软件工程总结Word文档格式.docx

上传人:b****4 文档编号:16672288 上传时间:2022-11-25 格式:DOCX 页数:6 大小:19.48KB
下载 相关 举报
软件工程总结Word文档格式.docx_第1页
第1页 / 共6页
软件工程总结Word文档格式.docx_第2页
第2页 / 共6页
软件工程总结Word文档格式.docx_第3页
第3页 / 共6页
软件工程总结Word文档格式.docx_第4页
第4页 / 共6页
软件工程总结Word文档格式.docx_第5页
第5页 / 共6页
点击查看更多>>
下载资源
资源描述

软件工程总结Word文档格式.docx

《软件工程总结Word文档格式.docx》由会员分享,可在线阅读,更多相关《软件工程总结Word文档格式.docx(6页珍藏版)》请在冰豆网上搜索。

软件工程总结Word文档格式.docx

主要解决待开发软件要“做什么”的问题,确定软件的功能、性能、数据、界面等要求,生成软件需求规约。

3)设计:

解决待开发的软件“怎么做”的问题。

分为系统设计和详细设计。

系统设计的任务是设计系统的体系结构, 设计的任务是设计各个组成成分的实现细节。

4)编码:

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

5)测试:

发现并纠正软件中的错误和缺陷。

测试主要包括单元测试、集成测试、确认测试和系统测试

6)运行和维护:

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

5软件过程模型

1)瀑布模型:

●特征:

阶段间具有顺序性和依赖性、推迟实现,阶段评审

●缺点:

(1)缺乏灵活性,难以适应需求不明确或需求经常变化的软件开发

(2)开发早期存在的问题往往要到交付使用时才发现,维护代价大

2)演化模型

●适用:

对软件需求缺乏准确认识的情况。

●开发过程:

从构造初始的原型出发,逐步将其演化成最终软件产品的过程。

●典型的演化模型:

增量模型、原型模型、螺旋模型

3)增量模型

●融合了瀑布模型的基本成分和演化模型的迭代特征

●后一个版本是对前一版本的修改和补充。

●强调每一个增量都发布一个可运行产品

●能有计划地管理技术风险

●适用范围:

(1)需求经常变化的软件开发

(2)市场急需而开发人员和资金不能在设定的市场期限之前实现一个完善的产品的软件开发

4)原型模型

●原型(prototype):

根据一组基本需求所构造的软件初始可运行版本

●原型的进一步解释:

预期系统的一个可执行版本,它反映了系统性质(如功能、计算结果等)的一个选定的子集。

●一个原型不必满足目标软件的所有约束,其目的是能快速、低成本地构建。

●原型的类型:

(1)探索型:

弄清要求,确定特性,并探讨多种方案的可行性

(2)实验型:

大规模开发和实现前,验证方案或算法的合理性。

(3)演化型:

原型作为目标系统的一部分。

●原型的使用策略

(1)废弃策略:

用于探索型和实验型原型。

(2)追加策略:

用于演化型原型

5)螺旋模型

l特点:

是瀑布模型和演化模型的结合,并增加风险分析

l 螺旋模型沿着螺线旋转,在四个象限上分别表达四个方面的活动,即:

制定计划、风险分析、实施工程、客户评估

使用范围:

大项目的开发

6)喷泉模型

特点:

(1)支持面向对象开发(2)迭代:

多次重复、不断演进(3)无间隙:

各阶段间无明显界限

面向对象的开发与设计

7)敏捷软件开发的价值观与开发原则(本题为作业题)

价值观:

【1】个人和交互高于过程和工具【2】可运行软件高于详尽的文档

【3】与客户协作高于合同(契约)谈判【4】对变更及时做出反应高于遵循计划

开发原则12条(应该不考)

(1)最优先的是通过尽早地和不断地提交有价值的软件使客户满意

(2)欢迎变化的需求,即使该变化出现在开发的后期,为了提升对客户的竞争优势,Agile过程利用变化作为动力

(3)以几周到几个月为周期,尽快、不断地发布可运行软件

(4)在整个项目过程中,业务人员和开发人员必须天天一起工作

(5)以积极向上的员工为中心建立项目组,给予他们所需的环境和支持,对他们的工作予以充分的信任

(6)项目组内效率最高、最有效的信息传递方式是面对面的交流

(7)测量项目进展的首要依据是可运行的软件

(8)敏捷过程提倡可持续的开发,项目发起者、开发者和用户应能长期保持恒定的速度

(9)应时刻关注技术上的精益求精和好的设计,以增强敏捷性

(10)简单化是必不可少的,这是尽可能减少不必要工作的艺术

(11)最好的构架、需求和设计出自于自我组织的团队

(12)团队要定期反思怎样才能更有效,并据此调整自己的行为

第二章:

系统工程

1.系统工程的任务:

计算机系统工程是一个问题求解活动,目的是揭示、分析所期望的功能,并把它们分配到各个单独的系统元素中去。

系统工程的任务是:

(1)识别用户的要求:

标识系统的功能和性能范围,确定系统的功能、性能、约束和接口。

(2)系统建模和模拟,可考虑建立如下模型:

【1】硬件系统模型:

硬件配置、通信协议、拓扑结构,以及确保安全性、可靠性、性能等要求的措施。

【2】软件系统模型:

各软件子系统的功能要求,性能要求,相互交互,在硬件系统中的部署。

【3】人机接口模型:

包括用户环境、用户的活动、人机交互的语法和语义等。

【4】数据模型:

