建设风景区网站的目的,灌南住房建设局网站,网页素材库,python做一个简单的网页软件工程概述
软件开发生命周期 软件定义时期#xff1a;包括可行性研究和详细需求分析过程#xff0c;任务是确定软件开发工程必须完成的总目标#xff0c;具体可分成问题定义、可行性研究、需求分析等。软件开发时期#xff1a;就是软件的设计与实现#xff0c;可分成… 软件工程概述
软件开发生命周期 软件定义时期包括可行性研究和详细需求分析过程任务是确定软件开发工程必须完成的总目标具体可分成问题定义、可行性研究、需求分析等。软件开发时期就是软件的设计与实现可分成概要设计、详细设计、编码、测试等。软件运行和维护就是把软件产品移交给用户使用。软件系统的文档可以分为用户文档和系统文档两类用户文档主要描述系统功能和使用方法并不关系这些功能是怎样实现的系统文档描述系统设计、实现和测试等各方面的内容。软件工程过程是指为获得软件产品包括以下4个方面活动 Pplan——软件规格说明。规定软件的功能及其运行时的限制。DDo——软件开发。开发出满足规格说明的软件。CCheck——软件确认。确认开发的软件能够满足用户的需求。AAction——软件演进。软件在运行过程中不断改进以满足客户新的需求。软件系统工具通常可以按软件过程活动将软件工具分为 软件开发工具需求分析工具、设计工具、编码与排错工具、测试工具等。软件维护工具版本控制工具、文档分析工具、开发信息库工具、逆向工程工具、再工程工具。软件管理和软件支持工具项目管理工具、配置管理工具、软件评价工具、软件开发工具的评价和选择。软件设计四个活动数据设计、架构体系结构设计、人机界面接口设计和过程设计。 能力成熟度模型 能力成熟度模型CMM 能力等级 特点 关键过程区域 初始级Initial 软件过程的特点是杂乱无章有时甚至很混乱几乎没有明确定义的步骤项目的成功完全依赖个人的努力和英雄式核心人物的作用。 可重复级Repeatable 建立了基本的项目管理过程和时间来跟踪项目费用、进度和功能特性有必要的过程准则来重复以前在同类项目中的成功。 软件配置管理、软件质量保证、软件子合同管理、软件项目跟踪与监督、软件项目策划、软件需求管理。 已定义级Defined 管理和工程两方面的软件过程已经文档化、标准化并综合成整个软件开发组织的标准软件过程。所有项目都采用根据实际情况修改后得到的标准软件过程来发和维护软件。 同行评审、组件协调、软件产品工程、集成软件管理、培训大纲、组织过程定义、组织过程集点。 已管理级Managed 制定了软件过程和产品质量的详细度量标准。对软件过程和产品质量有定量的理解和控制 软件质量管理和定量过程管理 优化级Optimized 加强了定量分析通过来自过程质量反馈和来自新观念、新技术的反馈使过程能不断持续地改进。 过程更改管理、技术改革管理和缺陷预防 能力成熟度模型集成CMMI
是若干过程模型的综合和改进不仅仅软件而是支持多个工程学科和领域的、系统的、一致的过程改进框架能适应现代工程的特点和需要能提高过程的质量和工作效率。
CMMI两种表示方法
阶段式模型类似于CMM它关注组织的成熟度五个成熟度模型如下 能力等级 特点 关键过程区域 初始级 过程不可预测且缺乏控制 已管理级 过程为项目服务 需求管理、项目计划、配置管理、项目监督与控制、供应商合同管理、度量和分析、过程和产品质量保证 已定义级 过程为组织服务 需求开发、技术解决方案、产品集成、验证、确认组织级过程焦点、组织级过程定义、组织级培训、集成项目管理、风险管理、集成化的团队、决策分析和解决方案、组织级集成环境 定量管理 过程已度量和控制 组织过程性能、定量项目管理 优化级 集中于过程改进和优化 组织级改革与实施、因果分析和解决方案 其中2-5级对应的过程域如下表所示 成熟度等级 过程域 已管理级 需求管理、项目计划、配置管理、项目监督与控制、供应商合同管理、度量和分析、过程和产品质量保证 已定义级 需求开发、技术解决方案、产品集成、验证、确认、组织级过程焦点、组织级过程定义、组织级培训、集成项目管理、风险管理、集成化的团队、决策分析和解决方案、组织级集成环境 定量管理 组织过程性能、定量项目管理 优化级 组织级改革与实施、因果分析和解决方案 连续式模型关注每个过程域的能力一个组织对不同的过程域可以达到不同的过程域能力等级。 软件过程模型 瀑布模型SDLC 概念瀑布模型是一个经典的生命周期模型一般将软件开发分为可行性分析计划、需求分析、软件设计概要设计、详细设计、编码含单元测试、测试、运行维护几个阶段。特点 从上一项开发活动接受该项活动的工作对象作为输入。利用这一输入实施该项活动应完成的工作内容。给出该项活动的工作成果作为输出给下一项开发活动。对该项活动的实施工作成果进行评审。若其工作成果得到确认则继续进行下一项开发活动否则返回前一项甚至更前项的活动。尽量减少多个阶段的反复。以相对来说较小的费用来开发软件。 螺旋模型 螺旋模型是一个演化软件过程模型将原型实现的迭代特征与线性顺序瀑布模型中控制的和系统化的方面结合起来。在螺旋模型中软件开发是一系列的增量发布。开发过程具有周期性重复的螺旋线状。四个象限分别标志每个周期所划分的四阶段制定计划、风险分析、实施工程和客户评估。螺旋模型强调了风险分析特别使用于庞大而复杂的、高风险的系统。 V模型 V模型从整体上看起来就是一个V字型的结构从左右两边组成。左边的下划线分别代表了需求分析、概要设计、详细设计、编码。右边的上划线代表了单元测试、集成测试、系统测试与验收测试。V模型的特点如下
单元测试的主要目的是针对编码过程中可能存在的各种错误。集成测试的主要目的是针对详细设计中可能存在的问题。系统测试主要是针对概要设计检查系统作为一个整体是否有效地得到运行。验收测试通常由业务专家或者用户进行以确认产品能真正符合用户业务上的需要。V模型用于需求明确和需求变更不频繁的情形。 原型化模型 原型化模型第一步就是创建一个快速原型能够满足项目干系人与未来的用户可以与原型进行交互再通过与相关干系人进行充分的讨论和分析最终弄清楚当前系统的需求进行了充分的了解之后再原型的基础上开发出用户满意的产品。原型法认为很难一下子全面准确地提出用户需求的情况下原型应当具备的特点如下。 实际可行具有最终系统的基本特征构造方便、快速、造价低。原型法的特点在于原型法对用户的需求是动态响应、逐步纳入的。 增量模型
增量模型首先开发核心模块功能而后与用户确认之后再开发次核心模块的功能即每次开发一部分功能并与用户需求确认最终完成项目开发优先级最高的服务最先交付。特点由于并不是从系统整体角度规划各个模块因此不利于模块划分。难点在于如何将客户需求划分成多个增量。与原型不同的是增量模型的每一次增量版本都可作为独立可操作的作品而原型的构造一般是为了演示。 喷泉模型
喷泉模型是一种以用户需求为动力以对象作为驱动的模型适合于面向对象的开发方法。使开发过程具有迭代性和无间隙性。
基于构件的开发模型CBSD
基于构件的开发模型CBSD利用预先包装的构件来构造应用系统。构件可以是组织内部开发的构件也可以是商品化成品软件构件。
特点是增强了复用性在系统开发过程中会构建一个构件库供其他系统复用因此可以提高可靠性节省时间和成本。 形式化方法模型
建立在严格数学基础上的一种软件开发方法主要活动是生成计算机软件形式化的数学规格说明。 敏捷模型 开发宣言个体和交互胜于过程和工具、可以工作的软件胜过面面俱到的文档、客户合作胜过合同谈判、响应变化胜过遵循计划。敏捷方法区别在于其他方面的两个特点 是“适应性”而非“预设性”是“面向人的”而非“面向过程的”。敏捷方法和核心思想 敏捷方向是适应型而非可预测型。拥抱变化适应变化。敏捷方法是以人为本而非以过程为本。发挥人的特性。迭代增量式的开发过程。以原型开发思想为基础采用法代增量式开发发行版本小型化。主要敏捷方法; 极限编程XP。基础和价值是交流、朴素、反馈和勇气即任何一个软件项目都可以从4个方面入手进行改善加强交流从简单做起寻求反馈勇于实事求是。 Xp是一种近螺旋式的开发方法它将复杂的开发过程分解为一个个相对简单的小周期通过积极的交流、反馈以及其他一系列的方法开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等并根据实际情况及时地调整开发过程。XP提倡测试先行为了将以后出现bug的几率降到最低。水晶系列方法。与XP方法一样都有以人为中心的理念但在实际上有所不同。其目的是发展一种体长“机动性的”方法包含具有共性的核心元素每个都含有独特的角色、过程模式、工作产品和实践。并列争球法Scrum。是一种迭代的增量化过程把每段时间如30天一次的迭代称为一个“冲刺”Sprint并按需求的优先级别来实现产品多个自组织和自治的小组并行地迭代实现产品。特性驱动开发方法FDD。是一个迭代的开发模型。认为有效的软件开发需要3个要素人、过程和技术。有5个核心过程开发整体对象模型、构造特征列表、计划特征开发、特征设计和特征构建。 统一过程模型RUP
RUP描述了如何有效地利用商业的、可靠的方法开发和部署软件是一种重量级过程。RUP类似一个在线的指导者它可以为所有方面和层次的程序开发提供指导方针、模板以及事例支持。RUP软件开发生命周期是一个二维的软件开发模型RUP中有9个核心工作流如下 业务建模理解代开发系统所在的机构及其商业运作确保所有参与人员对待开发系统所在的机构有共同的认识评估代开发系统对所在机构的影响。需求定义系统功能及用户界面使客户知道系统的功能使开发人员理解系统的需求为项目预算及计划提供基础。分析与设计把需求分析的结果转化为分析与设计模型。实现把设计模型转换为实现结果对开发的代码做单元测试将不同实现人员开发的模块集成为可执行系统。测试检查各子系统之间的交互、集成验证所有需求是否均被正确实现对发现的软件质量上的缺陷进行归档对软件质量提出改进建议。部署打包、分发、安装软件升级旧系统培训用户及销售人员并提供技术支持。配置与变更管理跟踪并维护系统开发过程中产生的所有制品的完整性和一致性。项目管理为软件开发项目提供计划、人员分配、执行、监控等方面的指导为风险管理提供框架。环节为软件开发机构提供软件开发环境即提供过程管理和工具的支持。RUP把软件开发生命周期划分为多个循环每个循环生成产品的一个新的版本每个循环依次由4各连续的阶段组成每个阶段完成确定的任务这4各阶段如下。 初始阶段定义最终产品视图和业务模型并确定系统范围。细化阶段设计及确定系统的体系结构制订工作计划及资源要求。构造阶段构造产品并继续演进需求、体系结构、计划直至产品提交。移交阶段把产品提交给用户使用。RUP中定义了如下一些核心概念理解这些概念对理解RUP很有帮助。 角色Who的问题。角色描述某个人或一个小组的行为与职责。RUP预先定义了很多角色如体系结构师、设计人员、实现人员、测试员和配置管理人员等并对每一个角色的工作和职责都做了详尽的说明。活动How的问题。活动是一个有明确目标的独立工作单元。制品What的问题制品是活动生成、创建或修改的一段信息。工作流When的问题。工作流描述了一个有意义的连续的活动序列每一个工作流产生一些有价值的产品并显示了角色之间的关系。RUP的特点 用例驱动需求分析、设计、实现和测试等活动都是用例驱动的。以体系结构为中心包括系统的总体组织和全局控制、通信协议等。是一个多维的结构会采用多个视图来描述。在典型的41视图模型中 分析人员和测试人员关心的是系统的行为会侧重于用例视图最终用户关心的是系统的功能会侧重于逻辑视图程序员关心的是系统的配置、装配等问题会侧重于实现视图系统集成人员关心的是系统的性能、可伸缩性、吞吐率等问题会侧重于进程视图系统工程师关心的是系统的发布、安装、拓扑结构等问题会侧重于部署视图。 迭代与增量。把整个项目开发分为多个迭代过程。在每次迭代中只考虑系统的一部分需求进行分析、设计、实现、测试和部署等过程每次迭代是在已完成部分的基础上进行的每次增加一些新的功能实现以此进行下去直到最后项目的完成。 逆向工程
软件复用是将已有软件的各种有关知识用于建立新的软件以缩减软件开发和维护的花费。软件复用是提高软件生产力和质量的一种重要技术。早期的软件复用主要是代码级复用被复用的知识专指程序后来扩大到包括领域知识、开发经验、设计决定、体系结构、需求、设计、代码和文档等一切有关方面。逆向工程软件的逆向工程是分析程序力图在比源代码更高抽象层次上建立程序的表示过程逆向工程是设计的恢复过程。逆向工程的四个级别 实现级包括程序的抽象语法树、符号表、过程的设计表示。结构级包括反映程序分量之间相互依赖关系的信息例如调用图、结构图、程序和数据结构。功能级包括反映程序段功能及程序段之间关系的信息例如数据和控制流模型。领域级包括反映程序分量或程序诸实体与应用领域概念之间对应关系的信息如R-R模型。
其中领域级抽象级别最高完备性最低实现级抽象级别最低完备性最高。
相关概念有重构、设计恢复、再工程和正向工程。 重构是指在同一抽象级别上转换系统描述形式。设计恢复是指借助工具从已有程序中抽象出有关数据的设计、总体结构设计和过程设计等方面的信息。再工程是指在逆向工程所获得信息的基础上修改或重构已有的系统产生系统的一个新版本。再工程是对现有系统的重新开发过程。包括逆向工程、新需求的考虑过程和正向工程三个步骤。它不仅能从已存在的程序中重新获得设计信息而且还能使用这些信息来重构现有系统以改进它的综合质量。在利用再工程重构现有系统的同时一般会增加新的需求包括增加新的功能和改善系统的性能。正向工程是指不仅从现有系统中恢复设计信息而且使用该信息去改变或重构现有系统以改善其整体质量。软件系统工具通常可以按照软件过程活动将软件工具分为软件开发工具、软件维护工具、软件管理和软件支持工具。 软件开发工具需求分析工具、设计工具、编码与排错工具软件维护工具版本控制工具、文档分析工具、开发信息库工具、逆向工程工具、再工程工具软件管理和软件支持工具项目管理工具、配置管理工具、软件评价工具、软件开发工具和评价和选择。 需求工程 软件需求
软件需求是指用户对系统在功能、行为、性能、设计约束等方面的期望。是指用户解决问题或达到目标所需的条件或能力是系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力以及反映这些条件或能力的文档说明。分为需求开发和需求管理两大过程如下图所示 业务需求反映企业或客户对系统高层次的目标要求通常来自项目投资人、客户、市场营销部门或产品策划部门。通过业务需求可以确定项目视图和范围。用户需求描述的是用户的具体目标或用户要求系统必须能完成的任务。即描述了用户能使用系统来做什么。通常采用用户访谈和问卷调查等方式对用户使用的场景进行整理从而建立用户需求。系统需求从系统的角度来说明软件的需求。包括功能需求、非功能需求和设计约束等。 功能需求也称为行为需求规定了开发人员必须在系统中实现的软件功能用户利用这些功能来完成任务满足业务需要。非功能需求指系统必须具备的属性或品质又可以细分为软件质量属性如可维护性、可靠性、效率等和其他非功能需求。设计约束也称为限制条件或补充规约通常是对系统的一些约束说明例如必须采用国有自主知识产权的数据库系统必须运行在UNIX操作系统之下等。软件需求开发是指从情况收集、分析和评价到编写文档、评审等一系列产生需求的活动分为获取情况、分析、制定需求规格说明和评审四个阶段。 需求获取 需求获取是一个确定和理解不同的项目关系人的需求和约束的过程。常见的需求获取法包括 用户访谈1对1-3有代表性的用户。其形式包括结构化和非结构化两种。问卷调查用户多无法一一访谈。采样从种群中系统地选出有代表性的样本集的过程。样本数量0.25*可信度因子/错误率²。情节串联版一系列图片通过这些图片来将故事。联合需求计划JRP通过联合各个关键用户代表、系统分析师、开发团队代表一起通过有组织的会议来讨论需求。需求记录技术任务卡片、场景说明、用户故事、Volere白卡。 需求分析
需求分析一个好的需求应该具有无二义性、完整性、一致性、可测试性、确定性、可跟踪行、正确性、必要性等特性因此需要分析人员把杂乱无章的用户要求和期望转化为用户需求这就是需求分析的工作。需求分析的任务 绘制系统上下文范围关系图创建用户界面原型分析需求的可行性确定需求的优先级为需求建立模型创建数据字典使用QFD质量功能部署结构化的需求分析 结构化特点自顶向下逐步分解面向数据三大模型功能模型数据流图、行为模型状态转换图、数据模型E-R图以及数据字典。 数据流图DFD 基本图像元素外部实体、加工、数据存储、数据流。 数据流由一组固定成分的数据组成表示数据的流向。在DFD中数据流的流向必须经过加工。加工描述了输入数据流到输出数据流之间的变换数据流图中常见的三种错误如图所示 加工3.1.2有输入但是没有输出称之为“黑洞”加工3.1.3有输出但没有输入称之为“奇迹”加工3.1.1中输入不足以生产输出我们称之为“灰洞”。数据存储用来存储数据。外部实体外部主体是指存在于软件系统之外的人员或组织它指出系统所需数据的发源地源和系统所产生的数据的归宿地宿。数据字典DD
数据流图描述了系统的分解但没有对图中各成分进行说明。数据字典就是为数据流图中的每个数据流、文件、加工以及组成数据流或文件的数据项做出说明。
数据字典有一下4类条目数据流、数据项、数据存储和基本加工。 符号 含义 举例及说明 被定义为 与 xab,表示x由a和b组成 […/…] 或 x[a/b],表示x由a或b组成 {……} 重复 x{a},表示x由0个或多个a组成 加工逻辑也称为“小说明”。常用的加工逻辑描述方法有结构化语言、判定表和片定树3种。 需求定义
需求定义软件需求规格说明书SRS是需求开发活动的产物编制该文档的目的是使项目干系人与开发团队对系统的初始规定有一个共同的理解使之成为整个开发工作的基础。SRS使软件开发过程中最重要的文档之一对于任何规模和性质的软件项目都不应该缺少。需求定义方法 严格定义也称为预先定义需求的严格定义建立在以下的基本假设之上所有需求都能够被预先定义。开发人员与用户之间能够准确而清晰地交流。采用图形或文字可以充分体现最终系统。原型方法迭代的循环型开发方式需要注意的问题并非所有的需求都能在系统开发前被准确地说明。项目干系人之间通常都存在交流上的困难原型提供了克服该困难的一个手段。特点需要实际的、可供用户参与的系统模型。有合适的系统开发环境。反复是完全需要和值得提倡的需求一旦确定就应遵从严格的方法。 需求验证
需求验证也称需求确认目的是与用户一起确认需求无误对需求规格说明书SAS进行评审和测试包括两个步骤 需求评审正式评审和非正式评审。需求测试设计概念测试用例。需求验证通过后要请用户签字确认作为验收标准之一此时这个需求规格说明书就是需求基线不可以再随意更新如果需要更改必须走需求变更流程。 需求管理
定义需求基线通过了评审的需求说明书就是需求基线下次如果需要变更需求就需要按照流程来一步步进行。需求的流程及状态如下图所示 需求变更和风险 主要关心需求变更过程种的需求风险管理带有风险的做法有无足够用户参与、忽略了用户分类、用户需求的不断增加、摸棱两可的需求、不必要的特性、过于精简的SRS、不准确的估算。
变更产生的原因外部环境的变化、需求和设计做的不够完整、新技术的出现、公司机构重组造成业务流程的变化。变更控制委员会CCB也成为配置控制委员会其任务是对建议的配置项变更做出评价、审批以及监督已经批准变更的实施。双向跟踪两个层次如下图所示 正向跟踪表示用户原始需求是否都实现了反向跟踪表示软件实现的是否都是用户要求的不多不少可以用原始需求和用例表格需求跟踪矩阵来表示若原始需求和用例有对应则在对应栏打对号若某行都没有对号表明原始需求未实现正向跟踪发现问题若某列都没有对号表明有多余功能用例软件实现了多余功能反向跟踪发现问题。
