项目经理面试题_信息化项目经理面试

1、项目经理的能力和职能？

       项目经理最重要的是协调沟通能力和组织能力，能够安排合适的人到合适的位置，制定较完备的项目计划方案，让项目组成员清楚了解各自的职责、工作量及时间安排，遇到困难能准确找到问题的关键点迅速组织人员解决之。项目经理不一定要技术最好，但技术好的项目经理在进度推进困难的时候将起到很大的作用。

2、结合人、成本、功能、质量和进度这五大因素怎样管理好一个项目？

        以人为本这是前提，只要保证将合适的人各就各位，这为项目的成功奠定了良好的基础成本、功能、质量、进度是矛盾统一体，要想以最低的成本按进度要求的完成一个功能完备、质量高的项目，这多半是理想状态下的情况，真正的项目实施之后很难达到这个要求，所以，我们必须在做项目分析和做实施方案时，做一些取舍。
       首先严格控制成本，这是做一个项目的最终目的，我们需要盈利，亏本的生意我们不做，除非我们的项目组是无需盈利的机构组织；进度与成本成比例，进度越快成本越低，所以保证进度是控制成本的手段。
       其次项目质量和功能，已定义好的必要功能是一定要的，多余的内容尽量暂不考虑，在设计之初多考虑一下系统的可扩充性，设计一个易于修改和测试的系统，严把测试关是保证项目质量的有效手段，一个项目最重要的是在设计阶段要尽量考虑全面，这对项目经理来说，经验很重要。
   简单总结：首先考虑成本，然后再对其他4项做出取舍，在项目整个过程中，根据进度适当调整。当然最好是能以我们最理想的情况下成功的完成整个项目。

 

3、项目实施有哪些主要阶段，每个阶段应该提交什么成果？

  这里只是列出几个大的阶段 

•    需求分析--需求规格说明书模板

目　录
1. 引言 1
1.1. 背景 1
1.2. 参考资料 1
1.3. 假定和约束 1
1.4. 用户的特点 1
2. 功能需求 1
2.1. 系统范围 1
2.2. 系统体系结构（二层架构的系统可剪裁本小节） 1
2.3. 系统总体流程 2
2.4. 需求分析 2
2.4.1. XXXXXXX(功能需求名称) 2
2.4.1.1. 功能描述 2
2.4.1.2. 业务建模 2
2.4.1.3. 用例描述 3
2.4.1.4. 用户界面 5
2.4.2. XXXXXXX(功能需求名称) 5
3. 非功能需求 5
3.1. 性能要求 5
3.1.1. 精度 5
3.1.2. 时间特性要求 6
3.1.3. 输人输出要求 6
3.2. 数据管理能力要求 6
3.3. 安全保密性要求 6
3.4. 灵活性要求 6
3.5. 其他专门要求 6
4. 运行环境规定 6
4.1. 设备 6
4.2. 支持软件 7
4.3. 接口 7
4.4. 控制 7
5. 需求跟踪 7
6. 签批单 7 
1. 引言
1.1. 背景
说明： 
a．待开发的软件系统的名称；
b．本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络；
C．该软件系统同其他系统或其他机构的基本的相互来往关系。 
1.2. 参考资料 
列出本说明书中引用和参考的资料，如：
a．本项目的经核准的计划任务书或合同、上级机关的批文；
b．属于本项目的其他已发表的文件；
c．本文件中各处引用的文件、资料、包括所要用到的软件开发标准。 列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
1.3. 假定和约束[可选]
列出进行本软件开发工作的假定和约束，例如经费限制、开发期限、设备条件、用户的资料准备和交流上的问题等。
1.4. 用户的特点[可选]
列出本软件的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本软件的预期使用频度。这些是软件设计工作的重要约束。
2. 功能需求
2.1. 系统范围 
明确概要地说明用户对系统、产品高层次的目标要求，如系统开发的意图、应用目标、作用范围以及其他相关的背景材料。
如果所定义的产品是一个更大系统的一个组成部分，则应说明本产品与该系统中其他各组成部分之间的关系，为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。
2.2. 系统体系结构（二层架构的系统可剪裁本小节）[可选]
以图+文本结合的方式描述系统的总体架构。
以下应提供系统总体架构图：
以下对系统总体架构进行描述：
2.3. 系统总体流程
以图+文本结合的方式说明系统的总体流程。
图一是计划合同管理系统的总体流程图。
图一
2.4. 需求分析
需求分析的目的是获取或描述系统需求中的每一个功能需求，并通过分析确定系统能够做什么？谁来使用这个系统？
· 建立用例模型：发现角色和用例，并确定角色之间的关系、用例之间的关系，以及角色与用例之间的相互关系
· 描述用例：角色与系统如何交互的规格说明。
2.4.1. XXXXXXX(功能需求名称) 
2.4.1.1. 功能描述
功能编号：
功能需求：从用户业务的角度描述功能需求。
2.4.1.2. 业务建模
从可视化的角度--用例图--描述功能需求
图二是综合计划管理系统合同编辑业务的功能需求用例图。
图二
2.4.1.3. 用例描述
以文本的方式描述每一个用例中角色与系统相互交互的规格说明。
1、 XXXXXX(用例名称)
描述对象 描述内容
标识符 用例的唯一标识符
说明 对用例的概要说明
参与者 与该用例相关的参与者列表，以及参与者的特点
频度 参与者访问此用例的频率
状态 通常分为：进行中、等待审查、通过审查或未通过审查
前置条件 一个条件列表，如果其中包含条件，则这些条件必须在访问用例之前得到满足
后置条件 一个条件列表，如果其中包含条件，则这些条件将在用例成功完成以后得到满足
被扩展的用例 此用例所扩展的用例（如果存在）
被包含的用例 此用例所包含的用例（如果存在）
基本操作流程 参与者在用例中所遵循的主逻辑路径，即当各项工作都正常进行时用例的工作方式
可选操作流程 在变更工作方式、出现异常或发生错误的情况下所遵循的路径
修改历史记录 修改人 ： 修改日期：修改原因：
问题 如果存在，则为与此用例的开发相关的问题或操作项目的列表
以下是综合计划管理系统中的合同编辑功能需求中的合同增加用例描述：
描述对象 描述内容
标识符 IPMS0101
说明 增加一条合同记录
参与者 合同编辑人员--熟悉合同管理业务
频度 
状态 通过审查
前置条件 1. 参与者具有合同增加的权限2. 参与者已选取对应的计划记录3. 当前计划总投资≥SUM(该计划下已签合同价)
后置条件 1. 数据库中更加一条合同纪律2. 可执行合同原件扫描用例3. 可执行合同付款增加用例4. 可执行合同修改和合同删除用例
被扩展的用例 无
被包含的用例 无
基本操作流程 请参见图三的合同增加流程
可选操作流程 当用户确认合同增加时发现异常时，系统提示合同增加无效的提示
修改历史记录 修改人 ： 修改日期：修改原因：
问题 1. 合同编码的具体约定2. 合同类型、资金来源、合同受委托方字典表的具体设计
 
