案例-某公司软件过程规范示例
软件过程规范模板

软件过程规范模板1. 总则最大限度提高Q&P (质量与生产率),提高Q&P的可预见性,是每一个软件开发机构的最大目标。
而Q&P 依赖于三个因素:过程、人和技术,因此要实现Q&P 的提高,除了加强技术能力,引进、培育更多优质技术人才之外,规范、改进机构的过程是一个十分重要的手段。
我们希望通过在制定软件过程规范标准,并在软件开发实践中不断地完善、修订,提高Q&P 和Q&P 的可预见性。
本规范采用CMM (软件过程成熟度模型)的指导,吸收RUP、XP、MSF、PSP、TSP等过程规范指南的思想、方法及实践,充分结合xxx技术开发部的实际情况,引入先进的技术、方法、工具,为公司的软件开发工作提供一部详细、可操作的过程指南。
在本规范的第一版本中,主要包括管理过程和开发过程两个部分,管理过程中包括项目管理过程、需求变更管理过程、配置管理过程。
对于软件开发项目中的其它的一些过程将在实践中逐步补充、完善。
2. 项目管理过程规范项目管理过程主要包括三个阶段:项目立项与计划、项目实施、项目关闭。
2.1 项目立项与计划参与人员:技术开发部指定的项目负责人(包括前期负责人、正式的项目经理)、立项申请人、[相关最终客户]以及实施该项目的开发组队成员;入口准则:接到经公司总经理或副总经理批准的市场部门的《软件开发立项申请表》;出口准则:立项申请人签字确认了经修订正后的正式《软件项目计划》,并通过《工作任务卡》下达了开发任务,开发工作正式开始;输入:经审批的《软件开发立项申请表》、与需求相关的业务资料;输出:《软件项目计划》、《软件需求规格说明书》、《开发任务卡》;活动:1. 接到《软件开发立项申请表》后,技术开发部经理指定前期负责人,并告知立项申请人;2. 前期负责人阅读《软件开发立项申请表》后,通过与立项申请人的沟通、阅读立项申请人提交的材料、通过立项申请人与客户直接交流等方式,了解项目目标、范围与基本需求;并形成最初的《软件需求规格说明书》;3. 前期负责人会同技术开发部经理以及其它相关人员,制定最初的《软件项目计划》,并组织评审;4. 向立项申请人提交最初的《软件项目计划》;5. 最初的《软件项目计划》通过立项申请人的确认后,项目经理计划安排需求分析;6. 需求分析完成后,形成正式的《软件需求说明书》,提交立项申请人确认;(需求分析过程参见开发过程规范部分)7. 根据立项申请人确认后的《软件需求说明书》,项目经理组织进行软件高层设计,并对工作任务进行分解,并根据实际需要向技术开发部经理申请资源,组建项目组队;8. 项目经理根据工作任务分解,下发《工作任务卡》,并协同组队成员进行任务估算;注:工作任务包括模块开发任务、其它任务(如安装);模块开发任务主要包括:详细设计、编码和单元测试9. 任务估算完成后,组队成员向项目经理提交《个人进度安排》(以甘特图的形式表示),项目经理根据每个组队成员的《个人进度安排》修订《软件项目计划》(必须包括总的计划甘特图),并提交立项申请人确认;10. 立项申请人确定后,项目经理根据软件项目计划基线,补充《工作任务卡》,下发到每个组队成员,开发工作开始。
项目管理——某公司软件开发案例

