Skip to main content

Introduction to Software Process Models

Software Development Life Cycle (SDLC)
The SDLC is systemic approach, defining the steps to be followed by the system engineers and systems developers in the development of software product in various phases of requirement analysis, design, implementation, testing, deployment and maintenance. The figure below illustrates the SDLC:

Engineering Study Material
Following are the phases mentioned in detail inthe SDLC process:
  • Project Planning
  • Requirements Development
  • Estimation
  • Scheduling
  • Design
  • Coding
  • Test Build/Deployment
  • Unit Testing
  • Integration Testing
  • User Documentation
  • System Testing
  • Acceptance Testing
  • Production Build/Deployment
  • Release
  • Maintenance
  1. ProjectPlanning:
    The Projects planning is a subset of the super set project management. Project planning can at its best be defined in the words Harold Kerzner as “the use of schedules such as Gantt charts to plan and subsequently report progress within the project environment.”
    Steps involve in this phase are:
    • Prepare
    • Review
    • Rework
    • Baseline
    • Revise and if everything comes out to be perfect proceed to next phase
  2. Requirements Analysis
    On successful completion of the project planning stage, here comes the important phase that is requirement analysis. In this phase the Business and product requirements are gathered. This stage is the key for successful software development. The bug free Software is not the best software, rather the software which meets the user requirements is termed as best software. How much ever good software might be, if doesn’t meet the user requirements it can’t be termed as best software. Such is the significance of requirements analysis stage. Most of projects do fail due to incompetence in requirement analysis data. This happens in two cases:
    1. Project team failure in gathering requirements specifications.
    2. Lack of clarity in user regarding what exactly he wants.
  3. Designing
    In this stage all the requirements will be transformed in to High Level Design and Detail Design case diagrams that are required to deliver the expected functionality. Often Unified modeling language is used for diagrammatic representation of tasks in the form of use case diagrams. This guides the developers in developing code strictly sticking to the requirements.

  4. Coding or development phase:
    The designing phase designs will be translated in to developmental code and ready to run executable files. Also all the code modules are integrated in to a single executable code and sent for testing.

  5. Testing:
    The key for software success lies in testing. Even if the project turns out to be outstanding with no bugs, if the project fails to meet the user requirements, the software is considered as failure. Here test cases are prepared and tested in all the environments, platforms and frameworks to ensure that the software meets all the requirements and runs with no failure and great quality. Each unit of the project is tested separately for bugs; this sort of testing procedure is referred to as unit testing. Once unit testing is done, then all the units are integrated and prepared as single executable code and tested, this is referred to as integration testing.

  6. Documentation
    The functionality of each modules and over all structure of software are documented in the form of manuals to assist client in the operating the product.

  7. Deployment
    After a rigorous case checks performed at various levels of software development, after getting approval from all the teams the project finally will be deployed to the client.

  8. Operation & Maintenance:
    Even after performing various number rigorous checks prior to deployment, bugs are expected to rise in client environment because of various reasons like: lack of knowledge on product, ignorant client operations, being run on alien environments unknown to the team, etc. To avoid this clients are given training on this on how to operate and also if any bugs are reported then the product is updated by rectifying. This is an ongoing process.
Software Process Models
Software process models are methodologies that are being selected for the development of the project depending on the project’s aims and goals. These models guide the software development process across software development life cycle, on what which strategy to be implemented. Picking of software process model depends on software objectives. This provide a deep insight on the transformation of each stage of software There many
  1. The waterfall model
  2. Evolutionary process models,
  3. The Unified process model.
1. Waterfall model:
Waterfall mode is the basic and the first software process model and is refereed to as sequential design process model. The waterfall model derives from the principles of construction and manufacturing industry, which is attorney of a traditional developmental model irrespective of the type of industry.

The first formal description of the waterfall model is often cited as a 1970 article by Winston W. Royce,a pioneer in the field of “software development”. although Royce did not use the term "waterfall" in that article. Royce presented this model as an example of a flawed, non-working model.

