软件开发流程

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

快视信息软件开发流程规X:

用户需求:软件项目首先由客户经理(CM,Custom Management)接洽客户的较大的需求。这时的需求叫市场需求(或叫用户需求),客户经理会进行各个项目的安排,即对项目的启动时间和发布时间进行规划和设置。

项目经理(PM,Project Management)对客户经理负责。项目经理的需求是根据客户经理给的,项目经理不和用户(客户)直接接触(通过客户经理接触),负责和用户进行需求洽谈和沟通的是客户经理。一个项目的需求在一般情况下是不准变更的,如果有需求理解方面的不清楚可以进行沟通,但是需求是不变更的。如果用户有新的需求,一般规划在下一个版本中。因为需求变更了,这个目的时间就要进行调整,就不能按计划进行和完成。客户经理提交给项目经理的是需求规格说明书。

一、项目开工会

在项目经理领到客户经理分配给的需求后,做项目计划,具体做项目人员的确定、需求的分解(需求分解到每个人)、代码量的估计,项目各个阶段时间的划分和工作量的计划、质量指标的设定。这时项目经理需要输出的文档是项目需求分解任务书、项目计划PPT、及做好整个项目需要填写的一系列表格。然后组织项目组成员和客户经理CM、QA(质量审计经理)进行项目开工会。这时这个项目就算真正启动,计算工作量时,即计算这个项目总共花了多少个工时,工时是项目经理做计划的时间也算在内,再加上项目开工会和后续各个阶段总共花的总工时数,还有各个阶段开会所花的时间。在项目开工会上,各个成员就明确了这个项目是属于增强型项目,还是其他项目的项目性质,增强型项目的意思是说在原来上一版本的基础上又根据新的需求进行增强型开发。还有要明确项目最后开发出的新增代码量有多少,最后要明确每个人的需求任务,接下来着手进行SRS的写作。

二、SRS阶段:System/Software Requirment Specification

软件需求规格说明

在项目开工会后,项目组就开始按照在项目开工会上项目经理的需求任务分解的任务开始进行SRS的写作。

一般项目经理给你的一个子需求任务,你这时需要分解为更小的需求。一般一个需求的写作是按这样进行的。先简单介绍这个需求,然后把这个需求设计成黑盒的形式,即输入,处理过程、输出。这些都需要写详细,任何一个需求都写成这种形式,输入是什么,处理过程是什么,输出结果是什么。处理过程需要用Visio或者PPT画出处理流程图,流程图要很详细。每一步的各种情况都要表示和考虑到。对异常情况也要考虑和进行处理。还有要说明在原来的基础上怎么改动,具体方法要进行说明。设计的数据库表结构,要给出脚本,SQL语句,

表结构需说明每个字段,哪些是主键,你在这个需求处理过程中哪里使用了哪些表,需要进行哪些操作,都需要说明。这里需要设计和编制《数据库设计说明书》文档。该文档中描述该系统中设计出的所有的数据库表结构和各字段类型。还有多个操作对象要画序列图表示出按时序的处理过程。这个SRS文档就相当于我们平时毕业设计或者一个题目的详细设计阶段达到的水平,甚至比它更详细。每个项目组成员都把自己的需求的SRS文档写出来之后放到配置库中,然后每个人对项目组其他成员的(非自己的)SRS文档进行Review(评审),对每个SRS文档在每页发现或者纠正的错误数不能低于一定的数目,而且要保留批注记录,经过Review的(保留批注的)文档要放到配置库的Review文件夹下,这是进行项目质量指标收集的重要依据,是QA 进行调阅和审计的资料。项目经理要对SRS文档、SRS Review文档进行汇总。在汇总后组织项目组全体成员进行SRS阶段会议,对每个人写的SRS进行评审会议(讨论和提意见),对别人给你提的修改意见你要一一进行说明,说明为什么不改,怎么改的,是什么问题,问题严重程度属于什么级别,而且都要填表,也是QA进行审计的内容。开完会后如果每个人完成的都差不多,然后安排半天或者一天的时间进行返工,主要是进行修改文档,按在会上讨论的结果和别人给你的Review文档结果(评审结果)进行准一修改和完善。然后再进行SRS阶段开会,如果都做的比较到位和具体、符合要求,即关闭SRS阶段。这时SRS阶段的花费的工时数和一些质量活动指标就出来了,比如你这个SRS文档写了几页,每页的错误数是多少,返工修改用了多少时间,然后这些这个比率也会自动计算出来。进而可以判断这个阶段的质量。每个项目组成员在每天工作完毕后都要进行Time Sheet 的填写,必须具体到半个小时,这是统计和分析的需要。填写必须真实。

三、UTP、STP阶段(UTP、STP写作)

UTP

Unit Test Plan

单元测试计划

STP

System Test Plan

系统测试计划

在SRS阶段完成后一般安排比较很短的时间进行UTP、STP的写作。即单元测试计划、系统测试计划。这两个需要输出提交的是两个表格。单元测试计划按预置条件(即需要设置的先决条件)、输入、期望的输出、实际的输出这样设计的表格来填。即每个单元测试用例都按这样的黑盒测试方法来写。另外还有一种需要编写测试代码来进行测试用例的设计,即对每个被测类需要设计一个测试类,用这个测试类来调用和驱动被测类的数据成员和方法,然后给出断言。测试用例的设计同一个主要功能的要多设计几个例子,对异常也要设计用例进行

测试。尽可能多的覆盖。STP 是在单元测试基础之后用的,是项目组把产品交到专门的测试部门前的项目组的联调和测试。这时需要写出系统测试计划。为了到后面单元测试阶段和系统联调阶段使用。这两个文档也需要按照前面的方法和流程进行Review(评审)、汇总、会议评审、修改返工、定稿。最后关闭这个阶段。也按前面的方法需要进行所用工时的填写。QA和PM进行分析。

QA

Quality Assurance

质量保证

四、SD阶段

System Design

系统设计

这个阶段是逻辑设计阶段。按照前面的SRS文档,一般一个人连续性地负责前面PM在项目开工会分配给你的一个需求的各个阶段的设计和其他工作。进行LD文档的写作。要非常具体,比如按照前面设计出的SRS文档中的一个需求,这个阶段你需要设计出具体的数据结构,要设计出哪些类,每个类的各个数据成员是什么,是什么类型的,每个类要设计哪些函数,函数要很具体,函数名称、返回值,参数(输入参数、输出参数),该函数由谁来调用它,它又由调用了哪些函数,函数的具体处理过程要写成伪码的形式。这个阶段需要使用Rational Rose画出设计出的每个类的成员和函数。以及类之间的关系。这个阶段的输出就是LD文档。也按前面的方法进行Review(评审)、汇总、会议评审、修改返工、定稿。也进行工时的记录和统计、分析。

五、CODE阶段

SRS、LD阶段完成后,在CODE(编写代码阶段)就比较容易和轻松了。只需要找到添加代码的地方,然后写上标志,比如

Begin infoX–MDSP V200102 2006-9-1 liuyongpingadd(modify,delete)

代码

End infoX–MDSP V200102 2006-9-1 liuyongpingadd(modify,delete)

Add表示中间这段代码是你写的,modify表示是你修改的,delete表示你把这段代码删除了。

相关文档
最新文档