系统开发计划书制作指南Word格式.docx

系统开发计划书制作指南Word格式.docx

《系统开发计划书制作指南Word格式.docx》由会员分享，可在线阅读，更多相关《系统开发计划书制作指南Word格式.docx（13页珍藏版）》请在冰豆网上搜索。

8.质量计划5/9

9.教育/培训计划7/9

10.提交计划7/9

11.项目规则7/9

12.相关资料一览表8/9

13.更改记录8/9

1.前言

本指南是制作系统开发计划书的书写要领。

系统开发计划书的制作目的是：

进行系统开发计划的立案，在此开发计划的基础上，项目负责人（系统开发计划书应由项目负责人书写）将要开发的功能，进行开发的开发体制，要实施的开发过程，以及开发程序等归纳在文件中，作为项目组成员的开发方针。

本系统开发计划书只列举了项目进行中最低所需项目，各个项目根据实际情况若有额外项目也可追加。

系统开发计划书的要点：

●本次开发是新开发还是改造

●开发范围是否已明确

●开发体制是否已明确

●开发过程是否已决定

●质量目标是否已决定

●性能目标是否已决定

●项目规则是否已决定

项目成员必须掌握和理解以上内容，也就是必须遵照系统开发计划书进行开发作业。

系统开发计划书是在项目需求规范明确后（DR-A完成后也可。

DR-B以前）制作，开发部部长审查后，由项目管理部批准。

若开发分为几个阶段进行时，原则上每个阶段都应制作开发计划书。

以下对各项目的书写方式进行说明。

2.封面

1）合同号

当项目为非合同软件包项目时，此编号不填。

合同项目填写相应的合同号（在制作开发计划书时，若尚未签订合同，则以后追加上）。

2）项目号

项目号是由项目管理部分配的唯一编号。

此编号是在项目负责人制作完系统开发计划书并通过开发部部长审查后，由项目管理部负责填写，一切与项目相关的管理都以此编号来进行。

3）客户名称

客户名称必须用全称，有简称时写在全称后的（）内。

若明确最终用户与合同签定者不一致时，在合同签定方名称后填写最终用户名称。

4）系统名称

系统名称（产品名）必须用全称，有简称时写在全称后的（）内。

5）承担部门

公司内承担此项目的部门的名称。

6）填表日期

填表年月日。

3.系统概要

明确整个系统的概要及本次开发的范围。

1）系统概述

说明系统的目的、构成、功能、优点等。

另外要明确说明是新开发还是改造,改造时,要说明这次作业的功能范围。

2）2000年对应的方针：

对于新开发的系统来说，应制定2000年对应方针,并在各个DR中确认要验证的内容与事件;

当为改造的,不仅要讨论改造的策略、还要注意改造部分对原有质量潜在的影响。

以下项目为需要实施的方针：

●内部日历数据用4位表示

●采用对应2000年问题的操作系统（OS）的应用程序接口（API）来进行日期判定

●对所有对年月日进行处理的项进行确认

●对外部接口进行确认

●只进行操作系统（OS）的2000年对应

●只进行应用程序接口（API）的2000年对应

3）硬件配置

说明整个系统的硬件配置环境。

与测试环境不同的时侯，要明确审查其有效性。

4）软件配置

说明软件的整体结构，改造时，要明确新做成部分/修正部分。

记述使用的操作系统，基本软件包，中间件，开发语言和程序的总量。

按以下方法用程序的条数来明确软件的开发规模（预估）：

●基本条数：

系统/子系统全体未发生更改的程序条数，也包括沿用部分。

（修改部分在30%以下）

●改造条数：

发生更改的程序的条数。

（修改在30%—90%）

●新做成条数：

新做成的程序条数（90%以上需要修改）

●总计程序语句条数：

基本+改造+新做成语句部分的总和

●沿用率：

基本部分/总和

在产品通过公司内部验收后，若实际程序条数与预计不符时，用=将预计值取消，并记录最终结果。

5）配置管理

制作以下的配置管理表：

（1）开发环境配置管理表：

记述系统开发时的环境配置（软件，硬件）。

软件、硬件应包括开发系统安装的所有的主要的软件和硬件，而不只是与该项目有关的那些。

（2）设计文档配置管理表：

记述开发中预定要制作的文档。

（3）程序配置管理表：

单元测试完成时的全部程序代码。

（4）接收文档／数据配置管理表：

记述全部从客户处接收的资料、数据、媒体等。

各个配置管理表作成后，将其质量记录编号填入关联资料一览表中。

4.开发体制

记述公司内部、用户单位的相关体制，以利于同相关公司、部门取得联系。

项目组成员很多时，制作开发体制图，附在本页后。

1）主管部门

