步骤(瀑布模型 water model)
1. 项目规划(计划)
2. 需求分析
3. 系统设计
4. 实现与部署
5. 软件测试
6. 运行管理
其实, 大部分的软件模型都是以瀑布模型为基础, 再稍加改动. (可以参考另一个blog, 查看所有的软件设计模型)
另外还有很多软件开发模型, 这里推荐一个 增量模型, 个人在使用
增量模型, (incremental model)
软件被作为一系列的增量构建来设计, 实现, 集成和测试, 每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成, 增量模型在各个阶段并不交付一个可运行的完整产品, 而是交付满足客户需求的一个子集的可运行产品. 整个产品被分解成若干个构件, 开发人员逐个的构件, 最后达成交付产品.
个人感觉增量模型比较好, 也在采用中. 
1. 规划与分析阶段, 使用 micro porject 工具来进行
2. 需求分析阶段, DFD, PROCESS 图, 使用 micro visio 工具来进行
3. ER图 阶段, 使用 toad, 或 power designer 来进行.
4. sql 语句及 后期的数据库维护阶段, 使用 toad.
上图中, 需求分析中:
数据需求分析: 是指在数据库中应该存储那些数据(数据的组织与存储, 注意这时不时建表), 所以 DFD 图要画到能够体现存储的数据为好, 这样为以后创建E-R图, 及创建数据库中的对象, 如表等都有帮助.
处理需求分析: 是指用户要完成什么处理功能. DFD
DFD
画数据流图 DFD 注意事项:
1. 不要过早陷入具体的细节
2. 从整体或宏观入手分析问题, 如业务系统的总体结构, 系统及子系统的关系. (按照业务逻辑划分出独立的子模块)
3. 通过图形化的模型对象直观地表示系统要做什么, 完成什么功能.
4. 模型对象不涉及太多技术术语, 便于用户理解模型
DFD 建模方法的核心是数据流, 首先抽象出具体应用的主要流程, 然后分析其输入, 如其初始的数据有哪些, 这些数据从哪里来, 将流向何处, 又经过了什么加工, 加工后变为什么数据, 这些数据流最终将得到什么结果. 通过对系统业务流程的层层追踪和分析把要解决的问题清晰的展现及描述出来.
DFD 方法由 4 种基本对象组成 数据流, 处理, 数据存储 和 数据源/数据终点.
注: 上图中的符号没有关系, 因为每本书所用的符号不一样, 但是设计思路, 内容是一样的
DFD图 的设计过程, 也是一个逐步细化的过程: 例如:
1. 先是一个有输入, 有输出, 然后一个大的系统
2. 大的系统再细分成若干子系统(可以按照实际的业务逻辑划分, 例如SUB系统, 可以按照 资材室, 不良仓, 生产线, 成品仓 划分为4个部分)
3. 若干子系统再细分为更细微的子系统
另外, 检查数据流图中的每一个元素标有名字, 且层次图易于理解, 其次自顶向下检查数据流图, 保证能够通过编号识别父图与子图之间的对应关系, 然后检查数据流, 要求在较高层次上出现的信息流(图中箭头表示的信息), 在分解后的较低层次中必须出现, 最后检查处理, 保证每个处理至少有一个输入数据流和一个输出数据流.
ER图
E-R 图的作用, 承上启下, 如果上上边的DFD图, PROCESS 图 等需求分析阶段 是针对现实世界流程的一个概括, 那么 E-R 图 是要将现实世界抽象成数据库世界的关键步骤, 主要的作用是根据现实逻辑 及 DFD 图中的存储数据来生成数据库中的对象, (实体(table 等), 实体间的关系, 还是实体的属性), 这时, 要考虑现实世间中哪些内容可以构成一个实体, 哪些内容数据实体的属性, 实体与实体之间有什么关系, 及实体的关键KEY.
一些工具甚至提供了, 你设计完E-R图以后, 会自动可以生成数据库中的 table 等实体, 属性, 等内容.
设计思路：
1. 是每个子系统出发, 形成实体, 属性, key, 子系统内部实体之间的联系.
2. 每个子系统都完事以后, 再次确认各个实体之间是否存在联系.
3. 完善已经生成的E-R图, 是否有冲突等等.
联系分类:
1:1 对于实体集A 中的每一个实例, 实体B中至多有一个实例与之联系, 反之亦然.
1:n A 中的每个实例, B 中可以有多个与之联系, 但是反之则不行, 只能有一个与之对应, 如果反之亦然, 那么就是 m:n 的关系了
m:n 应该通过设计的改变等等, 尽量避免这种情况出现. (如果避免不了, 需要单独建立一个关系实体, 这个M:N的关系, 其中要包括对于这个关系的实体的所有主键, 以便唯一确认关系)
转载
以自底向上设计概念结构的方法为例，它通常分为两步：
第一步：首先要根据需求分析的结果（数据流图、数据字典等）对现实世界的数据进行抽象，
设计各个局部视图即分E-R图。
第二步：集成局部视图。
概念结构是对现实世界的一种抽象，一般有三种抽象：
⑴分类 （ is member of ）
⑵聚集 ( is part of)
⑶概括 (is subset of )
设计分E-R图的步骤是：⑴选择局部应用
在需求分析阶段，通过对应用环境和要求进行详尽的调查分析，用多层数据流图和数据字典描述了整个系统。
设计分E-R图的第一步，就是要根据系统的具体情况，在多层的数据流图中选择一个适当层次的（经验很重要）数据流图，让这组图中每一部分对应一个局部应用，我们即可以以这一层次的数据流图为出发点，设计分E-R图。
一般而言，中层的数据流图能较好地反映系统中各局部应用的子系统组成，因此人们往往以中层数据流图作为设计分E-R图的依据
⑵逐一设计分E-R图
每个局部应用都对应了一组数据流图，局部应用涉及的数据都已经收集在数据字典中了。现在就是要将这些数据从数据字典中抽取出来，参照数据流图， <1> 标定局部应用中的实体, <2> 实体的属性、标识实体的码， <3> 确定实体之间的联系及其类型（1：1、1：n、m：n）。
<1> 标定局部应用中的实体
现实世界中一组具有某些共同特性和行为的对象就可以抽象为一个实体。对象和实体之间是 "is member of "的关系。例如在学校环境中，可以把张三、李四、王五等对象抽象为学生实体。
对象类型的组成成分可以抽象为实体的属性。组成成分与对象类型之间是 "is part of "的关系。例如学号、姓名、专业、年级等可以抽象为学生实体的属性。其中学号为标识学生实体的码。
<2> 实体的属性、标识实体的码
实际上实体与属性是相对而言的，很难有截然划分的界限。同一事物，在一种应用环境中作为 "属性 "，在另一种应用环境中就必须作为 "实体 "。一般说来，在给定的应用环境中：
⑴属性不能再具有需要描述的性质。即属性必须是不可分的数据项。
⑵属性不能与其他实体具有联系。联系只发生在实体之间。
<3> 确定实体之间的联系及其类型（1：1、 1：n、 m：n）。
根据需求分析，要考察实体之间是否存在联系，有无多余联系
（二）、 合并分E-R图，生成初步E-R图。
各分E-R图之间的冲突主要有三类：属性冲突、命名冲突和结构冲突。
1．属性冲突 (1) 属性域冲突，即属性值的类型、取值范围或取值集合不同。
例如：属性“零件号”有的定义为字符型，有的为数值型。
(2) 属性取值单位冲突。 例如：属性“重量”有的以克为单位，有的以公斤为单位。
2．命名冲突 (1) 同名异义。 不同意义对象相同名称。
(2) 异名同义（一义多名）。同意义对象不相同名称。“项目”和“课题”
3．结构冲突
(1) 同一对象在不同应用中具有不同的抽象。例如 "课程 "在某一局部应用中被当作实体，而在另一局部应用中则被当作属性。
(2) 同一实体在不同局部视图中所包含的属性不完全相同，或者属性的排列次序不完全相同。
(3) 实体之间的联系在不同局部视图中呈现不同的类型。
例如实体E1与E2在局部应用A中是多对多联系，而在局部应用B中是一对多联系；又如在局部应用X中E1与E2发生联系，而在局部应用Y中E1、E2、E3三者之间有联系。
解决方法是根据应用的语义对实体联系的类型进行综合或调整。
（三）．修改与重构，生成基本E-R图
分E-R图经过合并生成的是初步E-R图。之所以称其为初步E-R图，是因为其中可能存在冗余的数据和冗余的实体间联系，即存在可由基本数据导出的数据和可由其他联系导出的联系。冗余数据和冗余联系容易破坏数据库的完整性，给数据库维护增加困难，因此得到初步E-R图后，还应当进一步检查E-R图中是否存在冗余，如果存在，应设法予以消除。修改、重构初步E-R图以消除冗余，主要采用分析方法。除此外，还可以用规范化理论来消除冗余。
由于company隐私问题, DFD图, 流程图, ER图 实际项目, 请参考日记中的 “系统开发中的图标(公司隐私 非公开)”