1. 2012
Classification of Software Projects On the Basis
Of Its Features and Then Suggesting Appropriate
Life Cycle Model Based on the Features
Ashutosh
Singh Department of Electronics and Computer Engineering
10114010
Indian Institute of Technology Roorkee
Chirag Pawan
Under Guidance of:Dr. Sandeep Kumar Garg
Kothari Kumar
10114014 10114031
Ashutosh
Udit Panesar Vikas Yadav
10114044 10114046

2. Introduction
Software engineering is the application of a systematic, disciplined, quantifiable approach to
the design, development, operation, and maintenance of software, and the study of these
approaches, that is, the application of engineering to software. There was no software
engineering some years back.Softwares were being developed, coded and implemented
through mere intuition and trial and error approach. Gradually Software Engineering has
evolved from an art and taken the form of an engineering methodology .There are different
approaches to develop software s by following different paradigms and processes . Work is
divided at coded implemented ,designed and delivered finally.Many different methods have
come up for the development of softwares depending upon the problem size , cost and
complexity, also called Life Cycle Models. They provide a fixed generic framework that can
be tailored to a specific project. Each model has its advantages as well as disadvantages. To
identify which model is appropriate for the given project, we classify the project on the basis
of its features. Feature is an intentional distinguishing characteristic of a software item. Then
depending upon the features we decide which model is appropriate for the given project. The
features are decided not only by the project which means what to do, it also depends upon the
company or the workforce doing the project and also on user side needs and requirements
like complete delivery at the end or delivery in stages.
Software project classification:
Based on the different features of the project or the software being developed ,software projects
can be classified into many classes. To develop quality softwares successfully and systematically,
different methodology is followed for different types of projects depending upon their different
features. The different identifiable characteristics of the projects are as listed below:-
1. Risk
2. Approximated time
3. Size and Cost
4. Experience of members
5. Stability
6. Complexity
7. Maintenance Requirements
8. Reusability
9. User involvement
10. Requirement specification
11. Changes incorporated
12. Resources prediction
13. Documentations
14. Organization structure

3. Now, there are many Life Cycle Models. Here we have thrown light over some of the
prominent models used in the industry
V DEVELOPMENT MODEL
Overview
The V model is a basic Software Development Model, which is sometimes also referred as an
extension of the classical waterfall model.The mai difference being that instead of moving in
a linear way the steps are bent upwards after the coding phase to form a V shape , as shown
in the diagram at the bottom. In the V model there is a link between the phases present in the
two arms of the V .But this doesn’t mean that it is not a sequential process. It is a sequential
path of execution of processes. Each phase must be completed before the next starts. The
horizontal axis represents time of the completion of the project and the vertical axis
represents the level of abstraction, coarsest grain abstraction being the uppermost.
Testing is emphasized in this model more so than the waterfall model though. The testing
procedures are developed early in the life cycle before any coding is done, during each of the
phases preceding implementation. Requirements mark the beginning of the life cycle model
just like the waterfall model. A test plan is made before starting the project. The test plan
focuses on meeting the functionality specified in the requirements gathering. The high-level
design phase focuses on system architecture and design.In the low-level design phase, the
actual software components are designed, and unit tests are created.Coding takes place in the
implementation phase. As the coding gets completed the path of execution changes direction
and now starts moving up the V where the test plans which were made earlier are put into
use. A Generalized diagram of the model is shown below:
 Project Planning and Requirements– allocate resources
 Product Requirements and Specification Analysis – complete specification of the
software system
 Architecture or High-Level Design– defines how software functions fulfill the design
 Detailed Design – develop algorithms for each architectural component
 Production, operation and maintenance – provide for enhancement and corrections
 System and acceptance testing –check the entire software system in its environment
 Integration and Testing – check that modules interconnect correctly
 Unit testing – check that each module acts as expected

4.  Coding – transform algorithms into software
PROTOTYPING MODEL
Journey of the prototyping :-
THROWAWAY PROTOTYPING MODEL