图三 合同增加活动流程
2、XXXXX(用例名称)
……
2.4.1.4. 用户界面
概要描述功能对应的用户界面风格，采用原型生命周期的项目也可以提供原型界面拷贝。
2.4.2. XXXXXXX(功能需求名称)
……
3. 非功能需求
3.1. 性能要求
3.1.1. 精度[可选]
说明对该软件的输入、输出数据精度的要求，可能包括传输过程中的精度。
3.1.2. 时间特性要求
说明对于该软件的时间特性要求，如对：响应时间；更新处理时间；数据的转换和界面更新传送时间等的要求。
3.1.3. 输人输出要求
解释各输入输出数据类型，并逐项说明其媒体、格式、数值范围、精度等。对软件的数据输出及必须标明的控制输出量进行解释并举例，包括对硬拷贝报告（正常结果输出、状态输出及异常输出）以及图形或显示报告的描述。
3.2. 数据管理能力要求[可选]
说明需要管理的文卷和记录的个数、表和文卷的大小规模，要按可预见的增长对数据及其分量的存储要求做出估算。
3.3. 安全保密性要求
用户对系统所应具备的故障处理能力、处理方式及故障后的系统恢复、数据恢复等要求，对系统防止机密数据被非法侵入、修改及丢失的要求。
3.4. 灵活性要求[可选]
说明对该软件的灵活性的要求，即当需求发生某些变化时，该软件对这些变化的适应能力，如：
a．操作方式上的变化；
b．运行环境的变化；
c．同其他软件的接口的变化；
d．精度和有效时限的变化；
e．计划的变化或改进。
对于为了提供这些灵活性而进行的专门设计的部分应该加以标明。
3.5. 其他专门要求[可选]
如用户单位对使用方便的要求，对可维护性、可补充性、易读性、可靠性、异常处理要求、运行环境可转换性的特殊要求等。
4. 运行环境规定 
4.1. 设备 
列出运行该软件所需要的硬设备。说明其中的新型设备及其专门功能，包括：
a．处理器型号及内存容量；
b．外存容量、联机或脱机、媒体及其存储格式，设备的型号及数量；
c．输入及输出设备的型号和数量，联机或脱机； 
d．数据通信设备的型号和数量；
e．功能键及其他专用硬件
4.2. 支持软件
列出支持软件,包括网络和硬件设备平台、操作系统平台、数据库系统平台以及编译（或汇编）程序和测试支持软件等。
4.3. 接口[可选]
说明该软件同其他软件之间的接口、数据通信协议等。
4.4. 控制[可选]
说明控制该软件的运行的方法和控制信号，并说明这些控制信号的来源。
5. 需求跟踪
需求跟踪的主要目的是保证所有的需求都得到分析，以承诺需求-分析需求对应表（PRS_SRS表）的方式描述已分析需求对已承诺需求的覆盖情况。PRS_SRS表的格式请参见软件需求管理过程规范（SUPL-MANU-SRS-001）。
 
