2016-01-15 13:42:32 dhc566 阅读数 684

目 录

1 原则 4

2 目的 4

3 方案概述 4

4 软件技术序列的发展路线 5

5 方案概述 6

5.1 软件需求工序化 6

5.2 设计工序化 6

6 软件需求工序化详述 7

6.1 确定软件需求的含义 7




1 原则

软件生产工序化不是理论性的研究,而是各种理论的应用,这些理论可能包括计算机原理、软件开发模型、软件开发模式等。理论讲求全面,而实践讲求有效性。因此在进行工序化时,大家应该放弃概念之争①注,博采众家之长( 如何博采众家之长:在描述软件工序化时,会特别突出哪类是核心问题,如何解决某类问题。这需要大量理论的支持,但使用时可能仅使用核心理论 ),只为识别出有效的操作步骤,从而保证软件质量。

2 目的

软件的构建者往往有着不同的学习和工作经历,这些经历都是宝贵的财富,然而不同的经历会对软件的生产过程和生产方式产生不同的理解。本文重点是阐述一种机制,这种能将开发软件经验逐渐积累起来,用来规范和引导不同经历的人开发出同样品质的软件。这种机制以工序化的思想为依托,逐步完成软件生产各步骤的工序化。现阶段主要涉及软件需求、设计的工序化。

3 方案概述

---------创新源于传统

 

历史的车轮在不断前行,制造方式也从手工变为机械化,从而迎来了工业化。工业化的本质是生产的工序化,将某类产品工序化可以保证产品质量,从而达到量产的目的。

借鉴工业化的思想,将工序化的思想应用到软件生产中,称之为软件生产的工序化。软件生产的各个阶段都有相应的严格的方法,这种方法指导在软件生产过程中首先做什么,然后做什么,如何评价已完成的工作的质量。即为什么做、怎么做、如何评价。 

通过工序化方法保持软件质量,使开发的软件的质量在一定的水平线上,即要么开发的软件质量都差,要么都好。当发现更好的方法时需要积累好的方法,发现软件质量差时可以首先改进某些工序 ,使下次再进行软件生产时达到更高的水平。伴随着生产的软件数量和种类不断增加,不断完善这种方法。


软件技术序列的发展路线


技术序列需要有层次性,这种层次性为每个人提升自己的能力设立了目标,也为技术积累和内部组织提供一组解决方案,使整个开发集体逐渐成为一个团队。

个人清晰的提升目标,为个人工作建立了良好的基础,通过一步一步的训练逐步提高,为设计更好的系统打下基础。

技术积累需要有明确的方向,需要知道积累哪些技术、如何积累技术,明确的技术层次为技术积累建立了方向。

内部组织也将在技术积累中不断完善,在技术的越高层次,需要承担更多的任务和责任,从而建立一套基于责任的内部组织方式。

1中体现了在不同技术层次的上面临的困惑,解决这些困惑也就实现了一步步的技术积累。一个优秀的软件设计人员,需要具备图1中的各种能力,包括编码能力、独立模块设计能力、软件架构识别能力。之所以需要编码能力是因为,虽然软件的需求基本与开发语言无关、软件的设计中高层次也大部分与开发语言无关,但是设计的中低层次与开发语言有很大的关系,不同的语言实现同一种设计代码往往有很大差别。

5 方案概述

在进行软件生产工序化时,首先需要明确软件的生存周期,按照软件的生存周期划分工序。软件生存周期可分为:需求阶段、设计阶段、编码阶段、测试阶段、维护阶段,同时还有为之服务的软件开发计划制定。上面提到的各个工序都需要确定具体步骤以及各个步骤中具体的操作手段。现阶段先在需求和设计方面实现工序化。

任何的工序化都不是一个人能够完成的,需要团队共同努力,需要大家共同分享经验。分享经验时以专题为引导,比如将设计分成何种步骤,希望通过一个又一个专题,使大家学到和分享更多的经验。

你有一个思想,我有一个思想,大家交换每人都有两个思想。

5.1 软件需求工序化

将需求获取分为以下工序:

1:确定软件需求的含义。

2:界定软件的需求边界。

3:选取软件需求描述方法。

5.2 设计工序化

将设计分为以下工序:

1:明确设计对象。

2:明确什么是软件功能。

3:明确软件架构的含义、设计的重点及其表现方式。

     2 ,3两条参照《软件功能、软件设计思维方向.docx》。

4:找到合适的软件架构模式 。

