Process Purpose

軟體流程能力評估分析系統
李文誌 資四B 902959
鄭麗燕 資四B 902965
1/31/2005
1
大綱




摘要
說明
系統畫面
參考資料
1/31/2005
2
摘要

我們做的專題就是針對SPICE 1-2-1和
Capability Adviser為例。我們想做的就是
類似它們的功能。雖然我們做的功能沒
有那麼完整,我們有忽略到一些功能(列
如:每一個說明的部份、等等)但是我們
也有加一些功能。
1/31/2005
3
說明
ISO 15504 is complementary to several other international
standards:

ISO 9001:2000 – quality management systems
Provides a strong process management approach to the
establishment of a quality management system.
 ISO/IEC 12207 – software life cycle processes
Provides an overall contextual framework for software life
cycle processes.

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


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


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






ENG.4.BP1: Specify software requirements.
ENG.4.BP2: Determine operating environment impact.
ENG.4.BP3: Develop criteria for software testing.
ENG.4.BP4: Ensure consistency.
ENG.4.BP5: Evaluate and update software
requirements.
ENG.4.BP6: 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


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










SUP.9.BP1: Develop problem resolution strategy.
SUP.9.BP2: Identify and record the problem.
SUP.9.BP3: Provide initial support and classification.
SUP.9.BP4: Investigate and diagnose the cause of the problem.
SUP.9.BP5: Assess the impact of the problem to determine
solution.
SUP.9.BP6: Execute urgent resolution action, where necessary.
SUP.9.BP7: Raise alert notifications, where necessary.
SUP.9.BP8: Implement problem resolution.
SUP.9.BP9: Initiate change request.
SUP.9.BP10: 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]
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


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














MAN.3.BP1: Define the scope of work.
MAN.3.BP2: Define project life cycle.
MAN.3.BP3 Evaluate feasibility of the project.
MAN.3.BP4: Determine and maintain estimates for project attributes.
MAN.3.BP5: Define project activities and tasks.
MAN.3.BP6: Define needs for experience, knowledge and skills.
MAN.3.BP7: Define project schedule.
MAN.3.BP8: Identify and monitor project interfaces.
MAN.3.BP9: Allocate responsibilities.
MAN.3.BP10: Establish project plan.
MAN.3.BP11: Implement the project plan.
MAN.3.BP12: Monitor project attributes.
MAN.3.BP13: Review progress of the project.
MAN.3.BP14: 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
參考資料








ISO/IEC15504-4:2004(E)
setting target capability 講義
15504 v5.03.2.2a講義
http://neural.cs.nthu.edu.tw/jang/
http://www.cs.nthu.edu.tw/~jang/mlbook/
Capability Adviser
15504 PRM v5.11.1.0a 講義
SPICE Standard File
SPICE 1-2-1
1/31/2005
33
THE END
1/31/2005
34