PAGE
[Document Name Here]
GOTOBUTTON 1.0 draft1
Page i
Software Process Improvement
Strategic Action Plan
[Date]
[Author]
[Version #.# draft #]
Reviewed and Approved by:
Development Manager
Date
Grand Poobah
Date
Lord High Mucky-Muck
Date
Process Improvement Wizard
Date
Table of Contents
iiTable of Contents
Revision History
iii
1.
Purpose
1
1.1.
Acronyms
1
1.2.
Reference Documents
1
2.
Overview
1
3.
Executive Summary
1
4.
Business Case for SPI Initiative
2
4.1.
Business Rationale
2
4.2.
Guiding Principles
2
5.
Process Improvement Goals
3
5.1.
Short-Term Goals
3
5.2.
Long-Term Goals
3
6.
Assumptions, Risks, and Barriers
3
7.
Organization for Process Improvement
4
7.1.
Organizational Scope
4
7.2.
Management Steering Committee
4
7.3.
Software Process Improvement Leader
4
7.4.
Software Engineering Process Group
4
7.5.
Working Groups
4
7.6.
Process Owners
5
7.7.
SPI Consultant
5
8.
Criteria for Success
5
9.
Improvement Agenda
5
9.1.
Selection of SPI Activities
5
9.2.
Current SPI Activities
5
9.3.
Process Improvement Roadmap
6
Revision History
Name
Date
Reason For Changes
Revision
1.0 draft1
1. Purpose
[Describe the purpose of this document.]
This plan provides an introduction to the software process improvement (SPI) initiative for the software development projects at , describes the infrastructure to manage the initiative, and defines an approach for identifying and addressing the process improvement issues throughout .
1.1. Acronyms
[Define any acronyms used in this document. Here’s a starter list. Delete and add entries as necessary]
CMM
Capability Maturity Model
KPA
Key Process Area
MSC
Management Steering Committee
SEPG
Software Engineering Process Group
SPI
software process improvement
1.2. Reference Documents
[List any reference documents here.]
2. Overview
[Describe the background of the organization’s SPI activities, such as assessments, identifying SPI leaders and participants, etc.]
3. Executive Summary
[Explain how this action plan will integrate all software process improvement activities in this organization. Explain how the current improvement efforts will be linked to recommendations from assessments performed and how those and future efforts will be integrated, coordinated, and tied to the organization’s business objectives. Explain that this plan will provide answers to the following questions:
· What are our goals for the SPI program?
· What is our motivation to improve?
· What assumptions are we making?
· Who are the players?
· How will we measure successes?
· How will we continue to improve?]
This strategic action plan is intended to integrate all software process improvement activities within . It describes the goals, motivation for improving, the commitment required by various parties, the assumptions that are being made, the overall process to be applied in managing this initiative, and the infrastructure required to facilitate the initiative.
This document serves as the project plan for the SPI initiative, indicating an overall agenda, roles and responsibilities, assumptions and risks, key tasks, success criteria, key milestones, and how this initiative will evolve over multiple iterations of the continuous improvement cycle. A separate detailed schedule will be developed and used to manage the SPI initiative.
Management commitment to this effort is a critical success factor. Evidence of commitment includes:
· allocating appropriate and adequate resources
· setting realistic expectations and expecting accountability for realistic results
· providing clear, consistent, and public communications about the importance of the SPI initiative and the progress that is being made
· providing rewards and recognition for those exhibiting the desired process improvement related behavior
· defending software engineering based process discipline as the way that software development will be done in .
Software engineers should be both permitted and expected to follow sound software engineering principles and practices to meet their project expectations.
4. Business Case for SPI Initiative
4.1. Business Rationale
[Describe the business motivation for process improvement. You might address:
· cycle time reduction
· quality improvements in the delivered products
· improved schedule performance because of more realistic estimates and reduced feature creep
· reduced internal rework and wasted effort
· reduced staff turnover and increased morale
· the ability to facilitate movement of people from one project to another because of common software development practices.
Any projection of benefits to be obtained should be supported by references to pertinent literature, and caveats about the conditions that must exist for the projected results to be achieved.]
4.2. Guiding Principles
[Describe any guiding principles for the SPI effort or the SEPG. Some examples:
· The SPI initiative is intended to address business, technical, project management, and quality of life issues that are worth improving. The organization should be able to explain to stakeholders why a proposed activity or deliverable is important.
· Process oriented work products must be concise, must add value, and must be usable. There is no intent to produce reams of documentation.
· The appropriate mindset for process change is to understand “what’s in it for us” as a project team, an organization, or a company and its customers, not just what’s in it for any individual.
· The initiative will emphasize the importance of leveraging existing examples and templates. The organization must avoid the “not invented here” syndrome, choosing instead to borrow, buy, or adapt appropriate artifacts that already exist.]
5. Process Improvement Goals
5.1. Short-Term Goals
[Define the SPI goals for the next 6-12 months, in terms of the areas to be worked on, the improvement objectives desired, and the ways in which progress toward these goals will be measured and determined.]
5.2. Long-Term Goals
[Describe the long-term objectives of the SPI activity, over a span of 2 to 3 years. These may be motherhood statements, but the more they can be related to business objectives and correcting known shortcomings in the current business, the more plausible they will be. Keep goals few, concise, unambiguous, and measurable. A sample motherhood statement follows.]
The long term goal is to develop a software engineering culture that fully embraces an environment of continuous process improvement. Not only will the organization be developing superior quality software faster, better, and cheaper than our competitors, but it will also be monitoring the development processes currently being used , looking for ways to further improve.
6. Assumptions, Risks, and Barriers
[This section addresses assumptions underlying the motivations for SPI, the way SPI will be pursued, and the existence of elements necessary for success. It should also discuss barriers to being successful over the long term with SPI and risks inherent in the plan. Some areas to consider addressing here are:
· knowledge and skills, including training needs, availability of training resources, and time for training on the part of the staff
· management commitment
· resources (at SPI leadership, organizational management, practitioner, and consultant levels; what level of practitioner and SEPG effort is assumed?)
· recognition and reward]
The following are the major risks facing the success of this project:
ID
Risk Item
P
L
E
Mitigation Approaches
Who
Date Due
1
[identify the risk]
#
#
#
· [identify how risk will be mitigated]
[name]
[target date]
2
[identify the risk]
#
#
#
· [identify how risk will be mitigated]
[name]
[target date]
3
[identify the risk]
#
#
#
· [identify how risk will be mitigated]
[name]
[target date]
P = probability of occurrence (0 to 1)
L = relative loss factor (0 to 10)
E = risk exposure = P*L
7. Organization for Process Improvement
7.1. Organizational Scope
[Identify the project(s) and organization(s) that fall within the scope of this plan.]
7.2. Management Steering Committee
[The MSC is the governing body of the SPI effort. Forming an MSC sends a clear signal that process improvement is a management priority. Resistance from practitioners and project managers is easier to overcome if it is clear that process improvement is a priority for upper management. Identify the members of the MSC, its meeting frequency, and its regular activities.]
7.3. Software Process Improvement Leader
[Define the roles of the individual who is assigned responsibility for coordinating and leading the SPI activity.]
The responsibilities of the Software Process Improvement Leader include:
· documenting the organization’s strategic action plan (this document)
· creating a schedule identifying activities, resources, and effort
· tracking progress against the plan
· reviewing project team and working group action plans
· collecting status biweekly from the project teams and working groups
· summarizing and reporting status monthly at the MSC meeting
· suggesting corrective action to the MSC when actual progress deviates too far from the plans
· acquiring and coordinating resources for training and consulting
7.4. Software Engineering Process Group
[If you intend to establish an SEPG, describe its membership, operating principles, and primary activities and responsibilities here.]
7.5. Working Groups
[Describe what process improvement working groups are, how they will be chartered, what they will do, scope of their activities, their lifetime, their operating practices, and what they will produce. Some sample text follows.]
A working group is an ad hoc team of practitioners who produce, review, and assist with piloting new software process deliverables and tools in a specific, focused improvement area. The Process Owners will establish working groups on an as-needed basis. A working group can be formed within a project team, or it can cross project teams. Working group team members are expected to participate in pilots of the deliverables and in roll-outs of new processes.
Responsibility for each milestone in the SPI Roadmap will be accepted by an individual who will serve as the leader of a working group to address the improvement recommendations in that milestone. Those individuals will convene working groups of 2 to 4 appropriate practitioners who will evaluate the shortcomings in the current process, collect existing artifacts from throughout , develop new process assets, conduct pilots, modify the process assets as needed, and roll the new process assets out to the affected community.
7.6. Process Owners
[Consider identifying a manager to be the Process Owner for each major improvement area. The Process Owner provides continuity over time as working groups come and go. Feedback on application of new processes and requests for changes in the new processes should be delivered to the appropriate Process Owner. Process Owners charter working groups, and they evaluate to what extent the new processes are actually being applied and how well they are working.]
7.7. SPI Consultant
[If you intend to use outside process improvement consultants, describe their primary roles and responsibilities here.]
8. Criteria for Success
[Describe the criteria that will be used to determine how successful the SPI initiative has been. This should relate to the business rationale described previously, but should also address how effective the process used for SPI has been.]
9. Improvement Agenda
9.1. Selection of SPI Activities
[Describe how the software engineering and management areas to be addressed by SPI work will be selected and prioritized. Might be based on assessment or survey or team brainstorming results, results from post-project reviews of completed projects, alignment with business objectives ,selected key process areas, and so on.]
9.2. Current SPI Activities
[Provide a high-level description of all current improvement efforts: what they are doing, what resources are currently committed to the activity, and what resources are required to complete the activity. Describe how the above existing activities map to the recommendations or roadmap from the assessment, if one was held. Identify any differences between the assessment recommendations and the current improvement activities.]
9.3. Process Improvement Roadmap
[Present the roadmap created for the organization’s software process improvement strategy. The roadmap consists of several sequences of improvement areas linked along threads that lead to satisfying specific organizational business or technical objectives. Each roadmap thread addresses several recommendations from an assessment or other self-evaluation, with interim milestones. Describe the time table and milestone target dates for the roadmap elements, and indicate the individual who is responsible for each roadmap item.]
Page iii
本文档为【48篇软件工程文章strategic_plan_template】，请使用软件OFFICE或WPS软件打开。作品中的文字与图均可以修改和编辑，
图片更改请在作品中右键图片并更换，文字修改请直接点击文字进行修改，也可以新增和删除文档中的内容。
该文档来自用户分享，如有侵权行为请发邮件ishare@vip.sina.com联系网站客服，我们会及时删除。
[版权声明] 本站所有资料为用户分享产生，若发现您的权利被侵害，请联系客服邮件isharekefu@iask.cn，我们尽快处理。
本作品所展示的图片、画像、字体、音乐的版权可能需版权方额外授权，请谨慎使用。
网站提供的党政主题相关内容(国旗、国徽、党徽..)目的在于配合国家政策宣传，仅限个人学习分享使用，禁止用于任何广告和商用目的。
浙公网安备 33021202002483