Transparency Masters for Software Engineering: A Practitioner's ...

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

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.


The 4 P’s in Mgmt SpectrumThe 4 P’s in Mgmt Spectrum

People:People: The most important element of a successful project.The most important element of a successful project. Organizations that achieve high levels of maturity in the people management area Organizations that achieve high levels of maturity in the people management area

have a higher likelihood of implementing effective S.E. practices.have a higher likelihood of implementing effective S.E. practices. ProductProduct::

The software to be built.The software to be built. The S/W developer and customer must meet to define product objectives and scope.The S/W developer and customer must meet to define product objectives and scope. Objectives identify the overall goals for the product “customer’s viewpoint” without Objectives identify the overall goals for the product “customer’s viewpoint” without

considering how the goals will be achieved.considering how the goals will be achieved. Scope identifies the primary data, functions, and behaviors that characterize the Scope identifies the primary data, functions, and behaviors that characterize the

product.product. Once objectives and scope are understood, alternative solutions are considered. Once objectives and scope are understood, alternative solutions are considered.

Process:Process: The set of framework activities and software engineering tasks “milestones, Q.A.” to The set of framework activities and software engineering tasks “milestones, Q.A.” to

get the job done.get the job done. Project:Project:

All work required to make the product a reality.All work required to make the product a reality. Industry indicated that Industry indicated that 26%26% of S/W projects failed outright and of S/W projects failed outright and 46%46% experienced cost experienced cost

and schedule overruns.and schedule overruns.


PeoplePeople

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

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

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

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

End-users:End-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.

1. The Stakeholders:


Software TeamsSoftware Teams

How to lead?

How to organize?

How to motivate?

How to collaborate?

How to create good ideas?


2. Team Leaders:2. Team Leaders:

The MOI Model “Jerry Weinberg”The MOI Model “Jerry Weinberg” Motivation.Motivation. The ability to encourage (by “push or pull”) technical people to The ability to encourage (by “push or pull”) technical people to

produce to their best ability.produce to their best ability. Organization.Organization. The ability to mold existing processes (or invent new ones) that The ability to mold existing processes (or invent new ones) that

will enable the initial concept to be translated into a final product.will enable the initial concept to be translated into a final product. Ideas or innovation.Ideas or innovation. The ability to encourage people to create and feel The ability to encourage people to create and feel

creative even when they must work within bounds established for a particular creative even when they must work within bounds established for a particular software product or application.software product or application.

The Software project manager should concentrate on understanding the The Software project manager should concentrate on understanding the problem to be solved.problem to be solved.

The project manager must let the team know that quality counts and that it will The project manager must let the team know that quality counts and that it will not be compromised.not be compromised.

The project manager must take charge of the project and allow good technical The project manager must take charge of the project and allow good technical people to follow their instincts.people to follow their instincts.

A manager must reward initiative and accomplishment and demonstrate A manager must reward initiative and accomplishment and demonstrate through his own actions that controlled risk taking will not be punished.through his own actions that controlled risk taking will not be punished.

An effective manager must be able to read people; he/she must be able to An effective manager must be able to read people; he/she must be able to understand verbal and nonverbal signals and react to the needs of people understand verbal and nonverbal signals and react to the needs of people sending these signals.sending these signals.

The manager must remain under control in high-stress situations.The manager must remain under control in high-stress situations.


3. Software Teams3. Software 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 ““if you want to be incrementally better: Be competitive. If you want to be if you want to be incrementally better: Be competitive. If you want to be

exponentially better: Be cooperative”exponentially better: Be cooperative”

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

“Not every group is a team, and not every team is effective.” Glenn Parker


closed paradigmclosed paradigm: : structures a team along a traditional hierarchy of authority. structures a team along a traditional hierarchy of authority. Such teams can work well when producing S/W that is quite similar to past efforts, but they Such teams can work well when producing S/W that is quite similar to past efforts, but they

will be less likely to be innovative when working within the closed paradigm.will be less likely to be innovative when working within the closed paradigm. random paradigmrandom paradigm::

structures a team loosely and depends on individual initiative of the team members.structures a team loosely and depends on individual initiative of the team members. When innovation or technological breakthrough is required, team following the random When innovation or technological breakthrough is required, team following the random

