2018-06-19 11:07:16 qq_34489943 阅读数 112

软件工程

软件工程定义

1968年NATO(北大西洋公约组织)会议上首次提出

•    Fritz Bauer:软件工程是建立和使用一套合理的工程原则,以便获得经济的软件,这种软件是可靠的,可以在实际机器上高效地运行

•    IEEE:软件工程是:①将系统化的、严格约束的、可量化的方法应用于软件的开发、运行和维护,即将工程化应用于软件;②在①中所述方法的研究

•    计算机科学技术百科全书:软件工程是应用计算机科学理论和技术以及工程管理原则和方法,按预算和进度实现满足用户要求的软件产品的工程,或以此为研究对象的学科


软件工程的框架

软件工程的框架可概括为目标、活动和原则

目标

  生产具有正确性、可用性和开销合宜的产品

  正确性是指软件产品达到预期功能的程度

  可用性是指软件基本结构、实现以及文档为用户可用的程度

  开销合宜是指软件开发、运行的整个开销满足用户要求的程度

活动

软件开发活动指生产一个最终满足需求且达到工程目标的软件产品所需要的活动。软件开发的基本活动包括需求分析、设计、实现、验证与确认和维护。

原则

     选取适宜的开发风范

     采用合适的设计方法

     提供高质量的工程支持

     有效的软件工程管理


软件生存周期( software life cycle)

•    软件有一个孕育、诞生、成长、成熟、衰亡的生存过程。这个过程即为计算机软件的生存周期

•    软件生存周期大体可分为如下几个活动:计算机系统工程、需求分析、设计、编码、测试、运行和维护

计算机系统工程

Ø  计算机系统包括计算机硬件、软件、使用计算机系统的人、数据库、文档、规程等系统元素

Ø  计算机系统工程的任务

确定待开发软件的总体要求和范围,以及它与其它计算机系统元素之间的关系

进行成本估算,做出进度安排

进行可行性分析,即从经济、技术、法律等方面分析待开发的软件是否有可行的解决方案,并在若干个可行的解决方案中作出选择

软件需求分析

Ø  主要解决待开发软件要“做什么”的问题

Ø  确定软件的功能、性能、数据、界面等要求,生成软件需求规约

软件设计

Ø  主要解决待开发软件“怎么做”的问题

Ø  软件设计通常可分为系统设计(也称概要设计或总体设计)和详细设计

Ø  系统设计的任务是设计软件系统的体系结构,包括软件系统的组成成分、各成分的功能和接口、成分间的连接和通信,同时设计全局数据结构

Ø  详细设计的任务是设计各个组成成分的实现细节,包括局部数据结构和算法等

编码

  用某种程序设计语言,将设计的结果转换为可执行的程序代码

测试

  发现并纠正软件中的错误和缺陷。测试主要包括单元测试、集成测试、确认测试和系统测试

运行和维护

   在软件运行期间,当发现了软件中潜藏的错误或需要增加新的功能或使软件适应外界环境的变化等情况出现时对软件进行修改


2012-09-19 10:02:59 cpongo9 阅读数 12

Steve Tendon在最近一篇博文“约束理论和软件工程”里解释了为什么在软件开发公司中产出会计要优于成本会计,同时他还给出了一个适用于软件工程的产出会计简单模型。

\u0026#xD;\n

软件架构师除了负责架构设计之外,还需要关注商业因素。架构师在做架构决策时一定要考虑到商业因素,否则构造出来的系统可能没有很好的经济价值。Steve Tendon是一名专注于软件工程管理的顾问,在这篇文章里他提议用产出来评估商业价值,而不是用成本。

\u0026#xD;\n

为了阐述观点,Steve Tendon在博文中引用了约束理论(Theory of Constraints,简称TOC) 里的“链子的强度是由最弱的连接点决定的”的观点:

\u0026#xD;\n
\u0026#xD;\n

TOC认为所有业务都是将输入转变为输出的系统, 输入经过一系列工作步骤处理最终转化为输出。 输出是商业客户定价和付款的产品或服务。

\u0026#xD;\n
\u0026#xD;\n

TOC的核心原则是: 总会存在一个工作步骤限制了系统的输出能力。这一步骤被称为“能力约束资源”(Capacity Constrained Resource,简称CCR)。Steve Tendon认为CCR往往可以通过将过程流水化和细分任务来避免。在软件工程中,最小的任务单元可以是RUP里的用户用例,XP里的故事点或者是Scrum里的backlog。优化CCR的方法是称之为”5步聚焦法“的模型,如在维基百科中所提到的:

