SOEmm11

8/9/2019 SOEmm11

1/20

These courseware materials are to be used in conjunction with Soft ware Engineering: A Practit ioners Approach,6/e and are provided w ith permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001 , 2005 1

Supplementary Slides forSupplementary Slides forSoftware Engineering:Software Engineering:

A Practitioner's Approach, 6/e A Practitioner's Approach, 6/ePart 4Part 4

copyright 1996, 2001, 2005R.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 for short courses, industry seminars, or consulting purposes.


Software Engineering: A Practitioner Software Engineering: A Practitioner s Approach, 6/es Approach, 6/e

Chapter 21Chapter 21Project Management ConceptsProject Management Concepts

copyright 1996, 2001, 2005

R.S. Pressman & Associates, Inc.

For University Use OnlyMay be reproduced ONLY for student use at the university levelwhen used in conjunction with Software Engineering: A Practitioner's Approach.

Any other reproduction or use is expressly prohibited.

8/9/2019 SOEmm11

2/20


The 4 PThe 4 P ssPeoplePeople the most important element of athe most important element of asuccessful projectsuccessful projectProductProduct the software to be builtthe software to be builtProcessProcess the set of framework activities andthe set of framework activities andsoftware engineering tasks to get the job donesoftware engineering tasks to get the job doneProjectProject all work required to make the product aall work required to make the product arealityreality


StakeholdersStakeholders

Senior managersSenior managers who dene the business issues that often have signicant inuencewho dene the business issues that often have signicant inuenceon the project.on the project.Project (technical) managersProject (technical) managers who must plan, motivate, organize, and control thewho must plan, motivate, organize, and control thepractitioners who do software work.practitioners who do software work.PractitionersPractitioners who deliver the technical skills that are necessary to engineer a productwho deliver the technical skills that are necessary to engineer a productor application.or application.CustomersCustomers who specify the requirements for the software to be engineered and otherwho specify the requirements for the software to be engineered and otherstakeholders who have a peripheral interest in the outcome.stakeholders who have a peripheral interest in the outcome.End-usersEnd-users who interact with the software once it is released for production use.who interact with the software once it is released for production use.

8/9/2019 SOEmm11

3/20


Software TeamsSoftware TeamsHow to lead?

How to organize?

How to motivate?

How to collaborate?

How to create good ideas?


Team LeaderTeam Leader

The MOI ModelThe MOI ModelMotivation.Motivation. The ability to encourage (byThe ability to encourage (by push or pullpush or pull ))technical people to produce to their best ability.technical people to produce to their best ability.Organization.Organization. The ability to mold existing processes (or inventThe ability to mold existing processes (or inventnew ones) that will enable the initial concept to be translatednew ones) that will enable the initial concept to be translatedinto a nal product.into a nal product.Ideas or innovation.Ideas or innovation. The ability to encourage people to createThe ability to encourage people to create

and feel creative even when they must work within boundsand feel creative even when they must work within boundsestablished for a particular software product or application.established for a particular software product or application.

8/9/2019 SOEmm11

4/20


Software TeamsSoftware Teams

the difculty of the problem to be solvedthe difculty of the problem to be solvedthe size of the resultant program(s) in lines of code orthe size of the resultant program(s) in lines of code orfunction pointsfunction pointsthe time that the team will stay together (team lifetime)the time that the team will stay together (team lifetime)the degree to which the problem can be modularizedthe degree to which the problem can be modularizedthe required quality and reliability of the system to be builtthe required quality and reliability of the system to be builtthe rigidity of the delivery datethe rigidity of the delivery date

the degree of sociability (communication) required for thethe degree of sociability (communication) required for theprojectproject

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


closed paradigmclosed paradigm structures a team along a traditional hierarchy of structures a team along a traditional hierarchy of authorityauthorityrandom paradigmrandom paradigm structures a team loosely and depends on individualstructures a team loosely and depends on individualinitiative of the team membersinitiative of the team membersopen paradigmopen paradigm attempts to structure a team in a manner that achievesattempts to structure a team in a manner that achievessome of the controls associated with the closed paradigm but also much of some of the controls associated with the closed paradigm but also much of the innovation that occurs when using the random paradigmthe innovation that occurs when using the random paradigmsynchronous paradigmsynchronous paradigm relies on the natural compartmentalization of arelies on the natural compartmentalization of a

problem and organizes team members to work on pieces of the problemproblem and organizes team members to work on pieces of the problemwith little active communication among themselveswith little active communication among themselves

Organizational ParadigmsOrganizational Paradigms

suggested by Constantine [CON93]

8/9/2019 SOEmm11

5/20


