概要设计、详细设计(一)概念、方法、实践步骤

1.    概念、方法、实践步骤

设计是指根据需求开发的结果,对产品的技术实现由粗到细进行设计的过程。根据设计粒度和目的的不同可以将设计分为概要设计、详细设计等阶段以便于管理和确保质量。设计内容也要根据软件系统的实际情况进行定义,比如对于交互性要求高的系统可以有视觉设计等等。

一般来说可以将设计阶段划分为概要设计、详细设计2阶段进行管理,程序设计可以结合项目管理、作业配分、开发团队的能力以及质量要求等因素来决定是否作为单独的阶段进行管理。

n  概要设计: 定义实现需求的工作产品技功能、技术构架,定义设计准则及共通处理方针,分解划分功能模块,定义各功能模块的功能和业务处理,定义模块间的接口关系。典型的工作产品有《概要设计书》、《设计准则》及《共通处理方针》。一般包括系统技术构架,机能一览,机能迁移图,数据库逻辑设计,数据文件逻辑定义,系统各单位功能模块及接口定义,设计准则及共通处理方针(外观、操作、错误处理、日志、提示信息、异常处理、命名规约、编码规约等方针)等内容。

n  详细设计:定义各功能模块的功能单元的详细实现,包括接口的物理定义,明确数据库/数据文件的物理定义等。典型的工作产品:《详细设计书》。典型的内容包括各模块的功能单元实现的详细描述,数据库物理设计,数据文件物理定义,接口物理定义,状态码物理设计,输出信息(MSG/LOG)设计等内容。

程序设计:结合具体的编码语言,编码过程中对代码的设计。根据经验对于团队中有大量初学者来说,进行一定量的程序设计可以提高编码的质量和效率。

2.    设计阶段的主要流程

设计阶段的主要活动包括以下内容:设计阶段的计划或规划、确定设计的准则、设计以及制作设计文档、设计产物评审等。

1.设计阶段的计划或规划内容为确定设计团队的组织并授权、评估设计阶段的工作量、明确设计的工作任务(WBS分解)以及完成时间、定义设计阶段的质量标准以及效率标准。这部分活动主要是PDCA中首要步骤,除上述内容外,还需要考虑项目管理中一些共同管理规划,比如风险管理、配置管理、干系人管理、变更管理、决策分析管理等等内容。在多人或团队作业的工作,制定合理的计划和规划是首要的步骤。

2.设计不同类型的系统其设计方法、方式等有很大的区别,比如图像处理系统、监控系统和ERP等管理系统的差异是显而易见的。因此设计阶段有个关键的活动就是确定设计准则,这个活动的主要目的就是根据系统的实际情况,选择最佳的实践,用最优的方法指导设计的进行。设计准则通常要考虑的内容包括:设计的内容、方法、工具、模板、命名规约、模块划分规则(尤其设计粒度)、质量以及效率评估方式等等。

3.设计以及制作设计文档:根据设计准则以及设计规划执行设计任务并制作设计文档多数情况不是一件复杂的工作,但是对软件系统来说却是一个迭代的、消化大量时间的过程。从我们讨论设计思路、形成初步草案、充分沟通、决策优劣、再修正、评审通过都需要理解、学习、反复迭代并花费大量时间。软件系统的设计无论采用什么形式,分层、抽象、归纳、汇总是设计的主要方法。分层和抽象是最关键的步骤,也是相对比较难掌握的,无论分层和抽象都是从分类开始的,比如功能的分类、业务的分类、信息的分类、控制模式的分类等等,只要能逐层分类就很容易进行分层和抽象。另外,归纳、汇总是常见的方法,也是体力工作,只要认真细致就能很好的完成。

4.设计产物评审:针对设计设计产物进行评审以及相关的沟通是确保设计质量的主要活动。从形式上,可以采用多种方法,比如设计小组评审、P2P评审、正式会议评审等等。