\u0026#xD;\n
  1. 指出系统约束(阻碍组织在单位时间内达成更多目标)\u0026#xD;\n
  2. 决定如何利用系统约束(如何从系统约束中获益最多)\u0026#xD;\n
  3. 所有一切配合上述的决定(整个组织要支持上述决定)\u0026#xD;\n
  4. 升级该系统约束(为打破约束做必要的改变)\u0026#xD;\n
  5. 注意!如果前面的步骤已打破了某个约束,直接回到第一步。不要让惯性产生新的系统约束。\u0026#xD;\n

介绍完TOC模型后,Tendon 用三个公式解释了产出会计的概念:

\u0026#xD;\n
  • 产出T=收益-变动费用总和\u0026#xD;\n
  • 净利润NP=产出-运营费用\u0026#xD;\n
  • 投入回报ROI=净利润/投资额\u0026#xD;\n

如把这些概念用于软件工程的话,对应如下:

\u0026#xD;\n
  • 产出:指将工作中的代码发布到产品后的现金变现率,它通过将销售价格减去直接成本得到,直接成本包括:打包、发布、安装、培训、支持,以及网络系统。\u0026#xD;\n
  • 投入:包括软件使用环境以及获取对客户有价值功能所消耗的金钱。包括软件开发工具以及需求采集。\u0026#xD;\n
  • 营业费用:将概念需求转变为实际工作代码所涉及花费到的金钱。主要是软件工程师的人力成本,但也包括销售、综合成本和管理成本。\u0026#xD;\n

这个简单模型使得产出会计也能够被那些非会计专业出身的人(如 软件架构师)所理解。很多公司在提高商业绩效过程中常常会把重点放在减少成本上,但产出会计提出了另外一个方案,正如Tendon 所提到的:

\u0026#xD;\n
\u0026#xD;\n

减少成本是有限度的,而提高产出则有可能是没有限度的。过度地减少成本会危害到交付的能力,从而反过来会引起产出降低等更严重的后果。

\u0026#xD;\n
\u0026#xD;\n

Tendon在文章里列举了3个运用了产出会计方法的例子:

\u0026#xD;\n
  • 减少产出会计里的营业费用的一种办法是:在实现前砍掉需求。减少每个故事点都能够降低营业费用,从而提高净利润。\u0026#xD;\n
  • 利用开源软件减少投入,虽然这样做有可能提高营业费用,但通常会比新构造一个同样系统所耗费的费用少。\u0026#xD;\n
  • 当处于小众市场环境时,软件公司可以通过满足这个市场特有需求来提高报价。\u0026#xD;\n

就像Tendon在文章里解释的,产出会计不仅仅是可用于软件工程的会计模型,而且是可以彻底替代传统的专注于减少成本的(如减少营业成本)成本会计。在文章的最后,Tendon解释了产出会计在其他商业通用流程中(如周转、招聘、项目计划方面的约束、预算、资源和范围)所起的作用。最后是他对产出会计的总结:

\u0026#xD;\n
\u0026#xD;\n

产出会计可对所有商业流程进行管理决策,包括周转,招聘,外包,选择方法等。 方法很简单,做任何决策都要考虑到产出、营业费用和投入三因素,这样的决策才是明智且财政稳健的。

\u0026#xD;\n
\u0026#xD;\n

一部分读者对这个博文发表了自己的看法,Robert McGinley是一名支持TOC方法论的读者,他说:

\u0026#xD;\n
\u0026#xD;\n

自从我读了《The Goal》一书后,我就成为了TOC的坚定拥护者。我认为它对系统架构师是非常有意义的,这篇文章作了很多很好的解释。

\u0026#xD;\n
\u0026#xD;\n

Dave Nicolette 喜欢这篇文章,但不同意对故事点的处理:

\u0026#xD;\n
\u0026#xD;\n

我不同意将故事点与预估收入价值联系在一起。IME故事点是基于成果的而预估价值完全不是,我更倾向于用“挣值”来跟踪顾客价值交付。它适用于传统和非传统开发模式。 我见过有人用同样的方法来追踪范围和价值,其实是有问题的。你的看法可能不同。

\u0026#xD;\n
\u0026#xD;\n

Tendon 回复Dave Nicolette说道:

\u0026#xD;\n
\u0026#xD;\n

是的,将故事点与收入价值联系在一起并不是最好的方法,用挣值来衡量会更好,但从我所处理过的案例里来看,这样做已经足够接近真实值了,而且它可以为开发人员估计与管理决策所需要数字间的鸿沟铺平道路。也就是说:它是个可以达到理想结果的实用性的方法。它是基于平均来考虑的。从平均来看,一个故事点可以被平均地认为一个收益价值。而且如果你对工作清单进行严格分类的话,这个平均还能很好反映清单里剩余的工作量。

