项目管理经验.docx

上传人:b****6 文档编号:8903448 上传时间:2023-05-15 格式:DOCX 页数:12 大小:47.78KB
下载 相关 举报
项目管理经验.docx_第1页
第1页 / 共12页
项目管理经验.docx_第2页
第2页 / 共12页
项目管理经验.docx_第3页
第3页 / 共12页
项目管理经验.docx_第4页
第4页 / 共12页
项目管理经验.docx_第5页
第5页 / 共12页
项目管理经验.docx_第6页
第6页 / 共12页
项目管理经验.docx_第7页
第7页 / 共12页
项目管理经验.docx_第8页
第8页 / 共12页
项目管理经验.docx_第9页
第9页 / 共12页
项目管理经验.docx_第10页
第10页 / 共12页
项目管理经验.docx_第11页
第11页 / 共12页
项目管理经验.docx_第12页
第12页 / 共12页
亲,该文档总共12页,全部预览完了,如果喜欢就下载吧!
下载资源
资源描述

项目管理经验.docx

《项目管理经验.docx》由会员分享,可在线阅读,更多相关《项目管理经验.docx(12页珍藏版)》请在冰点文库上搜索。

项目管理经验.docx

项目管理经验

第1章:

项目团队与工作计划

分组与分工

不同公司或不同的项目的组织结构不同,组织结构的各成员或角色有各自的职责。

配置管理员

问题:

定位自己

换位思考

?

项目经理需要干什么(九大知识领域与五个过程组)。

工作计划

对任务进行有效分解,粒度适中,一般控制在40小时内,不要超过5个工作日。

第2章:

需求分析

需求规格说明书

需求变更处理

第3章:

软件设计

概要设计

基本目标:

能够针对软件需求分析中提出的一系列软件问题,概要地回答问题如何解决。

输入:

概要设计要求建立在需求分析基础之上,软件需求文档是软件概要设计的前提条件。

软件概要设计主要包括哪些方面:

需求文档--》需求框架--》设计系统架构---》概要设计文档部分

需求文档--》功能需求--》设计软件结构(分解成不同子系统、约定接口)--》软件结构--》概要设计文档部分

需求文档--》数据需求--》设计数据模型--》概要设计文档部分

需求文档--》非功能需求(包括安全、灾备、可靠性等)--》系统(软硬环境、网络、数据环境及各种措施)--》概要设计部分

系统架构设计内容

分解子系统:

根据业务需求--》业务架构--》设计独立子系统

约定接口:

分析子系统之间通信,确定子系统外部接口及使用协议等

约定系统环境:

分析系统应用场景及应用特点、技术特点等各种现实情况,确定软件、硬软网络、数据及存储等环境,及满足系统的非功能性要求的各种措施

软件结构设计

在系统架构确定后,对组成系统的各个子系统的结构进行设计,主要包括:

确定构造子系统的各模块元素,并根据软件需求定义模块(或再分解的子模块)的功能;

根据子系统特点选择相关技术或根据概要设计约定的技术进行逻辑层(或组件)设计;

定义模块接口或组件接口数据结构,并确定模块之间的调用关系;

公共数据设计

共享数据模型与域的划分

系统安全设计:

权限(数据权限)、操作日志、文件与数据加密等

运行环境约定

硬件要求

操作系统要求

服务器要求

数据库要求

网络要求

存储要求

其它

概要设计文档内容

主要内容:

•系统目标

•系统架构(业务架构、软硬、网络架构等、架构视图)

•软件结构

•数据结构

•安全与灾备

 

详细设计

设计目标与内容

根本目标:

确定如何具体实现所要求的系统,从而得出对目标系统的精确描述。

前提条件:

在概要设计的基础上,描述各模块具体实现和处理逻辑

面向对象设计方法

用例图、类图、状态图、序列图等使用

详细设计文档内容

详细设计文档包含主要内容:

软件的业务逻辑

数据处理过程

模块间的数据接口

