【系统架构设计师】九、软件工程(需求工程|系统分析与设计|DFD|DD|高内聚低耦合)

目录

四、需求工程

4.1 软件需求层次

4.2 软件需求

4.3 需求获取

4.4 需求分析

4.5 需求定义

4.6 需求确认与验证

4.7 需求管理

4.7.1 变跟控制

4.7.2 需求追踪

五、系统分析与设计

5.1  结构化方法

5.1.1 结构化需求分析

5.1.2 数据流图DFD

5.1.3 数据字典DD

5.2 结构化设计

5.2.1 高内聚

5.2.2 低耦合

5.3 结构化编程

5.4 人机界面设计

5.4.1 置于用户控制之下

5.4.2 减少用户的记忆负担

5.4.3 保持界面的一致性

5.5 流程表示工具

相关推荐

历年真题联系


四、需求工程

        软件需求目前并没有统一的定义,但都包含以下几方面的内容。

        (1)用户解决问题或达到目标所需条件或权能(Capability)。

        (2)系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或权能

        (3)一种反映上面(1)或(2)所述条件或权能的文档说明。它包括功能性需求及非功能性需求,非功能性需求对设计和实现提出了限制,比如性能要求、质量标准或者设计限制。

4.1 软件需求层次

        软件需求包括3个不同的层次:业务需求、用户需求和功能需求(也包括非功能需求)。 

        业务需求:反映企业或客户对系统高层次的目标要求,通常来自项目投资人客户、市场营销部门或产品策划部门。通过业务需求可以确定项目视图和范围。

        用户需求:描述的是用户的具体目标,或用户要求系统必须能完成的任务。即描述了用户能使用系统来做什么。通常采取用户访谈和问卷调查等方式,对用户使用的场景进行整理,从而建立用户需求。

        系统需求:从系统的角度来说明软件的需求,包括功能需求、非功能需求和设计约束等。
                 (1)功能需求:也称为行为需求,规定了开发人员必须在系统中实现的软件功能用户利用这些功能来完成任务,满足业务需要。
                (2)非功能需求:指系统必须具备的属性或品质,又可以细分为软件质量属性(如可维护性、可靠性、效率等)和其他非功能需求。
                (3)设计约束:也称为限制条件或补充规约,通常是对系统的一些约束说明,例如必须采用国有自主知识产权的数据库系统,必须运行在UNIX操作系统之下等。

4.2 软件需求

        需求工程是指应用已证实有效的原理、方法,通过合适的工具和记号,系统地描述待开发系统及其行为特征和相关约束。 软件需求分为需求开发需求管理两大过程,如下:

4.3 需求获取

        需求获取是一个确定和理解不同的项目千系人的需求和约束的过程。

        常见的需求获取法包括:
                (1)用户面谈:1对1-3,有代表性的用户。其形式包括结构化和非结构化两种。。
                (2)问卷调查:用户多,无法--访谈。
                (3)采样:从种群中系统地选出有代表性的样本集的过程。
                (4)情节串联板:一系列图片,通过这些图片来讲故事。
                (5)联合需求计划(JRP):通过联合各个关键用户代表、系统分析师、开发团队代表一起,通过有组织的会议来讨论需求。
                (6)需求记录技术:任务卡片、场景说明、用户故事、Volere白卡。

4.4 需求分析

        一个好的需求应该具有无二义性、完整性、一致性、可测试性确定性、可跟踪性、正确性、必要性等特性,因此,需要分析人员把杂乱无章的用户要求和期望转化为用户需求,这就是需求分析的工作。

        需求分析的任务:

        (1)绘制系统上下文范围关系图

        (2)创建用户界面原型

        (3)分析需求的可行性

        (4)确定需求的优先级

        (5)为需求建立模型

        (6)创建数据字典

        (7)使用QFD(质量功能部署)

