I see the object-oriented process model as being an improvement over the tradition process model. The traditional method is simple to follow and create related documentation, but there are limitations of the ability to be flexible with changes throughout the process. I understand the simplicity of the traditional approach to process modeling, but if you have been involved in a major project that uses it, you know and understand the limitations. The object-oriented approach just has more flexibility and the ability to modify or make corrections as you go through the process. Reliability, flexibility, usability, and maintainability are all still very valid measures of software quality. I work for a small company, and I know firsthand the issues that come along with homegrown software, and how it often has no real quality control, and certainly does not follow any industry standard for testing on these four factors or typically any others. This is where the human factor comes in on at least one level. When you are building software in house, whether as a team, or more typically for a small company, one individual, individual thought rule the design more than industry standards.
One reason for this is because people have a habit of doing thing the simplest way possible, and a lot of old school programmers like to cut corners. Ultimately the end user should be the judge of the quality of the software, and there should be a process in place for end user input. I think the best way to ensure that the end user will be happy with the product, is to stress proper planning and to have meeting the stakeholder expectations as you primary goal. So to me, the choice of process modeling is important. I have been involved in many projects where in house software was developed, but one instance, I find very relevant to this topic. I was involved with an in house development project where we used SAP’s ABAP code and Visual Basic to develop and interface between SAP, Milsoft’s mapping solution, a mobile GPS system, and Google Earth, to display real time information about the location, direction, and speed of a fleet of vehicles. This was for an electrical utility with about 75 vehicles of various sizes and models. This was unique, because the stakeholders know that they wanted something, but really did not understand the capabilities of each of the systems, and therefore did not really have well defined expectations regarding the final product. I see this as an instance where the object-oriented approach just has more flexibility and the ability to modify or make corrections as you go through the process. We needed that for this project and ended up making changes as we went. You could argue that the traditional method would have been very thorough in gathering the stakeholder requirement in the beginning of the project, but often the client is not sure of what they want at the beginning. Therefore for this instance and most, a more modern approach to process modeling is desired.
Basically, the requirements elicitation is what I would call a needs assessment. The requirements definition defines the expected functionality of a new system. It is the base from which developers develop, programmers program, testers test, and the users accept or reject a software product and its components. The human factor comes into play here heavily because humans are asking the questions and defining the expectations. This definition is the result of technical professional, through the process of the requirements elicitation, trying to get information from non technical users. When creating a requirements definition or requirements document, you should ask for certain project characteristics to flush out, so to speak, the needed information for successful project and end result. Some of these things include: Preconditions and Assumptions, High-Level Description of Functionality, Functional Requirements, Data Constraints, Design and Interface Constraints, and Quality Requirements. Some options to help in the process are: One-on-one interviews; Group interviews; Questionnaires; Prototyping; Use cases; Following people around; and Brainstorming.
There are two data models that I am used to for this purpose, the bottom-up model or view integration model and the top-down or logical data model. I prefer the top-down or logical data model because it is focused on getting real world date from stakeholders, super users, and subject matter experts. This is the way that I have always done my requirement gathering. I am familiar with the bottom-up model, by my understanding is that it is usually employed for copying functionality or re-engineering. Although copying functionality is a common thing, especially when moving from legacy software to something new. This can be due to company growth or acquisition .
The IT department gets pushed around in a lot of companies because technology is still seen as a necessary evil by a lot of older managers. This is defiantly a challenge for a lot of people. This is changing and has for the most part in larger companies, but since most companies are smaller, it is a slow process. Human error is also a big factor in any project. As a project manager, you have to trust in the project team members and their abilities. However, even when under close supervision, humans make mistakes. One way to avoid some of these mistakes is to properly gather and document the stakeholder requirements early on in the project, and in detail. This requires the use of data gathering techniques, or data models. As for properly defining the needs, this is a function of good communication, collaboration, and compromise between project team members and stakeholders. One tactic to facilitate this exchange is to use functional liaisons or super users to bridge the gap between the technical and the functional.
One mistake that a lot of companies make is that they don’t allocate enough resources to these important projects. The requirement management process drives quality the assurance processes heavily, like the old adage “garbage in, garbage out”. Also following the strategies above to properly gather and document the needs of the stakeholders. This will minimize the chance of error and help to keep the project on time and under budget. One big project killer is additional consultant hours and the associated cost due to scope creep. This scope creep is usually present because the need was not defined early in the process. Defining the need is one of the steps in the process model, and choosing a process model depends on what you are doing, but for most IT development, a flexible and circular model is better.