3 Software Development Life Cycle

R. Baskaran

 

Project Planning is an aspect of Project Management that focuses a lot on Project Integration. The project plan reflects the current status of all project activities and is used to monitor and control the project.

 

The Project Planning tasks ensure that various elements of the Project are coordinated and therefore guide the project execution.

 

Project Planning helps in

 

–  Facilitating communication

–  Monitoring/measuring the project progress, and

–  Provides overall documentation of assumptions/planning decisions

 

The Project Planning Phases can be broadly classified as follows:

 

–  Development of the Project Plan

–  Execution of the Project Plan

–  Change Control and Corrective Actions

 

Project Planning is an ongoing effort throughout the Project Lifecycle.

 

Why is it important?

 

“If you fail to plan, you plan to fail.”

Project planning is crucial to the success of the Project.

Careful planning right from the beginning of the project can help to avoid costly mistakes. It provides an assurance that the project execution will accomplish its goals on schedule and within budget.

 

What are the steps in Project Planning?

 

Project Planning spans across the various aspects of the Project. Generally Project Planning is considered to be a process of estimating, scheduling and assigning the projects resources in order to deliver an end product of suitable quality. However it is much more as it can assume a very strategic role, which can determine the very success of the project. A Project Plan is one of the crucial steps in Project Planning in General!

 

Typically Project Planning can include the following types of project Planning:

  1. Project Scope Definition and Scope Planning
  2. Project Activity Definition and Activity Sequencing
  3. Time, Effort and Resource Estimation
  4. Risk Factors Identification
  5. Cost Estimation and Budgeting
  6. Organizational and Resource Planning
  7. Schedule Development
  8. Quality Planning
  9. Risk Management Planning
  10. Project Plan Development and Execution
  11. Performance Reporting
  12. Planning Change Management
  13. Project Rollout Planning

We now briefly examine each of the above steps:

 

1)  Project Scope Definition and Scope Planning:

 

In this step we document the project work that would help us achieve the project goal. We document the assumptions, constraints, user expectations, Business Requirements, Technical requirements, project deliverable, project objectives and everything that defines the final product requirements. This is the foundation for a successful project completion.

 

2)  Quality Planning:

 

The relevant quality standards are determined for the project. This is an important aspect of Project Planning. Based on the inputs captured in the previous steps such as the Project Scope, Requirements, deliverable, etc. various factors influencing the quality of the final product are determined. The processes required to deliver the Product as promised and as per the standards are defined.

 

3)  Project Activity Definition and Activity Sequencing:

 

In this step we define all the specific activities that must be performed to deliver the product by producing the various product deliverable. The Project Activity sequencing identifies the interdependence of all the activities defined.

 

4)  Time, Effort and Resource Estimation:

 

Once the Scope, Activities and Activity interdependence is clearly defined and documented, the next crucial step is to determine the effort required to complete each of the activities. See the article on “Software Cost Estimation” for more details. The Effort can be calculated using one of the many techniques available such as Function Points, Lines of Code, Complexity of Code, Benchmarks, etc.

 

This step clearly estimates and documents the time, effort and resource required for each activity.

 

5) Risk Factors Identification:

 

“Expecting the unexpected and facing it”

It is important to identify and document the risk factors associated with the project based on the assumptions, constraints, user expectations, specific circumstances, etc.

6) Schedule Development:

 

The time schedule for the project can be arrived at based on the activities, interdependence and effort required for each of them. The schedule may influence the cost estimates, the cost benefit analysis and so on.

 

Project Scheduling is one of the most important task of Project Planning and also the most difficult tasks. In very large projects it is possible that several teams work on developing the project. They may work on it in parallel. However their work may be interdependent.

 

Again various factors may impact in successfully scheduling a project o Teams not directly under our control

o Resources with not enough experience

 

Popular Tools can be used for creating and reporting the schedules such as Gantt Charts

7)   Cost Estimation and Budgeting:

 

Based on the information collected in all the previous steps it is possible to estimate the cost involved in executing and implementing the project. See the article on “Software  Cost Estimation” for more details. A Cost Benefit Analysis can be arrived at for the project. Based on the Cost Estimates Budget allocation is done for the project.

