For developing systems/software that involves 10 Phases:
2. System Concept Development.
4. Requirements Analysis.
7. Integration and Testing.
9. Operations and Maintenance.
Initiation - Initiation is where there is an identified need for a new system. For
instance, a retailer of fine crystal glass is in need of a new system to handle inventory.
They've decided that the old System of putting the inventory into a simple spreadsheet
will no longer work. They want a system where they can track inventory, inventory cost,
facilities cost, personnel, a customer database, can track trends in buying, identify
inventory that is not moving well and price it to move, etc. In other words, they want to
be able to know everything with a few clicks of the keyboard. A Project Management is
placed in charge and he/she will develop a Concept Proposal - which is a document
identifying the problem and why the new system needs to be pursued. The document is
presented to upper management who approves it and the project moves on to the next
System Concept Development
- This is where the first real look at what will be necessary takes place. Several reports
can be created here.
- Feasibility Study (will it work?)
- Cost/Benefit Analysis (is the cost really worth it?)
- System Boundary (how far should the project go?)
- Risk Management (what will happen if we don't do it?)
These reports are then presented, again, to the powers that be and a decision is made
whether or not to go ahead. They approve the funding. If they give their approval it's on
to the next phase.
- Who is doing what, when, and how? What personnel are needed? Use existing
personnel or hire consultants? New Hardware? Develop own software or buy it off the
shelf? What are the Deliverables - such as completed software programming and
documentation, user manual, training, testing plans, etc? A Planning document is
submitted for approval.
- Documentation of requirements. What interfaces are required (will it run with Windows
NT and Windows XP?). What is the functionality required - should it be run with the
mouse or keyboard commands? What is the level of proficiency required by the user?
Will a new room be needed for the servers or equipment? Requirements documentation
is approved, and then it's on to the Design phase.
- Take those Requirements and develop detailed, workable specifications. This is where
everything is put together and the actual design of the system is done. This is also
where documentation such as the Maintenance Manual, Operations Manual, and Training
Manual begin. This is also where some of the flaws in the original planning may appear
and require some adjustment. Again, there is documentation and approval.
- The system is built. The software, hardware, and testing occur during the Development
Stage. This is also the phase where the bugs are worked out of the system. A
contingency plan is also developed at this point. A contingency plan is an emergency
management document. If the power goes out - what happens to the system? What is
the back up? How fast can it be brought back up to speed? Again, documentation and
approval (get used to this).
Integration and Testing Phase
- This is the formal integration and testing of the system. Testing has been done on the
development phase, but in the Integration and Testing Phase it is a formal, documented
testing procedure, not only to assure that the system performs as designed, but testing
the roll-out of the system. If there is already another system in place with data, how
fast can that data be migrated into the new system and useable to the company?
Usually, the system is rolled-out over a weekend so that if anything goes wrong, the old
system is still active and available. Integration and Testing is vital to the decision to go
"live" with the new system. If it fails testing, it cannot be trusted to work. Approval of
testing and test results is necessary before the project moves into implementation.
- Everything is ready and it's time to go live. Training takes place, everyone who will use
the system must be fully informed of the day it goes live, previous data is migrated, and
the system is ready for use. After it goes live, the system is reviewed postimplementation to see how well it worked and how well the project went. It's often
known as a debriefing or lessons learned meeting. It is also where any problems that
were not crucial to the implementation can be addressed and any necessary changes to
the system documented for future versions.
Operations and Maintenance Phase
- Hey, it's not over. Just like a car engine, maintenance and support are necessary.
What happens if the system is based on Microsoft NT 4.0 and 2 years later Microsoft is
no longer supporting NT 4.0? Or, a new e-mail program is put in place and it interferes
with the system? Fixes are necessary and will occur. This is the day-to-day operation of
the software. No one can just walk away once the software is rolled-out and say,
"Whew, glad that's over." It's not over; it's just begun.
- This is where the system has become obsolete. Perhaps a whole new system is coming
in, or this system cannot keep up. Many programs and systems became obsolete with
the Y2K problem or with upgrades of operating systems. Whatever the reason, putting
the system to bed involves more than just shutting off the server. Often, the system
may be kept going due to regulatory issues or because there are still projects using it.
Even if the system will be shut down due to the development of a better system,
disposition needs planning. A disposition plan, archiving of system documentation,
archiving of data, even a plan for getting rid of the old equipment may be a part of the
This is a short description of SDLC and its phases. The important idea to take away from
SDLC is that it involves planning, approval, testing, and documentation to assure that
the system can, and will work as required
System Development Models
1. Waterfall / Linear-Sequential / Classical
2. RAD (Rapid Application Development)
1. Waterfall / Linear-Sequential / Classical
It is sometimes called the classic life cycle or the linear sequential model.
Because of the cascade from one phase to another, this model is known as the
„waterfall model‟ or software life cycle.
Requirements analysis and definition The system‟s services, constraints, and
goals are established by consultation with system users. They are then defined
in detail and serve as a system specification.
System and software design The systems design process allocates the
requirements to either hardware or software systems by establishing an
overall system architecture. Software design involves identifying and
describing the fundamental software system abstractions and their
Implementation and unit testing During this stage, the software design is
realized as a set of programs or program units. Unit testing involves verifying
that each unit meets its specification.
Integration and system testing The individual program units or programs are
integrated and tested as a complete system to ensure that the software
requirements have been met. After testing, the software system is delivered to
Operation and maintenance Normally (although not necessarily), this is the
longest life cycle phase. The system is installed and put into practical use.
Maintenance involves correcting errors which were not discovered in earlier
stages of the life cycle, improving the implementation of system units and
enhancing the system‟s services as new requirements are discovered.
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
Idealised, does not match reality well.
Doesn‟t reflect iterative nature of exploratory development.
Unrealistic to expect accurate requirements so early in project
Software is delivered late in project, delays discovery of serious errors.
Difficult to integrate risk management
Difficult and expensive to make changes to documents, ”swimming upstream”.
Significant administrative overhead, costly for small teams and projects.
2. Incremental Model
Incremental software development, which is a fundamental part of agile
approaches, is better than a waterfall approach for most business, ecommerce, and personal systems.
Incremental development reflects the way that we solve problems. We rarely
work out a complete problem solution in advance but move toward a solution
in a series of steps, backtracking when we realize that we have made a
mistake. By developing the software incrementally, it is cheaper and easier to
make changes in the software as it is being developed.
Each increment or version of the system incorporates some of the functionality
that is needed by the customer. The customer can evaluate the system at a
relatively early stage in the development to see if it delivers what is required.
If not, then only the current increment has to be changed and, possibly, new
functionality defined for later increments.
Incremental development has three important benefits, compared to the waterfall
1. The cost of accommodating changing customer requirements is reduced. The
amount of analysis and documentation that has to be redone is much less than
is required with the waterfall model.
2. It is easier to get customer feedback on the development work that has been
done. Customers can comment on demonstrations of the software and see
how much has been implemented. Customers find it difficult to judge progress
from software design documents.
3. More rapid delivery and deployment of useful software to the customer is
possible, even if all of the functionality has not been included. Customers are
able to use and gain value from the software earlier than is possible with a
Advantages of Incremental model:
Generates working software quickly and early during the software life cycle.
More flexible – less costly to change scope and requirements.
Easier to test and debug during a smaller iteration.
Customer can respond to each built.
Lowers initial delivery cost.
Easier to manage risk because risky pieces are identified and handled during it‟d
Disadvantages of Incremental model:
Needs good planning and design.
Needs a clear and complete definition of the whole system before it can be
broken down and built incrementally.
Total cost is higher than waterfall.
A prototype is an initial version of a software system that is used to demonstrate
concepts, try out design options, and find out more about the problem and its possible
solutions. Rapid, iterative development of the prototype is essential so that costs are
controlled and system stakeholders can experiment with the prototype early in the
A software prototype can be used in a software development process to help anticipate
changes that may be required:
1. In the requirements engineering process, a prototype can help with the elicitation
and validation of system requirements.
2. In the system design process, a prototype can be used to explore particular
software solutions and to support user interface design.
3. The prototype is evaluated by the customer/user and used to refine requirements
for the software to be developed. Iteration occurs as the prototype is tuned to
satisfy the needs of the customer, while at the same time enabling the developer
to better understand what needs to be done.
Advantages of Prototyping Model
1) When prototype is shown to the user, he gets a proper clarity and 'feel' of
the functionality of the software and he can suggest changes and modifications.
2) This type of approach of developing the software is used for non-IT-literate people.
They usually are not good at specifying their requirements, nor can tell properly about
what they expect from the software.
3) When client is not confident about the developer's capabilities, he asks for a small
prototype to be built. Based on this model, he judges capabilities of developer.
4) Sometimes it helps to demonstrate the concept to prospective investors to get
funding for project.
5) It reduces risk of failure, as potential risks can be identified early and mitigation
steps can be taken.
6) Iteration between development team and client provides a very good and conductive
environment during project.
7) Time required to complete the project after getting final the SRS reduces, since the
developer has a better idea about how he should approach the project.
Disadvantages of Prototyping Model:
1) Prototyping is usually done at the cost of the developer. So it should be done using
minimal resources. It can be done using Rapid Application Development (RAD) tools.
Please note sometimes the start-up cost of building the development team, focused on
making prototype, is high.
2) Once we get proper requirements from client after showing prototype model, it may
be of no use. That is why; sometimes we refer to the prototype as "Throw-away"
3) It is a slow process.
4) Too much involvement of client is not always preferred by the developer.
5) Too many changes can disturb the rhythm of the development team.
4. RAD model
Rapid application development (RAD) is an incremental software development
process model that emphasizes an extremely short development cycle
The RAD model is a “high-speed” adaptation of the linear sequential model in
which rapid development is achieved by using component-based construction.
If requirements are well understood and project scope is constrained, the RAD
process enables a development team to create a “fully functional system”
within very short time periods.
RAD approach includes:
1. Business modeling
2. Data modeling
3. Process modeling
4. Application generation
5. Testing and turnover
Flexible and adaptable to changes
Can handle large projects without a doubt
RAD realizes an overall reduction in project risk
RAD realizes an overall reduction in project risk.
Generally Rad incorporates short development cycles.
Requires more resources and money to implement RAD
For large but scalable projects, RAD requires sufficient human resources to create the
right number of RAD teams.
All applications are not compatible with RAD
RAD is not appropriate, technical risks are high
Need both customer and developer commitments to complete a project. Otherwise RAD
5. Spiral Model
The spiral model is an evolutionary software process model that couples the iterative
nature of prototyping with the controlled and systematic aspects of the linear sequential
model. It provides the potential for rapid development of incremental versions of the
software. Using the spiral model, software is developed in a series of incremental
Provides early indication of insurmountable risks, without much cost
Users see the system early because of rapid prototyping tools
Critical high-risk functions are developed first
The design does not have to be perfect
Users can be closely tied to all lifecycle steps
Early and frequent feedback from users
Cumulative costs assessed frequently
Time spent for evaluating risks too large for small or low-risk projects
Time spent planning, resetting objectives, doing risk analysis and prototyping may
The model is complex
Risk assessment expertise is required
Spiral may continue indefinitely
Developers must be reassigned during non-development phase activities
May be hard to define objective, verifiable milestones that indicate readiness to
proceed through the next iteration
When to use Spiral Model
When creation of a prototype is appropriate
When costs and risk evaluation is important
For medium to high-risk projects
Long-term project commitment unwise because of potential changes to economic
Users are unsure of their needs
Requirements are complex
New product line
Significant changes are expected (research and exploration)