软件工程
文章平均质量分 61
qiang_gu
喜欢阅读,喜欢《人月神话》等书籍。
乐于与人沟通
感恩生活,珍惜生活每一天。
展开
-
软件项目中为什么要进行需求分析?
客户参与是避免期望差异(expectation gap)的唯一途径,这一期望差异表现在客户期望得到的产品与开发者所设计的产品之间不相符。然而,在项目的开始阶段仅仅简单地问一两个客户的需求,然后就开始编码,这样做是不够的。如果开发者仅仅为了客户的最初需求去开发软件,那么,他们可能要重新进行开发,因为,客户常常不知道他们的真正需要,而开发者也不知道。 用户提出“需要”原创 2004-11-20 11:35:00 · 6770 阅读 · 1 评论 -
需求与项目的预估
项目估计(预估)的第一步就是要把需求和软件产品规模的大小相联系。你可以根据文本需求、图形分析模型、原型或用户界面设计来预估产品的大小。虽然对于软件大小没有完善的度量标准,但以下给出了一些常用的度量标准:• 功能点和特性点的多少( Jones 1996b),或者3 - D功能点的数量(Whitmire 1995)。• 图形用户界面(G U I)元素的数量、类型和复杂度。• 用于实现特定需求原创 2004-12-29 14:32:00 · 1345 阅读 · 0 评论 -
从需求到设计、编码的转化
在你可以开始实现各个部分需求前,不必为整个产品进行完整、详细的设计。然而,在你进行编码前,必须设计好每个部分。设计规划将有益于大难度项目(有许多内部组件接口和交互作用的系统和开发人员无经验的项目)(McConnell 1998)。然而,下面介绍的步骤将有益于所有的项目: • 应该为在维护过程中起支撑作用的子系统和软件组件建立一个坚固的体系结构。 • 明确需要创建的对象类或功原创 2004-12-29 14:35:00 · 2071 阅读 · 0 评论 -
从需求到测试
详尽的需求是系统测试的基础,反过来只能通过测试来判断软件是否满足了需求。你必须针对软件需求规格说明中所记录的产品的预期行为来测试整个软件,而不是针对设计或编码。基于代码的系统测试可以变成“自满足的预见( self-fulfilling prophecy)”。产品可以正确呈现基于代码的测试用例所描述的所有行为,但这并不意味着产品正确地实现了用户的需求。如果你没有文档形式的需求,你应该原创 2004-12-29 14:43:00 · 1561 阅读 · 0 评论 -
需求开发向设计规划的转化
由于需求定义了项目预期的成果(outcome),所以的项目规划、预测和进度安排都必须以软件需求为基础。 软件项目可能经常不能达到预定的目标,这是因为开发人员和其他项目参与者是拙劣的规划者,倒不是因为他们是拙劣的软件工程师。主要的规划失误包括:忽略公共(用)的项目任务,低估了要花费的工作量和时间,没有考虑项目风险,并且没有考虑返工所需的时间。正确的项目规划需要以下元素:• 根据对需求的清原创 2004-12-29 14:23:00 · 1053 阅读 · 0 评论 -
一份合格的软件需求规格说明书的要求
合格的软件需求规格说明书软件需求规格说明作为产品需求的最终成果必须具有综合性:必须包括所有的需求。开发者和客户不能作任何假设。如果任何所期望的功能或非功能需求未写入软件需求规格说明那么它将不能作为协议的一部分并且不能在产品中出现。 构造并编写软件需求规格说明,并使用户和其它读者能理解它牢记以下可读性的建议:• 对节、小节和单个需求的号码编排必须一致。• 在右边部分留下文本注释区。• 允许不加原创 2005-02-23 17:13:00 · 4836 阅读 · 0 评论 -
听鲍志云--“对象设计”讲座
今天,到umlchina上逛了一下,看到了上面推荐的《对象设计》,翻译的是趋势公司的鲍志文。正好umlchina上有鲍的一个有关OOD的讲座,就下载下来听了一下。 讲座内容不错,鲍讲的很精彩!我一直在用过程开发方法在做项目,对OO的概念掌握不是很好,在项目中,设计模式应用的也不是很好。我听了讲座后,感觉收获还是蛮大的。 从事工作后,一直在做MIS系统的开发,感觉原创 2005-07-24 17:18:00 · 1436 阅读 · 0 评论 -
项目管理规范-RUP管理实施(来自UMLCHIANA)
项目管理规范-RUP管理实施(一)作者:李杰 本文选自:UMLCHINA 2002年03月28日 第一部分:项目阶段 第二部分:核心工作流程 第三部分:角色划分 第四部分:目前实施项目规范的考虑 概述软件开发的产品质量水平,是一个由来已久的话题。而提高软件企业的产品质量水平,必须改进软件产品的开发过程。但是这里没有什么百试百灵的灵丹妙药,我们必须根据本企业的实际情况,参考国内外先进企业的经原创 2005-07-29 14:30:00 · 1415 阅读 · 0 评论 -
UML学习笔记(二)
UML范围之外的几个问题。(Outside the Scope of the UML)1、编程语言 UML不是一门具体的编程语言,但是与面向对象的编程语言有很紧密的联系。The UML, a visual modeling language, is not intended to be a visual programming language,原创 2005-07-27 17:00:00 · 1211 阅读 · 0 评论 -
读《标准建模语言UML教程》有感
上周把从网上下载的《标准建模语言UML教程》认真的看了一遍。我认为这是国内写的一本相当好的关于UML方面的书籍。我看了前几章的电子文档,感觉写的挺好,就把全书打印出来看了,反正也才131页。真实言简意赅啊! 本书,首先用两章内容介绍了什么是UML,第3章介绍了软件开发过程,主要参照RUP。第4章到第11章,分别介绍了UML的用例图、类图、包图、交互图(顺序图、合作图)、状态图,活动图原创 2005-08-06 11:48:00 · 1547 阅读 · 0 评论 -
怎样成为优秀的软件模型设计者?
我们期待自己成为一个优秀的软件模型设计者,但是,要怎样做,又从哪里开始呢? 将下列原则应用到你的软件工程中,你会获得立杆见影的成果。 1. 人远比技术重要 你开发软件是为了供别人使用,没有人使用的软件只是没有意义的数据的集合而已。许多在软件方面很有成就的行家在他们事业的初期却表现平平,因为他们那时侯将主要精力都集中在技术上。显然,构件(components),EJB(Enterpris原创 2005-08-08 11:32:00 · 1219 阅读 · 1 评论 -
RUP学习心得
一、什么是RUP RUP是Rational Unified Proces 的缩写,翻译成中文就是“统一软件过程”。 RUP是一个基于6个最佳开发实践的流程定义产品。二、6个最佳开发实践 1、迭代始开发 2、需求管理 3、基于组建的体系架构 4、可视化建模 5、持续的质量管理 6、配置管理原创 2006-06-09 13:26:00 · 2565 阅读 · 2 评论 -
GNU宣言
GNU宣言Cnic.org,开放的网络天书!GNU宣言 -- 作者:理乍得·马修·斯托曼,翻译: chuhaibo[AKA] 本文版权为 Free Software Foundation, Inc. 所有, Copyright (C) 1985, 1993 任何人在拿到这份文件的同时便已授予他通过任何媒体,不加更改的复制与传播本文的副本的权利,前题是本版权宣告与授权转载 2006-11-17 14:35:00 · 1586 阅读 · 0 评论 -
认识GNU GPL发展Linux
认识GNU GPL发展Linux(作者:陈际红 2000年06月07日 12:18) Linux能在短短的几年内在软件领域占据如此耀眼的位置,是多数人始料不及的。由于它独特的许可证体系,Linux对于渴望突破微软Windows操作系统的垄断,拥有一套自主操作系统的我们而言,无疑具有巨大的吸引力。基于Linux的操作平台及其集成应用环境的软件已被列入国家优先发展的高技术产业化重点领域目录。 研转载 2006-11-17 14:55:00 · 1810 阅读 · 0 评论 -
迭代开发需要一种不同的观点
级别: 初级转载 2006-08-06 18:05:00 · 1637 阅读 · 1 评论 -
谈谈对系统集成的一点看法
在项目管理中,大家都知道测试很重要。现在的企业信息系统,系统间的接口越来越多,系统间业务流程的联系也越来越紧密。因此,系统间的集成测试显得尤为重要。 通过多年的项目经验,我发现涉及系统的接口,即使再完善的接口说明,也会存在双方理解的误差。因此,为了保证系统接口的正确性,只能尽量设计各种测试案例来进行验证测试。如果能进行覆盖测试,最好能覆盖所有的可能情况。 如何原创 2008-04-22 20:38:00 · 1614 阅读 · 0 评论 -
从需求到项目的成功
我最近遇到一个项目,在该项目中,一个新的开发小组将针对早先的开发小组所开发的求实现一个应用程序。这个新的开发小组一看到由3英寸活页纸订成的软件需求规格说明就到十分恐惧,于是立刻编写代码。在构造软件的过程中,他们没有参考软件需求规格说明,而是根据他们对预期系统的不完整且不正确的理解,按他们自己的想像进行编码设计。因此,该项目遇到许多问题便不足为奇了。试图理解这个庞大的需求规格说明肯定会原创 2004-12-29 14:57:00 · 1618 阅读 · 1 评论 -
需求验证
验收测试是以用户需求为基础的,系统测试是以功能需求为基础的,而集成测试是以系统的体系结构为基础的。在相应的开发阶段,必须规划测试活动并为每一种测试设计测试用例。不可能在需求开发阶段真正进行任何测试,因为还没有可执行的软件。然而,你可以在开发组编写代码之前,以需求为基础建立概念性测试用例,并使用它们发现软件需求规格说明中的错误、二义性和遗漏,还可以进行模型分析。 需求验证是需求开发的原创 2004-11-29 15:49:00 · 1864 阅读 · 1 评论 -
需求用例模板
用例编号UC-3用例名称积分累积创建者****最后更新 创建时间二〇〇四年十月二十五日最后更新时间十月二十五日执行者操作员或终端说明执行者收集消费客户的消费信息,并将这些信息发送至处理系统,根据消费客户消费对应的积分回报在其积分卡片帐上累加原创 2004-11-22 15:55:00 · 2632 阅读 · 0 评论 -
软件客户需求权利书&软件客户需求义务书
我们在进行软件项目需求分析时,经常遇到客户不够配合的情况。如果我们能跟客户签一个《软件客户需求权利书&软件客户需求义务书》的话,或许事情就好办的多了哦!软件客户需求权利书客户有如下权利:1. 要求分析人员使用符合客户语言习惯的表达。2. 要求分析人员了解客户系统的业务及目标。3. 要求分析人员组织需求获取期间所介绍的信息,并编写软件需求规格说明。4. 要求开发人员对需求过程中所产生的工作结果进行解原创 2004-11-20 11:41:00 · 2026 阅读 · 0 评论 -
需求获取(requirement elicitation)指导方针
一、需求获取的重要性1、需求获取(requirement elicitation)是需求工程的主体。2、对于所建议的软件产品,获取需求是一个确定和理解不同用户类的需要和限制的过程。3、获取用户需求位于软件需求三层结构的中间一层。它描述了用户利用系统需要完成的任务。从这些任务中,分析者能获得用于描述系统活动的特定的软件功能需求,这些系统活动有助于用户执行他们的任务。(来自项目视图和范围文档的业务需求原创 2004-11-22 11:38:00 · 3342 阅读 · 0 评论 -
使用实例(usecase)和功能需求
使用实例的描述并不向开发者提供他们所要开发的功能的细节。如果你在用户需求阶段停止了需求开发,你将会发现在软件的构造阶段,开发者必须询问许多问题来弥补他们的信息空白。为了减少这种不确定性,你需要把每一个使用实例叙述成详细的功能需求( A r l o w1 9 9 8)。 每一个使用实例可引伸出多个功能需求,这将使执行者可以执行相关的任务;并且多个使用实例可能需要相同的功能需求。例如,如原创 2004-11-22 16:45:00 · 3418 阅读 · 1 评论 -
使用实例(usecase)的好处
使用实例方法给需求获取带来的好处来自于该方法是以任务为中心和以用户为中心的观点。比起使用以功能为中心的方法,使用实例方法可以使用户更清楚地认识到新系统允许他们做什么。 如果开发者所编写的代码从未被使用过,这将是令人沮丧的。有了使用实例,所得到的功能需求明确规定了用户执行的特定任务。使用实例技术防止了“孤立”的功能—这些功能在需求获取阶段似乎是一个好的见解,但没有人使用它们,因为它们并原创 2004-11-22 16:51:00 · 1941 阅读 · 0 评论 -
避免使用实例陷阱
在使用实例的方法中应注意如下的陷阱:• 太多的使用实例如果你发现自己陷入使用实例的爆炸之中,你就可能不能在一个合适的抽象级上为之编写文档。不要为每一个可能的说明编写单独的使用实例。而是把普通过程、可选过程以及例外集成起来写入一个简单的使用实例。也不要把交互顺序中的每个步骤看成一个单独的使用实例。每一个使用实例都必须描述一个单独的任务。你将获得比业务需求多得多的使用实例,但你的功能需求将比使用实例还原创 2004-11-22 17:03:00 · 1035 阅读 · 0 评论 -
在需求采集时,如何对客户的需求进行分类
不要指望你的客户会给需求分析者提供一个简洁、完整、组织良好的需求清单。分析者必须把代表客户需求的许多信息分成不同的类型,这样他们就能合理地编写信息文档并把它们用于最合理的方式上。那些不属于这些类型的信息可能代表一个非软件项目的需求,例如,为使用新系统而进行的用户培训或者它仅仅是不重要的信息。 下面讨论在听取客户需求过程中的一些建议,这将有助于对信息进行分类处理。1) 业务需求,原创 2004-11-22 17:19:00 · 2587 阅读 · 0 评论 -
软件工程中“签约”意味着什么?
为所开发产品的需求签订协议是客户与开发人员关系中的重要部分。许多组织在需求文档中使用“签约”这个概念来作为客户同意需求的标志行为。故要让所有需求参与者都真正明白“签约”的意思。 但存在这样一个问题:客户代表经常把“签约”看作是毫无意义的。“他们要我在一张纸的最后一行文字下面签上名字,于是我就签了,否则这些开发人员不开始编码。”这种态度将来会带来麻烦,譬如客户想更改需求或对产品有不满时。原创 2004-11-20 11:37:00 · 1962 阅读 · 0 评论 -
建议需求开发过程
建议需求开发过程1. 定义项目的视图和范围2. 确定用户类3. 在每个用户类中确定适当的代表4. 确定需求决策者和他们的决策过程5. 选择你所用的需求获取技术6. 运用需求获取技术对作为系统一部分的使用实例进行开发并设置优先级7. 从用户那里收集质量属性的信息和其它非功能需求8. 详细拟订使用实例使其融合到必要的功能需求中9. 评审使用实例的描述和功能需求10. 如果有必要,就要开发分析模型用以澄原创 2004-11-22 11:46:00 · 1125 阅读 · 2 评论 -
基于usecase的需求分析过程
虽然usecase源于面向对象的开发环境,但是他能应用在采用其他的开发方法的项目中。用户并不关心你是采用何种方法来开发软件的。我们在实际的软件项目中,可能不会去画实际的实例图,但是使用实例的观点和思维过程带给需求开发的改变比起是否画正式的使用实例图显得更为重要。usecase是站在用户的角度来看待问题,关注的事“用户要用系统做什么”而以前的“用户希望系统为他们做什么”。 一个使原创 2004-11-22 14:55:00 · 2691 阅读 · 0 评论 -
软件需求的层次
最近,在看软件需求工程方面的资料。软件需求分析的好坏直接决定了软件项目的成功与否,软件需求分析、需求管理的时间在整个软件项目中所占的时间会达到40%~60%。 在宏观上,软件需求分三个层次: (1)business requirement (2) user requirement (3) functional requirement 业务需求对应原创 2004-11-20 11:43:00 · 1249 阅读 · 0 评论 -
“原型”是什么?为什么要使用“原型”
一个软件原型是所提出的新产品的部分实现。使用原型有三个主要目的:• 明确并完善需求原型作为一种需求工具,它初步实现所理解的系统的一部分。用户对原型的评价可以指出需求中的许多问题,在你开发真正产品之前,可以最低的费用来解决这些问题。• 探索设计选择方案原型作为一种设计工具,用它可以探索不同的用户界面技术,使系统达到最佳的可用性,并且可以评价可能的技术方案。• 发展为最终的产品原型作为一种构造原创 2004-11-29 14:08:00 · 5575 阅读 · 1 评论 -
再读《人月神话》
我第一次读人月生活大概在1年之前了。马上要做一个新的项目了,今天有空,我又翻阅了这本软件工程领域的经典书籍。再读“人月神话”有了新的理解与感想。 “用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话”、“向进度落后的项目中增加人手,只会使进度更加落后。”,对这些经典的论断有了新的理解。 在项目人员组成上,我个人比较喜欢人员数量少而精的项目结构,这样可以节省项目沟通所要花费原创 2004-12-05 16:38:00 · 1317 阅读 · 0 评论 -
需求的图形化分析的意义
根据在需求方面的权威Alan Davis的见解,仅仅单一来看需求并不能提供对需求的完全理解(Davis 1995),你需要把用文本表示的需求和用图形表示的需求结合起来,绘制出对预期系统的完整描述,并可帮助你检测不一致性、模糊性、错误和遗漏。这些图形化的表示或者分析模型可以增强你对系统需求的理解。在项目的参与者之间,对于某些类型的信息,图形化交互比文本交互更高效,并且可以在不同的开发组原创 2004-11-26 16:22:00 · 1473 阅读 · 0 评论 -
设定需求优先级
每一个具有有限资源的软件项目必须理解所要求的特性、使用实例和功能需求的相对优先级。设定优先级有助于项目经理,解决冲突,安排阶段性交付,并且做出必要的取舍。 当客户的期望很高、开发时间短并且资源有限时,你必须尽早确定出所交付的产品应具备的最重要的功能。建立每个功能的相对重要性有助于你规划软件的构造,以最少的费用提供产品的最大功能。如果你正在做时间盒图或者进行渐增式开发,那么设定优先原创 2004-11-29 15:01:00 · 2437 阅读 · 0 评论 -
为什么做不出好产品
原文地址:http://blog.sina.com.cn/s/blog_493a84550100vxhp.html 一个好产品必须是可用加可行,可用代表会产生价值,可行代表可以实现。一个软件产品要成功最终的衡量标准还是用户的使用和喜爱程度。用户经常会主动想起来要用你的软件转载 2011-08-22 22:55:13 · 602 阅读 · 0 评论