软件系统与设计.docx

软件系统与设计.docx

《软件系统与设计.docx》由会员分享，可在线阅读，更多相关《软件系统与设计.docx（26页珍藏版）》请在冰豆网上搜索。

软件系统与设计

第1章软件工程基础知识

1.1软件工程知识体系

•软件配置管理（SoftwareConfigurationManagement）

•软件工程管理（SoftwareEngineeringManagement）•软件工程过程（SoftwareEngineeringProcess）•软件工程工具和方法（SoftwareEngineeringToolsandMethods）

•软件质量（SoftwareQuality）

1.2软件生存周期及软件开发模型

•1.2.1软件生存周期

•Boehm定义软件生存周期模型

•GB8566-1988定义软件生存周期模型

•GB/T8566-1995定义软件生存周期过程模型

•GB/T8566-2001定义软件生存周期过程模型

•UP定义软件生存周期模型

•1.2.2软件开发模型

•瀑布模型（waterfallmodel）

•快速原型模型（rapidprototypemodel）

•演化模型（evolutionarymodel）

•增量模型（incrementalmodel）

•螺旋模型（spiralmodel）

•喷泉模型（waterfountainmodel）

1.3软件质量模型及软件质量管理

•1.3.1软件质量模型

•软件产品内部质量、外部质量和使用质量

•质量特性、质量子特性和度量

•功能性：

适宜性、准确性、互用性、依从性、安全性

•可靠性：

成熟性、容错性、可恢复性

•可用性：

可理解性、易学性、可操作性

•效率：

时间特性、资源特性

•可维护性：

可分析性、可修改性、稳定性、可测试性

•可移植性：

适应性、易安装性、一致性、可替换性

•1.3.2软件质量管理

•质量需求分析

•质量计划

•质量保证

•质量控制

•质量改进

•软件质量管理体系

1.4软件配置管理

•1.4.1软件配置项及基线

计算机软件配置项（CSCI）•基线（baseline）

•功能基线（functionalbaseline）

•指派基线（allocatedbaseline）

•产品基线（productbaseline）

•1.4.2软件配置管理过程

•对象标识

•版本控制

•变化控制

•配置审计

•配置报告

1.5软件过程管理

•1.5.1软件能力成熟度模型（CMM）

•CMM5个等级：

初始级、可重复级、已定义级、已管理级、优化级

•CMM关键过程域（KPA）：

需求管理、软件项目计划、软件项目跟踪和监控、软件子合同管理、软件质量保证、软件配置管理、组织级过程焦点、组织级过程定义、培训大纲、集成软件管理、软件产品工程、组间协调、同行评审、定量过程管理、软件质量管理、缺陷预防、技术变更管理、过程变更管理

•1.5.2软件过程及软件能力成熟度评估

•第一步，建立评估组

•第二步，填写提问单

•第三步，响应分析•第四步，现场考察

•第五步，提出调査发现清单

•第六步，制作关键过程域（KPA）剖面图

•1.5.3软件过程改进

•第一步，比较“目标状态”及“目前状态”，找出所有差距

•第二步，确定改进目标

•第三步，制定改进计划

•第四步，执行改进计划

•第五步，总结本轮改进经验，开始下一轮改进

1.6小节

•软件工程学是研究如何有效地组织和管理软件开发工程学科。

•软件产品所要经历计划、分析、设计、编程、测试、维护直至被淘汰这样一个全过程被称为软件生存周期。

用不同方式将软件生命周期中所有开发活动组织起来，可以形成不同软件开发模型。

•软件质量就是软件及明确地和隐含地定义需求相一致程度。

软件质量管理是指软件开发机构为保证软件项目满足客户需求所要实施质量活动。

•软件配置管理是在软件整个生命期内管理变化一组活动，目标是使变化更正确且更容易被适应。

•软件过程是指人们用于开发和维护软件及其相关产品一系列活动，包括软件工程过程和软件管理过程。

