系统分析与设计-homework1

  • 1.软件工程的定义
  • 答:比较认可的一种定义认为:软件工程是研究和应用如何以系统性的、规范化的、可定量的过程化方法去开发和维护软件,以及如何把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来。
  • 2.阅读经典名著“人月神话”等资料,解释 software crisis、COCOMO 模型。
  • 答:软件危机(Software Crisis) 是计算机软件在它的开发和维护过程中所遇到的一系列严重问题。概括地说,主要包含两方面的问题:如何开发软件,怎样满足对软件日益增长的需求;如何维护数量不断膨胀的已有软件。软件发展第二阶段的末期,由于计算机硬件技术的进步。一些复杂的、大型的软件开发项目提出来了,但软件开发技术的进步一直未能满足发展的要求。在软件开发中遇到的问题找不到解决的办法,使问题积累起来,形成了尖锐的矛盾,因而导致了软件危机。主要表现在以下几个方面: a.经费预算经常突破,完成时间一再拖延。 b.开发的软件不通满足用户要求。 c.开发的软件可维护性差。 d. 开发的软件可靠性差。 软件危机产生的原因是由于软件产品本身的特点以及开发软件的方式、方法、技术和人员引起的:     a.软件的规模越来越大,结构越来越复杂。     b.软件开发管理困难而复杂。     c.软件开发费用不断增加。     d.软件开发技术落后。     e.生产方式落后。     f.开发工具落后,生产率提高缓慢。要克服软件危机,就要认真分析软件危机的原因,探索用工程的方法进行软件生产的可能性,即用现代工程的概念、原理、技术和方法进行计算机软件的开发、管理、维护和更新。
  • 答:COCOMO,英文全称为constructive cost model,中文为构造性成本模型。它是一种精确、易于使用的,基于模型的成本估算方法,最早由勃姆 (Boehm) 于 1981 年提出。从本质上说是一种参数化的项目估算方法,参数建模是把项目的某些特征作为参数,通过建立一个数字模型预测项目成本(类似于居住面积作为参数计算的整体的住房成本)。
    COCOMO用3个不同层次的模型来反映不同程度的复杂性,他们分别为:
         
    基本模型 (Basic Model)。 是一个静态单变量模型,它用一个以已估算出来的源代码行数 (LOC) 为自变量的函数来计算软件开发工作量。
         
    中间模型 (Intermediate Model)。 则在用 LOC 为自变量的函数计算软件开发工作量的基础上,再用涉及产品、硬件、人员、项目等方面属性的影响因素来调整工作量的估算。
        
    详细模型 (Detailed Model) 包括中间 COCOMO 模型的所有特性,但用上述各种影响因素调整工作量估算时,还要考虑对软件工程过程中分析、设计等各步骤的影响。
        
    同时根据不同应用软件的不同应用领域,COCOMO模型划分为如下3种软件应用开发模式:
        
    组织模式(Organic Mode)。这种应用开发模式的主要特点是在一个熟悉稳定的环境种进行项目开发,该项目与最近开发的其他项目有很多相似点,项目相对较小,而且并不需要许多创新。
        
    嵌入式应用开发模式 (Embedded Mode)。在这种应用开发模式种,项目受到接口要求的限制。接口对整个应用的开发要求非常高,而且要求项目有很大的创新,例如开发一种全新的游戏。
       
    中间应用开发模式 (Semidetached Mode)。这时介于组织模式和嵌入式应用开发模式之间的类型。
  • 3.软件生命周期。
  • 答:软件生命周期(Software Life Cycle,SLC)是软件的产生直到报废或停止使用的生命周期。旧的解释是周期内有问题定义、可行性分析、总体描述、系统设计、编码、调试和测试、验收与运行、维护升级到废弃等阶段,这种按时间分程的思想方法是软件工程中的一种思想原则,即按部就班、逐步推进,每个阶段都要有定义、工作、审查、形成文档以供交流或备查,以提高软件的质量。随着新的面向对象的设计方法和技术的成熟,早期软件生命周期设计方法的指导意义正在逐步减少或需要调整。不过从另一种意义来说,面向对象本身也是一种软件生命周期,传统的软件生命周期的概念仍是所有软件工程师非常重要的知识基础和工作指导。软件生命周期的解释也应当调整。以上旧的解释与下文的生命周期模型是不相容的,只与瀑布型生命周期模型及其衍生模型(比如V模型,W模型)相符合,而与迭代为基本特征的生命周期模型是不符合的。新的情况应当是把迭代加入到阶段当中,如下:软件生命周期内有问题定义、可行性分析、总体描述、系统分析、编码、调试和测试、验收与运行、维护升级到废弃等阶段,也有将以上阶段的活动组合在内的迭代阶段,即迭代作为生命周期的阶段。
  • 4.按照 SWEBok 的 KA 划分,本课程关注哪些 KA 或 知识领域?
  • 答:软件需求、软件设计、软件建构、软件测试、软件维护与更新、软件构型管理、软件工程管理、软件开发过程、软件工程工具与方法、软件质量。
  • 5.解释 CMMI 的五个级别。例如:Level 1 - Initial:无序,自发生产模式。
  • 答:Level 1 - Initial:无序,自发生产模式。
        Level 2 - Managed:建立了基本的项目管理过程来跟踪费用、进度和功能特性。制定了必要的过程纪律,能重复早先类似应用项目取得的成功经验
        
    Level 3 - Defined:已将软件管理和工程两方面的过程文档化、标准化,并综合成该组织的标准软件过程。
        Level 4 - Quantitatively Managed:分析对软件过程和产品质量的详细度量数据,对软件过程和产品都有定量的理解与控制。
        Level 5 - Optimizing:过程的量化反馈和先进的新思想、新技术促使过程持续不断改进。
  • 6.用自己语言简述 SWEBok 或 CMMI (约200字)
  • 答:CMMI,即能力成熟度模型集成。它的目的是让软件企业可以更方便的管理改进软件工程过程,保证软件能够按时完成且不超过预算。其核心想法是,为了克服开发中的困难,我们要把精力放在建立有效的软件工程过程的基础结构,改进管理的实践和过程。能力成熟度模型集成提供了一个单一的集成化的、自动、可拓展的框架,消除了各个模型的不一致性,减少了模型之间的重复。主要关注点是成本效益、明确重点、过程集中和灵活性四个方面。
  • 阅读《现代软件工程》的 PSP: Personal Software Process 章节。 http://www.cnblogs.com/xinz/archive/2011/11/27/2265425.html
  • 按表格 PSP 2.1, 了解一个软件工程师在接到一个任务之后要做什么,需要哪些技能,解释你打算如何统计每项数据? (期末考核,每人按开发阶段提交这个表)
  • 答:
        一个工程师接到任务后需要:
            计划:
        估计这个任务需要多少时间
            开发
        分析需求
        生成设计文档
        设计复审(和同事审核设计文档)
        代码规范(为目前的开发制定合适的规范)
        具体设计
        具体编码
        代码复审
        测试(包括自我测试,修改代码,提交修改)
        记录用时
        测试报告
        计算工作量
        事后总结
        提出过程改进计划
        

        需要的技能:需求分析、做出规划与设计、交流沟通能力、协调能力、代码能力、总结能力
        数据:统计每一个阶段具体消耗的时间

阅读更多
想对作者说点什么?

博主推荐

换一批

没有更多推荐了,返回首页