定义：
1）指令的集合（计算机程序），通过执行这些指令可以满足预期的特性、功能和性能需求。
2）使得程序可以合理利用信息的数据结构。
3）以硬拷贝和虚拟形式存在的用来描述程序的操作和使用的软件描述信息。
4）支持用户应用软件的服务
特点：
1）软件是逻辑的非物理的系统元素，不会“磨损”。
2）软件存在退化。
3）在完整的生命周期里，软件会面临变更，每次变更都会引入新的错误。
七个大类：系统软件、应用软件、工程/科学软件、嵌入式软件、产品线软件、Web/移动App、人工智能软件。
定义：
1）软件工程是将系统化的、可规范化的、可量化的方法应用于软件的开发、维护和运
行，即将工程化的方法应用于软件。软件工程是对上述中所述的方法的研究。
内容：
1）软件工程是一种层次化的技术，支持软件工程的根基在于质量关注点。
2）软件工程的基础是过程层。
3）软件工程方法为构建软件提供技术上的解决方法。
4）软件工程工具为过程和方法提供自动化或半自动化的支持。
四大层次：
质量关注点（quality focus）
过程层（process）
方法层（methods）
工具层（tools）
定义：
软件过程是工作产品构建时所执行的一系列活动、动作和任务的集合。
组成部分：
活动：主要实现宽泛的目标（如与利益相关者进行沟通）。
动作：包含了主要工作产品（如体系结构设计模型）生产过程中的一系列任务。
任务：关注小而明确的目标，能够生产实际产品（如构建一个单元测试）。
过程框架定义了若干个框架活动，为实现完整的软件工程过程建立了基础。过程框架还包含一些适用于整个软件过程的普适性活动（umbrella activity）
通用软件工程过程框架定义了个活动：沟通、策划、建模、构建、部署。
沟通：在技术工作开始之前，和客户（及其他利益相关者）的沟通与协作是极其重要的，其目的是理解利益相关者的项目目标，并收集需求以定义软件特性和功能。
策划：策划活动就是指导团队的项目旅程。软件项目计划定义和描述了软件工程工作，包括需要执行的技术任务、可能的风险、资源需求、工作产品和工作进度计划。
建模：软件建模包括需求分析和设计。需要对整个项目有一个整体的构想——体系结构、不同的构件如何结合，以及其他一些特性。软件工程师也需要利用模型来更好地理解软件需求，并完成符合这些需求的软件设计。
构建：必须要对所做的设计进行构建，包括编码（手写的或者自动生成的）和测试，后者用于发现编码中的错误。
部署：软件（全部或者部分增量）交付给用户，用户对其进行评测并给出反馈意见。
软件工程过程框架活动由很多普适性活动来补充实现。这些普适性活动贯穿软件项目始终，帮助软件团队管理和控制项目进度、质量、变更和风险。
包括：
软件项目跟踪和控制；风险管理；软件质量保证；技术评审；
测量；软件配置管理；可复用管理；工作产品的准备和生产
通用的框架活动——沟通、策划、建模、构建和部署——和普适性活动构成了软件工程工作的体系结构的轮廓。但是软件工程的实践如何融入该框架？
包括：
1）理解问题（沟通和分析）
2）策划解决方案（建模和软件设计）
3）实施计划（代码生成）
4）检查结果的正确性（测试和质量保证）
包括：
1）存在价值
2）保持简洁
3）保持愿景
4）关注使用者
5）面向未来
6）提前计划复用
7）认真思考
略。
技术定义：为创建高质量软件所需要完成的活动、动作和任务的框架。软件过程定义了软件工程化中采用的方法。
概念：在开发产品或构建系统时，遵循一系列可预测的步骤（即路线图）是非常重要的，它有助于及时交付高质量的产品。软件开发中所遵循的路线图就称为“软件过程”。
重要性：软件过程提高了软件工程活动的稳定性、可控性和有组织性，如果不进行控制，软件活动将变得混乱。
软件过程示意图如下所示，由图可以看出，每个框架活动由一系列软件工程动作构成；每个软件工程动作由任务集来定义，这个任务集明确了将要完成的工作任务、将要产生的工作产品、所需要的质量保证点，以及用于表明过程状态的里程碑。
正如第二章讨论的，软件工程的通用过程框架定义了五种框架活动——沟通、策划、建模、构建以及部署。此外，一系列普适性活动——项目跟踪控制、风险管理、质量保证、配置管理、技术评审以及其他活动——贯穿软件过程始终。但是还有一个很重要的方面没讨论——过程流。
过程流（process flow）：
过程流描述了在执行顺序和执行时间上如何组织框架中的活动、动作和任务。
线性过程流（linear process flow）：从沟通到部署顺序执行五个框架活动
迭代过程流（iterative process flow）：在执行下一个活动前重复执行之前的一个或多个活动
演化过程流（evolutionary process flow）：采用循环的方式执行各个活动，每次循环都能产生更为完善的软件版本。
并行过程流（parallel process flow）：将一个或多个活动与其他活动并行执行。
关键问题：针对给定的问题、开发人员和利益相关者，哪些动作适合于框架活动？
略。
过程模式描述了软件工程工作中遇到的过程相关的问题，明确了问题环境并给出了针对该问题的一种或几种可证明的解决方案。
过程模式的描述模板：
1）模式名称
2）驱动力
3）类型
4）启动条件
5）问题
6）解决方案
7）结果
8）相关模式
9）已知应用和实例
惯用过程模型力求达到软件开发的结构和秩序，期活动和任务都是按照过程的特定指引顺序进行的。
所有过程模型的鼻祖。瀑布模型把软件开发过程划分成若干阶段，每个阶段的任务相对独立，便于不同人员分工协作，从而降低了整个软件开发工程的困难程度。
适用情况：
1）沟通到部署都采用合理的线性工作流方式
2）可以清楚地理解问题的需求
优点特点：
1）是一个系统的、顺序的软件开发方法
2）易于组织和管理
3）质量保证：可以按照阶段检查，及时发现问题；每个阶段必须完成规定的文档
缺点：
1）随着项目组工作的推进，变更可能造成混乱。
2）客户通常难以清楚地描述所有的需求。而瀑布模型却要求客户明确需求，这就很难适应在许多项目开始阶段必然存在的不确定性。
3）客户必须要有耐心。只有到最后阶段，项目接近尾声时，才能得到可执行的程序。
适用情况：
1）初始的软件需求有明确的定义，但是整个开发过程却不宜单纯运用线性模型。
2）可能迫切需要为用户迅速提供一套功能有限的软件产品，然后在后续版本中再进行细化和扩展功能。
优点特点：
1）第一个增量往往是核心产品
2）每个阶段都交付一个可用的产品
3）融合了瀑布模型的基本成分和快速原型的迭代特征
缺点：
1）由于各个构件是逐渐并入已有的软件体系结构中的，加入构件不能破坏已构造好的系统部分，这需要软件具备开放式的体系结构。 即每个构件都需要具备可扩展性。
2）在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力优于瀑布模型和原型模型，但也很容易退化为边做边改， 使软件过程的控制失去整体性。
3）如果增量之间存在相交的情况且未很好处理，则必须做全盘系统分析。
原型模型 the prototype model
适用情况：
1）客户定义了软件的一些基本任务，但是没有详细定义功能和特性需求。
2）开发人员对算法的效率、操作系统的适用性和人机交互的形式等情况并没有把握。
优点特点：
1）用户参与，原型可以由用户评估并用于细化需求
2）提高系统的实用性、可维护性
3）节省开发的投入、缩短整个软件的开发周期
4）采用迭代技术，使开发者逐步清晰用户的需求
缺点：
1）大多数项目中，构建的第一个系统很少是好用的
2）利益相关者看到了软件的工作版本，却未察觉到整个软件是随意搭建成的，也未察觉到为了尽快完成软件，开发者没有考虑整体软件质量和长期的可维护性
3）为了使原型快速运行起来，往往在实现过程中采用折中的手段。会使用不合适的操作系统或程序设计语言，也会采用一些低效的算法。
螺旋模型（the spiral model）
螺旋模型是一种演进式软件过程模型。
优点特点：
1）结合了原型的迭代性质和瀑布模型的可控性和系统性特点
2）具有快速开发越来越完善的软件版本的潜力
3）采用循环方式逐步加深系统定义和实现的深度，同时降低风险
4）确定一系列里程碑作为支撑点，确保利益相关者认可是可行的且可令各方满意的系统解决方案
5）紧密围绕开发中的风险问题，用风险分析推动软件设计向深一层扩展、求精
6）随着迭代的增加（成本的增加），风险程度随之降低
缺点：
1）比较复杂，需要相当的风险评估技术，且成功依赖于这种技术。
2）难以使客户（特别是以合同的形式）相信演进的方法是可控的。
并发开发模型有时也叫做并发工程，它允许软件团队表达本章所描述的任何过程模型中的迭代元素和并发元素。并发模型可用于所有类型的软件开发，它能够提供精确的项目当前状态图。
专用过程模型应用面较窄且较专一，只适用于某些特定的软件工程方法。
基于构件的开发模型（component-based development model）具有许多螺旋模型的特点。它本质上是演化模型，需要以迭代方式来构建软件。不同之处在于，基于构件的开发模型采用预先打包的软件构件来开发应用系统。
形式化方法模型（formal methods model）的主要活动是生成计算机软件形式的数学规格说明。形式化方法使软件开发人员可以应用严格的数学符号来说明。
横切关注点：涉及系统多个方面的功能、特性和信息。
方面的需求（aspectual requirement）：定义那些对整个软件体系结构产生影响的横切关注点。
面向方面的软件开发（AOSD) 通常称为 面向方面编程（AOP） 或者 面向方面构件工程（AOCE）。
特点：用例驱动，以架构为核心，迭代并且增量。
1）UP的起始阶段（inception phase）：包括客户沟通和策划活动。沟通阶段识别基本业务需求，并初步用用例描述每一类用户所需要的主要特性和功能。策划阶段将识别各种资源，评估主要风险，制定进度计划，，为软件增量开发建立基础。
2）UP的细化阶段（Elaboration Phase）：包括策划和通用过程模型的建模活动。细化阶段根据初始阶段定义的用例，扩展体系结构，设计详细的系统架构。包括五种视图——用例模型、需求模型、设计模型、实现模型、部署模型。
3）UP的构建阶段（construction phase）：采用体系结构模型作为输入，开发软件构件，并且要对构件实施单元测试和集成活动。
4）UP的转换阶段（transition phase）：包括通用构建活动的后期阶段以及通用部署（交付和反馈）活动的第一部分。将软件交给最终用户进行Beta测试，用户反馈意见，然后进行必要变更。
5）UP的生产阶段（production phase）：对持续使用的软件进行监控，提供运行环境的支持，提交并评估缺陷报告和变更请求。
敏捷宣言声明：
1）个人和他们之间的交流胜过开发过程和工具
2）可运行软件胜过宽泛文档
3）客户合作胜过合同谈判
4）变更的良好响应胜过按部就班
1）有效地响应变更
2）鼓励沟通和团队协作
3）强调可运行软件的快速交互
4）将客户作为开发团队的一部分开展工作
5）项目计划可以灵活调整
传统方法中，变更成本随着计划的进展成非线性增长。
敏捷开发，会减少变更的成本。
可适应性、增量式开发策略。
十二项敏捷原则：略
略
XP使用面向对象方法作为推荐的开发范型，它包含了策划、设计、编码和测试4个框架活动的规则和实践。
具有六个新实践：准备评估、项目社区、项目特许、测试驱动管理、回顾、持续学习。
Scrum；DSSD；敏捷建模（AM）；敏捷统一过程（AUP）
需求工程定义：需求工程是指致力于不断理解需求的大量任务和技术。从软件过程的角度来看，需求工程师一个软件工程动作，开始于沟通并持续到建模活动。它必须适用于过程、项目、产品和人员的需要。
七项需求工程任务：
1）起始：要建立基本的理解，包括存在的问题、谁需要解决方案、所期望解决方案的性质、与项目利益相关者和开发人员之间达成初步交流合作的效果。
2）获取：询问客户、用户和其他人相关需求。最重要的是建立商业目标。
3）细化：对获得的信息进行扩展和提炼。核心是开发一个精确的需求模型，用以说明软件功能、特征和信息。
4）协商：需求工程师通过协商来调节冲突，最终使各方均能达到一定的满意度。
5）规格说明：正式或非正式地描述需求的说明。可以是文档、图形化模型、形式化数学模型、场景、原型等。
6）确认：对需求工程的工作产品进行质量评估。要检查规格说明，审查其中的错误、模糊、遗漏、不一致、冲突等。
7）需求管理：用于帮助项目组在项目进展中标识、控制和跟踪需求以及需求变更的一组活动。
定义：直接或间接地从正在开发的系统中获益的人
不同的利益相关者，有不同的需求观点。需求工程师需要把所有利益相关者提供的信息分类。
客户之间应该团结协作，并和软件工程人员团结协作。需求工程师的工作是标识公共区域（所有利益相关者都同意的需求）和矛盾区域。
在项目开始时的提问应该是“与环境无关的”。
第一组问题：集中于客户和其他利益相关者以及整体目标和收益。
第二组问题：允许客户表达其对解决方案的看法。
第三组问题：关注沟通活动本身的效率。（元问题）
需求获取（又称为需求收集）：将问题求解、细化、协商和规格说明等方面的元素结合在一起。
基本原则：
协作收集需求的目标：标识问题、提出假设解决方案的相关元素、协商不同方法以及确定一套解决需求问题的初步方案。
召开会议可能做的工作：在需求起始阶段写下“产品要求”；选择会议地点、时间和日期；选派主持人；邀请软件团队和其他利益相关者参加会议；给所有参会者分发产品需求。
定义：质量功能部署是一种将客户要求转化为软件技术需求的技术。
目的：QFD的“目的是最大限度地让客户从软件工程过程中感到满意”。
强调：QFD强调理解“什么是对客户有价值的”，然后在整个工程活动中部署这些价值。
常规需求
常规需求：是指在会议中向客户陈述一个产品或系统时的目标，如果这些需求存在客户就会满意。
期望需求
期望需求：暗指在产品或系统中客户没有清晰表述的基础功能，缺少了这些将会引起客户的不满。
兴奋需求
兴奋需求：超出客户预期的需求，当这些需求存在时会令人非常满意。
客户意见表
客户意见表：QFD通过客户访谈和观察、调查以及历史数据检查为需求收集活动获取原始数据，然后翻译成的需求表。
为了在软件团队弄清用户如何使用之前实施更技术化的软件工程活动，开发人员和用户可以创建一系列的场景——场景可以识别对将要构建系统的使用线索。场景通产称为用例，它描述人们将如何使用某一系统。
包括：
1）要求和可行性陈述
2）系统或产品范围的界限说明
3）参与需求获取的客户、用户和其他利益相关者的名单
4）系统技术环境的说明
5）需求列表以及每个需求适用的领域限制
6）一系列使用场景
7）任何能够更好地定义需求的原型
在敏捷过程中，通过向所有利益相关者询问，生成用户故事以获取需求。
用户故事是从客户中获取并记录需求的方式
面向服务的开发将系统看做一套服务的集合。它的需求获取关注由应用系统所定义的服务。
==用例：==用例是从参与者的角度定义的。参与者是人员（用户）或设备在和软件交互时所扮演的角色。
撰写用例的第一步：确定故事中所包含的“参与者”。
分析模型的作用：为基于计算机的系统提供必要的信息、功能和行为域的说明。
1）基于场景的元素
使用基于场景的方法可以从用户的视角描述系统。
2）基于类的元素
每个使用场景都意味着当一个参与者和系统交互时所操作的一组对象，这些对象被分成类——具有相似属性和共同行为的事物集合。
3）行为元素
基于计算机的系统行为能够对所选择的设计和所采用的实现方法产生深远的影响。因此需求分析模型必须提供描述行为的建模元素。
状态图：是一种表现系统行为的方法，该方法描绘系统状态以及导致系统改变状态的事件。
简化后的UML状态图：
分析模式的两个优点：首先分析模式提高了抽象分析模型的开发速度，通过提供可重复使用的分析模型捕获具体问题的主要需求。其次，通过建议的设计模式和可靠的通用问题解决方案，分析模式有利于把分析模型转化为设计模型。
敏捷需求工程的意图是把利益相关者的思想传递给软件团队。
需求建模类型：
1）场景模型：出自各种系统“参与者”观点的需求。
2）面向类的模型：表示面向对象类（属性和操作）的模型，其方式为通过类的协作获得系统需求。
3）基于行为和模式的模型：描述如何将软件行为看作外部“事件”后续的模型。
4）数据模型：描述问题信息域的模型。
5）面向流的模型：表示系统的功能元素并且描述当功能元素在系统中运行时怎样进行数据变换。
需求模型三个主要目标：
1）描述客户需要什么
2）为软件设计奠定基础
3）定义在软件完成后可以被确认的一组需求
创建分析模型时的经验原则：
略
域分析：
软件域分析是指识别、分析和详细说明某个特定应用领域的共同需求。
需求建模的方法：
1）结构化分析：考虑数据和处理的需求建模方法
2）面向对象的分析：关注类的定义和影响客户需求的类之间的协作方式。例：UML和统一过程
使用UML需求建模将从开发用例、活动图和泳道图形式的场景开始。
（1）开发用例
流程：创建初始用例——细化初始用例——编写正式用例。
用例模板：
（2）初步用例图
（3）开发活动图
元素：
两端为半圆形的矩形：表示一个特定的系统功能
菱形：表示分支
实水平线：意味着并行发生的活动
黑色圆圈：开始
黑心白边圆圈：结束
（4）泳道图
UML泳道图是活动图的一种有用的变形，允许建模人员表示用例所描述的活动流。
UML泳道图表现了活动流和一些判定，并指明由哪个参与者实施。
类图建模流程：识别分析类——描述属性——定义操作。
识别分析类：
要对系统开发的用例进行“语法解析”，一般是寻找名词或名词词组。
描述属性：
属性是在问题的环境下完整定义类的数据对象集合。它描述了已经选择包含在需求模型中的类。
定义操作：
操作定义了某个对象的行为。粗略可划分为4中类型：1）以某种方式操作数据；2）执行计算操作；3）请求某个对象状态操作；4）监视某个对象发送某个控制事件操作。
类图示例：
类-职责-协作者建模（Class-Responsibility-Collaborator，CRC）：
CRC模型实际上是表示类的标准索引卡片的集合。分三部分：顶部类名；主体左侧列出类的职责；右侧列出类的协作者。
CRC卡示例：
类：
1）实体类
2）边界类
3）控制类
职责（属性和操作）：
5个指导原则：略。
协作：
定义：协作是以客户职责实现的角度表现从客户到服务器的请求。协作是客户和服务器之间契约的具体实现。
类实现职责的方法：
1）类可以使用其自身的操作控制各组的属性，从而实现特定的职责。
2）类可以和其他类协作。
三种通用关系：
1）is-part-of（是……一部分）
2）has-knowledge-of（有……知识）
3）depends-upon（依赖……）
分析类的关联和依赖关系：
关联（association）：两个分析类以某种方式相互联系着。
多样性：关联可以进一步指出多样性。
关联定义了类之间的联系，多样性定义了一个类和另一个类之间联系的数量关系。
依赖：两个分析类存在客户—服务器关系，客户类以某种方式依赖于服务器类。
行为建模描述了系统及其类的状态，以及事件对这些类的影响。
将系统行为表示成一个特定的事件和时间的函数。
行为模型：行为模型显示了软件如何对外部事件或激励做出响应。
步骤：
1）评估所有的用例
2）识别驱动交互顺序的事件
3）为每个用例生成序列
4）创建系统状态图
5）评审行为模型以验证准确性和一致性
只要系统与参与者之间交换了信息就发送了事件。
在行为建模中，必须考虑两种不同的状态描述：1）系统执行其功能时每个类的状态；2）系统执行其功能时从外部观察到的系统状态。
类具有被动和主动两种特征。被动状态只是某个对象所有属性的当前状态。主动状态指的是对象进行持续变换或处理时的当前状态。
分析类的状态图：
元素：
每个箭头：表示某个对象从一个主动状态转移到另一个主动状态。
箭头标注：体现触发状态转移的事件。
黑色圆圈：开始
顺序图：
元素：
每个箭头：代表一个事件并说明事件如何引导对象之间的行为。
窄的纵向矩形：处理某个活动所用的时间。
本文发布于:2024-01-29 07:51:41，感谢您对本站的认可！
本文链接：https://www.4u4v.net/it/170648590313805.html
版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系，我们将在24小时内删除。
| 留言与评论（共有 0 条评论） |
