1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e copyright © 1996, 2001 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.

2 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Chapter 3 Project Management

3 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 The 4 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 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Software Projects size delivery deadline budgets and costs application domain technology to be implemented system constraints user requirements available resources Factors that influence the end result...

5 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Project Management Concerns

6 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Why Projects Fail? an unrealistic deadline is established an unrealistic deadline is established changing customer requirements changing customer requirements an honest underestimate of effort an honest underestimate of effort predictable and/or unpredictable risks predictable and/or unpredictable risks technical difficulties technical difficulties miscommunication among project staff miscommunication among project staff failure in project management failure in project management

7 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 The People  Recruiting  Selection  Performance management  Training  Compensation  Career development  Organization and work design  Team/culture development Key practice areas for the people management capability maturity model (PM-CMM) :

8 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 The People  If you had to pick one thing out, it’s not the tools that we use, it’s the people.  The most important ingredient that was successful on this project was having smart people … the most important thing you do for a project is selecting the staff.  The only rule I have in management is to ensure I have good people and that I provide an environment in which good people can produce. The most important contributor to a successful software project as engineering vice presidents of three major companies described :

9 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 The Players  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 and other stakeholders who have a peripheral interest in the outcome.  End-users: who interact with the software.

10 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 The Leaders  Motivation: to encourage technical people to produce to their best ability.  Organization: to mold existing processes that will enable the initial concept to translated into a final product.  Ideas or innovation: to encourage people to create and feel creative when they must work within bounds established for a particular product. The MOI model of leadership:

11 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 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...

12 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Three generic team organization  Democratic decentralized (DD). Has no permanent leader. Task coordinators are appointed for short durations. Decisions on problems and approaches are made by group consensus.  Controlled decentralized (CD): Has a defined team leader who coordinates specific tasks and secondary leaders for subtasks. Problem solving remains a group activity, but implementation partitioned by team leader.  Controlled centralized (CC): Has a team leader who manages problem solving and internal team coordination.

13 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001  closed paradigm—structures a team along a traditional hierarchy of authority (similar to a CC team)  random paradigm—structures a team loosely and depends on individual initiative of the team members  open paradigm—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  synchronous paradigm—relies on the natural compartment- alization of a problem and organizes team members to work on pieces of the problem with little active communication among themselves Organizational Paradigms suggested by Constantine [CON93]

14 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001  Formal impersonal approaches —include software engineering documents and deliverables, technical memos, project milestones, schedules, and project control tools, …  Formal, interpersonal procedures —focus on quality assurance activities applied to software engineering work products, status review meetings and design and code inspection.  Informal interpersonal procedure —include group meetings for information dissemination and problem solving.  Electronic communication —encompasses electronic mail, electronic bulletin boards, video-based conferencing systems.  Interpersonal networking —includes informal discussions with team members and those outside that can assist team members. Coordination and Communication

15 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 The Product  Establish scope—answering these: Context. Information objectives. Function and performance.  Decomposition—establishes functional partitioning. Defining the Problem

16 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001  Linear sequential model  Prototyping model  RAD model  Incremental model  Spiral model  WINWIN spiral model  Component-based development model  Concurrent development model  Formal methods model  4GT model The Process

17 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Melding Product and Process

18 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001  Start on the right foot. Working hard to understand the problem that is to be solved, and setting realistic objects and expectations, building the right team and giving the team autonomy, authority, and technology needed.  Maintain momentum. The team should emphasize quality in every task it performs.  Track progress. Progress is tracked as work products are approved as part of a quality assurance activity.  Make smart decisions. Keep it simple. Decide to use commercial off- the-shelf software or existing software components. Avoid the risks and allocate more time than you think is needed to complex or risky tasks.  Conduct a postmortem analysis. Extract lessons learned for each project, evaluate the planned and actual schedules, analyze software project metrics, get feedback from team members and customers, and record them. The Project To avoid the problems :

19 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 To Get to the Essence of a Project  Why is the system being developed?  What will be done? By when?  Who is responsible for a function?  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? The W5HH principle of Barry Boehm

20 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Critical Practices  Formal risk analysis  Empirical cost and schedule estimation  Metrics-based project management  Earned value tracking  Defect tracking against quality targets  People aware project management