part 4

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 1

Supplementary Slides forSupplementary Slides for

Software Engineering:Software Engineering:A Practitioner's A Practitioner's Approach, 6/eApproach, 6/e

Part 4Part 4copyright © 1996, 2001, 2005

R.S. Pressman & Associates, Inc.

For University Use OnlyMay be reproduced ONLY for student use at the university level

when used in conjunction with Software Engineering: A Practitioner's Approach.Any other reproduction or use is expressly prohibited.

This presentation, slides, or hardcopy may NOT be used forshort courses, industry seminars, or consulting purposes.


Software Engineering: A Practitioner’s Software Engineering: A Practitioner’s Approach, 6/eApproach, 6/e

Chapter 21Chapter 21Project Management Project Management

ConceptsConcepts

copyright © 1996, 2001, 2005





The 4 The 4 P’sP’s

PeoplePeople — the most important element of a — the most important element of a successful projectsuccessful project

ProductProduct — the software to be built — the software to be built ProcessProcess — the set of framework activities and — the set of framework activities and

software engineering tasks to get the job software engineering tasks to get the job donedone

ProjectProject — all work required to make the — all work required to make the product a realityproduct a reality


StakeholdersStakeholders

Senior managersSenior managers who define the business issues that often who define the business issues that often have significant influence on the project.have significant influence on the project.

Project (technical) managersProject (technical) managers who must plan, motivate, who must plan, motivate, organize, and control the practitioners who do software organize, and control the practitioners who do software work.work.

PractitionersPractitioners who deliver the technical skills that are who deliver the technical skills that are necessary to engineer a product or application.necessary to engineer a product or application.

CustomersCustomers who specify the requirements for the software who specify the requirements for the software to be engineered and other stakeholders who have a to be engineered and other stakeholders who have a peripheral interest in the outcome.peripheral interest in the outcome.

End-usersEnd-users who interact with the software once it is who interact with the software once it is released for production use.released for production use.


Software TeamsSoftware Teams

How to lead?

How to organize?

How to motivate?

How to collaborate?

How to create good ideas?


Team LeaderTeam Leader

The MOI ModelThe MOI Model Motivation.Motivation. The ability to encourage (by “push or The ability to encourage (by “push or

pull”) technical people to produce to their best ability.pull”) technical people to produce to their best ability. Organization.Organization. The ability to mold existing processes The ability to mold existing processes

(or invent new ones) that will enable the initial concept (or invent new ones) that will enable the initial concept to be translated into a final product.to be translated into a final product.

Ideas or innovation.Ideas or innovation. The ability to encourage people The ability to encourage people to create and feel creative even when they must work to create and feel creative even when they must work within bounds established for a particular software within bounds established for a particular software product or application.product or application.


Software TeamsSoftware Teams

the difficulty of the problem to be solvedthe difficulty of the problem to be solved the size of the resultant program(s) in lines of code or the size of the resultant program(s) in lines of code or

function pointsfunction points the time that the team will stay together (team the time that the team will stay together (team

lifetime)lifetime) the degree to which the problem can be modularizedthe degree to which the problem can be modularized the required quality and reliability of the system to be the required quality and reliability of the system to be

builtbuilt the rigidity of the delivery datethe rigidity of the delivery date the degree of sociability (communication) required for the degree of sociability (communication) required for

the projectthe project

The following factors must be considered when selecting aThe following factors must be considered when selecting asoftware project team structure ...software project team structure ...


closed paradigmclosed paradigm—structures a team along a traditional hierarchy —structures a team along a traditional hierarchy of authorityof authority

random paradigmrandom paradigm—structures a team loosely and depends on —structures a team loosely and depends on individual initiative of the team members individual initiative of the team members

open paradigmopen paradigm—attempts to structure a team in a manner that —attempts to structure a team in a manner that achieves some of the controls associated with the closed achieves some of the controls associated with the closed paradigm but also much of the innovation that occurs when using paradigm but also much of the innovation that occurs when using the random paradigmthe random paradigm

synchronous paradigmsynchronous paradigm—relies on the natural —relies on the natural compartmentalization of a problem and organizes team members compartmentalization of a problem and organizes team members to work on pieces of the problem with little active communication to work on pieces of the problem with little active communication among themselvesamong themselves

Organizational ParadigmsOrganizational Paradigms

suggested by Constantine [CON93]


Avoid Team “Toxicity”Avoid Team “Toxicity”

A frenzied work atmosphere in which team members waste energy and lose focus on the objectives of the work to be performed.

High frustration caused by personal, business, or technological factors that cause friction among team members.

“Fragmented or poorly coordinated procedures” or a poorly defined or improperly chosen process model that becomes a roadblock to accomplishment.

Unclear definition of roles resulting in a lack of accountability and resultant finger-pointing.

“Continuous and repeated exposure to failure” that leads to a loss of confidence and a lowering of morale.


Agile TeamsAgile Teams

Team members must have trust in one another. Team members must have trust in one another. The distribution of skills must be appropriate to The distribution of skills must be appropriate to

the problem. the problem. Mavericks may have to be excluded from the Mavericks may have to be excluded from the

team, if team cohesiveness is to be maintained.team, if team cohesiveness is to be maintained. Team is “self-organizing”Team is “self-organizing”

An adaptive team structureAn adaptive team structure Uses elements of Constantine’s random, open, and Uses elements of Constantine’s random, open, and

synchronous paradigmssynchronous paradigms Significant autonomySignificant autonomy


Team Coordination & Team Coordination & CommunicationCommunication

Formal, impersonal approachesFormal, impersonal approaches include software engineering include software engineering documents and work products (including source code), technical documents and work products (including source code), technical memos, project milestones, schedules, and project control tools memos, project milestones, schedules, and project control tools (Chapter 23), change requests and related documentation, error (Chapter 23), change requests and related documentation, error tracking reports, and repository data (see Chapter 26). tracking reports, and repository data (see Chapter 26).

Formal, interpersonal proceduresFormal, interpersonal procedures focus on quality assurance activities focus on quality assurance activities (Chapter 25) applied to software engineering work products. These (Chapter 25) applied to software engineering work products. These include status review meetings and design and code inspections.include status review meetings and design and code inspections.

Informal, interpersonal proceduresInformal, interpersonal procedures include group meetings for include group meetings for information dissemination and problem solving and “collocation of information dissemination and problem solving and “collocation of requirements and development staff.” requirements and development staff.”

Electronic communicationElectronic communication encompasses electronic mail, electronic encompasses electronic mail, electronic bulletin boards, and by extension, video-based conferencing systems.bulletin boards, and by extension, video-based conferencing systems.

Interpersonal networkingInterpersonal networking includes informal discussions with team includes informal discussions with team members and those outside the project who may have experience or members and those outside the project who may have experience or insight that can assist team members.insight that can assist team members.


The Product ScopeThe Product Scope

ScopeScope Context. How does the software to be built fit into a larger

system, product, or business context and what constraints are imposed as a result of the context?

Information objectives. What customer-visible data objects (Chapter 8) are produced as output from the software? What data objects are required for input?

Function and performance. What function does the software perform to transform input data into output? Are any special performance characteristics to be addressed?

Software project scope must be unambiguous and understandable at the management and technical levels.


Problem DecompositionProblem Decomposition

Sometimes called partitioning or problem elaboration

Once scope is defined … It is decomposed into constituent functions It is decomposed into user-visible data objectsor It is decomposed into a set of problem classes

Decomposition process continues until all functions or problem classes have been defined


The Process

Once a process framework has been establishedOnce a process framework has been established Consider project characteristicsConsider project characteristics Determine the degree of rigor requiredDetermine the degree of rigor required Define a task set for each software engineering activityDefine a task set for each software engineering activity

Task set =Task set = Software engineering tasksSoftware engineering tasks Work productsWork products Quality assurance pointsQuality assurance points MilestonesMilestones


Melding the Problem and the Process


The Project

Projects get into trouble when …Projects get into trouble when … Software people don’t understand their customer’s needs.Software people don’t understand their customer’s needs. The product scope is poorly defined.The product scope is poorly defined. Changes are managed poorly.Changes are managed poorly. The chosen technology changes.The chosen technology changes. Business needs change [or are ill-defined].Business needs change [or are ill-defined]. Deadlines are unrealistic.Deadlines are unrealistic. Users are resistant.Users are resistant. Sponsorship is lost [or was never properly obtained].Sponsorship is lost [or was never properly obtained]. The project team lacks people with appropriate skills.The project team lacks people with appropriate skills. Managers [and practitioners] avoid best practices and lessons Managers [and practitioners] avoid best practices and lessons

learned.learned.


Common-Sense Approach to Projects

Start on the right foot.Start on the right foot. This is accomplished by working hard (very This is accomplished by working hard (very hard) to understand the problem that is to be solved and then hard) to understand the problem that is to be solved and then setting realistic objectives and expectations. setting realistic objectives and expectations.

Maintain momentum.Maintain momentum. The The project manager must provide incentives project manager must provide incentives to keep turnover of personnel to an absolute minimum, the team to keep turnover of personnel to an absolute minimum, the team should emphasize quality in every task it performs, and senior should emphasize quality in every task it performs, and senior management should do everything possible to stay out of the team’s management should do everything possible to stay out of the team’s way.way.

Track progress.Track progress. For a software project, progress is tracked as work For a software project, progress is tracked as work products (e.g., models, source code, sets of test cases) are products (e.g., models, source code, sets of test cases) are produced and approved (using formal technical reviews) as part of produced and approved (using formal technical reviews) as part of a quality assurance activity. a quality assurance activity.

Make smart decisions.Make smart decisions. In essence, the decisions of the project In essence, the decisions of the project manager and the software team should be to “keep it simple.” manager and the software team should be to “keep it simple.”

Conduct a postmortem analysis.Conduct a postmortem analysis. Establish a consistent mechanism Establish a consistent mechanism for extracting lessons learned for each project. for extracting lessons learned for each project.


To Get to the Essence of a To Get to the Essence of a ProjectProject

Why is the system being developed?Why is the system being developed? What will be done? What will be done? When will it be accomplished?When will it be accomplished? Who is responsible?Who is responsible? Where are they organizationally located?Where are they organizationally located? How will the job be done technically and How will the job be done technically and

managerially?managerially? How much of each resource (e.g., How much of each resource (e.g.,

people, software, tools, database) will be people, software, tools, database) will be needed?needed? Barry Boehm


Critical PracticesCritical Practices