6. 签批单
我已阅读上述软件需求规格说明书，我将严格遵守说明书中的条款，并保证全力支持该规格说明书的实施。
执行主管: 
日期
技术主管: 
日期
项目组长: 
日期
用户代表: 
日期
开发人员代表: 
日期
小组成员: 
日期
小组成员: 
日期

 

• 系统设计--《概要设计》、《详细设计》

1 引言 
 
1.1 编写目的 
 
1.2 项目背景 
 
1.3 定义 
 
1.4 参考资料 
 
2 总体设计方案 
 
2.1 设计前提和约束条件 
 
2.2 基本设计思想 
 
2.3 系统整体设计 
 
2.4 功能划分及处理流程 1
 
2.5 性能要求 
 
2.6 运行环境 
 
2.7 软件系统中需人工处理的过程 
 
2.8 概要设计中尚未解决的问题 
 
3 接口设计 
 
3.1 外部接口设计 
 
4 系统数据结构设计 
 
4.1 逻辑结构设计要点 
 
4.2 主要表结构 
 
5 安全设计 
 
5.1 系统安全体系 
 
6 系统出错处理设计 
 
7 系统维护设计 

 

1 引言

1.1 编写目的 

 本概要设计文档主要用来指导创新综合管理系统的详细设计工作，为详细设计提供统一的参照标准，其中包括系统的内外部接口、系统架构、编程模型以及其他各种主要问题的解决方案。在此文档被经过同行评审后，所有有关本系统的详细设计必须遵照此文档的相关标准和约束来进行。另外，此文档也作为对详细设计文档进行同行评审所依照的标准之一。在详细设计的过程中，如果发现需要添加新的概要设计标准或者约束来指导详细设计工作，必须在此文档进行更新和评审，以确保各模块详细设计的一致性和正确性。本文档主要描述的是创新综合管理系统的概要设计，其中包括定义系统的内外部接口、相关的系统架构和设计标准，不会涉及系统业务逻辑现实的细节。

1.2 项目背景 

创新是实现银行持续健康发展的源动力。总行、省分行十分重视创新工作。但由于缺乏系统支持，广东省分行主要依靠手工及邮件分发的方式，对创意进行收集、筛选、测评等处理，创意处理工作压力大，处理周期长，效率低，由于创意处理意见反馈较长，一些员工创新的积极性受到一定影响。此外，员工所提创意不能共享，创意的提出缺乏有效规范与指引，高质量的创意比较少。为了提高创意收集与处理效率，深化对创意的筛选与加工，为创新提供更多既符合客户需求、又与我行发展战略相吻合的创意，广东分行向总行请示拟开发创新综合管理系统。系统上线后，主要实现以下目标：一是将解决原来主要依靠手工邮件收集、处理创意的问题，提高创意处理效率，并提供团队提出、加工、研究创意的平台，实现对创意的深层次加工，为创新提供更多更好的创意；二是提供系统平台，支持创新项目的立项、审核、创效奖的申报和处理等；三是建立全分行统一规范的产品信息发布维护渠道平台，员工可方便地学习我行产品知识，促进市场拓展能力的提升；四是建立产品推广后运行信息收集平台，产品归口部门可及时了解产品满足客户情况、潜在风险及与同行先进产品的比较等信息。

 

1.3 定义 

1.4 参考资料

《创新综合管理系统业务需求说明书》

《创新综合管理系统需求分析》

2 总体设计方案

按功能不同进行技术层次划分，使各层功能相对独立。同时以接口形式来描述各层之间的调用关系，以达到层次之间的松散耦合。各层所提供功能不依赖于一种具体的技术或产品实现，应该提供一定范围的技术选择。技术架构不和具体的应用架构绑定，应具备较宽的使用范围，适合未来应用的扩展。

以下为总体模块之间的关系：

 

2.1 设计前提和约束条件

1． 系统用户登陆通过与总行UAAP认证系统实名认证

2． 创意产品研发过程对选取专家使用Lotus邮箱邮件通知功能

3． 遵循SUP的J2EE项目开发规范。使用SUP1.1.3作为开发平台。

4． 遵循建设银行JAVA编码规范。

2.2 基本设计思想

我们把状态控制及审批流转、评分评议的计算、邮件发送抽取成共用模块，以供其他模块引用。详见以下模块关系：

 

 

 

2.3 系统整体设计

2.3.1 物理部署架构

                                     

 

 

硬件：

Web服务器：IBM刀片服务器 * 2

小型机 磁盘阵列 200G

软件：

 Windows server 2003 + Weblogic

AIX 5.3 + Oracle 10.0

