概要设计怎么写(你想成为软件设计师吗) [转]

发表者付:
做软件到一定层次了,就要考虑到设计了,设计了很久,就是不系统,系统的设计需要一个记录,记录就用文档,那么对项目所有包括技术上的设计都记录下来,我们就可以理解为软件的概要设计了。

在需求明确、准备开始编码之前,要做概要设计,而详细设计可能大部分公司没有做,有做的也大部分是和编码同步进行,或者在编码之后。因此,对大部分的公司来说,概要设计文档是唯一的设计文档,对后面的开发、测试、实施、维护工作起到关键性的影响。
  一、问题的提出
  概要设计写什么?概要设计怎么做?
  如何判断设计的模块是完整的?
  为什么说设计阶段过于重视业务流程是个误区?
  以需求分析文档还是以概要设计文档来评估开发工作量、指导开发计划准确?
  结构化好还是面向对象好?
  以上问题的答案请在文章中找。
  二、概要设计的目的
  将软件系统需求转换为未来系统的设计;
  逐步开发强壮的系统构架;
  使设计适合于实施环境,为提高性能而进行设计;
  结构应该被分解为模块和库。
  三、概要设计的任务
   制定规范:代码体系、接口规约、命名规则。这是项目小组今后共同作战的基础,有了开发规范和程序模块之间和项目成员彼此之间的接口规则、方式方法,大家就有了共同的工作语言、共同的工作平台,使整个软件开发工作可以协调有序地进行。
  总体结构设计:
  功能(加工)->模块:每个功能用那些模块实现,保证每个功能都有相应的模块来实现;
  模块层次结构:某个角度的软件框架视图;
  模块间的调用关系:模块间的接口的总体描述;
  模块间的接口:传递的信息及其结构;
  处理方式设计:满足功能和性能的算法
  用户界面设计;
  数据结构设计:
  详细的数据结构:表、索引、文件;
  算法相关逻辑数据结构及其操作;
  上述操作的程序模块说明(在前台?在后台?用视图?用过程?······)
  接口控制表的数据结构和使用规则
  其他性能设计。
  四、概要设计写什么
  结构化软件设计说明书结构(因篇幅有限和过时嫌疑,在此不作过多解释)
  任务:目标、环境、需求、局限; Continue reading “概要设计怎么写(你想成为软件设计师吗) [转]”

概要设计模板-来自互联网

1.引言

1.1编写目的

  [说明编写这份概要设计说明书的目的,指出预期的读者。]

1.2背景

  a.[待开发软件系统的名称;]

  b.[列出本项目的任务提出者、开发者、用户。]

1.3定义

  [列出本文件中用到的专门术语的定义和外文首字母组词的原词组。]

1.4参考资料

  [列出有关的参考资料。]

2.总体设计

2.1需求规定

  [说明对本系统的主要的输入输出项目、处理的功能性能要求。包括]

  2.1.1系统功能

  2.1.2系统性能

    2.1.2.1精度

    2.1.2.2时间特性要求

    2.1.2.4可靠性

    2.1.2.5灵活性

  2.1.3输入输出要求

  2.1.4数据管理能力要求

  2.1.5故障处理要求

  2.1.6其他专门要求

2.2运行环境

  [简要地说明对本系统的运行环境的规定。]

  2.2.1设备

  [列出运行该软件所需要的硬设备。说明其中的新型设备及其专门功能。]

  2.2.2支持软件

  [列出支持软件,包括要用到的操作系统、编译(或汇编)程序、测试支持软件

等。]

1  2.2.3接口

  [说明该系统同其他系统之间的接口、数据通信协议等]

  2.2.4控制

  [说明控制该系统的运行的方法和控制信号,并说明这些控制信号的来源。]

2.3基本设计概念和处理流程

  [说明本系统的基本设计概念和处理流程,尽量使用图表的形式。]

2.4结构

  [给出系统结构总体框图(包括软件、硬件结构框图),说明本系统的各模块的

划分,扼要说明每个系统模块的标识符和功能,分层次地给出各模块之间的控制与被

控制关系。]