8)   Organizational and Resource Planning

 

Based on the activities identified, schedule and budget allocation resource types and resources are identified. One of the primary goals of Resource planning is to ensure that the project is run efficiently. This can only be achieved by keeping all the project resources fully utilized as possible. The success depends on the accuracy in predicting the resource demands that will be placed on the project. Resource planning is an  iterative process and necessary to optimize the use of resources throughout the project life cycle thus making the project execution more efficient. There are various types of resources – Equipment, Personnel, Facilities, Money, etc.

 

9)   Risk Management Planning:

 

Risk Management is a process of identifying, analyzing and responding to a risk. Based on the Risk factors Identified a Risk resolution Plan is created. The plan analyses each of the risk factors and their impact on the project. The possible responses for each of them can be planned. Throughout the lifetime of the project these risk factors are monitored  and acted upon as necessary.

 

10)  Project Plan Development and Execution:

 

Project Plan Development uses the inputs gathered from all the other planning processes such as Scope definition, Activity identification, Activity sequencing, Quality Management Planning, etc. A detailed Work Break down structure comprising of all the activities identified is used. The tasks are scheduled based on the inputs captured in the steps previously described. The Project Plan documents all the assumptions, activities, schedule, timelines and drives the project.

 

Each of the Project tasks and activities are periodically monitored. The team and the stakeholders are informed of the progress. This serves as an excellent communication mechanism. Any delays are analyzed and the project plan may be adjusted accordingly

 

11)   Performance Reporting:

 

As described above the progress of each of the tasks/activities described in the Project plan is monitored. The progress is compared with the schedule and timelines documented in the Project Plan. Various techniques are used to measure and report the project performance such as EVM (Earned Value Management) A wide variety of tools can be used to report the performance of the project such as PERT Charts, GANTT charts, Logical Bar Charts, Histograms, Pie Charts, etc.

 

12)   Planning Change Management:

 

Analysis of project performance can necessitate that certain aspects of the project be changed. The Requests for Changes need to be analyzed carefully and its impact on the project should be studied. Considering all these aspects the Project Plan may be modified to accommodate this request for Change. Change Management is also necessary to accommodate the implementation of the project currently under development in the production environment. When the new product is implemented in the production environment it should not negatively impact the environment or the performance of other applications sharing the same hosting environment.

 

13)   Project Rollout Planning:

 

In Enterprise environments, the success of the Project depends a great deal on the  success of its rollout and implementations. Whenever a Project is rolled out it may affect the technical systems, business systems and sometimes even the way business is run. For an application to be successfully implemented not only the technical environment should be ready but the users should accept it and use it effectively. For this to happen the users may need to be trained on the new system. All this requires planning.

 

The Waterfall methodology—also known as the Waterfall Model—is a sequential software development process, where progress flows steadily toward the conclusion (like a waterfall) through the phases of a project (that is, analysis, design, development, testing). This involves fully documenting a project in advance, including the user interface, user stories, and all the features’ variations and outcomes.

 

The goal of the Waterfall methodology follows the old adage to “measure twice, cut once.” A detailed investigation and full research into a product feature is conducted up front, eliminating (most) project risks. With the bulk of the research done in advance, estimates of the time required for each requirement are more accurate, thus providing a more predictable release date.

 

Project phases for software development using the Waterfall Model

ANALYSIS

 

The product development team analyzes the requirements, and fully understands the problems. This is a research phase that includes no building. The team attempts to ask all the questions and secure all the answers they need to build the product requirement.

 

DESIGN

 

The software developers design a technical solution to the problems set out by the product requirements, including scenarios, layouts and data models. This phase is usually accompanied by documentation for each requirement, which enables other members of the team to review it for validation. Once the design is approved, technical implementation begins. This is often the shortest phase because research and design have been done in advance.

 

TESTING

 

Upon completion of full imp lementation, testing needs to occur before the product can be released to customers. The software testing team will use the design documents, personas and user case scenarios delivered by the product manager in order to create their test cases.

 

Adaptation during product development

 

If nothing changes over the course of the product development, then estimates generated from the Waterfall methodology will result in a predictable release date.

 