项目管理——某公司软件开发案例观察项目的三个指标:时间、预算、质量及功能完整性。
失败的项目一般体现为:超时、预算超支、牺牲了部分功能或质量。
彻底失败的项目,就是一个最后压根没有完成的项目,比如烂尾楼。
首先,我们讨论其中的一个指标,时间。
每个人对时间的理解不同,同样在项目里面的每个人对项目的时间理解也是不同的。
1、公司,希望项目在最短的时间内完成,这样时间和预算都是最小的。
当然能做到的项目少之又少,业内有数据的。
2、项目经理(为行文方便,暂称为PM,下同),希望项目的计划时间尽可能地长,这样才有机会应付各种突发事件和不可抗的影响,毕竟很多原因是客观存在的。
墨菲定律。
3、功能模块小组长(如……等,暂称为小组长),一方面承受着项目经理的压力,一方面又承受着来自基层开发人员的压力。
PM会要求小组长以最短时间完成所负责的部分;开发人员则很反感长期加班、高度的压力感。
从过去的一年多来看,在时间要求方面,我们公司的意愿并不强烈。
当然并不是强烈就可以解决的,后面会讲到,这是本文的重点。
在我们公司,最后决定项目时间长短的关键,是开发人员。
在人数不变、人员不更换的前提下,每个开发人员的产出是固定的,至少目前来说是固定的。
加班,也不会有更好的改善,原因已经在我以前的邮件中说明过了。
那么,从上至下形成一种新的强制性时间要求,会不会有效呢?事实上,不是没人试过,结果估计并不理想。
程序开发是一种脑力劳动,决定一件任务完成所需时间是由程序员的脑袋决定的,甚至任务完成到什么程度,如果不花费大力气的检查也是不会轻易能发现的。
这点有过中层管理经验的人,应该都清楚。
例如,管理人员要求用三天完成某个新功能,开发人员说至少要一周时间,即使最后管理人员令开发人员妥协了,他得到的也很可能是一个半成品——能用,但有缺陷;或者表面功能完成了,主线功能有部分没有完成。
换人吧,中国程序员遍地都是,这不是问题的关键,所以换人作用不大。
新人很快会被同化。
软件实施方案实例范文

软件实施方案实例范文在软件实施方案的制定过程中,需要考虑到诸多因素,包括组织结构、流程优化、技术支持等方面的内容。
下面,我们将以某公司ERP系统实施方案为例,介绍一个软件实施方案的实例范文。
一、项目背景。
某公司是一家制造业企业,业务涉及生产、销售、采购、仓储等多个环节。
为了提高企业的管理效率,降低成本,提升竞争力,公司决定引入ERP系统进行全面的信息化建设。
二、项目目标。
1. 提高管理效率,通过ERP系统的实施,实现企业各个部门之间的信息共享和协同工作,减少重复劳动,提高工作效率。
2. 优化流程,对现有的业务流程进行梳理和优化,消除繁琐的手工操作,简化工作流程,提高工作效率。
3. 提升服务质量,通过ERP系统的实施,提升企业对客户的服务质量,提高客户满意度,增强市场竞争力。
4. 降低成本,通过ERP系统的实施,降低企业的管理成本和运营成本,提高企业的盈利能力。
三、实施方案。
1. 项目启动,成立ERP实施项目组,明确项目的组织结构和人员分工,确定项目的时间节点和目标。
2. 需求分析,对企业现有的业务流程和管理模式进行深入的调研和分析,明确需求和目标。
3. 系统选择,根据企业的实际情况,选择适合的ERP系统,考虑系统的功能完善性、稳定性、易用性等因素。
4. 定制开发,根据企业的实际需求,对ERP系统进行定制开发,确保系统能够满足企业的特定需求。
5. 数据迁移,将企业现有的数据迁移到新的ERP系统中,确保数据的完整性和准确性。
6. 系统集成,将ERP系统与企业现有的其他系统进行集成,实现信息的无缝对接和共享。
7. 测试验收,对ERP系统进行全面的测试,确保系统的稳定性和功能的完善性。
8. 培训上线,对企业员工进行系统的培训,确保员工能够熟练操作和运用ERP 系统。
9. 运营维护,建立ERP系统的运营维护机制,确保系统的稳定运行和持续优化。
四、实施效果。
1. 管理效率提升,ERP系统的实施,使得企业各个部门之间的信息共享更加便捷,工作效率得到显著提升。
公司软件使用管理制度范本