5:确定架构中组件抽象功能。

6:将系统需求分配到构架中。

7:编写测试用例。

8:进行组件内部设计。

9:组织包图。

 

6 软件需求工序化详述

软件需求工序化首先应该明确软件需求到底是什么概念,在明确了概念后,还需要解决需求挖掘的问题。需求挖掘是获取软件需求最核心的问题,本文将会采用用例+名词解析的方法解决此问题。

6.1 确定软件需求的含义

明确需求的范围是做好软件需求的基础,这里需要首先明确用户需求、系统需求和软件需求的范围。

系统需求等价于用户需求,用户会描述系统的需要实现的功能②注。 

软件需求既要完整描述用户提出的功能需求,又要描述系统设计对软件的约束。软件需求描述用户需求这个众所周之,需要特别指出的是对系统需求对软件的约束。















2009-12-25 11:19:00 yah99_wolf 阅读数 3893

              软件设计漫谈之一:什么是软件设计?

“哇,设计!”

每当说起这个词,你的脑海里是否很快闪出“天才”、“灵感”、“创意”。。。。。。等词汇,同时闪现出一些戴着又大又圆的黑边眼镜,一边踱来踱去,忽而又两眼一亮,大叫一声“I got it”的设计师形象?甚至想起了达芬奇、米开朗琪罗等艺术家?

如果是这样的话,有两个消息要告诉你:坏消息是你理解错了,好消息是本文对你有帮助:)

 

“什么是设计?”

在回答这个问题的时候,如果你想去翻开某本厚厚的XXX规范或者协议,那么请你打消这个念头,我们不需要去看XXX标准或者协议的!@#%定义,那些定义没人看得懂,看懂了也没有用。我们需要通俗的说法,但通俗的就可能存在瑕疵,我们需要从通俗的说法中提炼出正确的说法。

1                 “设计就是找到解决问题的方法!”

这个说法是最直接、也最容易理解的,因为不管什么设计,当然是要最终能够解决问题,如果问题都没有解决,那设计本身就是错误的,这样的设计当然是不可取的。

但是,设计只是为了解决问题吗?

肯定不是,举个最简单的例子:如果你原意(不需要你很牛),你完全可以在main函数里面实现所有的功能,解决所有的问题,一个main函数写上几万甚至几十万都可以,功能上实现没有任何问题,但现实中你除了见到写“Hello, World”外,谁会这么做?

所以,“是否解决问题”是区分正确和错误的设计的标准,而不是区分好的设计和差的设计的标准

2                 “设计就是天才的创新!”

这个是最迷惑人的一个说法,也正是这个说法,让很多人对设计师都有一种崇拜的感觉。同时由于有这个想法,就想当然的认为自己不是天才,因此没法做设计!

现实中有这么多的问题需要天才才能解决么?其实你只要看看你周围就知道了:你的团队的设计师是天才么?你的做设计的朋友是天才么?如果你是设计师,你觉得你是天才么?

答案很简单,你我周围没有那么多的天才,但设计师却不少;你我周围绝大部分问题都不是需要达芬奇、米开朗琪罗、爱因斯坦才能解决的。设计不是艺术,也不是科学研究,只是一项普通的工作而已,因此,只要你努力,你也可以做设计!

当然,创新在设计中是必不可少的,没有灵感和创新,你就没法超越已有的设计;有了好的创新,才能够作出好设计!苹果公司做手机时间和诺基亚、魔头罗拉等相比要短得多,但苹果的Iphone却掀起了世界手机潮流,这就是创新的力量!

所以,“天才的创新”不是设计的必要条件,但却是优秀和伟大设计的必要条件!

3                 “设计之道就是平衡之道”

这个说法比较玄乎,但以我的经验和理解来看,这个说法是最接近正确的说法,理解这个说法的关键在于这个“平衡”是什么。

其实说穿了也没有什么玄乎的,“平衡”其实就是满足需求的功能属性的前提下,如何平衡需求的质量属性(需求的功能属性和质量属性请参考我的上一篇博文《需求分析的故事——如何练就需求分析的火眼金晴?》)。

为什么要平衡质量属性呢?简单来说就是因为质量属性是互相约束的,当一个属性变化时,必然会有另外的属性跟着改变,设计师必须在这些属性间进行平衡。

