网络兼职招聘系统
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
合商业策略的产品等
1.风险管理的内容
• 风险管理的内容
风险管理
风险评估 风险控制
风险识别 风险分析 风险优先级 风险管理计划 风险化解 风险监控
• 风险评估
• 风险识别—提出一个潜在破坏项目进度的风险列表。评价风险变
成现实的可能性或概率。
• 风险分析—评估每一个风险出现的可能性及其变成现实时所造成
董事会
人力资源部
总经理
财务部
副总经理
总工程师（副总）
市场部
销售部
软件开发部
软件测试部
质量管理部
项目组1
项目组N
软件企业的职位概况
立项阶段 项目经理
需求分析阶段
构成阶段 系统架构设计师
需
系
求
统
分
分
析
析
师
师
软件架构设计师 数据库设计师 软件界面设计师
网络架构设计师
项目经理 结束阶段
实现阶段
网络 工程师
网络兼职招聘系统
大纲
• 可行性分析报告 • 需求规格说明书 • 总体设计报告 • 详细设计说明书 • 总结
一、可行性分析报告
• 软件项目管理的任务
• 制定项目计划和工程进度安排 • 监督和检查项目实施过程 • 保证工程满足要求的质量标准 • 分析确定并排除风险 • 在规定的期限和预算成本内完成项目
织方式固有的不切实际的地方：
• 主程序员既是高级程序员又是优秀管理者，但现实中这种人
才很难见到。
• 后备程序员更难找。人们希望后备程序员像主程序员一样优
秀，但他们必须坐在“替补席”上，拿着较低的工资等待接 替主程序员。
• 编程秘书也很难找。专业的软件技术人员一般都厌烦日常的
事务性工作。
• 现代程序员组
• 一个项目里程碑就是一个软件过程活动的终结。在每个里程碑都
应该有一个正式的可以提交给管理层的输出结果。
• 里程碑应代表该项目的一个特定的逻辑意义上的阶段的终结。 • 里程碑的两个必要特征：
与软件开发进展相关联； 在完成时必须非常明显。
• 基线
• 基线其实是一些重要的里程碑（产物） • 交付产品通过正式评审后才能成为基线 • 基线一旦建立后，任何更改都要受到控制（基线之前的更改可以
产品运行
正确性、健壮性、效率、完整性、可用性、风险
• 从管理角度对软件质量进行度量的McCall软件质量模型 • 上述模型反映了用户在使用软件产品时的三种不同的倾向：产品运
行、产品修改和产品转移。
(2)软件质量的属性
• 产品运行时的属性
• 正确性
系统满足规格说明和用户目标的程度，在预定环境下能正确完成预期
添加用户
删除用户
登录/注册
wenku.baidu.com
招聘信息
用发户布信信息 息管理
发布招聘信息
发布求职信息
开始
• 主要类的实现
初始化连接和命令对象属性
《实现类》用户
-name:String -LimitsOfAuthority:int -password:String
添加参数 打开连接 执行命令对象判断用户名和密码是否匹配
• 主程序员组
• 主程序员组使用经验丰富、技术好、能力强的程序员作为主程序
员。同时，利用人和计算机在事务性工作方面给主程序员提供充 分支持，而且保证所有通讯都通过一两个人进行。
• 后备程序员
• 后备程序员也应该技术熟练而且富于经验，他协助主
程序员工作并且在必要时(主程序员生病、出差或跳槽 )接替主程序员的工作。所以后备程序员必须和主程序 一样优秀，一样深入了解项目。
软件开发工程师 编码程序员
质量保障 工程师
软件测试 工程师
产品发布工程师
五、总结
• 定义
• “风险”是指对项目有利或不利的不确定因素 。
• 分类
• 按照风险的影响范围分类
项目风险：预算、进度、人力、资源、客户及需
求等方面
技术风险：设计、实现、接口、验证和维护等方
面
商业风险：无人真正需要的“优秀产品”，不符
方的首要考虑。
• 例如，CMM认证和ISO9000认证
3.2 软件质量模型
• 软件质量与软件的内部特性及其组合有关。要度量软
件质量，就应根据这些内部特性（即软件属性）建立 起软件度量模型，进而构建软件质量度量体系。
(1)软件质量模型
可理解性 可维护性 灵活性 可测试性
产品修改 产品转移
可移植性 可重用性 互运行性 轻便性
• 特点 将“主程序员组”中的主程序员的职则划为两个人来承担
： 一个技术负责人，负责小组的技术活动 一个行政负责人，负责所有的非技术的决策活动
现代程序员组
❖现代程序员组
大型项目的技术管理组织结构
❖现代程序员组
包含分散决策的组织方式
• 优点 将管理和行政分开，有助于调动组员的积极性 行政组长和技术组长分工明确 避免了“主程序员组”中，全才主程序员难找的问题
8 15
(4) 0 3 (0)
15 6 (0)
6 12
(5) 0 10 21
23 (1)
4
6 (0)
6
12 0
61
2
1 21 9 15 (5)
20
2 (0)
11 23 23
(11) 7 12 (6)
18
三、总体设计报告
• 背景
• 质量是产品的生命线，不论任何产品，质量都是极端重要的。 • 软件产品开发周期长，需耗费巨大的人力、物力，更必须特别注意
的产品准许出厂，不合格的产品作为次品处理。
• 全面质量管理
• 运用质量管理的科学理论、技术、方法，建立起贯穿于产品质
量形成全过程的质量保证体系，使企业全体职工树立质量观点 ，提高工作质量，经济地生产用户满意的产品。
• 它要求从影响软件产品质量的各个方面加强对软件质量的全面
管理。
• 权威认证
• 认证已经成为一个组织资质的证明，也成为买方选择合格供应
我们的定位 我们的使命 我们的愿景
实现虚拟的网上兼职招聘系统 确定应该如何具体的实现所要求的系统 人才潜力的发挥和知识的传播
• 三大模块的联系
企业
求职者
招聘网
三位一体 相互支撑
• 程序界面结构
网上招聘兼职系统
游客
会员
客户端
个人用户注册
协 议
用户中心
服务器端
用户登录 查看招聘/求职信息
企业注册
数据库
的后果，判定风险的级别。
• 风险优先级—按风险影响大小排出一个风险优先级，这个风险列
表将作为风险控制的基础。
• 评估过程
评估风险后果 建立风险表
• 风险控制
点是直观简明、容易掌握和绘制
线段的水平线表示完成任务所需的时间 • 优点
表明了各任务的计划进度和当前进度，能动态反应项目的进展
情况。
• 缺点 难以反映多个任务之间的复杂逻辑关系。
日期
• 甘特图实例
进度条
任务列表
• PERT图
• 对于某事件，箭头进入表示此作业结束，箭头离开表示此作业的开
始；
没有严格控制）
• 学生例：小考、中考、高考（成绩经主管部门评审后，变更受控
）
重要的检查点是里程碑，重要的需要客户确认的里程 碑，就是基线。在我们实际的项目中，周例会是检查点的 表现形式，高层的阶段汇报会是基线的表现形式
2.项目进度
• 项目进度
• 管理人员必须估算完成各项活动所需要的时间和资源，并按照一定
• 实线箭头表示具体存在的作业； • 虚线箭头表示虚拟作业，只为了表示作业之间的依赖关系。
刮3 5 刮4
1
刮2 刮1 2
3 刷2
刷3 8 刷4
6
清3 10
清4 11
刷1 4
清2 9
清1 7
EET 持续时间
(机动时间)
LET
1
事件号
02 0 (0)
2
36
46
2
(0) (0) 0
5
2 (3)
8 11
4 (3)
功能的程度。
• 健壮性
在硬件发生故障、输入数据无效、操作错误等意外环境下，系统能做
出适当响应的程度。
• 效率
为了完成预定功能，系统需要的计算资源的多少。
• 完整性
对未经授权的软件使用请求或数据访问的企图，系统能够控制（或禁
止）的程度。
• 可用性
系统在完成预定功能时令用户满意的程度。
• 风险
按预定的成本和进度开发系统，并且使得用户满意的概率
的顺序把他们紧密组织起来。
• 项目进度安排通常是将复杂的整体项目分解成许多可以准确描述、
度量、可独立操作的相对简单的任务，然后安排这些任务的执行顺 序，确定每个任务的完成期限、开始时间和结束时间。
• 需要考虑的主要问题
• 生存周期各个阶段工作量的划分 • 工程进展如何度量 • 项目的关键路径 • 各个阶段任务完成标志 • 如何自然过渡到下一阶段的任务等。 • 项目可以支配的人力及资源
项目 可交付的成果 可交付的子成果 最低层的可交付子成果
工作任务
• 工作分解结构的一个例子
东软三期公寓项目 （1000）
主体工程 （1100）
内外装修 （1200）
配套设施 （1300）
物业管理 （1400）
地基
框架
（1110） （1120）
给排水
电气
煤气
（1310） （1320） （1330）
供水系统 排水系统 （1311） （1312）
时，需要的工作量大小。
• 可重用性
在其他应用中该软件可以被使用的程度或范
围。
• 互运行性
把该软件系统和另一软件系统结合起来所需
要的工作量大小。
• 轻便性
允许软件能够从一台计算机很容易地传输到
另一台需要运行的计算机上的能力。
四、详细设计说明书
系统定位
使命
愿景
对利益相关者的承诺
我们的定位
我们要做什么 我们的目标是什么
• 缺点 有时行政组长和技术组长的管理权限界限不明
• 选择软件工程小组结构时应考虑的7个因素 • 待解决问题的困难程度 • 要开发程序的规模 • 小组成员在一起工作的时间 • 问题能够被模块化的程度 • 对待开发的系统的质量和可靠性的要求 • 交付日期的严格程度 • 项目要求的社交(通信)程度
• 软件企业的组织架构
• 主程序员
• 主程序员既是成功的管理人员，又是经验丰富、技术
好、能力强的高级程序员，负责体系结构设计和关键 部分的详细设计，并且负责指导其他程序员完成详细 设计和编码工作
• 编程秘书
• 编程秘书负责完成与项目有关的全部事务性工作，如
，维护项目资料库和项目文档，编译、连接、执行源 程序和测试用例。
• 虽然主程序员组有很多优点，但是，我们还应看到这种组
N
是否发生异常
Y
关闭连接和命令对象 返回判断值
抛出异常
结束
程序（标识符）设计说明
程序 描述
限制 条件
整体结 构
功能
注释
程序
设计
性能
存储分 配
是关键
A、客户端窗体： 尽量友好的设计，让用户 尽可能地关注信息的内容 主体。 B、服务器端设计： 该窗体在设计上尽量的符 合人们的使用习惯，并且 在出现非法操作的情况下， 有相应的提示信息输出。
2.2 进度管理工具
• 进度管理工具
• 项目进度通常用一系列的图表表示，通过这些图表可以了解
任务分解、活动依赖关系和人员分配情况。
• 常用的项目进度表示法
• 甘特图（Gantt） • 活动网络图（PERT）
• 常用软件管理工具软件
• MS-Project
• 甘特图
• 特点 形象地描绘了任务的分解，及每个作业的开始和结束时间，优
进度
质量 风险 成本
1.常用概念
• 检查点 （Check Point）
• 在规定的时间间隔内对项目进行的检查与复审工作 • 频度不能太高或太低，一般一周一次 • 目的
比较实际进展与计划进度的差异，并对项目进行调整 • 如：周报、周例会 • 学生例：每周的班会、测验、月考等
• 项目的里程碑（milestone）
2.1 工作分解
• 工作分解的原因
• 可以根据细分的工作包之间的逻辑关系来实施项目 • 让项目组各个成员明确自己的职责，减少繁琐的协调 • 每个组员可以清晰地理解任务的性质和各自的目标 • 准确把握项目所需要的技术、人力、资金、风险，为项目计划提供
基线
• 分解的方法
• 自上而下的分解 • 工作任务，即工作包，是项目中最小的可控制单元
保证产品质量。
• 软件质量定义
• 软件与明确的和隐含定义的需求相一致的程度
与明确描述的功能和性能需求相一致的程度 与文档中明确描述的开发标准相一致的程度 与任何专业开发的软件产品都应该具有的隐含
特征相一致的程度
坚持进行阶段评审
3.1 软件质量管理种类
• 事后检验
• 事后检验的方式是在产品生产的最后环节进行质量检查，合格
• 产品修改时的质量属性
• 可理解性 理解和使用软件的容易程度。
• 可维护性 • 诊断和改正在运行现场发现的错误所需要的工作量大小。 • 适应性
修改或改进正在运行的系统需要的工作量大小 • 可测试性
软件容易测试的程度。
• 产品转移时的质量属性
• 可移植性
把软件从一软硬件环境移植到另一配置环境
2.1 工作分解
• 工作分解和进度管理
• 正常情况，各活动应至少持续1周； • 对所有活动安排一个最高的时间限制
（8～10周左右），如一项活动持续 时间超过限制，就应该再次细分；
• 估算进度时，管理者不能想当然认为
项目的每个阶段都不会出问题；
• 除时间外，还必须估算完成每项任务
所需的资源：人力资源和其他可能的 资源。
1.风险管理的内容
• 风险管理的内容
风险管理
风险评估 风险控制
风险识别 风险分析 风险优先级 风险管理计划 风险化解 风险监控
• 风险评估
• 风险识别—提出一个潜在破坏项目进度的风险列表。评价风险变
成现实的可能性或概率。
• 风险分析—评估每一个风险出现的可能性及其变成现实时所造成
董事会
人力资源部
总经理
财务部
副总经理
总工程师（副总）
市场部
销售部
软件开发部
软件测试部
质量管理部
项目组1
项目组N
软件企业的职位概况
立项阶段 项目经理
需求分析阶段
构成阶段 系统架构设计师
需
系
求
统
分
分
析
析
师
师
软件架构设计师 数据库设计师 软件界面设计师
网络架构设计师
项目经理 结束阶段
实现阶段
网络 工程师
网络兼职招聘系统
大纲
• 可行性分析报告 • 需求规格说明书 • 总体设计报告 • 详细设计说明书 • 总结
一、可行性分析报告
• 软件项目管理的任务
• 制定项目计划和工程进度安排 • 监督和检查项目实施过程 • 保证工程满足要求的质量标准 • 分析确定并排除风险 • 在规定的期限和预算成本内完成项目
织方式固有的不切实际的地方：
• 主程序员既是高级程序员又是优秀管理者，但现实中这种人
才很难见到。
• 后备程序员更难找。人们希望后备程序员像主程序员一样优
秀，但他们必须坐在“替补席”上，拿着较低的工资等待接 替主程序员。
• 编程秘书也很难找。专业的软件技术人员一般都厌烦日常的
事务性工作。
• 现代程序员组
• 一个项目里程碑就是一个软件过程活动的终结。在每个里程碑都
应该有一个正式的可以提交给管理层的输出结果。
• 里程碑应代表该项目的一个特定的逻辑意义上的阶段的终结。 • 里程碑的两个必要特征：
与软件开发进展相关联； 在完成时必须非常明显。
• 基线
• 基线其实是一些重要的里程碑（产物） • 交付产品通过正式评审后才能成为基线 • 基线一旦建立后，任何更改都要受到控制（基线之前的更改可以
产品运行
正确性、健壮性、效率、完整性、可用性、风险
• 从管理角度对软件质量进行度量的McCall软件质量模型 • 上述模型反映了用户在使用软件产品时的三种不同的倾向：产品运
行、产品修改和产品转移。
(2)软件质量的属性
• 产品运行时的属性
• 正确性
系统满足规格说明和用户目标的程度，在预定环境下能正确完成预期
添加用户
删除用户
登录/注册
wenku.baidu.com
招聘信息
用发户布信信息 息管理
发布招聘信息
发布求职信息
开始
• 主要类的实现
初始化连接和命令对象属性
《实现类》用户
-name:String -LimitsOfAuthority:int -password:String
添加参数 打开连接 执行命令对象判断用户名和密码是否匹配
• 主程序员组
• 主程序员组使用经验丰富、技术好、能力强的程序员作为主程序
员。同时，利用人和计算机在事务性工作方面给主程序员提供充 分支持，而且保证所有通讯都通过一两个人进行。
• 后备程序员
• 后备程序员也应该技术熟练而且富于经验，他协助主
程序员工作并且在必要时(主程序员生病、出差或跳槽 )接替主程序员的工作。所以后备程序员必须和主程序 一样优秀，一样深入了解项目。
软件开发工程师 编码程序员
质量保障 工程师
软件测试 工程师
产品发布工程师
五、总结
• 定义
• “风险”是指对项目有利或不利的不确定因素 。
• 分类
• 按照风险的影响范围分类
项目风险：预算、进度、人力、资源、客户及需
求等方面
技术风险：设计、实现、接口、验证和维护等方
面
商业风险：无人真正需要的“优秀产品”，不符
方的首要考虑。
• 例如，CMM认证和ISO9000认证
3.2 软件质量模型
• 软件质量与软件的内部特性及其组合有关。要度量软
件质量，就应根据这些内部特性（即软件属性）建立 起软件度量模型，进而构建软件质量度量体系。
(1)软件质量模型
可理解性 可维护性 灵活性 可测试性
产品修改 产品转移
可移植性 可重用性 互运行性 轻便性
• 特点 将“主程序员组”中的主程序员的职则划为两个人来承担
： 一个技术负责人，负责小组的技术活动 一个行政负责人，负责所有的非技术的决策活动
现代程序员组
❖现代程序员组
大型项目的技术管理组织结构
❖现代程序员组
包含分散决策的组织方式
• 优点 将管理和行政分开，有助于调动组员的积极性 行政组长和技术组长分工明确 避免了“主程序员组”中，全才主程序员难找的问题
8 15
(4) 0 3 (0)
15 6 (0)
6 12
(5) 0 10 21
23 (1)
4
6 (0)
6
12 0
61
2
1 21 9 15 (5)
20
2 (0)
11 23 23
(11) 7 12 (6)
18
三、总体设计报告
• 背景
• 质量是产品的生命线，不论任何产品，质量都是极端重要的。 • 软件产品开发周期长，需耗费巨大的人力、物力，更必须特别注意
的产品准许出厂，不合格的产品作为次品处理。
• 全面质量管理
• 运用质量管理的科学理论、技术、方法，建立起贯穿于产品质
量形成全过程的质量保证体系，使企业全体职工树立质量观点 ，提高工作质量，经济地生产用户满意的产品。
• 它要求从影响软件产品质量的各个方面加强对软件质量的全面
管理。
• 权威认证
• 认证已经成为一个组织资质的证明，也成为买方选择合格供应
我们的定位 我们的使命 我们的愿景
实现虚拟的网上兼职招聘系统 确定应该如何具体的实现所要求的系统 人才潜力的发挥和知识的传播
• 三大模块的联系
企业
求职者
招聘网
三位一体 相互支撑
• 程序界面结构
网上招聘兼职系统
游客
会员
客户端
个人用户注册
协 议
用户中心
服务器端
用户登录 查看招聘/求职信息
企业注册
数据库
的后果，判定风险的级别。
• 风险优先级—按风险影响大小排出一个风险优先级，这个风险列
表将作为风险控制的基础。
• 评估过程
评估风险后果 建立风险表
• 风险控制
点是直观简明、容易掌握和绘制
线段的水平线表示完成任务所需的时间 • 优点
表明了各任务的计划进度和当前进度，能动态反应项目的进展
情况。
• 缺点 难以反映多个任务之间的复杂逻辑关系。
日期
• 甘特图实例
进度条
任务列表
• PERT图
• 对于某事件，箭头进入表示此作业结束，箭头离开表示此作业的开
始；
没有严格控制）
• 学生例：小考、中考、高考（成绩经主管部门评审后，变更受控
）
重要的检查点是里程碑，重要的需要客户确认的里程 碑，就是基线。在我们实际的项目中，周例会是检查点的 表现形式，高层的阶段汇报会是基线的表现形式
2.项目进度
• 项目进度
• 管理人员必须估算完成各项活动所需要的时间和资源，并按照一定
• 实线箭头表示具体存在的作业； • 虚线箭头表示虚拟作业，只为了表示作业之间的依赖关系。
刮3 5 刮4
1
刮2 刮1 2
3 刷2
刷3 8 刷4
6
清3 10
清4 11
刷1 4
清2 9
清1 7
EET 持续时间
(机动时间)
LET
1
事件号
02 0 (0)
2
36
46
2
(0) (0) 0
5
2 (3)
8 11
4 (3)
功能的程度。
• 健壮性
在硬件发生故障、输入数据无效、操作错误等意外环境下，系统能做
出适当响应的程度。
• 效率
为了完成预定功能，系统需要的计算资源的多少。
• 完整性
对未经授权的软件使用请求或数据访问的企图，系统能够控制（或禁
止）的程度。
• 可用性
系统在完成预定功能时令用户满意的程度。
• 风险
按预定的成本和进度开发系统，并且使得用户满意的概率
的顺序把他们紧密组织起来。
• 项目进度安排通常是将复杂的整体项目分解成许多可以准确描述、
度量、可独立操作的相对简单的任务，然后安排这些任务的执行顺 序，确定每个任务的完成期限、开始时间和结束时间。
• 需要考虑的主要问题
• 生存周期各个阶段工作量的划分 • 工程进展如何度量 • 项目的关键路径 • 各个阶段任务完成标志 • 如何自然过渡到下一阶段的任务等。 • 项目可以支配的人力及资源
项目 可交付的成果 可交付的子成果 最低层的可交付子成果
工作任务
• 工作分解结构的一个例子
东软三期公寓项目 （1000）
主体工程 （1100）
内外装修 （1200）
配套设施 （1300）
物业管理 （1400）
地基
框架
（1110） （1120）
给排水
电气
煤气
（1310） （1320） （1330）
供水系统 排水系统 （1311） （1312）
时，需要的工作量大小。
• 可重用性
在其他应用中该软件可以被使用的程度或范
围。
• 互运行性
把该软件系统和另一软件系统结合起来所需
要的工作量大小。
• 轻便性
允许软件能够从一台计算机很容易地传输到
另一台需要运行的计算机上的能力。
四、详细设计说明书
系统定位
使命
愿景
对利益相关者的承诺
我们的定位
我们要做什么 我们的目标是什么
• 缺点 有时行政组长和技术组长的管理权限界限不明
• 选择软件工程小组结构时应考虑的7个因素 • 待解决问题的困难程度 • 要开发程序的规模 • 小组成员在一起工作的时间 • 问题能够被模块化的程度 • 对待开发的系统的质量和可靠性的要求 • 交付日期的严格程度 • 项目要求的社交(通信)程度
• 软件企业的组织架构
• 主程序员
• 主程序员既是成功的管理人员，又是经验丰富、技术
好、能力强的高级程序员，负责体系结构设计和关键 部分的详细设计，并且负责指导其他程序员完成详细 设计和编码工作
• 编程秘书
• 编程秘书负责完成与项目有关的全部事务性工作，如
，维护项目资料库和项目文档，编译、连接、执行源 程序和测试用例。
• 虽然主程序员组有很多优点，但是，我们还应看到这种组
N
是否发生异常
Y
关闭连接和命令对象 返回判断值
抛出异常
结束
程序（标识符）设计说明
程序 描述
限制 条件
整体结 构
功能
注释
程序
设计
性能
存储分 配
是关键
A、客户端窗体： 尽量友好的设计，让用户 尽可能地关注信息的内容 主体。 B、服务器端设计： 该窗体在设计上尽量的符 合人们的使用习惯，并且 在出现非法操作的情况下， 有相应的提示信息输出。
2.2 进度管理工具
• 进度管理工具
• 项目进度通常用一系列的图表表示，通过这些图表可以了解
任务分解、活动依赖关系和人员分配情况。
• 常用的项目进度表示法
• 甘特图（Gantt） • 活动网络图（PERT）
• 常用软件管理工具软件
• MS-Project
• 甘特图
• 特点 形象地描绘了任务的分解，及每个作业的开始和结束时间，优
进度
质量 风险 成本
1.常用概念
• 检查点 （Check Point）
• 在规定的时间间隔内对项目进行的检查与复审工作 • 频度不能太高或太低，一般一周一次 • 目的
比较实际进展与计划进度的差异，并对项目进行调整 • 如：周报、周例会 • 学生例：每周的班会、测验、月考等
• 项目的里程碑（milestone）
2.1 工作分解
• 工作分解的原因
• 可以根据细分的工作包之间的逻辑关系来实施项目 • 让项目组各个成员明确自己的职责，减少繁琐的协调 • 每个组员可以清晰地理解任务的性质和各自的目标 • 准确把握项目所需要的技术、人力、资金、风险，为项目计划提供
基线
• 分解的方法
• 自上而下的分解 • 工作任务，即工作包，是项目中最小的可控制单元
保证产品质量。
• 软件质量定义
• 软件与明确的和隐含定义的需求相一致的程度
与明确描述的功能和性能需求相一致的程度 与文档中明确描述的开发标准相一致的程度 与任何专业开发的软件产品都应该具有的隐含
特征相一致的程度
坚持进行阶段评审
3.1 软件质量管理种类
• 事后检验
• 事后检验的方式是在产品生产的最后环节进行质量检查，合格
• 产品修改时的质量属性
• 可理解性 理解和使用软件的容易程度。
• 可维护性 • 诊断和改正在运行现场发现的错误所需要的工作量大小。 • 适应性
修改或改进正在运行的系统需要的工作量大小 • 可测试性
软件容易测试的程度。
• 产品转移时的质量属性
• 可移植性
把软件从一软硬件环境移植到另一配置环境
2.1 工作分解
• 工作分解和进度管理
• 正常情况，各活动应至少持续1周； • 对所有活动安排一个最高的时间限制
（8～10周左右），如一项活动持续 时间超过限制，就应该再次细分；
• 估算进度时，管理者不能想当然认为
项目的每个阶段都不会出问题；
• 除时间外，还必须估算完成每项任务
所需的资源：人力资源和其他可能的 资源。