\u0026#xD;\n
\u0026#xD;\n

Christian Beck喜欢这篇文章但认为约束并不一定总是坏的:

\u0026#xD;\n
\u0026#xD;\n

约束并不一定是总是坏的。在CDS(信用违约掉期)中,约束很大程度地决定了交付的范围(这在软件领域里是很难定义和衡量),而且还涉及了其他重要的交付指标如质量,结果是否新颖。甚至,约束还是系统设计的一部分(如在制品数量限制,时间限制等),变化的约束是影响(而不是控制)结果的重要工具。

\u0026#xD;\n
\u0026#xD;\n

Tendon回复Christian Beck道:

\u0026#xD;\n
\u0026#xD;\n

是的,约束必须结合着你自己的目标来看。一些约束实际上会帮你往正确的好的方向发展;而有些却相反。最好是能够分辨它们,而且也要知道怎样利用这些好或不好的约束来让你自己的目标受益。

\u0026#xD;\n
\u0026#xD;\n

查看英文原文:http://www.infoq.com/news/2012/08/tendon-toc-ta

\u0026#xD;\n

感谢郭雪品对本文的审校。

\u0026#xD;\n

给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ)或者腾讯微博(@InfoQ)关注我们,并与我们的编辑和其他读者朋友交流。

2019-07-22 22:37:13 bestSofia 阅读数 28

教材《软件工程 第三版》 钱乐秋著

第一章 概论

软件工程概念

  1. 软件工程是建立和使用一套合理的工程原则,以便获得经济的软件,这种软件是可靠的,可以在实际机器上高效运行。(NATO会议上提出)
  2. ①将系统化的、严格约束的、可量化的方法应用于软件的开发、运行和维护,即将工程化应用于软件。 ②对在①中所述方法的研究。(IEEE)
  3. 软件工程是应用计算机科学理论和技术以及工程管理原则和方法,按预算和进度实现满足用户要求的软件产品的工程,或以此为研究对象的学科。(《计算机科学技术百科全书》)

软件生存周期

  1. 计算机系统工程
    (1)包括计算机硬件、软件,以及使用计算机系统的人、数据库、文档、规程等系统元素
    (2)任务
    ①确定待开发软件的总体要求和范围,以及该软件与其他计算机系统元素之间的关系
    ②进行成本估算,做出进度安排
    ③进行可行性分析,即从经济、技术、法律等方面分析待开发的软件是否有可行的解决方案,并在若干个可行的解决方案中做出选择。
  2. 需求分析
    主要解决开发软件要“做什么”的问题,确定软件的功能、性能、数据、界面等要求,生成软件需求规约(也称软件需求规格说明)
  3. 设计
    主要解决开发软件“怎么做”的问题。通常分为系统设计和详细设计。系统设计的任务是设计软件系统的体系结构,同时设计全局数据结构;详细设计的任务是设计各个组成成分的实现细节,包括局部数据结构和算法等。
  4. 编码
    任务是用某种程序设计语言,将设计的结果转换为可执行的程序代码。
  5. 测试
    任务是发现并纠正软件中的错误和缺陷。
  6. 运行和维护
    当发现了潜藏的错误或需要增加新的功能或使软件适应外界环境的变化等情况出现时,对软件进行修改。

软件生存周期过程

  1. 基本过程
    供各主要参与方在软件生存周期期间使用。
  2. 支持过程
    具有不同目的,并作为一个有机组成部分来支持其他过程,以便取得软件项目的成功并提高软件项目的质量。
  3. 组织过程
    可被某个组织用来建立和实现由相关的生存周期过程和人员组成的基础结构,并不断改进这种结构和过程。

能力成熟度模型(CMM)

其目的是提供一种评级软件承接方能力的方法,同时,也可用于帮助软件组织改进其软件过程。 五个软件过程成熟度等级:

  1. 初始级:无秩序的,甚至是混乱的。成功往往依赖个人或者小组的努力。
  2. 可重复级:建立了基本的项目管理过程来跟踪成本、进度和功能特性。制定了必要的过程纪律,能重复早先类似应用项目取得的成功。
  3. 已定义级:已将管理和工程活动两方面的软件过程文档化、标准化,并综合成该组织的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程开开发和维护软件。
  4. 已管理级:收集对软件过程和产品质量的详细度量值,对软件过程和产品都有定量的理解和控制。
  5. 优化级:过程的量化反馈和先进的新思想、新技术促使过程不断改进。

能力成熟度模型继承(CMMI)

