必威体育Betway必威体育官网
当前位置:首页 > IT技术

系统架构设计师:软件开发基础知识

时间:2019-08-11 02:41:03来源:IT技术作者:seo实验室小编阅读:61次「手机版」
 

系统架构设计师

本课题是为了解决 “软件危机”问题。

软件开发方法是软件开发的方法学,通过软件开发方法研究,提高软件的质量、降低软件的成本。

软件开发方法包括:软件生命周期、软件开发模型、软件重用技术逆向工程及形式化开发方法

一、软件生命周期

    软件产品从形成概念开始,经过开发、使用和维护,直到最后退役的全过程成为软件生存周期。

    软件生存周期的提出是为了更好地管理、维护和升级软件,其中更大的意义在于管理软件开发的步骤和方法。

  GB8566-88中,软件生命周期划分为8个阶段:

1.可行性研究与计划确定开发此软件的必要性、目标、范围、风险、成本,输出《可行性研究报告》和《软件开发计划》。

2.需求分析。有了目标和范围,需要对需求进行细致的分析,确定软件是什么样的。

3.概要设计确定了软件的技术蓝图,把需求分析的结果转换为技术层面的设计方案系统架构、子系统间的关系、接口规约、数据库模型、编码规范等。

4.详细设计在概要设计的基础上,进行细化。有一些小工程可能省略这个阶段。

5.实现。编码和单元测试。

6.集成测试也叫组装测试。

7.确认测试。是否与需求一致?是否达成预期的目标?

8.使用和维护。使用过程中,业务需求会变化、环境会变化,新的bug会出现,因此,需要不断维护。

二、软件开发模型

1. 瀑布模型

瀑布模型认为软件开发是一个阶段化的精确的过程,阶段间有明显的界限和反馈,一个阶段结束会有固定的文档或者代码输入下一个阶段。因此,瀑布模型是面向文档的软件开发模型。

瀑布V模型是瀑布模型的一种变体。工程师们发现,缺陷无法避免,如何阶段都会在软件中引入缺陷,最后的测试也无法保证100%正确,只能争取在交付之前发现更多的缺陷。V模型就是增强了测试的瀑布模型:

瀑布模型是经典的开发模型,具有以下缺点:

一是需求分析阶段是一切活动的基础,设计、实现和验证活动都是从需求分析阶段的结果导出。

二是难以适应变化,阶段之间有强依赖性,后期有变化,前面的所有阶段都需要修改。

 三是所有阶段都结束之后,才有交付产品。需要很长时间才会有结果。

瀑布模型是文档驱动的,除了制造软件产品外,也将产生大堆的文档,大部分的文档对客户是没有意义的,整理编写这些文档需要花费大量的人力物力,所以瀑布模型是 重载过程

2.演化模型

 演化模型是做若干次瀑布模型的迭代,完成一个瀑布周期,又开始另外一个瀑布周期,不断演化、完善。根据不同迭代特点,分为螺旋模型、增量模型和原型法开发。

2.1 螺旋模型

每一个周期包括:需求定义、风险分析、工程实现和评审。

      风险分析:风险识别、风险分析和风险控制。

有了风险分析环节,螺旋模型适用于特别庞大而复杂、具有高风险的系统,软件交付时间长。

螺旋模型支持用户需求的动态变化,为用户参与软件开发的所有关键决策提供了方便,有助于提高软件的适应能力,并且为项目管理人员及时调整管理决策提供了便利,从而降低了软件开发的风险。

使用螺旋模型,需要具备相当丰富的风险评估经验和专业知识。

2.2 增量模型

适用于技术架构成熟、风险较低,增量模型缩短初始版本的交付周期,提高用户对系统的可见度。

增量模型有两种策略:

一是增量发布方法。把软件划分为若干不同版本,每一个版本都是完整的系统,后一个版本在前一个版本的基础上进行开发,扩充前一个版本的功能。第一版本往往是系统的核心功能。

二是原型法。原型法的每一次迭代都经过一次完整的生命周期,原型法用于加强用户参与度,提高需求的明确性。一般情况下,后期会抛弃最开始的原型,重新实现完整的系统。

3. 构建组装模型

构件是独立的、自包容的,构件之间通过接口相互协作。

    优缺点

构件的自包容性让系统的扩展变得容易;构件可以重用;可以对软件进行不同颗粒度划分,任务分工清晰,可以并行开发;

构件设计需要经验丰富的架构设计师;性能可能是一个问题;需要熟悉构件,增加了学习成本;第三方构件难以控制,最终会影响软件的质量。