记述作为本公司与客户之间窗口的部门名称和负责人姓名。

2）管理体制

记述开发本系统的开发部门名称及各项职能人员名单。

3）合作单位体制

若将本系统开发业务的一部分委托给其它单位进行开发时，记述合作单位的开发体制。

4）用户单位体制

记述客户单位的相关体制。

5.质量管理工程图（QCP）

明确在该系统开发中预定要实施的项目、成果、管理对象。

●实施项目的明确：

●明确各个过程中的实施内容，预定实施的项目用“√”标识。

●成果的明确：

●确定各过程的成果，必要时也可在成果一栏中追加QCP中不存在的成果名称。

●管理对象的明确：

明确作为管理文档的文档，标识方法同实施项目一样。

在分阶段开发过程中，对每个阶段分别制作质量管理工程图。

6.风险管理

在系统开发中，要对每个DR阶段考虑有无风险，并挑选出所有的风险项目。

1）开发风险

确认对应于以下项目是否存在风险：

●硬件

●操作系统

●特殊技术

●共同开发

●特殊项（超短交纳期限等）

认为存在风险时，将相应项用○圈住。

将风险项目的内容、对策、编号记载在管理表中。

对策要填写具体的实施内容。

另外要在DR中对对策的完成进行确认。

（1）过程风险

开发规模过大；

开发的交纳期限、需求的成本和规模特别不符；

发生预定以外的开发任务。

（2）技术风险

使用新的操作系统、软件包、数据库等；

新硬件、新机器、特殊机器等；

没有很多经验的新技术领域；

性能方面的要求比较难以实现；

被要求的算法高度复杂。

（3）用户体制上的问题

验收能否顺利完成；

是否有订货更改的危险；

和用户共同开发时，工程是否有被抢走的危险（或有被拖延的危险）；

用户担当的业务，是否有拖延的危险；

其它危险。

2）购入/顾客提供物品

（1）品名：

记述购入产品名/顾客提供物品名

（2）筹备

●负责人：

记述筹备负责人的部门名称和姓名

●提供方：

购入品时记述销售商名称，顾客提供物品时记述提供方名称

●预定日：

记述筹备预定日

（3）预定交纳期：

记述筹备部门将物品交付开发部门的预定日期

（4）验收日期（开始～结束）：

记载交付后物品接受检查的期限

（5）维护形式：

从以下维护形式中选择相应的维护形式的编号

（6）备注：

●记述与独立软件商/独立硬件商的合同内容（包括维护，特别是问题发生时的处理规则）

●记述其他的特殊事项

7.日程计划

做成表示系统开发过程的大日程进度管理表，明确DR的召开日期。

1）大日程进度管理表

制作大日程进度管理表，对系统开发中必要的以下方面作出规定：

●规范确定日期

●用户确认返回日期

●开发用机器的设置日期

●用户检查日期

●出厂日期

●现场调试日期

●正式运转日期

●各开发阶段的日期

●DR召开日期

另外还需要考虑在进度上的协调,包括：

●与其它公司的机器的连接

●用户提供物品

●用户开发部分

●其它部门开发部分

●与其它部门的机器相连接

●买入软件

●现场调试计划

8.质量计划

明确要达到的质量目标。

1）性能管理表

一定要将客户要求的和应管理的项目全部列举出来并设定目标值，项目如下：

●最大最小应答时间

●数据输入/输出时间

●（新开发时）系统特有性能的关键指标

●（改造时）对应于改造功能的性能项目

●（改造时）确认对非改造部分的性能没有不良影响的性能项目等

制作性能管理表时要注意以下各点：

●要明确作为性能评价条件的软件/硬件配置和数据条件。

●DR－A要明确性能目标提出方，若是客户提出的性能目标值则在数值的左上角附加“*”。

●DR－B设定基于DR－A设定值的设计的目标值

若DR－A中已设定了设计目标值，则可以与DR－A中设定的值一样，设定的目标值必须能用DR－F进行验证。

对负载有要求时，以功能为单位进行评价。

●DR－C基于软件设计，设定评价方法和预测结果。

即，根据软件设计记述预测的性能值。

●DR－E1/E2是在单元或组合测试的级别上对性能进行评价。

●DR－F对虚拟运行时的性能测定的结果进行验证。

DR－E1/E2，DR－F的测定结果除了记录在性能管理表中以外，还要对测定值的正当性进行验证。

若没有达到目标时，要调查问题发生在何处，是否要花费很多时间，并做成能用来向第三者说明的文件。

2）质量确认分析表

明确为确保质量而必要的质量指标，项目成员以此作为测试的目标值。

●测试项目数是组合测试项目数与综合测试项目数的合计值，或者是在没有组合测试时的综合测试项目数。