CMMI是若干过程模型的综合和改进,是支持多个工程学科和领域的系统的、一致的过程改进框架,能适应现代工程的特点和需要,能提高过程的质量和工作效率。
CMMI提供了两种表示法:阶段式模型和连续式模型。阶段式模型的结构类同于软件CMM,他关注组织的成熟度。连续式模型关注每个过程域的能力,一个组织对不同的过程域可以达到不同的过程域能力等级。

软件过程模型

  1. 瀑布模型:上一阶段的活动完成并经过评审后才能开始下一阶段的活动。
    1)特征
    ①接收上一阶段活动的结果作为本阶段活动的输入。
    ②依据上一阶段活动的结果实施本阶段应完成的活动。
    ③对本阶段的活动进行评审。
    ④将本阶段活动的结果作为输出,传递给下一阶段。

  2. 演化模型
    1)特征:从构造初始的原型出发,逐步将其演化成最终软件产品的过程。
    2)适用场景:对软件需求缺乏准确认识的情况。

  3. 增量模型
    1)特征:将软件的开发过程分成若干个日程时间交错的线性序列,每个线性序列产生软件的一个可发布的“增量”版本,后一个版本是前一个版本的修改和补充,重复增量发布的过程,直至完成最终的产品。
    2)适用于需求经常发生变化的软件开发;此外,在市场急需而开发人员和资金都不能在设定的市场期限之前实现一个完善的产品时,也适用增量模型。

  4. 原型模型:通过不断构建和完善原型来确定需求,是一个循环的模型

  5. 螺旋模型:将瀑布模型与原型化模型结合起来,并加入了风险分析。

  6. 喷泉模型:喷泉模型认为软件生命周期的各个阶段是相互重叠和多次反复的,是一种支持面向对象开发的过程模型。

  7. 基于构件的开发模型:利用预先包装的构件来构造应用系统,支出软件复用。

  8. 形式化方法模型:建立在严格的数学基础上的一种软件开发方法。采用严格的数学语言,具有精确的数学语义的方法。

CASE工具与环境

  1. 计算机辅助软件工程(computer aided software engineering)是指使用计算机及相关的软件工具辅助软件开发、维护、管理等过程中各项活动的实施,以确保这些活动能高效率、高质量的进行。
  2. 分类:按软件过程的活动来分类
    1)支持软件开发过程的工具
    2)支持软件维护过程的工具
    3)支持软件管理过程和支持过程的工具

敏捷开发

  1. 定义:在软件开发中,强调软件开发的灵活性的各种方法

  2. 特点
    1)致力于降低变化带来的成本
    2)强调价值
    3)强调人的作用
    4)使用增量和迭代的开发方法

  3. 价值观
    1)个体和交互重于过程和工具
    2)工作的软件重于详尽的文档
    3)客户合作重于合同谈判
    4)响应变化终于遵循计划

  4. 原则
    1)我们最重要的目标,是通过持续不断地及早交付有价值的软件使客户满意。
    2)欣然面对需求变化,即使在开发后期。善于掌控变化,帮助客户获得竞争优势。
    3)经常地交付可工作的软件,相隔几星期或一两个月,倾向于采取较短的周期。
    4)业务人员和开发人员必须紧密合作。
    5)激发个体的斗志,以他们为核心搭建项目。提供他们所需的环境和支持,相信他们能够达成目标。
    6)不论团队内外,传递信息效果最好,效率也最高的方式是面对面的交谈。
    7)可工作的软件是进度的首要度量标准。
    8)敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
    9)持续地追求技术卓越和良好设计,可以提高敏捷性。
    10)以简洁为本,极力减少不必要工作量。
    11)最好的架构、需求和设计出自于自组织的团队。
    12)团队定期地反思如何能更加高效,并依此调整团队的行为。

  5. XP方法(Extreme Programming,简称XP)
    极限编程是敏捷软件开发方法的代表, 极限编程是一种轻量级的、灵巧的、简单的软件工程方法。与传统的开发过程不同,极限编程的核心活动体现在需求→测试→编码→设计过程中。因此适用于规模小、进度紧、需求变化大、质量要求严的项目。它希望以最高的效率和质量来解决用户目前的问题,以最大的灵活性和最小的代价来满足用户未来的需求。

第二章 系统工程

可行性分析

  1. 概念:可行性分析主要从经济、技术、法律等方面分析所给出的解决方案是否可行,能否在规定的资源和时间的约束下完成。
  2. 分类
    1)经济可行性主要进行成本效益分析,从经济角度,确定系统是否值得开发。
    2)技术可行性主要根据系统的功能、性能、约束条件等,分析在现有资源和技术条件下系统能否实现。
    3)法律可行性主要研究系统开发过程中可能涉及到的合同、侵权、责任以及各种与法律相抵触的问题。

