Dr. Chaw-Kwei Hung 洪肇奎 National Cheng-Kung University Software Engineering Center

1. Light-Weight CMMI (Capability Maturity Model Integration )Stage 1: Requirement Development and Project Planning For NSC Open Source Projects Dr. Chaw-Kwei Hung 洪肇奎 National Cheng-Kung University Software Engineering Center hungc@ismp.csie.ncku.edu.tw February 2004

2. Agenda • CMMI Maturity Levels Overview • Life Cycle of NSC's Free Software Project Development • Major Milestones • Light-Weight (Tailoring) CMMI Process Areas (PAs) • Requirement Development and Requirement Management PAs • Student Exercise and Presentation – Your Project Requirement Specification : Functional Requirements, Performance Requirements, , Interface Requirements and Operational Concepts • Project Management and Project Monitor and Control PAs • Measurement and Analysis, Configuration Management, and Process and Product Quality assurance PAs • Student Exercise and Presentation – Your Project : Work Breakdown Structure, Work Package, and Tasks Description • Q & A

3. 5 Optimizing Organizational Innovation and Deployment (OPD) Causal Analysis and Resolution (CAR) Continuous Process Improvement Quantitative Management Organizational Process Performance (OPP) Quantitative Project Management (QPM) (QPM)(QPM) 4 Quantitatively Managed Requirements Development (RD) Technical Solution (TS) Product Integration (PI) Verification (VER) Validation (VAL) Organizational Process Focus (OPF) Organizational Process Definition (OPD) Organizational Training (OT) Integrated Project Management(IPPD) Risk Management (RSKM) Integrated Teaming (IT) Decision Analysis and Resolution (DAR) Organizational Environment for Integration (OEI) Process Standardization 3 Defined Requirements Management (REQM) Project Planning (PP) Project Monitoring and Control Supplier Agreement Management (SAM) Measurement and Analysis (M&A) Process and Product Quality Assurance (PPQ) Configuration Managemen (CM)t Basic Project Management 2 Managed CMMI Maturity Levels Overview Level Staged Organization of PAs Focus 1 Initial

