软件定义阶段总结.ppt

软件定义阶段总结,软件定义阶段各章回顾 对软件定义各个阶段的进一步认识 与软件工程相关的一些补充内容 软件工程中一些有争议的观念 给大家的几条建议,Chap01 软件工程学概述,软件工程的基本原理和方法（7条原理2种方法） 软件工程方法学： 生命周期方法学（传统方法学），采用结构化技术来完成软件开发的各项任务。 面向对象方法 面向对象方法对象类继承用消息通信。 软件生命周期划分：问题定义、可行性研究、需求分析、总体设计、详细设计、编码和单元测试、综合测试、运行维护等8个阶段 软件过程：瀑布模型、快速原型模型、增量模型、风险驱动的螺旋模型。,可行性研究目的是进一步探讨问题定义阶段所确定的问题是否有可行的解。 可行性研究过程 1、经过定义问题，分析问题，提出解法的反复过程，最终提出一个符合系统目标的高层次的逻辑模型。 2、 然后根据系统的这个逻辑模型设想各种可能的物理系统，并且从技术、经济和操作等各方面分析这些物理系统的可行性。 3、最后，系统分析员提出一个推荐的行动方针，提交用户和使用部门负责人审查批准。,Chap02 可行性研究-1,可行性研究-2,系统流程图实质上是物理数据流图，它描绘组成系统的主要物理元素以及信息在这些元素间流动和处理的情况。 数据流图的基本符号只有四种，它是描绘系统逻辑模型的极好工具。 数据字典是关于数据的信息的集合，对数据流图中包含的所有元素的定义的集合。通常数据字典和数据流图共同构成系统的逻辑模型。 成本效益分析是可行性研究的一项重要内容 。,需求分析是软件生命周期的一个重要阶段，它最根本的任务是确定为了满足用户的需要系统必须做什么。 通过分析应该得出用数据流图、ER图、数据字典和和IPO图（或PDL等其他描述算法的工具）描绘的精确的系统逻辑模型。还可以用层次方框图或Warnier图等图形工具辅助描绘系统中的数据结构。为了减少冗余、简化修改步骤，往往需要规范数据的存储结构。 需求分析的结果是软件开发的基础，必须仔细验证它的正确性 。,Chap03 需求分析,软件定义各个阶段的进一步认识,深入“问题定义”,问题定义是软件工程过程中重要的一环，也是最简短的阶段，通常在一天或更少的时间内完成。但它是一个项目的开始，也就是根基，如果问题定义不明确、不完整，会直接影响到以后的工作，问题定义决定了整个软件工程是否能朝着正确的方向前进。,错误的问题定义,把问题定义当作是需求分析 把问题定义当作一件小事 把问题定义当作解决方法 避重就轻地定义问题,规范问题定义,思想上重视 客观、全面地定义 严格评审 深入分析,可行性研究,可行性分析是要决定“做还是不做”。 即使可行性分析是客观的、科学的，但决策仍有可能是错误的。因为决策者是人，人会冲动，有赌博心态。如果可行性分析表明做某件事的成功率是10%，失败率是90%，倘若该事情的意义非常大，决策者也许会一拍脑袋：“豁出去，干！”于是这世界就多了一份极喜与极悲。可行性分析的四大要素：经济、技术、社会环境和人。 目前国内很多软件公司做系统集成项目，如果谈谈系统集成项目的可行性分析将很有意思。可是那些系统集成项目大多是政府机构的，由于软件行业尚不规范并且客户方存在腐败现象，所以业内流传“没有做不了的系统集成项目”。软件公司的注意力几乎全集中在“如何拿到项目订单”以及“拿到订单后如何蒙混过关”上，丧失了 “可行性分析”的机会。 联想集团领导人柳传志曾说：“没钱赚的事我们不干；有钱赚但投不起钱的事不干；有钱赚也投得起钱但没有可靠的人选，这样的事也不干。”柳传志为决策立了上述准则，同时也为可以行性分析指明了重点。,经济可行性-1,经济可行性分析主要包括：“成本收益”分析和“短期长远利益”分析。 成本收益分析最容易理解，如果成本高于收益则表明亏损了，如果成本大大高于收益那就亏大了。商人都不喜欢做吃亏的事情。有些商店成天贴着“最后一天跳楼大拍卖”的标语，意思是：我准备吃大亏让你占便宜，同志，你快上钩吧。 要考虑的成本： （1）办公室房租。 （2）办公用品，如桌、椅、书柜、照明电器、空调等。 （3）计算机、打印机、网络等硬件设备。 （4）电话、传真等通讯设备以及通讯费用。 （5）资料费。 （6）办公消耗，如水电费、打印复印费等。,经济可行性-2,（7）软件开发人员与行政人员的工资。 （8）购买系统软件的费用，如买操作系统、数据库、软件开发工具等。有些老板买盗版的系统软件，却按市场价算成本，可从美国佬那里赚一笔。 （9）做市场调查、可行性分析、需求分析的交际费用。 （10）公司人员培训费用。 （11）产品宣传费用。如果用Internet作宣传，则要考虑建设Web站点的费用。 （12）如果客户是政府部门，还要充分考虑用于吃喝玩乐、行贿的费用。 （13）如果公司的风水不好，会有很多莫名其妙的管理费。每戳一个红艳艳的公章都要化一把钞票。,经济可行性-3,短期长远利益分析 短期利益容易把握，风险较低。国内软件公司经常出现一窝蜂地去做信息管理系统、多媒体光盘、系统集成项目或Internet服务。每当我们沉迷于短期利益不思进取时，应该好好回忆童年时代那些伟大的抱负，给自己一些激励。 长远利益难以把握，风险较大。能为了长远利益不惜短期亏损的人，要么是雄心勃勃的将帅之才，要么是“纸上谈兵”、“眼高手底”的那一类庸人。国内目前有不少Internet企业，只投入不产出。为了成就将来的霸业，甘愿现在拼财力、比耐性。最后存活下来的几个公司将瓜分市场。,技术可行性,（1）在给定的时间内能否实现需求说明中的功能。如果在项目开发过程中遇到难以克服的技术问题，麻烦就大了。轻则拖延进度，重则断送项目。 （2）软件的质量如何？有些应用对实时性要求很高，如果软件运行慢如蜗牛，即便功能具备也毫无实用价值。有些高风险的应用对软件的正确性与精确性要求极高，如果软件出了差错而造成客户利益损失，那么软件开发方可要赔惨了。 （3）软件的生产率如何？如果生产率低下，能赚到的钱就少，并且会逐渐丧失竞争力。在统计软件总的开发时间时，不能漏掉用于维护的时间。软件维护是非常拖后腿的事，它能把前期拿到的利润慢慢地消耗光。如果软件的质量不好，将会导致维护的代价很高，企图通过偷工减料而提高生产率，是得不偿失的事。 技术可行性分析可以简单地表述为：做得了吗？做得好吗？做得快吗？,社会环境可行性,社会环境的可行性至少包括两种因素：市场与政策。 市场又分为未成熟的市场、成熟的市场和将要消亡的市场。 涉足未成熟的市场要冒很大的风险，要尽可能准确地估计潜在的市场有多大？自己能占多少份额？多长时间能实现？ 挤进成熟的市场，虽然风险不高，但油水也不多。如果供大于求，即软件开发公司多，项目少，那么在竞标时可能会出现恶性杀价的情形。国内第一批卖计算机的、做系统集成的公司发了财，别人眼红了也挤进来，这个行业的平均利润也就下降了。 将要消亡的市场就别进去了。尽管很多程序员怀念DOS时代编程的那种淋漓尽致，可现在没人要DOS应用软件了。学校教学尚可用用DOS软件，商业软件公司则不可再去开发DOS软件。 政策对软件公司的生存与发展影响非常大。整个90年代，中国电信的收费相当高，仅此一招就把国内互联网企业打得奄奄一息。某些软件行业的利润很高，但可能存在地方保护政策，使竞争不公平。政策不当将阻碍软件公司的健康发展，可最怕的还是政府干预企业的正当行为。,人的因素,有句名言：“人分四类人物，人才，人手，人渣。” 如果一个软件公司里上述四类人齐全了，那么最好的分工是让“人物”当领导，“人才”做第一线的开发人员，“人手”做行政人员，“人渣”负责行贿。 对于公司的领导与开发人员“行还是不行”。“人物”毕竟是少数，“人才”可是济济的。举重若轻的那类“人才”可以做领导，举轻若重的那类人才适合做软件开发人员。假如一群持有学士、硕士和博士文凭的毕业生到软件公司应聘，该如何录用呢？ 先选择本科毕业生，因为他们正当青春、干劲十足、不摆架子、不耻下问、要求不高、奉献甚多。 其次选择硕士毕业生，如果该生没象范进中举时那么老，并且在读硕士时没有天天去造文章而丢弃了编程工作，那么让有经验的学士程序员带他们煅练几个月就可以用了。 如果学士、硕士被其它公司取光了，那只好捡几个博士充数。,通过前边的学习，我们会发现需求析是最为重要的一个过程，在这个过程中，系统分析员和软件工程师确定顾客的需要。只有在确定了这些需要后他们才能够分析和寻求新系统的解决方法。 在软件工程的历史中，很长时间里人们一直认为需求分析是整个软件工程中最简单的一个步骤，但在过去十年中越来越多的人认识到它是整个过程中最关键的一个过程。假如在需求分析时分析者们未能正确地认识到顾客的需要的话，那么最后的软件实际上不可能达到顾客的需要，或者软件无法在规定的时间里完工。,项目需求分析难在哪里？-1,客户说不清楚需求 客户对需求只有朦胧的感觉，说不清楚具体的需求。 如果客户本身就懂软件开发，能把需求说得清清楚楚，这样的需求分析将会非常轻松、愉快。如果客户全不懂软件，但信任软件开发方，这事也好办。分析人员可以引导客户，先阐述常规的需求，再由客户否定不需要的，最终确定客户真正的需求。最怕的就是“不懂装懂”或者“半懂充内行”的客户，他们会提出不切实际的需求。如果这些客户甚至觉得自己是上帝的爸爸，那么沟通和协商都会很困难。,项目需求分析难在哪里？-2,需求自身经常变动 “据历史记载，没有一个软件的需求改动少于三次。唯一只改动需求两次的客户是个死人。这个可怜的家伙还是在运送第三次需求的路上被车子撞死的。” 因此我们应先接受“需求会变动”这个事实，免得在需求变动时惊慌失措。明白“需求会变动”这个道理后，在进行需求分析时就要留点神： （1）尽可能地分析清楚哪些是稳定的需求，哪些是易变的需求。以便在进行系统设计时，将软件的核心建筑在稳定的需求上，否则将会吃尽苦头。 （2）在合同中一定要说清楚“做什么”和“不做什么”。如果合同含含糊糊，日后扯皮的事情就多。,分析人员或客户理解有误 软件系统分析人员不可能都是全才。客户表达的需求，不同的分析人员可能有不同的理解。如果分析人员理解错了，可能会导致开发人员白干活，吃力不讨好。所以分析人员写好需求说明书后，要请客户方的各个代表验证。如果问题很复杂，双方都不太明白，就有必要请开发人员快速构造软件的原型，双方再次论证需求说明书是否正确。 由于客户大多不懂软件，他们可能觉得软件是万能的，会提出一些无法实现的需求。有时客户还会把软件系统分析人员的建议或答复给想歪了。 有一个软件人员滔滔不绝地向客户讲解在“信息高速公路上做广告”的种种好处，客户听得津津有味。最后，心动的客户对软件人员说：“好得很，就让我们马上行动起来吧。请您决定广告牌的尺寸和放在哪条高速公路上，我立即派人去做。”,项目需求分析难在哪里？-3,软件项目获取用户需求的沟通技巧,软件需求过程包括了5个主要活动：需求获取、需求分析和确认、编写需求规格说明书、需求验证和需求管理。 进行需求分析的时候应该按照上边的步骤去做。,需求获取,需求的收集、分析、细化、核实并组织的步骤，并将它编写成文档。这个活动包括了编写项目视图和范围文档、用户群分类、选择用户代表、建立核心队伍、确定使用实例、召开联合会议、分析用户工作流程、确定质量属性、检查问题报告和需求重用10个具体任务。,需求分析和确认-1,1、绘制关联图，用于定义系统与系统外部实体间的边界和接口的简单模型； 2、创建开发原型，当开发人员或用户不能明确某些需求时，开发一个系统原型，这样使得许多概念和可能发生的事更为直观明了； 3、分析可行性，在允许的成本、性能要求下，分析每项需求实施的可行性，明确每项需求实现相联系的风险，包括与其它需求的冲突，涉及各类用户的利益平衡，对外界因素的依赖和技术障碍；,需求分析和确认-2,4、确定需求优先级：分析方法来确定使用实例、系统特性或单项需求实现的优先级别，以优先级为基础确定产品版本将包括哪些特性或哪类需求； 5、为需求建立模型，为需求建立图形分析模型是软件需求规格说明极好的补充说明，可以为系统需求从多个角度建模； 6、编写数据字典，创建数据字典数据字典是对系统用到的所有数据项和结构的定义，以确保开发人员使用统一的数据定义； 7、应用质量功能调配，将系统特性、属性与对客户的重要性联系起来，提供了一种分析方法以明确哪些是客户最为关注的特性。,编写需求规格说明书-1,需求开发的最终成果是客户和开发小组对将要开发的产品达成一致协议，这一协议就是通过文档化的需求规格说明书来体现。需求规格说明书包括项目视图和范围文档说明了系统的业务需求，而使用实例文档则说明了用户需求。这个活动需要完成下面几个任务： 1、采用模版,在你的组织中要为编写软件需求规格说明书等文档定义一种标准模板,该模板为记录系统需求和各种其它与需求相关的重要信息提供了统一的结构； 2、指明需求来源，为了让所有项目风险承担者明白需求规格说明书中为何提供这些功能需求，要能追溯每项需求的来源，来源可能是一种使用实例或其它客户要求，也可能是某项更高层系统需求、业务规范、政府法规、标准或别的外部来源，这些来源应该记录在需求的跟踪能力矩阵中；,编写需求规格说明书-2,3、为每项需求注上标号，为了需求的可跟踪性和可修改性的质量标准，必须唯一确定每个软件需求，为制定一种惯例来为需求规格说明书中的每项需求提供一个独立的可识别的标号或记号; 4、记录业务规范，是指关于系统的操作原则，比如谁能在什么情况下采取什么动作,将这些编写成需求规格说明书中的一个独立部分，或一独立的业务规范文档; 5、创建需求跟踪能力矩阵，建立一个矩阵把每项需求来源、定义与实现、测试它的设计和代码部分联系起来,这样有利于需求的管理和需求变更影响范围的评估。,需求验证-1,需求的验证是为了确保需求说明准确、完整，表达必要的质量特点,需求将要作为系统设计和最终验证的依据,因此一定要保证它的正确性。需求验证务必确保符合完整性、正确性、灵活性、必要性、无二义性、一致性、可跟踪性及可验证性这些良好特征。这个活动需要完成下面几个任务： 1、审查需求文档，对需求文档进行正式审查是保证软件质量的有效的方法。组织一个由不同代表（如用户，分析人员，设计人员，测试人员）组成的小组，对需求规格说明书及相关模型进行仔细的检查；,需求验证-2,2、依据需求编写测试用例，根据用户需求所要求的产品特性写出系统的功能测试用例作为系统测试依据； 3、编写用户手册，在需求开发早期即可起草一份用户手册，用它作为需求规格说明的参考并辅助需求分析; 4、确定合格的标准，需求说明中描述什么样的产品才算满足用户的要求和适合他们使用的，将合格的测试建立在使用情景描述或使用实例的基础之上。,需求管理-1,需求管理是组织、控制和文档化需求的系统方法，也是一种建立和维护用户和开发组织对于改变系统功能的协议。需求开发的结果经验证批准就定义了开发工作的需求基线,这个基线在客户和开发人员之间就构筑了一个需求约定，需求管理包括在项目进展过程中维持需求约定一致性和精确性的活动。现在很多商业化的需求管理工具都能很好的支持需求管理活动。这个活动需要完成下面几个任务： 1、确定变更控制过程,确定一个选择、分析和决策需求变更的过程,所有的需求变更都需遵循此流程; 2、建立软件变更控制委员会(SCCB，Software Change Control Board),组织一个由项目风险承担者组成的小组作为变更控制委员会，由他们来评估和确定需求变更; 3、进行变更影响分析,评估需求变更对项目进度、资源、工作量和项目范围以及其它需求的影响;,需求管理-2,4、跟踪变更影响的产品,当进行某项需求变更时，参照需求跟踪能力矩阵找到相关的其它需求、设计文档、源代码和测试用例，这些相关部分可能也需要修改； 5、建立基准和控制版本,需求文档确定一个基线，这是一致性需求在特定时刻的快照，之后的需求变更就遵循变更控制过程即可; 6、维护变更的历史记录,记录变更需求文档版本的日期以及所做的变更、原因，还包括由谁负责更新和更新的新版本号等情况; 7、跟踪每项需求的状态,这里状态包括“确定“、“已实现“、“暂缓“、“新增“、“变更“ 等。建立一个数据库，其中每一条记录记录一项需求; 8、衡量需求稳定性,记录基线需求的数量和每周或每月的变更（添加、修改、删除）数量。,软件开发经验谈 规范与文档,介绍纲要,软件与软件危机 编码风格 软件设计及文档 一些CASE工具,软件与软件危机,软件及其特点 定义 与硬件相互依存 包括程序、相关数据及其说明文档 特点 是一种逻辑实体，具有抽象性 没有明显的制造过程（开发后复制） 在使用过程中，无磨损、老化的问题，但存在软件退化问题（硬件、环境以及需求的变化）,软件与软件危机,软件危机及其原因 软件危机：在软件的开发和维护过程中所遇到的一系列严重问题 对开发成本和进度的估计常常不准确 用户对“已完成”系统不满意的现象经常发生 软件产品的质量往往靠不住（Bug） 软件的可维护程度非常之低 软件通常没有适当的文档资料 成本不断提高 开发生产率的提高赶不上硬件的发展和人们需求的增长,软件与软件危机,软件危机及其原因 软件危机的原因 与软件本身的特点有关 与开发和维护的方法不正确有关 忽视软件开发前期的需求分析 开发过程没有统一的、规范的方法论的指导，文档资料不齐全，忽视人与人的交流 忽视测试阶段的工作，提交用户的软件质量差 轻视软件的维护,软件与软件危机,校园中的软件开发 编程至上，淡化分析设计 文档稀少，样例、方法、内容 风格不统一，忽视整体规范化 组织松散，合作意识不强 钻研技术，追求编程技巧 软件生命力低，难于实用和发展壮大 .,编码风格,编排格式：Tab键缩进、空行、长句的分行. 注释：文件、函数/过程、数据结构、控制流. 各种名字的命名方法：匈牙利命名法. 界面风格的统一：对话框/多文档/单文档、大小、字体、颜色、用词. 宏的使用：便于扩展、变更、意义明确 数据结构的引入与管理：数据与操作的封装性 文件、模块的组织：规模，功能、数据的相关性 低耦合性：如何支持低的依赖性和高的复用性 高内聚力：如何支持可管理的低复杂性 异常的考虑与处理,编码风格,如何在校培养编码风格？ 程序设计语言：编排格式、变量函数的命名 数据结构：数据结构的选择与使用、宏的使用 编译原理（操作系统）设计：更复杂的数据结构的设计，耦合性与内聚力，尝试界面的制作，文件、模块的组织，异常的考虑与处理 其他 意识、自觉、勤奋、自立、严谨、不耻下问,软件设计与文档,文档(设计说明)的重要性 开发者之间交流的有效手段； 帮助开发者记忆设计思想； 引导人们快速地理解软件； 文档的复用 写文档的困惑 程序中不是有注释吗？ 写什么呢？ 用什么写呢？ 文档与程序的一致性,软件设计与文档,软件分析设计方法 结构化分析设计：数据流图, .； 面向对象的分析设计: UML, . 关系数据库: E-R, 关系模型； 软件分析设计的表现 头脑+纸笔+代码 由人思考输入的文档 利用工具建模生成的文档 文本+图形,软件设计与文档,如何在学校培养写文档 程序设计语言：注释的习惯 数据结构：数据结构的实验报告 编译原理（操作系统）设计：设计报告 现存的问题：检查力度不够 如何在学校培养软件分析设计 软件工程等课程 贵在实践和意识,CASE工具-青鸟系统,简介 国家科技攻关课题成果，北大牵头研制 面向对象的软件开发环境 研究过程 “七五”期间，青鸟J型系统 “八五”期间，青鸟II型 “九五”期间，青鸟III型(JB3)系统 基于异构平台、具有多信息源接口 支持面向对象技术，支持软件复用 完善并初步实现青鸟软件生产线（基于构件构架模式的软件工业化生产技术）的思想,CASE工具-青鸟系统,构件-构架 软件构件技术 构件：应用系统中可以明确辨识的构成成分 可复用的构件：具有相对独立的功能 属性 有用性有用的功能 可用性易于理解与使用 质量构件及其变形能正确工作 适应性可进行参数化的配置 可移植性 内容：源代码、需求规约、系统和软件的构架、文档、测试计划、测试案例和数据,CASE工具-青鸟系统,构件-构架 软件构架 对系统整体结构的刻划，包括 全局组织与控制结构 构件间通讯、同步和数据访问协议 设计元素间的功能分配，物理分布 设计元素集成，伸缩性和性能，设计选择 意义 发现不同系统在较高级别上的共同特性 获得正确的构架以进行正确的系统设计 根据一些原则在不同的软件构架中选择 有利于系统较高级别性质的描述和分析,一些不正确的观念-1,观念之一：我们拥有一套讲述如何开发软件的书籍，书中充满了标准与示例，可以帮助我们解决软件开发中遇到的任何问题。 客观情况：好的参考书无疑能指导我们的工作。充分利用书籍中的方法、技术和技巧，可以有效地解决软件开发中大量常见的问题。但实践者并不能因此依赖于书籍，这是因为：（1）现实的工作中，由于条件千差万别，即使是相当成熟的软件工程规范，常常也无法套用。（2）软件技术日新月异，没有哪一种软件标准能长盛不衰。祖传秘方在某些领域很吃香，而在软件领域则意味着落后。 观念之二：我们拥有最好的开发工具、最好的计算机，一定能做出优秀的软件。 客观情况：良好的开发环境只是产出成果的必要条件，而不是充分条件。如果拥有好环境的是一群庸人，难保他们不干出南辕北辙的事情。,一些不正确的观念-2,观念之三：如果我们落后于计划，可以增加更多的程序员来解决。 客观情况：软件开发不同于传统的农业生产，人多不见得力量大。如果给落后于计划的项目增添新手，可能会更加延误项目。因为：（1）新手会产生很多新的错误，使项目混乱。（2）老手向新手解释工作以及交流思想都要花费时间，使实际开发时间更少。所以科学的项目计划很重要，不在乎计划能提前多少，重在恰如其分。如果用“大跃进”的方式奔向共产主义，只会产生倒退的后果。 观念之四：既然需求分析很困难，不管三七二十一先把软件做了再说，反正软件是灵活的，随时可以修改。 客观情况：对需求把握得越准确，软件的修修补补就越少。有些需求在一开始时很难确定，在开发过程中要不断地加以改正。软件修改越早代价越少，修改越晚代价越大，就跟治病一样道理。,一些有争议的观念-1,争议之一：如果软件运行较慢，是换一台更快的计算机，还是设计一种更快的算法？ 观点：如果开发软件的目的是为了学习或是研究，那么应该设计一种更快的算法。如果该软件已经用于商业，则需谨慎考虑：若换一台更快的计算机能解决问题，则是最快的解决方案。改进算法虽然可以从根本上提高软件的运行速度，但可能引入错误以及延误进程。技术狂毫无疑问会选择后者，因为他们觉得放弃任何可以优化的机会就等于犯罪。 类似的争议还有：是买现成的程序，还是彻底自己开发？技术人员和商业人士常常会有不同的选择。 争议之二：有最好的软件工程方法，最好的编程语言吗？ 观点：在软件领域永远没有最好的，只有更好的。能解决问题的都是好方法或是好语言。程序员在最初学习Basic、Fortran、 Pascal、C、C+等语言时会感觉一个比一个好，不免有喜新厌旧之举。而如今的Visual Basic、Delphi、Visual C+、Java等