Software Process, Perspective and Specialized Process Models:
One of the primary duties of the manager of a software development project is to ensure that all of the project activities follow a certain predefined process, i.e. that the activities are organized as a series of actions conducing to a desirable end. The activities are usually organized in distinct phases, and the process specifies what artifacts should be developed and delivered in each phase. For a software development team, conforming to a certain process means complying with an appropriate order of actions or operations. For the project manager, the process provides means for control and guidance of the individual team members and the team as a whole, as it offers criteria for tracing and evaluation of the project's deliverables and activities.
Software development process encompasses many different tasks, such as domain analysis and development planning, requirements specification, software design, implementation and testing, as well
as software maintenance. Hence it is no surprise at all that a number of software development processes exist. Generally, processes vary with the project’s goals (such as time to market, minimum cost, higher quality and customer satisfaction), available resources (e.g., the company’s size, the number, knowledge,
and experience of people -- both engineers and support personnel -- and hardware resources), and application domain.
However, every software developer and manager should note that processes are very important. It is absolutely necessary to follow a certain predefined process in software development. It helps developers understand, evaluate, control, learn, communicate, improve, predict, and certify their work. Since processes vary with the project's size, goals, and resources, as well as the level at which they are applied (e.g., the organization level, the team level, or the individual level), it is always important to define, measure, analyze, assess, compare, document, and change different processes.
There are several well-known examples of software development processes. Each process relies on a certain model of software development. The first well-established and well-documented software development process has followed the waterfall model. One of its variants is shown in Figure 2. The model assume that the process of software development proceeds through several phases in a more-or-less linear manner. The phases indicated in Figure 2 are supposed to be relatively independent. There is not much feedback and returning to previous phases other than the one directly preceding the phase in focus. In other words, once a certain phase is finished it is considered closed, and the work proceeds with the next phase. Many developers have criticized the waterfall model for its rigidity in that sense, and for its failure to comply with the reality of ever-changing requirements and technology. However, the waterfall model is at least partially present in most of the other models as well, simply because of its natural order of phases in software development.
Detailed design Module coding and testing
Figure 2 - The waterfall model of software development
There have been many attempts to overcome the limitations of the waterfall model. Two common points in all such attempts are introduction of iterations in software development activities and incremental development. Iterative and incremental software development means going through the same activities more than once, throughout the product's lifecycle, each time producing new deliverables and/or improving the old ones. The main advantage of working in that way is that each individual developer works on a small ``work packet" at any given moment, which is much easier to control.
A classical example of iterative and incremental models is the spiral model, sketched in Figure 3. In the spiral model, there are five core tasks: planning and design (largely corresponding to the classical analysis phase), approval (requirements specification), realization (design and implementation), revision (testing and modification), and evaluation (integration and system-level testing). The process iterates through these tasks, getting closer and closer to the end by adding increments (e.g., new functions, new design, new modules, new or improved testing procedures, new or improved parts of the user interface, new integration and testing certificates, and so on) to the product in each iteration. The spiral model underlies many processes, such as DBWA (Design By Walking Around), and PADRE (Plan-Approve-Do-Review-Evaluate). The DBWA process combines the spiral model with multiple design views, flexible structuring of development teams, and dynamic changes in modes of working (e.g., working individually, working in pairs, or working in small teams), in order to improve the process efficiency and parallelism. The PADRE process uses the spiral model at multiple levels - the project level, the phase level, and the individual software module level - thus creating the ``spiral in a spiral in a spiral" effect.
The JNIDS model (Joint National Intelligence Development Staff) is similar to the spiral model in that it is also iterative and incremental. There are, however, six tasks in the JNIDS model: requirements analysis, team orchestration (i.e. the team-building stages, ``forming, storming, norming, and performing"), design, coding, integration, and system implementation (delivery and maintenance). The model prescribes to iterate through all six tasks in every phase of software development. There are five phases (requirements identification, prototype development, the breadth of system functionality, system functionality refinement, and transition). They differ in the amount of time and effort they dedicate to each specific task. The first phase focuses most on requirements analysis, the second one focuses most on team orchestration, and so on. The last phase is concentrated most on integration and maintenance. Hence on the time axis the shift of the focus of attention in different phases generates a waterfall-like shape if the six tasks are put on the ordinal axis. However, an important difference between the classical waterfall and JNIDS models is that in the JNIDS model developers conduct their activities through all tasks in each phase.
The Unified Process for object-oriented software development, Figure 4, has recently become very popular. It is also iterative and incremental, just like the spiral and JNIDS models. All of its iterations go through five core workflows (tasks) shown in Figure 4, and are grouped in four phases - inception (resulting in a global vision of the software product), elaboration (detailed analysis and design of the baseline architecture), construction (building the system's initial capability), and transition (product release). Just like in the JNIDS model, Figure 4 shows ``fuzzified" traces of the waterfall model in the Unified Process. The process is architecture-centric, meaning that its main deliverable is an executable architecture (the system), described by a set of models generated during the system development (use-case model, analysis model, design model, deployment model, implementation model, and test model). The models are represented using the standard UML diagrams . The Unified Process is also use-case oriented, which means that generic scenarios of how the user or external applications use the system or its subsystems bind all the workflows and drive the iterations.
Being iterative, the Unified Process reduces additional development costs generated by unexpected situations (usually just a single iteration of work is lost). Iterating through all core workflows in every iteration, the process is compliant with the reality of ever changing and incomplete user requirements. The Unified Process is also risk-driven - it enforces examining areas of highest risk in every phase and every iteration, as well as doing the most critical tasks first. Hence it minimizes the risk of project runaways. Managers can easily adapt the Unified Process to different application types, project sizes, development teams, and levels of competence.
Because of the importance of the Unified Process for software project management today, comments on some other issues from the Unified Process perspective are included in the following chapters.