|
|
知识路径： > 信息系统综合知识 > 信息系统 > 信息系统常用的开发方法 >
|
被考次数：3次
被考频率：中频率
总体答错率：67%
知识难度系数： 
|
由 软考在线 用户真实做题大数据统计生成
|
|
相关知识点：5个
|
|
|
|
|
信息系统的开发需要大量的人力、物力、财力和时间的投入。在系统开发时，为了更好地控制时间、质量、成本，并使用户满意，除了技术、管理等因素外，系统开发方法也起着很重要的作用。
|
|
|
|
系统常用的开发方法包括结构化方法、原型法、面向对象方法、敏捷开发等。
|
|
|
|
|
|
结构化方法是应用最为广泛的一种开发方法。应用结构化系统开发方法，把整个系统的开发过程分为若干阶段，然后依次进行，前一阶段是后一阶段的工作依据，按顺序完成。每个阶段和主要步骤都有明确详尽的文档编制要求，并对其进行有效控制。
|
|
|
|
优点：理论基础严密，它的指导思想是用户需求在系统建立之前就能被充分了解和理解。由此可见，结构化方法注重开发过程的整体性和全局性。
|
|
|
|
缺点：开发周期长；文档、设计说明烦琐，工作效率低；要求在开发之初全面认识系统的信息需求，充分预料各种可能发生的变化，但这并不十分现实；若用户参与系统开发的积极性没有充分调动，造成系统交接过程不平稳，系统运行与维护管理难度加大。
|
|
|
|
|
|
原型法的基本思想与结构化方法不同，原型法认为在很难一下子全面准确地提出用户需求的情况下，首先不要求一定要对系统做全面、详细的调查、分析，而是本着开发人员对用户需求的初步理解，先快速开发一个原型系统，然后通过反复修改来实现用户的最终系统需求。原型应当具备的特点如下：
|
|
|
|
|
|
|
|
|
|
原型法的特点在于原型法对用户的需求是动态响应、逐步纳入的，系统分析、设计与实现都是随着对一个工作模型的不断修改而同时完成的，相互之间并无明显界限，也没有明确分工。系统开发计划就是一个反复修改的过程。适于用户需求开始时定义不清、管理决策方法结构化程度不高的系统开发，开发方法更易被用户接受；但如果用户配合不好，盲目修改，就会拖延开发过程。
|
|
|
|
|
|
（1）抛弃型原型：此类原型在系统真正实现以后就放弃不用了。
|
|
|
|
（2）进化型原型：此类原型的构造从目标系统的一个或几个基本需求出发，通过修改和追加功能的过程逐渐丰富，演化成最终系统。
|
|
|
|
|
|
对象模型表示了静态的、结构化的系统数据性质，描述了系统的静态结构，它是从客观世界实体的对象关系角度来描述，表现了对象的相互关系。面向对象的信息系统开发，其关键点是能否建立一个全面、合理、统一的模型，它既能反映问题域，也能被计算机系统求解域所接受。
|
|
|
|
|
|
（1）客观事物是由对象组成的，对象是在原事物基础上抽象的结果。
|
|
|
|
（2）对象是由属性和操作组成的，其属性反映了对象的数据信息特征，而操作则用来定义改变对象属性状态的各种操作方式。
|
|
|
|
|
|
|
|
（5）对象具有封装的特性，可达到软件（程序和模块）复用的目的。
|
|
|
|
|
|
敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
|
|
|
|
|
|
（1）快速迭代：相对那种半年一次的大版本发布来说，小版本的需求、开发和测试更加简单快速。一些公司，一年仅发布2~3个版本，发布流程缓慢，它们仍采用瀑布开发模式，更严重的是对敏捷开发模式存在误解。
|
|
|
|
（2）让测试人员和开发者参与需求讨论：需求讨论以研讨组的形式展开最有效率。研讨组，需要包括测试人员和开发者，这样可以更加轻松定义可测试的需求，将需求分组并确定优先级。同时，该种方式也可以充分利用团队成员间的互补特性。如此确定的需求往往比开需求讨论大会的形式效率更高，大家更活跃，参与感更强。
|
|
|
|
（3）编写可测试的需求文档：开始就要用“用户故事”（User Story）的方法来编写需求文档。这种方法，可以让我们将注意力放在需求上，而不是解决方法和实施技术上。过早提及技术实施方案，会降低对需求的注意力。
|
|
|
|
（4）多沟通，尽量减少文档：任何项目中，沟通都是一个常见的问题。好的沟通，是敏捷开发的先决条件。在圈子里面混得越久，越会强调良好高效的沟通的重要性。团队要确保日常的交流，面对面沟通比邮件强得多。
|
|
|
|
（5）做好产品原型：建议使用草图和模型来阐明用户界面。并不是所有人都可以理解一份复杂的文档，但人人都会看图。
|
|
|
|
（6）及早考虑测试：及早地考虑测试在敏捷开发中很重要。传统的软件开发，测试用例很晚才开始写，这导致过晚发现需求中存在的问题，使得改进成本过高。较早地开始编写测试用例，当需求完成时，可以接受的测试用例也基本一块完成了。
|
|
|
|
在系统开发的实际工作中，往往根据需要将多种开发方法进行组合应用，最终完成系统开发的全部任务。
|
|
|
