系统开发过程和项目管理

开发模型

把开发过程分成一些阶段。

瀑布模型：SDLC。缺陷在于最开始需求要明确，但是开发周期很难不变动。

因此改进：

原型：一个demo。

快速原型模型：抛弃模型，一旦获取到了用户需求，就可以抛弃掉原型了。

演化模型：在原型基础上根据用户需求进行改进。但是问题在于如果用户干涉过多，用户主导项目，那么难以控制项目时间。

因此把原型和瀑布模型结合，诞生了螺旋模型和增量模型。

螺旋模型：适合项目大，风险高的项目。从demo做起，可能做到最后才有一个可操作的产品。

增量模型：每次发布的都是可操作的产品。

V模型：加了一些验证和测试。对软件要求质量高，缺点在于测试要在编码之后才能进行。

喷泉模型：面向对象。

图片来源：喷泉模型是什么？_智慧蓉城的博客-CSDN博客

在这里插入图片描述

RAD：基于构件模型和瀑布模型的快速模型，现在常用。

构件组装模型：

构件库大大提高了移植等开发的效率。

敏捷方法模型：符合敏捷宣言就是敏捷方法。

大概原理就是小的版本快速交付。

典型的敏捷方法：

极限编程。

并非必须全部应用，要根据具体项目具体分析。

水晶方法系列：crystal，用较少的纪律约束仍然能成功。
开放式源码 openUp：开发者地域上分布很广，差错排障高度并行。任何人把补丁发给维护者，维护者把补丁并入源码库。
scrum 并列争球法：不断迭代。把一段时间比如30天的迭代称为一个冲刺，多次按优先级进行的迭代实现需求。
FDD 功用驱动开发方法，短时迭代阶段，编程任意一般分为首席程序员（项目协调）和类程序员（源码编写）。
asd 自适应软件开发方法，分为猜测、合作、学习三个阶段。
dsdm 动态系统开发方法，业务中心框架开发方法，以业务为核心。

项目管理

专家判断法：专家利用经验判断。

三点估算法：最好情况需要多少人员？最坏情况呢？一般情况呢？根据权重计算。

功能点估算：根据项目的几个功能点估算。

时间管理

PERT图

虚线是不需要时间的活动。

最早开始时间从头开始正推。如E活动。最早要等到到达3结点后开始，也就是第四天开始(AB最大值），最早第七天结束。

25最早完成。

最迟工作时间从该节点开始反推。

A：总时差0

B：2

C：2

……

关键路径：总时差=0的一条路径。1-2-3-4-6-7-9，这条关键路径上的事件不能延误，延误会影响整体项目流程。

PERT图关系表示的很明白。

甘特图

甘特图时间流程，资源规划方便。但是表示关系表示的不好。

例题：

最少时间是最长路径 ABCEFJ 18天。

BC BD同一个人开发，要么先BC后BD，BD晚3天；要么先BD后BC，BC晚2天，总时长+2.

本来是02578最久，55天。

改变后相当于0268是8+23+25=56天。

最短时间：ABDIJL 20天。

经过GH的路径：17天，所以GH松弛时间20-17.

软件配置管理

开发库测试后可以进入受控库，可以修改，修改后再测试放回。

检查点：规定的时间间隔内对项目检查，看看实际与计划之间的差异并修改。

里程碑：阶段性工作的标志。

基线：经过正式的评审，重要的里程碑。不能轻易改变。

功能基线：系统设计规格说明书。
分配基线 srs：需求规格说明书。
产品基线：软件产品的全部配置项的规格说明（综合）。

提交评审通过后再申请变更，把代码拉下来检出到工作状态开始变更。

风险分类

CMM认证

一种认证，通过的项目可能更受青睐。软件研制和软件测试中的实践。

18个关键域：

考试会问哪个评审是哪个级别的。

需求工程

需求分析很重要，有时候做不好整个项目都会崩。

需求开发：需求获取，需求分析，需求定义（srs规格说明书），需求验证。

需求管理：上面的部分确定后，通过需求基线申请改动实际的需求。包括变更控制，版本控制，需求跟踪，需求状态跟踪。

需求分为：软件需求，用户对系统在功能、控制、行为、性能、设计约束等方面的期望（系统要解决的问题是什么）。

用户需求：用户视角。
业务需求：整体全局。
系统需求：计算机化。包括功能需求（要实现的功能），非功能需求（性能等），设计约束（比如数据库，用户要求用mysql，或者os，用户要求linux）。

从上到下从抽象的全局到具体的细节。

三最抽象，二功能上最具体。

A。

结构化分析

数据字典：对数据的描述，便于用户或开发者理解。比如数据库里的dbname项存储数据库名称，encoding存储其编码方式……或者购票平台上规范用户输入，目的地只能选择如北京、河北、广州……

数据流图：

顶层表示系统与外部实体的关系。下图是顶层图的具体。

圆圈是数据的加工，箭头是有流向的数据，两根线是数据的存储，外部实体是方形的实体，是外部数据的来源。

状态行为图：

起点，终点（带圈），框是状态，线是事件。

相对于数据流图，是一种动态的行为，数据流图是静态的。

ER图，mysql的老熟人：

实体和属性通过连线连接。

强实体和弱实体的概念：

培训公司数据库设计
业务需求是这样的：

每位学生每期只能参加一门课程。

言外之意，公司有很多课程。我们只分析“每位学生每期只能参加一门课程”这一需求，发现涉及到两个实体：学生、课程。所以我们或许会想当然地这样去设计数据库：

一个课程可以由多个学生选择，一个学生只可以选择一门课程。发现问题了吗？业务需求里不是说一个学生只能参加一门课程，而是说一个学生在一期只能参加一门课程！这么设计数据库是在断人家财路。因此，我们必须考虑“每期课程”这个概念：

看样子似乎是没问题了，但是数据库设计是不可能这么容易就没问题的。我们把每期课程都作为一个记录，那么对于课程的信息，比方说课程名称、价格、介绍，每开一期课就要向数据库中存一行记录，因此我们的数据库会出现大量冗余（也就是说不满足数据库第二范式)。因此，我们应该这样去设计数据库：

看到了吗？这里的“Record”是一个弱实体，它的主键是“学期主键+学生主键”，代表学生参加课程这一行为，抽象成为了弱实体。为什么要用学期表的主键和学生表的主键呢？因为一个学生、一个学期，那么就只能参加一门课程了，所以根据主键唯一标识每行记录的原则，应该这样去选取。课程表的主键成为了Record表的外键，课程表与Record表之间存在一对多关系。

在这个例子中，学生、课程是业务需求描述中显而易见的实体，“期”也可以认为是比较明显的实体，但“参加”这个动词在我们的数据库中便成为了“参加记录” ，也就是Record实体。
————————————————
版权声明：本文为CSDN博主「乔卿」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qq_41112170/article/details/103328927