使用了哪些数据库管理系统,它们之间的数据转换方式,必要时可给出主要的数据结构。

(3)成本估算及进度安排:

对将开发的基于计算机的系统进行成本估算,并作出进度安排。

(4)可行性分析:

从经济、技术、法律等方面分析所给出的解决方案是否可行,通常只有当解决方案可行并有一定的经济效益和/或社会效益时才开始真正的基于计算机的系统的开发

(5)生成系统规格说明

2基于计算机的系统由哪些元素组成?

(课后题)

计算机的系统指:

通过处理信息来完成某些预定义目标组织在一起的元素的集合或者排列,组成计算机系统的元素主要有:

软件,硬件,人员,数据库,文档和规程。

3如何进行可行性分析(作业题)

可行性分析需要从以下几个方面进行考虑:

【1】经济可行性:

从经济角度考虑进行成本效益的分析,包括成本、效益、货币的时间价值,投资回收期,纯收入等方面。

【2】技术可行性,包括风险分析、资源分析、技术分析,【3】法律可行性。

【4】通过对每个方面的综合考虑,折中选择最合适的方案,

4通常的分析要根据各种情况进行方案的折中选择。

但是可行性分析必须有一个明确的结论,下面给出集几种可以选择的结论:

(1)可立即开始

(2)需要推迟到某些条件落实才能开始。

(3)需要对开发目标进行某些修改后才能开始(4)因为某种原因不能进行。

第三章需求工程

1需求的概念:

需求是由系统分析员参与的,主要解决产品必须提供的服务和产品必须具备的质量特征的问题。

需求关注于顾客的需要,指定系统要“做什么”,而不关心问题的解决方案或实现

2需求分析的任务

(1)深入描述软件的功能和性能

(2)确定软件设计的约束和软件同其它系统元素的接口细节(3)定义软件的其它有效性需求

3获取需求的方法

(1)建立顺畅的通信途径

(2)访谈与调查(3)观察用户操作流程

(4)组成联合小组(5)用况,用况提供了系统将会被如何使用的描述

4软件需求的种类(作业题)

性能需求、用户或人的因素、环境需求、界面需求、文档需求、数据需求、资源使用需求、安全保密要求、可靠性需求、软件成本消耗与开发进度需求、其他非功能性要求

5需求工程的步骤?

每个步骤的任务?

分为6个阶段

(1)需求获取:

通过与用户的交流、对系统的观察等,对任务进行分析,确定系统的基本要求

(2)需求分析与协商:

对需求进行分类组织,分析每个需求与其他需求的关系以检查需求的一致性(3)系统建模:

使用某些建模技术和建模工具将对需求进行分析,使其符合用户的要求(4)需求规约,需求规约是分析系统的最终产物,它作为用户和开发者之间的一个协议,在之后的开发过程中发挥重要的作用(5)需求验证,验证对功能的正确性、完整性和清晰性。

(6)需求管理,需求管理是对需求工程所有相关活动的规划和控制

6需求分析的原则?

(作业题)

(1)必须能够表示和理解问题的信息域

(2)信息域:

包括信息内容、信息流、以及信息结构。

(3)必须能够定义软件将完成的功能(4)必须能够表示软件的行为(作为外部事件的结果(5)必须划分描述数据、功能和行为的模型,从而可以分层次地揭示细节

(6)分析过程应该从要素信息移向细节信息

7需求规约(SRS)的概念

需求规约是分析任务的最终产物,通过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标准,给出对目标软件的各种需求。

包括:

引言、信息描述、功能描述、行为描述、校验标准、参考书目和附录几个部分

附:

需求规约的原则(不知道是否考)

1. 

 

从现实中分离功能,即描述要“做什么”而不是“怎样实现”。

2. 

要求使用面向处理的规约语言(或称系统定义语言),讨论来自环境的各种刺激可能导致系统做出什么样的功能性反应,来定义一个行为模型,从而得到“做什么”的规约。

3. 

如果被开发软件只是一个基于计算机的系统中的一个元素,那么整个大系统也包括在规格说明的描述之中。

4. 

规约必须包括系统运行环境。

5. 

规约必须是一个认识模型,而不是设计或实现的模型。

6. 

规约必须是可操作的,以便能够利用它决定对于任意给定的测试用例,已提出的解决方案是否都能满足规约。

7. 

规约必须允许不完备性并允许扩充。

8. 

规约必须局部化和松散耦合。

它所包括的信息必须局部化,这样当信息被修改时,只要修改某个单个的段落(理想情况)。

同时,规约应被松散地构造(即松耦合),以便能够很容易地加入和删去一些段落。

8如何进行评审

评审要注意3点:

(1)需求确认和验证的手段。

(2)应指定专门人员负责。

(3)按规程严格进行。

评审人员评审时往往需要检查以下内容:

1.系统定义的目标是否与用户的要求一致;

2.系统需求分析阶段提供的文档资料是否齐全;

文档中的描述是否完整、清晰、准确地反映了用户要求;

3.被开发项目的数据流与数据结构是否确定且充足;

4.主要功能是否已包括在规定的软件范围之内,是否都已充分说明;

5.设计的约束条件或限制条件是否符合实际;

6.开发的技术风险是什么;

7.是否详细制定了检验标准,它们能否对系统定义是否成功进行确认。

第四章:

设计工程

1软件设计的原则

(1)抽象与逐步求精

(2)模块化(3)信息隐藏(4)模块独立

 

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 求职职场 > 简历

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1