软件生命周期
问题定义
必须明确要解决的问题是什么，这是第一位的
“我要开发一个论坛”，“我们需要一个网站”……这种问题描述是模糊的，我们必须明确问题的性质是什么，工程目标是什么，工程规划是什么
问题定义的文档经过讨论后形成报告，最终要得到客户的确认
可行性分析
问题定义完成后，我们需要在较高的抽象层面上思考问题是否能够完成，是否值得完成，在成本，设备，技术，法律等方面衡量，避免盲目开展不值得投资的工程项目
需求分析
需求分析的主要目的是确定系统应该具备哪些功能，即：为了解决这个问题，我们应该做什么。需求分析应该得到一份如用数据流图，数据字典和简要的算法来表示的系统逻辑模型，用正式的文档记录对目标系统的需求，即规格说明书
总体设计
又称为概要设计，应该至少给出高中低成本三个方案，并用恰当的工具描述出来供用户选择
确定方案后，应该确定程序的体系结构，即软件所包含的模块，每个模块的功能和模块间的联系
详细设计
给出程序的详细规格说明，它们应该包含对应的细节，可以对照着写出代码的那种
编码和单元测试
顾名思义
综合测试
代码写好后整体的验收
软件维护
软件的改正，完善，预防，适配新环境等
软件过程
通常采用生命周期模型来描述软件过程
瀑布模型
需求分析->设计实现->测试->维护一条龙
按顺序一步一步开发，前面的必须做好提交好文档之后才能进行后面的工作，防止急于求成导致失败
问题是过于理想化了——前面的工作做完美了才能开展后面的，但肯定没法完美。也有可能前面分析的挺好，做到后面才发现变了——不经实践就分析出完美的需求是不可能的
快速原型模型
先搞个原型，让用户体验，根据反馈的意见来修改原型，再交给用户……
这样做可以了解用户的真正需求
增量模型
把用户的需求分成多个增量构件，先把最核心的需求实现了，然后每次加一些构件，分批提供产品
好处是便于用户适应，也防止用户跑路，维护性好，能更好地随环境变化而变化
但缺点是增量构件要求在不破坏之前产品的情况下对其进行扩展——这是很难的
螺旋模型
加了风险分析的快速原型模型？我不太懂
喷泉模型
面向对象软件模型，开发过程中有迭代和无缝的特征，不是很懂
其他模型
不是很懂
可行性研究工具
系统流程图
系统流程图是描述物理系统的，每个符号形式定义了组成系统的一个部件，箭头规定信息流过系统的逻辑路径
数据流图
数据流图DFD描述信息流和数据从输入移动到输出过程中所经受的变换，数据流图不包含任何物理部件，它仅仅描述数据在软件中流动和处理的逻辑过程
方框表示数据的输入和输出，圆表示数据的处理，箭头是数据的流动，两条线是数据的存储
数据字典
数据字典是对数据流图中所包含的元素定义的集合
比如一个数据流叫订货报表
1 | 名字：订货报表 |
需求分析工具
实体-联系图
即ER图，是对数据库的建模和抽象
包含数据对象和组成数据对象的属性，以及数据对象之间的联系
状态转换图
状态是可以被观察到的系统行为模式，事件是某个特定时刻发生的事情
事件会引起系统做动作或转换状态，而系统处于不同的状态也会影响对事件的处理方式
状态转移图用箭头连接不同状态，箭头上的事件是造成转移的触发条件。如果箭头上没有事件，则表明是状态内部活动执行完之后自动转移