Software Life Cycle
Problem Definition: To show system analysts and users to communicate and figure out "what the user needs a computer to solve the problem" and then asked about the "Targets and scope of the system," and confirmation submit a user review
Feasibility Study: on the one hand that the target system to be developed to clarify the language to describe it, on the other hand a feasibility study from the economic, technical, legal and other aspects
Needs analysis: determine the functional requirements and non-functional requirements of software systems; data requirements analysis software system; logic model export system; amended project development plan; if necessary, develop a prototype system
Development stage: Design -> realization -> Test
maintain:
- Corrective maintenance: after delivery of the software, due to complete at the time of development and testing, is not complete, there must be a hidden part of the error was brought to the operational phase, these hidden errors in a certain environment will be exposed.
- Adaptive maintenance: is to adapt to environmental change and modify the software activities.
- Improve maintenance: according to some constructive suggestions raised by users in the course of maintenance activities carried out.
- Preventive maintenance: in order to further improve the maintainability and reliability of software systems , and to lay the foundation for future improvements.
Unified Process (UP)
Kai early stage: Lifecycle Objectives
Essence stages: Lifecycle Framework
Construction Phase: Initial motor function
Transition phase: Product Release
CMM (Capability Maturity Model)
Initial: The software project management system deficiencies, lack of process definition, chaos
Repeatable: the establishment of a basic project management processes and practices to track project costs, schedule and features
Defined Level: All items are used to develop standard software according to the practical situation resulting process and maintenance software
Managed Level: collect detailed metrics for software process and product quality, understanding and control of the software process and products are metric
Optimizing: The process of quantification feedback and advanced new ideas, new technology to promote the continuous improvement process
CMMI (Capability Maturity Model Integration)
未完成级:表明过程域的一个或多个特定目标没有被满足
已执行级:过程通过转化可识别输入工作产品,产生可识别的输出工作产品,关注于过程域的特定目标的完成
已管理级:
过程作为已管理的过程制度化,针对单个过程的实例的能力
已定义级:
过程作为已定义的过程制度化,关注过程的组织级标准化和部署
量化管理级:
过程作为定量管理的过程制度化
优化级:
过程作为优化的过程制度化,表明过程得到很好的执行且持续得到改进
COCOMO
基本COCOMO模型:静态单变量模型,用于对整个软件系统进行估算
中级COCOMO模型:静态多变量模型,将软件系统模型分为系统和部件两个层次
详细COMO模型:将软件系统分为系统、子系统、模块三个层次,除包括中级模型所考虑的因素外,还考虑了在需求分析、软件设计等每一步的成本驱动属性的影响
COCOMOII
应用组装模型:在软件工程的前期阶段使用,这时用户界面的原型开发、对软件和系统交互的考虑、性能的评估以及技术成熟度的评价是最重要的
早期设计阶段模型:在需求已经稳定并且基本的软件体系结构已经建立时使用
体系结构阶段模型:在软件的构造过程中使用
Putnam估算模型:动态多变量,它是假设在软件开发的整个生存周期中工作量有特定的分布
ISO/IEC 9126(软件质量模型):
由3个层次组成:第一层是质量特性,第二层是质量子特性
特性含义:
其中各六个质量特性与二十七个质量子特性的关系如下表:
耦合
无直接耦合
(最低耦合):两个模块之间没有直接的关系,它们分别从属于不同模块的控制与调用,它们之间不传递任何信息。因此,模块间的耦合性最弱,模块独立性最高
数据耦合:两个模块之间有调用关系,传递的是简单的
数据值
标记耦合:两个模块之间传递的是数据结构,如果高级语言的数组名,记录名,文件名等这些名字即为标记,其实传递的是这个
数据结构的地址
内容耦合
(最高耦合):当一个模块直接使用另一个模块的内部数据,或通过非正常入口而转入另一个模块内部
控制耦合:模块间传递的信息不但有数据,还包括
控制信息
外部耦合:
模块间通过软件之外的环境联结(如I/O将模块耦合到特定的设备、格式、通信协议上)
公共耦合:
通过一个公共数据环境相互作用的那些模块间的耦合
内聚
功能内聚:完成一个
单一功能,各个部分协同工作,缺一不可(最高)
顺序内聚:处理元素相关,而且
必须顺序执行
通信内聚:所有处理元素集中在一个
数据结构的区域上
过程内聚:处理元素相关,而且
必须按特定的次序执行
瞬时内聚:所包含的任务
必须在同一时间间隔执行
逻辑内聚:完成
逻辑上相关的一组任务
偶然内聚:完成一组
没有关系或松散关系的任务(最低)
软件开发模型
瀑布模型:
给出了软件生存周期中制定开发计划、需求分析、软件设计、编码、测试和维护等阶段以及各阶段的固定顺序,上一阶段完成后才能进入到下一阶段,整个过程如同瀑布流水。该模型为软件的开发和维护提供了一种有效的管理模式,但在大量的实践中暴露出其缺点,其中最为突出的是缺乏灵活性,特别是无法解决软件需求不明确或不准确的问题。这些问题有可能造成开发出的软件并不是用户真正需要的,并且这一点只有在开发过程完成后才能发现。所以瀑布模型适用于需求明确,且很少发生较大变化的项目。
演化模型(快速原型模型):
允许在获取了一组基本需求后,通过快速分析构造出软件的一个初始可运行版本(称作原型),然后根据用户在适用原型的过程中提出的意见对原型进行改进,从而获得原型的新版本。这一过程重复进行,直到得到令用户满意的软件。该模型主要用于对软件需求缺乏准确认识的情况。
螺旋模型:
将瀑布模型和演化模型进行结合,在保持二者优点的同时,增加了风险分析,从而弥补了二者的不足。该模型沿着螺线旋转,并通过笛卡尔坐标的四个象限分别表示四个方面的活动:制定计划、风险分析、实施工程和客户评估。螺旋模型为项目管理人员及时调整管理决策提供了方便,进而可降低开发风险。
喷泉模型:
以面向对象的软件开发方法为基础,以用户需求为动力,以对象来驱动的模型。该模型主要用于描述面向对象的开发过程,体现了面向对象开发过程的迭代和无间隙特性。迭代指模型中的活动通常需要重复多次,相关功能在每次迭代中被加入新的系统。无间隙是指在各开发活动(如分析、设计、编码)之间没有明显边界。
软件开发方法
结构化方法:
面向
数据流、自顶向下、适合数据处理领域的问题、不适合大规模、复杂的项目、难以适应需求的变化
Jackson方法:
面向
数据结构、适合小规模项目、当输入数据结构与输出数据结构没有对应关系时,难以应用此方法
原型化方法:
适合需求不清、业务理论不确定、需求经常变化的情况
Booch方法:
面向
数据结构
冗余附加技术
屏蔽硬件错误的容错技术:
键程序和数据的冗余及调用;
检测、表决、切换、重构和复算的实现。
屏蔽软件错误的容错技术:
冗余备份程序的存储及调用;
实现错误检测和错误恢复的程序;
实现容错软件所需的固化程序。
软件风险
项目风险:项目风险威胁到项目计划,若发生项目风险,就有可能拖延项目的进度和增加项目的成本。项目复杂度、规模及结构不确定性也属于项目风险因素
技术风险:技术风险威胁到开发软件的交付时间。若发生技术风险,开发工作就可能变得很困难或根本不可能。规格说明的歧义性、技术的不确定性、技术陈旧以及前沿技术也是技术风险因素
商业风险:商业风险威胁到开发软件的生存能力
市场风险:开发了一个没有人真正需要的优良产品或系统
策略风险:开发的产品不再符合公司的整体商业策略
销售风险:开发了一个销售部们不知道如何去销售的产品
管理风险:由于重点的转移或人员的变动而失去了高级管理层的支持
预算风险:没有得到预算或人员的保证
Gantt
无法描述任务之间的依赖关系,也无法确定影响进度的关键任务
Pert和CPM
Pert无法描述任务之间的并行关系