Project Management Concepts

Transcription

1 Project Management Concepts Software Engineering 3 1 Webster on Project Main Entry: proj ect Pronunciation: 'prä-"jekt, -jikt also 'pro- Function: noun Etymology: Middle English proiecte, from Medieval Latin projectum, from Latin, neuter of projectus, past participle of proicere to throw forward, from pro- + jacere to throw -- more at JET Date: 15th century 1 : a specific plan or design : SCHEME 2 obsolete : IDEA 3 : a planned undertaking: as a : a definitely formulated piece of research b : a large usually government-supported undertaking c : a task or problem engaged in usually by a group of students to supplement and apply classroom studies 4 : a usually public housing development consisting of houses or apartments built and arranged according to a single plan 2 SOE3 1

2 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 3 Factors that Software influence the end Projects result... size delivery deadline budgets and costs application domain technology to be implemented system constraints user requirements available resources 4 SOE3 2

3 Project Management Concerns product quality? risk assessment? measurement? cost estimation? project scheduling? customer communication? staffing? other resources? project monitoring? 5 Why Projects Fail? an unrealistic deadline is established changing customer requirements an honest underestimate of effort predictable and/or unpredictable risks technical difficulties miscommunication among project staff failure in project management 6 SOE3 3

4 The following factors Software must be considered Teams 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 7 Three Generic Team Organizations Democratic decentralized (DD) No permanent leader. Decisions by group consensus. Horizontal communication. Controlled decentralized (CD) Defined leader. Subgroups partitioned by group leader. Communication mostly horizontal, but vertical communication occurs. Controlled centralized (CC) Top-level problem solving. Coordination by team leader. Vertical communication. 8 SOE3 4

5 Organizational Paradigms 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 compartmentalization of a problem and organizes team members to work on pieces of the problem with little active communication among themselves suggested by Constantine 9 Project Characteristics vs. Team Structure Team type DD CD CC Difficulty high low low Size small large large Team lifetime long short short Modularity low high high Reliability high high low Delivery date lax lax strict Sociability high low low 10 SOE3 5

6 The Problem Software Scope a narrative that bounds the problem Context Information objectives Function and performance Problem Decomposition establishes functional partitioning 11 The Process Choice of software process model Appropriate for the software to be engineered by the team Melding the problem and the process Estimation of ressource requirements for each software engineering activity and for each funcion to be engineered Process decomposition From generic activities to actual work tasks 12 SOE3 6

7 Melding Problem and Process COMMON PROCESS FRAMEWORK ACTIVITIES customer communication planning risk analysis engineering Software Engineering Tasks Product Functions Text input Editing and formating Automatic copy edit Page layout capability Automatic indexing and TOC File management Document production 13 Process Modeling Perspectives Functional what is done Organizational who does it where it is done Behavioral when it is done how it is controlled Informational what information how it is related 14 SOE3 7

8 The Players Senior Managers Project Managers Practitioners Customers End users 15 Organisation - An Example Systematic Software Engineering Management Michael Holm Managing Director Alex Holm Jensen Deputy Director Finance Chris Chris Dahlerup Financial Financial Manager Manager Business Process Improvement Carsten Højmose Kristensen R&D R&D and and Consultancy Søren Rosenørn Defence Systems Jens Jens Peder Rasmussen Business Business Unit Unit Manager Manager Industrial Systems Kaj Kaj Ø. Ø. Jeppesen Business Business Unit Unit Manager Manager Command & Control Peter Peter Hundborg IRIS IRIS Interoperability Jeppe Nielsen EC EC // EDI EDI Rie Rie Søe Søe Lysgaard Key Key Accounts Air: OPUS CCIS IRIS - Message Format. EDItoolbox DSB Navy: RDN CCIS IMT - Data Modelling EDIsec Superfos Navy: RDN EWare X-Post EC/EDI projects Realkreditrådet F-16 Simulator Post Danmark Tele Danmark Internet Landbr. Rådgiv.center Den Danske Bank 16 SOE3 8

9 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 17 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 18 SOE3 9