现代物流信息技术：3-1物流信息系统开发过程

1、第3章 物流信息系统开发技术3.1 物流信息系统的开发过程3.1.1 物流信息系统开发概述 物流信息系统是由人员、设备和程序组成的、为物流管理者执行计划、实施、控制等职能提供信息的交互系统，是物流管理软件与信息网络结合的产物。 物流信息系统的开发是一项复杂的系统工程。它涉及物流管理理论、信息系统技术、物流信息技术等知识，不仅涉及运输部门、而且涉及到仓储、调度、信息中心、门店等多部门，不仅涉及技术，而且涉及管理业务、组织和行为。软件的特点软件是一种逻辑实体，而不是有形的系统元件，其开发成本和进度难以准确地估算软件是被开发的或被设计的，它没有明显的制造过程，一旦开发成功，只需复制即可，但其维护的工

2、作量大软件的使用没有硬件那样的机械磨损和老化问题其它特点：软件的开发和运行常受到计算机硬件的限制，对计算机硬件有着不同程度的依赖性软件的开发至今尚未完全实现自动化软件成本相当昂贵相当多的软件工作涉及到社会因素物流信息系统开发的基本过程 物流管理系统开发的基本过程主要是系统的可行性分析（任务提出、初步调查和系统的可行性分析）、系统分析、系统设计、系统实施、系统维护和系统评价6个阶段。物流信息系统开发的全生命周期系统生命周期各阶段工作量 一般常用甘特图（Gautt）来记载和描述各阶段工作量，如时间、进度、投入和工作顺序之间的关系。 系统设计 20% 系统分析15% 系统实施 50% 系统规划 9%

3、 系统运行 6% 软件生存期的阶段划分 (1)问题定义 (2)可行性研究 (3)需求分析 (4)总体设计 上游 (5)详细设计 （设计师任务） (6)实现 (7)单元测试 (8)确认测试 (9)系统测试 下游 (10)运行和维护 （程序员任务）（根据国标计算机软件开发规范）计划时期开发时期运行时期系统的可行性分析可行性分析的作用：确定系统开发的依据；为系统开发筹集资金的依据；与合作单位签订合同的依据；系统验收的依据。 系统开发可行性分析的内容包括：从技术上、经济上、管理与社会等目标对方案的可行性进一步分析。初步调查1）初步调查的目的、原则 初步调查的对象是现行系统（包括手工系统和已采用计算机的

4、管理信息系统），目的在于完整掌握现行系统的现状，发现问题和薄弱环节，收集资料，为下一步的系统化分析和提出新系统的逻辑设计做好准备。2）初步调查的方法 调查的方法可以采用召开调查会、访问、发调查表、参加业务实践等方式。可行性分析的报告内容包括：（1）系统描述；（2）项目的目标；（3）所需资源、预算和期望效益；（4）对项目可行性的结论。系统开发的思想系统工程 系统工程的基本思想：系统工程是按照系统科学的思想，运用信息论、控制论、运筹学等理论和方法，从整体的角度对系统进行规划、研究、设计、实施和控制的工程技术。系统工程的方法：统一规划方法、霍尔的三维结构法3.1.2 物流信息系统的开发方法典型的软件

5、过程模型有：瀑布模型（waterfall model）演化模型（evolutionary model）增量模型（incremental model）原型模型（prototyping model)螺旋模型（spiral model）喷泉模型（water fountain model）基于构件的开发模型 （component-based development model）形式方法模型 （formal methods model）（1）瀑布模型 瀑布模型也称软件生存周期模型。根据软件生存周期各个阶段的任务，瀑布模型从可行性研究（或称系统需求分析）开始，逐步进行阶段性变换，直至通过确认测试并得到用户

6、确认的软件产品为止。 瀑布模型的主要特点是：阶段间的顺序性和依赖性，开发过程是一个严格的下导式过程，即前一阶段的输出是后一阶段的输入，每一阶段工作的完成需要确认，而确认过程是严格的追溯式过程，后一阶段出现了问题要通过前一阶段的重新确认来解决。因此，问题发现得越晚解决问题的代价就越高。瀑布模型 (线形顺序模型)问题定义需求分析设 计编 码运行维护测 试计划阶段 （Why，What）运行阶段（Change）可行性研究开发阶段（How） 1970年W.Royce提出瀑布模型 特征接受上一阶段的结果作为本阶段的输入利用这一输入实施本阶段应完成的活动对本阶段的工作进行评审将本阶段的结果作为输出，传递给下

