以下是我在软件行业中9年的工作经验,7年的带队、软件分析、建模、设计、开发的经验的一些浅谈。希望对在软件行业中的软件分析员、软件架构师及项目经理等职位的相关人员共勉。
一个完整的软件开发包括以下七个步骤:
1 准备工作
2 获取需求
3 需求分析
4 系统分析
5 系统设计
6 开发
7 测试
步骤1到步骤3,我们一般称为“需求分析”阶段;
步骤4、步骤5,我们一般称为“系统设计”阶段;
步骤6,我们一般称为“编码实现”阶段;
步骤7,我们一般称为“系统测试”阶段;
而以上七个步骤和四个阶段可根据软件大小、开发周期、开发方式等不同而对各步骤各阶段涉及的内容进行取舍。以下我们来浅谈各个阶段、各个步骤涉及的相关内容。
每次开发迭代过程都应该包括以上七个步骤和四个阶段,在迭代过程中,随时进行内容更新。
一般来说,准备工作应该涵盖以下部分内容:
1 了解问题领域
主要包括两部分:“了解业务概况”和“整理业务目标”,最终落实下来,该部分形成“需求分析”文档中的“项目背景”和“业务目标”(该业务目标为粗线条目标)。
2 涉众分析
主要包括两部分:“定义涉众”和“形成涉众分析报告”。而涉众分析报告,对具体的业务需求获取能提供直接明确的指向性;且对业务用例、业务用例场景、业务用例场景分析、业务用例边界定义、系统架构设计等提供指导意义。
“涉众分析报告”内容主要包括:涉众概要、涉众简档(涉众部分针对业务)、用户概要和用户简档(用户部分针对系统,粗线条抽取)四部分组成。
3 规划业务范围
主要包括两部分:“涉众优先级划分”和“期望(业务目标)优先级划分”。该部分对“规划需求层次”工作的开展有指导性作用。
4 规划需求层次
主要包括三部分:“业务架构”、“业务流程”和“工作细节”;我们一般从涉众和期望优先级从高到低逐步进行规划。
“业务架构”:围绕业务背景、业务目标、业务目标人员、业务参与人员、组织结构、岗位设置等展开,搭建对业务领域的第一认识和了解;
“业务流程”:针对业务目标、将参与这个业务目标的业务目标人员、业务参与人员、组织结构、岗位设置等组织起来,描述业务流程的运转过程以及每个参与元素在运转过程中的贡献和期望;
“工作细节”:根据每个业务流程的涉众(参与者)展开,描述每个涉众的工作细节。即需得到涉众的在业务流程中做什么、怎么做、有哪些规则(限制)、得到的结果是什么……
一般来说,获取需求应该涵盖以下部分内容:
1 抽取业务用例
一般来说,业务用例的抽取,以业务目标为基准进行抽取,业务目标的每项,抽取为一个或几个用例。注意业务用例的抽取或业务用例的细化都应该统一在一个抽象层次上。
2 定义边界
根据业务目标和业务用例,定义业务用例的边界。边界为该业务从什么地方和什么开始,到什么地方和什么时候结束,牵涉到哪些涉众,且牵涉的涉众在该业务用例中,只设置哪些具体业务等;注意:边界的定义,需具体化,不能出现凌磨两可的情况;
3 发现主角
根据涉众概要和定义的边界两方面来发现业务用例主角。注意:主角都应该在业务用例边界外,作用于业务用例;
4 业务建模
主要包括:绘制业务用例图和业务用例场景图、说明业务用例规约和业务规则、建立业务对象模型(包括业务属性和业务方法);
5 领域建模
主要包括:划分领域、定义领域边界、绘制领域关系图(包图)。
6 提炼业务规则
多说几句,很多人在需求分析时,不太重视业务规则或只当成系统设计中的程序逻辑,而往往业务规则能在需求阶段就告诉我们应该怎么做,才能成功完成用例或用例场景;
主要包括:全局规则、交互规则、内部规则;
7 获取非功能性需求
这个不用多说相信大家都明白,主要包括:用户习惯、系统美观等等。表现在系统中主要体现在系统的可靠性、可用性、有效性和可移植性四个方面;
一般来说,需求分析应该涵盖以下部分内容:
1 关键概念分析
主要包括:建立概念模型、归纳子系统、抽取功能点、定义概念类(包括边界类、控制类、实体类)
2 业务架构设计
主要内容:系统框架设计图、子系统功能拓展图、概念层和说明层类图、包图、业务和概念用例活动图、状态图、时序图、协作图;
以上3部分为“需求分析阶段”,通过以上3部分每个部分的迭代,最终生成软件工程中的“需求分析文档”。
一般来说,系统分析应该涵盖以下部分内容:
1 确定系统用例
主要包括:系统用例图、系统用例场景图、实施层类图、包图。
2 分析业务规则
目的:形成系统编程的全局量、输入参数、接口、逻辑规范等。
主要包括:
1) 全局规则,形成系统全局量、逻辑规范等;
2) 交互规则:形成接口、输入参数等;
3) 内部规则:形成输出参数等;
3 用例实现
主要包括:实现用例的场景活动图、时序图等;定义用例边界类接口、控制类方法、实体类属性和动作函数等;
4 软件架构和框架
主要包括:
1) 系统架构:包括系统子系统、子系统的输入输出、子系统间的交互接口等;
2) 系统框架:实施技术、机制、方法、算法等;
5 分析模型
主要包括:系统接口类、控制类、实体类的详细定义;绘制数据流程图(根据具体情况);
6 分析组件模型
主要包括:归纳、分析组件模型。通过对上面的系统用例、系统用例场景的实现,抽取出相同功能性的具体系统技术、表现点、界面呈现点等,归纳为组件,且分析组件的输入输出相关结构;
7 定义部署模型
主要包括:
1) 应用程序:基础软件结构、软件架构、外部接口等;
2) 运行环境:安全环境、数据环境、外设等;
3) 绘制部署模型图;
一般来说,系统设计应该涵盖以下部分内容:
1 设计模型:
主要包括:功能点的目标、输入输出对象或数据结构、使用的技术和算法、函数名的定义等;
2 设计接口:
主要包括:边界类、控制类、实体类、超类对外交互的函数的定义;
3 设计包
主要包括:设计软件层包、模块包、代码包等;
该阶段其实没什么可说的,大家好像的明白是怎么回事,这里主要说说我的一些相关经验。编码,我建议从最核心的系统用例和系统用例场景开始。这样的好处,通过很多次的迭代周期,系统的核心业务会非常强壮,在软件交付时,不会出现预料外的情况。尤其在软件开发周期内并没有全部完成软件的功能时,核心业务的强壮程度,决定了甲方对系统的任何程度。
一般来说,开发应该涵盖以下部分内容:
1 编写代码
主要包括:环境设置、编码、反向工程(技术分析和测试时使用的比较多);
2 分工策略
主要包括:纵向和横向两种,主要看系统大小、技术力量、研发周期等因数,灵活考虑分工策略;
在这里,根据我的经验,我测试分作两个阶段:
1 设计阶段的测试
主要包括:
1) 确定用例;
2) 确定用例场景;
3) 确定执行路径和步骤;
4) 确定测试用例因数(白盒测试用例因素、黑盒测试用例因素和定义压力测试用例因素等);
5) 编写或开发测试矩阵报告;
2 开发阶段的测试
主要包括:
1) 功能性测试:使用白盒测试用例数据,程序员自行测试或测试员重点测试;
2) 用例和用例场景测试:测试员根据白盒测试用例和黑盒测试用例进行覆盖式测试,形成用例和用例场景功能性测试报告;
3) 非功能性测试:测试员对可靠性、可用性、有效性和可移植性进行测试,形成非功能性测试报告;
4) 压力测试:对整个系统、用例场景进行耗时、内存占用、进程和线程等进行极限测试,形成压力测试报告;
5) 形成系统整体测试报告;
在每次迭代前,都需要制定迭代计划;
迭代计划包括:
1)迭代周期;
2)人员分工;
3)迭代场景;
4)迭代范围(上次迭代实现并测试完成的用例、场景、功能不应纳入该次迭代范围中,主要说明拓展部分);
5)迭代周期应该包括需求分析阶段、系统设计阶段、开发阶段和测试阶段,根据迭代内容的拓展,而修改各个阶段生成的文档和代码;