设计阶段的主要活动设计阶段的计划或规划、确定设计的准则、设计以及制作设计文档、设计产物评审等是个反复迭代的过程。本质上设计是个学习迭代的过程、通过不断的评审、确认、改善达到成熟,因此设计的保证手段主要是设计准则和评审。

根据软件项目类型的不同具体流程也有一些细节差异,每个软件开发组织可以结合业务特征具体定义,下面举例介绍2种典型的流程。

例:软件外包企业,工程类的典型流程(概要设计)

主要特征:

ü  流程强调客户的参与,比如对设计的计划、设计的成果的评审。

ü  强调对关键的过程,比如系统架构的结果进行质量管控。

ü  对不同规模、技术、质量、进度要求的项目进行分级控制。

3.1制定及修改项目计划

•   项目经理根据《项目计划规程》制定概要设计计划,明确设计(式样)管理组中参与概要设计人员的工作任务和完成时间,并通知各相关者进行确认。

•   项目进行中,根据给定需求的变更和概要设计的实际进度状况的跟踪结果,及时调整或重新制定概要设计的详细进度计划。

•   根据概要设计的进展状况,必要时修正计划并与客户达成一致。

注:与客户达成一致是外包的核心,计划以及核心内容和客户达成一致非常重要。

•   项目概要设计计划并入项目计划中。

3.2确定系统架构和概要设计准则

•   确定系统架构

a.  对于A、B类项目

?  启动DAR(参见《决策分析规程》),分析风险、成本、进度的制约、技术、质量的要求,决定是否需要购买商业组件、是否复用已有构件。如果确认需要进行采购,请参见《供应商合同管理规程》。

?  根据公司人员情况、项目业务特征、性能数据量要求、可靠性要求、成本、效率、风险等方面内容提出多种系统架构进行评定,最终选定适合项目的系统架构。

?  输出参见《决策分析规程》的输出。

b.  对于非A、B类项目

?  设计(式样)管理组根据公司人员情况、项目业务特征、性能数据量要求、可靠性要求、成本、效率、风险等方面内容对多种系统架构进行评定,最终选定适合项目的系统架构。

如果用户有不同于一般项目的要求或者采用了公司不熟悉的架构,开发技术(环境)组需制作项目原型,以验证技术架构方案并确保其正确性。

注:根据不同工作量、技术、质量、进度要求、团队规模等识别出项目分类,并对概要设计的关键控制点(体系结构)进行不同的管控。

•   确定概要设计准则

?  设计(式样)管理组根据项目情况,确定项目的概要设计准则,准则通常包括:项目概要设计的方法、项目概要设计所使用的工具、概要设计成果物所使用的部分模板等。

?  设计(式样)管理组定义各种方针,各单位机能模块设计时应遵循已定义的各类方针。

?  通常需要定义的方针包括:操作、错误处理、日志、提示信息、异常处理、命名规约等方针。

?  所定义的所有的处理方针均需形成文档,进行配置管理。

?  对定义的所有内容形成《概要设计准则》。

3.3设计业务机能

•   设计(式样)管理组对《系统要件定义书》中定义的业务组件使用各种方法进行细化(包括拆分、合并、分组等),并将各需求分配到这些细分的业务组件或功能模块上。

•   设计(式样)管理组根据各类处理方针,对各单位机能组件和功能模块的外观、数据项目定义、功能概要、数据处理流程、操作方法、各机能组件或功能模块的接口和参数等进行设计。

•   定义各机能组件和功能模块的接口和参数,各设计人员需验证其接口衔接上的一致性。

•   将以上的内容加入对系统架构的描述,形成《概要设计书》。

•   设计(式样)管理组将概要设计的内容按照其和需求的对应关系填入《需求追踪矩阵》。

•   数据库逻辑设计。

3.4评审系统概要设计

•   项目经理组织项目评审专家组对概要设计的成果物进行评审(参见评审规程)。评审中发现的问题需体现于《概要设计评审报告》中。评审结束后,开发经理(PJL)跟踪这些问题,直到问题得到修正。