5. With 'throw-away' prototyping prototype for a small portion of the system is developed and then
given to the end user to test and evaluate. The user provides feedback which can quickly be followed
and incorporated into the development of the system. The prototype is then thrown away or discarded.
This is very different to the evolutionary approach.
There are many situations in which user’s end requirements are not clearly specified. This model
fulfils the objective of validating the requirements are validated and clearly understood. The approach
is to construct a quick and dirty partial implementation of the system during or before the
requirements phase.
Main benefits :Used in making projects that have low risk in such areas as losing budget, schedule
predictability and control, large-system integration problems, or coping with information sclerosis,
but high risk in user interface design.
Main risks:Use in projects that have low risk in such areas as losing budget, schedule predictability
and control, large-system integration problems, or coping with information sclerosis, but high risk in
user interface design.
Advantages:
1. This model significantly reduces the project risks.
2.The projects formed through this model have a short life span.
Disadvantages:
1.The prototype basically does nothing. It is just presentational.
2.This model can be employed only for limited purposes.
EVOLUTIONARY PROTOTYPING MODEL
The idea behind this is that an initial prototype is presented to the user. They provide feedback and
suggestions for improvements. These are acted upon by the developer who then presents a more
refined prototype. The user once more provides feedback. The process is repeated.
So at each stage the prototype 'evolves' towards the final system.
Hence the term 'evolutionary prototyping'.
Advantages:
1.This model helps to speed up the delivery of the system .
2.This model also allows a lot of user interaction.
3. The system meets up to the user requirements.
Disadvantages:

6. 1. A problem with evolutionary prototyping is knowing when it is necessary to stop tweaking the
system and actually finish the development.
2. Long term maintenance can be expensive.
Use in projects that have low risk in such areas as losing budget, schedule predictability and control,
large-system integration problems, or coping with information sclerosis, but high risk in user interface
design.
EXTREME PROGRAMMING
Extreme programming is very far from difficult ,large or complex projects .Extreme
Programming, also called XP, is a lightweight method of software development based on
principles of communication ,simplicity, courage and feedback . XP is designed for small
teams who need to build the software quickly in an environment of rapidly-changing
re-quirements . It works by bringing the whole team together in the presence of simple
practices, with required feedback to enable the team to see where they stand and to modify
the practices according to their unique situation.
Extreme Programming can be summed up into twelve practises:
The Planning Process
The XP planning process allows the XP customer to set and define the business value
of desired features, and uses cost estimates provided by the coders to choose what needs to be
done and what not. The effect of XP’s planning process is that it is easy to propell the project
to success.
Small Releases
XP teams put a simple system into production early, and update it frequently
through a very short cycle.This is repeated for many iterations.
Metaphor
XP teams use a common “system of names” and a common system description
that guides development and communication.
Simple Design
A program built with XP should be the simplest program and it should meet the current
requirements.There is not much building for the future”. Instead, the focus is
on providing business value. Of course it is necessary to ensure that you have a
good design, and in XP this is brought about through “refactoring”, discussed
below.

7. Testing
XP teams focus on validation of the software at all times. Programmers de-
velop software by writing tests first, then software that fulfills the requirements
reflected in the tests. Customers provide acceptance tests that enable them to
be certain that the features they need are provided.
Refactoring
XP teams improve the design of the system throughout the entire development.
This is done by keeping the software clean: without duplication, with high
communication, simple, yet complete.
Pair Programming
XP programmers write all production code in pairs, two programmers working
together at one machine. Pair programming has been shown by many exper-
iments to produce better software at similar or lower cost than programmers
working alone.
Collective Ownership
All the code belongs to all the programmers. This lets the team go at full speed,
because when something needs changing, it can be changed without delay.
Continuous Integration
XP teams integrate and build the software system many times per day. This
keeps all the programmers on the same page, and makes very rapid progress possible.
Perhaps surprisingly, integrating more frequently tends to eliminate integration
problems that persists with teams who integrate less often.
40-hour Week
Tired programmers make more mistakes. XP teams do not work excessive
overtime, keeping themselves fresh, healthy, and effective.
On-site Customer
An XP project is steered by a dedicated individual who is empowered to de-
termine requirements, set priorities, and answer questions as the programmers
have them. The effect of being there is that communication improves, with less
hard-copy documentation - often one of the most expensive parts of a software
project.
Coding Standard
For a team to work effectively in pairs, and to share ownership of all the code,
all the programmers need to write the code in the same way, with rules that
make sure the code communicates clearly.

