software engineering - ieee china

Software Engineering Management

SWEBOK Certification Program

Referen

ce C

opy

Not for

Dist

ributi

on

IEEE C

ompu

ter S

ociet

y

Copyright Statement

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‐[email protected].

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

Referen

ce C

opy

Not for

Dist

ributi

on

IEEE C

ompu

ter S

ociet

y

Software Engineering Management - Slide-2

Software Engineering Management - Roadmap

Initiation and Scope Definition

Software Project Planning

Software Project Enactment

Review and Evaluation

Closure

Software Engineering Measurement

Software Management Tools

Referen

ce C

opy

Not for

Dist

ributi

on

IEEE C

ompu

ter S

ociet

y


Software Engineering ManagementAs 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 technologyRefe

rence

Cop

y

Not for

Dist

ributi

on

IEEE C

ompu

ter S

ociet

y


Content Area 1


Referen

ce C

opy

Not for

Dist

ributi

on

IEEE C

ompu

ter S

ociet

y



Content Area 1: Initiation and Scope Definition

Referen

ce C

opy

Not for

Dist

ributi

on

IEEE C

ompu

ter S

ociet

y


Content Area 2

Software Project Planning

Referen

ce C

opy

Not for

Dist

ributi

on

IEEE C

ompu

ter S

ociet

y


Project Planning Process

Content Area 2: Software Project Planning

Project Planning

1. Planning the process(lifecycle stages, methods,tools, tasks)

2. Determining deliverables(buy vs. develop vs. reuse)

3. Estimating effort,schedule and cost

4. Allocating resources(equipment, facilities,

people)

5. Identifying andManaging risks

6. Developing aquality management

process

7. Planning to manage the plan

Referen

ce C

opy

Not for

Dist

ributi

on

IEEE C

ompu

ter S

ociet

y




Project Planning





people)



process


Referen

ce C

opy

Not for

Dist

ributi

on

IEEE C

ompu

ter S

ociet

y


Process Planning

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


Referen

ce C

opy

Not for

Dist

ributi

on

IEEE C

ompu

ter S

ociet

y


Lifecycle Models

Waterfall (linear)

Prototyping (iterative)

Incremental (iterative)

Evolutionary (iterative)

Spiral (iterative)


Referen

ce C

opy

Not for

Dist

ributi

on

IEEE C

ompu

ter S

ociet

y


Implementation

Test

Installation and Checkout

Operation and Maintenance

Retirement

Waterfall and Prototyping Model

Prototyping model can be used with other models

besides just waterfall


Referen

ce C

opy

Not for

Dist

ributi

on

IEEE C

ompu

ter S

ociet

y


Iterative and Evolutionary Model

Concept Exploration

Requirements

Design

Implementation

Test

Installation and Checkout

Operation

Retirement

Iterations

Ongoing maintenance occurs as soon as the

first tested implementation is in the

field.

Defined for each

iteration or just once

Iterative Model Evolutionary Model

Partial Requirements

Prototype

Additional Requirements

Iterations


Referen

ce C

opy

Not for

Dist

ributi

on

IEEE C

ompu

ter S

ociet

y


Spiral Model

Iterations are independent, but knowledge gained is rolled over as project grows in size

Spiral Model explicitly considers risk in every iteration


Referen

ce C

opy

Not for

Dist

ributi

on

IEEE C

ompu

ter S

ociet

y


Risk Analysis “against” Selecting a Life-Cycle Model

Once‐through (Waterfall) Incremental Evolutionary

Risk Item Risk Level



Requirements not well understood

H Requirements not well understood

H

System too large to do at once

M User prefers all capabilities at first delivery

M User prefers all capabilities at delivery

M

Rapid changes in technology anticipated –may change requirements

H Rapid changes in technology anticipated –may change requirements

H

Limited staff or budget available now

M

Source: IEEE/EIA Std. 12207.2-1997


Referen

ce C

opy

Not for

Dist

ributi

on

IEEE C

ompu

ter S

ociet

y

Presenter

Presentation Notes

Risk Items indicate reasons against adopting this life-cycle


Risk Analysis “for” Selecting a Life-Cycle Model

Once‐through (Waterfall) Incremental Evolutionary

Opportunity Item Opp Level



User prefers all capabilities at first delivery

M Early capability is needed

H Early capability is needed H

User prefers to phase out old system all at once

L 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


Referen

ce C

opy

Not for

Dist

ributi

on

IEEE C

ompu

ter S

ociet

y

Presenter

Presentation Notes

Risk Items indicate reasons against adopting this life-cycle


Discussion Question

What is the difference between iterative and incremental

software development?


Referen

ce C

opy

Not for

Dist

ributi

on