软件过程管理目就是提升软件组织

提高软件开发能力。

第2章项目管理基础知识

2.1项目及项目管理

•2.1.1项目

•项目是在特定条件下、具有特定目标一次性任务，是在一定时间内、满足一系列特定目标多项相关工作总和。

1.项目临时性

•项目独特性

1.项目渐进性

2.1.2项目管理

•项目管理就是将各种知识、技能、工具和技术应用于项目之中，以达到项目要求。

•项目范围

•项目时间

•项目成本

•项目质量

2.2项目管理过程及过程组

•2.2.1过程及过程组

•过程就是一组为了完成一系列事先指定产品、服务或成果而需执行互相联系行动和活动。

软件项目管理过程可归纳为五个过程组。

•启动过程组（initiatingprocessgroup）

•规划过程组（planningprocessgroup）

实施过程组（executingprocessgroup）

监控过程组（monitoringandcontrollingprocessgroup）

收尾过程组（closingprocessgroup）

•2.2.2项目管理过程交互作用

项目管理过程并不是互不相干一次性事件

项目管理过程组之间是一种前后衔接、承前启后关系

项目管理过程组之间有时又是一种时间交错、空间并行关系项目管理过程组之间还是一种信息收集、存储、处理和传递关系某些过程组关联具有重复迭代性

规划过程组、执行过程组和监控过程组之间形成一种闭环关系过程组交互作用往往还会跨越项目阶段

项目阶段和过程之间有相互联系

•2.2.3项目管理过程裁剪

不同类型软件项目应选用不同项目管理过程

不同阶段软件项目应选用不同项目管理过程

不同软件项目管理过程会有不同具体过程

不同软件项目管理过程会有不同具体过程顺序

不同软件项目管理过程会有不同条件及约束

不同软件项目管理过程会有不同简化程度

不同软件项目管理过程需要不同集成程度

项目变更会使项目管理过程随之变化

2.3项目管理知识体系

•项目综合管理

•项目范围管理

•项目时间管理

•项目成本管理

•项目质量管理

•项目人力资源管理

•项目沟通管理

•项目风险管理

•项目采购管理

2.4小节

•项目管理就是将项目管理知识、技能、工具和技术应用于项目活动之中，可以将软件项目管理活动视做一系列相互联系过程。

•项目管理过程可归纳为5个过程组：

启动过程组、规划过程组、实施过程组、监控过程组及收尾过程组。

•项目管理包括9个知识领域：

项目综合管理、项目范围管理、项目时间管理、项目成本管理、项目质量管理、项目人力资源管理、项目沟通管理、项目风险管理及项目采购管理。

第3章软件开发技术

3.1软件开发平台

•3.1.1Microsoft.NET平台

•Microsoft.NETFramework：

.NETCLR（通用语言运行环境）；・NETBCL（基础类库）；ASP.NET；ADO.NETo

•MicrosoftVisualStudio・NET：

ADO.NET组件；XML数据组件；Windows

表单组件；ASP.NET应用服务；ASP.NETWeb表单；Web服务支持。

•3.1.2J2EE平台

•组件-容器：

搭建体系架构

•平台标准服务

•多层应用模型

3.1.3Microsoft.NET及J2EE异同

•类似平台基础构造

•相同三层/多层体系

1.不同移植、性能和扩展

•在Web支持方面比较

•第三方厂商支持

1.潜在市场

3.2中间件技术

•3.2.1中间件简介

•终端仿真/屏幕转换中间件

•数据访问中间件

•远程过程调用中间件

•消息中间件

•交易中间件

•对象中间件

•Web服务器中间件

•安全中间件

•3.2.2消息代理中间件

•构件化结构

•可恢复性、易于管理、灵活性

•具有数据转换设施。

•可靠高效通信

•多样管理能力

•丰富应用开发环境

•3.2.3面向数据库中间件

•ODBC

•JDBC

•数据库网关

