软件开发
APP开发公司
手机软件
苹果IOS开发
android安卓开发
会员系统
三级分销
网站建设
商城网站
小程序开发
微信公众号开发

软件工程

频道:APP开发 标签:软件软件工程软件制作广州软件公司 时间:2019年03月07日 浏览:43次 评论:0条
1.2软件的特性:
①软件是设计开发的,而不是传统意义上生产制造的;
②软件不会“磨损”;
③虽然整个工业向着基于构件的构造模式发展,然而大多数软件仍是根据实际的顾客需求定制的
1.4.1遗留软件的质量
 
2.1软件工程
软件工程是:将系统化、规范的、可量化的方法应用于软件的开发、运行和维护,即将工程化的方法应用于软件。

2.2过程框架
沟通:与客户之间大量的交流和协作,还包括需求获取以及其他相关活动
策划:为后续的软件工程工作制定计划
建模:包括创建模型和设计两方面
构建:包括编码和测试
部署:软件交付到用户,用户对其惊醒评测并给出反馈意见
在通用的过程框架中,建模活动包括分析和设计两个动作。
2.3能力成熟度模型集成(CMMI
2.6.1个人软件过程(PSG
个人软件过程强调产品以及产品质量的个人测量。
2.6.2团队软件过程(TSP
TSP的目标是建立一个能够“自我管理”的项目团队,团队能自我组织惊醒高质量的软件开发。
 
3.2瀑布模型
瀑布模型,又被称为经典生命周期,它提出了一个系统的、顺序的软件开发方法,从用户需求规格说明开始,通过策划、建模、构建。和部署的过程,最终提供一个完整的软件并提供持续的技术支持。
v-mod瀑布模型的改进。
3.3增量过程模型
①增量模型以迭代的方式运用瀑布模型。
②运用增量模型的时候,第一个增量往往是核心产品。
RAD模型
快速应用程序开发(RAD是一种侧重于短暂的开发周期的增量软件过程模型。
3.4.1使用原型开发的情况
①客户提出了软件的一些基本功能,但是没有详细的定义输入、处理和输出需求;
②开发人员可能对算法的效率、操作系统的兼容性和人机交互的形式等情况不确定。
当需求很模糊的时候,原型开发范型帮助软件工程师和客户更好地理解究竟需要做什么。
3.4.2螺旋模型
螺旋模型是一种风险驱动型过程模型的生成器,对于软件集中的系统,它可以指导多个共利益者的协同工作。
它有两个显著的特点
①采用循环的方式逐步加深系统定义和实现的深度,同时降低风险;
②确定一系列里程碑,确保共利益者都支持可行的和令人满意的系统解决方案。
3.6统一过程
“用例驱动,以架构为核心,迭代并且增量”
它建立了一种迭代的、增量的过程流,提供一种演进的特性。
 
4.1敏捷是什么
敏捷不仅仅是有效地响应变化,它还鼓励能够在组员之间、技术和商务人员之间、软件工程师和经理之间进行更便利沟通的团队结构和协作态度,强调可运行软件的快速交付而不是中间产品,将客户作为开发组成员以消除持续、普遍存在于多数软件项目中的“区分你我”的态度,意识到在不确定的世界里计划是有局限性的,它必须是可以调整的。
4.3敏捷过程模型
4.3.1极限模型

 
5.4建模实践
在软件工程中,要创建两类模型:分析模型和设计模型。
分析模型通过以下三个不同域描述软件来表达客户的需求:信息域、功能域、行为域。
设计模型表述了可以帮助开发者高校开发软件的特征:架构、用户界面、构建细节。
5.4.1分析建模原则
①必须描述并理解问题的信息域;
②必须确定软件所要实现的功能;
③必须描述软件的行为;
④描述信息、功能和行为的模型必须以一种能揭示分层细节的方式分解开来;
⑤分析人物应该从本质信息转向实现细节。
5.4.2设计建模的原则
①设计科追溯到分析模型;
②经常关注特建系统的构造;
③数据设计与功能设计同等重要;
④必须设计接口;
⑤用户界面设计必须符合最终永华要求;
⑥功能独立的构件级设计;
⑦构件之间以及构件与外部环境之间松散耦合;
⑧设计表述应该做到尽可能易于理解;
⑨设计应该迭代式进行,每一次迭代,设计者都应该尽力简化。
5.5构造实践
构建活动包括一系列编码和测试任务。
5.5.2测试原则
软件测试的目标:
①测试是一个以查找程序错误为目的的程序执行过程;
②一个好的测试用例能最大限度地找到尚未发现的错误;
③一个成功的测试能找到那些尚未发现的错误。
5.6部署
部署活动包括三个动作:交付、支持和反馈。
 
6.5.2 UML系统建模
 
7.1连接设计和构造的桥梁
理解问题的需求是软件工程师所面对的最困难的任务之一。
需求工程是一个软件工程动作,开始于沟通并持续到建模。创建用户的信息、功能、行为模型。
7.2.2导出
为什么导出需求这么困难?
①范围问题;系统的边界不清楚,或客户/用户的说明带有多余的技术细节
②理解问题;客户/用户并不完全确定需要什么,与系统工程师在要求沟通上有问题
③易变问题。需求随时间变化
7.2.3精化
精化阶段需求工程活动集中于开发一个精确的技术模型,用以说明软件的功能、特征和约束。
7.4.2质量功能部署(QFD
质量功能部署是一种将客户要求转化成软件技术需求的技术。
有三类需求:正常需求、期望需求、令人兴奋的需求。
7.6构建分析模型(细看)
8.3数据建模的概念

8.5基于场景建模
8.6.3控制规格说明(CSPEC
CSPEC使用两种不同的方式表现系统的行为。它包含一个状态图
8.6.4处理规格说明(PSPEC
PSPEC用于描述出现在求精过程中最终层次的所有流模型的处理。
8..8生成行为模型
状态度。行为模型的组成之一
顺序图。第二种表现行为的方式
 
9.1软件工程馆衡中搞得设计
软件设计在软件工程过程中处于技术核心,并且和它的应用与所用的软件过程模型无关。
设计表示法和设计方法:
①数据/类设计,将分析类模型转化为设计类的实现以及软件实现所要求的数据结构。
②体系结构设计,定义了软件的主要结构元素之间的联系,可用于达到系统所定义徐区域的体系结构风格和设计模式以及影响体系结构实现方式的约束。
③接口OA系统设计,描述了软件和协作系统之间、软件和使用人员之间是如何通信的。
④构件级设计,将软件体系结构的结构元素变换为对软件构件的过程性描述。
软件设计的重要性可以用一个词来表达---质量
9.3设计概念
设计四要素:数据、体系架构、结构。构建。
9.4.5部署级设计元素
部署级设计元素指明软件功能和子系统将如何在支持软件的物理计算机环境内分布。
9.5基于模式的软件设计
 
10.1软件体系结构
一个程序和计算系统软件体系结构是指系统的一个或者多个结构。结构中包括软件的构件,构件的外部可见属性以及它们之间的相互关系。
体系结构之所以关键的三个原因:
①软件体系结构的表示有助于对计算机系统开发感兴趣的各方开展交流;
②体系结构突出了早期设计决策,这些决策对随后的所有软件工程工作有深远的影响,同时对系统作为一个可运行实体的最后成功有着重要作用。
③体系结构“构建了一个相对小的,易于理解的模型,该模型描述了系统如何构成以及其构件如何一起工作”。
10.3.1体系结构风格的简单分类
以数据为中心的体系结构
数据流体系结构
调用和返回体系结构
面向对象体系结构
层次体系结构
10.6映射数据流到软件体系结构
 
11.2设计基于类的构件
开关原则(OCP):模块应该对外延具有开放性,对修改具有封闭性。
Liskov替换原则(LSP):子类可以替换它们的基类。
依赖倒置原则(DIP):依赖于抽象,而非具体实现。
接口分离原则(ISP):多个用户专用接口比一个通用接口要好。
发布复用等价性原则(REP):复用的粒度就是发布的粒度。
共同封装原则(CCP):一同变更的类应该合在一起。
共同复用原则(CRP):不能一起复用的类不能被分到一组。
11.2.3内聚性
把内聚性描述为构件的专诚性。
11.2.4耦合性
耦合是类之间彼此联系程度的一种定性度量。
 
12.1黄金规则
①置用户于控制之下;
②减少用户的记忆负担;
③爆出界面的一致。
 
13.1.1验证与确认
验证是指确保软件正确地实现某一特定功能的一系列活动。
确认则是指的是确保开发的软件可追溯到用户需求的另外一系列活动。
13.3传统软件的测试策略
13.3.1单元测试
13.3.2集成测试
自顶向下  优点:不需要测试驱动程序,能够在测试阶段的早期实验并验证系统的主要功能,
               而且能在早期发现上层模板的接口错误。
          缺点:需要存根程序,可能遇到与此相联系的测试困难,低层关键模板中的错误
               发现较晚,而且用这种方法早期不能充分展开人力。
自底向上  优点:由于驱动模块模拟了所有调用参数,测试模式返回结果不影响驱动模式,
                生成测试数据也没有困难,如果关键模块式在结构图的底部,自底向上测
                试是有优越性的,且自底向上的组装测试不必开发脏模块。
          缺点:当最后一个模块尚未测试时,还没有呈现出被测试软件系统的雏形。
13.5.3 α测试与β测试
α测试是由最终用户在开发者的场所进行。软件在自然环境下使用,开发者站在典型用户的后面观看,并记录错误和使用问题。α测试在受控的环境下进行。
β测试是在最终用户场所执行。开发者通常不在场。因此,β测试是在不为开发者控制的环境下软件的“现场”应用。最终用户记录测试过程中遇见的所有问题,并将其定期地报告给开发者。
 
14.1软件测试基础
软件可测试性就是(计算机程序)能够被测试的容易程度。
14.2白盒测试与黑盒测试
白盒测试:了解产品的内部运行情况,可以执行测试以确保”所有齿轮吻合“--即内部操作依据规格说明执行,而且对所有的内部构件已进行了充分测试。
黑盒测试:了解已设计产品所完成的指定功能,可以执行测试以显示每个功能是可操作的,同时,查找每个功能中的错误。
14.3白盒测试
软件工程师设计的测试用例可以:
①保证一个模块中的所有独立路径至少被执行一次;
②对所有的逻辑值均需测试真和假;
③在上下边界及可操作的范围内执行所有的循环;
④检验内部数据结构以确保其有效性。
14.6黑盒测试
黑盒测试可用的用例集:
①能够减少达到合理测试所需的附加测试用例数;
②能够告知某些错误类型是否存在,而不是仅仅知道与特定测试相关的错误。

◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。