IEEE C

ompu

ter S

ociet

y


Iterative Versus Incremental

Incremental

Staging & scheduling strategy

Various parts of the system are

developed and built at different

times

Integrated as they are completed

versus integrating in one go

– Increments may be shipped

Helps improve the development

process

Works well with waterfall or

iterative approaches

Iterative

Rework scheduling strategy

Rework strategy to revisit and

improve parts of the product

Iteration is examined for

modification

– But not shipped

Helps improve the product

Works well with incremental

development

Reference: http://alistair.cockburn.us/index.php/Incremental_versus_iterative_development


Referen

ce C

opy

Not for

Dist

ributi

on

IEEE C

ompu

ter S

ociet

y


Discussion Question

What are the principal activities and elements of software

project planning?


Referen

ce C

opy

Not for

Dist

ributi

on

IEEE C

ompu

ter S

ociet

y



Project Planning





people)



process



Referen

ce C

opy

Not for

Dist

ributi

on

IEEE C

ompu

ter S

ociet

y


Determination of DeliverablesProject 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


Referen

ce C

opy

Not for

Dist

ributi

on

IEEE C

ompu

ter S

ociet

y


Make versus Buy Decisions

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


Referen

ce C

opy

Not for

Dist

ributi

on

IEEE C

ompu

ter S

ociet

y



Project Planning





people)



process



Referen

ce C

opy

Not for

Dist

ributi

on

IEEE C

ompu

ter S

ociet

y


Estimation of SizeGaffney 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

1. Count features internal inputs or files; external outputs, inquiries, or interfaces)

2. Weight features for level of complexity3. Adjust to account for 14 factors affecting

functional size

SizeMeasures

Size in SLOC

Size in function points

Reference: Thayer, Richard H. Software Engineering Project Management, 2nd ed. Los Alamitos, California: IEEE Computer Society, 2000


Referen

ce C

opy

Not for

Dist

ributi

on

IEEE C

ompu

ter S

ociet

y


Estimation of Effort

Effort estimation depend upon the project size estimation

– Combine size with productivity estimation to compute effort in

person‐months

ProductivityMeasures

SLOC/person‐month

Code statements /person‐month

Function points /person‐month


Referen

ce C

opy

Not for

Dist

ributi

on

IEEE C

ompu

ter S

ociet

y


Estimation of ScheduleProject 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)


Referen

ce C

opy

Not for

Dist

ributi

on

IEEE C

ompu

ter S

ociet

y


PERT/CPM Chart

Reference: http://www.rff.com/pert_hardware.htm


Referen

ce C

opy

Not for

Dist

ributi

on

IEEE C

ompu

ter S

ociet

y


Estimation of Schedule

Gantt chart method

– 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


Referen

ce C

opy

Not for

Dist

ributi

on

IEEE C

ompu

ter S

ociet

y


Gantt Chart

Reference: Gantt Chart Tutorial http://www.gantt-chart.biz/


Referen

ce C

opy

Not for

Dist

ributi

on

IEEE C

ompu

ter S

ociet

y


Discussion Question

When would you use a PERT chart or a GANTT chart? Explain.


Referen

ce C

opy

Not for

Dist

ributi

on

IEEE C

ompu

ter S

ociet

y


Estimation of Cost

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


Referen

ce C

opy

Not for

Dist

ributi

on

IEEE C

ompu

ter S

ociet

y


Discussion QuestionA 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.


Referen

ce C

opy

Not for

Dist

ributi

on

IEEE C

ompu

ter S

ociet

y

Presenter

Presentation Notes

According to the Mythical Man Month book written by Frederick Brooks, adding people to a late project only makes it later due to coordination efforts.



Project Planning





people)



process



Referen

ce C

opy

Not for

Dist

ributi

on

IEEE C

ompu

ter S

ociet

y


Resource AllocationResources 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


Referen

ce C

opy

Not for

Dist

ributi

on

IEEE C

ompu

ter S

ociet

y



Project Planning





people)



process



Referen

ce C

opy

Not for

Dist

ributi

on

IEEE C

ompu

ter S

ociet

y


Risk Management

All project management activities can be seen as risk management

– 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.


Referen

ce C

opy

Not for

Dist

ributi

on

IEEE C

ompu

ter S

ociet

y


Risk Management ProcessAs per IEEE/EIA Std. 12207.0‐1996

Plan and implementrisk management

Manage project risk profile

Perform risktreatment

Perform riskanalysis

Perform riskmonitoring

Review/update risk levels, assess effectivenessof risk treatment, search for new risks & sources

Identify conditions that cause risks andconsequences of those risks

Select, plan, monitor, and control actions to decrease risk exposure