三、统一过程

统一过程(UP)是由Rational公司开发的一种迭代的软件过程,提供了完整的开发过程解决方案,可以降低风险,可以适应各种规模的团队和系统。

横轴是时间主线,纵轴是不同阶段的工作流程,每一个阶段都是相互交叠配合的,但是每一个阶段都是侧重点:

初始阶段重点是业务建模,细化阶段重点是分析设计,构建阶段重点是构建和测试,交付阶段重点是重构、修改、测试和部署。

纵轴是9个核心工作流:业务建模、需求、分析设计、实施、测试、部署、配置和变更管理、项目管理、环境。环境比较难以理解:在软件开发中,需要为各种工作准备相应的工作环境,在工作环境中需要包含必需的工具、活动的指南、活动的流程规范、工作产品的模板、基本的开发设施等。实际的公司很多时候是忽略了环境的,放羊式的管理,除了收获羊毛,啥也收获不了。

UP是特点鲜明的开发模型:

它是一个迭代的二维开发模型;采用不同迭代模式UP可以演变为演化模式或者增量模型;它容易控制软件开发的风险;未经裁剪的UP是一个重载过程。有人也称UP是一个以架构为中心的开发模型。

四、敏捷方法

2001年2月在美国犹他州17位“无政府主义者”共同发表了《敏捷软件开发宣言》,指出:

尽早地、持续地向客户交付有价值的软件;

拥抱变化,即使在开发的后期;

经常交付可工作的软件;

业务人员和开发者紧密合作;

围绕士气高昂的团队进行开发,提供适宜的环境,足够的信任;

面对面沟通;

可以工作的软件是进度首要的度量方式;

可持续地开发;

不断追求优秀的技术和良好的设计;

要简单,尽可能减少工作量;

最好的架构、需求和设计都来自于一个自我组织的团队;

团队要定期总结如何才能更有效率,相应地调整。

以上就是敏捷开发方法,其中极限编程(XP)比较普遍。

XP是一种轻量、高效、低风险、柔性、可预测、科学而且充满乐趣的软件开发方式。

XP 的四大价值观:

    一是沟通。比如结对编程。

二是简单。够用即好。

三是反馈。客户、管理层、开发团队,通过反馈达成信息的流转。

四是勇气。有勇气面对快速开发,面对可能的重新开发。

XP的十二个最佳实践:

1)计划游戏。快速计划,用户故事。

2)小型发布。持续集成、小步快走。

3)隐喻。寻求共识、发明共享语汇、描述架构。

4)简单设计。设计不应该在编码之前一次性完成。

5)测试先行。不能忽略测试。

6)重构。要有重构的勇气。

7)结对编程。强调人文主义,协作顺畅、知识交流和共享、团队稳定。

8)集体代码所有制。代码属于所有人,公开、民主。

9)持续集成。

10)每周工作40小时。

11)现场客户。把客户请到现场。

12)编码标准。确保代码清晰、便于交流。

除了XP,敏捷开发方法还有特征驱动开发、Scrum、水晶方法等。

五、基于架构的软件设计

 ABSD是一种架构驱动方法,它有三个基础:

一是功能的分解。   

二是选择架构风格实现质量和业务需求。

三是软件模板的使用。

六、需求分析

开发软件系统最为困难的部分就是准确说明开发什么。最为困难的概念性工作便是编写出详细的技术需求,这包括面向用户、面向机器和其他软件系统的接口。同时,这也是一旦出错,将会该系统带来极大困难的部分,并且以后再对它进行修改也极为困难。

软件需求可以分为几个层次:

1.业务需求(business requirements)。反映组织结构或者客户对系统、产品高层次的目标要求,它们在项目视图与范围文档中给予说明。

2.用户需求(user requirements)。描述用户使用产品必须完成的任务,在用例文档或者方案场景中给予说明。

3.功能需求(functional requirements)。描述开发人员必须实现的软件功能,使得用户能完成他们的任务,从而满足业务需求。

4.非功能需求(none-functional requirements)。描述系统展现给用户的行为和执行的操作等。包括:产品必须遵循的标准、规范和合约;外部界面的具体细节;性能要求;设计或者实现的约束条件;质量属性。

软件需求说明书(SRS)是需求分析阶段的成果,不仅是系统测试和用户文档的基础,也是所有子系统项目规划、设计、编码的集成。它应该尽可能完整地描述系统预期的外部行为和用户可视化行为。除了设计和实现上的限制,软件需求说明书不应该包括设计、构造、测试或工程管理的细节。

可以使用一下三种方法编写软件需求规格说明:

1.用好的结构化和自然语言编写文本型文档。

2.建立图形化模型,这些模型可以描绘转换过程、系统状态和它们之间的编号、数据关系、逻辑流或对象类和它们的关系。

3.编写形式化规格说明,这可以通过使用数学上精确的形式化逻辑语言来定义需求。

七、结构化分析方法

结构化分析方法(SA)是一种预先严格定义需求的方法,强调分析对象的数据流,其指导思想是自顶向下逐层分解。

八、聚合和耦合

模块的独立程度有两个定性标准度量:聚合和耦合。

聚合衡量模块内部各元素结合的紧密程度;

耦合度量不同模块间相互依赖的程度;

聚合程度从低到高排列:偶然聚合——逻辑聚合——过程聚合——时间聚合——通信聚合——顺序聚合——功能聚合

耦合程度从低到高排列:数据耦合、控制耦合、公共耦合和内容耦合。

九、用例模型

用例模型描述了各种参与者(人和其他系统)和要分析的系统之间的主要交互;在系统的上下文环境中,显示系统和外部参与者之间的边界,并描述系统和参与者的关键交互。用例建模可以描述利益相关者所看到的系统行为。

获取需求的沟通和交流技巧:用户访谈;用户调查和联合讨论会议。

十、RAD(快速应用开发)模型

RAD模型是一个增量型的软件开发过程模型,强调极短的开发周期。RAD模型是瀑布模型的一个高速变种,通过大量使用可复用的构件,采用基于构件的构造方法赢得快速开发。如果需求理解得好,而且项目范围明确,利用这种模型可以很快创建出功能完善的信息系统。其流程从业务建模开始,随后是数据建模、过程建模、应用生成、测试及反馈。各个活动周期完成任务如下:

1.业务建模:以什么信息驱动业务过程运转?要生成什么信息?谁生成它?信息流的去向是哪里?由谁处理?可以用数据流图

2.数据建模:为支持业务过程的数据流,找数据对象集合,定义数据对象属性,与其他数据对象的关系构成数据模型,可以用E--R图

3.过程建模:使数据对象在信息流中完成各业务功能。创建过程以描述数据对象的增加、修改、删除、查找,细化数据流图。

4.应用程序生成:编写处理程序,重用已有构件或创建新的可重用构件,逐步搭建整个应用系统。

5.测试与交付:大量构件重用,重点不在于构件的测试,重点在系统测试和集成测试,但是新创建的构件还是需要测试的。

缺点:1.模块或者功能点必须能够模块化;2.需求必须快速开发出来,需要客户高度配合;3.如果需要较高互操作性,风险比较高;4.构件之间需要通信,通信会成为系统性能瓶颈。

十一、基于构件的开发模型

基于构件的开发模型是利用模块化方法,将整个系统模块化,并在一定构件模型的支持下,复用构件库中的一个或者多个软件构件,通过组合手段高效率、高质量地构造应用软件系统的过程。基于构件的开发模型融合了螺旋模型的许多特征,本质上是演化的,开发过程是迭代的。基于构件的开发模型由需求分析和定义、体系结构设计、构件库建立、应用软件构建、测试和发布5个阶段。

基于构件的开发方法使得软件开发不再一切从头开始,开发的过程就是构件组装的过程,维护的过程就是构件升级、替换和扩充的过程,其优点是构件组装模型导致了软件的重用,提高了软件开发的效率,降低了费用,提高了可维护性。

构件通用的标准,组装标准、通信标准,性能可能是瓶颈,需要精干、有经验的分析人员和开发人员。构件库的质量影响着产品质量

相关阅读

中国软件开发的现状

【回复“1024”,

软件开发文档模板

目录 1. 范围 2. 总体要求 2.1 总体功能要求 2.2 软件开发平台要求 2.3 软件项目的开发实施过程管理要求 2.3.1 软件项目实

软件开发人员的职业发展规划

几年来,随着公司每年的“校园行”、“金种子”等招聘项目的开展,越来越多的新鲜血液加入到我们这个大家庭。如何引导我们年青的技术

类 QQ IM 通讯软件开发实战

课程简介用习惯了微信的你,还记得当初的 QQ 吗?曾几何时,你是否也在梦想自己也能写出一个像 QQ 一样牛气的即时通讯软件?即使你不曾有

软件开发中什么是CI/CD

持续集成(Continuous integration)是一种软件开发实践,每次集成都通过自动化的构建(包括编译,发布,自动化测试)来验证,从而尽早地发现集

分享到:

栏目导航

推荐阅读

热门阅读