(2人评价)
CMMI5级的软件项目实战及文档编写(评审)技巧
价格 ¥ 969.00
会员免费学 购买课程

1.近期的事情需要详细规划,中远期的事情可大致规划

计划应该持续更新和优化

2.什么都不确定,就应该想办法确定。

计划就是用来解决不确定因素及已知问题的。

3.项目管理是项目组每一个人的事情

4.计划就是将“心中有数”可视化

计划需要“晒”出来,才能真正让你想清楚事情

---------------------------------------------------------

什么是项目计划?

为成功完成项目,有侧略有步骤地解决相关问题,而对项目团队工作进行的规划,计划应根据情况变化持续更新和优化

--------------------------------------------------------------



[展开全文]

1.实施最大目标就是推动验收

2.某些工作不注意,所有努力可能付诸东流

3.备份就是为了以防万一,无论如何晓得部署都应该先做好备份工作

4.客户不是IT专业人士,不能尽信客户,项目组应发挥专业水平,“纠正”客户的“错误”

5.项目组应把握住实施工作的大方向,预防“一失足成千古恨”的问题发生

---------------------------------------------------------

实施文档份三类:实施计划、用户文档、培训文档




[展开全文]

推动验收的策略

1.初验与终验分开

初验:功能性验收

终验:上线运行一段时间后验收

2.上下层路线都有走好

3.真心为用户着想,和用户成为朋友

4.让系统成为客户工作一部分

Tips:在双赢的基础上做以上工作!先保证客户能赢,然后是公司能赢。


实施工程师应具备的技能

1.精湛和全面的业务知识

2.扎实全面的IT基础架构知识

3.良好的数据库知识

4.良好的客户沟通技巧

5.一定的商务处理技能



[展开全文]

模拟实际

1.测试应尽量模拟所有环境,软硬件环境、使用环境、数据环境等都不应忽视。

2.使用简单字符会让测试工作简单一些,但要注意简单字符应起到业务数据的“等价”作用。

3.使用真正的业务数据进行测试是必不可少的。

4.先做好测试设计,再考虑测试用例

5.针对测试难点,设计详细的有针对性的测试用例

6.测试用例的数据尽量用实际业务数据,至少必须是“等价数据”

7.不必事无大小都写测试用例

8.不必所有测试用例都非常详细

9.对与测试新受,可要求写比较详细的测试用例

10.针对常见的测试情况,可建立测试用例库,测试指南等

要求所有测试人员都遵循

项目中遇到这样的情况,必不另外再写测试用例




[展开全文]

测试症候群--壮士断臂

测试理论和方法  |   业务知识    |  

基本技能要求

---------------------------------------------

IT基础架构知识:操作系统|网络|硬件

数据库知识:数据库管理|SQL|数据库设计

进阶技能需求

--------------------------------------------

开发知识:测试脚步|编程语言|软件开发

软件设计知识

高级技能要求

------------------------------------------------------------

测试设计

分布式系统

生产环境下的处理情况

评审测试计划




[展开全文]

代码评审最最佳实践-1

1.明确评审目标

2.评审应尽早进行

3.新人的代码更应尽早评审

4.实现方法类似的多个功能点,完成第一个即安排评审

5.“第一次”写的代码应评审

6.测试代码(如果有的话)也应该一并评审

代码评审最佳实践-2

1.关键代码应尽早评审、重点评审

复杂算法|核心业务代码|被调用的多的代码

2.代码评审者水平要高,找近似水平的人来评审效果不大

3.开发人员水平能达到评审目标时,无需再安排评审

4.可通过某些评审来教育开发人员

5.高手在项目初期多展示自己的代码

Tips:编码初期安排比较密集评审,大家都达到水平要求后,可较少甚至不需要评审






[展开全文]

升级型项目的软件设计


[展开全文]

数据库设计评审

1.业务模型是重要依据,请根据需求文档的类图进行评审

模块设计的评审依据

1.哪些部分需要进行详细的设计?

2.模块设计是否满组架构要求?

3.模块设计是否高性价比?

[展开全文]

常见的“设计方法”

1.“编码第一”型

2.“一招定天下”型

3.“精益求精”型

OO

设计模式

要适应所有变化

--------------------------------------------------------------

抓住设计的重点

复用

分析项目的战略,定出合适的设计方略

