项目管理(PM)

                                                                                  PM(Project Manager)
需求规格说明书:
   《需求规格说明书》概念软件开发项目中用于明确定义系统需求的文档。
需求规格说明书的作用开发者与用户间事实上的技术合同书 开发者下一步设计和编码的基础 测试验收目标系统的依据。

        《需求规格说明书》概念软件开发项目中用于明确定义系统需求的文档。
       《 需求规格说明书》的作用 开发者与用户间事实上的技术合同书 开发者下一步设计和编码的基础 测试验收目标系统的依据。

需求规格说明书包括功能性需求，非功能性需求。
功能性需求：功能性需求：用来描述系统所应提供的功能和服务 。==>>系统功能，输入输出，异常。
非功能性需求：不直接与系统的具体功能相关的一类需求 。==>>安全性，可扩展性，响应时间。


概要设计:
概要设计系统设计：系统具体的技术方案，与其他系统的接口方式。   
系统设计需要考虑到：
硬件环境、软件环境、网络环境用户操作水平团队技术能力开发时间限制
结构设计：确定程序是由哪些模块组成的，各模块分别完成什么样的功能，它们之间存在着什么样的关系。
概要设计的核心是系统框架设计。

详细设计:
详细设计的核心是将业务模型映射到技术模型业务模型 。
在概要设计的基础上再将其细化，得到一个非常接近于源代码的设计表达形式。

技术模型  ：  
执行 select book_name from sys_book where book_no = [书籍编号] and book_status = '已预订' and book_subscribe_stu_no <> [学生借书卡编号]。
如果查询到1条记录，则抛出异常，异常信息为：“图书《[图书名称]》已经被预订，不能借出。”；否则，继续处理。

设计的目的：设计的目的就是是所设计的系统能够被开发方顺利的实现，并且恰如其分地满足用户的需要。。
软件设计分为：概要设计和详细设计。
概要设计：系统框架设计，结构设计。

系统设计：
系统设计需要考虑到：硬件环境、软件环境、网络环境用户操作水平团队技术能力开发时间限制 。
结构设计：确定程序是由哪些模块组成的，各模块分别完成什么样的功能，它们之间存在着什么样的关系。

详细设计中的类图    ：
图中每一个方框表示一个类（或接口），分成三格：
第一格：类的名字 。
第二格：类的属性
第三格：类的方法空。
三角箭头：实现关系虚线箭头：依赖关系。

我们现在需要做的就是：导入框架代码，调试通过。然后直接在此基础上按照《需求规格说明书》，严格遵守项目规范写代码 。

测试用例：
前置条件：系统管理员登录系统事件流：
1、系统管理员在系统菜单中选择“用户管理”时用例开始。
2、系统管理员可以增加一个系统用户 。
3、系统管理员可以根据用户名查询系统用户 。
4、对于每一个用户。
a）系统管理员可以查看该用户的详细信息。
b）系统管理员可以为该用户分配角色 。
c）系统管理员可以删除该用户循环结束。
后置条件：系统管理员执行的用户管理动作生效。

什么是进度管理？
1、在规定的时间内，制定出合理的进度计划 。
2、在计划的执行过程中，检查实际进度是否与计划相一致 。
3、若出现偏差，要及时找出原因，采取补救措施 。（快速跟进，赶工）
4、如有必要，还要调整原进度计划，从而保证项目按时完成。

        每个任务有三个状态：未开始、已完成、延期通过修改功能点和状态信息，就可以自动计算出每个人都总体进度和整个项目的总体进度。
      
         风险识别技术对于已识别的风险，我们可以制定计划进行管理对于未知风险，可以借助文件审核、收集信息等方式来发现风险风险定性分析技术对已经发现的风险，从发生的概率和如果发生造成的严重后果来分类、排序 风险定量分析技术对每项风险的发生概率和影响，以及整个项目的整体风险程度进行数值分析。


应对策略：
回避某些不重要的功能先不实现了，保证核心业务的稳定运行增加资源（一般情况下指人手） 。
转嫁将本公司（部门）不擅长的项目，外包出去。
减轻对于逾期的项目，一方面抓紧完成，一方面请求客户谅解。
接收对于“不可抗拒（比如地震）”的情况，只能“尽人事、安天命。”。


风险和风险管理的概念：
确定： 是指所有信息是可用的，对结果的预言比较有把握。
不确定： 即没有信息，对可能的结果一无所知。
风险： 一种不确定的事件或条件，一旦发生会对项目产生正面或负面的影响。


记录、跟踪：对于每个可能发生的危险，我们都要予以记录，并随时对风险的状况进行追踪 。

如何做进度管理：
合理的计划在获得开发工程师的承诺的基础上制定合理可行的软件开发计划。
跟踪进度数据对每个任务点的完成情况进行追踪，随时了解每个任务点的进度数据。
优先保证“关键路径”上任务点的完成例：需求调研未完成前，设计无法开始(因为还不知道客户要什么) 。
当进度异常时，可以采取“快速跟进”和“赶工”。


进度跟踪表：权重
风险分析评估表：

风险记录跟踪表：

为什么要做单元测试：
    系统故障原因：硬件故障:软件故障 = 10:1
    运行软件的驻留故障密度(每千行代码的故障数目)：
