Sei sulla pagina 1di 62

Managing Software

Projects
Processes
Project Success Determinants
Product
Methods
Process Management
Pre-project activity
To improve quality through
Formal Process Definition
Acquire best practices existing outside the industry
Process measurement
Measure processes for goal achievement
Feedback and Control
Happens after repeated iterations of processes
Improvement
Repeat and modify to achieve goals
Optimization
Continuous improvement
Process Management
Plan
Time frame
What data is needed
Role / functionality for team member

Do what the plan said
Collect data
Design studies
Train people to collect data
Process Management
Check
Compare project studies to plan
If plan was not carried out then do it.
Look for lessons for future use
Discuss adjustments in approaches
Determine course of action and changes
Act
Implement fixes, adjustments
Inform others of needed changes
Improve communication from process to process
Process Management Cycle
Take appropriate
action
Check Effect of
Implementation
Determine
Goals and
Targets
Determine
Methods of
reaching the
goal
Engage in
education and
training
Imple-
ment Work
ACT
CHECK DO
PLAN
Plan Plan; Do Research, Observe, Analyze; Check Adapt; Act Improve
Selection of Life Cycle
What is SDLC?
Graphical description of the development
activities that will be performed in a sequence
Sequence may or may not be sequential.

Why SDLC?
A map that guides all project stakeholders forward
and help them to understand where we / they are

Process Framework
Life Cycle
Plan
Specify Develop
Post
Project
Design Code Unit Test
System
Test
LOC
Test
Plans
Test
Strategies
Process
Phase
Activity
Deliverables
Waterfall model - characteristics
Requirement specifications
documents
Functional specifications and
overall system specification
Design specifications
Code modules
Test
documentation
REQUIREMENTS
ANALYSIS
SYSTEM
DESIGN
PROGRAM
DESIGN
IMPLEMENTATION
TESTING
(unit & integration test
System testing
acceptance testing)
OPERATION
& MAINTENANCE
Error reports
Strengths of Waterfall Model
Tackles complexity in an orderly way
Easy to understand, to complete required
activities
Easy for PM to plan and staff
Defines Quality control procedures
Milestones are well understood
Easy to track the progress of the project
Provides requirement stability
Weaknesses of Waterfall Model
Inherently linear in nature. Revisions cost
time and money
Does not handle reality of iterations among
phases
Phases are tied to activities rather than
people or how teams work
Each phase completion is a prerequisite for
the successive phase, thereby inhibiting
flexibility

When to use Waterfall Model
Performs well for product cycles with stable product
definitions and well understood technical
methodologies
Can be used in creation and release of a new
version of an existing product, where changes are
well defined and controlled
Porting of an existing product to a new platform
For example, if a company has experience in
building compiler systems, then building another
such software based on the existing designs is best
managed with the waterfall model
V-Shaped Life Cycle Model
Requirement
Analysis
Specifications
Design
Coding
Testing and
Debugging
Implementation
Maintenance
& Support
REQUIREMENTS
ANALYSIS
SYSTEM
DESIGN
PROGRAM
DESIGN
CODING
UNIT & INTE-
GRATION TESTING
SYSTEM
TESTING
OPERATION
& MAINTENANCE
Verify design
Validate requirements


ACCEPTANCE
TESTING
V Model - document produced
RS
Acceptance test
description
SD, FS
System design
test description
DS, Code
Module test
description & code
Test analysis report
Strengths of V-Shaped Model


Model emphasizes planning for verification
and validation
Encourages definition of requirements before
designing the system, and designing of
software before building components
Deliverable at the end of each phase well
defined and test-able.
Completion of each phase is a milestone.
Weaknesses of V-Shaped Model