物理部署关系图

                                                             

 

         1． 系统用户登陆通过与总行UAAP认证系统实名认证

         2． 创意产品研发过程对选取专家使用Lotus邮箱邮件通知功能

 

2.3.2系统的层次模型

  

2.3.1.1 客户端(Client Tier)

客户端指的是访问应用的web浏览器终端，通过web浏览器啊来访问创新综合管理系统。该层的展示效果应遵循我行《BS 架构系统用户界面规范》

2.3.1.2 表现层(Presentation Tier)

表现层接收客户端的 HTTP 请求，提供系统登陆，会话管理，访问控制，数据封装和交易分发等功能。采用 JSF 时，应遵循中国建设银行相关的 JSF技术实施规范。

2.3.1.3 业务控制层(Usecase Controller Tier)

对表示层发来的数据格式进行检查判断，根据不同的业务将数据分配到不同的业务处理服务进行处理。

2.3.1.4 业务服务层(Business Service Tier)

业务层是 J2EE 构架的核心层，它接收展示层分发的交易请求，完成业务逻辑的具体实现。对不同的业务数据进行处理，处理完成后，将处理结果返回表现层。

2.3.1.5 集成层(Interface Tier)

集成层向业务层提供统一的内部和外部资源访问，为业务层的数据访问请求屏蔽不同的数据存储访问技术，以及与外部系统整合技术的差异性。

2.3.1.6 数据层(Resource Tier)

资源层主要指数据库、文件系统和外部系统。该层采用的产品遵循总行信息技术管理部对数据库等软件产品的统一规定。本系统采用ORACLE 10g 作为数据库系统。

 

2.4 功能划分及处理流程

 

 

 

 

2.4.1创意综合管理模块

2.4.1.1  功能概述

系统建立较便捷、易用的创意提出平台。所有用户既可单独提交创意，也可以通过系统选择若干“志同道合者”组成小组，共同提出创意各级创新牵头管理机构从完整性、创意价值等方面对收集的创意进行快速筛选，并按业务条线进行分发处理。根据相关评分指标，从创新专家库中，选择若干创新专家，对筛选认可的创意进行内部评分，评选出奖励创意及奖励方案，上传集中评议结果，并将获奖创意入库。对创意进行加工完善，形成产品模型。

 

2.4.3.2业务处理流程

 

 

系统要根据提交创意的部门所属级别的不同，提供不同的处理流程，包括如下2种级别：

二级分行普通员工提交创意→二级分行牵头部门。

省行部门员工提交创意→省行部门牵头部门。

 

流转超过7天需要邮件提醒改管理员和省分行管理员。

管理员转移功能，完全转移和临时转移

2.4.2创新项目

2.4.2.1 功能概述

立项申请→部门负责人审核→项目初审→审批结果反馈→项目进展登记→创效奖申报→项目/部门负责人审核→初审→生成评奖批次→选择专家（含设置权重）→专家评议→生成评议结果→结果修正→公示→产品委审议结果登记

 

2.4.2.2业务处理流程

 

考虑到业务的需要，部门/二级行管理员可对本业务部门的立项申请或者创效奖励申请进行审核和填写审核意见并提交初审核。

 

○:具有相应权限  ╳:无相应权限

 

2.4.3产品信息平台

2.4.3.1功能概述

产品信息平台包括 产品信息维护，上市产品运行信息模块，产品知识讨论及评估。

产品信息维护是用于产品经理对该条线的产品信息进行录入、维护和发布，以便前台员工和大堂经理能进行产品知识的学习并及时掌握产品的变动要求。上市产品运行信息模块是提供给员工对我行已上市的产品（指所有创新项目，既包括产品创新，也包括管理创新、服务创新、流程创新），特别是对最新推出的产品和对业务发展具有重要影响的重点产品进行营销意见反馈、风险预警和评价的平台。该模块有助于产品管理部门和业务管理部门对新产品的跟踪和调查，从而及时准确的更正和完善这些上市产品，使新产品的推出向着更有利于客户、有利于建行的发展方向进行，同时，可加大创新成果的共享。产品知识讨论及评估 主要用于所有产品信息展示，员工对产品的评论。

 

2.4.3.2业务处理流程

 产品信息维护流程：

                       

2.4.4用户管理模块

用户管理功能主要有SUP 1.1.3 生成， 主要包括： 机构管理、角色管理、菜单权限管理、用户管理。 增加功能为用户登录统计和UAAP认证接口。

          

2.4.5系统参数模块

 系统参数模块主要包括：下拉列表数据配置、系统参数配置和通知管理，主要使用SUP的“高级单表维护工具”来实现。

 

2.5 性能要求

• 处理能力

系统面对可能达到几十的用户任务并发性，应保证正常的处理能力。

• 稳定性

系统资源利用合理，保证系统前后台数据操作效率。

• 传输能力

本系统业务功能包括附件和图片传输，应提高文件传输速度

