购物车(0)
软件项目计划书篇1
二、项目实施方案介绍
（一）项目启动阶段
此阶段处于整个项目实施工作的最前期，由成立项目组、前期调研、编制总体项目计划、启动会四个阶段组成。
此阶段主任务：
公司：在合同签定后，指定项目经理，成立项目组，授权项目组织完成项目目标。
公司项目组：进行前期项目调研，与用户共同成立项目实施组织，编制《总体项目计划》，召开项目启动会。
商务经理：配合公司项目组，将积累的项目和用户信息转交给项目组。将项目组正式介绍给用户，配合项目组建立与用户的联系。
用户：成立项目实施组织，配合前期调研和召开启动会，签署《总体项目计划》和《项目实施协议》。
1、成立项目组
部门经理接到实施申请后，任命项目经理，指定项目目标，由部门经理及项目经理一起指定项目组成员及成员任务，并报总经理签署《项目任务书》。
2、前期调研
项目经理及项目组成员，在商务人员配合下，建立与用户的联系，对合同、用户进行调研。填写《用户及合同信息表》。在项目商务谈判中，商务经理积累了大量的信息，项目组首先应收集商务和合同信息，并与商务经理一起识别那些个体和组织是项目的干系人，确定他们的需求和期望，如何满足和影响这些需求、期望以确保项目能够成功。
3、编制《项目总体计划》
《项目总体计划》是一个文件或文件的集合，随着项目信息不断丰富和变化，会被不断变更，主要介绍项目目标、主要项目阶段、里程碑、可交付成果。通常包括以下几方面内容：
项目描述，项目目标、主要项目阶段、里程碑、可交付成果。所计划的职责分配（包括用户的）；
沟通管理计划，确定项目干系人对信息和沟通的需要：即什么人何时需要什么信息以及通过什么方式将信息提供给他们。质量管理计划，确定适合于项目的质量标准和如何满足其要求。如果有必要，可以包括上述每一个计划，详细程度根据每个具体项目的要求而定。未解决事宜和未定的决策。
4、启动会
项目组与用户共同召开的宣布项目实施正式开始的会议。
会程安排如下：
共同组建项目实施组织，实施组织的权利和职责；双方签署《项目实施协议》。
项目组介绍《项目总体计划》和《项目实施协议》，包括以下内容：
项目目标、主要项目阶段、里程碑、可交付成果。所计划的职责分配（包括用户的）；
项目实施中项目管理的必要性和如何进行项目管理，项目的质量如何控制；
项目实施中用户的参与和领导的支持的重要作用；
阶段验收、技术交接和项目结束后如何对用户提供后续服务。
（二）需求调研确认阶段
此阶段的主要工作是软件公司的项目实施人员向用户调查用户对系统的需求，包括管理流程调研、功能需求调研、报表要求调研、查询需求调研等，实施人员调研完成后，会编写《需求调研分析手册》，并交付用户进行确认，待用户对《需求调研分析手册》上所提到的需求确认完毕后，项目实施人员将以此为依据进行软件功能的实现。如果用户又提出新的需求，实施人员将分析需求的难度及对整个系统的影响程度来确定是否给予实现。需求调研阶段具体包括如下内容：
1、进行需求调研准备
2、编制《需求调研计划》
3、内部评审是否通过《需求调研计划》，项目组、部门经理、商务等人员根据合同要求和项目实际情况对《需求调研计划》草稿进行评审，如评审通过，则在稍后的时间内签署，如评审不通过则重新修改。
4、用户是否签署《需求调研计划》，如用户签署《需求调研计划》，则作为以后需求调研工作的指南。否则重新修改。
5、《需求调研计划》是否有变更，如果计划存在变更，则执行变更控制流程，否则按计划进行后续工作。
6、编写及发出《需求调研通知》，项目组编写《需求调研通知》，确定进行需求调研的相关事宜，发给用户，为顺利完成需求调研工作做准备
7、需求调研，项目组以《需求调研手册》为依据，从业务流程、单据使用、打印格式、报表查询几个方面展开深入和全面的调研，并搜集用户的个性化需求。
8、需求调研分析根据调研的结果，项目组和公司其他技术部门将进一步进行分析，确定合理、可行的需求，将分析结果形成《需求分析报告》草稿。
9、内部评审是否通过《需求分析报告》。项目组、部门经理、公司其他技术部门的人员对《需求分析报告》草稿进行评审，如评审通过，则在稍后由用户签署，如评审不通过则重新修改，直至内部评审通过。
10、编写及发出《需求分析报告确认通知》。项目组编写《需求分析报告确认通知》，发给用户，确定进行需求确认的相关事宜，告之相关部门及人员安排好工作，准时参与需求确认工作，为顺利完成需求确认工作做准备。
11、用户是否确认《需求分析报告》。如果用户确认，并签署了《需求分析报告》，则需求调研阶段工作结束，进行后续的软件功能实现的工作；如没有确认，则进一步进行调研、分析，直至用户最终确认并签署《需求分析报告》。双方签署了《需求分析报告》，需求调研工作结束之后，如果用户提出新的需求或是变更已有的需求，则执行需求新增及变更流程。
（三）软件功能实现确认阶段
此阶段的主要工作是项目实施人员根据需求调研阶段确认的《需求调研分析手册》中的用户需求内容进行具体软件功能的实现工作。在软件功能实现的过程中，项目实施人员将记录软件实现的详细过程。便于公司售后服务之用。每一个实施技术人员必须严格按照要求记录、存档。按照调研要求的所有功能实现完毕后，项目实施人员将编制《软件功能确认表》，将定制好软件功能待用户确认，用户根据《软件功能确认表》上的功能逐一确定软件功能是否达到要求，对不满足要求的功能，项目实施人员将会记录下来并进行功能修改，直到满足用于要求。
（四）数据标准化初装阶段
此阶段的主要工作是项目实施人员指导用户进行系统标准化资料的准备工作，并对用户进行初装资料的软件操作培训，以便用户能够及时的将标准资料录入系统，初装完成后，项目实施人员会对资料初装的情况进行核查，为以后具体业务功能的开展做好基础。
（五）系统培训阶段
系统培训阶段工作是整个项目实施工作中比较重要的工作，用户对软件的操作功能是否熟练将直接影响到后面的软件应用效果，所以软件公司和用户双方要对此阶段的工作给予足够的重视。要充分认识培训的重要性和艰巨性。在项目实施之前对用户的相关人员进行系统和规范的产品培训是非常必要的，达到让用户了解软件产品，最终自己能够解决使用中的具体的问题。
此阶段的培训工作中将用户参加产品培训的人员划分为三个层次：决策层、技术层、操作层，对不同层次的用户参加产品培训人员的培训内容分别是：
决策层：领导在实施中的作用与重要性、决策查询。
维护层：系统维护知识、操作方法。
操作层：操作方法。
具体的培训工作流程为：
1、调研培训信息：在培训开始前3天由用户实施负责人，将参加培训的部门和人员情况填入《受训部门汇总表》、《受训人员情况一览表》。
2、编制培训计划：结合调研结果，与用户实施负责人商议具体培训内容、时间，场地，人员等。项目组编制《培训计划》。
3、签署培训计划：用户签署《培训计划》，进一步确认培训安排。
4、发培训通知：培训开始前2天，按照签署的《培训计划》，将培训内容、时间，场地，人员等信息通知用户实施负责人。
5、搭建培训环境：公司项目组在培训开始前，将培训环境搭建及检查妥当，将培训提纲及培训手册准备好。
6、组织培训：公司项目组培训负责人与用户实施负责人组织相关人员参加培训，按培训制度严格考核。由用户将考勤情况填入《培训人员签到表》。
7、培训考核：公司项目组培训负责人与用户实施负责人组织受训人员参加上机及理论考试。
8、培训总结：公司项目组培训负责人与用户实施负责人一起将出勤情况及考核情况做出总结，填入《培训及考核统计表》，及时向相关负责人
汇报。
（六）系统安装测试及试运行阶段
此阶段的主要工作是在用户真实环境下，对用户网络及硬件设备进行测试，对软件系统进行容量、性能压力等测试测试及试运行的目的在于确保系统各项功能均能正常使用，并且符合用户签署的《需求分析报告》中描述的需求，同时把尽可能多的潜在问题在正式运行之前发现并改正；同时目的还在于在正式运行前用户的有关人员能进一步提高操作水平，掌握操作规范。此阶段的主要工作内容为：
1、 编制计划：与用户实施负责人商议具体测试及试运行时间，地点，人员等安排，项目组编制《测试及试运行计划》。
2、签署计划：用户签署《测试及试运行计划》，进一步确认测试及试运行安排。
3、发测试及试运行通知：在测试及试运行开始前2天，按照签署的《测试及试运行计划》，将时间，地点，人员等信息通知用户实施负责人。
4、搭建环境及数据准备：在试运行开始前搭建好软件环境、硬件环境、网络环境、调通线路；检查软件、硬件、网络、线路等各个环节是否有问题；
5、组织测试及试运行：用户相关各级领导给予全面配合，组织相关人员进行测试及试运行。
6、测试及试运行总结：测试及试运行完成，总结试运行中设备、软件的运行情况，总结试运行中业务流程和操作环节的情况，以书面总结形式将测试及试运行结果通知相关负责人。
公司项目组负责担当指挥，检查用户人员组织情况并给予指导，跟踪检查如下情况：
跟踪单据流转状况。
跟踪新资料登录环节。
观察业务流程执行状况。
观察操作人员操作表现。
观察系统运行速度及异常表现。
观察关键数据的正确性。
及时纠正错误操作、对于新发生的问题及时与相关人员沟通，确定解决办法。
（七）总体验收阶段。
此阶段是对项目总体的完成情况进行验收。验收分阶段进行，在每一项目阶段结束时，用户对这一阶段的可交付成果进行验收，在测试及试运行结束后，对系统进行总体验收。
需要验收的可交付成果：
主要项目阶段
阶段组成
主要里程碑
软件项目计划书篇2
xx软件的短期目标：基于xx数据库（xxSQL）的“xx企业信息备份和搜索工具”能够在一些具体行业或项目中进行推广应用。初期市场开拓的目标在于建立和提高公司产品的信誉和客户对于产品的可接受程度，而非盲目追求数量增长。总之，首先使公司运营正常，实现良性现金流和一定的赢利空间，再求进一步发展，实现良好的投资回报。
xx软件的长期目标：开发和推广大型通用数据库管理系统及其应用产品。
二、公司目前的股权结构
公司目前的股份构成：
三、已投入的资金及用途
公司于20XX年7月成立，注册资金200万元人民币，主要用于产品的开发、测试，市场渠道的铺设。
公司成立以来成功申请了20XX年科技部中小企业技术创新基金（75万元）和20XX年中国市第一批软件和集成电路产业发展专项资金（50万元）。
四、公司目前主要产品及服务
公司的主要产品：“xx数据库管理系统（xxSQL）”。
正在开发的产品有：“xx企业信息备份与搜索工具”。
公司还计划基于xx数据库建立“xx数据服务中心”，为广大中小企业用户提供数据集中维护及安全保障。
五、产品的知识产权和归属权
“xx数据库管理系统（xxSQL）”是由两位创始人（xx、xx）在国外任教期间发明，通过与任教所在大学签定法律合同（见附件），数据库的专利权、出版权及其相关知识产权都归属于两位创始人所有，目前数据库的所有知识产权已转到中国xx软件有限公司。
“xx企业信息备份与搜索工具”则是在中国研发的基于xx数据库的应用产品。中国xx软件有限公司拥有产品的所有知识产权。
六、市场概况和营销策略
目前企业搜索市场还处于起步阶段，还没有出现一家独大或几分天下的局面，因此，现在是进入企业搜索市场的最好时机。
xx的总体营销策略是：分别向中小企业、大型企业和服务运营商提供不同的细化产品，逐步开拓本地、国内、国际市场。
七、核心团队
公司的核心团队由五人组成：
xx（公司创办人，现任董事长兼CTO，xx大学计算机系终身教授，数据库及人工智能专家）；
xx（公司创办人，现任总经理，xx大学计算机系终身教授，人工智能专家）；
周先生（于95年获美国名校计算机科学博士学位，曾任美国xx公司中层管理人员、大型外资公司副总裁，软件工程和人工智能专家）；
陈先生（于88年获美国名校计算机科学博士学位，曾任美国加州硅谷著名软件公司高级系统分析师）；
王先生（xx大学计算机系博士后，曾任加拿大著名软件公司高级系统分析师，数据库专家）。
八、公司优势说明
公司的主要优势如下：
1) 企业搜索引擎的技术处在不断发展完善中，xx拥有自主的先进技术，创新能力强；
2) xx企业备份和搜索工具是基于xx自身的数据库产品研发的，充分利用了数据库的
高性能和安全机制，产品性价比高；
3) xx能快速灵活地向用户提供按需定制服务。
九、目前公司为实现目标的增资需求
为了抢占企业信息搜索的市场发展先机，xx需要的外部投资为750万元人民币，加上xx的预期销售收入及其他资金，致力于“xx企业信息备份与搜索工具”产品的市场开发。
公司计划在20XX年实现收支平衡，09年实现销售赢利，占据国内企业搜索市场有一定影响力的份额，打造xx软件品牌。
十、融资方案
企业的产品经营和资本经营是相辅相成的，产品经营是基础，资本经营则是企业快速发展的助推器。公司此次计划筹集750万元的风险资金，主要用于“xx企业信息备份与搜索工具”的市场开发。
此次融资的资金筹措方式：股权融资（投资750万获取20%股权）或引进战略投资者。 投资方可通过股票上市或公司兼并的方式退出。
软件项目计划书篇3
对任一项目而言，有三个文件是非常重要的。即:项目章程、项目范围说明书，项目管理计划。这三个文件均产生于项目启动阶段和项目规划阶段。其中项目章程被认为是三大文件之首（项目章程、项目范围说明书，项目管理计划）。一个项目，不论大小，都应该有项目章程。
项目章程由项目发起人(Sponsor)签发，自签发之日起，项目经理即获得法定权力。
项目经理在获得法定权力之后的第一动作是制定项目初步范围说明书。为了制定这份文档，他/她将广泛地收集来自项目发起人的需求，以便在项目计划正式编制之前，与项目发起人在项目范围的理解上达成一致。项目初步范围说明书还将在后续项目范围规划过程中进一步细化，并融入项目客户、执行组织、项目干系人等各方面需求，进而形成完整的项目范围说明书。
项目初步范围说明书编制完成以后，项目经理将进入项目计划编制阶段。这个阶段将会涉及项目管理方方面面的规划、计划。有经验的项目经理在此过程中总是会认真听取和吸收团队骨干成员和同行们的经验意见，从而形成广为认可和接受的规划、计划。
经过权衡和必要的调整，这些文档最终将被集成到一个完整的项目管理计划中。项目管理计划经由项目发起人、高级管理层审批以后，即可生效。
此后，项目经理将召开项目开工会议，宣布项目正式开始进入执行阶段。
项目启动阶段的项目章程和项目初步范围说明书，也可以体现在分包或采购合同中。这在软件外包服务型企业中最为常见。
通常，伴随合同到达项目经理手中的还有项目建议书，项目建议书由项目发起人制定，内容和项目章程中有关产品、可交付成果的描述大致类似，此外，还应包括对项目经理成功完成此项目的一些指导性建议。项目经理进行综合考虑，与相关干系人磋商，在项目团队相关专家的帮助下，制定出合适的项目管理计划。
上面讨论的是一般项目启动过程组与规划过程组。具体到测试项目的启动与规划，工作内容也是类似的。读者朋友请根据所在测试项目的特点做适当调整。需要交待清楚的是测试项目启动与规划过程组有可能与其他六个过程组（测试需求分析、测试设计、测试执行、测试项目收尾、测试交付、测试项目监控与调整）在项目实施过程中有频繁的迭代关系（参见图1）。
比如，规划过程组有可能在整个项目生命期内都有更新和完善。
对于整周期软件开发项目的测试而言，上述过程组的内容会有较大的差异。
比如:项目章程将重点关注开发，而不会过多讨论测试相关的工作。对于这一类型的软件测试，笔者建议在任命开发项目经理的同时，由项目经理[适用于项目型或强矩阵组织]或高层经理[适用于弱矩阵或职能型组织]指定项目测试经理。测试经理应根据项目章程、项目初步范围说明书和项目建议书尽早开始软件测试相关规划和设计，并和项目经理沟通、协调，以将一些重要的信息及时反映给项目经理，从而使项目计划能较好地支持测试工作的开展。
软件测试需求分析
理论上，软件测试需求是源于软件需求的，而软件需求又是源于用户需求的。然而，有些时候在分析软件测试需求时并不存在已经文档化的软件需求规格说明。
在这种情况下，要分析软件测试需求可能仍然需要追溯到用户需求。由于后者涉及需求工程的专门知识，本文略过不做细述;这里重点讨论前者。在一个规范化的软件需求规格说明中，用户需求是由更高层次的业务需求（体现在项目章程、SOW、项目建议书等文档中）细化而成，它通常描述了用户使用该软件系统会涉及到的不同的执行路径、工作逻辑以及所预期的处理结果。在UML表示方法中，用户需求通常通过Use Case来进行刻画。
接下来，用户需求将进一步转化为三类需求项，即功能需求项、性能需求项以及约束性需求项。这三类需求项就是通常意义上的软件需求项。管理这三类需求项的矩阵被称为需求矩阵。
理论上，在测试资源许可并且确有必要的前提下，测试的使命将是验证和确认待开发的软件及其中间产品满足需求矩阵各个需求项。（注意:为了简化讨论，这里笔者没有把需求的验证与确认纳入进来，实际上这部分工作也是软件测试工作的重要组成部分。）
然而，几乎没有几个公司或开发团队能够提供这类测试所需的诸多的资源，此时，一种可行的策略是将待测试的软件需求项按照优先关系进行排序，以帮助测试经理决策在既定资源的情况下，应该如何统筹安排测试工作。
软件需求项是测试需求分析的起点，这一点在工程实践中并不绝对。对于不同阶段的测试（这里主要指单元测试、集成测试、系统测试和验收测试，暂不考虑验证技术和需求和设计的确认），测试需求开发所涉及的工作内容和方法都会略有差异。例如，如果是一个验收测试，那么，除了个别的需求需要做进一步明确外，几乎可以将测试需求等同于用户需求和业务需求（由于该类测试是以客户为主体，因此并不需要向下追溯到软件需求）。
又如，如果是系统测试，除了需要对不具备可测试性的软件需求项进一步开发外，几乎可以对软件需求和测试需求不做区分。
再如，如果是集成测试，测试需求应该从概要设计规格说明中导出。如果尚不存在概要设计规格说明，就需要从软件需求规格说明出发，与软件设计人员协同工作，具体定出构成系统的各个模块、子系统、分系统的功能、性能、约束性条件以及相互接口关系。根据协同工作的结果，开发出对应的测试需求。
最后，如果是单元测试，测试需求应该从详细设计规格说明中导出。如果项目不存在概要设计规格说明，就需要从概要设计规格说明出发，与软件设计人员明确每个模块内部的对象属性与方法以及对象与对象间的通信关系。根据此结果，进一步开发相应的测试需求。相应地，上一节所说的对软件需求项进行优先关系排序在实践中要变通地理解为对测试需求项进行优先关系排序。
读者朋友可能会问，对于整周期的开发项目，以上论述是否意味着测试需求开发的依据文档是否要根据测试所处的阶段而不断调整呢？是的，笔者认为这也是完全必要的。我们不能指望软件需求项能够描述清楚集成或单元测试阶段的测试需求。测试需求的开发总是有赖于相应层次的软件规格说明书
只有在开发团队不能提供的情况下才确有必要循着“详细设计规格说明->概要设计规格说明->软件需求规格说明->用户需求规格说明->项目章程、合同、项目建议书、工作说明书等”的顺序往前追溯。通常相关依据文档的可测试性越好，测试需求开发所需要的工作量越少。
软件项目计划书篇4
笔者所在院校的计算机应用技术专业是与某教育集团开展的校企合作教学改革专业，采用项目驱动+任务贯穿为主线的“双核”内容组织思路开展教学活动，对于理论性强的课程采取以任务模块为主线，加深原理和思想的理解和升华，对于实践性强的课程采取以项目驱动的内容组织思路，重点训练学生的实践动手能力和综合运用能力，因此，任务和项目是教学活动的主要手段。为实现“零距离就业”，引用企业软件项目管理模式，来指导校内学生项目的实施，是专业技术类课程必行之路。
二、为什么要借鉴企业软件项目管理
1、运用软件项目管理知识是教学项目成功实施的保障
教学过程中，真实项目活动在实施过程中最大的问题就是，学生无法按时保质的完成整个项目功能和目标。在教学项目实施过程中，借鉴企业软件项目管理的先进经验，完全模拟企业开发软件项目的工作流程，让讲师、组长及成员模拟企业员工角色，从项目的招投标、可行性分析、需求分析等到整个项目开发完成、测试完成，所有学生均参与，均有任务，并且按企业项目监控手段开展教学项目实施监控，保障教学项目成功实施。
2、让学生提前了解企业软件项目管理流程
目前，项目教学法已应用于各种课程教学中，而项目的选取或实施并不是都能和企业接轨。在教学项目实施过程中借鉴、模拟企业真实软件项目的实施和管理过程，并借鉴、使用企业真实软件项目管理工具，能让学生提前了解到自己所学的专业知识，在以后就业后如何应用于工作岗位，了解企业软件项目管理的真实流程，缩短甚至实现“零距离”就业。
3、为项目教学提供多种监控手段
课程项目实施的目的是总结复习某阶段学习内容，将所学的零散知识点整合成完成的真实项目，让学生真正理解课程重点，并了解所学知识如何应用于实际，项目在实施过程中并不可能完成是前期所学过的内容，有些是同类知识点的扩展，项目的实施是有一定难度的，在这种情况下，项目能否按期保质的完成是教学项目管理的重点。借鉴企业软件项目管理中的先进监控手段来监控教学项目，包括监控文档和监控软件的应用，对教学项目的实施提供了完美的监控和保障措施。
4、带学生项目的过程也是一个真实商业项目开发的过程
专业技术类课程教学项目选取的原则是，选取大型真实商业项目中的部分典型业务模块，至少80%以上相似。教学项目在再是为了知识点而设计，而是为了市场需求而设计。因此，讲师在带学生完成这些项目的过程，实际上也是一个真实商业项目的开发过程，不权能提起学生学习兴趣、提高学生技能水平，对讲师无形中也是一个企业锻炼。
三、如何借鉴企业里的软件开发管理来指导教学项目
分析教学项目在实施过程中遇到的主要问题有：无法按时完成项目、项目质量不达标、参与学生任务分配不合理，纠其原因主要是讲师无法对项目实施标准有明确的参考和定义，对项目目标定义不完全，项目实施计划不合理，缺乏项目开发监控的必要手段。联系到学生以后的就业方向，及项目选取的专业范畴，需要借鉴企业软件开发管理来之不易的经验来指导教学项目。
1.借鉴企业项目计划制定合理的教学项目计划
软件企业里开发计划的制定一般有两个部分，一是软件本身的计划，即需要开发什么软件、具备什么功能、构架、界面、测试等;二是开发项目的计划，即谁来开发具体功能、具体开发工作的资源、时间、顺序、控制等，而且这两部分由开发的具体实际情况来确定顺序或交叉开展。
教学项目的开发目标及功能，在项目教学文档中一般均明确给出，讲师要做的是分析项目功能的技术要点，对班级项目小组专业技能水平进行摸底，提出项目开发整体计划，并要求项目小组长制定小组开发计划，讲师在小组计划制定时进行必要指导和干预。主要工作比如：首先，掌握项目难度。分析项目开发目标和技术要点，确定项目各技术难度等级，扩展知识点举例讲解。然后了解学生的技术能力。充分了解平时的学习情况和动手能力，在组长分配任务时当面沟通，保证任务分配的合理性。最后需要合理分配任务和时间。在教学项目规定的课时内完成项目的实施，必要的时候开始课后小班辅导，对难的技术点分配给动手能力强的学生，容易的技术点分配给动手能力弱的学生，保证每位学员都有任务，且任务对学员来说是可行的。
在任务分解时借鉴企业“站立会议”的实施方法，把分解的模块和任务写到分发在成员手上的贴纸上，并按模块和任务的紧急不同，选择不同的颜色，要求成员写上预计完成时间(以天或课时为单位)。将贴纸贴在分小组的项目进度表上(讲师制定)。
2.模拟企业真实项目人员角色
教学项目的选取应是企业大型真实商业项目中的部分典型业务模块，至少80%以上的相似度，因此，在实施过程中学生的角色完成模拟借鉴企业员工角色。在能力互补、差异匹配分工原则的基础上，对于讲师定位在项目经理(大型的毕业设计项目定位项目总监)，主要任务是进行任务模块分解，项目总体开发计划的制定和编码过程的监控。学生的定位均是实习生，小组长定位在协助项目经理实施项目管理的优秀实习生。组员定位在实习程序员(首要能完成编码，其次会写文档、最后能讲解业务流程)。
3.借鉴软件企业项目开发文档
借鉴软件企业项目开发文档，合理的设计教学项目开发文档，来指导和监控教学项目的实施。根据实际项目一般可以设计出六个文档和三个表格，分别是：项目立项及开发规划说明书、需求规格说明书、概要设计说明书、详细设计说明书、产品测试说明书、项目关闭总结报告、项目开发计划表、小组编码进度控制表、项目测试报告表。
根据教学项目的大小及难易程序，合理安排文档制定人。对于小型项目，可以在课前准备好项目开发计划表，包括分组计划表及编码计划表;课中则要求组长每次课程后提交编码进度表，同时召开项目组长的“站立会议”，保证项目实施进度，并要求组长召开组员之间的站立会议，核定编码进度。对于中大型项目，比如毕业项目，在课前准备好项目立项及开发规划说明书、需求规格说明书、概要及详细设计说明书和项目开发计划表。课中则要求组长制定小组编码进度表，同时讲师召开小组长站立会议，小组长召开组员站立会议，监控项目实施。
软件项目计划书篇5
【文献标识码】A
【文章编号】1672—5158（2012）10-0416-01
引言
嵌入式软件已经在我国航天导弹武器系统等尖端产品中得到广泛的应用。目前，《GJB5000A-2008军用软件研制能力成熟度模型》已经并实施，航天嵌入式软件项目的研制过程逐渐要依据这个标准进行。软件作为航天控制系统的关键部分，其地位显得越来越突出，分系统级软件规模已经超过数万行。同时从事软件研制人员已经形成一个组织分工明确、相互配合紧密的团队，从任务书、需求分析、概要设计、详细设计、代码实现、软件测试、交付和维护等环节，每个岗位可能涉及到多个人员。如何通过软件项目策划，保证软件研制流程明晰、可控、软件产品质量可靠，成为型号研制工作的一个不可或缺的重要环节。
1 项目策划的目的
随着管理要求日益严谨，软件管理由粗放式向精细化和准确化转型成为大势所趋，利用软件策划帮助研制方提高研制进度管理的有效性，保证产品质量、提升核心竞争力已经成为共识。策划的目的是为执行软件工程和管理软件项目制定合理的计划，旨在使软件开发人员及管理人员充分了解软件项目策划过程，使项目管理人员遵照过程实施项目策划活动、制定项目开发计划及执行相关策划活动。
2 软件策划前提和输入
项目策划的前期，软件项目组成员要积极参加整个系统项目的早期策划活动，并在系统方案的制定和评审过程中，共同讨论方案报告，协商有关软件项目的目标、范围、进度、资源等，从而逐步了解软件在系统中的作用、进度、功能等。同时对设计输入的任务书要进行认真评审，对其每项内容了如指掌，并纳入配置管理。参加项目策划活动的人员还要接受相关培训。
3 软件策划的规程
软件策划需经多个步骤，从而对整个项目阶段工作进行全面梳理。根据输入的任务书和标准等，首先依据策划的主要内容，制定软件策划的工作计划，然后选择软件生命周期模型，确定软件开发阶段，其次就要进行工作分解结构（WBS）分解，这是策划中非常重要的步骤。在此基础上进行规模、工作量、成本和进度估计，最后形成软件开发计划。其中有多个非常关键的环节，直接影响策划的真实性和可执行性，因此需要重点关注。
3.1 工作分解结构
工作分解结构（Work Breakdown Structure，简称WBS）是归纳和定义整个软件项目范围的一种最常用方法，它将一个项目分解成易于管理的几个部分或子项，以确保找出完成项目工作范围需要的所有工作元素。
工作分解结构是对软件工作产品和软件过程进行分解，以层次结构来组织软件项目的产品元素和活动元素，将项目的软件工作产品和软件过程分解为较小的、更易于管理的元素。
WBS分解时，通常按照树型结构，不断将项目的最终目标分解到一些较小工作单元，直到这些工作单元可以被很容易地“控制”住为止。在划分任务时，任务的颗粒度不能太大，也不能太小。颗粒度太大，难以及时发现问题；颗粒度太小，就会增加管理成木。任务的颗粒度最小可以到半天，最大到周，一般以小于3天为宜，也就是说项目经理能够在1周中至少检查2次成员的工作进展情况。适当的任务颗粒度便于监控，另一方而也有利于调整任务。当出现任务拖期时，可以比较灵活地重新安排人员接手其他人员的任务。
3.2 项目估计
根据WBS分解的项目内容进行项目估计，项目估计包括项目规模、工作量和成本的估计，这是整个策划中的关键环节，只有项目估计尽量准确，才能保证项目进度、质量能够受控。为了保证项目估计合理性，可采用下面措施：
1）借助历史数据。历史数据是“经验”的量化，通过和历史项目的数据对比，可降低估计的风险。在借鉴历史数据时，要注意数据的可比性，要考察项目类型是否类似、生命周期模型是否类似等。
2）采用多种估计方法互相验证。在估计时可以采用多种估计方法，然后对多种方法的结果进行对比，通过分析其差异以判断合理性。
3）细分任务。任务拆分的越详细，就越容易估计，越容易和历史数据对比。内容任务要完备。估计时要识别出所有工作，不要有遗漏。
4）有估计经验的人参与估计。一方面要对参与估计的人员进行培训，另一方面需要在实践中积累估计经验。每次估计完成后，都要和实际的情况进行对比，经过3-5次反复，则可积累估计经验，提高估计准确性。
多人分别估计并形成估计表，然后由项目负责人进行汇总形成软件估计报告。
3.3 资源和管理计划
人力资源策划方面要包含完成软件开发项目必需的人员数量，姓名，指明项目管理、软件工程、正式软件测试、软件产品评价、软件配置管理等分别所需的人员数目及总数。相应岗位若需通过相应岗位的培训考核，则还要制定培训计划。
项目负责人要确定软件项目相关的利益相关方，包含硬件设计人员、任务提出方、测试设备负责人、用户代表、评测机构等。从而协调制定相关的计划或关键点，描述利益相关方的权限和责任，以及与其它组织的关系。
基础设施资源的策划要同步进行，估计时参考类似项目的历史数据，根据项目需求、工作产品的规模，考虑开发环境、测试环境、目标环境或者这些环境的任何适当组合情况下所需的基础设施资源。同时制定测试计划、配置管理计划、质量保证计划、风险管理计划、数据管理计划、里程碑评审计划和沟通计划等。对上述计划确认后进行配置管理。
4 风险估计
标识风险源为项目研制过程中检查随时间而更改的状态提供了基础，直接显示出影响项目研制目标的各个因素。风险源来自项目的内部和外部。随着项目的进展，可能会发现更多的风险源。项目策划阶段就要识别和分析风险，并制订风险减缓计划，才能进一步跟踪项目风险，及时消除各个风险源带来的影响。
5 形成软件开发计划
软件项目计划书篇6
核电设计分析以及运行支持软件是开展核电工程设计以及维护核电厂运行的重要技术手段之一，对核电工程设计科研工作的质量、研发效率以及核电厂的运行安全起到了至关重要的作用。由于核电设计分析以及运行支持软件具有很强的核安全相关性，多年以来，国外核发达国家对核电软件设计研发以及运行管理都是高度重视的，相关软件研发的各个流程环节、软件适用性、可靠性、过程质量管理以及后续的应用均受到核安全监管机构的高度关注。与此同时，在国内，核电相关的安全也受到了核安全监管机构的高度关注。针对核安全相关软件，国家核安全监管机构也制定了相关的软件评价实施办法。根据相关实施办法，核安全相关软件的认证过程不仅重视软件的重要物理现象识别、物理模型建立、验证计算模型的合理性以及不确定性和敏感性等评价，对软件的研发过程、研发体系以及质量保证体系的建立也同样重视。在中核集团龙腾自主创新科研项目的支持下，由中国核动力研究设计院牵头，中国核电工程有限公司、中核武汉核电运行技术股份有限公司参与共同完成了成体系的核电设计与分析软件包NESTOR（NuclearPowerPlantEngineeringSoftwareTechnologyResearchProject)）。NESTOR软件包包含了核电设计与分析所需要的相关专业软件，涉及核反应堆物理设计、屏蔽与源项设计、热工水力与安全分析、燃料元件相关设计、系统与设备设计、仪控设计、软件共性技术等相关领域。NESTOR软件项目自2011年立项以来便高度重视软件研发体系建设，并针对“软件开发过程质量保证体系与开发规范”成立单独的课题进行研究。该项目致力于将核电工程设计与软件工程化相结合，贯穿研发全生命周期，覆盖需求管理、模型研究、软件设计、VV流程等各个环节，建立健全核电软件工程化研发体系，并在NESTOR项目中的各个软件开展软件工程化实施流程。长期以来，建立适应核电工程特色的软件工程化研发体系，并将体系融入工程设计、科研及管理工作中，一直是NESTOR项目的重要研究方向之一。
1核电软件工程化体系建立
核电设计分析软件以及运行支持软件具有高可靠性、高安全性、高经济性的特殊要求。在国家核安全导则、GJB5000A、CMMI等软件工程化的总体指导要求下，遵循软件工程化思想，建立一套具有核电工程特点的完善的核电软件工程化研发管理体系，对确保研发团队开发出高质量、满足核电核动力工程需求的软件产品起到重要的保障作用。中国核动力研究设计院经过多年的研究及实践应用，制定了覆盖软件工程化研发中的重要过程域的指导性文件《软件工程化体系文件》。
2NESTOR软件工程化实施过程
软件工程化研发的实施主要覆盖软件开发过程和软件管理过程。针对NESTOR软件，主要分为工程化主机平台类软件以及嵌入式软件。软件的开发过程依据软件的类型以及规模等属性，选择适用的软件生存周期模型，并定义软件开发的阶段及阶段中的活动。软件管理过程主要包括需求管理、项目策划、项目监督与控制、过程和产品质量保证、配置管理、测量与分析等过程，软件项目的管理过程中的活动可根据软件的自身特点进行裁剪。
2.1核电软件的管理过程实施
2.1.1项目初始管理策划
在接受核电软件研制任务后，应落实项目组主要成员，并组织各阶段工作安排。项目负责人根据《软件研制能力等级要求》，组织对项目软件的重要性等级和规模等级进行确定。最终形成《项目软件工程化策划书》，作为开展核电软件工程化研发的输入。
2.1.2研发过程规范制定
NESTOR项目结合自身的特点，建立了一系列的研发过程规范，规范由项目部批准后应用于本项目所承担的所有核电软件研发中。
2.1.3项目监督与控制
核电软件项目的监督与控制是将软件项目的实际执行情况与相关计划要求进行对比分析，如超出偏差范围，则采取必要的纠正措施。如软件需求发生重大变化，则修订计划以满足相关要求，从而确保项目研发工作有序、正常的实施。
2.1.4核电软件项目过程和产品质量保证
开展质量管理的策划工作，主要目的是识别NESTOR项目及其最终交付成果的质量要求及规范标准。通过有计划地、定期地对NESTOR相关软件全生存周期的开发与管理活动进行符合性检查，对各阶段工作产品与活动进行审核来判断研发工作是否按照软件工程化体系的要求实施，从中发现不符合项并实施相应的纠正措施。
2.1.5项目配置管理
配置管理是结合配置管理工具对开发的软件进行版本管理与变更控制，对软件开发过程的各阶段工作产品进行有效保护，维护阶段工作产品和软件产品的完整性和可追溯性的管理过程。NESTOR项目相关软件的配置管理贯穿于软件研发活动的全生命周期以及各个流程环节。NESTOR项目采用专门的软件配置管理工具，对程序源代码、版本、各阶段文档、工况数据及流程进行有效的配置，实现了研发过程的自动化配置和动态管理，增加了软件研发人员对设计流程的能见度。NESTOR项目在配置管理实施中建立了软件开发库、受控库以及产品库，并限定配置项在不同库之间的流转的权限及流程的控制。通过实施配置管理有效地保证了软件的正确性、完整性及可追溯性。
2.1.6测量与分析
测量与分析是NESTOR软件项目各软件设置有专门的测量分析工程师，该人员负责依据既定的测量目标、测量项、数据采集和存储规程、分析规程等相关要求采集和分析测量数据，在合适的控制点/项目结题时采集并汇总相关数据，形成测量分析信息。项目执行的过程中，相关的测量分析信息及时专递到项目组团队成员内以及利益相关方。通过测量与分析活动，有效的监督了项目绩效，并为后续活动做出有根据的管理和技术决策，以便在出现问题时及时采取相应的纠正措施，实现项目监督控制的可视性、及时性
2.1.7项目评审
在软件开发与管理过程中，针对重要节点或者里程碑组织软件项目组内部及外部人员对NESTOR软件产品、研发活动及工作进展情况的符合性、合理性和正确性进行验证。通过评审活动，可以高效率、尽早发现并消除问题，从而保证软件产品的最终质量。
2.1.8记录控制
为满足软件工程化体系要求，NESTOR项目实施工程化研发过程中所产生的记录、以及能够证明体系文件有效运行的记录、作为可追溯性依据的记录均进行了有效的控制。通过核电管理平台，对项目实施中产生的所有过程记录文档进行分发、流转等控制，过程记录包括技术传递单、技术联系单、备忘录、会议纪要、设计评审报告、项目周报、QA核查单、质量保证报告、配置管理报告等。同时，通过档案管理系统，对项目所产生的所有设计文件进行有效的归档及控制。
2.1.9软件的鉴定与应用
研发完成的软件，在未经过专业鉴定前仅可用于学习、科研，不能直接应用于工程设计。软件的鉴定是专业设计人员对入库归档的软件产品进行专业分类及筛选后，由软件鉴定专家委员会对筛选后的软件进行鉴定。鉴定软件的功能、性能、工程适用范围、可靠性等各方面能够满足相关工程使用需求。NESTOR所研发的软件只有通过鉴定才能够归入工程可用软件库。当工程项目产生软件应用需求时，即可从工程软件库中选择合适的软件。
2.2核电软件的开发过程实施
2.2.1核电软件研制策划
NESTOR软件研制策划工作是估计NESTOR软件包中每个软件的规模、开发工作量，并根据估计结果，结合进度要求来制定合理的开发计划，提出必要保障条件的管理过程。本项工作主要由项目软件负责人组织，对所负责软件的根据各项软件的开发和管理工作进行全面的策划，并安排相关角色依据既定的分工制定所需研制软件的各项计划，最终以书面的形式形成《软件开发计划》、《软件配置管理计划》、《软件质量保证计划》、《软件测量分析计划》、《软件验证和确认计划》、《文件清单》以及估计记录等相关文档，文档经过评审后生效执行。相关文档是软件开发过程中各项活动的重要依据文件，并将随着软件研发过程而细化或调整.
2.2.2核电软件需求分析
NESTOR项目结合核电工程软件特点，在需求阶段开展了详细的需求理解、需求确认、需求跟踪等需求分析活动，需求包括功能需求以及非功能的需求。需求分析是软件生存周期中最重要的一步。只有通过需求分析，才能准确地将软件的功能以及非功能的需求从概念描述转换为具体的可测量的规格说明形式。NESTOR项目的各个软件在需求分析阶段都依据软件的相关需求完成对应软件的需求分析活动，并以书面的形式形成《需求说明书》/《需求分析报告》，同时建立并维护需求跟踪矩阵。NESTOR项目在开发的过程中持续跟踪维护需求矩阵，确保了需求与项目策划的一致性，并在必要时进行变更。
2.2.3核电软件设计与实现
软件的设计是在需求的基础上，对软件开展计算部分的设计以及界面设计工作，计算部分包括系统结构设计、数据设计、接口设计、算法以及过程设计，界面部分的设计工作包括界面原型设计以及界面设计，软件设计即是把需求转换成表达的过程。在设计活动完成后，软件的设计工程师需要依据体系文件以及相关规范编制相关的《软件设计说明书》，设计说明书可依据软件规模或者复杂程度拆分成《概要设计说明书》以及分模块的《设计说明书》。在软件的实现阶段，按照对应的编码规范，依据设计结果实现软件编制、编译和调试，编制《软件编码报告》以及《用户手册》。《软件编码报告》主要对软件的数值计算及界面模块的目录结构、模块结构、全局数据、各模块的功能和数据，以及软件的编译运行方式、集成方式进行描述《用户手册》主要对软件的功能、性能、运行环境、安装以及操作说明进行描述，给最终软件使用对象对软件的使用有直观的了解。
2.2.4核电软件测试及验证
软件测试是由人工或自动方法来执行或评价系统或系统部件的过程，以验证它是否满足规定的需求。测试活动由软件测试工程师负责，在测试的策划阶段形成《软件测试计划》并开展测试设计，包括测试用例说明等相关文档。NESTOR项目的测试计划以及测试说明文档均经过评审，以确保测试工作的有效性。测试工作严格按照计划及测试说明执行，对测试过程发现的缺陷应进行报告、确认、修正和验证，并形成缺陷记录单，通过多轮测试及回归，确保缺陷全部关闭或得到妥善处置。测试完成后编制《软件测试报告》。通过测试的软件，由独立于开发团队的验证工程师，通过确认用例对软件进行验证，确认用例包括基准题、实测数据（试验数据或电厂运行数据）等，通过验证确保软件的功能、性能以及计算精度满足预期。采用第三方验证的方式对所开发软件的正确性进行确认
2.2.5核电软件
VV验证和确认遵循GJB5000A要求以及软件工程化体系执行，从VV的过程、过程中包含的VV活动，再到具体的VV任务，多层次全方位地定义验证和确认流程。N开展VV活动是确保NESTOR软件的质量和可靠性的重要措施，通过VV活动确认各项需求以及设计要求正确实施，识别期望的结果和实际结果之间有无差别，有效地提高软件计算的精度并保证软件的正确性，确保NESTOR软件质量。除了项目团队内的VV团队，NESTOR项目还创新的采用软件研发合作模式，邀请了高校测试组、专业测试公司以及第三方验证团队，针对开发的核电软件根据相关行业内规范开展了第三方独立的测试和验证。通过有效利用外部资源，对软件的功能、性能进行全面的测试验证分析，有效地摒除了内部团队在相关工作中的“程式”思维、思路局限性而带来的漏洞，更多的发现软件运行中的问题，进一步提高所开发核电软件VV的全面性和客观性。
2.2.6核电软件结项
软件研制完成后，项目软件负责人组织对软件的测试验证情况进行分析，根据项目目标要求，组织总结分析工作。就软件的研发工作进行总结，组织编制《软件开发总结报告》，另外，还有软件开发过程中的相关配置管理情况、质量管理情况进行总结，编制《配置管理总结报告》以及《质量保证总结报告》。相关总结文档完成后，组织项目结项评审，软件具备结项条件后，提交验收申请并组织验收，形成验收报告。
3结语
NESTOR软件包通过结合广泛的工程经验，依托科学理论和软件工程化技术的进步，形成了重要的自主创新能力，成功应用于华龙一号工程设计与校核，并正在进一步应用于其他核电工程开发中。部分运行支持软件也已在国内多个核电厂推广应用，发挥了良好的经济效益。通过工程化管理体系的建立以及对软件工程化的过程管理实施，NESTOR软件包的研发工作以及运行管理实现了流程精细化管控以及监督可视化、可控化。确保了NESTOR软件在满足工程需求同时，提升了研发效率、缩短了研发周期，提高了软件的质量，大大减轻了运行管理成本，提升了软件研发精细化管理水平。
【参考文献】
［1］张晓龙.现代软件工程[M].清华大学出版社,2011.
［2］林锐,彭国明.CMMI和集成化软件研发管理[M].北京:电子工业出版社,2008.
软件项目计划书篇7
P6项目管理系统软件程序，研发方为美国，属于大型项目的管理系统软件，P6R8.4为最新版本。该系统软件程序具有较强灵活性，能够借助制定项目计划、实时化跟踪、项目管控、协同工程项目、积累数据资料等，全面监督及管理工程项目。同时，还可依据现有资源，针对多个项目开展计算分析操作，编制每个项目优先的等级，为管理者提供最具真实、完整性的数据信息。
2具体应用
2.1项目背景
以某多层建筑项目工程为案例，该项目属于某校区内的图书馆建筑项目，占地约为5330㎡，实际的建筑面积约为22238㎡，总建设投资达2439.06万元。主体结构为5层，建筑总高度约为32m。
2.2具体应用
2.2.1基本流程
①步骤一：采集工程项目各项信息数据，包括P6项目管理小组成立、存储所采集到的信息数据、全面了解项目工程具体情况；②步骤二：工程项目计划环节，设立项目工程目标、工作范围，设计工程代码与分类码，明确所有施工工序工作耗时，合理计划项目工程实际花费资源的数量，设置项目总体逻辑关系，计算项目所涉及到的各项费用；③步骤三：项目控制环节，参考项目工程建设项目勘测数据及具体情况，获取数据信息并做好比对分析，整理、归纳及分析数据信息，把检测结果数据信息传输至P6项目管理系统软件程序当中，依据该数据信息，重置新项目的工程数据信息；④项目工程管理的结束环节，做好工程项目总结工作，得出相应经验及教训。
2.2.2建立项目
项目开始初期，就需构建P6模式的项目管理小组，并开展P6模式的项目管理操作，进入到软件系统程序界面后，需先建立好企业的项目结构，具体使用该P6模式的项目管理系统软件期间，所有项目工程均需建立在该系统的项目结构内。建立该项目结构期间，需结合不同管理功能予以合理设定。站立于管理角度上，仅项目工程管理采可需借助P6的项目管理系统软件。但是，对于工程项目监督管理及财务控制等相关模块，还需建立所对应的各种项目结构。待项目结构均建立完毕，需继续开展OBS创建工作，也就是对企业所有组织形式进行模拟，在该软件系统程序当中依据企业各个部门形式予以细致地区分，划分好项目工程各个环节的具体责任。在该建筑项目当中，模拟企业项目工程组织架构主要包含着项目的领导小组、工程部、财务的预算部、设备部、材料部、质量部等相应部门。而后，需在该软件系统程序当中创建好具体的日程安排，所有项目工程当中，需对土建施工日期的安排做好规划，忽略掉工程期间节假日。但因该项目属于校区内的图书馆，故需充分考虑到校区内图书馆管理者日常工作时间这一方面因素，对于该国内工程项目当中工作日的制度安排上，则是以5天的工作日为基准，倘若涉及到节假日，则可自行做出相应调整。
2.2.3编码
待设置完工程项目的数据后，就可设计工作分类的编码，通过在项目工程当中每个环节均设置好不同分类编码，便于今后日常工作期间快速查询项目，这对于项目整体，借助分类编码还可更好地管理项目。如图1所示，为该校区内的图书馆建筑项目分类编码明细。工程项目编码设计完毕后，需设置好该项目每个环节权限，借助不同的项目部门各项权限，来实现对该软件系统使用者进行有效管控。权限设置完毕后，需对该项目每个环节予以分类处理。该校区内的图书馆建筑项目，可分成以下子项目：施工图设计、房屋屋面于相关设施、土建、通风设备、配电、电梯、室内装修、空调等项目。通过对项目每个环节做分类处理，便能够为项目进度运算管理提供有利支持，在该P6项目管理系统软件程序中，专门有工程项目的计算分析功能模块，能够依据每个环节工序各项参数予以精准地计算分析，生产项目进度结果。整个计算分析进程当中，借助对项目重点工序的计算分析，获取到工程进度结果，工程进度能够依据具体情况实现自由浮动变化，如该校区内的图书馆建筑项目当中，因学校新生军训通常结束于10月份。故前期图书馆需正式开放，工程进度需结合该实际情况做出合理调整。
2.2.4划分各部门职责
软件项目计划书篇8
第一，在软件选择之前要选聘值得信赖的业内专家或专家组，帮助公司进行需求分析，以及设计对软件的评估体系。为了选好咨询专家，建议公司加强市场调研，向同类型企业收集咨询专家信息，以及评价意见，采取公开招标的形式确定咨询企业。第二，设计科学的软件评估体系。公司项目实施小组与咨询专家密切配合，对软件供应商进行全面的评估，建立一个科学规范的软件该评估体系。由企业内部组织精选出来的评估小组（由外聘信息化专家参加）进行评估。这样的评估小组对自己企业的需求很了解，在加上外聘信息化专家的帮助，会有很好效果。评估小组在听取软件供应商介绍和演示以后，可以进行充分讨论，在讨论的基础上进行评分。
三、数据风险应对计划
第一，扎实推进KKS编码工作。建议在设备采购阶段即严格采用KKS编码原则，与设计单位及设备厂家通过设计联络会的形式确定全厂数据编码规则，并按照唯一性、标准化、易用性的原则编写KKS编码技术规范书，对以下三个阶段的各类技术数据进行规范：（1）规划设计阶段：电厂的设计图纸等技术文档数据；（2）工程建设阶段：设备的采购、安装、工程的质量、进度、费用等数据信息；（3）经营管理阶段：产生和积累电及热能生产实时数据、设备维护、成本管理、技术管理等信息。第二，建立数据核查机制。信息化软件上线后，保持原有管理软件与其同步运行一段时间，期间由项目实施小组安排专人负责每周对信息化系统数据的准确性进行可靠性核查。对同步运行过程中出现的数据差异，要查明数据来源，分析差异产生原因，书面向公司高管进行汇报，由公司确定责任部门，限期进行整改。
软件项目计划书篇9
文献标识码：A
文章编号：1009-2374（2012）24-0118-03
1 概述
随着我国核电事业的蓬勃发展，在核电行业尤其是核电厂，无论是从设计、制造、运行到退役等各个阶段，还是从控制、测量、检查等各个环节，无不涉及到计算机软件的应用。作为我国核电行业生产管理和安全保证的重要手段和工具之一，核电工程应用软件正扮演着越来越重要的角色。
本文主要以软件工程化开发和软件工程化管理的思想和方法为依据，以我们研制的核电工程应用软件——核电厂系统化培训管理系统为例，介绍了核电工程应用软件的研制过程控制管理以及在此过程中要遵循的主要原则和规范，并对过程管理和研制特点做了简要分析总结。
2 项目概况
2.1 背景
核电厂各类人员的整体、综合素质和业务能力对达到电厂“安全、可靠、稳定、经济运行”的目标至关重要。为了保持人员的资格和工作能力、保证人员的培训质量和工作绩效，核电厂将在培训管理活动中，采用IAEA推荐的国际上普遍应用的SAT（Systematic Approach to Training）系统化培训方法对培训活动进行管理控制。
针对系统化培训活动中控制过程复杂、数据信息量大、用户接口繁多等特点，相关核电厂决定借助目前流行的计算机技术，遵循核电厂人员系统化培训方法的控制流程，开发一套“核电厂系统化培训管理系统（以下简称TMS-SAT系统）”来辅助核电厂的被培训人员、培训管理人员和电厂管理人员，系统地规范核电厂现有的培训活动，提高培训效果和效率，使核电厂各类人员能获得并保持完成所承担工作的资格和能力。
2.2 项目目标和范围
核电厂系统化培训管理系统属于核电工程软件类项目，目标是在将来核电厂内的培训工作中以TMS-SAT系统为载体推广SAT培训方法，全面推行系统化培训的理念和管理，不断完善核电厂的培训管理工作，该项目主要完成软件系统平台的开发，主要内容包括：岗位任务分析子系统开发，培训大纲管理子系统开发，培训教材管理子系统开发，培训记录管理子系统开发，评价反馈管理子系统开发以及考试题库管理子系统开发。
3 项目实施和过程管理实践
TMS-SAT项目的控制管理是按需求确定范围、按目标制定质量计划和开发计划、按计划执行管理的过程，对该项目软件系统开发各阶段加强控制管理的根本目的在于增强对软件开发的控制能力，提升软件开发的质量。TMS-SAT按以下6个阶段
进行：
3.1 项目的定义与分析
该项目的立项由用户单位根据自身业务的工作需要，对立项目的、业务需求范围、技术经济指标、开发周期要求等方面做简要概述，进行项目立项的可行性论证。单位在该阶段协助用户完成系统的定义与分析，协助用户编制《技术规格书》并交付用户审查，使用户能了解我们的研发能力和对此软件开发所需投入的人力、物力以及此项目最终达到的目标。
3.2 需求分析阶段
当第一阶段工作完成后，我们将制定适合本项目开发活动中的《质量计划》来控制软件开发周期内所有活动的工作条件、工作结果、评审要求等节点和各工作阶段的质量控制点要求；为了向用户描述有关此项目文档要求、人力资源、开发进度、审查要求、最终交付的产品等内容，编制此项目的《开发计划》和《测试计划》。
然后根据《技术规格书》的要求，进一步了解此项目的数据输入、输出、系统性能、环境以及最终将达到的目标等详细内容，形成本项目的《软件需求分析说明书》和《数据要求说明书》。
3.3 系统设计阶段
当软件需求分析阶段的审查通过后，根据《软件需求分析说明书》和《数据要求说明书》的要求，完成“应该如何解决这个问题”和“具体解决此问题应该采取的办法”这两项工作。根据此系统的总体概要设计，通过数据流图和数据字典的形势来表示系统的逻辑模型，形成《概要设计说明书》和《数据库设计说明书》。
3.4 系统开发
开发人员按照《详细设计说明书》和《软件开发规范》的要求，编写出正确的、容易理解和便于维护的程序模块。在每个子模块形成后，程序开发人员和软件测试人员对此子模块进行单元测试，形成《单元测试报告或记录》。在此阶段，还将根据《测试计划》和《详细设计说明书》的要求，编制此软件系统的《测试程序》，将所需测试的内容、步骤、结果、案例等描述出来供测试阶段使用。
3.5 系统测试阶段
该项目软件系统在开发人员完成所有软件模块编码后，测试人员及用户将根据《测试程序》进行软件系统测试。对测试中产生的软件不符合项，形成“软件问题报告单”，并最终形成《系统测试报告》。当软件交付给用户使用时，还将同时向用户提交《软件系统现场安装实施手册》、《用户手册》和《维护手册》等相关文档。
3.6 运行和维护阶段
项目正式交付给用户使用后，关键任务是通过各种必要的维护活动使软件系统能长久地满足用户的需要。为完成此任务，我们从改正性、适应性、完善性、预防性等几方面来进行维护活动中的工作。
4 项目控制管理的分析总结
4.1 项目开发管理质量化
该项目组通过编制《项目质量计划》、《项目开发计划》和《项目测试计划》等质量文件，对该项目进行全过程监督、控制，使各质量相关活动在受控状态下完成，确保项目中的各项质量要求得到了满足。
4.2 项目开发过程规范化
该项目的软件系统在依据软件工程化开发和软件工程化管理的理念和方法的基础上，通过严格执行有关软件开发管理和工作程序，规范软件研发过程，同时也更好地指导了培训大纲和基础理论教材的开发工作；项目所有过程文档资料及软件编码均采用统一的编码和编写格式。
4.3 项目开发控制进度化
依据软件工程化开发和软件工程化管理的理念和方法，科学地划分和制定核电工程应用软件的研制过程，同时各阶段也兼顾了培训大纲和基础理论教材的开发工作；采用三级进度管理体系，分级落实进度责任制。
4.4 项目开发监督岗位化
由于该项目软件系统的《需求分析说明书》往往是采用软件设计的术语编写，业务需求方难以理解，也就很难发现需求报告中与实际需求不符之处，更难提出建设性的意见。因此在该项目软件系统的研制开发过程中引入了软件监督岗位，由核电厂信息技术管理部门担任，协调业务需求部门和软件开发方的关系，监控软件开发任务的执行情况，给开发人员和管理层提供反映软件过程质量的信息和数据，提高项目透明度。
4.5 人员配备专业化
项目编制了各类人员的配置计划，如系统分析人员、系统设计人员、软件开发人员、测试和验证人员等，明确了具体的工作方式、内容和要求，并根据岗位要求进行必要的培训和再培训，以便使他们获得并保持必要的能力。
5 结语
实践证明由于该项目在软件系统方面依照软件工程化开发和软件工程化管理的理念和方法，严格按照我们单位提出的核电工程软件研制方法进行研制、设计和开发，加强软件研发的规范化管理，同时也更好地指导了培训大纲和基础理论教材的开发工作，从而保证了软件研发乃至整个项目的进度和质量，使得我们开发的产品可维护性好，特别是在出厂验收后大大减少了在现场测试和维护的人员投入，最终也得到了用户的认可。
参考文献
[1] 国际原子能机构．核电厂人员培训及其评价（技术报告丛书第380号2005版）[S]．
软件项目计划书篇10
一.小型软件开发项目中常犯的错误
小型软件开发项目一般具有项目需求相对较少、人员较少、开发周期较短的特点。因此，小型软件开发看起来都比较简单，比较容易成功，因而人们往往忽视了小型软件开发的管理，其实这是一种误解。例如，由于人员较少就分工不明确或由于开发周期较短就忽视项目计划和进度表的控制，结果是经常会出现开发流程混乱，重编码轻设计，甚至到编码完成后再回头编写各种文档资料等现象。从我这次的开发经验看来，在小型软件开发管理中最容易犯以下的错误：
(1)没有重视项目计划，做一天和尚撞一天钟
往往由于项目较小，便很草率地制定一个开发日程表，也没有认真地估计项目难度，结果是实际完成时间与估计完成时间往往有较大差别。还有人是这样说计划的："计划、计划，纸上画画，墙上挂挂，计划不如变化"。因此，由于观念的不正确使到计划管理经常成为空话，特别是在小型软件开发中影响计划的因素太多时或加上想省事怕麻烦，结果计划管理就形同虚设了。
但是，软件进行项目管理的目的就是综合各种因素，制定合理的计划，并通过计划的实施，使其规范化，从而提高人员效率，降低项目成本。因此，软件开发无论项目大小，其实都需要计划过程。只是对于小型软件项目来说，计划阶段可能切换的很快。例如，有时候项目负责人只是脑海里想一遍就把计划确定了。但项目负责人必须心里要清楚：有时候想省事儿，可能反而会更加费事儿。俗语有云：一年之计在于春、一日之计在于晨。其意义不是说越早做越好，而是阐述一个目标的实现需要尽早做规划。
(2)没有完整的开发文档，无意之中增大项目风险
一个完整的软件开发项目应包括有相当多的相关文档：例如项目开发计划、软件需求说明书、概要设计说明书、详细设计说明书、开发进度月报、测试计划和开发总结报告等。而在实际中，许多小型软件项目只有简单的流水帐式的开发日志。最常见的借口往往是以文档滞后来解释文档的不健全，这似乎没有什么不妥，而且好象还理直气壮的。但如果将软件项目叫做"工程"的话，再将其与建筑工程相比较，那我们也就可以说：大楼有了，图纸滞后，这是很可笑的。还有许多开发人员认为软件设计已经在其脑子里完成了，在其意识里工作就只是一堆需要敲出来的程序，既然能直接敲得出来，自然没必要再做写文档的重复工作。
这样做的结果使到设计思路和实现细节在项目团队内的交流很困难，开发过程会由于需要大量尝试性、重复性工作而变得缓慢，而且会出现许多意想不到的大大小小的问题，狼烟四起之时最重要的工作就变成了"救火"。所以，在小型软件项目里会"救火"的技术人员会成为大家推崇和依赖的英雄。但这种"救火"式的行为最终结果却是项目延期成了普遍现象，产品质量也得不到保证。另外，如果这个英雄半途离开，那没有任何文档支持的中间结果对其它人来说基本上就是"一堆垃圾"而已，项目被迫中断就成了家常便饭。
(3)人员没有技术分层，职责不清分工不明
许多小型软件开发项目一直采用个人主义式的开发方式，决定了规范化开发方式的不被认可。对规范化管理的淡漠，抑制了团队工作效率的提高，甚至扼杀了其生命。所以，小型软件项目往往要求主要的项目人员从各个方面都得是非常出色的，不仅要全面地掌握系统架构知识、具有业务分析和系统设计能力，而且还得是多种流行开发工具的专家、数据库的专家、网络配置的专家等，但这样的全才和通才往往是可遇不可求的。
因此，小型软件项目更需要做技术分层，例如系统分析员、需求分析师、程序员、测试员等。在项目开发中相应的角色必须要有相应的专业人员来担当，当然可依据项目规模大小和现有人员来合理配置。这里强调技术结构分层和技术人员划分，更多的是技术责任的明细，而非具体个人的技术定位，将技术任务和相应的责任划分到具体的岗位、将岗位落实到具体的人，这与具体技术人员身兼数职是不矛盾的。
而我们经常看到的是在许多小型软件开发过程中，人员职责不清、分工不明的现象非常严重。有的甚至从调研到分析、设计，到开发、调试，再到测试一气呵成。先不说工作量有多大，仅从项目的风险来说就是非常可怕的，更不用说最大限度发挥开发人员的长处了。
二.小型软件实行项目管理的方法和步骤
为什么小型软件开发项目却会面临更多的失败风险呢?在我所负责的项目面临下马前的每一个夜晚，我的脑袋里一直在思考这个问题。也许是多日思考的沉淀，也许是思绪在不停的四处游荡后的突发灵感。使我明白到原来决定小型软件项目成败的核心因素，是有没有坚持进行实行项目管理。现总结为以下几个要点：
(1)树立小型软件开发也需要项目管理的理念
但凡专业的软件开发人员都学过《软件工程》这门课，纵观这些指导性的理论以及建议。我们应该要树立即使是小型软件开发也应该在一定程度不要违背开发理论，必须要遵从于工程化软件理论的原则和方法，落实规范化的管理。否则，失败的风险将伴随着整个开发过程，而且越到后期失败的可能性会越大。
对小型软件项目而言，最急需的不是设计方法，也非分析方法，当然也不是开发方法，而是管理方法。因此，无论项目大小都必须要遵循一定的项目管理步骤。
从概念上讲，软件项目管理是为了使软件开发能够按照预定的成本、进度、质量顺利完成，而对成本、人员、进度、质量、风险等进行分析和管理的活动。实际上，软件项目管理的意义不仅仅如此，进行软件项目管理还有利于将"英雄"式的开发人员的个人开发能力转化成团队的开发能力，团队的软件开发能力越高，就越能减小项目的开发风险。
(2)项目需求的确认
在软件开发中，最重要的活动是要明确项目的范围、需求和提出至少一个可用的软件架构方案。在明确项目范围的过程中，不能认为是小型软件开发项目就马马虎虎的、想当然的认为已经了解了客户的真实需求。项目经理应要就项目的边界、功能、限制条件等与客户进行协商，并应以需求说明书和功能说明书的形式把客户的需求记录下来，并且和客户达成一致的认识和理解。在此基础上，再提供至少一个合适的软件架构方案，并且完成原型系统。原型系统的目的不但是为了验证技术上的可行性，而且是为了给客户一个感性的认识，更好地完善对需求的理解和确认。
(3)人员角色的安排和定义
角色定义包括个人或团队的行为和职责，包括设计人员、编程人员、测试人员、项目管理人员和辅助人员。比较小的项目往往是几个人来完成，这几个人基本上从头到尾参加开发。而且由于项目小，项目负责人除了负责分析、设计和协调的工作外，也要参加编程。但在此过程中必须要合理进行人员角色的安排和定义，将技术任务和相应的责任划分到具体的岗位，再将岗位责任落实到具体的人身上，避免推卸责任或由不专业的人马虎应付了事。例如，一个人可以同时担当几个角色，一个角色也可以由几个人来共同承担，但前提都是要有责任的、有专业技能的。
(4)建立合理的开发流程，注重过程的衔接
一句话形容就是"麻雀虽小，五脏俱全"。也就是说即使是小型软件的开发，仍然应该遵循软件开发的一般规律，必须的步骤和合理的开发流程还是不能省略。不但要建立合理的开发流程，而且还要注重分析与设计过程的衔接。当然，小软件项目也有它自身的一些特点，实行起来可以相对灵活些。
例如：①要强调协调几个人的工作比某一开发人员完成一段编码更重要。因为在协调上出了漏洞，就可能导致很大的问题。②是给每个开发人员要有明确的任务书，也就是说每个开发人员必须非常明确自己的任务，而且这些任务是采用文档来表示。③是要让每个开发人员都清楚自己所做的工作在整个系统中处于什么地位，避免各人的代码编写完毕之后又要重复修改。
(5)重视文档化过程
在小型软件项目中有两个特点：①是由于人员少，意味着不同人员的程序之间交互、接口相对少一些;②是由于人员少，往往是同样的几个人从头到尾负责这个项目。但这两个特点会让人容易犯错误，就是往往是几个人碰一下头，讨论一下最基本的任务分工便分头去做自己的工作了，没有一份较正式的开发文档。当有人对任务理解有偏差时或有误解时，就可能会造成返工。因此，小型软件开发项目也不应该忽视文档化过程的作用。
文档化有三方面的作用：①是有助于团队沟通，能给别人一个交待以及给自己一个备忘。②是有助于自我理解，一般来说如果你不能写下它，你就可能没有真正的理解它。③是有助于连贯一致性，它会使团队拥有可重复的优势。虽然文档是如此重要，但在小型项目中有用的文档最好也不要太冗长繁杂，一般1-2页的过程说明就足够了。
(6)使用好制度与纪律这个工具
软件项目计划书篇11
明确需求后，由系统分析师和软件设计师严格按照《需求分析说明书》为用户设计总体方案，该方案是面向用户的，内容尽量少地涉及技术层面内容，主要侧重功能描述。包括该软件有多少功能模块，具体功能描述，辅助手段说明，最终达到的使用效果，以及对一些用户关心的特性（如安全性、可靠性等）方面的描述，同时，为客户提供一些硬件设备选择方案。该阶段形成的书面材料：《项目总体方案》。
系统分析师和软件设计师根据《项目总体方案》，做系统规划和概要设计。从该步骤开始，以下的各步都将面向开发人员，形成的文字材料均以专业术语和列表等形式展现，尽量少用或不用描述性语言，力求言简意赅地表达。该阶段按软件模块提取功能点，不同模块间有交叉或相似内容的进行合并，并详细说明每个模块下包含的具体功能点，如增加、删除、修改、检索、分类、排序等，即对功能模块进行细化。形成的书面材料：《概要设计说明书》。
在概要设计基础上，系统分析师和软件设计师进行详细设计。该阶段将搭建软件系统的整体框架，框架搭建一般有两种方式：一种从技术角度，按功能点搭建；另一种按内容，即按模块来组织。其中第二种用的居多，即按内容分成若干模块，在每个模块下，确定需要开发的功能函数（在面向对象的设计方法中我们称其为方法），把这些函数或方法要实现的功能都确定下来，并设计数据库的结构，包括有多少表，每个表有哪些字段，主键，外键，字段长度，是否需要索引，表与表间是否有关联，是否需要建立触发器等内容。形成的书面材料：《功能设计说明书》、《数据库设计说明书》。
软件项目计划书篇12
1 引言
近年来，随着中国国防技术的发展，国家启动了一系列国防重大专项任务，计算机软件在各项任务中起着关键性作用，往往作为整个系统的中枢神经。任务中计算机软件一旦崩溃，就可能会导致整个任务失败，从而引起严重的后果。
为提高我国军用软件质量，总装备部吸收国外CMM经验，组织国内专家对其研究并结合我国国情于2003年了GJB5000体系标准文件。中国科学院国际天文台在国家重大专项任务探月工程中承担地面应用系统建设任务，软件作为一项重要建设内容，其质量保证工作不可忽视。因此，在软件改进过程中遵循了总装备部的 GJB5000A-2008《军用软件研制能力成熟度模型》二级实践。该模型严格定义了过程与产品质量保证（PPQA）关键过程，站在软件的角度，就是软件质量保证（SQA）过程。在GJB5000A-2008二级实践中，SQA是一个关键过程域，它贯穿在整个软件生命周期中，在软件质量保证上起着举足轻重的作用，同时也是最难实现的一个过程域。SQA通过有计划地实施SQA活动来控制软件过程的质量，并通过控制关键过程的质量保证软件产品的质量。
2 GJB5000A二级关键过程域SQA概述
GJB5000A-2008定义软件质量保证是建立一套有计划、有系统的方法，向管理层保证拟定出的标准、步骤、实践和方法能够正确地被项目采用。软件质量保证人员在项目开始时就参与建立计划、标准和过程。质量保证基本目标是：1.软件质量保证工作是有计划进行的；2.客观的验证软件项目产品和工作是否遵循恰当的标准、步骤和需求；3.将软件质量保证工作及结果通知给项目相关组别和个人；4.高级管理者应接触到项目内部不能解决的问题。
GJB5000A-2008二级实践中，过程和产品质量保证活动的流程图如图1所示，
3 SQA在探月工程地面应用系统软件过程改进中的实践
在探月工程地面应用系统软件改进过程改进中，开展的实践活动如下：
3.1 明确项目相关成员以及职责
项目相关成员包括：SQA人员、配置管理员、部门负责人，软件项目负责人，软件开发组，软件测试组；SQA人员负责项目的软件质量保证活动。
3.2 SQA人员参与制定项目计划、标准和规程
SQA人员帮助策划项目的规模、进度、成本和工作量的估计等，参与项目的开发计划、标准和规程的准备，使得验证计划、标准和规程在项目开始时已到位并可用于评审和审计软件项目。主要的标准和规程包括软件项目计划过程规程、质量保证过程规程、需求过程规程、软件跟踪与监督规程、软件配置管理规程、软件测试规程、软件编码标准和文档编写标准等。
3.3 制定和维护SQA工作计划
SQA人员根据项目开发计划制定SQA工作计划，主要描述SQA的目的、范围及SQA计划与其他项目计划之间的关系，内容包括：组织和职责、资源需求、项目各阶段的工作内容、工作方式、评审工作过程和工作产品。SQA工作计划制定后，由部门负责人、软件项目负责人、SQA人员、项目组内其他受影响的小组和个人参加计划的评审。同时在项目进行过程中，根据项目的变化变更与维护质量保证计划。
3.4 软件过程活动评审
SQA人员根据工作计划进行工程过程评审，评审采用正式会议或者非正式会议形式，评审专家依据SQA人员事先制定的检查单进行评审，如果评审发现偏差，评审后SQA人员要对偏差进行跟踪直至问题关闭。从软件需求阶段开始到系统测试为止，软件质量保证过程域软件开发过程是同步的，并在周期例会、评审会上适时地报告当前开发过程的状态，使得软件开发过程可视透明。图2为SQA过程审核活动与软件开发过程的对应关系：
3.5 软件工程产品审计
SQA人员根据工作计划进行工作产品评审，评审采用正式会议或者非正式会议形式，评审专家依据SQA人员事先制定的检查单进行评审，如果评审发现偏差，评审后SQA人员要对偏差进行跟踪直至问题关闭。在一个软件项目的生命周期中，SQA主要审计的工程产品有：软件任务书、软件需求规格说明书、软件概要设计说明书、软件接口设计说明书、软件详细设计说明书、程序源码、软件测试计划、软件测试说明、软件测试报告、软件使用说明以及各类管理报告等。
3.6 配置管理审计
SQA人员定期审计配置管理活动，对照软件配置管理计划检查配置管理员的工作是否符合配置管理计划，软件配置项的变更是否遵循了配置项的变更控制流程。检查配置管理员是否定期报告基线状态，是否定期对配置库进行备份。
3.7 偏差记录与跟踪
在项目质量审核与审计过程中发现的偏差要记录到偏差报告中。发现偏差后要及时有效的与软件负责人沟通，由软件负责人落实偏差的处理负责人以及处理期限，由SQA人员负责进行跟踪，直至问题关闭。同时，SQA人员还应该分析是否存在共性问题，做到防患于未然，提早预防。如果发现的偏差软件负责人无法解决，或者软件负责人和SQA人员对偏差问题无法达成一致意见，SQA人员向部分负责人汇报，由部门负责人决策。
3.8 向部门负责人直接汇报
SQA人员直接对部门负责人负责，具有向部门负责人直接汇报的渠道，定期向部门负责人汇报SQA工作情况，帮助部门负责人了解项目进展以及项目中存在的问题。如果软件负责人和SQA人员对偏差问题无法达成一致意见，或者项目组出现无法解决的问题时，SQA及时向部门负责人汇报并寻求解决途径。
4 SQA活动实践经验总结
在探月工程地面应用系统软件过程改进过程中，总结SQA活动的过程，得到一些经验和教训：
4.1 需要管理者高度重视
首先，管理者决不能认为SQA可有可无，不能狭隘的认为设置SQA只是为了CMM或者GJB-5000A评估的需要；其次，在项目进展过程中，管理者与SQA相关的工作非常多，要积极参加SQA组织的评审、定期听取SQA工作汇报、解决项目组与SQA人员的分歧、对SQA人员工作进行评审与检查。因此，管理者要积极支持SQA人员的工作。
4.2 检查单与项目结合，避免空谈
SQA所有活动均依据检查单进行的，检查单是软件质量保证计划的一项重要内容，也需要经过评审，所以SQA人员要根据不同项目情况适当地裁剪过程和工作产品的检查单内容。只有使用适应于项目的检查单，才能做到检查的有效性，否则就是空谈。
4.3 SQA人员要求专业而且专职
SQA人员要求具有非常丰富的项目开发和管理经验，只有这样才能发现问题与偏差，减少后期无用的返工，以利于项目组保证项目进度和产品质量。同时，必须要求SQA人员是由非项目组成员担任，以保证评价的客观性。SQA人员需要有充分的时间与精力去检查与评价产品与过程，要求SQA人员尽量做到专职，而不是身兼几个职位。
4.4 项目成员配合
在项目中，SQA人员与项目组人员的立场不同，往往是对项目组成员的工作情况实行监督与检查，所以项目组的成员对SQA人员往往不理解、不支持，甚至部分成员会抵制SQA人员工作展开。项目组应该加强SQA活动知识的培训，使项目组成员认识到SQA审计的是过程和产品，而不是针对某个人审计。其中，软件负责人的支持与配合，对SQA工作的展开起着至关重要的作用。
4.5 需要对SQA进行同行评审，确保SQA活动有效性
SQA人员本身也需要被监督，才能保证他的公正性和客观性。管理者、独立SQA专家、软件负责人定期评价SQA活动，并向SQA人员开放评审结果，对SQA活动的不符合问题同样进行跟踪直至关闭，确保SQA活动的有效性。
5 结束语
在软件工程中，SQA活动是保证软件项目质量的关键因素，SQA活动的有效性很大程度上决定了软件项目质量。每一位项目管理者应高度重视SQA工作，并给予充足的人力与物力资源。只有SQA通过积极而客观的检查、评价、独立而有效的多向沟通，有效行使监督指导职责，积极贯彻软件工程化、过程改进理念，增加主动的预防手段，才能有效地促进项目成功。
参考文献
[1]马丽飞.浅谈SQA在GJB5000A二级实施过程中的作用.中国电子科技集团公司第二十七研究所[J].电子质量，2014.
[2]王杨玲等.航天型号软件过程改进实践，北京宇航系统工程研究所[J].航天标准化，2011.
[3]石柱.军用软件能力成熟度模型可重复级实施指南[M].北京：中国标准出版社，2006.
[4]刘彦涛，马闰娟.CMM二级SQA关键过程域与软件过程改进，华东计算机技术研究所[J].计算机工程，2007.
[5]王精明.浅谈在CMM2中如何实现SQA[J].滁州学院学报，2006.
[6]王勇等.CMM质量保证的理论与实践[J].计算机工程与设计，2005.
软件项目计划书篇13
Abstract： The design and development of software quality evaluation management system which used in instrument and control （I&C） system of nuclear power plant is based on the GB/T 18905-2002 and open-source code. User can customize and select proper set of evaluation standard according to the different quality objectives to evaluate and quantify the quality of I&C system software in nuclear power plant objectively.
Key words： I&C software of nuclear power plant； software quality evaluation
件产品在工控领域内的地位变得越来越重要，作为核电厂控制核心的集散控制系统（Distributed Control System，以下简称DCS）更是发挥着十分重要的作用。特别是在核电厂DCS国产化进程中，DCS软件产品的研制普遍存在任务重、质量要求和可靠性要求高的特点。如何对自主研发的核电厂仪控系统软件的质量进行高效、客观的评价也变得十分迫切。随着核电厂仪控系统软件产品日趋复杂和庞大，相应的软件产品质量评价工作包含着更多的数据信息，如果仅靠手工或word、excel工具来管理这些数据，工作量巨大而且容易出现错误，数据信息不能及时得到更新，导致评价过程难以执行和评价效率低下。
作者以GB/T 18905-2002 软件工程 产品评价系列标准的思想为依托设计出一种对软件质量的评价过程进行管理的系统，具体业务流程完全符合GB/T 18905-2002中对软件质量评价过程的定义。
作者基于开源代码开发出的该评价管理系统，采用B/S架构，客户端（通过浏览器）和服务器建立TCP连接，主要负责软件质量评价流程业务处理；服务器端（Web服务器）使用Apache+PHP+MySQL配置，服务器端对客户端发出的请求按照HTTP协议进行解码，主要负责项目数据处理，包括数据库操作、数据统计、软件质量评价过程文档生成等。
由于核电厂仪控系统软件的特殊性，不同安全级别的软件必须符合国家、国际标准规定。尤其是其安全性和可靠性必须严格遵照IEC 60880-2006、IEC 62138-2004、IEC 61513-2011和NUREG/CR 6101-1993中的要求，该评价管理系统提供符合核电厂仪控系统软件评价标准的软件质量模型库，同时具备良好的可扩展性，用户可以根据不同软件质量目的进行自定义和裁剪。
1 软件的主要功能
该系统的主要功能如下：
根据GB/T 18905-2002建立一个软件质量评价流程体系，支持软件质量和软件过程的持续改进
提供核电厂仪控软件专属的质量属性和度量标准（即质量模型），帮助评价者根据不同的项目进行裁剪：
1） 基于GB/T 16260-2006提供软件的内部质量度量、外部质量度量、使用质量度量模型库；
2） 基于IEC 62645-2014、IEC 6244-2013 提供核电厂仪控系统软件信息安全相关的质量度量模型库；
3） 基于GB/T 7826-2012、GB/T 2817-2011提供核电厂仪控软件可靠性相关的质量度量模型库；
对所收集的数据进行分析统计，帮助用户有效地了解软件质量评价结果，分析软件开发中发现的问题和风险；
提供报表生成功能，生成评价需求规格说明书、评价计划、评价报告等过程文档。
2 软件用户设置
在系统中，每个用户都可以维护自己的私有信息。admin可以创建用户，但不能看到其它用户的密码。
该系统提供了六种角色，分别是V&V engineer、guest、V&V designer 、senior V&V engineer、V&V leader、admin。相对应的功能权限可以通过角色管理进行自定义。
3 软件操作流程
3.1创建软件评价项目
通过主页左边的列表栏的【评价项目管理】菜单，进入创建页面中有【创建】按钮创建新的待评价的软件项目，本系统可以对多项目进行管理，而且各个项目之间是独立的，不能分享数据，但只有admin级的用户可以设置项目。Admin进行项目设置后，V&V人员就可以进行项目评价需求、项目评价规定、评价计划以及评价执行等相关工作。
3.2创建评价需求
评价需求规格说明书应该由GB/T 16260-2006中定义的称为【质量特性】的一系列质量需求点组成。
评价需求规格说明书是开展评价工作的依据。首先，对软件的需求规格书进行分析和整理，将其拆分为多个评价需求点。
创建评价需求规格说明书
建评价需求点
3.2.1创建评价需求规格说明书
主页左边的列表栏中有 【评价需求管理】的菜单，子菜单中有【评价需求规格说明书】，可以添加编辑评价需求规格说明书。
3.2.2创建评价需求点
选择需要编辑的评价需求规格说明书，选择该页面上的【创建评价需求点】按钮新建评价需求点。
评价需求点内容包含：需求点的标识、名称、概述、需求的状态，需求的类型，以及对应的评价方法数。
该管理系统提供了两种状态来管理评价需求点：有效的、不可评价的。
另外，管理系统提供了从文件导入需求点的功能，支持的文件类型有csv和xml、DocBook三种。同时系统也提供了将需求导出的功能，支持的文件类型有xml一种。 管理系统还提供上传文件的功能，可以在创建评价需求点的时候，为该需求点附上相关的文档。
3.3评价规定
评价规定的目的是定义评价的范围和定义对供评价的产品及各种部件执行的测量，按照评价需求进行评价设计。评价规定宜详细到在它的基础上能确保评价的可重复性和可再现性。规定评价的活动主要有：
质量模型的导入和裁剪；
评价方法的设计；
3.3.1质量模型的导入和裁剪
选择主页横向导航栏中的【评价质量模型裁剪/评价设计】出现评价质量模型操作界面，选择【导入评价质量模型】 将本管理系统适用的评价质量模型导入待评价的项目中。选择评价的质量模型文件（.xml格式）进行上传。
3.3.2评价方法设计
选择【评价方法设计】，进入评价方法设计页面进行设计。评价方法设计的要素包括：方法设计、期望结果。
3.4评价计划
在本管理系统系统中，评价者应制定一个评价计划来描述执行指定评价时所需要的资源和执行各种动作时对这些资源的分配，一个完整的评价计划包括：
创建评价计划
评价版本管理
指派评价计划角色
添加/删除评价标准到评价计划
分配执行评价任务
3.4.1创建评价计划
选中主页右上【评价计划管理】模块下的【评价计划管理】菜单。通过【增加】按钮，进入评价计划创建页面。评价计划的内容包括：计划名称，计划描述，以及是否从已有的评价计划创建，如果选择从已有的评价计划中创建，则新创建的评价计划包含选择的已有评价计划的所有相关联的信息，比如已有评价计划分配的评价方法。
3.4.2评价版本管理
选中主页右上方【评价计划管理】模块下的【评价版本管理】菜单，创建一个新的评价版本。评价版本的内容包括：输入版本的标识，版本的说明。
3.4.3指派评价计划角色
选择主页【评价计划管理】模块下的【分配评价计划角色】菜单，为评价计划指派用户。
在分配评价计划角色页面，可以将该评价计划以不同的角色分配给不同的用户，通过角色列表，可以选择用户对该评价计划的操作角色。
3.4.4添加/删除评价标准到评价计划
在主页通过评价计划下拉列表，先选择一个评价计划，选择【评价计划管理】下的【添加评价标准到评价计划】按钮，进入向评价计划中筛选评价标准的界面。
将已经导入好的评价标准加入到该评价计划。选择一个评价标准集，可以看到该评价标准及下的所有评价标准。
选择该评价计划中要执行的评价标准，根据版本下拉列表来选择该评价计划下需要执行的评价标准的版本。选择好后，选择【增加选择的评价标准】按钮，可以将选择好的评价标准分配给该评价计划。选择【添加/删除选择的评价标准】按钮，可以将选择好的评价标准移除该评价计划。
3.4.5分配执行评价任务
选择主页【评价计划管理】模块下的【分配执行评价任务】菜单，进入分配执行评价任务页面，可以为当前评价计划中所包含的每个评价标准指定一个具体的执行人员。
3.5执行评价
执行评价的目的是根据评价需求，按照评价规定中的评价规定和评价计划中的计划，对软件产品的测量和验证中获得结果。
选择主页横向导航栏中的【执行评价】进入执行页面。
执行完评价方法后，在【说明/描述】输入框中输入在执行评价过程中的一些说明性情况，在【结果】栏选择评价执行的结果。
其中评价结果分四种情况：
未执行：该评价标准没有执行
通过：该评价标准通过
失败：该评价标准没有执行成功
中断：由于其他评价标准失败，导致该评价标准无法执行，被中断。
3.6评价结果分析
本管理系统根据评价过程中记录的数据，提供了多种度量统计功能，可以直观的得到评价管理过程中需要进行分析和总结的数据。选择主页横向导航栏中的【评价报告和度量】或者评价执行模块中的【评价报告和度量】，即可进入评价结果报告页面。
4 结论
本系统可以指导评价者更加高效地进行软件质量评价。它可以保证过程数据得以及时和准确地收集，通过软件的监督使整个评价过程符合标准，并得以实施和贯彻，为持续改进核电厂仪控系统软件质量和软件过程改进提供基础。旨在为评价过程提供系统化的指导，减少评价过程的成本和时间，提高对整个软件产品评价管理过程的可控性。
