Скачать презентацию S W Project Management Software Project Planning Agenda Скачать презентацию S W Project Management Software Project Planning Agenda

061eeb3554da8e4d2cc5fd58efdf5d34.ppt

  • Количество слайдов: 30

S/W Project Management Software Project Planning S/W Project Management Software Project Planning

Agenda 2 Overview of phases of Software Project Management (SPM) Software Project Planning Project Agenda 2 Overview of phases of Software Project Management (SPM) Software Project Planning Project S/W Project Planning Content and deliverables

Phases of SPM 3 The software project management activities include: Project planning and scheduling Phases of SPM 3 The software project management activities include: Project planning and scheduling Project cost Project monitoring and reviews Personnel selection and evaluation Report writing and presentations S/W Project Planning

Phases of SPM 4 The previous management activities are captured using the acronym POMA: Phases of SPM 4 The previous management activities are captured using the acronym POMA: Planning Organizing Monitoring Adjusting S/W Project Planning

POMA Management Process 5 Planning Activities Organizing Activities Monitoring Activities Adjustment Activities S/W Project POMA Management Process 5 Planning Activities Organizing Activities Monitoring Activities Adjustment Activities S/W Project Planning

POMA 6 Models the software management cycle Software processes model development cycle Applies software POMA 6 Models the software management cycle Software processes model development cycle Applies software engineering knowledge For example Requirements elicitation Software measurements S/W Project Planning

POMA 7 Not necessarily sequential Activities within each category may overlap Categories may overlap POMA 7 Not necessarily sequential Activities within each category may overlap Categories may overlap For example, original plans may be adjusted during monitoring and adjustment activities. S/W Project Planning

Planning 8 Set of activities used to develop a plan of attack for the Planning 8 Set of activities used to develop a plan of attack for the project: Description of software product i. e. , artifact contents and deliverables. The Software product attributes. Project schedule. Resources needed to meet project schedule. Measurements used to gauge the status of the project. Risk associated with project. S/W Project Planning

Planning 9 Points to note: Time consuming Important phase of SPM Often rushed Even Planning 9 Points to note: Time consuming Important phase of SPM Often rushed Even with a well conceived plan changes are often necessary. Experience is very helpful in developing a project plan. especially knowledge of organization. S/W Project Planning

Organizing 10 Seeks to construct a software development based on the project plan. Activities Organizing 10 Seeks to construct a software development based on the project plan. Activities include: Acquiring various skilled individuals needed for the project. Defining the a process and a set of methodologies for the project. Obtaining the tools to support the process and methodologies. Creating a set of well-defined metrics to track and gauge the project. S/W Project Planning

Organizing 11 Issues of major concern: Personnel are properly equipped to perform their designated Organizing 11 Issues of major concern: Personnel are properly equipped to perform their designated task i. e. , equipping personnel include obtaining tools and preparing facilities educating personnel in using tools, methodology, and metrics Allocation of adequate financial funding. Team may include financial and personnel management. “People management” aspect of organizing is critically important. Morale affects productivity S/W Project Planning

Monitoring 12 Monitoring focuses on: Consistently and regularly collecting measurements. Analyzing the data. Representing Monitoring 12 Monitoring focuses on: Consistently and regularly collecting measurements. Analyzing the data. Representing and presenting the data for a defined set of reports. Making projections and making recommendations based on the analysis of the data. Involves people management. S/W Project Planning

Adjusting 13 Adjustments are often necessary due to: Changing software requirements Discovery of an Adjusting 13 Adjustments are often necessary due to: Changing software requirements Discovery of an unfeasible design Lost of skilled team members Financial constraints Adjustments may be made to: Requirements Schedule Resources Project content It is very important to do a thorough risk analysis during the planning stage of the project S/W Project Planning

Agenda 14 Phases of Software Project Management (SPM) Software Project Planning (POMA) Project Content Agenda 14 Phases of Software Project Management (SPM) Software Project Planning (POMA) Project Content and deliverables S/W Project Planning

Plan Content 15 Varies depending on the type of software project. All project plans Plan Content 15 Varies depending on the type of software project. All project plans must address: What is the nature of the s/w project and what software artifacts are the desired deliverables? What is the overall schedule and the associated major project milestones? What are the required resources and their associated financial costs? What are the known risks and the areas that are still unknown? S/W Project Planning

Comprehensive Plan 16 Problem and requirements User problems needs and wishes Product/Project Description Complete Comprehensive Plan 16 Problem and requirements User problems needs and wishes Product/Project Description Complete scope of the project i. e. , all project deliverables, and a description of each deliverable. Product/Project Attributes Description of the various attributes of deliverables and non deliverables as they pertain to the goals of the project e. g. , quality. Identify metrics for the attributes. Schedule Sequence of tasks Identification of milestones and deliverables S/W Project Planning

