软件设计与失信
本章主要介绍软件设计与实现的过程。
11.1 分析与设计方法
分析与设计方法有很多：
以文字为主的文档，如Word、PowerPoint 文档。正如我们在需求分析和场景设计中看到的那样。
用图形为主构造的模型，如Mind Map（思维导图），ERD，DFD，UML的各种图，甚至包括Flow Chart流程图
用数学语言的描述，如Vienna Development Method
用类自然语言+代码构造的描述，如Literate Programming
源代码加注释也能描述
11.2 图形建模和分析方法
11.2.1 表达实体和实体之间的关系（Entity Relationship Diagram, Entity Relationship Model，Mind Map）
思维导图
实体关系图（Entity Relationship Diagram）
表示实体之间的静态关系时，ERD是一个合适的工具：
- 参与者（Actor）：表示参与系统运作的外部因素，例如用户，管理员，外部模块，设备，来自外部的信号等。通常是一个简笔画的小人。
- 系统：通常用一个方框来表示系统的边界。有时也可以忽略。
- 用例（Use Case）：表示系统和参与者交互的一次场景。它是一组动作的集成，而不是一个单独的内部元素。
- 信息传递线：用带箭头的线用来表示参与者和系统通过相互发送信号或消息进行交互的关联关系。
11.2.2 表达数据的流动（Data Flow Diagram）
大学图书馆管理系统为例
11.2.3 表达控制流（Flow Chart, Finite State Machine）
有限状态自动机（Finite State Machine, FSM）
11.2.4 统一的表达方式（Unified Modeling Language, UML）
各种图示建模方法的大致特点
11.4 从Spec到实现
某公司开发流程
11.5 开发阶段的日常管理
- 闭门造车（Leave Me Alone）
当场景、功能都计划好的时候，要给员工足够多的时间，让他们投入到工作中去，而不要经常打断他们。要尽量减少非开发时间，不要动不动就开“全体会议”。
- 每日构建（Daily Build）
当有一个能运行的系统时，即使只是一个简单的系统，（团队的）积极性也会上升。
在理论上，理论和实践是一回事，而在实践上，理论和实践是两回事。
- 构建大师
- 负责管理构建服务器。
- 调试构建，负责找错，并分析出错的原因。
- 负责把“构建大师”称号和责任交给下一个导致构建失败的成员。
- “构建大师”同时向团队的“腐败基金”存入50元，以供大家将来“腐败”之用（此项可选）。
- 宽严皆误
大部分时间都花在了没有价值的“同步/编译/验证/再同步……”的循环中。
团队有两条路可以实行。
（1）严格的规则和流程控制，这样会保证很高的签入成功率，如果一个人根据流程来做，几乎肯定能成功。这样构建质量高，但是团队的进展会受到限制。极端情况下，整个团队的进展被序列化为一系列个人串行签入操作。
（2）宽松的规则和流程，每个人随时可以签出签入，签入时的成本很低，但是签入成功率不高，构建质量低，极端情况下，所有人都可以签入、同步，但是没有人能正常工作。
构建宽严表，某团队目前的开发流程如上表
- 小强地狱（Bug Hell）
让Bug多的队员专心修复Bug，不要开发新功能。
The End
以上介绍的是软件设计与实现的一些策略方法，可以借鉴参考，选择更适合自己团队的流程，提高开发效率。
