从上世纪中叶计算机的诞生同时也就产生了program，将近有半个多世纪了，而从1970s的软件危机起诞生的软件工程理论的萌芽到90年代的井喷，而现在已经逐渐进入成熟和完善期，而国内的大部分软件公司却仍处于对国外90年代末期软件理论的学习和了解阶段。其实软件工程是一个极具规则化的项目过程管理，这个游戏涉及中的人必须都按要求遵循，我这里简单的介绍下Microsoft的一套MSF (Microsoft Solutions Framework) 开发流程。
不同的注释风格，不通的开发思路），还有大量的程序冗余（不同的地方写着相同功能的方法，还有一些根本用不着的功能——可能是先前需要的后来又不要了吧）；接手的第一个月……是痛苦的一个月，可以这样形容：头上的每一根头发都有疑问，业务上的每一个逻辑的代码实现几乎都感觉有问题，一个熟悉人员3天的项目，我熟悉了3周，加班开发了一周，提交日本后的结果确是不合格。
[@more@]我以前在一家日企，是做标签打印的，这也是我毕业后的第一家公司，而我去的第一个年头的绝大部分时间是去开发和维护一款进销存软件（当然也是和标签打印有关系的），说了这么多，我只是想为回顾一下以前项目的开发做个开场，言归正传：
由于是一个沿用作坊式的开发模式，虽然公司人员也有50几口，但真正一个项目的开发通常会控制到10人一下。项目经理PM与客户做完前期沟通后，发起一个项目【立项】，并提交给合适的1～2个Team Leader，TL简单评估各自选择1～3个程序员协助开发，此时程序员接到通知并开始查看文档，然后与TL，PM展开详尽的讨论。最终用户的需求要通过PM，TL，甚至先前开发人员才传到现在的开发人员手里，而我当时就是属于这种接手先辈（没有bs的意思，先辈，先前开发的前辈）的项目，而我接手时那个项目已经在市场上爬滚了近10年，前后参与修改的人员至少也有15人了吧（不同的注释风格，不通的开发思路），还有大量的程序冗余（不同的地方写着相同功能的方法，还有一些根本用不着的功能——可能是先前需要的后来又不要了吧）；接手的第一个月……是痛苦的一个月，可以这样形容：头上的每一根头发都有疑问，业务上的每一个逻辑的代码实现几乎都感觉有问题，一个熟悉人员3天的项目，我熟悉了3周，加班开发了一周，提交日本后的结果确是不合格。但就从那次我终于开始熟悉了代码，了解了业务，之后慢慢的熟悉起来，2个月后一直到我离开那家公司之前，那个软件中文版相关的改进，版本升级和维护都一直是我来负责。
分析下当中遇到的一些问题：
1、 前期产品需求分析过于简单，经常是一个简单的业务流程图+几百字的一份邮件，造成立项后需要花费大量的时间与PM沟通，甚至再次与客户沟通，我们常常戏称那份邮件为“开发秘籍”，往往TL和开发人员人手一份，讨论会上字斟句酌，但仍有些百思不解；
2、 无论是从需求分析上的业务流程或是程序设计上的逻辑流程还是开发流程等“游戏规则”，或多或少的总有些人不遵守，比如说不同的开发人员对TL和PM指定的规则理解的有歧义，到最后代码merge的时候发现问题；
3、 一些聪明而又执着的开发人员偶尔会因为过度开发而导致项目的延误（虽然警钟在心，偶确还是偶有再犯，罪过啊！罪过！！阿弥陀佛！！！）；
4、 人员分配的失策，一种是引入新的开发人员，就像我刚接手上面的那个项目时，花了别人N倍的时间，但最终还是导致TL对结果买单（可怜的TL加了2天班终于搞定）；二是引入质量失控人员，开发出的代码问题多多；
5、 流程混乱，有时候会出现逆流现象；程序设计文档在开发时严重偏离，甚至会发生程序开发结束后才根据代码来写文档（程序员往往乐此不已，可怜）；
6、 风险管理，往往在开发或测试的后期，迫于客户或老板的要求，追加新的功能，再加上dead-line的关系，导致了end-user面前看到的臭虫永远比想象中的要多的多；
总结：
从上世纪中叶计算机的诞生同时也就产生了program，将近有半个多世纪了，而从1970s的软件危机起诞生的软件工程理论的萌芽到90年代的井喷，而现在已经逐渐进入成熟和完善期，而国内的大部分软件公司却仍处于对国外90年代末期软件理论的学习和了解阶段。其实软件工程是一个极具规则化的项目过程管理，这个游戏涉及中的人必须都按要求遵循，我这里简单的介绍下Microsoft的一套MSF (Microsoft Solutions Framework) 开发流程。
1、 Chatting（预讨论）（项目经理，商务分析员，客户）进行可行性分析
分析的工具是：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, 开发组，测试组，支持组）
制定详细的项目计划。确定项目的三要素“时间”，“资源”和“范围”。再加上风险管理。
i。对于项目经理来说，最重要是向老板要resource（资源）。当然还要确定项目开发的确切时间。
ii。对于业务分析人员来说，需要明确详细的业务需求。这时候会画出系统流程图和用户界面草图，再加上每一项功能的业务描述等等。这些都包括在SRS(system requirement specification)中。
iii。对于开发组来说，最重要是制定了开发计划，瓜分用例（把每一个功能点分配给开发人员）。定制每个开发人员的开发进度表，code review计划。
IV。对于开发组来说，还需要定义风险管理计划和措施。这里的风险，特指技术难点。技术难点需要先做prototype，risk太高的需要舍弃一些功能。（FMEA, failure model effect analysis）因为“任何可能出错的地方都会出错。”
V。测试组根据SRS定制测试计划。
VI。项目计划获得用户，项目经理，开发经理和测试经理的同意。
里程碑：批准的SRS(system requirement specification)
4. Developing。（项目经理，开发组，用户，服务器组，数据库管理员）
设计阶段：
i、开发组：软件建模。定义系统的架构（逻辑、物理），域建模，用例分析，对每个用例的序列图分析，对象建模。重新评估项目的复杂度。在这个阶段，可适当调整项目计划。
ii、服务器组：安装测试服务器，安装开发相关软件。如IIS，BIG IP, IBM Message Queue等等。
iii、DBA：安装配置开发数据库。配置用户账号：一般情况下分为两个账号。app帐号为正式环境下运行的受限帐号。admin帐号为可建立数据库对象的特权帐号。
iv、项目经理：协调各团队的工作，检查各项工作进度。
里程碑：批准的设计文档SDS(system design specification)。
编码阶段：把设计转换成代码，根据实际问题适当调整并同步设计，code review和审核进度。
里程碑：代码通过单元测试,代码和文档都check in版本管理器。
测试阶段：
A、SIT内部测试，根据用例描述测试每一个场景，分析内存泄漏，优化系统性能，提交数据库性能execution plan执行计划给DBA review。对系统进行压力测试（必要情况下提交到专业的压力测试组进行测试）。
里程碑：完成内部测试报告和得到DBA的上线批准。
B、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 支持组
话外篇，逆流现象往往发生在作坊公司，软件工程意识淡薄，软件详细设计人员和开发人员重叠过重，解决办法：软件设计和开发过程分离，即使软件开发中发现设计缺陷，也应该将所有与设计相关人员讨论，并将结果归档后再继续开发。想起上一篇文章《指数效应》——差之毫厘，失之千里。
2008-9-3 凌晨 完
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/75396/viewspace-1010058/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/75396/viewspace-1010058/
1805
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