第三章 需求工程

需求工程

  1. 需求获取
    系统分析人员通过与用户的交流、对现有系统的观察以及对任务进行分析,确定系统或产品范围的限制性描述、与系统或产品有关的人员及特征列表、系统的技术环境的描述、系统功能的列表及应用于每个需求的领域限制、描述不同运行条件下系统或产品使用情况的应用场景等。
  2. 需求分析与协商
    分析活动对需求进行分类组织,分析每个需求与其他需求的关系以检查需求的一致性、重叠和遗漏的情况,并根据用户的需要对需求进行排序。
  3. 系统建模
    建模工具的使用在用户和系统分析人员之间建立了统一的语言和理解的桥梁,同时系统分析人员借助建模技术对获取的需求信息进行分析,排除错误和弥补不足,确保需求文档正确反映用户的真实意图。
  4. 需求规约
    通过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标准,给出对目标软件的各种需求。
  5. 需求验证
    需求验证对功能的正确性、完整性和清晰性,以及其他需求给予评价。
  6. 需求管理
    对需求工程所有相关活动的规划和控制。

第四章 设计工程

软件设计的任务

  1. 数据/类的设计
  2. 体系结构设计
  3. 接口设计
  4. 部件级设计

软件设计的原则

  1. 抽象与逐步求精

  2. 模块化
    1)概念:把软件按照规定原则,划分为一个个较小的、相互独立的但又相互关联的部件。
    2)模块独立性(功能独立性):在设计程序模块时,使得模块实现独立的功能并且与其他模块的接口简单,符合信息隐藏原则。功能独立性比较强的模块应该是高内聚低耦合的模块。
    3)度量指标:内聚度和耦合度
    ①内聚是一个模块内部各个元素彼此结合的紧密程度的度量,一个内聚程度高的模块应当只做一件事。
    ②耦合是模块之间的相对独立性(互相连接的紧密程度)的度量。
    ③降低耦合度的方法:尽量使用数据耦合,少用控制耦合,限制公共耦合的范围,坚决避免内容耦合,降低接口复杂性。

  3. 信息隐藏

第五章 结构化分析与设计

启发式设计策略

  1. 改造程序结构图,降低耦合度,提高内聚度
  2. 避免高扇出,并随着深度的增加,力求高扇入
  3. 模块的影响范围应限制在该模块的控制范围内
  4. 降低模块接口的复杂程度和冗余程度,提高一致性
  5. 模块的功能应是可预测的,避免对模块施加过多的限制
  6. 尽可能设计单入口和单出口的模块

如何判断数据流图的一致性和完整性? (答案不全)

子图的输入和输出数据流同父图相应加工的输入输出数据流必须一致。

第七章 第八章 面向对象

面向对象基本概念

面向对象=对象+分类+继承+通过消息的通信
对象是指一组属性以及这组属性上的专用操作的封装体。
类是一组具有相同属性和相同操作的对象的集合。
多态性是指同一个操作作用于不同的对象上可以有不同的解释,并产生不同的执行结果。
动态绑定是指在程序运行时才将消息所请求的操作与实现该操作的方法进行连接。
用况建模

  1. 用况建模是用于描述一个系统应该做什么的建模技术,用况建模不仅用于新系统的需求获取,还可用于已有系统的升级。

  2. 步骤
    1)定义系统
    2)确定执行者
    3)确定用况
    4)描述用况
    5)定义用况间的关系
    6)确认模型

  3. 用况图中的关系
    关联:执行者与他所参与的一个用况之间的通信路径。
    扩展:扩展的用况到基本用况的一种关系,指出扩展用况所定义的行为如何插入到基本用况所定义的行为中。扩展的用况通过模块化方式增量的修改基本用况。
    包含:从基本用况到另一个用况的一种关系。
    用况泛化:一个一般用况与一个更特殊的用况之间的关系,特殊用况可继承一般用况的特征。

类图

  1. 类之间的关系
    关联:类实例间连接的描述
    依赖:两个模型元素之间的一种关系
    泛化:更特殊描述与更一般描述之间的一种关系,用于继承和多态性类型声明
    实现:规约与它的实现之间的关系

  2. 类的属性和方法

  3. 状态机图

  4. 顺序图

  5. 协作图

第十三章 软件测试

软件测试的目的

(1)测试是一个为了发现错误而执行程序的过程。
(2)一个好的测试用例是指很可能找到迄今为止尚未发现的错误的测试用例。
(3)一个成功的测试是指揭示了迄今为止尚未发现的错误的测试。
测试的目的是发现软件中的错误和缺陷,并加以纠正。应该排除对测试的错误观点,设计合适的测试用例,用尽可能少的测试用例,来发现尽可能多的软件错误。

