软件开发过程概述.docx
《软件开发过程概述.docx》由会员分享，可在线阅读，更多相关《软件开发过程概述.docx（30页珍藏版）》请在冰豆网上搜索。
软件开发过程概述
第1章软件开发过程概述
1.1软件开发过程概述
1.1.1 软件的概念
软件（Software）简单的说就是那些在计算机中能看的着，但摸不着的东西，概念性的说软件也称为“软设备”，广义地说软件是指系统中的程序以及开发、使用程序所需要的所有文档的集合软件分为系统软件和应用软件。
软件并不只是包括可以在计算机上运行的程序，及这些程序相关的文件一般也被认为是软件的一部分。
软件被应用于世界的各个领域，对人们的生活和工作都产生了深远的影响。
1.系统软件
系统软件是负责管理计算机系统中各种独立的硬件，使得它们可以协调工作。
系统软件使得计算机使用者和其他软件将计算机当作一个整体而不需要顾及到底层每个硬件是如何工作的。
一般来讲，系统软件包括操作系统和一系列基本的工具（比如编译器，数据库管理，存储器格式化，文件系统管理，用户身份验证，驱动管理，网络连接等方面的工具）。
2.应用软件
应用软件是为了某种特定的用途而被开发的软件。
它可以是一个特定的程序，比如一个图像浏览器。
也可以是一组功能联系紧密，可以互相协作的程序的集合，比如微软的Office软件。
也可以是一个由众多独立程序组成的庞大的软件系统，比如数据库管理系统。
较常见的有：
文字处理软件如WPS、Word等；信息管理软件；辅助设计软件如AutoCAD；实时控制软件；教育及娱乐软件。
1.1.2 编程及软件开发
软件开发的内容是：
需求、设计、编程和测试。
（1）需求：
不仅仅是用户需求，应该是开发中遇到的所有的需求。
比如，你首先要知道做这个项目是为了解决什么问题；测试案例中应该输入什么数据......为了清楚地知道这些需求，你经常要和客户、项目经理等交流。
（2）设计：
编码前，肯定有个计划告诉你要做什么，结构是怎样等等。
你一定要按照这个来做，否则可能会一团糟。
（3）编程：
如果在项目截止日，你的程序不能跑起来或达不到客户的要求，你就拿不到钱。
（4）测试：
目的是让你知道，什么时候算是完成了。
如果你聪明，你就应该先写测试，这样可以及时知道你是否真地完成了。
否则，你经常会不知道，到底有哪些功能是真正完成了，离预期目标还差多远。
软件开发中，客户和开发人员都有自己的基本权利和义务。
（1）客户：
定义每个用户需求的商业优先级；
制订总体计划，包括用多少投资、经过多长时间、达到什么目的；
在项目开发过程中的每个工作周，都能让投资获得最大的收益；
通过重复运行你所指定的功能测试，准确地掌握项目进展情况；
能随时改变需求、功能或优先级，同时避免昂贵的再投资；能够根据各种变化及时调整项目计划；
能够随时取消项目；项目取消时，以前的开发工作不是一堆垃圾，已开发完的功能是合乎要求的，正在进行或未完成的的工作则应该是不难接手的。
（2）开发人员：
知道要做什么，以及要优先做什么；
工作有效率；
有问题或困难时，能得到客户、同事、上级的回答或帮助；
对工作做评估，并根据周围情况的变化及时重新评估；
积极承担工作，而不是消极接受分配。
1.1.3 软件开发过程
软件开发过程一般分为以下6个阶段：
1.计划
对所要解决的问题进行总体定义，包括了解用户的要求及现实环境，从技术、经济和社会因素等3个方面研究并论证本软件项目的可行性，编写可行性研究报告，探讨解决问题的方案，并对可供使用的资源（如计算机硬件、系统软件、人力等）成本，可取得的效益和开发进度作出估计。
制订完成开发任务的实施计划。
2.分析
软件需求分析就是回答做什么的问题。
它是一个对用户的需求进行去粗取精、去伪存真、正确理解，然后把它用软件工程开发语言（形式功能规约，即需求规格说明书）表达出来的过程。
本阶段的基本任务是和用户一起确定要解决的问题，建立软件的逻辑模型，编写需求规格说明书文档并最终得到用户的认可。
需求分析的主要方法有结构化分析方法、数据流程图和数据字典等方法。
本阶段的工作是根据需求说明书的要求，设计建立相应的软件系统的体系结构，并将整个系统分解成若干个子系统或模块，定义子系统或模块间的接口关系，对各子系统进行具体设计定义，编写软件概要设计和详细设计说明书，数据库或数据结构设计说明书，组装测试计划。
3.设计
软件设计可以分为概要设计和详细设计两个阶段。
实际上软件设计的主要任务就是将软件分解成模块是指能实现某个功能的数据和程序说明、可执行程序的程序单元。
可以是一个函数、过程、子程序、一段带有程序说明的独立的程序和数据，也可以是可组合、可分解和可更换的功能单元。
模块，然后进行模块设计。
概要设计就是结构设计，其主要目标就是给出软件的模块结构，用软件结构图表示。
详细设计的首要任务就是设计模块的程序流程、算法和数据结构，次要任务就是设计数据库，常用方法还是结构化程序设计方法。
4.编码
软件编码是指把软件设计转换成计算机可以接受的程序，即写成以某一程序设计语言表示的"源程序清单"。
充分了解软件开发语言、工具的特性和编程风格，有助于开发工具的选择以及保证软件产品的开发质量。
当前软件开发中除在专用场合，已经很少使用二十世纪80年代的高级语言了，取而代之的是面向对象的开发语言。
而且面向对象的开发语言和开发环境大都合为一体，大大提高了开发的速度。
5.测试
软件测试的目的是以较小的代价发现尽可能多的错误。
要实现这个目标的关键在于设计一套出色的测试用例（测试数据和预期的输出结果组成了测试用例）。
如何才能设计出一套出色的测试用例，关键在于理解测试方法。
不同的测试方法有不同的测试用例设计方法。
两种常用的测试方法是白盒法测试对象是源程序，依据的是程序内部的的逻辑结构来发现软件的编程错误、结构错误和数据错误。
结构错误包括逻辑、数据流、初始化等错误。
用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果。
白盒法和黑盒法依据的是软件的功能或软件行为描述，发现软件的接口、功能和结构错误。
其中接口错误包括内部/外部接口、资源管理、集成化以及系统错误。
黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。
黑盒法。
6.维护
维护是旨在已完成对软件的研制（分析、设计、编码和测试）工作并交付使用以后，对软件产品所进行的一些软件工程的活动。
即根据软件运行的情况，对软件进行适当修改，以适应新的要求，以及纠正运行中发现的错误。
编写软件问题报告、软件修改报告。
一个中等规模的软件，如果研制阶段需要一年至二年的时间，在它投入使用以后，其运行或工作时间可能持续五年至十年。
那么它的维护阶段也是运行的这五年至十年期间。
在这段时间，人们几乎需要着手解决研制阶段所遇到的各种问题，同时还要解决某些维护工作本身特有的问题。
做好软件维护工作，不仅能排除障碍，使软件能正常工作，而且还可以使它扩展功能，提高性能，为用户带来明显的经济效益。
然而遗憾的是，对软件维护工作的重视往往远不如对软件研制工作的重视。
而事实上，和软件研制工作相比，软件维护的工作量和成本都要大得多。
在实际开发过程中，软件开发并不是从第一步进行到最后一步，而是在任何阶段，在进入下一阶段前一般都有一步或几步的回溯。
在测试过程中的问题可能要求修改设计，用户可能会提出一些需要来修改需求说明书等。
1.2 软件需求分析
1.2.1 需求获取
需求获取（requirementelicitation）是需求工程的主体。
对于所建议的软件产品，获取需求是一个确定和理解不同用户类的需要和限制的过程。
获取用户需求位于软件需求三个层次的中间一层。
业务需求决定用户需求，它描述了用户利用系统需要完成的任务。
从这些任务中，分析者能获得用于描述系统活动的特定的软件功能需求，这些系统活动有助于用户执行他们的任务。
需求获取是在问题及其最终解决方案之间架设桥梁的第一步。
获取需求的一个必不可少的结果是对项目中描述的客户需求的普遍理解。
一旦理解了需求，分析者、开发者和客户就能探索出描述这些需求的多种解决方案。
参及需求获取者只有在他们理解了问题之后才能开始设计系统，否则，对需求定义的任何改进，设计上都必须大量的返工。
把需求获取集中在用户任务上—而不是集中在用户接口上—有助于防止开发组由于草率处理设计问题而造成的失误。
需求获取、分析、编写需求规格说明和验证并不遵循线性的顺序，这些活动是相互隔开、增量和反复的。
当你和客户合作时，你就将会问一些问题，并且取得他们所提供的信息（需求获取）。
同时，你将处理这些信息以理解它们，并把它们分成不同的类别，还要把客户需求同可能的软件需求相联系（分析）。
然后，你可以使客户信息结构化，并编写成文档和示意图（说明）。
下一步，就可以让客户代表评审文档并纠正存在的错误（验证）。
这四个过程贯穿着需求分析的整个阶段。
需求获取可能是软件开发中最困难、最关键、最易出错及最需要交流的方面。
需求获取只有通过有效的客户—开发者的合作才能成功。
分析者必须建立一个对问题进行彻底探讨的环境，而这些问题及产品有关。
为了方便清晰地进行交流，就要列出重要的小组，而不是假想所有的参及者都持有相同的看法。
对需求问题的全面考察需要一种技术，利用这种技术不但考虑了问题的功能需求方面，还可讨论项目的非功能需求。
确定用户已经理解：
对于某些功能的讨论并不意味着即将在产品中实现它。
对于想到的需求必须集中处理并设定优先级，以避免一个不能带来任何益处的无限大的项目。
需求获取是一个需要高度合作的活动，而并不是客户所说的需求的简单誊本。
作为一个分析者，你必须透过客户所提出的表面需求理解他们的真正需求。
询问一个可扩充（open-ended）的问题有助于你更好地理解用户目前的业务过程并且知道新系统如何帮助或改进他们的工作。
调查用户任务可能遇到的变更，或者用户需要使用系统其它可能的方式。
想像你自己在学习用户的工作，你需要完成什么任务？
你有什么问题？
从这一角度来指导需求的开发和利用。
还有，探讨例外的情况：
什么会妨碍用户顺利完成任务？
对系统错误情况的反映，用户是如何想的？
询问问题时，以“还有什么能”,”当?
时，将会发生什么”“你有没有曾经想过”,“有没有人曾经”为开头。
记下每一个需求的来源，这样向下跟踪直到发现特定的客户。
有些时候，尝试着问一些“愚蠢”的问题也有助于客户打开话匣子。
如果你直接要求客户写出业务是如何实现的，客户十有八九无法完成。
但是如果你尝试着问一些实际的问题，例如：
“以我的理解，你们收到订单后，会...”。
客户立刻就会指出你的错误，并滔滔不绝的开始谈论业务，而你，就在一边仔细的聆听吧。
这一招就叫做“抛砖引玉”。
需求讨论会上必须要使用笔记本电脑，还要指定一个打字熟练的人把所有的讨论记录下来，记录的同时还要做一定的整理。
如果不这样做，那么你结束会议的时候就会发现，所有的讨论只剩下一个模糊的印象，需求对你来说仍然是一件遥远的事情。
在座谈讨论之后，记下所讨论的条目（item），并请参及讨论的用户评论并更正。
及早并经常进行座谈讨论是需求获取成功的一个关键途径，因为只有提供需求的人才能确定是否真正获取需求。
进行深入收集和分析以消除任何冲突或不一致性。
尽量把客户所持的假设解释清楚，特别是那些发生冲突的部分。
从字里行间去理解以明确客户没有表达清楚但又想加入的特性或特征。
Gause和Weinberg（1989）提出使用“上下文无关问题”—这是一个高层次的问题，它可以获取业务问题和可能的解决方案的全部信息。
客户对这些问题的回答诸如“产品要求怎样的精确度”或“你能帮我解释一下你为什么不同意某人的回答吗？
”这些回答可以更直接地认识问题，而这是封闭（close-end）问题所不能做到的。
需求获取利用了所有可用的信息来源，这些信息描述了问题域或在软件解决方案中合理的特性。
一个研究表明：
比起不成功的项目，一个成功的项目在开发者和客户之间采用了更多的交流方式（KielandCarmel1995）。
及单个客户或潜在的用户组一起座谈，对于业务软件包或信息管理系统（MIS）的应用来说是一种传统的需求来源。
直接聘请用户进行获取需求的过程是为项目获得支持和买入（buy-in）的一种方式。
尽量理解用户用于表述他们需求的思维过程。
充分研究用户执行任务时作出决策的过程，并提取出潜在的逻辑关系。
流程图和决策树是描述这些逻辑决策途径的好方法。
在需求获取的过程中，你可能会发现对项目范围的定义存在误差，不是太大就是太小。
如果范围太大，你将要收集比真正需要更多的需求，以传递足够的业务和客户的值，此时获取过程将会拖延。
如果项目范围太小，那么客户将会提出很重要的但又在当前产品范围之外的需求。
当前的范围太小，以致不能提供一个令人满意的产品。
需求的获取将导致修改项目的范围和任务，但作出这样具有深远影响的改变，一定要小心谨慎。
正如经常所说的，需求主要是关于系统做什么，而解决方案如何实现是属于设计的范围。
这样说虽然很简洁，但似乎过于简单化。
需求的获取应该把重点放在“做什么”上，但在分析和设计之间还是存在一定的距离。
你可以使用假设“怎么做”来分类并改善你对用户需求的理解。
在需求的获取过程中，分析模型、屏幕图形和原型可以使概念表达得更加清楚，然后提供一个寻找错误和遗漏的办法。
把你在需求开发阶段所形成的模型和屏幕效果看成是方便高效交流的概念性建议，而不应该看成是对设计者选择的一种限制。
需求获取讨论会中如果参及者过多，就会减慢进度。
人数大致控制在5到7人是最好的。
这些人包括客户、系统设计者、开发者和可视化设计者等主要工程角色。
相反地，从极少的代表那里收集信息或者只听到呼声最高、最有舆论影响的用户的声音，也会造成问题。
这将导致忽视特定用户类的重要的需求，或者其需求不能代表绝大多数用户的需要。
最好的权衡在于选择一些授权为他们的用户类发言的产品代表者，他们也被同组用户类的其它代表所支持。
1.2.2 需求分析
1.定义
所谓“需求分析”，是指对要解决的问题进行详细的分析，弄清楚问题的要求，包括需要输入什么数据，要得到什么结果，最后应输出什么。
可以说，“需求分析”就是确定要计算机“做什么”。
在软件工程中，需求分析指的是在建立一个新的或改变一个现存的电脑系统时描写新系统的目的、范围、定义和功能时所要做的所有的工作。
需求分析是软件工程中的一个关键过程。
在这个过程中，系统分析员和软件工程师确定顾客的需要。
只有在确定了这些需要后他们才能够分析和寻求新系统的解决方法。
在软件工程的历史中，很长时间里人们一直认为需求分析是整个软件工程中最简单的一个步骤，但在过去十年中越来越多的人认识到它是整个过程中最关键的一个过程。
假如在需求分析时分析者们未能正确地认识到顾客的需要的话，那么最后的软件实际上不可能达到顾客的需要，或者软件无法在规定的时间里完工。
2.特点
需求分析是一项重要的工作，也是最困难的工作。
该阶段工作有以下特点：
（1）用户及开发人员很难进行交流
在软件生存周期中，其它四个阶段都是面向软件技术问题，只有本阶段是面向用户的。
需求分析是对用户的业务活动进行分析，明确在用户的业务环境中软件系统应该"做什么"。
但是在开始时，开发人员和用户双方都不能准确地提出系统要"做什么？
"。
因为软件开发人员不是用户问题领域的专家，不熟悉用户的业务活动和业务环境，又不可能在短期内搞清楚；而用户不熟悉计算机应用的有关问题。
由于双方互相不了解对方的工作，又缺乏共同语言，所以在交流时存在着隔阂。
（2）用户的需求是动态变化的
对于一个大型而复杂的软件系统，用户很难精确完整地提出它的功能和性能要求。
一开始只能提出一个大概、模糊的功能，只有经过长时间的反复认识才逐步明确。
有时进入到设计、编程阶段才能明确，更有甚者，到开发后期还在提新的要求。
这无疑给软件开发带来困难。
（3）系统变更的代价呈非线性增长
需求分析是软件开发的基础。
假定在该阶段发现一个错误，解决它需要用一小时的时间，到设计、编程、测试和维护阶段解决，则要花2.5、5、25、100倍的时间。
因此，对于大型复杂系统而言，首先要进行可行性研究。
开发人员对用户的要求及现实环境进行调查、了解，从技术、经济和社会因素三个方面进行研究并论证该软件项目的可行性，根据可行性研究的结果，决定项目的取舍。
3.任务
（1）确定对系统的综合要求
虽然功能需求是对软件系统的一项基本需求，但却并不是唯一的需求，通常对软件系统有下述几方面的综合要求。
a、功能需求
b、性能需求
c、可靠性和可用性需求
d、出错处理需求
e、接口需求
f、约束
g、逆向需求
h、将来可能提出的要求
（2）分析系统的数据要求
任何一个软件本质上都是信息处理系统，系统必须处理的信息和系统应该产生的信息很大程度上决定了系统的面貌，对软件设计有深远的影响，因此，必须分析系统的数据要求，这是软件分析的一个重要任务。
分析系统的数据要求通常采用建立数据模型的方法。
复杂的数据由许多基本的数据元素组成，数据结构表示数据元素之间的逻辑关系。
利用数据字典可以全面地定义数据，但是数据字典的缺点是不够直观。
为了提高可理解性，常常利用图形化工具辅助描述数据结构。
用用的图形工具有层次方框图和Warnier图。
（3）导出系统的逻辑模型
综合上述两项分析的结果可以导出系统的详细的逻辑模型，通常用数据流图、E-R图、状态转换图、数据字典和主要的处理算法描述这个逻辑模型。
（4）修正系统开发计划
根据在分析过程中获得的对系统的更深入的了解，可以比较准确地估计系统的成本和进度，修正以前定制的开发计划。
4.方法
进行需求分析，应注意以下几点：
（1）首先调查组织机构情况
包括了解该组织的部门组成情况，各部门的职能等，为分析信息流程作准备。
（2）然后调查各部门的业务活动情况
包括了解各个部门输入和使用什么数据，如何加工处理这些数据，输出什么信息，输出到什么部门，输出结果的格式是什么。
（3）协助用户明确对新系统的各种要求
包括信息要求、处理要求、完全性及完整性要求。
（4）确定新系统的边界
确定哪些功能由计算机完成或将来准备让计算机完成，哪些活动由人工完成。
由计算机完成的功能就是新系统应该实现的功能。
需求分析常用的调查方法有：
（1）跟班作业
通过亲身参加业务工作来了解业务活动的情况。
这种方法可以比较准确地理解用户的需求，但比较耗费时间。
（2）开调查会
通过及用户座谈来了解业务活动情况及用户需求。
座谈时，参加者之间可以相互启发。
（3）请专人介绍。
（4）询问
对某些调查中的问题，可以找专人询问。
（5）设计调查表请用户填写
如果调查表设计得合理，这种方法是很有效，也很易于为用户接受的。
（6）查阅记录
即查阅及原系统有关的数据记录，包括原始单据、账簿、报表等。
通过调查了解了用户需求后，还需要进一步分析和表达用户的需求。
分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。
1.2.3 需求文档的编写
需求的写作形式一般分为两种，面向对象和面向过程。
对于不同的受众和应用,采取不同的形式。
面向过程的形式：
主要的思想是IPO的原则，也就是“输出－处理－输出”，文档格式：
（1）首先是对于整体系统的简略介绍：
目的，确定文档描述的对象和大体内容
（2）系统上下文，介绍系统和其他系统之间的关系，边界如何划分
（3）系统的需求分解，介绍完成整体系统需要分解的大框架的需求内容
（4）具体需求
对于具体需求很简单，按照如下形式完成：
a、简介
b、输入
c、处理
d、输出
（5）除了具体需求外，还包括其他相关方面的需求：
a、接口需求（及其他系统、子系统、模块的接口，用户接口等）所谓的界面原型，其实是接口需求中的内容。
由于界面原型通常都很重要，所以可以将这一部分拿出来放到具体需求中去。
界面原型不是仅仅一张图，还包括界面元素的描述、范围、错误提示信息等
b、性能需求
c、依赖：
依赖的数据库、第三方软件等
d、需求优先级排序，用于衡量开发策略
（6）参考文档
面向对象的形式，整体文档架构是和上面描述的一致，区别只有两点。
（1）在系统的需求分解处，用用例的包图来描述、这个很简单，其实就是上面文字描述的图形化显示。
（2）主要区别是具体需求，通过用例的形式来描述，包括：
a、介绍
b、用户（actor）
c、前置条件
d、后置条件
e、触发条件
f、事件流
g、备选事件流
1.3 软件系统架构设计
软件架构（softwarearchitecture）是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。
软件架构是一个系统的草图。
软件架构描述的对象是直接构成系统的抽象组件。
各个组件之间的连接则明确和相对细致地描述组件之间的通讯。
在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。
在面向对象领域中，组件之间的连接通常用接口_（计算机科学）来实现。
软件体系结构是构建计算机软件实践的基础。
及建筑师设定建筑项目的设计原则和目标，作为绘图员画图的基础一样，一个软件架构师或者系统架构师陈述软件构架以作为满足不同客户需求的实际系统设计方案的基础。
软件构架是一个容易理解的概念，多数工程师（尤其是经验不多的工程师）会从直觉上来认识它，但要给出精确的定义很困难。
特别是，很难明确地区分设计和构架：
构架属于设计的一方面，它集中于某些具体的特征。
在“软件构架简介”中，DavidGArlan和MaryShaw认为软件构架是有关如下问题的设计层次：
“在计算的算法和数据结构之外，设计并确定系统整体结构成为了新的问题。
结构问题包括总体组织结构和全局控制结构；通信、同步和数据访问的协议；设计元素的功能分配；物理分布；设计元素的组成；定标及性能；备选设计的选择。
”
但构架不仅是结构；IEEEWorkingGrouponArchitecture把其定义为“系统在其环境中的最高层概念”。
构架还包括“符合”系统完整性、经济约束条件、审美需求和样式。
它并不仅注重对内部的考虑，而且还在系统的用户环境和开发环境中对系统进行整体考虑，即同时注重对外部的考虑。
在RationalUnifiedProcESs中，软件系统的构架（在某一给定点）是指系统重要构件的组织或结构，这些重要构件通过接口及不断减小的构件及接口所组成的构件进行交互。
从和目的、主题、材料和结构的联系上来说，软件架构可以和建筑物的架构相比拟。
一个软件架构师需要有广泛的软件理论知识和相应的经验来事实和管理软件产品的高级设计。
软件架构师定义和设计软件的模块化，模块之间的交互，用户界面风格，对外接口方法，创新的设计特性，以及高层事物的对象操作、逻辑和流程。
1.3.1软件架构的要素
一般而言，软件系统的架构（ArchitECture）有两个要素：
（1）它是一个软件系统从整体到部分的最高层次的划分。
一个系统通常是由元件组成的，而这些元件如何形成、相互之间如何发生作用，则是关于这个系统本身结构的重要信息。
详细地说，就是要包括架构元件（ArchitectureComponent）、联结器（Connector）、任务流（TASk-flow）。
所谓架构元素，也就是组成系统的核心"砖瓦"，而联结器则描述这些元件之间通讯的路径、通讯的机制、通讯的预期结果，任务流则描述系统如何使用这些元件和联结器完成某一项需求。
（2）建造一个系统所作出的最高层次的、以后难以更改的，商业的和技术的决定。
在建造一个系统之前会有很多的重要决定需要事先作出，而一旦系统开始进行详细设计甚至建造，这些决定就很难更改甚至无法更改。
显然，这样的决定必定是有关系统设计成败的最重要决定，必须经过非常慎重的研究和考察。
1.3.2软件架构的目标
正如同软件本身有其要达到的目标一样，架构设计要达到的目标是什么呢？
一般而言，软件架构设计要达到如下的目标：
（1）可靠性（Reliable）。
软件系统对于用户的商业经营和管理来说极为重要，因此软件系统必须非常
升级会员 