第一章 需求分析
——追求完美VS.容忍缺陷
1. 软件分析和设计的基本思路:
当项目组面临两难选择时,首先要用鱼和熊掌来识别矛盾的两个对立方面。项目组用“小鱼”来比喻那些开发和维护代价较小、结构较简单,但是缺乏某些灵活性的设计方案,用“熊掌”来比喻那些灵活、易扩展,但结构复杂,卡发和维护成本较高的设计方案。在最终进行选择的时候,项目组必须坚持如下原则:
在满足需求的情况下,尽量选择“小鱼”而舍弃“熊掌”;只有存在无可置疑的理由时才选择“熊掌”作为设计方案。
2. 软件项目的需求分析一般要经历下面这些步骤:
1) 区定项目的目标和范围
2) 根据项目的目标和范围分析出所有项目干系人
3) 提出所有的非功能性需求
4) 分析所有的功能性需求,现在一般采用用例分析的方法进行
5) 撰写出项目的《需求说明书》
3. 极限编程Extreme Programming 中的一个基本原则:只实现你真正需要的东西,不要去实现你认为需要的东西
4. 小A的错误:
1) 在Fish GUI 分析时将Windows界面照搬进去,其中大量而复杂的无用的功能将会浪费大量的人力物力
2) 小A认为只要增加资源,就可以在更短的时间内实现更多的需求。例如:1个人2个月能完成的事在现实中2个人用1个月是不可能完成的。
5. 使用快速原型法实现对客户界面需求分析
6. 需求分析是一个项目组与其他所有项目干系人共同参与的过程,在这一过程中,有效的交流与沟通最为重要
7. 任何项目都会发生变化,程序员应当对项目过程中的需求变化作好充分准备。
第二章 用例分析
——海底总动员VS.云中漫步
1. UML只是开发人员在设计过程中表达世纪思想进行交流和沟通的一种工具,使用时应该“点到为止”
2. 用例的三要素:
1) 用例是由系统的最终用户或外部环境发起的。用例的发起者被称为用例的参与者。参与者既可能是具体的人,也可能是某个外部软件系统
2) 每个用例只描述单独的任务,而不能描述多个任务,用力所描述的任务必须符合用户意图的完整的工作内容
3) 用例必须产生一个对用户有意义的结果s
3. 根据用例三要素,用例建模步骤如下:
1) 确定系统边界
2) 确定参与者
3) 找出所有用例
4) 确定每个用例的级别
5) 撰写用例的文字描述
6) 画出以整个系统为对象的顺序图
4. 可以在不同的系统边界或不同的用例级别上进行,程序员应根据具体情况谨慎选择。从不同角度的分析,结果会有很大差异
5. 用例图,文字描述,顺序图等都是用例分析的有效工具