4.5 需求定义

        需求定义(软件需求规格说明书SRS):是需求开发活动的产物,编制该文档的目的是使项目干系人与开发团队对系统的初始规定有一个共同的理解,使之成为整个开发工作的基础。SRS是软件开发过程中最重要的文档之一,对于任何规模和性质的软件项目都不应该缺少。

        需求定义方法:

        (1)严格定义也称为预先定义,需求的严格定义建立在以下的基本假设之上:

                a.所有需求都能够被预先定义
                b.开发人员与用户之间能够准确而清晰地交流。
                c.采用图形(或文字)可以充分体现最终系统。

        (2)原型方法,迭代的循环型开发方式,需要注意的问题

                a.并非所有的需求都能在系统开发前被准确地说明。
                b.项目于系人之间通常都存在交流上的困难,原型提供了克该服困难的一个手段。

                特点:需要实际的、可供用户参与的系统模型。有合适的系统开发环境。反复是完全需要和值得提倡的,需求一旦确定就应遵从严格的方法。

4.6 需求确认与验证

        需求验证,也称为需求确认,目的是与用户一起确认需求无误,对需求规格说明书SAS进行评审和测试,包括两个步骤:

                需求评审:正式评审和非正式评审。
                需求测试:设计概念测试用例。

        需求验证通过后,要请用户签字确认,作为验收标准之一,此时,这个需求规格说明书就是需求基线 (Baseline),不可以再随意更新,如果需要更改必须走需求变更流程。这个基线在客户和开发者之间构筑了计划产品功能需求和非功能需求的一个约定 (Agreement)。需求约定是需求开发和需求管理之间的桥梁

4.7 需求管理

        需求管理是一个对系统需求变更、了解和控制的过程,包括变更控制、版本控制、需求跟踪等活动。

4.7.1 变跟控制

        变更控制过程用来跟踪已建议变更的状态,使已建议的变更确保不会丢失或疏忽。一旦确
定了需求基线,应该使所有已建议的变更都遵循变更控制过程

        需求变更和风险:主要关心需求变更过程中的需求风险管理,带有风险的做法有:无足够用户参与、忽略了用户分类、用户需求的不断增加、模棱两可的需求、不必要的特性、过于精简的SRS、不准确的估算。

        变更产生的原因:外部环境的变化、需求和设计做的不够完整、新技术的出现、公司机构重组造成业务流程的变化。

        变更控制委员会CCB:也称为配置控制委员会,CCB 由项目所涉及的多方成员共同组成,通常包括用户和实施方的决策人员。CCB 是决策机构,不是作业机构,通常 CCB 的工作是通过评审手段来决定项目是否能变更,但不提出变更方案。过程及操作步骤为制定决策、交流情况、重新协商约定

4.7.2 需求追踪

        需求跟踪提供了由需求到产品实现整个过程范围的明确查阅的能力。需求跟踪的目的是建立与维护“需求—设计—编程—测试”之间的一致性,确保所有的工作成果符合用户需求。需求跟踪有正向跟踪和逆向跟踪两种方式,合称为“双向跟踪”。正向跟踪表示用户原始需求是否都实现了,反向跟踪表示软件实现的是否都是用户要求的。

        不论采用何种跟踪方式,都要建立与维护需求跟踪矩阵


        不论采用何种跟踪方式,都要建立与维护需求跟踪矩阵,若原始需求和用例有对应,则在对应栏打对号:

                若某行都没有对号,表明原始需求未实现,正向跟踪发现问题;
                若某列都没有对号,表明有多余功能用例软件实现了多余功能,反向跟踪发现问题。

五、系统分析与设计

5.1  结构化方法

        结构化方法又称为面向功能的软件开发方法或面向数据流的软件开发方法。针对软件生存周期各个不同的阶段,有结构化分析、结构化设计和结构化编程等方法。

5.1.1 结构化需求分析

        结构化特点:自顶向下,逐步分解,面向数据

        三大模型:功能模型(数据流图)、行为模型(状态转换图)、数据模型(E-R图(实体-联系图))以及数据字典