7、一阶段 缺点缺乏灵活性，难以适应需求不明确或需求经常变化的软件开发开发早期存在的问题往往要到交付使用时才发现，维护代价大按照传统瀑布模型开发软件的特点1.是说明软件生存周期的典型模型2.阶段间具有明显的顺序性和依赖性（缺点）。3.推迟实现的观点（优点）。4.每个阶段靠如下措施保证质量(优点) 每个阶段必须完成规定的文档; 每个阶段结束前完成文档审查,及早改正错误；5.存在的问题： 需求分析是成败关键，不适合需求模糊的系统； 需求变化很难适应。许多软件项目在开发早期对软件需求的认识是模糊的、不确定的，因此软件很难一次开发成功。可以在获取了一组基本的需求后，通过快速分析构造出该软件的一个初始可运行

8、版本，称之谓原型（prototype），然后根据用户在试用原型的过程中提出的意见和建议、或者增加新的需求，对原型进行改造，获得原型的新版本，重复这一过程，最终得到令客户满意的软件产品。演化模型的开发过程就是从构造初始的原型出发，逐步将其演化成最终软件产品的过程。演化模型适用于对软件需求缺乏准确认识的情况。典型的演化模型有：增量模型、原型模型、螺旋模型。（2）演化模型增量模型项目日历时间软件功能性和特征12345第2次增量发布增量212345第n次增量发布增量n12345第1次增量发布增量15部署（发布，反馈）4构造（编码，测试）3建模（分析，设计）2计划1交流增量模型将软件的开发过程分成若干个

9、日程时间交错的线性序列，每个线性序列产生软件的一个可发布的“增量”版本，后一个版本是对前一版本的修改和补充，重复增量发布的过程，直至产生最终的完善产品。增量模型融合了瀑布模型的基本成分（重复地应用）和演化模型的迭代特征增量模型强调每一个增量都发布一个可运行的产品增量模型特别适用于：需求经常变化的软件开发市场急需而开发人员和资金不能在设定的市场期限之前实现一个完善的产品的软件开发增量模型能有计划地管理技术风险，如早期增量版本中避免采用尚未成熟的技术原型（prototype）是预期系统的一个可执行版本，它反映了系统性质（如功能、计算结果等）的一个选定的子集。一个原型不必满足目标软件的所有约束，其目

10、的是能快速、低成本地构建原型。原型方法从软件工程师与客户的交流开始，其目的是定义软件的总体目标，标识需求。然后快速制订原型开发的计划，确定原型的目标和范围，采用快速设计的方式对其建模，并构建原型。被开发的原型应交付给客户试用，并收集客户的反馈意见，这些反馈意见可在下一轮迭代中对原型进行改进。在前一个原型需要改进，或者需要扩展其范围的时候，进入下一轮原型的迭代开发。原型模型部署交付和反馈构建原型交流快速设计方式建模快速计划原型模型原型模型（快速成型模型）建造/修改 原型用户测试运行原型 听取用 户意见原型模型采用原型模型的软件生存周期分析定义系统需求生成原型系统设计程序设计编码测试运 行和维护原

11、型化含原型化的软件生存期采用原型模型的特点及早向用户展示系统模型（原型），即具体形象地展示界面及功能；用户认可原型后进行开发，逐一完善；修改集中在前期的原型确认上；借助原型开发工具会加快进度快速原型法模型快速原型系统的不足之处有以下两点：系统开发人员在初期往往考虑得不周全，有可能使原型不能成为最终软件产品的一部分，只是一个示例而已。这样，在实际开发软件产品时，仍有许多工作要做。 快速原型模型对工具和环境的依赖性较高。原型的类型：探索型（exploratory prototyping） 其目的是要弄清目标系统的要求，确定所希望的特性，并探讨多种方案的可行性实验型（experimental pro

12、totyping） 其目的是验证方案或算法的合理性，它是在大规模开发和实现前，用于考核方案是否合适，规格说明是否可靠。演化型（evolutionary prototyping） 其目的是将原型作为目标系统的一部分，通过对原型的多次改进，逐步将原型演化成最终的目标系统。 原型的使用策略：废弃（throw away）策略 主要用于探索型和实验型原型的开发。这些原型关注于目标系统的某些特性，而不是全部特性，开发这些原型时通常不考虑与探索或实验目的无关的功能、质量、结构等因素，这种原型通常被废丢，然后根据探索或实验的结果用良好的结构和设计思想重新设计目标系统。追加（add on）策略 主要用于演化型原

