刚进公司(北京九章天演科技有限公司)时写的，当时Web开发很混乱，需求不明，居然没有Spec文档，任凭一位所谓的大虾指挥。大虾被我弹劾了，这个流程规范设计和写的都不算很严谨，因为时间有限以及*#·￥%—￥#等原因（说来话太长了），所以没花太多时间来修改。个人认为我写的这个规范对中小软件公司（尤其Web为主）的开发管理还是有一些参考价值的，虽然我并不喜欢规范中自己所建议的瀑布式开发模型，但如果项目不大，公司开发团队的组织成熟度不是很高，那还是采用瀑布式模型吧。RUP迭代、XP极限编程，如果开发团队的组织成熟度不是很高，建议最好不要尝试，对团队成员能力要求还是比较高的。呵呵~~~~~闪砖头~~~交流mail: 82314066@qq.com、pushu2002@sina.com...
刚进公司(北京九章天演科技有限公司)时写的，当时Web开发很混乱，需求不明，居然没有Any Spec文档，任凭一位所谓的大虾指挥。 大虾被我弹劾了，这个流程规范设计和写的都不算很严谨，因为时间有限以及*#·￥%—￥#等原因（说来话太长了），所以没花太多时间来修改。 个人认为我写的这个规范对中小软件公司（尤其Web为主）的开发管理还是有一些参考价值的，虽然我并不喜欢规范中自己所建议的瀑布式开发模型，但如果项目 不大，公司开发团队的组织成熟度不是很高，那还是采用瀑布式模型吧。RUP迭代、XP极限编程，如果开发团队的组织成熟度不是很高，建议最好不要尝试，对 团队成员能力要求还是比较高的。呵呵~~~~~闪砖头~~~ 交流mail: 82314066@qq.com、pushu2002@sina.com...
刚进公司(北京九章天演科技有限公司)时写的，当时Web开发很混乱，需求不明，居然没有Any Spec文档，任凭一位所谓的大虾指挥。 大虾被我弹劾了，这个流程规范设计和写的都不算很严谨，因为时间有限以及*#·￥%—￥#等原因（说来话太长了），所以没花太多时间来修改。 个人认为我写的这个规范对中小软件公司（尤其Web为主）的开发管理还是有一些参考价值的，虽然我并不喜欢规范中自己所建议的瀑布式开发模型，但如果项目 不大，公司开发团队的组织成熟度不是很高，那还是采用瀑布式模型吧。RUP迭代、XP极限编程，如果开发团队的组织成熟度不是很高，建议最好不要尝试，对 团队成员能力要求还是比较高的。呵呵~~~~~闪砖头~~~ 交流mail: 82314066@qq.com、pushu2002@sina.com...
...的应用部署问题及安全问题与专业厂商协作解决，产品的核心竞争力在于业务处理。 EC项目组组建仅仅3个月，人员背景基本分为两部分：软件开发、视觉设计。软件实现业务以满足下属一IT硬件分销企业为目标，该企业营运总监（MBA出身）负责与软件事业部协调软件开发，事实上该企业业务量暴涨，分销渠道遍布全国，迫切需要一套网络管理软件。 软件工程的“迭代式开发”已经逐渐取代“瀑布式开发”成为主流。所谓“迭代式开发”，根据我的理解说白了就是象爱因斯坦那样做小板凳，终极的理想板凳就是不断修正前面板凳错误的后一个板凳，“最好的是下一个”。“迭代式开发”与“瀑布式开发”存在本质的不同，传统“瀑布式开发”的出发点是务求各个开发阶段的成果都是最优成果...
...的同一性的振荡的。系统处于其所有同一性的交替地“求同-变异-再求同-再变异”，也就是交替出现的系统同一性变强-变弱的过程中，才造成了它的复杂性和活性。我们要把握一个复杂的活系统，就必须找到它的同一性，调节或影响其同一性振荡的状态，才能维持系统持续稳定、并有所改进地发展。 如何将“同一性振荡原理”应用到计算机信息系统开发和应用过程中去呢？ 3.1 瀑布式开发和迭代式开发 计算机软件系统如何随着用户需求的变化而快速调整自身的结构，来满足用户的需求，是长期以来困绕软件界的大问题，为此，业界已经在计算机软件开发过程、计算机软件体系结构、开发方法和开发工具环境等多方面进行了不懈的努力。其中，在软件开发过程模式方面进行的一项重大变革就是：用迭代式开发取代传统的瀑布式开发模式。 很多国际上著名的软件工程大师，在推荐迭代式软件开发方式时，所能陈述的理...
...速原型是一个由粗到细的过程，在最终形成产品之前，不论原型被修改了多少个版本，都还不能达到产品化的要求，不能对外发布。使用快速原型方法的最大困难就是工程管理的问题，许多具有较强管理能力的企业对快速原型方法也感到畏惧，根本原因就是其不确定性所带来的风险。但是应该知道，快速原型的方法，正是为了针对主要风险，分解风险，尽早地、低成本地降低风险。否则，如果一味地强调软件开发必须以明确的需求为前提，采用传统的瀑布式开发方法，则会面临更大的市场风险，如果以不明确的需求采用传统的开发方法，软件开发本身也必然面临着灾难性的风险。因此，快速原型方法应该成为我们软件开发过程中降低风险的一种有效的方法。许多企业在新的软件开发需求提出时，实际已经建立了自己的信息系统的基础架构，也已经开发了类似的软件系统，因此在新产品开发中应采用的技术手段方面，已经不存在问题，这时的风险主要存在于不明确的需求上，此时采用进化的原型方...
...开发的目标：关注实际设计和构造，让繁冗的流程事件不至于影响项目的进度。具体来讲，经过协调，与SQA达成共识：
1． 在SPP过程制定项目策略计划
这不是一个有确定时间规划和版本规划的可执行计划，而是一种“战略规划”。它明确地定义，什么样的用户需求变更，采用正式的CMM流程，什么样的需求变更可以采用简约流程。而且，还定义了简约流程中项目的模式，如整个项目采用迭代式开发，分期发布版本，每个版本采用瀑布式开发；定义了此后每个版本根据用户需求规模，制定具体的项目执行计划的模式，如需求在评审之后，可以不进行系统设计，直接进入详细设计等；相应的项目追踪SPTO与之适应。
2． 需求管理RM不能省略
因为用户的需求此时成为指导项目方向的灯塔；不过，这个阶段的加速体现在PR中；
3． 同行评审PR设立三种方式以适应不同的场合
（1）审查，即要求所有相关同行必须进行预审，和召开正是评审会议，周期...
... 例如当初采用Use Case来表示用户需求，那么从各种序列图中选出相互交互的各个实体，就是一个个类。
三是分析与设计过程的衔接。
分析过程的内容是用类的结构来表示目标系统，并不设计具体实现，如采用什么编程 语言，在什么操作系统平台上运行等等。这些具体实现是在设计阶段来完成的。面向对象方法的优点是分析、设计、编码过程表示法统一，能比较好的衔接。但是，是把分析和设 计阶段分开，采用瀑布式开发，还是采用其他方式，要看具体的情况。
对于需求潜在变化不大的项目，可以采用瀑布模型，有一个很明显的设计阶段，这样做的好处是有一份比较完整的分析文档，这样以后如果需要采用不同的编程语言、或者采 用其他的平台时，便可以以这份分析文档作为开发的基础。
对于需求变化频繁的项目，可能采用少量分析;少量设计少量编码测试的方式更合适，而且随时可能要返回到前面某个一阶段去进行修改。但是这意味...
...
例如当初采用Use Case来表示用户需求，那么从各种序列图中选出相互交互的各个实体，就是一个个类。
三是分析与设计过程的衔接。
分析过程的内容是用类的结构来表示目标系统，并不设计具体实现，如采用什么编程语言，在什么操作系统平台上运行等等。这些具体实现是在设计阶段来完成的。面向对象方法的优点是分析、设计、编码过程表示法统一，能比较好的衔接。但是，是把分析和设计阶段分开，采用瀑布式开发，还是采用其他方式，要看具体的情况。
对于需求潜在变化不大的项目，可以采用瀑布模型，有一个很明显的设计阶段，这样做的好处是有一份比较完整的分析文档，这样以后如果需要采用不同的编程语言、或者采用其他的平台时，便可以以这份分析文档作为开发的基础。
对于需求变化频繁的项目，可能采用少量分析->少量设计->少量编码->测试的方式更合适，而且随时可能要返回到前面某个一阶段去进行修改...
...预算，项目开发进度往往会被意外发生的问题所打乱，需要进行返工或其他一些额外的开发周期，造成项目延期或费用超支。
另外，在传统的瀑布模型中，需求和设计中的问题是无法在项目开发的前期被检测出来的，只有当第一次系统集成时，这些设计缺陷才会在测试中暴露出来，从而导致一系列的返工：重新设计、编码、测试，进而导致项目的延期和开发成本的上升。
但在早期的软件开发中和现在很多简单的软件开发项目中，瀑布式开发模型应用还很普遍。对于需求简单、目标明确的单一部门级应用软件或大型应用软件的部分简单模块均可采用此种方式，例如简单的办公软件应用或ERP模块中简单、单一的物流、财务、库存软件开发可采用此种模型。
迭代模型与瀑布模型相比有很多优势，其首先允许变更、优化系统需求，通过向业务部门演示迭代所产生的部分系统功能，研发人员可以尽早地收集业务部门对于系统的反馈，及时改正对业务部门需求的理解偏差...
...用户仍然需要注意程序开发的进度是否符合项目计划，开发的程序是否与需求分析相符。
在公文交换系统的程序开发阶段，周月报制度就显得尤为重要，每周召开的三方碰头会上，由开发公司介绍当前开发的进度，有变更计划时间的，立刻进行版本控制。公文交换系统的程序设计实现模块化，每完成一个子模块，开发公司先给中心进行演示，有修改的就立刻记录下来，回去修改，再演示，再修改，以瀑布式开发的方法，循序渐进，减少软件在设计过程中功能上的失误，不会越走越远，得到及时的更正。
4）系统维护的质量保证
项目完成以后，随着软件运作的稳定，开发公司的开发人员会逐渐转移到其它项目，在原来项目跟进的人逐步减少，必然从技术支持的响应上，得不到有效的支持，这使业主方出现了维护工作繁重，开发公司的维护不能及时。
...
...统的软件测试理论和技术已经不能够很好地满足开发组织在产品质量、开发成本
以及研制周期等方面的需求。本文主要从软件测试的组织和管理角度，阐述了CMMI模型规范对软件测试技术的应用和扩充，对于软件开发组织如何发展和完善软
件开发中的测试工作进行了初步探索。
1、 传统的软件测试技术和测试过程模型
传统的软件测试只是作为软件开发过程中的一个特定阶段，并且只针对软件成品进行测试。如图1所示，在瀑布式开发过程模型中，测试是在编码完成之后和软件产
品交付运行之前的一个工程阶段，所有的审查和评审活动都是针对软件成型产品而开展。这样的软件测试主要关注的是对软件的验收测试，在一定程度上保证了所提
交的软件产品的质量。但是，全面质量管理的理论认为，软件的高质量是开发和设计出来的，而不是测试出来的。因此，仅仅依靠对软件产品进行测试的质量保证活
动显然是远远不够的。随着软件开发过程模型和开发技术...
...sp; ...
...周期中，他们的收入在不断变化，因此他们的需求、期望和支付能力都在不断变化。通过CRM的实施，公司就可以建立客户知识库，然后就可以利用客户数据/信息来预测客户的行为变化。当然这还需要企业建立成功的客户行为和生命周期模型。另外，大多数成功的追加销售模型是建立在切实能为客户带来价值的基础上，同样这个基础也是企业客户战略的一部分。
线性式开发
Waterfall development: 也称之为“瀑布式开发”，它是一种技术开发的系统化的线性方法。通常在功能部署到最终用户之前，只经过了一整条开发生命周期。整个开发周期比较长。与之相对的开发方法有反复迭代式开发、增补式开发等。
工作流程管理
Workflow Management：有两种工作流程管理方式1）内部和外部流程的集成。这个方法充分考虑了横跨多种应用系统（包括采用来自不同的软件供应商的软件）的业务流程的定...