白盒测试

  1. 白盒测试又称结构测试,这种方法把测试对象看作一个透明盒子,测试人员根据程序内部的逻辑结构及有关信息设计测试用例,检查程序中所有逻辑路径是否都按预定的要求正确地工作。
    白盒测试主要用于对程序模块的测试,包括:
    ● 程序模块中的所有独立路径至少执行一次
    ● 对所有逻辑判定的取值(“真"与"假”)都至少测试一次
    ● 在上下边界及可操作范围内运行所有循环
    ● 测试内部数据结构的有效性等
    白盒测试方法主要有逻辑覆盖测试、基本路径测试、数据流测试和循环测试

  2. 逻辑覆盖测试
    1)语句覆盖
    2)判定覆盖
    3)条件覆盖
    4)判定/条件覆盖
    5)条件组合覆盖
    6)路径覆盖

  3. 基本路径测试
    首先根据程序或设计图(流程图)画出控制流图,并计算其区域数,然后确定一组独立的程序执行路径(基本路径),最后为每一条基本路径设计一个测试用例。映射的前提是流程图的判定中不包含符合条件;如果包含符合条件,先将其转成等价的简单条件流程图。 独立路径数据=流图的区域数=流图的环形复杂度V(G)=E-N+2,E是边数,N是结点数。

黑盒测试

  1. 黑盒测试又称行为测试,这种方法把测试对象看做一个黑盒子,测试人员完全不考虑程序内部的逻辑结构和内部特性,只依据程序的需求规格说明书,检查程序的功能是否符合它的功能需求。
    黑盒测试可用于各种测试,试图发现以下类型的错误:
    ● 不正确或遗漏的功能
    ● 接口错误
    ● 数据结构错误或外部信息访问错误
    ● 性能错误
    ● 初始化和终止错误
    主要的黑盒测试方法有:等价类划分,边界值分析,比较测试,错误猜测和因果图方法。
  2. 等价类划分
    将所有有可能的输入数据划分成若干等价类,然后在每个等价类中选取一个代表性的数据作 为测试数据。 等价类分为有效等价类和无效等价类。
    有效等价类是指符合规格说明要求的合理的输入数据集合,主要用来检验程序是否实现了规格说明中规定的功能。
    无效等价类是指不符合规格说明要求的不合理的或非法的输入数据集合,主要用来检验程序是否做了不符合规格说明的事。
    利用等价类设计测试用例的规则如下:
    ● 设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖的有效等价类,重复这一步,直至所有的有效等价类都被覆盖为止。<=有效等价类个数
    ● 为每个无效等价类设计一个新的测试用例。=无效等价类个数

测试策略
(1)单元测试
(2)集成测试
(3)确认测试
(4)系统测试
(5)α测试
(6)β测试
(7)回归测试
(8)压力测试
(9)性能测试

第十五章 软件维护与再工程

1.软件维护的概念
2.软件可维护性,影响因素,维护的分类
3.再工程的概念
4.软件再工程过程
5.逆向工程概念

2018-09-04 11:54:00 qq_30684181 阅读数 18

软件工程知识大纲

第1章 概述

1.1什么是软件工程

软件工程是关于软件生产的各个方面的工程学科

1.2软件过程

软件工程中系统化的方法叫做软件过程

 

第2章 软件过程

2.1软件工程四种基本的活动

  1. 软件描述:必须定义软件的功能以及软件操作上的约束
  2. 软件设计和实现:必须生产符合描述的软件
  3. 软件有效性验证:软件必须得到有效性验证,即确保软件是客户想要的
  4. 软件进化:软件必须进化以满足不断变化的客户需要

2.2软件过程模型

  1. 瀑布模型:该模型将基本的过程活动、描述、开发、有效性验证和进化,看成是一些界限分明的独立的过程阶段,例如,需求描述阶段、软件设计阶段、实现阶段、测试阶段,等等
  2. 增量式开发:该方法使得描述活动、开发活动和有效性验证活动交织在一起。系统的开发是建立一系列的版本(增量),每个版本添加部分功能到先前的版本中
  3. 面向复用的软件工程:该方法是基于已存在的大量可复用的组件。系统开发过程着重于集成这些组件到新系统中,而非从头开发

第3章 敏捷软件开发

3.1敏捷开发

敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发

第4章 需求工程

4.1用户需求

用户需求是用自然语言加图的形式给出的、关于系统需要提供哪些服务以及系统操作受到哪些约束的声明

4.2系统需求