Formal risk managementFormal risk management Empirical cost and schedule estimationEmpirical cost and schedule estimation Metrics-based project managementMetrics-based project management Earned value trackingEarned value tracking Defect tracking against quality targetsDefect tracking against quality targets People aware project managementPeople aware project management



Chapter 22Chapter 22Process and Project Process and Project

MetricsMetrics

copyright © 1996, 2001, 2005





A Good Manager A Good Manager MeasuresMeasures

measurementmeasurement

What do weWhat do weuse as ause as abasis?basis? • • size?size? • • function?function?

project metricsproject metrics

process metricsprocess metricsprocessprocess

productproduct

product metricsproduct metrics


Why Do We Measure?Why Do We Measure?

assess the status of an ongoing project track potential risks uncover problem areas before they go

“critical,” adjust work flow or tasks, evaluate the project team’s ability to

control quality of software work products.


Process Measurement We measure the efficacy of a software process indirectly. We measure the efficacy of a software process indirectly.

That is, we derive a set of metrics based on the outcomes that That is, we derive a set of metrics based on the outcomes that can be derived from the process. can be derived from the process.

Outcomes include Outcomes include measures of errors uncovered before release of the softwaremeasures of errors uncovered before release of the software defects delivered to and reported by end-usersdefects delivered to and reported by end-users work products delivered (productivity)work products delivered (productivity) human effort expendedhuman effort expended calendar time expendedcalendar time expended schedule conformanceschedule conformance other measures.other measures.

We also derive process metrics by measuring the We also derive process metrics by measuring the characteristics of specific software engineering tasks. characteristics of specific software engineering tasks.


Process Metrics Guidelines

Use common sense and organizational sensitivity when Use common sense and organizational sensitivity when interpreting metrics data.interpreting metrics data.

Provide regular feedback to the individuals and teams who Provide regular feedback to the individuals and teams who collect measures and metrics.collect measures and metrics.

Don’t use metrics to appraise individuals.Don’t use metrics to appraise individuals. Work with practitioners and teams to set clear goals and Work with practitioners and teams to set clear goals and

metrics that will be used to achieve them.metrics that will be used to achieve them. Never use metrics to threaten individuals or teams.Never use metrics to threaten individuals or teams. Metrics data that indicate a problem area should not be Metrics data that indicate a problem area should not be

considered “negative.” These data are merely an indicator considered “negative.” These data are merely an indicator for process improvement.for process improvement.

Don’t obsess on a single metric to the exclusion of other Don’t obsess on a single metric to the exclusion of other important metrics.important metrics.


Software Process Improvement

SPI

Process model

Improvement goals

Process metrics

Process improvementrecommendations


Process MetricsProcess Metrics

Quality-relatedQuality-related focus on quality of work products and deliverablesfocus on quality of work products and deliverables

Productivity-relatedProductivity-related Production of work-products related to effort expendedProduction of work-products related to effort expended

Statistical SQA dataStatistical SQA data error categorization & analysiserror categorization & analysis

Defect removal efficiencyDefect removal efficiency propagation of errors from process activity to activitypropagation of errors from process activity to activity

Reuse dataReuse data The number of components produced and their degree The number of components produced and their degree

of reusabilityof reusability


Project Metrics

used to minimize the development schedule by making the used to minimize the development schedule by making the adjustments necessary to avoid delays and mitigate adjustments necessary to avoid delays and mitigate potential problems and riskspotential problems and risks

used to assess product quality on an ongoing basis and, used to assess product quality on an ongoing basis and, when necessary, modify the technical approach to improve when necessary, modify the technical approach to improve quality.quality.

every project should measure:every project should measure: inputsinputs—measures of the resources (e.g., people, tools) —measures of the resources (e.g., people, tools)

required to do the work.required to do the work. outputsoutputs—measures of the deliverables or work products —measures of the deliverables or work products

created during the software engineering process.created during the software engineering process. resultsresults—measures that indicate the effectiveness of the —measures that indicate the effectiveness of the

deliverables.deliverables.


Typical Project MetricsTypical Project Metrics

Effort/time per software engineering taskEffort/time per software engineering task Errors uncovered per review hourErrors uncovered per review hour Scheduled vs. actual milestone datesScheduled vs. actual milestone dates Changes (number) and their characteristicsChanges (number) and their characteristics Distribution of effort on software Distribution of effort on software

engineering tasksengineering tasks


Metrics GuidelinesMetrics Guidelines Use common sense and organizational sensitivity when Use common sense and organizational sensitivity when

interpreting metrics data.interpreting metrics data. Provide regular feedback to the individuals and teams who have Provide regular feedback to the individuals and teams who have

worked to collect measures and metrics.worked to collect measures and metrics. Don’t use metrics to appraise individuals.Don’t use metrics to appraise individuals. Work with practitioners and teams to set clear goals and Work with practitioners and teams to set clear goals and

metrics that will be used to achieve them.metrics that will be used to achieve them. Never use metrics to threaten individuals or teams.Never use metrics to threaten individuals or teams. Metrics data that indicate a problem area should not be Metrics data that indicate a problem area should not be

considered “negative.” These data are merely an indicator for considered “negative.” These data are merely an indicator for process improvement.process improvement.

Don’t obsess on a single metric to the exclusion of other Don’t obsess on a single metric to the exclusion of other important metrics.important metrics.


Typical Size-Oriented Typical Size-Oriented MetricsMetrics

errors per KLOC (thousand lines of code)errors per KLOC (thousand lines of code) defects per KLOCdefects per KLOC $ per LOC$ per LOC pages of documentation per KLOCpages of documentation per KLOC errors per person-montherrors per person-month Errors per review hourErrors per review hour LOC per person-monthLOC per person-month $ per page of documentation$ per page of documentation


Typical Function-Oriented Typical Function-Oriented MetricsMetrics

errors per FP (thousand lines of code)errors per FP (thousand lines of code) defects per FPdefects per FP $ per FP$ per FP pages of documentation per FPpages of documentation per FP FP per person-monthFP per person-month


Comparing LOC and FPComparing LOC and FP

Programming LOC per Function point

Language avg. median low high

Ada 154 - 104 205Assembler 337 315 91 694C 162 109 33 704C++ 66 53 29 178

COBOL 77 77 14 400Java 63 53 77 -JavaScript 58 63 42 75Perl 60 - - -PL/1 78 67 22 263Powerbuilder 32 31 11 105SAS 40 41 33 49Smalltalk 26 19 10 55SQL 40 37 7 110Visual Basic 47 42 16 158

Representative values developed by QSM


Why Opt for FP?Why Opt for FP?

Programming language independentProgramming language independent Used readily countable characteristics that are Used readily countable characteristics that are

determined early in the software processdetermined early in the software process Does not “penalize” inventive (short) Does not “penalize” inventive (short)

implementations that use fewer LOC that other implementations that use fewer LOC that other more clumsy versionsmore clumsy versions

Makes it easier to measure the impact of Makes it easier to measure the impact of reusable componentsreusable components


Object-Oriented MetricsObject-Oriented Metrics

