我对软件开发过程的理解Word格式.docx
《我对软件开发过程的理解Word格式.docx》由会员分享，可在线阅读，更多相关《我对软件开发过程的理解Word格式.docx（8页珍藏版）》请在冰豆网上搜索。
析的
特
占
八
和
任
务.
・1
法,
.2
求
分
析
的
—
般
方
…1
第
2
章静
压
轴承多
孔
质石
墨渗
透
率的
研
究
.3
■
概
要
设
，十
述.
•
••
3
标.
计
目
计・
详
细
4
码・
章
编
5
第试・
测
6
软
件
试
内
容.
5.1.1正确性测
试…6
5.1.2性能与效率测
5.1.3易用性测
试….…
5.2软件测试的常用方
法.6
5.2.1黑盒测
试…
.7
5.2.2白盒测
试
5.3软件测试的常用工
具
5.3.1白盒测试工
具…
5.3.2黑盒测试工
具
.8
第6章维
护
•••••••
结
论
第1章需求分析
1.1需求分析的特点和任务
需求分析是软件开发的第一步。
获取需求的一个必不可少的结果是对项目中描述的客户需求的普遍理解。
一旦理解了需求，分析者、开发者和客户就能探索出描述这些需求的多种解决方案。
参与需求获取者只有在他们理解了问题之后才能开始设计系统，否则，对需求定义的任何改进，设计上都必须大量的返工。
把需求获取集中在用户任务上一而不是集中在用户接口上一有助于防止开发组由于草率处理设计问题而造成的失误。
有儿种原因使需求分析变得困难：
（1）客户说不清楚需求；
（2）需求自身经常变动；
（3）分析人员或客户理解有误。
需求获取、分析、编写需求规格说明和验证并不遵循线性的顺序，这些活动是相互隔开、增量和反复的。
当你和客户合作时，你就将会问一些问题，并且取得他们所提供的信息（需求获取）。
同时，你将处理这些信息以理解它们，并把它们分成不同的类别，还要把客户需求同可能的软件需求相联系（分析）。
然后，你可以使客户信息结构化，并编写成文档和示意图（说明）。
下一步，就可以让客户代表评审文档并纠正存在的错误（验证）。
这四个过程贯穿着需求分析的整个阶段。
需求获取可能是软件开发中最困难、最关键、最易出错及最需要交流的方面。
需求获取只有通过有效的客户一开发者的合作才能成功。
分析者必须建立一个对问题进行彻底探讨的环境，而这些问题与产品有关。
为了方便清晰地进行交流，就要列出重要的小组，而不是假想所有的参与者都持有相同的看法。
对需求问题的全面考察需要一种技术，利用这种技术不但考虑了问题的功能需求方面，还可讨论项H的非功能需求。
确定用户已经理解：
对于某些功能的讨论并不意味着即将在产品中实现它。
对于想到的需求必须集中处理并设定优先级，以避免一个不能带来任何益处的无限大的项目。
1.2需求分析的一般方法
跟班作业。
通过亲身参加业务工作来了解业务活动的情况。
这种方法可以比较准确地理解用户的需求，但比较耗费时间。
开调查会。
通过与用户座谈来了解业务活动情况及用户需求。
座谈时，参加者之间可以相互启发。
需求获取讨论会中如果参与者过多，就会减慢进度。
人数大致控制在5到7人是最好的。
这些人包括客户、系统设计者、开发者和可视化设计者等主要工程角色。
相反地，从极少的代表那里收集信息或者只听到呼声最高、最有舆论影响的用户的声音，也会造成问题。
这将导致忽视特定用户类的重要的需求，或者其需求不能代表绝大多数用户的需要。
最好的权衡在于选择一些授权为他们的用户类发言的产品代表者，他们也被同组用户类的其它代表所支持。
设计调查表请用户填写。
如果调查表设计得合理，这种方法是很有效，也很易于为用户接受的。
查阅记录。
即查阅与原系统有关的数据记录，包括原始单据、账簿、报表等。
通过调查了解了用户需求后，还需要进一步分析和表达用户的需求。
分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。
第2章概要设计
2.1概要设计概述
概要设计重点在于将模块分解为对象并阐明对象之间的关系，引用架构设计说明书中的模块图，并阐述对于模块进行设计的大致思路。
主要工作是根据该模块的职责对模块进行概要设计（分解模块为对象、描述对象的职责以及声明对象之间的接口），绘制模块的对象图、对象间的依赖图以及模块主要功能的序列图，分别加以描述并相应的描述模块异常的处理方法。
如果需要并描述数据视图。
2.2概要设计的目标
正如同软件本身有其要达到的LI标一样，架构设计要达到的目标是什么呢？
一般而言，软件架构设计要达到如下的目标：
（1）可鼎性（Reliable）。
软件系统对于用户的商业经营和管理来说极为重要，因此软件系统必须非常可黑。
（2）安全行（Secure）＜＞软件系统所承担的交易的商业价值极高，系统的安全性非常重要。
（3）可扩展性（SCAlable）。
软件必须能够在用户的使用率、用户的数目增加很快的情况下，保持合理的性能。
只有这样，才能适应用户的市场扩展得可能性。
（4）可定制化（CuSTomizable）。
同样的一套软件，可以根据客户群的不同和市场需求的变化进行调整。
第3章详细设计
详细设计重点在于对每个模块进行实现，将模块的对象分解为属性和方法，并阐述如何实现。
主要工作视根据模块概要设汁详细描述对于模块内对象的实现，包括对象的职责、属性、方法、对象内功能的流程图、对象关联的类、对象的异常。
（需要绘制的主要为类图）
详细设计的LI标有两个：
实现模块功能的算法要逻辑上正确和算法描述要简明易懂。
在软件详细设计阶段，将生成详细设计说明书，为每个模块确定采用的算法,确定每个模块使用的数据结构，确定每个模块的接口细节。
在软件详细设计结束时，软件详细设计说明书通过复审的形成形成正式文档，作为下一个阶段的工作依据。
详细设计的主要任务是：
为每个模块确定采用的算法，选择某种适当的工具表达算法的过程，写出模块的详细过程性描述；
确定每一模块使用的数据结构；
确定模块接口的细节，包括对系统外部的接口和用户界面，对系统内部其它模块的接口，以及模块输入数据、输岀数据及局部数据的全部细节；
为每一个模块设计出一组测试用例，以便在编码阶段对模块代码（即程序）进行预定的测试，模块的测试用例是软件测试讣划的重要组成部分，通常应包括输入数据，期望输出等内容。
第4章编码
软件编码是将上一阶段的详细设计得到的处理过程的描述转换为基于某种汁算机语言的程序，即源程序代码。
编码需注意根据项LI的应用领域选择适当的编程语言、编程的软硬件环境以及编码的程序设计风格等事项。
在计划阶段，极少考虑程序语言的技术特性。
但在选定资源时，要规划将要使用的支撑工具，就要确定一个具体的编译器或者确定一个程序设计环境。
如果软件开发组的成员对所要使用的语言不熟悉，那么在成本及进度佔算时必须把学习的工作量估算在内。
一旦确定了软件需求，待选用的程序语言的技术特性就显得非常重要了。
如果需要复杂的数据结构，就要仔细衡量有哪些语言能提供这些复杂的数据结构。
如果首要的是高性能及实时处理的能力，就可选用适合于实时应用的语言或效率高的语言。
如果该应用有许多输出报告或繁杂的文件处理，最好是根据软件的要求，选定一种适合于该项工作的语言。
软件的设计质量与程序设计语言的技术性能无关（面向对象设计例外）。
但在实现软件设讣转化为程序代码时，转化的质量往往受语言性能的影响。
因而也会影响到设计方法。
语言的技术性能对测试和维护的影响是多种多样的。
例如，直接提供结构化构造的语言有利于减少循环带来的复杂性（即McCabe复杂性），使程序易读、易测试、易维护。
另一方面，语言的某些技术特性却会妨碍测试。
例如，在面向对象的语言程序中，III于实行了数据封装，使得监控这些数据的执行状态变得比较困难；
山于建立了对象类的继承结构，使得高内聚、低耦合的要求受到破坏，增加了测试的困难。
此外，只要语言程序的可读性强，而且可以减少程序的复杂性,这样的程序设计语言对于软件的维护就是有利的。
第5章测试
不论是对软件的模块还是整个系统，总有共同的内容要测试，如正确性测试,容错性测试，性能与效率测试，易用性测试，文档测试等。
5.1软件测试的内容
5.1.1正确性测试
正确性测试乂称功能测试，它检查软件的功能是否符合规格说明。
山于正确性是软件最重要的质量因素，所以其测试也最重要。
基本的方法是构造一些合理输入，检查是否得到期望的输出。
这是一种枚举方法。
倘若枚举空间是无限的，那可惨了，还不如回家种土豆有盼头。
测试人员一定要设法减少枚举的次数，否则没好日子过。
关键在于寻找等价区间，因为在等价区间中，只需用任意值测试一次即可。
5.1.2性能与效率测试
性能与效率测试主要是测试软件的运行速度和对资源的利用率。
有时人们关心测试的“绝对值”，如数据送输速率是每秒多少比特。
有时人们关心测试的“相对值”，如某个软件比另一个软件快多少倍。
在获取测试的“绝对值”时，我们要充分考虑并记录运行环境对测试的影响。
5.1.3易用性测试
易用性测试没有一个量化的指标，主观性较强。
调查表明，当用户不理解软件中的某个特性时，大多数人首先会向同事、朋友请教。
要是再不起作用，就向产品支持部门打电话。
只有30%的用户会查阅用户手册。
5.2软件测试的常用方法
从测试是否针对系统的内部结构和具体实现算法的角度来看，可分为口盒测试和黑盒测试。
5.2.1.黑盒测试
黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。
5.2.2.白盒测试
白盒测试也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证。
5.3软件测试的常用工具
tr前用于测试的工具已经比较多了，测试工具的应用可以提高测试的质量、测试的效率、减少测试过程中的重复劳动、实现测试自动化，这些测试工具一般可分为口盒测试工具、黑盒测试工具、性能测试工具，另外还有用于测试管理的工具，本文对常用的测试工具作一个分析比较。
5.3.1白盒测试工具
（1）Jtest
是一个代码分析和动态类、组件测试工具，是一个集成的、易于使用和自动化的Java单元测试工具。
它增强代码的稳定性，防止软件错误。
（2）Jcontract
Jcontract在系统级验证类/部件是否正确工作并被正确使用。
Jcontract是个独立工具，在功能上是Jtest的补充。
可以用Jcontract插装按DbC注解的Java代码。
当您将类/部件组装成系统时，Jcontract在运行时监视并报告错用和功能性问题。
Jcontract帮助每个开发人员有效地考核类/部件的系统级行为。
5.3.2黑盒测试工具
（1）WinRunner
MercuryInteractive公司的WinRunner是一种企业级的功能测试工具,用于检测应用程序是否能够达到预期的功能及正常运行。
通过自动录制、检测和回放用户的应用操作，WinRunner能够有效地帮助测试人员对复杂的企业级应用的不同发布版进行测试，提高测试人员的工作效率和质量，确保跨平台的、复杂的企业级应用无故障发布及长期稳定运行。
企业级应用可能包括Web应用系统，ERP系统，CRM系统等等。
（2）SilkTestSilkTestInternational
Segue公司的标准的、面向多语种企业级应用的功能和回归测试工具。
让用户能跨语和|、跨平台和跨Web浏览器，高效率地进行各种类型的应用可為性测试。
第6章维护
维护是旨在已完成对软件的研制（分析、设计、编码和测试）工作并交付使用以后，对软件产品所进行的一些软件工程的活动。
即根据软件运行的情况，对软件进行适当修改，以适应新的要求，以及纠正运行中发现的错误。
编写软件问题报告、软件修改报告。
软件维护是一项长期而繁琐的任务，长时间的跨度可能会牵扯到文档、代码更新，人员更换等。
所以有关软件的文档一定要写好、保存好。
另外开发团队要有自己的文档代码规范标准等，也是做好软件维护的前提条件。
一个中等规模的软件，如果研制阶段需要一年至二年的时间，在它投入使用以后，其运行或工作时间可能持续五年至十年。
那么它的维护阶段也是运行的这五年至十年期间。
在这段时间，人们儿乎需要着手解决研制阶段所遇到的各种问题，同时还要解决某些维护工作本身特有的问题。
做好软件维护工作，不仅能排除障碍，使软件能正常工作，而且还可以使它扩展功能，提高性能，为用户带来明显的经济效益。
然而遗憾的是，对软件维护工作的重视往往远不如对软件研制工作的重视。
而事实上，和软件研制工作相比，软件维护的工作量和成本都要大得多。
在实际开发过程中，软件开发并不是从第一步进行到最后一步，而是在任何阶段，在进入下一阶段前一般都有一步或儿步的回溯。
在测试过程中的问题可能要求修改设计，用户可能会提出一些需要来修改需求说明书等。
软件开发过程覆盖了需求、设计、实现、确认以及维护等活动。
需求活动包括问题分析和需求分析。
需求分析生成功能规约。
设计活动一般包括概要设计和详细设计。
概要设计建立整个软件系统结构，包括子系统、模块以及相关层次的说明、每一模块的接口定义。
实现活动把设计结果转换为可执行的程序代码。
确认活动贯穿于整个开发过程，实现完成后的确认，保证最终产品满足用户的要求。
（注：
本资料素材和资料部分来自网络，仅供参考。
请预览后才下载，期待您的好评与关注！
）
升级会员 