●检查覆盖率：

=检查项目数（件）/开发条数（KS）

●错误密度：

=错误数（件）/开发条数（KS）

●错误命中率：

=错误件数（件）/检查项目数

●预定外作业比率：

=处理时间（H）/总测试时间（H）

●必须记述破坏性测试、边界测试、虚拟运行测试的测试目标

●病毒检查记录

●系统中内存与硬盘等空余度

3）知识产权确认

考虑这一过程是否有出让自身知识产权的行为及解决办法。

确定开发中的行为是否对其它人/方面的知识产权构成侵害及解决办法。

4）文档计划

本项目预定要制作的文档全部要记载在设计文档配置管理表中，文档名称由项目统一确定。

5）测试计划

对项目成员明确单元测试、组合测试、综合测试的方针、重点、测试方法等。

必要时还包括：

●在单元测试时，没有保留问题报告的理由

●没有做成单元测试规范书/成绩书的理由

●一起进行组合测试与综合测试的理由

●在有问题时，作成问题表（TroubleSheet）

9.教育/培训计划

明确项目成员是否掌握了系统开发中所必要的技术。

若没有掌握必要技术时，需记录培训计划，并在大日程进度管理表中记载预定日程。

并在以后记载实施情况。

若无进行培训的必要时，在表中用“／”标记。

10.提交计划

要明确向用户提交系统时要提交的成果以及交付条件、交付后的维护体制。

取得确认后做成交纳物品一览表。

1）交纳成果

●交给用户的文档应全部记述在设计文档配置管理表中。

文档的名称要与交纳的物件名称相同。

●交纳目标程序等电子媒体时，明确使用的媒体类型。

2）现场工作责任

●明确有没有现场工作

●明确现场调试时的工作体制（共同/单独作业）

●在直接与最终用户对应时要记录工作要点

●若有现场调试的体制图，应附加在下页。

3）验收条件

●记述接受用户验收的条件

●明确是否有用户验收活动

●在没有用户验收会时，要明确在何处实施验收

4）维护条件

●用合同书来确认交付给用户后的维护责任期限

●产品化软件要填写在使用许可书中确定的保证期限

●记述关于维护的特别事项

●在直接与最终用户对应时，要明确与本公司的联络方式

5）提交程序

●记述向用户提交系统或者是在现场调试结束后，作为结束通知的文件、程序等

●作为相应的资料，现场作业结束报告书/交纳一览表等

11.项目规则

1）进展报告规则

明确作为进度报告的方法，例如：

●每周例会

●用周报和小日程表一起报告进度，在小日程表中用之字型线记入实际进展情况

●完成成果时，与周报一起提出并接受审批

●DR，ＷＴ的残留问题与周报一起，进行解决状况的报告并接受审批

2）规范更改规则

有用户方的需求规范更改时要明确是用什么样的方式来确认与实现的：

●怎样接受来自用户的规范更改内容？

●在项目内怎样进行规范更改？

●规范更改的管理者是谁？

●更改文档是什么？

3）使用的CASE工具

明确系统开发所使用的工具：

●工具名和版本号

●文档制作工具

●设计工具，测试工具

4）更改，修正管理规则

明确各成果的更改，修正管理规则

●文档更改管理

●程序版本管理

●库管理

●组合测试、综合测试中发生的不合格在文档，程序中的反映规则

5）采用的设计规则

如：

规范书制作规则、编码规则、程序检查规则等

6）备份规则

明确开发过程中电子化的文档，记录，程序等的备份规则

●周期：

对应不同的成果采用不同的备份周周期

●保管场所：

原则上要与开发机器分离进行保管，保管环境要好

●保管管理者：

指定管理者，用管理表进行管理

7）病毒检查规则（定期专人检查）

8）其它

其它规则等。

12.相关资料一览表

将系统开发计划书参照的所有资料，做成相关资料的一览表。

●资料名称：

填写资料的名称

●总页数：

文档的总页数

●文档编号/版本：

文档的质量记录的编号以及最新版本号

●未做成的资料在备注栏中填写预定完成日

13.更改记录

当内容更改时，记录更改履历。

1）初次发行时

●序号：

“0”

●发行日：

“发行日日期”

●更改对象·

更改内容：

固定为“系统开发计划书初次发行”

●批准：

开发部长，项目管理部签字或盖章

●审查：

项目负责人

●担当：

承担者签字或盖章

2）计划更改时

“1～N”

“计划更改的要点以及更改的页码”，日程更改时，要一起提交“DR日程更改委托”

3）实际记入时

“实际记录的内容以及记录的页码”

开发部长签字或盖章

4）产品申请出厂时时

固定为“产品出厂时的确认”，它也可与DR-F（实际记入）合并。