Waterfall model stages and sequential flow of the stages is diagrammatically demonstrated in the below figure:
Engineering Study Material
In Waterfall model , as in other manufacturing projects, all the requirements of the project will be gathered and analyzed before kickstarting the project.

Requirement Analysis:
During this phase research is being conducted which includes brainstorming about the software, what it is going to be and what purpose is it going to fulfill.

Requirement Specifications:
In this stage, after gathering thorough requirement analysis, basic formulation of the specifications and briefing of the project. Well thought plan will be developed which will be foundation for the software design.

Design & Development:
After the basic requirement specification Is done with perfection, then a more elaborated technical design, development and prototyping will be planned. Here the functions of each of the part are decided and the engineering units are placed for example modules, programs etc.

Construction / Implementation:
With prototype developed in reference to the design and development phase, the source code of the programs is written in this phase.

Testing:
The success software is the one which is not just bug free one, it is which meets client requirements. In this complete project is subjected to testing to find out if any bugs exist and does it meets all the customer requirements. If test results positive the code is routed to next phase, if test results negative again the code is sent to coding team and asked recheck the code. This cycle continues till the test case turns positive.

Integration:
With testing phase reusulting positive code be will be routed to code integration phase. In the phase of Integration, the company puts it in use after the system has been successfully tested.

Management and Maintenance:
Maintenance and management is needed to ensure that the system will continue to perform as desired.

In waterfall, 20–40% of the time invested for the first two phases, 30–40% of the time to coding, and the rest dedicated to testing and implementation.

Strengths
  • Easy to understand, easy to use
  • Provides structure to inexperienced staff
  • Milestones are well understood
  • Sets requirements stability
  • Good for management control (plan, staff, track)
  • Works well when quality is more important than cost or schedule
Drawbacks:
  • All requirements must be known upfront
  • Deliverable created for each phase are considered frozen – inhibits flexibility
  • Can give a false impression of progress
  • Does not reflect problem-solving nature of software development – iterations of phases
  • Integration is one big bang at the end
  • Little opportunity for customer to preview the system (until it may be too late)
When to use the Waterfall Model
  • Requirements are very well known
  • Product definition is stable
  • Technology is understood
  • New version of an existing product
  • Porting an existing product to a new platform.
2. Evolutionary process models
2.1 Incremental process model:
In incremental process model the functionality of the desired system is divided into small modules, that follows all the stages of waterfall model and after on succession next module is picked up. Each increment is chosen so that it expands on the previous one, and is small enough to produce quickly. During the design phase of the first increment, the functionality with topmost priority from the project activity list is selected and the design is prepared. In the implementation phase, the design is implemented and tested. In the analysis phase, the functional capability of the partially developed product is analyzed. The development process is repeated until all the functions of the project are implemented. With it can clearly said that the incremental Model is an evolution of the waterfall model, where the waterfall model is incrementally applied.
Engineering Study Material

Advantages:
  • In waterfall customer interaction happens once, where as here there is good customer feedback at every stage of development
  • As small units are developed at every iteration, it is easy to test and debug
  • Lowers initial delivery cost.
  • Risk management is very easy as it is iteration based mechanism.
  • News Requirements can be added at any point of time.
  • Step by step progress is achieved.
  • Divide and conquer of requirements allows the developer to focus more.
  • Controls requirements creep and changes because user gains experience interacting with the system in earlier increments.
Disadvantages
  • Needs good planning and design.
  • Needs a clear and complete definition of the whole system before it can be broken down and built incrementally.
  • Costlier than than waterfall model.
  • It needs complete definition of the fully functional system early in the cycle to allow planning the increments.
  • Formal reviews and audits are harder to implement on increments than on complete system.
  • The analysis phase does not develop fully detailed complete requirements model which management may not be comfortable with.
  • Requires good planning skills for work to be distributed watching the dependencies.
When to use
  • When time is limited and there is a need to release the basic functionality soon.
  • In low risk cases.
  • This model can be used when the requirements of the complete system are clearly defined and understood.
  • Major requirements must be defined; however, some details can evolve with time.
  • There is a need to get a product to the market early.
  • A new technology is being used
  • Resources with needed skill set are not available
  • There are some high risk features and goals.
