What is a process models?

Process model or modeling is a technique for organizing and documenting the structure and flow of data through a system’s processes and/ or the logic, policies and procedures to be implemented by a system’s processes.

Software process models are universal approaches to organize projects into actions. Regularly represents a system series of activities, objects, transformations, and events that symbolize strategies for accomplishing software evolution. These models can be used in developing more precise and formalized descriptions of software life cycle activities.

Process models

Waterfall Model- is a sequential software development process, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of Conception, Initiation, Analysis, Design (validation), Construction, Testing and maintenance.

The waterfall model derives its name due to the cascading effect from one phase to the other as is illustrated in Figure1.1. In this model each phase well defined starting and ending point, with identifiable deliveries to the next phase.



The model consist of six distinct stages, namely:
 
1.      In the requirements analysis phase
(a)    The problem is specified along with the desired service objectives (goals)
(b)   The constraints are identified
 
2.      In the specification phase the system specification is produced from the detailed definitions of  (a) and (b) above. This document should clearly define the product function.
 
Note that in some text, the requirements analysis and specifications phases are combined and represented as a single phase.
 
3.      In the system and software design phase, the system specifications are translated into a software representation. The software engineer at this stage is concerned with:
·        Data structure
·        Software architecture
·        Algorithmic detail and
·        Interface representations
 
The hardware requirements are also determined at this stage along with a picture of the overall system architecture. By the end of this stage the software engineer should be able to identify the relationship between the hardware, software and the associated interfaces. Any faults in the specification should ideally not be passed ‘down stream’
  
4.      In the implementation and testing phase stage the designs are translated into the software domain
·        Detailed documentation from the design phase can significantly reduce the coding effort.
·        Testing at this stage focuses on making sure that any errors are identified and that the software meets its required specification.
 
5.      In the integration and system testing phase all the program units are integrated and tested to ensure that the complete system meets the software requirements. After this stage the software is delivered to the customer [Deliverable – The software product is delivered to the client for acceptance testing.]
  
6.      The maintenance phase the usually the longest stage of the software. In this phase the software is updated to: 
·        Meet the changing customer needs
·        Adapted to accommodate changes in the external environment
·        Correct errors and oversights previously undetected in the testing phases
·        Enhancing the efficiency of the software
 
Observe that feed back loops allow for corrections to be incorporated into the model. For example a problem/update in the design phase requires a ‘revisit’ to the specifications phase. When changes are made at any phase, the relevant documentation should be updated to reflect that change.
 
Advantages
·        Testing is inherent to every phase of the waterfall model
·        It is an enforced disciplined approach
·        It is documentation driven, that is, documentation is produced at every stage
 
Disadvantages
 
The waterfall model is the oldest and the most widely used paradigm.
However, many projects rarely follow its sequential flow. This is due to the inherent problems associated with its rigid format. Namely:
·        It only incorporates iteration indirectly, thus changes may cause considerable confusion as the project progresses. 
·        As The client usually only has a vague idea of exactly what is required from the software product, this WM has difficulty accommodating the natural uncertainty that exists at the beginning of the project.
·        The customer only sees a working version of the product after it has been coded. This may result in disaster if any undetected problems are precipitated to this stage.



Iterative and Incremental Model-The product is designed, implemented, integrated, and tested as a series of incremental builds, where a build consists of code pieces from various modules interacting to provide a specific functional capability.

The basic idea behind iterative enhancement is to develop a software system incrementally, allowing the developer to take advantage of what was being learned during the development of earlier, incremental, deliverable versions of the system. Learning comes from both the development and use of the system, where possible key steps in the process are to start with a simple implementation of a subset of the software requirements and iteratively enhance the evolving sequence of versions until the full system is implemented. At each iteration, design modifications are made and new functional capabilities are added.

Strengths:
a.Maximizes early return on investment
b.Promotes Maintainability

Weaknesses:
a.Requires open architecture
b.May degenerate into build- And-fix



Extreme Programming- It is a new approach to software development based on the incremental model. Other elements of Extreme Programming include: programming in pairs or doing extensive code review, unit testing of all code, avoiding programming of features until they are actually needed, a flat management structure, simplicity and clarity in code, expecting changes in the customer's requirements as time passes and the problem is better understood, and frequent communication with the customer and among programmers. The methodology takes its name from the idea that the beneficial elements of traditional software engineering practices are taken to "extreme" levels, on the theory that if some is good, more is better. It is unrelated to "cowboy coding", which is more free-form and unplanned. It does not advocate "death march" work schedules, but instead working at a sustainable pace.

Strengths:
a.Maximizes early return on investment
b.Works well when client’s requirements are vague

Weaknesses:
a.Has not yet been widely used



REFERENCES:
Schach, R.(2002) Object-Oriented and Classical Software Engineering. Crawfordsville: R.R. Donelley & Sons Company.
Whitten L., Bentley D., & Dittman C. (2000) Systems Analysis and Design Methods. Versailles: Quebecor World
http://en.wikipedia.org/wiki/Software_development_process#Models
http://en.wikipedia.org/wiki/Waterfall_modelhttp://en.wikipedia.org/wiki/Spiral_model
http://en.wikipedia.org/wiki/Incremental_development
http://en.wikipedia.org/wiki/Extreme_Programming