3.3构件技术

•3.3.1构件库

•构件存储

•构件分类及检索机制

•构件库编目

•构件库管理和维护

•3.3.2构件模型

•3C模型

•刻面（Facet）模型

•青鸟模型

•3.3.3构件属性及特点

•构件是可独立配置单元，构件必须自包容。

•构件强调及环境和其他构件分离，因此构件实现是严格封装，外界没机会或没必要知道构件内部实现细节。

•构件可以在适当环境中被复合使用，因此构件需要提供清楚接口规范,可以及环境交互。

•构件没有个体特有属性，最多仅有特定构件一份副本。

•3.3.4构件及中间件

•中间件，本质上是对分布式应用抽象，中间件及系统架构实际上是从两种不同角度看待软件中间层次。

•中间件促进了构件化软件，基于中间件开发应用系统是构件化，中间

件提供了构件体系结构，极大提高了构件化软件开发效率和质量。

•构件化软件设计思想在中间件发展中起到了重要作用。

3.4小节

•Microsoft.NET平台和J2EE平台是目前最常用两大软件开发平台。

作为彼此竞争应用平台，Microsoft.NET平台和J2EE平台在目标和体系结构上极其相似，但在实现上又完全不同。

二者总关系是：

异中有同,同中有异。

•中间件是处于操作系统和应用程序之间软件。

中间件保持了平台透明性，抽象了典型应用模式。

应用软件开发者可以基于标准中间件进行再开发，而不必再考虑操作系统问题。

•构件是可复用软件成份，可被用来构造其他软件。

中间件促进了构件

化软件，应用系统在中间件提供环境中可以更好地集中于业务逻辑上,并以构件形式存在。

构件思想也反过来推动了中间件发展。

第4章软件项目规划

4.1项目策划

•从政策导向中寻找项目机会

1.从市场需求中寻找项目机会

•从技术发展中寻找项目机会

1.从特定事件中寻找项目机会

4.2项目可行性分析

4.2.1技术可行性分析

•项目必要性分析

•软件组织水平及能力分析

•项目技术来源分析

•及项目相关专利分析

•项目负责人及技术骨干资质分析

1.项目总体技术方案分析

•项目创新点分析

•项目技术风险分析

•项目技术成熟性分析

•4.2.2项目投资及效益分析

•项目投资预算分析

•项目投资来源分析•市场需求及产品销售额分析

•产品成本、利润及盈亏平衡点分析

•投资回收期、投资收益率分析

•社会效益分析

4.3项目论证、评估及立项

•4.3.1项目论证及评估基本概念

•项目论证是指对拟实施项目技术上先进性、成熟性、适用性，经济上合理性、盈利性，实施上可能性、风险性进行全面科学综合分析，为项目决策提供客观依据一种技术经济研究活动。

•项目评估指在项目可行性研究基础上，项目投资者或项目主管部门或其委托第三方权威机构根据国家颁布政策、法律、法规、标准和技术规范，对拟开发项目市场需求、技术先进性和成熟性、预期经济效益和社会效益等进行评价、分析和论证，进而判断其是否可行过程。

•项目论证及评估内容、程序和依据大同小异，只是侧重点稍有不同，有时不加区分或合并进行。

•4.3.2项目可行性报告真实性评估

•项目申请单位资质真实性评估

•项目申请单位财务真实性评估

•项目申请单位技术真实性评估

•其他事项真实性评估

•4.3.3项目可行性报告客观性评估

•技术创新点客观性评估

•技术先进性及成熟性客观性评估

•信息安全措施客观性评估

•采用标准、规范先进性、合理性评估

•项目风险及应对方案客观性评估

•其他事项客观性评估

•4.3.4评估报告

•项目概况

•评估目标

•评估依据

•评估内容

•评估机构及评估专家

•评估过程

•详细评估意见

•存在或遗漏重大问题

•潜在风险

•评估结论

•进一步建议

