3.系统工程基础与可行性研究
2021-05-07 21:48:41 0 举报AI智能生成
登录查看完整内容
课堂软件工程第3讲PPT梳理
作者其他创作
大纲/内容
3.系统工程基础与可行性研究
思考题
基于计算机的系统的基本组成包括什么？
可行性研究主要关注哪些方面？
经济效益的度量包括哪三个方面，如何计算？
硬件工程包括哪三个阶段？
软件工程包括哪三个阶段？
应从哪些角度进行系统定义评审？
系统工程
概念
关注目标系统各种相关要素的分析、设计，并将其组织成有机的系统
有机
像生命体一样，各个部分密切配合、有序演化，达到系统的总体目标
系统工程与软件工程
系统工程更加广泛，软件工程源于系统工程
任何软件的开发都处于一个更大的系统之中，因此软件开发必须先了解软件所处的系统全局视图
基于计算机的系统
通过处理信息来完成某些预定义目标而组织在一起的元素的组合
主要组成元素
软件、硬件、人员、数据库、文档和过程
系统元素
软件
计算机程序、数据结构和描述所需的逻辑方法、过程或控制的文档
硬件
计算机系统中提供计算能力的物理电子设备
人员
硬件和软件的用户和操作员
数据库
通过软件进行加工与存取的，大型、有组织的信息集合
文档
用以描述系统使用和操作的描述性信息
过程
定义每种元素特定的使用步骤或系统的主流过程性环境
系统的层次结构
任何系统都处在一个更大的系统之中，形成系统的层次结构
校园一卡通系统包括基础网络、结算系统、银行接口系统、消费终端等子系统
一卡通系统处于整个学校系统(教务、财务、学工…)之中
学校系统属于整个高等教育系统乃至社会系统的一环……
在某个项目中关注的具体系统总是有确定的边界
对于结算系统项目而言
已知：消费终端可以将基本消费信息通过一卡通网络发送过来、银行接口系统支持银行系统的联机存取操作…
当前系统任务
根据消费及存取信息记录更新各学生账户信息…
基于计算机的系统结构
基于计算机的系统可呈现一个层次结构
计算机系统工程
为什么强调系统工程
被动选择
现实的信息系统往往是一个复杂的系统工程，其中的软件需要与系统中其它部件合理分配责任、密切配合，从而达到系统的总体目标
主动选择
只作自己擅长的事情
选择合适的硬件解决方案
选择基础软件解决方案，或者第三方软件部件和软件服务
eg
一卡通结算系统中的安全性要求
硬件方面
整个校园消费网络采用专线联接，不与校园网连通，同时要求敏感操作员使用USB Key认证身份
应用软件方面
进行日志记录，并与USB Key认证接口进行集成
制度方面
建立机房及核心服务器的日常安全管理制度，设置专人负责可疑交易信息的监控…
软件项目的客户方基础设施
业务现状、人员现状
遗留数据、遗留系统以及重用的可能
是否处于一个规划中的更大系统之中，与其他系统的关系如何
软件项目的第三方基础设施
基础软硬件系统
服务器、OS、DB、AS等
可用软件构件
特殊硬件设备
USB Key
加密狗
等......
可能的项目合作伙伴
软件外包
构件外包
一个问题求解活动，通过和用户的协商揭示并分析客观的功能需求，把整体需求化整为零，分配给计算机系统中的各个元素去完成
任务
识别用户的要求(了解问题)
系统建模和模拟（提出完整的解决方案）
成本估算及进度安排(给出实施计划)
可行性分析(系统及实施方案的现实可行性)
生成系统规格说明
硬件工程
选择某种硬件元素的组合构成基于计算机系统的硬件元素
硬件工程的三个阶段
计划与定义
设计和样机实现
生产、销售和售后服务
软件工程
目标
开发高质量的软件
软件工程的三个阶段
定义
定义阶段
开发
开发阶段
检验交付与维护阶段
人机工程
确定和设计高质量的人机对话界面
(1) 活动分析：对分配给人的每一项活动，在与其他系统 生成元素进行交互的环境中进行评价
(2) 语义分析和设计：对用户要求的每一个动作和机器产 生的每一个动作的精确含义进行定义，并进行能够传 递正确语义的对话设计
(3) 语法和词法设计：标识与描述各个动作和命令的特定 形式，然后设计每一动作或命令的硬件与软件实现
(4) 用户环境设计：将硬件、软件和其他系统生成元素组合起来形成用户环境
数据库工程
明确加工对象和输出结果的数据结构特征
可行性研究分析
系统分析目标
(1) 识别用户需求
(2) 评价系统可行性
(3) 进行经济分析和技术分析
(4) 在明晰总体需求的前提下，将要实现的功能分配给硬件、软件、人、数据库和其他的系统元素
(5) 预测成本、进行进度设计
(6) 生成系统规格说明，用作所有后继工程的基础
系统分析过程
识别用户的真正需求是系统分析的第一步
弄清楚下列问题
(1) 用户所期望的功能和性能
(2) 对于可靠性和质量提出的问题有哪些
(3) 总的系统目标是什么
(4) 成本、资源和进度有哪些限制和约束
(5) 可能会有哪些扩充需求
(6) 有哪些有效的技术可供使用
(7) 制造的需求是什么？市场竞争情况如何
系统分析员协助用户整理其需求，提出总的目标
对辅助需求信息做进一步评估
如工期限制、资源、技术储备等
把对系统需求的理解和相关技术路线的分析写入前期调研报告，通过和用户的反复交流，对文档进行滚动修改
为什么要进行可行性研究？
不是所有的问题都可以有明显的解决方法
如果问题没有可行的解决办法，贸然开发项目就会造成时间、人力、资源和经费浪费
软件项目开发也存在这一问题
在进行任何一项较大的工程（包括软件开发）时，首先要进行可行性分析和研究
可行性研究目标与主要内容
研究软件项目是否值得去开发，其中的关键和技术难点是什么，问题能否得到解决，怎样达到目的等
主要内容
对问题定义，初步确定问题的规模和目标
导出系统的逻辑模型
从逻辑模型出发，选择若干供选择的主要系统方案
可行性分析的主要方面
考虑的问题
在指定的目标和满足质量、时间、成本约束条件前提下，问题有没有可行解
四个主要方面
经济可行性
技术可行性
法律可行性
对不同方案进行评估抉择
经济可行性分析
进行成本效益分析，从经济角度，确定系统是否值得开发
基于计算机的系统成本主要包括
购置硬件、软件（如数据库管理系统、第三方开发的构件等）和设备（如传感器等）的费用
系统的开发费用
系统安装、运行和维护费用
人员培训费用
效益
经济效益
采用新系统后增加的收入和节约的运行费用
在进行成本效益分析时通常只统计五年内的经济效益
社会效益
采用新系统后对社会产生的影响（如提高了办事效益，使用户满意等），通常社会效益只能定性地估计
经济效益的度量
一般从三个方面度量
投入/产出比
投资回收期
纯收入
货币的时间价值
投入/产出比=累计当前收益 / 投资额
累计的经济效益正好等于投资额（成本）时所需的时间
纯收入=累计经济效益 – 投资额
相当于比较一个待投入的软件项目可能获取的利润和将20万元存入银行所取得的收益
当纯收入大于零时，该工程才值得投资开发
纯收入越大越好
技术可行性分析
主要根据系统的功能、性能、约束条件等，分析在现有资源和技术条件下系统能否实现
技术可行性分析通常包括
风险分析
分析在给定的约束条件下设计和实现系统的风险
–采用不成熟的技术可能造成技术风险
–人员流动可能给项目带来风险
–成本和人员估算不合理造成的预算风险
目的
找出风险，评价风险的大小，并有效地控制和缓解风险
资源分析
论证是否具备系统开发所需的各类人员、软件、硬件等资源和相应的工作环境
技术分析
分析当前的科学技术是否支持系统开发的各项活动
技术分析过程
分析员收集系统的性能、可靠性、可维护性和生产率方面的信息，分析实现系统功能、性能所需的技术、方法、算法或过程，从技术角度分析可能存在的风险，以及这些技术问题对成本的影响
通常需进行系统建模，必要时可建造原型和进行系统模拟
技术分析建模
法律可行性分析
研究系统开发过程中可能涉及到的合同、侵权、责任以及各种与法律相抵触的问题
– 中华人民共和国著作权法
– 计算机软件保护条例
与计算机软件的使用场合相关的其他法律
– 例如：开发一套网络监控系统对员工在个人电脑上的所有行为进行监控
方案的评估选择
不同方案投入的资源不尽相同，要在多个可行的实现方案中作出选择
方案评估的依据是待开发系统的功能、性能、成本、开发时间、采用的技术、设备、风险以及对开发人员的要求等
系统的功能和性能会受到多种因素的影响，某些因素之间相互关联和制约
如，为达到高的精度就可能导致长的执行时间，为达到高可靠性就会导致高的成本等等。必要时进行折衷
方案的选择
一般在满足功能、性能指标的前提下，通常首先根据经济因素进行选择
可行性报告的主要内容
(1) 项目背景
问题描述、实现环境和限制条件等
(2) 管理概要与建议
重要的研究结果、说明、劝告和影响等
(3) 推荐的方案
候选系统的配置与选择最终方案的原则
(4) 简略的系统范围描述
分配元素的可行性
(5) 经济可行性分析结果
经费概算和预期的经济效益等
(6) 技术可行性
技术实力分析、已有的工作及技术基础和设备条件等
(7) 法律可行性分析结果描述
(8) 可用性评价
汇报用户的工作制度和人员的素质，确定人机交互功能界面需求
(9) 其他项目相关的问题
如可能会发生的变更等等
可行性报告
由系统分析员撰写，交由项目负责人审查，再上报给上级主管审阅
应当明确项目“可行还是不可行”，如果认为可行，还要明确地推荐方案
系统体系结构建模
系统建模
建立模型表达系统元素及它们之间的关系
建模过程
由抽象的系统结构模板开始，不断细化，得到详细的系统结构流程图
系统结构模板
五个处理区域
IPO+用户界面处理+系统维护与自测试
能帮助分析员建立一个逐层细化的层次结构
结构环境图（ACD）
每个方框都代表一个外部实体
整个系统用圆角矩形表示
系统作为一个宏元素在ACD的“处理与控制”区域内表示
用附加名字的箭头表示外部实体与系统之间传送的数据或控制信息
结构流程图AFD
对系统的部分区域进行详细分析，细化这个结构环境图，能够完成系统规定的功能的各个专门子系统，并在ACD定义的环境中加以标识
专门子系统定义在从ACD导出的结构流程图AFD( Architecture Flow Diagram）中
信息流穿越ACD的各个区域，可用于引导系统工程师开发AFD
AFD给出了各个专门子系统和重要的数据与控制信息流，把每一个子系统划分成为了结构模板中定义的五个区域
结构流程图规格说明
给出了有关每个子系统的信息和各个子系统之间的信息流
对每个子系统进行“系统模块描述”，详细说明每一个子系统的功能、处理对象与方法，以及和其它子系统如何接口
结构字典
对子系统中的每个信息项的类型、组成、来源、去处和传输方式进行说明
例：对“零件号”数据项进行详细描述
系统定义与评审
系统定义
对待开发系统的一个全面、真实、简略的定义性说明文档
系统定义的评审
评价系统分析的合理性与定义的正确性
系统定义文档
系统定义评审
评审由开发人员和用户代表合作进行，目的是保证
(1) 正确地定义了项目的范围
(2) 适当地定义了功能、性能和接口
(3) 通过可行性分析证明了系统是可行的
(4) 开发方和用户方对系统的目标达成了共识
评审角度
管理角度
管理方面考虑的关键问题
(1) 商业需求是否已经确定，系统可行性分析的结论是否合理
(2) 市场(用户)是否真的需要所描述的系统
(3) 是否考虑过一组候选方案并进行了择优
(4) 每一系统元素的开发风险有哪些
(5) 是否具备开发系统的有效资源
(6) 成本与进度的期望值是否合理
技术角度
技术方面考虑的重点问题
(1) 系统的功能复杂性是否与开发风险、成本、进度的评估相一致
(2) 功能分配定义是否足够准确
(3) 系统元素之间的接口、系统元素和环境的接口定义是否清晰
(4) 在规格定义中是否考虑了性能、可靠性和可维护性问题
(5) 系统规格说明是否足以支持后继的硬件、软件工程步骤
0 条评论
回复 删除
下一页