•   评审结束后,项目评审专家组需要根据评审的结论产生《概要设计评审报告》,并上报项目经理(PM)。

3.5确认概要设计

•   概要设计评审通过后,项目经理(PM)针对《概要设计书》取得客户的认可。

注:软件外包中的概要设计结果一般还需要客户的评审,这个也是项目屏蔽风险的主要方法,但是不同的客户技术水平并不相同,还要根据实际情况来判断。

3.6纳入基线管理

•   概要设计评审通过后,《概要设计准则》、《概要设计书》、《需求追踪矩阵》需纳入基线管理

•   本规程所产生的所有文档均需进行配置管理(参见配置管理规程)。产生的文档通常包括:

?  《概要设计准则》

?  《概要设计书》

?  《概要设计评审报告》

案例2:软件产品类的典型流程

主要特征:

ü  流程强调交互设计

ü  强调设计方针的管理。

ü  对设计内容进行的明确规范

3.1计划编制

产品研发经理根据《开发详细时间计划》细化设计工作,编制《系统设计计划》。经相关人员确认后,提交产品团队经理审核,审核通过后发布计划。

产品团队经理应将《系统设计计划》及时合并到《开发详细时间计划》中。

3.2设计准则确定

系统设计组根据项目情况,确定设计准则。准则通常包括:设计的方法、设计使用的工具、设计成果物所使用的模板等。

系统设计组制定各种设计方针,设计过程中需遵循已定义的方针。

3.2.1概要设计准则

概要设计方针通常包含:功能模块命名规约、功能模块操作、错误处理、异常处理、提示信息显示、日志记录等。

系统设计组汇总概要设计方针形成《概要设计准则》。

3.2.2详细设计准则

详细设计的方针通常包含:类和方法命名规约、方法输入参数的排列次序、方法输出参数的格式、提示信息输出格式、方法级日志输出格式等。

系统设计组汇总详细设计方针形成《详细设计准则》。

3.2.3设计准则评审

产品研发经理宜组织资源对《概要设计准则》、《详细设计准则》进行评审,评审通过后,由配置组进行配置管理。

3.3概要设计

3.3.1《概要设计书》编制

《概要设计书》应包含以下内容:

?  系统架构设计

?  根据产品的业务特征、性能要求、可靠性要求、成本等方面内容,针对产品使用的技术平台和软硬件架构,提出多种候选方案;

?  方案的内容应包含:系统使用的软硬件技术平台及相关技术列表、系统的物理架构、物理器件类型、数据库管理系统类型、服务器类型、子系统划分及部署方式、系统的软件架构、第三方软件平台列表等;

?  功能模块设计

?  根据《产品规格说明书》的定义,结合产品的领域知识,通过拆分、合并、分组等方法,将产品的各项功能划分到子系统中,并细化到各机能组件和功能模块上;

?  系统接口设计

?  接口主要用于子系统/模块之间或内部系统与外部系统进行各种交互;

?  接口设计应根据制定各种方针,结合业务特点,并使用相应的设计方法;

?  接口设计的内容应包含:接口的名称、功能描述、接口的输入输出定义、接口的使用方法、接口的数据处理流程、输入输出的数据结构定义、异常处理机制、错误处理机制、日志记录方法及格式等;

?  数据库设计

?  根据业务的复杂程度和设计实现的需要,对核心和重要的数据生成数据字典,对于复杂的操作流程,进行适当的流程说明;

?  完成核心和重要库表的逻辑设计;

3.3.2《概要设计书》评审

产品研发经理组织相关干系人对《概要设计书》进行评审。评审通过后,由配置组进行配置管理。

3.4视觉设计

?  视觉设计的主要工作是根据交互设计的低保真原型进行高保真视觉效果设计;

?  视觉设计主要内容为整体风格把握,包括页面颜色、元素外观、配图;

