2块木板一夹,在四处乱跑的东西都要老实很多,如果是3木块板呢,我想它会被固定住。
对MIS类的详细设计报告而言:
第一块木板:需求规格说明书功能列表和分册,列表里面有功能点、分册里面有界面,那么这块木板就把详细设计报告的目录和实现的样子给确定了。专业点就是说面子已经固定下来,就是要长成这摸样,不要试图去韩国美容。
第二块木板:概要设计报告,概要设计在我的理解,它就是约定,也就是说一个业务的实现必须需要遵守的规则。这个就不是面子问题了,是强制,就是要这么走路,这么坐姿,这么吃饭,这么说话,这么这么什么的,这决定了是贵族还是平民的问题。
第三块木板:数据库设计报告(这个我们后面章节谈),决定了存储,就是掌控了锅碗瓢盆,掌握着吃饭的问题,要吃饭,可以,遵守我定的规则。
三块木板这么一夹,我们是不是觉得写详细设计报告就很清晰了,在我看来这种情况,就是边界的魅力,我们从需求开始一直在控制,一直在收敛。团队规模越大,意味着沟通会成为最重要的障碍,如果边界定的越不清晰,合作起来越痛苦,越多的扯皮。当然团队规模越小,边界越模糊,每个人都可能客串很多角色,只要沟通好,没歧义也行。
谈了这么多,我们找个例子来分享一下详细设计报告吧。
这个例子是《混在IT-(7)需求规则说明书案例分享》文章的延续,有人问,上章概要设计的时候为什么不用这个案例?呵呵,那是因为项目很小,成员也没几个,概要设计当时就是在会议室做了个约定,还做了现在都不知道跑到哪里去的会议纪要,因为有了需求规格说明书,本来还想详细设计不做了,后来想想还是做吧,不然与程序员沟通怎么和数据库实在交换太累了,这个可是比沟通什么架构复杂多了,也无趣。
开始贴图:
项目是使用.NET做的,数据库是SQL SERVER。通过10张图来展现。
[u]1、分册[/u]
详细设计报告可以根据分工不同或分类做成不同分册
[align=center][img]http://dl.iteye.com/upload/attachment/342079/7efe188a-1d75-3688-8dbf-3fd6c0132a69.jpg[/img][/align]
[u]2、分册中公共部分的目录[/u]
主要是定义输入输出
[align=center][img]http://dl.iteye.com/upload/attachment/342082/02726e53-35d6-3246-a881-cf71096e6202.jpg[/img][/align]
[u]3、实体类说明描述[/u]
[align=center][img]http://dl.iteye.com/upload/attachment/342085/3981aff6-462d-3f3e-9e7a-90a587469bf2.jpg[/img][/align]
[u]4、功能模块设计目录[/u]
[align=center][img]http://dl.iteye.com/upload/attachment/342087/a725be75-4d43-3c17-9ffb-f83c05aa7eae.jpg[/img][/align]
[u]5、目录内概述和分层列表[/u]
[align=center][img]http://dl.iteye.com/upload/attachment/342089/84375d09-84c6-30d9-ad3e-82e538026a70.jpg[/img][/align]
[u]6、目录内某一个业务逻辑的描述[/u]
[align=center][img]http://dl.iteye.com/upload/attachment/342091/f2764baa-6e7e-36ef-be25-d9c16bc83fce.jpg[/img][/align]
[u]7、目录内页面处理的文件名定义[/u]
[align=center][img]http://dl.iteye.com/upload/attachment/342093/56b28bed-78b4-32cd-9679-b1e688c096f3.jpg[/img][/align]
[u]8、目录内的用户界面和元素说明[/u]
是不是很熟悉,这个界面可是从需求规格说明书分册中复制过来的。
[align=center][img]http://dl.iteye.com/upload/attachment/342095/d813bec4-3ac8-37a7-8eec-04b91a33dd02.jpg[/img][/align]
[u]9、界面逻辑描述[/u]
[align=center][img]http://dl.iteye.com/upload/attachment/342097/a6e3f7c6-726e-3cc8-8ec3-d17ce8d13a1e.jpg[/img][/align]
[u]10、界面处理的事件[/u]
[align=center][img]http://dl.iteye.com/upload/attachment/342099/0687ff42-d1e3-352d-b2ca-004045de4f5d.jpg[/img][/align]
大家有仔细看哦,这里有几个重要的东西要重复一下
[b]实现功能和需求规格说明书功能列表的编号一致,在第5张图上
分层列表和文件列表和概要设计的约定一致,在第5和第7图上
界面和需求规格说明书分册的界面一致,在第8张图[/b]
我们从需求、概要、详设一起走过来,不知道大家是否有个感觉,我们只是解决了面上的问题,即有界面可以体现的需求,但是在实际项目中我们还会碰到很多没有界面的需求,这些需求也是要填进需求规格说明书,也要在概要中约定,也要在详设中设计。如外部接口、客户要求的算法等等。我们将在下一章专题讨论这些没有面子的需求该如何处理,看看我们是怎样套用前面讨论的思路。
对MIS类的详细设计报告而言:
第一块木板:需求规格说明书功能列表和分册,列表里面有功能点、分册里面有界面,那么这块木板就把详细设计报告的目录和实现的样子给确定了。专业点就是说面子已经固定下来,就是要长成这摸样,不要试图去韩国美容。
第二块木板:概要设计报告,概要设计在我的理解,它就是约定,也就是说一个业务的实现必须需要遵守的规则。这个就不是面子问题了,是强制,就是要这么走路,这么坐姿,这么吃饭,这么说话,这么这么什么的,这决定了是贵族还是平民的问题。
第三块木板:数据库设计报告(这个我们后面章节谈),决定了存储,就是掌控了锅碗瓢盆,掌握着吃饭的问题,要吃饭,可以,遵守我定的规则。
三块木板这么一夹,我们是不是觉得写详细设计报告就很清晰了,在我看来这种情况,就是边界的魅力,我们从需求开始一直在控制,一直在收敛。团队规模越大,意味着沟通会成为最重要的障碍,如果边界定的越不清晰,合作起来越痛苦,越多的扯皮。当然团队规模越小,边界越模糊,每个人都可能客串很多角色,只要沟通好,没歧义也行。
谈了这么多,我们找个例子来分享一下详细设计报告吧。
这个例子是《混在IT-(7)需求规则说明书案例分享》文章的延续,有人问,上章概要设计的时候为什么不用这个案例?呵呵,那是因为项目很小,成员也没几个,概要设计当时就是在会议室做了个约定,还做了现在都不知道跑到哪里去的会议纪要,因为有了需求规格说明书,本来还想详细设计不做了,后来想想还是做吧,不然与程序员沟通怎么和数据库实在交换太累了,这个可是比沟通什么架构复杂多了,也无趣。
开始贴图:
项目是使用.NET做的,数据库是SQL SERVER。通过10张图来展现。
[u]1、分册[/u]
详细设计报告可以根据分工不同或分类做成不同分册
[align=center][img]http://dl.iteye.com/upload/attachment/342079/7efe188a-1d75-3688-8dbf-3fd6c0132a69.jpg[/img][/align]
[u]2、分册中公共部分的目录[/u]
主要是定义输入输出
[align=center][img]http://dl.iteye.com/upload/attachment/342082/02726e53-35d6-3246-a881-cf71096e6202.jpg[/img][/align]
[u]3、实体类说明描述[/u]
[align=center][img]http://dl.iteye.com/upload/attachment/342085/3981aff6-462d-3f3e-9e7a-90a587469bf2.jpg[/img][/align]
[u]4、功能模块设计目录[/u]
[align=center][img]http://dl.iteye.com/upload/attachment/342087/a725be75-4d43-3c17-9ffb-f83c05aa7eae.jpg[/img][/align]
[u]5、目录内概述和分层列表[/u]
[align=center][img]http://dl.iteye.com/upload/attachment/342089/84375d09-84c6-30d9-ad3e-82e538026a70.jpg[/img][/align]
[u]6、目录内某一个业务逻辑的描述[/u]
[align=center][img]http://dl.iteye.com/upload/attachment/342091/f2764baa-6e7e-36ef-be25-d9c16bc83fce.jpg[/img][/align]
[u]7、目录内页面处理的文件名定义[/u]
[align=center][img]http://dl.iteye.com/upload/attachment/342093/56b28bed-78b4-32cd-9679-b1e688c096f3.jpg[/img][/align]
[u]8、目录内的用户界面和元素说明[/u]
是不是很熟悉,这个界面可是从需求规格说明书分册中复制过来的。
[align=center][img]http://dl.iteye.com/upload/attachment/342095/d813bec4-3ac8-37a7-8eec-04b91a33dd02.jpg[/img][/align]
[u]9、界面逻辑描述[/u]
[align=center][img]http://dl.iteye.com/upload/attachment/342097/a6e3f7c6-726e-3cc8-8ec3-d17ce8d13a1e.jpg[/img][/align]
[u]10、界面处理的事件[/u]
[align=center][img]http://dl.iteye.com/upload/attachment/342099/0687ff42-d1e3-352d-b2ca-004045de4f5d.jpg[/img][/align]
大家有仔细看哦,这里有几个重要的东西要重复一下
[b]实现功能和需求规格说明书功能列表的编号一致,在第5张图上
分层列表和文件列表和概要设计的约定一致,在第5和第7图上
界面和需求规格说明书分册的界面一致,在第8张图[/b]
我们从需求、概要、详设一起走过来,不知道大家是否有个感觉,我们只是解决了面上的问题,即有界面可以体现的需求,但是在实际项目中我们还会碰到很多没有界面的需求,这些需求也是要填进需求规格说明书,也要在概要中约定,也要在详设中设计。如外部接口、客户要求的算法等等。我们将在下一章专题讨论这些没有面子的需求该如何处理,看看我们是怎样套用前面讨论的思路。