|
执行阶段
图 5-1 执行阶段的任务和工件
分析产品的关键需求、对架构设计有影响的需求和风险较高的需求，直到分析的程度能开展足界面原型设计和架构设计工作。
《需求规格说明书》的内容包括：
|
商业或业务需求
|
从商业或业务角度宏观上对产品或系统的要求。它主要在宏观的层面归纳总结为满足客户提出的要求或赢得市场竞争所必须实现的功能、性能、质量等要求。
- 做什么
- 做的范围
- 对结果的要求
|
|
使用者需求
|
从客户对软件产品或系统使用方案的角度出发，描述和总结使用者利用该软件产品或系统能够做的事或能够完成的任务。
|
|
功能需求
|
根据上述使用者需求列出的使用方案，列出开发者必须为软件产品或系统实现的功能。
|
|
性能需求
|
- 运行速度、容量、并发性能
- 对资源的利用率
- 对外界输入的反馈速度和准确性
- 对差错的负荷能力
|
|
系统需求
|
（包括运行平台、网络及其他硬件要求）
（包括与操作系统、数据库、浏览器及其他应用软件的兼容要求）
|
|
质量需求
|
（可靠性、效率性、灵活性、安全性、互操作性、稳定性、健全性、可用性）
（可维护性、多用转换性、重复使用性、可测试性）
|
|
其他需求
|
不属于上述需求范围的，但受到其他环境和商业合同影响的要求。
- 国家或地区的任何特别的标准
- 软件使用界面的特别要求
- 与知识产权有关的要求
- 软件所面对的市场和行业的规范
- 客户的特别要求
|
|
开发的局限
|
对开发的成功与否起很大影响的因素，是开发能力的局限：
- 人员的局限
- 技术的制约和局限
- 客户的特别要求
|
表 5-1 需求分析告
《需求分析报告》的编制方式可以是多样的，例如把所有“非功能性需求”组织成“外部接口需求”、“质量属性需求”和“需求约束”。【如：图5-2】
图 5-2 需求规格说明书
明确了系统的关键需求后，就可以进行界面原型设计工作，获取用户的反馈，尽快确定产品的界面基调。同时要编写一份《界面设计概要》文档，作为后续的界面设计工作的指导。
《界面设计概要》的内容包括：
- 设计的理念
- 理念的来源或参考
- 设计的要点
- 与类似产品界面的对比
架构设计从关键需求开始，建立概念性的架构，并逐步细化和验证。最终生成架构设计说明书和架构基线代码。
架构设计的方法：可以从几个不同的视角进行架构设计，然后汇总综合得出完整的设计。（架构设计的五个视图【如：图5-3】）
图 5-3 架构设计的五视图
《架构设计说明书》的内容包括：
|
概 述
|
说明编写的目的、适用范围以及设计原则等。
|
|
逻辑架构
|
关注功能。其设计着重考虑功能需求。
- 细化功能单元
- 发现通用机制
- 细化领域模型
- 确定子系统接口和交互机制
|
|
开发架构
|
关注程序包。其设计着重考虑开发期质量属性，如可扩展性、可重用性、可移植性、易理解性和易测试性等。
- 确定要开发或直接利用的程序包之间的依赖关系
- 确定采用的技术、框架等
|
|
数据架构
|
关注持久化数据的存储方案。其设计着重考虑“数据需求”。
- 持久化数据存储方案
- 数据传递、数据复制、数据同步等策略
|
|
运行架构
|
关注进程、线程、对象等运行时概念，以及相关的并发、同步、通信等问题。其设计着重考虑运行期质量属性，例如性能、可伸缩性、持续可用性和安全性等。
- 确定引入哪些进程与线程
- 确定主动对象、被动对象，以及控制关系
- 处理进程线程的创建、销毁、通信机制、资源争用等
- 协议设计
|
|
物理架构
|
关注软件系统最终如何安装或部署到物理机器。其设计着重考虑“安装和部署需求”。
- 确定物理配置方案
- 确定如何将目标程序映射到物理节点
|
|
总 结
|
基于上述的设计进行总结，并描述架构基线。
|
表 5-2 架构设计说明书
架构设计的另一个重要任务是编写架构基线代码，基线代码表述和验证架构，同时也是指导后续开发的基础代码。架构基线代码的内容包括：
- 所有工程项目
- 工程目录结构
- 软件包结构
- 导入所有依赖包
- 基础公共代码
- 架构框架代码
- 架构框架示例代码和测试代码
- 数据库框架
图 5-4 和图 5-5 展示了软件架构师的工作和成功的软件架构设计包含的内容：
图 5-4 软件架构师的工作
图 5-5 成功的软件架构设计
1 软件构建
软件可以分阶段进行构建，每个阶段可以使用增量的方式开发，用通过若干个Build构建，最后发布阶段性产品成果。
（注意：在这里 ，名词“阶段”的含义和本文其他地方的含义不一样）
构建阶段计划的内容包括：
- 确定本阶段要实现的功能
- 列出阶段任务
- 计划Build构建数量
- 细化《开发进度表》中本阶段的工作内容
详见：下一节
构建阶段完成后发布阶段产品成果，向用户展示并接受用户反馈，同时做好阶段总结。
《发布清单》的内容包括：
- 产品版本号和日期
- 改正的Bug
- 修改的功能
- 实现的新功能
- 其他说明
《阶段总结报告》的内容包括：
- 阶段任务的完成情况
- 进度计划的执行情况
- 用户的反馈情况
- 本阶段碰到的主要问题
- 下一阶段的改进建议
2 Build 构建
Build构建以增量的方式执行阶段的开发任务，每个Build构建的周期一般不超过两星期，每一次Build构建都会发布为一个内部版本，并提交测试。测试发现的问题留待以后的Build构建解决。
《Build计划》的内容包括：
- 本次Build的版本号
- 本次Build的历时
- 本次Build的工作任务
- 要解决的遗留Bug
- 本应由以前的Build实现的，但推迟到本次Build实现的功能
- 要实现的新功能
- 其他工作任务
- 工作任务分配
根据《Build计划》，细化本次Build要实现的需求，细化到能进行详细设计为止。有了细化的需求后就编写本次Build的测试计划。
《测试计划》的内容包括：
- 其他测试（性能测试、边界测试、使用界面测试、可用性测试、安全性测试等）
- 。。。。。。
根据细化的需求设计用户界面，当界面确定后即可编写测试用例。
《测试用例》的内容包括：
- 测试用例对应的功能模块
- 测试用例的性质（功能测试用例、性能测试用例、。。。。。。）
- 输入（或操作步骤）
- 期望输出
- 实际输出（执行测试后再填写）
- 是否通过（执行测试后再填写）
详细实际每项需求的实现方法，对于重要的设计决策、算法、公共模块和外部接口等必须以模块设计文档的形式进行记录。《模块设计文档》的内容包括：
- 模块名称
- 设计思想
- 设计图表（类图、流程图等）
- 要点描述（包、接口、类、方法、算法、设计模式）
- 测试方式
编码和单元测试是开发人员的工作，对于重要的代码都必须进行单元测试，编写代码必须遵守下列准则：
- 遵守编码规范
- 编码前必须充分理解相关的需求
- 编码前先进行设计，把流程理顺
- 注意设计方法和设计模式的灵活运用
- 总体考虑问题，使代码遵从架构并容易测试
- 设计时要充分考虑异常情况和临界条件
- 严禁Copy-Paste，注意提取公共代码，在编码过程中实现重构
- 异常处理必须记录日志，严禁草率地直接打印异常信息
- 灵活运用ASSERT() / VERIFY()等断言来帮助调试程序
- 单元测试是程序员的工作，所以编码完成后必须对代码严格测试
- 功能代码完成后必须先做以下4件事情：
- 编译代码，保证编译通过
- （不运行程序）对代码进行全面检查
- 用调试模式启动程序，一行一行单步执行代码，并注意调试输出
- 改变条件，让代码尽可能走遍所有程序分支
- Check In代码前必须保证能编译通过
代码集成发布前需冻结代码，所有人把要提交的代码Check In，并保证编译后的程序能在测试服务器上正常启动，界面能正常打开。同时还要提交Build清单。
《Build清单》的内容包括：
- Build版本号和日期
- 改正的Bug
- 修改的功能
- 实现的新功能
- 其他说明
按照《测试计划》针对《Build清单》执行《测试用例》，测试完成后编写测试报告。
《测试报告》的内容包括：
- 测试用例汇总（用例数量、通过的用例数量、未通过的用例数量等）
- Bug汇总（Bug总数、新增Bug数量、关闭Bug数量、Bug趋势图表等）
- 测试计划执行情况
- 测试总结
|