公司软件使用管理制度范本第一章总则第一条为了加强公司软件资源的管理,保障软件资源的合法、合规使用,维护软件版权,根据《计算机软件保护条例》和国家有关法律、法规,制定本制度。
第二条本制度适用于公司内部所有计算机软件的使用、管理和保护活动。
第三条公司应建立健全软件使用管理制度,明确软件使用的责任、权限和程序,保障软件资源的合理、有效利用。
第四条公司全体员工应遵守本制度,严格按照国家法律法规和公司的相关规定使用软件。
第二章软件采购与管理第五条公司采购软件时,应选择合法、正规的渠道,确保软件的合法性、合规性。
第六条公司应对采购的软件进行登记、归档,建立软件档案管理制度,记录软件的名称、版本、数量、购买日期、使用范围等信息。
第七条公司应加强对软件密钥的管理,建立密钥使用、变更、报废等制度,确保密钥的安全、有效使用。
第三章软件使用与维护第八条公司员工在使用软件时,应遵守软件的使用协议和法律法规,不得擅自复制、传播、修改、删除软件。
第九条公司应加强对软件的维护管理,定期对软件进行升级、更新,确保软件的安全、稳定运行。
第十条公司应建立软件故障报告制度,员工在使用软件过程中发现故障、问题应及时报告,公司应尽快处理。
第四章软件版权保护第十一条公司应加强对软件版权的保护,禁止任何形式的软件侵权行为,包括非法复制、传播、修改、删除等。
第十二条公司应定期组织软件版权法律法规的培训,提高员工的版权意识,防止软件侵权行为的发生。
第五章违规处理第十三条对违反本制度的员工,公司将依法予以处理,包括但不限于警告、罚款、停职、解除劳动合同等。
第十四条对涉及软件侵权的员工,公司将依法予以处理,并承担相应的法律责任。
第六章附则第十五条本制度自发布之日起实施,如有未尽事宜,公司将根据实际情况予以补充。
第十六条本制度的解释权归公司所有。
以上就是一篇公司软件使用管理制度范本,公司可以根据自身实际情况进行修改和完善,以保障软件资源的合法、合规使用,维护软件版权。
公司计算机软件规范化使用管理办法模板

AA公司计算机软件规范化使用管理办法(试行)第一章总则第一条为有效使用计算机软件资源,确保公司计算机软件的合法使用,避免公司员工因使用未经授权的商业软件导致触犯《中华人民共和国著作权法》、《计算机软件保护条例》,从而影响公司声誉或造成计算机、服务器等设备被病毒侵害,影响公司正常工作,依据公司实际情况,制定本管理办法。
第二条本管理办法适用于AA公司(以下简称“总部”)及其在中国境内设立的子公司及附属公司,包括但不限于XXXXX公司等(以下合称“AA公司”或“公司”)。
第二章定义与适用范围第三条本办法中所称的计算机软件(以下简称“软件”),包括但不限于操作系统(Windows 操作系统)、办公软件(如:Office)、专业的应用软件 /工具:(一)操作系统,指日常办公使用的 Windows 操作系统,如:Windows7、Windows10 等;(二)办公软件,指为满足员工日常办公需求必须使用的软件,如: Office 类软件、图片查阅软件、PDF 文件查阅软件等;(三)专业软件,指各业务部门用于生产或业务开展的各类专业软件,如:设计类、开发类、运维类软件及工具。
第四条按照软件商业性质的合法性进行区分,计算机软件包括合法授权的商业软件、免费软件以及未经授权的商业软件,详细区分如下:(一) 合法授权的商业软件,指通过公司统一采购,公司已取得软件权利人合法授权,并经资产管理系统办理入库的软件;(二) 免费软件,指可以自由使用、下载、修改、散布的,不涉及商业授权、不需付费的软件;(三) 未经授权的商业软件,指未取得合法授权的商业软件,包括公司未取得软件权利人的合法授权的商业软件或公司取得软件权利人的合法授权但员工未经审批而使用的或超过授权范围而使用的商业软件。
第三章计算机软件管理的职责与分工第五条信息系统解决方案部作为公司软件正版化归口管理部门,负责监督检查总部及各子公司软件正版化工作的开展和执行情况、负责统筹软件的需求和申请审批、负责各类软件的库存管理及使用分配与台账记录。
软件发布管理流程规范

