Supplementary Slides for

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

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. This presentation, slides, or hardcopy may NOT be used for short courses, industry seminars, or consulting purposes.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005

Software Engineering: A Practitioners Approach, 6/e

Chapter 21 Project Management Concepts

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.

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

The 4 Ps in Mgmt Spectrum

People:

The most important element of a successful project. Organizations that achieve high levels of maturity in the people management area have a higher likelihood of implementing effective S.E. practices. The software to be built. The S/W developer and customer must meet to define product objectives and scope. Objectives identify the overall goals for the product customers viewpoint without considering how the goals will be achieved. Scope identifies the primary data, functions, and behaviors that characterize the product. Once objectives and scope are understood, alternative solutions are considered. The set of framework activities and software engineering tasks milestones, Q.A. to get the job done. All work required to make the product a reality. Industry indicated that 26% of S/W projects failed outright and 46% experienced cost and schedule overruns.

Product:

Process:

Project:

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

People
1. The Stakeholders:

Senior managers: who define the business issues that often have significant influence on the project. Project (technical) managers: who must plan, motivate, organize, and control the practitioners who do software work. Practitioners: who deliver the technical skills that are necessary to engineer a product or application. Customers: who specify the requirements for the software to be engineered and other stakeholders who have a peripheral interest in the outcome. End-users: who interact with the software once it is released for production use.

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

Software Teams
How to lead? How to organize? How to collaborate?

How to motivate?

How to create good ideas?

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

2. Team Leaders:

The MOI Model Jerry Weinberg

Motivation. The ability to encourage (by push or pull) technical people to produce to their best ability. Organization. The ability to mold existing processes (or invent new ones) that will enable the initial concept to be translated into a final product. Ideas or innovation. The ability to encourage people to create and feel creative even when they must work within bounds established for a particular software product or application. The Software project manager should concentrate on understanding the problem to be solved. The project manager must let the team know that quality counts and that it will not be compromised. The project manager must take charge of the project and allow good technical people to follow their instincts. A manager must reward initiative and accomplishment and demonstrate 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 understand verbal and nonverbal signals and react to the needs of people sending these signals. The manager must remain under control in high-stress situations.

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

3. Software Teams Not every group is a team, and not every team is effective. Glenn Parker The following factors must be considered when selecting a software project team structure ...

The difficulty of the problem to be solved The size of the resultant program(s) in lines of code or function points The time that the team will stay together (team lifetime) The degree to which the problem can be modularized The required quality and reliability of the system to be built The rigidity of the delivery date The degree of sociability (communication) required for the project if you want to be incrementally better: Be competitive. If you want to be exponentially better: Be cooperative

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

Organizational Paradigms

closed paradigm:

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 will be less likely to be innovative when working within the closed paradigm. structures a team loosely and depends on individual initiative of the team members. When innovation or technological breakthrough is required, team following the random paradigm will excel. But such teams may struggle when Orderly Performance is required. 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 paradigm. Work is performed collaboratively. Heavy communication and consensus-based decision making are the trademarks of open paradigm teams. Open paradigm team structure are well suited to the solution of complex problems but may not perform as efficiently as other teams. 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.

random paradigm:

open paradigm:

synchronous paradigm:

Working with people is difficult but not impossible. Peter Drucker

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

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

A Senior Engineer that plans, coordinates, and reviews all technical activities of the team. A Technical Staff (2 5 people), that conduct analysis and development activities. A Backup Engineer that supports the senior engineer in his activities and 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 than the sum of parts. Members of jelled teams are significantly more productive and more motivated than average. They share a common goal, a common culture, and in many cases, a sense of eliteness that makes them unique. But not all teams jell. In fact, many teams suffer from team toxicity.

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

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 fingerpointing. 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 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 absolutely necessary. Do or do not, There is no try. Yoda from Star Wars. Teams often struggle with the differing human traits of their members. Some team members are extroverted; others are introverted.

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