Avoid TeamAvoid Team ToxicityToxicity A frenzied work atmosphere in which team members waste energy andlose focus on the objectives of the work to be performed.High frustration caused by personal, business, or technological factors thatcause friction among team members.Fragmented or poorly coordinated procedures or a poorly dened orimproperly chosen process model that becomes a roadblock toaccomplishment.Unclear denition of roles resulting in a lack of accountability and resultantnger-pointing.Continuous and repeated exposure to failure that leads to a loss of condence 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 theThe distribution of skills must be appropriate to theproblem.problem.Mavericks may have to be excluded from the team, if Mavericks may have to be excluded from the team, if team cohesiveness is to be maintained.team cohesiveness is to be maintained.Team isTeam is self-organizingself-organizing

An adaptive team structureAn adaptive team structureUses elements of ConstantineUses elements of Constantine s random, open, and synchronouss random, open, and synchronousparadigmsparadigmsSignicant autonomySignicant autonomy

8/9/2019 SOEmm11

6/20


Team Coordination & CommunicationTeam Coordination & CommunicationFormal, impersonal approachesFormal, impersonal approaches include software engineering documents and work include software engineering documents and work products (including source code), technical memos, project milestones,products (including source code), technical memos, project milestones,schedules, and project control tools (Chapter 23), change requests and relatedschedules, and project control tools (Chapter 23), change requests and relateddocumentation, error tracking reports, and repository data (see Chapter 26).documentation, error tracking reports, and repository data (see Chapter 26).Formal, interpersonal proceduresFormal, interpersonal procedures focus on quality assurance activities (Chapter 25)focus on quality assurance activities (Chapter 25)applied to software engineering work products. These include status reviewapplied to software engineering work products. These include status reviewmeetings and design and code inspections.meetings and design and code inspections.Informal, interpersonal proceduresInformal, interpersonal procedures include group meetings for informationinclude group meetings for informationdissemination and problem solving anddissemination and problem solving and collocation of requirements andcollocation of requirements anddevelopment staff.development staff. Electronic communicationElectronic communication encompasses electronic mail, electronic bulletin boards,encompasses electronic mail, electronic bulletin boards,and by extension, video-based conferencing systems.and by extension, video-based conferencing systems.Interpersonal networkingInterpersonal networking includes informal discussions with team members andincludes informal discussions with team members andthose outside the project who may have experience or insight that can assistthose outside the project who may have experience or insight that can assistteam members.team members.


The Product ScopeThe Product Scope

ScopeScopeContext. How does the software to be built t into a larger system,product, or business context and what constraints are imposed as aresult of the context?Information objectives. What customer-visible data objects(Chapter 8) are produced as output from the software? What dataobjects are required for input?Function and performance. What function does the softwareperform to transform input data into output? Are any specialperformance characteristics to be addressed?

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

8/9/2019 SOEmm11

7/20


Problem DecompositionProblem DecompositionSometimes called partitioning or problem elaborationOnce scope is dened

It is decomposed into constituent functionsIt is decomposed into user-visible data objects

orIt is decomposed into a set of problem classes

Decomposition process continues until all functions orproblem classes have been dened


The Process

Once a process framework has been establishedOnce a process framework has been establishedConsider project characteristicsConsider project characteristicsDetermine the degree of rigor requiredDetermine the degree of rigor requiredDene a task set for each software engineering activityDene a task set for each software engineering activity

Task set =Task set =Software engineering tasksSoftware engineering tasksWork productsWork products

Quality assurance pointsQuality assurance pointsMilestonesMilestones

8/9/2019 SOEmm11

8/20


Melding the Problem and the Process


The Project

Projects get into trouble whenProjects get into trouble when Software people donSoftware people don t understand their customert understand their customer s needs.s needs.The product scope is poorly dened.The product scope is poorly dened.Changes are managed poorly.Changes are managed poorly.The chosen technology changes.The chosen technology changes.Business needs change [or are ill-dened].Business needs change [or are ill-dened].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 learned.Managers [and practitioners] avoid best practices and lessons learned.

8/9/2019 SOEmm11

9/20


Common-Sense Approach to ProjectsStart on the right foot.Start on the right foot. This is accomplished by working hard (very hard) toThis is accomplished by working hard (very hard) tounderstand the problem that is to be solved and then setting realisticunderstand the problem that is to be solved and then setting realisticobjectives and expectations.objectives and expectations. Maintain momentum. Maintain momentum. TheThe project manager must provide incentives to keepproject manager must provide incentives to keepturnover of personnel to an absolute minimum, the team should emphasizeturnover of personnel to an absolute minimum, the team should emphasizequality in every task it performs, and senior management should doquality in every task it performs, and senior management should doeverything possible to stay out of the teameverything possible to stay out of the team s way.s way.Track progress.Track progress. For a software project, progress is tracked as work productsFor a software project, progress is tracked as work products(e.g., models, source code, sets of test cases) are produced and approved(e.g., models, source code, sets of test cases) are produced and approved(using formal technical reviews) as part of a quality assurance activity.(using formal technical reviews) as part of a quality assurance activity. Make smart decisions. Make smart decisions. In essence, the decisions of the project manager andIn essence, the decisions of the project manager and

