M.3资额耗用与状态
M.3.1 资额耗用
主要说明本月份内耗用的工时与机时。
M.3.1.1工时
分为三类:
a.管理用工时包括在项目管理(制订计划、布置工作、收集数据、检查汇报工作等)方面耗用的 工时;
b.服务工时包括为支持项目开发所必须的服务工作及非直接的开发工作所耗用的工时; C.开发用工时要分各个开发阶段填写。
M.3.1.2机时
说明本月内耗用的机时,以小时为单位,说明计算机系统的型号。
M.3.2状态
说明本月内实际耗用的资源与计划相比,是超出了、相一致、还是不到计划数?如果与计划不一致,说明原因及准备采取的措施。
M.4经费支出与状态
M.4.1经费支出
M.4.1.1支持性费用
列出本月内支出的支持性费用,一般可按如下七类列出,并给出本月支持费用的总和:
a. 房租或房屋折旧费;
b.社工资、奖金、补贴;
c.培训费包括给教师的酬金及教室租金;
d.资料费包括复印及购买参考资料的费用;
e.会议费召集有关业务会议的费用;
f.旅差费;
g.其他费用。
M.4.1.2设备购置费
列出本月内支出的设备购置费,一般可分如下三类:
a.购买软件的名称与金额;
b.购买硬设备的名称、型号、数量及金额;
c.已有硬设备的折旧费。
M.4.2状态
说明本月内实际支出的经费与计划相比较,是超过了。相符合、还是不到计划数?如果与计划不一致,说明原因及准备采取的措施。
M.5下个月的工作计划
M.6建议
本月遇到的重要问题和应引起重视的问题以及因此产生的建议。
附录N
项目开发总结报告的编写提示
N.I引言
N.1.1编写目的
说明编写这份项目开发总结报告的目的,指出预期的阅读范围。
N.1.2背景
说明:
a.本项目的名称和所开发出来的软件系统的名称;
b.此软件的任务提出者、开发者、用户及安装此软件的计算中心。
N.I.3定义
列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
N.1.4参考资料
列出要用到的参考资料,如:
a.本项目的已核准的计划任务书或合同、上级机关的批文;
b.属于本项目的其他已发表的文件;
c.本文件中各处所引用的文件、资料,包括所要用到的软件开发标准。 列出这些文件的标题、文件编号、发表日期和出版单位,说明能够得到这些文件资料的来源。
N.2实际开发结果
N.2.1产品
说明最终制成的产品,包括:
a.程序系统中各个程序的名字,它们之间的层次关系,以千字节为单位的各个程序的程序量、存储媒体的形式和数量;
b.程序系统共有哪几个版本,各自的版本号及它们之间的区别;
c.每个文件的名称;
d.所建立的每个数据库。 如果开发中制订过配置管理计划,要同这个计划相比较。
N.2.2主要功能和性能
逐项列出本软件产品所实际具有的主要功能和性能,对照可行性研究报告、项目开发计划、功能需 .求说明书的有关内容,说明原定的开发目标是达到了、未完全达到、或超过了。
N.2.3基本流程
用图给出本程序系统的实际的基本的处理流程。
N.2.4进度
列出原定计划进度与实际进度的对比,明确说明,实际进度是提前了、还是延迟了,分析主要原因。
N.2.5费用
列出原定计划费用与实际支出费用的对比,包括:
a.工时,以人月为单位,并按不同级别统计;
b.计算机的使用时间,区别CPU时间及其他设备时间;
c.物料消耗、出差费等其他支出。
明确说明,经费是超出了、还是节余了,分析其主要原因。
N.3开发工作评价
N.3.1对生产效率的评价
给出实际生产效率,包括:
a.程序的平均生产效率,即每人月生产的行数;
b.文件的平均生产效率,即每人月生产的千字数;
并列出原订计划数作为对比。
N.3.2对产品质量的评价
说明在测试中检查出来的程序编制中的错误发生率,即每干条指令(或语句)中的错误指令数(或语句数)。如果开发中制订过质量保证计划或配置管理计划,要同这些计划相比较。
N.3.3对技术方法的评价
给出对在开发中所使用的技术、方法、工具、手段的评价。
N.3.4出错原因的分析
给出对于开发中出现的错误的原因分析。
N.4经验与教训
列出从这项开发工作中所得到的最主要的经验与教训及对今后的项目开发工作的建议。
附录O
文件给制实施规定的实例
尽管在文件编制中存在着很多灵活性,然而,文件的编制确实是非常必要的,其意义如前所述。为了控制这种灵活性,保证文件编制能达到应该达到的目的,对于具体的软件开发任务,应编制的文件的种类、详细程度应取决于承担开发单位的管理能力、任务的规模、复杂性和成败风险等因素。一个软件开发单位应该根据本单位经营承包的应用软件的专业特点和本单位的管理能力,制定一个文件编制实施规定,说明在什么情况下应该编制哪些文件。由于国内目前在这方面还缺乏成熟的经验,这里提供参考国外经验制定的两个例子,用以向国内软件开发单位说明如何建立这种实施规定,使项目负责人能确定本项目开发过程中应编制的文件的种类。当然,例子毕竟只是例子,这两个例子各自都不免有其片面性,它们两者之间也不免有不一致之处,之所以列出来无非是供国内软件开发单位参考。
例1:
此例规定用求和法来确定应编制的文件。该方法的要点是提出十二个考虑因素来衡量一个应用软,件,每个因素可能取值的范围是互至5。任务负责人可用这十二个因素对所要开发的程序进行衡量,确定每个因素的具体值。把这十二个因素的值相加,得到一个总和。然后由这个总和的值来确定应该编制的文件的种类。使用这个方法的具体过程如下:
a. 按表OI中的十二个因素衡量所要开发的程序,得到每个因素的值;
b.把衡量所得的各个因素的值相加,得总和之值;
c. 根据总和之值,从表OZ查出应编制的文件的种类。
表OI文件编制的十二项衡量因素
*在因素总和较低的情况下,项目开发总结报告的内容应包括:程序的主要功能、基本流程、测试结果和使用说明。
**测试分析报告应该写,但不必很正规。
* **数据要求说明和数据库设计说明是否需要编写应根据所开发软件的实际需要来决定。
例2:
为了避免在软件开发中文件编制的不足或过分,一个简便的办法是把对软件文件的编制要求同软件的规模大小联系起来,这就是本例的出发点。软件的规模不妨分为四级:
1.小规模软件源程序行数小于5 000的软件;
2.中规模软件源程序行数为 10 000~ 50 000的软件;
3.大规模软件源程序行数为 100 000—500 000的软件;
4.特大规模软件源程序行数大于500 000的软件。
对上述的四级软件的文件编制要求分别列于表O3。
至于源程序行数为 5 000~ 10 000, 50 000~ 100 000的软件,其文件编制要求介于两级之间,可根据一个软件产品的具体情况,由项目负责人参照表O3的规定,确定需要编制的文件种类。
对于源程序行数大于500 000的特大规模软件,可进一步把本指南规定的十四种文件按实际需要扩展成更多种类,这一点在本指南5.3.3已经提到。
各省软考办 | ||||||||||