hello--你的钱掉了
简述数据与软件工程的关系
大数据是随着互联网的普及应运而生的，大数据和云是分不开的，数据存储，数据的分类，数据挖掘，数据的分析，如何把一堆在硬盘，内存，服务器中存储的数据通过分析，处理，转换成能够为我们带来实际利益的东西，或者说实际能有用处的东西，就是大数据的解决问题。
其实云现在在中过是个双刃剑（不说了，硬伤。
。
。
无耐），大数据也因此受到了限制，不过云时代和大数据的到来是早晚的问题，而且近两年是有相当的趋势的，那么大数据对软件工程的影像无非就是方展方向上面和数据的安全问题，怎样防止数据的丢失被盗，IT技术又是如何对大数据进行存储和解析处理，都是当前软件工程的热门和必然的趋势，做好数据分析，数据挖掘，以后真的是不用发愁钱的问题
软件工程中 业务流程优化与用例图的关系是什么？
CMM是指“能力成熟度模型”，其英文全称为Capability Maturity Model for Software，英文缩写为SW-CMM，简称CMM。
它是对于软件组织在定义、实施、度量、控制和改善其软件过程的实践中各个发展阶段的描述。
CMM的核心是把软件开发视为一个过程，并根据这一原则对软件开发和维护进行过程监控和研究，以使其更加科学化、标准化、使企业能够更好地实现商业目标。
CMM是是一种用于评价软件承包能力并帮助其改善软件质量的方法，侧重于软件开发过程的管理及工程能力的提高与评估。
CMM分为五个等级：一级为初始级，二级为可重复级，三级为已定义级，四级为已管理级，五级为优化级。
CMM是由美国卡内基梅隆大学软件工程研究所1987年研制成功的，是目前国际上最流行最实用的软件生产过程标准和软件企业成熟度等级认证标准。
目前，我国已有软件企业通过了CMM标准认证 。
SW-CMM(Capability Maturity Model For Software 软件生产能力成熟度模型，以下简称＂CMM＂)，是87年由美国卡内基梅隆大学软件工程研究所（CMU SEI）研究出的一种一种用于评价软件承包商能力并帮助改善软件质量的方法，其目的是帮助软件企业对软件工程过程进行管理和改进，增强开发与改进能力，从而能按时地、不超预算地开发出高质量的软件。
其所依据的想法是：只要集中精力持续努力去建立有效的软件工程过程的基础结构，不断进行管理的实践和过程的改进，就可以克服软件生产中的困难。
CMM它是目前国际上最流行、最实用的一种软件生产过程标准，已经得到了众多国家以及国际软件产业界的认可，成为当今企业从事规模软件生产不可缺少的一项内容。
CMM目前通用流行的版本是1.1(Version1.1)。
《按照软件工程研究所（SEI）的原来计划，CMM的改进版版本2.0(V2.0)是要在1997年的11月完成的。
但是，美国国防部办公室要求软件工程研究所（SEI）延迟发放公布CMM版本2.0，直至他们完成另一个更为紧迫的项目-CMMI。
CMMI(Capability Maturity Model Integration能力成熟度模型集成)，是美国国防部的一个设想。
他们希望把所有现存的与将被发展出来的各种能力成熟度模型，集成到一个框架中去。
这个框架用于解决两个问题：第一，软件获取办法的改革；第二，从集成产品与过程发展的角度出发，建立一种包含健全的系统开发原则的过程改进。
CMM为软件企业的过程能力提供了一个阶梯式的改进框架，它基于过去所有软件工程过程改进的成果，吸取了以往软件工程的经验教训，提供了一个基于过程改进的框架；它指明了一个软件组织在软件开发方面需要管理哪些主要工作、这些工作之间的关系、以及以怎样的先后次序，一步一步的做好这些工作而使软件组织走向成熟。
一、CMM的诞生 信息时代，软件质量的重要性越来越为人们所认识。
软件是产品、是装备、是工具，其质量使得顾客满意，是产品市场开拓、事业得以发展的关键。
而软件工程领域在1992年至1997年取得了前所未有的进展，其成果超过软件工程领域过去15年来的成就总和。
软件管理工程引起广泛注意源于20世纪70年代中期。
当时美国国防部曾立题专门研究软件项目做不好的原因，发现70%的项目是因为管理不善而引起，而并不是因为技术实力不够，进而得出一个结论，即管理是影响软件研发项目全局的因素，而技术只影响局部。
到了20世纪90年代中期，软件管理工程不善的问题仍然存在，大约只有10%的项目能够在预定的费用和进度下交付。
软件项目失败的主要原因有：需求定义不明确；缺乏一个好的软件开发过程；没有一个统一领导的产品研发小组；子合同管理不严格；没有经常注意改善软件过程；对软件构架很不重视；软件界面定义不善且缺乏合适的控制；软件升级暴露了硬件的缺点；关心创新而不关心费用和风险；军用标准太少且不够完善等等。
在关系到软件项目成功与否的众多因素中，软件度量、工作量估计、项目规划、进展控制、需求变化和风险管理等都是与工程管理直接相关的因素。
由此可见，软件管理工程的意义至关重要。
软件管理工程和其它工程管理相比有其特殊性。
首先，软件是知识产品，进度和质量都难以度量，生产效率也难以保证。
其次，软件系统复杂程度也是超乎想象的。
因为软件复杂和难以度量，软件管理工程的发展还很不成熟。
软件管理工程的发展，在经历了从70年代开始以结构化分析与设计、结构化评审、结构化程序设计以及结构化测试为特征的结构化生产时代，到90年代中期，以CMM模型的成熟模型和日益为市场接受为标志，已经进入以过程成熟模型CMM、个体软件过程PSP和群组软件过程TSP为标志的以过程为中心的时代，而软件发展第三个时代，及软件工业化生产时代，从90年代中期软件过程技术的成熟和面向对象技术、构件技术的发展为基础，已经渐露端倪，估计到2005年，可以实现真正的软件工业化生产，这个趋势应该引起软件企业界和有关部门的高度重视，及早采取措施，跟上世界软件发展的脚步。
软件生产转向以改善软件过程为中心，是世界各国软件产业或迟或早都要走的道路。
软件过程改善是当前软件管...
在软件工程中什么是里程碑
里程碑就是项目开发过程中一个重要的阶段点，这个阶段点之后将意味着项目的开发进入了另一个层面，比如需求分析结束概要设计开始前就应该有一个里程碑，表示需求阶段结束，将进入另外一个过程，这两个过程之间只有文档的交互就可以了，而不一定非要有人员的交互。
阶段就是项目开发过程中明显可以区分的任务分解，需求收集和需求分析就可以划分为两个阶段，但都数据需求这个大阶段中的，但需求收集和需求分析之间就不能存在一个里程碑，因为你没有完成一个完整的过程。
需求收集和需求分析阶段至少有客户是必须始终参与的，而概要设计阶段一般就不需要客户的参与了。
软件工程都涉及到那些概念和名词,它们的关系如何？如何解释。
名词解释题汇总：1.软件是能够完成预定功能和性能，并对相应数据进行加工的程序和描述程序及其操作的文档。
2.信息隐藏模块中的软件设计决策信息封装起来的技术，只知道它的功能以及对外的接口，而不知它的内部细节3.对象对象是现实世界中个体或事物的抽象表示，是其属性和相关操作的封4.软件可维护性 指软件被理解、改正、调整和改进的难易程度。
5.原型是目标软件系统的一个可操作模型，它实现了目标软件系统的某些重6.软件生存周期软件产品从形成概念开始，经过开发、运行（使用）和维护直到退役的全过程称为软件生存周期，包括软件定义、开发、使用和维护三部分。
7.白盒测试是已知产品内部工作过程，通过测试检验产品内部动作是否按照产品规格说明的规定正常进行8.预防性维护是为了进一步改善软件系统的可维护性和可靠性，并为以后的改进奠定基础。
9.构件图描述软件实现系统中各组成部件以及它们之间的依赖关系。
10.场景从单个执行者的角度观察目标软件系统的功能和外部行为。
11.计算机辅助软件工程（CASE） 将若干工具集成起来，与软件工程数据库和计算机系统构成一个支持软件开发的系统12.编程风格是在不影响性能的前提下，有效地编排和组织程序以提高可读性和可维性。
13.黑盒测试方法是已知产品应该具有的功能，通过测试检验每个功能是否都能正常使用; 14.实体—关系图描述系统所有数据对象的组成和属性，描述数据对象之间关系的图形语言。
15.软件维护的副作用指由于维护或在维护过程中其他一些不期望的行为引入的错误, 16.软件生存周期软件产品从形成概念开始，经过开发、运行（使用）和维护直到退役的全过程称为软件生存周期，包括软件定义、开发、使用和维护三部分。
17.结构化程序设计是一种程序设计技术，采用自顶向下逐步求精的设计方法和单入口单出口的控制构件。
18.软件过程（software process） 软件开发人员为开发和维护软件及相关产品所实施的一系列步骤，这些步骤涉及方法、工具及人的组织和行为。
19.综合测试是组装软件的系统测试技术，按设计要求把通过单元测试的各个模块组装在一起之后，进行综合测试以便发现与接口有关的各种错误。
20.过程抽象把完成一个特定功能的动作序列抽象为一个过程名和参数表，通过指定过程名和实际参数调用此过程; 21.水平原型是指仅仅模拟目标软件系统某一层面（通常是用户界面层）的原型。
22CASE工具是一些软件系统，支持软件过程的常规活动，如编辑设计图表、检查图表的连贯性、跟踪已经运行的程序测试等。
在软件工程中什么是需求分析？
一。
确定对系统的综合要求1. 功能需求这方面的需求指定系统必须提供的服务。
通过需求分析应该划分出系统必须完成的所有功能。
2. 性能需求性能需求指定系统必须满足的定时约束或容量约束，通常包括速度（响应时间）、信息量速率、主存容量、磁盘容量、安全性等方面的需求。
3. 可靠性和可用性需求可靠性需求定量地指定系统的可靠性。
可用性与可靠性密切相关，它量化了用户可以使用系统的程度。
4. 出错处理需求这类需求说明系统对环境错误应该怎样响应。
例如，如果它接收到从另一个系统发来的违反协议格式的消息，应该做什么？注意，上述这类错误并不是由该应用系统本身造成的。
5. 接口需求接口需求描述应用系统与它的环境通信的格式。
常见的接口需求有：用户接口需求；硬件接口需求；软件接口需求；通信接口需求。
6. 约束设计约束或实现约束描述在设计或实现应用系统时应遵守的限制条件。
在需求分析阶段提出这类需求，并不是要取代设计（或实现）过程，只是说明用户或环境强加给项目的限制条件。
常见的约束有：精度；工具和语言约束；设计约束；应该使用的标准；应该使用的硬件平台。
7. 逆向需求逆向需求说明软件系统不应该做什么。
理论上有无限多个逆向需求，我们应该仅选取能澄清真实需求且可消除可能发生的误解的那些逆向需求。
8. 将来可能提出的要求应该明确地列出那些虽然不属于当前系统开发范畴，但是据分析将来很可能会提出来的要求。
注意：举例让学生理解：这样做的目的是，在设计过程中对系统将来可能的扩充和修改预做准备，以便一旦确实需要时能比较容易地进行这种扩充和修改。
二 。
分析系统的数据要求任何一个软件系统本质上都是信息处理系统，系统必须处理的信息和系统应该产生的信息在很大程度上决定了系统的面貌，对软件设计有深远影响，因此，必须分析系统的数据要求，这是软件需求分析的一个重要任务。
分析系统的数据要求通常采用建立数据模型的方法（举例）。
三。
导出系统的逻辑模型综合上述两项分析的结果可以导出系统的详细的逻辑模型，通常用数据流图、实体-联系图、状态转换图、数据字典和主要的处理算法描述这个逻辑模型。
四。
修正系统开发计划根据在分析过程中获得的对系统的更深入更具体的了解，可以比较准确地估计系统的成本和进度，修正以前制定的开发计划。
在软件工程中“用例”和“用例图”有什么区别是什么？
1、用例是对包括变量在内的一组动作序列的描述，系统执行这些动作，并产生传递特定参与者的价值的可观察结果。
这是UML对用例的正式定义，对我们初学者可能有点难懂。
我们可以这样去理解，用例是参与者想要系统做的事情。
对于对用例的命名，我们可以给用例取一个简单、描述性的名称，一般为带有动作性的词。
用例在画图中用椭圆来表示，椭圆下面附上用例的名称。
2、用例图是指由参与者（Actor）、用例（Use Case）以及它们之间的关系构成的用于描述系统功能的静态视图。
用例图（User Case）是被称为参与者的外部用户所能观察到的系统功能的模型图，呈现了一些参与者和一些用例，以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模。
用例图由参与者参与者（Actor）、用例（Use Case）、系统边界、箭头组成，用画图的方法来完成。
转载请注明出处51数据库 » 软件工程中的扩展关系