the software team should be tothe software team should be to keep it simple.keep it simple. Conduct a postmortem analysis.Conduct a postmortem analysis. Establish a consistent mechanism forEstablish a consistent mechanism forextracting lessons learned for each project.extracting lessons learned for each project.


To Get to the Essence of a ProjectTo Get to the Essence of a Project

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 andHow will the job be done technically andmanagerially?managerially?How much of each resource (e.g., people,How much of each resource (e.g., people,software, tools, database) will be needed?software, tools, database) will be needed?

Barry Boehm

8/9/2019 SOEmm11

10/20

8/9/2019 SOEmm11

11/20


Software Engineering: A Practitioner Software Engineering: A Practitioner s Approach, 6/es Approach, 6/e

Chapter 22Chapter 22Process and Project MetricsProcess and Project Metrics

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


A Good Manager MeasuresA Good Manager Measures

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

8/9/2019 SOEmm11

12/20


Why Do We Measure?Why Do We Measure?assess the status of an ongoing projecttrack potential risksuncover problem areas before they go critical,adjust work ow or tasks,evaluate the project teams ability to controlquality of software work products.


Process MeasurementWe measure the efcacy of a software process indirectly.We measure the efcacy of a software process indirectly.

That is, we derive a set of metrics based on the outcomes that can be derivedThat is, we derive a set of metrics based on the outcomes that can be derivedfrom the process.from the process.Outcomes includeOutcomes include

measures of errors uncovered before release of the softwaremeasures of errors uncovered before release of the softwaredefects delivered to and reported by end-usersdefects delivered to and reported by end-userswork products delivered (productivity)work products delivered (productivity)human effort expendedhuman effort expendedcalendar time expendedcalendar time expended

schedule conformanceschedule conformanceother measures.other measures.

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

8/9/2019 SOEmm11

13/20


Process Metrics GuidelinesUse common sense and organizational sensitivity when interpretingUse common sense and organizational sensitivity when interpretingmetrics data.metrics data.Provide regular feedback to the individuals and teams who collectProvide regular feedback to the individuals and teams who collectmeasures and metrics.measures and metrics.DonDont use metrics to appraise individuals.t use metrics to appraise individuals.Work with practitioners and teams to set clear goals and metrics that willWork with practitioners and teams to set clear goals and metrics that will be used to achieve them. 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 consideredMetrics data that indicate a problem area should not be considerednegative.negative. These data are merely an indicator for process improvement.These data are merely an indicator for process improvement.DonDont obsess on a single metric to the exclusion of other important metrics.t obsess on a single metric to the exclusion of other important metrics.


Software Process Improvement

SPI

Process model

Improvement goals

Process metrics

Process improvementrecommendations

8/9/2019 SOEmm11

14/20


Process MetricsProcess MetricsQuality-relatedQuality-related

focus on quality of work products and deliverablesfocus on quality of work products and deliverablesProductivity-relatedProductivity-related

Production of work-products related to effort expendedProduction of work-products related to effort expendedStatistical SQA dataStatistical SQA data

error categorization & analysiserror categorization & analysisDefect removal efciencyDefect removal efciency

propagation of errors from process activity to activitypropagation of errors from process activity to activityReuse dataReuse data

The number of components produced and their degree of reusabilityThe number of components produced and their degree of reusability


Project Metrics

used to minimize the development schedule by making the adjustments necessary toused to minimize the development schedule by making the adjustments necessary toavoid delays and mitigate potential problems and risksavoid delays and mitigate potential problems and risksused to assess product quality on an ongoing basis and, when necessary, modify theused to assess product quality on an ongoing basis and, when necessary, modify thetechnical approach to improve quality.technical approach to improve quality.every project should measure:every project should measure:

inputsinputs measures of the resources (e.g., people, tools) required to do the work.measures of the resources (e.g., people, tools) required to do the work.outputsoutputs measures of the deliverables or work products created during the softwaremeasures of the deliverables or work products created during the softwareengineering process.engineering process.resultsresultsmeasures that indicate the effectiveness of the deliverables.measures that indicate the effectiveness of the deliverables.

8/9/2019 SOEmm11

15/20


Typical Project MetricsTypical Project Metrics