•4.3.5项目立项

项目立项决定应当由项目团队之外、适当级别、并为项目出资项目发起人或投资人作出，通常以项目立项决定（通知）书、项目批文、项目许可证书和项目任务书等形式发布。

4.4项目开发计划

•1.引言

•2.引用文件

•3.项目最终成果

•4.需求及约束

•5.系统开发总体计划

•6.项目开发详细计划

•7.进度表及活动网络图

•8.项目组织及资源

•9.培训

•10.项目估算

•11.风险管理

•12.支持条件

•13.注解

•14.附录

4.5小节

•软件项目规划任务主要包括项目策划、可行性研究、论证、评估、立

项及项目开发计划制订工作。

•项目策划，也称项目机会研究，其目是选择投资机会、鉴别投资方向。

•项目可行性分析目是确定以下问题：

项目有无必要？

能否完成？

是否

值得去做？

•项目论证及评估目是审查项目可行性研究可靠性、真实性和客观性，

为项目主管部门或投资机构立项决策提供科学依据。

•项目开发计划是项目规划阶段重要成果，编写软件项目开发计划时可依据《GB/T8567-2006计算机软件文档编制规范》中软件开发计划模版。

第5章系统分析方法学

5.1系统需求分析及软件需求

•系统需求：

系统总体功能和业务结构；硬件系统需求；软件系统需求;硬件系统和软件系统之间接口需求。

•软件需求：

软件能力需求；软件外部接口需求；软件内部接口需求；软件内部数据需求：

适应性需求；安全性需求；保密性和私密性需求;软件环境需求；计算机资源需求；软件质量需求；设计和实现约束；数据需求；操作需求；故障处理需求；算法需求；相关人员需求；相关培训需求；相关后勤需求；包装需求；其他需求。

5.2结构化分析

•结构化分析（SA）方法是一种面向数据流需求分析方法，基本思想是自顶向下逐层分解。

•数据流图（DFD）和数据字典（DD）是结构化分析最常用工具。

•数据流图用来描述数据流从输入到输出变换流程。

•数据字典是关于数据信息集合，也就是对数据流图中包含所有元素定义集合。

•数据流图和数据字典共同构成系统逻辑模型。

5.3原型化方法

•5.3.1原型化方法及结构化方法比较

•结构化方法假设：

所有需求都能被预先定义；修改定义不完备系统代价昂贵且实施困难；项目参加者之间能够清晰进行准确通信；静态描述或图形模型对应用系统反映是充分；结构化方法生命周期各阶段都是固有正确。

•原型化方法假设：

并非所有需求在系统开发以前都能准确地说明；有快速系统建造工具；项目参加者之间通常都存在通信上障碍；需要实际、可供用户参及系统模型；需求一旦确定，就可以遵从严格方法；大量反复是不可避免、必要，应该加以鼓励。

•5.3.2原型生命周期及其策略

•原型生命周期划分：

选择开发方法；识别基本需求；开发工作模型；模型验证；修正和改进；判定原型完成；差别细部说明；严格说明细部；判定原型效果；整理原型和提供文档。

•原型化策略：

建立数据模型；利用组合工程；剪裁和粘贴；用系统举例；字典驱动；文档自动化；小原型化队伍；交互式开发平台；陈述性规格说明；终端用户报表生成器；专业原型化人员；开发人员参加原型化。

5.4面向对象分析

•5.4.1面向对象方法学概述

•对象及封装

•类

•继承及多态性

•消息通信

•面向对象方法学优点

•5.4.2面向对象分析方法

•OMT方法简介

•建立对象模型

•建立动态模型

•建立功能模型

5.5小节

•系统分析涉及系统需求获取、分析、规格说明和确认。

系统需求可分为以下儿个方面：

系统总体功能和业务结构、硬件系统需求、软件系统需求、硬件系统和软件系统之间接口需求。

•常用系统分析方法包括结构化分析、原型化方法和面向对象分析。