13、型的开发。这种原型通常是实现了目标系统中已明确定义的特性的一个子集，通过对它的不断修改和扩充，逐步追加新的要求，最后使其演化成最终的目标系统。原型可作为单独的过程模型使用，它也常被作为一种方法或实现技术应用于其它的过程模型中。B.Boehm于1988年提出是瀑布模型和演化模型的结合，并增加了风险分析螺旋模型沿着螺线旋转，在四个象限上分别表达四个方面的活动，即：制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件风险分析：评价所选的方案，识别风险，消除风险工程实施：实施软件开发，验证工作产品客户评估：评价开发工作，提出修正建议螺旋模型 螺旋模型出现了一些变种，它可以有3到6个任务区域。螺

14、旋模型指引的软件项目开发沿着螺线自内向外旋转，每旋转一圈，表示开发出一个更为完善的新软件版本。如果发现风险太大，开发者和客户无法承受，则项目就可能因此而终止。多数情况下沿着螺线的活动会继续下去，自内向外，逐步延伸，最终得到所期望的系统。螺旋模型的特点多种模型的结合瀑布模型+快速原型的一种演进模型增加前三种模型所忽略的风险分析螺旋式迭代、演进过程，每次迭代由四个阶段构成制定计划：确定目标，选择方案，设定约束条件，选定 完 成本周期目标的策略 ；风险分析：风险角度分析该策略，必要时可建立原型， 可 确定、修改、终止项目 ；工程实现：每次循环实施瀑布模型中的一个或若干个阶 段； 评审阶段：用户占参与

15、评估前一步的结果，计划下一轮 的工作 风险可控，但依赖于风险评估的准确性喷泉模型喷泉模型是一种支持面向对象开发的模型体现迭代和无间隙特征迭代：各开发活动常常重复工作多次，相关的功能在每次迭代中随之加入演进的系统无间隙：开发活动之间不存在明显的边界支持软件复用（reuse）利用预先包装好的软件构件（包括组织内部开发的构件和现存商品化构件COTS）来构造应用系统基于构件的开发模型对象可重用部件组装模型使用重用技术的软件工程模型构件(components):可重用的软件成份可复用性（Reusability） （可重用性）集成化软件开发环境（ISEE）可重用部件组装模型系统A的软件构成系统C的软件构成

16、系统B的软件构成可重用部 件 可重用 部 件 软件生产线应用构件提取车间 应用构件库构件生产车间 构件库组装车间领域 1领域 2应用系统 .12341基础构件，2功能构件 3接口构件，4用户界面构件 领域分析构件可变性分析构建可复用构件领域模型领域基准体系结构图可复用构件库分析体系结构设计获取构件构件特化和修改评价构件组装和测试开发未找到构件的部分应用系统工程应用系统领域工程领域工程的目的是构建领域模型、领域基准体系结构和可复用构件库。领域分析分析该领域中各种应用系统的公共部分或相似部分，构建领域模型和领域基准体系结构（reference architecture），标识领域的候选构件。对候选

17、构件进行可变性分析，以适应多个应用系统的需要。构建可复用构件，经严格测试和包装后存入可复用构件库（称为构件工程）。应用系统工程的目的是使用可复用构件组装应用系统。分析待开发的应用系统，设计应用系统的体系结构，标识应用系统所需的构件。在可复用构件库中查找合适的构件（也可购买第三方的构件）。特化选中的构件，必要时作适当的修改，以适应该应用系统的需要。开发那些未找到合适构件的应用部分。组装应用系统。评价构件的复用情况，以改进可复用构件，同时对新开发的部分进行评价，并向构件工程推荐候选构件。形式方法模型形式化方法（formal methods）是建立在严格数学基础上的一种软件开发方法。软件开发的全过程

18、中，从需求分析、规约、设计、编程、系统集成、测试、文档生成、直至维护各个阶段，凡是采用严格的数学语言，具有精确的数学语义的方法，都称为形式化方法。形式化方法用严格的数学语言和语义描述功能规约和设计规约，通过数学的分析和推导，易于发现需求的岐义性、不完整性和不一致性，易于对分析模型、设计模型和程序进行验证。通过数学的演算，使得从形式化功能规约到形式化设计规约，以及从形式化设计规约到程序代码的转换成为可能。3.1.3物流信息系统的开发方式 信息系统的开发方式有：自行开发、IT外包、委托开发、联合开发和软件采购四种。这几种开发方式各有特点，对企业来说也各有利弊。自行开发方式 自行开发方式是指基层单位