系统需求详细地给出系统将要提供的服务以及系统所受到的约束

4.3功能需求和非功能需求

  1. 功能需求:包括对系统应该提供的服务、如何对特殊输入做出反应,以及系统在特定条件下的行为的描述
  2. 非功能需求:对系统提供的服务或功能给出的约束。包括时间约束、开发过程的约束和所受到的标准的约束

4.4UML中定义的图表类型

 4.4.1活动图

它表示一个过程或数据处理中所涉及的活动

参考:https://www.cnblogs.com/liangxiaofeng/p/4180332.html

 

4.4.2用例图

它表示一个系统和它所处环境之间的交互

参考:https://www.cnblogs.com/13062225wmx/p/5432356.html

1)参与者(Actor)

  参与者是与系统交互的人或物。首先当然包括我们的开发系统用户,除此之外,与我们开发的系统有关联的其他系统也算是参与者。

在UML图中我们用一个小人表示。

2)用例(Use Case)

   用例是参与者可以感受到的系统服务或功能单元。我理解的就是用户可以使用我们开发的项目去做的任何事情

任何用例都不能在缺少参与者的情况下独立存在,同样,任何参与者也必须要有与之关联的用例。在UML图中我们用椭圆表示:

3)系统边界

  指系统与系统之间的界限。把系统边界以外的同系统相关联的其他部分称为系统环境。

在UML图中我们用一个矩形表示。

4)关系

  用例图中的关系有4种:关联,泛化,包含和扩展。

  关联:表示参与者和用例之间的交互。为通信途径,任何一方都可发送或可接收消息。

  箭头指向:指向消息接收方。在UML中用直线表示

  包含:包含关系用来把一个较复杂的用例所表示的功能分解成较小的步骤。包含用例是必须的,如果缺少包含用例,基用例就是不完整的。

包含关系最典型的应用就是复用。这种情况类似与在过程设计语言中,将程序的某一段算法封装成一个子过程,然后在从主程序中调用这一子过程(这么说好像懂了点)

在UML中,包含关系用带箭头的虚线段加《include》表示,箭头指向被包含的用例。

在VISIO中没有找到include包含关系,解决办法:

1)选择菜单栏中的'UML'-》单击’构造型‘-》新建-》构造型那里输入include-》基类那里选择归纳,点击确定

2)将UML用例下的“扩展”拖到绘图页上-》双击或右键属性-》构造下拉列表中选择include-》确定

  扩展:扩展关系是指用例功能的延伸。与包含关系不同的是,扩展用例是可选的,如果缺少扩展用例。不会影响到基用例的完整性。

  在UML中,扩展关系用带箭头的虚线段加《extend》表示,要注意的是箭头指向基用例。

  泛化:用例的泛化指的是一个父用例可以被特化形成多个子用例,用我们熟悉的语言来说就是继承关系。

  在UML中,泛化关系用空心箭头表示,箭头指向的是父用例。

4.4.3类图

它表示系统中的对象类以及这些类之间的联系

参考:http://www.cnblogs.com/shindo/p/5579191.html

一、类的属性的表示方式

在UML类图中,类使用包含类名、属性(field) 和方法(method) 且带有分割线的矩形来表示,比如下图表示一个Employee类,它包含name,age和email这3个属性,以及modifyInfo()方法。

那么属性/方法名称前加的加号和减号是什么意思呢?它们表示了这个属性或方法的可见性,UML类图中表示可见性的符号有三种:

· + :表示public

· - :表示private

· #:表示protected(friendly也归入这类)

因此,上图中的Employee类具有3个私有属性和一个公有方法。

 

实际上,属性的完整表示方式是这样的:

可见性  名称 :类型 [ = 缺省值]

中括号中的内容表示是可选的

 

二、类的方法的表示方式

上图中我们已经看到了方法的表示形式。实际上,方法的完整表示方式如下:

可见性  名称(参数列表) [ : 返回类型]

同样,中括号中的内容是可选的。

 

比如在下图的Demo类中,定义了3个方法:

 

· public方法method1接收一个类型为Object的参数,返回值类型为void

· protected方法method2无参数,返回值类型为String

· private方法method3接收类型分别为int、int[]的参数,返回值类型为int

 

三、类与类之间关系的表示方式

1、关联关系

关联关系又可进一步分为单向关联、双向关联和自关联。

(1)单向关联

我们可以看到,在UML类图中单向关联用一个带箭头的直线表示。上图表示每个顾客都有一个地址,这通过让Customer类持有一个类型为Address的成员变量类实现。

 

(2)双向关联

