软件设计是怎样炼成文档格式.docx
- 文档编号:14840828
- 上传时间:2022-10-25
- 格式:DOCX
- 页数:24
- 大小:970.64KB
软件设计是怎样炼成文档格式.docx
《软件设计是怎样炼成文档格式.docx》由会员分享,可在线阅读,更多相关《软件设计是怎样炼成文档格式.docx(24页珍藏版)》请在冰豆网上搜索。
2)这些需求,设计上是如何考虑实现的?
结果没有人能答上来!
我们从书本上看到的那些“通用”的设计标准,说得难听一点,就是废话!
对实际的项目工作基本上没有实质用途!
请看下面4个例子,分别思考这4个案例的软件设计思路,你会发现上述“漂亮设计的标准”,真的是废话!
案例1:
某项目要求在很短时间内完成,而且客户对系统的当前认识还是比较初步的,你打算怎样设计这个系统?
案例2:
某软件公司接了一个“网页+数据库”类型的项目,这类项目已经做过多个,但这次的业务却是新的,你怎样考虑这个项目的设计?
案例3:
某软件公司已经成功为n个医院做了管理系统,现在需要为一家新的大医院做类似这个系统,你会怎样考虑这个系统的设计?
案例4:
你接到一个任务,要做一个即时战略游戏,目标是要在当前游戏市场找中杀出一条血路,你怎样考虑这个游戏的设计?
4个案例各有特点,分别代表了4种“典型”:
需求很朦胧,工期很紧,技术上基本上没有积累。
需求是新的,但可以重用“网页+数据库”的技术架构。
需求是类似的,技术架构也是类似的,相信你会直接重用之前的系统。
这是一个需要创意和高技术含量的游戏,而游戏软件的需求和技术都是充满挑战的。
上述4种情况,相信你采取的设计策略是不一样的,你可能会发现所谓的优秀设计没有固定的标准。
如果硬是要来一个优秀设计的标准呢?
我会这样说:
就是做高性价比的设计!
一个优秀的设计应该具备以下特点:
1)优秀的设计都是需求驱动的,不熟悉需求就做出来的设计是不靠谱的;
2)优秀的设计应该是当前团队能理解能实现的,太超前的设计项目团队做不出来,这个设计只能是摆设;
3)优秀的设计应充分考虑当前各种限制条件,适当做出平衡,能保证达成项目的目标:
4)优秀的设计能尽量降低项目的整体工作量,让整个项目更加可控。
2.优秀的设计能节省项目工作量
关于软件设计的话题,如果脱离一些实际案例讨论的话,很容易变成空洞无力的学术讨论,所以本文将会列出很多案例供你参考。
设计案例:
开发某线上社区网站
背景:
某社区已经举办了多期沙龙活动,为了拓展沙龙的影响力,让更多朋友受益,树立良好品牌,将来实现盈利,有必要建立一个线上的社区网站。
该网站应有这样的功能:
1)发布各种活动信息。
2)发布业界新闻。
3)能开展线上沙龙活动,包括在线视频沙龙。
4)具备SNS社区,可汇聚人气。
5)每位会员有自己的博客,能维护自己的个人页面。
6)支持简体中文、繁体中文、英文三种语言随时切换。
7)支持全文搜索。
你打算如何设计上述系统呢?
你可能会问,有工期限制吗?
你说呢?
真实项目一定会有工期限制的,这个项目你的工期只有1个月!
你可能会说:
你当我是神仙啊,1个月有可能怎样死都死不出啊!
这个时候能帮助你的就是优秀的设计,优秀的设计有可能能让你用很少的工作量就做出来,优秀的设计也不一定需要你全部从零开发的,我们可以拿来主义!
有不少开源软件是可以基本满足上述要求的,我们可以直接拿来用,这样你需要付出的工作量就少很多了。
我曾经用某开源软件做了这样的一个网站出来,但发现没有全文搜索功能,结果我想了一个“投机取巧”的办法,自己不写一句代码,直接利用谷歌的这个搜索功能“site:
域名关键字”,让谷歌帮我搞定全文搜索。
当然这样做出来的效果还不是很完美,但至少我能在很短时间内能做出个大概啊,如果自己开发还不一定能做出这样的效果呢!
小结:
受工期限制、受能力限制等制约因素,十全十美的设计基本上是很难做到的,但如果因为赶工期而在软件设计上节省时间甚至是直接忽略这步,其实是得不偿失的。
在软件设计上“节省”1小时,可能会让你将来多投入成倍的项目时间;
越是工期紧,越需要冷静思考软件的设计,合适的设计能大大地降低项目工作量,让你后期的工作轻松很多。
3.优秀设计从分析需求开始
设计应该针对需求来做,这个大道理似乎人人都懂,但实际操作时往往就不是这样。
所以我们也不说大道理,直接通过一个“很简单”的案例来体验一下优秀设计应该如何从分析需求开始。
3.1案例挑战:
考勤系统的软件设计
某公司要做一个内部用的考勤系统,希望达成以下目标:
1)规范员工的上下班、请假、外出工作等行为。
2)方便计算员工的薪金。
3)方便管理各种带薪假期。
你如何考虑本系统的设计呢?
我靠,才三句话的需求,怎样做设计呢?
说得太好了!
我们做软件设计的,第一步并不是直接去设计,而是分析需求!
3.2如何分析需求?
当你接受一个项目的设计任务时,可能会遇到比较尴尬的情况,那就是需求有问题!
具体的情况可能有:
a)需求很简单,几句话或者是一页纸的需求。
b)需求很详细,可能有几十页甚至上百页,这些需求是招标书中提供的,或者是客户直接提供的。
不要以为有这么多需求是好事,这些需求通常是前后有点矛盾、逻辑有点混乱,甚至是不知所云滴!
c)你们有专门的部门或者专职完成了需求工作,提供了一份需求文档。
你也不要以为这是好事,因为很可能会出现这样的情况:
需求文档的提供者认为自己写的需求文档很牛逼,水平很高;
但负责实现的开发部门认为该文档质量太差,比方说:
不考虑实现的可能性和难度,没有考虑到客户的真正需求等等。
有时候甚至出现开发部门忽略掉需求部门,直接找客户重新调研,重新编写需求文档的情况。
上述三种情况一句话总结就是:
需求的质量有问题!
我们需要重新分析一次需求,先从业务角度审视一次,然后再从软件设计的视角审视一次。
通常我们需要按顺序思考以下问题:
1)什么人会使用这个系统?
2)不同的人将会使用这个系统的什么功能?
3)还有哪些不确定或不具体的需求点?
4)哪些需求对技术提出了怎样的要求?
5)系统的大致架构应该如何考虑?
下面开始我们看几个图,按顺序逐一思考一下上述的几个问题。
本小节回答问题1、2,后面的小节回答其他问题。
不少技术人员分析需求时往往是技术的视角,当你问他系统有什么用户时,你可能得到的结果有两种:
a)没有什么用户啊,所有人都是用户,因为系统只需要配置一下权限,谁都可以用。
b)系统有两种用户,就是:
用户和管理员。
我们从业务的角度来审视一下考勤系统的可能用户,请看下图:
图2.1系统可能用户分析
此图列出了如下可能用户:
employee:
员工
finance:
财务
receptionist:
前台
manager:
经理
seniormanager:
高级经理
administrator:
管理员
而上述用户还有这样的关系:
finanace(财务)、receptionist(前台)、manager(经理)继承employee(员工);
seniormanager(高级经理)继承manager(经理)。
用户之间的继承关系,是什么意思呢?
我们都知道代码中B类(子类)继承A类(父类),子类就具备了父类的特点。
用户之间的继承关系是相同的意思,我们继续看看下图你就可以理解了。
下图将会回答这个问题:
图2.2系统的需求分析
图2.1和图2.2都是UML的用例图,两个图加在一起比较完整系统地表达了以下问题:
a)什么角色会用本系统?
b)这些角色通过本系统分别能干什么事情?
c)角色之间有可能会有继承关系,请留意父类能干的事情,子类也能干,例如:
employee可以打卡,manager也可以打卡,尽管图2.2中manager没有直接与”打卡“相连,但图2.1中已经说明了manager继承employee。
UML是需求分析的有力工具,我的工作中很喜欢用UML。
但你的工作中、你的需求文档中可能会没有UML图,不管你们是否用UML图,分析需求时都需要从业务的角度思考这些问题:
a)什么人(角色)会用这个系统?
b)这些人(角色)分别需要用系统的什么功能?
需求分析其实是一个负责的高难度的话题,回答上述两个问题仅仅是需求分析的第一步而已,我们还需要深入分析业务,包括业务流程、业务数据结构等等。
如果之前的需求工作不到位,就需要我们立马开展软件设计工作,其实将会埋下很多地雷,后患无穷。
。
3.3找出设计关注点
本小节我们回答这两个问题:
软件设计师需要有敏锐的需求及设计触觉,看着图2.1和图2.2嗅出一些问题,你能嗅出一些问题吗?
请看下图:
图2.3系统的设计点分析
图2.3主要从设计的视角对需求再进行一次审视,以下是一些建议:
a)你需要更加深入思考需求,考虑到各种不同的业务场景和特殊情况,例如:
领导不在公司时如何审批请假?
b)你需要思考需求的细节,例如:
报表的具体形式?
c)你需要思考各种技术方案,例如:
打卡数据的同步方案,财务软件是否要对接等等?
d)你要做出平衡,用合适的方案和尽量少的工作量来满足需求。
3.4针对需求做初步的架构设计
本小节将会回答这个问题:
接下来你要做初步的架构设计了,架构设计是难度很高的事情,需要你全面考虑需求,考虑工期限制预算限制,考虑项目组人员的水平,而做出的一种平衡。
图2.4系统架构的考虑
图2.4是UML的部署图,这个图比较粗糙,而且为了降低大家阅读难度,我仅仅是用了部署图的最基本最少的语法来表达。
图2.4中的每一个立体的矩形,表示的就是物理上或者是逻辑上的一台设备,设备之间有物理连接的话就用线条连接,每台设备中”{}“括起来的文字是对该设备的进一步说明。
图可能是表达设计的最好方式,建议大家用UML,表达系统架构时,用UML的部署图、组件图和包图是比较合适的。
我们设计的系统多数是分布式系统,不是单机系统,用部署图来表达分布式系统的架构设计可能是比较合适的。
图2.4针对图2.3中提出的问题进行了初步的回应,图2.4就是一个初步的架构设计,当然后续我们还需要继续细化这个设计。
3.5小结:
如何需求驱动设计?
本篇的例子告诉我们:
1)优秀的设计是需要从分析需求开始的。
2)需求的质量可能有问题,那么我们需要从业务的角度重新审视一次。
3)从设计的角度审视需求,我们会提出很多需求细化及设计方案的问题。
4)架构设计是全面考虑各种需求、项目的工期限制预算限制,还有项目组人员水平后综合做出来的一种平衡。
4.软件系统不是木桶型的
4.1某种“需求直接驱动设计”的工作方法
案例分析:
某敏捷实践项目小组的设计方式
某项目小组正在如火如荼地实践敏捷,任务看板上已经粘贴了很多“用户故事”,项目小组经常在看板前讨论问题:
1)讨论每一个用户故事的实现方法,并进行估算;
2)项目小组成员领取用户故事,负责实现该用户故事;
3)每天检讨进度情况和遇到的问题。
该工作模式给项目小组带来了新鲜的动力,调动了大家的工作热情,取得一定的工作成绩,但也带来了一些思考:
1)只要我们将每一个用户故事的设计想好并实现,每个用户故事都能通过测试,软件就能完成?
2)用户故
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件设计 怎样
![提示](https://static.bdocx.com/images/bang_tan.gif)