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
February

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. CMMI Maturity Levels Overview
Focus
Staged Organization of PAs
Organizational Innovation and Deployment (OPD)
Causal Analysis and Resolution (CAR)
5 Optimizing
Continuous
Process Improvement
4 Quantitatively
Managed
Quantitative
Management
Organizational Process Performance (OPP)
Quantitative Project Management (QPM) (QPM)(QPM)
3 Defined
Process
Standardization
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)
2 Managed
Basic
Project
Management
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
1 Initial

4. Continuous Organization of PAs
Category
Continuous Organization of PAs
Organizational Process Focus (OPF) (L3)
Organizational Process Definition (OPD) (L3)
Organizational Training (OT) (L3)
Organizational Process Performance (OPP) (
Organizational Innovation and Deployment
Process
Management
(5)
Project
Management
(7)
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
Requirements Management (REQM) (L2)
Requirements Development (RD) (L3)
Technical Solution (TS) (L3)
Product Integration (PI) (L3)
Verification (VER) (L3)
Validation (VAL) (L3)
Engineering
(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)
Support
(6)

5. Life Cycle of NSC's Free Software Project Development
Technology Advancement
NSC’s Requirements
Concept Exploration
Requirement Development
Technical Solution
Product Integration
Delivery
Product
Papers …
Project Planning
Project Monitor and Control
Requirement Management
Support (CM, PPQA, M&A)
Verification and Validation
Technology Innovation
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. The Requirements & Engineering Process Areas
Briefing Concept
The Requirements & Engineering Process Areas
REQM
Requirements
Product & product component requirements
Alternative solutions RD TS
Product components PI
Product
Customer
Require- ments
Product components, work products, verification and validation reports
Ver
Val
Customer needs

8. Light-Weight PAs Requirements 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.1 Establish 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 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 PA Key Points
SP 1.2 Commitment to requirements from the project participants

20. Requirement Management PA Key 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 PA Key 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 PA Key Points
SP 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
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.
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. 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. 2. Actors. List the actor or actors who can perform this use case.
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. Chapter 2 Background Information
Requirement Specification and Project Execution Plan ( Example - Use NSC SDH Project)
Chapter 1 Project Scope
1.1 Identification (SDH 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 & Engineering and Support
Acquisition PAs
Status, issues, results of process and product evaluations;
measures and analyses
PMC
Corrective action
Corrective action
What To Monitor
Replan
Status, issues, results of progress and milestone reviews
What To Build PP
What To Do
Engineering and Support
process areas
Commitments
Plans
Measurement needs
SAM
Supplier agreement
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 To estimate effort, cost and schedule
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 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 Review plans that affect the project
Review PEP, QAP, CM, M&A, PMC…etc

49. Project Planning
SP 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

51. Project Monitoring and Control
Purpose
The purpose of Project Monitoring and Control is to
provide understanding into the project’s progress
so that appropriate corrective actions can be taken
when the project’s performance deviates
significantly from the plan.

52. Project Monitoring and Control (PMC)
SG 1 Monitor Project Against Plan
SP 1.1 Monitor Project Planning Parameters
SP 1.2 Monitor Commitments
SP 1.3 Monitor Project Risks
SP 1.4 Monitor Data Management
SP 1.5 Monitor Stakeholder Involvement
SP 1.6 Conduct Progress Reviews
SP 1.7 Conduct Milestone Reviews
SG 2 Manage Corrective Action to Closure
SP 2.1 Analyze Issue
SP 2.2 Take Corrective Action
SP 2.3 Manage Corrective Action

53. Project Monitor and Control PA Key Points
SG 1 – Monitor Project against Plan
SP 1.6 – Conduct progress reviews
Can be informed review, internal reviews
Each review may identify different issues
Project performance measure – schedules, effort, deviations from plan
Review with staff, project engineers and support, management, key suppliers
Identify and document significant issues and deviation from the plan

54. Project Monitor and Control PA Key Points
SG 1 – Monitor Project against Plan
SP 1.7 – Conduct milestone reviews
PMC Plan identify project’s milestones
Milestone reviews are planned during project planning and typically formal reviews
Define criteria and review the commitment plans, status, and risk of the project
Identify significant issues and their impacts
Action Items and tracking
, External expert involved

55. Project Monitor and Control PA Key Points
SG 2 – Manage corrective actions to closure

56. Level 2 Support Process Areas

57. Measurement and Analysis
Purpose
The purpose of Measurement and Analysis is to
develop and sustain a measurement capability that
is used to support management information needs

58. Measurement and Analysis (MA)
SG 1 Align Measurement and Analysis Activities
SP 1.1 Establish Measurement Objectives
SP 1.2 Specify Measures
SP 1.3 Specify Data Collection and Storage Procedures
SP 1.4 Specify Analysis Procedures
SG 2 Provide Measurement Results
SP 2.1 Collect Measurement Data
SP 2.2 Analyze Measurement Data
SP 2.3 Store Data and Results
SP 2.4 Communicate Results

59. Measurement and Analysis PA Key Points
SG 1 – Align measurement and analysis activities
SP Specify measures to address measurement objectives
Base data – base measures , by direct measurement . Examples – Schedule And Progress

60. Measurement and Analysis PA Key Points
SG 2 – Provide measurement results
SP Collect measure data
Obtain the data for measure

61. Project Measurement & Analysis
measurement indicators
Schedule & Progress
MA status : MA monthly report with PMC Progress Review (June 、July)

62. Process and Product Quality Assurance
Purpose
The purpose of Process and Product Quality
Assurance is to provide staff and management with
objective insight into the processes and associated
work products

63. Process and Product Quality Assurance (PPQA)
SG 1 Objectively Evaluate Processes and Work Products
SP 1.1 Objectively Evaluate Processes
SP 1.2 Objectively Evaluate Work Products and Services
SG 2 Provide Objective Insight
SP 2.1 Communicate and Ensure Resolution of Non- compliance Issues
SP 2.2 Establish Records
Remark: NSC Reviewer will perform these functions

64. Configuration Management Purpose
The purpose of Configuration Management is to establish and maintain the integrity of work products using configuration identification, configuration control, configuration status accounting, and configuration audits.

65. Configuration Management (CM)
SG 1 Establish Baselines
SP 1.1 Identify Configuration Items
SP 1.2 Establish a Configuration Management System
SP 1.3 Create or Release Baselines
SG 2 Track and Control Changes
SP 2.1 Track Changes Requests
SP 2.2 Control Changes Items
SG 3 Establish Integrity
SP 3.1 Establish Configuration Management Records
SP 3.2 Perform Configuration Audits

66. Configuration Management PA
SG 1 – Establish baselines of identified work products
SP 1.1 – Identify configuration items, components, and related work product
Select the CIs and the work products that compose them based documented criteria
Critical for the project (Life cycle major work products)
Assign unique identifiers to CIs

67. Configuration Management PA
SG 1 – Establish baselines of identified work products
SP 1.3 – Create or release baselines (Internal use and for delivery to customers)
Baselines can be changed only through change control procedures

68. Configuration Management PA Key Points
SG 2 – Track and control change

69. Configuration Management
Develop CM Plan for Prototype
Defining Configuration Items
Define Access & Maintenance Rules
Define Baseline Creation, Release, & Change Rules for Version Control
Record CM activities

70. 5.1.6. Project Execution Plan
It should contain the following information:
Project Work Breakdown Structure (WBS), schedule and milestones.
Give reasonable deadlines for completion of tasks. Project 2000 or
similar formats should be adopted.
2. Resources:
a. Budget
b. Personnel
3. Risk Management. Describe the risks and difficulties expected to
be most critical to the project, or to specific subsystems. The management
strategies for the mentioned risks should also be described.
The project execution plan could be described in a nested manner, that is,
each subsystem could be described with the same format.

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

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

73. Exercise (2) Title : Generate Project Execution Plan (PEP)
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 project execution
Plans under development.
As a group based on your previous work,, examine
your Requirements and to determine
which of the project planning such as WBS, Work
Packages, Tasks, Schedule Resources,…etc

74. Q & A