10

Some people gather information intuitively, distilling broad concepts from dissimilar facts. Others process information linearly, collecting and organizing minute details from the data provided. Some team members are comfortable making decisions only when a logical, orderly argument is presented. Others are intuitive, willing to make a decision based on feel. Some practitioners want a detailed schedule populated by organized tasks that enable them to achieve closure for some element of a project. Others prefer a more spontaneous environment in which open issues are OK. 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 rush to make a last minute deadline. It is important to note that recognition of human differences is the first step toward creating teams that jell.

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

11

4. Agile Teams

Team members must have trust in one another. The distribution of skills must be appropriate to the problem. Mavericks may have to be excluded from the team, if team cohesiveness is to be maintained. Team is self-organizing An adaptive team structure Uses elements of random, open, and synchronous paradigms Significant autonomy The agile philosophy stresses individual competency coupled with group collaboration as critical success factors for the team. 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 team. Jim Highsmith

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

12

5.Team Coordination & Communication

Formal, impersonal approaches include software engineering documents and work products (including source code), technical memos, project milestones, schedules, and project control tools, change requests and related documentation, error tracking reports, and repository data. Formal, interpersonal procedures focus on quality assurance activities applied to software engineering work products. These include status review meetings and design and code inspections. Informal, interpersonal procedures include group meetings for information dissemination and problem solving and collocation of requirements and development staff. Electronic communication encompasses electronic mail, electronic bulletin boards, and by extension, video-based conferencing systems. Interpersonal networking includes informal discussions with team members and those outside the project who may have experience or insight that can assist team members.

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

13

The Product Scope

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

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

14

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

Once scope is defined

It is decomposed into constituent functions It is decomposed into user-visible data objects It is decomposed into a set of problem classes

or

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

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

15

The Process

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 work. The characteristics of the product itself The project environment in which the S/W team works.

Once a process framework has been established Consider project characteristics Determine the degree of rigor required Define a task set for each software engineering activity Task set = Software engineering tasks Work products Quality assurance points Milestones

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

16

Melding the Problem and the Process

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

17

Process Decomposition

Process decomposition commences when the manager asks. how do we accomplish this framework activity? For example, a small, relatively simple project might require the following work tasks for the communication activity: Develop list of clarification issues. Meet with customer to address clarification issues. Jointly develop a statement of scope. Review the statement of scope with all concerned. Modify the statement of scope as required.

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

18

The Project

Projects get into trouble when

Software people dont understand their customers needs. The product scope is poorly defined. Changes are managed poorly. The chosen technology changes. Business needs change [or are ill-defined]. Deadlines are unrealistic. Users are resistant. Sponsorship is lost [or was never properly obtained]. The project team lacks people with appropriate skills. Managers [and practitioners] avoid best practices and lessons learned.

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

19

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

Start on the right foot.

This is accomplished by working hard (very hard) to understand the problem that is to be solved and then setting realistic objectives and expectations. The project manager must provide incentives to keep turnover of personnel to an absolute minimum, the team should emphasize quality in every task it performs, and senior management should do everything possible to stay out of the teams way.

2.

Maintain momentum.

3.

Track progress.

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 technical reviews) as part of a quality assurance activity.
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 obvious risks, and decide to allocate more time than you think is needed to complex or risky tasks (youll need every second.) Establish a consistent mechanism for extracting lessons learned for each project.

4.

Make smart decisions.

5.

Conduct a postmortem analysis.

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

20

To Get to the Essence of a Project

Why is the system being developed? What will be done? When will it be accomplished? Who is responsible? Where are they organizationally located? How will the job be done technically and managerially? How much of each resource (e.g., people, software, tools, database) will be needed?

Barry Boehm

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

21

Critical Practices

Formal risk management Empirical cost and schedule estimation Metrics-based project management Earned value tracking Defect tracking against quality targets People aware project management

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

22