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

8/14/2019 SoftwareEngineering: APractitioner'sApproach, 6/e

1/19

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

Supplementary Slides forSupplementary Slides for

Software Engineering:Software Engineering:A Practitioner's Approach,A Practitioner's Approach,

6/e6/ePart 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 ApproachAny other reproduction or use is expressly prohibited.

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


2/19


Software Engineering: A Practitioners Approach,Software Engineering: A Practitioners Approach,

6/e6/e

Chapter 21Chapter 21

Project Management ConceptsProject Management Concepts

copyright 1996, 2001, 2005

R.S. Pressman & Associates, Inc.

For University Use Only

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


3/19


The 4 PsThe 4 Ps

PeoplePeople the most important element of a the most important element of asuccessful 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 donesoftware engineering tasks to get the job done ProjectProject all work required to make the product a all work required to make the product a

realityreality


4/19


StakeholdersStakeholders

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

Project (technical) managersProject (technical) managerswho 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.


5/19


Software TeamsSoftware Teams

How to lead?How to organize?

How to motivate?

How to collaborate?

How to create good ideas?


6/19


Team LeaderTeam Leader

The MOI ModelThe MOI Model Motivation.Motivation. The ability to encourage (by push or pull)The ability to encourage (by push 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 invent

new ones) that will enable the initial concept to be translatednew ones) that will enable the initial concept to be translatedinto a final product.into a final product.

Ideas or innovation.Ideas or innovation. The ability to encourage people to createThe ability to encourage people to createand 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.


7/19


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 function pointsthe size of the resultant program(s) in lines of code or function points the 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 modularized

the required quality and reliability of the system to be builtthe required quality and reliability of the system to be built

the rigidity of the delivery datethe rigidity of the delivery date the degree of sociability (communication) required for the projectthe degree of sociability (communication) required for the 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 ...


8/19


closed paradigmclosed paradigmstructures a team along a traditional hierarchy ofstructures a team along a traditional hierarchy ofauthorityauthority

random paradigmrandom paradigmstructures a team loosely and depends on individualstructures a team loosely and depends on individualinitiative of the team membersinitiative of the team members

open paradigmopen paradigmattempts to structure a team in a manner that achievesattempts to structure a team in a manner that achieves

some of the controls associated with the closed paradigm but also much ofsome of the controls associated with the closed paradigm but also much ofthe innovation that occurs when using the random paradigmthe innovation that occurs when using the random paradigm synchronous paradigmsynchronous paradigmrelies 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]


9/19


Avoid Team ToxicityAvoid Team Toxicity

A frenzied work atmosphere in which team members waste energy and losefocus 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 defined orimproperly chosen process model that becomes a roadblock toaccomplishment.

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

Continuous and repeated exposure to failure that leads to a loss ofconfidence and a lowering of morale.


10/19

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

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 the

problem.problem. Mavericks may have to be excluded from the team, ifMavericks may have to be excluded from the team, if

team cohesiveness is to be maintained.team cohesiveness is to be maintained. Team is self-organizingTeam is self-organizing

An adaptive team structureAn adaptive team structure Uses elements of Constantines random, open, and synchronousUses elements of Constantines random, open, and synchronous

paradigmsparadigms Significant autonomySignificant autonomy


11/19


Team Coordination & CommunicationTeam Coordination & Communication

Formal, impersonal approachesFormal, impersonal approaches include software engineering documents and workinclude software engineering documents and workproducts (including source code), technical memos, project milestones, schedules,products (including source code), technical memos, project milestones, schedules,and project control tools (Chapter 23), change requests and relatedand 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 and collocation of requirements anddissemination and problem solving and collocation 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 assist teamthose outside the project who may have experience or insight that can assist team

members.members.


12/19


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


13/19


Problem DecompositionProblem Decomposition

Sometimes calledpartitioning orproblem elaboration Once scope is defined

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

or It is decomposed into a set of problem classes

Decomposition process continues until all functions orproblem classes have been defined


14/19


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


15/19


Melding the Problem and the Process


16/19


The Project

Projects get into trouble when Projects get into trouble when Software people dont understand their customers needs.Software people dont understand their customers 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 learned.Managers [and practitioners] avoid best practices and lessons learned.


17/19


Common-Sense Approach to Projects

Start 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 teams way.everything possible to stay out of the teams 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 andthe software team should be to keep it simple.the software team should be to 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.


18/19


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 and

managerially?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


19/19


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

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

Documents

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