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.c | epoll创建,注册,杀出,事件监听 |
HTTP 模块 | mk_http.c | HTTP协议处理 |
线程管理模块 | 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 选择合适的模型
根据项目特征选择
根据项目需求选择