DELL项目工作整理

    大家好，今天来这里做一个DELL公司内部的软件开发流程简介。DELL不是一家专业的软件开发公司，它的软件开发流程还远不完善，但在一些流程控制上也有它的优势，今天来这里和大家做一个分享，也希望能得到大家的一些建议。今天这里有一些CMM3和CMM4公司的开发人员，希望你们也能给点建议。 

DELL的软件开发项目，遵循的是Microsoft的另一套MSF (Microsoft Solutions Framework) 开发流程。

    项目开发分为五个阶段：1. Chatting (预讨论), 2.Envisioning （想象）, 3.Planing （计划）, 4.Developing （开发）, 4.Stabilizing （稳定）。在每一个阶段都有不同的角色协同工作。

1. Chatting (预讨论) （项目经理，BA业务分析人员，用户）

    项目前期分析，主要内容就是业务分析。项目经理和用户开会，第一，分析用户想做什么？第二，用户的想法可不可行？值不值得做？如果值得做，预算要做多少？分析的工具是：CBA (cost benefit analysis) 成本收益分析 ，它的结果是ROI (return of investment) 投入产出比 。一般情况下，用户提供benefit（收益）分析结果，IT评估项目的cost（成本）。公司目前的立项标准是ROI10比1。我从项目经理那得到的数据是，大致1/3的项目可以继续往下走。

里程碑：立项。（项目得到用户部门经理和IT部门经理的批准，项目进入项目列表）  

2. Envisioning. （想象）（项目经理，业务分析人员，用户，开发组）

    项目的范围界定。描绘项目的范围和关键功能点，使项目有个可视的轮廓。这时候，项目经理会收集各个小组的建议。例如，和开发组沟通大致的开发时间，向服务器组征询服务器的类型和配置，向DBA征询数据库的类型和配置等等。

里程碑：批准的VSD(vision scope definition)    

3. Planning。（项目经理，BA, 开发组，测试组，支持组）

    制定详细的项目计划。确定项目的三要素“时间”，“资源”和“范围”。再加上风险管理。

    1。对于项目经理来说，最重要是向老板要resource（资源）。当然还要确定项目开发的确切时间。

    2。对于业务分析人员来说，需要明确详细的业务需求。这时候会画出系统流程图和用户界面草图，再加上每一项功能的业务描述等等。这些都包括在SRS(system requirement specification)中。

    2。对于开发组来说，最重要是制定了开发计划，瓜分用例（把每一个功能点分配给开发人员）。定制每个开发人员的开发进度表，code review计划。

    3。对于开发组来说，还需要定义风险管理计划和措施。这里的风险，特指技术难点。技术难点需要先做prototype，risk太高的需要舍弃一些功能。（FMEA, failure model effect analysis）因为“任何可能出错的地方都会出错。” 

    4。测试组根据SRS定制测试计划。

    5。项目计划获得用户，项目经理，开发经理和测试经理的同意。

里程碑：批准的SRS(system requirement specification) 

4. Developing。（项目经理，开发组，用户，服务器组，数据库管理员）

设计阶段：

    1。开发组：软件建模。定义系统的架构（逻辑、物理），域建模，用例分析，对每个用例的序列图分析，对象建模。重新评估项目的复杂度。在这个阶段，可适当调整项目计划。

    2。服务器组：安装测试服务器，安装开发相关软件。如IIS，BIG IP, IBM Message Queue等等。

    3。DBA：安装配置开发数据库。配置用户账号：一般情况下分为两个账号。app帐号为正式环境下运行的受限帐号。admin帐号为可建立数据库对象的特权帐号。

    4。项目经理：协调各团队的工作，检查各项工作进度。

里程碑：批准的设计文档SDS(system design specification)。

编码阶段：把设计转换成代码，根据实际问题适当调整并同步设计，code review和审核进度。

里程碑：代码通过单元测试,代码和文档都check in版本管理器。

测试阶段：

    1。SIT内部测试，根据用例描述测试每一个场景，分析内存泄漏，优化系统性能，提交数据库性能execution plan执行计划给DBA review。对系统进行压力测试（必要情况下提交到马来西亚的压力测试组进行测试）。

里程碑：完成内部测试报告和得到DBA的上线批准。

    2。UAT（user acceptable testing）用户测试。用户根据用例描述测试每一个场景，反馈系统bug和issue。开发人员修正bug并基于issue对系统影响和对业务影响进行判断，适当的修正系统或记录业务需求，根据业务优先等级，集成进以后的演进阶段。

里程碑：UAT Sign off。用户签收当前系统功能。

部署：

    项目经理整理文档（Design document, SIT test report, UAT sign off, System downtime approval, server check list, DB checklist. implementation plan. back out plan(data & program)），向change committee（一个专门控制系统更新的委员会）提交新系统上线请求。如果change committee批准请求。

    开发组在指定的时间里向production（生产）计算机部署系统，生成数据库部署脚本，提交给DBA。

    DBA运行部署脚本，反馈结果。 

5. Stabilizing。（项目经理，开发组，支持组）

系统稳定期。开发组 记录和反馈系统BUG，向支持组移交程序和文档等等。

Bug修正：为了减少对生产的影响，在生产环境下的任何bug修正都需要change committee的批准。Change committee只有周二和周四下午接受修改请求，紧急情况下需要部门经理特别批准。对开发组而言，bug修正是一件非常痛苦的事情，这样在一定程度上也提高了软件质量。

里程碑：Support Team Sign off。 

角色：User，Project team 项目经理, BA 业务分析人员， Server team 服务器组, DBA 数据库管理员, Develop team 开发组, Support team 支持组。