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 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 Project Management  Involves planning, monitoring, and control of the people, process, and events that occurs as software evolves from a preliminary concept to an operational implementation ++

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 Who does it?  Everyone…  (1) Software engineer manages day-to-day activities, planning, monitoring, and controlling technical tasks.  (2) Project managers plan, monitor, and control the work of a team of software engineers  (3) Senior managers coordinate the interface between the business and the software professionals ++

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

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

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 Project Management Concerns

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

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 PEOPLE The Players 1.Senior manages 2.Project (technical) managers 3.Practitioners 4.Customers 5.End-Users ++

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 PEOPLE MOI model of Leadership  Motivation  Organization  Ideas or Innovation By Jerry Wienberg ++

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 PEOPLE Characteristics that define an effective project managers  Problem Solving  Managerial Identity  Achievement – eg. Reward initiatives  Influence and team building – ability to “read” people ++

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

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 Team Organizations  Democratic Decentralized (DD) No permanent leader, decisions made by group consensus, communication is horizontal  Controlled Decentralized (CD) a defined leader, problem solving in group but implementation in subgroup, communication is horizontal and vertical  Controlled Centralized (CC) a defined leader, problem solving by team leader, communication vertical ++

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 Centralized vs Decentralized  Centralized structure completes task faster  suitable for small problems  Decentralized teams generate better solution than individuals  suitable for difficult problems  Large projects are best addressed by teams with CC or CD structures (subgrouping is easily accommodated)  DD is good for long term project (DD results in high morale)  DD is best applied for low modularity problems (higher volume of 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 Centralized vs Decentralized Findings:  Centralized produced fewer defects than DD teams  Decentralized teams generally require more time to complete ++

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  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]

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 Potentially toxic team environment  A frenzied work atmosphere  waste energy & lost focus  High frustration  Fragmented or poorly coordinated procedures/process model  Unclear definition of roles  Continuous and repeated exposure to failure ++

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 Coordination & Communication  Formal, impersonal approach deliverables, milestones, schedules, tools, change requests, error tracking reports, repository data  Formal, interpersonal procedures QA (review meeting, code inspections)  Informal, interpersonal procedures group meeting  Electronic communication , bulletin board, video conference  Interpersonal networking informal discussion with team members or outside experts ++

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 PRODUCT SOFTWARE SCOPE  Context  How it fit into the larger system, product or business context  Information objective  What is output & input  Function and performance ++

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 PRODUCT Project scope must be unambiguous and understandable Statement of scope must be bounded Quantitative data are stated explicitly (eg. Number of simultaneous users, size of mailing lists, maximum allowable response time) Constraint and/or limitation are noted (eg memory size) Mitigating factors are described (eg. Algorithm are well understood and available) ++

21 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 PRODUCT SOFTWARE DECOMPOSITION  The functionality  The process to deliver the software ++

22 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 Defining the Problem  establish scope—a narrative that bounds the problem  decomposition—establishes functional partitioning

23 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 PROCESS Framework activities  Customer communication  Planning  Risk analysis  Engineering  Construction and release  Customer evaluation ++

24 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 Problem and Process

25 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 Commonsense approach to software project 1.Start on the right foot – understand the problem, set realistic objectives 2.Maintain momentum – provide incentives, emphasize on quality, minimum bureaucracy 3.Track progress 4.Make smart decisions – keep it simple 5.Conduct a postmortem analysis ++

26 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? Barry Boehm W5HH Priciples

27 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