Waterfall Model
The Waterfall
Model is the oldest and most well-known SDLC model. The distinctive feature of
the Waterfall model is its sequential step-by-step process from requirements
analysis to maintenance. The major weakness of the Waterfall Model is that
after project requirements are gathered in the first phase, there is no formal
way to make changes to the project as requirements change or more information
becomes available to the project team. Because requirements almost always
change during long development cycles, often the product that is implemented at
the end of the process is obsolete as it goes into production. The Waterfall
Model is a poor choice for software development projects where requirements are
not well-known or understood by the development team.
The sequential phases in Waterfall model are:
Requirement Gathering and analysis: All possible requirements of the system to
be developed are captured in this phase and documented in a requirement specification
doc.
System Design: The
requirement specifications from first phase are studied in this phase and
system design is prepared. System Design helps in specifying hardware and
system requirements and also helps in defining overall system architecture.
Implementation: With inputs from system design, the system is first
developed in small programs called units, which are integrated in the next
phase. Each unit is developed and tested for its functionality which is
referred to as Unit Testing.
Integration and Testing: All the units developed in the implementation phase are
integrated into a system after testing of each unit. Post integration the
entire system is tested for any faults and failures.
Deployment of system: Once the functional and nonfunctional testing is done, the
product is deployed in the customer environment or released into the market.
Maintenance: There
are some issues which come up in the client environment. To fix those issues
patches are released. Also to enhance the product some better versions are
released. Maintenance is done to deliver these changes in the customer
environment.
Agile Model
What
is Agile?
Agile model
believes that every project needs to be handled differently and the existing
methods need to be tailored to best suit the project requirements. In agile the
tasks are divided to time boxes (small time frames) to deliver specific
features for a release.
Iterative
approach is taken and working software build is delivered after each iteration.
Each build is incremental in terms of features; the final build holds all the
features required by the customer.
Twelve Principals
1. Customer
satisfaction by rapid delivery of useful software
2. Welcome
changing requirements, even late in development.
3. Working
software is delivered frequently (weeks rather than months)
4. Working
software is the principal measure of progress
5. Sustainable
development, able to maintain a constant pace
6. Close daily
cooperation between businesspeople and developers.
7. Face-to-face
conversation is the best form of communication (co-location)
8. Projects are
built around motivated individuals, who should be trusted
9. Continuous
attention to technical excellence and good design
10. Simplicity
11.
Self-organizing teams
12. Regular
adaptation to changing circumstances
Agile Methods
1.Agile modelling
2.Agile unified process(AUP)
3.Dynamic systems development method)DSDM)
4.Essential unified process(ESSUP)
5.Extreme programming(XP)
6.Feature driven development(FDD)
7.Open unified process(open Up)
8.Scrum
9.Velocity tracking
Prototype Model
The Software
Prototyping refers to building software application prototypes which display
the functionality of the product under development but may not actually hold
the exact logic of the original software. Software prototyping is becoming very
popular as a software development model, as it enables to understand customer
requirements at an early stage of development. It helps get valuable feedback
from the customer and helps software designers and developers understand about
what exactly is expected from the product under development. Prototype is a
working model of software with some limited functionality. The prototype does
not always hold the exact logic used in the actual software application and is an
extra effort to be considered under effort estimation .Prototyping is used to
allow the users evaluate developer proposals and try them out before
implementation. It also helps understand the requirements which are user
specific and may not have been considered by the developer during product
design.
Spiral Model
This model of
development combines the features of the prototyping model and waterfall model the
spiral model is intended for large, expensive and complicated projects ,aids risk
management at regular stages and iterative
1) Determines
objectives
2) Identify and
resolve risks
3) Development
and test
4) Plan the next
iteration
Top-Down Model
The Top-down
SDLC model was popularized by IBM in the 1970s, and its concepts are used in
other SDLC models such as the Waterfall and Spiral Models In a pure Top-down model, high-level
requirements are documented, and programs are built to meet these requirements.
Then, the next level is designed and built. A good way to picture the Top-down
model is to think of a menu-driven application. The top level menu items would
be designed and coded, and then each sublevel would be added after the top
level was finished. Each menu item represents a subsystem of the total
application.
Bottom-Up Model
In the Bottom-up
SDLC model, the lowest level of functionality is designed and programmed first,
and finally all the pieces are integrated together into the finished application.
This means that, generally, the most complex components are developed and
tested first. The idea is that any project show-stoppers will surface early in
the project. The Bottom-up model also encourages the development and use of
reusable software components that can be used multiple times across many
software development projects. Think of a menu driven system where the
development starts with the lowest level menu items.
Cocomo Model
Constructive
Cost Model, a method for evaluating and/or estimating the cost of software
development. There are three levels in the COCOMO hierarchy:
Basic COCOMO: computes software development effort
and cost as a function of program size expressed in estimated DSIs. There are
three modes within Basic COCOMO:
Organic Mode: Development projects typically are
uncomplicated and involve small experienced teams. The planned software is not
considered innovative and requires a relatively small amount of DSIs (typically
under 50,000).
Semidetached Mode: Development projects typically
are more complicated than in Organic Mode and involve teams of people with mixed
levels of experience. The software requires no more than 300,000 DSIs. The
project has characteristics of both projects for Organic Mode and projects for
Embedded Mode.
Embedded Mode: Development projects must fit
into a rigid set of requirements because the software is to be embedded in a
strongly joined complex of hardware, software, regulations and operating
procedures.
Intermediate COCOMO: an extension of
the Basic model that computes software development effort by adding a set of
"cost drivers," that will determine the effort and duration of the
project, such as assessments of personnel and hardware.
Detailed COCOMO: An extension of the Intermediate
model that adds effort multipliers for each phase of the project to determine
the cost driver’s impact on each step COCOMO was developed by Barry Boehm in
his 1981 book, Software Engineering Economics.
