⾃从1968年提出“软件⼯程”概念以来，软件开发领域对于借鉴传统⼯程的原则、⽅法，以提⾼质量、降低成本的探索就从未停⽌过。⽽在这个过程中，提出了许多不同的软件开发模型，典型的有：瀑布式，快速原型法，以及迭代式开发等。 瀑布式模型
是由W.W.Royce在1970年最初提出的软件开发模型，在瀑布模型中，开发被认为是按照需求分析，设计，实现，测试 (确认)， 集成，和维护顺序的进⾏。新安琪儿
快速原型法
快速原型模型的第⼀步是建造⼀个快速原型，实现客户或未来的⽤户与系统的交互，⽤户或客户对原型进⾏评价，进⼀步细化待开发软件的需求。通过逐步调整原型使其满⾜客户的要求，开发⼈员可以确定客户的真正需求是什么；第⼆步则在第⼀步的基础上开发客户满意的软件产品。 迭代式开发
在迭代式开发⽅法中，整个开发⼯作被组织为⼀系列的短⼩的、固定长度（如3周）的⼩项⽬，被称为⼀
系列的迭代。每⼀次迭代都包括了需求分析、设计、实现与测试。采⽤这种⽅法，开发⼯作可以在需求被完整地确定之前启动，并在⼀次迭代中完成系统的⼀部分功能或业务逻辑的开发⼯作。再通过客户的反馈来细化需求，并开始新⼀轮的迭代。
不同的开发模型，对于设计阶段的⼯作要求也不尽相同。相对来说，瀑布式模型中对于设计⽂档的粒度要求得最细，⽽快速原型法对于设计的要求⼀般来说⽐较弱，迭代式开发在每⼀阶段中的设计⽂档⼯作量都相对较少，但在软件开发完成后，最终的设计⽂档完善程度要⽐快速原型法的好。
软件设计的总体思路
软件设计的本质就是针对软件的需求，建⽴模型，通过将模型映射为软件，来解决实际问题。因此软件设计需要解决的核⼼问题是建⽴合适的模型，使得能够开发出满⾜⽤户需求的软件产品，并具有以下特性： 灵活性（Flexibility）
有效性（Efficiency）
可靠性（Reliability）
可理解性（Understandability）
维护性（Maintainability）
重⽤性（Reuse-ability）
适应性（Adaptability）
可移植性（Portability）
可追踪性（Traceability）
互操作性（Interoperability）
因此，软件设计并没有⼀套放之四海⽽皆准的⽅法和模板，需要我们的设计开发⼈员在软件的设计开发过程中针对软件项⽬的特点进⾏沟通和协调，整理出对软件项⽬团队的⾏之有效的⽅式，进⾏软件的设计。并保障软件设计⽂档的⼀致性，完整性和可理解性。
谁来进⾏软件设计
在我们开发⼈员中，有很多⼈这样理解：“软件设计⽂档就是软件架构师和设计⼈员的事情”，其实不然。设计⽂档是整个软件开发团队的产出，其中有些设计⽂档由架构师或者设计⼈员给出，有些⽂档由开发⼈员给出。这并没有⼀定的区分。
最佳实践
我们经常听到这样的话：
“设计⽂档没有⽤，是⽤来糊弄客户和管理层的⽂档”；
“⽤来写设计⽂档的时间，我的开发早就做完了”；
“项⽬紧张，没有时间做设计”；
这些⾔论，并不是正确的观念，根据软件项⽬的实际情况，软件开发设计团队可以约定设计⽂档的详细程度。项⽬团队需要保障设计⽂档的完整性和⼀致性，在项⽬进度紧张的情况下，软件设计⽂档可以更初略⼀些；在项⽬时间充裕的情况下，相关⽂档可以更为详尽。但是在项⽬开发过程中，需要软件设计开发团队对于设计⽂档有共同的理解。
设计⽂档分类与使⽤
通常来说，作为软件项⽬，我们需要有这⼏类⽂档
需求说明⽂档
功能设计⽂档奋进的旋律评价
系统架构说明书
模块概要设计⽂档
模块详细设计⽂档
就像我之前说到的，在某个软件团队，对于以上的⽂档的要求是可以完全不同的，在简单项⽬中，可能所有类型的⽂档放在⼀个⽂档中进⾏说明；在复杂项⽬中，每⼀类⽂档可能都要写⼏个⽂档；⽽在最极端的情况下，可能每⼀类⽂档都能装订成⼏册。因此，在我们软件设计和开发⼈员⼼⽬中需要明确的是：⽂档并不是我们进⾏设计的⽬标，也不是我们设计过程中额外的⼯作。
软件设计⽂档是我们在软件设计开发过程中形成的，⽤来在软件设计开发团队内部以及与各⼲系⼈之间进⾏沟通的⽂档，这些⽂档记录了软件项⽬中的各种知识，⽅案的思路、以及各种决策意见。
下⾯我们就软件设计开发过程中必须要完成的⼯作进⾏梳理，⽽我们需要注意到，这些需要完成的⼯作，在不同的开发流程模型的指导下可能有不同的时间要求，⽽我们需要关注的是在这个阶段内需要完成的⼯作，以及这个阶段内我们需要沟通的⼈员。
需求分析
需求分析是我们进⾏任何⼀个软件项⽬设计开发过程中都必须要完成的⼯作。
双宿主机防火墙这个⼯作通常与客户⼀起完成。在不同的项⽬中，这个“客户”可能来⾃真正的购买产品的⽤户，使⽤系统的⽤户，也有可能来⾃团队的某个⼈员，如产品经理等。软件设计开发团队的参与成员根据项⽬的不同规模，则参与的⼈员也有所不同。原则上，设计开发⼈员参与的时间点越早，对于需求的理解和把握会更好。这个阶段，通常需要软件架构师参与其中。从资源优化的⾓度来说，开发⼈员不必参与需求分析，但需要理解需求。
需求分析的结果通常我们需要使⽤需求说明⽂档来描述，⽬前主流的需求描述⽅法包括：⽤户例图、⽤户故事等⽅式。这些⽅式有所不同的侧重，其核⼼思想就是描述清楚⽤户的使⽤场景。但⽆论采取何种⽅式，进⾏需求的描述，需求说明需要明确以下⼏点：
所需要开发的软件系统边界
系统所有的相关及使⽤⼈员⾓⾊
系统关键的使⽤场景
系统规模、性能要求以及部署⽅式等⾮功能性需求
功能设计
功能设计与需求分析差不多同时在开展，在很多软件项⽬中，对于功能设计不是特别重视。但对于某些软件项⽬⽽⾔，这是⼀个相当重要的⼯作。对于主要是⽤户界⾯的软件项⽬来说，功能设计可以看作是画出原型界⾯，描述使⽤场景，获得⽤户认可的过程。⽽对于没有界⾯的软件项⽬来说，则功能设计与需求分析的区分更为模糊。
迟华东参与的⼈员与需求分析的参与⼈员类似，架构师更侧重于参与此类⼯作，并给与⼀些实现层⾯的判断和取舍。
功能设计需要明确的核⼼是：
系统的⾏为
系统架构设计
系统架构设计是⼀个⾮常依赖于经验的设计过程。需要根据软件项⽬的特定功能需求和⾮功能性需求进⾏取舍，最终获得⼀个满⾜各⽅要求的系统架构。系统架构的不同，将很⼤程度上决定系统开发和维护是否能够较为容易的适应需求变化，以及适应业务规模扩张。
架构设计⼯作中，⽤户参与程度很低。软件开发团队中的需求⼈员参与程度很低，但团队中的所有核⼼设计和开发⼈员都应该参与其中，并达成⼀致意见。
架构设计的主要成果，是将系统的不同视图予以呈现，并使之落实到开发中：
系统开发视图及技术路线选择
系统逻辑视图
系统部署视图
系统模块视图
系统的领域模型
在软件开发过程中，系统的架构不是⼀成不变的，随着设计⼈员和开发⼈员对于系统的理解不断深⼊，系统的架构也会发⽣演化。在软件项⽬中，架构设计是开发团队沟通的统⼀语⾔，设计⽂档必须要随着系统的变化进⾏更新，保障开发团队对于系统的理解和沟通的⼀致性。
模块/⼦系统概要设计
模块/⼦系统的概要设计，由架构师参与，核⼼设计和开发⼈员负责的⽅式进⾏。
在概要设计⼯作中，我们需要在架构确定的开发路线的指导下，完成模块功能实现的关键设计⼯作。
在概要设计阶段，需要关注于模块的核⼼功能和难点进⾏设计。这个过程中更多推荐的采⽤UML来进⾏概要设计，需要进⾏：
模块实现机制设计
模块接⼝设计
关键类设计
画出时序图
交互图等。
模块详细设计
在瀑布式开发模型中，模块的详细设计会要求⽐较严格，将所有类进⾏详细设计。据我所知，除了⼀些对于系统健壮性要求⾮常严格的软件项⽬，如国防项⽬，⾦融项⽬还要求有详细设计⽂档之外。其他的项⽬⼤多采⽤其他⽅式来处理这样的⼯作，如⾃动化测试等。
综上所述，软件设计⽂档作为软件开发团队的沟通、理解、知识共享的⼿段，具有⾮常重要的意义。
⽽根据软件团队的规模，对于⽂档上承载的信息详细程度可以有不同程度的要求。我们软件团队对于*如何使⽤设计⽂档有⼀个统⼀的理解，并坚持更新设计⽂档*，这就是软件设计的最佳实践！
软件设计所需要的知识与技能
UML 统⼀建模语⾔
渔港之夜软件⼯程
⾯向对象的编程 OOP
操作系统
莱州湾论坛数据库原理
设计模式
沟通能⼒
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议