軟體流程能力評估分析系統 李文誌 資四B 902959 鄭麗燕 資四B 902965 1/31/2005 1
大綱 n n 摘要 說明 系統畫面 參考資料 1/31/2005 2
摘要 n 我們做的專題就是針對SPICE 1 -2 -1和 Capability Adviser為例。我們想做的就是 類似它們的功能。雖然我們做的功能沒 有那麼完整，我們有忽略到一些功能(列 如：每一個說明的部份、等等)但是我們 也有加一些功能。 1/31/2005 3
說明 ISO 15504 is complementary to several other international standards: n ISO 9001: 2000 – quality management systems Provides a strong process management approach to the establishment of a quality management system. n ISO/IEC 12207 – software life cycle processes Provides an overall contextual framework for software life cycle processes. n ISO/IEC 15288 – system life cycle processes Provides a common process framework covering the life cycle of man-made systems. 1/31/2005 4
Steps of Process Improvements 1/31/2005 5
軟體流程能力評估分析系統(1) 1/31/2005 6
Processes & Rating 1/31/2005 7
Processes 1/31/2005 8
Capability levels and process attributes ISO/IEC 15504 1/31/2005 9
Assessment indicators n n Process Performance Indicators 1. Base Practice (BP) an activity that addresses the purpose of a particular process 2. Work Product (WP) Process Capability Indicators 1. Generic Practice (GP) activities of a generic type and provide guidance on the implementation of the attribute's characteristics 2. Generic Resource (GR) associated resources that may be used when performing the process in order to achieve the attribute, including human resources, tools, methods and infrastructure 3. Generic Work Product (GWP) sets of characteristics that would be expected to be evident in work products 1/31/2005 10
Measurement Framework 1/31/2005 11
1/31/2005 12
Capability Level Rating 1/31/2005 13
Rating 1/31/2005 14
ENG. 4 Software Requirement Analysis n n Process Purpose The purpose of the Software requirements analysis process is to establish the requirements of the software elements of the system. Process Outcomes As a result of successful implementation of Software requirements analysis process: 1) the requirements allocated to the software elements of the system and their interfaces are defined; 2) software requirements are analyzed for correctness and testability; 3) the impact of software requirements on the operating environment are understood; 4) consistency and traceability are established between the software requirements and system requirements; 5) prioritization for implementing the software requirements is defined; 6) the software requirements are approved and updated as needed; 7) changes to the software requirements are evaluated for cost, schedule and technical impact; and 8) the software requirements are baselined and communicated to all affected parties. 1/31/2005 15
Base Practices of ENG. 4 n n n ENG. 4. BP 1: Specify software requirements. ENG. 4. BP 2: Determine operating environment impact. ENG. 4. BP 3: Develop criteria for software testing. ENG. 4. BP 4: Ensure consistency. ENG. 4. BP 5: Evaluate and update software requirements. ENG. 4. BP 6: Communicate software requirements. 1/31/2005 16
Work Product of ENG. 4 Work Products Inputs Outputs 04 -06 System architecture design [Outcome: 1] 13 -04 Communication record [Outcome: 8] 13 -16 Change request [Outcome: 6, 7] 13 -17 Customer request [Outcome: 6, 7] 13 -21 Change control record [Outcome: 7] 13 -22 Traceability record [Outcome: 4] 15 -01 Analysis report [Outcome: 2, 3, 7] 17 -08 Interface requirements [Outcome: 1] 17 -11 Software requirements [Outcome: 1, 2, 4, 5, 6] 17 -12 System requirements [Outcome: 1, 4] 1/31/2005 17
SUP. 9 Problem Resolution Management n n Process Purpose The purpose of the Problem resolution management process is to ensure that all discovered problems are identified, analyzed, managed and controlled to resolution. Process Outcomes As a result of successful implementation of the Problem resolution management process: 1) a problem management strategy is developed; 2) problems are recorded, identified and classified; 3) problems are analyzed and assessed to identify acceptable solution(s); 4) problem resolution is implemented; 5) problems are tracked to closure; and 6) the status of all problem reports is known NOTE: Problem resolution management may initiate a change request. 1/31/2005 18
Base Practices of SUP. 9 n n n n n SUP. 9. BP 1: Develop problem resolution strategy. SUP. 9. BP 2: Identify and record the problem. SUP. 9. BP 3: Provide initial support and classification. SUP. 9. BP 4: Investigate and diagnose the cause of the problem. SUP. 9. BP 5: Assess the impact of the problem to determine solution. SUP. 9. BP 6: Execute urgent resolution action, where necessary. SUP. 9. BP 7: Raise alert notifications, where necessary. SUP. 9. BP 8: Implement problem resolution. SUP. 9. BP 9: Initiate change request. SUP. 9. BP 10: Track problem status. 1/31/2005 19
Work Product of SUP. 9 Work Products Inputs Outputs 08 -27 Problem management plan [Outcome: 1] 13 -07 Problem record [Outcome: 3, 5] 13 -16 Change request [Outcome: 2] 14 -08 Tracking system [Outcome: 4, 5, 6] 15 -01 Analysis report [Outcome: 3] 15 -05 Evaluation report [Outcome: 3] 15 -12 Problem status report [Outcome: 6] 1/31/2005 20
MAN. 3 Project Management n n Process Purpose The purpose of the Project management process is to identify, establish, co-ordinate, and monitor the activities, tasks, and resources necessary for a project to produce a product and/or service, in the context of the project’s requirements and constraints. Process Outcomes As a result of successful implementation of Project management process: 1) the scope of the work for the project is defined; 2) the feasibility of achieving the goals of the project with available resources and constraints are evaluated; 3) the tasks and resources necessary to complete the work are sized and estimated; 4) interfaces between elements in the project, and with other project and organizational units, are identified and monitored; 5) plans for the execution of the project are developed and implemented; 6) progress of the project is monitored and reported; and 7) actions to correct deviations from the plan and to prevent recurrence of problems identified in the project are taken when project targets are not achieved. 1/31/2005 21
Base Practices of MAN. 3 n n n n MAN. 3. BP 1: Define the scope of work. MAN. 3. BP 2: Define project life cycle. MAN. 3. BP 3 Evaluate feasibility of the project. MAN. 3. BP 4: Determine and maintain estimates for project attributes. MAN. 3. BP 5: Define project activities and tasks. MAN. 3. BP 6: Define needs for experience, knowledge and skills. MAN. 3. BP 7: Define project schedule. MAN. 3. BP 8: Identify and monitor project interfaces. MAN. 3. BP 9: Allocate responsibilities. MAN. 3. BP 10: Establish project plan. MAN. 3. BP 11: Implement the project plan. MAN. 3. BP 12: Monitor project attributes. MAN. 3. BP 13: Review progress of the project. MAN. 3. BP 14: Act to correct deviations. 1/31/2005 22
Work Product of MAN. 3(1) Work Products Inputs Outputs 02 -00 Contract [Outcome: 1, 2] 03 -06 Process performance data [Outcome: 3, 7] 07 -05 Project measure [Outcome: 6] 08 -08 Human resource management plan [Outcome: 2] 08 -12 Project plan [Outcome: 3, 6, 7] 08 -12 Project plan [Outcome: 1, 2, 3, 4, 5] 08 -19 Risk management plan [Outcome: 6, 7] 08 -19 Risk management plan [Outcome: 5] 12 -01 Request for proposal [Outcome: 1] 13 -04 Communication record [Outcome: 6] 13 -07 Problem record [Outcome: 7] 1/31/2005 23
Work Product of MAN. 3(2) Work Products Inputs Outputs 13 -14 Progress status record [Outcome: 7] 13 -14 Progress status record [Outcome: 6] 13 -16 Change request [Outcome: 1] 13 -16 Change request [Outcome: 7] 13 -17 Customer request [Outcome: 1] 13 -19 Review record [Outcome: 7] 14 -02 Corrective action register [Outcome: 7] 14 -06 Schedule [Outcome: 1, 3] 14 -06 Schedule [Outcome: 5] 14 -08 Tracking system [Outcome: 4, 6] 14 -09 Work breakdown structure [Outcome: 5] 14 -09 Work breakdown structure [Outcome: 4] 08 -06 Project activity network [Outcome: 5] 08 -06 Project activity network [Outcome: 4] 15 -06 Project status report [Outcome: 4, 6] 17 -03 Customer requirements [Outcome: 2] 19 -07 Software development methodology [Outcome: 5] 1/31/2005 24
Table 1/31/2005 25
Level Capability 1/31/2005 26
Setting Target Capability 1/31/2005 27
Process Attributes Gaps 1/31/2005 28
Capability Level Gaps 1/31/2005 29
Risk Associated with Each Capability Level 1/31/2005 30
Consequence of Problem Occuring 1/31/2005 31
Risk Analysis 1/31/2005 32
參考資料 n n n n ISO/IEC 15504 -4: 2004(E) setting target capability 講義 15504 v 5. 03. 2. 2 a講義 http: //neural. cs. nthu. edu. tw/jang/ http: //www. cs. nthu. edu. tw/~jang/mlbook/ Capability Adviser 15504 PRM v 5. 11. 1. 0 a 講義 SPICE Standard File SPICE 1 -2 -1 1/31/2005 33
THE END 1/31/2005 34
Скачать презентацию 軟體流程能力評估分析系統 李文誌 資四B 902959 鄭麗燕 資四B 902965 1 31 2005
4dd47ba670feb375a78c36c0ef255a77.ppt