要求很高的关键财务或财产软件为：1～10个软件缺陷/千行代码关键的生命软件为：0.01～1个故障/千行代码



测试：黑盒测试：功能测试;白盒测试：debug来测试等。
黑盒测试：功能测试。
思想：根据已知程序的功能和性能(而不是内部细节)，通过测试检验每个功能和性能是否正常
依据：程序的功能和性能描述
特点：知道程序的功能和性能，不必了解程序的内部结构和处理细节


白盒测试：debug来测试等。
思想：已知程序内部工作流程，通过测试检验程序内部动作是否按规格说明书规定正常运作。
依据：程序的内部逻辑结构，针对程序的逻辑路径设计测试用例。
特点：必须了解程序的内部工作流程。


什么是软件测试：定义：软件测试是为了发现软件缺陷而执行程序的过程。

软件测试的依：
据需求规格说明书（重中之重）；
相关的设计说明（概要设计，详细设计等）；
已经基本成型的UI（可以有针对性地补充一些用例）。


测试用例的定义：
测试用例就是一个“情况”，软件程序在这种情况下，必须能够正常运行并且得到预期的结果。
一个简化的测试用例：
用户登录前置条件：用户进入到“用户登录页面”
输入： 合法用户在系统中的用户名和密码
期待结果：用户提交正确的用户名和密码后，顺利进入系统
测试结果：成功/失败


软件缺陷的定义:
软件未达到产品说明书中已经标明的功能;
软件出现了产品说明书中指明不会出现的错误;
软件未达到产品说明书中虽未指出但应当达到的目标; 软件功能超出了产品说明书中指明的范围;
软件测试人员认为软件难以理解、不易使用，或者最终用户认为该软件使用效果不良.

要想真正设计、编写出高质量的软件，首先需要我们在做事的时候，脑子里具有质量意识。


什么是软件测试:
定义：软件测试是为了发现软件缺陷而执行程序的过程。
软件测试的依据: 需求规格说明书（重中之重）；
相关的设计说明（概要设计，详细设计等）；
已经基本成型的UI（可以有针对性地补充一些用例）。


测试用例:
测试用例的定义：测试用例就是一个“情况”，软件程序在这种情况下，必须能够正常运行并且得到预期的结果。
一个简化的测试用例：用例： 用户登录；前置条件：用户进入到“用户登录页面”；
输入： 合法用户在系统中的用户名和密码；
期待结果：用户提交正确的用户名和密码后，顺利进入系统；测试结果：成功/失败。


测试用例的设计原则:
对应需求编写测试用例 :
    测试用例要全面覆盖需求规格说明书中的软件功能点
便于发现有价值的缺陷

测试用例的组织方式:系统模块；功能点；用例编号；用例说明；前置条件；输入；预期结果；测试结果；失败原因。


如何进行缺陷管理:1.缺陷等级划分；2. 缺陷管理中的角色。
1.缺陷等级划分：
严重的缺陷：所导致的问题会导致系统停止工作、工作不正常 例：windows的蓝屏、死机。
一般的缺陷：主要工作运作不完全，所产生的问题虽然严重，但是不影响下一步的测试。 例：软件异常。
轻微的缺陷：功能运作正常，可是有改进的空间。     例：对“必填”的文本框未作校验。


2. 缺陷管理中的角色:
开发负责人（项目组长）:负责制定缺陷管理计划和流程，将测试工程师发现的问题指派给指定开发工程师，协调缺陷管理流程中的问题。
测试工程师: 将发现的问题提交到缺陷管理系统中，写明问题的描述、严重程度，问题重现方法；负责重新测试开发工程师修改过的缺陷。
开发工程师:确认并修改指定给自己的软件缺陷。


常见问题列表:
《常见问题列表》将放在VSS服务器上，由小组组长维护。小组内人员发现问题后，在问题列表中提出问题，组内各成员经常查看该问题列表，遇见自己可以解答的问题，将解决方案写入表格。


项目实施：
什么是项目实施？
定义：实施是指将软件系统部署到客户方的计算机上，协助客户；
准备基础数据，使软件系统顺利上线运行。
项目实施时的准备
        保证软件符合需求，质量过关  ：全面做好测试工作（集成测试、系统测试、性能测试）
制定实施计划 ：   
        要发布的代码版本、数据库创建方式、基础数据。
准备方式准备好程序代码和相关文档 ： 
         用户手册、测试用例文档。


项目培训：
培训人员的选择：行业积累雄厚，对客户方业务很了解，对我们的系统很了解。
培训时注意事项：准备好培训内容不可临时抱佛脚，丢了面子。
制定好培训计划了解客户时间，做好沟通，协调好，安排好 。


项目验收:
客户对系统的“接收测试”：对系统进行范围核实（看看需求是否全部实现）和质量核实。然后我们的项目正式进入“维护阶段”！

如何做项目维护：
范围管理
        严格定义系统的边界，明确什么需要给客户做，什么不需要做。
         软件需求变更和膨胀是项目的杀手。
                功能性膨胀例：
                        客户业务流程（CRM和HR系统要集成）变化所需系统做调整。
                非功能性膨胀例：
                        培训要求、文档要求、性能要求。
                保持一致性
                        系统中一个小小的调整，导致牵一发而动全身 。