Comprehensive Plan 17 Cost Details in terms of some unit e. g. , person-days, Comprehensive Plan 17 Cost Details in terms of some unit e. g. , person-days, for each deliverable Includes expenditures – tools, travel, training, communications Resources List of people needed and their skills Complete set of tools Special training Software and hardware systems required S/W Project Planning

Comprehensive Plan 18 Process and Methods Description of the overall process and methods Risks Comprehensive Plan 18 Process and Methods Description of the overall process and methods Risks List of potential problems Assessed impact Probability of occurrence Plan to prevent risk from turning into a real problem S/W Project Planning

Requirements Elicitation 19 Before the project can be initiated, software engineers need to: identify Requirements Elicitation 19 Before the project can be initiated, software engineers need to: identify the requirements of the project, interfaces to related systems or subsystems. Gathering s/w requirements is one of the most difficult task of any s/w project. The software project manager needs to provide an environment conducive to proper requirements gathering and analysis. Enough time and suitable skilled people S/W Project Planning

Requirements Elicitation 20 Points to note: Requirements must be understood and agreed upon by Requirements Elicitation 20 Points to note: Requirements must be understood and agreed upon by all the stakeholders. Not understanding the s/w requirements of the project can be very costly. Not just software engineers Improper testing, quality issues Customer requirements not met Missed schedules Consult domain experts is necessary. The requirements document is a contract!! S/W Project Planning

General requirements management activities 21 Agreeing on and initiating Reqs Elicitation (as needed) Reqs General requirements management activities 21 Agreeing on and initiating Reqs Elicitation (as needed) Reqs Analysis and Prototyping Reqs Review Reqs Specification Agreeing and “Signing Off” S/W Project Planning

Requirements Analysis 22 Involves checking that the specification is correct, complete, consistent, unambiguous, and Requirements Analysis 22 Involves checking that the specification is correct, complete, consistent, unambiguous, and realistic. Correct – accurately represents the client’s view of the system. Complete – all possible scenarios are described including exceptional behavior. Consistent – does not contradict itself. Unambiguous – exactly one system is defined. S/W Project Planning

Requirements Analysis 23 Software prototype - a s/w model created for the purpose of Requirements Analysis 23 Software prototype - a s/w model created for the purpose of better understanding the requirements and the feasibility of the proposed solution. Must have clearly specified schedules To avoid repeated viewing and reviewing of prototypes Define clear entrance and exit criteria. Define scope of prototype activity. Must be agree upon by everyone. S/W Project Planning

Types of Requirements 24 Major types of requirements: The project deliverables The needs satisfied Types of Requirements 24 Major types of requirements: The project deliverables The needs satisfied by the deliverables (project) Project deliverables Requirements document Design document Source code Executable code Test scenarios S/W Project Planning

Types of Requirements 25 Project deliverables User guide Product reference manual Test results and Types of Requirements 25 Project deliverables User guide Product reference manual Test results and quality-related data Process specification Test cases with test data Project plan It is important to be informed of the practices of the organization. S/W Project Planning

Types of Requirements 26 Project needs and their characterization This is the area where Types of Requirements 26 Project needs and their characterization This is the area where most s/w engineers, rather than the software project manager, should focus there energy. The following items should be identified: The functionality of the s/w The nonfunctional requirements of the s/w The interfaces that the s/w needs to interact with its users S/W Project Planning

Review and Approval of Requirements 27 software project manager needs to ensure the first Review and Approval of Requirements 27 software project manager needs to ensure the first set of reqs (the deliverables) are clearly defined understood, prioritized, and agreed upon by the stakeholders. All parties should formally “sign-off” on the deliverables. include a final review of the requirements specification prior to sign-off. S/W Project Planning

Prioritization of Requirements 28 Project reqs are sometimes initiated by solution providers internally. These Prioritization of Requirements 28 Project reqs are sometimes initiated by solution providers internally. These requirements are the most difficult to evaluate. The requirements usually initiate during maintenance. It is a good idea to have a prioritization procedure for both internal and external reqs. Inputs from the various reqs sources are constantly coming in to the s/w organization and being captured, possibly by an automated tool. S/W Project Planning

Requirements Prioritization 29 Requirements Sources Development Requirements Prioritization Support . . . Customer Consultant Requirements Prioritization 29 Requirements Sources Development Requirements Prioritization Support . . . Customer Consultant S/W Project Planning Reqs Repository Software Product Management Board List of Reqs input to the Product Plan

Prioritization of Requirements 30 Resources must be set aside for the following activities: Regular Prioritization of Requirements 30 Resources must be set aside for the following activities: Regular review of inputs Analysis of the valid inputs Prioritization of the inputs Response to both the accepted ideas and rejected ones Formulation of the accepted reqs subset into actual reqs for the product plan. S/W Project Planning