软件:(1)指令的集合(计算机程序),通过执行这些指令可以满足预期的特性,功能和性能需求;(2)数据结构,使得数据可以合理利用信息;(3)软件描述信息,它以硬拷贝和虚拟形式存在,用来描述程序的操作和使用。
某些系统软件(例如编译器、编辑器、文件管理软件)处理复杂但确定地信息结构,另一些系统应用程序(例如操作系统构建,驱动程序,网络软件、远程通信处理器》主要处理的是不确定的数据。
这类应用软件处理商务或技术数据,以协助业务操作或协助做出管理或技术决策。
嵌入式软件可以执行有限的和内部的功能(例如微波炉的按键控制),或者提供重要的功能和控制能力(例如汽车中的燃油控制、仪表盘显示、刹车系统等汽车电子功能)。
产品线软件关注有限的及内部的市场(例如库存控制产品)或者大众消费品市场。
其概念覆盖了宽泛的应用软件产品,包括基于浏览器的App和安装在移动设备上的软件。*
这个领域的应用程序包括机器人、专家系统、模式识别(图像和语音)、人工神经网络、定理证明和博弈等。
定义:在几十年前开发,不断被修改以满足商业需要和计算平台变化的软件系统。
特点:生命周期长,业务关键性,质量差。
定义:(1)将系统化的,规范化的,可量化的方法应用于软件的开发、运行和维护、即将工程化方法应用于软件;(2)对以上方法的研究。
自顶向下:工具、方法、过程、质量关注点。
(1)支持软件工程的根基在于质量关注点;
(2)软件工程的基础是过程层;
软件过程将各个技术层次结合在一起,使得合理、及时地开发计算机软件成为可能。过程定义了一个框架有效实施软件工程技术。软件过程构成了软件项目管理控制的基础。建立了工作环境以便于应用技术方法、提交工作产品(模型、文档、数据、报告、表格等)
(3)软件工程的方法为构建软件提供技术上的解决方法;
方法覆盖面很广,包括沟通、需求分析、设计模型、程序构造、测试和技术支持
(4)软件工程工具为过程和方法提供自动化或半自动化的支持。
工具可以集成起来,使得一个工具产生地信息可被另外一个工具使用,这样就建立了软件开发地支撑系统,称为计算机辅助软件工程
软件过程是工作产品构建时所执行的一系列活动、动作和任务的集合。
活动主要实现宽泛的目标
动作包含了主要工作产品生产过程中的一系列任务
任务关注了小而明确的目标
过程框架定义了若干个框架活动,为实现完整的软件工程过程建立了基础。
软件项目跟踪和控制、风险管理、软件质量保证、技术评审、测量、软件配置管理、可复用管理、工作产品的准备和生产。
关于软件开发过程中的一些被人们盲目相信的说法,它实际上误导了管理者和从业人员对软件开发的态度。
过程模式描述了软件工程工作中遇到的过程相关的问题,明确了问题环境并给出了针对该问题的一种或几种可证明的解决方案。
瀑布模型(经典生命周期)提出了一个系统的、顺序的软件开发方法。
增量模型综合了线性过程流和并行过程流的特性,随着时间的推移,增量模型在每个阶段都运用线性序列。每个线性序列生产出软件的可交付增量。
演化过程模型是迭代的过程模型,这种模型使得软件开发人员能够逐步开发出更完整的软件版本。
两种常用的演化过程模型:原型开发、螺旋模型
*很多时候,客户定义了软件的一些基本任务,但没有详细定义功能和特性需求。另一情况,开发人员可能对算法的效率、操作系统的适用性和人机交互的形式等情况并没有把握。*在这些情况和类似情况下,采用原型开发范型是最好的解决方法。
在原型系统不断调整以满足各种利益相关者需求的过程中,采用迭代技术,同时也使开发者逐步清楚用户的需求。
螺旋模型是一种演进式软件过程模型,它结合了原型的迭代性质和瀑布模型的可控性和系统性特点。它具有快速开发越来越完善的软件版本的潜力。
特点:1.采用循环的方式逐步加深系统定义和实现的深度,同时降低风险。2.确定一系列里程碑作为支撑点,确保利益相关者认可是可行的且可令各方满意的系统解决方案
并发开发模型(并发工程),它允许软件团队表述以上所描述的任何过程模型中的迭代元素和并发元素。
一种“用例驱动,以架构为中心,迭代并且增量”的软件过程。
在某种程度上,统一过程尝试着从传统的软件过程中挖掘最好的特征和性质,但是以敏捷软件开发中许多最好的原则来实现。统一过程认识到与客户沟通以及从用户的角度描述系统(即用例)并保持该描述的一致性的重要性。它强调软件体系结构的重要作用,并“帮助架构师专注于正确的目标。它建立了迭代的、增量的过程流,提供了演进的特性,这对现代软件开发非常重要。
UP的起始阶段包括客户沟通的策划活动
通过与利益相关者协作定义软件的业务需求,提出系统大致的架构,并指定开发计划以保证项目开发具有迭代和增量的特性。
UP的细化阶段包括沟通和通用过程模型的建模活动
细化阶段扩展了初始阶段定义的用例,并扩展了体系结构以包括软件的五种视图——用例模型、需求模型、设计模型、实现模型和部署模型。
UP的构建阶段与通用软件过程中的构建活动相同
构建阶段采用体系结构模型作为输入、开发或是获取软件构件,使得最终用户能够操作用例。
UP的转换阶段包括通用构建活动的后期阶段以及通用部署(交付和反馈)活动的第一部分
软件被提交给最终用户进行Beta测试,用户反馈报告缺陷及必要的变更。
UP的生产阶段与通用过程的部署活动一致
在该阶段,对持续使用的软件进行监控,提供运行环境(基础设施)的支持,提交并评估缺陷报告和变更请求。
XP使用面向对象方法作为推荐的开发泛型,它包含了策划、设计、编码和测试4个框架活动的规则和实践。
策划
设计
重构既是构建技术又是设计技术,以不改变代码外部行为而改进其内部结构的方式来修改软件系统的过程。
编码
编码活动中的关键概念是结对编程。XP建议两个人面对同一台计算机共同为一个故事开发代码。
测试
略
起始
要建立基本的理解,包括存在的问题、谁需要解决方案、所期望解决方案的性质、与项目利益相关者和开发人员之间达成初步交流合作的效果。
获取
询问客户、用户和其他疼:系统或产品的目标是什么。
细化
在起始和获取阶段获得的信息将在细化阶段进行扩展和提炼
协商
业务资源有限,而客户和用户却提出了过高的要求,这是常有的事。
规格说明
规格说明可以是一份写好的文档、一套图形化的模型、一个形式化的数学模型、一组使用场景。
确认
在确认这一步将对需求工程的工作产品进行质量评估
需求管理
对于基于计算机的系统,其需求会变更,而且变更的要求贯穿于系统的整个生命周期。
利益相关者:直接或间接地从正在开发地系统中获益的人。
质量功能部署(Quality Function Deployment, QFD)
常规需求 在会议中向客户陈述一个产品或系统时的目标,如果这些需求存在,客户就会满意。
期望需求 在产品或系统中客户没有清晰表述的基础功能,缺少了这些将会引起客户的不满。
兴奋需求 超出客户预期的需求,当这些需求存在时会令人非常满意。
开发人员和用户可以创建一系列的场景——场景可以识别对将要构建系统的使用线索。场景通常称为用例,它描述了人们将如何使用某一系统。
需求模型实际上时第一组模型,是系统的第一个技术表示。
在需求分析中,软件工程师可以细化在前期需求工程的起始、获取、协商任务中建立的基础需求。需求分析的结果为以下的某种模型:场景模型、面向类的模型、基于行为和模式的模型、数据模型、面向流的模型
需求模型必须实现的三个主要目标
(1)描述客户需要什么;
(2)为软件设计奠定基础;
(3)定义在软件完成后可以被确认的一组需求;
需求建模的方法
1.结构化分析,考虑数据和处理的需求建模方法,其中处理过程将数据作为独立实体加以转换;
2.面向对象的分析。UML和统一过程主要是面向对象的分析方法