However, change is inevitable, and will come in many different forms. For example, you might learn more information about a feature and will need to adjust the requirements,   or your team might realize once they begin the build that it is more complicated than initially imagined. These factors will change the delivery dates, and add risk to the project.

 

In the Waterfall Model, change is expensive because most of the time and effort has been spent early on in the design and analysis phases. Also, because the team will be so invested in the requirements before the project begins, there may be considerable resistance to change.

 

PRODUCT MANAGER’S ROLE IN WATERFALL METHODOLOGY

 

In the Waterfall methodology, the role of the product manager is to create the requirements and ask all pertinent questions up front. Because the team does all of the research and design in the initial phases, the requirements given must be as complete as possible. As well, the requirements drive the detailed estimates on which the project plan will be based.

 

The Waterfall methodology is a documentation-heavy approach because it relies on the “measure twice, cut once” theory. The product manager’s workload is much heavier at the beginning of the project than it is during the actual release. The aim is to ask all pertinent questions in advance to minimize change during the development process, especially since change is relatively expensive.

 

Customer input in the Waterfall methodology

 

The nature of the Waterfall methodology insists that each phase be complete and perfected before the start of the next phase. This prevents customers from reviewing and providing feedback on a project before its release. Even if suggestions were solicited, since change is expensive, the team will be less flexible about accepting feedback.

 

Building solutions that have features that are not dependent on each other can help mitigate these issues, although challenges will remain. For example, a wind -powered energy solution may have different components, and by ensuring that each part can work independently, your team can mitigate overall project risk.

 

Example: Product development—Waterfall methodology

 

If a team were to develop a customer address book using the Waterfall methodology, the order of work would be as follows (timeframes are for demonstration purposes only):

 

PRODUCT REQUIREMENTS

 

Product manager creates requirements documents that include the following requirements (in order of priority):

  • User should be able to create new contacts.
  • User should be able to view their contacts.
  • User should be able to import contacts from other programs.
  • User should be able to email their contacts from the address book.
  • User should be able to add pictures to represent their contacts.

These requirement documents will include detailed requirements, user scenarios and potential layouts for the functionality.

 

Timeframe: 2 weeks

 

ANALYSIS

 

Engineering team takes these requirements and analyzes them, asking questions as needed. Product manager updates documents as questions are resolved.

 

Timeframe: 1 week

 

DESIGN

 

Engineering team creates a design for functionality, including database design, mock- ups and workflows.

 

Timeframe: 3 weeks

Engineering team develops functionality and prepares it for testing.

Timeframe: 1 week

 

SOFTWARE PRODUCT TESTING

 

Product team tests entire functionality.

Timeframe: 2 weeks

 

RELEASE

The product functionality is released.

TOTAL elapsed time: 9 weeks

 

Waterfall Model is also known as Liner Sequential Life Cycle Model. Waterfall Model followed in the sequential order and so we move to next step of development or testing   if the previous step completed successfully. Waterfall Model is very successful approach for the small projects and if the requirements are very clear. In Waterfall Model, testing starts at the end when development work is completed. The name Waterfall describes  that testing or development is carried out in downward mechanism like water falls towards down. Waterfall Model is very popular strategy for SDLC. Once Waterfall Model is followed and if any step completed and next step has been started in development process, we can’t revert back to the previous step to redevelop or perform any change. Waterfall Model concept first introduced in 1970 by Winston W. Royce.

 

Phases in Waterfall Model-

Requirements

Analysis

Design

Implementation

Testing

Deployment

Maintenance

waterfall

  1. Requirements: This is the first phase of development where all the requirements gathered and documented.
  2. Analysis: In this phase we analyze all the gathered requirements whether the requirements are valid or invalid.
  3. Design: In this phase all the system design is analyzed and specified like hardware, system configuration and architecture or the system.
  4. Implementation: In this phase all the development works are performed and development components or units handed over to testing team.
  5. Testing: Once the development completed, testing phase starts and in this phase we test the each unit or component and make sure the developed components are working as expected. All the testing activities are performed in this phase.
  6. Deployment: Once testing is completed and make sure there is no bug or defect or any kind of issue, then project is deployed to production. Once product is deployed to production the end users start using the product.
  7. Maintenance: We always keep eye on the product and provide all the necessary bug or issue fixes if occurs in production or reported by end users. Also time to time we keep updated the product with new updates or patches if developed or available.

 

