《信息系统分析与设计》软件工程
《信息系统分析与设计》讲授提纲
课程简介：
1、为什么开设这门课？
①本课程教学目的：“具备现代经济、管理学理论基础、计算机科学技术知识及应用能力，掌握软件工程思想和方法，……，能从事计算机信息系统分析、设计、实施、管理和评价等工作的高级专门人才。”
②对专业成长的意义：程序员→高级程序员→系统分析员（Systems Analyst）,或日显重要的CIO（Chief Information Officer）。
③本课程以过去所学经济管理类课程，与计算机科学技术类课程为基础，力图将以往所学知识全部调动出来，解决经济建设与社会发展面临的信息化建设问题。对非经管类软件开发所起作用相同。
④建立一种信息系统开发的思想，工作的思路，了解开发过程中需用到的各种方法、工具，系统开发质量的评价标准，为下一步实际投入真实系统（而不是小段的程序作业）的开发建设打下思想、理论的基础。
2、主要内容简介
①主要内容：信息系统科学，即软件工程学科的由来与发展，结构化系统开发方法（详
细，基础），面向对象的开发方法。
②相关与相近课程：系统开发理论与方法、软件工程、软件开发技术等。
③重点掌握：系统思想与方法，系统开发的生命周期模型及其各种变型运用，系统开发常用方法与工具，系统开发理论与方法的最新发展。
3、教材与参考书
教材：软件工程2009年7月出版张海藩编著清华大学出版社
参考：Software Engineering—A Practitioner’s Approach, 6/e, Jun., 2006, By Roger S. Pressman, Mc Graw Hill, 清华大学出版社英文原版影印
第一章软件工程学概述
主要内容：软件危机及其产生原因
克服软件危机的途径——软件工程学科的产生
软件工程的基本原理
软件过程昱过程模型
软件工程方法学简介（传统方法学、面向对象方法学）
1.1软件危机
软件的产生及其开发方法的发展演变。软件危机的主要表现：
①软件开发无计划，或无法按计划进行（一切“走着瞧”，工期超期、成本超支）；
②不能确切保证理解用户需求；
③无软件质量保证及相应技术，无软件质量衡量标准；
④软件可维护性与可重用性做不到；
⑤无必需的文档，开发出的软件无任何人可理解；
⑥软件及开发成本越来越高（相应地硬件成本降低），而软件生产效率却越来越
低，跟不上硬件发展，跟不上日益高涨的软件应用需求。
产生原因：①软件生产过程较硬件更难控制、管理、评价
②缺乏软件质量标准（没有物理意义上的标准），和保证质量的技术措施 ③软件开发中引入的错误较难发现，修改时又可能引入新错误
④软件日趋庞大、复杂，人控制复杂问题的能力有限（多人协同完成时更难），又不重视开发方法选用和开发过程管理。
⑤程序设计者常忽视软件需求分析的重要性，用户需求不准确、不完整 ⑥缺乏软件产品的完整概念（软件配置），忽视文档建设，导致维护困难
总之，一方面传统的个体化程序设计工作方式、和习惯的“作坊式”开发环境与60年代中期起计算机应用的普及、软件需求量剧增，软件日趋庞大、复杂形成尖锐矛盾。另方面，不注意质量和可维护性，使得每开发出一个新的软件系统，开发人员即陷入无休止的维护、修改之中，无暇接手新系统，且这种情况越来越严重，形成“软件危机”。
1.2 软件工程
IEEE （1983年）强调了软件产品的正确定义，是由
计算机程序 + 方法 + 规则 + 相关文档资料 + 运行数据 五种成分构成的完整配置。该定义否定了一直以来以为软件就是一段程序代码，是个人灵机一动而生成的神秘产物，强调了软件是一种工程产物——“产品”特性。
解决软件危机要采用工程化方法（分析问题，设计方案，控制实施）；要研究系统开发的理论与方法；要利用高效的支持性的软件开发环境与工具；要有必要的组织管理与过程控制措施。
? 软件工程的基本定义
1968年北大西洋公约组织的计算机科学家在联邦德国召开的国际会议上正式提出“软件工程”一词，并形成一门学科。
NATO(北大西洋公约组织)最初给出的定义为：“软件工程就是为了经济地获得可靠的，且能在实际机器上运行的软件，而建立和使用完善的工程原理”。
IEEE （1993年）也对软件工程做了定义：是①把系统的、规范的、可度量的途径用于软件开发、运行和维护过程，也就是把工程应用于软件； ②研究上一点中提到的“途径”。
软件工程是技术与管理相结合，研究软件开发效率与质量的一门学科。 四十余年来，软件科学家为此开展了大量研究工作。一般认为软件工程具有如下本质特性：
① 重点关注大型软件构造（多人员、长时间、复杂结构）； ② 中心是如何控制复杂度问题（提高可管理、可控性、系统分析、逐个解决）； ③ 强调可维护、可改变（适应现实世界变化，延长生命期）；
代价
④ 提高开发效率（方法学、辅助工具）； ⑤ 和谐合作（标准、规范、过程，团队合作、沟通工具）； ⑥ 有效支持客户（确保满足功能、性能需求，提供完整配置产品）； ⑦ 明确自己扮演的角色（明确服务职责，明确团队中每一角色作用；了解客户领域业务、背景知识，创造性开发产品；明确客户第一，应用第一，客户评价第一） ?软件工程的（七条）基本原理（B. W. Boehm, 1983）： ①用分阶段的生命周期计划严格管理 ②坚持进行阶段评审 ③实行严格的产品控制 ④采用现代程序设计技术 ⑤结果应能清楚地审查
⑥开发小组的人员应该少而精
⑦承认不断改进软件工程实践的必要性 ?软件工程方法学（Methodology ）
方法学（又称范型Paradigm ）,指软件生命周期全过程中使用的一整套技术、方法的集合。方法学包括方法、工具和过程三种要素。
① 传统方法学（结构化方法学、生命周期法，可以面向过程/数据） ② 面向对象方法学（对象：数据与对数据操作的结合，OO 方法特点：对象+类+继承+消息通讯）
1.3 软件过程
软件工程中的“过程”指：为获得高质量软件所要完成的一系列任务的框架，它规定了完成各项任务的工作步骤和要求标准。通常用“生命周期”法定义任务框架。 1.3.1 软件生命周期及各阶段的基本任务
软件的生命周期 VS 软件开发的生命周期 ? 软件生命周期
? 软件系统开发的生命周期
系统开发生命周期各阶段简介
其实，软件开发生命周期所含阶段的个数少则可以3个（分析（定义）、设计、实现），多者可分出8~9个。本书作者分出7个阶段，分别是：问题定义、可行性研究、需求分析、概要设计、详细设计、编码和单元测试、综合测试，以及软件维护（已不属于开发生命周期），分别简介如下：
a)问题定义：要解决的问题的性质？是否适合计算机方法解决？项目的基本目标与项
目的大致规模。
b)可行性研究：该问题是否有可行的解决方法（技术、经济、可操作）？是否值得去
解？
c)需求分析：用模型的方法描绘出目标系统必须能够实现的全部功能，产生新系统的
逻辑模型，并得到用户的确认。所产生文档称“需求报告”或“规格说明”。
d)概要设计：新系统总体实现策略（子系统划分、软硬方案、网络架构、软件体系结
构等）
e)详细设计：新系统各方面的具体设计（数据库、模块算法、I/O界面、代码体系等）
f)编码和单元测试：完成各模块的程序编码并对他们进行测试。
g)综合测试：完成集成、系统、验收等测试及相应调试工作。完成系统提交。
此外，软件维护：通过各种维护工作使运行的系统能持久地满足用户需要。
各国（甚至各企业）在阶段划分上会有不同，但大顺序不会不同。（中国有国家标准GB/T 8566-2001 信息技术软件生存周期过程）
1.3.2 软件过程
为开发软件系统所必须完成的一系列工作的框架（包括步骤、任务内容和过程要求）?传统的“瀑布模型”
特点：各阶段的展开具有顺序性、前后依赖性
尽可能地推迟物理实现的时间
可以在各阶段末用验证、测试等把关的办法保证阶段性产品的质量
强调文档生成（滚动生成）
?快速原型模型
特点：从重要界面入手，通过原型获取需求规格；
其间与用户有大量交互、探讨过程；
依赖快速或自动生成工具。
?增量模型（渐增模型）
特点：先完成全部需求分析、规格说明、概要设计，再分解出各个增量构件；
第一个增量构件是代表系统核心功能的产品；
此后每一个增量构件也都是一个可运行的产品，且可以和已实现部分集成、测试；
可较短时间内提供部分产品，使客户提前熟悉、使用；
每次新的增量构件与已有部分的集成实际上有些困难。
增量模型之二（并行构建，进度加快，但缺乏总体分析设计，风险更大）
? 螺旋模型
（完整的螺旋模型见P.18，图1.8） 特点：每次先做风险分析（风险驱动），做原型，然后是本周期产品的设计、实现、评价、对下一周期工作的规划……。
与原型法区别：在做原型之前，加风险分析；
每一周期完成的不是最终产品，只是阶段产品（如完成规格说明书或编码）； 每一周期的工作步骤（除风险分析外）相当于瀑布模型；
强调规避风险，适用于可由自己控制（如内部开发）的大型软件； 对风险评估、风险排除的专门知识和经验要求较高。
构件3：
?喷泉模型
特点：一种有代表性的面向对象式开发生命周期；
中间垂直线表示有开发进展总目标；
各阶段活动有重叠（模型的连贯特性使得各阶段的转换“无缝”）
各阶段内下弯箭头表示阶段内不断迭代、求精
运行状态下的进一步开发或维护也是开发过程的迭代（两个下弯箭头表示）
?RUP ( Rational Unified Process, Rational统一过程)
在RUP中，软件开发生命周期根据时间的推进和RUP的核心工作流化分为二维空间：横轴表示项目的时间维，纵轴则以工作内容来组织。
纵轴上，RUP共有9个核心工作流，分为6个核心工作流(包括业务建模，需求，分析
和设计，实现，测试，部署)和三个核心支持工作流(包括配置和变更管理，项目管理，环境)。
横轴上，RUP划分为初始，细化，构造和交付等4个阶段。每个阶段都由一个或多个连续的迭代组成，每个迭代都是一个完整的开发过程，是一个具体的迭代工作流从头到尾的执行。每个阶段结束于一个主要的里程碑(Major Milestones)，在每个阶段的结尾执行一次评估以确定这个阶段的目标是否已经满足，如果评估结果令人满意的话，可以允许项目进入下一阶段。
这四个阶段每个阶段的的侧重点都有所不同。
初始阶段：需求和分析工作流；
初始阶段结束时是第一个重要的里程碑：生命周期目标(Lifecycle Objective)里程碑。生命周期目标里程碑评价项目基本的生存目标与能力。
细化阶段：需求，分析和设计工作流；
细化阶段结束时第二个重要的里程碑：生命周期结构(Lifecycle Architecture)里程碑。生命周期结构里程碑为系统的结构建立了管理基准并使项目小组能够在构建阶段中进行衡量。此刻，要检验详细的系统目标和范围、结构的选择以及主要风险的解决方案。
构造阶段：实现工作流；
构建阶段结束时是第三个重要的里程碑：初始功能(Initial Operational)里程碑。初始功能里程碑决定了产品是否可以在测试环境中进行部署。此刻，要确定软件、环境、用户是否可以开始系统的运作。此时的产品版本也常被称为“beta”版。
交付阶段：实现和测试工作流。
在交付阶段的终点是第四个里程碑：产品发布(Product Release)里程碑。此时，要确定目标是否实现，是否应该开始另一个开发周期。在一些情况下这个里程碑可能与下一个周期的初始阶段的结束重合。
RUP的迭代开发模型
RUP中的每个阶段都可以进一步分解为迭代。一个迭代是一个完整的开发循环，产生一个科执行的产品版本，是最终产品的一个子集，它增量式地发展，从一个迭代过程到另一个迭代过程到成为最终的系统。
在工作流中的每一次顺序的通过称为一次迭代。软件生命周期式迭代的连续，通过它，软件是增量的开发。
迭代过程的优点是降低了在一个增量上的开支风险。如果开发人员重复某个迭代，那么损失只是这个开发有误的迭代的花费；降低了产品无法按照既定进度进入市场的风险。通过在开发早期确定风险，可以尽早解决问题而不至于在开发后期匆匆忙忙；加快了整个开发工作的进度。因为开发人员清楚问题的焦点所在，他们的工作会更有效率。
由于用户的需求并不能在一开始就做出完全的界定，通常是在后续阶段中不断细化的。因此，迭代过程这种模式使适应需求的变化会更容易。
RUP的三大特点：
软件开发是一个迭代过程；
软件开发是由Use Case驱动的；
软件开发是以构架设计（Architectural Design）为中心的。
?敏捷过程与极限编程
2001年2月，为更有效地解决需求不确定性较大，而开发时间又较紧的软件项目开发带来的困扰，一批（17位）专家联合提出了一个敏捷软件开发宣言。敏捷开发过程的方法主要有：SCRUM，Crystal,特征驱动软件开发（Feature Driven Development，简称FDD），自适应软件开发(Adaptive Software Development，简称ASD)，以及最重要的极限编程(eXtreme Programming,简称XP极限编程，XP是于1998年由Smalltalk社群中的大师级人物Kent Beck首先倡导的)。
敏捷软件开发宣言包括如下一些可以让软件开发团队具有快速工作、响应变化能力的价值观和原则：
1.个体和交互胜过过程和工具
首先保证团队由优秀成员构成，它们之间有良好合作、沟通和交互能力
2.可以工作的软件胜过面面俱到的文档
主要精力要放在创建可工作的软件上面
3.客户合作胜过合同谈判
保证用户能与开发团队紧密协作、密切配合（否则再严格的合同规定也无法保证满足客户需求的不断变化）
4.响应变化胜过遵循计划
开发团队应有足够能力及时响应（业务或技术上的）变化
注意，左项的提出不是要否定右项。即，承认右项是有价值的，但是敏捷软件开发宣言认为左项的价值会更大。
极限编程(XP)是敏捷方法中最著名的一个，它由一系列好的开发实践组成，包括：
项目开发小组（Team）
在XP中，每个对项目做贡献的人都应该是项目开发小组中的一员。而且，这个小组中必须至少有一个人对用户需求非常清晰，能够提出需求、决定各个需求的优先级、根据需求等的变化调整项目计划，对每一次迭代给予反馈等。这个人扮演的是“客户”角色，最好他就是实际的最终用户，因为整个项目就是围绕最终用户的需求而展开的。程序员是项目开发小组中必不可少的成员。小组中可以有测试员，他们帮助客户制订验收测试；有分析员，帮助客户确定需求；通常还有个Coach（教练），负责跟踪开发进度、解决开发中遇到的一些问题、推动项目进行；还可以有一个项目经理，负责调配资源、协助项目内外的交流沟通等等。
并不是说项目小组中每个角色的工作是别人不能插手或干预的。XP鼓励每个人尽可能地为项目多做贡献，大家自由讨论、平等相处，取长补短，形成一个开放的工作空间，这就是最好的XP开发小组。
频繁地小规模发布软件（Small Releases）
在XP中，每个周期（Iteration）开发的需求都是用户最需要的东西。所发布的系统，都应该是用户很容易评估，或者已经能够投入实际运行的。这样，软件开发对于客户来说，成为实实在在，看得见摸得着的东西，能及时给予反馈。XP要求频繁地发布软件，如果有可能，应该每天都发布一个新版本；而且在完成任何一个改动、整合或者新需求后，就应该
立即发布一个新版本。这些版本的一致性和可靠性，是靠验收测试和测试驱动的开发来保证的。
验收测试
客户对每个需求都定义了一些验收测试。通过运行验收测试，开发人员和客户可以知道开发出来的软件是否符合要求。XP开发人员把这些验收测试看得和单元测试一样重要。
结对编程（Pair Programming）
XP中，所有的代码都是由两个程序员在同一台机器上一起完成的——这保证了所有的代码、设计和单元测试至少被另一个人复核过，代码、设计和测试的质量因此得到提高。
项目开发中，每个人会不断地更换合作编程的伙伴。因此，PairProgramming不但提高了软件质量，还增强了相互之间的知识交流和更新，增强了相互之间的沟通和理解。这不但有利于个人，也有利于整个项目、开发队伍和公司。
测试驱动开发
在软件开发中，只有通过充分的测试才能获得充分的反馈。XP中提出的测试与其它软件开发方法差不多，比如功能测试、单元测试、系统测试和负荷测试等；与众不同的是，XP 将测试结合到它独特的螺旋式增量型开发过程中，测试随着项目的进展而不断积累。另外，由于强调整个开发小组拥有代码，测试也是由大家共同维护的。即，任何人在向代码库中放程序（CheckIn）前，都应该运行一遍所有的测试；任何人如果发现了一个BUG，都应该立即为这个BUG增加一个测试，而不是等待写那个程序的人来完成；任何人接手其他人的任务，或者修改其他人的代码和设计，改动完以后如果能通过所有测试，就证明他的工作没有破坏原系统。这样，测试才能真正起到帮助获得反馈的作用；而且，通过不断地优先编写和累积，测试应该可以基本覆盖全部的客户和开发需求，因此开发人员和客户可以得到尽可能充足的反馈。
集体拥有代码（Collective Code Ownership）
与很多项目开发过程不同，XP提倡大家共同拥有代码，每个人都有权利和义务阅读其他代码，发现和纠正错误，重整和优化代码。这样，这些代码就不仅仅是一两个人写的，而是由整个项目开发队伍共同完成的，错误会减少很多，重用性会尽可能地得到提高，代码质量达到最好。
为了防止修改其他人的代码而引起系统崩溃，每个人在修改后都应该运行测试程序（这点也体现出XP的各个惯例和规则是怎样有机地结合在一起的）。
频繁地整合（Integration）
在很多项目开发中，开发人员在整合过程中经常会发现很多问题，但已很难确定到底是谁的程序出了问题。为了解决这些问题，XP提出，整个项目过程中，应该频繁地，尽可能地整合已经开发完的USERSTORY（每次整合一个新的USERSTORY）。每次整合，都要运行相应的单元测试和验收测试，保证符合客户和开发的要求。整合后，就发布一个新的应用系统。这样，整个项目开发过程中，几乎每隔一两天，都会发布一个新系统，有时甚至会一天发布好几个版本。通过这个过程，客户能非常清楚地掌握已经完成的功能和开发进度，并基于这些情况和开发人员进行有效地、及时地交流，以确保项目顺利完成。
（UserStory：开发人员要求客户把所有的需求写成一个个独立的小故事，每个只需要几天时间就可以完成。开发过程中，客户可以随时提出新的UserStory，或者更改以前的UserStory）
编程规范
XP开发小组中的所有人都遵循一个统一的编程标准，因此，所有的代码看起来好像是一个人写的。因为有了统一的编程规范，每个程序员更加容易读懂其他人写的代码。
不加班
大量的加班说明原来关于项目进度的估计和安排有问题，或者是程序员不清楚自己到底什么时候能完成什么工作。而且开发管理人员和客户也因此无法准确掌握开发速度；开发人员也因此非常疲劳。XP认为，为保持可持续的开发速度，每周工作不应超过40小时，连续加班不得超过两周。如果出现大量的加班现象，开发管理人员（比如Coach）应该和客户一起确定加班的原因，并及时调整项目计划、进度和资源。
计划项目
XP认为，最初的项目计划没有必要（也没有可能）非常准确。因为每个需求的开发成本、风险及其重要性都不是一成不变的。计划会在实施过程中被不断地调整以趋精确。
开发过程中，还会有很多阶段计划（比如每三个星期一个计划）。开发人员可能在某个周期对系统进行内部（代码和设计）的重整和优化，而在某个周期增加了新功能，甚至在一个周期内同时做两方面的工作，而客户也会再确定下一个周期要完成的需求。在同一个项目中，每经过一个开发周期，对下一周期的估算都会有更多的经验、参照和依据，从而更加准确，XP的这种做法也是为了及早发现问题、解决问题。
简单设计
XP要求用最简单的办法实现每个小需求，前提是按照这些简单设计开发出来的软件必须通过测试。这些设计只要能满足系统和客户在当下的需求就可以了，不需要任何画蛇添足的设计，而且所有这些设计都将在后续的开发过程中就被不断地重整和优化。
在XP中，没有那种传统开发模式中一次性的、针对所有需求的总体设计。在XP中，设计过程几乎一直贯穿着整个项目开发：从制订项目的计划，到制订每个开发周期（Iteration）的计划，到针对每个需求模块的简捷设计，到设计的复核，以及一直不间断的设计重整和优化。整个设计过程是个螺旋式的、不断前进和发展的过程。从这个角度看，XP是把设计做到了极致。
重整和优化(Refactoring)
开发人员对每个USERSTORY都进行简单设计，但同时也在不断地对设计进行改进，这个过程叫设计的重整和优化（Refactoring）。
Refactoring主要是努力减少程序和设计中重复出现的部分，增强程序和设计的可重用性。Refactoring的概念并不是XP首创的，它已经被提出了近30年了，而且一直被认为是高质量的代码的特点之一。但XP强调，把Refactoring做到极致，应该随时随地、尽可能地进行Refactoring，只要有可能，程序员都不应该心疼以前写的程序，而要毫不留情地改进程序。当然，每次改动后，程序员都应该运行测试程序，保证新系统仍然符合预定的要求。
Metaphor（系统比喻）
为了帮助每个人清楚一致地理解要完成的客户需求和要开发的系统功能，XP开发小组用很多形象的比喻来描述系统或功能模块是怎样工作的，让所有人对系统有个共同的、简洁的认识。比如，对于一个搜索引擎，它的Metaphor可能就是“一大群蜘蛛，在网上四处寻找要捕捉的东西，然后把东西带回巢穴。”
?微软过程
微软软件生命周期阶段划分和主要里程碑（P.26, 图1.13）
微软过程的生命周期模型（P.28, 图1.14）
系统的概念与系统思想的建立
①什么是“系统”
系统是相互依赖、相互作用的若干组成部分结合而成的，具有特定功能的整体（钱学森）
②定义中的几个要点
a.系统由多个相互依赖相互作用的元素组成
b.这些元素具有一定的组成结构
c.每个元素有各自的分功能，分功能是对系统总功能的贡献
d.系统总功能大于系统各元素分功能之和（系统有增益作用）
e.系统的基本要素包括：系统环境（位于系统之外，与系统有关联的部分）、系统边界（系统与环境间的分界，取决于系统目标的界定及研究者所关心的问题）、系统输入、系统输出、系统组成元素与各自功能、系统结构（各部分间交互关系，如层次式、网络式等）、子系统、接口（系统或子系统两两之间交互方式与内容）
③系统的思想与方法
复杂系统是由不那么复杂的子系统构成的。理解复杂系统可用分解的办法（这种分解可逐层不断进行），使复杂系统化解为许多可理解的小（小小）系统。
同样，复杂问题总是由不那麽复杂的子问题组成的，可用类似方法不断分解复杂问题使之不断降低复杂程度和抽象程度，成为一些简单的、具体的问题。底层简单问题的解决等与其相应上层问题的解决，上层问题全部解决就等于其相应上上层问题的解决。这种把复杂问题看成一个系统的思想，并利用分解——综合的办法解决之的做法就是系统的思想与方法。
第二章可行性研究
可行性研究目的与任务
目的：
以最小的代价，在尽可能短的时间内确定问题是否可解，以及是否值得去解。（并把研究结果形成文档交给用户。当项目可行时，还要向用户提出推荐方案的梗概和项目的初步计划。）
任务：至少从三方面进行分析
①技术上：技术的可利用性（该种技术的存在性、可利用性、可使用性，以及性能指
标，工程进度的实现上是否存在不可逾越的困难。例）
②可操作性上：是否有违法规、制度、约定、用户条件与环境约束、其它客户不可接
受的操作方案（如人对变革的恐惧与抗拒，例）
③经济上：是否符合成本-效益原则，即开发与运行成本是可接受的，且收益大于成
本。
成本一效益分析
任何项目投资均应取得效益，一般至少要考虑经济效益（有些情况下，也要考虑社会效益），既，收益-成本>0
a.开发成本（开发人员经费，开发环境，消耗品，设备购置安装，顾问咨询，开发商利润及其它）
b.运行成本（操作人员，软硬件维护，日常消耗品，运行环境及管理费等）
c.开发收益（技术革新投资带来的减免税，原有设备处理等）
d.运行收益（人员费用的节省，效率的提高，直接收入改善等）
①成本-效益分析方法：
货币的时间价值与收入折现：F=P(1+i)n ——复利公式
P=F/(1+i)n ——折现公式，
其中，1/（1+i）n为折现因子
a.投资回收期法：
回收期=投资/期均收益
要点：与其他投资方案的回收期比较。注意投资项目的预期寿命。
b.净现值法：
系统生命周期内累计收益的现值与累计投入的现值之差。
要点：净现值为零时，表明预期收入与投资到银行一样（若折现因子中的i取银行利率）。
只有净现值大于零才表明投资是可行的。但仅看净现值大小是不科学的，还要考虑原始投资的大小。如果甲项目净现值44160，乙项目净现值81500，应投资那个项目？
假设甲项目原始投资100000，乙项目原始投资1000000，可分别计算它们的NPV系数（NPV Coefficient）：
NPV C甲=44160/100000=0.4416
NPV C乙=81500/1000000=0.0815
表明甲项目可取。
c.投资回收率法：
F1/(1+i)+F2/(1+i)2+…+F n/(1+i)n-（C1/(1+i)+C2/(1+i)2+…+C M/(1+i)M）=0 要点：计算i，即当生命期内累计收益总额的现值减去投资额结果为零时的利率。其含义为：当确定下各期的收益F及C後，计算出仅仅为了收回成本，其内部增殖率就已达到了多少？显然i越大表明收益越大。可用i与银行利率及公司投资回收率标准进行比较。此公式计算可用数学表、软件包或试错法计算。
第三章需求分析
3.1 概述
需求分析的根本目标是获取准确的用户需求，并用E-R图、数据流图、数据字典、状态图，以及其它图、表、文字说明等构成关于新系统的模型或规格说明。这相当于工程化过程中要首先产生蓝图。
需求分析的任务:对系统必需实现的功能、性能及其他需求，提出完整、准确、清晰、具体的描述。即，产生完整的新系统逻辑模型。
具体工作包括：
1、确定对系统的综合要求：
功能要求——确定系统必须完成的所有功能（工作量最大）
性能要求——处理时间、效率、存储容量、安全性、灾害恢复等
可靠性和可用性需求——平均无故障时间长，任何时刻保证可用
出错处理需求——对各种出错情况的及时、有效反映与处理
接口需求——用户接口、硬件接口、软件接口、通讯接口等要求
约束——政策、法规、标准要求；精度、实现工具、软硬平台要求
逆向需求——不应该、不需要做什么
将来可能提出的要求——为将来可能的扩充修改所预做的准备。
2、分析系统的数据要求：
对系统的综合要求特别是功能要求基本确定后，要确定支持这些要求所需的数据，包括系统运行所需的系统输入、中间变换、预先存放的数据，以及产生的输出数据需求分析阶段要通过逻辑数据分析产生系统的概念数据模型。主要方法工具是E-R图，规范化等
3、导出系统的逻辑模型
根据功能分析和数据分析结果导出新系统的详细逻辑模型，模型由数据流图、数据字典、主要处理算法等构成。
4、修正系统开发计划
在需求分析的基础上，更准确地修正原拟的，关于今后的开发计划，包括对成本、进度的更准确的估计。
3.2 与用户沟通的技术
正确理解用户需求并不容易：分析员不熟悉该业务领域；用户不知如何表达自己的需求；现系统不能满足要求的关键问题有哪些；什么是最佳业务流程，其中哪些是可改造的，哪些是因为什么原因而不能改动…………
1、调研技术
以调研现行系统情况为例
弄清目的：了解运行状况、处理流程、存在问题、收集其它信息
a.新系统总是源於现系统。对现系统的研究有助于对拟建新系统的概念形成。
b.开发新系统是因为现系统存在不足，必须予以研究、澄清。
c.可行性研究需要在新旧系统间做比较才能完成。
重点调研的方面：
a.系统界限（包括功能范围、与其它系统的交接、涉及的组织机构与人员、在所处的更
大系统中的位置）；
b.运行状态（包括运行效率效果、运行费用与资源配置、管理水平）；
c.基本业务流程（系统输入、输出、各主要处理功能，绘出其业务信息流程）；
d.收集信息流载体（收集伴随业务信息流所需或所产生的全部单、据、证、表、报、册、
帐等，并与业务流相对照）；
e.薄弱环节（功能处理上的缺漏、不符、低效，及流程上的不合理等）；
f.约束条件（政策法规上、资金人员上、环境或其它）
调研注意事项：
a.预先约定（采访对象、时间、内容）；
b.调查顺序（先由上而下，再由下而上）；
c.注重数量概念（收集具体数据供可行性研究及推荐新方案使用）；
d.抓紧研究分析（避免因时间拖延造成情况模糊、信息丢失）；
e.把握调研主动权（研究对象心理，注意态度方法）
f.控制时间（现系统调研不能耗时太长，会丧失信任感）
要点：现系统研究耗费时间不宜过长，要有效率。
其它确定需求的方法：
采用会议方式收集所需信息
采用快速原型法获取对于需求的定义
2、应用规格说明技术
新系统的规格说明用模型表示。模型法的好处：记录系统所有复杂细节，且可随时修正；在考虑确定之前不必大规模投入资金与人力；是与用户交流、探讨的最佳媒介。
物理模型：实际运行系统的表示，含有非业务必需成分。
逻辑模型：又称Essential System(本质系统)，只强调系统做什么。
分析阶段的建模技术与规格说明
a.系统规格说明（目标系统概貌、功能要求、性能要求、可靠与可用性需求、出
错处理需求、接口需求、约束、逆向及将来可能提出的要求）。以及用户要求和系统功能之间的参照关系。规格说明可用自然语言描述（重要部分也可采用形式化描述）。
b.以DFD表示的处理功能模型。
c.以E-R图、数据字典、描绘数据结构的层次方框图或Warnier图等表示的系统
数据模型。
d.对动态交互、事件驱动类系统一般还要有行为模型（用状态图等表示）
注意需求分析过程要累积、书写文档。例如，除上述模型、规格说明外还应有：用户手册的初步内容（系统功能描述、性能描述、主要操作步骤与方法等），以及修正后的开发计划（成本估计、进度计划、资源使用计划等）。
3、必要时，开发原型系统
“必要时”的含义：用户需求说不清楚；除此之外难以沟通；用户无使用类似系统的经验，要求有一样板等。
原型主要包括主要界面、核心功能的演示（不必十全十美，甚至不必是真正完成了该功能）、重要输出等。
前提条件：原型部分不是很大、很复杂，有建立快速原型的工具软件，方便修改。
3.3 分析建模与规格说明
模型构成要素对模型的贡献
软件需求规格说明（参考框架）
Ⅰ.引言
A.系统参考文献
B.整体描述
C.软件项目约束
Ⅱ.信息描述
A.信息内容
B.信息流
1.数据流
2.控制流
Ⅲ.功能描述
A.功能分解
B.功能描述
1.处理说明
2.限制
3.性能需求
4.设计约束
5.支撑图
C.控制描述
1.控制规格说明
2.设计约束
Ⅳ.行为描述
A.系统状态
B.事件和动作
Ⅴ.确认标准
A.性能范围
B.测试种类
C.预期的软件响应
D.特殊考虑
Ⅵ.参考书目
Ⅶ.附录
3.4 实体-关系图
逻辑数据分析和逻辑数据模型的建立
目的：建立起最简单、无冗余且能完全支持过程模型需要的数据模型
逻辑数据分析可借助关系规范化完成，以使产生的数据模型达到最简、无冗余。逻辑数据模型本身可用E-R图或其它工具表达。
1)逻辑数据分析
范式（Normal Forms）——用以定义消除数据冗余的程度
规范化（Normalization）——使数据达到范式要求的过程
第一范式（1NF）——表中所有属性都是不可再细分的（包括属性中没有重复组、属性没有空白值）。
第二范式（2NF）——满足1NF，且表中所有非键属性都完全函数依赖于键的每一部分。第三范式（3NF）——符合2NF，且表中任何一个非键属性都不是传递依赖于健的任一部分的。
2)逻辑数据分析举例
（Student Registration System）做1NF、2NF、3NF，按实体归类，消除表中冗余，消除表间冗余，效率下降问题的解决，回答“系统所使用的数据文件是怎样最终确定下来的？”
EXERCISE FOR LOGICAL DATA ANALYSIS &DESIGN The Figure-1 is a DFD for a portion of a student registration system. The part of the system shown here contains several data stores，some used to maintain data over
a period of time and others used as transitional stores for the production of reports. During the components of these data stores are shown in the partial data dictionary in Figure-2. (The data elements that make up the key for each data store are italicized.) Note that each data store is an iteration of a data structure. Thus，the normalization of data is essentially equivalent to the normalization of a set of data structures.
CLASS-FILE ={CLASS} ALL classes offered where
CLASS =Class-Number+
Class-Name+
Class-Credits+
Class-Room+
Class-Time+
Class-Instructor+
Class-Enrollment+
Class-Maximum+
Class-Openings
INSTRUCTOR-FILE={INSTRUCTOR} ALL Instructors where
INSTRUCTOR = Instructor-Number+
Instructor-Name+
Instructor-Dept.+
Instructor-Office
REGISTRATINO-FILE ={STUDENT-REGISTRA TION} All students where STYDENT-REGISTRA TION = Student-Number+
Student-Name+
Student-Address+
Student-Credits
Class-Number+
Class-Name+
Class-Credits+
Class-Grade all classes for student
ROSTER-FILE ={ROSTER} All classes where
ROSTER =Class-Number+
Class-Name+
Class-Credits+
Class-Room+
Class-Time+
Class-Instructor+
Class-Enrollment+
Student-Number+
Student-Name+
Student-Level All students in class
STUDENT-FILE={STUDENT} All students where
STUDENT = Student-Number+
Student-Name+
Student-Address+
Student-Major+
Student-Level+
Student-Credits-Earned+
Student-GPA
TEACHING-FILE={INSTRUCTOR} All classes where
INSTRUCTOR-ASSIGNMENT = Instructor-Number+
Instructor-Name+
Instructor-Dept.+
Instructor-Credits+
Class-Number+
Class-Name+
Class-Credits+
Class-Enrollment all classes taught by instructor
FINGURE-2
Up to this point in system analysis，the focus has been on the transformations or processes. Data stores have been designed to support that process. The next step is to derive the best logical design for the set of data stores. The group of existing data stores is replaced in this analysis by its logical equivalent. The result is a set of simple data stores containing no redundant elements. This is the set of stores that will ultimately be packaged into physical files or databases that support processing in the most effective manner.
The procedure used to derive this logical structure is called normalization. In general，normalization produces the simplest，most straightforward organization of data elements into component data stores. Normalization should produce a set of data stores containing no redundant data elements accessible through use of unique primary keys. Please analyze the case given and make the data structures normalized and more logical as the whole.
3)逻辑数据模型（概念数据模型）：E-R图（Entity-Relationship Diagram）
最早由Peter. Chen于1967年提出。
实体——客观世界存在的，人们想用一组数据加以描述的任何一种对象或事件。它可以是人、事物、组织或抽象概念，如职工、产品、课程、城市、机器故障或时间单位。实体可看作是实例的集合。
属性——实体特征或性质的描述。
键——能够唯一地识别实体实例的一个或一组属性。
关系——两个或多个实体之间存在的自然联系（关系也可以具有属性）
关系的复杂度：
1：1联系——若从一实体中任取一个实例，另一实体中总有唯一一个实例与之对应（反之亦然），则这两个实体间存在着1对1的联系。
1：m联系——若从甲实体中任取一个实例，乙实体中有多个实例与之对应；反之，从乙实体中任取一个实例，甲实体中仅有一个实例与之对应，则这两个实体间存在着1对多的联系。M：n联系——若从甲实体中任取一个实例，乙实体中有多个实例与之对应；反之，从乙实体中任取一个实例，甲实体中也有多个实例与之对应，则这两个实体间存在着多对多的联系。
图符：
Peer Chen的实体关系图符号标记
实体：
关系：
例如:
数据关系是有方向的（从哪个方向读到那个方向）
业务规则：
序数基数最少实例数最大实例数
1:1 0:M 0:M 1:M