第7章系统分析文档

7.1系统/子系统需求规格说明

•引言

•引用文件

•需求：

要求状态和方式；需求概述；系统能力需求；系统外部接口需求；系统内部接口需求；系统内部数据需求；适应性需求；安全性需求；保密性和私密性需求；操作需求；可使用性、可维护性、可移植性、可靠性和安全性需求；故障处理需求；系统环境需求；计算机资源需求；系统质量需求；设计和构造约束；相关人员需求；相关培训需求；相关后勤需求；包装需求；其他需求；需求优先次序和关键程

•合格性规定

•需求可追踪性

•非技术性需求

•尚未解决问题

•注解

•附录

7.2接口需求规格说明

•引言

1.引用文件

•需求

•合格性规定

1.需求可追踪性

•注解

•附录

7.3软件需求规格说明

•引言

•引用文件

•软件需求：

要求状态和方式；需求概述；需求规格；软件能力需求；

软件外部接口需求；软件内部接口需求；软件内部数据需求；适应性需求；安全性需求；保密性和私密性需求；软件环境需求；计算机资源需求；软件质量需求；设计和实现约束；数据需求；操作需求；故障处理需求；算法需求；相关人员需求；相关培训需求；相关后勤需求；包装需求；其他需求；需求优先次序和关键程度

•合格性规定

•需求可追踪性

•尚未解决问题

•注解

•附录

7.4小节

•根据《GB/T8567-2006计算机软件文档编制规范MSpecificationforcomputersoftwaredocumentation）,系统分利「文档主要包括系统/子系统需求规格说明（SSS）、接口需求规格说明（IRS）和软件需求规格说明（SRS）o

•系统/子系统需求规格说明（SSS）为一个系统或子系统指定需求以及保证每个需求得到确认所使用方法。

•接口需求规格说明（IRS）描述为实现一个或多个系统、子系统、硬件配置项（HWCI）、计算机软件配置项（CSCI）、用户

•软件需求规格说明（SRS）描述对计算机软件需求以及确保每个需求得到确认所使用方法。

第8章系统设计基础

8.1系统设计概述

•8.1.1系统级设计决策

•系统级设计决策，是指系统行为设计决策（忽略其内部实现，从用户角度出发，描述系统将怎样运转以满足需求）和其他对系统部件选择和设计产生影响决策。

•系统级设计决策内容：

有关系统接收输入和产生输出设计决策；对每个输入或条件进行响应系统行为设计决策；系统数据库/数据文件如何呈现给用户设计决策；为满足安全性、保密性和私密性需求所选用方法；硬件或硬软件系统设计和构造选择；为了响应需求而作出其他系统级设计决策。

•8.1.2系统架构设计

•总体设计

•系统部件设计

•动态交互设计

•接口设计

•&1.3运行设计

•系统初始化一说明本系统初始化过程。

•运行控制一一说明对系统施加不同外界运行控制时所引起各种不同运行组件组合、每种运行所经历内部组件和支持软件、每一种外界运行控制方式方法和操作步骤、每种运行组件组合将占用各种资源情况以及系统运行时安全控制。

•运行结束一一说明本系统运行结束过程。

•8.1.4系统出错处理设计

•出错信息一一包括出错信息表、故障处理技术等。

•补救措施一一说明故障出现后可能釆取补救措施。

•8.1.5系统维护设计

•检测点设计——说明在系统中专门安排用于系统检査及维护检测点。

•检测专用组件设计——说明在系统中专门安排用于系统检査及维护专用组件。

8.2软件设计概述

•8.2.1软件级设计决策

•软件级设计决策是指软件行为设计决策（忽略其内部实现，从用户角度出发，描述软件将怎样运转以满足需求）和其他影响组成该软件软件配置项选择及设计决策。

•软件级设计决策内容：