19、或行业主管部门自己组织技术力量进行信息系统的开发工作。其优点：（1）自行开发方式使企业控制信息系统开发的全过程。开发成功的系统能够充分、真实地反映企业的实际需求，针对性强，使用效率高。（2）便于企业规划本企业整个信息系统的建设工作。（3）由于本企业的技术人员和应用人员直接介入系统的开发工作，系统建成后推广应用迅速，取得预期的经济效益。（4）自行开发信息系统，可为企业培养一支称职的维护队伍。自行开发方式 自行开发方式对开发队伍的素质要求很高，如果不具备一定条件，在开发过程中将会存在以下问题：（1）一般的企业自行开发信息系统时容易忽视成本、收益分析。（2）人员组成结构不合理。（3）一般的企业开发队

20、伍没有实力采用和尝试先进和新兴的技术，开发的系统技术先进性差。IT外包与委托开发 IT外包（IT Outsourcing）主要指的是依靠第三方提供企业所需的IT功能，例如应用程序维护和开发、网络管理和运作等。 IT外包的优越性：降低成本、能够利用新技术、更集中于核心活动、改善IT管理。 IT外包的局限性：有的IT功能不容易同企业分离；技术发展的不确定性；IT活动的估价较为困难；IT服务提供策略的转换成本很高；缺乏组织学习和创新。IT外包与委托开发 委托开发方式是企业委托具有雄厚技术力量和丰富软件开发经验的计算机软件公司、科研机构、高等院校等外部技术单位完成。这种方式建设信息系统，要注意的问题：

21、（1）被委托单位的开发人员对企业的管理业务熟悉程度。（2）在实现用户需求上能否对手工系统不合理的地方提出合理的改进意见和方法。（3）委托单位的开发人员能否发现较为准确的需求和开发的系统具有柔性。（4）在系统交付使用后，委托单位对系统的维护支持度如何。联合开发方式 联合开发方式指企业邀请有信息系统开发实践经验的电脑公司、科研院所的专家进行协作，并选派得力的领导和有经验的管理人员以及本企业的计算机技术人员参与。 采用联合开发方式，企业技术部门可以学习专业软件公司的开发方法，同时由软件公司负责解决技术难点，对开发进程进行科学的安排和控制，企业技术人员负责编制代码。这样就可回避了企业学习系统开发队伍开

22、发经验少，技术低下的问题。同时又在联合开发中锻炼和培训了本企业学习技术人员，所以联合开发方式的效果一般好于自行开发。软件采购 目前我国已有不少专门从事信息系统软件开发的单位，他们开发的软件在性能上较注意通用性和易学易用性，在开发的管理和技术力量上具有较大的优势，软件质量相对较高。但现在我国自行开发的通用软件产品还是较少，而引进的国外软件产品价格昂贵又不太适合我国国情，因此，这种方式目前还不是主要的开发方式。3.1.4物流信息系统的项目管理项目管理的发展：1. 软件能力成熟度模型 软件过程是形成软件产品的一系列步骤，是一个为建造高质量软件所需完成的任务的框架，包括中间产品、资源、角色及过程中采取

23、的方法、工具等范畴。 软件过程成熟度是一个特定软件过程被明确和有效地定义、管理、测量和控制的程度。成熟度可指明一个软件开发组织软件过程能力的增长潜力。 软件能力成熟度模型是对软件组织进化阶段的描述，随着软件组织定义、实施、测量、控制和改进其软件过程，软件组织的能力经过这些阶段逐步前进。 软件组织的成熟与不成熟 1. 不成熟的软件组织软件过程一般并不预先计划，而是在项目进行中由实际工作人员及管理员临时计划有时，即使软件过程已计划好，仍不按计划执行没有一个客观的基准来判断产品质量，或解决产品和过程中的问题对软件过程步骤如何影响软件质量，一无所知，产品质量得不到保证。而且，一些提高质量的环节，如检查