paradigm will excel.paradigm will excel. But such teams may struggle when “Orderly Performance” is required.But such teams may struggle when “Orderly Performance” is required.

open paradigmopen paradigm:: attempts to structure a team in a manner that achieves some of the controls associated with attempts to structure a team in a manner that achieves some of the controls associated with

the closed paradigm but also much of the innovation that occurs when using the random the closed paradigm but also much of the innovation that occurs when using the random paradigm.paradigm.

Work is performed collaboratively. Heavy communication and consensus-based decision Work is performed collaboratively. Heavy communication and consensus-based decision making are the trademarks of open paradigm teams.making are the trademarks of open paradigm teams.

Open paradigm team structure are well suited to the solution of complex problems but may Open paradigm team structure are well suited to the solution of complex problems but may not perform as efficiently as other teams. not perform as efficiently as other teams.

synchronous paradigm:synchronous paradigm: relies on the natural compartmentalization of a problem and organizes team members to relies on the natural compartmentalization of a problem and organizes team members to

work on pieces of the problem with little active communication among themselves.work on pieces of the problem with little active communication among themselves.

““Working with people is difficult but not impossible.” Peter DruckerWorking with people is difficult but not impossible.” Peter Drucker

Organizational Organizational ParadigmsParadigms


One of the earliest S/W structures was a closed paradigm structure originally One of the earliest S/W structures was a closed paradigm structure originally called called chief programmer team. chief programmer team. The nucleus of the teams is composed of:The nucleus of the teams is composed of:

AA Senior Engineer Senior Engineer that plans, coordinates, and reviews all technical that plans, coordinates, and reviews all technical activities of the team.activities of the team.

A TA Technical Staffechnical Staff (2 – 5 people), that conduct analysis and development (2 – 5 people), that conduct analysis and development activities.activities.

A BA Backup Engineerackup Engineer that supports the senior engineer in his activities and that supports the senior engineer in his activities and can replace the Senior Engineer with minimum loss of project continuity.can replace the Senior Engineer with minimum loss of project continuity.

A jelled team is a group of people so strongly know that the whole is greater A jelled team is a group of people so strongly know that the whole is greater than the sum of parts.than the sum of parts.

Members of jelled teams are significantly more productive and more motivated Members of jelled teams are significantly more productive and more motivated than average.than average.

They share a common goal, a common culture, and in many cases, a “sense of They share a common goal, a common culture, and in many cases, a “sense of eliteness” that makes them unique.eliteness” that makes them unique.

But not all teams jell. In fact, many teams suffer from “team toxicity.”But not all teams jell. In fact, many teams suffer from “team toxicity.”


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

To avoid a frenzied work environment, the manager should be certain that To avoid a frenzied work environment, the manager should be certain that the team has access to all information required to do the job and that the team has access to all information required to do the job and that major goals and objectives, once defined, should not be modified unless major goals and objectives, once defined, should not be modified unless absolutely necessaryabsolutely necessary..

““Do or do not, There is no try.” Do or do not, There is no try.” YodaYoda from Star Wars. from Star Wars. Teams often struggle with the differing human traits of their members.Teams often struggle with the differing human traits of their members. Some team members are extroverted; others are introverted.Some team members are extroverted; others are introverted.


Some people gather information intuitively, distilling broad concepts from Some people gather information intuitively, distilling broad concepts from dissimilar facts.dissimilar facts.

Others process information linearly, collecting and organizing minute Others process information linearly, collecting and organizing minute details from the data provided.details from the data provided.

Some team members are comfortable making decisions only when a Some team members are comfortable making decisions only when a logical, orderly argument is presented.logical, orderly argument is presented.

Others are intuitive, willing to make a decision based on “feel”.Others are intuitive, willing to make a decision based on “feel”. Some practitioners want a detailed schedule populated by organized tasks Some practitioners want a detailed schedule populated by organized tasks

that enable them to achieve closure for some element of a project.that enable them to achieve closure for some element of a project. Others prefer a more spontaneous environment in which open issues are Others prefer a more spontaneous environment in which open issues are

OK.OK. Some work hard to get things done long before a milestone date, thereby Some work hard to get things done long before a milestone date, thereby

