1. 1 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. Chapter 24 Project Management Concepts Slide Set to accompany Software Engineering: A Practitioner’s Approach, 7/e by Roger S. Pressman Slides copyright © 1996, 2001, 2005, 2009 by Roger S. Pressman For non-profit educational use only May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach, 7/e. Any other reproduction or use is prohibited without the express written permission of the author. All copyright information MUST appear if these slides are posted on a website for student use.

2. The Importance of Software Project Management Building computer software is complex, particularly if it involves many people working over a relatively long time. That is why software projects need to be managed. 2 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

3. 3 The Four P’s Effective software project management focuses on the four P’s: People — the most important element of a successful project Product — the software to be built Process — the set of framework activities and software engineering tasks to get the job done Project — all work required to make the product a reality

4. 4 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. The People People must be organized to perform software work effectively. The “people factor” is so important that the Software Engineering Institute has developed People Capability Maturity Model (People-CMM). People-CMM defines key practice areas like staffing, communication and coordination, work environment, training, career development, team/ culture development and many more. Organizations that have a higher levels of People-CMM have a higher likelihood of implementing effective software project management practice.

5. 5 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. People: 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.

6. 6 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. People: Team Leader The MOI Model of leadership: 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.

7. 7 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. People: Software Teams How to lead? How to organize? How to motivate? How to collaborate? How to create good ideas?

8. 8 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. People: Software Teams 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 The following factors must be considered when selecting a software project team structure...

9. 9 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. People: Agile Teams Agile teams are formed for agile software development. Agile philosophy encourages customer satisfaction and early incremental delivery of software, small highly motivated project teams, informal methods, minimal software engineering work products, and overall development simplicity. The distribution of skills must be appropriate to the problem. Mavericks (individualist) may have to be excluded from the team, if team cohesiveness is to be maintained. Agile teams are self-organizing.

10. 10 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. People: Coordination and Communication Issues Reasons for software projects get into trouble: Scale- the scale of many development efforts is large, leading to complexity, confusion, and significant difficulties in coordinating team members. Uncertainty- resulting in a continuing stream of changes Interoperability- new software must communicate with existing software and conform to predefined constraints imposed by the system or product.

11. 11 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. People: Coordination and Communication Issues Formal and informal communication among team members and between multiple teams must be established. Formal communication – writing, structured meetings, and other non-interactive and impersonal communication channel. Informal communication – more personal. Members share ideas on an ad hoc basis.

12. 12 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. The Product Communication with the customer and other stakeholders must occur so that product scope and requirements are understood. Alternative solutions and technical and management constraints should also be identified. The alternative solutions enable the managers and practitioners to select a “best” approach, given the constraints imposed by delivery deadlines, budgetary restrictions, personnel availability and other factors.

13. 13 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. Product: The Product Scope Scope is defined by answering the following questions: 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.

14. 14 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. Product: Problem Decomposition Sometimes called partitioning or problem elaboration. A complex problem is partitioned into smaller problems that are more manageable.

15. 15 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. The Process A process that is appropriate for the people and the product should be selected.

16. 16 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. Process: Melding the Product and the Process

17. 17 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. Process: Melding the Product and the Process Refer to figure shown in previous slide. The job of the project manager (and other team members) is to estimate resource requirements for each matrix cell, start and end dates for the tasks associated with each cell, and work products to be produced as a consequence of each task.

18. 18 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. Process: Project Decomposition Factors that you need to look at when choosing the process model: 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 software team works

19. 19 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. Process: Project Decomposition Example of type of project and suitable approach: A relatively small project that is similar to past efforts - linear sequential approach might be suitable The deadline is so tight that full functionality cannot reasonably be delivered – incremental approach might be suitable

20. 20 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. The Project The project must be planned by estimating effort and calendar time to accomplish work tasks. Some of the required activities: defining work products, establishing quality checkpoints, and identifying mechanisms to monitor and control work defined by the plan.

21. 21 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. The Project Projects get into trouble when … Software people don’t understand their customer’s 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.

22. 22 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. Project: Common-Sense Approach to Projects How does a manager act to avoid problems discussed before? 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. Maintain momentum. 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 team’s way. Refer to footer (page 660) for the implication of above underlined statement.

23. 23 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. Project: Common-Sense Approach to Projects 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. Make smart decisions. In essence, the decisions of the project manager and the software team should be to “keep it simple.” Conduct a postmortem analysis. Establish a consistent mechanism for extracting lessons learned for each project.

24. 24 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. Project: The W 5 HH Principle W 5 HH Principle- a series of questions that lead to a definition of key project characteristics and the resultant project plan.

25. 25 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. Project: The W 5 HH Principle 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 [Boe96]

26. 26 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. Critical Practices Example of practices that is important in software project management: Metrics-based project management Measures of specific attributes of the process, project, and product are used to compute software metrics. These metrics can be analyzed to provide indicators that guide management and technical actions. Empirical cost and schedule estimation Estimate how much money, effort, resources (people, hardware, software), risks, and time that will take to build a system.

27. 27 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. Critical Practices Defect tracking against quality target Requires that quality targets be set and that tracked defects be analyzed against those targets. Involve activities like recording defects in a database; following a documented process to analyze, resolve, and remove them; tracking the process; measuring defects against quality targets; and reporting metrics on the process to program management.

28. 28 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. Critical Practices Example of quality measures with examples of target values, are as follows: Number of defects (a measure of reliability): less than 1 defect per function point Cyclomatic Complexity (McCabe's): less than 10 for all modules Operator errors: Less than 5 per day Time to restore: less than 1 hour Timing: less than 1 second response time Fault tolerance: at least 80% of failures circumvented Reference: https://goldpractice.thedacs.com/practices/gp_28.php https://goldpractice.thedacs.com/practices/gp_28.php

29. 29 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. Critical Practices Earned value tracking Quantitative technique for assessing progress as the software team progresses through the work tasks allocated to the project schedule. People aware management Management of people that involve in project.