系统设计思考题

实验三软件设计(2015/4/29--2015/5/10)

作业内容

实验三系统设计

一、实验学时

12课时，其中课内6课时，课外6课时

二、实验目的

在实验二基础上完成系统的体系结构的建立和系统详细设计，并给出相应的规格说明书。

三、实验内容和要求

功能结构图设计，软件处理流程设计，输出设计（主要指打印输出设计），存储文件格式设计（数据库结构设计），输入设计（主要指数据录入卡设计），代码设计，完成概要设计和详细设计规格说明书

四、思考题

1．系统设计和需求分析的关系是什么？两者必须先后关联吗？

系统设计时把需求分析变换成软件表示的过程，主要包含两个阶段：软件体系结构设计和部件级设计阶段。前者为概要设计，后者为详细设计。系统设计是将需求分析转化为数据结构和软件，进而将软件体系结构元素转化为软件部件的过程性描述，得到软件详细的数据结构和算法的过程。因此，系统设计时基于需求分析的。两者必须是先后关联，如果不这样，系统设计时盲目的，会导致这个工程失去目标和方向，最终导致失败。

2．怎样描绘系统的体系结构？

体系结构的描述有多种风格；数据位中心的体系结构；数据流风格的体系结构；调用和返回风格的体系结构;面向对象风格的体系结构；层次式风格的体系结构。

3．怎样绘制符合规范的流程图。

首先要对整个系统流程有清晰的认识，其次要使用合适的绘图软件帮助实践，最后要对绘好的流程图进行检查，保证逻辑的清晰正确。

4．怎样组织对设计阶段工作的评审？

建议一：分层次评审

我们知道用户的需求是可以分层次的，一般而言可以分成如下的层次：

目标性需求：定义了整个系统需要达到的目标；

功能性需求：定义了整个系统必须完成的任务；

操作性需求：定义了完成每个任务的具体的人机交互；

目标性需求是企业的高层管理人员所关注的，功能性需求是企业的中层管理人员所关注的，操作性需求是企业的具体操作人员所关注的。对不同层次的需求，其描述形式是有区别的，参与评审的人员也是不同的。如果让具体的操作人员去评审目标性需求，可能会容易地

导致“捡了芝麻，丢了西瓜”的现象，如果让高层的管理人员也去评审那些操作性需求，无疑是一种资源的浪费或者就会出现案例三的情形。

建议二：正式评审与非正式评审结合

正式评审是指通过开评审会议的形式，组织多个专家，将需求涉及到的人员集合到一起，并定义好参与评审人员的角色和职责，对需求进行正规的会议评审。而非正式的评审并没有这种严格的组织形式，一般也不需要讲人员集合在一起评审，而是通过电子邮件，文件会签甚至是网路聊天等多种形式对需求进行评审。两种形式各有利弊，但往往非正式的评审比正式的评审效率更高，更容易发现问题。因此在评审时，应该灵活地利用这两种方式。

建议三：分阶段评审

应该在需求形成的过程中进行分析阶段的评审，而不是在需求最终形成后再进行评审。分阶段评审可以将原来需要进行的大规模评审拆分为各个小规模的评审，降低了需求返工的风险，提高了评审的质量。比如可以在形成目标需求后进行一次评审，在形成系统的初次概要需求后进行一次评审，当对概要需求细分为几个部分，对每个部分进行各个评审，最终再对整体的需求进行评审。