软件设计与实现
分析和设计有许多方法，比如以文字为主的文档、以图形为主的模型、用数学语言描述、注释加代码等。
图形建模和分析方法
思维导图Mind Map
思维导图形式灵活，适用于很多鼓励探索、发散思维的场合，但是它的图形元素缺乏严格的语法和语义。
实体关系图Entity Relationship Diagram
着重表达实体之间的联系时可以用实体关系图，例如：
我们可以将各种词汇来与ERD图中的元素对应起来：
用例也有图形化的表示，也就是Use Case Diagram，UCD。用例图主要有下列几种元素：参与者、系统、用例和信息传递线。
表达数据的流动Data Flow Diagram
关注数据在不同实体之间的流动时，可以用该图表述，以图书管理系统为例：
每个数据的操作还可以进一步细化，形成一个更低层次的DFD。
表达控制流Flow Chart
也就是基本的流程图，此外还有有限状态自动机（Finite State Machine，FSM），它是由一组状态、一个起始状态、输入、将输入与现在状态转化为下一个状态的转换函数所构成。
统一表达方式UML
全称是Unified Modeling Language，UML使用了统一的表达方式来完成图形建模，是一个非常成熟的理论，但是对于它能否清楚的表达还有待争论。
从Spec到实现
一个开发人员拿到设计文档后，他会做下面几件事情：
将开发人员的标准工作流程用图来表示：
开发阶段的日常管理
闭门造车Leave Me Alone
有很多开发人员在工作中会出现忙了很久，却发现真正用在开发上的时间很少的情况，此时应该面对不同的任务或邮件，分优先级处理，分批查看和解决。
另外，不要主动查看测试人员发现了什么bug，而是经过会诊之后正式提交到你手上再行动，防止做无用功。这是因为开发人员在开发阶段最重要的任务就是完成规定的功能（有时在项目初期，可以不用等到集体会诊结束，开发和测试人员可以直接处理bug）
每日构建Daily Build
编译时要产生debug版（调试版本，包含调试信息，不包括优化）和release版（发布版本，进行了各种优化，让用户更好的使用）。
构建时如果出现失败，就要分析构建失败的原因，然后对症下药，让做事不仔细的人慢下来，对于导致构建失败的成员，可以授予构建大师Build Master称号，他负责管理构件服务器，负责找错和调试，而且把该称号传递给下一个导致构建失败的成员，也可以进行罚款，设置一个构建基金。
宽严问题
有时在修改完代码然后提交到服务器后，发现有人签入了与我的代码有关的新修改，导致版本冲突，如果再次本地编译并测试又会浪费大量时间，而且还有可能遭遇新的版本冲突，此时应该怎么办？
如果在签出一个文件时，加上一个防止别人签出的锁，就可以防止冲突。但是这样的锁多了可能又会导致死锁现象。因此面临这种问题时，团队一般有两种选择：
1、严格的规则和流程控制，这样做个人签入成功率很高，但是团队的进展会受到限制
2、宽松的规则和流程，每个人都可以随时签入签出，但是签入的成功率不高
此时要根据团队目前的情况来选择应对策略，选择时要注意，当团队成员的行为只是影响到个人时，就尽量放松，当其行为影响到整个团队时，就尽量严格。我们也可以公开固定的构建时间。下表就是构建宽严表：
以某公司的具体开发流程为例，时间安排至关重要：
小强地狱Bug Hell
随着项目进展，开发人员手上的bug数会越来越多，有些开发人员喜欢新功能全部实现后再修复bug，但是某些bug久久不修复可能导致的后果很严重，可能会重写一些功能，导致设计变更需求，也就是DCR。因此有这样一种方法可以避免这种情况，这就是小强地狱Bug Hell。
如果开发人员手中的bug达到某一规定值，那么这个人就被送入小强地狱，在地狱中，他唯一能做的就是修复bug，直到bug数低于此阈值，这个值通常由团队根据实际情况确定，注意开发人员同时入狱的人数最好不要超过50%，且阈值不宜频繁调整，可以在每天早上例会时宣布入狱和出狱名单。