练就软件开发真功夫
开篇：润墨网以专业的文秘视角，为您筛选了一篇练就软件开发真功夫范文，如需获取更多写作素材，在线客服老师一对一协助。欢迎您的阅读与分享！
软件是一种非常特殊的人工制品，但它本质上与其它工程产品并没有什么不同。我们完全可以将传统的工程学方法应用于软件的开发上;而将工程方法运用于解决软件开发的问题，便是软件工程。
软件的精确性、模糊性、复杂性、关联性、不一致性、多样性、不可视性、主观性、易变性与不确定性特性决定了软件的开发是一项非常富有挑战性的工作。
当前软件的规模越来越庞大，面对的问题也越来越复杂多样，人们不可能再像起初那样，直接进行编码，一次性地构造出最终软件交付。前述做法中，程序员同时要考虑用户如何操作软件来解决业务问题，如何组织大量代码的结构，要编写哪些具体代码来实现功能等，最终交付质量很难被保证。
为此，前辈们借用传统工程“中间工作产品”的概念，划分出软件需求、设计、代码、测试案例等中间制品，使得开发者能够分步去完成这些性质相对单一的制品，以避免同时关注性质各异甚至完全相反的内容。
然而，软件庞大的规模，使得既便是单一中间制品，其涵盖的信息量也仍然超出人类思维能力的极限，于是前辈们又借鉴传统工程“分而治之”的根本策略，将软件划分为较小的模块来分别构造，这样就大幅减少了开发者同时要处理的信息量。另外，软件交付的质量，将可以通过控制各个中间制品的质量，以及各个模块的质量，来得以保证，这样质量控制工作也变得更为容易了。
除此之外，软件还存在不可视性、主观性、易变性（可塑性）与不确定性等问题，传统工程学方法尚不能很好地解决它们;当代软件工程的大师们经过不懈的努力，终于给出了有效的药方。
图1 软件开发中间制品关系示意图
“中间工作产品”（见图1），例如需求，其开发的过程依然很复杂，需要开发者具备非常专业的技能;而“分而治之”的策略也不是任何人都能够运用自如;以架构为中心、迭代增量式开发，更是只有那些技术管理经验极为丰富的人，才有能力在项目中加以推行。换句话说，我们不可能培养出软件通才，能够掌握软件工程中涉及的所有方法与技能。这样，我们还必须借用传统工程“分工协作”的做法，组织具备不同知识与技能的成员，去分别从事不同性质的软件开发活动（见图2）。
图2 软件开发角色示意图
将软件开发的“中间工作产品”到底是划分为需求规格文档、概要设计文档等，还是划分为业务模型、用例模型、用例规约，以及架构文档等，这些都不是普通软件工程师在短时间内所能总结和确定的。
实际上，软件是人类迄今为止所面对的最复杂事物，其对应的软件工程方法，较之其它工程方法要复杂得多。
如果闭门造车，完全从头来设计一种软件工程方法，其工作量将极其庞大，而且它第一次在实际项目中实践成功的概率是零。我们只能参照业界成熟的标准，并结合以往大量实践的总结，在新的项目中采用被验证过的软件工程方法。
软件过程
为了方便项目组在新的项目中重复被验证过的方法与经验，需要将如何组织开发活动、分配人员职责等进行明确的定义。
所谓“软件过程software process”是指将涉众（客户、用户等）的需要转化为软件系统交付的所有活动集合。它定义了软件开发活动的序列，即按照什么顺序，在何时When、由何人Who、在何处Where做什么What（产出的制品）、怎么做How（使用什么工具Tool，应用什么技术等）才能达成目标Goal，以及为什么这么做Why等。
如图3所示，软件项目的上下文是客户及其业务（或者是某个领域问题）;为了支持业务的运作、实现客户的要求，必须设立一个软件项目，以组织相关的人员，将涉众的需要最终转化为软件交付。
图3 软件开发项目构成示意图
软件项目中包含了拥有不同技能的人才，他们将使用合适的工具，运用相关的技术，执行各类活动来完成项目。项目组采用的软件过程事先定义了如何组织这些人才，怎样使用工具，和按什么顺序执行相应的活动。项目组实际执行这个软件过程，从而实施了整个项目。
当前软件行业最为急迫的任务，就是研究与设计这些适用于不同类型软件、并适合不同状况开发团队来应用的软件过程与方法。
这些过程方法与传统的工程学方法一样，必须是在经济上切实可行的;也就是说，它们能够解决项目问题、普通素质的团队能较快地学习和掌握、执行的成本可以被接受、执行的过程可以被控制等。
一个有效的软件过程应当具备如下属性:
保证交付产品质量
能够迅速减少项目（需求、技术等）风险
保证项目（进度、成本等因素）可预测性与可控性
能够获得和提供最佳实践方法，并让团队较快地学习和掌握
促进涉众在软件开发领域内的达成共识和相互理解
软件过程的表述
为了设计软件过程，并让项目组学习和在实际项目中应用，必须使用适当的形式来表述它，以方便人们进行交流。
与软件过程比较相似的是企业的业务流程，实际上我们也可以将软件开发的过程看作是软件机构的业务流程。业界描述业务流程的主流途径是业务建模。
OMG组织较早便通过扩展UML语言来描述企业的业务流程，即UML在业务建模上的侧面扩展Profile。因为软件过程与之类似，OMG组织近几年又参考前者专门定义了表达软件过程的标准――SPEM（Software Process Engineering Metamodel软件过程工程元模型）。
软件过程异常复杂，包含了多种性质各异的活动，例如需求的开发、项目管理、质量保证等;这些活动交织在一起，人们很难理解与把握;为了简化表达结构，UP统一软件过程借用“分而治之”的思想，将这些不同性质的活动，及其关联的角色、工件等，组织为不同的科目discipline。而每个科目中的相关活动需要相互协同，体现了一种执行顺序关系，UP使用工作流workflow来精确地定义这种执行序列。
软件过程中每种活动的执行，都具有类似的行为结构:这项活动被对应的人员（角色Role）所执行，在执行过程中，具体人员将参照指南、工具指导等，使用工具并利用模板，来创建或修改工件Artifact;为了确保工件的质量，还要对照检查点来进行复核。这些属于工作流的基本要素，在工作流细节中将会采用这种统一的模式来描述对应活动的具体内容。
此外，软件过程本身是动态的，科目中的各项活动最终要在时间轴上对应展开，这些关系将在生命周期模型中被表述。
基本组成要素
软件过程虽然复杂，但它的基本行为结构却是一致的，我们可以将这些要素抽象出，并利用这些要素来描述过程本身。
活动Activity――指具体人员在工作流中充当某种角色所执行的有形工作单元，其完成将为项目提供符合要求的结果（工件）。活动存在明确的目的，并有明确定义的输入（一组工件），和产生明确定义的输出（另一组工件），例如模型、代码或文档等。
一个活动一般延续几小时到几天，它通常由一类角色来承担，并影响一个或少数几个工件。有时可能会对同一工件重复多次活动，例如同一用例规约可能在多次迭代中被修改。
工作单元Work Unit―在项目计划中，当把任务（活动）分配到具体的人员时，就产生了一个被清晰界定的工作单元。
角色Role―指对开发过程中承担相似职责的一类岗位的抽象。每个角色都具有一系列在对应活动中所要担负的职责。
工件Artifact―由相关角色在执行活动的过程中，创建、修改和使用的最终或中间产物。工件由某个或多个角色负责;它们通常要被置于配置管理之下。