各模块的实现算法、数据结构

对核心算法、核心功能的实现进行描述

4章:

项目规范与版本控制

项目规范

包含项目过程、流程、文档命名、数据库、编码、用户界面、测试和评审等等规范

作用

提高可读性

促进团队协作

提高程序员的个人能力

知识传递,加快工作交接

降低维护成本

降低缺陷引入的机会

研发人员主要涉及内容

数据库规范

数据库规范

编码规范

界面规范

界面风格要一致

特定内容的展现格式要一致

特定内容的输入格式要统一

操作风格要一致

功能设定要保持一致

版本控制

作用

团队成员可以并行开发

彼此的修改不会冲突

保留工作过程中产生的所有内容的所有版本

工具

版本控制系统可以做到,目前常用的有SVN、VSS、Git等

SVN

统一的版本号

原子提交

VSS

支持Windows系统所有文件格式

适合.NET开发

Git

不需要服务器端软件

第5章:

进度风险管理与项目评审

进度管理

进度管理的概念:

对项目中的实际进展情况和预定完成期限进行的管理

进度管理的要点:

及时掌握团队每个成员的工作进度

明确任务完成标准

使用敏捷模型管理软件开发过程

及时调整计划

找出影响项目进度的因素

关注人

风险管理

风险管理的策略:

被动风险管理

主动风险管理

风险管理的要点:

风险意识

风险识别

风险回避

风险转移

风险损失控制

项目评审

评估内容:

项目组完成的项目内容

项目进度及项目计划执行情况

项目中存在的风险

项目开发中遇到的困难及问题,解决思路

后续开发计划

第6章:

软件测试

质量意识

在一个组织中不同角色的人对质量有不同的职责:

作为高层管理:

负责组织的质量

项目经理:

负责项目的质量

个人:

负责所做工作的质量

即将要走向社会的你,对自己负责的工作,从现在开始就要建立起质量观念。

测试阶段

详细代码所以在编程的时候进行单元测试。

详细设计阶段需要完成测试设计,把每个单元模块集成起来一起测试,就是集成测试,主要是测试代码的接口问题。

在概要测试阶段是对系统的整体把握,测试时也要进行系统整体情况进行测试。

验收测试,就是结合需求对系统进行测试,测试做出的系统是否符合需求的要求。

1、单元测试。

单元测试是针对软件设计的最小单位-程序模块甚至代码段进行正确性检验的测试工作,通常由开发人员进行。

2、集成测试。

集成测试是将模块按照设计要求组装起来进行测试,主要目的是发现与接口有关的问题。

由于在产品提交到测试部门前,产品开发小组都要进行联合调试,因此在大部分企业中集成测试是由测试人员和开发人员来共同完成的。

3、系统测试。

系统测试是在集成测试通过后进行的,目的是充分运行系统,验证各子系统是否都能正常工作并完成设计的要求。

它主要由测试部门进行,是测试部门最大最重要的一个测试,对最终产品的质量有重大的影响。

4、验收测试。

验收测试以需求阶段的《需求规格说明书》为验收标准,测试时要求模拟实际用户的运行环境。

对于实际项目可以和客户共同进行,对于产品来说就是最后一次的系统测试。

测试内容为对功能模块的全面测试,尤其要进行文档测试。

测试用例

测试用例的定义:

测试用例就是某个特定场景,软件程序在这种场景下,必须能够正常运行并且得到预期的结果。

一个简化的测试用例:

用例:

用户登录

前置条件:

用户进入到“用户登录页面”

输入:

合法用户在系统中的用户名和密码

期待结果:

用户提交正确的用户名和密码后,

顺利进入系统

测试结果:

成功/失败

缺陷跟踪管理系统

了解缺陷处理过程

测试人员--》提出bug(有对应状态)

研发主管/项目经理--》查阅并分配bug到修复人(开发人员)(有对应状态)

开发人员---》查询分配给自己的bug(并修复bug并自己测试)