24、、测试等经常由于要赶进度而减少或取消产品在交付前，对客户来说，一切都是不可见的没有长远目标，管理员通常只关注解决任何当前的危机由于没有实事求是地估计进度、预算，因此他们经常超支、超时。当最后期限临近，他们往往在功能性和质量上妥协，或以加班加点方式赶进度2. 成熟的软件组织具有全面而充分的组织和管理软件开发和维护过程的能力管理员监视软件产品的质量以及生产这些产品的过程制定了一系列客观基准来判别产品质量，并分析产品和过程中的问题进度和预算可以按照以前积累的经验来制定，结果可行。预期的成本、进度、功能与性能和质量都能实现，并达到目的能准确及时地向工作人员通报实际软件过程，并按照计划有规则地(前后一致

25、，不互相矛盾)工作凡规定的过程都编成文档软件过程和实际工作方法相吻合。必要时，过程定义会及时更新，通过测试，或者通过成本-效益分析来改进过程。全体人员普遍地、积极地参与改进软件过程的活动。在组织内部的各项目中，每人在软件过程中的职责都十分清晰而明确，每人各守其责，协同工作，有条不紊，甚至能预见和防范问题的发生。能力成熟度模型CMMCMM（Capability Maturity Model）即能力成熟度模型，是美国卡耐基梅隆大学软件工程研究所（SEI）在美国国防部资助下于二十世纪八十年代末建立的，用于评价软件机构的软件过程能力成熟度的模型。此模型在建立和发展之初，主要目的在于提供一种评价软件承接

26、方能力的方法，为大型软件项目的招投标活动提供一种全面而客观的评审依据。而发展到后来，又同时被软件组织用于改进其软件过程。SW-CMM的由来与发展美国卡内基-梅隆大学软件工程研究所(SEI)80年代中期 美国国防部 资助提出软件能力成熟度模型 (Software Capability Maturity Model )软件过程改进工业标准克劳斯比汉弗莱 成熟度框架SEI给CMM下的定义： 对于软件组织在定义、实现、度量、控制和改善其软件过程的各个发展阶段的描述。这个模型便于确定软件组织的现有过程能力和查找出软件质量及过程改进方面的最关键的问题，从而为选择过程改进战略提供指南。如今的行情是：一家软件

27、企业如果不能通过相应等级的CMM评估，他的产品就少了一张进入国际市场的通行证。SW-CMM的管理思想与结构SW-CMM为软件企业的过程能力提供了一个阶梯式的进化框架。它是基于过去所有软件工程成果的过程改善的框架，吸取了以往软件工程的经验教训。指明了一个成熟的软件组织在软件开发方面需要管理的主要工作、这些工作之间的关系以及以怎样的先后次序，一步一步的做好这些工作使软件组织走向成熟。 软件过程成熟度等级 CMM提供了一个成熟度等级框架： 1级-初始级、 2级-可重复级、 3级-已定义级、 4级-已管理级和5级-优化级。 1.初始（initial）级： 软件过程的特点是无秩序的，甚至是混乱的。几乎没

28、有什么过程是经过妥善定义的，成功往往依赖于个人或小组的努力。2.可重复（repeatable）级： 建立了基本的项目管理过程来跟踪成本、进度和功能特性。制定了必要的过程纪律，能重复早先类似应用项目取得的成功。3.已定义（defined）级： 己将管理和工程活动两方面的软件过程文档化、标准化，并综合成该机构的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件。4.已管理（managed）级： 收集对软件过程和产品质量的详细度量值，对软件过程和产品都有定量的理解和控制。 5.优化（optimizing）级： 整个组织关注软件过程改进的持续性、预见及增强自身，防止缺陷及问题的发生

29、。过程的量化反馈和先进的新思想、新技术促使过程不断改进。5.优化级4.已管理级3.已定义级2.可重复级1.初始级标准、一致的过程有纪律的过程可预测的过程持续改进的过程软件过程成熟度的5个等级软件项目管理软件危机后的普遍性结论：软件项目成功率非常低的原因可能是项目管理能力太弱软件项目管理是指软件生存周期中软件管理者所进行的一系列活动，其目的是在一定的时间和预设范围内，有效地利用人力、资源、技术和工具，使软件系统或软件产品按原定计划和质量要求如期完成 软件项目管理的关注点(4P)人员(People)人员是软件工程项目的基本要素和关键因素在对人员进行组织时，有必要考虑参与软件过程(及每一个软件项目)

30、的人员类型 产品(Product)定义项目范围，其中包括建立产品的目的和范围、可选的解决方案、技术或管理的约束等 过程(Process)通常将项目分解为任务子任务等，其分解准则是基于软件工程的过程 项目(Project) 采用科学的方法及工具对项目基本内容进行管理 软件项目管理中的五类人员项目管理人员负责软件项目的管理工作，其负责人通常称为项目经理高级管理人员可以是领域专家，负责提出项目的目标并对业务问题进行定义开发人员掌握了开发一个产品或应用所需的专门技术，可胜任包括需求分析、设计、编码、测试、发布等各种相关的开发岗位客户一组可说明待开发软件的需求的人，也包括与项目目标有关的其它风险承担者最

