软件开发周期文档格式.docx
- 文档编号:3022874
- 上传时间:2023-05-01
- 格式:DOCX
- 页数:7
- 大小:39.15KB
软件开发周期文档格式.docx
《软件开发周期文档格式.docx》由会员分享,可在线阅读,更多相关《软件开发周期文档格式.docx(7页珍藏版)》请在冰点文库上搜索。
大致将软件需求分三个层次:
1.业务需求
2.用户需求
3.功能需求和非功能需求
1.业务需求反映了组织机构或客户对系统、产品高层次的目标要求,它们在项目视图与范围文档中予以说明。
2.用户需求文档描述了用户使用产品必须要完成的任务,这在使用实例文档或方案脚本说明中予以说明。
3.功能需求定义了开发人员必须实现的软件功能,使得用户能完成他们的任务,从而满足了业务需求。
4.非功能性的需求——描述了系统展现给用户的行为和执行的操作等,它包括产品必须遵从的标准、规范和约束,操作界面的具体细节和构造上的限制。
(2)软件项目之设计
设计是根据需求调研的结果,对产品的技术实现有粗到细进行设计,而根据设计粒度和目的的不同可以将设计分为概要设计、详细设计等阶段以便于管理和确保质量。
概要设计就是设计软件的结构,包括组成模块,模块的层次结构,模块的调用关系,每个模块的功能等等。
同时,还要设计该项目的应用系统的总体数据结构和数据库结构,即应用系统要存储什么数据,这些数据是什么样的结构,它们之间有什么关系。
详细设计阶段就是为每个模块完成的功能进行具体的描述,要把功能描述转变为精确的、结构化的过程描述。
概要设计阶段
一般在概要设计这个阶段,主要集中于划分模块、分配任务、定义调用关系,模块间的接口与传参在这个阶段要定得十分细致明确,应编写严谨的数据字典,避免后续设计产生不解或误解。
概要设计一般不是一次就能做到位,而是反复地进行结构调整。
典型的调整是合并功能重复的模块,或者进一步分解出可以复用的模块。
在概要设计阶段,应最大限度地提取可以重用的模块,建立合理的结构体系,节省后续环节的工作量。
概要设计文档最重要的部分是分层数据流图、结构图、数据字典以及相应的文字说明等。
以概要设计文档为依据,各个模块的详细设计就可以并行展开了。
详细设计阶段
这个阶段,各个模块可以分给不同的人去并行设计。
在详细设计阶段,设计者的工作对象是一个模块,根据概要设计赋予的局部任务和对外接口,设计并表达出模块的算法、流程、状态转换等内容。
这里要注意,如果发现有结构调整(如分解出子模块等)的必要,必须返回到概要设计阶段,将调整反应到概要设计文档中,而不能就地解决,不打招呼。
详细设计文档最重要的部分是模块的流程图、状态图、局部变量及相应的文字说明等。
一个模块一篇详细设计文档。
概要设计文档相当于机械设计中的装配图,而详细设计文档相当于机械设计中的零件图。
我们公司对模块的认识和传统定义有所不同,认为是较大的软件功能单元才可以称作模块。
这种认识使大家对概要设计和详细设计的分工产生了混乱的理解,降低了文档的可用性,应该予以纠正。
概要设计中较顶层的部分便是所谓的方案。
方案文档的作用是在宏观的角度上保持设计的合理性。
有的项目采用面向对象的分析、设计方法。
可能在概要设计、详细设计的分工上疑问更多。
其实,面向对象的分析、设计方法并没有强调结构化方法那样的阶段性,因此一般不引入概要、详细设计的概念。
如果按照公司的文档体系,非要有这种分工的话,可以将包的划分、类及对象间的关系、类的对外属性、方法及协作设计看做概要设计;
类属性、方法的内部实现看做详细设计。
概要设计里的功能应该是重点在功能描述,对需求的解释和整合,整体划分功能模块,并对各功能模块进行详细的图文描述,应该让读者大致了解系统作完后大体的结构和操作模式。
(3)软件项目之编码
有了上述两个阶段完成了,有了相应的需求文档,以及设计文档,Now,接下来对Coding人员相对来说就相对Easy了,数据约束神马的都有了,业务逻辑神马的也有了,根据相要求完成相应模块,按标准完成任务。
(4)软件项目之测试
功能测试用户界面测试性能测试压力测试容量测试配置测试安装测试
(5)软件项目之维护
项目中的维护任务主要指为保障信息系统正常运行提供支持服务,配合业务变更对软件系统进行维护等,包括软件功能变更等开发维护、日常运维支持和一些临时性工作需求。
根据风险控制等管理需要,将维护工作分为以下五类,不同的工作类别采用不同的管理手段。
(1)新增功能。
在业务模块中添加新的业务功能或操作。
(2)功能变更。
对已上线使用的业务功能进行修改、完善和功能扩充或变更、下线操作。
以上两类一般需要修改源代码,明确需求后,经过严格的变更影响分析,按照开发流程实施,经过测试后上线。
(3)辅助性操作。
分为数据相关和非数据相关两个部分,不涉及代码的修改,用于支持用户更好地开展工作或者进行开发的辅助工作。
数据相关工作主要是配合用户的临时需求进行数据统计、回溯等工作;
非数据相关工作包括用户账户开设、培训、应用软件安装等事务性工作。
(4)常规操作。
周期性的系统运维工作,包括日常例行检查、日常维护操作等。
(5)应急处理。
对各类因系统故障、软件功能缺陷等突发事件处理和应对,确保系统尽快提供服务,避免对业务的开展造成影响。
软件外包流程
一个完整的软件外包项目流程包括:
需求分析、总体设计、详细设计、开发编程、测试分析、系统整合及现场支持。
1.需求分析:
建立合作意向后,我们首先会对客户要求有详尽的了解,准确知道客户需求、客户的商业模式和业务流程,并结合自身的经验,为客户提出改进建议。
2.总体设计:
在需求确定并获得客户认可后,由系统设计师进行系统架构设计,并与客户一起制定项目实施计划。
3.详细设计:
由程序设计人员根据系统架构,真对不同模块的功能和规格进行详细设计。
4.开发编程:
由程序员根据详细设计及计划,进行软件程序代码的编写。
5.测试分析与系统整合:
不同模块的编程工作完成后,经过测试,并进行系统的整合。
6.现场支持:
软件系统开发最终完成后,到客户现场进行安装、调试、培训。
7.系统运行支持:
在系统投入运行后,我们可以为客户进行长期系统的维护,除了保证系统的正常运行外,还要根据客户的业务变化以及使用过程中发现的问题,对系统进行修改。
需求规定
项目中功能说明
逐项定量和定性地叙述对项目所提出的功能需求,说明输入什么量、经怎样的处理、得到什么输出、说明产品的容量等等
对功能的一般性规定
列出开发产品的所有功能(或一部分)的共同要求,如要求界面格式统一,统一的错误提示等等
业务流程
数据描述静态数据动态数据
功能需求功能描述界面描述报表格式图形要求输入输出要求接口要求性能要求
数据精确度数据量
技术需求
解决方案架构
配置
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 开发 周期