10-16 项目规划

1. 项目目标

1.1项目目标必须明确：做什么、不做什么、做到什么程度

可量化：

非量化的描述量化描述大并发并发量>1000tps低延时响应时间<0.1s高可靠性故障率<3%%

通过交互成果体现

阶段成果设计阶段设计文档开发代码、文档测试测试报告上线投产可用于生成的软件系统

1.2 三要素：时间、成本、质量

1.2.1 进度、时间

进度延误会导致成本上升

过期的成果没有意义

进度难以把控：工作量难以评估，完成工作的人难以评估

项目进度管理方法

-编制计划：任务分解，排序，工作量评估，起始时间，产出

-实施，跟踪

-过程监控：监督，偏差分析，调整

1.2.2 成本

合理的投入，有限的预算

成本并不是越低越好（低价中标，恶性竞争，质量缩水）

软件项目成本管理就是管理好进度、质量

1.2.3质量

核心要素

规定时间，成本范围内，拿出质量可接受的成果

质量不是越高越好

软件质量要素

质量管理贯穿整个项目过程

1.2.4 不同项目侧重点不同

1.2.5 三要素之间达成平衡

1.3 功能目标

层次性：核心功能、辅助功能、外围功能

功能界面：做什么，不做什么

1.4 性能目标

1.4.1 响应时间

客户端从发出请求到收到响应的时间

直接关系到用户感受

1.4.2 吞吐量

单位时间内系统处理的客户请求的数量（常用单位tps）

直接体现软件系统的性能承载能力

1.4.3 并发用户数量

系统能同时处理多少个请求

最大用户容量、同时在线用户数、同时处理多少个请求有差异

1.4.4 服务时间

对外持续提供服务的时间

7*24小时：ATM机

1.4.5 故障率

可容许的最长故障时间或错误频率

1.4.6 资源使用率

内部技术参数

合理范围：太高资源匹配不足，太低配置过剩

1.4.7 数据、业务量增长和性能扩展

增长方式：常数、线性、几何级数

扩展：增长软件配置扩展；增长硬件配置扩展；不可扩展

1.4.8 性能瓶颈

网络

数据库

1.5 HTTP服务器目标分解与需求分析

1.5.1 功能

功能层次功能名称详细描述核心功能服务器功能1.监听端口
2.接收客户端连接请求
3.处理连接请求，并发送响应 并发处理1.多线程
2.异步并发 协议支持HTTP1.1协议支持辅助功能缓存静态页面缓存 压缩算法支持支持常见的压缩算法gzip 扩展协议支持支持SSL算法 负载均衡1.支持负载 均衡
2.支持轮询、随机、HASH、最小负载策略 日志管理1.日志自动分片
2.日志自动压缩

1.5.2 性能

用户容量单服务>10000同时在线用户单服务>2000吞吐量静态页面请求>200TPS响应请求单个静态页面请求<0.5s服务时间7*24故障率<千分之三

2. 分层理论

分层优点：

1）分解问题规模：大事化小，复杂变简单

2）专人做专事

3）降低系统、子系统间的依赖

4）有利于复用

软件三次模型：

HTTP服务器的层次：

接口层服务管理：服务启停、参数配置
服务提供：监听、连续接收/回执业务层连接处理、调度策略、会话管理驱动引擎层HTTP协议、socket读写、信号量处理、MIME、string模块，memory模块

3. 模块规划

3.1 模块化设计

把程序、系统划分成若干个模块，每个模块完成一个子功能，各模块集合起来形成一个整体

3.2 特点

各模块完成独立的一类功能

细节隐藏、信息局部化

特定的输入、输出

模块依赖程度应该最小

3.3 要求

高内聚低耦合

3.4 Monkey的模块规划

模块名称源文件功能说明连接管理mk_connection.c连接读写、关闭，超时处理请求模块mk_request.c请求创建/释放，request列表管理，request解析、处理，会话管理epoll模块mk_epoll.cepoll创建，注册，杀出，事件监听HTTP
模块mk_http.cHTTP协议处理线程管理模块mk_scheduler.c线程管理

4. 开发方式选择

4.1 瀑布模型

a. 将软件生命周期规划为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了他们自上而下、相互衔接的固定次序，每上一个阶段的输出作为下一个阶段的输入。

b. 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量；

c. 由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险；

d. 早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果；

e. 适用情况

- 稳定的产品定义和很容易被理解的技术解决方案时，纯瀑布模型特别合适；

- 容易理解但很复杂的项目，采用纯瀑布模型比较合适，因为可以用顺序的方法处理

- 开发队伍技术力量比较弱或缺乏经验

- 例如：公司财务系统，库存管理系统

f. 缺点：缺乏灵活性；应对变化和未知能力弱；必须在项目开始前说明全部需求；

4.2 增量开发模型

a. 整个系统被分解成若干个构件，每个构件实现一定的功能，逐个构件集成整合到系统中，不是在项目结束的时候一下交付全部软件，而是在项目的整个开发过程中持续不断的交互阶段性成果。

b. 有点：

用户能尽快得到核心功能，第一个增量往往是实现基本需求的核心产品

使软件开发可以较好地适应变化

不断地看到系统功能增量，从而降低开发风险

短时间跨度有助于减少变更带来的风险

c. 缺点：

增量持续集成到系统中，要求设计具有良好的开放性

对已有的部分构成不稳定因素

后期的增量可能要求修改前面的实现

4.3 敏捷开发模型

上世纪90年代兴起的一种新型、应对快速变化的需求的一种软件开发方法

强调协作、沟通、频繁交付

更注重作为软件开发中人的作用

系统具有较高的关键性、可靠性、安全性方面的要求，则可能不完全适合

团队和环境设施满足成员间快速沟通之需要

适用于小的团队和项目

被有些人认为无计划性和纪律性的方法，实际上更注重实际和效率的方法

4.4 其他模型

原型模型

V型模型

螺旋模型

4.5 选择合适的模型

根据项目特征选择

根据项目需求选择