SOFTWARE PROJECT

MANAGEMENT(SPM)
OVERVIEW

1
 Project

• Software project is an endeavor undertaken

with a purpose
• A project has the following attributes:
o A project has a unique purpose
o A project is temporary
o A project is developed in increments
o A project requires resources
o A project involves uncertainty
2
 Project Constraints
• A project has triple constraints:
o Scope – what work will be done?
o Time- how long will it take to complete?
o Cost-how much will it cost to complete?
• Managing the triple constraint involves
making trade-offs between them

3
 Project Management
• Project management is the application of
knowledge, skills, tools and techniques to
project activities to meet requirements.
• A project management framework includes:
o Stakeholders- people involved
o Project management knowledge areas,
o Project management tools and techniques-
assist in carrying out the work
4
 Project Management
• The knowledge area has 3 parts with 9
knowledge:
o Core functions:
- Scope, time, cost and quality
o Supporting functions:
- Human resource, communication, risk and
procurement management
o Integration management
5
 Knowledge Areas
• Scope Management involves defining and
managing all the work required to complete
the project successfully
• Time Management involves estimating how
long it will take to complete the work,
developing an acceptable project schedule,
and estimating timely completion of the
project

6
 Knowledge Areas
• Cost Management consists of estimating and
managing the budget for the project
• Quality Management ensures that the project
will satisfy the stated needs for which it was
undertaken
• Human resource management is concerned
with making effective use of the people
involved with the project

7
 Knowledge Areas
• Communication Management involves generating,
collecting disseminating, and storing information
• Risk Management includes identifying, analyzing,
and responding to risks
• Procurement Management involves acquiring or
procuring goods and services for a project
• Project Integration Management involves
coordinating all of the other project management
knowledge areas through out a project’s life cycle
8
 Project Management Fundamentals

• SPM ensures the delivery of quality system on

time within budget
• SPM fundamentals consist of:
- Determining the size of the product
- Allocating resources appropriate for a product
of that size
- Creating a plan for applying the resources, and
- Monitoring and directing the resources.
9
 Processes (contd)
• The processes are not isolated events
• The level of activity and length of each process
varies for every project:
o Normally, execution takes more resources and
time followed by planning
o Controlling is done throughout the project and
take less resource and time
o Initiating and closing take the least amount of
resources and time
10
 Fundamentals-focus
• SPM’s basic focuses – 4 Ps
i) People
It is not only critically important to select good team members,
but also manage the team effectively.
ii) Product
• Software product is defined and described in terms of
context, objective, functions and performance.
• The product requirements must be communicated from
customer to developer, partitioned (decomposed) into their
constituent parts, and positioned for work by the software
team.

11
 Fundamentals-focus
iii) Process
• Software process is a framework for the tasks that are required to build high-quality
software.
• The framework includes:
o Framework activities with
Task sets which in turn includes
- Tasks
- Milestones, Work products
o Umbrella activities include:
- SQA, SCM, RM, SQA
• The umbrella activities are independent of the framework activities and occur
throughout the process
• The software process is applicable to all software projects regardless of size and
complexity.

12
 Process Maturity
• In recent years, there has been a significant emphasis on
“process maturity.”
• To determine an organization’s current state of process
maturity, the Software Engineering Institute (SEI) uses an
assessment that results in a five point grading scheme.
• The grading scheme determines compliance with a
capability maturity model (CMM) that defines key
activities required at different levels of process maturity.
• The five process maturity levels are defined in the
following manner:

13
 Process Maturity
• Level 1: Initial.
o The software process is characterized as ad hoc and
occasionally even chaotic.
o Few processes are defined, and success depends on
individual effort.
• Level 2: Repeatable.
o The necessary process discipline is in place to repeat earlier
successes on projects with similar applications.
o Basic project management processes are established to
track cost, schedule, and functionality.
14
 Process Maturity
• Level 3: Defined.
o The software process for both management and engineering activities is documented,
standardized, and integrated into an organization wide software process.
o All projects use a documented and approved version of the organization's process for
developing and supporting software.
o This level includes all characteristics defined for level 2.
• Level 4: Managed.
o Detailed measures of the software process and product quality are collected.
o Both the software process and products are quantitatively understood and controlled
using detailed measures.
o This level includes all characteristics defined for level 3.
• Level 5: Optimizing.
o Continuous process improvement is enabled by quantitative feedback from the process
and from testing innovative ideas and technologies.
o This level includes all characteristics defined for level 4.

