微软公司软件开发模式简介(上)
北京大学出版社96年底所出的《微软的秘密》一书是目前我所见到的对微软公司软件产品开发过程介绍的最专业、最深入的一本书。通过本书，我们可以看到微软公司是如何对科学地对软件产品开发进行有效地管理，我想这些经验对于中国的广大软件开发人员，尤其是关心中国软件产业发展的各位朋友是大有益处的。所以特将此书中涉及软件产品开发的部分内容摘录出来（第四章“产品定义与开发过程”），加上我在微软中国工作的实际经验总结出这篇文章，希望与大家共同分享。本文作为摘录，自然是挂一漏万，所以建议大家若有时间还是找来原书一读。
在微软的产品定义与开发过程中，微软软件开发遵循着一种可称之为“靠改进特性（Feature）与固定资源（Resource）来激发创造力”的战略。该战略可分为五个原则：
将大项目分成若干里程碑式（Milestone）的重要阶段，各阶段之间有缓冲时间，但不进行单独的产品维护。
运用想象描述和对特性的概要说明（Program Specification）指导项目。
根据用户行为（User Behavior）和有关用户的资料确定产品特性及其优先顺序。
建立模块化的和水平式的设计结构，并使项目结构反映产品结构的特点。
靠个人负责和固定项目资源实施控制。
原则一：将大项目分成若干里程碑式的重要阶段，各阶段之间有缓冲时间，但不进行单独的产品维护。
项目进度安排与里程碑
微软通常采用“同步－稳定产品开发法”。典型项目的生命周期包括三个阶段：
计划阶段：完成功能的说明和进度表的最后制定
开发阶段：写出完整的的源代码
稳定化阶段：完成产品，使之能够批量生产（Roll Out）
这三个大阶段以及阶段间内在的循环方法与传统的“瀑布”（Water Fall）式开发方式很不相同，后者是由需求、详尽设计、模块化的代码设计与测试、集成测试以及系统测试组成的。而微软的三个阶段更像是风险驱动的、渐进的“螺旋”式的生命周期模型。
计划阶段的产品是想象性描述与说明文件，用来解释项目将做什么和怎么做。在管理人员拟定进度表、开发员写出代码之前，这些东西都促进了人们对设计问题的思考与讨论。开发阶段围绕三次主要的内部产品发布来进行；稳定化阶段集中于广泛的内部与外部测试。在整个产品生产周期中，微软都使用了缓冲时间的概念。缓冲时间使开发组能够对付意外的困难和影响到时间进度的变故，它也提供了一种手段，可以缓和及时发货与试图精确估计发货时间之间的矛盾。
在开发和稳定化阶段的所有时间中，一个项目通常会将2/3的时间用于开发，1/3的时间用于稳定化。（Office部门副总裁曾这样概述通常的进度：“一般说来，在总的进度表中，用一半的时间写出产品，留下另一半的时间调试或应付意外事故。这样，如果我有一个两年的项目，我会用一年来完成事先想好的东西……如果事情有点麻烦，我便去掉我认为不太重要的特性。”）。这种里程碑式的工作过程使微软的经理们可以清楚地了解产品开发过程进行到了哪一步，也使他们在开发阶段的后期有能力灵活地删去一些产品特性以满足发货时期的要求。
计划阶段
计划阶段是在一个项目的生命周期中，所有于开发前进行的计划所占用的时间。计划阶段产生出想象性描述、市场营销计划、设计目标、一份最初的产品说明、为集成其他组开发的构件而规定的接口标准、最初的测试计划、一个文档策划（印刷品和联机帮助形式的）以及一份可用性问题清单（Usability List）。计划阶段从想象性描述开始。想象性描述来自产品经理以及各产品单位的程序经理；它是对规划产品的市场营销设想，包括了对竞争对手产品的分析以及对未来版本的规划。想象性描述也可能讨论在前一次版本中发现面必须解决的问题以及应添加的主要功能。所有这些都基于对顾客和市场的分析以及从产品支持服务组处得到的资料。
说明文件从一个大纲开始，然后定义出新的或增加的产品特性，并对其赋以不同的优先级。说明文件只是产品特性的一个预备性概览；从开始开发到项目完成它要增加或变化20% - 30%。虽然在生命周期的后期说明变化一般较小，但越到后期，开发员就越是必须具充分的理由来作改变。
通常程序经理使用VB创建项目原型。他们也开展设计可行性研究以了解设计中的取舍情况，尽快做出涉及产品说明的决定。对于重要产品的说明需由公司高层领导进行复审。对于不太重要的产品，则由部分经理去完成。
开发阶段
开发阶段的计划对三四个主要的里程碑版本都逐个分配一组特性，规定出特性的细节和技术上的相关性，记录下单个开发员的任务以及对进度的估计。在开发阶段中，开发员在功能性说明的指导下写源代码，测试员写出测试项目组以检查产品的特性与工作范围是否正常，用户教育人员（User Education）则编写出文档草案。
当测试员发现错误时，开发员并不是留待以后处理，而是马上改正，并在整个开发阶段内使测试不断地、自动地进行。这就改善了产品的稳定性并且使版本发布日期更易估计。当达到项目中的一定阶段点后（40%时），开发员就试图“锁定”产品的主要功能要求或特性，从此只允许小范围的改动。如果在此点之后开发员想作大的改动，他们必须与程序经理以及开发经理进行讨论协商，也许还要征求产品部门经理的意见。
一个项目是围绕着3或4个主要的内部版本，或“里程碑子项目”来组织开发阶段的。一般用2至4个月来开发每一个主要的里程碑版本。每个版本都包括其自身的编码、优化、测试以及调试活动。项目为意外事故保留总开发1/3的时间，即“缓冲时间”（Padding Time）。（苹果公司的小组是割裂的、独立的，各自开发各自的东西。在还有3个月就要发货时，才会将所有的东西集成起来；Borland公司以一种渐近的方式进行开发，即把工作分成许多小的部分，并且总是让开发的东西能够运转。看起来似乎这种渐进的方法费时，但实际上几乎没有用过很长时间，因为这使你总是能掌握住事情真实的情况。）
当对最后一个主要的里程碑版本做了测试与稳定化之后，产品就要进行“外观固定”（UI Freeze），即确定产品的主要用户界面，如菜单、对话框以及文件窗口等。此后有关用户界面将不再进行大的改动，以免引进同步修改相应文档的困难。
稳定化阶段
稳定化阶段着重于对产品的测试与调试。项目在此阶段尽量不再增加新的功能，除非是竞争产品或者市场发生了变化。稳定化阶段也包括了缓冲时间，以应付不可预见的问题或者延迟。
下面我将Micosoft开发软件的模式用以下这张简图加以描述：（这张图对微软的测试进行了比较详细的描述，我个人认为微软的测试是Microsoft软件产品开发中一个十分重要也是十分有特色的分工。这是通
过在微软将近一年的观察和与国内同类企业的分析，我才得出这样的结论。大家都很明白，国内的软件开发商在这方面做得很不够，尤其不重视软件的内部测试，在他们的思想中，可能有一个误区：认为测试应该完全去由用户去负责，其实不然，在软件的开发流程中，软件的测试与开发是一种“矛与盾”的关系，互为补充，缺一不可。在微软，可能这种关系发挥到了极至：有时开发部门与测试部门互相较着劲，开发经理和测试经理的地位是相同的，有时甚至测试经理的地位甚至凌驾于开发经理之上，但他们之间没有根本的利益冲突，只有一个共同的目标：将产品的质量提高。）
补充一点：（对微软的测试流程加以简要的描述一下）微软内部，专门有一个小组负责为微软的工程师们提供日常工作和管理的工具软件，他们是非盈利机构，其主要任务是开发微软内部所需要的工具软件：例如：
SLM(Source Library Tree),源代码管理工具，负责管理软件开发过程中各个程序员的源码，各个程序员负责写自己的模块，每天将完成的代码Check-in到一个中央服务器的SLM树中，这个SLM树由预先定义好的脚本在固定的时间开始编译，通常这个过程需要好几个小时，所以微软内部根据各个项目组的情况有各自的规定：比如开发员必须在下班前（比如下午6：00）之前将当天修改的代码Check-in进去，这样SLM才开始编译。
第二天，QA组的各个测试员从服务器上下载前一天的一个Build开始测试，将测试的情况及时的反映到另外一个工具软件中：RAID（Raid is a tool for entering, tracking, analyzing, and reporting product defects during development and maintenance.）.这个工具负责管理产品的BUG情况，每个BUG包含很多属性：比如状态（活动的、解决的、关闭的）、严重级、优先级、哪个区域、哪个版本出现的、发现者、要将这个BUG赋给哪一个开发员等等一系列属性。还可以根据这个工具查询哪个开发员当天的BUG 活动的、解决的数量，哪个测试员的BUG质量数目等等一些基本的产品质量情况，这样项目经理可以很容易的掌握该项目的具体进展情况。如果在项目的开发中期，发现的BUG数目比解决的BUG数目持续的多（意味着该产品的活着的BUG越来越多），可能意味着这个项目出现了问题，决策者可以迅速的作出相应的决策，及时的纠正产品开发中出现的失误（微软曾经有很多产品因为这样的因素被Cancel了）。还有项目经理可以根据这个工具，及时的掌握、了解每个测试员和开发员的工作状态，这一点很重要。有很多人曾经说过：Microsoft凭借着SLM和RAID打败了无数的竞争对手，通过我在微软的经历，我看这话一点也不假。这两个工具确实是非常杰出的工具，微软将它们使用到了十分艺术的程度上，对微软的成功起着非常重要的作用。更难能可贵的是，目前这些工具在功能上还在不断的进行改进、升级，使得微软的工程师们工作起来更加如虎添翼、虎虎生风，这样的企业哪有不成功的道理?
在测试过程中，也不是随便的对软件产品毫无目的的瞎使用、乱使用，微软也有一套十分先进的方法和工具支撑着测试的每个方面：比如ATCM( Access Test Case Management)，一种基于Test Case（测试用例）的测试管理工具就承担着这方面的工作。
微软也许正是靠着“程序员的聪明和测试员的勤奋”构建起软件帝国的大厦、谱写着软件事业的辉煌。
Product Developing Process in Microsoft
上图中：QA是微软大的产品部门下设的一个比较专业的测试部门（Quality Assurance Dept）
项目进度表中的缓冲时间（Padding Time）
微软使用缓冲计划，以在最高的效率与较好地对未来作预计之间求得平衡。这种应付突发事件的时间在开发和稳定化过程中是每一个主要里程碑的一部分。缓冲时间主要用于弥补由于对特性（Feature）的不完全理解，或者是技术困难或是由于疏忽而忘记把任务写入进度，或者是未料到的难题而形成的漏洞。缓冲时间有助于一个项目适应意料之外的事件。
原则二：运用想象性描述和对特性的概要说明指导项目
为了给出足够的开发框架以使工作能持续进行，并且能容纳开发过程中出现的变化并保持足够的灵活性，微软采用想象性描述和概要的说明来指导项目开发，而不是在一开始就努力写出一份完整和详细的说明。所谓想象性描述是由程序经理和来自市场营销组的产品计划人员共同编写的一份非常短的文件，在其中主要是定义产品开发的目标（不涉及产品的具体细节！）。通常对一个全新的产品，想象性描述一般会相对较详细，在其中还含有一份粗略的说明文件。总的来说，微软对于想象性描述的要求是：
越短越好，尽量说明"产品不做什么"(而不是"产品要做什么"！)。
运用想象性描述，程序经理开始编写功能说明文件，该文件解释产品的特性是什么以及这些特性如何与其他特性及产品发生关系。最初它只是一个概要性的说明文件，随着项目的进展，程序经理会随时向其中添加更多的细节，最终的说明文件将变得象用户手册一样。完整的说明不只起着对产品最新功能的描述作用，而且它还是在产品投产与发货之前进行测试与评估的主要依据。
想象性描述有助于决定删除哪些特性。
微软内的各个开发组采用想象性描述帮助细化产品版本的规定主题，然后以此主题来决定是否需要增加产品各个可能的特性。通常不要轻易改变所确定的主题，否则可能造成产品开发上的混乱。
编写说明文件
说明文件在产品小组的所有成员之间，产品小组之间以及产品小组与管理部门之间起着传递产品的设想与要求的作用。在说明文件中必须清楚地描述产品特性（描述每个特性如何工作，外观如何以及从用户的角度出发如何与用户交互。如果特性有一个界面，还应包括一张示意图，以显示出界面的效果），并赋于其相应的优先级。程序经理据此建立起项目的开发进度表。此外在其中还应包括以下各项内容：用一句话表示的项目开发目的，关于产品是什么与不是什么的清单，对顾客的定义，对竞争产品的定义，产品对系统的要求（包括操作系统版本、最小内存要求、硬盘空间、处理器速度以及显示器分辩率），对第三方（如打印机驱动程序、组件）的任何依赖性。程序经理负责协调并"写下"说明
程序经理（Program Manager）应考虑以下问题：
这项特性的要点是什么？
用户如何使用该特性？
这项特性有意义吗？
该产品中或微软的其他产品中有类似的特性吗？
有哪些问题被遗漏了？
组内的交流令人满意吗？
最终程序经理通过与组内开发人员的共同讨论决定有关特性的内容，并将其写下来。
构造原型
构造原型是程序经理具体说明一件新产品或一个新版本的最好方法，这从许多方面来说都使开发前测试成为可能，尤其在可用性方面，并且有助于对与用户交互情况作出好的理解，它也能使产品说明更紧凑。
微软的开发人员通常采用VB构造用户界面原型，但是对于构造计算机屏幕模型之类的工作，画笔（Paint brush）也是一个很好用的工具。死板的说明变成有生命的文件，说明不应过于详细以至限制了发明创造。
在项目开发过程中，说明文件的早期版本会有相当大的增加与改变。由于说明的变动可能会导致相应开发工作的极大变动，所以微软通常是将精力首先集中于那些没有什么用户界面的特性上，因为在完成开发前不必去了解用户对它们有何反应，也就是说这些特性不大可能改变。然后再面对其它特性。但是当产品开发到一定程序后，例如40%之后，程序经理必须严格控制对特性的修改（主要是指增加新的特性），否则不光会造成开发延迟，而且会压缩可用的测
微软公司软件开发模式简介(下)
原则三：根据用户行为和有关用户的资料确定产品特牲及其优先顺序
对于一个开发项目而言，如何确定最终产品中应包含什么特性通常是比较困难的一件事。为此微软采用了一个称之为“基于行为制定计划”的方式来进行特性选择与优先级安排。
基于行为制定计划法从对用户行为，诸如写信或做预算，做系统研究开始。然后，根据某一特性在支持重要的或者是经常的用户行为上的程序对其进行评价。这样做的优点是对特性取舍更具理性：讨论对顾客想要做什么加以更好的安排，对某个给定特性是否方便了特定任务的更集中的辩论，可读性更强的说明，以及在市场营销、用户教育和产品开发中更好地同步。
特性选择和优先级安排中的基于行为制定计划
基于行为制定计划法中的关键点在于按用户行为、产品特性以及行为和特性之间的内部联系来分析产品。程序经理和产品计划者把产品试图支持的用户任务或方案分成大约20个“行为”，然后他们努力把行为（以及任何子行为）映射入微软的现行特性和竞争对手产品的特性中去。他们也把行为映射到不同的顾客形象或不同的市场部分中去。
当说明产品的新版本时，基于行为制定计划法帮助程序经理和开发员集中他们的精力与创造力。象Excel 之类的项目，争取在每个新版本中加入的主要行为不超过四个。绝大多数特性直接映射入这些行为之中。该做法使项目可以按特性对用户的价值来进行分级。通过分级，促使程序经理和开发人员都行动起来，使他们的特性支持尽可能多的行为。这种良性竞争对于用户有益，同时也利于提高生产率。
为顾客行为而非产品特性准备资料
基于行为制定计划进度，项目在计划阶段首先集中于行为，其次才是特性。程序经理和市场营销人员并不去思考和排除他们喜爱的特性，再围绕它们搞出想象性描述的草案。他们真正做的是列出一份顾客都做些什么的清单，然后把想象性描述集中于支持那些行为的特性上。
以行为为中心对产品进行全面考虑
由于基于行为制定计划法是从整个产品的观点着眼，因此有助于在不同职能上工作的项目成员理解产品做什么，以及其他产品的相应特性如何可能支持那些需要或不需要其他应用软件产品的行为。
做市场营销研究以支持基于行为制定计划法
为支持基于行为制定计划法，从市场营销组来的产品经理与程序经理、开发人员一起开展一些联合的研究，如指导对用户的研究工作。然而，一般来说是产品经理做大多数的研究，并可使其更明确地影响微软产品的演进。
原则四：建立模块化的和水平式的设计结构，并使项目结构反映产品结构的特点
微软产品设计中的一个关键概念是产品的基础结构（Infrastructure），尤其是生命周期短的应用软件，应随项目的进展变得更加单一（而不是错综复杂）。当开发组构造产品的第一版时，他们更多地使用分级式结构，好为产品设计规定出一个最初的架构。随着时间推移，他们向单一的结构迈进，以使项目能集中于特性开发。微软越来越强调不同产品间的特性共享。共享有助于使不同产品的“性能与感觉”（Look and Feel）都统一协调起来；它也方便了需要不只一个应用软件的用户，减少了代码的重复书写，缩小了单独一个应用软件的规模。
微软用特性小组组织产品开发，这种方法使得每个人都容易明白小组是如何与整个产品相关联的。项目从规定概要说明开始。概要说明的形式是一份已确定了优先级安排的内容清单，涉及产品下一版本将要开发的相对独立的特性，以便由分开的特性小组加以开发。
程序经理和开发员把项目分成特性子集，再将之分配给每个特性小组，让他们在3到4个主要的内部项目里程碑中进行生产。这种产品组织与开发方法使微软能靠简单地增加开发员和创建一个大的小组来渐进地增加产品的功能。
把特性(与函数)作为开发单位
微软软件产品的特性是用户最终可见的相对独立的功能单位，就如建筑材料一般，对应用软件产品更是如此。系统软件产品，如NT或者95的特性，对最终用户通常不直接可见。微软和其他公司有时简单地称这些不直接可见的特性为“函数”。
程序经理承担开发一组特性或函数，实现从说明经测试、文档化直到最后完成的过程。他们必须与开发员合作，后者负责估计进度表与完善每个特性。开发员还要在一台联网开发计算机上存储一到几个文件，用以保存特性的程序源代码。大多数特性的开发与改进只要一名开发员，而有的大型特性则要一个小的小组。
产品结构是决定其长期结构完整性的基石
产品结构是产品内部的基干，它规定了重要的结构构件以及这些构件如何组装到一起。产品结构及用于组装结构的构件，提供了实现产品特性（即做详细设计与编码）的支柱。产品的结构对最终用户而言，通常并非直接可见。只有结构要实现的特性是可见的。产品结构也是决定产品长期结构完整性的基石。产品功能的任何改变都不应造成潜在的产品结构散架。
产品的层次结构
对于产品，也可以采用层次结构的方法加以分析。通常定义良好的层次结构有助于对产品特性进行灵活的增加、删除与改进。此外良好的层次结构有助于产品在不同平台上的移植。（例如Excel总共定义了五层，其中只有最底层的操作系统层是与平台相关的，其它各层均是通过调用其下层所提供的API接口加以实现的，所以其移植极其方便。而在Windows 95中通过“虚拟机”的概念实现了对16位、32位以及DOS 程序的支持。）
小的结构文档：源代码是唯一文件
除了API文档，微软不对其产品结构生成相应的文档，虽然有时高级开发员可能会写下高层结构。对复杂的特性，许多开发员在某些点记录并复查特定于他们所负责的结构细节，但此工作是可选的，并不强制执行。除了源代码文件与特性说明，为数不多的组为新程序员准务了描绘某层结构的文档（主要的数据结构，如何工作等等）。但是这些文件并不时常更新，经理们也不要求项目组生成此类内部文档。在有关的说明
文件中，并不涉及实现问题。开发员应该知道如何去实现，或者能够去学会。记录的关于结构的文档如此之少是因为“一个开发员的工作是编写我们要卖的代码，而不是花时间写高水平的设计文件”，“设计文件不应与源代码分离”。分割代码与“保持事情的简单”。
特性小组和作为"内容专家"的小组领导
特性小组一般由一个领导和3至8名开发人员组成，工作于相关的特性领域。小组的规模常常视小组领导的经验和能力而定。特性小组领导向项目开发领导汇报并负责项目的全部开发工作；而项目开发领导则拥有对产品的更为全局性的观点，从而最有可能发现不互相关联的问题。在特性小组中的每个人均是此领域的“专家”，他们了解如何使用产品、了解竞争对手的产品、了解未来将向何处去。通常为便于交流，提高软件的组织结构（软件倾向于映射出构造它的组织的结构），应保持特性小组的小规模。
原则五：靠个人负责和固定项目资源实旋控制
对于软件项目而言，精确估计产品的开发与交付进度是很困难的。对此微软采取的方法是将进度安排和工作管理的责任推到最底层，即单个的开发人员和测试人员那儿去。这保证了每个人除了作为小组的一部分外，还负有个人的责任。单独的开发人员设立他们自已的进度表，程序经理把单独的进度表汇总起来，再加上缓冲时间，以制定出一个全面的项目进度表。顶层的总经理也固定人员与时间等基本资源，以确保项目集中并限制其努力与创造程序。
关键的目标，尤其对应用软件，是指明产品的目标出品日并争取尽可能长久地坚持它。程序经理和开发员从出品日回溯，规定中间的项目里程碑的日期。这个“固定的出品日法“的中心在开发员身上。以避免因为项目没有固定的结束点，导致在最终无用的设计、再设计和测试的循环中消耗一年或更多的时间。
开发人员做出他们自已的进度估计
“日期设定方法"。但是开发人员一般会做出较乐观的估计，因此开发经理还需对他们所提供的日期进行调整并加上缓冲时间以避免因因信息不完全而出现的问题。微软这种制定进度的方法的优点在于：它从人们那儿得到更多的合作，因为日期是自已定的，不是经理定的；进度总是富有进取性，因为开发人员不可避免地会低估他们真正需要的时间。
对细致的任务的进度估计
微软的第二个进度安排方法是：对要完成的任务做非常详尽的考虑，在此基础上请开发人员给出他们对“实现”的估计，以此力图“促使”更加现实主义并避免过度低估。
通常微软把任务细化到4小时（半天）到3天之间。对于准确进度的安排，微软的经理是这样认识的：“任何任务只要超过一星期，那人们就一定没有充分地全盘考虑它。任何任务某人估计只用少于半天就可完成，则他对它考虑得太多了。他应该用更多的时间去编程，更少的时间来考虑”。对于类似类于Windows NT 之类的操作系统而言，进度安排更加困难，对其一般以几天或者半周为工作单位进行进度估计。
安排开发人员与小组进度时的心理学
当项目变大时，微软把员工分成小组。然后经理把进度的责任和所有权尽可能地分发下去，直到小组和个人；这使二者都产生了一种拥用工作的感觉。它还在小组中，个人中，尤其是小组领导中造成强烈的跟上其它同事预计进度的压力，因为经理可能再平衡进度，从落后的小组或个人手中拿走工作。这样，同事间的压力使经理不需要太多的努力就可以对个人或单个小组的进程实施严格控制。
"固定的"出品日( RTM: Release To Manufacture)
为了把创造力约束在时间限制之中，微软现在在新产品或者产品新版本开始前争取固定出品日，至少是有出品日的内部目标。这给人们施加砍去特性和集中在一个项目上的压力，逼迫他们去苦苦思考应将哪个新特性加入产品中。虽然最终产品的交付目标可能是由高级执行人员设定，但是开发人员与小组仍然设定他们自已的进度表。
微软一般根据预先的时间进度的大致估计出一个RTM日期，然后向前回溯相应的各个Milestone日期，如RC、Beta、Tree Lock、UI Freeze、Feature Complete以及CC（Code Complete）等等各个Milestone 的相应日期。制定出十分详尽的产品研究开发时间进度表，产品开发组的各个成员以这个进度表为目标统一协调工作。微软十分强调软件开发过程中的Teamwork Spirits，这种理念贯穿在微软各个产品开发的各个阶段。这也是微软得以成功的一个十分重要的原因。
小结：同步－稳定开发法
计划阶段
定义产品的想象性描述、说明与进度
想象性描述产品和程序管理部门运用广泛的顾客意见来确定和优化产品的特性。
说明文件基于想象性描述，程序管理部门与开发组定义特性的功能，结构问题，以及各部分间的相关性。制订进度表与构造特性小组其于说明文件，程序管理部门协调进度表，安排出特性小组，每个小组包括大约1名程序经理，3 - 8个开发员，3 - 8个测试员(以1:1比例与开发员平行工作。)
开发阶段
用3 - 4个顺序的子项目，每个产生一个里程碑式的产品发送，来完成特性的开发。程序经理协调开发过程。开发员设计、编码、调试。测试员与开发员配对，不断进行测试。
子项目1 前1/3的特性：最重要的特性与共享的构件。
子项目2中间1/3的特性。
子项目3最后1/3的特性：最不重要的特性。
稳定化阶段
全面的内外部测试，最后的产品稳定化以及发货。程序经理协调OEM与ISV，监督从顾客得到的信息反馈。开发员进行最后的调试与代码稳定化。测试员发现并清除错误。
内部测试公司内部对整个产品做详尽的测试。
外部测试公司外在的"β"测试点，象OEM，ISV以及最终用户处对整个产品做详尽的测试。
发货准备为批量生产准备发布最后的“金盘”（Golden Disk）与文档，制作之前，还需要进行各种严格的检查：如政治敏感性术语检查、病毒检查、文件相关性检查等
成功软件开发者的9种编程习惯
李政和·yesky
好的原程序做出好的软件
有些人会想：只要程序运行结果好，就不管原程序编得怎样。但绝对不是这样的。软件不是一次性就作完的，有必要做修改，扩展等管理。所以原程序要尽量作成易看懂，管理方便。
这样做，第一是为了软件开发者方便，其次还会影响到软件的性能。管理不方便的程序不会作出好的软件。
希望通过这篇文章能学到好的编程习惯。要理解这文章的内容，你至少要懂得1个开发工具语言。这里举例说明的都是C语言，但你对C语言没有了解也不要担心。这里说明的是原理而不是特定的语言。
1. 语句要结束得彻底---(冒号；)
程序员经常有的失误之一是忘记在语句结束后加一个冒号。这样的问题点不易发现，时而让程序员不知所措。编程时要时时注意每个语句是否以冒号结束，虽然不是所有语言都以冒号结束。下面有忘记点冒号的例子。
int main(void)
{
/* 没有冒号，导致问题*/
printf("Hello World!\n")
return(0);
}
很多的人犯这样的错误。不到几条的程序是不难发现这样的问题，但1000条以上的程序里呢？查找那忘记写冒号了的语句不会是很容易的事。记住，结束一条语句，一定要写冒号，如同一般文章结束后点句号一样。
还有一种关于冒号的失误是不该写冒号的时候写冒号。有经验的程序员看到下面例子会觉得好笑，但笔者确实看到了很多这样的失误。
/* main() 后面不该写冒号*/
int main(int argc, char *argv[]);
{
printf("Hello World");
return(0);
}
函数或Method后面是不该写冒号的。
2. 要适合使用空格和tab键
C语言是不分辨空格的，因此程序也可以不需要空格一直写下去，但这样的程序会是谁都看不懂的"很有难度"的程序，请看以下例子：
if(x==0) {a=b=c=d=MAX; x++;}
这样写，也许会节省空间，但不仅别人，编程的本人也会很难看懂。程序要写得容易看懂！
if(x == 0)
{
a =
b =
c =
d = MAX;
x++;
}
这样写，看起来不很清楚吗？程序要有确切的空格才容易看得懂。
3. 统一使用大括号和切断方式
每个程序员使用大括号({})和改行的方式都有自己的习惯，这样，把程序移交给别人继续做的时候，会出现混乱。比如象以下例子：
int main()
{
int x = 1;
int y = 10;
while(x < y ){
printf("Value of x is %d\n", x);
x++;
}
}
有些程序员会这样写大括号：
int main()
{
int x = 1;
int y = 10;
while(x < y )
{
printf("Value of x is %d\n", x);
x++;
}
}
笔者是喜欢第二种方式。因为一段语句的开始和结束很明显。我们不能要求每个程序员都用某一种方式来编程，但一个程序里一定要统一。还有，看别人编的程序时要想到他人编程的习惯也许与你不同。
4. 不乱用if语句
软件开发过程管理规范文件管理序列号：[K8UY-K9IO69-O6M243-OL889-F88688]
0 引言 如果要提高软件开发人员的开发质量，必须有相应的考核制度，有了制度后才能推动开发人员想方设法改善自已的开发质量。目前研发对软件开发的过程缺乏细粒度的度量，所以不能依据有效的度量数据来考核开发人员的工作绩效，大部份只是凭考核人主观意志来考核，不能形成对被考核人有效的说服力。此绩效考核办法旨在结合实际情况合理客观地评价开发效率和质量。 1 目的 对软件开发的过程所产生的软件项的质量和过程进行定量的评价，用评价的结果指导软件的开发过程，不断地提高软件开发质量水平，并依据度量记录来考核软件开发人员的工作绩效。 2 软件项包括 1）技术文档：主要包括：可行性分析报告、需求分析报告、软件功能规格说明、开发计划、系统设计报告、测试文档、用户手册、总结报告等； 2）计算机程序。 3 度量数据的来源 1）项目计划； 2）评审报告； 3）测试报告； 4）问题报告； 5）软件维护记录； 4 质量度量
4.1 度量指标 主要根据各类软件项检查表的检查指标来确定，例如，软件需求规格说明书检查表（见附录1），有10个检查指标，则根据具体项目检查侧重点不同，可从中选择相应的检查指标作为度量指标。 4.2 质量等级 1）软件项的质量等级的确定根据度量综合指标进行。 2）度量综合指标计算公式为：Total = ∑QiMi。 3）其中i=1,2,...n代表指标数量； 4）Q代表度量的指标； 5）M代表度量的指标Q在整个指标体系中所占的权重系数，对不同的开发项目可能不同，此系数根据开发的不同着重点给出。 度量指标权重系数表： 序号指标权重 1 指标1 权数1 2 指标2 权数2 3 指标3 权数3 4 指标4 权数4 5 指标5 权数5 加权平均分 1.0 6）质量评价：一般地，根据度量综合指标值，有以下评分标准。 质量评价计分标准表 序号得分质量评价
微软公司的历史 微软公司是世界PC机软件开发的先导，比尔·盖茨是它的核心。微软公司1981年为IBM-PC 机开发的操作系统软件MS-DOS曾用在数以亿计的IBM-PC机及其兼容机上。但随着微软公司的日益壮大，Microsoft与IBM已在许多方面成为竞争对手。1991年，IBM公司和苹果公司解除了与微软公司的合作关系，但IBM与微软的合作关系从未间断过，两个公司保持着既竞争又合作的复杂关系。微软公司的产品包括文件系统软件（MS-DOS和Xenix）、操作环境软件（窗口系统Windows系列）、应用软件MS-Office等、多媒体及计算机游戏、有关计算机的书籍以及CDROM产品。1992年，公司买进Fox公司，迈进了数据库软件市场。 1975年，19岁的比尔·盖茨从哈佛大学退学，和他的高中校友保罗·艾伦一起卖BASIC 语言程序编写本。当盖茨还在哈佛大学读书时，他们曾为MITS公司的Altair编制语言。后来，盖茨和艾伦搬到阿尔伯克基，并在当地一家旅馆房间里创建了微软公司。1979年，MITS公司关闭，微软公司以修改BASIC程序为主要业务继续发展。 1977年，微软公司搬到西雅图的贝尔维尤(雷德蒙德)，在那里开发PC机编程软件。1980年，IBM公司选中微软公司为其新PC机编写关键的操作系统软件，这是公司发展中的一个重大转折点。由于时间紧迫，程序复杂，微软公司以5万美元的价格从西雅图的一位程序编制者帕特森手中买下了一个操作系统的使用权，再把它改写为磁盘操作系统软件（MS-DOS）。公司目前在60多个国家设有分支办公室，全世界雇员人数接近44,000人。 IBM-PC机的普及使MS-DOS取得了巨大的成功，因为其他PC制造者都希望与IBM兼容。MS-DOS在很多家公司被特许使用，因此80年代，它成了PC机的标准操作系统。到1984年，微软公司的销售额超过1亿美元。随后，微软公司继续为IBM、苹果公司以及无线电器材公司的计算机开发软件，但在91年后，由于利益的冲突，IBM、苹果公司已经与Microsoft 反目。1983年，保罗·艾伦患霍奇金氏病离开微软公司，后来成立了自己的公司。艾伦拥有微软公司15%的股份，至今仍列席董事会。1986年，公司转为公营。盖茨保留公司45%的股权，这使其成为1987年PC产业中的第一位亿万富翁。1996年，他的个人资产总值已超过180亿美元。1997年，则达到了340亿美元，98年超过了500亿大关，成为理所当然的全球首富。 微软的拳头产品Windows98/NT/2000/Me/XP/Server2003成功地占有了从PC机到商用工作站甚至服务器的广阔市场，为微软公司带来了丰厚的利润：公司在Internet软件方面也是后来居上，抢占了大量的市场份额。在IT软件行业流传着这样一句告戒：“永远不要去做微软想做的事情”。可见，微软的巨大潜力已经渗透到了软件界的方方面面，简直是无孔不入，而且是所向披靡。微软的巨大影响已经对软件同行构成了极大的压力，也把自己推上了反垄断法的被告位置。连多年来可靠的合作伙伴Intel也与之反目，对薄公堂。2001年9月，鉴于经济低迷，美国政府有意重振美国信息产业，拒绝拆分微软。至此，诉微软反垄断法案告一段落。 微软的产品微软生产的软件产品包括了很多的种类： Windows -称为「视窗」的图形操作系统；它有很多版本。目前桌上版最新版本是Windows XP，服务器最新版本是Windows Server 2003。Windows几乎预装在所有的IBM 兼容的个人电脑上。请参看Microsoft Windows的历史获取更多详细资料。 MS-DOS -微软公司的早期产品，它是一个命令行界面。早期的Windows版本要在MS-DOS下运行，但是到了Windows NT以及以后的产品已经可以脱离MS-DOS运行了，但基于用户因软硬件在Windows NT不能正常运作，微软同时间继续推出Windows 95, Windows 98, Windows Me在MS-DOS下运行的过渡产品。 Microsoft Office -它是微软公司的办公软件套件，根据版本不同可能包括Word（文字处理）、Excel（试算表）、Access（桌面数据库）、PowerPoint（幻灯片制作）、Outlook
快视信息软件开发流程规范： 用户需求：软件项目首先由客户经理(CM，Custom Management)接洽客户的较大的需求。这时的需求叫市场需求（或叫用户需求），客户经理会进行各个项目的安排，即对项目的启动时间和发布时间进行规划和设置。 项目经理(PM，Project Management)对客户经理负责。项目经理的需求是根据客户经理给的，项目经理不和用户（客户）直接接触（通过客户经理接触），负责和用户进行需求洽谈和沟通的是客户经理。一个项目的需求在一般情况下是不准变更的，如果有需求理解方面的不清楚可以进行沟通，但是需求是不变更的。如果用户有新的需求，一般规划在下一个版本中。因为需求变更了，这个目的时间就要进行调整，就不能按计划进行和完成。客户经理提交给项目经理的是需求规格说明书。 一、项目开工会 在项目经理领到客户经理分配给的需求后，做项目计划，具体做项目人员的确定、需求的分解（需求分解到每个人）、代码量的估计，项目各个阶段时间的划分和工作量的计划、质量指标的设定。这时项目经理需要输出的文档是项目需求分解任务书、项目计划PPT、及做好整个项目需要填写的一系列表格。然后组织项目组成员和客户经理CM、QA(质量审计经理)进行项目开工会。这时这个项目就算真正启动，计算工作量时，即计算这个项目总共花了多少个工时，工时是项目经理做计划的时间也算在内，再加上项目开工会和后续各个阶段总共花的总工时数，还有各个阶段开会所花的时间。在项目开工会上，各个成员就明确了这个项目是属于增强型项目，还是其他项目的项目性质，增强型项目的意思是说在原来上一版本的基础上又根据新的需求进行增强型开发。还有要明确项目最后开发出的新增代码量有多少，最后要明确每个人的需求任务，接下来着手进行SRS的写作。 二、SRS阶段：System/Software Requirment Specification 软件需求规格说明 在项目开工会后，项目组就开始按照在项目开工会上项目经理的需求任务分解的任务开始进行SRS的写作。 一般项目经理给你的一个子需求任务，你这时需要分解为更小的需求。一般一个需求的写作是按这样进行的。先简单介绍这个需求，然后把这个需求设计成黑盒的形式，即输入，处理过程、输出。这些都需要写详细，任何一个需求都写成这种形式，输入是什么，处理过程是什么，输出结果是什么。处理过程需要用Visio或者PPT画出处理流程图，流程图要很详细。每一步的各种情况都要表示和考虑到。对异常情况也要考虑和进行处理。还有要说明在原来的基础上怎么改动，具体方法要进行说明。设计的数据库表结构，要给出脚本，SQL语句，表结构需说明每个字段，哪些是主键，你在这个需求处理过程中哪里使用了哪些表，需要进行哪些操作，都需要说明。这里需要设计和编制《数据库设计说明书》文档。该文档中描述该系统中设计出的所有的数据库表结构和各字段类型。还有多个操作对象要画序列图表示出按时序的处理过程。这个SRS文档就相当于我们平时毕业设计或者一个题目的详细设计阶段达到的水平，甚至比它更详细。每个项目组成员都把自己的需求的SRS文档写出来之后放到配置库中，然后每个人对项目组其他成员的（非自己的）SRS文档进行Review（评审）,对每个SRS文档在每页发现或者纠正的错误数不能低于一定的数目，而且要保留批注记录，经过Review的（保留批注的）文档要放到配置库的Review文件夹下，这是进行项目质量指标收集的重要依据，是QA 进行调阅和审计的资料。项目经理要对SRS文档、SRS Review文档进行汇总。在汇总后组织项目组全体成员进行SRS阶段会议，对每个人写的SRS进行评审会议（讨论和提意见），对别人给你提的修改意见你要一一进行说明，说明为什么不改，怎么改的，是什么问题，问题严重程度属于什么级别，而且都要填表，也是QA进行审计的内容。开完会后如果每个人完成的都差不多，然后安排半天或者一天的时间进行返工，主要是进行修改文档，按在会上讨论的结果和别人给你的Review 文档结果（评审结果）进行准一修改和完善。然后再进行SRS阶段开会，如果都做的比较到位和具体、符合要求，即关闭SRS阶段。这时SRS阶段的花费的工时数和一些质量活动指标就出来了，比如你这个SRS文档写了几页，每页的错误数是多少，返工修改用了多少时间，然后这些这个比率也会自动计算出来。进而可以判断这个阶段的质量。每个项目组成员在每天工作完毕后都要进行Time Sheet 的填写，必须具体到半个小时，这是统计和分析的需要。填写必须真实。 三、UTP、STP阶段（UTP、STP写作） UTP Unit Test Plan 单元测试计划 STP System Test Plan
【最新资料,Word版，可自由编辑！】
目录 1.前言 (3) 1.1 目的 (3) 1.2 对象 (3) 1.3 要求 (3) 1.4 适用范围 (3) 1.5 软件开发过程模型 (3) 1.6 开发过程划分 (4) 2.技术过程规范部分 (4) 2.1 概述 (4) 2.2 业务建模阶段 (4) 2.3 需求阶段 (6) 2.4 分析设计阶段 (8) 2.5 实现阶段 (10) 3.管理过程规范部分 (11) 3.1 概述 (11) 3.2 接受项目 (12) 3.3 重新评估项目范围和风险（对于较大项目） (12) 3.4 制定开发计划 (13) 3.5 迭代开发管理 (13) 3.6 监控项目的实施 (14) 3.7 结束项目 (15)
软件开发过程规范 前言 目的 本规范的目的是使整个软件产品开发及项目工程阶段清晰，要求明确，任务具体，便于规范化、系统化及工程化。有利于提高软件生命周期的控制及管理，提高所开发软件的质量，缩短开发时间，减少开发和维护费用，使软件开发活动更科学、更有成效。 对象 本规范面向产品生命周期的所有相关人员，包括管理人员、开发人员、质管人员。 要求 具有软件开发管理职能的人员要求熟知项目开发的各阶段过程和各阶段过程相应的规范。 适用范围 适用于产品开发生命周期中的除产品提交外的其他全部过程；规范分为两部分：技术过程规范和管理过程规范，分别适用于软件开发过程中的技术性活动和管理性活动。 软件开发过程模型 本规范所采用的软件开发过程模型为简化的RUP开发过程模型；软件开发过程是体系结构为中心，用例驱动和风险驱动相结合的过程迭代。
软件开发过程详解 软件开发过程即软件设计思路和方法的一般过程，包括设计软件的功能和实现的算法和方法、软件的总体结构设计和模块设计、编程和调试、程序联调和测试以及编写、提交程序。 生产一个最终能满足需求且达到工程目标的软件产品所需要的步骤。软件开发过程覆盖了需求、设计、实现、确认以及维护等活动。需求活动包括问题分析和需求分析。问题分析获取需求定义，又称软件需求规约。需求分析生成功能规约。设计活动一般包括概要设计和详细设计。概要设计建立整个软件系统结构，包括子系统、模块以及相关层次的说明、每一模块的接口定义。详细设计产生程序员可用的模块说明，包括每一模块中数据结构说明及加工描述。实现活动把设计结果转换为可执行的程序代码。确认活动贯穿于整个开发过程，实现完成后的确认，保证最终产品满足用户的要求。维护活动包括使用过程中的扩充、修改与完善。 1.需求分析 1.1 需求分析的特点和任务 需求分析是软件开发的第一步。获取需求的一个必不可少的结果是对项目中描述的客户需求的普遍理解。一旦理解了需求，分析者、开发者和客户就能探索出描述这些需求的多种解决方案。参与需求获取者只有在他们理解了问题之后才能开始设计系统，否则，对需求定义的任何改进，设计上都必须大量的返工。把需求获取集中在用户任务上—而不是集中在用户接口上—有助于防止开发组由于草率处理设计问题而造成的失误。有几种原因使需求分析变得困难：（1）客户说不清楚需求；（2）需求自身经常变动；（3）分析人员或客户理解有误。 需求获取、分析、编写需求规格说明和验证并不遵循线性的顺序，这些活动是相互隔开、增量和反复的。当你和客户合作时，你就将会问一些问题，并且取得他们所提供的信息（需求获取）。同时，你将处理这些信息以理解它们，并把它们分成不同的类别，还要把客户需求同可能的软件需求相联系（分析）。然后，你可以使客户信息结构化，并编写成文档和示意图（说明）。下一步，就可以让客户代表评审文档并纠正存在的错误（验证）。这四个过程贯穿着需求分析的整个阶段。需求获取可能是软件开发中最困难、最关键、最易出错及最需要交流的方面。需求获取只有通过有效的客户—开发者的合作才能成功。分析者必须建立一个对问题进行彻底探讨的环境，而这些问题与产品有关。为了方便清晰地进行交流，就要列出重要的小组，而不是假想所有的参与者都持有相同的看法。对需求问题的全面考察需要一种技术，利用这种技术不但考虑了问题的功能需求方面，还可讨论项目的非功能需求。确定用户已经理解：对于某些功能的讨论并不意味着即将在产品中实现它。对于想到的需求必须集中处理并设定优先级，以避免一个不能带来任何益处的无限大的项目。 1.2.需求分析的一般方法
1、需求分析是怎样做的？（自己理解着说） 需求分析是构建软件系统的一个重要过程。 一般，把需求类型分成三个类型： 1、业务需求（business requirement）反映了组织机构或客户对系统、产品高层次的目的要求，它们在项目视图与范围文档中予以说明。 2、用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务，这在使用实例文档或方案脚本说明中予以说明。 3、功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。 业务需求和用户需求是软件需求分析的基础，也是软件构建的前提。系统分析员通过对业务需求和用户需求的分解，将其转换成克一形式化描述的软件功能需求。开发软件系统最为困难的部分，就是准确说明开发什么。这就需要在开发的过程中不断的与用户进行交流与探讨,使系统更加详尽,准确到位。这就需要确定用户是否需要这样的产品类型以及获取每个用户类的需求。 4、客户也经常是矛盾的。事实上，很少有客户能够明确的知道怎样的一个系统对自己是最有益处的，他们往往在集中方案之间徘徊，于是经常产生需求的变动。生产厂商经常陷入客户自己的矛盾之中。 客户的负面影响可能对于能够在预算内按时完成项目产生很大的影响。尽管客户需要对需求的质量负责任，但是，当一个软件项目因为客户事先没有预料到的情况而导致失败的时候，即使客户不会追究开发方的责任，就软件项目本身而言，也已经是失败的。 总结： 良好的需求分析是软件成功的基础。以上是作者对需求分析工作实践的一次小结以及综合性的思考，是对需求分析本身所做的一次分析。在此基础上，作者提出了逆向沟通的设想，即系统分析员主动进行沟通，提出指导性意见。当软件融合了客户和系统分析员双方智慧，其质量将会进一步得以提高。 2、 6周 （比较合理的代码行数是多少，如果多了，我是怎么切割的）500行，例如：实现数据3、如何将用户登录的信息保存？ 用户登陆页面将每个用户的信息使用session保存下来,例如: session.setAttribute("UserID","ytang"); 如果用到用户的登陆信息，再从session根据session.getAttribute("userID")所存储的信息例如在项目1中的应用 4．软件项目开发流程应该是什么样子的？ 1。需求分析和获取； 2。界面的设计和修改，直到用户可以接受； 3。后台数据库的建立，做成几张表，写几个存储过程； 4。前台模块的编写和调试； 5。项目的实施和维护；
软件构架师培训项目简介 软件构架（Architecture ）是软件工程中发展迅速的一个研究实践领域。软件构架师从软件产品的角度讲，是软件企业新的产品、新的技术体系的构建者；从构架师个人利益角度讲，是提高个人身价与收入的资本；从软件企业角度讲，具有足够数量的构架师是承接外包项目的前提条件。根据IDC 的估计，近年中国的构架人才缺口在2万人以上，是目前软件开发中急需的高层次技术人才。 微软（中国）有限公司顾问咨询部．．．．．（微软在中国的核心技术．．．． 部门）的资深专家及管理人员整合微软公司近三十年来积累的构架设计及开发经验有系统、有组织地与国内软件企业分享。软件构架师高级培训面向国内大中型软件开发商．．．．．．．．．．、方案提．．．供商．．、应用开发商．．．．．以及相关软件企业的研发和技术人员．．．．．．．．．．．．．．。微软公司和中国国信信息总公司真诚希望通过与中国软件企业分享微软先进的管理经验和实践感悟，切实地帮助中国软件企业培养高级软件构架技术人才，提升整体研发能力，建立符合中国国情的软件开发架构设计体系，从而加快国内软件产业的发展。 课程 本次授课不同于市场上以介绍某一软件平台为内容的所谓的软件构架课程，它是开发的任何软件产品所采用的解决问题的思路和方法，是解决人和软件构架问题的通．．．．．．．．．．用的方法．．．．论．，体现了课程本身极强的通用性。您能够从微软经验的分享中领悟到软．件构架设计的精髓和技巧．．．．．．．．．．．，结合您企业的实际情况加以应用，为您的事业发展助上一臂之力。 讲师 本次软件构架师培训由微软首席行业技术策略及架构师．．．．．．．．．．．．．．亲自授课，讲师除了有丰富的培训经验外还有一定的海外工作及培训经历。软件构架师的培训注重素质和能力．．．．．．．的培养．．．。我们旨在帮助软件企业完善软件开发流程，改善软件开发质量和效率并提升企业的整体竞争力。 授课 微软软件构架师高级培训采取小班教学，力求讲师和学员在教学上的充分互动，采取了现场模拟、角色扮演、案例分析和群体讨论．．．．．．．．．．．．．．．．．．．等各种灵活形式，并注重同国情及最佳实践的结合，充分鼓励学员间的经验分享及问题探讨，强调培训的有效性和实用性。 品牌 本课程的主办方微软公司是全球最大．．．．的软件公司，中国国信总公司是国内最大．．．．的电子政务建设单位之一。 证书
标准的软件开发过程 软件开发的标准过程包括六个阶段，而六个阶段需要编写的各类文件达14种之多，在每个阶段需要编写哪些文件，以及这些文件的主要内容见下： 1.可行性与计划研究阶段 可行性研究报告：在可行性研究与计划阶段内，要确定该软件的开发目标和总的要求，要进行可行性分析、投资一收益分析、制订开发计划，并完成应编制的文件。 项目开发计划：编制项目开发计划的目的是用文件的形式，把对于在开发过程中各项工作的负责人员、开发进度、所需经费预算、所需软、硬件条件等问题作出的安排记载下来，以便根据本计划开展和检查本项目的开发工作。 2.需求分析阶段 软件需求说明书：软件需求说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解，使之成为整个开发工作的基础。内容包括对功能的规定对性能的规定等。 数据要求说明书：数据要求说明书的编制目的是为了向整个开发时期提供关于被处理数据的描述和数据采集要求的技术信息。 初步的用户手册：用户手册的编制是要使用非专门术语的语言，充分地描述该软件系统所具有的功能及基本的使用方法。使用户（或潜在用户）通过本手册能够了解该软件的用途，并且能够确定在什么情况下，如何使用它。 3.设计阶段 概要设计说明书：概要设计说明书又可称系统设计说明书，这里所说的系统是指程序系统。 编制的目的是说明对程序系统的设计考虑，包括程序系统的基本处理流程、程序系统的组织结构、模块划分、功能分配、接口设计。运行设计、数据结构设计和出错处理设计等，为程序的详细设计提供基础。
详细设计说明书：详细设计说明书又可称程序设计说明书。编制目的是说明一个软件系统各个层次中的每一个程序（每个模块或子程序）的设计考虑，如果一个软件系统比较简单，层次很少，本文件可以不单独编写，有关内容合并入概要设计说明书。 数据库设计说明书：数据库设计说明书的编制目的是对于设计中的数据库的所有标识、逻辑结构和物理结构作出具体的设计规定。 测试计划初稿：这里所说的测试，主要是指整个程序系统的组装测试和确认测试。本文件的编制是为了提供一个对该软件的测试计划，包括对每项测试活动的内容、进度安排、设计考虑、测试数据的整理方法及评价准则。4.实现阶段 模块开发卷宗（开始编写）：模块开发卷宗是在模块开发过程中逐步编写出来的，每完成一个模块或一组密切相关的模块的复审时编写一份，应该把所有的模块开发卷宗汇集在一起。 编写的目的是记录和汇总低层次开发的进度和结果，以便于对整个模块开发工作的管理和复审，并为将来的维护提供非常有用的技术信息。 用户手册完工 操作手册：操作手册的编制是为了向操作人员提供该软件每一个运行的具体过程和有关知识，包括操作方法的细节。 测试计划终稿： 5.测试阶段 模块开发卷宗(此阶段内必须完成) 测试分析报告：测试分析报告的编写是为了把组装测试和确认测试的结果、发现及分析写成文件加以记载。 项目开发总结报告：项目开发总结报告的编制是为了总结本项目开发工作的经验，说明实际取得的开发结果以及对整个开发工作的各个方面的评价。
亿赛德信息科技有限公司 作者：亿赛德软件 全国通用：4oo-o8o-o574 亿赛德信息科技有限公司是一家专业从事软件开发、软件定制、软件实施的高新技术企业。拥有一批长期专业从事软件开发、软件定制的专业人才，具有雄厚的技术开发实力，全方位满足政府与企业信息化需求。 公司非常重视企业的内部管理工作，市场销售、软件研发、技术支持是公司的三大核心部门，现已经建立了一套比较完善的管理体制。在客户服务方面，本着为客户服务的思想，设立了24小时产品咨询电话、24小时售后技术支持电话等多个无障碍通道，为客户提供了高质量的售前和售后的服务，为亿赛德软件“‘软硬’融合之剑，开辟信息创新之路！”的目标提供了强有力的支持。 公司主营业务包括软件外包、软件定制开发、系统维护、OA办公系统、手机软件定制等等。 亿赛德软件领域经过十多年的经验积累，总结出了针对各行业、不同规模和不同阶段的企业信息化解决方案，我们的项目实施团队能够更加准确快捷地找出客户的具体需求，为您的企业度身定做真正切合实际需求的解决方案。我们实施方面多年的实践积累与将为您的企业带来最大投资回报。 亿赛德提供符合软件整个开发生命周期的过程服务。 亿赛德提供的服务：定制应用开发，实施电子商务网站，移动和无线应用发展，垂直搜索引擎等。 亿赛德提供产品：楼宇能耗系统、4S店管理软件综合平台、大型门户软件、项目综合管理系统、车辆GPS跟踪定位系统、育苗工厂无线监管系统、无线生产流程管理系统、工资核算管理系统、外贸订单跟踪管理系统、移动外勤管理平台、政府内外网、行业门户软件、垂直及时搜索引擎等。 配套的硬件包括：手机系统、条码技术、RFID技术、短信猫、GPRS传输、手持机、触摸屏、采集器、能源监测等多种配套硬件。 服务理念：技术为本，服务制胜 客户的感动源于我们高度的责任感、敬业精神与专业素质。帮助客户不断创造价值，才能实现自身价值的升华,亿赛德软件助力您企业的发展，实现共赢。
（1）软件开发过程是什么？ 软件开发过程是按照软件工业化的标准定义的心之所向，所向披靡 ?在软件开发中必须具有的一系列过程规范； ?软件开发过程是定义在软件中的软件需求、软件设计、软件编码、软件测试、软件部署的实现目标和规范化的管理方法论； ?软件开发过程是保证软件工业化生产的法典；?软件开发过程做的是：定义标准和为了达到标准的路； ?软件开发过程要改善的是：软件开发的效率和质量； ?软件开发过程的实现最重要的是：人。 （2）大多数软件项目失败的原因： a)不完整、不现实的项目需求 b)对需求的变更束手无策 c)脆弱的架构 d)采用不成熟的技术 e)测试的不充分性 f)拙劣的进度计划和评估 g)缺乏资源 h)不具备项目管理方法 i)缺少管理层的支持 （3）软件工程的三个要素：方法、工具和过程（4）A software project failed if It is delivered late It is runs over the budget It does not satisfy the customer’s need It is of poor quality Classical software development methods have not solved software crisis.传统的软件开发方法没有能够解决软件危机。 （5）A software engineer’s job: a)Make a working plan.制定工作计划 b)Carry out it.(Do their work according to this plan)按照此计划工作 c)Try his/her best to produce high-quality products.尽最大努力生产 出高质量产品 (6)3 Key aspects a)Quality products 高质量产品 b)Expected costs c)On agreed schedule （7）Summary of PSP PSP is a framework designed to teach software engineers to do better work Estimate and plan →track →improve quality Quality methods take time to learn and practice,but it will help you in you engineering career Establish goals →measure quality → understand the process → change and reure process → measure & analyze the results → recycle improving Identify the tasks you do (8)敏捷软件开发宣言 个体和交互胜过过程和工具 可以做到工具的软件胜过面面俱到的文档 客户合作胜过合同谈判 响应变化胜过遵循计划 敏捷开发的原则： 1、我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。 尽早交付具有部分功能的系统和质量系统之间具有很强的相关性 2、即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。 关于态度的声明，敏捷过程的参与者不惧怕变化，努力保持软件结构的灵活性。 3、经常性地交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间越短越好。 关注的目标是交付满足客户需要的东西。它们是敏捷实践区别其他过程的特征所在。 4、在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。 有意义的、频繁的交互，必须对软件项目进行持续不断地引导。 5、围绕被激励起来的个人来构建项目。给他们提供所需要的环境和支持，并且信任他们能够完成工作。 人被认为是项目取得成功的最重要的因素。 6、在团队内部，最具有效果并且富有效率的传递信息的方法就是面对面的交谈。首要的、默认的沟通方式。 7、工作的软件是首要的进度度量标准。 敏捷项目通过度量当前软件满足客户需求的数量来度量开发速度。 8、敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期、恒定的开发速度。不是 50米短跑，而是马拉松。以快速但是可持续的速度行进。 9、不断关注优秀的技能和好的设计会增强敏捷能力。
亿赛德信息科技有限公司 亿赛德信息科技有限公司是浙江宁波一家专业从事软件开发、软件定制、软件实施的高新技术企业。拥有一批长期专业从事软件开发、软件定制专业人才，具有雄厚的技术开发实力，全方位满足政府与企业信息化需求。 公司非常重视企业内部管理工作，市场销售、软件研发、技术支持是公司的三大核心部门，现已经建立了一套比较完善的管理体制。在客户服务方面，本着为客户服务的思想，设立了24小时产品咨询电话、24小时售后技术支持电话等多个无障碍通道，为客户提供了高质量的售前和售后的服务，为亿赛德软件“‘软硬’融合之剑，开辟信息创新之路！”的目标提供了强有力的支持。 公司主营业务：软件外包、软件定制开发、系统维护、OA办公系统、手机软件定制等等。 亿赛德软件经过十多年的经验积累，总结出了针对各行业、不同规模和不同阶段的企业信息化解决方案，我们的项目实施团队能够更加准确快捷地找出客户的具体需求，为您的企业度身定做真正切合实际需求解决方案。我们实施方面多年的实践积累将为您的企业带来最大投资回报。 亿赛德提供符合软件整个开发生命周期过程服务。 亿赛德提供的服务：定制应用开发，实施电子商务网站，移动和无线应用发展，垂直搜索引擎等。 亿赛德提供产品：楼宇能耗系统、4S店管理软件综合平台、大型门户软件、项目综合管理系统、车辆GPS跟踪定位系统、育苗工厂无线监管系统、无线生产流程管理系统、工资核算管理系统、外贸订单跟踪管理系统、移动外勤管理平台、政府内外网、行业门户软件、垂直及时搜索引擎等。 配套的硬件包括：手机系统、条码技术、RFID技术、短信猫、GPRS传输、手持机、触摸屏、采集器、能源监测等多种配套硬件。 服务理念：技术为本，服务制胜 客户的感动源于我们高度责任感、敬业精神与专业素质。帮助客户不断创造价值，才能实现自身价值的升华,亿赛德软件助力您企业发展，实现共赢。 服务领域 1.信息化解决方案提供
软件开发过程 一. 规范 规范应当是从简单到复杂的，我们首先制定的规范并不复杂，只是对如何使用异常机制的一些定义。要获得这些规范并不困难，大部分介绍异常的技术资料中都给出了很多的建议。理解并使用它们，仅此而已。 1、对不正常的条件使用异常，尽可能准确的使用预定义的异常。这一目标来自于Effective Java中的条款39和条款42。其目的是为了能够正确的使用异常。使用系统提供的异常能够减少代码，提高代码的可读性（特别是新人不需要了解自定义的异常结构）。大多数情况下，系统提供的异常已经足够用了。 2、尽可能多的收集异常发生时的上下文信息。异常之所以比返回码优秀的一个原因就是它能够将错误类型化，提供比错误代码多得多的信息。因此，我们实在没理由不使用这一功能。 3、正确的使用异常转义，并保留原异常信息。异常转义的目的是为了让客户端能够得到易于理解的类型。我们想象一个用户登录的情境，假设用户数据保存在一个文件中，当文件中找不到用户名的相关记录的时候抛出一个RecordNotFoundException异常，系统截获了这个异常，并将其发布给用户，问题在于，用户会觉得非常的奇怪，为什么会是记录没有找到呢？因此，建立一个IllegalUserException异常会更适合于这种情况。 4、针对不同的抽象层次定义不同的异常。正如我们在第三点中提到的，RecordNotFoundException异常并不适合于用户这个层次。但是，这个异常对于程序员调试代码就很有意义了。 5、将异常发布到合适的地方。有计算机的地方就一定有输入和输出。如果把异常发生时的信息收集看作输入，那么异常的输出是什么呢？可能是错误的提示信息，可能是一个显示错误信息的网页，可能是日志中的记录，可能是一条短信，也可能是一封EMail。这些就是异常的输出形式。此外，异常的输出还需要正确的确定对象，对用户来说，异常只要有一个友好的提醒方式就够了，但对于管理者来说，异常需要记录下来，或是通过异步消息进行通知。 这就是规范，你也可以把它称为最佳实践、建议等名词。当然，它还可以更加的细化，但事情总有个过程，一开始把问题弄得过于复杂未必是一件好事，你说呢？ 二．技能 有了规范是一回事，能否把规范运用起来则取决于人员的技能。在有一部描述清末的电影中，有这样一个情节，留学归来的知识分子为了提高民众的知识水平，不惜花费巨资免费发放报纸，这一举措大受欢迎，可惜大部分的民众都不识字，他们要报纸的原因只是这东西烧火很方便。 所以其次要解决的问题就是，大部分的程序员没有足够的异常处理经方面的技能。如果程序员没有这方面的概念，你把一本异常管理最佳实践放在他的面前会有用吗？ 学会使用异常并不困难，困难的是如何让程序员正确的使用异常。什么时候使用系统定义的异常。什么时候使用自定义的异常，自定义异常又该如何设计。这些都是程序员的技能问题。基于这种思路，首先做的是培训，而培训的目标是让程序员理解异常的机制，让程序员能够把异常运用到工作中。培训不等于上课，因为我们的目标是能够影响程序员的行为，单靠上课是无法达成目标的，因此我们把几种方式综合使用。一般来说，程序员对未知的技术总是
软件项目开发和管理规范 本文阐述软件项目开发和管理的流程规范，作为软件项目开发的高级指引，本规范定义了软件开发的各个阶段以及每个阶段的工作活动和工件，但不对活动和工件的细节作过多规定。在项目开发过程中，每个项目根据自身的需要确定这些活动和工件的细节。 项目阶段 图2-1 项目开发的五个阶段 ?启动阶段 这个阶段的工作目的是决定一个项目是否需要启动。为了达到这个目的，首先要明确项目的总体战略目标，对项目的需要建立认同。即确定到底需要做什么、开发什么产品或提供什么服务，以及需要解决什么样的问题和需要满足客户或市场的什么要求等，同时还要总结项目工作的范围、所需资源、大约开支、各种风险，以及该项目不执行的其他替代选择等。这些代表了对整个项目目标从战略角度和宏观层次所进行的分析，通过项目的意向书总结出来，由此确证客户或项目发起人和赞助者的要求与期望，并帮助他们判定项目是否上马。项目意向总结书的通过及项目被批准上马形成了这个项目的起始点。 ?计划阶段 这个阶段的工作是为整个项目做计划。项目开始后，首先要确定项目的具体范围，明确定出项目到底要做什么，总结、归纳并定出产品的功能。然后进一步制定项目的计划，列出每项具体工作，并建立所有工作任务的重要性及顺序；确定每项工作的执行人和所需资源；根据人员的配置和能力设定各项工作和整个项目的完成时间表。 ?执行阶段
这个阶段的工作是通过执行项目的计划来完成项目的任务。它包括落实一切所需资源，如：人员、设备、费用、技术、信息，由管理者领导全体项目参与者开展各项工作。同时跟踪各项具体工作和整个项目的进度，定期向全体项目人员及项目的发起人报告项目状态。 ?控制阶段 这个阶段的工作是确证项目工作的结果符合项目的计划。它通过对项目结果的衡量和审核，与项目计划所期望的结果进行比较，找出实际结果与计划的差别，并制定处理措施。这个阶段的工作还包括对项目进程中出现的任何更改要求进行审核和批准。同时调解项目进程中出现的各种问题，如：对缺乏的资源的补偿调节；对项目的进度表及各项具体工作的优先级或顺序的修订。 ?结束阶段 这个阶段的工作是确保项目的最终结果或提交物达到计划的要求，并对完成的结果作可接受的确认。还包括在项目完成之后的收尾工作，对整个项目的经历进行总结，修订项目文档，用户培训等。 阶段完成标志 在项目开发过程中，当一个阶段完成后才会开展下一个阶段的工作；另外，“某个阶段完成”通常被定义为项目的一个里程碑，里程碑标识了项目的进度，它是项目开发和控制的重要参考，对整个项目有重要的意义。因此，“确证某个阶段是否已经完成”的工作非常有重要。 ?每一个阶段的结束以它特定任务的完成为象征 只有当某个阶段中被规定的所有工作任务都完成了，这个阶段才算真正结束，整个项目才可以进入到下一个阶段中去。反过来说，要是阶段中某个任务没有全部完成，按照项目的定义，整个阶段就不能算是完成，因此项目就不能进入到下一个阶段去。 ?衡量阶段结束的工作结果必须是实在的交付品 阶段中的任务是否完成是透过任务活动中产生的交付品来体现的，交付品必须是可交付的、非抽象的、实质的并且可以通过用衡量的方法来判断是否真正地完成了的具体事物。如：某一阶段的完成是以建造一个样品或完成某分文件作为象征。任何项目阶段的结束，都应该有这样的实质性东西的完成作为象征。 ?跨阶段的进程以阶段结尾的合格验证和审核来决定 当一个阶段结束时，在进入到下一个阶段之前所需要做的工作应包括对交付品进行合格验证，并检查这一阶段的工作质量和效率，由此判断是否可以进入到下一个阶段。这些检验象征了一个阶段的结尾终点，表示项目的进程离开了上一个阶段而进入了下一个阶段。
软件公司简介范文1 软件公司简介范文 1 石家庄达内科技有限公司是中国高端it行业领导品牌，由美国国际数据集团idgvc partners和集富亚洲jafco asia投资，是国内首家获得国际风险投资的it机构，2006-2008连续3年入选德勤“高科技高成长中国50强、亚太地区500强”。达内it集团是java之父sun公司在中国境内最大的java合作伙伴、中关村科技园区管委会指定的“软件示范基地”，是中国it新模式的创始者。 经过12年运营，达内科技已经于2014年4月3日赴美国纳斯达克成功上市(股票代码tedu)。达内先后在石家庄、北京、上海、广州、深圳、杭州、南京、武汉、成都、西安、沈阳、大连、青岛等30多个城市建立了100多家中心，员工规模达5000人。已与ibm、微软、摩托罗拉、华为、中软、用友、yahoo、阿里巴巴、tom、新浪、搜狐、百度、联想、神州数码、大唐电信、亚信等知名it企业达成密切合作，跨越电信、金融、电子政务(商务)、电力、通讯、搜索、欧美外包及对日外包等十数个行业。目前，达内年产值接近2亿元，运营规模已远远超出其它同类公司。 软件公司简介范文 2 爱趣网络信息科技有限公司公司主营游戏推广、运营、手机游戏研发、媒体门户网站经营等 2013年9月正式在河南郑州成立分公司，目前郑州业内：没有之一，只有唯一郑州分公司位于花园路北环路省直花园6号楼1301室
注册资金1000万元，办公面积近300平方。郑州分公司预计招募100名喜欢玩游戏的精英人才以及管理团队新兴行业+新的团队+新的起点== 机遇+挑战+高薪公司刚刚成立就加入我们的团队等于什么? 软件公司简介范文3 北京中关村软件园落成于2000年，目前园区汇聚了281家知名it企业，从业软件开发及其它it类工程师3万余人，为国家软件产业基地和国家软件出口基地，在软件与信息服务产业领域在全球具有广泛的影响力，it产业全球领先，中国第一。 人才基地由北京中关村软件园官方投资建设，为中关村软件园重要的配套工程; 基地由国中央中国青年职业能力培训基地——中青才智教育投资(北京)有限公司与北京中关村软件园人才基为落实中关村软件园人才发展战略，共同设立的培训与人力资源服务机构。承担着为园区企业培养和输送it技术研发人员的任务，被教育部认定为国家级的工程实践教育中心。 中关村软件园二期全面建成后,将聚集it企业500家，吸纳10万高端it人才就业，预计每月人才缺口将超过2000人，人才需求量远远大于人才供应量，对欲在it领域有所建树的有识之士来说千载难逢、机会难得... 迫在眉睫的人才之渴，将是未来园区企业发展的瓶颈，尽快培养一大批多层次、实用型、高水平的it人才，已经成为园区发展的一项基础性、战略性的重要任务。在这样的迫切需求之下，人才基地于2005年成立。 基地从服务园区企业的根本需求出发，将充分发挥软件园的
毕业设计（论文）题目：软件开发流程管理 班级：11工升 学号：1000303071 姓名： 指导教师： 2014年11月
从软件开发最初至今，不断地有新的软件开发技术产生，但是在软件开发能力和质量方面却始终存在达不到预计目标这一问题。每一个软件开发的最大目标，就是最大限度提高质量与生产率。而影响质量与生产率的三个关键因素：过程、人和技术，因此，我们除了提高技术能力，培养更多优质人才之外，还需要制定一套软件开发过程管理标准，并在软件开发过程中对这一标准不断地完善，以达到提高软件质量与生产率的目标。 本文结合CMM（软件过程成熟度模型），对软件开发、维护全过程进行标准化、规范化管理，制定出软件开发管理标准。 关键词：软件开发过程，管理标准
第一章软件开发的概念及目的 (4) 第二章软件开发流程划分及开发环境 (4) 2.1.软件开发阶段划分 (4) 2.2.软件开发环境需求........................... 错误！未定义书签。第三章软件开发过程中存在的问题 .................... 错误！未定义书签。 3.1.对用户方需求的掌握不全面................... 错误！未定义书签。 3.2.对软件的价值认识不清晰..................... 错误！未定义书签。 3.3.跟用户方的合作不顺利....................... 错误！未定义书签。 3.4.开发队伍的结构不合理....................... 错误！未定义书签。 3.5.软件开发管理制度不健全..................... 错误！未定义书签。 3.6.开发团队人员不稳定......................... 错误！未定义书签。第四章软件开发流程管理规范 . (10) 4.1.什么是CMM (10) 4.2.结合CMM制定开发流程管理方案 (11) 4.2.1软件项目生命周期模型................... 错误！未定义书签。 4.2.2需求分析流程图及描述................... 错误！未定义书签。 4.2.3设计流程图及描述....................... 错误！未定义书签。 4.2.4编码流程图及描述....................... 错误！未定义书签。 4.2.5测试流程图及描述....................... 错误！未定义书签。 4.2.6验收流程图及描述 (22) 第四章软件开发行业前景 (23) 参考文献........................................... 错误！未定义书签。