类的操作如何定义 软件工程_软件工程操作手册模板 免费下载 - CSDN
  • 什么是软件软件是计算机系统中与硬件相互依存的一部分,它是包括程序,数据和文档的集合。 特点: (1)抽象性,是一种逻辑实体,不是具体的物理实体。 (2)没有明显的制造过程 (3)没有磨损老化现象 (4...

    什么是软件?
    软件是计算机系统中与硬件相互依存的一部分,它是包括程序,数据和文档的集合。
    特点:
    (1)抽象性,是一种逻辑实体,不是具体的物理实体。
    (2)没有明显的制造过程
    (3)没有磨损老化现象
    (4)对于系统有着不同程度的依赖性
    (5)尚未完全摆脱手工艺的开发方式
    (6)本身是复杂的
    (6)成本相当昂贵.
    软件的分类
    系统软件
    1.操作系统
    2数据库管理程序
    3.通讯处理程序

    支撑软件

    1. 文本编辑程序
    2. 文件格式化
    3. 程序库系统

    应用软件

    1. 商业处理
    2. 计算软件
      ,,,,,,,
      工作方式分
      实时处理软件:必须立刻响应和处理,并且返回信号
      分时软件:
      交互式软件:人机通讯
      批处理软件:输入的作业按照输入的顺序排队轮流执行

    软件的服务对象
    项目软件:接受特定客户的委托有软件开发机构在合同的约束下开发的软件。不以盈利为目的
    产品软件:软件开发机构开发以后推向市场,以盈利为目的

    发展的阶段
    程序设计阶段50~60年代 机器语言或者汇编语言,手工操作没有文档
    程序系统阶段60~70年代 作坊式开发,程序加说明阶段
    软件工程阶段70年代以后 产品规范法,标准化

    软件危机的产生原因
    (1)软件开发的过程中遇到的严重问题利用现有的技术无法解决的
    (2)产品不符合用户的实际需要
    (3)开发生产率满足不了用户的需求
    (4)质量差不可靠
    (5)对产品的成本的估计不准确
    (6)维护性差
    (7)文档不全

    展开全文
  • 操作系统与软件工程学习笔记

    慢慢发现,根据需求完成任务代码其实并不是很难,遵循一些项目的规范,采用项目中统一的技术去实现对应的功能。东西都已经封装好了,你只需要使用一些工具或框架就可以轻易实现。

    但是,你想要有质的提高,却抛不开基础知识,因为思维是最重要的。因此对一些基础知识进行回顾,以下是对操作系统回顾后的总结。

    在回顾中,收获最大的是操作系统主要功能中的“内存扩充”,很值得借鉴学习的!

    操作系统的基本特性

    (1)并行性与并发性,并行性是指两个或多个事件在同一时刻发生;并发性是指两个或过个事件在同一时间间隔内发生;在多道程序环境下,并发性是指一段时间内宏观上有多个程序在同时运行,但是在但处理机系统中,每一刻却仅能有一道程序执行,故微观上这些程序只能分时地交替执行。对于多处理机。可以实现并行执行,多个程序同时运行。
    (2)引入进程,进程是指在系统中能独立运行并作为资源分配的基本单位。
    (3)引入线程,通常把进程作为分配资源的基本单位,而把线程作为独立运行的独立运行和独立调度的基本单位。
    (4)共享性,在操作系统环境下,所谓共享,是指系统中的资源可供内存中多个并发执行的进程(线程)共同使用。
    (5)互斥共享,仅当A进程访问完并释放该资源后,才允许另一进程对该资源访问。
    (6)同时访问,交替访问。
    (7)虚拟技术,操作系统中所谓的“虚拟”是指通过某种技术把一个物理实体变为若干个逻辑上的对应物。虚拟技术分为时分复用技术和空复用技术。
    (8)时分复用技术,人们利用时分复用技术,将一条物理信道虚拟为多条逻辑信道,将每条信道提供一对用户通话。为每道程序建立一个进程,让多道程序并发地执行。以此来分时使用一台处理机。
    (9)空分复用技术,通常一台机器上只配置一台硬盘,我们可以通过虚拟磁盘技术将一台硬盘虚拟为多台虚拟磁盘。
    (10)异步,如打印请求,而此时打印机正在为其他进程打印,由于打印机术语临界资源,因此正在执行的进程必须等待,且放弃处理机,知道打印机空闲,并在此把处理机分配该进程时,该进程方能继续执行。进程是以人们不可预知的速度向前推进,此即进程的异步性。

    操作系统的主要功能

    (1)进程控制,主要功能时为作业创建进程,撤销已结束的进程,以及控制进程在运行过程中的状态转换。
    (2)进程同步,进程同步的主要任务是为多个进程(含线程)的运行进行协调。
    (3)进程通信,进程通信的任务就是用来实现在相互合作的进程之间的信息交换。
    (4)调度,分为作业调度和进程调度。作业调度的基本任务是从后备队列中按照一定的算法,选择出若干个作业,为它们分配运行所需要的资源(首先分配内存);进程调度的任务是从进程的就绪队列中,按照一定的算法选出一个进程,把处理机分配给它。
    (5)内存分配,允许正在运行的程序申请附加的内存空间。
    (6)内存保护,确保每道用户程序都只在自己的内存空间内运行,彼此互不干扰。
    (7)在多道程序环境下,每道程序不可能都从“0”地址开始装入内存,这就致使地址空间内的逻辑地址和内存空间中的物理地址不相一致。为使程序正确运行,存储器管理必须提供地址映射功能。
    (8)内存扩充,用于实现请求调入功能和置换功能。请求调入功能允许在装入一部分用户程序和数据的情况下,便能启动该程序运行。在程序运行过程中,若若发现要继续运行时所需的程序和数据尚未装入内存,可向OS发出请求,有OS从磁盘中将所需部分调入内存。置换功能,若发现在内存中已无足够的空间来装入需要调入的程序和数据时,系统应能从内存中的一部分暂时不用的程序和数据调至盘上,以腾出内存空间。
    (9)缓冲管理,例如在I/O设备和CPU之间引入缓冲,可有效缓和两者速度不匹配的矛盾,提高CPU利用率。
    (10)设备分配,处理过程是:设备处理程序首先检查I/O请求的合法性,了解设备状态是否空闲的,了解有关的传递参数以及设置设备的工作方式,blabla…..
    (11)文件管理功能,分为文件存储空间管理、目录管理、文件读写/管理和保护
    (12)操作系统与用户之间的接口,分为用户接口和程序接口。用户接口是提供给用户使用的接口,用户通过该接口取得操作系统的服务;程序接口是提供给程序员在编程时使用的接口,是用户程序取得操作系统服务的唯一途径。


    一、软件生命周期
    软件定义
    软件任务立项:名称、性质、目标、意义、规模
    项目可行性分析:技术、经济、操作可行性分析
    制定项目计划:人员、组织、进度资金、设备等多方面
    软件需求分析:功能、性能、数据、操作等方面
    软件开发期
    软件概要设计:软件构造、接口、全局数据和数据环境、模块结构、模块接口等
    软件详细设计:各个模块的程序算法和局部数据结构等细节
    编码和单元测试:程序员完成实现并单元测试
    系统集成测试:把测试过的各个模块使用如渐增集成策略组装起来
    系统确认验证:需要以用户为主体、以需求规格说明书对软件的定义为依据进行逐项确认。
    软件运行与维护

    二、软件开发六大模型
    (1)瀑布模型
    瀑布模型是一种基于里程碑的阶段过程模型,它所提供的里程碑式 的工作流程,为软件项 目按规程管理提供了便利,例如,按阶段制定项目计划,分阶段进行成本核算,进行阶段性评 审等;并对提高软件产品质量提供了有效保证。
    瀑布模型的作用还体现在文档上。每个阶段都必须完成规定的文档,并在每个阶段结束前 都要对所完成的文档进行评审。这种工作方式有利于软件错误的尽早发现和尽早解决,并为软 件系统今后的维护带来了很大的便利。
    瀑布模型是一种线性模型,要求项目严格按规程推进,必须等到所有开发工作全部作完以后才能获得可以交付的软件产品。应该讲,通过瀑布模型并不能对软件系统进行快速创建,对 于一些急于交付的软件系统的开发,瀑布模型有操作上的不便。
    瀑布模型主要适合于需求明确,且无大的需求变更的软件开发,例如,编译系统、操作系统等。但是,对于那些分析初期需求模糊的项目,例如那些需要用户共同参加需求定义的项目,瀑布模型也有使用上的不便。

    (2)原型模型,分为快速原型方法、原型进化模型
    <1>快速原型方法
    快速原型方法是原型模型在软件分析、设计阶段的应用,用来解决用户对软件系统在需求 上的模糊认识,或用来试探某种设计是否能够获得预期结果。
    快速原型是用来获取用户需求的,或是用来试探设计是否有效的。一旦需求或设计确 定下来了,原型就将被抛弃。因此,快速原型要求快速构建、容易修改,以节约原型创建成本、 加快开发速度。快速原型往往采用一些快速生成工具创建,例如4GL 语言。目前,MicrosoftVisual Basic、Inprise Delphi 等基于组件的可视化开发工具,也被应用于原型创建之中,并 且都是非常有效的快速原型创建工具,而且还可用于原型进化。
    快速原型是暂时使用的,因此并不要求完整。它往往针对某个局部问题建立专门原型, 如界面原型、工作流原型、查询原型等。
    快速原型不能贯穿软件的整个生命周期,它需要和其他的过程模型相结合才能产生作 用。例如,在瀑布模型中应用快速原型,以解决瀑布模型在需求分析时期存在的不足。
    <2>原型进化模型
    原型进化对开发过程的考虑是,针对有待开发的软件系统,先开发一个原型系统给用户使 用,然后根据用户使用情况的意见反馈,对原型系统不断修改,使它逐步接近并最终到达开发目标。跟快速原型不同的是,快速原型在完成需求定义后将被抛弃,而原型进化所要创建的原型则是一个今后将要投入应用的系统,只是所创建的原型系统在功能、性能等方面还有许多不足,还没有达到最终开发目标,需要不断改进。

    (3)增量模型
    增量模型是瀑布模型和原型进化模型的综合,它对软件过程的考虑是:在整体上按照瀑布 模型的流程实施项目开发,以方便对项目的管理;但在软件的实际创建中,则将软件系统按功 能分解为许多增量构件,并以构件为单位逐个地创建与交付,直到全部增量构件创建完毕,并 都被集成到系统之中交付用户使用。
    如同原型进化模型一样,增量模型逐步地向用户交付软件产品,但不同于原型进化模型的 是,增量模型在开发过程中所交付的不是完整的新版软件,而只是新增加的构件。

    (4)螺旋模型
    螺旋模型即是一种引入了风险分析与规避机制的过程模型,是瀑布模型、快速原型方法和 风险分析方法的有机结合。
    螺旋模型基本方法是,在各个阶段创建原型进行项目试验,以降低各个阶段可能遇到的项 目风险。例如,为了降低用户对软件界面不满意的风险,可以在需求分析阶段建立“界面原型”;为了降低软件不能按设计要求实现的风险,可以在设计阶段针对所采用的技术建立“仿真试探原型”。

    (5)喷泉模型
    喷泉模型的过程方法所考虑的是,基于面向对象方法所带来的便利,对软件的分析、设计和实现按照迭代的方式交替进行,并通过进化的方式,使软件分阶段逐渐完整、逐步求精。例如,第一阶段软件开发的目标可以是软件的基本功能;第二阶段可以是在第一阶段建立的软件的基础上,对软件进行进一步的完善,并实现软件的主要功能;第三阶段则是在第二阶段的基础上,对软件进行更加完整的开发,并以实现软件全部功能作为创建目标。

    (6)组件复用模型
    自有软件开发以来,软件复用就一直存在,并产生了一些比较常用的软件复用方法。传统的软件复用方法是建立源程序函数库,可以把这些函数用在许多不同的软件上面。而在面向对 象技术中,软件复用则可以通过建立类模块来实现。由于大多数的类模块具有继承性,因此, 比起传统方法,基于类模块的复用效果要好一些。
    组件技术是基于面向对象技术发展起来的,可以把组件看作为一个盒子,它里面封装了许多个类模块。因此,组件比类更大、更 抽象,其中包含了更多的功能,更具有通用性,更加有利于复用。

    展开全文
  • 软件工程定义

    2019-04-01 21:09:25
    软件工程 是指应用计算机科学、数学及管理科学等原理,以工程化的原则和方法来解决软件工程问题的工程,其目的是提高软件生产效率、提高软件质量、降低软件成本。 计算机软件的十个分类 1、系统软件 是一套服务于...

    软件工程

    是指应用计算机科学、数学及管理科学等原理,以工程化的原则和方法来解决软件工程问题的工程,其目的是提高软件生产效率、提高软件质量、降低软件成本

    计算机软件的十个分类

    1、系统软件

    是一套服务于其他程序的程序。
    特点:
    和计算机硬件大量交互;多用户大量使用;需要调度、资源共享和复杂进程管理的同步操作;复杂的数据结构以及多种外部接口。

    2、应用软件

    解决特定业务需要的独立应用程序。

    3、工程/科学软件

    通常带有“数值计算”算法的特征。

    4、嵌入式软件

    存在于某个产品或系统中,可实现和控制面向最终使用者和系统本身的特性和功能。
    可以实现有限但难于实现的功能

    5、产品线软件

    产品为多个不同用户提供不同功能。

    6、Web应用

    是一类以网络为中心的软件
    随着Web2.0的出现,网络应用正在发展为复杂的计算环境,不仅为最终用户提供独立的特性、计算功能和内容信息,还和数据库和商务应用程序相结合。
    绝大多数WebApp具备网络密集性、并发性、无可预知的负载量、性能、可用性和数据驱动属性。

    7、人工智能软件

    利用非数值算法解决计算和直接分析无法解决的复杂问题。

    8、开放计算

    9、网络资源

    10、开源软件

    展开全文
  • 软件工程

    Software:

    (1)指令的集合,通过执行这些指令可以满足预期的特征、功能和性能需求;
    (2)数据结构,使得程序可以合理利用信息
    (3)软件描述信息,它以硬拷贝和虚拟形式存在,用来描述程序操作和使用


    Software Engineering:

    软件工程是:
    (1)将系统化的、规范化、可量化的方法应用于软件的开发、运行和维护,即将工程化方法应用于软件。
    (2)在(1)中所述方法的研究

    What the difference between software and hardware?
    1.软件是设计开发的,而不是传统意义上生产制造的。
    2.软件不会“磨损”
    3.大多数软件根据实际的顾客需求定制的。

    Why does software need Change or Evolved?
    软件必须适应新的计算环境或技术的需要。
    必须增强软件来实现新的业务需求。
    软件必须扩展到与其他更现代的系统或数据库进行互操作。
    必须重新构建软件,使其在网络环境中可行。
    列表内容
    支持软件工程的根基在于质量关注点(quality focus)
    是对软件的组织承诺,是支持软件工程的基石
    软件工程的基础是过程(process)层。软件过程将各个技术层次结合在一起,使得合理、及时地开发计算机软件成为可能。
    软件工程方法(method)为构建软件提供技术上的解决方法。方法包括:沟通、需求分析、设计模型、编程、测试和技术支持。


    Software Process :

    软件过程:软件过程是工作产品构建时所执行的一系列活动、动作和任务的集合。

    Generic Framework Activity
    适用于所有软件项目,无论其规模和复杂程度如何
    1.沟通(Communication):目的是理解利益相关者的项目目标,并收集需求以定义软件特性和功能。
    2.策划(Planning):定义和描述了软件工程工作,包括需要执行的技术任务、可能的风险、资源需求、工作产品和工作进度计划。
    3.建模(Modeling):利用模型哎更好地理解软件需求并完成符合这些需求的软件设计。
    4.构建(Construction):它包括编码和测试以发现编码中的错误。
    5.部署(Deployment):软件交付到用户,用户对其进行评测并给出反馈意见。

    Umbrella Activities(普适性活动):
    普适性活动贯穿软件项目始终。
    1.软件项目跟踪和控制:项目根据计划评估项目进度,并且采取必要的措施保证项目按进度计划进行。
    2.风险管理:对可能影响项目成果或者产品质量的风险进行评估。
    3.软件质量保证:确定和执行软件质量保证的活动
    4.技术评估:评估软件工程产品、尽量在错误传播到下一个活动之前,发现并清除错误。
    5.测量:定义和收集过程、项目和产品的度量,以帮助团队在发布软件的时候满足利益相关者要求。同时,测量还可以与其他框架活动和普适性活动配合使用。
    6.软件配置管理:在整个软件工程中,管理变更所带来的影响。
    7.可复用管理:定义产品复用的标准,并且建立构建复用机制。
    8.工作产品的准备和生产:包括了生产产品所必需的活动。


    Process Flow

    过程流:描述了在执行顺序和执时间上,如何组织框架中的活动,动作,任务。
    线性过程流(Liner process flow):从沟通到部署顺序执行五个框架活动。
    这里写图片描述
    迭代过程流(iterative process flow):在执行下一个活动前重复执行之前一个或多个活动。
    这里写图片描述
    演化过程流(evolution process flow):采取循环的方式执行各个活动。
    这里写图片描述
    并行过程流(parallel process flow):将一个或是多个活动与其他活动并行执行。
    这里写图片描述


    过程模式(process pattern):描述了软件工程工作中遇到的过程相关的问题、明确了问题环境并给出了针对该问题的一种或几种可证明的解决方式。


    Process Model

    惯用过程模型是为了改变软件开发的混乱状态,促使软件开发更加有序。
    瀑布模型(waterfall model):又被称为经典生命周期(classic life cycle),它提出了一个系统的、顺序的软件开发方法。
    优点:
    有利于大型软件开发过程中人员的组织、管理,从而提高了大型软件项目开发的质量和效率。
    当需求确定、工作采用线性的方式完成的时候瀑布模型是一个很有用的过程模型。
    一个有用的过程模型,其中需求是固定的,工作将以线性方式完成。
    缺点:
    过于理想,缺乏灵活性,容易产生需求偏差。
    实际的项目很少遵守瀑布模型提出的顺序。
    客户通常很难清除的描述所有的需求。
    客户必须要有耐心,因为只有在项目接近尾声的时候,他们才能的带执行的程序。
    适用范围:需求确定,工作能够采用线性的方式完成的软件。
    这里写图片描述
    V模型(V-model):
    描述了质量保证动作同沟通、建模相关动作以及早期构建相关的动作之间的关系。
    V模型强调软件开发的协作和速度,将软件实现和验证有机地结合起来,在保证较高的软件质量情况下缩短开发周期。
    优点:适合工程量小、人力资源少并且开发过程中改动不大的项目
    缺点:错误发现时间迟,产生的风险代价高
    这里写图片描述

    增量过程模型(Incremental Model)
    增量过程模型侧重于每一个增量都提交一个可以运行的产品。
    优点:
    1.能在较短的时间内向用户提交可完成部分工作的产品。
    2.逐步增加产品功能可以使用户有充裕的时间学习和适应新产品,从而减少一个 全新的软件可能给客户组织带来的冲击。
    3. 规避技术风险
    4. 可并行开发构件,加快开发的进度
    5. 对于在业务截止日期之前完全实施的人员配置非常有用。
    缺点:
    (1)并行开发构件有可能遇到不能集成的风险,软件必须具备开放式的体系结构;
    (2)增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型,但也很容易退化为边做边改模型,从而是软件过程的控制失去整体性。
    适用范围:
    (1)进行已有产品升级或新版本开发,增量模型是非常适合的; (2)对完成期限严格要求的产品,可以使用增量模型;
    (3)对所开发的领域比较熟悉而且已有原型系统,增量模型也是非常适合的。
    (4) 项目在既定的商业要求期限之前不可能找到足够的开发人员
    这里写图片描述

    演化过程模型(Evolutionary Model)
    演化模型是迭代的过程模型。
    原型开发(prototyping ):当需求很模糊的时候,原型开发可以帮助软件开发人员和利益相关者更好地理解究竟需要做什么。
    优点:
    开发者与用户充分交流,可以澄清模糊需求,需求定义比其他 模型好得多
    开发过程与用户培训过程同步
    为用户需求的改变提供了充分的余地
    开发风险低,产品柔性好
    开发费用低,时间短
    系统易维护,对用户更友好

    缺点:
    1、 没有考虑软件的整体质量和长期的可维护性。
    2、 大部分情况是不合适的操作算法被采用目的为了演示功能,不合适的开发工 具被采用仅仅为了它的方便,还有不合适的操作系统被选择等等。
    3、 由于达不到质量要求产品可能被抛弃,而采用新的模型重新设计。
    适用范围:
    尽管原型可以用作独立的流程模型,但它更常用作一种可以在任何流模型的上下文中实现的技术。
    这里写图片描述
    螺旋模型(Spiral Model)
    螺旋模型是一种风险驱动型的过程模型生成器,对于软件集中的系统,它可以指导多个利益相关者的协同工作。
    优点:
    它结合了原型的迭代性质和瀑布模型的系统性和可控性特点。
    1. 强调风险
    2. 强调阶段质量
    3. 提供纠错的机会
    4. 使用原型作为风险降低机制,进一步使开发人员能够在产品演变的任何阶段应用原型方法。
    缺点:
    1. 每个阶段都要提出被选方案,进行风险分析,研发周期长,效率低
    2. 必须要转业的风险分析人员的参与
    3. 如果没有发现和管理重大风险,问题无疑将会发生。
    适用范围:大型项目
    这里写图片描述

    协同模型(concurrent development model)
    有时候又称为协同工程,它允许软件团队表述本章所描述的任何模型中的迭代和并发元素。
    协同建模提供了项目当前状态的准确画面。
    适用范围:所有类型的软件开发,协同模型通常更适合涉及不同工程团队的产品工程项目。
    这里写图片描述

    统一过程(Unified Process)
    统一过程模型
    统一过程模型是一种“用例驱动、以体系结构为核心、迭代及增量”的软件 过程框架,由 UML 方法和工具支持。它是一种增量模型,定义了五个阶段:
    a、起始阶段,包括用户沟通和计划活动,强调定义和细化用例
    b、 细化阶段,包括用户沟通和建模活动,重点是创建分析和设计模型。
    c、构件阶段,细化模型设计,并将设计模型转化为软件构件实现
    d、 转化阶段,将软件从开发人员传递给最终用户,并由用户完成 beta 测试和验 收测试
    e、生产阶段,持续地监控软件的运行,并提供技术支持。
    优点:
    1. 任何功能开发后就进入测试过程,及早进行验证
    2. 早期风险识别,采取预防措施

    缺点:
    1. 需求必须在开始之前完全弄清楚,否怎有可能在架构上出现错误
    2. 必须有严格的过程管理,以免使过程退化为原始的试→错→改模式
    3.如果不加控制的让用户过早接触没有测试完全,版本不稳定的产品可能对用 户和开发团队都带来负面的影响。
    这里写图片描述


    Agile Development

    敏捷宣言(Agile development manifesto):
    个人和这些个人之间的交流胜过了开发过程和工具
    可运行的软件胜过了宽泛的文档
    客户合作胜过了合同谈判
    对变更的良好响应胜过了按部就班地遵循计划

    极限编程(Extreme Programming (XP))
    极限编程是敏捷软件开发使用最广泛的一个方法。

    极限编程过程:
    1.策划:
    开始创造“用户故事”
    敏捷团队评估每个故事并分配一个成本(开发周数)
    故事被分组到一个可交付增量
    承诺在交付日期进行
    在第一次递增之后,“项目速度”用于帮助估计后续发行版本的发布日期和进度安排,确定是否对整个开发项目中的所有故事有过分承诺。
    2.设计
    遵循KIS(保持简洁)原则
    鼓励使用CRC(类-责任-协作者)卡(见第8章)
    对于困难的设计问题,建议创建“尖峰解决方案” - 一个设计原型
    鼓励“重构”: 重构是以不改变代码外部行为而改进其内部结构的方式来修改软件系统的过程。
    3.编码
    在编码开始之前,建议对故事进行单元测试
    鼓励“结队编程”
    4.测试
    所有的单元测试每天都执行
    “验收测试”,由客户规定技术条件,并且着眼于客户可见的、可评审的系统级的特征和功能。
    这里写图片描述

    工业极限编程(Industrial XP (IPX))
    IXP是XP的一种有机进化。它由XP的最低限要求、以客户为中心、测试驱动精神组成。IXP和XP的主要差别在于其管理具有更大的包容性,它扩大了用户角色,升级了技术实践。
    IXP合并了六个新实践
    Readiness assessment(项目准备)
    Project community(项目社区)
    Project chartering(项目承租)
    Test-driven management (测试驱动管理)
    Retrospectives.(回顾)
    Continuous learning (持续学习)

    需求工程(Requirement engineering)

    七个任务
    1.起始(Inception):在项目起始阶段,要建立基本的理解,包括对问题、谁需要解决方案、所期望解决方案的性质、与项目利益相关者和开发人员之间达成初步交流合作的效果。
    2.导出(Elicitation –gathering requirements):询问客户、用户和其他人,系统或产品的目标是什么,想要实现什么,系统和产品如何满足业务的要求,最终系统或产品如何利用于日常工作。
    3.精化(Elaboration-requirement modeling):在起始和导出阶段获得的信息将在精化阶段进行扩展和提炼该任务集中于开发一个精确的需求模型。
    4.协商(Negotiation-win-win):使用迭代的方法给需求排序,评估每项需求对项目产生的成本和风险,表述内部冲突,删除、组合和修改需求,以便参与各方均能达到一定的满意度,实现双赢。
    5.规格说明(Specification-document,Model,prototype):一个规格说明可以是一份写好的文档、一套图形化的模型、一个形式化的数学模型、一组使用场景、一个原型或上述各项的任意组合。
    6.确认(Validation-Quality assess):在确认这一步对需求工程的工作产品进行质量评估。
    7.需求管理(Management-Change):基于计算机的系统其需求会变更,并且变更的要求贯穿于系统的整个生存期。需求管理是用于帮助项目组在项目进展中标识、控制和跟踪需求以及需求变更的一组活动。

    需求建模的元素

    这里写图片描述
    这里写图片描述

    基于场景建模(功能)

    使用基于场景的方法可以从用户的视角描述系统。
    开发用例图时,应列出特定参与者执行的功能或活动。
    例:
    这里写图片描述

    UML**活动图**在特定场景通过提供迭代流的图形表示来补充用例。
    例:
    这里写图片描述

    UML**泳道图**是活动图的一种有用变化,可以让建模人员表示用例所描述的活动流,同时指示哪个参与者或分析类是由活动矩形所描述的活动来负责。
    这里写图片描述

    基于类的建模

    基于类建模表示了系统操作的对象、应用于对象间能有效控制的操作、这些对象间的关系以及已定义类之间的协作。
    基于类的分析模型包括类和对象、属性、操作、类的职责协作者(CRC)模型、协作图和包。

    识别分析类
    外部实体(其他系统、设备、人员),产生或实验基于计算机系统的信息。
    事物(报告、显示、字母、信号),问题信息域的一部分。
    偶发事件或事件(所有权转移或完成机器人的一组移动动作),在系统操作环境内发生。
    角色(经理,工程师,销售人员),由和系统交互的人员扮演
    组织单元(部门,组,团队),和某个应用系统相关
    场地(制作车间或码头),建立问题的环境和系统的整体功能
    结构(传感器、交通工具、计算机),定义了对象的类或与对象相关的类。
    例:
    这里写图片描述
    这里写图片描述

    类-职责-协作者建模(CRC)
    CRC模型实际上是表示类的标准索引卡片的集合。
    顶部写类名,左侧列出类的职责,右侧部分列出了类的协作者。
    这里写图片描述

    类:
    Entity classes 实体类:一般代表保存在数据库中和贯穿应用程序的事物。
    Boundary classes 边界类:创建用户可见的和在使用软件时交互的接口
    Controller classes 控制类:管理“控制单元”

    职责:
    职责的基本原则:
    属性:描述了已经选择包含在需求模型中的类
    操作:定义了某个对象的行为。
    5个指导原则:
    1.智能系统应分布哎所有类中以求最佳地满足问题的需求。
    2.每个职责的说明应尽可能具有普遍性。
    3.信息和与之相关的信息应局限于一个类中而不要分布在多个类中。
    4.信息和与之相关的行为应该放在同一类中。
    5.适合时,职责应由相关类共享。

    生成行为模型

    生成行为模型的步骤:
    1.评估所有的用例,以保证完全理解系统内的交互顺序
    2.识别驱动交互顺序的事件,并理解这些事件如何与特定的对象相互关联
    3.为每个用例生成序列
    4.创建系统状态图
    5.评审行为模型以验证准确性和一致性。

    状态图:
    UML状态图就是一种行为模型,该图为每个类呈现了主动状态和导致这些主动状态变化的事件。
    例:
    这里写图片描述
    顺序图:
    表明事物引发从一个对象到另一个对象的转移。
    这里写图片描述

    软件设计(Software Design)

    这里写图片描述

    设计概念

    1.抽象(Abstraction):
    过程抽象是指具有明确和有限的指令序列(描述动作)
    数据抽象是描述数据对象的冠名数据集合(描述动作怎么做)

    2.体系结构(Architecture):软件的整体结构和这种结构为系统提供概念完整方式。构件表示主要的系统元素及其交互。

    3.模式(Patterns):模式承载了已证实的解决方案的精髓。设计模式描述了在某个特定场景与可能影响模式应用和使用方法的“影响力”中解决某个特定的设计问题的设计结构。

    4.关注点分离(Separation of concerns):它表明任何复杂问题如果被分解为可以独立解决和优化的若干块,该复杂问题能够更容易的被处理。

    5.模块化(Modularity):模块化是关注点分离最常见的表现。模块化设计使得开发工作更易规划。

    6.信息隐蔽(Hiding):隐蔽意味着通过定义一系列独立的模块可以得到有效的模块化,独立模块互相之间只交流实现软件功能所必须的那些信息。隐蔽定义并加强了对模块内过程细节的访问约束和对模块所使用的任何局部数据结构的访问约束。

    7.功能独立(Functional independence):开发具有“专一”功能和低耦合性的模块即可实现功能独立。

    8.求精(Refinement):通过连续精化过程细节层次来实现程序的开发,通过逐步分解功能的宏观陈述直到形成程序设计语言的语句来进行层次开发。
    抽象和精化是互补的概念。

    9.方面(Aspects):一个方面作为一个独立的模块进行实施,而不是作为“分割的”或者和许多构件“纠缠的”软件片段进行实施。设计体系结构应当支持定义一个方面,该方面即一个模块,该模块能够使该关注点经过它横切的所有其他关注点而得到实施。

    10.重构(Refactoring):重构是使用这样一种方式改变软件系统的过程:不改变代码的外部行为而是改进其内部结构。

    11.面向对象的设计概念(OO design concepts):
    面向对象概念(类、对象、继承、消息和多态)

    12.设计类(Design Class):提供设计细节,使程序得以实施。

    设计概念强调了:
    (1)抽象的必要性,它提供了一种创造可重用软件构件的方法
    (2)体系结构的重要性,它使得能够更好地理解系统整体结构
    (3)基于模式的工程的有益性,它是一项用于已证明能力的软件的设计技术
    (4)关注点分离和有效的模块化的价值,他们使得软件更容易理解、更容易测试以及更容易维护。
    (5)信息隐藏的直接作用,当错误发生时,它能够减少负面影响的传播
    (6)功能独立的影响,他是构造有效模块的标准
    (7)求精作为一种设计方法的作用
    (8)横切系统需求方面的考虑
    (9)重构的应用,他是为了优化已导出的设计
    (10)面向对象的类和与类相关特征的重要性

    设计模型(design model)

    数据设计元素:数据设计创建在高级抽象级上表示的数据模型和信息模型。
    体系结构设计元素:体系结构设计元素通常描述为一组相互关联系统的子系统,且常常从需求模型中的分析包中派生出来。
    接口设计元素:软件接口设计元素描述了信息如何流入和流出系统以及被定义为体系结构一部分的构件之间是如何通信的。
    接口设计有3个重要的元素:
    (1)用户界面
    (2)和其他系统、设备、网络或其他信息生成者或使用者的外部接口
    (3)各种设计构件之间的内部接口
    构件级设计元素:软件的构件级设计完整地描述了每个软件构件的内部细节。构件级设计为所以局部数据对象定义数据结构,为所有在构件内发生的处理定义算法细节,并定义允许访问所有构件操作的接口。
    部署级设计元素:部署级设计元素指明软件功能和子系统将如何在支持软件的物理计算环境内分布。

    体系结构设计

    程序或计算机系统的软件体系结构是指系统的一个或者多个结构,它包括软件构件、构件的外部可见属性以及它们之间的相互联系
    体系结构并非可运行的程序。
    确切的说,它是一种表达,是能够:
    (1)对设计在满足既定需求方面的有效性进行分析
    (2)在设计变更相对容易的阶段,考虑体系结构可能的选择方案
    (3)降低与软件构造相关的风险

    体系结构重要的3个关键原因
    1.软件体系结构的表示有助于对计算机系统开发感兴趣的各方展开交流。
    2.体系结构突出了早期的设计决策,这些决策对随后所有的软件工程工作有深远影响,同时对系统作为一个可运行实体的最后成功有重要作用。
    3.体系结构“构建了一个相对小的、易于理解的模型,该模型描述了系统如何构成以及其构件如何一起工作”

    体系结构风格
    1.以数据为中心的体系结构。
    2.数据流体系结构。
    3.调用和返回体系结构
    4.面向对象体系结构
    5.层次体系结构

    体系结构环境图(ACD)
    上级系统:这些系统把目标系统作为某些高层处理方案的一部分
    下级系统:这些系统被目标系统使用,并为完成目标系统的功能提供必要的数据和处理
    同级系统:这些系统在对等的基础上相互作用
    参与者:通过产生和消耗必要处理所需的信息,实现与目标系统交互的实体(人,设备)
    这里写图片描述
    这里写图片描述

    构件级设计

    构件的概念:
    1.构件是计算机软件中的一个模块化的构造块。
    2.OMG定义构件:系统中模块化的、可部署的和可替换的部件,该部件封装了实现并暴露一组接口。
    面向对象的观点(Object-Oriented view):构件包括一组协作的类。
    传统观点(Traditional View):一个构件就是程序的一个功能要素,程序由处理逻辑及实现处理逻辑所需的每部数据结构以及能够保证构件被调用和实现数据传递的结构构成。

    基本设计原则

    开闭原则(Open-Closed Principle ,OCP):模块应该对外延具有开放性,对修改具有封闭性。
    依赖倒置原则(Dependency Inversion Principle ,DIP):依赖于抽象,而非具体实现。

    Liskov替换原则(Liskov Substitution Principle (LSP)):子类可以替换他们的基类。
    接口分离原则(The Interface Segregation Principle (ISP)):多个客户专用接口比一个通用接口好
    发布复用等价性原则(The Release Reuse Equivalency Principle,REP):复用的粒度就是发布的粒度
    共同封装原则(The Common Closure Principle (CCP)):一同变更的类应该合在一起
    共同复用原则(The Common Reuse Principle (CRP)):不能一起复用的类不能被分到一组

    内聚性(Cohesion):内聚性意味着构件或者类只封装那些相互关联密切,以及与构件或类自身有亲密关系的属性和操作。
    功能内聚:主要通过操作来体现,当一个模块只完成某一组特定操作并返回结果时,就称此模块是功能内聚的。
    分层内聚:高层能够访问低层的服务,但低层不能访问高层的服务。
    通信内聚:访问相同数据的所有操作被定义在同一个类中。(数据的查询,访问,存储)

    耦合性(Coupling):
    耦合是类之间彼此联系程度的一种定性度量。
    随着类(构件)相互依赖越来越多,类之间的耦合程度亦会增加。
    内容耦合:暗中修改其他构件的内部数据,这违反了信息隐蔽原则
    公用耦合:当大量的构件都要使用同一个全局变量时发生这种耦合
    控制耦合:当操作A调用操作B,并向B传递控制标记时,就会发生这种耦合。
    标记耦合:当类B被声明为类A某一操作中的一个参数类型时,就会发生这种耦合。
    数据耦合:当操作需要传递长串的数据参数时,就会发生这种耦合。
    例程调用耦合:当一个操作调用另一个操作时,就会发生这种耦合。
    类型使用耦合:当构件A使用了在构件B中定义的一个数据类型时,就会发生这种耦合。
    包含或者导入耦合:当构件A引入或者包含一个构件B的包或者内容时,就会发生这种耦合。
    外部耦合:当一个构件和基础设施构件进行通信和协作时,就会发生这种耦合。

     为什么要高内聚?  
     模块之间的关系越紧密,出错就越少!
     为什么要低耦合?  
     子程序间的关系越复杂,就会产生更多的意想不到的错误!会给以后的维护工作带来很多麻烦!
      高内聚低耦合,是软件工程中的概念,是判断设计好坏的标准,主要是面向对象的设计,主要是看类的内聚性是否高,耦合度是否低。

    用户界面设计

    黄金准则

    1.用户操纵控制
    (1)以不强迫用户进入不必要的或不希望的动作的方式来定义交互模式
    (2)允许用户交互被中断和撤销
    (3)当技能级别增长时可以使交互流线化并允许定制交互
    (4)使用用户与内部技术细节隔离开来
    (5)设计应允许用户与出现在屏幕上的对象直接交互
    2.减少用户的记忆负担
    (1)减少对短期记忆的要求
    (2)建立有意义的缺省
    (3)定义直观的快捷方式
    (4)以不断进展的方式揭晓信息
    3.保持界面一致
    (1)允许用户当前任务放入有意义的环境中
    (2)在应用系统家族内保持一致性
    (3)如果过去的交互模型已经建立起了用户期望,除非有迫不得已的理由,doze不要改变它。

    可用性

    可用性是指用户在使用高科技产品所提供的功能和特性时,对使用的容易程度和有效程度的定量测量。

    用户界面的分析与设计

    工程师建立用户模型。软件工程师创建设计模型。最终用户在脑海中对界面产生映像,称为用户的心理模型或系统感觉。系统的实现者创建实现模型
    用户模型:确定了系统最终用户的轮廓。
    设计模型:用户界面的设计
    心理模型:最终用户在脑海里对系统产生的印象。
    实现模型:组合了计算机系统的外在表现,结合了所有用来描述系统语法和语言的支撑信息。

    用户界面的分析和设计过程是迭代的,用户界面分析和设计过程开始于螺旋模型的内部,并且包括4个阶段:(1)界面分析及建模。(2)界面设计。(3)界面构造。(4)界面确认。

    这里写图片描述

    界面设计的目标是定义一组界面对象和动作,使得用户能够以满足系统所定义的每个使用目标的方式完成所有定义对的任务。

    界面分析

    在用户界面的设计中,理解问题就意味着了解:
    (1)通过界面和系统交互的人
    (2)最终用户为完成工作要执行的任务
    (3)作为界面的一部分而现实的内容
    (4)任务处理的环境

    界面分析:
    (1)用户分析:
    设计师能够将用户心理模型与设计模型聚合在一起的唯一办法就是努力了解用户,以及了解用户是如何使用系统的。
    可以从各种途径获得信息
    用户访谈:软件团队(代表)与用户讨论。
    销售输入:销售人员与用户定期见面。
    市场输入:市场分析,分析/理解市场每个部分使用软件的细微差别。
    支持输入:技术支持人员与用户访谈。

    (2)任务分析与建模
    任务分析的目标就是将这些技术应用到用户界面:
    a.用例:用例描述了参与者和系统的交互方式。从用例描述中,软件工程师可以提炼出任务、对象和整个的交互过程。
    b.任务细化:改进了交互流程。任务细化有两种方法:
    1.理解实现活动目标而必须完成的任务
    2.研究已有的基于计算机的解决方案的规格说明,并且得到一个适应于用户模型、设计模型和系统感觉的用户任务集合。
    逐步细化。
    c.对象细化:对象细化标识了接口对象
    d.工作流分析:工作流分析定义了涉及多个人(和角色)时工作流程是如何完成的。
    e.层次分析:
    用户任务:请求重新填写处方
    提供识别信息。
    指定名称。
    指定用户ID。
    指定PIN和密码。
    指定处方号码。
    指定日期重填是必需的。

    测试

    测试:测试是在交付给最终用户之前以特定意图找出错误为目的来执行程序的过程。
    验证与确认(Verification and Validation,V&V):
    验证是指确保软件正确地实现某一特定功能的一系列活动。
    确认是指确保开发的软件可追溯到客户需求的另外一系列活动。

    测试策略

    从小到大

    这里写图片描述

    传统的测试策略

    单元测试

    单元测试侧重于软件设计的最小单元(软件构件或模块)的验证工作。
    单元测试侧重于构件的内部处理逻辑和数据结构。
    可以对多个构件并行执行。
    测试模块的接口是为了保证被测试程序单元的信息能够正常地流入和流出;
    检查局部数据结构以确保临时存储的数据在算法的整个执行过程中能维持其完善性。
    执行控制结构中的所有独立路径(基本路径)以确保模块中的所有语句至少执行一次。
    测试边界条件确保模块在到达边界值得极限或受限处理的情形下仍能正确执行。
    最后要对所有的错误处理路径进行测试。
    这里写图片描述
    在单元测试期间,选择测试的执行路径是最基本的任务。
    边界测试时最重要的单元测试任务之一。

    单元测试过程
    这里写图片描述
    驱动模块:接收测试用例数据,将这些数据传递给被测模块,并输出结果。
    桩:替换那些从属于被测模块的模块
    当设计高内聚的构件时,就可以简化单元测试。当构件只强调一个功能时,测试用例数就会降低,且比较容易预见错误和发现错误。

    集成测试

    集成测试时构造软件体系结构的系统化技术,同时也是进行一些旨在发现与接口相关的错误的测试。
    集成测试的目标是利用单元测试的构件建立设计中描述的程序结构。

    自顶向下集成:自顶向下集成测试是一种构造软件体系结构的增量方法。
    深度优先:深度优先集成是首先集成位于程序结构中主控路径上的所有控件。
    广度优先:广度优先集成首先沿水平方向,将属于同一层的构件集成起来。
    自顶向下集成过程:
    1.主控模块作为测试驱动模块,用桩模块代替直接附属的下层模块;
    2.根据所选的集成策略(深度优先/广度优先),每次用一个实际模块替换一个桩模块;
    3.每集成一个模块都进行测试;
    4.完成每个测试集之后,用实际模块替换另一个桩模块;
    5.可以进行回归测试(即全部或部分地重复已做过的测试),以避免引入新错误。
    回到第2步继续执行此过程,直到完成整个程序结构的构造。

    自底向上集成测试:就是从原子模块(程序结构的最底层构件)开始进行构造和测试。
    自底向上集成测试过程:
    1.连接底层构件以构成完成特定子功能的簇。
    2.编写驱动模块(测试的控制程序)以协调测试用例的输入和输出
    3.测试簇
    4.去掉驱动程序,沿着程序结构向上逐步连接簇
    这里写图片描述

    回归测试

    回归测试重新执行已测试过的某些子集,以确保变更没有传播不期望的副作用。
    回归测试有助于保证变更不引入无意思行为或额外的错误。
    回归测试可以手工进行,方法是重新执行所以测试用例的子集,或者利用捕捉/回放工具自动进行。

    面向对象软件的测试策略

    面向对象软件的类测试等同于传统软件的单元测试。
    不同的是:
    传统软件单元测试侧重于模块的算法细节和模块接口数据;
    面向对象类的测试侧重于封装在该类中的操作和类的状态行为。
    封装的类是单元测试的重点,但不再孤立地对单个操作进行测试,而是将其作为类的一部分。
    簇测试时面向对象软件集成测试中的一个步骤。

    确认测试(Validation Testing)

    确认测试准则:软件确认是通过一系列表明与软件需求相符合的测试而获得的。

    α测试(Alpha testing):α测试测试是由代表性的最终用户在开发者的场所进行。软件在自然的环境下使用,开发者站在用户的后面观看,并记录错误和使用问题。α测试在受控的环境下测试。

    β测试(Beta testing)(又称客户验收测试,Acceptance testing):β测试在一个或多个最终用户场所进行。与α测试不通过,开发者通常不在场,因此,β测试是在不为开发者控制的环境下软件的“现场”应用。是在不可控的环境下测试。

    系统测试

    系统测试实际上是对整个基于计算机的系统进行一系列不同考验的测试。所有测试都是为了验证系统成分已经正确地集成在一起,并且完成了指派的功能。

    恢复测试(Recovery testing):通过各种方式强制让软件以各种方式失败并验证恢复是否正确执行。
    安全测试(Security testing):安全测试验证建立在系统内的保护机制是否能够实际保护系统不受非法入侵。
    压力测试(Stress testing):压力测试的目的是是软件面对非正常的情形。是一种要求以非正常数量、频率或容量的方式进行彻底评估。
    性能测试(Performance testing):性能测试用来测试软件在集成环境中的运行性能。
    部署测试(Deployment testing):部有时也将署测试称为配置测试,是在软件将要在其中运行的每一种环境中测试软件。

    测试传统的应用系统

    白盒测试:白盒测试有时也称为玻璃盒测试,是一种测试用例设计方法,它利用作为构件层设计的一部分描述的控制结构来生成测试用例。
    白盒测试是在了解模块内部结构的情况下进行的测试。
    利用白盒测试方法导出的测试用例可以:
    (1)保证一个模块中的所有独立路径至少被执行一次。
    (2)对所有的逻辑判定均需要测试取真和取假两个方面。
    (3)在上下边界及可操作的范围内执行所有的循环。
    (4)检验内部数据结构以确保其有效性。

    基本路径测试(Basic path testing)
    基本路径测试时由TOM首先提出的一种白盒测试技术。
    流图(程序图)是一种简单的控制流表示方法。
    流程图用于描述程序的控制结构,流程图映射为相应的流图。
    圆称为流图结点(flow graph node),表示一个或多个过程语句。处理框序列和一个菱形判定框可以映射为单个节点。
    流图中的箭头称为边或者连接,标识控制刘,类似于流程图中的箭头。
    由边和结点限定的区域称为域。当计算域时,将图的外部作为一个域。
    包含条件的结点称为判定结点,其特征是由它发射出两条或多条边。
    这里写图片描述
    这里写图片描述
    独立路径是指任何贯穿程序的、至少引入一组新语句或一个新条件的路径。
    如果设计测试用例强迫执行这些路径(基本集合),就可以保证程序中的每条语句至少执行一次,同时,每个条件判断的真和假都被执行。
    这里写图片描述
    环复杂度(Cyclomatic Complexity )计算方法:
    这里写图片描述
    V(G)的值提供了组成基本集合的独立路径的上街,并由此得出覆盖所有程序语句所需设计和运行的测试数量的上界。

    黑盒测试

    黑盒测试也称为行为测试,侧重软件的功能需求。
    黑盒测试使软件工程师能设计出将测试程序所有功能需求的输入条件集。
    黑盒测试不是白盒测试的替代品,而是作为发现其他类型错误的辅助方法。
    黑盒测试试图发现以下类型的错误:
    (1)不正确或遗漏的功能
    (2)接口错误
    (3)数据用在测试的后期阶段
    (4)行为或性能错误
    (5)初始化和终止错误
    黑盒测试的方法:
    Graph-based testing methods 基于图的测试方法
    Equivalence partitioning 等价类划分
    Boundary value analysis 边界值分析
    Orthogonal array testing 正交数组测试

    黑盒测试的例子:
    这里写图片描述
    这里写图片描述
    这里写图片描述

    展开全文
  • 什么是软件工程

    2017-08-10 10:55:57
    软件工程学科诞生后,人们为软件工程给出了不同的定义,例如最早的定义是由F.L. Bauer给出的,即“软件工程是为了经济地获得能够在实际机器上高效运行的、可靠的软件而建立和应用一系列坚实的软件工程原则”。而美国...
  • 软件工程基础知识

    2018-09-04 23:02:41
    软件工程知识点总结 有以下知识点(考试内容,当然不止这些)   1. 软件工程定义 2. 软件生存周期 3. 软件过程模型 4. 需求分析的定义、获取 5. 常见的软件体系结构(B/S 、C/S 、软件总线中间件) 6. ...
  • 软件工程重点知识点

    2019-03-25 22:41:59
    软件工程考试重点 1.软件工程定义: a.软件工程是一种工程形式,它运用计算机科学和数学原理,针对软件问题获得一种经济有效的解决方案。 b.用系统的、规范的、可度量的方法,开发、运行和维护软件。 2.软件...
  • 软件工程思想》读后感 林锐博士通过《软件工程思想》讲述“软件开发”和“做程序员”的道理,视野独特,构思新颖,内容风趣,不落窠臼,令人耳目一新。...搜狗百科中,是这样定义的:软件工程 (Software...
  • 软件工程核心概念

    2019-07-22 22:14:45
    文章目录软件概念软件的逻辑抽象性软件分类软件危机软件开发与软件工程软件开发基本过程软件开发成本软件工程要点软件工程原则软件工程目标软件开发方法软件生命周期模型软件生命周期软件生命周期模型SDM瀑布模型V-W...
  • 软件工程北大慕课题

    2020-01-23 13:56:33
    第一周:软件工程概论 软件的定义及特点 1单选(2分)软件产品与物质产品有很大的区别,软件产品是一种(C)产品。 A.有形 B.消耗 C.逻辑 D.文档 2多选(2分)下列关于软件的说法正确的是(BCD) A.软件是通过定制进而...
  • 第2章 软件工程与需求工程标签: 软件需求工程 《软件需求工程》 毋国庆 第二版 个人笔记 第2章 软件工程与需求工程软件工程 软件开发过程模型 需求工程在软件开发中的地位 软件需求的开发和管理过程1. 软件工程 ...
  • 软件工程定义:把软件当作一种工业产品,采用工程学的原理来管理和组织软件的开发和维护,称为软件工程。 v 软件是指程序、数据和文档三者共同构成的配置。 v 包含与数据处理系统操作有关的程序、规程...
  • 前言: 前面的关于软件工程的系列博客讲述的是传统的软件工程,本文讲述一下现在现代软件工程。...而现代软件工程强调的是人和物的关系,在不同层次的不断循环发展中的关系现代软件工程为研究单位。
  • 软件工程面试题

    2015-05-06 17:10:05
    软件工程就是用科学的知识和技术原理来定义,开发,维护软件的一门学科。 软件工程目标:付出较低开发成本;达到要求的功能;取得较好的性能;开发的软件易于移植;只需较低的维护费用;能按时完成开发任务,及时...
  • 本文主要介绍实体模型的设计过程,首先识别之间的关系,然后画出类图和包图,最后识别的属性和操作是面向对象方法的一个全新概念,模型是面向对象分析的核心,实体位于系统结构的商业规则服务层。...
  • 找到这篇文章的人一定被软件工程考试搞得头秃吧。 这篇文章将会让你不再那么头秃~ 文章内容仅供参考,如有错误,请指正。 Chapter01 SE的定义、目的、方法及作用? 定义软件工程即用系统科学的工程性...
  • 软件工程的设计意义

    2013-11-07 11:09:31
    良好的软件工程设计具有不可比拟的意义,它胜于执行软件需求、软件编码、软件维护等任何一个环节,这就是设计的优越性。秉承设计优先这一原则,会让软件开发变得简单而高效,可以尽量避免掉因设计失误而导致的缺陷。...
  • 软件工程导论 第一章 软件工程学概述 1. 软件工程的7条基本原理: 用分阶段的生命周期计划严格管理;坚持进行阶段评审;实行严格的产品控制;采用现代程序设计技术;结果应能清楚的审查;开发小组的人应该少而...
  • 摘要:如果想深入了解《软件工程导论》这本书,可以参考《软件工程导论》第五版、《系统分析与设计方法》普渡大学机械工业出版社、《实用软件工程》第二版、《软件工程-实践者的研究方法》等一系列书。 那么来详细...
1 2 3 4 5 ... 20
收藏数 201,496
精华内容 80,598
关键字:

类的操作如何定义 软件工程