31、终用户产品或应用提交后与产品/应用进行交互的软件项目管理中的产品定义项目范围，其中包括建立产品的目的和范围、可选的解决方案、技术或管理的约束目的：从客户的角度定义该产品的总体目标，但不必考虑这些目标如何实现软件范围定义了与软件产品相关的数据、功能和行为，及其相关的约束：语境(context)：说明待建造的软件与其它相关系统、产品或环境的关系，以及相关的约束条件信息目标：说明目标系统所需要的输入数据及应产生的输出数据功能和性能：说明软件应提供的功能来完成输入数据到输出数据的变换以及给出对目标软件的性能要求软件项目方法对项目进行有计划和可控制的管理明确目标及过程：充分理解被解决的问题，明确定义项目

32、目标及软件范围，为项目小组及活动设置明确、现实的目标，并充分发挥相关小组的自主性保持动力：提供激励措施使人员变动最小跟踪进展：对每个任务的进展进行跟踪，并对其软件过程和质量进行度量 做出聪明的决策：项目管理者和软件小组的决策应该 “保持其简单” 项目总结：从每个完成的项目中获取可学习的经验软件项目管理过程示例软件项目启动在软件项目启动前对项目进行可行性分析，以明确项目的目标和范围，从而确定：合理精确的成本分析；实际可行的任务分解；可管理的进度安排在多个项目方案中选择一个相对完善的方案考虑交付期限、预算、个人能力、技术界面等限制条件在正式启动软件项目前组成项目组，并召开项目启动会议，内容包括：项

33、目组的初步交流；进一步对项目目标理解；对组织形式、管理方式、方针的一致认识；明确岗位职责项目组织在项目经理领导下，组织不同类型的项目组成员共同协作完成软件项目存在多种可选的项目组织结构，组织结构的选择对项目的成败具有很大影响规划软件工程项目组织结构时考虑如下因素：待解决问题的困难程度目标系统的规模，可用代码行或功能点来度量项目组的生存期，即项目小组需要共同工作的时间问题可被分解的程度对目标系统要求的质量和可靠性可供开发时间的紧迫性，即交付时间的严格程度项目组内部的通信的复杂性，即成员(小组)之间正式或非正式通信的机制项目组织原则项目组织形式不仅要考虑软件项目的特点，还需要考虑参与人员的素质在软

34、件项目的组织原则：尽早落实责任：在软件项目开始组织时，要尽早指定专人负责，使他有权进行管理，并对任务的完成负全责减少接口：一个组织的生产率随完成任务中存在通信路径数目的增加而降低。要有合理的人员分工、好的组织结构、有效的通信，减少不必要的生产率的损失责权均衡：软件经理人员所负的责任不应比委任给他的权力还大项目组织模式按项目划分的模式：按项目将开发人员组织成项目组，项目组的成员共同完成该项目的所有开发任务，包括项目的定义、需求分析、设计、编码、测试、评审以及所有的文档编制，甚至包括该项目的维护按职能划分的模式：按软件过程中所反映的各种职能将项目的参与者组织成相应的专业组，如开发组、测试组、质量保

35、证组、维护组等矩阵形模式：上述两种模式的复合，每个软件人员既属于某个专业组，又属于某个项目组矩阵型组织结构示例人员配备合理地配备人员包括：对不同的开发活动指派不同的人员，并明确指出对种类人员的要求通常在项目初期需要的人员并不太多，但其业务和技术水平要高在项目的中后期需要较多的人参与，其中大多是一些有专门技术(如编程、测试)的人在项目临近结束(试运行)时，只需少量人员参与即可如果一个软件项目从开始到结束都保持一个恒定的人员配备，那么就会出现下图中的情况配备人员的原则重质量：软件项目组不仅需要足够的人，更需要业务和技术水平高的人重培训：培养所需技术人员和管理人员是有效解决人员问题的好方法双阶梯提升

36、：人员提升应分别按技术职务和管理职务进行，不能混在一起项目经理的要求项目经理是项目的组织者，关系到项目的成败一个称职的项目经理应具备如下能力：获得充分资源的能力组建团队的能力分解工作的能力为项目组织提供良好环境的能力权衡项目目标的能力应付危机，解决冲突的能力谈判及广泛沟通的能力技术综合能力领导才能项目计划项目计划是项目组织根据软件项目的目标及范围，对项目实施中进行的各项活动进行周密的计划项目计划根据项目目标确定项目的各项任务、安排任务进度、编制完成任务所需的资源预算等项目计划包括：工作计划、人员组织计划、设备采购计划、变更控制计划、进度控制计划、财务计划、文件控制计划、应急计划等软件度量软件度