8. Synchronize and Stabilize lifecycle
Model:-
This lifecycle model defines an overall approach for managing & developing large-scale
software systems.
Sync-and-stabilize is a Systems Development Life Cycle methodology in which teams work
concurrently on individual application modules. They frequently synchronize their code with
that of other teams, and debug or “stabilize” their code regularly throughout the development
process. Synch-and-stabilize is Microsoft's attempt to scale-up a loosely structured small-
team ("hacker") style of product development.
 Many small teams (3 - 8 developers per team) work in parallel.
 Components will work together if changes are synchronized frequently.
o Complete recompilation is done at the end of the day so that developers can
check their work.
o A defect that breaks the build must be fixed immediately
 Features are evolved incrementally with occasional innovations.
o Start with a "vision statement".
o Select features and establish priority of features with user input.
o Continued testing is done during development.
 The product is stabilized at 3 or 4 milestone junctures in the project life.
o It is done thorough internal and external testing.
o Fixes almost all errors detected.
o "Zero-bug" release is aimed at the last milestone.
The special feature of this model is that the specification is complete only when the product is
ready. This model has been used extensively by many innovative companies. Some of the
example projects using this software development model are some small scale projects i.e.
first version of DOS, Lotus1-2-3, WordPerfect, Word or Excel. This process is also known as
"milestone", "daily build", "nightly build", and "zero-defect" process. The overall strategy of
this model is to quickly introduce products that are "good enough" to capture a mass market,
and then further improve the product, selling multiple product versions and upgrades.
Advantages of Synchronize-and-stabilize model:-
- The periodic system building approach makes way for testing the software for its
functionality and performance.
- Project monitoring will be easy as there will be intermediate milestones.
- The integration problems encountered in large projects using other models are eliminated
using this model.

9. - Because of intermediate releases, the product can be made rich in feature by incorporating
the necessary feedback methodology.
Disadvantages of Synchronize-and-stabilize model:-
- A parallel independent testing team needs to work independently.
- The detailed specifications document will be made available only at time of release.
- Periodic system builds require a rigorous process to be defined for integration of various
modules.
Overview of Synch-and-Stabilize Development Approach
Planning Phase:-
Vision Statement:- Product and program management use extensive customer input
to identify and prioritize product features.
Specification Document:- Based on vision statement, program management and
development group define feature functionality, architectural issues, and component
interdependencies.
Schedule and Feature Team Formation:- Based on specification document,
program management coordinates schedule and arranges feature teams that each
contain approximately 1 program manager, 3-8 developers, and 3-8 testers (who work
in parallel 1:1 with developers).
Development Phase:- Feature Development in 3-4 sequential subprojects that results in a
milestone release. Program managers coordinate evolution of specification. Developers
design, code, and debug. Testers pair up with developers for continuous testing.
Subproject I First 1/3 of features: Most critical features
And shared components.
Subproject II Second 1/3 of features.
Subproject III Final 1/3 of features: Least critical
Features.
Stabilization Phase: - Comprehensive external and internal testing and final product
stabilization. Program managers coordinate OEMs (Original Equipment Manufacturer) and
ISVs and monitor Customer feedback. Developers perform final debugging and Code
stabilization. Testers recreate and isolate errors.
Internal Testing: - Thorough testing of complete product within the company.
External Testing:- Thorough testing of complete product outside the company by
"beta" sites such as OEMs, ISVs, and end-users.

10. Release preparation: - Prepare final release of "golden master" diskettes and
documentation for manufacturing.
Synch-and-Stabilize Development Phase Breakdown:-
Time: Usually 2-4 months per Milestone
MILESTONE 1 (frst1/3 features):-
Development (Design, Coding, Prototyping)
Usability-Lab
Daily Builds
Private Release Testing
Feature Debugging:
Feature Integration
Code Stabilization (no severe bugs):
Buffer time: (20-50%)
MILESTONE2 (next 1/3)-
Development-
Usability Lab
Daily Builds
Private Release Testing
Feature Debugging
Feature Integration
Code Stabilization
Buffer time
MILESTONE3 (Last Set)-
Development,
Usability
Daily Builds
Private Release Testing
Feature Debugging
Feature Integration
Feature Complete
Code Complete
Code Stabilization
Buffer Time
Zero Bug Release
Release to Manufacturing