注:强调交互设计中的视觉设计,单独作为一项工作内容进行管理。

3.5详细设计

3.5.1《详细设计书》编制

《详细设计书》应包含以下内容:

?  模块接口设计

?  对用于持久化的文件进行设计,设计的内容应包含:文件的存放位置、文件名称、内容编码、内容结构、读写控制机制等;

?  对持久化内存数据进行设计,设计的内容应包含数据的存储格式、数据的缓存刷新机制、数据的读写时机和方式等;

?  对数据库进行物理设计。设计的内容应包含:表、视图、存储过程等;

?  模块功能设计

?  对模块/子模块的的命名空间进行设计。如对源代码的包结构进行设计;

?  对模块/子模块的内部功能流程进行设计,将功能和职责细分到具体的类;

?  对于核心的类进行属性和方法进行设计;

?  对复杂的计算进行算法设计;

?  共通功能设计

?  对异常、错误、消息和日志进行详细的设计;

?  对内存管理、线程管理等进行设计;

?  对系统性能诸如:抗压性、吞吐量、响应速度、安全性等进行进行设计;

3.5.2《详细设计书》评审

产品研发经理组织相关干系人对《详细设计书》进行评审。评审通过后,由配置组进行配置管理。

3.6 前端设计

?  前端设计是指根据视觉设计结果,进行CSS、HTML、JS进行编码;

?  前端设计的主要工作为:超文本结构设计、样式设计、交互效果实现、浏览器兼容设计、页面性能优化;

注:强调交互设计中的视觉设计,单独作为一项工作内容进行管理。

时间: 2024-08-28 07:04:06

概要设计、详细设计(一)概念、方法、实践步骤的相关文章

【设计】概要设计-详细设计-到底需要输出什么???

概要设计-详细设计 概要设计.详细设计:概念.方法.实践步骤-博客-云栖社区-阿里云 概要设计.详细设计(二) 设计的内容_可爱桑树_新浪博客 项目管理_可爱桑树_新浪博客 软件系统概要设计的三大要素 软件概要设计 - 天神一 - 博客园 概要设计与详细设计分别要做什么 - -Numeric- - 博客园 软件概要设计与详细设计的区别 - CSDN博客 详细设计_百度百科 概要设计_百度百科 [图文]大型软件系统的设计思路_百度文库 一分钟教你知道乐观锁和悲观锁的区别 - CSDN博客 原文地址

采用[ICONIX] 方法实践分析和设计之四 [健壮性分析]

在前三章中通过(问题域)建模和用例分析之后,在许多的UML书中可能接下来就要进行时序图和协同图的绘制了.但是问题好像还没那么简单,因为这里有一条鸿沟还没有跨过去,正如下图所示:                    在我刚学开始学习 UML时,在拿到用例文本时要去画时序图总感觉有些别扭,不知如何才能将文本中的意思完全用图的形式表达出来,总是感觉分析出来的文本中缺了一些很重要的东西, 而这些被丢掉的对象最终可能会导致无法绘制时序图,但又找不出用例文本中到底还有什么东西被遗漏,最终导致设计瘫痪.后来

采用[ICONIX] 方法实践分析和设计之五 [初步设计复核](转)

