Software Project Management Chapter 1 PDF

SE 482 Software Project Management Chapter 1: Introduction Adapted From The Lecture Slides for Managing and Leading Software Projects developed by Richard E. (Dick) Fairley, Ph.D. to accompany the text:...

SE 482 Software Project Management Chapter 1: Introduction Adapted From The Lecture Slides for Managing and Leading Software Projects developed by Richard E. (Dick) Fairley, Ph.D. to accompany the text: Managing and Leading Software Projects published by Wiley, 2009 Managing and Leading Software Projects, chapter 1 by R. Fairley, © Wiley, 2009 slide 1-1  Topics ▪ Why Managing and Leading Software Projects Is Difficult ▪ The Nature of Project Constraints ▪ A Workflow Model for Managing Software Projects ▪ Organizational Structures for Software Projects ▪ Organizing the Project Team ▪ Maintaining the Project Vision and the Product Vision ▪ Frameworks, Standards, and Guidelines Managing and Leading Software Projects, chapter 1 by R. Fairley, © Wiley, 2009 slide 1-2 What is a Project? A project is characterized as follows: a one-time effort is planned starting and ending dates are prescribed a project team is assembled schedule and budget are allocated well-defined objectives are established roles are identified, responsibilities are assigned, and authority is delegated Software projects are temporary organizational units Managing and Leading Software Projects, by R. Fairley, © Wiley, 2009 chapter 1 slide 1-6  What is Management? Management is concerned with planning and coordinating the work activities of others so that they can achieve goals that cannot be achieved by each individual acting alone Managing and Leading Software Projects, chapter 1 by R. Fairley, © Wiley, 2009 slide 1-7 What is Software Project Management? Software Project Management (SPM) is the art and science of planning and coordinating the work of software developers and other personnel to develop and modify software artifacts that: ▪ are pleasing to users and customers ▪ are developed and modified in an economical and timely manner ▪ and that can be maintained efficiently and effectively Managing and Leading Software Projects, chapter 1 by R. Fairley, © Wiley, 2009 slide 1-8 The Four Major Activities of SPM 1. Planning and Estimating ▪ identify work activities ▪ prepare a schedule ▪ prepare a budget 2. Measuring and Controlling ▪ requirements ▪ quality and productivity ▪ schedule and budget ▪ product evolution 3. Leading and Communicating ▪ motivating / coaching / educating project members ▪ communicating with management, customers, ▪ subcontractors, other projects 4. Managing Risk ▪ identifying and confronting potential problems Managing and Leading Software Projects, chapter 1 by R. Fairley, © Wiley, 2009 slide 1-9 Managing versus Leading Managing is concerned with the quantitative aspects of SPM: ▪ planning and estimating ▪ measuring and controlling ▪ quantitative risk management Leading is concerned with the qualitative aspects of SPM: ▪ communicating and coordinating ▪ inspiring and maintaining morale Should a project ▪ qualitative risk management manager be a manager or a leader? An effective project manager is both a manager and a leader! Managing and Leading Software Projects, chapter 1 by R. Fairley, © Wiley, 2009 slide 1-10 Project Success Criteria The primary goal of S/W engineering is to develop and modify S/W, where: ▪ the product satisfies technical requirements, user needs & expectations ▪ the product is delivered on time & within budget ▪ development milestones are achieved on time & within budget ▪ the product is easy to modify and maintain ▪ staff morale is high throughout project work instills pride in the developers Managing and Leading Software Projects, by R. Fairley, © Wiley, 2009 chapter 1 slide 1-11 Project Manager’s Success Criteria ▪ delivery of an acceptable product on time and within budget within the limits imposed by project constraints ▪ maintaining good relations with customers, suppliers, managers, and other organizational units ▪ maintaining a motivated project team ▪ advancing the career of each project member advancing his or her career ▪ Other criteria? Managing and Leading Software Projects, by R. Fairley, © Wiley, 2009 chapter 1 slide 1-12 Why Are Software Projects Difficult? ▪ According to Fred Brooks*, software projects are difficult because of accidental and essential difficulties. ▪ Accidental difficulties are caused by the current state of our understanding of methods, tools, and techniques of the underlying technology base. ▪ Essential difficulties are caused by the inherent nature of software. There are four essential properties of software differentiate it from other kinds of engineering artifacts and make software projects difficult: Complexity, Conformity, Changeability, and Invisibility of software. * The Mythical Man-Month by Fred Brooks, Addison Wesley, 1995 Managing and Leading Software Projects, chapter 1 by R. Fairley, © Wiley, 2009 slide 1-13 Essential Difficulties ▪ Complexity The complexity of software arises from the large number of unique, interacting parts in a software system. ▪ Conformity Software must conform to exacting specifications in the representation of each part, in the interfaces to other internal parts, and in the connections to the environment in which it operates. ▪ Changeability Changes may occur because customers change their minds; competing products change; mission objectives change; laws, regulations, and business practices change,........etc. Managing and Leading Software Projects, chapter 1 by R. Fairley, © Wiley, 2009 slide 1-14 Essential Difficulties – Cont. ▪ Invisibility ▪ Software has no physical properties. ▪ software products under development are often reported to be “ almost complete ” for long periods of time with no evidence. ▪ Many software projects have been cancelled after large investments of effort, time, and money, because no one could objectively determine the status of the work products or provide a credible estimate of a completion date or the cost to complete the project. Managing and Leading Software Projects, chapter 1 by R. Fairley, © Wiley, 2009 slide 1-15 Additional Difficulties Additional reasons software projects are difficult are: ▪ Intellect-intensive, team-oriented nature of the work Software is developed by teams of individuals engaged in creative problem solving activities. The team may pursue a “plan-driven” approach or an “agile” approach. Most successful S/W projects incorporate aspects of both planning and agility ▪ Externally imposed constraints ▪ Platforms, software tools, hardware,…etc. ▪ Process standards ▪ Business considerations ▪ Ethical considerations ▪ … ▪ Others? Managing and Leading Software Projects, chapter 1 by R. Fairley, © Wiley, 2009 slide 1-15 More About Constraints… Useful constraints provide guidance. For example, well-defined requirements are the basis for planning, estimating, and establishing success criteria. Inhibiting constraints inhibit the ability to achieve success criteria. For example, excessive schedule pressure may inhibit the ability to deliver a product of high quality. Some of the most difficult problems or challenges you will encounter in managing software projects arise from establishing and maintaining a balance among the constraints on: ▪ Scope (the work to be done ), ▪ Budget ( the money to acquire resources), ▪ Resources ( the assets available to do the job), ▪ Technology ( methods and tools to be used), and ▪ Scheduled delivery date ( the date on which the system must be ready for delivery). Managing and Leading Software Projects, chapter 1 by R. Fairley, © Wiley, 2009 slide 1-26 A Workflow Model/ Process Model for Software Projects Change Requests Problem Reports Start Requirements Software Here and Constraints Development customer Planning Work and Activity Independent Definition Assign- Validation Replanning ments management Directives and Quality Deliver Constraints Assurance Product Estimating Controlling Configuration Management Data Retention Other Supporting Processes Project Reports Status Reports Reporting Measuring Managing and Leading Software Projects, chapter 1 by R. Fairley, © Wiley, 2009 slide 1-28 Some Supporting Processes for S/W Projects Supporting Process Purpose Configuration Change control; base line management; product audits; Management Product builds Verification Determining the degree to which work products satisfy the conditions placed on them by other work products and work processes Validation Determining the degree of fitness of work products for their intended use in their intended environments QualityAssurance Assuring conformance of work processes and work products to policies, plans, and procedures Documentation Preparation and updating of intermediate and deliverable work products Developer Training Maintaining adequate and appropriate skills User and Operator Imparting skills needed to effectively use and operate Training systems Managing and Leading Software Projects, chapter 1 by R. Fairley, © Wiley, 2009 slide 1-30 Eight Supporting Processes in ISO & IEEE Standards 12207 1. Documentation 2. Configuration management 3. Quality assurance 4. Verification 5. Validation 6. Joint review 7. Audit 8. Problem resolution Managing and Leading Software Projects, chapter 1 by R. Fairley, © Wiley, 2009 slide 1-31  Topics ▪ Why Managing and Leading Software Projects Is Difficult ▪ The Nature of Project Constraints ▪ A Workflow Model for Managing Software Projects ▪ Organizational Structures for Software Projects ▪ Organizing the Project Team ▪ Maintaining the Project Vision and the Product Vision ▪ Frameworks, Standards, and Guidelines Managing and Leading Software Projects, chapter 1 by R. Fairley, © Wiley, 2009 slide 1-34  Organizational Structures for S/W Projects Organizations that conduct engineering projects, including software projects, are typically organized in one of four ways: 1. functional structure, 2. project structure, 3. matrix structure, or 4. hybrid structure. Managing and Leading Software Projects, chapter 1 by R. Fairley, © Wiley, 2009 slide 1-35 1. Functional Structures Department Manager Process-Oriented: Requirements Design Implementation... Group Group Group Group Department Manager Product-Oriented: User Interface Algorithms Data base... Group Group Group Group Managing and Leading Software Projects, chapter 1 by R. Fairley, © Wiley, 2009 slide 1-36 2. Project-Structured Organizations The project manager, have full Department authority and responsibility for managing budget and resources Manager Project #1 Project #2 Project #3 Project #n Managing and Leading Software Projects, chapter 1 by R. Fairley, © Wiley, 2009 slide 1-38 3. Matrix-Structured Organizations The goal of a matrix organization is to obtain the advantages of both functional and project structures; functional specialists are assigned to projects as needed and work for you, the project manager, while applying their expertise to your project. When their tasks are completed, they return to their function groups and are assigned, as needed, to other projects. Workers in a matrix organization thus have two bosses: their functional manager and their project manager. Managing and Leading Software Projects, chapter 1 by R. Fairley, © Wiley, 2009 slide 1-39 3. Matrix-Structured Organizations – Cont. Two problems that can occur in matrix organizations are: (1) conflicts between functional managers and project managers over the allocation of worker resources (which puts the workers in untenable situations), and (2) frequent shifting of workers from project to project as crises occur (know as “ firefighting ” mode). Managing and Leading Software Projects, chapter 1 by R. Fairley, © Wiley, 2009 slide 1-39 4. Hybrid Structured Organizations Few, if any, organizations are purely functional, project, or matrix in nature. 100% 0% Functional Functional Matrix Project Emphasis Emphasis Project 0% 100% Project Project Coordinator Manager Managing and Leading Software Projects, chapter 1 by R. Fairley, © Wiley, 2009 slide 1-40 An Organizational Model for S/W Projects Customer Project Manager Software Architect Team Team Team V&V CM XX Leader #1 Leader#2 Leader #3...... V&V: Verification and Validation CM: Configuration Management Member Member XX: other supporting processes Member Member Each team has 2 to 5 members plus a team leader Managing and Leading Software Projects, chapter 1 by R. Fairley, © Wiley, 2009 slide 1-41 Organizing The Project Team A complex system is composed of: ▪ hardware (computers and others) ▪ software (newly developed and reused) ▪ people (operators, maintainers) A software project may be one of a collection of projects ▪ under the technical direction of a system engineering team Managing and Leading Software Projects, chapter 1 by R. Fairley, © Wiley, 2009 slide 1-42 The System Engineering Team The responsibilities of systems engineers include: ▪ defining operational requirements, ▪ specifying system requirements, ▪ developing the system design, ▪ allocating system requirements to system components, integrating the system components as they become available, ▪ verifying that the system to be delivered is correct, complete, and consistent with respect to its technical specifications, and ▪ validating operation of the system with its intended users in its intended operational environment. for “software only” projects the people who perform these functions are termed “software system engineers” Managing and Leading Software Projects, chapter 1 by R. Fairley, © Wiley, 2009 slide 1-43 Maintaining the Project and Product Visions ▪ The project manager is the the keeper of the process vision (the project roadmap), which is documented in the project plan and is updated as the project evolves. ▪ The software architect is the keeper of the product vision (the goals for the product), which is documented in the requirements and architectural design specifications and is updated as the product evolves The project manager is like a movie producer and the software architect to a movie director. !!! Managing and Leading Software Projects, chapter 1 by R. Fairley, © Wiley, 2009 slide 1-45 The movie producer and the movie director! ▪ The producer (project manager) has overall responsibility for schedules, budgets, resources, customer relations, and delivery of a satisfactory product on time and within budget. ▪ The director (software architect) is responsible for the content of the product. ▪ Producer and director must work together to maintain and constantly communicate the process vision and the product vision to the cast of developers and supporting personnel as well as other project stakeholders Managing and Leading Software Projects, by R. Fairley, © Wiley, 2009 chapter 1 slide 1-46 Frameworks, Standards, and Guidelines A process framework is a generic process model that can be tailored and adapted to fit the needs of particular projects and organizations. An engineering standard is a codification of methods, practices, and procedures that is usually developed and endorsed by a professional society or independent agency. Guidelines are pragmatic statements of practices that have been found to be effective in many practical situations. Managing and Leading Software Projects, chapter 1 by R. Fairley, © Wiley, 2009 slide 1-47 Frameworks, Standards, and Guidelines – Cont. Some well known frameworks, standards, and guidelines for software engineering and the associated URLs are: ▪ The Capability Maturity Model® Integration for development CMMI- DEV-v1.2) [www.sei.cmu.edu/cmmi/models] ▪ ISO/IEC and IEEE/EIA Standards 12207 [www.iso.org]; [standards.ieee.org/software] ▪ IEEE/EIA Standard 1058 [standards.ieee.org/software] ▪ the Project Management Body of Knowledge (PMBOK®) [www.pmibookstore.org] Elements of these models that are relevant to managing and leading software projects are presented in appendices to the chapters of this text, including Appendix 1A to this chapter. Managing and Leading Software Projects, chapter 1 by R. Fairley, © Wiley, 2009 slide 1-48 The Main Points of Chapter 1 ▪ A project is a coordinated set of activities that occur within a specific timeframe to achieve specific objectives ▪ The primary activities of software project management are planning and estimating; measuring and controlling; leading, communicating, and coordinating; and managing risk ▪ Software projects are inherently difficult because software is complex, changeable, conformable, and invisible ▪ Software projects are conducted by teams of individuals who engage in intellect-intensive teamwork Managing and Leading Software Projects, chapter 1 by R. Fairley, © Wiley, 2009 slide 1-49 The Main Points of Chapter 1 – Cont. ▪ Project constraints are limitations imposed by external agents on some or all of the operational domain, operational requirements, product requirements, project scope, budget, resources, completion date, and platform technology ▪ A workflow model indicates the work activities and the flow of work products among work activities in a software project ▪ The entire description of a software system or product is usually too complex for the entire description to be written directly in programming language, so we must prepare different descriptions at different levels of abstraction, and for different purposes. Managing and Leading Software Projects, chapter 1 by R. Fairley, © Wiley, 2009 slide 1-50  The Main Points of Chapter 1– Cont. ▪ Organizations that conduct software projects use functional, project, weak matrix, and strong matrix structures Software projects organized in a hierarchical manner provide well-defined work activities, roles, authorities, and responsibilities at each level in the hierarchy; hierarchies can expand and shrink to fit the needs of each project ▪ Requirements must be allocated and the design structured so that the work of each small team can proceed concurrently with the work of other teams. Managing and Leading Software Projects, chapter 1 by R. Fairley, © Wiley, 2009 slide 1-51  The Main Points of Chapter 1– Cont. ▪ The project manager maintains the project vision, as documented in the project plan, and the software architect maintains the product goals, as documented in the requirements and architectural design ▪ A software process framework is a generic process model that can be tailored and adapted to fit the needs of particular projects and organizations. ▪ A software engineering standard is a codification of methods, practices, and procedures, usually developed and endorsed by a professional society or independent agency. ▪ Guidelines are pragmatic statements of practices that have been found to be effective in many practical situations. Managing and Leading Software Projects, chapter 1 by R. Fairley, © Wiley, 2009 slide 1-51