Classification of Software Projects On the Basis Of Its Features and Then Suggesting Appropriate Life Cycle Model Based on the Features Department of Electronics and Computer Engineering Indian Institute of Technology Roorkee Under Guidance of:Dr. Sandeep Kumar Garg Vikas Yadav 10114046 Pawan Kumar 10114031 Chirag Kothari 10114014 Ashutosh Singh 10114010 Udit Panesar 10114044 2012
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Classification of Software Projects On the Basis
Of Its Features and Then Suggesting Appropriate
Life Cycle Model Based on the Features
Department of Electronics and Computer Engineering
Indian Institute of Technology Roorkee
Under Guidance of:Dr. Sandeep Kumar Garg
Vikas Yadav
10114046
Pawan
Kumar
10114031
Chirag
Kothari
10114014
Ashutosh
Singh
10114010
Udit Panesar
10114044
2012
Ashu
Stamp
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
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
Coding – transform algorithms into software
PROTOTYPING MODEL
Journey of the prototyping :-
THROWAWAY PROTOTYPING MODEL
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:
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.
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.
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