这一篇文章的内容有些对不住大家了.因为公司正在准备发布新产品(Discuz!NT2.0),大家的心思 全在产品上,因此构思内容和写作的时间几乎没有了,本人就偷了个懒,把书中认为很有必要让大家了解的 内容简单的抄上来.同时因为这一章主要的内容都是进行相应的用例文本和健壮性图的检查,以及更新域模 型(使之逐步向详细类图逼进),所以如果大家感兴趣的话,可以找几个人一起研究一下,相信大家一定会 有所收获的.最后我也希望在产品正式发布之后能够回过头来有时间进一步完善和补充相应的内容.再次向大家致歉了:(

采用[ICONIX] 方法实践分析和设计之一 [问题域建模](转)

前言:自从加入 Discuz!NT开发小组开始.我就放弃了以前的软件设计思想,转而去使用项目组所规范使用的架构设计思想和开发模式来进行开发.这样的时间一直持续到了今天.虽然我向往面向对象的开发方式,且向来对不够OO的设计存有偏见.但人必定要生存,特别是已经做了父亲的程序员来说,这种压力是不容回避的. 但今天开始的这一系列的文章将会说是一次对OO的一种回归.也可以说是对已有的设计思想的一种思考.在我从这中书柜上拿出这本已有两年多没再看的"用例驱动的UML对象建模应用--实例分析"(App

关于成本核算方法、步骤、成本分析的简单回复

关于成本核算方法.步骤.成本分析的简单回复成本核算的方法依据企业生产产品的特点来定:主要看产品是否是多步骤生产(生产工艺的特点):半成品是否有销售的情况(假设有销售,可能须要採用分步核算,以便准确核算半成品的成本):工作(成本/生产)中心是依照产品来分还是工艺来分.怎样核算成本:首先归集产品的材料成本,一般都须要技术部门提供产品的BOM(物料清单),以确保按订单或者生产计划生产的时候领料的准确.(通常会问生产线出现来料不良和损坏怎么处理:退仓并补领就可以,损坏部分须要当月预提计入制费,损坏材料报

采用[ICONIX] 方法实践分析和设计之六 [时序图](转)

采用[ICONIX] 方法实践BLOG设计之六 [时序图] 在前几篇文章中,我们分别进行了域模型和用例建模,并使用 Robustness工具进一步分析验证了相应用例的处理流程,并在相应模型(域模型)的基础上,通过Robustness方法引入相关的边界对象,控制对象(控制器),并更新了相应域模型中类的属性(字段).下面就可以进入到交互建模阶段了.如下图:    作为交互建模本身,就是要通过寻找对象之间的交互关系,进而进行方法(操作或行为)分配.    正所谓"只有在所有的用例为所有事件进程建立了交

采用[ICONIX] 方法实践分析和设计之二 [用例建模](转)

在上一篇文章中我们了解并进行了域建模,换言之我们有了一个好的开始,起码开发人员对自己要开发的软件已有了初步的认识,且也得到了进行交流时可以使用的术语表. 本章将会在前一篇的基本上进一步阐述使用ICONIX方法实践用例建模,同样在文章的最后还会有在这个阶段最容易犯的10个错误,以给大家提醒或在分析过程中进行参照.     本文在ICONIX方法中所处的位置如下图(红圈标记的地方)     在开始进行用例建模之前,我们需要对这一过程有一些粗线条的认识,如果您以前做过或学习过这方面的知识,可以把下面的

采用[ICONIX] 方法实践分析和设计之三 [需求复核](转)

需求复核旨在确保用例和域模型同时满足客户的功能性需求.同时确保客户知道开发小组将根据这些需求做何种设计.同时它也是系统分析阶段的一个里程碑(milestone).      这一阶段在ICONIX方法中的位置如下图:      三巨头的首次聚首:客户代表,开发小组代表,经理就已有的工具(用例,原型和域模型)帮助客户理解其需求,并确定系统的功能需求.在这一过程中,ICONIX方法认为可跟踪性(traceability)是非常关键的,它强调清楚每种需求是如何转换为一个或多个用例,以及域模型中的一个或

UIAutomator定位Android控件的方法实践和建议(Appium姊妹篇)

在本人之前的一篇文章<<Appium基于安卓的各种FindElement的控件定位方法实践和建议>>第二章节谈到Appium可以通过使用UIAutomator的方法去定位Android界面上的控件,当时只是一笔带过举了个例子.如该文给自己的承诺,今天特撰写此文以描述UIAutomator各种控件定位的方法,以作为前文的姊妹篇互通有无. 1. 背景 为了和前文达成一致,这次的实践对象同样也是使用SDK自带的NotePad应用,同样是尝试去获得在NotesList那个Activity里