开发人员--》修改bug状态(例如已修复)并填写修复相关信息(后边需要修改测试申请单)

测试人员--》重新测试bug,如果没有问题,修改bug状态,关闭bug,如果还有问题,重新修改bug状态(重新打开)。

第7章:

验收交付与过程改进

项目实施

什么是项目实施?

定义:

实施是指将软件系统部署到客户方的计算机上,协助客户准备基础数据,使软件系统顺利上线运行

项目实施时的准备:

保证软件符合需求,质量过关

全面做好测试工作(集成测试、系统测试、性能测试)

制定实施计划:

要发布的代码版本、数据库创建方式、基础数据准备方式

准备好程序代码和相关文档:

用户手册、测试用例文档

用户培训

培训人员的选择:

行业积累雄厚,对客户方业务很了解,对我们的系统很了解

培训时注意事项:

制定好培训计划:

了解客户时间,做好沟通和安排

准备好培训内容

项目验收

项目验收:

对系统进行范围和质量核实,最后,需要客户在验收报告上签字,大中型的项目会有一个签字验收仪式。

维护阶段

维护阶段工作

校正性维护:

诊断、校正软件错误的过程

适应性维护:

为适应环境的变更(计算机设备更新)而修改软件的维护活动

完善性维护:

为满足用户提出的新功能、性能要求而进行的维护

预防性维护:

为进一步改进可维护性、可靠性而进行的维护活动

过程改进

过程问题的存在

很多软件企业的软件开发过程中,都存在着各种问题:

同等规模的项目,乙部门总是比甲部门周期长,成本高,而且容易出现各种风险。

同类的错误反复重犯。

要么是需求没有控制好,要么设计出问题,项目压力大,项目成员流失来得。

对相同错误,项目团队似乎对错误“没有记性”。

CMMI

CMMI全称是CapabilityMaturityModelIntegration,即软件能力成熟度模型集成(也有称为:

软件能力成熟度集成模型),是美国国防部的一个设想,1994年由美国国防部(UnitedStatesDepartmentofDefense)与卡内基-梅隆大学(Carnegie-MellonUniversity)下的软件工程研究中心(SoftwareEngineeringInstitute,SEISM)以及美国国防工业协会(NationalDefenseIndustrialAssociation)共同开发和研制的,他们计划把现在所有现存实施的与即将被发展出来的各种能力成熟度模型,集成到一个框架中去。

其目的是帮助软件企业对软件工程过程进行管理和改进,增强开发与改进能力,从而能按时地、不超预算地开发出高质量的软件。

五个级别:

1).初始级

软件过程是无序的,有时甚至是混乱的,对过程几乎没有定义,成功取决于个人努力。

管理是反应式的。

2).可管理级

建立了基本的项目管理过程来跟踪费用、进度和功能特性。

制定了必要的过程纪律,能重复早先类似应用项目取得的成功经验。

3).已定义级

已将软件管理和工程两方面的过程文档化、标准化,并综合成该组织的标准软件过程。

所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件,软件产品的生产在整个软件过程是可见的。

4).量化管理级

分析对软件过程和产品质量的详细度量数据,对软件过程和产品都有定量的理解与控制。

管理有一个作出结论的客观依据,管理能够在定量的范围内预测性能。

5).优化管理级

过程的量化反馈和先进的新思想、新技术促使过程持续不断改进。

每个等级都被分解为过程域,特殊目标和特殊实践,通用目标、通用实践和共同特性:

每个等级都有几个过程区域组成,这几个过程域共同形成一种软件过程能力。

每个过程域,都有一些特殊目标和通用目标,通过相应的特殊实践和通用实践来实现这些目标。

当一个过程域的所有特殊实践和通用实践都按要求得到实施,就能实现该过程域的目标。

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > 初中教育 > 语文

copyright@ 2008-2023 冰点文库 网站版权所有

经营许可证编号:鄂ICP备19020893号-2