第一篇:软件工程生命周期模型的学习总结
综述
软件过程定义了软件开发中采用的方法。软件工程是集成计算机软件开发的过程、方法和工具的学科。
软件工程的一般视图:定义阶段(做什么)、开发阶段(如何做)、支持阶段(变化)。线性顺序模型
有时被称为“传统生存周期或瀑布模型”。
活动包括:系统/信息工程和建模、软件需求分析、设计、代码生成、测试、支持 为什么线性模型有时候不能奏效?
建议:虽然线性模型经常被嘲笑为“旧式的”,但是,在需求被很好理解的情况下,它仍然是一种合理的方法。缺点:
1、实际的项目大部分情况难以按照该模型给出的顺序进行,而且这种模型的迭代是间接的,这很容易由微小的变化而造成大的混乱。
2、经常情况下客户难以表达真正的需求,而这种模型却要求如此,这种模型是不欢迎具有二义性问题存在的。
3、客户要等到开发周期的晚期才能看到程序运行的测试版本,而在这时发现大的错误时,可能引起客户的惊慌,而后果也可能是灾难性的。
4、采用这种线性模型,会经常在过程的开始和结束时碰到等待其他成员完成其所依赖的任务才能进行下去,有可能花在等待的时间比开发的时间要长。我们称之为“堵赛状态”。
优点:
1、它提供了一个摸板,这个摸板使得分析、设计、编码、测试和支持的方法可以在该摸板下有一个共同的指导。
2、虽然有不少缺陷但比在软件开发中随意的状态要好得多。
瀑布模型将软件开发活动分为需求分析、设计、编码、测试等几个阶段,这几个阶段是对工程活动的划分,瀑布模型没有再涉及其它方面的活动,因此瀑布模型关注于工程活动。
关于选取开发模型
有时开发模型的选取不是很容易判断的,这里面有时不单是需求及开发的问题,对于开发商有开发周期、开发费用的问题,对于用户同样有内部计划、公司发展计划等因素进行影响。
一般来说对于应用开发―――为客户开发软件,客户在开发及测试完毕软件后就要实际开始使用,那么就使用瀑布模型。
当然在需求明确的情况下自然也要使用瀑布模型
对于自主开发及客户需求不明并有较长的设计时间―――可以用演化模型。
而螺旋模型适于适合于大型软件开发,吸收了“演化”概念,不过有时也用于用户需求不明的情况下。当然还有其他开发模型,没有在本文讨论。名词定义:
瀑布模型:规定了各项软件工程活动。包括:制定开发计划、进行需求分析和说明、软件设计、程序编码、测试及维护。
特点:自上而下,相互衔接的固定次序,如瀑布流水、逐级下落。
演化模型:第一次只是试验开发,其目标只在于探索可行性,弄清软件需求;第二次则在此基础上获得较为满意的软件产品,通常把一次得到的试验性产品称“原型”。特点:减少由于软件需求不明确而给开发带来的风险。
螺旋模型:将瀑布模型及演化螺旋模型结合起来,并且加入被两种模型都忽略了的风险分析,弥补了两者的不足。
瀑布模型的特点:
① 瀑布模型为软件的开发和维护提供了一种有效有管理模式,对保证软件产品的质量有重要的作用;
② 可根据这一模式制定出开发计划,进行成本预算,组织开发力量,以项目的阶段评审和文档控制为手段,有效地对整个开发过程进行指导; ③ 在一定程度上消除非结构化软件、降低软件的复杂度、促进软件开发工程化方面起到显著作用;
④ 瀑布模型缺乏灵活性、无法通过开发活动来澄清本来不够确切的需求,这将导致直到软件开发完成时发现所开发的软件并非是用户所需求的。原型实现模型
原型实现范型定义: 需求收集 快速设计
原型实现模型是迭代的,是帮助客户或开发者理解需求的,总体上讲,并不是交付一个最终产品系统。其流程从听取客户意见开始、随后是建造/修改原型、客户测试运行原型、然后回头往复循环直到客户对原型满意为止。由于这种模型可以让客户快速的感受到实际的系统(虽然这个系统不带有任何质量的保证),所以客户和开发者都比较喜欢这种过程模型(对于那些仅仅用来演示软件功能的公司而言或从来不考虑软件质量和不害怕长期维护的公司而言)。缺点:
1、没有考虑软件的整体质量和长期的可维护性。
2、大部分情况是不合适的操作算法被采用目的为了演示功能,不合适的开发工具被采用仅仅为了它的方便,还有不合适的操作系统被选择等等。
3、由于达不到质量要求产品可能被抛弃,而采用新的模型重新设计。
优点:
1、如果客户和开发者达成一致协议:原型被建造仅为了定义需求,之后就被抛弃或者部分抛弃,那么这种模型很合适了。
2、迷惑客户抢占市场,这是一个首选的模型。
原型实现仍然是软件工程的一个有效范型。关键是定义开始时的游戏规则,即客户和开发者达成一致:原型被建造仅是为了定义需求,之后就被抛弃了(或至少部分被抛弃),实际的软件在充分考虑了质量和可维护性之后才被开发。
建议:当你的客户有一个合理的续签,但对细节没有任务线索时,先开发一个原型。
原型模型则主要是为了解决需求获取的难题而创建原型用于需求的获取和确认,再将需求转化为软件系统,其主要内容集中在软件开发本身,因此原型模型也关注于工程活动。RAD模型
快速应用开发(Rapid Application Development、RAD)是一个增量型的软件开发过程模型,强调极短的开发周期。是线性顺序模型的一个“高速”变种,通过使用基于构件的建造发放赢得了快速开发。如果需求理解的好而且约束了项目的范围,利用这种模型可以很快的创建出功能完善的“信息系统”。其流程从业务建模开始,随后是数据建模、过程建模、应用生成、测试及反复。RAD过程强调的是复用,复用已有的或开发可复用的构件。实际上RAD采用第四代技术。基于构件的软件工程(不理解)适用范围:
如果需求理解得很并且约束了项目范围。主要适用于信息系统应用,包括以下阶段:业务建模、数据建模、过程建模、应用生成、测试及反复。
业务建模工作流程与其他工作流程的关系如下:
业务模型是需求工作流程的一种重要输入,用来了解对系统的需求。
业务实体是分析设计工作流程的一种输入,用来确定设计模型中的实体类。
缺点:
1、只能用于信息系统。
2、对于较大的项目需要足够的人力资源去建造足够的RAD组。
3、开发者和客户必须在很短的时间完成一系列的需求分析,任何一方配合不当都会导致RAD项目失败。
4、这种模型对模块化要求比较高,如果有哪一功能不能被模块化,那么建造RAD所需要的构件就会有问题。
5、技术风险很高的情况下不适合这种模型。
优点:
1、开发速度快,质量有保证。
2、对信息系统特别有效。演化软件过程模型
演化模型是迭代的。它的特征是:使软件工程师渐进地开发逐步完善的软件版本。
5.1 增量模型
增量模型融合了线性顺序模型的基本成分(重复的应用)和原型实现的迭代特征。增量模型采用随着日程时间的进展而交错的线性序列。每一个线性序列产生软件的一个可发布的“增量”。当使用增量模型时,第一个增量往往是核心的产品,也就是说第一个增量实现了基本的需求,但很多补充的特征还没有发布。客户对每一个增量的使用和评估,都做为下一个增量发布的新特征和功能。这个过程在每一个增量发布后不断从复,直到产生了最终的完善产品。增量模型强调每一个增量均发布一个可操作的产品。
缺点:
1、至始至终开发者和客户纠缠在一起,直到完全版本出来。
优点:
1、人员分配灵活,刚开始不用投入大量人力资源,当核心产品很受欢迎时,可增加人力实现下一个增量。
2、当配备的人员不能在设定的期限内完成产品时,它提供了一种先推出核心产品的途径,这样就可以先发布部分功能给客户,对客户起到镇静剂的作用。
3、具有一定的市场。
增量模型将瀑布模型的顺序化和多次迭代相结合,每个增量开发都是一次瀑布模型的过程,强调每一个增量均发布一个可运行版本,以满足客户和市场的需要。增量模型主要考虑当需要快速推出可运行的版本,而该版本不需要完整的功能时,在工程活动上的解决方案,因此增量模型也关注于工程活动。
5.2 螺旋模型
这是一个演化软件过程模型,它将原型实现的迭代特征和线性顺序模型中控制的和系统化的方面结合起来。使得软件的增量版本的快速开发成为可能。在螺旋模型中,软件开发是一系列的增量发布。在每一个迭代中,被开发系统的更加完善的版本逐步产生。螺旋模型被划分为若干框架活动,也称为任务区域。典型地,有3到6个任务区域:
1、客户交流:建立开发者和客户之间有效通信所需要的任务。
2、计划:定义资源、进度、及其它相关项目信息所需要的任务。
3、风险分析:评估技术的及管理的风险所需要的任务。
4、工程:建立应用的一个或多个表示说需要的任务。
5、构造及发布:构造、测试、安装和提供用户支持所需要的任务。
6、客户评估:基于对在工程阶段产生的或在安装阶段实现的软件表示的评估,获得客户反馈所需要的任务。
这是一个相对较新的模型,它的功效还需要经历若干年的使用方能确定下来。
缺点:
1、需要相当的风险分析评估的专门技术,且成功依赖于这种技术。
2、很明显一个大的没有被发现的风险问题,将会导致问题的发生,可能导致演化的方法失去控制。
3、这种模型相对比较新,应用不广泛,其功效需要进一步的验证。
优点:
1、对于大型系统及软件的开发,这种模型是一个很好的方法。开发者和客户能够较好地对待和理解每一个演化级别上的风险。
螺旋模型的主要贡献在于明确提出迭代概念和风险的问题,并指出在项目定义、需求、设计等阶段均存在风险,需要重点考虑,并通过多次迭代的原型主动诱发风险。风险管理不属于工程活动的范围,但我们仍然认为螺旋模型的主要内容是工程方面的:因为对于非工程活动,螺旋模型仅考虑了风险问题,而风险管理仅是非工程活动的一个小部分,不足以依此推断螺旋模型主要关注于非工程活动。
5.3 WINWIN螺旋模型
螺旋模型提出了强调客户交流的一个框架活动。该活动的目标是从客户处诱导项目需求。在理想情况下,开发者简单地询问客户需要什么,而客户提供足够的细节进行下去。不幸的是这种情形很少发生。在现实中,客户和开发者进入一个谈判过程,客户被要求在成本和应市之间的约束下平衡功能、性能、和其它产品或系统特征。最好的谈判追求“双赢”结果,也就是说通过谈判客户获得大部份系统的功能,而开发者则获得现实的和可达到的预算和时限。对客户的交流定义了下面的活动:
1、系统或子系统的关键“风险承担者”的标识。
2、风险承担者的“赢条件”的确定。
3、风险承担者的赢条件谈判,以将它们协调为一组满足各方考虑的双赢条件。
缺点:
1、需要额外的谈判技巧。
优点:
1、客户和开发者达到一种平衡。
5.4 并发开发模型
这种模型关注于多个任务的并发执行,表示为一系列的主要技术活动、任务及它们的相关状态。并发过程模型是由客户要求、管理决策、评审结果驱动的。该模型不是将软件工程活动限定为一个顺序的事件序列,而是定义了一个活动网络。网络上的每一个活动均可于其它活动同时发生。这种模型可以提供一个项目的当前状态的准确视图。
缺点:暂时无
优点:
1、可用于所有类型的软件开发,而对于客户/服务器结构更加有效。
2、可以随时查阅到开发的状态。基于构件的开发模型
面向对象的技术为软件工程的基于构件的过程模型提供了技术框架。面向对象模型强调了类的创建、类的封装了的数据、操纵该数据的算法。一般来讲经过合适的设计和实现,面向对象的类可以在不同的应用及基于计算机的系统的体系结构中复用。基于构件的开发模型融合了螺旋模型的许多特征,它本质上是演化形的,要求软件创建的迭代方法。然而基于构件的开发模型是利用预先包装好的软件构件(有时成为类)来构造应用。
开发活动从候选类的标识开始,这一步是通过检查将被应用系统操纵的数据及用于实现该操纵的算法来完成的。相关的数据和算法被封装成一个类。
缺点:
1、过分依赖于构件,构件库的质量影响着产品质量。
优点:
1、构件可复用。提高了开发效率。
2、采用了面向对象的技术。形式化方法模型
形式化方法模型包含了一组活动,他们导致了计算机软件的数学规约。形式化方法使得软件工程师们能够通过应用一个严格的数学符号体系来规约、开发、和验证基于计算机的系统。这种方法的一个变种,称为净室软件工程,已经被一些组织所采用。在开发中使用形式化方法时,它们提供了一种机制,能够消除使用其它软件过程模型难以克服的很多问题。二义性、不完整性、不一致性能被更容易地发现和纠正,而不是通过专门的评审,是通过对应用的数学分析。形式化方法提供了可以产生无缺陷软件的承诺。
缺点:
1、开发费用昂贵(对开发人员需要多方面的培训),而且需要的时间较长。
2、不能将这种模型作为对客户通信的机制,因为客户对这些数学语言一无所知。
3、目前还不流行。
优点:
1、形式化规约可直接作为程序验证的基础,可以尽早的发现和纠正错误(包括那些其它情况下不能发现的错误)。
2、开发出来的软件具有很高的安全性和健壮性,特别适合安全部门或者软件错误会造成经济损失的开发者。
3、具有开发无缺陷软件的承诺。第四代技术
一系列的软件工具的使用,是第四代技术的特点。这些工具有一个共同的特点:能够使软件工程师们在较高级别上规约软件的某些特征,然后根据开发者的规约自动生成源代码。我们知道,软件在越高的级别上被规约,就越能被快速的建造出程序。软件工程的4GT模型集中于规约软件的能力:使用特殊的语言形式或一种采用客户可以理解的术语描述待解决问题的图形符号体系。和其它模型一样,4GT也是从需求收集这一步开始的,要将一个4GT实现变成最终产品,开发者还必须进行彻底的测试、开发有意义的文档,并且同样要完成其它模型中同样要求的所有集成活动。总而言之,4GT已经成为软件工程的一个重要方法。特别是和基于构件的开发模型结合起来时,4GT模型可能成为当前软件开发的主流模型!
缺点:
1、用工具生成的源代码可能是“低效”的。
2、生成的大型软件的可维护性目前还令人怀疑。
3、在某些情况下可能需要更多的时间。
优点:
1、缩短了软件开发时间,提高了建造软件的效率。
2、对很多不同的应用领域提供了一种可行性途径和解决方案 9 过程技术 产品和过程 11 附录
第二篇:软件工程之用例模型总结
软件工程之用例模型总结
一、用例模型1.用例概念用例:使用系统时发现的功能性需求,不应过于复杂,简单的来说就是你希望系统能够有什么功能,能够增加系统的价值。
用例模型包括用例描述和用例图,我们主要把中心放在用例描述上。
用例模型包含参与者和场景,场景包括成功场景和失败场景。因此用例模型中有多个场景;每个场景是一个用例。用例必须注重为用户提供可观察的返回值,就是系统触发了一个用例之后能够给用户带来什么。
一般用例都是黑盒用例,即不考虑如何实现。2.Use Case Description每个用例都有一个描述。怎样确定用例?(1)确定一个功能;
(2)写一个用例;(1)主要参与者:调用系统服务完成目标的人。(2)次要参与者:为系统提供服务的人。
(3)写出每个项目相关人员的理想需求,从中分析功能。(4)PreCondition:执行到这个用例之前必须为真的情况,比如必须已成功登录或通过验证。
(5)PostCondition:成功执行完此用例后的情况,比如登录用例的后置条件是成功登录(不考虑其他失败情况)。(6)main flow:将最理想的步骤列出。一般main flow步骤如下:
(1)参与者发生动作。
(2)系统验证。
(3)返回结果。
(7)extension flow:扩展步骤,通常格式为:(1)系统检测到**有问题;在main flow中的第一步扩展,则用1a,1b,1c;3.如何确保正确的用例
EBP原则:一般用例都需要遵守这个规则,即确定主要用例。用例中的主要用例是一些重复做但是有意义的事,比如收银员收钱,重复多次是有意义的,因为钱收得多了;但是像登录系统,这种做100次却没有意义的用例,不能被称为主要用例;
(1)EBP(基本业务过程)原则的用例写入;
(2)如果要写编辑A,删除A,添加A,可以合并成“管理A”; 4.用例图
每个用例描述都是一个用例,左边是主要参与者(希望系统为他提供服务)和次要参与者(提供给系统服务的人);
在次要参与者中不能有数据库,因为在用户角度看是不知道系统有数据库的;
关系:
(1)泛化关系,在参与者和用例中都能泛化。(2)包含关系:
表示A包含B;比如A是管理数据,B可以是添加数据、删除数据等;
(3)扩展关系:表示D被C扩展,D包含新的功能,比如D是查询数据,C可以是打印数据,即用户可以查询但不打印数据,打印数据只是一个扩展功能。用例描述模板 [html] view plain copy
用例模型根据系统边界的确定,描述了系统的输入和输出,确定了系统外部的参与者,通过用例描述了系统的主要功能,描述了外部参与者与系统的交互,将系统作为一个黑盒,从用户角度描绘出系统需要提供的功能;
Use Case:用例名称
Actor:参与者
Precondition:前置条件,即执行这个用例一定要满足的条件
Postcondition:后置条件,如果成功执行,则一定会变成的状态
Main flow:
1.用户开始一次会话
2.用户输入信息
3.系统验证并反馈
4.用户重复2,3步
Extensions:
3a:数据无效
1.系统提示出错
第三篇:软件工程学习总结
软件工程学习总结
通过一个学期系统的学习软件工程这门课,结合与小组成员一起开发设备管理系统的经验,让我对软件的开发有了更深的了解,学习到每一个软件的开发都不仅仅是写代码,还有更加复杂的系统性的开发流程。
要开发一个软件,就拿设备管理系统来说,我们不能一上手就开始写代码,这样会浪费大量的人力物力财力还得不到理想的结果,首先我们应该先做好市场及需求方面的调查,了解用户需求有助于我们开发更加实用高效的软件,做好市场调研可以让我们对成本、利润、市场情况等有深层了解,让我们做出最优决策。
调查结束后,我们要写出详细的报告,包括项目开发计划书、软件需求规格说明书等,有了这些调查结果,我们才可以系统的,条理的来编写我们的软件。从前我们写代码都非常的盲目,杂乱无章,想到哪写到哪,浪费了大量的时间,写的代码结构也很松散,错误率高。学习软件工程后,我们学习了多种软件开发模型,学会了模块化的开发方法,小组成员每人完成不同的模块,最后综合起来,这样能够节省大量的时间,缩短开发时间,使代码结构更加紧凑,易于管理维护。如果说代码是一种工具的话,那么软件工程就是使用工具的经验指导,他能指导我们更好的使用这个工具,发挥它最大的潜能,帮助我们完成项目,不管使用什么程序语言,软件工程教给我们的开发方法都无条件适用,我们需要认真学习理解这门课程,它将伴随我们在程序开发的路上走下去。
第四篇:软件工程学习总结和体会2015
西安交通大学
2015级研究生课程专题作业
软 件
工 程 心 得专 业: 班 级: 学 号: 姓 名: 电 话:
二○一五年十月
体 会
一、软件生命周期各阶段任务目的和主要方法
在分阶段总结之前,首先要明确以下三个问题:
1、什么是软件生存周期?
软件生存周期是指从软件定义、开发、使用、维护到淘汰的全过程。主要包括:
(1)问题定义;(2)可行性研究;(3)需求分析;(4)概要设计;(5)详细设计;(6)编码;(7)测试;
(8)软件维护。
2、软件生存周期为什么划分成阶段?
(1)任何一个阶段的具体任务不仅独立,而且简单,便于不同人员分工协作,从而降低整个软件开发工作的困难程度。
(2)可以降低每个阶段任务的复杂程度,简化不同阶段的联系,有利于工程的组织管理,也便于采用良好的技术方法。
(3)使软件开发的全过程以一种有条不紊的方式进行,保证软件的质量,特别是提高了软件的可维护性。
3、应该怎样来划分阶段?
(1)每一个阶段的任务尽可能独立;(2)同一阶段内的任务性质尽可能相同;
(3)每一个阶段任务的开始和结束有严格的标准。
下面分别对各阶段进行讨论:
1、问题定义
目的是将用户提出的要求具体化、定量化,任务是确定研制系统的范围,明确研制的边界。
方法步骤:
(1)通过调查研究,了解系统要求;
(2)需求方与开发方讨论确定系统的功能、性能、可靠性、安全保密性等方面的要求,以及费用、进度等方面的要求。
2、可行性研究
可行性研究说明该软件开发项目的实现在技术上、经济上和社会条件上的可行性,评述为合理地达到开发目的可能选择的各种方案,目标是用最小的代价在尽可能短的时间内确定问题是否能够解决。
可行性研究的方法是首先需要进一步分析和澄清问题定义;然后分析员导出系统的逻辑模型;最后对未来的行动方针提出建议。
在导出逻辑模型的过程中,具体要根据以下四个方面分析可行性:
(1)经济可行性:进行成本效益分析,评估项目的开发成本,估算开发成本是否会超过项目预期的全部利润.分析系统开发对其它产品或利润的影响。
(2)技术可行性:根据客户提出的系统功能,性能及实现系统的各项约束条件,从技术的角度研究实现系统的可行性。(3)法律可行性:研究在系统开发过程中可能涉及的各种合同,侵权,责任以及各种于法律相抵触的问题。
(4)开发方案的选择性:提出并评价实现系统的各种看法方案.从中选出一种用于软件项目开发。
3、需求分析
需求分析是为了有效解决用户的需要而进行的一项工程活动,要考虑的问题是功能需求、数据需求、性能需求和接口需求,开发者承担分析任务,核心是用户。
软件项目的失败大半源于需求分析没有做好,软件开发人员首先应该明确用户的意图和要求,正确获取用户的需求,然后形成一个软件需求规格说明,它是软件开发的重要基础。
需求分析的方法:
(1)需求获取:获取客户需求,客户泛指某个人或机构部门等,一般方法是调查,包括访谈座谈、问卷、跟班和收集资料,需求规约可表达用户的软件价值。
(2)需求分析与规格说明:建立需求模型,它是用户需求的图解,一些常用的模型有:业务树图、用例图、活动图。分别用于结构化需求建模、系统业务举例和反映系统工作流程。
(3)需求验证:要验证的主要内容有:有效性验证、一致性验证、完整性验证、现实性验证和可检验性验证。
需求建模的方法:
(1)关联模型
(2)面向对象模型(3)原型方法
4、系统设计
此阶段主要根据需求分析的结果,对整个软件系统进行设计,如系统框架设计,数据库设计等,一般分为概要设计和详细设计,好的软件设计将为软件程序编写打下良好的基础。
概要设计是对需求规格说明书中提供的软件系统逻辑模型进行进一步的分解,从而建立软件系统的总体结构和各个子系统间及各个模块间的关系,定义各子系统接口界面和各模块的功能描述,并根据设计结果产生概 要设计文档。
概要设计在早期有模块化方法、功能分解方法;在60年代后期提出了面向数据流和面向数据结构的设计方法;近年来又提出面向对象的设计方法等。
详细设计过程根据概要设计形成的结果对各个模块的内部实现进行规划设计,并根据设计结果产生详细设计文档。
详细设计主要方法是通过采用结构化和面向对象的方法从视图、控制、模型三层模型上细化概要设计的各个模块,并完成伪代码为编码阶段做准备。
5、编码和测试
编码是将软件设计的结果转换成计算机可执行的程序代码。主要方法是依据详细设计文档实现设计中的算法、功能、接口、数据结构,采用结构化和面向对象化的方法编写代码。
编码过程中要制定统一,符合标准的编写规范,以保证程序的可读性,易维护性,提高程序的运行效率。
软件设计完成后要经过严密的测试,以发现软件在整个设计过程中存在的问题并加以纠正。整个测试过程分单元测试、组装测试以及系统测试三个阶段进行。
测试的方法主要有白盒测试和黑盒测试两种。在测试过程中需要建立详细的测试计划并严格按照测试计划进行测试,以减少测试的随 意性。
6、软件维护
软件维护是软件生命周期中持续时间最长的阶段。在软件开发完成并投入使用后,由于多方面的原因,软件不能继续适应用户的要求。要延续软件的使用寿命,就必须对软件进行维护。
软件的维护包括纠错性维护和改进性维护两个方面。
二、课程主要收获
《软件工程》课程强调概念和知识的理解和掌握,侧重软件项目的分析、设计、实现和维护的基本技能。比较注意“点”和“面”的结合,是一门理论性和实践性都较强的学科。作为一名已经在IT领域工作十年之后又重返校园的大龄学生,虽然已经不是第一次学习这门课程了,去年也刚在单位取得了信息系统项目管理高级工程师资格,从另一个侧面对软件开发过程有了更深层次的理解。不过温故而知新,这次仍然选修这门课,我还是得到了一些新的启示。最大的收获就是在我看来,软件工程与其说是一门课程,不如说是一门思想,是一个如何去分析和处理问题的过程,应该说其范畴已经远远不止局限于该门课程,它已经成为了一个综合的能够解决问题的思想集合。
此外,通过对软件开发过程的重学习,并结合之前在软件开发管理工作中的经验,我对自己在软件开发主要阶段管理工作中的不足有了更进一步的认识,总结了相应的管理要点,具体阐述如下:
1、概要设计
主要任务:系统应该怎样做,或概括地说,系统应该如何实现。本阶段特点:将用户的具体要求转为抽象的计算机软件设计。管理要点:
通过分析对比,从多种可能的实现方案和软件结构中选出最佳方案及最合理的,即: 设想供选择的方案→推荐最佳方案→选取合理的方案功能分解→ 软件设计结构 → 数据库设计 3 确定测试要求并确定测试计划
作为项目管理者必须从概要设计开始就应该从全局角度开始把握整个系统的进展,并必须从此阶段开始,时刻从全局观的问题来发现问题,解决问题。
2、详细设计
主要任务:系统应该怎样具体地做,或概括地说,系统应该如何具体地去实现所有的要求。
本阶段特点:将抽象的计算机软件设计转为形象的,具体的,面向用户的计算机界面设计。
管理要点:
本阶段尚未涉及具体编写程序,而是要设计出程序的“蓝图”,所以详细设计的结果基本上决定了最终的程序代码的质量。逻辑是否正确性能是否满足要求是否容易阅读和理解 作为项目管理者在详细设计阶段,应始终不忘从一名用户的使用角度出发,审视每一个界面的详细设计,以保证设计出来的界面以及程序能够满足一般用户希望将来的系统能够通俗易懂,简单实用的要求。
3、编码
主要任务:用某种程序设计语言书写计算机能够识别的程序。
本阶段特点:将详细设计书的内容“翻译”成计算机语言,直接关系到整个项目的质量。
管理要点:
本阶段的编码是设计的自然结果,因此,程序的质量主要取决于软件设计的质量。但是,程序设计语言的特性和编码途径也对程序的以下特性产生深远的影响: 程序的可靠性 2 程序的可读性 3 程序的可测试性 4 程序的可维护性
作为项目管理者在编码阶段,必须从把握进度与质量这两个基本方面来有效地实施对项目的管理。首先应该根据项目进度计划来合理地安排每一名作业成员的作业日程,并且随时监督每一作业的进展情况,还需要针对项目的最新变更及时对计划进行调整,以保证项目的按时完成。同时,在项目的进展过程中还需要通过小组讨论,检查评审等形式洞察每项作业的质量,以保证项目的保质保量完成。可以说,本阶段是一名项目管理者在项目开发过程中极为忙碌也异常重要的阶段。
4、测试
主要任务:通过单元测试和综合测试来保证软件工程的高质量。
本阶段特点:尽可能早地发现并纠正差错,往往占到软件开发总工作量的40%以上,是保证软件质量的关键。
管理要点:
软件测试在软件生命周期中横跨两个阶段。通常在编写出每个模块之后就对其作必要的测试(称之为单元测试),模块的编写者和测试者是同一人,编码和单元测试属于软件生命周期的同一个阶段。在此阶段结束之后,对软件系统还应该进行各种综合测试,这是软件生命周期的另一个独立阶段,通常由专门的测试人员来承担这项工作。
作为项目管理者在编码阶段,必须高度重视软件测试工作,甚至可以说应该把测试看作与编写程序同等重要的任务来对待。在要求每一名开发人员完成自己分内的单元测试,并且监督测试人员认真进行各项综合测试的同时,应该把自己完全当成一名本软件工程的用户,从用户的角度以一种高度负责,甚至近乎苛刻的严格态度来对软件进行彻底的测试。在本阶段通过严把质量关来确保软件工程的质量。
所以说,尤其在软件进入具体开发阶段后,能否遵循要点进行管理是很重要的。
总之,实际工作当中软件项目为什么会失败?为什么交付日期会一拖再拖?我觉得项目失败只有一个原因:就是项目经理不合格。除非这个项目经理在项目开始阶段就已经提出来了这个项目会失败,或者是完全属于项目之外不可抗拒的原因导致失败。也许还会有一些我的同行跳出来说不服,那么请继续:
难道是新增需求的原因导致失败?客户会让你新增100个需求而要你二天交货吗?必然是分析设计阶段没有充分考虑好可扩展性和新增需求导致现在不可控制而失败的!
难道是程序员人力不足导致?人都没有到位,怎么会失败,多少人做多少人的事,多少人做多少人的计划,不会有失败。
难道是程序员技能不够?项目经理是如何面试的?怎么在项目失败了才发现是程序员技能不够?有问题早提出来嘛。
难道测试人员没有做好?少来了,测试人员只是加了一道保障证明。程序很多流程都通过不了,程序还属于开发调试阶段,与测试人员有什么关系?
我曾经在单位参加一些项目,发现有这样一个概念很多项目经理都没有搞清楚:什么叫开发阶段?我认为开发阶段最多只能包括单元测试这一部分。综合测试绝对不能属于开发阶段了,也就是说不能到了最后交付阶段还有程序流程走不通,程序随便正常操作都会失败。程序随便正常操作都出现好多bug属于开发还没有完成,绝对还没有过单元测试阶段,离综合测试和验收阶段还早着呢。说白了,还属于代码审查阶段。
不懂程序设计的项目经理,往往不注重code开发人员,其实这是一个严重的错误。软件的质量来源于什么?由谁来保证?有的项目经理说是由测试人员来保证,就算测试人员的测试用例写得很详细,把需求中的每一个功能点都测试到了,那最后就没有问题了吗?当然不是,很多逻辑上的东西要程序员来保证不出问题的,而测试人员只是起一个验证的作用,问题不应该由测试人员来发现,而应该由开发人员来发现。也就是说,我们尽量不要让测试人员来发现问题。如果第一次测试有至少25%以上的用例通不过,那说明质量控制出了问题。这样的版本根本就不应该拿出来进行测试。由此可见,软件的质量是由程序员来保证的,而不是测试人员。
总的说来,一个项目的成败与否,与项目的各个阶段皆有关系:需求都不清楚,开发起来肯定是南辕北辙;分析设计不够好,会让程序员难以维护,随着新增需求的增多,会导致整个系统混乱不可控制;编码不好,整个系统不稳定是必然的,Bug也是抓不尽的;测试不做好,系统是没有保证的,少了哪个环节都不行。
所以做软件项目开发过程管理工作,我认为重点要放在项目计划、进度控制、质量控制、风险预测这四个方面。不要说项目的失败是因为新需求引起的,一个没有新增需求和风险的项目是不存在的,承认这一点之后,我们就不会有很多怨言了。
以下针对这四个方面进行详述:
项目计划:没有项目计划,那失败还有什么话好说?大家都知道凡事预则立,不预则废。项目计划一定要包括这几方面的内容:各阶段里程碑时间点,各个里程碑的输出结果,风险预测,意外应对。计划时间一定要提前于交货时间,并注意风险意外是否留下足够的应对时间和处理方案。
进度监控:对每个阶段把握好,每个阶段要完成的任务一定要完成,如果完不成,是什么原因导致的?我们的应对策略是什么?我们要信任别人,但是不要忘记锁门。同样的,别人说完成了,你不能就认为别人完成了,要看到结果才能证明完成了。有的项目经理说,我也进度监控啦,他说完成了就完成了,谁想到没有完成?到底是程序员不诚实还是项目没有管理好?你没有锁好门,能怨别人偷你东西吗?还有一种情况就是不懂如何锁门,根本就不知道这一阶段的输出结果是什么?当然进度监控就是一句空话了。
质量监控:也应该是分阶段进行的,每一个阶段的质量监控内容有所不同。
需求分析阶段的质量监控就是完整而又正确的理解用户需求,需求是否清楚可懂,写用例的测试人员是否明白需求?
分析设计阶段的质量监控就是设计是否完全满足需求?这个设计方案是否满足以后新功能的扩展?以及是否有考虑到新功能的意外和设备环境,运行平台的变化?
编码阶段的质量监控就是变量命名是否规范?代码是否可读?是否有详细的注释?是否有重复代码?要知道重复代码是必然会造成系统不稳定,bug成群的。可变部分的代码和不可变部分的代码是否分离。要知道上面讲的每一部分如果没有做好,都会导致后期的产品出现大量问题。代码阶段还有一个重要的工作就是做code review代码公开评审,你自己发现不了的问题别人也许就看得见。
单元测试阶段的质量监控任务就是单元测试代码是否测试通过?代码覆盖是否完全?单元测试报告提交情况如何?单元测试用例有没有做好? 综合测试阶段质量监控任务当然就是看用例是否完全?是否全部真正执行?测试报告有没有写好?
回归测试当然得看以前测试的Bug是否还在,如果还在,当然是无条件打回去重新开发。
测试阶段最主要的监控就是看用例是否真正执行,是否有安全性测试?破坏性测试?异常测试,压力测试?
以上的每个阶段最好完成了才进行下一阶段,否则会造成混乱出现问题的,造成想并行进行节约时间却反而浪费了时间。
以上就是我重学《软件工程》并结合实际工作经验所得到的启示,不妥之处请刘老师批评指正!
第五篇:企业文化刚性的组织生命周期模型
企业管理
科学学与科学技术管理
张 敏 “,陈传明 $
(”-南京财经大学,江苏 南京 $“%%+.;$-南京大学,江苏 南京 $”%%(/)
摘要:企业文化具有不易被改变的刚性特征。以组织的生命周期为主线,围绕组织的设计过程、组织战略的形成过程和 组织知识的演化过程,探究企业文化刚性特征的形成机理,并指出,企业文化刚性问题的实质是一种企业成长过程中的 路径依赖或锁定现象,其对组织行为的作用与影响是辩证的。关键词:企业文化;刚性特征;组织生命周期模型 中图分类号:0$*%
文献标识码:1
文章编号:“%%$‟%$+”)$%%.,%$‟%“&%‟%.“刚性”在物理学中是指材料的一种力学性能,描 述物体不易被改变的程度。牢固建立起来的企业文 化,为了保护自己,它发展了一系列精心设计的、力量 强大的机制,使得企业对其文化表现出了显著的路径 依赖特征,在企业管理过程中特别是在企业战略调整 过程中,企业文化所具有和表现出的这种不易被改变 的特性即为企业文化的刚性特征!”#。当处于变化中的 企业进行战略调整时,企业文化的这种不易被改变的 性质即企业文化的刚性特征便会显现出来,阻碍、破 坏企业战略调整的贯彻执行,最终使企业在竞争中走 向失败。那么,曾经一度被管理学界和企业界视为“制 胜法宝”和“企业动力之源”的企业文化,其不易被改 变的刚性特征究竟是如何产生的?运用组织生命周期 模型,本文将对此问题进行探讨。
一、企业文化刚性组织生命周期模型的建立 企业从诞生之日起,便面临着生存与发展两大基 本问题,在组织管理上则表现为组织控制与战略调整 两大根本任务。组织控制主要是通过对组织的结构形 式、信息技术和控制系统、生产技术、人力资源系统和 部门之间的联系等内容进行理性的设计!$#,通过对组 织内部的管理活动及其效果进行衡量和校正,以确保
组织的目标以及为此而拟定的计划得以实现。战略调 整的目的是保持组织系统及其内部环境与外部环境 之间的动态平衡,在组织的成长过程中,组织的战略 也经历了以内部为重点到以外部为重点的转变。同 时,一种文化在一个企业中能够得以生存并发展的前 提条件,是这种文化得到了企业组织成员的一致认 可,或者这种文化被实践所证明对于该企业的成功是 行之有效的。不过,企业文化是一柄“双刃剑”,它既可 以传承企业的优良传统,也可能作为一种惰性而存在 和孳生。企业文化的刚性特征与企业文化是相伴而生 的,在一种文化开始成为企业主流文化的同时,企业 文化的刚性特征也随之产生了。本文以组织的生命周 期为主线,围绕组织的设计过程、组织战略的形成过 程和组织知识的演化过程去探究企业文化刚性特征 的形成。
在企业成长的不同阶段,企业文化具有相异的内 涵与刚性特征,战略管理的重心也有所不同,基于上 述分析,本文构建了一个企业文化刚性的组织生命周 期模型(见图 “)。
二、初创阶段—文化的冲突 企业在初创阶段最突出的特点是关心组织成收稿日期:$%%&‟%(‟%&
基金项目:国家自然科学基金项目“企业战略调整的内部影响因素研究”)*%+*$%+&,第一作者简介:张敏(”(*%-$‟),男,上海市人,南京财经大学营销与物流管理学院讲师,管理学博士,研究方向:企业战略管理与组织 设计。
!“#
$##%$
科学学与科学技术管理
企业管理
包含着对正确与否的解释,而且,它还隐含着一种观 念:某种行为或结果比其他行为或结果更为可取。因 此,价值观会使得客观性和理性变得含糊不清。而在 组织的初创阶段,由于组织成员的社会化程度很低,所以,价值观的冲突成为不可避免)。因此,组织设计 的关键在于整合和解决冲突的机制的建立,并在这种 机制的约束下,组织成员与组织之间通过社会性活动 与政治性活动实现目标的一致以及价值观念的趋同。这一过程类似于自然界的生物进化,是一个自发的过 程。初创阶段的组织是一个尚未达到平衡态的开放系 统,它将遵守达尔文的进化论学说,通过与环境不断 地进行能量、物质和信息的交换,在整合和解决冲突 机制的作用下产生自组织现象,即由无序到有序、较 低的有序到较高的有序并形成组织内外各种力量的平衡—均衡或内在秩序。
组织初创阶段的战略重点是在全新的环境中求 生存,因此,分析内外部环境态势、设计组织结构、组 织过程与行为,以及确立企业的主导战略便构成了组 织战略的主要内容,其中,组织主导战略的确定是通 过战略一致性的形成来实现的,为此,组织应注意四 个方面的因素:焦点 0)#12$3,即组织中哪些类型的成 员参与一致性的形成;范围0$1#4&3,即参与人员的数 量比例;程度 05&,”&&3,即一致性的强度(程度);内容
高变通
组织 控制 程度
高控制
图 @ 基于组织生命周期的企业文化刚性特征形成过程
员,强调创新,重视个人的创造力与想象力;人力资 源受到高度重视,培训、自我管理、授权相当普遍;专 业管理、职务与个人技能相匹配在这种价值体系中 得到充分体现。在该阶段,组织对外部环境的适应能 力可以通过组织的开放性、员工的参与和讨论而得 以维持。这种组织形式是非规范化和非官僚制的,因 此,我们可以从斯格特提出的组织自然系统的视角 去分析。
自然系统视角的主要内容是对组织目标复杂性 和非正式结构进行研究和解释,所关注的更多是组织 及其参与者的行为。在自然系统视角的学者们眼中,(初创阶段的)组织中充满着目标的冲突(!“#$$ 指出,既定的目标和组织“实际”所寻求的目标之间存在着 差距,组织寻求的目标不是指导参与者行为的唯一目 标,还必须寻求“维持”目标,也就是说,组织并不只是 达成既定目标的工具,其在本质上是力图在特定环境 中 适 应 并 生 存 下 来 的 社 会 性 团 体)、结 构 的 冲 突(%#&‟()*$+&”,&“ 和-*))*./ 认为,正式结构是特意设 计来规范组织成员行为以服务于特定的组织目标,与 此同时,非正式结构的出现会替代、侵蚀和改变正式 的结构。正式结构等同于那些独立于个体行为特征而 存在的规范和行为规则,是“成本和效率逻辑”,而非 正式结构是建立在具体参与者的个性及互动关系基 础上的,是“情绪逻辑”,因此,正式结构与非正式结构 之间一直保持着一种张力)和价值观的冲突(罗宾斯 指出,价值观对于研究组织行为是十分重要的,因为 它是了解员工的态度和动机的基础,同时它也影响着 我们的知觉和判断。每个人在加入一个组织之前,便 已经形成了什么是应该的或是不应该的思维模式,它
01#6‟&6‟3,即最后达成的实际意见789。此时,组织的知识
构成,包括组织成员独自带来的或组织所面对外部的 知识,都可以用“新奇”06#:&)‟;3来描述,而对于这种新 奇的知识,<.”)*)& 和 %&+&6‟*$1(建议采取“储存”0$‟#“=
.,&3的方式 7>9。对知识的“储存”有些类似于“组织记
忆”或“组织的学习曲线”7?9。由于组织的知识体系尚未 结构化而处于一种混沌的状态,组织中已有的知识与 新知识之间、已有知识的组成部分之间、已有知识的 部分与整体之间,以及新知识的组成部分之间,在获 得组织成员的解释和认同时可能会产生相互矛盾而 形成一种张力,这种张力一方面为组织寻求新知识提 供了动力,另一方面也加速了组织知识结构化的进 程。
!”“#$”!
%&%
企业管理
在初创阶段,由于组织中整合机制尚未完全形 成,主导战略尚未确立、组织知识尚未结构化,组织成 员之间尚处于磨合期,同时由于个体文化的差异性,企业尚未确立其主流文化,企业文化的特征是多文化 的冲突与交流,这也决定了在该阶段必然要采取人际 关系型的管理模式。很显然,由于一元的核心价值观 尚未形成,并且组织成员各具特色,这可以给组织带 来多种选择上的优势,此时的企业文化具有极强的可 塑性,因而是无刚性可言的,但这种企业文化是无法 产生推动企业向前发展的强大的文化力的。所以,在 初创阶段,领导者必须具备良好的解决冲突的能力,管理的重心是在尽可能短的时间内选择和确立主流 文化,启动文化力以带动组织前进。
三、成长阶段—文化的演化 企业在初创阶段的这种混沌状态不会持续很长 时间,随着“领导与管理危机”!“#的出现,组织开始寻求 并获得强有力的领导,组织开始提出明确的目标和发 展方向,部门也随着权力层级、工作分派和劳动分工 而逐步建立。尽管此时组织中已出现了某些规范的制 度和程序,但这是组织的青年期,其结构形式仍然是 非规范化的!$#,因此,本文从组织的开放系统视角去审 视处于成长期的组织。
组织的开放系统视角将组织作为一种以功能模 块形式出现的控制系统来进行分析的,并引入“熵”的 概念,即组织系统自发地朝着熵增的状态运行:设置 结构要素、分解差异性结构、使系统自组织而向更高 的秩序和复杂性方向演进!%#。为此,组织设计的目标就 是确定适当的工作流程、控制体系以及计划机制之间 的关系,通过条件相关进程中的连锁行为,解决组织 在规定环境中的模糊性问题,强调维持组织的等级制 度,重视组织内部,将信息管理和记录有效地结合在 一起,以保证组织的稳定性和长期决策的连续性。强 调这种价值观念的组织通常拥有完备的资料库、明确 的职务说明、预期目标和解决冲突的程序。
在经过了初创阶段的一致性进程之后,组织的战 略逐步收敛于某一主导战略,但由于这种主导战略往
科学学与科学技术管理
往是由一些偶然事件,如市场中的新机遇或某项新技 术的出现所引发,而一旦被确立下来,主导战略便会 引导并“锁定”于特定的路径,并沿着既定的路径持续 地发展下去。组织战略的这种路径依赖特征的形成机 制十分复杂,既有经济方面的原因,也有组织管理的 影响,其中,从经济学的角度看,沉没成本效应!、网络 效应!‟(#、学习效应!‟‟#和规模经济性,从组织管理方面 看,组织记忆!‟)#、管理人员认知!‟*#以及组织结构!‟+#等均 决定了组织战略的这种锁定状态。此时,出于组织主 导战略和日益增加的工作复杂性的需要,作为组织生 产性、技术性和社会交往性知识的储藏库的组织惯例 开始出现,但这种组织惯例并不仅仅是组织知识的简 单加总,而是一种结构化的组织特定操作性知识的存 储。组织的这种知识结构具有自行衍生的功能,即组 织不仅可以通过学习从外界直接获得知识,而且由于 知识之间具有能够为人们所觉察的内在联系,还可以 通过组织成员和他们的环境之间正在发生的相互作 用逐渐演化出新的知识来,这种新知识是内生的从而 具有了默会的特征。默会的知识是特定群体的成员所 独有的,在成员交往过程中起到协调作用。所以,正如,-./01 和 2314-5 所说的,组织惯例是一个“休战协
定”64578-9,通过使组织成员满意于他们所扮演的角 色,把组织内潜在的和明显的冲突保持在可预测的限 度之内,从而提高组织这一功能模块运行的可控性。但 ,-./01 和 2314-5 同时也指出,坚持组织的惯例将 导致相对刚性或甚至是惰性的行为,当环境条件非预 期地发生变化时,它表现得不够灵活!‟:#,也就是说,企 业文化的刚性特征出现在组织的成长阶段。
在组织的成长阶段,企业文化亦处于成长阶段,并在不断的吐故纳新过程中获取养分,不断地演化自 己,提升自己的文化力以保证企业的快速成长。因此,成长阶段企业文化建设的重心是培育共同的核心价 值观,从而确立起企业的主流文化。;7311 将这一过 程描述为:为组织定义特定的使命和目标;清晰、直 观、量化地陈述这些目标;将目标分配至个人或组织 的单元;建立量化的绩效测评系统以控制组织向既定
!”#
#$$%&$#
科学学与科学技术管理
目标成长!“#$。%&‟((和)*+,*-./ 则将这一过程模式化 为 0121314!”5$。其中,形成历史感60+(7‟&89包含精心 编制历史和宣传英雄,并通过英雄与其他人进行文化
企业管理)+-‟/ 指出,组织简化参与者决策的一个主要方法是对
指导其行为的目标进行限制,组织的目标可以作为构
建手段—目标链条的起点,建立起一沟通的过程;创造统一感62/:/:((9包含领导和角色模 仿、宣传规范和价值观的过程;促进成员感63:-;:&<
(*+=9包含奖励系统、事业管理和工作安全、人事和招
聘、新成员社会化、培训和发展等内容;增加成员间交 流64>,*./?:9包含成员接触、决策制定的参与、群体间 协调、人员交换等过程。很显然,在 0121314 的过程 中,企业成员必然会改变自己以适应组织主流文化的 要求,这样,各具特色的个体带给企业的行为与选择 的多样化就会丧失。因此,当主流文化大大削弱了不 同背景的个体带到组织中的独特优势时,企业文化的 刚性特征就产生了。
四、成熟阶段—核心价值观 组织进入成熟阶段以后,规范化的程序已经完全 建立,清晰的层级制和明确的部门分工也已完全形 成。但此时,组织中不断繁衍的制度和规程可能开始 束缚组织成员的思想而显现出官僚制的特征。因此,理性目标是企业在成熟阶段最显著的特征。
从理性系统的视角看,组织是一种为了完成特定 目标而设计的工具,理性则是指为了最有效地达成既 定目标而以某种方式组织起来的一系列行为逻辑。所 以,理性并不是指目标选择而是指目标达成!“@$。为此,组织设计的核心要素是目标的具体化、形式化和结构化。具体目标为组织及其成员选择相应的行动提供了明确 的标准,也对组织设计起着指导作用。目标的具体化带 动行动的具体化,并使组织明确了其成员的类型以及 组织资源在组织参与者之间的分配方式;目标的形式 化使组织体系中指导成员行为的角色和原则关系结构 更加清楚明晰,使参与者或观察者能够描绘组织的结 构及其运作流程,描绘其与操作合理性的关系和过程,包括责任分工的设计与修订、信息与物质流转以及参 与者之间互动的方法等,通过标准化、规范化和形式化 能使组织成员的个体行为更加确定,使组织中的每个 成员能够稳定地预期其他成员在特定条件下的行为;
个目标等级体
系。在其中,从下往上看,个体决策和行为的合理性只 有在与更高层次的决策相联系时才能获得评价,即对 每一个子目标的评价只能看它是否与更高层次的目标 相一致;从上往下看,把更高层次的大的目标分解并指 派给子单位形成子目标,通过具体化价值前提简化每 一层次必须的决策,进而评价行为的合理性!”A$。以上分 析可以看出,组织目标的结构化可以提高组织内部决 策的效率和行为的一致性。
处于成熟阶段的企业非常重视对战略目标的控 制以及计划的实现,并为此建立高效的反馈系统,以 便在目标不能实现时及时地修改工作程序,其最终 目的是为了在激烈的竞争环境中获取最大化的产 出。由于组织内部已基本实现了程序化操作,所以企 业的战略重点已经转向外部,其实质是建立在战略 计划、组织活动、后果等为未来活动提供信息的全面 评估基础之上的战略控制。战略控制要求不仅监控 组织内部状况,更要监控外部环境状况的持续变化。
2B,*+ 提出了三种主要的战略控制方法,即市场、官
僚制和小团体!CD$。其中,市场控制方法的思想来自于 经济学,是指组织利用竞争性价格来评估组织的产 出和生产率;官僚制是利用规则、政策、权威层级、书 面文件、标准和其他官僚机制来使行为标准化和评 估业绩;而当组织进入成熟阶段以后,战略控制的手 段则更多地依赖于第三种方法,即使用社会手段,例 如组织文化、共享的价值观、承诺、传统、信念来控制 组织成员的行为。
虽然战略控制的方法有所不同,但其结果却都强 化了处于成熟阶段的组织的理性特征,于是,企业员 工的知识体系与技能、企业的权力机构和管理系统、企业的组织结构均处于成熟与稳定阶段,企业的各组 成要素之间经过长期的磨合,互相启发和补充,产生 整体大于个体之和的协同效应。但一旦组织成员的知 识体系结合为一体,就会像矿床一样,形成阻止知识、“#$”!
%&‟
企业管理
个人自由转移的组织氛围(这种现象也与个体的“知 识过滤”机能有关。!“#$%& 等人指出,个体的心智模 式对于所接受到的外部信息有一种过滤作用,个体会 保留下与自己心智模式相匹配的信息,而对于与自己 心智模式不相匹配的信息则可能无意识地予以忽略。而这种“扭曲的认知特点”将会使个体丧失对有可能 引发重大变革的新知识的识别与保持的能力,也会降 低知识转移的效率)。此时,企业所拥有的知识已经成 为组织进行变革与调整的障碍,人们既不想改变,也 不可能迅速地改变。工作方式通常是根深蒂固地植根 于特定组织行为模式之中的,而且在很多情况下,知 识的生成和共享与有形资产不同,在许多行业中仍然 被视作不正常的,甚至被认为会对个人职位形成威 胁。并且,企业文化在经历了前两个阶段的演化之后,已逐步走向成熟与稳定,强调内部控制,注重一元文 化的塑造,在企业中形成了围绕企业使命的共同的核 心价值观。成熟阶段的企业往往也处于成功的巅峰,经营上取得的成就使得企业认定其现有的企业文化 是最优的而不对其加以变革甚至还自觉或不自觉地 予以强化,在此过程中,企业文化的刚性特征便逐步 达到了它的临界点。由于企业文化刚性特征的存在,企业组织的结构和文化此时已逐渐走向惰性与僵化,一旦企业面临环境的突变,这种曾经培育了成功的组 织结构和文化便会迅速成为企业走向衰败的最根本 的因素。
五、蜕变阶段—文化的分化 与自然界中的有机体类似,企业也有其独特的诞 生、成长、成熟以及衰老死亡的生命周期,一般而言,在蜕变阶段,组织中的官僚体制可能达到了其极限,并拥有广泛的控制系统、规章和程序。此时,企业的产 品、企业所拥有的市场甚至企业组织自身都进入了衰 退期,但衰亡并不是企业生命周期的必然结局,企业 完全可以通过自行调整来获取新生,这也正是企业管 理的魅力所在。处在蜕变阶段的企业往往正处于成功 的巅峰,其路径演化也处于线性与非线性状态的交界 处,当能够超越既定演化路径的外部效应、外生变量
科学学与科学技术管理
或权力的变化出现时,沿着原有路径继续演化的企业 将陷入“核心能力陷阱”,而要实现企业的永续发展,企业必须要努力实现对既有发展路径的超越。为此,在组织设计方面要以组织转型为重点 ‟()、在组织战略 方面要实现战略的柔性化 ‟*+)、在组织知识的管理方面 要注重知识的再获取与创新。
在蜕变阶段,企业文化的刚性特征到达了它上升 曲线的一个“拐点”,企业文化也面临着它的分化点,即要么就此继续演化自生自灭,要么与组织一起实现 对其自身路径的超越。
六、结 语
企业组织是一个由许多成分和行为主体所组成 的复杂自适应系统,既为系统,就具有层次结构和功 能结构,并处于不断的发展和变化之中,系统持续地 与其环境发生物质、能量和信息的交换,系统在远离平衡的状态下也可以稳定(自组织),确定性的系统 有其内在的随机性(混沌),而随机性的系统却又有 其内在的确定性(突现)。因此,在组织管理过程中,我们所遇到的核心问题是怎样设计组织系统,从而 产生成功的系统输出。在组织发展的初期,出于控制 混乱的需要,组织设计了一套组织管理框架,一般 地,组织会强化这一管理框架以保证当权者或大多 数组织成员心目中的组织最重要任务得以实现,进 而在组织中形成了围绕共同目标与组织首要任务的 一致性的行为模式与共同文化,于是,组织的文化便 “锁定”于某一条路径,并且在报酬递增机制和自增 强机制的作用下而显得极难改变。文化是一个历史 的概念,是在企业经营的过程中经过岁月流逝逐渐 积累而成的,企业文化基本上反映了企业组织的记 忆,所以,用企业文化来指导企业及其成员今天的行 为,实际上是用过去的经验来指导企业及其成员今 天的行动,这无疑会给企业的战略调整行为带来极 大的制约。企业战略的生命力在于与环境变化之间 的动态适应性,组织的历史能够对企业目前的行为 产生有力的、不知不觉的影响,因此,企业战略的实 施与调整必须将这种影响因素考虑在内,但如果一
!”#
$%%&‟%$
科学学与科学技术管理
味拘泥于企业成功的历史,以企业的过去来限定企 业当前的战略,则常常会使一个企业成为其过去的 牺牲品。
参考文献
!“# 陈传明,张敏$企业文化的刚性特征及其克服!%#$江海学刊,&‟‟((&)
!)*+,-./$ 0$ 1 2344566.7$ 8$ 9”::;<= 2>? 3@@4,AB@*C 3C
D*@*4E,-3-@C 5F 54G3-,H3@,5-36 D*C,G-!%#$ ?4G3-,H3@,5-8@BDI ,*C.“(9&<= JKI&”&
!K# L34MNOHP.)$ 9&‟‟“<= 25-C*-CBC F54E3@,5-DB4,-G C@43@*G,O
OQ3-G*!%#$ 8@43@*G,O L3-3G*E*-@ %5B4-36.&&= ”‟“KIK”!;# 2346,6*.R$ S$ 1 S*A*-@,COQ.>4,O8$ 9&‟‟K<= T-@5 @Q* A63OM
A5U= VQ* M-5+6*DG* @43-CF54E3@,5-OPO6*!%#$ L3-3G*E*-@ 8O,*-O*$ W56$;:9:<= “"J‟I”“:(!(# /4G5@*.)$ *@ 36$ 9”::‟<= VQ* X*4C,C@*-O* 3-D @43-CF*4 5F
6*34-,-G ,-,-DBC@4,36 C*@@,-GC!%#$ L3-3G*E*-@ 8O,*-O*$ W56$ KY= “;‟I”(;
!Y# ZB,--.S$ >$ 1 23E*45-.[$ 9“:JK<= ?4G3-,H3@,5-36 6,F* OPI
O6*C 3-D CQ,F@,-G O4,@*4,3 5F *FF*O@,*-*CC!%#$ L3-3G*E*-@ 8O,*-O*$ W56$&:= KKIK(!]#!美#达夫特$组织理论与设计精要!L#,北京,机械工业出
版社,”:::$
!J# ^*4@363-FFP.)BD+,-G 5-$ 9“:Y&<= _*-*436 8PC@*E VQ*54P!S#$
T-_*-*436 8PC@*EC= 0*34A55M 5F @Q* 85O,*@P F54 _*-*436 8PC@*EC S*C*34OQ.*D$)BD+,-G 5-^*4@363-FFP 3-D /-3@56 S3X5X54@.]=”I&‟
!:# RBFF*4@.„$ 9&‟‟‟<= R3@Q „*X*-D*-O*.a*@+54M b54E 3-D
V*OQ-565G,O36 2Q3-G*!S#.R4*X34*D F54 X4*C*-@3@,5-3@ @Q* O5-F*4*-O* ,-Q5-54 5F R45$ R3B6 /$ „3,D= c,C@54P L3@@*4C.*4C,@P.%B-*$&IK
企业管理
!“‟# 卡尔・夏皮罗、哈尔・瓦里安,信息规则:网络经济的策略指
导!L#,北京,中国人民大学出版社 &‟‟‟:”(KI“(:
!”“# c,4COQ.R$ L$ 1 _,66*CX,*.%$ %$ 9&‟‟”<= 7-X3OM,-G R3@Q
„*X*-D*-O*!L#.S3GQB _34BD 1 R*@*4 [3-5* >DC$.R3@Q „*X*-D*-O* 3-D O4*3@,5-.)5-D5-=)3+4*-O* >46A3BE /CI C5O,3@*C$
!“ 8@*,-.>$ d$ 9”::(<= ?4G3-,H3@,5-36 E*E54P!%#$ T-@*4-3@,5-I
%5B4-36 5F T-F54E3@,5-L3-3G*E*-@.W56$“(!”K# c3EA4,OM.„$ 2$ *@36$ 9“::”<= VQ* C*3C5-C 5F 3 2>?eC
@*-B4*!%#$ /O3D*EP 5F L3-3G*E*-@ S*,*+./X4,6.]“:I];&!”;# c3--3-.L$ V$.3-D %$ S$ b4**E3-9“:J;<= 8@4BO@B436 ,-*4I
@,3 3-D 54G3-,H3@,5-36 OQ3-G*!%#$ /E*4,O3-85O,565G,O36 S*I ,*+.&:= ”;:I“Y;
!”(# a*6C5-.S$ 3-D d,-@*4.8$ _$ 9“:J&<$ /-*56B@,5-@Q*54P
5F *O5-5E,O OQ3-G*!L#$ 23EA4,DG*.L/= c3434D 7-,*4C,@P R4*CC$
!”Y# ZB,--.%$ ^$ 9“:J‟<= 8@43@*G,*C F54 2Q3-G*!L#$ T4+,-.c5EI
*+55D.T).Y‟IYY
!”]# d344*-_45CC 3-D 8QB63 8Q,OQE3-= c5+ @5 _45+ 3-?4I
G3-,H3@,5-36 2B6@B4*!%#$ R*4C5--*6.8*X@*EA*4 “:J]:(&I(Y!”J#!美#斯格特$组织理论:理性、自然和开放系统!L#,北京:华
夏出版社,&‟‟“$
!”:# 8,E5-.c$ /$ 9“:]Y<= /DE,-,C@43@,* ^*Q3,54 9K4D *D$
!&‟# ?BOQ,.d$ _$ 9“:J‟<= L34M*@C.^B4*3BO43O,*C.3-D 263-C
!%#$ /DE,-,C@43@,* 8O,*-O* ZB34@*46P.&(= ”&:I“;”!&“# 83-OQ*H.S$ 9”::(<= 8@43@*G,O F6*U,A,6,@P ,-X45DBO@ O5EX*I
@,@,5-!%#$ 8@43@*G,O L3-3G*E*-@ %5B4-36$56$“Y=”K(I“(:
(责任编辑
徐
惠)
>O5-5E,O _45+@Q.V*OQ-565GP 3-D R5XB63@,5-.8@3-F54D 7-,I
!”# $%&‟()*‟+),(-).# /012# 3,4#2 ,./,%5,%‟+# /62+6%# 7)&)4)+0
fc/a_ L,-“.2c>a 2QB3-E,-G&
9”$a3-g,-G b,-3-O,36 1 >O5-5E,O 7-,*4C,@P.a3-g,-G &“‟‟;Y.2Q,-3h &$a3-g,-G 7-,*4C,@P.a3-g,-G &”‟‟:K.2Q,-3<
89:+%‟1+;254X543@* OB6@B4* Q3C 3-B-OQ3-G*3A6* 4,G,D,@P OQ343O@*4$ V3M,-G 54G3-,H3@,5-6,F* OPO6* 3C 3 @Q4*3D 3-D O*-@*4i,-G 5-@Q* X45O*CC 5F 54G3-,H3@,5-D*C,G-.C@43@*G,O F54EB63@,5-.M-5+6*DG* *56B@,5-.@Q,C X3X*4 3-36PH*C @Q* F54EB63@,5-E*OQ3-,CE 5F @Q* 4,G,D,@P OQ343O@*4 5F O54X543@* OB6@B4*$ VQ* X3X*4 36C5 X5,-@C 5B@ @Q3@ @Q* 4,G,D,@P OQ343O@*4 5F O54X543@* OB6@B4* ,C 3 XQ*-5E*-5-5F X3@Q D*X*-D*-O* ,-54G3-,H3@,5-D**65XE*-@.3-D ,@C ,-F6B*-O* ,C D,36*O@,O36$ <#0 =,%4:;O54X543@* OB6@B4*h 4,G,D,@P OQ343O@*4,C@,OCh 54G3-,H3@,5-6,F* OPO6* E5D*6
!“"#$”!
%&&