举个简单的例子:性能和成本,要想提高性能,成本就会跟着上升,可能是硬件成本(购买更好更贵的CPU),也可能是软件成本(软件重构、重写)。这种情况下,设计的平衡之道就体现出来了,你不可能只要性能,不考虑成本;也不可能只考虑成本,不考虑性能;只能在两者之间取一个完美的平衡点。即使是好评如潮苹果的IPhone,在售价上相信也是超出了大部分人的承受能力。

但是,把设计完全等同于平衡也是不正确的,如果永远都是在已有的东西里面做加减乘除,那么也就不会有创新了,只有创新才有可能解决所有的质量约束。比如:如果人类永远只盯着如何提高马车的速度和运力,那么火车就不会出现。

 

4                 再谈什么是设计

相信聪明的读者看到这里已经能够给出自己的答案了,我总结如下:

设计是一项创新和平衡的活动!要么创造一个新的东西来满足所有要求,要么就在已有的要求之间进行平衡。

 

2017-12-12 19:43:51 geniusli 阅读数 431

说到软件设计师都干点儿啥,很多人会想到写设计文档,画UML图,而我想从另一方面来说说

从职业类比说起

医生是个职业,医师、主治医师、主任医师是职称
律师是个职业,四级律师、三级律师、二级律师、一级律师是职称
程序员是个职业,你可以将软件设计师、软件架构师理解为职称

三种职业的相同点

医生一般是,通过检查确认身体的病因,寻找治疗方案,再进行治疗
抽象地说就是:分析问题,寻找解决方案,解决方案落地

律师一般是,通过对证据进行分析,在法律上找到解决纠纷的方法,打官司
抽象地说就是:分析问题,寻找解决方案,解决方案落地

程序员一般是,通过分析要实现的功能,梳理设计思路,写代码
抽象地说就是:分析问题,寻找解决方案,解决方案落地

这三种职业及其相似,都是在:分析问题,寻找解决方案,解决方案落地

三种职业的不同点

这三种职业的不同点也很明显,就是:问题所处的领域不同

不同职称有何区别

以医生为例,我父亲生病住院,主治医师当晚就说,可能是GBS。第二天主任医师查房,要求做CT和脊髓穿刺,排除中枢神经的一些病变并确诊是GBS。
抽象地说就是:主任能从更高的层次、更大的范围,去分析问题并寻找解决方案

所以,比起普通程序员,软件设计师也是一样,能从更高的层次、更大的范围,去分析问题并寻找解决方案

结论

软件设计师都干点儿啥?
软件设计师也是程序员,除了写代码之外,软件设计师可以解决更高的层次、更大的范围的问题。
更高层次和更大范围的问题的解决方案,描述起来需要用更宏观的方式,这就是UML。虽然解决方案最终也是用代码实现,但如果要描述并讨论解决方案,会由于代码太细致,导致只见树木不见森林。
UML只不过是描述解决方案的一种工具,并且在软件行业已经达成一致,所以它非常有利于交流。

进行软件设计

找需求人员把问题理解清楚,分析问题并思考解决方案,把解决方案用UML描述出来,这就是软件设计。
软件设计的过程不需要面面俱到的文档,只要能自己想清楚,并且用UML描述出来就行了。
思考的过程,会发现很多需求的细节,过程中应该和需求人员深入地讨论。

设计评审

往往会有多个方案拿不准,或者自己的方案担心有缺陷,这就需要设计评审了。
设计评审更不应该有面面俱到的文档,我的经验是:

把设计草图画在纸上,拍个照
把大家召集在一起,一定要有白板
大家一边看你的设计草图(投影或显示器),一边讨论,一边在白板上重绘
将白板上的结论拍照留底,直到所有问题讨论结束

写设计文档

设计文档就是把问题描述清楚,再把解决方案描述清楚就可以了。
解决方案就是设计评审通过时,大家在白板上绘制的照片。
具体的方法和模板,在下一篇有详细描述。