从上图中我们很容易看出,所谓的双向关联就是双方各自持有对方类型的成员变量。在UML类图中,双向关联用一个不带箭头的直线表示。上图中在Customer类中维护一个Product[]数组,表示一个顾客购买了那些产品;在Product类中维护一个Customer类型的成员变量表示这个产品被哪个顾客所购买。

 

(3)自关联

自关联在UML类图中用一个带有箭头且指向自身的直线表示。上图的意思就是Node类包含类型为Node的成员变量,也就是“自己包含自己”。

 

2、聚合关系

上图中的Car类与Engine类就是聚合关系(Car类中包含一个Engine类型的成员变量)。由上图我们可以看到,UML中聚合关系用带空心菱形和箭头的直线表示。聚合关系强调是“整体”包含“部分”,但是“部分”可以脱离“整体”而单独存在。比如上图中汽车包含了发动机,而发动机脱离了汽车也能单独存在。

 

3、组合关系

组合关系与聚合关系见得最大不同在于:这里的“部分”脱离了“整体”便不复存在。比如下图:

显然,嘴是头的一部分且不能脱离了头而单独存在。在UML类图中,组合关系用一个带实心菱形和箭头的直线表示。

 

4、依赖关系

从上图我们可以看到,Driver的drive方法只有传入了一个Car对象才能发挥作用,因此我们说Driver类依赖于Car类。在UML类图中,依赖关系用一条带有箭头的虚线表示。

 

5、继承关系

继承关系对应的是extend关键字,在UML类图中用带空心三角形的直线表示,如下图所示中,Student类与Teacher类继承了Person类。

 

6、接口实现关系

这种关系对应implement关键字,在UML类图中用带空心三角形的虚线表示。如下图中,Car类与Ship类都实现了Vehicle接口。

4.4.4状态图

它表示系统是如何响应内部和外部事件的

参考:https://blog.csdn.net/li2534153206/article/details/55004031

 

posted @ 2018-09-04 11:54 Rest探路者 阅读(...) 评论(...) 编辑 收藏
2017-02-06 17:14:40 qq_34969081 阅读数 502

前言:
以前没有当项目经理,不知道软件工程的重要性。
以前没有当产品经理,不知道软件工程的重要性。

产品经理:做正确的事情。一个是目的。
项目经理:把事情做正确。一个是过程。

参考资料:
1. 敏捷开发
2. 微服务架构:敏捷软件架构的实际体现
3. 软件工程
4. 持续集成

软件工程

  1. 一般软件过程中分为4个活动

    • 软件描述:确定软件的功能和约束
    • 软件的设计和开发:生产符合描述的软件
    • 软件的有效性验证:验证是否满足客户要求
    • 软件进化:不断的满足客户的要求
  2. 软件工程可以分为三种软件过程模型,简化符合规范的模型。

    • 瀑布式:RUP rational公司是一个迭代的过程
      这里写图片描述
    • 增量式:敏捷开发(极限编程和scurm)
      这里写图片描述
    • 复用式
      这里写图片描述
  3. 问题是怎样讲现实世界的映射到程序世界。
    不管软件过程模型是哪一种,都离不开4个活动。
    • 需求分析
    • 软件设计和开发(建模和体系结构设计)
      体系结构设计:如何组织和设计系统的整体机构,满足系统需求的功能和非功能。体系结构设计输出体系结构模型
      体系结构模型:非功能-影响系统的性能、健壮性、安全、可用性、可维护性。
      体系结构模型由体系机构视图表示
      每个视图针对的不同的角色,每个角色关注不同的侧面。
      • 概念视图:用例图 称为场景视图,是用户需求和系统功能抽象—
      • 逻辑视图:模式图(此图uml没有,但是可以找到相对应) 对象和对象类进行抽象 客户
      • 开发视图: 类、组件图 将不同的模块进行合理的分解 ——项目管理者和程序员。
      • 进程视图: 时序图、活动图和状态图,表示的是系统中不同的组件按照功能的实现进行的交互。
      • 物理视图:部署图。

而各视图之间有什么关系,怎样与uml的图对应。
- 怎样画4+1视图

软件测试:

测试只能证明存在错误,而不能证明它们不存在
原则:测试优于开发
过程:测试的各个阶段
1. 向开发者和用户展示功能满足需求-有效性测试
2. 找出缺陷和不足-缺陷测试
软件测试的过程模型

测试的3个阶段
1. 开发测试–缺陷测试
系统设计师和程序员 发现故障和缺陷
- 单元测试:针对单独的程序单元或对象类
- 组件测试:着重于组件接口
- 系统测试:整体测试 着重组件交互
2. 发布测试
着重需求测试
3. 用户测试

没有更多推荐了,返回首页