Number of Number of scenario scriptsscenario scripts (use-cases) (use-cases) Number of Number of support classessupport classes ( (required to

implement the system but are not immediately related to the problem domain)

Average number of support classes per key class (analysis class)

Number of subsystems (an aggregation of classes that support a function that is visible to the end-user of a system)


WebE Project MetricsWebE Project Metrics

Number of static Web pages (the end-user has no control over the content displayed on the page)

Number of dynamic Web pages (end-user actions result in customized content displayed on the page)

Number of internal page links (internal page links are pointers that provide a hyperlink to some other Web page within the WebApp)

Number of persistent data objects Number of external systems interfaced Number of static content objects Number of dynamic content objects Number of executable functions


Measuring QualityMeasuring Quality

CorrectnessCorrectness — the degree to which a program — the degree to which a program operates according to specificationoperates according to specification

MaintainabilityMaintainability—the degree to which a program —the degree to which a program is amenable to changeis amenable to change

IntegrityIntegrity—the degree to which a program is —the degree to which a program is impervious to outside attackimpervious to outside attack

UsabilityUsability—the degree to which a program is easy —the degree to which a program is easy to useto use


Defect Removal EfficiencyDefect Removal Efficiency

DRE = E /(E + D)

E is the number of errors found before delivery of the software to the end-user D is the number of defects found after delivery.


Metrics for Small Metrics for Small OrganizationsOrganizations

time (hours or days) elapsed from the time a request is made until evaluation is complete, tqueue.

effort (person-hours) to perform the evaluation, Weval. time (hours or days) elapsed from completion of evaluation

to assignment of change order to personnel, teval.

effort (person-hours) required to make the change, Wchange.

time required (hours or days) to make the change, tchange.

errors uncovered during work to make change, Echange. defects uncovered after change is released to the customer

base, Dchange.


Establishing a Metrics Establishing a Metrics ProgramProgram

Identify your business goals. Identify what you want to know or learn. Identify your subgoals. Identify the entities and attributes related to your subgoals. Formalize your measurement goals. Identify quantifiable questions and the related indicators that

you will use to help you achieve your measurement goals. Identify the data elements that you will collect to construct the

indicators that help answer your questions. Define the measures to be used, and make these definitions

operational. Identify the actions that you will take to implement the

measures. Prepare a plan for implementing the measures.



Chapter 23Chapter 23Estimation for Software Estimation for Software

ProjectsProjectscopyright © 1996, 2001, 2005





Software Project Software Project PlanningPlanning

The overall goal of project planning is to The overall goal of project planning is to establish a pragmatic strategy for establish a pragmatic strategy for controlling, tracking, and monitoring a controlling, tracking, and monitoring a complex technical project.complex technical project.

Why?Why?

So the end result gets done on time, with So the end result gets done on time, with quality!quality!


Project Planning Task Set-IProject Planning Task Set-I

Establish project scopeEstablish project scope Determine feasibilityDetermine feasibility Analyze risksAnalyze risks

Risk analysis is considered in detail in Chapter 25.Risk analysis is considered in detail in Chapter 25. Define required resourcesDefine required resources

Determine require human resourcesDetermine require human resources Define reusable software resourcesDefine reusable software resources Identify environmental resourcesIdentify environmental resources


Project Planning Task Set-IIProject Planning Task Set-II

Estimate cost and effortEstimate cost and effort Decompose the problemDecompose the problem Develop two or more estimates using size, function Develop two or more estimates using size, function

points, process tasks or use-casespoints, process tasks or use-cases Reconcile the estimatesReconcile the estimates

Develop a project scheduleDevelop a project schedule Scheduling is considered in detail in Chapter 24.Scheduling is considered in detail in Chapter 24.

Establish a meaningful task setEstablish a meaningful task set Define a task networkDefine a task network Use scheduling tools to develop a timeline chartUse scheduling tools to develop a timeline chart Define schedule tracking mechanismsDefine schedule tracking mechanisms


EstimationEstimation

Estimation of resources, cost, and schedule for a Estimation of resources, cost, and schedule for a software engineering effort requires software engineering effort requires experienceexperience access to good historical information (metricsaccess to good historical information (metrics the courage to commit to quantitative predictions when the courage to commit to quantitative predictions when

qualitative information is all that existsqualitative information is all that exists Estimation carries inherent risk and this risk Estimation carries inherent risk and this risk

leads to uncertaintyleads to uncertainty


Write it Down!Write it Down!

SoftwareSoftwareProjectProject

PlanPlan

Project ScopeProject ScopeEstimatesEstimatesRisksRisksScheduleScheduleControl strategyControl strategy


To Understand Scope ...To Understand Scope ...

Understand the customers needsUnderstand the customers needs understand the business contextunderstand the business context understand the project boundariesunderstand the project boundaries understand the customer’s understand the customer’s

motivationmotivation understand the likely paths for understand the likely paths for

changechange understand that ...understand that ...Even when you understand,Even when you understand,

nothing is guaranteed!nothing is guaranteed!


What is Scope?What is Scope?

Software scopeSoftware scope describes describes the functions and features that are to be delivered to the functions and features that are to be delivered to

end-usersend-users the data that are input and outputthe data that are input and output the “content” that is presented to users as a the “content” that is presented to users as a

consequence of using the softwareconsequence of using the software the performance, constraints, interfaces, and reliability the performance, constraints, interfaces, and reliability

that that boundbound the system. the system. Scope is defined using one of two techniques:Scope is defined using one of two techniques:

A narrative description of software scope is developed A narrative description of software scope is developed after communication with all stakeholders.after communication with all stakeholders.

A set of use-cases is developed by end-users.A set of use-cases is developed by end-users.


ResourcesResources

project

people

skills

number

location

reusablesoftware

OTScomponents

full-experiencecomponents

newcomponents

part.-experiencecomponents

environment

hardware

softwaretools

networkresources


Project EstimationProject Estimation

Project scope must be understoodProject scope must be understood Elaboration (decomposition) is Elaboration (decomposition) is

necessarynecessary Historical metrics are very Historical metrics are very

helpfulhelpful At least two different techniques At least two different techniques

should be usedshould be used Uncertainty is inherent in the Uncertainty is inherent in the

processprocess


Estimation TechniquesEstimation Techniques Past (similar) project experiencePast (similar) project experience Conventional estimation techniquesConventional estimation techniques

task breakdown and effort estimatestask breakdown and effort estimates size (e.g., FP) estimatessize (e.g., FP) estimates

Empirical modelsEmpirical models Automated toolsAutomated tools


Estimation AccuracyEstimation Accuracy

Predicated on …Predicated on … the degree to which the planner has properly estimated

the size of the product to be built the ability to translate the size estimate into human

effort, calendar time, and dollars (a function of the availability of reliable software metrics from past projects)

the degree to which the project plan reflects the abilities of the software team

the stability of product requirements and the environment that supports the software engineering effort.


Functional DecompositionFunctional Decomposition

functional functional decompositiondecomposition

StatementStatementofof

ScopeScope Perform a Perform a Grammatical “parse”Grammatical “parse”


Conventional Methods:Conventional Methods:LOC/FP ApproachLOC/FP Approach

compute LOC/FP using estimates of compute LOC/FP using estimates of information domain valuesinformation domain values

use historical data to build estimates for use historical data to build estimates for the projectthe project


Example: LOC Example: LOC ApproachApproach

Average productivity for systems of this type = 620 Average productivity for systems of this type = 620 LOC/pm. LOC/pm.

Burdened labor rate =$8000 per month, the cost per Burdened labor rate =$8000 per month, the cost per line of code is approximately $13. line of code is approximately $13.

Based on the LOC estimate and the historical Based on the LOC estimate and the historical productivity data, the total estimated project cost is productivity data, the total estimated project cost is $431,000 and the estimated effort is 54 person-$431,000 and the estimated effort is 54 person-months.months.


Example: FP ApproachExample: FP Approach

The estimated number of FP is derived:The estimated number of FP is derived:FPFPestimatedestimated = count-total = count-total 33 [0.65 + 0.01 [0.65 + 0.01 33 SS (F (Fii)])]

FPFPestimatedestimated = 375 = 375

organizational average productivity = 6.5 FP/pm. organizational average productivity = 6.5 FP/pm. burdened labor rate = $8000 per month, the cost per FP is burdened labor rate = $8000 per month, the cost per FP is approximately $1230. approximately $1230. Based on the FP estimate and the historical productivity data, Based on the FP estimate and the historical productivity data, the total the total estimated project cost is $461,000 and the estimated effort is 58 person-estimated project cost is $461,000 and the estimated effort is 58 person-monthsmonths..


Process-Based EstimationProcess-Based EstimationObtained from “process framework”Obtained from “process framework”

applicationapplicationfunctionsfunctions

framework activitiesframework activities

Effort required to Effort required to accomplishaccomplisheach framework each framework activity for each activity for each application functionapplication function


Process-Based Estimation Process-Based Estimation ExampleExample

A ctivity

T ask

F u n ctio n

U IC F

2D GA

3D GA

D SM

PC F

C GD F

D AM

T o tals

% effo rt

CC P la nningRis k

Ana ly s is E ngine e ringCons truc tion

Re le a s e T o talsCE

analy s is des ign c ode tes t

0.25 0.25 0.25 3.50 20.50 4.50 16.50 46.00

1% 1% 1% 8% 45% 10% 36%

C C = cus tom er com m unicat ion C E = cus tom er evaluat ion

0.50

0.750.50

0.50

0.500.25

2.50

4.004.00

3.00

3.002.00

0.40

0.601.00

1.00

0.750.50

5.002.00

3.00

1.50

1.501.50

8.40

7.358.50

6.00

5.754.25

0.50 2.00 0.50 2.00 5.00

n/an/a

n/a

n/a

n/an/a

n/a

Based on an average burdened labor rate of $8,000 per Based on an average burdened labor rate of $8,000 per month, the total estimated project cost is $368,000 and the month, the total estimated project cost is $368,000 and the estimated effort is 46 person-months.estimated effort is 46 person-months.


Tool-Based EstimationTool-Based Estimation

project characteristicsproject characteristics

calibration factorscalibration factors

LOC/FP dataLOC/FP data


Estimation with Use-CasesEstimation with Use-Cases

use cases scenarios pages scenarios pages LOC LOC estimatee subsystem 6 10 6 12 5 560 3,366subsystem group 10 20 8 16 8 3100 31,233e subsystem group 5 6 5 10 6 1650 7,970

stimate 42,568

User interface subsystemEngineering subsystem groupInfrastructure subsystem group

Total LOC estimate

Using 620 LOC/pm as the average productivity for systems Using 620 LOC/pm as the average productivity for systems of this type and a burdened labor rate of $8000 per month, of this type and a burdened labor rate of $8000 per month, the cost per line of code is approximately $13. Based on the the cost per line of code is approximately $13. Based on the use-case estimate and the historical productivity data, the use-case estimate and the historical productivity data, the total estimated project cost is $552,000 and the estimated total estimated project cost is $552,000 and the estimated effort is 68 person-months.effort is 68 person-months.


Empirical Estimation Empirical Estimation ModelsModels

General form:General form:

effort = tuning coefficient * sizeeffort = tuning coefficient * sizeexponentexponent

usually derivedusually derivedas person-monthsas person-monthsof effort requiredof effort required

either a constant oreither a constant ora number derived based a number derived based on complexity of projecton complexity of project

usually LOC butusually LOC butmay also bemay also befunction pointfunction point

empiricallyempiricallyderivedderived


COCOMO-IICOCOMO-II

COCOMO II is actually a hierarchy of estimation COCOMO II is actually a hierarchy of estimation models that address the following areas:models that address the following areas:

Application composition model.Application composition model. Used during the early Used during the early stages of software engineering, when prototyping of user stages of software engineering, when prototyping of user interfaces, consideration of software and system interfaces, consideration of software and system interaction, assessment of performance, and evaluation of interaction, assessment of performance, and evaluation of technology maturity are paramount.technology maturity are paramount.

Early design stage model.Early design stage model. Used once requirements have Used once requirements have been stabilized and basic software architecture has been been stabilized and basic software architecture has been established.established.

Post-architecture-stage model.Post-architecture-stage model. Used during the Used during the construction of the software.construction of the software.


The Software EquationThe Software EquationA dynamic multivariable modelA dynamic multivariable model

E = [LOC x BE = [LOC x B0.3330.333/P]/P]33 x (1/t x (1/t44))

where where E = effort in person-months or person-yearsE = effort in person-months or person-yearst = project duration in months or yearst = project duration in months or yearsB = “special skills factor”B = “special skills factor”P = “productivity parameter”P = “productivity parameter”


Estimation for OO Projects-IEstimation for OO Projects-I Develop estimates using effort decomposition, FP analysis, Develop estimates using effort decomposition, FP analysis,

and any other method that is applicable for conventional and any other method that is applicable for conventional applications.applications.

Using object-oriented analysis modeling (Chapter 8), Using object-oriented analysis modeling (Chapter 8), develop use-cases and determine a count. develop use-cases and determine a count.

From the analysis model, determine the number of key From the analysis model, determine the number of key classes (called analysis classes in Chapter 8).classes (called analysis classes in Chapter 8).

Categorize the type of interface for the application and Categorize the type of interface for the application and develop a multiplier for support classes:develop a multiplier for support classes: Interface typeInterface type MultiplierMultiplier No GUINo GUI 2.0 2.0 Text-based user interfaceText-based user interface 2.25 2.25 GUIGUI 2.5 2.5 Complex GUIComplex GUI 3.0 3.0


Estimation for OO Projects-IIEstimation for OO Projects-II

Multiply the number of key classes (step 3) by the Multiply the number of key classes (step 3) by the multiplier to obtain an estimate for the number of support multiplier to obtain an estimate for the number of support classes.classes.

Multiply the total number of classes (key + support) by the Multiply the total number of classes (key + support) by the average number of work-units per class. Lorenz and Kidd average number of work-units per class. Lorenz and Kidd suggest 15 to 20 person-days per class.suggest 15 to 20 person-days per class.

Cross check the class-based estimate by multiplying the Cross check the class-based estimate by multiplying the average number of work-units per use-caseaverage number of work-units per use-case


Estimation for Agile ProjectsEstimation for Agile Projects Each user scenario (a mini-use-case) is considered separately for Each user scenario (a mini-use-case) is considered separately for

estimation purposes.estimation purposes. The scenario is decomposed into the set of software engineering The scenario is decomposed into the set of software engineering

tasks that will be required to develop it.tasks that will be required to develop it. Each task is estimated separately. Note: estimation can be based Each task is estimated separately. Note: estimation can be based

on historical data, an empirical model, or “experience.”on historical data, an empirical model, or “experience.” Alternatively, the ‘volume’ of the scenario can be estimated in LOC, Alternatively, the ‘volume’ of the scenario can be estimated in LOC,

FP or some other volume-oriented measure (e.g., use-case count).FP or some other volume-oriented measure (e.g., use-case count). Estimates for each task are summed to create an estimate for the Estimates for each task are summed to create an estimate for the

scenario.scenario. Alternatively, the volume estimate for the scenario is translated into Alternatively, the volume estimate for the scenario is translated into

effort using historical data.effort using historical data. The effort estimates for all scenarios that are to be implemented The effort estimates for all scenarios that are to be implemented

for a given software increment are summed to develop the effort for a given software increment are summed to develop the effort estimate for the increment.estimate for the increment.


The Make-Buy DecisionThe Make-Buy Decision

system Xsystem Xreusereuse

simple (0.30)simple (0.30)

difficult (0.70)difficult (0.70)

minorminor changeschanges

(0.40)(0.40)

majormajorchangeschanges

(0.60)(0.60)

simple (0.20)simple (0.20)

complex (0.80)complex (0.80)

majormajor changeschanges (0.30)(0.30)

minorminor changeschanges

(0.70)(0.70)

$380,000$380,000

$450,000$450,000

$275,000$275,000

$310,000$310,000

$490,000$490,000

$210,000$210,000

$400,000$400,000

buybuy

contractcontract

without changes (0.60)without changes (0.60)

with changes (0.40)with changes (0.40)

$350,000$350,000

$500,000$500,000

buildbuild


Computing Expected CostComputing Expected Cost

(path probability) x (estimated path cost) (path probability) x (estimated path cost) ii ii

For example, the expected cost to build is:For example, the expected cost to build is:

expected cost = 0.30 ($380K) + 0.70 ($450K) expected cost = 0.30 ($380K) + 0.70 ($450K)

similarly,similarly,

expected cost = expected cost = $382K$382Kexpected cost = expected cost = $267K$267Kexpected cost = expected cost = $410K$410K

buildbuild

reureusesebubuyyconcontrtr

expected cost =expected cost =

= $429 K= $429 K



Chapter 24Chapter 24Project Scheduling and Project Scheduling and

TrackingTrackingcopyright © 1996, 2001, 2005





Why Are Projects Late?Why Are Projects Late? an unrealistic deadline established by someone outside the an unrealistic deadline established by someone outside the

software development groupsoftware development group changing customer requirements that are not reflected in changing customer requirements that are not reflected in

schedule changes;schedule changes; an honest underestimate of the amount of effort and/or the an honest underestimate of the amount of effort and/or the

number of resources that will be required to do the job;number of resources that will be required to do the job; predictable and/or unpredictable risks that were not predictable and/or unpredictable risks that were not

considered when the project commenced;considered when the project commenced; technical difficulties that could not have been foreseen in technical difficulties that could not have been foreseen in

advance;advance; human difficulties that could not have been foreseen in human difficulties that could not have been foreseen in

advance;advance; miscommunication among project staff that results in delays;miscommunication among project staff that results in delays; a failure by project management to recognize that the project a failure by project management to recognize that the project

is falling behind schedule and a lack of action to correct the is falling behind schedule and a lack of action to correct the problemproblem


Scheduling PrinciplesScheduling Principles

compartmentalizationcompartmentalization—define distinct tasks—define distinct tasks interdependencyinterdependency—indicate task —indicate task

interrelationship interrelationship effort validationeffort validation—be sure resources are —be sure resources are

availableavailable defined responsibilitiesdefined responsibilities—people must be —people must be

assignedassigned defined outcomesdefined outcomes—each task must have an —each task must have an

outputoutput defined milestonesdefined milestones—review for quality—review for quality


Effort and Delivery TimeEffort and Delivery Time

EffortCost

Impossibleregion

td

Ed

Tmin = 0.75Td

to

Eo

Ea = m (td4/ ta

4)

development time

Ea = effort in person-months

td = nominal delivery time for schedule

to = optimal development time (in terms of cost)

ta = actual delivery time desired


Effort AllocationEffort Allocation

40-50%40-50%

30-40%30-40%

““front end” activitiesfront end” activities customer communicationcustomer communication analysisanalysis designdesign review and modificationreview and modification

construction activitiesconstruction activities coding or code coding or code

generationgeneration testing and installationtesting and installation

unit, integrationunit, integration white-box, black boxwhite-box, black box regression regression

15-20%15-20%


Defining Task SetsDefining Task Sets

determine type of projectdetermine type of project assess the degree of rigor requiredassess the degree of rigor required identify adaptation criteriaidentify adaptation criteria select appropriate software engineering select appropriate software engineering

taskstasks


Task Set Task Set RefinementRefinement

1.1 Concept scoping determines the overall scope of the project.Task definition: Task 1.1 Concept Scoping

1.1.1 Identify need, benefits and potential customers;

1.1.2 Define desired output/control and input events that drive the application;

Begin Task 1.1.2

1.1.2.1 FTR: Review written description of need FTR indicates that a formal technical review (Chapter 26) is to be conducted.

1.1.2.2 Derive a list of customer visible outputs/inputs

1.1.2.3 FTR: Review outputs/inputs with customer and revise as required;

endtask Task 1.1.2

1.1.3 Define the functionality/behavior for each major function;

Begin Task 1.1.3

1.1.3.1 FTR: Review output and input data objects derived in task 1.1.2;

1.1.3.2 Derive a model of functions/behaviors;

1.1.3.3 FTR: Review functions/behaviors with customer and revise as required;

endtask Task 1.1.3

1.1.4 Isolate those elements of the technology to be implemented in software;

1.1.5 Research availability of existing software;

1.1.6 Define technical feasibility;

1.1.7 Make quick estimate of size;

1.1.8 Create a Scope Definition;endTask definition: Task 1.1

is refined to


Define a Task Define a Task NetworkNetwork

I.1Conceptscoping

I.3aTech. Risk

Assessment

I.3bTech. Risk

Assessment

I.3cTech. Risk

Assessment

Three I.3 tasks areapplied in parallel to3 different conceptfunctions

Three I.3 tasks areapplied in parallel to3 different conceptfunctions

I.4Proof ofConcept

I.5aConcept

Implement.

I.5bConcept

Implement.

I.5cConcept

Implement.

I.2Conceptplanning

I.6CustomerReaction

Integratea, b, c


Timeline ChartsTimeline Charts

Tasks Week 1 Week 2 Week 3 Week 4 Week n

Task 1Task 2Task 3Task 4Task 5Task 6Task 7Task 8Task 9Task 10Task 11Task 12


Use Automated Use Automated Tools toTools to

Derive a Timeline Derive a Timeline ChartChart

I.1.1 Identify need and benefits Meet with customers Identify needs and project constraints Establish product statement Milestone: product statement definedI.1.2 Define desired output/control/input (OCI) Scope keyboard functions Scope voice input functions Scope modes of interaction Scope document diagnostics Scope other WP functions Document OCI FTR: Review OCI with customer Revise OCI as required; Milestone; OCI definedI.1.3 Define the functionality/behavior Define keyboard functions Define voice input functions Decribe modes of interaction Decribe spell/grammar check Decribe other WP functions FTR: Review OCI definition with customer Revise as required Milestone: OCI defintition completeI.1.4 Isolate software elements Milestone: Software elements definedI.1.5 Research availability of existing software Reseach text editiong components Research voice input components Research file management components Research Spell/Grammar check components Milestone: Reusable components identifiedI.1.6 Define technical feasibility Evaluate voice input Evaluate grammar checking Milestone: Technical feasibility assessedI.1.7 Make quick estimate of sizeI.1.8 Create a Scope Definition Review scope document with customer Revise document as required Milestone: Scope document complete

week 1 week 2 week 3 week 4Work tasks week 5


Schedule TrackingSchedule Tracking conduct periodic project status meetings in which each conduct periodic project status meetings in which each

team member reports progress and problems.team member reports progress and problems. evaluate the results of all reviews conducted throughout evaluate the results of all reviews conducted throughout

the software engineering process.the software engineering process. determine whether formal project milestones (the determine whether formal project milestones (the

diamonds shown in Figure 24.3) have been accomplished diamonds shown in Figure 24.3) have been accomplished by the scheduled date.by the scheduled date.

compare actual start-date to planned start-date for each compare actual start-date to planned start-date for each project task listed in the resource table (Figure 24.4).project task listed in the resource table (Figure 24.4).

meet informally with practitioners to obtain their meet informally with practitioners to obtain their subjective assessment of progress to date and problems subjective assessment of progress to date and problems on the horizon.on the horizon.

use earned value analysis (Section 24.6) to assess progress quantitatively.


Progress on an OO Project-IProgress on an OO Project-I

Technical milestone: OO analysis completed Technical milestone: OO analysis completed All classes and the class hierarchy have been defined and reviewed.All classes and the class hierarchy have been defined and reviewed. Class attributes and operations associated with a class have been Class attributes and operations associated with a class have been

defined and reviewed.defined and reviewed. Class relationships (Chapter 8) have been established and reviewed.Class relationships (Chapter 8) have been established and reviewed. A behavioral model (Chapter 8) has been created and reviewed.A behavioral model (Chapter 8) has been created and reviewed. Reusable classes have been noted.Reusable classes have been noted.

Technical milestone: OO design completedTechnical milestone: OO design completed The set of subsystems (Chapter 9) has been defined and reviewed.The set of subsystems (Chapter 9) has been defined and reviewed. Classes are allocated to subsystems and reviewed.Classes are allocated to subsystems and reviewed. Task allocation has been established and reviewed.Task allocation has been established and reviewed. Responsibilities and collaborations (Chapter 9) have been identified.Responsibilities and collaborations (Chapter 9) have been identified. Attributes and operations have been designed and reviewed.Attributes and operations have been designed and reviewed. The communication model has been created and reviewed.The communication model has been created and reviewed.


Progress on an OO Project-IIProgress on an OO Project-II

Technical milestone: OO programming completedTechnical milestone: OO programming completed Each new class has been implemented in code from the design Each new class has been implemented in code from the design

model.model. Extracted classes (from a reuse library) have been implemented.Extracted classes (from a reuse library) have been implemented. Prototype or increment has been built.Prototype or increment has been built.

Technical milestone: OO testingTechnical milestone: OO testing The correctness and completeness of OO analysis and design The correctness and completeness of OO analysis and design

models has been reviewed.models has been reviewed. A class-responsibility-collaboration network (Chapter 8) has been A class-responsibility-collaboration network (Chapter 8) has been

developed and reviewed.developed and reviewed. Test cases are designed and class-level tests (Chapter 14) have Test cases are designed and class-level tests (Chapter 14) have

been conducted for each class.been conducted for each class. Test cases are designed and cluster testing (Chapter 14) is Test cases are designed and cluster testing (Chapter 14) is

completed and the classes are integrated.completed and the classes are integrated. System level tests have been completed.System level tests have been completed.


Earned Value Analysis (EVA)Earned Value Analysis (EVA)

Earned value is a measure of progress enables us to assess the “percent of completeness” of a

project using quantitative analysis rather than rely on a gut feeling

“provides accurate and reliable readings of performance from as early as 15 percent into the project.” [FLE98]


Computing Earned Value-IComputing Earned Value-I

The The budgeted cost of work scheduledbudgeted cost of work scheduled (BCWS) is (BCWS) is determined for each work task represented in determined for each work task represented in the schedule. the schedule. BCWSBCWSii is the effort planned for work task is the effort planned for work task i.i. To determine progress at a given point along the To determine progress at a given point along the

project schedule, the value of BCWS is the sum of the project schedule, the value of BCWS is the sum of the BCWSBCWSii values for all work tasks that should have been values for all work tasks that should have been completed by that point in time on the project schedule. completed by that point in time on the project schedule.

The BCWS values for all work tasks are summed The BCWS values for all work tasks are summed to derive the to derive the budget at completion,budget at completion, BAC. Hence, BAC. Hence,

BAC = BAC = ∑∑ (BCWS (BCWSkk) for all tasks ) for all tasks kk


Computing Earned Value-IIComputing Earned Value-II Next, the value for Next, the value for budgeted cost of work performedbudgeted cost of work performed (BCWP) (BCWP)

is computed. is computed. The value for BCWP is the sum of the BCWS values for all work The value for BCWP is the sum of the BCWS values for all work

tasks that have actually been completed by a point in time on the tasks that have actually been completed by a point in time on the project schedule.project schedule.

““the distinction between the BCWS and the BCWP is that the the distinction between the BCWS and the BCWP is that the former represents the budget of the activities that were former represents the budget of the activities that were planned to be completed and the latter represents the budget planned to be completed and the latter represents the budget of the activities that actually were completed.” [WIL99] of the activities that actually were completed.” [WIL99]

Given values for BCWS, BAC, and BCWP, important progress Given values for BCWS, BAC, and BCWP, important progress indicators can be computed:indicators can be computed:

Schedule performance index, SPI = BCWP/BCWSSchedule performance index, SPI = BCWP/BCWS Schedule variance, SV = BCWP – BCWSSchedule variance, SV = BCWP – BCWS SPI is an indication of the efficiency with which the project is utilizing SPI is an indication of the efficiency with which the project is utilizing

scheduled resources.scheduled resources.


Computing Earned Value-IIIComputing Earned Value-III

Percent scheduled for completion = BCWS/BACPercent scheduled for completion = BCWS/BAC provides an indication of the percentage of work that should provides an indication of the percentage of work that should

have been completed by time have been completed by time t.t. Percent complete = BCWP/BACPercent complete = BCWP/BAC

provides a quantitative indication of the percent of provides a quantitative indication of the percent of completeness of the project at a given point in time, completeness of the project at a given point in time, t.t.

Actual cost of work performed,Actual cost of work performed, ACWP ACWP, is the sum of the , is the sum of the effort actually expended on work tasks that have been effort actually expended on work tasks that have been completed by a point in time on the project schedule. It is completed by a point in time on the project schedule. It is then possible to computethen possible to compute

Cost performance index, CPI = BCWP/ACWPCost performance index, CPI = BCWP/ACWP Cost variance, CV = BCWP – ACWPCost variance, CV = BCWP – ACWP



Chapter 25Chapter 25Risk ManagementRisk Management

copyright © 1996, 2001, 2005





Project RisksProject Risks

What can go wrong?What can go wrong?What is the likelihood?What is the likelihood?What will the damage be?What will the damage be?What can we do about it?What can we do about it?


Reactive Risk Reactive Risk ManagementManagement

project team reacts to risks when they occurproject team reacts to risks when they occur mitigation—plan for additional resources in mitigation—plan for additional resources in

anticipation of fire fightinganticipation of fire fighting fix on failure—resource are found and applied fix on failure—resource are found and applied

when the risk strikeswhen the risk strikes crisis management—failure does not respond crisis management—failure does not respond

to applied resources and project is in jeopardyto applied resources and project is in jeopardy


Proactive Risk Proactive Risk ManagementManagement

formal risk analysis is performedformal risk analysis is performed organization corrects the root causes of riskorganization corrects the root causes of risk

TQM concepts and statistical SQATQM concepts and statistical SQA examining risk sources that lie beyond the bounds examining risk sources that lie beyond the bounds

of the softwareof the software developing the skill to manage change developing the skill to manage change


Seven PrinciplesSeven Principles

Maintain a global perspectiveMaintain a global perspective—view software risks within the context of —view software risks within the context of system and the business problem system and the business problem

Take a forward-looking viewTake a forward-looking view—think about the risks that may arise in the —think about the risks that may arise in the future; establish contingency plans future; establish contingency plans

Encourage open communicationEncourage open communication—if someone states a potential risk, don’t —if someone states a potential risk, don’t discount it. discount it.

IntegrateIntegrate—a consideration of risk must be integrated into the software —a consideration of risk must be integrated into the software processprocess

Emphasize a continuous processEmphasize a continuous process—the team must be vigilant throughout —the team must be vigilant throughout the software process, modifying identified risks as more information is the software process, modifying identified risks as more information is known and adding new ones as better insight is achieved.known and adding new ones as better insight is achieved.

Develop a shared product visionDevelop a shared product vision—if all stakeholders share the same —if all stakeholders share the same vision of the software, it likely that better risk identification and assessment vision of the software, it likely that better risk identification and assessment will occur.will occur.

Encourage teamworkEncourage teamwork—the talents, skills and knowledge of all stakeholder —the talents, skills and knowledge of all stakeholder should be pooledshould be pooled


RISK

Risk Management Risk Management ParadigmParadigm

controlcontrol

identifyidentify

analyzeanalyze

planplan

tracktrack


Risk IdentificationRisk Identification Product sizeProduct size—risks associated with the overall size of the software to be —risks associated with the overall size of the software to be

built or modified.built or modified. Business impactBusiness impact—risks associated with constraints imposed by —risks associated with constraints imposed by

management or the marketplace.management or the marketplace. Customer characteristicsCustomer characteristics—risks associated with the sophistication of the —risks associated with the sophistication of the

customer and the developer's ability to communicate with the customer customer and the developer's ability to communicate with the customer in a timely manner.in a timely manner.

Process definitionProcess definition—risks associated with the degree to which the —risks associated with the degree to which the software process has been defined and is followed by the development software process has been defined and is followed by the development organization.organization.

Development environmentDevelopment environment—risks associated with the availability and —risks associated with the availability and quality of the tools to be used to build the product.quality of the tools to be used to build the product.

Technology to be builtTechnology to be built—risks associated with the complexity of the —risks associated with the complexity of the system to be built and the "newness" of the technology that is packaged system to be built and the "newness" of the technology that is packaged by the system.by the system.

Staff size and experienceStaff size and experience—risks associated with the overall technical and —risks associated with the overall technical and project experience of the software engineers who will do the work.project experience of the software engineers who will do the work.


Assessing Project Risk-IAssessing Project Risk-I

Have top software and customer managers Have top software and customer managers formally committed to support the project?formally committed to support the project?

Are end-users enthusiastically committed to the Are end-users enthusiastically committed to the project and the system/product to be built?project and the system/product to be built?

Are requirements fully understood by the Are requirements fully understood by the software engineering team and their customers?software engineering team and their customers?

Have customers been involved fully in the Have customers been involved fully in the definition of requirements?definition of requirements?

Do end-users have realistic expectations?Do end-users have realistic expectations?


Assessing Project Risk-IIAssessing Project Risk-II

Is project scope stable?Is project scope stable? Does the software engineering team have the Does the software engineering team have the

right mix of skills?right mix of skills? Are project requirements stable?Are project requirements stable? Does the project team have experience with the Does the project team have experience with the

technology to be implemented?technology to be implemented? Is the number of people on the project team Is the number of people on the project team

adequate to do the job?adequate to do the job? Do all customer/user constituencies agree on the

importance of the project and on the requirements for the system/product to be built?


Risk ComponentsRisk Components

performance riskperformance risk—the degree of uncertainty that —the degree of uncertainty that the product will meet its requirements and be fit the product will meet its requirements and be fit for its intended use.for its intended use.

cost riskcost risk—the degree of uncertainty that the —the degree of uncertainty that the project budget will be maintained.project budget will be maintained.

support risksupport risk—the degree of uncertainty that the —the degree of uncertainty that the resultant software will be easy to correct, adapt, resultant software will be easy to correct, adapt, and enhance.and enhance.

schedule riskschedule risk—the degree of uncertainty that the —the degree of uncertainty that the project schedule will be maintained and that the project schedule will be maintained and that the product will be delivered on time.product will be delivered on time.


Risk ProjectionRisk Projection

Risk projectionRisk projection, also called , also called risk estimation,risk estimation, attempts to rate each risk in two waysattempts to rate each risk in two ways the likelihood or probability that the risk is real the likelihood or probability that the risk is real the consequences of the problems associated with the the consequences of the problems associated with the

risk, should it occur. risk, should it occur. The are four risk projection steps:The are four risk projection steps:

establish a scale that reflects the perceived likelihood of a riskestablish a scale that reflects the perceived likelihood of a risk delineate the consequences of the riskdelineate the consequences of the risk estimate the impact of the risk on the project and the product,estimate the impact of the risk on the project and the product, note the overall accuracy of the risk projection so that there note the overall accuracy of the risk projection so that there

will be no misunderstandings.will be no misunderstandings.


Building a Risk TableBuilding a Risk Table

RiskRisk ProbabilityProbability ImpactImpact RMMMRMMM

RiskRiskMitigationMitigationMonitoringMonitoring

& & ManagementManagement


Building the Risk TableBuilding the Risk Table

Estimate the Estimate the probabilityprobability of occurrence of occurrence Estimate the Estimate the impactimpact on the project on a on the project on a

scale of 1 to 5, wherescale of 1 to 5, where 1 = low impact on project success1 = low impact on project success 5 = catastrophic impact on project success5 = catastrophic impact on project success

sort the table by probability and impactsort the table by probability and impact


Risk Exposure (Impact)Risk Exposure (Impact)

The overall risk exposure, RE, is determined using the following relationship [HAL98]:

RE = P x C

where P is the probability of occurrence for a risk, and C is the cost to the project should the risk occur.


Risk Exposure ExampleRisk Exposure Example

Risk identification.Risk identification. Only 70 percent of the software Only 70 percent of the software components scheduled for reuse will, in fact, be integrated into components scheduled for reuse will, in fact, be integrated into the application. The remaining functionality will have to be the application. The remaining functionality will have to be custom developed.custom developed.

Risk probability.Risk probability. 80% (likely). 80% (likely). Risk impact.Risk impact. 60 reusable software components were planned. 60 reusable software components were planned.

If only 70 percent can be used, 18 components would have to be If only 70 percent can be used, 18 components would have to be developed from scratch (in addition to other custom software developed from scratch (in addition to other custom software that has been scheduled for development). Since the average that has been scheduled for development). Since the average component is 100 LOC and local data indicate that the software component is 100 LOC and local data indicate that the software engineering cost for each LOC is $14.00, the overall cost engineering cost for each LOC is $14.00, the overall cost (impact) to develop the components would be 18 x 100 x 14 = (impact) to develop the components would be 18 x 100 x 14 = $25,200.$25,200.

Risk exposure. Risk exposure. RE = 0.80 x 25,200 ~ $20,200. RE = 0.80 x 25,200 ~ $20,200.


mitigationmitigation—how can we avoid the risk?—how can we avoid the risk? monitoringmonitoring—what factors can we track that —what factors can we track that

will enable us to determine if the risk is will enable us to determine if the risk is becoming more or less likely?becoming more or less likely?

managementmanagement—what contingency plans do —what contingency plans do we have if the risk becomes a reality?we have if the risk becomes a reality?

Risk Mitigation, Risk Mitigation, Monitoring,Monitoring,

and Management and Management


Risk Due to Product SizeRisk Due to Product Size

• • estimated size of the product in LOC or FP?estimated size of the product in LOC or FP?

• • estimated size of product in number of programs, estimated size of product in number of programs, files, transactions?files, transactions?

• • percentage deviation in size of product from percentage deviation in size of product from average for previous products?average for previous products?

• • size of database created or used by the product?size of database created or used by the product?

• • number of users of the product?number of users of the product?

• • number of projected changes to the requirements number of projected changes to the requirements for the product? before delivery? after delivery?for the product? before delivery? after delivery?

• • amount of reused software?amount of reused software?

Attributes that affect risk:Attributes that affect risk:


Risk Due to Business Risk Due to Business ImpactImpact

• • affect of this product on company revenue?affect of this product on company revenue?• • visibility of this product by senior management?visibility of this product by senior management?• • reasonableness of delivery deadline?reasonableness of delivery deadline?

• • number of customers who will use this product number of customers who will use this product

• • interoperability constraintsinteroperability constraints

• • sophistication of end users?sophistication of end users?

• • amount and quality of product documentation that amount and quality of product documentation that must be produced and delivered to the customer?must be produced and delivered to the customer?

• • governmental constraintsgovernmental constraints

• • costs associated with late delivery?costs associated with late delivery?

• • costs associated with a defective product?costs associated with a defective product?

Attributes that affect risk:Attributes that affect risk:


Risks Due to the Risks Due to the CustomerCustomer

• • Have you worked with the customer in the past?Have you worked with the customer in the past?

• • Does the customer have a solid idea of requirements?Does the customer have a solid idea of requirements?

• • Has the customer agreed to spend time with you? Has the customer agreed to spend time with you?

• • Is the customer willing to participate in reviews?Is the customer willing to participate in reviews?

• • Is the customer technically sophisticated?Is the customer technically sophisticated?

• • Is the customer willing to let your people do their Is the customer willing to let your people do their job—that is, will the customer resist looking over your job—that is, will the customer resist looking over your shoulder during technically detailed work?shoulder during technically detailed work?

• • Does the customer understand the software Does the customer understand the software engineering process?engineering process?

Questions that must be answered:Questions that must be answered:


Risks Due to Process Risks Due to Process MaturityMaturity

• • Have you established a common process framework? Have you established a common process framework? • • Is it followed by project teams?Is it followed by project teams?• • Do you have management support for Do you have management support for software engineering software engineering • • Do you have a proactive approach to SQA? Do you have a proactive approach to SQA? • • Do you conduct formal technical reviews?Do you conduct formal technical reviews?

• • Are CASE tools used for analysis, design and Are CASE tools used for analysis, design and testing?testing?• • Are the tools integrated with one another?Are the tools integrated with one another?

• • Have document formats been established?Have document formats been established?



Technology RisksTechnology Risks

• • Is the technology new to your organization?Is the technology new to your organization?• • Are new algorithms, I/O technology required?Are new algorithms, I/O technology required? • • Is new or unproven hardware involved?Is new or unproven hardware involved?• • Does the application interface with new software?Does the application interface with new software?• • Is a specialized user interface required? Is a specialized user interface required? • • Is the application radically different?Is the application radically different?• • Are you using new software engineering methods?Are you using new software engineering methods?

• • Are you using unconventional software development Are you using unconventional software development methods, such as formal methods, AI-based approaches, methods, such as formal methods, AI-based approaches, artificial neural networks?artificial neural networks?

• • Are there significant performance constraints?Are there significant performance constraints?

• • Is there doubt the functionality requested is "do-able?"Is there doubt the functionality requested is "do-able?"



Staff/People RisksStaff/People Risks

• • Are the best people available?Are the best people available?• • Does staff have the right skills?Does staff have the right skills?• • Are enough people available?Are enough people available?• • Are staff committed for entire duration?Are staff committed for entire duration?• • Will some people work part time? Will some people work part time? • • Do staff have the right expectations?Do staff have the right expectations?• • Have staff received necessary training?Have staff received necessary training?• • Will turnover among staff be low?Will turnover among staff be low?



Project:Project: Embedded software for XYZ system Embedded software for XYZ systemRisk type:Risk type: schedule risk schedule riskPriority (1 low ... 5 critical):Priority (1 low ... 5 critical): 4 4Risk factor:Risk factor: Project completion will depend on tests which require Project completion will depend on tests which require hardware component under development. Hardware component hardware component under development. Hardware component delivery may be delayeddelivery may be delayedProbability:Probability: 60 % 60 %Impact: Impact: Project completion will be delayed for each day that Project completion will be delayed for each day that hardware is unavailable for use in software testinghardware is unavailable for use in software testingMonitoring approach:Monitoring approach: Scheduled milestone reviews with hardware groupScheduled milestone reviews with hardware groupContingency plan:Contingency plan: Modification of testing strategy to accommodate delay usingModification of testing strategy to accommodate delay using software simulationsoftware simulationEstimated resources:Estimated resources: 6 additional person months beginning 7-1-96 6 additional person months beginning 7-1-96

Recording Risk Recording Risk InformationInformation



Chapter 26Chapter 26Quality ManagementQuality Management

copyright © 1996, 2001, 2005





QualityQuality

The The American Heritage DictionaryAmerican Heritage Dictionary defines defines qualityquality as as ““a characteristic or attribute of something.” a characteristic or attribute of something.”

For software, two kinds of quality may be For software, two kinds of quality may be encountered: encountered: Quality of designQuality of design encompasses requirements, encompasses requirements,

specifications, and the design of the system. specifications, and the design of the system. Quality of conformanceQuality of conformance is an issue focused primarily on is an issue focused primarily on

implementation.implementation. user satisfaction = compliant product + good quality + user satisfaction = compliant product + good quality +

delivery within budget and scheduledelivery within budget and schedule


Software QualitySoftware Quality

Conformance to explicitly stated functional Conformance to explicitly stated functional and performance requirements, explicitly and performance requirements, explicitly documented development standards, and documented development standards, and implicit characteristics that are expected of implicit characteristics that are expected of all professionally developed software. all professionally developed software.


Cost of QualityCost of Quality Prevention costsPrevention costs include include

quality planningquality planning formal technical reviewsformal technical reviews test equipmenttest equipment TrainingTraining

Internal failure costsInternal failure costs include include reworkrework repairrepair failure mode analysisfailure mode analysis

External failure costsExternal failure costs are are complaint resolutioncomplaint resolution product return and replacementproduct return and replacement help line supporthelp line support warranty workwarranty work


Software Quality Software Quality AssuranceAssurance

FormalTechnicalReviews

Test Planning& ReviewMeasurement

Analysis&

Reporting

ProcessDefinition &Standards


Role of the SQA Group-IRole of the SQA Group-I

Prepares an SQA plan for a project. Prepares an SQA plan for a project. The plan identifiesThe plan identifies

evaluations to be performedevaluations to be performed audits and reviews to be performedaudits and reviews to be performed standards that are applicable to the projectstandards that are applicable to the project procedures for error reporting and trackingprocedures for error reporting and tracking documents to be produced by the SQA groupdocuments to be produced by the SQA group amount of feedback provided to the software project teamamount of feedback provided to the software project team

Participates in the development of the project’s Participates in the development of the project’s software process description.software process description. The SQA group reviews the process description for The SQA group reviews the process description for

compliance with organizational policy, internal software compliance with organizational policy, internal software standards, externally imposed standards (e.g., ISO-9001), and standards, externally imposed standards (e.g., ISO-9001), and other parts of the software project plan.other parts of the software project plan.


Role of the SQA Group-IIRole of the SQA Group-II Reviews software engineering activities to verify compliance Reviews software engineering activities to verify compliance

with the defined software process.with the defined software process. identifies, documents, and tracks deviations from the process and identifies, documents, and tracks deviations from the process and

verifies that corrections have been made.verifies that corrections have been made. Audits designated software work products to verify Audits designated software work products to verify

compliance with those defined as part of the software process.compliance with those defined as part of the software process. reviews selected work products; identifies, documents, and tracks reviews selected work products; identifies, documents, and tracks

deviations; verifies that corrections have been madedeviations; verifies that corrections have been made periodically reports the results of its work to the project manager.periodically reports the results of its work to the project manager.

Ensures that deviations in software work and work products Ensures that deviations in software work and work products are documented and handled according to a documented are documented and handled according to a documented procedure.procedure.

Records any noncompliance and reports to senior Records any noncompliance and reports to senior management.management. Noncompliance items are tracked until they are resolved.Noncompliance items are tracked until they are resolved.


Why SQA Activities Pay Why SQA Activities Pay Off?Off?cost to findcost to find

and fix a defectand fix a defect

100100

1010

loglogscalescale

11

Req.Req.DesignDesign

codecodetesttest

systemsystemtesttest

fieldfielduseuse

0.750.75 1.001.001.501.50

3.003.00

10.0010.00

60.00-100.0060.00-100.00


Reviews & InspectionsReviews & Inspections

... there is no particular reason... there is no particular reasonwhy your friend and colleaguewhy your friend and colleaguecannot also be your sternest critic.cannot also be your sternest critic.

Jerry WeinbergJerry Weinberg


What Are Reviews?What Are Reviews? a meeting conducted by technical people a meeting conducted by technical people

for technical peoplefor technical people a technical assessment of a work a technical assessment of a work

product created during the software product created during the software engineering processengineering process

a software quality assurance mechanisma software quality assurance mechanism a training grounda training ground


What Reviews Are NotWhat Reviews Are Not

A project summary or progress assessmentA project summary or progress assessment A meeting intended solely to impart informationA meeting intended solely to impart information A mechanism for political or personal reprisal!A mechanism for political or personal reprisal!


The PlayersThe Players

reviewreviewleaderleader

producerproducer

recorderrecorder reviewerreviewer

standards bearer (SQA)standards bearer (SQA)

maintenance maintenance oracleoracle

user repuser rep


Conducting the Conducting the ReviewReviewbe prepared—evaluate be prepared—evaluate

product before the reviewproduct before the review

review the product, not review the product, not the producerthe producer

keep your tone mild, ask keep your tone mild, ask questions instead of questions instead of making accusationsmaking accusations

stick to the review agendastick to the review agenda

raise issues, don't resolve themraise issues, don't resolve them

avoid discussions of style—stick to technical avoid discussions of style—stick to technical correctnesscorrectness

schedule reviews as project tasksschedule reviews as project tasks

record and report all review resultsrecord and report all review results

1.1.

2.2.

3.3.

4.4.

5.5.

6.6.

7.7.

8.8.


Review Options MatrixReview Options Matrix

trained leadertrained leaderagenda establishedagenda establishedreviewers prepare in advancereviewers prepare in advanceproducer presents productproducer presents product““reader” presents productreader” presents productrecorder takes notesrecorder takes noteschecklists used to find errorschecklists used to find errorserrors categorized as founderrors categorized as foundissues list createdissues list createdteam must sign-off on resultteam must sign-off on result

IPR—informal peer review WT—WalkthroughIPR—informal peer review WT—WalkthroughIN—Inspection RRR—round robin reviewIN—Inspection RRR—round robin review

IPRIPR WTWT ININ RRRRRR

nonomaybemaybemaybemaybemaybemaybenonomaybemaybenononononononono

yesyesyesyesyesyesyesyesnonoyesyesnonononoyesyesyesyes

yesyesyesyesyesyesnonoyesyesyesyesyesyesyesyesyesyesyesyes

yesyesyesyesyesyesnonononoyesyesnonononoyesyesmaybemaybe

**

*


Sample-Driven Reviews (SDRs)Sample-Driven Reviews (SDRs)

SDRs attempt to quantify those work products that are SDRs attempt to quantify those work products that are primary targets for full FTRs.primary targets for full FTRs.

To accomplish this …To accomplish this … Inspect a fraction aInspect a fraction aii of each software work product, of each software work product, i. i.

Record the number of faults, fRecord the number of faults, fii found within a found within aii.. Develop a gross estimate of the number of faults within Develop a gross estimate of the number of faults within

work product work product ii by multiplying f by multiplying fii by 1/a by 1/aii.. Sort the work products in descending order according to Sort the work products in descending order according to

the gross estimate of the number of faults in each.the gross estimate of the number of faults in each. Focus available review resources on those work products Focus available review resources on those work products

that have the highest estimated number of faults.that have the highest estimated number of faults.


Metrics Derived from ReviewsMetrics Derived from Reviews

inspection time per page of documentationinspection time per page of documentationinspection time per KLOC or FPinspection time per KLOC or FP

errors uncovered per reviewer hourerrors uncovered per reviewer hourerrors uncovered per preparation hourerrors uncovered per preparation hour

errors uncovered per SE task (e.g., design)errors uncovered per SE task (e.g., design)number of minor errors (e.g., typos)number of minor errors (e.g., typos)

number of errors found during preparationnumber of errors found during preparation

number of major errorsnumber of major errors (e.g., nonconformance to req.) (e.g., nonconformance to req.)

inspection effort per KLOC or FPinspection effort per KLOC or FP


Statistical Statistical SQASQA

ProductProduct& Process& Process

measurement

... an understanding of how to improve quality ...

Collect information on all defectsFind the causes of the defectsMove to provide fixes for the process


Six-Sigma for Software Six-Sigma for Software EngineeringEngineering

The term “six sigma” is derived from six standard The term “six sigma” is derived from six standard deviations—3.4 instances (defects) per million occurrencesdeviations—3.4 instances (defects) per million occurrences—implying an extremely high quality standard. —implying an extremely high quality standard.

The Six Sigma methodology defines three core steps:The Six Sigma methodology defines three core steps: DefineDefine customer requirements and deliverables and project customer requirements and deliverables and project

goals via well-defined methods of customer communicationgoals via well-defined methods of customer communication MeasureMeasure the existing process and its output to determine the existing process and its output to determine

current quality performance (collect defect metrics)current quality performance (collect defect metrics) AnalyzeAnalyze defect metrics and determine the vital few causes.defect metrics and determine the vital few causes. ImproveImprove the process by eliminating the root causes of defects. the process by eliminating the root causes of defects. Control the process to ensure that future work does not

reintroduce the causes of defects.


Software ReliabilitySoftware Reliability

A simple measure of reliability is A simple measure of reliability is mean-time-mean-time-between-failurebetween-failure (MTBF), where (MTBF), where

MTBF = MTTF + MTTRMTBF = MTTF + MTTR

The acronyms MTTF and MTTR are mean-time-to-failure and mean-time-to-repair, respectively.

Software availabilitySoftware availability is the probability that a is the probability that a program is operating according to requirements program is operating according to requirements at a given point in time and is defined asat a given point in time and is defined as

Availability = [MTTF/(MTTF + MTTR)] x 100%


Software SafetySoftware Safety

Software safetySoftware safety is a software quality assurance is a software quality assurance activity that focuses on the identification and activity that focuses on the identification and assessment of potential hazards that may affect assessment of potential hazards that may affect software negatively and cause an entire system software negatively and cause an entire system to fail. to fail.

If hazards can be identified early in the software If hazards can be identified early in the software process, software design features can be process, software design features can be specified that will either eliminate or control specified that will either eliminate or control potential hazards.potential hazards.


Mistake-ProofingMistake-Proofing

Poka-yoke (mistake-proofing) devices—mechanisms that lead to the prevention of a potential quality problem before it

occurs or the rapid detection of quality problems if they are

introduced. An effective poka-yoke device exhibits a set of An effective poka-yoke device exhibits a set of

common characteristics: common characteristics: It is simple and cheap.It is simple and cheap. If a device is too complicated or If a device is too complicated or

expensive, it will not be cost effective.expensive, it will not be cost effective. It is part of the process. It is part of the process. That is, the That is, the poka-yokepoka-yoke device is device is

integrated into an engineering activity.integrated into an engineering activity. It is located near the process task where the mistakes occur.It is located near the process task where the mistakes occur.

Thus, it provides rapid feedback and error correction.Thus, it provides rapid feedback and error correction.


ISO 9001:2000 StandardISO 9001:2000 Standard

ISO 9001:2000 is the quality assurance standard ISO 9001:2000 is the quality assurance standard that applies to software engineering. that applies to software engineering.

The standard contains 20 requirements that must The standard contains 20 requirements that must be present for an effective quality assurance be present for an effective quality assurance system. system.

The requirements delineated by ISO 9001:2000 The requirements delineated by ISO 9001:2000 address topics such as address topics such as management responsibility, quality system, contract management responsibility, quality system, contract

review, design control, document and data control, review, design control, document and data control, product identification and traceability, process control, product identification and traceability, process control, inspection and testing, corrective and preventive inspection and testing, corrective and preventive action, control of quality records, internal quality action, control of quality records, internal quality audits, training, servicing, and statistical techniques.audits, training, servicing, and statistical techniques.


The “First The “First Law”Law”

No matter where you are in the system No matter where you are in the system life cycle, the system will change, and the life cycle, the system will change, and the desire to change it will persist throughout desire to change it will persist throughout the life cycle.the life cycle.

Bersoff, et al, 1980Bersoff, et al, 1980


What Are These What Are These Changes?Changes?

datadata

otherotherdocumentsdocuments

codecodeTestTest

ProjectProjectPlanPlan

changes in changes in technical requirementstechnical requirements

changes in changes in business requirementsbusiness requirements

changes inchanges inuser requirementsuser requirements

software modelssoftware models


The Software ConfigurationThe Software Configuration

programsprograms documentsdocuments

datadataThe piecesThe pieces


BaselinesBaselines

The IEEE (IEEE Std. No. 610.12-1990) defines a The IEEE (IEEE Std. No. 610.12-1990) defines a baseline as:baseline as:

A specification or product that has been formally reviewed A specification or product that has been formally reviewed and agreed upon, that thereafter serves as the basis for and agreed upon, that thereafter serves as the basis for further development, and that can be changed only further development, and that can be changed only through formal change control procedures.through formal change control procedures.

a baseline is a milestone in the development of a baseline is a milestone in the development of software that is marked by the delivery of one or software that is marked by the delivery of one or more software configuration items and the more software configuration items and the approval of these SCIs that is obtained through a approval of these SCIs that is obtained through a formal technical reviewformal technical review


BaselinesBaselines

SCIs

SCIs

modified

Softwareengineering

tasks

Formaltechnicalreviews

SCIs

approved

SCIs

extracted

SCMcontrols

SCIs

stored

Project database

System SpecificationSoftware RequirementsDesign SpecificationSource CodeTest Plans/Procedures/DataOperational System

BASELINES:


Software Configuration ObjectsSoftware Configuration Objects

Design specification

data designarchitectural designmodule designinterface design

Component N

interface descriptionalgorithm descriptionPDL

Data model

Test specification

test plantest proceduretest cases

Source code


SCM RepositorySCM Repository

The SCM repository is the set of mechanisms and data structures that allow a software team to manage change in an effective manner

The repository performs or precipitates the following functions [FOR89]: Data integrity Information sharing Tool integration Data integration Methodology enforcement Document standardization


Repository ContentRepository Content

BusinessContent

ModelContent

V&VContent

ProjectManagement

Content

ConstructionContent

Documents

business rulesbusiness functionsorganization structureinformation architecture

project estimatesproject scheduleSCM requirements change requests change reportsSQA requirementsproject reports/audit reportsproject metrics

Project PlanSCM/SQA PlanSystem SpecRequirements SpecDesign DocumentTest Plan and ProcedureSupport documentsUser manual

use-casesanalysis model scenario-based diagrams flow-oriented diagrams class-based diagrams behavioral diagramsdesign model architectural diagrams interface diagrams component-level diagramstechnical metrics

source codeobject codesystem build instructions

test casestest scriptstest resultsquality metrics


Repository FeaturesRepository Features Versioning.

saves all of these versions to enable effective management of product releases and to permit developers to go back to previous versions

Dependency tracking and change management. The repository manages a wide variety of relationships among the data

elements stored in it. Requirements tracing.

Provides the ability to track all the design and construction components and deliverables that result from a specific requirement specification

Configuration management. Keeps track of a series of configurations representing specific project

milestones or production releases. Version management provides the needed versions, and link management keeps track of interdependencies.

Audit trails.Audit trails. establishes additional information about when, why, and by whom changes establishes additional information about when, why, and by whom changes

are made. are made.


SCM ElementsSCM Elements

Component elementsComponent elements—a set of tools coupled within a file —a set of tools coupled within a file management system (e.g., a database) that enables access management system (e.g., a database) that enables access to and management of each software configuration item. to and management of each software configuration item.

Process elementsProcess elements—a collection of procedures and tasks —a collection of procedures and tasks that define an effective approach to change management that define an effective approach to change management (and related activities) for all constituencies involved in the (and related activities) for all constituencies involved in the management, engineering and use of computer software.management, engineering and use of computer software.

Construction elementsConstruction elements—a set of tools that automate the —a set of tools that automate the construction of software by ensuring that the proper set of construction of software by ensuring that the proper set of validated components (i.e., the correct version) have been validated components (i.e., the correct version) have been assembled.assembled.

Human elementsHuman elements—to implement effective SCM, the —to implement effective SCM, the software team uses a set of tools and process features software team uses a set of tools and process features (encompassing other CM elements) (encompassing other CM elements)


The SCM ProcessThe SCM Process

How does a software team identify the discrete elements of How does a software team identify the discrete elements of a software configuration?a software configuration?

How does an organization manage the many existing How does an organization manage the many existing versions of a program (and its documentation) in a manner versions of a program (and its documentation) in a manner that will enable change to be accommodated efficiently?that will enable change to be accommodated efficiently?

How does an organization control changes before and after How does an organization control changes before and after software is released to a customer?software is released to a customer?

Who has responsibility for approving and ranking changes? Who has responsibility for approving and ranking changes? How can we ensure that changes have been made How can we ensure that changes have been made

properly?properly? What mechanism is used to appraise others of changes that What mechanism is used to appraise others of changes that

are made? are made?

Addresses the following questions …Addresses the following questions …


The SCM ProcessThe SCM Process

identification

change control

version control

configuration auditing

reporting

SCIs

SoftwareVm.n


Version ControlVersion Control Version control combines procedures and tools to manage

different versions of configuration objects that are created during the software process

A version control system implements or is directly integrated A version control system implements or is directly integrated with four major capabilities: with four major capabilities: a a project database (repository)project database (repository) that stores all relevant that stores all relevant

configuration objectsconfiguration objects a a version managementversion management capability that stores all versions of a capability that stores all versions of a

configuration object (or enables any version to be constructed configuration object (or enables any version to be constructed using differences from past versions); using differences from past versions);

a a make facilitymake facility that enables the software engineer to collect all that enables the software engineer to collect all relevant configuration objects and construct a specific version of relevant configuration objects and construct a specific version of the software. the software.

an an issues trackingissues tracking (also called (also called bug trackingbug tracking) capability that ) capability that enables the team to record and track the status of all outstanding enables the team to record and track the status of all outstanding issues associated with each configuration object.issues associated with each configuration object.


Change ControlChange Control

STOPSTOP


Change Control Process—IChange Control Process—I

change request from userchange request from user

developer evaluatesdeveloper evaluates

change report is generatedchange report is generated

change control authority decideschange control authority decides

request is queued for actionrequest is queued for actionchange request is deniedchange request is denied

user is informeduser is informed

need for change is recognizedneed for change is recognized

change control process—IIchange control process—IIchange control process—IIchange control process—II


Change Control Change Control Process-IIProcess-II

assign people to SCIsassign people to SCIs

check-out SCIscheck-out SCIs

make the changemake the change

review/audit the changereview/audit the change

establish a “baseline” for testingestablish a “baseline” for testing

change control process—IIIchange control process—IIIchange control process—IIIchange control process—III


Change Control Change Control Process-IIIProcess-III

perform SQA and testing activitiesperform SQA and testing activities

promote SCI for inclusion in next releasepromote SCI for inclusion in next release

rebuild appropriate versionrebuild appropriate version

review/audit the changereview/audit the change

include all changes in releaseinclude all changes in release

check-in the changed SCIscheck-in the changed SCIs


AuditingAuditing

SCIsSCIs

ChangeChangeRequestsRequests SQASQA

PlanPlan

SCM AuditSCM Audit


Status AccountingStatus Accounting

SCIsSCIs

ChangeChangeRequestsRequests

ChangeChange ReportsReports ECOsECOs

Status AccountingStatus Accounting

ReportingReporting


SCM for Web Engineering-ISCM for Web Engineering-I

Content. A typical WebApp contains a vast array of content—text,

graphics, applets, scripts, audio/video files, forms, active page elements, tables, streaming data, and many others.

The challenge is to organize this sea of content into a rational set of configuration objects (Section 27.1.4) and then establish appropriate configuration control mechanisms for these objects.

People. Because a significant percentage of WebApp development

continues to be conducted in an ad hoc manner, any person involved in the WebApp can (and often does) create content.


SCM for Web Engineering-IISCM for Web Engineering-II

Scalability. Scalability. As size and complexity grow, small changes can have far-As size and complexity grow, small changes can have far-

reaching and unintended affects that can be problematic. reaching and unintended affects that can be problematic. Therefore, the rigor of configuration control mechanisms Therefore, the rigor of configuration control mechanisms should be directly proportional to application scale.should be directly proportional to application scale.

Politics. Politics. Who ‘owns’ a WebApp? Who ‘owns’ a WebApp? Who assumes responsibility for the accuracy of the Who assumes responsibility for the accuracy of the

information on the Web site?information on the Web site? Who assures that quality control processes have been Who assures that quality control processes have been

followed before information is published to the site? followed before information is published to the site? Who is responsible for making changes? Who is responsible for making changes? Who assumes the cost of change? Who assumes the cost of change?


Content Management-IContent Management-I The collection subsystemThe collection subsystem encompasses all actions required to create encompasses all actions required to create

and/or acquire content, and the technical functions that are necessary to and/or acquire content, and the technical functions that are necessary to convert content into a form that can be represented by a mark-up language convert content into a form that can be represented by a mark-up language

(e.g., HTML, XML(e.g., HTML, XML organize content into packets that can be displayed effectively on the client-organize content into packets that can be displayed effectively on the client-

side.side.

The management subsystemThe management subsystem implements a repository that implements a repository that encompasses the following elements:encompasses the following elements: Content databaseContent database—the information structure that has been established to —the information structure that has been established to

store all content objectsstore all content objects Database capabilitiesDatabase capabilities—functions that enable the CMS to search for specific —functions that enable the CMS to search for specific

content objects (or categories of objects), store and retrieve objects, and content objects (or categories of objects), store and retrieve objects, and manage the file structure that has been established for the contentmanage the file structure that has been established for the content

Configuration management functionsConfiguration management functions—the functional elements and associated —the functional elements and associated workflow that support content object identification, version control, change workflow that support content object identification, version control, change management, change auditing, and reporting.management, change auditing, and reporting.


Content Management-IIContent Management-II The The publishing subsystempublishing subsystem extracts from the repository, extracts from the repository,

converts it to a form that is amenable to publication, and formats converts it to a form that is amenable to publication, and formats it so that it can be transmitted to client-side browsers. The it so that it can be transmitted to client-side browsers. The publishing subsystem accomplishes these tasks using a series of publishing subsystem accomplishes these tasks using a series of templates. templates.

Each Each templatetemplate is a function that builds a publication using one of is a function that builds a publication using one of three different components [BOI02]:three different components [BOI02]: Static elementsStatic elements—text, graphics, media, and scripts that require no —text, graphics, media, and scripts that require no

further processing are transmitted directly to the client-sidefurther processing are transmitted directly to the client-side Publication servicesPublication services—function calls to specific retrieval and —function calls to specific retrieval and

formatting services that personalize content (using predefined rules), formatting services that personalize content (using predefined rules), perform data conversion, and build appropriate navigation links.perform data conversion, and build appropriate navigation links.

External servicesExternal services—provide access to external corporate information —provide access to external corporate information infrastructure such as enterprise data or “back-room” applications.infrastructure such as enterprise data or “back-room” applications.


Content ManagementContent Management

database

configuration objects

templates

ContentManagement

System

HTML code+ scripts

server-side

client-side browser


Change Management for Change Management for WebApps-IWebApps-I

classify therequested change

acquire related objectsassess impact of change

OK to make

class 1 change

class 2 change

develop brief writtendescription of change

develop brief writtendescription of change

transmit to all teammembers for review

changesrequiredin relatedobjects

class 3 change

furtherevaluationis required

class 4 change

OK to make

transmit to all stake-holders for review

furtherevaluationis required


Change Management for Change Management for WebApps-IIWebApps-II

check out object(s)to be changed

make changesdesign, construct, test

check in object(s)that were changed

publish to WebApp

part 4

Documents

university use

student use

university level

software engineering

pressman associates

practitioners approach

consulting purposes

industry seminars