软件项目管理大作业Word格式.docx
《软件项目管理大作业Word格式.docx》由会员分享，可在线阅读，更多相关《软件项目管理大作业Word格式.docx（27页珍藏版）》请在冰点文库上搜索。
主要为保证整个项目能够按时，保质，保量的完成，每个人在项目开发中都能够发挥自己的作用，使整个软件开发过程顺利，平稳，有序的进行，提供有效的进度参考。
1.2范围
本文档适用于《储蓄业务软件》这一软件项目。
1.3项目概述
本项目要开发一个银行系统，系统一共分为储蓄业务、贷款业务、外汇交易、网上银行、信用卡业务和系统管理六个子系统。
本团队负责其中的有关储蓄业务
的子系统。
通过团队合作开发整个子系统，使团队成员获得软件工程开发的实际训练。
本系统采用目前主流的B/S开发架构，将与整个银行系统一起发布。
不单独发布。
交付的产品包括可执行的文件、源代码、技术文档与用户使用手册等。
本系统的开发过程中的主要工作是子系统需求分析、系统总体设计、子系统源代码开发、子系统测试、交付团长进行最后的集成、整个系统的测试。
关键里程碑是制定项目管理计划书、制定需求设计规格说明书初稿、制定系统设计报告的初稿、进行子系统运行情况的检查与测试、进行系统集成后的运行情况的检查与测试。
项目所需工具是个人电脑和开发工具。
进度为11周，工程量为3人/天。
1.4项目范围说明
（1）提交文档：
项目管理计划、需求规格说明，设计报告、测试报告、用户使用手册和项目个人总结。
其中项目总结为每人一份，每个小组所有成员的总结装订在一起；
其余文档每组提交一份。
每个团队可将各小组的文档综合到一起，各小组也可自行分开提交，具体方式由团队内部协商确定。
所有文档需要提交电子版和打印稿。
（2）源程序检查：
一共两次。
第一次检查每个小组的子系统运行情况。
第二次检查每个团队内六个小组集成后完整的银行系统运行情况，检查完成后需要提交程序源文件和可执行的系统。
程序检查安排在上机时间进行。
1.5项目生存期：
该项目的特点
此项目需求比较模糊，在开发过程中极有可能发生需求的变更，即使在开发结束后，也常常需要功能上的扩充，
面向的用户群体相当广泛，不同的用户都有可能提出该系统针对某一类群体的改进意见和要求。
项目组内部对此系统的认识也不够统一，对大量辅助功能及新增功能有不同的看法，需要在基本的核心功能完成之后，随着项目的进行，由项目经理进一步收集用户及成员的想法意见进行决策。
用户及成员都需要在短时间内得到一个系统最初的版本，对其进行评价并在后续的开发上对其定位，并得出更多明确的需求。
在项目本身的开发上，为了使系统锦上添花，会用到许多开发人员也并不熟悉的技术，这可能需要开发人员进一步的学习后，再对系统进行改进。
针对该项目的这些特点，权衡各个生存期的适用条件，该项目组选用了增量式模型来开发此系统。
增量式模型的特点如下：
可以避免一次性投资太多带来的风险，将主要的功能或者风险大的功能首先实现，然后逐步完善，保证投入的有效性。
可以更快地开发出可以操作的系统。
可以减少开发过程中用户需求的变更。
一些增量可能需要重新开发（如果早期开发的需求不稳定或者不完整）。
可见，增量式模型充分迎合了该项目的特点，并且提供了多种途径解决项目中的一些难题。
生存期中各阶段的描述如下：
阶段
项目规划阶段
目标
根据合同和初步的需求分析，确定项目的规模、时间计划和资源需求
输入
合同文本，SOW
过程
项目规划，计划确认
输出
项目计划
需求分析阶段
确定客户的需求
项目计划，SOW
需求获取，需求分析，需求控制
原型系统，需求规格
设计阶段
总体系统结构设计
总体设计
系统设计说明书，数据库结构定义
增量1实现
实现系统的通用功能
详细设计，编码，代码走查，代码评审，单元测试
详细设计说明书，源代码，可运行版本--1
增量2实现
实现系统的用户管理功能
详细设计说明书，源代码，可运行版本--2
增量3实现
实现系统的文章管理功能
详细设计说明书，源代码，可运行版本--3
增量4实现
实现系统的好友管理功能
详细设计说明书，源代码，可运行版本--4
增量5实现
实现系统的在线聊天功能
详细设计说明书，源代码，可运行版本--5
集成测试
通过集成环境下的软件测试
测试计划，测试用例
集成测试，系统测试
系统软件包，测试报告，产品说明书
产品提交
产品可投入使用
系统软件包
验收报告
1.6软件项目计划书的演化
软件项目计划书在第三周周末前经由小组讨论、共同撰写、汇总整合三步骤形成初稿，第四周以后根据项目的进展可以对其进行修改，需要有组员提出修改意，在全体会上讨论通过，并由组长整理修改意见并作出相应的修改。
其余组员同步获得更新稿。
项目计划组成结构图：
计划名称
对应部分
简要描述
范围计划
项目人物范围
确定项目的范围，为制定其他计划打下基础。
范围管理是项目实施的依据和变更的输入，另外还包括对可交付成果落实到个人上的分解，即项目分解结构（WBS），通过WBS清楚明确地组织并定义了整个项目的范围，以及该项目的参与者各自的分工。
成本计划
项目估算
成本计划是对完成项目所需费用的估计和计划，是项目计划中的一个重要组成部分。
软件成本估算是成本管理的核心，是预测开发一个软件系统所需要的总工作量的过程。
软件成本估算以从软件计、需求分析、设计、编码、单元测试、集成测试到接受测试等这些过程所花费的代价为依据，对完成项目所需要的所有费用进行估算。
进度计划
项目时间计划
进度计划是从时间的角度对项目进行规划。
时间是一种特殊的资源，以其单向性、不可重复性、不可替代性而有别于其他资源，因此进度计划也是项目计划中最难、最重要、最核心的部分。
在进度计划中，首先根据任务分解的结果（WBS）再进一步分解出主要的任务（活动），确立任务（活动）之间的关联关系，然后估算出每个任务（活动）需要的资源、历时，最后编制出完整的进度计划（如进度表）。
风险计划
项目风险分析
风险计划是在项目进行过程中不断对风险进行识别、评估、制定策略、监控风险的过程，它是项目管理中最容易被忽略而且最难以管理的环节。
通过风险识别、风险分析和风险评价去认识项目的风险，并以此为基础合理的使用各种风险应对措施，管理方法、技术和手段对项目的风险进行有效的控制，妥善处理风险事件造成的不利后果，以最小成本保证项目总体目标的实现。
人力资源计划
项目组织结构
人是软件项目中最重要的因素，因此软件项目人力资源管理计划也是项目计划中根本的一项计划。
人力资源管理是保证参加项目的人员能够被最有效使用所需要的过程，是对项目组织所储备的人力资源开展的一系列科学规划、开发培训、合理调配、适当激励等方面的管理工作，是项目组织各方面人员的主观能动性得到充分发挥，做到人尽其才，事得其人、人事相宜，同时保持项目组织高度的团结性和战斗力，从而成功地实现项目组织的既定目标。
关键资源计划
关键资源计划是对项目所需关键资源根据生存期阶段所做的计划。
关键资源包括引起竞争的人力和设备资源。
设施工具计划
实施工具计划是对项目开发所需的设备和支持工具所做的计划。
质量管理计划
质量管理计划主要是确定项目应达到的质量标准，以及决定如何满足质量标准的计划安排和方法；
依据公司的质量方针、产品描述以及质量标准和规则等制定出实施策略，其内容全面反映用户的需求，为质量小组成员有效工作提供指南，也为项目相关人员了解在项目进行中如何实施质量保证和控制提供依据。
合适的质量标准是质量计划的关键。
配置管理计划
软件配置管理计划用来确定软件配置管理的解决方案，软件配置管理的解决方案涉及面很广，将影响软件软件开发环境、软件过程模型、配置管理系统的使用者、软件产品的质量和用户的组织机构。
该计划由配置管理者负责制定，它是软件配置管理规划过程的产品，并在整个软件项目开发过程中作为配置管理活动的依据进行使用和维护。
沟通计划
保证项目成功必须进行沟通，为了有效的沟通，需要创建一个沟通计划。
沟通计划决定项目相关人的信息和沟通需求：
谁需要什么信息、什么时候需要、怎样获得、选择的沟通模式——什么时候采用书面沟通和什么时候采用口头沟通、什么时候使用非正式的备忘录和什么时候使用正式的报告等等。
2项目组织管理
2.1过程模型
2.2团队的分工与合作
成员
角色
职责
张三
组长、主程序员
领导项目团队、执行和管理团队、负责软件的交付工作。
同时作为主程序员还要负责软件设计和编写代码。
并撰写软件设计报告。
李四
程序员、文档维护员
整理需求分析并撰写需求分析报告、维护并及时修改和发布已更新技术文档。
作为程序员还要参与软件设计与代码开发。
王五
软件测试员、秘书、美工
主要负责软件代码测试和用户测试、并撰写测试文档初稿并对界面美工付主要责任、作为秘书要主持每周的讨论会以及团内沟通工作。
2．管理过程
3.1管理目标及优先级
基本管理原则：
每位成员既是积极的建言者，又是负责的合作者，同时也是决策的制定者。
决策应在充分的讨论基础上由大家共同做出，一旦决策做出就必须被及时有效的执行。
禁止再有异议。
目标1：
按时按量完成项目的基本功能，按时发布产品及文档，这是本团队的最高目标。
目标2：
遵循规范化的项目运作标准，文档严谨完整，代码注释充分，便于后续维护，这是第二目标。
目标3：
产品运行稳定，界面友好，用户易操作，尽量从用户的角度去看问题，并提出解决问题的方案。
目标4：
注重团队建设，成员分工合理，团队成员合作默契，气氛融洽。
每周的讨论会积极建言。
在开发过程中积极协作。
目标5：
项目设计和开发上尽量有创新，有亮点。
3.2项目风险管理
3.2.1项目风险管理的目的
风险是指在项目进行过程中可能发生的事件，这些事件将会对项目按预期时间，资源和预算完成产生重大影响。
风险管理的目标是在潜在问题发作以前就标志它们，这样就可以在生命周期中可以适时地计划和启用风险处理活动。
本次开发过程中存在的风险及规避方法如下表：
风险类型
存在风险
规避方法
进度风险
由于时间紧张导致项目最后无法按期完成。
充分考虑各种潜在因素，适当留有余地；
任务分解要详细，便于考核；
在执行过程中，应该强调项目按照进度执行的重要项，再考虑任何问题时，都要经保持进度作为先决条件；
同时，合理利用赶工期及快速跟进等方法，充分利用资源。
如果出现必须延期的情况，组长需及时同银行相关负责人沟通，并申请延期时间。
系统没有足够的测试时间
持续地监控，项目进度控制随着项目的进行而不断进行的，保证每个环节都有足够的时间。
技术风险
开发软件结构体系存在问题，使完成的软件产品未能实现项目预定目标
选用正版软件开发
对开发软件的掌握不够深入，造成开发出的产品性能以及质量低劣。
提前制定好两周的学习计划，各组员要对开发工具vs2005+sqlsever2005，css，photoshop及flash进行快速的学习。
尽快掌握其中的要点。
同时在软件的设计上尽可能降低难度使项目最后能成功完成。
质量风险
质量不符合用户要求
经常和用户交流工作成果、品牌管理采用符合要求的开发流程、认真组织对产出物的检查和评审、计划和组织严格的独立测试等。
软件项目开发和实施过程，所必须用到的管理工具、开发工具、测试工具未能及时到位
在项目的启动阶段就落实好各项工具的来源或可能的替代工具，在这些工具需要使用之前跟踪并落实工具的到位事宜。
在进行项目开发之前先设计和搭建出系统的基础架构并进行性能测试，确保架构符合性能指标后再进行后续工作。
人力资源风险
组员成员因意外无法参加设计
事先同用户商量解决办法
3.2.2风险的控制
1．控制方法
（1）风险管理计划
重点是制定一个计划，以处理在排位靠前的高风险项。
风险管理计划每阶段/迭代重新评估一次。
风险监控时选取风险管理计划中没有关闭的前10大风险进行监控即可。
每阶段/迭代启动时，选取“风险管理计划”中处于“监控”状态的前10大风险，用于本阶段/迭代的周例会上进行跟踪和监控（注意：
周例会时只监控阶段/迭代启动时监控的前10大风险）。
（2）风险的化解
避免风险（即：
不要做冒险的活动）
将风险从系统的一部分转移到另一部分（可能对于系统的其他部分此风险不会发生或发生时影响不大）
购买关于风险的信息（例如：
做实验性项目，请咨询专家等）
消除风险的根源
接受风险（如果风险后果较小，而处理它可能代价很大，滚动处理可能是最有效的途径）
发布风险（将风险发布给相关涉众，如：
管理者、市场人员、客户{特别注意策略}等）
控制风险
制定风险无法化解时的“风险应急计划”
分配额外的资源来处理风险
为处理风险留出额外的时间
记住风险（为将来的项目积累）
3.2.3风险监控
（1）周例会检查风险
在周工作例会上，项目经理需要跟踪项目的风险。
根据风险列表，逐一分析前10大风险，确认已经风险状态是否“发生”或“关闭”；
如果风险发生则启动“风险应急计划”或项目组协商解决办法，必要时PM请求相关高级管理者解决已发生的风险，并且PM负责在风险管理计划中将此条风险标示为“发生”。
如果风险已经消除，则PM负责在风险管理计划中将此条风险标示为“关闭”。
统计每项风险的停留时间（周数）。
3.2.4储蓄项目的风险管理
储蓄项目的主要风险是开发人员对客户需求不是很熟悉，另外，客户要求的进度比较紧，而且具体需求不是很明确，客户可能随时提出需求和对项目的改进，需求的不稳定性和项目规模的不断扩展，可能导致项目存在规模风险。
功能的无限追加，在强大的压力下放弃计划都造成了项目的进度风险。
下面的这个风险列表就是通过一系列的风险识别、风险评估、风险应对，等到的储蓄项目的风险列表。
排序
风险事件
可能性
影响
风险值
风险应对措施
1
客户的SOW
需求不明确，增加需求，导致需求蔓延
3
9
1．采取加班的方法
2．修改计划去掉一些任务
3．与客户商量延长一些时间
2
WBS
复杂模块的技术难关
6
对复杂模块进行外包
合同
进度要求紧，合同金额有限
可以请一些实习的学生做辅助工作,一来成本不高,二来可以加快进度.
4
供货商、外包商的质量问题
多选择几个可以作为备份的外包商和供应商
5
历史项目信息
开发人员的流动
1．注意项目团队的沟通，及时了解开发人员的动态
2．控制好项目过程中的文档
3.从其他的项目组借调人员
4．从外部招聘有过此类开发经验人员
规模成本估算
项目的特殊性，成本估算不准确
让有类似项目经验的小组成员对成本估算审查
7
质量计划
软件达不到质量指标，软件性能欠缺
对每一个里程碑进行严格的质量审查
8
计划
进度要求紧，时间紧迫
采取加班的方法
可以请一些实习的学生做辅助工作
3.3项目沟通管理
报告机制：
1.要求各组员以周为单位记录工作进展，形成开发日志，并以电子文档的形式提交给秘书进行整理，最后由文档维护员进行维护。
2.每周例会上各位组员积极对当前的开发工作进行积极的评审和建言，由组长做最后的作口头总结，由秘书主持会议并记录和整理会议的内容。
文档维护员修改和维护相应的文档。
并交由小组进行会议评审并给出意见。
3.小组成员都要密切监控风险状态，发现风险后提交风险报告。
由秘书定期提交风险报告。
必要时将突发风险通知所有组员，并由组长做出临时处理决定。
然后在该周的例会上由小组成员共同讨论对风险的处理意见。
并形成风险处理的日志做为以后的经验。
4.在项目进行的过程当中，组员之间应该多进行各种形式的非正式沟通，以使沟通更加的方便、快捷。
报告格式：
报告主题，时间段，发现人，报告内容，审核意见
评审机制：
每周例会上小组讨论形成一致意见后并，并邀请团长和其他组长参加评议。
对于重大的风险处即为通过，相关负责人针对改进意见开展下一周工作，严格执行例会上所制定的决策。
小组会议持续评估其成效。
每一项目阶段结束之前（里程碑前后），组织一次阶段评审会，评估整个阶段的工作效率和成果质量。
尽量与项目例会合理意见，应该由团长及其他组长组成评审团对处理意见进行审议和评估。
并以评审团的决议作为重要参考来制定决策。
3.4项目人力资源管理
3.4.1项目所需人员
C#程序员：
张三，李四
要求：
熟悉C#编程和微软.Net平台
界面设计员：
熟悉CSS、Photoshop、.Net平台
数据库设计员：
熟悉SQL语句，熟练使用SQLSever2005
文档维护员：
熟悉使用Word及Powerpoint
沟通交流员：
较强的沟通能力，能及时调解组内以及组与组之间的矛盾。
软件测试人员：
全体组员，有王五付总责
熟练使用开发工具的debug工具，有耐心。
3.4.2技能培训
C#以及.Net编程培训
培训对象：
全体组员。
培训内容：
熟练掌握C#编程、基本了解.Net平台的特性、并掌握vs2005的调试工具。
于第6周完成。
美工培训：
全体组员
熟悉Css及Photoshop、了解Flash以及Dreamever的基本操作。
于第8周完成。
3．技术过程
4.1开发工具、方法和技术：
本小组的团队组织结构为主程序员式组织结构；
编程语言为C#；
采用面向对象的分析设计方法；
利用Windows.Net平台作为开发平台；
使用SqlSever2005作为数据库管理系统图；
并采用统一的C#标准的文件命名方式、代码版式、注释等编码规范；
编码人员对代码进行严格检查后再进行代码编译；
测试人员根据测试文档进行单元测试；
最后实现软件的交付。
开发环境：
Sqlsever2005+.Net2.0+VisualStudio2005。
4.2软件需交付的文档：
1．软件项目管理计划
该文档由组长完成，介绍项目的整个管理过程。
该文档在软件设计需求分析初级阶段完成，后续阶段由文档维护员进行相应的更新。
1．需求规格说明初稿
在需求分析阶段，由全体小组成员采集分析用户的需求，并在例会上作出决策，有文档维护员撰写整理需求规格说明初稿，并在后续各个阶段进行需求变更的更新。
2．设计报告初稿
在总体设计阶段，小组根据需求规格说明文档，完成软件体系结构的设计，由组长编写软件体系结构设计文档初稿，并在后续开发阶段补充和更新。
该文档由文档维护员负责维护更新。
4.测试文档
在软件开发阶段，测试人员需要编写测试规格说明文档，并在后续测试阶段更新。
开发人员将根据测试规格说明文档建立测试环境、准备测试数据。
5．用户手册
在更新用需求分析阶段，测试人员需要开始着手编写用户手册，并在需求分析结束后需要形成初稿；
在后续阶段不断由文档维护员户文档；
并在系统交付阶段随着系统一起被交付。
6.个人项目总结
由组内成员各自独立完成，对开发过程中获得的工作经验进行总结。
在提交系统时一并提交。
7.其他文档
软件开发过程中的其他文档，如开发日志（按组员意见选择公开与否），风险报告及其处理意见等，由秘书进行整理与汇聚。
作为以后软件开发以及交流的经验。
5.项目进度及成本管理
5.1项目估算
声明
项目规模估算使用Delphi法进行估算，具体步骤如下：
协调人向小组成员提供项目规格和估计表格；
协调人召集小组讨论与规模相关的因素；
小组成员匿名填写迭代表格；
协调人整理出一个估计总结，以迭代表的形式返回各成员；
协调人召集小组会，讨论较大的估计差异；
成员复查估计总结并在迭代表上提交另一个匿名估计；
5.2项目规模
升级会员 