Steps of Project Analysis:

• 1. Identify project as either objective driven or project driven

• 2. Analyze other project characteristics
Is it data oriented or process oriented project.
general tool or application specific
Is the project safety critical
Nature of the hardware /software environment in which the
system will operate.
• 3. Identify high level risks
Product uncertainty
Process uncertainty
Resource uncertainty
Technical Plan Content List

1. Introduction and summary of constraints

2. Recommended approach-
3. Development needs
4. Implications-project
• The V-Process Model is an improved version of the classic
waterfall model whereby each level of the development life
cycle is verified before moving on to the next level.

• With this model, testing explicitly starts at the especially

beginning, i.e. once the requirements are written.

• Here, by testing we mean verification by means of reviews

and inspections, i.e. static testing.

• This helps in recognizing errors very early in the life cycle

and reducing potential future defects appearing in the code
later in the life cycle.
Advantages

•
 Each phase has specific deliverables.
•
Higher chance of success over the waterfall model due to the
development of test plans early on during the life cycle.
•
Time concern in comparison with the waterfall model is low
or even we can say 50% less.
•
Works well for small projects where requirements are easily
understood.
•
 Utility of the resources is high.
Disadvantages

•
 Very rigid, like the waterfall model.
•
 Little flexibility and adjusting scope is difficult and expensive.
•
 No early prototypes of the software are produced.
•
 Model doesn’t provide a clear path for problems found during
testing phases.
Spiral Model
• The classical models do not deal with the uncertainty with the
software projects.
• A lot risk assessment and analysis form a part of the software
development.
• This was first realized by Barry Boehm, who introduced the
factor of “project risk” into the life cycle model which resulted
in the spiral model in 1986
• The radial dimension represents the cumulative cost and
each path around the spiral indicates the incremented cost.
• The angular dimensions depict the progress made in each
cycle completion.
• Each loop of the spiral, clockwise from the X-axis, through
360 degrees represents one phase.
• Each phase is split into four sectors namely:
• Planning: Determining aims, alternatives and constraints.
• Risk Analysis: Analyzing alternatives and identify and resolution of
risks.
• Development: Product development and testing.
• Assessment: Customer review.
• The essential concept of the Spiral Model is “to minimize risks by the repeated
use of prototypes [emphasis added] and other means.
• Unlike other models, at every stage risk analysis is performed.
• The Spiral Model works by building progressively more complete versions of the
software by starting at the center of the spiral and working outwards.
• With each loop of the spiral, the customer evaluates the work and suggestions
are made for its modification.
• Additionally, with each loop of the spiral, a risk analysis is performed which
results in a ‘go/nogo’ decision. If the risks are determined to be too great then
the project is terminated” [Frankovic 1998].
• Thus, the Spiral Model addresses the problem of requirements engineering
through development of prototypes, and it addresses the need for risk
management by performing risk analysis at each step of the life cycle.
To What Extent is the prototyping to be done?
Disadvantage of Prototyping:

• Lack of project control and standards possible

• Additional expense of building prototype

DSDM
XP
What is XP?
A system of practices that a community of software developers is
evolving to address the problems of quickly delivering quality
software, and then evolving it to meet changing business needs.
XP features

XP is the most suitable for:
 Small and medium size projects
 New technologies
 Projects with unclear requirements
 Risky projects


XP improves skills by cross training


No more than 20 developers in a team


Using of XP in life-critical projects is questionable
Extreme programming practices 1

Incremental planning Requirements are recorded on Story Cards and the Stories to be
included in a release are determined by the time available and
their relative priority. The developers break these Stories into
development ÔTasksÕ.
Small Releases The minimal useful set of functionality that provides business
value is developed first. Releases of the system are frequent and
incrementally add functionality to the first release.
Simple Design Enough design is carried out to meet the current requirements
and no more.
Test first development An automated unit test framework is used to write tests for a new
piece of functionality before that functionality itself is
implemented.
Refactoring All developers are expected to refactor the code continuously as
soon as possible code improvements are found. This keeps the
code simple and maintainable.
Extreme programming practices 2

Pair Programming Developers work in pairs, checking each otherÕs work and
providing the support to always do a good job.
Collective Ownership The pairs of developers work on all areas of the system, so that
no islands of expertise develop and all the developers own all the
code. Anyone can change anything.
Continuous Integration As soon as work on a task is complete it is integrated into the
whole system. After any such integration, all the unit tests in the
system must pass.
Sustainable pace Large amounts of over-time are not considered acceptable as the
net effect is often to reduce code quality and medium term
productivity
On-site Customer A representative of the end-user of the system (the Customer)
should be available full time for the use of the XP team. In an
extreme programming process, the customer is a member of the
development team and is responsible for bringing system
requirements to the team for implementation.
Thank you