11. FOUNTAIN MODEL
The model is created by Henderson-Sellers and Edwards. The Fountain model is a logical
improvement of the Waterfall model. The steps are still there, in the same sequence, however
at any step there can be a fallback to an earlier step. Moving through a number of steps and
falling back one or more steps, performed repeatedly, is far more flexible than the Waterfall
model.
The process will have following phases:
- Requirements Phase
- Object Oriented Analysis Phase
- Object Oriented Design Phase
- Implementation Phase
- Implementation and Integration Phase
- Maintenance
Advantages of Fountain model:-
- Do not have to freeze the requirements too soon.
- Interaction B/W Design and requirement is more.
- Able to start the coding earlier.

12. (Stages in Fountain Model)
Analysis:
Its basic strengths are that it supports iteration within phases, allows parallelism between
phases, and it is an incremental development. And its weakness is that it may be degraded
into code-a-bit test-a-bit which requires frequent iterations and refinements.
I think that the Fountain Model is a better model to use in the industry. Though it would be a
bit inappropriate for small projects. It has the flexibility to fall back on any phase if some
problems arise in between any of the previous phases. Also practically the requirements keep
on changing quite frequently. Even if there is an error in the understanding of the client
requirements, those can be easily rectified without much loss of project time for not very
huge systems. Also a combination of a fountain and a spiral model would be more effective
as the Spiral model could be used at the beginning in the requirements definition phase to
minimize the risks involved in the project. This will also lead to a reuse of the components
developed in the earlier phases.
SPIRAL MODEL

13. The spiral Model includes the iterative nature of the prototyping model and the linear nature
of the waterfall model. This approach is ideal for developing software that is revealed in
various versions.
In each iteration of the spiral approach, software development process follows the phase-wise
linear approach. At the end of first iteration, the customer evaluates the software and provides
the feedback. Based on the feedback, software development process enters into the next
iteration and subsequently follows the linear approach to implement the feedback suggested
by the customer. The process of iteration continues throughout the life of the software.
Spiral Approach Phases
1. Customer Communication: Includes understanding the system requirements by
continuous communication between the customer and the system analyst.
2. Planning: Includes estimating Schedule, cost, and resource for the iteration.
3. Risk Analysis: includes identifying, estimating, and monitoring technical and
management risks, such as schedule slippage and cost overrun.
4. Engineering: Includes requirement gathering and design of the software system.
5. Construction and release: Includes coding, testing and deploying software at the customer
site and providing user-support documents.
6. Customer Evaluation: Includes evaluation of software by the customer and implementing
feedback in the next iteration of the software development.
Product:

14. An example of the spiral model is the evolution of Microsoft Windows Operating system
from Windows 3.1 to windows 2003. We may refer to Microsoft windows 3.1 Operating
System as the first iteration in the spiral approach. The product was released and evaluated by
the customers, which include the market large. After getting the feedback from customers
about the windows 3.1, Microsoft planned to develop a new version of windows operating
system. Windows’95 was released with the enhancement and graphical flexibility. Similarly,
other versions of windows operating system were released.
Application:
The spiral model is mostly used in large projects. For smaller projects, the concept of agile
software development is becoming a viable alternative. The spiral model suit small (up to $3
million) software applications and not a complicated ($3 billion) distributed, interoperable,
system of systems.
Also it is 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. For
example, the Spiral Architecture Driven Development is the spiral based Software
Development Life Cycle (SDLC) which shows one possible way how to reduce the risk of
non-effective architecture with the help of a spiral model in conjunction with the best
practices from other models.
Advantages
1. Realism: the model accurately reflects the iterative nature of software development on
projects with unclear requirement.
2. Flexible: incoporates the advantages of the waterfall and rapid prototyping methods
3. Comprehensive model decreases risk
4. Good project visibility.
Disadvantages
1. Needs technical expertise in risk analysis to really work
2. Model is poorly understood by nontechnical management, hence not so widely used
3. Complicated model, needs competent professional management. High administrative
overhead.