Advantages of Waterfall Model:

  • Very good approach for small projects.
  • Easy to use and follow.
  • Cost effective.
  • Each phase completely developed.
  • Development processed in sequential manner so very less chance to rework.
  • Easy to manage the project.
  • Easy documentation.

 

Disadvantages of Waterfall Model:

  • Not very useful for the large project.
  • Less effective if requirements are not very clear at the beginning.
  • Very difficult to move back to change on the previous phase.
  • Testing starts once development completes, so more and more chances of bugs to be found.
  • High risk.
  • Less flexible.

 

When Waterfall Model should be followed:

 

If project is small and requirements are very clear. For low budget projects. The Waterfall Model was first Process Model to be introduced. It is also referred to as  a linear-sequential life cycle model.  It is very simple to understand and use.  In a waterfall model, each phase must be completed fully before the next phase can begin.

 

This type of model is basically used for the for the project which is small and there are no uncertain requirements. At the end of each phase, a review takes place to determine if the project is on the right path and whether or not to continue or discard the project. In this model the testing starts only after the development is complete. In waterfall model phases do not overlap.

 

Advantages of waterfall model:

  • This model is simple and easy to understand and use.
  • It is easy to manage due to the rigidity of the model – each phase has specific deliverables and a review process.
  • In this model phases are processed and completed one at a time. Phases do not overlap.
  • Waterfall model works well for smaller projects where requirements are very well understood.

 

Disadvantages of waterfall model:

  • Once an application  is  in the testing stage,  it is  very difficult to  go back and change something that was not well-thought out in the concept stage.
  • No working software is produced until late during the life cycle.
  • High amounts of risk and uncertainty.
  • Not a good model for complex and object-oriented projects.
  • Poor model for long and ongoing projects.
  • Not suitable for the projects where requirements are at a moderate to high risk of changing.

 

When to use the waterfall model:

  • This model is used only when the requirements are very well known, clear and fixed.
  • Product definition is stable.
  • Technology is understood.
  • There are no ambiguous requirements
  • Ample resources with required expertise are available freely
  • The project is short.

 

Very less customer enter action is involved during the development of the product. Once the product is ready then only it can be demoed to the end users. Once the product is developed and if any failure occurs then the cost of fixing such issues are very high, because we need to update everywhere from document till the logic.

 

In waterfall model it is very important to take the sign off for the deliverable of each phase. As of today most of the projects are moving with Agile and Prototype models, Waterfall model still holds good for smaller projects. If requirements are straightforward and testable, Waterfall model will yield the best results.

 

Quadrant 4 – Learn More/ Web Resources / Supporting Materials

Web Links
http://www.tutorialspoint.com/software_engineering/software_engineering_overview.htm
http://www.practicalprocess.com/seyp/definition.html
http://www.softwareengineerinsider.com/articles/what-is-software- engineering.html#.V44IRtJ97Dc

Supporting & Reference Materials
Roger S. Pressman, “Software Engineering: A Practitioner’s Approach”, Fifth Edition, McGraw Hill, 2001.
PankajJalote, “An Integrated Approach to Software Engineering”, Second Edition, Springer Verlag, 1997.
Ian Sommerville, “Software Engineering”, Sixth Edition, Addison Wesley, 2000.

Glossary

Starting char Term Definition Re late d Te rm
S Software Engineering It is the building of software systems which are so large or so complex that they are built by a team or teams of engineers Software Development
C Change Control Change control is a systematic approach to managing all changes made to a product or system Versioning
R Reliability It is the probability of failure-free software operation for a specified period of time in a specified environment. QoS, Software Quality
C Cost Estimation It is the approximation of the cost of a program, project, or operation. Estimate

Points to Ponder

S.No Points to Ponder
1. Good notations can clarify the relationships and interactions of interest.
2. The existence of standard practices is one of the distinguishing characteristics of a professional  discipline.
3. Team communication, product complexity, facilities and resources, etc are some of the quality and productivity factors.
4. Functionality, reliability usability, efficiency, maintainability are some of the characteristics of software quality.