5.1.2 数据流图DFD

        基本图形元素:外部实体、加工、数据存储、数据流。        

        数据流:由一组固定成分的数据组成,表示数据的流向。在DFD 中,数据流的流向必须经过加工

        加工:描述了输入数据流到输出数据流之间的变换,数据流图中常见的三种错误:

                加工只有输入没有输出,称之为“黑洞”。
                加工只有输出没有输入,称之为“奇迹”。
                
加工输入不足以产生输出,称之为“灰洞”

        数据存储:用来存储数据

        外部实体(外部主体):是指存在于软件系统之外的人员或组织,它指出系统所需数据的发源地(源)和系统所产生的数据的归宿地(宿)。

        数据流图的平衡原则

                1.父图 ( 上层数据流图 ) 与 子图 ( 下层数据流图 ) 平衡
                        个数一致:两层数据流图中的数据流个数一致
                        方向一致:两层数据流图中的数据流方向一致

                2.子图内部的平衡
                        加工只有输入没有输出,称之为“黑洞”。
                        加工只有输出没有输入,称之为“奇迹”。
                        
加工输入不足以产生输出,称之为“灰洞”

5.1.3 数据字典DD

        数据流图描述了系统的分解,但没有对图中各成分进行说明。数据字典就是为数据流图中的每个数据流、文件、加工,以及组成数据流或文件的数据项做出说明

        数据字典有以下4 类条目:数据流、数据项、数据存储和基本加工。

符号 含义 举例与说明
= 被定义为 x=a,表示x等于a
+ x=a+b,表示x由a和b组成
[...,...]或[...|...] x=[a,b],x=[a|b],表示x由a或由b组成
{...} 重复 x={a},表示x由0个或多个a组成
(...) 可选 x=(a),表示a可在x中出现,也可以不出现

        加工逻辑也称为“小说明”。常用的加工逻辑描述方法有结构化语言、判定表和判定树3 种。

5.2 结构化设计

        系统设计主要目的:为系统制定蓝图,在各种技术和实施方法中权衡利弊精心设计,合理地使用各种资源,最终勾画出新系统的详细设计方法

        系统设计方法:结构化设计方法,面向对象设计方法

        系统设计的主要内容:概要设计、详细设计

        概要设计基本任务:又称为系统总体结构设计,是将系统的功能需求分配给软件模块,确定每个模块的功能和调用关系,形成软件的模块结构图,即系统结构图

        详细设计的基本任务:模块内详细算法设计、模块内数据结构设计、数据库的物理设计、其他设计(代码、输入/输出格式、用户界面)、编写详细设计说明书、评审。

        系统设计基本原理:

                抽象化;
                自顶而下,逐步求精;
                信息隐蔽;
                模块独立(高内聚,低耦合)。

        系统设计原则:

                保持模块的大小适中;
                尽可能减少调用的深度;
                多扇入,少扇出;
                单入口,单出口;
                模块的作用域应该在模块之内;
                功能应该是可预测的。

5.2.1 高内聚

        内聚表示模块内部各代码成分之间联系的紧密程度,根据内聚度从高到低的排序如表所示:

内聚类型 描述 关键字
功能内聚 完成一个单一功能,各个部分协同工作,缺一不可 协同工作,缺一不可
顺序内聚 处理元素相关,而且必须顺序执行 顺序执行,输入为输出
通信内聚 所有处理元素集中在一个数据结构的区域上 相同数据结构,相同输入输出
过程内聚 处理元素相关,而且必须按特定的次序执行 指定过程顺序
时间内聚 所包含的任务必须在同一时间间隔内执行 同时执行
逻辑内聚 完成逻辑上相关的一组任务 逻辑相似,参数决定
偶然内聚 完成一组没有关系或松散关系的任务 无直接关系

5.2.2 低耦合

        耦合表示模块之间联系的程度耦合度从低到高依次如表所示:

耦合类型 描述 关键字
非直接耦合 两个模块之间没有直接关系,它们之间的联系完全是通过上级模块的控制和调用来实现的 无直接关系
数据耦合 一组模块借助参数表传递简单数据 传递数据
标记耦合 一组模块通过参数表传递记录等复杂信息(数据结构) 传递数据结构
控制耦合 一个模块调用另一个模块时,传递的是控制变量,被调用模块通过该控制变量的值有选择的执行模块内的某一功能。 控制变量、选择执行某一功能。
外部(通信)耦合 模块间通过软件之外的环境联合(如 I/O将模块耦合到特定的设备、格式、通信协议上)时 软件外部环境
公共耦合 多个模块都访问同一个公共数据环境,公共的数据环境可以是全局数据结构、共享的通信区、内存的公共覆盖区等 公共数据结构
内容耦合 一个模块直接访问另一个模块的内部数据;一个模块不通过正常入口转到另一个模块的内部;两个模块有一部分程序代码重叠;一个模块有多个入口等 模块内部关联

5.3 结构化编程

        结构化编程(Structured Programming,SP)。SP 通过顺序、分支和循环三种基本的控制结构可以构造出任何单入口单出口的程序。

        SP 强调:

                自顶向下,逐步细化;
                清晰第一,效率第二;
                书写规范,缩进格式;
                基本结构,组合而成。

        SP 原则:程序=(算法)+(数据结构)。两者分开设计,以算法(函数或过程)为主。

5.4 人机界面设计

        人机界面设计三大黄金原则:置于用户控制之下、减少用户的记忆负担、保持界面的一致性

5.4.1 置于用户控制之下

        以不强迫用户进入不必要的或不希望的动作的方式来定义交互方式
        提供灵活的交互
        允许用户交互可以被中断和撇消
        当技能级别增加时可以使交互流水化并允许定制交互
        使用户隔离内部技术细节
        设计应允许用户和出现在屏幕上的对象直接交互

5.4.2 减少用户的记忆负担

        减少对短期记忆的要求
        建立有意义的缺省
        定义直觉性的捷径
        界面的视觉布局应该基于真实世界的隐喻
        以不断进展的方式揭示信息

5.4.3 保持界面的一致性

        允许用户将当前任务放入有意义的语境
        在应用系列内保持一致性
        如过去的交互模型已建立起了用户期望,除非有迫不得已的理由,不要改变它

5.5 流程表示工具

        概要设计使用系统结构图(Structure Chart,SC),又称为模块结构图,反映了系统的总体结构。详细设计的主要任务是设计每个模块的实现算法、所需的局部数据结构。详细设计的表示工具有图形工具、表格工具和语言工具。图形有业务流图、程序流程图(PFD)、问题分析图(ProblemAnalysis Diagram,PAD)、NS 流程图等

        程序流程图(Program Flow Diagram,PFD)又称为程序框图。用一些图框表示各种操作,它独立于任何一种程序设计语言,比较直观、清晰,易于学习掌握。任何复杂的程序流程图都应该由顺序、选择和循环结构组合或嵌套而成


        IPO图也是流程描述工具,用来描述构成软件系统的每个模块的输入、输出和数据加工


        N-S图容易表示嵌套和层次关系,并具有强烈的结构化特征。但是当问题很复杂时,N-S图可能很大,因此不适合于复杂程序的设计


        问题分析图(PAD)是一种支持结构化程序设计的图形工具。PAD具有清晰的逻辑结构、标准化的图形等优点,更重要的是,它引导设计人员使用结构化程序设计方法,从而提高程序的质量。

相关推荐

【系统架构设计师】九、软件工程(软件工程定义|软件过程模型|能力成熟度模型)-CSDN博客文章浏览阅读623次,点赞17次,收藏17次。历年真题考情:本章节每年单项选择考13分左右,下午案例、论文也会有涉及,在系统架构设计师中本章节绝对是重点中的重点。主要学习软件工程、需求工程、系统分析与设计、净室软件工程、基于构件的软件工程、软件项目管理等内容。很少涉及超纲题。https://blog.csdn.net/g984160547/article/details/140095679【系统架构设计师】八、系统工程基础知识(系统工程|系统性能)-CSDN博客文章浏览阅读394次,点赞9次,收藏19次。系统工程是运用系统方法,对系统进行规划、研究、设计、制造、试验和使用的组织管理技术。是人们用科学方法解决复杂问题的一门技术。系统工程方法的特点是整体性、综合性、协调性、科学性和实践性。系统工程是利用计算机作为工具,对系统的结构、元素、信息和反馈等进行分析,以达到最优规划、最优设计、最优管理和最优控制的目的。https://blog.csdn.net/g984160547/article/details/140043065