4. Process Management (5) Organizational Process Focus (OPF) (L3) Organizational Process Definition (OPD) (L3) Organizational Training (OT) (L3) Organizational Process Performance (OPP) ( Organizational Innovation and Deployment Project Planning (PP) (L2) Project Monitoring and Control (PMC) (L2) Supplier Agreement Management (SAM) (L Integrated Project Management (IPPD) (L3) Integrated Teaming (IT) (L3) Risk Management (RSKM) (L3)Quantitative Project Management (QMP) (L Project Management (7) Engineering (6) Requirements Management (REQM) (L2) Requirements Development (RD) (L3) Technical Solution (TS) (L3) Product Integration (PI) (L3) Verification (VER) (L3) Validation (VAL) (L3) Support (6) Configuration Management (CM) (L2) Process and Product Quality Assurance (PPQ)2 Measurement and Analysis (M&A) (L2) Causal Analysis and Resolution (CAR) (L5) Decision Analysis and Resolution (DAR) (L3) Organizational Environment for Integration (OEI) (L3) Category Continuous Organization of PAs

5. ProjectPlanning TechnologyAdvancement NSC’sRequirements ConceptExploration RequirementDevelopment TechnicalSolution ProductIntegration Delivery Product Papers … Project Monitor and Control Requirement Management Technology Innovation Verification and Validation Support (CM, PPQA, M&A) Life Cycle of NSC's Free Software Project Development Milestone 1 Milestone 2 Milestone 3

6. Three Major Milestones Today • M1 – Requirement Analysis and Project Planning • Requirement Specification • Project Execution Plan • M2– Solution Exploration and System Design • System Design Document • Draft System Test Plan • System Implementation and Testing • System Test Plan, procedures and report • System Prototype and User Guides

7. TS PI REQM RD Ver Val Briefing Concept The Requirements & Engineering Process Areas Requirements Product & product component requirements Alternativesolutions Productcomponents Product Customer Require-ments Product components, work products, verification and validation reports Customer needs

8. Light-Weight PAsRequirements Development Purpose The purpose of Requirements Development is to produce and analyze customer, product, and product component requirements.

9. Requirements Development (RD) • SG 1 Develop customer requirements (Use NSC Proposal) • SP 1.1 Elicit needs • SP 1.2 Develop the customer requirements, • SG 2 Develop product requirements • SP 2.1 Establish product and product component requirements • SP 2.2 Allocate product component requirements • SP 2.3 Identify interface requirements • SG 3 Analyze and validate requirements • SP 3.1Establish operational concepts and scenarios • SP 3.2 Establish a definition of required functionality • SP 3.3 Analyze requirements • SP 3.4 Analyze requirements to achieve balance • SP 3.5 Validate requirements with comprehensive methods

10. Requirement Developments • SP 2-1 - Establish product and product-component requirements • Based on NSC’s Proposal (Customer Requirements) • Steps: • Develop requirements in technical terms necessary for product and product-component design • Derive requirements that result from the design decision • Selection of technology brings with additional requirements • Work Products: Product requirements, product-component requirements, derived requirements

11. Requirement Developments • SP 2.2 Allocate Product-component Requirements • Allocating requirements to functions • Allocate requirements to product components • Allocate design constraints to product components • Work Products – Requirements allocation sheets, relationships among derived requirements

12. Requirement Developments • SP 2.3 Identify Interface Requirements • Steps: • Identify interfaces both external to the product and internal to the product • Develop the requirements for the identified interfaces • Work Product: - Interface requirements System or Subsystems

13. Requirement Developments • SG 3 – Analyze and validate requirements • Analyzing and validating the requirements with respect to the user’s intended environment • Development of operational concept

14. Requirement Developments • SG 3 – Analyze and validate requirements • SP 3.1 Establish operational concepts and scenarios Steps: • Develop operational concepts and scenarios • Define the environment the product will operate in, including boundaries and constraints • Develop a detailed operational concepts that define the interaction of the product, the end users, and the environment, and that satisfy • Work Product: -Operational concept, use cases, timeline scenarios,

15. Requirement Management The purpose of Requirement Management is to manage the requirements of the project’s products and product components and to identify inconsistencies between those requirements and the project’s plan and work products.

16. Requirement Management (RM) SG 1 Manage Requirements SP 1.1 Obtain an Understanding of Requirements SP 1.2 Obtain Commitment Requirements SP 1.3 Manage Requirements Changes (See Configuration management (CM)) SP 1.4 Maintain Bi-directional Traceability of Requirements SP 1.5 Identify Inconsistencies between Project Work and Requirements (See Project Monitor and Control)

17. Requirement Management Requirements Must be Documented • Simple as a memo • All changes must be documented, tracked, and verified throughout the life cycle.

18. Requirement Management SG1- Manage Requirements SP 1.1 Understanding the requirements • Establish acceptance criteria for the acceptance of requirements Examples: • Clearly and properly stated, • complete, • consistent with each others, • uniquely defined, • appropriate to implement, • verifiable, testable, • traceable • Analyze requirements and meet criteria

19. Requirement Management PAKey Points SP 1.2 Commitment to requirements from the project participants

20. Requirement Management PAKey Points SP 1.3 Manage requirements change • Configuration management – monitoring and controlling the requirement baseline records and decision Part of CM manage baseline change procedures

21. Requirement Management PAKey Points SP 1.4 – Bidirectional traceability of requirement • Steps: • Maintain requirements traceability from a requirement to its derived requirements and allocation to functions, objects, people, processes and work products • Maintain horizontal traceability from function to function and across interfaces • Generate the requirements traceability matrix • Work products - Requirements Traceability matrix, requirements tracking system (Web – KM??)

22. Requirement Management PAKey Points SP 1.5 - Identify inconsistencies between requirements and project work/project plans • PMC activities – progress and milestone reviews

23. Stage 1: requirement specification and project execution plan. • 5.1. Requirement Specification Document • This document should include the following contents • Project Scope • Background Information • System Environment and Interface • Functional Requirements (Use Cases) • Non-functional Requirements • 5.1.1. Project Scope • It should be a brief statement of system’s objectives, including • What the eventual system will do. • What functions will be part of the system. • Which users it will service. • What will not be part of the system (optional).

24. 5.1.2. Background Information • It gives information that will help readers understand the requirements • . It should contain References to domain technology documents. • References to domain standards .Important issues related to the project (and • the rationale for your decisions, if possible). • For an academic research project, the decisions for the considered issues • might be postponed to the stage for solution exploration. Therefore, associated • information can be included into the System Specification and Solution • Document. • 5.1.3. System Environment and Interface • It provides the context in which the target system runs and • a global overview of the system. Usually, it includes • Context diagram. System platform specification. • Interface to other systems.User interface prototype.

25. 5.1.4. Functional Requirements Functional requirements document what services (functions) the target system should offer to the users. Basically, they are presented by a set of use cases. Each use case represents a scenario that some actor could follow to make use of the target system. A use case diagram should be given to illustrate the relationships among all use cases and actors Associated with the target system. Then, each use case is described by the following format:

26. 5.1.4. Functional Requirements 1. Name. Give a short, descriptive name to the use case (verb + [qualified] object). 2. Actors. List the actor or actors who can perform this use case. 3. Goals. Explain what the actor or actors are trying to achieve. 4. Preconditions. Describe the state of the system before the use case occurs by listing any conditions that must be true before an actor can initiate this use case. 5. Summary. Summarize what occurs as the actor or actors perform the use case. 6. Related use cases. List use cases that may be generalizations, specializations, extensions or inclusions of this one. Identify operational concepts and scenario 7. Steps. Describe each step of the use case using a two-column format, with the left column showing the actions taken by the actors, and the right column showing the system’s responses. 8. Post conditions. What state is the system in following the completion of this use case.

27. . 5.1.5. Non-functional Requirements Non-functional requirements document any constraints that must be imposed on the design of the system. They should be verifiable and include the following groups of requirements: Constraints for design quality: response time, throughput, resource usage (memory, bandwidth,…), reliability, availability, recovery from failure, allowances for maintainability and enhancement, allowances for reusability, etc. Constraints for system environment and technology: platform, technology to be used, etc. Constraints for project plan and development methods: development process (methodology) to be used, cost and delivery date, etc.

28. Requirement Specification and Project Execution Plan ( Example - Use NSC SDH Project) • Chapter 1 Project Scope • 1.1 Identification (SDH 1.2) 1.2 Overview ( 1.3) • 1.3 System Description (2.1) 1.4 Subsystem A Description (3.1) • 1.5 Subsystem B Description (4.1) , • Chapter 2 Background Information • 2.1 Document Scope (1.4) 2.2 Controlling Document (1.7) • 2.3 Method (1.5) • Chapter 3 System • 3.1 System Development and Interfaces • 3.1.1 Context Diagram (Figure 2 Architecture) • 3.1.2 Interface Requirements (2.3) • 3.1.3 Operational Concept and Scenario (2.5) • 3.2 Functional Requirements (2.2) • 3.3 Non-Functional Requirements (2.6) • Performance Requirements (2.4) • Safety, reliability, and maintainability requirements, other non-functional requirements (2.6)

29. Requirement Specification and Project Execution Plan (con’t) • Chapter 4 Subsystem A • 3.1 Subsystem System Development and Interfaces • 3.1.1 Context Diagram (3.1 Architecture) • 3.1.2 Interface Requirements (3.3) • 3.1.3 Operational Concept and Scenario (3.5) • 3.2 Functional Requirements (3.2) • 3.3 Non-Functional Requirements • Performance Requirements (3.4) • Safety, reliability, and maintainability requirements, other non-functional requirements (3.7 – 3.11) • Trace Matrix (3.13) • Chapter Y Subsystem X

30. Requirement Specification and Project Execution Plan (con’t) • Chapter N Project Execution Plan • N.1 System • N.1.1 Success Criteria • N.1.2 Project Scope (WBS) • N.1.3 Establish Estimates of Project Attributes • N.1.4 Project Life Cycle • N.1.5 Project Schedule • N.1.6 Resources (Budget, Personnel) • N.1.7 Risk Management • N.1.8 Data Management Plan • N-2 Subsystem A • N-2-1 Scope (WBS) • N-2-2 Schedule • N-2-3 Resources (Budget, Personnel) • N-2-4 Risk Management • N-Y Subsystem X

31. Requirement Specification and Project Execution Plan (con’t) • Glossary • Reference • Appendixes • Appendix A Configuration Management Plan • Appendix B Measurement and Analysis Plan

32. Exercise (1) Title : Generate Requirement Specification Time 15 minutes for preparation updated 15 minutes for presentation (5 minutes per group) Instructions Break into groups as determined by the instructor and consider the description of your product requirements under development. As a group based on your previous work,, examine your Customer Requirements and to determine which of the product requirements – Functional, Performance, Interface Requirements and Operational Concepts

33. Basic Project Management & Acquisition PAs Status, issues, results of process and product evaluations; measures and analyses PMC Correctiveaction Corrective action What To Monitor Replan What To Build Status, issues, resultsof progress and milestone reviews PP What To Do Engineering and Support process areas Commitments Plans Measurement needs SAM Supplieragreement Product component requirements Technical issues Completed product components Acceptance reviews and tests Supplier

34. Project Planning Purpose The purpose of Project Planning is to establish and maintain plans that define project activities Key Involves: • Developing a project plan • Interacting with stakeholders appropriately • Getting commitment the plan • Maintaining the plan

35. Project Planning (PP) • SG 1 Establish Estimate • SP 1.1 Estimate the Scope of the Project • SP 1.2 Establish Estimates of work product and task attributes • SP 1.3 Define Project Life Cycle • SP 1.4 Determine Estimates of Effort and Cost • SG 2 Develop a Project Plan • SP 2.1 Establish the Budget and Schedule • SP 2.2 Identify Project Risks • SP 2.3 Plan for Data Management • SP 2.4 Plan for Project Resources • SP 2.5 Plan for Needed Knowledge and Skills • SP 2.6 Plan Stakeholder Involvement • SP 2.7 Establish the Project Plan • SG 3 Obtain Commitment the Plan • SP 3.1 Review the plans that affect the project • SP 3.2 Reconcile Work and Resource Levels • SP 3.3 Obtain Plan Commitment

36. Project Planning PA • SG 1 Establish Estimate SP 1.1 – Estimate the scope of the project • Top Level WBS to serve to structure the initial estimating for estimate the scope of the project • WBS – Divides the project into a set of manageable component, product-oriented structure • Work Package – Logical unit of work to be managed • Effort, schedule and responsibility • WBS - Estimate Project Task responsibilities and schedule

37. WBS Example • Work Breakdown Structure (WBS) XXX-YYY-ZZZ

38. Project Planning PA SP 1.2 – Estimate of the work products and task attributes • To estimate effort, cost and schedule • Size and complexity • Example of Size measure – Function points, line of code, class and objects,

39. Project Planning PA SP 1.3 – Define project life cycle • Development phase – sub-phases – requirement analysis, design, build, integration, and verification

40. Project Life Cycle • Waterfall Model is well-defined development process in which one phase has to be finished before the next phase.  The model is very simple to use. The model can be used if the requirement is well understood and defined. • Prototyping Model is the technique which helps designers and users to clarify the requirement of the system.  A throw-away prototype is developed by designers and is evaluated by users.  From feedback of users, designers will understand the system better and improve the prototype. • Incremental Model.  The designers develop the software in a number of stages and are able to deliver the product early.  • Spiral Model  is an iterative approach. The model carefully take risks into account.  The designers develop a small part of the project and evaluate the risks.  If the risk is low, designers keeps developing more features.  For each iteration, there are six steps: 1. Determine objectives, alternatives, and constraints. 2. Identify and resolve risks. 3.Evaluate alternatives. 4. Develop deliverables and verify that they are correct. 5. Plan the next iteration. 6. Commit to an approach for the next iteration.

41. Project Planning PA SP 1.4 – Determine estimates of effort and cost

42. Project Planning • SG 2 – Develop a project plan • SP 2.1 Establish the budget and schedule • Budget allocation, task complexity, task dependences are addresses • Schedule assumption and constraints • Identify major milestones

43. Project Planning • SP 2.2- Identify and analyze (Prioritized) project risks • Risk identification and analyze including risk priorities (Section of PEP)

44. Project Planning • SP 2.3 – plan for data management • Determined project data to be identified, collected and distributed

45. Project Planning • SP 2.4 – plan for project resources • Project resources – labor, machinery/equipments, materials, and methods

46. Project Planning • SP 2.6 – plan stakeholder involvement • Ensure that relevant stakeholders in the later phases of the life cycle have early input to requirements and design decision that affected them

47. Project Planning • SP 2.7 – Establish the project plan

48. Project Planning • SG 3 – Obtain commitment to the plan • SP 3.1 - Review plans that affect the project • Review PEP, QAP, CM, M&A, PMC…etc

49. Project Planning • SP 3.2 - Reconcile work and resource levels

50. Project Planning • SP 3.3 – Obtain plan commitment • Using WBS and schedules • Identify commitment on interfaces between elements in the project