S/W Project Management

1. S/W Project Management Software Project Planning

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

3. Phases of SPM • 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

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

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

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

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. POMA S/W Project Planning

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

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

10. Organizing • 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

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

12. Monitoring Monitoring focuses on: • Consistently and regularly collectingmeasurements. • 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

13. Adjusting • 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

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

15. Plan Content • 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

16. Comprehensive Plan • 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

17. Comprehensive Plan • 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

18. Comprehensive Plan • 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

19. Requirements Elicitation • 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

20. Requirements Elicitation Points to note: • Requirements must be understood and agreed upon by all the stakeholders. • Not just software engineers • Not understanding the s/w requirements of the project can be very costly. • 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

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

22. Requirements Analysis • Involves checking that the specification is correct, complete, consistent, unambiguous,andrealistic. • 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

23. Requirements Analysis • 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

24. Types of Requirements • 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

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

26. Types of Requirements • 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

27. Review and Approval of Requirements • 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

28. Prioritization of Requirements • 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

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

30. Prioritization of Requirements • 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