2.2 Spiral process model:
Spiral model proposed by Mr. Bohem, is evolved version of waterfall and incremental model combined. So the definition for spiral model can be thought of as: The spiral model, originally proposed by Boehm [BOE88], is an evolutionary software process model that couples the iterative nature of prototyping with the controlled and systematic aspects of the linear sequential model”

A spiral model is divided into number of framework activities, also called task regions. Each framework activity corresponds to section of the spiral path. As the development process starts, the software team perform activities that are indirect by a path around the spiral model in a clockwise direction. It begins at the center of spiral model. In total there are six task regions in spiral model, which is demonstrated in the figure below:
Engineering Study Material
Customer communication—tasks required to establish effective communication between developer and customer.
Planning—tasks required to define resources, timelines, and other project related information.
Risk analysis—tasks required to assess both technical and management risks.
Engineering—tasks required to build one or more representations of the application.
Construction and release—tasks required to construct, test, install, and provide user support (e.g., documentation and training).
Customer evaluation—tasks required to obtain customer feedback based on evaluation of the software representations created during the engineering stage and implemented during the installation stage.

Advantages of Spiral model:
  • Efficient Risk management, as there is large amount of time spent on risk analysis.
  • Very effective in case of big projects and mission critical projects.
  • Estimates ( i.e budget, schedule, etc) become more realistic as work progresses, because more important issues are discovered earlier.
  • Adaptive to the changes that software development generally entails. If in case some functions to be added in the later stages, it is easy to add.
  • Strong approval and documentation control.
  • Software is produced early in the software life cycle.
Disadvantages of Spiral model:
  • Costly model to use.
  • Need for highly specific expertise.
  • Project’s success is highly dependent on the risk analysis phase.
  • Doesn’t work well for smaller projects.
  • Highly customized limiting re-usability.
  • Applied differently for each application.
  • Risk of not meeting,budget or schedule.
When to use Spiral model:
  • When costs and risk evaluation is important
  • For medium to high-risk projects
  • Long-term project commitment unwise because of potential changes to economic priorities
  • When the client is not 100% sure of their needs
  • When the requirements are intricate
  • In case of research projects, significant changes are expected to happen during any phase of project in such cases spiral model comes very handy.
  • The spiral model thus may suit small software applications and not a complicated distributed, inter operable, system of systems.
  • It is also reasonable to use the spiral model in projects where business goals are unstable but the architecture must be realized well enough to provide high loading and stress ability.
2.3 The Concurrent Development Model
The concurrent development model, sometimes called concurrent engineering. The concurrent process model defines a series of events that will trigger transitions from state to state for each of the software engineering activities. For example,during early stages of design, an inconsistency in the analysis model is uncovered. This generates the event analysis model correction which will trigger the analysis activity from the done state into the awaiting changes state.

The concurrent development model - called concurrent engineering. It provides an accurate state of the current state of a project.
  • Focus on concurrent engineering activities in a software engineering process such as prototyping, analysis modeling, requirements specification and design.
  • Represented schematically as a series of major technical activities, tasks and their associated states.
  • Defined as a series of events that trigger transitions from state to state for each of the software engineering activities.
  • Often used as the paradigm for the development of client/server applications. A client/server system is composed of a set of functional components. When applied to client/server, the concurrent process model defines activities in two dimensions :(i) System dimension -System level issues are addressed using three activities: design, assembly, and use.(ii) The component dimension is addressed with two activities: design and realization.
The figure below provides schematic representation of one activity with the concurrent process model.
Engineering Study Material
The activity—analysis—may be in any one of the states noted at any given time. Similarly, other activities (e.g., design or customer communication) can be represented in an analogous manner. All activities exist concurrently but reside in different states. For example, early in a project the customer communication activity has completed its first iteration and exists in the awaiting changes state. The analysis activity (which existed in the none state while initial customer communication was completed) now makes a transition into the under development state. If, however, the customer indicates that changes in requirements must be made, the analysis activity moves from the under development state into the awaiting changes state.
Published date : 11 Mar 2015 12:19PM

Photo Stories