It is not easy to handle concurrent
events
Does not handle iteration of phases
Model not equipped to handle dynamic
changes in requirements
No risk analysis activities
When to use V-Shaped
Model?
Works best when all requirements are
available
It can be modified to overcome its
weaknesses, to use as iterative phases
Excellent choice for systems that require high
reliability
Works well when the knowledge, technology
and staff proficiency is available
Prototyping
Project Plan
Database
Creation
Rapid
Analysis
Functions
User
Interface
Prototype
Iteration
Design
Derivation
Tuning
Operation
& Maint.
User
Approval
Strengths of Prototyping
End-users can see the system requirements
being gathered
Less room for miscommunication or
misunderstanding
Steady and visible signs of progress seen,
making customers secure
Development cost saved through less re-
work
Weaknesses of
Prototyping
Model may not acceptable among purists
May lead to missing documentation
If prototype objectives not agreed upon, then,
can lead to code hacking
Customers and developers may not know
prototype to product progress
Structured techniques are abandoned
When to use Prototyping
When requirements are not know upfront
For short-lived demonstrations
When algorithms and interfaces are complex
When requirements are changing rapidly
On a new original development
Generally used with analysis and design of
Object oriented development
Incremental model
Feasibility
Requirements
Design
Detail
Design
Code
Integration
Implemen-
tation
Ops. &
Maint.
Increment 3
Increment 2
Increment 1
Detail
Design
Code
Integration
Implemen-
tation
Ops. &
Maint.
Detail
Design
Code
Integration
Implemen-
tation
Ops. &
Maint.
Strengths of Incremental
Model
An operational product is delivered at each
increment
Successive increments provide way to
refined product
Cost and schedule risks may be re-visited
with each increment
Customers can see useful functionality early
Weaknesses of Incremental
Model
Requires good planning and Design

Tendency to push difficult problems to the
future

Definition of complete fully functional system
must be done early in the life cycle
When to use Incremental
Model
On low-medium risk programs
Most requirements are understood but are
expected evolve over a period of time
When it risky to develop the entire system at
once
When deliverables are required are regular
intervals
Spiral Model
Boehm Spiral Model
Strengths of Spiral Model
Risk identified early on the life cycle

Quality, correctness, cost, schedule and
staffing control is improved

Costs can be assessed frequently
Weaknesses of Spiral
Model
If the project is a low-risk, then this is an
expensive model.
Considerable risk assessment expertise
required.
Model is too complicated to put to use
Industry has not had much experience with
this model
When to use Spiral
Model?
When requirements are complex
For projects that represent medium to high
risk
For large projects
When a new technology is employed
With computation intensive systems (DSS)

Open Source Methodologies
Use an OSI certified license
Document every decision / action
Use simple and available tools
Reward merit with increased responsibility
Work transparently
Encourage contribution
Agile Methods
Agile methods:
Scrum
Extreme Programming
Adaptive Software Development (ASD)
Dynamic System Development Method (DSDM)

Agile Alliance (www.agilealliance.org)
A non-profit organization promotes agile
development

Agile Manifesto
History
Evolved in the mid 1990s as part of a
reaction against "heavyweight" methods
Methodologies similar to Agile: Crystal clear,
XP, DSDM, Feature Driven Development
2001 The Agile Alliance at the Snowbird Ski
resort, Utah
http://agilemanifesto.org/principles.html
Current Trend
iterative and incremental

project is divided into small parts

backlog is prioritized to be completed.

clear definition of roles and work

Scrum
Characteristics
Self-organizing teams
Product progresses in a series of month-long
sprints
No specific engineering practices prescribed
Uses generative rules to create an agile
environment for delivering projects
One of the agile processes

Scrum
Characteristics
Each iteration of a scrum is known as Sprint
Product backlog is a list where all details are
entered to get end product
During each Sprint, top items of Product
backlog are selected and turned into Sprint
backlog
Team works on the defined sprint backlog
Team checks for the daily work
At the end of sprint, team delivers product
functionality


How Scrum Works?
Scrum Principles

Time-boxes
Cross-functional teams
Open communications
Within team
With stakeholders
Priorities set by Product Owner
Demonstrable results
Responsive to change
Scrum Terms
Team
ScrumMaster
Scrum Team
Product Owner
Users & Stakeholders
Sprint
Backlog
Product
Sprint

Meetings
Daily scrum
Planning
Review
Retrospective

Burndown
Chart
Velocity
http://www.youtube.com/watch?v=XU0llRltyFM
MDE: Model Driven Engineering
Set of Engineering Tools and technology for Agile
Methodology
XP
Extreme Programming

Choosing THE Lifecycle
The level of formality and complexity of the
lifecycle for each project is constrained by
any number of factors, including budgetary
constraints, experience and size and
complexity of the project and development
team.

Choosing THE Lifecycle
Varies by project
What are the business goals of the Organization?
Opt for iterative or incremental
How well are requirements understood?
What is the size of the Project?
What are the risks?
Is there a fixed deadline?
How experienced is the team or customer?
Choosing THE lifecycle
ask questions.
How stable are the requirements?
Who are the end-users of the system?
Is the timeline aggressive/ conservative?
What is the size of the project?
Where are the Project Teams located?
What the critical resources?