15
 Process Model
The generic phases are common to all products. The issue is how
these phases will be executed. The execution is through a process.
Thus, it is appropriate to choose the process that fits your project.
The process models include:
a) Linear
phases: a number of dependent phases executed sequentially with no
feedback loops
Example: standard waterfall model
Characteristics:
-Requirements are clear and stable
-Goal and solution are clear
-complete solution is not released until the final phase

16
 Linear Model
• Disadvantage:
- change intolerant
- Requires detailed plan
• Advantage:
- Complete scheduling is possible
- Resource requirements are known

17
 Process Model
b) Incremental:
• Phases: a number of dependent phases that are repeated sequentially with no
feedback loops
• Example: Staged delivery Waterfall model; Feature-Driven Development
model(FDD)
• Characteristics:
- Clear goal, and solution
- Requirement splits for development purposes and delivered in increments
- Complete product evolves over time; each increment releases a partial of
known solution so that the customer can begin to realize business value
without having to wait for the complete solution. The first increment is often
a core product. That is, basic requirements are addressed, but many
supplementary features (some known, others unknown) remain undelivered.

18
 Incremental
• Advantage:
- Accommodates some changes unlike linear
o The core product is used by the customer (or undergoes detailed review).
o As a result of use and/or evaluation, a plan is developed for the next increment.
o The plan addresses the modification of the core product to better meet the needs of the
customer and the delivery of additional features and functionality.
o This process is repeated following the delivery of each increment, until the complete product is
produced.
- Better use scarce resource – scarce resource can be scheduled to from increment to increment
-allows involvement of clients
• Disadvantage:
- Requires detailed plan
- Defining each increment might be problematic: Each increment must be sound from a technical
as well as a business perspective. At times they might be at odds
Application:
- Any concern that requirements may not be clear and complete

19
 Incremental
• Analysis Design Code Test Delivery of 1st
increment
• Analysis Design Code Test Delivery of 2nd
increment
• Analysis Design Code Test Delivery of 3rd
increment
• Analysis Design Code Test Delivery of 4th
increment

20
 Process Model
• C) Iterative
• Phase: a number of phases that are repeated in groups
with a feedback loops after each group is completed.
Iteration can be on requirements, design,
implementation, and others
• Example:
- Evolutionary development waterfall model
- SCRUM
- Rational Unified Process(RUP)
- Dynamic Systems Development Method(DSDM)
21
 Iterative
• Characteristics:
- Clear goal; not all of the solution is clearly
defined
- Learn by doing or learn and discover
- Known solution is released in each iteration
- With each iteration more and more of the depth
of the solution is revealed. That follows from the
customer having an opportunity to play with the
then solution.
22
 Iterative
• Advantage:
- Customer can review intermediate prototype
- Accommodates changes between iterations
- Adapts to changing business conditions:
o Due to business conditions, what the
customer needs in the solution might change
and these changes can be built into the
solution at succeeding iterations
23
 Iterative
• Disadvantage:
- Requires more active customer involvement
which is not easily obtained
- Complete solution cannot be specified from
the outset which might be difficult to convince
the customer

24
 Examples of Iterative Models
• Evolutionary Development Waterfall Model
• SCRUM
• Rational Unified Process
• Dynamic Systems Development Model

25
 Evolutionary Development Waterfall
Model(EDWM)
• EDWM handles those cases where the
solution is known to a certain level of detail.
• The final features that completely defines the
solution are what are missing.
• Through a sequence of partial solutions the
complete solution is discovered.
• The process involves a meaningful
involvement of the customer.

26
 SCRUM
• A SCRUM involves the team as a unit moving the ball
down field in what would appear to be an ad hoc manner.
• The SCRUM team
- is self-directed
- Operates in successive one-month iterations
- Holds team meetings
- Continuously demos the client, and
- Adapts its development plan at the end of each iteration.
• SCRUM is characterized as chaotic and without project
manager.

27
 RUP
• RUP adapts quite well to a process approach that is
documentation-heavy or documentation-light
• The foundation of RUP lies in the library of reusable code,
requirements, designs, and so on.
• The essential concepts of RUP are:
- Inception
- Elaboration
- Construction
- Transition
• Each iteration of RUP includes the entire life cycle