Effort/time per software engineering task Effort/time per software engineering task Errors uncovered per review hourErrors uncovered per review hourScheduledScheduled vsvs. actual milestone dates. actual milestone datesChanges (number) and their characteristicsChanges (number) and their characteristicsDistribution of effort on software engineeringDistribution of effort on software engineeringtaskstasks


Metrics GuidelinesMetrics GuidelinesUse common sense and organizational sensitivity when interpretingUse common sense and organizational sensitivity when interpretingmetrics data.metrics data.Provide regular feedback to the individuals and teams who have workedProvide regular feedback to the individuals and teams who have workedto collect measures and metrics.to collect measures and metrics.DonDont use metrics to appraise individuals.t use metrics to appraise individuals.Work with practitioners and teams to set clear goals and metrics that willWork with practitioners and teams to set clear goals and metrics that will be used to achieve them. 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 consideredMetrics data that indicate a problem area should not be considerednegative.negative. These data are merely an indicator for process improvement.These data are merely an indicator for process improvement.

DonDont obsess on a single metric to the exclusion of other importantt obsess on a single metric to the exclusion of other importantmetrics.metrics.

8/9/2019 SOEmm11

16/20


Typical Size-Oriented MetricsTypical Size-Oriented Metricserrors per KLOC (thousand lines of code)errors per KLOC (thousand lines of code)defects per KLOCdefects per KLOC$ per LOC$ per LOCpages of documentation per KLOCpages of documentation per KLOCerrors per person-montherrors per person-monthErrors per review hourErrors per review hourLOC per person-monthLOC per person-month$ per page of documentation$ per page of documentation


Typical Function-Oriented MetricsTypical Function-Oriented Metrics

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

8/9/2019 SOEmm11

17/20


Comparing LOC and FPComparing LOC and FPProgramming LOC per Fu nction pointLanguage avg. median low high

Ada 154 - 104 205

A ss em ble r 33 7 315 91 694C 162 109 33 704C++ 66 53 29 178

COBOL 77 77 14 400

Java 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 110

Visual Basic 47 42 16 158

Representative values developed by QSM


Why Opt for FP?Why Opt for FP?

Programming language independentProgramming language independentUsed readily countable characteristics that areUsed readily countable characteristics that aredetermined early in the software processdetermined early in the software processDoes notDoes not penalizepenalize inventive (short) implementationsinventive (short) implementationsthat use fewer LOC that other more clumsy versionsthat use fewer LOC that other more clumsy versionsMakes it easier to measure the impact of reusableMakes it easier to measure the impact of reusablecomponentscomponents

8/9/2019 SOEmm11

18/20


Object-Oriented MetricsObject-Oriented MetricsNumber of Number of scenario scriptsscenario scripts (use-cases)(use-cases)Number of Number of support classessupport classes ((required to implement thesystem but are not immediately related to the problemdomain)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 asystem)


WebE Project MetricsWebE Project Metrics

Number of static Web pages (the end-user has no control over the contentdisplayed on the page)Number of dynamic Web pages (end-user actions result in customizedcontent displayed on the page)Number of internal page links (internal page links are pointers that providea hyperlink to some other Web page within the WebApp)Number of persistent data objectsNumber of external systems interfacedNumber of static content objectsNumber of dynamic content objectsNumber of executable functions

8/9/2019 SOEmm11

19/20


Measuring QualityMeasuring QualityCorrectnessCorrectness the degree to which a program operatesthe degree to which a program operatesaccording to specicationaccording to specicationMaintainabilityMaintainability the degree to which a program isthe degree to which a program isamenable to changeamenable to changeIntegrityIntegrity the degree to which a program is imperviousthe degree to which a program is imperviousto outside attack to outside attack UsabilityUsability the degree to which a program is easy to usethe degree to which a program is easy to use


Defect Removal EfciencyDefect Removal Efciency

DRE = E /( E + D)

E is the number of errors found before delivery

of the software to the end-userD is the number of defects found after delivery.

8/9/2019 SOEmm11

20/20


Metrics for Small OrganizationsMetrics for Small Organizationstime (hours or days) elapsed from the time a request is made untilevaluation is complete, tqueue.effort (person-hours) to perform the evaluation, W eval.time (hours or days) elapsed from completion of evaluation toassignment of change order to personnel, teval.effort (person-hours) required to make the change, W change.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 ProgramEstablishing a Metrics ProgramIdentify 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 quantiable questions and the related indicators that you will useto help you achieve your measurement goals.Identify the data elements that you will collect to construct the indicatorsthat help answer your questions.Dene the measures to be used, and make these denitions operational.Identify the actions that you will take to implement the measures.Prepare a plan for implementing the measures.

Documents

SOEmm11