37、量是指计算机软件范围内的测量，主要是为产品开发的软件过程和产品本身定义相关的测量方法和标度对软件开发过程度量的目的是为了对过程进行改进对产品进行度量的目的是为了提高产品的质量，度量的作用是为了有效地采用定量的方式来进行管理管理人员利用度量来了解软件工程过程的执行情况和产品质量需要考虑：合适的度量是什么所收集的数据如何使用用于比较个人、过程或产品的度量是否合理项目估算项目估算是制定项目计划的基础项目所需的人力(以人月为单位)、项目持续时间(以年份或月份为单位)、成本(以元为单位)等参照以前类似项目中的相关数据进行估算若存在类似历史项目则可进行类比估算若缺少可类比的项目数据则采用特定的估算技术(例

38、如功能点估算方法等)通常采用多种估算技术进行交叉检查风险管理风险：人员、经费、进度及需求等方面存在的可能影响项目按计划完成的不确定因素风险管理：标识软件项目中的风险，预测风险发生的概率以及风险造成的影响，并对风险进行评估，找出那些可能导致项目失败的风险，然后采取相应的措施来缓解风险风险管理贯彻于整个软件工程过程中项目进度管理目标：确保软件项目在规定的时间内按期完成项目进度管理任务定义所有的项目任务以及它们之间的依赖关系制订项目的进度安排规划每个任务所需的工作量和持续时间在项目开发过程中不断跟踪项目的执行情况，发现那些未按计划进度完成的任务对整个项目工期的影响，并及时进行调整制定进度计划的两种情

39、况客户方都规定了明确的交付日期，此时进度安排必须在此约束下进行只规定了大致的时间界限，最终的交付日期由开发组织确定，此时的进度安排可以比较灵活，工作量的分布可考虑对资源的充分利用指导软件项目进度安排的基本原则-1划分：项目必须被划分成若干可以管理的活动和任务，为了实现项目的划分，对产品和过程都需要进行分解相互依赖性：确定各个被划分的活动或任务之间的相互关系，有些任务必须是串行的，有些可能是并行的时间分配：必须为每个被调度的任务分配一定数量的工作单位此外还必须为每个任务制定开始和结束日期，这些日期是相互依赖的工作量确认：确保在任意时段中分配给任务的人员数量不会超过项目组中的人员数量指导软件项目进

40、度安排的基本原则-2定义责任：每个被调度的任务都应该指定某个特定的小组成员来负责定义结果：每个被调度的任务都应该有一个确定的输出结果定义里程碑：每个任务或任务组都应该与一个项目里程碑相关联(当一个或多个工作产品经过质量评审并且得到认可时，标志着一个里程碑的完成)基于瀑布模型的任务网络示例任务工作量的确定根据软件工程过程的不同，可确定其相应的任务的工程量分配常用的有40-20-40规则：在整个软件开发过程中，编码工作量仅占20%，编码前工作量占40%，编码后工作量占40%CoCoMo模型按目标程序规模对不同任务工作量分配的比例：在实际应用时，按此比例确定各个阶段工作量的分配，从而进一步确定每一阶

41、段所需的开发时间，然后在每个阶段，进行任务分解，对各个任务再进行工作量和开发时间的分配进度安排通用的项目进度安排工具和技术可以直接应用于软件项目为监控软件项目的进度计划和工作的实际进展情况，表现各项任务之间进度的相互依赖关系，需要采用图示的方法明确标识：各个任务的计划开始时间和完成时间各个任务的完成标志各个任务与参与工作的人数，各个任务与工作量之间的衔接情况完成各个任务所需的物理资源和数据资源甘特图和网络图是两种常用的图示方法跟踪进度根据项目进度表，跟踪和控制各任务的实际执行情况一旦发现某个任务(特别是关键路径上的任务)未在计划进度规定的时间范围内完成，那么就要采取措施进行调整增加额外的资源、

42、增加新的员工或调整项目进度表可以通过以下方式来实现项目跟踪：定期举行项目状态会议，由项目组中的各个成员分别报告进度和问题评价在软件工程过程中产生的所有评审结果确定正式的项目里程碑是否在预定日期内完成比较项目表中列出的各项任务的实际开始日期与计划开始日期非正式与开发人员进行会谈，获取他们对项目进展及可能出现的问题的客观评价跟踪与控制跟踪是控制的前提，它实际上是在项目实施过程中对影响项目进展的内外部因素进行及时的、连续的、系统的记录和报告的活动，其核心在于反映项目变化、提供相关信息的报告控制是通过工具和技术对项目计划与实际执行进行对比，并对项目的未来走向进行预测，再此基础上进行项目的各种调整软件配