http://www.softdevteam.com/Software/SLSelector.asp
How to decide?
High risks or high cost of failure? A spiral process may be your best
choice.
New kind of system? Probably not test-driven development, unless
you are focused on prototyping; you'll need to do requirements work.
Very large project? Probably spiral.
Medium-sized project? A sashimi process may work well for you.
Want to keep stakeholders involved? An Agile / incremental process
may be what you need.
All the developers are experts? If the project is small enough, an
agile approach may work for you.
Don't have an on-site stakeholder to sit with the developers? Agile
development is not for you.
Developers are not highly skilled? A waterfall or spiral process can
help keep them on track and out of trouble.

Select a Model
A corporation is rewriting its Accounts Payable
system to move it from an old batch-type mainframe
to Web-enables system. No new functionality will be
added.
The statement of work calls for a conversion as is.
Only the input and output subsystems will be
altered. Because it is a financial application, testing
and verification will be emphasized within the
development activity. The schedule allows five
months for the project, with two people working on it.
What is the most appropriate model applicable and
what is the advantage ?
A corporation has recently completed a three-year
process to develop a global configuration
management system. It is now ready to move into
the next phase, where new releases will be issued
approximately every three months. An average of 12
new features and an appropriate number of bug
fixes will be included in each release spread across
teams located geographically apart. Development
time for new features can range from one to five
months. Some features can require multiple
releases for full implementation What do you think is
the most suited life cycle approach for this project?
What is the advantage of the approach?
Select a Model
A company has created a new small business
division to develop a specialized wireless
protocol operating system. Approx. 12 persons
will be transferred from key areas of the
company to form the base for the venture.
Additionally, 23 people will be recruited who are
all engineers. Object oriented tools and Java
have been decided as approaches and
language. Training is scheduled for the new
platform. The Primary wireless supplier is having
major financial difficulties and has laid of 35% of
its workforce.
Select a Model
Last word
No major software project that has been successful
in a general marketplace (as opposed to niches)
has ever gone through those nice lifecycles they
tell you about in Project Mgmt classes.

- Linus Trovalds
Global Delivery Model-
defined

Global Delivery Model involves the
deployment of resources from
different parts of the world to provide
maximally efficient service delivery.

Global Delivery Model involves having
the right volume of skills and the
right skills mix in the right place at
the right time and the right price
point.

Global Delivery Model gives the
advantage of delivery centers located
around the globe as well as a team
working close to the business using
consistent processes.

Most businesses have now come to
expect Global Delivery to be an
integral component of the solution
offered by the service provider.
Global Delivery Model
Onsite
Offshore
Analysis High Level
Design
Development
Coordination
Deployment
Integrated
Testing
Client
Acceptance
Testing Development Detailed
Architecture
Planning


Global Software
Delivery Model
Evolution of the Global
Delivery Model
Simplification Standardization
Shared
Services
Outsourcing
Offshore
<--------------Act Local-----------> <-------------Act Regional-------->
Maximum
L
e
v
e
l

o
f

B
e
n
e
f
i
t

Minimum
GLOBAL






REGIONAL






LOCAL
What
improvements
can be made by
implementing
local
best practice?
Can benefits of
standardization
across
businesses and
geography be
achieved?
Can shared
service
economies
of scale be
captured?
Is outsourcing
feasible,
beneficial and
outweighs
additional
risk?
Source from
offshore
location-
(captive or
vendor)
Global
Delivery
Source from
multiple
locations/vendor
s across the
globe
<-------------Act Global-------->
Onsite Team - Tasks
Understand Client requirements
Mediator between client and ODC
Initial steps planned and designed
Task allocation to available resources
Testing, Executing, support for maintenance

ODC - Tasks
Detailed design continuation of onsite team
Technological requirements
Development
Testing before handing over to onsite team
Continuous technical support.
Yet another way to look at..
Other Models
Onsite Deployment

Hosted Services

SaaS (IaaS, PaaS)
Business Drivers (Customers)
Cost
Hosted vs. Onsite solutions
Differentiation
Core business processes vs. commodity processes
Time-to-Market
Ready-made vs. custom built
Resource availability
Related to cost
Process affinity
Some processes more suited to any one of the
deployment solutions

Potrebbero piacerti anche