-------------------------------------------------------------

软件设计要解决什么问题?

1.保证软件可是实现,且满足需求

2.保证软件的实现方式项目组成员理解一致

3.从总体上减轻项目工作量

减轻验收之前的工作量

减轻维护、服务的工作量(基本要求)

4.应对更复杂更多变的需求

5.提高组织的软件质量

6.提高组织的工作效率(高级要求)

--------------------------------------------------------------

软件设计要设计什么?

 








[展开全文]

评审需求规格说明书

1.“硬”问题

与模版不符

没参考上游文档

没遵循规范

注:加强培训和管理,应尽量避免这些问题

2.表达问题

逻辑混乱

内容虚

注:平时加强文字表达能力的训练

3.核心问题

内容缺失

内容不具体

内容不是最佳

注:评审时应重点发现的问题

----------------------------------------------

如何才能发现有价值的问题

1.作者

保证第一次成稿的文档质量,消灭“硬问题”

提高表达能力,不要怕书面表达,减少“表达问题”

提升专业知识,减少“核心问题”

2.评审参与人员

把每次评审当成自己生命的最后一次

提升专业知识,发现尽量多的核心问题

3.“硬问题”、“表达问题”属于低级问题,低级问题太多,会“淹没”掉“核心问题”

4.分析清楚当前公司的实际情况,有策略地逐步消灭这些问题

----------------------------------------------------

升级型项目的需求分分析

弄清楚哪个层次的需求发生了变化?

背景、需要、业务情况、功能性需求

-------------》-----------》-----------------》

变化大                                           变化小

工作量大                                      工作量小

--------------------------------------------

非功能性需求(变化可大可小,工作量可大可小)











[展开全文]

项目的战略分析

项目的需求分析

涉众:测试、开发、PM、领导、客户(不能按时获得满足质量要求的产品)

需求开发基本流程

1.了解项目背景、获取原始需求

2.分析需要 | 分析业务概念 | 分析业务流程

3.整理出需求规格

需求文档应具备的内容

1.背景描述

2.需要描述

涉众、需解决的问题、系统目标、系统范围。。。

3.业务描述

业务概念、业务流程

4.功能性需求描述

5.非功能性需求描述

备注:格式不重要,关键是包含主要内容


需求评审的依据

上游文档

1.合同、方案、项目立项通知书

2.项目”天书“

需求文档模版

背景-需要-业务-需求规格

1.脉络是否清晰?

2.是否描述清楚?

3.能否达到”双赢“?

4.能否解决”温饱问题“

需求文档评审指南

1.了解清楚项目的背景,客户为什么做这个项目?

2.完成项目"天书”

双方商业目标、项目钻石五角的要求


存在问题、风险,有利条件...

评审前须完成的工作

-------------------------------------------------------

3.客户的需要是什么?

目标、涉众、解决的问题、系统范围、....

评审时要查找答案的问题

4.业务分析是否清楚?

业务概念有哪些?是否清晰?

业务流程有哪些?是否清晰?

5.功能性需求有哪些?应该达到怎样的粒度?这些需求对应哪些需要?

6.非功能性需求有哪些?

软件技术架构的要求?

安全性、易用性、性能等方面的要求

7.比较明确的需求有哪些?哪些还不确定?






[展开全文]

对项目组的忠告:

不要埋怨客户,绝大部分客户是理性和聪明的,只是我们不够理性和聪明。

需求分析的基本过程

1. 北京很容易知道,但常常被忽略

2.需求分析的核心问题是找对需要

3.如果客户只能提出“需求规格”,那你需要本事透过这些表面需求,找到“需要“

4.”需要“和”需求规格“要经常用来互相检验


需求规格:功能性需求、非功能性需求

用户体验设计

需求最细化时基本等同用户体验设计

用户体验:用户使用软件时的整体感受

用户体验设计包含三方面:

1.Screen规划

界面流图

2.统一界面标准

形象

文字

行为

3.易用性设计

非功能性需求

1.软件技术架构的要求

安全性、易用性、性能等方面的要求

开发语言、数据库平台上的要求

与现有系统、第三方系统对接的要求

IT架构上的要求(如:服务器、网络环境等要求)








[展开全文]

授课教师

首席专家

课程特色

视频(20)
下载资料(6)
PPT(1)