15. RAPID APPLICATION DEVELOPMENT
Rapid application development is a software development methodology that involves
methods like iterative development and software prototyping. According to Whitten
(2004), it is a merger of various structured techniques, especially data-driven Information
Engineering, with prototyping techniques to accelerate software systems development.[1]
In rapid application development, structured techniques and prototyping are especially used
to define users' requirements and to design the final system. The development process starts
with the development of preliminary data models and business process models using
structured techniques. In the next stage, requirements are verified using prototyping,
eventually to refine the data and process models. These stages are repeated iteratively; further
development results in "a combined business requirements and technical design statement to
be used for constructing new systems"
RAD approaches may entail compromises in functionality and performance in exchange for
enabling faster development and facilitating application maintenance.
Four phases of RAD

16. 1. Requirements Planning phase – combines elements of the system planning and
systems analysis phases of the System Development Life Cycle (SDLC). Users,
managers, and IT staff members discuss and agree on business needs, project scope,
constraints, and system requirements. It ends when the team agrees on the key issues
and obtains management authorization to continue.
2. User design phase – during this phase, users interact with systems analysts and
develop models and prototypes that represent all system processes, inputs, and
outputs. The RAD groups or subgroups typically use a combination of Joint
Application Development (JAD) techniques and CASE tools to translate user needs
into working models. User Design is a continuous interactive process that allows
users to understand, modify, and eventually approve a working model of the system
that meets their needs.
3. Construction phase – focuses on program and application development task similar
to the SDLC. In RAD, however, users continue to participate and can still suggest
changes or improvements as actual screens or reports are developed. Its tasks are
programming and application development, coding, unit-integration and system
testing.
4. Cutover phase – resembles the final tasks in the SDLC implementation phase,
including data conversion, testing, changeover to the new system, and user training.
Compared with traditional methods, the entire process is compressed. As a result, the
new system is built, delivered, and placed in operation much sooner. Its tasks are data
conversion, full-scale testing, system changeover, user training
AGILE MODEL
Agile is a significant departure from the heavyweight document-driven software development
methodologies such as Waterfall model. Agile methodologies embrace iterations. Small
teams work together with stakeholders to define quick prototypes, proof of concepts, or other
visual means to describe the problem to be solved.
The team defines the requirements for the iteration, develops the code, and defines and runs
integrated test scripts, and the users verify the results. One specialty of this model is that
verification occurs much earlier in the development process than it would with waterfall,
allowing stakeholders to fine-tune requirements while they’re still relatively easy to change.

17. image taken from: cs.utexas.edu/users/downing/papers/Agile2007.pdf
Types of agile software development methodologies :
 XP (Xtreme Programming)
 Scrum Methodology
EXTREME PROGRAMMING
Extreme programming is very far from difficult ,large or complex projects .Extreme
Programming, also called XP, is a lightweight method of software development based on
principles of communication ,simplicity, courage and feedback . XP is designed for small
teams who need to build the software quickly in an environment of rapidly-changing
re-quirements . It works by bringing the whole team together in the presence of simple
practices, with required feedback to enable the team to see where they stand and to modify
the practices according to their unique situation.
Extreme Programming can be summed up into twelve practises:
The Planning Process
The XP planning process allows the XP customer to set and define the business value
of desired features, and uses cost estimates provided by the coders to choose what needs to be
done and what not. The effect of XP’s planning process is that it is easy to propell the project
to success.

18. Small Releases
XP teams put a simple system into production early, and update it frequently
through a very short cycle.This is repeated for many iterations.
Metaphor
XP teams use a common “system of names” and a common system description
that guides development and communication.
Simple Design
A program built with XP should be the simplest program and it should meet the current
requirements.There is not much building for the future”. Instead, the focus is
on providing business value. Of course it is necessary to ensure that you have a
good design, and in XP this is brought about through “refactoring”, discussed
below.
Testing
XP teams focus on validation of the software at all times. Programmers de-
velop software by writing tests first, then software that fulfills the requirements
reflected in the tests. Customers provide acceptance tests that enable them to
be certain that the features they need are provided.
Refactoring
XP teams improve the design of the system throughout the entire development.
This is done by keeping the software clean: without duplication, with high
communication, simple, yet complete.
Pair Programming
XP programmers write all production code in pairs, two programmers working
together at one machine. Pair programming has been shown by many exper-
iments to produce better software at similar or lower cost than programmers
working alone.
Collective Ownership
All the code belongs to all the programmers. This lets the team go at full speed,
because when something needs changing, it can be changed without delay.
Continuous Integration
XP teams integrate and build the software system many times per day. This
keeps all the programmers on the same page, and makes very rapid progress possible.
Perhaps surprisingly, integrating more frequently tends to eliminate integration
problems that persists with teams who integrate less often.
40-hour Week