软件发布管理流程规范编制:审核:日期:版本:编号:密级:精品文档修改历史目录1. 目标 (4)2. 发布流程 (4)2.1.补丁发布流程 (4)2.2.主版本发布流程 (6)2.3.产品实施流程 (9)2.4.VSS管理流程 (10)3. 相关资料 (10)1.目标软件的发布过程,需要形成有序的良性循环。
否则,各环节流转中容易发生相互等待、被动接应的局面。
无形中,不断增加了沟通成本,扩大了软件的风险。
且对后期造成的影响并不能够完全预知、完全估量。
因此,根据公司内部前期已有的习惯,总结过去产品的发布经验,分析统计结果后,特制定本发布过程规范。
预期达到如下目的:1、减少交叉沟通。
通过将发布过程流程化,使每一个环节的执行者都非常清楚自己的产入产出,受谁的影响,将影响谁。
当遇到困难时,能明确的定位寻找到关键人物沟通解决。
避免当需要获取一件事情的进展情况时,需要广泛征询才能掌握的现象。
减少交叉沟通成本。
2、提高工作预见性。
流程一旦启动,流程中的所有人员便被触动。
各环节执行人能迅速在早期预算出自己的“参与时间”、“参与内容”、“参与工作量”,主动提前做出安排、准备,避开人力、时间等资源上的冲突。
且一旦发现冲突,便能立刻“报警”,报得越早,越能提前应对,减少损失。
3、提高可控性。
软件发布就像道路交通。
交通电台有了可靠的消息渠道(取决于上述“1、减少交叉沟通”),便能随时掌握路面交通状况,配合可预见的行车计划(取决于上述“2、提高工作预见性”),当然更能向车队提供有价值的消息。
因此,车队领导能做出更有控制力的指令,各车队协调行驶,整个交通自然更受控。
一条早已设计好的行车路线,加上提前准备就绪的车队人马,再加上行进途中密切配合的交通电台。
与没有固定线路,需要时才去调配车马,电台信息又不畅的队伍相比,哪一个更能成功到达目的地?2.发布流程本章节的流程图中,将使用下列简称。
1、需求组(人):包括需求总负责人(或PM)、各模块需求负责人。
CMM案例分析范文

CMM案例分析范文CMM(Capability Maturity Model)即能力成熟度模型,是一种软件过程改进模型。
CMM是由美国卡内基梅隆大学软件工程研究所(SEI)在1987年开始开发,最早用于评估和改进软件工程的过程。
CMM帮助组织识别自己的软件过程成熟度,并提供了一系列的指导和实践方法,帮助组织改进和提高其软件开发过程的质量和效率。
下面将以家软件公司的CMM案例来进行分析。
软件公司是一家新兴的初创企业,公司规模较小,有一支优秀的开发团队。
由于市场需求不断变化以及项目周期紧张,该公司面临着日益增长的开发压力和质量问题。
为了在竞争激烈的市场中获得优势,公司决定引入CMM,以改进其软件开发过程。
在引入CMM之前,公司的开发过程没有明确的规范和定义,项目经理和开发人员没有固定的流程和标准,每个项目都是在临时的指导下进行开发。
这导致了很多项目在进度、质量和客户满意度方面存在问题。
为了改变这种情况,公司决定实施CMM级别2(管理的软件过程)的要求。
首先,公司组建了一支专门负责软件过程改进的团队,该团队的成员由企业内部高层和开发团队中的一些主要人员组成。
团队的主要任务是分析和评估当前开发过程的状况,然后提出相应的改进方案。
在CMM级别2的要求下,该公司重视制定和标准化软件开发过程,包括项目管理、需求分析、软件设计、编码、测试等环节。
为了确保各个环节的质量,公司在每个环节都引入了相关的文档和规范,并且进行了培训以及内部审核。
此外,公司开始收集和分析项目的度量数据,以便及时识别和解决问题。
软件团队在引入CMM后,逐步改变了他们的开发方式。
他们对每个项目进行详细的计划和需求分析,明确每个阶段的工作内容和交付物,确保项目按计划完成。
团队开始使用一些常用的开发工具和技术来提高开发效率和质量。
此外,他们开始进行代码评审和测试,以减少缺陷的数量。
在实施CMM后的一段时间后,软件公司发现他们的质量和效率得到了显著的提升。
软件公司软件开发流程规范