avoiding stress as the date approaches, while others are energized by the avoiding stress as the date approaches, while others are energized by the rush to make a last minute deadline.rush to make a last minute deadline.

It is important to note that recognition of human differences is the first It is important to note that recognition of human differences is the first step toward creating teams that jell. step toward creating teams that jell.


4. Agile Teams4. Agile 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 problem. The distribution of skills must be appropriate to the problem. Mavericks may have to be excluded from the team, if team cohesiveness is to Mavericks may have to be excluded from the team, if team cohesiveness is to

be maintained.be maintained. Team is “self-organizing”Team is “self-organizing”

An adaptive team structureAn adaptive team structure Uses elements of random, open, and synchronous paradigmsUses elements of random, open, and synchronous paradigms Significant autonomySignificant autonomy

The agile philosophy stresses individual competency coupled with group The agile philosophy stresses individual competency coupled with group collaboration as critical success factors for the team.collaboration as critical success factors for the team.

““Collective ownership is nothing more than an instantiation of the idea that Collective ownership is nothing more than an instantiation of the idea that products should be attributable to the team, not individuals who make up the products should be attributable to the team, not individuals who make up the team.” team.” Jim HighsmithJim Highsmith


5.Team Coordination & Communication5.Team Coordination & Communication

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, change requests and related documentation, error tracking reports, change requests and related documentation, error tracking reports, and repository data. and repository data.

Formal, interpersonal proceduresFormal, interpersonal procedures focus on quality assurance activities focus on quality assurance activities applied to software engineering work products. These include status applied to software engineering work products. These include status review meetings and design and code inspections.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

1. Software Scope1. Software Scope 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 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.

A statement of software scope must be bounded “bounds the features of the software.”


2. Problem Decomposition2. Problem Decomposition

Sometimes called partitioning or problem elaboration: An activity that sits at the core of S/W requirements analysis. During the scoping activity no attempt is made to fully decompose the problem. Decomposition is applied in:

The functionality that must be delivered.

The process that will be used to deliver it. 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

The manager must decide which process model is most appropriate for:The manager must decide which process model is most appropriate for: The customers who have requested the product and the people who will do the The customers who have requested the product and the people who will do the

work.work. The characteristics of the product itselfThe characteristics of the product itself The project environment in which the S/W team works.The project environment in which the S/W team works.

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


Process DecompositionProcess Decomposition

Process decomposition commences when the manager asks. “how do we Process decomposition commences when the manager asks. “how do we accomplish this framework activity?” accomplish this framework activity?”

For example, a small, relatively simple project might require the following For example, a small, relatively simple project might require the following work tasks for the communication activity:work tasks for the communication activity:

Develop list of clarification issues.Develop list of clarification issues. Meet with customer to address clarification issues.Meet with customer to address clarification issues. Jointly develop a statement of scope.Jointly develop a statement of scope. Review the statement of scope with all concerned.Review the statement of scope with all concerned. Modify the statement of scope as required.Modify the statement of scope as required.


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.


How does a manager act to avoid the problems just noted?

1.1. Start on the right foot.Start on the right foot. This is accomplished by working hard (very hard) to understand the problem This is accomplished by working hard (very hard) to understand the problem

that is to be solved and then setting realistic objectives and expectations. that is to be solved and then setting realistic objectives and expectations. 2.2. Maintain momentum.Maintain momentum.

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

3.3. Track progress.Track progress. For a software project, progress is tracked as work products (e.g., models, For a software project, progress is tracked as work products (e.g., models,

source code, sets of test cases) are produced and approved (using formal source code, sets of test cases) are produced and approved (using formal technical reviews) as part of a quality assurance activity. technical reviews) as part of a quality assurance activity.

4.4. Make smart decisions.Make smart decisions. In essence, the decisions of the project manager and the software team should In essence, the decisions of the project manager and the software team should

be to “keep it simple.” Decide to allocate more time to identify and then avoid be to “keep it simple.” Decide to allocate more time to identify and then avoid obvious risks, and decide to allocate more time than you think is needed to obvious risks, and decide to allocate more time than you think is needed to complex or risky tasks (you’ll need every second.)complex or risky tasks (you’ll need every second.)

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

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

database) will be needed?database) will be 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

Transparency Masters for Software Engineering: A Practitioner's ...

Documents