19. Tired programmers make more mistakes. XP teams do not work excessive
overtime, keeping themselves fresh, healthy, and effective.
On-site Customer
An XP project is steered by a dedicated individual who is empowered to de-
termine requirements, set priorities, and answer questions as the programmers
have them. The effect of being there is that communication improves, with less
hard-copy documentation - often one of the most expensive parts of a software
project.
Coding Standard
For a team to work effectively in pairs, and to share ownership of all the code,
all the programmers need to write the code in the same way, with rules that
make sure the code communicates clearly.
SCRUM METHODOLOGY
‘Scrum’ (related to “scrimmage”) is the term for a huddled mass of players engaged with
each other to get a job done in rugby. In software development, the job is to put out a release.
Scrum for software development came out of the rapid prototyping community because users
wanted a methodology that would support an environment in which the requirements were
not only incomplete at the start, but also could change rapidly during development.
At the center of each Scrum project, there is a backlog of work to be done. This backlog is
populated during theplanning phase of a release and defines the scope of the release. After the
team completes the project scope and high-level designs, it divides the development process
into a series of short iterations called sprints.
These sprints aim to implement a fixed number of backlog items. Before each sprint, the team
members identify the backlog items for the sprint. The team reviews the sprint to articulate
lessons learned and check progress at the end of sprint.
The Scrum development process concentrates on managing sprints. Before each sprint
begins, the team plans the sprint, identifying the backlog items and assigning teams to these
items. Teams develop, wrap, review, and adjust each of the backlog items. Below is picture
describing the Scrum method:

20. PROJECT ENVIRONMENT IMPACT ON LIFE
CYCLE MODEL:-
Design and adaptation of the life cycle model for each project category or subcategory must
reflect the important characteristics of the project environment. So life cycle models are
categorized on the basis of Project types as following:
Project Categories Life Cycle Models
1. Aerospace/Defense Projects Defense Acquisition Model.
1.1 Defense systems Process Based Mission Assurance (PMBA)
1.2 Space Program Life Cycle model.
1.3 Military operations
2. Business & Organization Change Generic Waterfall, Parallel-Work,
Projects Evolutionary Models.
2.1 Acquisition/Merger Standard Waterfall, Cyclical, Spiral Models.
2.2 Management process improvement
2.3 New business venture
2.4 Organization re-structuring
2.5 Legal proceeding
3. Communication Systems Projects -do-
3.1 Network communications systems

21. 3.2 Switching communications
systems
4. Event Projects -do-
4.1 International events
4.2 National events
5. Facilities Projects -do-
5.1 Facility decommissioning
5.2 Facility demolition
5.3 Facility maintenance and
modification
5.4 Facility
design/procurement/construction
6. Information Systems (Software) Predictive (Waterfall, Prototyping, RAD,
Projects Incremental Build, Spiral) and Adaptive
(ASD, XP, SCRUM) Models.
Code and Fix, Incremental, Iterative Model.
Formula-IT Development Model.
Refined Process Spiral Model.
7. International Development Projects Waterfall, Spiral Models.
7.1 Agriculture/rural development
7.2 Education
7.3 Health
7.4 Nutrition
7.5 Population
7.6 Small-scale enterprise
8. Media & Entertainment Projects -do-
8.1 Motion picture
8.2 TV segment
8.2 Live play or music event
9. Product and Service Development Stage/Gate Product Development Model.
Projects Phase-Gate Process Model.
9.1 Information technology hardware Pharmaceutical Model.
9.2 Industrial product/process
9.3 Consumer product/process
9.4 Pharmaceutical product/process
9.5 Service (financial, other)
10. Research and Development Projects Technical Acquisition: Basic Model, Phased
10.1 Environmental Model, Multi-Solution Model.
10.2 Industrial
10.3 Economic development
10.4 Medical
10.5 Scientific