Software Engineering Management
R
IE No ef
EE t er
fo en
C rD c
om i e
C
s
t
pu ri o
te bu py
r S tio
oc n
ie
ty
SWEBOK Certification
Program
Copyright Statement
R
IE No ef
EE t er
fo en
C rD c
om i e
C
s
t
pu ri o
te bu py
r S tio
oc n
ie
ty
Copyright © 2011 IEEE Computer Society. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning, or otherwise, except as permitted under Section 107 or 108 of the 1976 United States Copyright Act, without the prior written permission of the Publisher. Permission to reprint/republish this material for commercial, advertising or promotional purposes or for creating new collective works for resale or redistribution must be obtained from IEEE by writing to the IEEE Intellectual Property Rights Office, 445 Hoes Lane, Piscataway, NJ 08854‐4141 or pubs‐permissions@ieee.org. IEEE MAKES THIS DOCUMENT AVAILABLE ON AN "AS IS" BASIS AND MAKES NO WARRANTY, EXPRESS OR IMPLIED, AS TO THE ACCURACY, CAPABILITY, EFFICIENCY MERCHANTABILITY, OR FUNCTIONING OF THIS DOCUMENT. IN NO EVENT WILL IEEE BE LIABLE FOR ANY GENERAL, CONSEQUENTIAL, INDIRECT, INCIDENTAL, EXEMPLARY, OR SPECIAL DAMAGES, EVEN IF IEEE HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
1
R
IE No ef
EE t er
fo en
C rD c
om i e
C
s
t
pu ri o
te bu py
r S tio
oc n
ie
ty
Software Engineering
Management - Roadmap
Initiation and Scope Definition
Software Project Planning
Software Project Enactment
Review and Evaluation
Closure
Software Engineering Measurement
Software Management Tools
Software Engineering Management - Slide-2
Software Engineering Management
R
IE No ef
EE t er
fo en
C rD c
om i e
C
s
t
pu ri o
te bu py
r S tio
oc n
ie
ty
As per (IEEE610.12‐90), Software Engineering Management can be defined as the application of management activities—planning, coordinating, measuring, monitoring, controlling, and reporting—to ensure that the development and maintenance of software is systematic, disciplined, and quantified
The following aspects complicate software engineering management
–
Clients often a lack of appreciation for the complexity inherent in software engineering, particularly in relation to the impact of changing requirements
–
Often software engineering processes themselves generate the need for new or changed client requirements
–
As a result, software is often built in an iterative process rather than a sequence of closed tasks
–
Software engineering necessarily incorporates aspects of creativity and discipline. Maintaining an appropriate balance between the two is often difficult
–
The degree of novelty and complexity of software is often extremely high
–
There is a rapid rate of change in the underlying technology
Software Engineering Management - Slide-3
R
IE No ef
EE t er
fo en
C rD c
om i e
C
s
t
pu ri o
te bu py
r S tio
oc n
ie
ty
Content Area 1
Initiation and Scope Definition
Software Engineering Management - Slide-4
Content Area 1: Initiation and Scope Definition
R
IE No ef
EE t er
fo en
C rD c
om i e
C
s
t
pu ri o
te bu py
r S tio
oc n
ie
ty
Initiation and Scope Definition
Software Engineering Management - Slide-5
R
IE No ef
EE t er
fo en
C rD c
om i e
C
s
t
pu ri o
te bu py
r S tio
oc n
ie
ty
Content Area 2
Software Project Planning
Software Engineering Management - Slide-6
Content Area 2: Software Project Planning
Project Planning Process
6. Developing a
quality management
process
5. Identifying and
Managing risks
1. Planning the process
(lifecycle stages, methods,
tools, tasks)
R
IE No ef
EE t er
fo en
C rD c
om i e
C
s
t
pu ri o
te bu py
r S tio
oc n
ie
ty
7. Planning to manage the plan
Project Planning
2. Determining deliverables
(buy vs. develop vs. reuse)
3. Estimating effort,
schedule and cost
4. Allocating resources
(equipment, facilities,
people)
Software Engineering Management - Slide-7
Content Area 2: Software Project Planning
Project Planning Process
6. Developing a
quality management
process
5. Identifying and
Managing risks
1. Planning the process
(lifecycle stages, methods,
tools, tasks)
R
IE No ef
EE t er
fo en
C rD c
om i e
C
s
t
pu ri o
te bu py
r S tio
oc n
ie
ty
7. Planning to manage the plan
Project Planning
2. Determining deliverables
(buy vs. develop vs. reuse)
3. Estimating effort,
schedule and cost
4. Allocating resources
(equipment, facilities,
people)
Software Engineering Management - Slide-8
Content Area 2: Software Project Planning
Process Planning
R
IE No ef
EE t er
fo en
C rD c
om i e
C
s
t
pu ri o
te bu py
r S tio
oc n
ie
ty
Requirements define the end result of software development
Project plan describes how to get from the stated requirements to the functioning software
As per IEEE/EIA Std. 12207.0‐1996, project plan elements include
Resources needed to execute the tasks
Allocation of tasks
Assignment of responsibilities
Quality control measures to be used throughout
Provision of environment and infrastructure
Software Engineering Management - Slide-9
Content Area 2: Software Project Planning
Lifecycle Models
R
IE No ef
EE t er
fo en
C rD c
om i e
C
s
t
pu ri o
te bu py
r S tio
oc n
ie
ty
Waterfall (linear)
Prototyping (iterative)
Incremental (iterative)
Evolutionary (iterative)
Spiral (iterative)
Software Engineering Management - Slide-10
Content Area 2: Software Project Planning
R
IE No ef
EE t er
fo en
C rD c
om i e
C
s
t
pu ri o
te bu py
r S tio
oc n
ie
ty
Waterfall and Prototyping Model
Prototyping model can be used with other models besides just waterfall
Implementation
Test
Installation and Checkout
Operation and Maintenance
Retirement
Software Engineering Management - Slide-11
Content Area 2: Software Project Planning
Iterative and Evolutionary Model
Iterative Model
Concept Exploration
Evolutionary Model
R
IE No ef
EE t er
fo en
C rD c
om i e
C
s
t
pu ri o
te bu py
r S tio
oc n
ie
ty
Partial Requirements
Requirements
Defined for each iteration or just once
Iterations
Prototype
Design
Additional Requirements
Implementation
Iterations
Test
Installation and Checkout
Ongoing maintenance
occurs as soon as the
first tested
implementation is in the
Software Engineering Management - Slide-12
field.
Operation
Retirement
Content Area 2: Software Project Planning
Spiral Model
R
IE No ef
EE t er
fo en
C rD c
om i e
C
s
t
pu ri o
te bu py
r S tio
oc n
ie
ty
Iterations are independent, but knowledge gained is rolled over as project grows in size
Spiral Model explicitly considers risk in every iteration
Software Engineering Management - Slide-13
Content Area 2: Software Project Planning
R
IE No ef
EE t er
fo en
C rD c
om i e
C
s
t
pu ri o
te bu py
r S tio
oc n
ie
ty
Risk Analysis “against” Selecting
a Life-Cycle Model
Once‐through (Waterfall)
Risk Item
Requirements not well understood
System too large to do at once
Rapid changes in technology anticipated –
may change requirements
Limited staff or budget available now
Incremental
Risk Level
Risk Item
Risk Level
H
Requirements not well understood
H
M
User prefers all capabilities at first delivery
M
H
Rapid changes in technology anticipated –
may change requirements
H
M
Source: IEEE/EIA Std. 12207.2-1997
Software Engineering Management - Slide-14
Evolutionary
Risk Item
User prefers all capabilities at delivery
Risk Level
M
Content Area 2: Software Project Planning
Risk Analysis “for” Selecting a
Life-Cycle Model
Opportunity Item
Opp Level
User prefers all capabilities at first delivery
M
User prefers to phase out old system all at once
L
Incremental
Evolutionary
R
IE No ef
EE t er
fo en
C rD c
om i e
C
s
t
pu ri o
te bu py
r S tio
oc n
ie
ty
Once‐through (Waterfall)
Opportunity Item
Opp Level
Opportunity Item
Opp Level
Early capability is needed
H
Early capability is needed
H
System breaks naturally into increments
M
System breaks naturally into increments
M
Funding/staffing will be incremental
H
Funding/staffing will be incremental
H
User feedback & monitoring of technology changes is needed to understand full requirements
H
Source: IEEE/EIA Std. 12207.2-1997
Software Engineering Management - Slide-15
Content Area 2: Software Project Planning
Discussion Question
R
IE No ef
EE t er
fo en
C rD c
om i e
C
s
t
pu ri o
te bu py
r S tio
oc n
ie
ty
What is the difference between iterative and incremental software development?
Software Engineering Management - Slide-16
Content Area 2: Software Project Planning
Iterative Versus Incremental
Incremental
Iterative
Rework scheduling strategy
Various parts of the system are developed and built at different times
Rework strategy to revisit and improve parts of the product
R
IE No ef
EE t er
fo en
C rD c
om i e
C
s
t
pu ri o
te bu py
r S tio
oc n
ie
ty
Staging & scheduling strategy
Integrated as they are completed versus integrating in one go
– Increments may be shipped
Helps improve the development process
Iteration is examined for modification – But not shipped
Helps improve the product
Works well with incremental development
Works well with waterfall or iterative approaches
Reference: http://alistair.cockburn.us/index.php/Incremental_versus_iterative_development
Software Engineering Management - Slide-17
Content Area 2: Software Project Planning
Discussion Question
R
IE No ef
EE t er
fo en
C rD c
om i e
C
s
t
pu ri o
te bu py
r S tio
oc n
ie
ty
What are the principal activities and elements of software project planning?
Software Engineering Management - Slide-18
Content Area 2: Software Project Planning
Project Planning Process
6. Developing a
quality management
process
5. Identifying and
Managing risks
R
IE No ef
EE t er
fo en
C rD c
om i e
C
s
t
pu ri o
te bu py
r S tio
oc n
ie
ty
7. Planning to manage the plan
1. Planning the process
(lifecycle stages, methods,
tools, tasks)
Project Planning
2. Determining deliverables
(buy vs. develop vs. reuse)
3. Estimating effort,
schedule and cost
4. Allocating resources
(equipment, facilities,
people)
Software Engineering Management - Slide-19
Content Area 2: Software Project Planning
Determination of Deliverables
–
–
–
–
–
–
–
–
–
–
–
R
IE No ef
EE t er
fo en
C rD c
om i e
C
s
t
pu ri o
te bu py
r S tio
oc n
ie
ty
Project plan specifies the project deliverables which may include, without being limited to:
The operational software
Customer requirements
Functional specifications
Design specifications
Design documentation
Source code
User manuals
Principles of operation
Installation instructions
Maintenance procedures
Training materials
Software Engineering Management - Slide-20
Content Area 2: Software Project Planning
Make versus Buy Decisions
R
IE No ef
EE t er
fo en
C rD c
om i e
C
s
t
pu ri o
te bu py
r S tio
oc n
ie
ty
To evaluate the relative merits of building, buying, or reusing software, the project manager has to consider the following
– Evaluate whether to reuse existing components or buy off‐the‐shelf components
– Plan for any use of third parties
– Procure software and select suppliers
– Determine training needs and how to address them
Before purchasing or reusing software, the project manager must evaluate
– Whether the software truly satisfies the requirements
– Whether the software is compatible with the rest of the system
Software Engineering Management - Slide-21
Content Area 2: Software Project Planning
Project Planning Process
6. Developing a
quality management
process
5. Identifying and
Managing risks
R
IE No ef
EE t er
fo en
C rD c
om i e
C
s
t
pu ri o
te bu py
r S tio
oc n
ie
ty
7. Planning to manage the plan
1. Planning the process
(lifecycle stages, methods,
tools, tasks)
Project Planning
2. Determining deliverables
(buy vs. develop vs. reuse)
3. Estimating effort,
schedule and cost
4. Allocating resources
(equipment, facilities,
people)
Software Engineering Management - Slide-22
Content Area 2: Software Project Planning
Estimation of Size
Gaffney and Cruikshank identify the following 14 factors for function point estimation:
¾ Data communications
¾ Distributed functions
¾ Performance
¾ Heavily used operational configuration
¾ Transaction rate
¾ Online data entry
¾ Design for end‐user efficiency
¾ Online update (for logical internal files)
¾ Complex processing
¾ Reusability of system code
¾ Operational ease
¾ Multiple sites
¾ Ease of change
R
IE No ef
EE t er
fo en
C rD c
om i e
C
s
t
pu ri o
te bu py
r S tio
oc n
ie
ty
Size in SLOC
Size
Measures
Size in function points
1. Count features internal inputs or files; external outputs, inquiries, or interfaces)
2. Weight features for level of complexity
3. Adjust to account for 14 factors affecting functional size
Reference: Thayer, Richard H. Software Engineering Project Management, 2nd ed. Los Alamitos, California: IEEE
Computer Society, 2000
Software Engineering Management - Slide-23
Content Area 2: Software Project Planning
Estimation of Effort
R
IE No ef
EE t er
fo en
C rD c
om i e
C
s
t
pu ri o
te bu py
r S tio
oc n
ie
ty
Effort estimation depend upon the project size estimation
– Combine size with productivity estimation to compute effort in person‐months
SLOC/person‐month
Productivity
Measures
Code statements /person‐month
Function points /person‐month
Software Engineering Management - Slide-24
Content Area 2: Software Project Planning
Estimation of Schedule
R
IE No ef
EE t er
fo en
C rD c
om i e
C
s
t
pu ri o
te bu py
r S tio
oc n
ie
ty
Project manager must create the most efficient schedule keeping in mind the available resources and the nature of tasks
Milestone chart method (for smaller projects)
– Lists task completion time; does not show task interactions
Critical Path Method (CPM)
– Critical path consists of all tasks that must wait for prior completion of other tasks. Other tasks can be run simultaneously in parallel
Program Evaluation and Review Technique (PERT)
– Has a network of tasks like CPM but has project events as milestones instead of project activities. – Can specifies probabilities for meeting deadlines for each event (this is especially useful when doing estimations for Research and Development projects where the cause‐
effect relationship is not very well‐established)
Software Engineering Management - Slide-25
Content Area 2: Software Project Planning
R
IE No ef
EE t er
fo en
C rD c
om i e
C
s
t
pu ri o
te bu py
r S tio
oc n
ie
ty
PERT/CPM Chart
Reference: http://www.rff.com/pert_hardware.htm
Software Engineering Management - Slide-26
Content Area 2: Software Project Planning
Estimation of Schedule
Gantt chart method
R
IE No ef
EE t er
fo en
C rD c
om i e
C
s
t
pu ri o
te bu py
r S tio
oc n
ie
ty
– Is a bar chart that illustrates start and end dates for all tasks
– Provides a visual representation of the degree to which tasks overlap in time
– Does not explicitly display the dependent tasks like PERT/CPM
Full‐wall scheduling method
– Use a large wall containing a grid to indicate weeks of project time
– Post‐it notes are used by team‐members to indicate the start and end dates of tasks
– Invites most participation from team‐members than other methods
– Does not show task relationships
– Poorly adapts to revision when changes occur to tasks/times
Software Engineering Management - Slide-27
Content Area 2: Software Project Planning
R
IE No ef
EE t er
fo en
C rD c
om i e
C
s
t
pu ri o
te bu py
r S tio
oc n
ie
ty
Gantt Chart
Reference: Gantt Chart Tutorial http://www.gantt-chart.biz/
Software Engineering Management - Slide-28
Content Area 2: Software Project Planning
Discussion Question
R
IE No ef
EE t er
fo en
C rD c
om i e
C
s
t
pu ri o
te bu py
r S tio
oc n
ie
ty
When would you use a PERT chart or a GANTT chart? Explain.
Software Engineering Management - Slide-29
Content Area 2: Software Project Planning
Estimation of Cost
R
IE No ef
EE t er
fo en
C rD c
om i e
C
s
t
pu ri o
te bu py
r S tio
oc n
ie
ty
Convert all preceding estimates into costs. This includes all resources required to complete all the designated tasks
– E.g. labor, tools, travel, facilities, material items (e.g., off‐the‐shelf software)
Work Breakdown Structure (WBS) allows bottom‐up costing
– This method supports Earned Value Management (EVM) approach to project management
Costing should account for – Peripherals when outsourcing
– Overhead (e.g., benefits, support staff) for internal labor
Sample Chart showing Earned Value
versus Planned Value versus Actual Cost
Software Engineering Management - Slide-30
Content Area 2: Software Project Planning
Discussion Question
R
IE No ef
EE t er
fo en
C rD c
om i e
C
s
t
pu ri o
te bu py
r S tio
oc n
ie
ty
A software development project is behind schedule and requires 6‐man months effort for completion. The team working on the project currently consists of 3 employees. In order to finish the project by the deadline which is in 1 month, the project manager decides to add 3 new software developers to the existing team. Do you think the project will be completed in time? Explain.
Software Engineering Management - Slide-31
Content Area 2: Software Project Planning
Project Planning Process
6. Developing a
quality management
process
5. Identifying and
Managing risks
R
IE No ef
EE t er
fo en
C rD c
om i e
C
s
t
pu ri o
te bu py
r S tio
oc n
ie
ty
7. Planning to manage the plan
1. Planning the process
(lifecycle stages, methods,
tools, tasks)
Project Planning
2. Determining deliverables
(buy vs. develop vs. reuse)
3. Estimating effort,
schedule and cost
4. Allocating resources
(equipment, facilities,
people)
Software Engineering Management - Slide-32
Content Area 2: Software Project Planning
Resource Allocation
R
IE No ef
EE t er
fo en
C rD c
om i e
C
s
t
pu ri o
te bu py
r S tio
oc n
ie
ty
Resources i.e. tools, people, facilities need to be assigned for specific tasks
– Allocation of people requires balance of expertise and personalities
Training of team members can help – Teams to become productive quickly
– Select leaders
– Improve communication skills
Schedule/cost adjustment is needed if resources become unexpectedly unavailable
Project manager may need to alter team size and structure so that concurrent activities can be effectively executed
Software Engineering Management - Slide-33
Content Area 2: Software Project Planning
Project Planning Process
6. Developing a
quality management
process
5. Identifying and
Managing risks
R
IE No ef
EE t er
fo en
C rD c
om i e
C
s
t
pu ri o
te bu py
r S tio
oc n
ie
ty
7. Planning to manage the plan
1. Planning the process
(lifecycle stages, methods,
tools, tasks)
Project Planning
2. Determining deliverables
(buy vs. develop vs. reuse)
3. Estimating effort,
schedule and cost
4. Allocating resources
(equipment, facilities,
people)
Software Engineering Management - Slide-34
Content Area 2: Software Project Planning
Risk Management
All project management activities can be seen as risk management
R
IE No ef
EE t er
fo en
C rD c
om i e
C
s
t
pu ri o
te bu py
r S tio
oc n
ie
ty
– E.g., Cost estimates mitigate the risk of losing money
The ISO/IEC Std. 24765 vocabulary defines risk management as:
(1) an organized process for identifying and handling risk factors.
(2) an organized means of identifying and measuring risk (risk assessment) and developing, selecting, and managing options (risk analysis) for resolving (risk handling) these risks.
(3) organized, analytic process to identify what might cause harm or loss (identify risks); to assess and quantify the identified risks; and to develop and, if needed, implement an appropriate approach to prevent or handle causes of risk that could result in significant harm or loss.
Software Engineering Management - Slide-35
Content Area 2: Software Project Planning
Risk Management Process
As per IEEE/EIA Std. 12207.0‐1996 Risk management plan is negotiated & accepted by all stakeholders. Assign resources and responsibilities.
R
IE No ef
EE t er
fo en
C rD c
om i e
C
s
t
pu ri o
te bu py
r S tio
oc n
ie
ty
Plan and implement
risk management
Manage project risk profile
Identify project’s risks as well as priority, status, threshold, and action requests for each risk
Identify conditions that cause risks and
consequences of those risks
Perform risk
analysis
Perform risk
treatment
Perform risk
monitoring
Select, plan, monitor, and control actions to decrease risk exposure
Review/update risk levels, assess effectiveness
of risk treatment, search for new risks & sources
Evaluate risk
management process
Software Engineering Management - Slide-36
Inform stakeholders about the
quality of risk management Content Area 2: Software Project Planning
Techniques to Manage Risks
Once risks are identified, they can be managed in the following ways:
R
IE No ef
EE t er
fo en
C rD c
om i e
C
s
t
pu ri o
te bu py
r S tio
oc n
ie
ty
Avoidance ‐ Avoid high risks
– E.g., Choose a component that performs acceptably but has a lower risk than another component
Control ‐ Use traditional project management techniques to control risks
– E.g., Use QA, reviews, and audits
Assumption
– If potential benefits are high enough and probability of risk occurrence is low, accept the risks
Transfer ‐ If a risk seems high in one area, transfer it another area
– E.g., If subcontracting development involves a high risk of late delivery, bring offshore development to in‐house for tighter control
Software Engineering Management - Slide-37
Content Area 2: Software Project Planning
Discussion Question
R
IE No ef
EE t er
fo en
C rD c
om i e
C
s
t
pu ri o
te bu py
r S tio
oc n
ie
ty
Identifying and managing risks are an important part of effective management of the software engineering effort. Risks are documented:
A. In a concise statement of what went wrong and when they occurred in the project lifecycle
B. As clearly defined tasks in the project schedule
C. In a concise statement that includes the context, conditions, and consequences of risk occurrence
D. As clearly defined line‐items in the project budget
Answer: C
Software Engineering Management - Slide-38
Content Area 2: Software Project Planning
Project Planning Process
6. Developing a
quality management
process
5. Identifying and
Managing risks
R
IE No ef
EE t er
fo en
C rD c
om i e
C
s
t
pu ri o
te bu py
r S tio
oc n
ie
ty
7. Planning to manage the plan
1. Planning the process
(lifecycle stages, methods,
tools, tasks)
Project Planning
2. Determining deliverables
(buy vs. develop vs. reuse)
3. Estimating effort,
schedule and cost
4. Allocating resources
(equipment, facilities,
people)
Software Engineering Management - Slide-39
Content Area 2: Software Project Planning
Quality Management
R
IE No ef
EE t er
fo en
C rD c
om i e
C
s
t
pu ri o
te bu py
r S tio
oc n
ie
ty
Project manager works with all stakeholders to establish a quality plan for both the process and products
As per IEEE/EIA Std. 12207.0‐1996, a quality assurance management plan should include:
– Quality standards, methodologies, procedures, and tools for performing the quality assurance activities (or their references in organization’s official documentation).
– Procedures for contract review and coordination thereof. – Procedures for identification, collection, filing, maintenance, and disposition of quality records.
– Resources, schedule, and responsibilities for conducting the quality assurance activities.
– Selected activities and tasks from supporting processes such as Verification, Validation, Joint Review, Audit, and Problem Resolution.
More details are covered in Content Domain “Software Quality”
Software Engineering Management - Slide-40
Content Area 2: Software Project Planning
Project Planning Process
6. Developing a
quality management
process
5. Identifying and
Managing risks
R
IE No ef
EE t er
fo en
C rD c
om i e
C
s
t
pu ri o
te bu py
r S tio
oc n
ie
ty
7. Planning to manage the plan
1. Planning the process
(lifecycle stages, methods,
tools, tasks)
Project Planning
2. Determining deliverables
(buy vs. develop vs. reuse)
3. Estimating effort,
schedule and cost
4. Allocating resources
(equipment, facilities,
people)
Software Engineering Management - Slide-41
Content Area 2: Software Project Planning
Plan Management
R
IE No ef
EE t er
fo en
C rD c
om i e
C
s
t
pu ri o
te bu py
r S tio
oc n
ie
ty
Project management plan helps assess how the project is faring. Therefore, as the project progresses, the plan must be updated to reflect – Revised requirements
– Extended schedules
– Changes in testing procedures
– Modified software functionality
Adherence to the plan must be systematically directed, monitored, reviewed, reported, and revised
Project management plans are configuration items and are part of the program baseline
– Thus, changes to a plan should be analyzed, scoped, and submitted to the Change Control Board (CCB) for disposition
Software Engineering Management - Slide-42
Content Area 2: Software Project Planning
Discussion Question
R
IE No ef
EE t er
fo en
C rD c
om i e
C
s
t
pu ri o
te bu py
r S tio
oc n
ie
ty
Paul has drafted a software project management plan. Which of the following items should be discussed in this plan?
I. Schedule
II. Budget
III. Requirements
IV. Staffing
A.
B.
C.
D.
I, III, IV only
I, II, III only
I, II, IV only
I, II, III, IV
Answer: C
Software Engineering Management - Slide-43
R
IE No ef
EE t er
fo en
C rD c
om i e
C
s
t
pu ri o
te bu py
r S tio
oc n
ie
ty
Content Area 3
Software Project Enactment
Software Engineering Management - Slide-44
Content Area 3: Software Project Enactment
Project Enactment
R
IE No ef
EE t er
fo en
C rD c
om i e
C
s
t
pu ri o
te bu py
r S tio
oc n
ie
ty
After the project plan has been prepared and approved by stakeholders, the project manager has to implement the plan
Enactment involves the following project manager duties:
– Managing any supplier contracts
– Monitoring adherence to the plan to discover any significant variances
– Controlling any problems discovered by monitoring
– Reporting adherence to the plan to stakeholders both on and outside the team
Software Engineering Management - Slide-45
Content Area 3: Software Project Enactment
Supplier Contract Management
R
IE No ef
EE t er
fo en
C rD c
om i e
C
s
t
pu ri o
te bu py
r S tio
oc n
ie
ty
Managing agreements with subcontractors who either sell or develop software components introduces special demands on the project manager
Process for handling supplier contracts as per IEEE Std. 1062: 1998
–
–
–
–
–
–
–
–
–
Planning organizational strategy
Implementing organization’s process
Determining software requirements
Identifying potential suppliers
Preparing contract documents
Evaluating proposals and selecting suppliers
Managing supplier performance
Accepting the software
Using the software
Software Engineering Management - Slide-46
Content Area 3: Software Project Enactment
Monitoring Plan Adherence
R
IE No ef
EE t er
fo en
C rD c
om i e
C
s
t
pu ri o
te bu py
r S tio
oc n
ie
ty
At predetermined intervals, the project manager assesses the status of the process to see if there are any variances from the plan
Successful monitoring includes the following activities:
– Analysis of outputs and completion conditions for each task
– Evaluation of deliverables in terms of required characteristics (such as by reviews and audits)
– Investigation of effort expenditure, schedule adherence & costs to date
– Examination of resource usage
Among the types of variance that may require action are cost overruns, schedule slippage, incomplete delivery of an item, failure to meet quality standards, status or risks, and risk reports
Software Engineering Management - Slide-47
Content Area 3: Software Project Enactment
Control Process & Reporting
R
IE No ef
EE t er
fo en
C rD c
om i e
C
s
t
pu ri o
te bu py
r S tio
oc n
ie
ty
To control problems discovered by monitoring, the following needs to be done:
Accurate assessment of the real cause of the problems
Identification of the side‐effects of those problems using an appropriate project management model such as CPM/PERT diagrams
Making suitable decisions to address the problems as well as their side‐effects
Updating the schedule and cost estimates based on the new decisions
Documenting the decisions and communicating them to all relevant parties
Reporting is essential for proper monitoring and control of the project
The project manager is responsible for establish reporting procedures for the project. These procedures include:
– Timing, nature, distribution list, and media of communication for the reports
Software Engineering Management - Slide-48
R
IE No ef
EE t er
fo en
C rD c
om i e
C
s
t
pu ri o
te bu py
r S tio
oc n
ie
ty
Content Area 4
Review and Evaluation
Software Engineering Management - Slide-49
Content Area 4: Review and Evaluation
Review and Evaluation
R
IE No ef
EE t er
fo en
C rD c
om i e
C
s
t
pu ri o
te bu py
r S tio
oc n
ie
ty
Satisfied users provide the ultimate measure of success for a software engineering project. So, it is important to regularly assess progress towards user satisfaction
Formal reviews at major milestones help – Detect variances from the plan – Address the identified variances
– Communicate the problems and adopted solutions to stakeholders
– Record review data in a central database
Periodic performance reviews help assess concerns such as – Individual performance to date
– Readiness for performing future tasks
– Relationships within the team and hierarchy
The process, itself, should also be subjected to review and revision Software Engineering Management - Slide-50
R
IE No ef
EE t er
fo en
C rD c
om i e
C
s
t
pu ri o
te bu py
r S tio
oc n
ie
ty
Content Area 5
Closure
Software Engineering Management - Slide-51
Content Area 5: Closure
Software Project Closure
The following are project closure criteria:
R
IE No ef
EE t er
fo en
C rD c
om i e
C
s
t
pu ri o
te bu py
r S tio
oc n
ie
ty
– Tasks specified in the plans have been completed, and satisfactory achievement of completion criteria has been confirmed
– All planned products have been delivered with acceptable characteristics
– Requirements are checked off and confirmed as satisfied
– Project objectives have been achieved
Closure activities include: – Archiving of project materials
– Updating the organization’s measurement database with final project data followed by post‐project analyses
– Undertaking the project postmortem so that all issues, problems, and opportunities encountered during the process (particularly via review and evaluation) are analyzed. Lessons are drawn from the process and fed into organizational learning and improvement endeavors
Software Engineering Management - Slide-52
R
IE No ef
EE t er
fo en
C rD c
om i e
C
s
t
pu ri o
te bu py
r S tio
oc n
ie
ty
Content Area 6
Software Engineering Measurement
Software Engineering Management - Slide-53
Content Area 6: Software Engineering Measurement
R
IE No ef
EE t er
fo en
C rD c
om i e
C
s
t
pu ri o
te bu py
r S tio
oc n
ie
ty
Software Engineering
Measurement
Accurate measurement is critical for effective project management
ISO/IEC Std. 15939 identifies four steps in establishing and applying a measurement system:
– Establish and sustain measurement commitment
– Plan the measurement process
– Perform the measurement process
– Evaluate measurement
Software Engineering Management - Slide-54
Content Area 6: Software Engineering Measurement
R
IE No ef
EE t er
fo en
C rD c
om i e
C
s
t
pu ri o
te bu py
r S tio
oc n
ie
ty
Establish & Sustain Measurement
Commitment
Accept requirements for measurement based on objectives accepted by all relevant parties
Create a plan for measuring progress towards each objective – Specify the scope of measurement: identify what is to be measured
– Obtain a formal agreement from management and staff
Commit resources for measurement
– Assign people to carry out specific measurement‐related tasks
– Provide funds, training, and tools Software Engineering Management - Slide-55
Content Area 6: Software Engineering Measurement
Plan the Measurement Process
Planning the measurement process includes the following activities:
R
IE No ef
EE t er
fo en
C rD c
om i e
C
s
t
pu ri o
te bu py
r S tio
oc n
ie
ty
– Characterize the organizational unit in terms of organizational processes, application domains, technology, and organizational interfaces
– Identify and prioritize information needs based on goals, constraints, risks, and problems of the organizational unit
– Select measures from candidate measures with clear links to information needs, basing selection on priority of information needs and other practical criteria
– Define data collection, analysis, and reporting procedures
– Define criteria for evaluating the information products
– Review, approve, and provide resources for measurement tasks:
ƒ All stakeholders must review the plan
ƒ Resources should be made available for implementing the planned and approved measurement tasks
– Acquire and deploy supporting technologies
Software Engineering Management - Slide-56
Content Area 6: Software Engineering Measurement
Perform the Measurement
Process
R
IE No ef
EE t er
fo en
C rD c
om i e
C
s
t
pu ri o
te bu py
r S tio
oc n
ie
ty
The measurement process can be broken down into four phases:
– Integrate measurement procedures, such as data collection, with relevant project processes. This may involve changing processes to accommodate the measurement activity or to minimize additional effort required of team members
– Collect, verify, and store data
– Analyze data and develop information products. This involves aggregation, transformation, or recording of data as part of analysis. This results, typically, in graphs, numbers, or other indications that must be interpreted to yield conclusions for presentation to stakeholders
– Communicate results to users and other stakeholders
Software Engineering Management - Slide-57
Content Area 6: Software Engineering Measurement
Evaluate Measurement
R
IE No ef
EE t er
fo en
C rD c
om i e
C
s
t
pu ri o
te bu py
r S tio
oc n
ie
ty
As the project progresses and measurements are taken, the measurement activities and products can be evaluated and improved as necessary. The project team may:
– Evaluate information products against criteria to determine their strength or weakness, and seek feedback from users. Record lessons in a database
– Evaluate the measurement process, and include feedback from users. Record lessons in a database
– Identify potential improvements
Software Engineering Management - Slide-58
R
IE No ef
EE t er
fo en
C rD c
om i e
C
s
t
pu ri o
te bu py
r S tio
oc n
ie
ty
Content Area 7
Software Management Tools
Software Engineering Management - Slide-59
Content Area 7: Software Management Tools
Software Management Tools
R
IE No ef
EE t er
fo en
C rD c
om i e
C
s
t
pu ri o
te bu py
r S tio
oc n
ie
ty
Software engineering management tools can be very helpful in monitoring and measuring the program process
Software engineering management tools can be divided into three categories
– Project planning and tracking tools
ƒ Used in software project effort measurement, cost estimation, and scheduling
ƒ E.g. Primavera, MS Project etc.
– Risk management tools
ƒ Used to identify, estimate, and monitor risks
– Measurement tools
ƒ Assist in performing activities related to the software measurement program
Software Engineering Management - Slide-60
R
IE No ef
EE t er
fo en
C rD c
om i e
C
s
t
pu ri o
te bu py
r S tio
oc n
ie
ty
Module – 3
Chapter –Debrief
Software Engineering Management
Software Engineering Management - Slide-61
End of Module 4
Suggested Reading & References
R
IE No ef
EE t er
fo en
C rD c
om i e
C
s
t
pu ri o
te bu py
r S tio
oc n
ie
ty
Boehm, Barry W. “A Spiral Model of Software Development and Enhancement.” Computer, Vol. 21, Issue 5, May 1998
Brooks, Frederick P. The Mythical Man‐Month: Essays on Software Engineering. Reading, Massachusetts: Addison‐Wesley, 1975
Guide to the Software Engineering Body of Knowledge (SWEBOK), 2004 ed. Los Alamitos, California: IEEE Computer Society Press, 2004
Ian Sommerville, “Software Engineering”, 8th ed., Addison‐Wesley, 2006
Thayer, Richard H. Software Engineering Project Management, 2nd ed. Los Alamitos, California: IEEE Computer Society, 2000
Thayer, Richard H., and Mark J. Christensen, eds. Software Engineering, Volume 1: The Development Process, 3rd ed. Hoboken, New Jersey: John Wiley/Los Alamitos, California: IEEE Computer Society Press, 2005
Thayer, Richard H., and Merlin Dorfman, eds. Software Engineering, Volume 2: The Supporting Processes, 3rd ed. Hoboken, New Jersey: John Wiley/Los Alamitos, California: IEEE Computer Society Press, 2005
Software Engineering Management - Slide-62