软体开发流程( 二 )


软体开发流程

文章插图
2.系统分析员深入了解和分析需求 , 根据自己的经验和需求用WORD或相关的工具再做出一份文档系统的功能需求文档 。这次的文档会清楚列出系统大致的大功能模组 , 大功能模组有哪些小功能模组 , 并且还列出相关的界面和界面功能 。3.系统分析员向用户再次确认需求 。概要设计首先 , 开发者需要对软体系统进行概要设计 , 即系统设计 。概要设计需要对软体系统的设计进行考虑 , 包括系统的基本处理流程、系统的组织结构、模组划分、功能分配、接口设计、运行设计、数据结构设计和出错处理设计等 , 为软体的详细设计提供基础 。详细设计在概要设计的基础上 , 开发者需要进行软体系统的详细设计 。在详细设计中 , 描述实现具体模组所涉及到的主要算法、数据结构、类的层次结构及调用关係 , 需要说明软体系统各个层次中的每一个程式(每个模组或子程式)的设计考虑 , 以便进行编码和测试 。应当保证软体的需求完全分配给整个软体 。详细设计应当足够详细 , 能够根据详细设计报告进行编码 。编码在软体编码阶段 , 开发者根据《软体系统详细设计报告》中对数据结构、算法分析和模组实现等方面的设计要求 , 开始具体的编写程式工作 , 分别实现各模组的功能 , 从而实现对目标系统的功能、性能、接口、界面等方面的要求 。在规範化的研发流程中 , 编码工作在整个项目流程里最多不会超过1/2 , 通常在1/3的时间 , 所谓磨刀不误砍柴功 , 设计过程完成的好 , 编码效率就会极大提高 , 编码时不同模组之间的进度协调和协作是最需要小心的 , 也许一个小模组的问题就可能影响了整体进度 , 让很多程式设计师因此被迫停下工作等待 , 这种问题在很多研发过程中都出现过 。编码时的相互沟通和应急的解决手段都是相当重要的 , 对于程式设计师而言 , bug永远存在 , 你必须永远面对这个问题!测试测试编写好的系统 。交给用户使用 , 用户使用后一个一个的确认每个功能 。软体测试有很多种:按照测试执行方 , 可以分为内部测试和外部测试;按照测试範围 , 可以分为模组测试和整体联调;按照测试条件 , 可以分为正常操作情况测试和异常情况测试;按照测试的输入範围 , 可以分为全覆盖测试和抽样测试 。以上都很好理解 , 不再解释 。总之 , 测试同样是项目研发中一个相当重要的步骤 , 对于一个大型软体 , 3个月到1年的外部测试都是正常的 , 因为永远都会有不可预料的问题存在 。完成测试后 , 完成验收并完成最后的一些帮助文档 , 整体项目才算告一段落 , 当然日后少不了升级 , 修补等等工作 , 只要不是想通过一锤子买卖骗钱 , 就要不停的跟蹤软体的运营状况并持续修补升级 , 直到这个软体被彻底淘汰为止 。软体交付在软体测试证明软体达到要求后 , 软体开发者应向用户提交开发的目标安装程式、资料库的数据字典、《用户安装手册》、《用户使用指南》、需求报告、设计报告、测试报告等双方契约约定的产物 。《用户安装手册》应详细介绍安装软体对运行环境的要求、安装软体的定义和内容、在客户端、伺服器端及中间件的具体安装步骤、安装后的系统配置 。《用户使用指南》应包括软体各项功能的使用流程、操作步骤、相应业务介绍、特殊提示和注意事项等方面的内容 , 在需要时还应举例说明 。验收用户验收 。维护根据用户需求的变化或环境的变化 , 对应用程式进行全部或部分的修改 。软体维护维护是指在已完成对软体的研製(分析、设计、编码和测试)工作并交付使用以后 , 对软体产品所进行的一些软体工程的活动 。即根据软体运行的情况 , 对软体进行适当修改 , 以适应新的要求 , 以及纠正运行中发现的错误 。编写软体问题报告、软体修改报告 。1、软体资料库管理