软件公司软件开发流程规范第一章:项目立项与需求分析 (3)1.1 项目立项 (3)1.1.1 项目背景 (3)1.1.2 项目目标 (3)1.1.3 项目可行性 (3)1.2 需求分析 (3)1.2.1 业务需求 (3)1.2.2 功能需求 (3)1.2.3 技术需求 (4)1.2.4 系统功能需求 (4)第二章:系统设计 (4)2.1 架构设计 (4)2.2 模块划分 (4)2.3 数据库设计 (5)2.4 界面设计 (5)第三章:编码规范 (5)3.1 编码规范制定 (5)3.1.1 编码规范的内容 (5)3.1.2 编码规范的制定步骤 (6)3.2 代码审查 (6)3.2.1 代码审查的内容 (6)3.2.2 代码审查的步骤 (6)3.3 代码管理 (7)3.3.1 版本控制 (7)3.3.2 代码仓库 (7)3.3.3 代码集成 (7)3.3.4 代码备份 (7)3.3.5 代码审查 (7)3.3.6 代码维护 (7)第四章:单元测试与集成测试 (7)4.1 单元测试 (7)4.2 集成测试 (8)第五章:系统测试 (9)5.1 功能测试 (9)5.2 功能测试 (9)5.3 安全测试 (9)第六章:版本控制与发布管理 (10)6.1 版本控制 (10)6.2 发布管理 (11)第七章:项目管理 (11)7.1 项目计划 (11)7.3 风险管理 (12)第八章:团队协作与沟通 (13)8.1 团队协作 (13)8.1.1 团队目标明确 (13)8.1.2 团队角色分配 (13)8.1.3 信任与尊重 (13)8.1.4 沟通与协调 (13)8.2 沟通交流 (13)8.2.1 明确沟通目的 (13)8.2.2 采用合适的沟通方式 (14)8.2.3 倾听与表达 (14)8.2.4 建立良好的沟通氛围 (14)8.2.5 及时反馈 (14)第九章:软件维护与升级 (14)9.1 软件维护 (14)9.1.1 维护的定义与重要性 (14)9.1.2 维护类型 (14)9.1.3 维护过程 (15)9.2 软件升级 (15)9.2.1 升级的定义与目的 (15)9.2.2 升级类型 (15)9.2.3 升级过程 (15)第十章:软件评估与验收 (16)10.1 软件评估 (16)10.1.1 评估目的与意义 (16)10.1.2 评估内容 (16)10.1.3 评估方法 (16)10.2 软件验收 (17)10.2.1 验收目的与意义 (17)10.2.2 验收内容 (17)10.2.3 验收流程 (17)第十一章:信息安全与合规 (18)11.1 信息安全 (18)11.1.1 数据保护 (18)11.1.2 系统安全 (18)11.1.3 网络防御 (18)11.1.4 应急响应 (18)11.2 合规性检查 (18)11.2.1 合规性检查内容 (18)11.2.2 合规性检查方法 (19)第十二章:售后服务与支持 (19)12.1 售后服务 (19)12.1.1 售后服务内容 (19)12.1.3 售后服务重要性 (20)12.2 技术支持 (20)12.2.1 技术支持内容 (20)12.2.2 技术支持形式 (21)12.2.3 技术支持重要性 (21)第一章:项目立项与需求分析1.1 项目立项1.1.1 项目背景信息技术的快速发展,企业对信息系统的依赖日益增加,为了提高管理效率、降低运营成本,并适应市场变化,本项目应运而生。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
编者说明:软件过程管理中的一个很重要的工作就是制定项目、组织的过程规范,它是软件开发组织行动的准则与指南。
该文档就是一个实际的过程规范的实例,通过该实例,相信对大家根据自身情况制定符合要求的项目过程规范、组织过程规范有很好的借鉴作用。
1.总则最大限度提高Q&P(质量与生产率),提高Q&P的可预见性,是每一个软件开发机构的最大目标。
而Q&P依赖于三个因素:过程、人和技术,因此要实现Q&P的提高,除了加强技术能力,引进、培育更多优质技术人才之外,规范、改进机构的过程是一个十分重要的手段。
我们希望通过在制定软件过程规范标准,并在软件开发实践中不断地完善、修订,提高Q&P和Q&P的可预见性。
本规范采用CMM(软件过程成熟度模型)的指导,吸收RUP、XP、MSF、PSP、TSP 等过程规范指南的思想、方法及实践,充分结合xxx技术开发部的实际情况,引入先进的技术、方法、工具,为公司的软件开发工作提供一部详细、可操作的过程指南。
在本规范的第一版本中,主要包括管理过程和开发过程两个部分,管理过程中包括项目管理过程、需求变更管理过程、配置管理过程。
对于软件开发项目中的其它的一些过程将在实践中逐步补充、完善。
2.项目管理过程规范项目管理过程是对软件项目过程进行计划、监控/管理、总结的辅助过程,包括需求、配置、成本、进度、质量和风险等的管理。
项目管理过程主要包括三个阶段:项目立项与计划、项目实施、项目关闭。
2.1 项目立项与计划参与人员:技术开发部指定的项目负责人(包括前期负责人、正式的项目经理)、立项申请人、[相关最终客户]以及实施该项目的开发组队成员;入口准则:接到经公司总经理或副总经理批准的市场部门的《软件开发立项申请表》;出口准则:立项申请人签字确认了经修订正后的正式《软件项目计划》,并通过《工作任务卡》下达了开发任务,开发工作正式开始;输入:经审批的《软件开发立项申请表》、与需求相关的业务资料;输出:《软件项目计划》、《软件需求规格说明书》、《开发任务卡》;活动:接到《软件开发立项申请表》后,技术开发部经理指定前期负责人,并告知立项申请人;前期负责人阅读《软件开发立项申请表》后,通过与立项申请人的沟通、阅读立项申请人提交的材料、通过立项申请人与客户直接交流等方式,了解项目目标、范围与基本需求;并形成最初的《软件需求规格说明书》;前期负责人会同技术开发部经理以及其它相关人员,制定最初的《软件项目计划》,并组织评审;向立项申请人提交最初的《软件项目计划》;最初的《软件项目计划》通过立项申请人的确认后,项目经理计划安排需求分析;需求分析完成后,形成正式的《软件需求说明书》,提交立项申请人确认;(需求分析过程参见开发过程规范部分)根据立项申请人确认后的《软件需求说明书》,项目经理组织进行软件高层设计,并对工作任务进行分解,并根据实际需要向技术开发部经理申请资源,组建项目组队;项目经理根据工作任务分解,下发《工作任务卡》,并协同组队成员进行任务估算;注:工作任务包括模块开发任务、其它任务(如安装);模块开发任务主要包括:详细设计、编码和单元测试任务估算完成后,组队成员向项目经理提交《个人进度安排》(以甘特图的形式表示),项目经理根据每个组队成员的《个人进度安排》修订《软件项目计划》(必须包括总的计划甘特图),并提交立项申请人确认;立项申请人确定后,项目经理根据软件项目计划基线,补充《工作任务卡》,下发到每个组队成员,开发工作开始。
相关模板:《软件需求规格说明书》、《软件项目计划》、《工作任务卡》说明:如果计划确认、需求确认未通过,立项申请人与项目经理进行协商,进行修正,无法达成共识的,提交部门经理、总经理协调;2.2 项目实施参与人员:项目经理,项目组成员;入口准则:项目计划基线已建立,并通过立项申请人确定,带有工作进度要求的《工作任务卡》已下发到每个项目成员;出口准则:立项申请人在《验收报告》上签字确认;输入:《软件需求规格说明书》、《软件项目计划》、《工作任务卡》;输出:经验收测试的可交付的程序、源代码及相关文档。
活动:在开发期间,项目成员每周需上交一份《时间日志》、《缺陷日志》,每天向项目经理汇报工作任务进度;在开发期间,项目经理负责填写《项目进度周报》报于技术开发部经理、立项申请人(格式不同,交予立项申请人的只需周报的第一页,报予技术开发部经理的项目进度周报的第二页为“跟踪甘特图”);项目经理必须根据实际的进度情况,及时调整项目计划,若发现进度延误,需采取措施。
相关模板:《软件项目计划》、《开发任务卡》、《时间日志》、《缺陷日志》、《项目进度周报》2.3 项目关闭参与人员:技术开发部经理或经理助理、项目经理,项目组成员、立项申请人、[相关客户、公司总经理、公司副总经理];入口准则:立项申请人在《验收报告》上确认;出口准则:形成《项目总结》,完成项目绩效考核,项目数据存入“过程数据库”;输入:《时间日志》、《缺陷日志》、《项目开发计划》;输出:《项目总结》、已完成的《项目绩效考核表》、过程数据库中的该项目记录;活动:项目经理主持召开项目总结会,交流项目实施过程中的心得体会,对项目实施中的成功处、不足处进行总结,并由项目经理形成《项目总结》;由技术开发部经理组织对该项目进行绩效考核,并填写相应的《项目绩效考核表》;项目经理组织所有成员对项目过程中的文档、源程序等资料进行整理、归档;由项目经理根据过程数据库的需要,整理相应的数据,提交技术开发部经理,存入过程数据库。
相关模板:《项目总结》、《项目绩效考核表》3.开发过程规范开发过程是提炼用户需求,设计、构建和测试满足这些需求的软件并最终将其交付给客户的过程。
是软件过程中的主体过程之一。
当开发新的应用或计划为现有的应用进行重要的增强时,需使用本规范所定义的开发过程执行。
项目管理过程是对开发过程进行计划、监控/管理、总结的辅助过程,但由于项目管理是保证进度、质量的重要手段,因此在软件项目中也是十分重要的过程之一。
而需求管理过程与配置管理过程则是次重要的辅助过程,需求管理过程是一个需求变更管理的过程,以对变更进行统一的管理;配置管理过程的最重要工作就是版本控制,使得开发过程中的各种交付物能够有机地形成一个个整体。
因此以上四个过程是交织进行的,均是为成功完成软件项目的保障过程。
3.1 过程总述现在比较通行的开发过程模型包括:瀑布模型、演化模型、原型模型、螺旋模型等。
根据公司的项目特点、队伍规模、组队情况等实际因素,决定选择最为简单、易于掌握的瀑布模型为基础,根据公司特点,进行合理的修改,使其成为公司本阶段的软件开发过程。
本规范将整个开发过程分为:需求分析、高层设计、详细设计、编码和单元测试、集成计划与测试、系统测试、验收测试与安装、维护等八个阶段。
3.2 需求分析阶段需求分析的主要目的是生成一个正确说明客户所有需求的文档。
换言之,软件需求规格(Software Requirement Specification,SRS)文档是该阶段的主要输出。
正确的需求分析和确定需求规格对一个项目的成功是非常关键的。
许多在系统和验收测试时发现的缺陷是在需求阶段产生的。
在验收阶段去掉需求阶段产生的一个错误将比在需求阶段本身去掉该错误要多花100多倍的费用。
很明显,在执行这阶段时,正确地生成具有最少缺陷的SRS 是非常必要的。
参与人员:项目经理,[分析员],立项申请人,[客户,最终用户];入口准则:项目立项,最初的项目计划已得到立项申请人的确认。
注:这里所说明的需求分析阶段是进行开发过程的需求分析阶段,在技术开发部出具初步的项目计划之前的需求沟通工作,不是该过程规范所定义的。
最初的需求沟通工作可以参考本过程规范。
出口准则:立项申请人、[客户]在《软件需求规格说明书》上签字确认;输入:《项目立项申请表》、最初的《项目计划》,需求相关的资料;输出:经确认的《软件需求规格说明书》;活动:整个需求分析过程主要包括以下几个步骤:首先,项目经理与分析员一块,做好需求分析的准备,包括阅读相关的背景资料,熟悉客户的实际情况,准备用户访谈计划,准备会谈问题清单等;然后通过面谈、专题讨论会等形式与客户进行沟通,采集需求的详细内容,澄清每一个需求点;从而界定出系统的目标和范围;对所采集和澄清的需求进行分析,构建需求模型,从功能性、非功能性两个方面进行需求分析,深入领会客户需求;形成《软件需求规格说明书》,建立软件需求基线,并为软件需求评审做好准备;由项目经理安排软件需求评审,协同立项申请人、[客户]进行需求评审;立项申请人[或客户]在《软件需求规格说明书》上确认。
相关模板:《软件需求规格说明书》3.3 高层设计阶段高层设计是软件开发过程中的一个重要阶段,在这个阶段将从计算机实现的逻辑角度开发针对用户需求的解决方案。
这一解决方案是一个高级的抽象方案。
高层设计要设计出各主要部分,并说明他们在技术上如何工作:1)相互间的协作;2)所需外在的硬件和软件环境;3)内在环境。
也就是说,高层设计确定了组成产品的构件,定义了每个构件的功能任务,并且定义了构件间的接口及构件到运行环境的外部接口。
参与人员:项目经理,项目组员(设计团队);入口准则:《软件需求规格说明书》已通过立项申请人的确认;出口准则:形成高层设计,实现任务分解,所有的问题得到解决;输入:《软件需求说明书》输出:《高层设计说明书》(功能与数据库设计)、详细设计、编码、文档和用户接口标准;活动:制定详细设计、编码、文档和用户接口的标准;根据项目特点选择运行的目标平台和开发工具;制定软件的体系结构,定义逻辑和物理的对象模型,包括确定类、类的属性、类方法、类之间的关系和对象间的动态交互。
若采用结构化设计,则该活动应为功能设计;从需求规格说明书中的数据模型中得到物理数据库结构,进行物理数据库设计:包括确定表/记录类型、域和其他部分。
生成高层设计说明书,并组织设计评审。
相关模板:《高层设计说明书》3.4 详细设计阶段在详细设计阶段,高层设计阶段开发出的整体应用被分成几个模块(或构件)和程序。
为每个程序(或构件)进行逻辑设计,然后归档作为程序规格,同时为每个程序(或构件)生成一个单元测试计划。
详细设计阶段的重要活动包括通用例程和程序的确定、框架程序的开发以及用于提高生产率的实用程序和工具的开发。
在详细设计阶段负责每个程序、模块(或构件)的内部设计,确定其程序流程,并且可以通过使用设计语言、图形流程图(如活动图、状态图)等,或通过简单地写叙述而将设计文档化。
参与人员:每个模块(或构件)的任务承担人;入口准则:《高层设计说明书》已通过评审;出口准则:完成详细设计,所有的问题得到解决,详细设计与单元测试计划文档化;输入:《软件需求规格说明书》、《高层设计说明书》、详细设计标准输出:《详细设计说明书》、《单元测试计划》活动:将高层设计中的每个程序(或构件)细分成小的组件;对每个小组件进行详细设计,包括确定调用方法、输入和输出、程序逻辑、数据结构等;根据组件的逻辑,制定单元测试计划,包括确定单元测试环境、测试用例、测试数据等;向项目经理(或高层设计者)提交详细设计与单元测试计划;相关模板:《详细设计说明书》、《单元测试计划》剪裁说明:对一些小项目,详细设计阶段的活动1、2可以省略。