软件系统设计总体思路_第1页
软件系统设计总体思路_第2页
软件系统设计总体思路_第3页
全文预览已结束

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1、系统设计得总体思路/软件-、概念软件设计得本质就就是针对软件得需求,建立模型,通过将模型映射为软件,来 解决实际问题。因此软件设计需要解决得核心问题就是建立合适得模型,使得能 够开发出满足用户需求得软件产品,并具有以下特性:灵活性(Flexibility) ?有效性(Efficiency):可靠性(Reliability) ?可理解性(Understandab?维护性(Hdintdindb订ity):重用性< Reuse-ab?适应性(Adaptab订ity):可移植性(Portability) ?可追踪性(Traceab订ity):互操作性(Interoperab订ity) ?因此,软

2、件设 计并没有一套放之四海而皆准得方法与模板,需要我们得设讣开发人员在软件得 设讣开发过程中针对软件项U得特点进行沟通与协调,整理出对软件项LI团队得 行之有效得方式,进行软件得设计。并保障软件设计文档得一致性,完整性与可 理解性。我们经常听到这样得话:“设计文档没有用,就是用来糊弄客户与管理层得文档”;'用来写设计文档得时间,我得开发早就做完了”;? “项目紧张,没有时间做设计”;软件开发设讣团队根据软件项LI得实际情况,这些言论,并不就是正确得观念, 可以约定设计文档得详细程度。项LI团队需要保障设计文档得完整性与一致性, 在项LI时间充裕得情软件设计文档可以更初略一些;在项LI进

3、度紧张得情况下, 需要软件设计开发团但就是在项II开发过程中,况下,相关文档可以更为详尽。 队对于设计文档有共同得理解。 二、设计文档分类与使用 通常来说, 作为软件项U,我们需要有这儿类文档需求说明文档:功能设计文档系统架构说明书模块概要设计文档:模块详细设计文档:就像我之前说到得,在某个 软件团队,对于以上得文档得要求就是可以完全不同得,在简单项目中,可能所 有类型得文档放在一个文档中进行说明;在复杂项口中,每一类文档可能都要写 儿个文档;而在最极端得情况下,可能每一类文档都能装订成儿册。因此,在我 们软件设计与开发人员心中需要明确得就是:文档并不就是我们进行设计得口 标,也不就是我们设计

4、过程中额外得工作。软件设讣文档就是我们在软件设计开发过程中形成得,用来在软件设计开发 团队内部以及与各干系人之间进行沟通得文档,这些文档记录了软件项U中 得各种知识,方案得思路.以及各种决策意见。三、软件设计开发过程下面我们就软件设计开发过程中必须要完成得丄作进行梳理,而我们需要注意到, 这些需要完成得工作,在不同得开发流程模型得指导下可能有不同得时间要求, 而我们需要关注得就是在这个阶段内需要完成得丄作,以及这个阶段内我们需要 沟通得人员。需求分析、1.需求分析就是我们进行任何一个软件项U设讣开发过程中都必须要完成得工作。 这个工作通常与客户一起完成。在不同得项H中,这个“客户”可能来自真正

5、得 购买产品得用户,使用系统得用户,也有可能来自团队得某个人员,如产品经理 等。软件设讣开发团队得参与成员根据项口得不同规模,则参与得人员也有所不 同。原则上,设计开发人员参与得时间点越早,对于需求得理解与把握会更好。 这个阶段,通常需要软件架构师参与其中。从资源优化得角度来说,开发人员不 必参与需求分析,但需要理解需求。需求分析得结果通常我们需要使用需求说明文档来描述,U前主流得需求描述方 法包括:用户例图、用户故事等方式。这些方式有所不同得侧重,其核心思想就 就是描述清楚用户得使用场景。但无论采取何种方式,进行需求得描述,需求说 明需要明确以下儿点:所需要开发得软件系统边界“系统所有得相关

6、及使用人员角色:系统关键得使用场景,系统规模、性能要求以及部署方式等非功能性需求"2、 功自g设计 功能设讣与需求分析差不多同时在开展,在很多软件项U中,对于功能设计不就 是特别重视。但对于某些软件项U而言,这就是一个相当重要得工作。对于主要 就是用户界面得软件项LI来说,功能设讣可以瞧作就是画出原型界面,描述使用 场景,获得用户认可得过程。而对于没有界面得软件项口来说,则功能设计与需 求分析得区分更为模糊。参与得人员与需求分析得参与人员类似,架构师更侧重于参与此类工作,并给与 一些实现层面得判断与取舍。功能设计需要明确得核心就是:系统得行为,系统架构设计、3.系统架构设讣就是一个非

7、常依赖于经验得设计过程。需要根据软件项LI得特定功 能需求与非功能性需求进行取舍,最终获得一个满足各方要求得系统架构。系统 架构得不同,将很大程度上决定系统开发与维护就是否能够较为容易得适应需求 变化,以及适应业务规模扩张。架构设讣工作中,用户参与程度很低。软件开发团队中得需求人员参与程度很低, 但团队中得所有核心设计与开发人员都应该参与其中,并达成一致意见。架构设计得主要成果,就是将系统得不同视图予以呈现,并使之落实到开发中: 系统开发视图及技术路线选择系统逻辑视图'系统部署视图:系统模块视图“系统得领域模型:在软件开发过程中,系统得架构不就是一成不变得,随着设计人员与开发人员对于系

8、统得理解不断深入,系统得架构也会发生演化。在 软件项LI中,架构设计就是开发团队沟通得统一语言,设计文档必须要随着系统 得变化进行更新,保障开发团队对于系统得理解与沟通得一致性。模块/子系统概要设计模块/子系统得概要设ilMli架构师参与,核心设计与开发人员负责得方式进行。 在概要设计工作中,我们需要在架构确定得开发路线得指导下,完成模块功能实 现得关键设计工作。在概要设计阶段,需要关注于模块得核心功能与难点进行设 计。这个过程中更多推荐得采用UML来进行概要设计,需要进行:模块实现机制设计“模块接口设计:关键类设计,画出时序图交互图等。,.5、模块详细设计在瀑布式开发模型中,模块得详细设计会要求比较严格,将所有类进行详细设计。 据我所知,除了一些对于系统健壮性要求非常严格得软件项U,如国防项金 融项U还要求有详细设计文档之外。其她得项L1大多采用其她方式来处理这样得 工作,如自动化测试等。综上所述,软件设计文档作为软件开发团队得沟通、理解、知识共享得手段,具 有非常重要得意义。而根据软件团队得规模,

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论