当前位置: 代码迷 >> 综合
 解决方案列表
  • [综合] 需求分析主要用来做什么

    需求分析实际上是业务分析,也就是选择一种业务导向的线索将零散的需求串起来,形成一个体系完整、内容清晰的框架,以指导后续的设计、开发工作。 更具体地描述需求分析工作的任务:分解、提炼、消除矛盾。连成一句话就是: 需求分析就是先分解、再提炼,在这个过程中消除矛盾。

    52
    热度
  • [综合] 建模的要点与原则

    建模的要点 设计要考虑到计划之外的变化 设计要文档化 用可视化的模型表达架构 切忌“为了建模而建模” 建模的原则 选择创建什么模型对如何动手解决问题和如何形成解决方案有着深远的影响 每一种模型可以在不同的精度级别上表示 最好的模型是与现实相联系的 单个模型是不充分的,对每个重要的系统最好用一组几乎独...

    13
    热度
  • [综合] UML的优点

    首先UML是一种统一的、标准化的建模语言,它能为许许多多参与软件设计和开发的人提供一种公共“语言”,使他们能够基于共同的“模型”来理解业务、需求,理解软件和架构如何构造 其次UML是一种应用面很广泛的建模语言,它不仅可以用于软件系统建模,还可以用于业务流程、业务知识、数据库、嵌入式等多个领域;而且对...

    13
    热度
  • [综合] 两个用例之间可能存在的关系

    包含、扩展、泛化,而通常不应该有通信关系 包含关系:在UML中,用构造型<<include>>表示(箭头方向是从基用例到被包含用例),它是指基用例在它内部说明的某一个位置上显式地合并了另一个用例的行为 扩展关系:在UML中,扩展关系用构造型<<extend>...

    63
    热度
  • [综合] 业务流程为主线的分解结构

    业务流程为主线的分解结构: 这种结构是以业务流程为主线索的,也就是按“事”的角度进行分解。它对于联机事务处理系统、管理信息系统而言是非常适用的方法。 程序结构为主线索的分解结构: 适用于问题域不复杂,或者系统与问题域关联性不强的情况下,例如工具软件、面向设备的嵌入式系统等 基于场景的分解结构 对于决...

    101
    热度
  • [综合] 软件需求规格说明书编写

    常见的描述风格: 自然语言: 优点:易于编写、易于阅读,不用掌握特定的技能, 缺点:不够严谨,歧义性强,表述力差 图形化模型 优点:可视性、聚集性 缺点:要求编写和阅读人都能够正确地理解模型 形式化规格描述 优点:严谨、精确 缺点:编写和阅读人都会感觉很困难,易产生理解歧义 根据不同项目、软件开发团...

    68
    热度
  • [综合] 涉众

    客户、用户(客户的一部分)、需求分析员、开发人员、测试人员、文档编制人员、项目经理、法律人员、生产人员、市场营销、技术支持及其他与产品和客户打交道的人员

    20
    热度
  • [综合] .软件需求的定义

    1)用户为解决某个问题或达到某个目标而需具备的条件或能力。 2)系统或系统组件为符合合同、标准、规范或其他正式文档而必须满足的条件或必须具备的能力。 3)上述第一项或第二项中定义的条件或能力的文档表达。

    84
    热度
  • [综合] 软件需求工程分为需求开发和需求管理

    (1)需求开发:获取、分析、编写规约、确认 包括的活动: 1)确定产品将要面对的各类用户 2)从各类用户的代表处收集需求 3)了解用户的任务和目标,以及这些任务要实现的业务目标 4)分析从用户处得到的信息,将用户的任务目标与功能需求、功能性需求、业务规则、解决方案建议以及其他无关信息区分开来 5)将...

    47
    热度
  • [综合] 需求相关的常见风险

    1)用户参与不足:客户不想花大力气进行需求收集,开发人员也不重视用户的参与,有时客户代理方也不能完全理解用户的真正需求,导致不能发现项目需求中的缺陷。 2)用户需求扩展:开发过程中需求不断发展与增加,项目落后计划的进度或者超出预算 3)有歧义需求: 4)镀金问题 5)过于抽象的需求 6)忽略某类用户...

    52
    热度
  • [综合] 三种最经常使项目“遇到困难”的因素是

    n缺乏用户介入:占所有项目的13% n不完整的需求和规格说明:占所有项目的12% n不断改变的需求和规格说明:占所有项目的12%

    120
    热度
  • [综合] 三种项目最主要的“成功因素”

    n用户介入:占所有成功项目的16% n高层管理的支持:占所有成功项目的14% n需求陈述清晰:占所有成功项目的12%

    59
    热度
  • [综合] IEEE软件工程标准词汇表定义需求

    1.用户解决问题或达到目标所需的条件或能力。 2.系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。 一种反映上面(1)或(2)所描述的条件或能力的文档说明。

    88
    热度
  • [综合] 需求的层次

    *需求是多层次的,包括业务需求、用户需求、功能需求和非功能需求。 业务需求反映了组织机构或客户对系统、产品高层次的目标要求,位于需求链中的最顶层,在项目视图和范围文档中予以说明。 用户需求描述了用户使用产品必须要完成的任务,这在实例文档或方案脚本予以说明。 功能需求定义了开发人员必须实现的软件功能,...

    47
    热度
  • [综合] 需求路线图

    涉众需要—〉系统的特性—〉建立软件需求 软件的6个质量特征(非功能性需求):可靠性,可用性,有效性,可维护性,可移植性,约束。 有效性(Efficiency) 是在规定的条件下,软件性能水平与所使用资源量之间关系有关的一组属性。 可靠性(Reliability) 是与在规定的一段时间和条件下,软...

    85
    热度
  • [综合] 要软件生命周期模型

    瀑布模型 快速应用开发模型(RAD) 螺旋模型 RUP 迭代式模型

    53
    热度
  • [综合] 瀑布模型的优点

    客户很容易熟悉该模型。 以有序的方式解决复杂的问题,易于理解,目标简单—完成所需要的活动。 可以严格控制项目进程,使项目管理易于实施。 方便按阶段设置里程碑,便于项目跟踪。 定义了质量控制过程。运用该过程来确定系统的质量。

    66
    热度
  • [综合] 采用瀑布模型需要具备的项目特征

    p在系统开发前要对需求有完整、全面、清晰的了解。 p上述需求不存在隐含的不可克服的风险。 p需求变更不能过于频繁。 p不同涉众的需求互相兼容,不存在明显的冲突。 p开发团队掌握了解决需求问题的有效方法。 p开发期限允许分阶段地串行工作。

    31
    热度
  • [综合] RAD模型

    RAD模型的优点 p采用高效率的开发工具,从而减少了整个产品的开发周期。提高了生产率,降低了成本。 p用户能够持续地参与开发,提高了用户参与程度,从而使用户的满意度上升,保证了系统能够满足用户的需要。 p工作重点从文档转为构建,所见即所得。 RAD方法包含三个阶段:需求计划阶段,用户描述,构建阶段 ...

    95
    热度
  • [综合] RUP的优点

    p降低了在一个增量上的开支风险。如果开发人员重复某个迭代,那么损失只是这一个开发有误的迭代的花费。 p降低了产品无法按照既定进度进入市场的风险。通过在开发早期就确定风险,可以尽早来解决而不至于在开发后期匆匆忙忙。 p加快了整个开发工作的进度。因为开发人员清楚问题的焦点所在,他们的工作会更有效率。 由...

    81
    热度