2013-01-05 21:38:16 shuqin1984 阅读数 745


      软件设计师的价值

      一个软件设计师必须提供足够分量的价值和服务,才能为这项工作带来荣耀。

       一个软件设计师的职责应该包括以下几点:

            1.  编程开发: 专注于 软件框架、 API 的设计、实现和改进,提供问题的优雅解决方案;

            2.  项目重构: 能够提出中肯的意见,作出重要的改进;

            3.  项目启动: 与软件架构师、需求方等多方协作,参与项目的总体规划和设计,确保项目的长远发展。

        一位真正的软件设计师, 他需要通过编程来实践自己的理念,否则就没有什么事例来说服别人。软件设计与程序开发应该是一脉相承的,而不是交集很少的事情的两端。软件设计师与开发者的根本差异在于关注角度和思考维度的不同,而不在于是否编程的形式。

        一个软件设计师的心应该是足够自由的,宁可暂时性失业,也不受外界的影响和逼迫, 唯有如此, 才能汲取各种灵感, 创作出真正杰出的设计。   


       软件设计的作用

       软件设计是代码组织的学问和艺术,将应用逻辑组织为一系列一致性强的、可读性好的、易维护的、容易扩展的、小型的逻辑工作单元。软件架构则是数据组织的学问和艺术,从更全局的角度来思考数据的最大化利用,探索业务需求、实现产品功能的系统总体结构,

        软件架构的作用是使基于其上构建的应用系统能够很好地适应业务需求和拓展, 以尽可能小的成本(时间、人力、资源、管理等)实现系统后续的改进、修复和扩展。在系统构建初期,主要作用在于确保系统的性能满足需求以及稳定可靠地运行; 确立一个系统发展的长远目标,增强系统的可维护性和可扩展性。最首要的一条设计原则是开闭原则: 对修改关闭,对扩展开放。

        由于软件架构是必须适应业务需求和扩展的,因此,不存在万能的软件架构; 不过,幸运的是,对于各种类型的应用系统, 都有一些成功的实践案例可供借鉴,有一些通用的设计思想和方法可以学习汲取,一些通用的基础设施可以重用。 

         

         小设计与大设计

         小设计是指,对于任意一个问题,从设计的角度进行思考和解决,从而获得一个整体上的优雅的思路和解决方案(而不是权宜之计);

          大设计是指,针对复杂的软件(子)系统或组件,从整体宏观兼顾微观的角度进行考量,获得一个整体的系统构架图以及一系列重要决策,作为具体开发实现时的关键指导。


         软件设计的基本问题

         如何保证系统的健壮性、可靠性和稳定运行?

             1.  保证业务逻辑严谨可靠:  ---->     编写短小函数、短小类;  充分单元测试;

             2.  所有的错误和异常都得到处理 ---->  考虑所有可能的错误情形和异常情形,给出合理的提示或跳转行为;

             3.  深入理解框架和组件,洞悉应用框架、组件之间的交互 ---->  配置要正确; 参数调优;

             4.  避免内存泄漏, CPU 压力负载测试良好;

             5.  适应动态变化。

 



2018-03-25 10:22:52 u010193457 阅读数 12388

软件的需求分析阶段知道系统要“做什么”,而软件设计阶段我们明白的是“怎么做”。
软件的设计分为:总体设计&&详细设计

设计基本原理:



总体设计的任务和过程

总体设计分为:面向数据,面向功能,面向对象的分析


设计原则:独立性,规模,深,宽,入,出。作用域。接口。单入单出。预测(黑盒子)

总体设计图形工具

1.层次图:描述层次结构。
2.HIPO图:在层次图的基础上,把图中除了顶层的方框外都加上编号****基本形式:输入,处理,输出。
3.结构图(SC):表达程序结构图形的表示方法,反映程序模块间的层次关系和联系。
成分:模块,模块间调用关系,通信,辅助控制符号。
结构图的四中类型:传入,传出,变换,协调
结构图VS数据流图
数据流图反映的是程序中数据流的情况
结构图反映的是程序中控制流的情况
结构图VS程序流程图
Battle1:
结构图着重反映模块间的隶属关系,即调用关系和层次关系。
程序流程图表达程序执行的顺序及执行顺序依赖的条件。
Battle2:
结构图着眼于软件系统的总体结构,不涉及内部细节,只考虑模块作用,以及上下级模块关系

程序流程图表达执行程序的具体算法


面向数据流的设计方法

目标:给出设计软件结构的一个系统化途径。
作用:信息流映射成软件结构。
映射的方法由信息流的类型决定
    信息流的类型分为两类
 1.变换流:信息-->系统-->外换内-->加工-->内换外-->离开。
    变换型系统结构图:输入,变换中心,输出。
 2.事务流:信息-->输入-->处理-->输入类型选动作-->执行
    根据信息流类型,进行不同的分析。
       变换分析:把具有变换流特点的数据流图按预先确定的模式映射成软件结构
       事务分析:设计步骤跟变换分析类似,不同之处是数据流图到软件结构的映射方式不同。事务流映射的软件结构包括一个接收分支和一个发送分支。


没有更多推荐了,返回首页