2.5功能需求与系统模块的关系

  [本条用一张矩阵图说明各项功能需求的实现同各模块的分配关系。]

    [系统模块1] [系统模块2] [……] [系统模块m]

[功能需求1]  √             

[功能需求2]      √         

[┇]                

[功能需求n]      √       √ 

2.6人工处理过程

  [说明在本系统的工作过程中不得不包含的人工处理过程。]

2.7尚未解决的问题

  [说明在概要设计过程中尚未解决而设计者认为在系统完成之前必须解决的各个

问题。]

3.接口设计

3.1用户接口

  [说明将向用户提供的命令和它们的语法结构,以及相应的回答信息。]

  [说明提供给用户操作的硬件控制面板的定义。]

3.2外部接口

  [说明本系统同外界的所有接口的安排包括软件与硬件之间的接口、本系统与各

支持系统之间的接口关系。]

3.3内部接口

  [说明本系统之内的各个系统元素之间的接口的安排。]

4.运行设计

4.1运行模块组合

  [说明对系统施加不同的外界运行控制时所引起的各种不同的运行模块组合,说

明每种运行所历经的内部模块的支持软件。]

4.2运行控制

  [说明每一种外界的运行控制的方式方法和操作步骤。]

4.3运行时间

  [说明每种运行模块组合将占用各种资源的时间。]

5.系统数据结构设计

  [不涉及软件设计可不包含]

5.1逻辑结构设计要点

  [给出本系统内软件所使用的每个数据结构的名称、标识符以及它们之中每个数

据项、记录、文卷和系的标识、定义、长度及它们之间的层次的或表格的相互关系。

]

5.2物理结构设计要点

  [给出本系统内软件所使用的每个数据结构中的每个数据项的存储要求,访问方

法、存取单位、存取的物理关系、设计考虑和保密条件。]

5.3数据结构与程序的关系

  [说明各个数据结构与访问这些数据结构的各个程序之间的对应关系。]

    [程序1] [程序2] [……] [程序m]

[数据结构1]  √             

[数据结构2]      √         

[┇]                

[数据结构n]      √       √ 

6.系统出错处理设计

6.1出错信息

  [用一览表的方式说明每种可能的出错或故障情况出现时,系统输出信息的形式

、含意及处理方法。]

6.2补救措施

  [说明故障出现后可能采取的变通措施。包括:]

  a.后备技术 [说明准备采用的后备技术,当原始系统数据万一丢失时启用的副本

的建立和启动的技术,例如周期性地把磁盘信息记录到磁带上去就是对于磁盘媒体的

一种后备技术。]

  b.降效技术 [说明准备采用的后备技术,使用另一个效率稍低的系统或方法来求

得所需结果的某些部分,例如一个自动系统的降效技术可以是手工操作和数据的人工

记录。]

  c.恢复及再启动技术 [说明将使用的恢复再启动技术,使软件从故障点恢复执行

或使软件从头开始重新运行的方法。]

6.3系统维护设计

  [说明为了系统维护的方便而在程序内部设计中作出的安排,包括在程序中专门

安排用于系统的检查与维护的检测点和专用模块。]

概要设计应该包括哪些内容

转自:http://learnsoftwareprocesses.com/2007/09/20/high-level-design-document-template/

The High Level Design Document is a pretty important document for a project, covering at a high level the overall design of the solution. If one were to try and present a very succinct summary of the High Level Document, it could be something like this:
– Detailed use case scenarios of key process flows of the application
– The class model and relationships
– The sequence diagrams which outline key use case scenarios
– The data/object model with relational table design
– User interface style and design

High-level design is the transitional step between WHAT [requirements for sub-systems] the system does,
and HOW [architecture and interfaces] the system will be implemented to meet the system requirements.
This process includes the decomposition of system requirements into alternative project architectures and
 then the evaluation of these project architectures for optimum performance, functionality, cost, and other issues
[technical and non-technical]. Stakeholder involvement is critical for this activity. In this step,
internal and external interfaces are identified along with the needed industry standards.
These interfaces are then managed throughout the development process.

Some examples of a High Level Document available at these links:
Link 1, Link 2, Link 3, Link 4