2.6 运行环境

2.6.1硬件规划

磁盘空间估计：200G主要考虑系统中的附件上传功能。

2.6.2软件配置

 

2.7 软件系统中需人工处理的过程

无

2.8 概要设计中尚未解决的问题

无

3 接口设计

3.1 外部接口设计

                                       

3.1.1与UAAP系统接口

创新综合管理系统的用户身份认证将通过UAAP实名认证。

3.1.2与Lotus邮件系统接口

创新综合管理系统中的创意综合管理模块中的创意深度加工产品研发步骤将提供邮件通知业务部门人员。

 

4 系统数据结构设计

采用POJO的方式实现。结合SUP平台的业务类型规范。

4.1 逻辑结构设计要点

功能点及功能模块间的关系

 

4.2  主要表结构

系统信息表主要与系统框架有关的系统表，包括：

 

SUP平台对用户信息处理的基础表结构

 

 

5 安全设计

5.1 系统安全体系

系统的安全体系可用下图表示：

 

整个系统的安全取决于系统运行物理环境的安全性、服务器及网络的安全性、操作系统的安全性、应用系统的安全性及应用数据的安全性等，通过设计实施整体的安全策略，对安全策略的实施结果进行评估，及时采取修复补救措施，调整安全预防策略，综合动态地进行系统安全管理。

创新综合管理系统的信息数据安全主要实现在业务流程控制和代码的详细设计中，对系统权限设计应充分考虑整体策略安全性。

由于本系统建立在我行现有的物理环境和网络环境中，环境安全性很好，并将不断完善优化，因此，有关本系统的安全设计的主要对象是系统自身的应用安全、数据安全、服务器操作系统和数据库的安全管理维护。

5.1.1系统面临的安全威胁

本系统需要考虑系统及数据可能面临的以下安全威胁：

非人为因素：服务器意外断电、损坏、硬盘出错或损坏，网络中断等；

人为因素：操作失误，恶意攻击，病毒破坏等；

信息泄露、信息窃取、假冒、抵赖等；

系统软件安全漏洞。

5.1.2系统安全方案

针对上述安全威胁，系统的安全运行依赖网络和服务器系统的安全，系统本身需要设计相应的安全监控功能。

5.1.2.1服务器及客户端系统安全

对于数据库系统，进行相应的安全配置维护管理，根据实际情况及时进行安全策略调整，定期进行数据库系统的有关备份。

由于客户端计算机用途很开放，很容易受到病毒感染、恶意攻击等，可能会进一步影响到服务器，因此，对客户端计算机也要采取安全措施，进行相应的安全配置管理，如设置有效的系统密码，设置较高的浏览器级别，及时打补丁，安装反病毒程序，定期查杀病毒，根据实际情况及时采取安全措施。

5.1.2.2应用系统安全

• 身份认证

使用建行统一身份认证体系UAAP进行身份认证。

• 用户权限控制

系统提供用户角色权限管理功能模块，UAAP上的用户即可作为普通用户登录本系统进行创意提交、创意查询、创新项目查询、产品知识查询和交流、上市产品信息反馈等等功能。

角色分为以下几种

系统管理员： 参数设置、流程跟进

专家库 ： 可以被选中后进行创意和创效奖评分操作

产品经理 ： 有录入和修改该部门下面的产品的权限

部门管理员 ： 负责该部门或条线的创意筛选工作。

广东分行管理员 ：创意筛选和创新项目审批，创意和创新的评奖和公示。

二级行管理员 ： 创意筛选、创新项目效益收集、分行奖金分配

普通用户 ： 提出创意、项目进展登记、产品学习和评估

• 安全管理和权限制度设计

明确系统的安全管理机构/部门、人员及职责，负责管理系统安全保密工作。制定系统安全保密管理制度，并严格加以执行及监督，实现资源的合理配置和统一管理，实现统一的访问控制策略，确保系统的安全运行、安全审查。

在外部安全上，企业级的防火墙可以为本系统提供一个安全的运行环境。

在系统内部，本系统用户，机构、角色、权限根据实名制层级设置，提高系统数据操作的安全保护。

6 系统出错处理设计

系统出现故障或错误，按模块记录错误日志，并提示用户，方便分析错误和维护；数据库系统容错：数据库系统定期备份由数据库服务器自身的容错系统解决；

6.1.1客户端异常处理机制及实现方法

根据业务需要，定义成两大类型的异常：

BizException： 弹出框或页面上方信息提示，可以保持原来页面所显示的内容。

RollbackableBizException： 数据库回滚异常，并给出相应的提示。

抛出到页面提示用户进行处理或直接在Backing Bean跟进不同的错误类型作出不同形式的错误展示方式。

6.1.2业务逻辑层异常处理机制及实现方法

各个模块定义不同的模块异常，抛出到Backing Bean进行统一处理。

6.1.3数据存储层异常处理机制及实现方法

