CEN 4021 Software Engineering II

1. CEN 4021 Software Engineering II Phases of Software Project Management Software Project Planning Project Content and deliverables Instructor: Masoud Sadjadi http://www.cs.fiu.edu/~sadjadi/ sadjadi@cs.fiu.edu

2. Acknowledgements • Dr. Onyeka Ezenwoye • Dr. Peter Clarke

3. Agenda • Overview of phases of Software Project Management (SPM) • Software Project Planning • Project Content and deliverables

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

5. Phases of SPM • The previous management activities are captured using the acronym POMA: • Planning • Organizing • Monitoring • Adjusting

6. POMA Management Process Planning Activities Organizing Activities Monitoring Activities Adjustment Activities

7. POMA • Models the software management cycle • Software processes model development cycle • Applies software engineering knowledge • For example • Requirements elicitation • Software measurements

8. POMA • Not necessarily sequential • Activities within each category may overlap • Categories may overlap • For example, original plans may be adjusted during monitoring and adjustment activities.

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

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

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

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

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

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

15. Agenda • Phases of Software Project Management (SPM) • Software Project Planning (POMA) • Project Content and deliverables

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

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

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

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

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

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

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

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

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

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

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

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

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

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

30. Requirements Sources Development Requirements Prioritization Support Software Product Management Board List of Reqs input to the Product Plan Reqs Repository . . . Customer Consultant Requirements Prioritization

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