28
 DSDM
• DSDM is separated from the standard
waterfall model by its feedback loops.

29
 Process Model
d) The Spiral Model
• Is evolutionary that couples the iterative nature of prototyping with
the controlled and systematic aspects of the linear sequential
model.
• It provides the potential for rapid development of incremental
versions of the software.
• Using the spiral model, software is developed in a series of
incremental releases.
• During early iterations, the incremental release might be a paper
model or prototype.
• During later iterations, increasingly more complete versions of the
engineered system are produced.

30
 Process Model
• The model has six task sets:
o Customer communication—tasks required to establish effective
communication between developer and customer.
o Planning—tasks required to define resources, timelines, and other project
related information.
o Risk analysis—tasks required to assess both technical and management risks.
o Engineering—tasks required to build one or more representations of the
application.
o Construction and release—tasks required to construct, test, install, and
provide user support (e.g., documentation and training).
o Customer evaluation—tasks required to obtain customer feedback based on
evaluation of the software representations created during the engineering
stage and implemented during the installation stage.

31
 Process Model
• The spiral model has the following problems:
o It may be difficult to convince customers
(particularly in contract situations) that the
evolutionary approach is controllable.
o It demands considerable risk assessment
expertise and relies on this expertise for
success. If a major risk is not uncovered and
managed, problems will undoubtedly occur.

32
 Process Model
e) Prototyping
Phases: Gather Reqts build test

Application: requirement is unclear to all

Disadvantage:
• The customer sees what appears to be a working version of the software,
unaware that in the rush to get it working no one has considered overall
software quality or long-term maintainability. When informed that the product
must be rebuilt so that high levels of quality can be maintained, the customer
demands that "a few fixes" be applied to make the prototype a working product.
• The developer often makes implementation compromises in order to get a
prototype working quickly. An inappropriate operating system or programming
language may be used simply because it is available and known; an inefficient
algorithm may be implemented simply to demonstrate capability.

33
 Process Model
e) RAD(Rapid Application Development)
• incremental software development process model that emphasizes an extremely short
development cycle.
• A “high-speed” adaptation of the linear sequential model in which rapid development is
achieved by using component-based construction.
• Application
- Requirement is clear and stable
- Each major function can be addressed by a separate RAD team
Disadvantage:
• For large but scalable projects, RAD requires sufficient number of RAD teams.
• RAD requires committed developers and customers to get a system complete in a much
abbreviated time frame. If commitment is lacking from either constituency, RAD projects will fail.
• If a system cannot be properly modularized, the RAD approach may not work.
• RAD is not appropriate when technical risks are high. This occurs when a new application makes
heavy use of new technology or when the new software requires a high degree of
interoperability with existing computer programs.

34
 Process Model
f) Component Based
Application: requirement can be split mapped to existing components
g) Concurrent Model
• The concurrent process model is often used as the paradigm for the development of lient/server11
applications.
• A client/server system is composed of a set of functional components.
• When applied to client/server, the concurrent process model defines activities in two dimensions: a
system dimension and a component dimension.
• System level issues are addressed using three activities: design, assembly, and use.
• The component dimension is addressed with two activities: design and realization.
• Concurrency is achieved in two ways:
o (1) system and component activities occur simultaneously and can be modeled using the state-
oriented approach described previously;
o (2) a typical client/server application is implemented with many components, each of which can be
designed and realized concurrently.
• In reality, the concurrent process model is applicable to all types of software development and
provides an accurate picture of the current state of a project.

35
 Process Technology
• The process models discussed must be
adapted for use by a software project team.
• To accomplish this, process technology tools
have been developed to help software
organizations analyze their current process,
organize work tasks, control and monitor
progress, and manage technical quality.

36
 Fundamentals-focus
Iv) Project
• In order to manage a successful software project, we must understand what can go
wrong (so that problems can be avoided) and how to do it right.
• Ten signs that indicate that a project is in jeopardy:
1. Software people don’t understand their customer’s needs.
2. The product scope is poorly defined.
3. Changes are managed poorly.
4. The chosen technology changes.
5. Business needs change [or are ill-defined].
6. Deadlines are unrealistic.
7. Users are resistant.
8. Sponsorship is lost [or was never properly obtained].
9. The project team lacks people with appropriate skills.
10. Managers [and practitioners] avoid best practices and lessons learned.