数据层Exception统一由业务逻辑层进一步进行处理。

 

7 系统维护设计

在系统中专门设置用于系统检查与维护的检测点和专用模块。尽可能地降低系统维护工作量。系统的前台应用的界面风格要一致，提示信息要明确。软件编码的要求风格一致,有详细注释，保证代码易读易懂，以便于系统维护。要求提供完备的设计文档、用户手册、安装文档、在线和联机帮助文档，为系统地维护工有效的帮助和指导。系统发生变化后要及时更新相关文档内容。

---

详细设计说明书模板

目录
 
1 范围 (1)
 
1.1 标识 (1)
 
1.2 系统概述 (1)
 
1.3 文档概述 (1)
 
2 引用文档 (1)
 
3 CSCI体系结构设计 (1)
 
3.1 部件组成 (1)
 
3.2 体系结构 (1)
 
3.3 系统流程 (1)
 
3.4 应用部署 (2)
 
3.5 接口关系 (2)
 
4 CSCI详细设计 (2)
 
4.1 (软件单元的项目唯一的标识符,或者一组软件单元的标志符) (2)
 
4.1.1 功能 (2)
 
4.1.2 技术指标 (2)
 
4.1.3 设计思路 (3)
 
4.1.4 相关单元关系 (3)
 
4.1.5 输入输出项 (3)
 
4.1.6 处理过程 (3)
 
4.1.7 时序图 (3)
 
4.1.8 异常处理 (3)
 
4.1.9 存储分配 (3)
 
4.1.10 界面设计 (3)
 
5 需求可追踪性 (3)
 
6 注释 (3)

---

• 编码和测试－ 项目得到成品，并按《项目需求说明书》要求测试完毕，解决了所有已知问题。

测试人员和开发人员比例多少才是最科学的？上网查了很多，很难给出一个答案。
这个比例的问题来自两方面的矛盾。一方面来自boss，希望通过一个比例来优化人员结构，减少团队工作冗余资源；另一方面是测试人员工作量及工作范围界限不那么清晰，确保优质产品交付势必工作量细而繁多。
微软公司的开发与测试人员比例为1:1，甚至在有的团队中该比例为1:2，测试占比大。
谷歌的开发与测试人员比例则为10:1，测试人员占比很低。
比较普遍的一个比例是4:1~2:1,包括Testleader在内。
当前所在部门194人，架构15人占比8%，开发99人占比51%，测试45人占比23%，需求19人占比10%，UI4人占比2%，安全分析2人占比1%，项目管理10人占比5%。测试人员占比1/4左右，平均2个开发对应一个测试。与行业普遍能够接受的3：1（对于成熟系统来说，这个比例我也是比较认可的）相比，我们的测试人员比例略微偏高的。但是作为2:1下的一名测试人员，我并没有感觉到轻松：
1、常规成熟系统的功能bug的确是相对较少的，但是测试覆盖（包括设计和执行）确一个也不能少，因此工作量相对来说可以打个折扣但不大。
   新项目功能不稳定，版本更迭速度极快，测试工作量投入比较大。
