美文网首页
系统分析与设计学习笔记1

系统分析与设计学习笔记1

作者: SevenAnon | 来源:发表于2018-03-11 20:19 被阅读0次

    软件工程的定义

    1. 将系统化、 规范化、 可度量的
      方法应用与软件的开发、 运行和维护的过程,
      即将工程化应用于软件中。
    2. 对(1)中所述方法
      的研究

    Software Crisis

    软件危机是指在软件开发及维护的过程中所遇到的一系列严重问题,这些问题皆可能导致软件产品的寿命缩短甚至夭折。软件危机的根源是软件的大量需求与软件生产力效率之间的矛盾和软件系统的复杂性与软件开发方法之间的矛盾。软件危机的原因主要是用户需求不明确、软件开发过程缺乏正确的理论指导、软件开发的规模越来越大且软件开发的复杂度越来越高。软件工程的表现形式有项目运行超出预算、项目运行超过时间、软件质量低落、软件通常不匹配需求和项目无法管理且代码难以维护。软件危机的解决途径主要是正确认识计算机软件的内涵、充分认识到软件开发是一种组织良好、管理严密、协同配合的工程活动、采用成熟的软件开发技术和方法、开发和使用适当的软件工具。

    COCOMO模型

    COCOMO模型是一种在软件项中估算工作量、成本以及时间表的模型。COCOMO模型由三个不断深入和详细的层次组成。第一层,“基本COCOMO”,适用对软件开发进行快速、早期地对重要的方面进行粗略的成本估计,但因其缺少不同的项目属性(“成本驱动者”)的因素,所以准确性有一定的局限性。“中级COCOMO”中考虑进了这些成本驱动者。“详细COCOMO”加入了对不同软件开发阶段影响的考量。

    软件生命周期

    又称为软件生存周期或系统开发生命周期,是软件的产生直到报废的生命周期,周期内有问题定义、可行性分析、总体描述、系统设计、编码、调试和测试、验收与运行、维护升级到废弃等阶段,每个阶段都要有定义、工作、审查、形成文档以供交流或备查,以提高软件的质量。随着新的面向对象的设计方法和技术的成熟,生命周期的每一个周期都有确定的任务,并产生一定规格的文档(资料),提交给下一个周期作为继续工作的依据。软件开发要求覆盖软件开发的全过程,即每一周期工作的开始只能也必须是建立在前一个周期结果“正确”前提上的延续;因此,每一周期都是按“活动 ── 结果 ── 审核 ── 再活动 ── 直至结果正确”循环往复进展的。软件生存周期从时间角度上把整个周期划分为若干个阶段。各阶段的任务彼此间尽可能相对独立,上一阶段的输出是下一阶段任务的输入。同一个阶段各项任务的性质尽可能相同,从而降低每个阶段任务的复杂性,简化不同阶段之间的联系,有利于软件开发过程的组织管理。各阶段的划分受软件规模、性质、种类、开发方法等因素的影响。

    SWEBok KA 及课程关注KA

    SWEBok的知识领域有软件需求、软件设计、软件建构、软件测试、软件维护与更新、软件构型管理、软件工程管理、软件开发过程、软件工程工具与方法、软件质量。本课程关注的知识领域有软件需求、软件设计、软件建构、软件测试、软件构型管理、软件开发工程、软件工程工具与方法、软件质量等。

    解释 CMMI 的五个级别。例如:Level 1 - Initial:无序,自发生产模式。

    1. 第一级-初始级:软件过程是无序的,有时甚至是混乱的,对过程几乎没有定义,成功取决于个人努力。管理是反应式的。
    2. 第二级-已管理:建立了基本的项目管理过程来跟踪费用、进度和功能特性。制定了必要的过程纪律,能重复早先类似应用项目取得的 成功经验。第二级共7个过程域:需求管理、项目规划、项目跟踪与控制、供应商协议管路、度量与分析、过程与产品质量保证、配置管理。
    3. 第三级-已定义:已将软件管理和工程两方面的过程文档化、标准化,并综合成该组织的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件,软件产品的生产在整个软件过程是可见的。第二级共14个过程域:需求开发、技术解决方案、产品集成、验证、确认、组织过程焦点、组织过程定义、组织培训、集成项目管理、风险管理、决策分析和解决、集成团队、集成组织环境、集成供应商管理。
    4. 第四级-已量化的管理:分析对软件过程和产品质量的详细度量数据,对软件过程和产品都有定量的理解与控制。管理有一个作出结论的客观依据,管理能够在定量的范围内预测性能。第四级共两个过程域:组织过程性能、量化项目管理。
    5. 第五级-优化中:过程的量化反馈和先进的新思想、新技术促使过程持续不断改进。第五级共两个过程域:组织创新与部署、原因分析与决策

    简述 SWEBok 或 CMMI

    CMMI是CMM模型的最新版本。早期的CMMI(CMMI-SE/SW/IPPD)1.02版本是应用于软件业项目管理方法,SEI在部分国家和地区开始推广和试用。随着应用的推广与模型本身的发展,演绎成为一种被广泛应用的综合性模型。
      自从1994年SEI正式发布软件CMM以来,相继又开发出了系统工程、软件采购、人力资源管理以及集成产品和过程开发方面的多个能力成熟度模型。虽然这些模型在许多组织都得到了良好的应用,但对于一些大型软[企业来说,可能会出现需要同时采用多种模型来改进自己多方面过程能力的情况。这时他们就会发现存在一些问题,其中主要问题体现在:
      1、不能集中其不同过程改进的能力以取得更大成绩;
      2、要进行一些重复的培训、评估和改进活动,因而增加了许多成本
      3、遇到不同模型中有一些对相同事物说法不一致,或活动不协调,甚至相抵触。
      于是,希望整合模型[需求产生了。1997 年,美国联邦航空管理局(FAA)开发了FAA-iCMMSM(联邦航空管理局的集成CMM),该模型集成了适用于系统工程的SE-CMM、软件获取的SA-CMM 和软件的SW-CMM 三个模型中的所有原则、概念和实践。该模型被认为是第一个集成化的模型。
      CMMI 与CMM 最大的不同点在于:CMMISM-SE/SW/IPPD/SS 1.1 版本有四个集成成分,即:系统工程(SE)和软件工程(SW)是基本的科目,对于有些组织还可以应用集成产品和过程开发方面(IPPD)的内容,如果涉及到供应商外包管理可以相应的应用SS(Supplier Sourcing)部分。
      CMMI 有两种表示方法,一种是大家很熟悉的,和软件CMM 一样的阶段式表现方法,另一种是连续式的表现方法。这两种表现方法的区别是:阶段式表现方法仍然把CMMI 中的若干个过程区域分成了5 个成熟度级别,帮助实施CMMI 的组织建议一条比较容易实现的过程改进发展道路。而连续式表现方法则通过将CMMI 中过程区域分为四大类:过程管理、项目管理、工程以及支持。对于每个大类中的过程区域,又进一步分为基本的和高级的。这样,在按照连续式表示方法实施CMMI的时候,一个组织可以把项目管理或者其他某类的实践一直做到最好,而其他方面的过程区域可以完全不必考虑。

    解释 PSP 各项指标及技能要求:

    PSP2.1

    首先是各自定位角色, 然后根据分得的工作涉及到的能力进行记录测试,团队内出一个全体可见的个人贡献与工作分析表,相互督促学习,确保数据客观真实

    相关文章

      网友评论

          本文标题:系统分析与设计学习笔记1

          本文链接:https://www.haomeiwen.com/subject/jmiwfftx.html