有关软件接收输入和产生输出设计决策；对每个输入或条件进行响应软件行为设计决策；有关数据库/数据文件如何呈现给用户设计决策；为满足安全性、保密性和私密性需求所选用方法；为响应需求而作出其他软件级设计决策。

•8.2.2软件架构设计

•程序结构设计

•全局数据结构设计

•软件配置项设计

•动态交互设计

•接口设计

•8.2.3软件详细设计

•软件配置项设计决策

•软件配置项设计中约束、限制或非常规特征

•软件配置项使用编程语言考虑

•软件配置项使用过程式命令选取

•软件配置项局部数据及软件配置项输入或输出数据设计

•软件配置项逻辑设计

8.3设计原则

•8.3.1组件化

•组件可分解性

•组件可组装性

•组件可理解性

•组件连续性

•组件保护性

•&3.2抽象

•抽象就是抽出事物本质特性而暂时忽略其细节，使得不同事物可以当作相同事务来处理。

•软件工程过程每一步都是对软件解法抽象层次一次精化。

•软件设计中抽象机制主要包括类、模板、过程抽象、数据抽象和控制抽象。

•&3.3内聚及耦合

•内聚是指一个组件内各个元素彼此结合紧密程度

•内聚种类（由低到高排列）：

偶然内聚；逻辑内聚；瞬时内聚；过程内聚；通信内聚；顺序内聚；功能内聚

•耦合是指一个软件结构内不同组件之间互连程度

•耦合种类（由高到低排列）：

内容耦合；公共耦合；外部耦合；控制耦合；标记耦合；数据耦合；非直接耦合

•组件高内聚、低耦合原则称为组件独立原则

•8.3.4封装及信息隐蔽

•第一，组件是其全部属性和全部服务紧密结合而形成一个不可分割整体。

•第二，组件是一个不透明黑盒子，表示组件状态数据和实现操作代码都被封装在黑盒子里面。

使用一个组件时候，只需知道它向外界提供接口形式，无须知道它数据结构细节和实现操作算法。

•8.3.5启发式规则

•深度、宽度、扇出及扇入

•作用域和控制域

•功能可预测性

8.4设计视图

•8.4.1架构视图（静态视图）

•架构描述语言（ADL）

•类图及对象图

•组件图

•协作责任卡（CRC）

•部署图

•实体-联系图（E-R图）•接口描述语言（IDL）

结构图

•Jackson结构图

•8.4.2行为视图（动态视图）

•活动图

•协作图

•顺序图

•数据流图

•决策表和决策图

•流程图和结构化流程图

•状态图

•形式化描述语言

•伪码

8.5小节

•系统设计是定义一个系统或软件架构、组件、接口和其它特征过程。

包括系统级设计决策、系统架构设计、运行设计、系统出错处理设计和系统维护设计。

•软件设计主要包括软件级设计决策、软件架构设计（概要设计）及详细设计。

软件架构设计主要任务是程序结构设计、全局数据结构设计、软件配置项设计、动态交互设计和接口设计。

软件详细设计是指每一个软件配置项具体设计。

•组件化、抽象、高内聚及低耦和、封装及信息隐蔽是软件设计基本原

则。

•软件设计视图通常可分为架构视图（静态视图）和行为视图（动态视图）两类。

第9章系统设计方法

9.1结构化设计

•9.1.1结构化设计方法概述

•分析系统总体需求，并将需求逐步分解为基本、具体功能。

•确定每个功能应当记录数据。

•列出系统中应提供各项基本功能，并分析各项基本功能之间耦合关系,根据高内聚、低耦和原则分配到系统中适当模块中。

•9.1.2系统结构图

•模块

•调用

•数据

•控制

•转接符号

•9.1.3系统结构图分类

•变换流及事务流

•变换型系统结构图

•事务型系统结构图

•混合型系统结构图

9.2面向数据结构设计

•9.2.1面向数据结构设计概述

•分析并建立适合系统数据结构；

•根据数据结构在相应层次建立程序结构