43、置管理Software Confignation Management(SCM)任务：标识和确定系统中的配置项，在系统整个生命期内控制这些项的发布和变更，记录并报告配置的状态和变更要求，验证配置项的完整性和正确性SCM存在于整个软件过程中，是一种保护性活动软件质量管理软件质量定义ISO/IEC 9126：与软件产品满足明确或隐含需求的能力有关的特征和特性的总和GB/T 13423：软件产品中能满足给定需求的性质和特性的总和，例如符合规格说明的程度；软件具有所期望的各种属性的组合程度；客户或用户觉得软件满足其综合期望的程度；软件的综合特性，它确定软件在使用中将满足客户预期要求的程度典型的软件质量

44、模型：McCall模型、Boehm模型和ISO/IEC9126质量模型McCall模型质量要素反映软件的质量，决定产品质量的软件属性用作评价准则，量化的度量体系可测量软件质量属性的优劣McCall软件质量要素软件产品的运行、修改和迁移三个方面11个软件质量要素 McCall软件质量要素定义正确性(correctness)：一个程序满足它的需求规约和实现客户任务目标的程度可靠性(reliability)：一个程序期望以所需的精确度完成它的预期功能的程度效率(efficiency)：一个程序完成其功能所需的计算资源和代码的数量完整性(integrity)：对未授权人员访问软件或数据的可控制程度可用

45、性(usability)：学习、操作、准备输入和解释程序输出所需的工作量可维护性(maintainability)：定位和修复程序中一个错误所需的工作量灵活性(flexibility)：修改一个运作的程序所需的工作量可测试性(testability)：测试一个程序以确保它完成所期望的功能所需的工作量可移植性(portability)：把一个程序从一个硬件和/或软件系统环境移植到另一个所需的工作量可复用性(reusability)：一个程序(或一个程序的部分)可以在另外一个应用程序中复用的程度，与程序完成的功能的包装和范围相关可互操作性(interoperability)：连接一个系统和另一个系

46、统所需的工作量。质量要素之间的关系其中表示正相关，表示负相关 软件质量属性软件质量要素难以直接测量，因此需要为每个质量要素定义一组软件质量属性用作质量要素的评价准则，要求能够完整、准确地描述软件质量要素容易量化和测量McCall定义了21种软件质量属性质量要素与评价准则的关系软件质量控制高质量的软件应该具备以下条件：满足软件需求定义的功能和性能文档符合事先确定的软件开发标准软件的特点和属性遵循软件工程的目标和原则还应该考虑在预算和进度范围内交付，因此在项目进行过程中要对偏差进行控制质量控制和质量保证质量控制是为了保证每一件工作产品都满足对它的需求而应用于整个开发周期中的一系列审查、评审和测试质

47、量控制在创建工作产品的过程中包含一个反馈循环，通过对质量的反馈，使得我们能够在得到的工作产品不能满足其规约时调整开发过程所有工作产品都应该具有定义好的和可度量的规约，这样就可以将每个过程的产品与这一规约进行比较质量保证由管理层的审计和报告构成，目标是为管理层提供获知产品质量信息所需的数据，从而获得产品质量是否符合预定目标的认识和信心软件质量保证软件质量保证活动由两类不同的角色承担负责技术工作的软件工程师：通过采用可靠的技术方法和措施、进行正式的技术评审、计划周密的软件测试来考虑质量问题，并完成软件质量保证和质量控制活动负责质量保证工作的SQA (Software Quality Assuran

48、ce)小组：辅助软件工程小组得到高质量的最终产品软件评审软件评审是软件质量保证的重要手段通常在软件工程过程的每个活动(如需求分析、设计、编码)的后期进行正式的软件评审两种主要评审活动：项目管理评审和技术评审(ISO/IEC 12207信息技术 软件生存周期过程中的联合评审过程定义)项目管理评审项目管理评审的任务是针对适用的项目计划、进度安排、标准和指南进行项目状态的评价评审的结果应做出下列规定：基于对活动或软件产品状态的评价，按照计划进行改进活动通过配备必要的资源维持项目的总体控制改变项目的方向或决定是否需要另外计划评价和管理可能危及项目成功的风险问题技术评审技术评审的任务是举行技术评审以评价正在考虑中的软件产品或服务，并提供下列证据：它们是完整的它们符合标准和规