历年真题联系

        7.1 流程设计的任务是设计出系统所有模块和它们之间的相互关系,并具体设计出每个模块内部的功能和处理过程。以下关于流程设计的叙述,正确的是()

                A.任何复杂的程序流程图都应该由顺序、选择、循环结构构成
                B.IPO图不适合用来进行流程设计
                C.PAD图是一种支持原型化设计方法的图形工具
                D.N-S图容易表示嵌套关系和层次关系,特别适合于设计非常复杂的流程

        7.2 螺旋模型在()的基础上扩展而成。

                A.瀑布模型
                B.原型模型
                C.快速模型
                D.面向对象模型

        7.3 (1)适用于程序开发人员在地域上分布很广的开发团队。(2) 中,编程开发人员分成首席程序员和“类”程序员。
                (1)A.水晶系列(Crystal)开发方法                B.开放式源码(Open Source)开发方法
                    C.Scrum 开发方法                                 D.功用驱动开发方法(FDD)
                (2)A.自适应软件开发(ASD)                        B.极限编程(XP)开发方法
                    C.开放系统-过程开发方法(OpenUP)      D.功用驱动开发方法(FDD)

人工分割线-答案

        7.1 A 
                解析:概念就是这么描述的。不是所有选择题看到都应该必须等字眼都是错的。

        7.2 B

        7.3 B、D
                解析:开放式源码指的是开放源码界所用的一种运作方式。开放式源码项目有一个特别之处,就是程序开发人员在地域上分布很广,这使得它和其他敏捷方法不同,因为一般的敏捷方法都强调项目组成员在同一地点工作。开放源码的一个突出特点就是查错排障(Debug)的高度并行性,任何人发现了错误都可将改正源码的“补丁”文件发给维护者。然后由维护者将这些“补丁”或是新增的代码并入源码库。
                        功用驱动开发方法(Feature Driven Development,FDD)是由 JeffDeLuca 和 Peter Coad提出来的。像其他方法一样,它致力于短时的迭代阶段和可见可用的功能。在FDD 中,一个迭代周期一般是两周。在 FDD 中,编程开发人员分成两类:首席程序员和“类”程序员(Class Owner)。首席程序员是最富有经验的开发人员,他们是项目的协调者、设计者和指导者,而“类”程序员则主要做源码编写。

        

最近更新

  1. docker php8.1+nginx base 镜像 dockerfile 配置

    2024-07-10 09:10:01       4 阅读
  2. Could not load dynamic library ‘cudart64_100.dll‘

    2024-07-10 09:10:01       5 阅读
  3. 在Django里面运行非项目文件

    2024-07-10 09:10:01       4 阅读
  4. Python语言-面向对象

    2024-07-10 09:10:01       4 阅读

热门阅读

  1. SSL证书到期自动巡检脚本-推送钉钉告警

    2024-07-10 09:10:01       9 阅读
  2. 如何才能在Linux下编写驱动程序

    2024-07-10 09:10:01       6 阅读
  3. Tomcat打破双亲委派模型的方式

    2024-07-10 09:10:01       12 阅读
  4. C++惯用法: 通过std::decltype来SFINAE掉表达式

    2024-07-10 09:10:01       7 阅读
  5. HTTP 范围Range请求

    2024-07-10 09:10:01       8 阅读
  6. React 开发报错整理

    2024-07-10 09:10:01       14 阅读
  7. 微软 Edge 浏览器全解析

    2024-07-10 09:10:01       8 阅读
  8. 静态搜索iOS动态链接函数的调用位置

    2024-07-10 09:10:01       10 阅读
  9. demon drone 200无人机标定流程

    2024-07-10 09:10:01       9 阅读