2、版本测试结束并不意味着工作就完结了，而后要指导生产环境更新版本，有时候也需要编写指导文档和方案。
3、有些联调测试工作，其实是很繁琐的。本公司内部协调、对外协调需要的沟通成本可能比实际联调测试所需时间还多。
4、参与各个阶段的文档的评审工作，包括需求人员的需求评审、开发人员的软件设计评审、编写设计测试案例及评审、patch发布说明评审。
5、有些版本需要实现自动化，便于后续版本维护成本的节约，自动化案例的设计（原有的自动化工具ATP），RobotFrameWork工作量（从0开始）简直相当于自动化的开发。
春节前一个月开始，这段段时间工作量负荷比较大（春节过渡缓了一下，节后工作量相对较大一直没有缓冲的清闲时间，老实说有点累），一方面是业务能力提升，工作范围扩展和深入，Boss放心让你挑的担子大了；另一方面公司最近阶段项目比较多，全体开发系统工作量都多了。具体来说，节后至今两个月先后：
1、独立完成两个需求版本（140、141）的完整的系统测试工作（需求评审始-->版本发布结束）  一个是节前完成的，另一个持续3周
2、三个联调测试工作（2个对外、1个对内） 其中2个联调分别持续2周，一个联调持续1周（未完成）
3、一个版本上线联调测试指导（进行中）   1周（未完成）
4、一个大版本的2个模块完整系统测试      2周
5、1中版本新增需求对应的完整系统测试    1周
6、一个联调测试工作（即将开始）         暂未投入
7、两个新项目的前期投入（其中一个为"新"项目需要攻坚，版本不稳定是能预料的） 前期投入1周，预计要2周 + 新项目不好估算，可能半年甚至更长时间
以上时间估算都是相对保守的（对测试来说项目实际跨度更大，投入少切割不记录在内），大部分时间都是处于复用状态。这比完全投入一个项目是要更累的，经常在几个进行的项目中进行角色切换，个人效率不是最高的（但是项目需要在时间点上对外负责--必须要启动项目并行，现实中很多这种情景都是需要牺牲部分效率的），头脑中每天要装的东西也非常多不能丢。
再来看看我认可3:1这个比例，但是2:1下却感觉累，终归还是要回到测试工作的范围定义上来。
这是一个常规的测试过程：评审文档-->搭建测试环境及维护-->编写测试案例-->测试执行-->跟踪bug，回归测试-->自动化实现-->性能测试-->报告
3:1的比例对于一个纯粹的测试来说，只对测试质量保证负责，前端开发对交付测试的系统产品负责，后端交接给维护人员进行上线和维护，其实也是轻松的。前端开发人员完成单元测试覆盖达到80%，到测试人员接手时功能bug很少，相当于成熟稳定系统，功能问题分析和定位时间投入不大，主要工作集中自动化测试工具的支持+性能、负载、安全性测试等等；后端交接给成熟的运营维护团队，需要测试投入也很少，这样的测试和开发界限其实已经很模糊了，几乎是一个开发，一个负责后端交付的开发，比例为5:1都可以说是合理的。
有的产品不能使用beta版本，因为线上出现问题影响比较大。对版本质量要求比较严格，同时将测试工作范围放大（行业中实际情况经常如此），另外开发、运维及测试人员素质都没有理想的那么高，那么问题来了，因团队人员素质问题产生的额外工作量，作为中间人员承担的相对会多一些，工作范围也就要相互前后延伸协作，简单就是工作量都增大了。对于中间的测试人员来说，质量保证所需测试的轮次增加了，后端交付需要投入也增加了。
从团队发展来说，减少测试人员比例对需求人员、开发人员、测试人员、运维人员等的素质提出很大的挑战，唯有各方面团队人员共同进步，完成产品优质交付所需的测试资源投入才能减少。任重道远！

•    结项阶段－－ 客户验收通过。
•    具体实施和维护阶段－－实施成功，并合同要求进行维护

   
4、如何识别和控制风险？

       以后经验和收集到的资料对项目中将遇到的风险进行预测，对各种分析进行分析评级，设置风险系数也就是风险可承受范围，然后针对各个风险列出降低风险各种方案，确保风险真的来临之时，有可用方案应对。我们无法完全规避风险，只能把未来的风险控制在尽量低的范围内。

5、需求变更管理的手段和与客户沟通的手段？

   项目开发过程中，需求变更是不能回避的问题，我们需要一个正规的变更文档来定义每一次变更，并保持各个阶段文档的一致性，避免混乱。对于需求变更应得到客户在开发成本和进度的认可情况下进行，而不是一未满足客户，导致严重超支延期。 变更这对项目开发一方是很头痛的问题，变更应该有所控制，在双方相互协调、认识统一的前提下进行，与客户的沟通尽量采用可见的通俗易懂的方式方法进行。但在必要的情况下，应该采取对客户进行相关专业知识的培训手段，避免不合理的要求。

项目经理的职责（职位描述）

1、计划

☆ 对教育项目所有的合同文件完全熟知

☆ 为基于Web技术的教育信息化审查、筛选、实施、成本控制制定项目基本计划。

☆ 知道基于Web技术的教育信息化产品及其项目评价、选择、投资、建设、实施、流程的准备。

☆ 指导教育项目成本（市场、技术、外包等）预算的准备。

☆ 指导教育项目时间进度安排的准备。

☆ 指导教育项目的基本设计、准则、理念及总的规范的准备。

☆ 指导现场教育项目宣传活动的组织、活动人员，会员人员的实施和成本控制计划的准备。

☆ 定期对计划和与项目相关程序进行检查评价，在必要的时候对项目的原计划和设计、实施流程进行改变。

2、组织

☆ 开发项目组织图。

☆ 对教育项目中的各职位进行描述，列出项目主要监管人员的职责范围。

☆ 参与对教育项目中主要监管人员的挑选。

☆ 开发项目（产品）所需的人力资源的挑选。

☆ 定期对教育项目进行评价，必要的时候对本项目组织结构及人员进行变动。

3、指导

☆ 指导项目相关合同中规定的所有工作

☆ 在教育项目组中建立决策系统，以便在适当的层次做出决策。

☆ 促进项目监管人员的成长。

☆ 设立项目目标，并为主管的各监管人员建立绩效标准。

☆ 培养教育项目组成员与公司的企业文化一致化，并培养项目组成员的团队合作精神（包括监管人员）

☆ 辅助解决存在于各职能部门，各事业部，各项目组及其承担各项目的小组之间的分歧（冲突）或问题。

☆ 对教育项目总体进展情况保持了解，以避免或缺少潜在问题的发生。