Identify project’s risks as well as priority, status, threshold, and action requests for each risk

Risk management plan is negotiated & accepted by all stakeholders. Assign resources and responsibilities.

Evaluate riskmanagement process

Inform stakeholders about thequality of risk management


Referen

ce C

opy

Not for

Dist

ributi

on

IEEE C

ompu

ter S

ociet

y


Techniques to Manage Risks

Once risks are identified, they can be managed in the following ways:

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


Referen

ce C

opy

Not for

Dist

ributi

on

IEEE C

ompu

ter S

ociet

y


Discussion Question

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


Referen

ce C

opy

Not for

Dist

ributi

on

IEEE C

ompu

ter S

ociet

y



Project Planning





people)



process



Referen

ce C

opy

Not for

Dist

ributi

on

IEEE C

ompu

ter S

ociet

y


Quality ManagementProject 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”


Referen

ce C

opy

Not for

Dist

ributi

on

IEEE C

ompu

ter S

ociet

y



Project Planning





people)



process



Referen

ce C

opy

Not for

Dist

ributi

on

IEEE C

ompu

ter S

ociet

y


Plan ManagementProject 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


Referen

ce C

opy

Not for

Dist

ributi

on

IEEE C

ompu

ter S

ociet

y


Discussion Question

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. I, III, IV only

B. I, II, III only

C. I, II, IV only

D. I, II, III, IV

Answer: C


Referen

ce C

opy

Not for

Dist

ributi

on

IEEE C

ompu

ter S

ociet

y

Presenter

Presentation Notes

Rationale: Schedule, Budget, Staffing are all required in support of a Software Project Management Plan.


Content Area 3

Software Project Enactment

Referen

ce C

opy

Not for

Dist

ributi

on

IEEE C

ompu

ter S

ociet

y


Project Enactment

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

Content Area 3: Software Project Enactment

Referen

ce C

opy

Not for

Dist

ributi

on

IEEE C

ompu

ter S

ociet

y


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

Supplier Contract Management


Referen

ce C

opy

Not for

Dist

ributi

on

IEEE C

ompu

ter S

ociet

y


Monitoring Plan Adherence

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


Referen

ce C

opy

Not for

Dist

ributi

on

IEEE C

ompu

ter S

ociet

y


Control Process & ReportingTo 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 projectThe 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


Referen

ce C

opy

Not for

Dist

ributi

on

IEEE C

ompu

ter S

ociet

y


Content Area 4

Review and Evaluation

Referen

ce C

opy

Not for

Dist

ributi

on

IEEE C

ompu

ter S

ociet

y


Review and EvaluationSatisfied 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

Content Area 4: Review and Evaluation

Referen

ce C

opy

Not for

Dist

ributi

on

IEEE C

ompu

ter S

ociet

y


Content Area 5

Closure

Referen

ce C

opy

Not for

Dist

ributi

on

IEEE C

ompu

ter S

ociet

y


Software Project Closure

The following are project closure criteria:– 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

Content Area 5: Closure

Referen

ce C

opy

Not for

Dist

ributi

on

IEEE C

ompu

ter S

ociet

y


Content Area 6


Referen

ce C

opy

Not for

Dist

ributi

on

IEEE C

ompu

ter S

ociet

y



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

Content Area 6: Software Engineering Measurement

Referen

ce C

opy

Not for

Dist

ributi

on

IEEE C

ompu

ter S

ociet

y


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


Referen

ce C

opy

Not for

Dist

ributi

on

IEEE C

ompu

ter S

ociet

y


Plan the Measurement Process

Planning the measurement process includes the following activities:– 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


Referen

ce C

opy

Not for

Dist

ributi

on

IEEE C

ompu

ter S

ociet

y


Perform the Measurement ProcessThe 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


Referen

ce C

opy

Not for

Dist

ributi

on

IEEE C

ompu

ter S

ociet

y


Evaluate Measurement

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


Referen

ce C

opy

Not for

Dist

ributi

on

IEEE C

ompu

ter S

ociet

y


Content Area 7

Software Management Tools

Referen

ce C

opy

Not for

Dist

ributi

on

IEEE C

ompu

ter S

ociet

y


Software Management ToolsSoftware 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

Content Area 7: Software Management Tools

Referen

ce C

opy

Not for

Dist

ributi

on

IEEE C

ompu

ter S

ociet

y


Module – 3Chapter –Debrief

Software Engineering Management

End of Module 4

Referen

ce C

opy

Not for

Dist

ributi

on

IEEE C

ompu

ter S

ociet

y


Suggested Reading & References

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

Referen

ce C

opy

Not for

Dist

ributi

on

IEEE C

ompu

ter S

ociet

y

software engineering - ieee china

Documents