37
Fundamentals-Organization

38
 Responsibilities-Customer
• Giving requirements and requirement
clarifications
• Providing test data, acceptance criteria, etc
• Accepting deliverables

39
 Responsibilities-PM
• The PM plans and guides the project by:
- Initiating the project
- Understanding the project requirement
- Planning, estimation and scheduling of project
- Identifying the training needs, planning and executing them
- Moderating work products
- Reporting, monitoring, and reviewing status
- Resolving issues
- Releasing deliverables
- Closing the project

40
 Responsibilities-Dev’pt Team leader

• The leader coordinates and guides the team

whose tasks include:
o Understanding system requirements
o Defining requirements, RAD
o Performing design, SDD and implementation
o Reporting status and resolving issues

41
Responsibilities-CNFG Mgt Team Leader

• The leader coordinates and guides the team

whose tasks include:
o Controlling configuration library
o Enforcing change control
o Holding custody of change requests
o Preparing SCM plan

42
 Responsibilities-Risk Mgt Team Leader

• The leader coordinates and guides the team

whose tasks include:
o Identifying potential risks
o Estimating the probability and impact of each
risk
o Constructing a risk plan

43
 Responsibilities-SQA Team Leader
• The leader coordinates and guides the team
whose tasks include:
o Upholding organizational policies
o Adhering to project methodologies
o Performing review and test
o Preparing SQA plan

44
 Project Management Tasks
• SPM has 5 processes/phases:
- Initiating includes defining and authorizing a project
- Planning includes devising workable plans such as SPMP,
RMP, QAP
- Executing includes coordinating people and other resources
to carry out the various plans to produce a product
- Controlling includes regularly measuring and monitoring
progress to ensure the project is on track
- Closing includes formalizing acceptance of the project and
ending it

45
 Project Management Tasks-Initiation

• Purpose of project initiation

- To formally authorize a new project or allow
continuation of an existing one
- To confirm that the assigned project is
achievable with the specified framework

46
 Project Initiation- Activities
• Project initiation activities:
- Study customer’s request with care
- Investigate needs/business objectives
- Find out constraints and opportunities
- Choose dev’pt strategy by considering alternatives
- Develop the initial project plan
- Build the team
- Organize the project kick-off

47
 Project Initiation- Kick-off
• Purpose of project kick-off:
- To create a team spirit right up front
- To create an open environment where a fair
exchange of technical issue is encountered
- To achieve a common understanding of
project requirements
- To get commitment of the team members
towards the project objectives
48
 Project Initiation- Kick-off
• Kick-off agenda:
- Customer commitments
- Project plan and milestones
- Risks
- Performance measures
- baselines

49
 Project Initiation- Kick-off
• Who should attend kick-off:
- Project manager
- Team members
- Senior management
- Customers
- Suppliers
- Any other stakeholders

50
 SPM Tasks- Planning
• Purpose of project planning:
- to build appropriate software by making
everyone in the project to understand and
agree on both why and how that software will
be built before the work begins.
• Planning starts during project initiating stage

51
 SPM Tasks- Planning
• Planning specifies:
- What work will be done?
- How will it be done?
- How much will it cost?
- When will it be accomplished?
- What is the resource to do the work?
- What are the mechanisms of monitoring and
controlling?
- How will the changes and risks be handled?
52
 SPM Tasks- Planning
• Planning documents:
- Software Project Management Plan(SPMP)
- Risk Management Plan(RMP)
- Software Configuration Mgt Plan(SCMP)
- Software Quality Assurance Plan(SQAP)

53
 Software Management Plan Template
1. Introduction
1.1 Overview
1.2 Deliverables
2. Project Organization
2.1 Structure
2.2 Project Responsibilities
3. Managerial Process
3.1Meetings
3.2 Risk Management
3.3 Configuration Management
3.4 Quality Management
3.5 Monitoring and Controlling Mechanisms

54
 Template Cont’d
4. Technical process
4.1 Process model, methods, tools and
techniques
5. WBS, Schedule and Budget
5.1 WBS
5.2 Budget
5.3 Schedule

55
 Template cont’d
• Under section 3.2 -3.5 you need only to
indicate why they are needed. Inform the
reader that complete document on each will
be prepared separately.

56