☆ 对关键问题确立书面的战略指导原则，清楚理解基于Web技术的教育项目的定义、责任和约束。

4、控制

☆ 监督教育项目的活动，使项目的进展与项目目标及公司总体政策相一致。

☆ 监督教育项目的活动，使项目的进展与合同、计划、程序及用户的要求相一致。

☆ 对项目所有人员进行控制（并对监管人员的绩效监督）保证其遵守合同条款。

☆ 密切监督项目的有关活动，建立有关"变更"的沟通程序，对有相关项目范围可能的变更进行必要的评价和沟通。

☆ 对城域教育网项目的成本，进度、及质量进行监督、保证及时向项目发动人汇报。

☆ 与用户及有关政府或其他组织保持良好有效的沟通。

 

理论、关于项目经理的2个面试题
1，某软件工程项目工期4个月，如果您是该项目的项目经理，请综合考虑工程的各方面内容，制定出该项目的简短而比较完善的实施方案

2，软件工程项目即将在2个月内验收，如果您是该项目的项目经理，请综合考虑工程的各方面内容，制定出该项目的简短而比较完善的验收方案

 

 ================================================================================================

1:第一个星期内确定 大致需求\了解客户并确认资源(人\设备)

2:第二个星期,开列需求文档,前期技术准备,人员培训

3:第三个星期,开列系统分析文档,与客户确认开发目标,制定开发计划(大概分三个版本,4-6个星期一个版本),部分基础模块先期开发

4:第四个星期,完善系统设计\确保开发进入正常轨道\根据开发进度调整开发计划

5:按开发计划进行,做好客户沟通了解最新需求变化

6:第一次交付测试...

7:第二次交付测试...

8:第三次交付测试...  验收方案和开发方案大致一样,与客户沟通是重点,确定里程碑,确保所有资源按计划进行是关键.

 

出题的思路

1。初步定位是不是我们需要的人选（价值观、个性、领导风格、沟通能力）
2。实际管理经验是否丰富？（诚实度、责任心、主动性、管理能力）
3。能不能培养？有无培养价值？ （个性、态度、自我定位）
4。与企业文化是否融合？（没有好坏对错之分，只看缘分）
 
 
１．请你谈谈你自己

*提问意图：透过这个问题，可以在很短的时间内了解对方，也可以借此看出对方的表达能力、个性等。

２．为什么选择我们这家公司？

*提问意图：了解对方是否了解本公司的背景，可了解对方是否真心想得到这份工作，而不只是探探路。

３．为什么选择这个职务？

点评：适时举出过去的“丰功伟业”，表现出你对这份职务的熟稔度，但避免过于夸张的形容或流于炫耀。

４．对这个职务的期许？

点评：回答前不妨先询问该公司对这项职务的责任认定及归属，因为每一家公司的状况不尽相同。以免说了一堆理想抱负却发现牛头不对马嘴。

５．为什么我们要在众多的面试者中选择你？

点评：别过度吹嘘自己的能力，或信口开河地乱开支票，例如一定会为该公司带来多少钱的业务等，这样很容易给人一种爱说大话、不切实际的感觉。

６．如何安排自己的时间？会不会排斥加班？

点评：虽然不会有人心甘情愿的加班，但依旧要表现出高配合度的诚意。

７．为什么离开上一个工作？

点评：第一，切忌一听到这样的问题，就开始大肆数落过去的主管或公司，希望博取对方的同情，这样子只会让面试者觉得你是一个会推卸责任，爱抱怨、发牢骚的员工，更惨的是，如果对方正巧认识你之前的主管，还颇有交情，这可就糗大了。第二，尽量将原因转换成客观因素，如组织的调整，与本身所设定的生涯规划有冲突等，而非自己能力的问题

８．你对未来五年的规划为何？

９．谈谈你过去做过的成功案例。

点评：举一个你最有把握的例子，把来龙去脉说清楚，而不要说了很多却没有重点。切忌夸大其词，把别人的功劳到说成自己的，很多主管为了确保要用的人是最适合的，会打电话向你的前一个主管征询对你的看法及意见，所以如果说谎，是很容易穿梆的。

１０．谈谈你过去的工作经验中，最令你挫折的事情。

*提问意图：借此了解对方对挫折的容忍度及调解方式。
 
考察业务能力 
面谈以往和客户交手的能力。

考察过程管理 
Microsot Project或类似工具--考察制定项目进度计划的能力。 
考察进度跟踪的能力，是用email+excel?还是辅助管理工具比如trac，jira等。

项目组管理能力 
cmm式管理？严谨的流程和文档。 
xp开发方法?测试驱动、模型驱动、迭代、持续集成？ 
瀑布是管理方法？--嗯，保守派。

项目经理如果要管代码(兼任系统分析)的话，考察设计能力 
直接拿出具体的业务模块需求分析，写一份概要设计，看uml基础--用例、类图耍得如何。 
从类图查看oo三原则和模式的能力。