软件工程（1）
第一章 软件工程的概述
1.1 软件危机
-
软件危机的介绍：
-
硬件和软件发展的不平衡，硬件性能的发 展极其迅速，给软件提出了更高的要求 .**
-
软件开发和维护成本越来越大，令人吃惊 地高.**
-
失败的软件开发项目屡见不鲜.**
![]()
-
-
什么是软件危机：软件危机是指在计算 机软件的开发和维护 过程中所遇到的一系 列严重问题。
-
软件危机的表现：
-
软件成本日益增长。
-
开发进度难以控制
-
软件质量差
-
开发过程无法有效介入和管理
-
代码难以维护等
-
-
软件危机的原因：
-
技术原因：
-
软件规模越来越大
-
软件复杂度越来越高
-
-
管理原因：
-
软件开发缺乏正确的理论指导，过分依靠个人技巧和创造性
-
对用户需求没有完整准确的认识
-
-
-
如何解决软件危机？：
-
软件工程
-
-
消除软件危机的途径：
-
对计算机软件正确认识。
-
推广使用开发软件成功的技术和方法，研究探索更好更有效的技术和方法，消除错误概念和做法
-
开发和使用更好的软件工具
-
对于时间、人员、资源等需要引入更加合理的管理措施。
-
1.2 软件工程
-
概述：软件工程正是从技术和管理两方面研究如何更好地开发和维护计算机软件的一门新兴学科。
-
定义：1968年秋，提出软件工程
-
将系统化、规范化、可量化的工程原则和方法，应用于软件的开发、运行和维护；
-
对其中方法的理论研究。
-
-
主要目的：高效开发高质量软件，降低开发成本。
-
软件工程的基本原理（开发与维护的指导）：
-
用分阶段的生命周期计划严格管理
-
坚持进行阶段评审
-
实行严格的产品控制
-
采用现代程序设计技术
-
结果应能清楚地审查
-
开发小组的人员应该少而精
-
承认不断改进软件工程实践的必要性
-
1.3 系统工程
-
定义：系统工程是为了更好地达到系统目标，对系统的构成要素、组织结构、信息流动和控制机构等进行分析与设计的技术。
-
实现方法：针对不同的领域，系统工程有着不同的实现方法， 如商业过程工程（Business Process Engineering）、 产品工程（Product Engineering）等。
-
目的：系统工程的目的是使得人们能够确保在正确的时间使用了正确的方法在做正确的事情。
1.4 系统分析方法
-
方法：系统分析的常用方法是层次分析方法， 将问题分解为不同的组成因素，并按照因素间的相互关联影响以及隶属关系将因素按不同层次聚集组合，形成 一个多层次的分析结构模型。
1.5 软件工程开发方法
-
软件工程的三要素：方法、工具和过程
-
方法是完成软件开发各项任务的技术，回答“如何做”；
-
工具是为方法的运用提供自动或半自动软件支撑环境，回答“用什么做”；
-
过程是为获得高质量的软件要完成的一系列任务的框架，规定完成各项任务步骤，回答“如何控制、协调、保证质量”
-
-
随着软件工程的发展及技术的不断进步，软件工程开发方法从人们分析问题角度和方式的不同，可以笼统的分为传统的和面向对象的两种。
-
传统方法：传统开发方法又称为结构化方法，是一种静态的思想
-
将软件开发过程划分成若干个阶段，并规定每个阶段必须完成的任务，各阶段之间具有某种顺序性；
-
体现出对于复杂问题“分而治之”的策略，但主要问题是缺少灵活性，缺少应对各种未预料变化的能力，这些变化却是在实际开发中无法避免的；
-
当软件规模比较大，尤其是开发的早期需求比较模糊或者经常变化的时候，这种方法往往会导致软件开发的不成功或维护困难；
-
-
传统方法的特点：
-
生命周期模型
-
软件过程划分为若干个阶段
-
每个阶段有各自的任务
-
阶段之间有某种顺序性
-
![image-20220906105214358]()
-
-
面向对象方法：
-
对象作为融合数据及在数据之上的操作行为的统一的软件构件。
-
把所有对象都划分成类(Class)。每个类都定义了一组数据和一组操作。
-
按照父类(或称为基类)与子类(或称为派生类)的关系，把若干个相关类组成一个层次结构的系统(也称为类等级)。在类等级中，下层派生类自动拥有上层基类中定义的数据和操作，称为继承。
-
对象彼此间仅能通过发送消息互相联系－封装性。
-
-
面向对象的特点：
-
面向对象方法学的出发点和基本原则，是尽可能模拟人类习惯的思维方式。
-
用面向对象方法学开发软件的过程，是一个主动地多次反复迭代的演化过程
-
概念和表示方法上的一致性，阶段间平滑（无缝）过渡。
-
特殊到一般的归纳思维过程；一般到特殊的演绎思维过程。（继承的思想）
-
最终产品中的对象与现实世界中的实体相对应，降低了复杂性，提高了可理解性，简化了软件的开发和维护工作。
-
对象是相对独立的实体，容易在软件产品中重复使用，促进了软件重用
-
面用对象方法特有的继承性，也进一步提高了面向对象软件的可重用性
-
第二章 软件开发过程
-
定义：软件开发过程（software development process）又叫做软件开发生命周期（software development life cycle,SDLC），是软件产品开发的任务框架和规范，又可以简单的称为软件生命周期及软件过程。
2.1 软件生命周期与开发过程
-
**国际标准ISO/IEC 12207是软件生命周期过程的国际标准，旨在提供一套软件开发与维护过程中涉及的各种任务定义的标准，如软件生命周期的选择、实现与监控等。
-
可重复的、可预测的过程能够提升软件生产的效率和质量。
-
软件工程过程小组(Software Engineering Process Group, SEPG)提供给软件开发人员统一的标准的开发原则，充分协调各开发人员、开发小组，通过过程控制的方法，保证软件产品的质量
2.2 软件过程与生命周期
-
通常生命周期模型要更一般化，而软件开发过程则更为具体化。
-
可重复的、可预测的过程能够提升软件生产的效率和质量。（过程改进）
-
生命周期是软件开发的宏观上的框架，软件过程则涉及到软件开发的流程等管理细节，在框架稳定的前提下允许对软件过程进行裁剪
-
4种不同类型的生命周期：顺序式、迭代式、增量式以及敏捷式
2.2 软件生命周期
-
过程管理：过程管理主要采用的是一种“分而治之”的思想，即将整个软件的生命周期划分成软件定义、软件开发和运行维护三个主要的时期，每个时期再细分为具体的阶段，分别对应明确的任务
-
可行性分析与开发计划：
-
目的：用最小的代价在尽可能短的时间内确定该软件项目是否能够开发，是否值得开发，最后给决策者提供做与不做的依据。（较高层次的需求分析和设计）
-
任务：确定项目的规模和目标，确定项目的约束和限制；进行简要的需求分析，抽象出逻辑结构，建立逻辑模型；从逻辑模型出发，经过压缩的设计，探索出若干种可供选择的主要解决办法。
-
每种解决方法都要从三方面研究它的可行性：技术可行性、经济可行性和社会可行性。
-
描述所提出的解决方案和方案的可行性，并拟定开发计划，包括对费用、时间、进度、人员组织、硬件配置、软件开发环境和运行环境配置等进行说明和规划。
-
-
需求分析：
-
在确定软件开发可行的情况下，对目标软件未来需要完成的功能进行的详细分析。
-
需求分析是软件开发后续阶段的基础，直接关系到整个系统开发的成功与否。由于用户的需求随着项目的进展和理解处在不断的变化之中，应对需求进行变更管理。
-
应充分理解和掌握用户对目标软件的期望，除功能需求外还要对系统设计有影响的非功能性需求加以识别和分析。
-
需求分析阶段的输出是一份“需求规格（Specification）说明书”的文档。
-
-
软件设计：
-
软件设计是在需求分析的基础上寻求系统求解的框架，如系统的架构设计、数据设计等。
-
软件设计可分为概要设计和详细设计，此阶段的输出分别为“概要设计说明书”和“详细设计说明书”。
-
设计方案是软件实现的蓝图，应综合考虑软件的性能、扩展、安全等因素，合理规划系统模块的结构，充分考虑未来变化的可能性并预留空间，尽可能保证系统设计结构在整体上的稳定性。
-
-
程序编码：
-
此阶段是将软件设计的结果翻译成某种计算机语言实现的程序代码。
-
在程序编码中必须要制定统一的如何编码的标准规范，尽量提高程序的可读性、易维护性，提高程序的运行效率。
-
-
软件测试：
-
程序编码后需要对代码进行严密的测试，以发现软件在整个设计过程中存在的问题并加以纠正。
-
测试的环节可分为单元测试、集成测试及系统测试三个阶段进行。
-
测试方法主要包括黑盒和白盒方法。
-
测试过程需要建立详细的测试计划、编写测试用例、记录并分析测试结果，以保证测试过程实施的有效性，避免测试的随意性。
-
-
软件维护：
-
软件维护是软件生命周期中持续时间最长的阶段，是为软件能够持续适应用户的要求延续软件使用寿命的活动。
-
改正性维护：诊断和改正在使用过程中发现的软件错误；
-
适应性维护：修改软件以适应环境的变化；
-
完善性维护：根据用户的要求改进或扩充软件使它更完善；
-
预防性维护：修改软件为将来的维护活动预先做准备。
-
-
2.3 传统生命周期模型
2.3.1 瀑布模型：
-
瀑布模型：在20世纪80年代之前，瀑布模型一直是唯一被广泛采用的生命周期模型，现在仍然是应用得最广泛的过程模型。
-
按照传统的瀑布模型来开发软件，有如下特点：
-
阶段间具有顺序性和依赖性，文档驱动。
-
推迟实现，不急于编写代码。
-
尽可能的理解和掌握系统需求。
-
清楚地区分逻辑设计与物理设计，尽可能推迟程序的物理实现。
-
-
质量保证的观点 ：
-
每个阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务。
-
每个阶段结束前都要对所完成的文档进行评审，以便尽早发现问题，改正错误。
-
-
-
瀑布模型的问题：
-
不希望有“变化”
-
变化来的越晚，付出的代价越高。
-
设计阶段过多的假设，导致理想化、一厢情愿的东西过多。(用户只参与需求) 。
-
“文档驱动”，静态。
![image-20220906131954791]()
-
-
实际瀑布模型：
-
可以在一定程度解决“变化”的问题。
-
计划驱动，在对系统整体的把控和协调上，具有优势，因此适合规模较大的系统或分布式开发模式。
![image-20220906132432082]()
-
2.3.2 快速原型模型：
-
快速原型模型（Rapid Prototype）的主要作用是在用户和开发者之间起到“桥梁”的作用。
-
开发者和用户之间经常面临的一个状况是：用户熟悉的是业务但不懂得开发的技术，而开发者正好相反，其更熟悉具体的开发方法、工具等技术内容而不明白相关的业务流程。
-
这也是为什么需求分析较难开展的原因之一，也是无法固化用户需求的客观原因之一。
-
快速原型模型的特点：
-
快速原型模型要求对系统进行简单和快速的分析，快速构造一个软件原型。
-
用户和开发者在试用或演示原型过程中加强沟通和反馈，通过反复评价和改进原型，减少双方的误解，降低缺陷引入的几率，降低由于需求不明确带来的开发风险和提高软件质量，获取到用户真正的需求。
-
比较适合一个全新的系统开发，用户借助原型了解开发方向的正确性，如用户界面的构建，使用户建立起对未来系统的认识和了解。
-
快速原型中可以尝试运用未来系统中需要的新技术，提前测试一些性能上的要求是否能够达到预期。
-
-
快速原型的问题：
-
所选用的开发技术和工具不一定是实际项目的需要。
-
快速建立起来的模型可能由于不符合各种开发规范，再加上不断的修改，质量一般都比较差，通常在实际开发过程中会完全抛弃之前建立起来的原型系统。
-
2.3.3 增量模型：
-
增量模型也称为渐增模型。把软件产品作为一系列增量构件（构件是系统中实际存在的可更换部分。）来设计、编码、集成和测试。
-
每个构件由多个相互作用的模块构成，并且能够完成特定的功能。
-
使用增量模型时，第一个增量构件往往实现软件的基本需求，提供最核心的功能。(滚雪球方式)。
2.3.4 螺旋模型：
-
螺旋模型的基本思想是使用原型及其它方法尽量降低风险。
-
在每个阶段之前都增加了风险分析过程的快速原型模型。
-
-
特别适合于大型复杂的系统。螺旋模型沿着螺线进行若干次迭代，四个象限代表了不同的活动。
2.3.5 喷泉模型：
-
迭代是OO开发过程的主要特性。
-
喷泉模型是典型的面向对象生命周期模型。
-
“喷泉” 体现了面向对象软件开发过程迭代和无缝的特性。
-
为避免喷泉模型的过分无序，把一个线性过程作为总目标。
2.3.6 敏捷软件开发
-
概述：
-
迭代式开发。
-
增量交付。
-
开发团队和用户反馈推动产品开发。
-
持续集成 。
-
开发团队自我管理。
-
-
敏捷的宣言：
-
个体和互动胜过流程和工具；
-
工作的软件胜过详尽的文档；
-
客户合作胜过合同谈判；
-
响应变化胜过遵循计划。
-
-
迭代的思想就是当对需求还没有信心的时候，不指望构建的软件正是客户所想要的，但可以先构建后修改，通过多次反复找到真正客户需要的软件。（逐步求精）
-
精确，质量，速度，丰厚的投资回报率，高效的自我管理团队。
-
敏捷开发更适合规模中小、需求变化频繁的系统开发，并且强调团队的作用，所以更适合集中式的开发模式。
2.3.7 增量的开发方式
-
增量开发的方式即分批分期的交付用户产品，通过增量开发来应对软件产品之外的不确定因素（风险）。
-
敏捷方法建议先实现必要性的用户案（用）例（用户故事）（“用例”是指一件用户通过系统完成的有价值的目标，它不是一个具体的功能。），体现出软件的价值，然后在后续版本中对功能进行细化，使得我们的软件产品的所有功能都能够达到相同的用户体验水平。
2.3.8 迭代的开发方式
-
-
迭代的思想就是当对需求还没有信心的时候，不指望构建的软件正是客户所想要的，但可以先构建后修改，通过多次反复找到真正客户需要的软件。（逐步求精）
浙公网安备 33010602011771号