软件质量的三个层次

最新推荐文章于 2023-01-09 11:06:38 发布
最新推荐文章于 2023-01-09 11:06:38 发布
阅读量6.2k 收藏 3
点赞数 2
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/ShanShanlaichiji/article/details/51774990
版权

1.符合需求规格：符合开发者明确定义的目标，即产品是不是在做让它做的事情。目标是开发者定义的，并且是可以验证的。

2.符合用户显式需求：符合用户所明确说明的目标。目标是客户所定义的，符合目标即判断我们是不是在做我们需要做的事情。

3.符合用户实际需求：实际的需求包括用户明确说明的和隐含的需求。

姗姗欧妮
关注
  • 2
    点赞
  • 踩
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
网络通信设备
10-25
IT实际上有三个层次：第一层是硬件，主要指数据存储、处理和传输的主机和网络通信设备；第二层是指软件，包括可用来搜集、存储、检索、分析、应用、评估信息的各种软件，它包括我们通常所指的ERP(企业资源计划)、CRM(客户关系管理)、SCM(供应链管理)等商用管理软件，也包括用来加强流程管理的WF(工作流)管理软件、辅助分析的DW/DM(数据仓库和数据挖掘)软件等；第三层是指应用，指搜集、存储、检索、分析、应用、评估使用各种信息，包括应用ERP、CRM、SCM等软件直接辅助决策，也包括利用其它决策分析模型或借助DW/DM等技术手段来进一步提高分析的质量，辅助决策者作决策(强调一点，只是辅助而不是替代人决策)。有些人理解的IT把前二层合二为一，统指信息的存储、处理和传输，后者则为信息的应用；也有人把后二层合二为一，则划分为前硬后软。通常第三层还没有得到足够的重视，但事实上却是唯有当信息得到有效应用时IT的价值才能得到充分发挥，也才真正实现了信息化的目标。信息化本身不是目标，它只是在当前时代背景下一种实现目标比较好的一种手段。 卡尔的IT是指什么呢？在那篇文章里面他并没有明确提出，不过他提到信息技术的核心功能--数据存储、处理和传输。从他推理的逻辑来看，即从蒸汽机、铁路、电报电话、电力等基础设施建设推过来的，还用摩尔定律来佐证主机和光纤的发展。如果他就此打住，只从这一点出发，他的逻辑论证是非常严谨的，后面对《IT不再重要》发表不管支持与反对评论的人，在这一点上都是基本认同的(除了那些硬件和网络厂商外)，笔者也认同这一点。整个文章里他对物化的IT基础设施建设部分关注很多，基本没有关注应用层面。但后面他讲到大众化趋势时，又提到“信息技术极易复制”，则把IT又推到了商业软件，这里已经迈出了“危险”的一步。在2004年他出版同名书时开篇就定义了他研究、类比过来的IT，“我用的‘IT’是指通常意义上的，即所有被用来以数字形式存储、处理和传输信息的硬件和软件，特别强调的是，我只是指技术本身，我指的‘IT’并不包括技术中流动的信息和那些使用技术的人才技能”，所以他所指的IT是指前二层。如果就这此打住，可能还是不会有太大争议(这次又加上那些难受的软件厂商)。客观地分析软件本身的特征，的确不具备核心竞争力的四个判断标准中的三个即：稀缺性、不易复制性、不易替代性，卡尔本人也没有否认而且是在强调IT具备核心竞争力的第四个判断标准，即有价值。但他偏偏又把题目定成了“IT不再重要”，几欲把整个IT一棍子打死!
软件设计规范
03-11
范围：CPU上可以识别的代码和数据。全部的代码总和。 要求：从定义开始的设计。完整性，彻底地定义从无开始的整个设计。这是因为软件之软，也是因为硬件平台的多样性和特殊性。 完整把握，从头设计是第一原则。因为软件世界自己并不能统一，还有继续分化的趋势。没有根本一致的基础可能是软件的本性。退回到一无所有是处理软件问题的根本。 在这样的视野下，操作系统只是一个部分，一个模块，不同的操作系统任你选择；语言的选择是运行环境的选择（每种语言有每种语言的运行时布局）；所谓框架只是“类库＋运行环境”的一种构造。 没有对其负载能力、操作强度进行评估前，这些东西（操作系统、语言、框架）还都不能纳入设计规范。 性能：运行过程的收敛（长时间运行的均态）。操作强度设计（串行处理速度），负载能力设计（并发处理的量）。可靠性设计。 软件问题的3个方面： 1、硬件，软件的操作对象和运行软件的数字系统（CPU系统和数字加速硬件） 2、交互操作（界面），专业界面设计 3、软件调度性能，实时的自动化过程（设备控制和自动测量）和用户交互过程（请求服务过程和干预过程；本地交互和远程交互），程控和网络访问的调度（服务器）。 软件项目的3个部分：（把3个阶段由纵向横过来，进行统筹） 分解文档，集成平台，可维护性要求。 软件设计必须有自说明特性。不能对文档产生依赖性。软件代码中合适的地方，需要对文档进行恰如其分说明。原则是，每段代码，每处需要理解的地方，如果和总体架构相关，就要有说明。 软件领域需要简化。需要还原软件本来的面目。EDA有泛滥的趋势，软件的各个方面都需要简化。软件形态、需求分析、文档说明、开发工具等。 需求分析过分强调适应生命周期的变化和没有需求分析是一样的。不切实际的面向未来的需求架构的直接结果是软件的复杂和错误百出。 软件只有一个，而观察的视角很多。要采用最适合的观察视角，让软件一目了然。 软件的生成过程和观察过程是两个不同的观念。生成过程又可以区分为：研究过程和工程过程。研究过程可以通过结果，研究报告反映；工程过程则必须采用过程刻画。 软件规范使用的语言一定要有普遍语义，但描述本身具有特殊性；不能强求它的全球唯一。一定要雄视全体，才能选择正确的立足点，这就要求对目前的软件技术有一个了解；要考虑纳入新的发展，那么规范应该分层，把一般的和具体易变的成分分开；要有具体的指导意义，越具体指导意义越大，但通用性则越小。 所谓架构，可能是十分具体应用的代表；不同类别的应用必然有不同的架构。软件架构本身是“应用架构”。因此，不能规范具体的架构。到是可以做：应用架构规范的规范。 逻辑架构的特殊性。可以判断，任何一款实用的软件采取的软件逻辑抽象都是别样的，特例的逻辑。否则，软件不可能那么轻快实用。软件逻辑，鬼魅也。而需求分析，必须是现实实用的，而不是同构/仿真的－这似乎是反对象分析的。因为这里强调的是和软件的交互界面，这个界面远远没有反映现实世界的结构。须知，软件强调的是数据处理，是输入输出。否则，就不能达到最简化。 可能现实世界的结构映射，最适合的方式是数据库 － 采用纯数据结构进行映射。除此之外，能有更合适的技术吗？ 面向对象建模是吗？那么对象又如何与现实世界的对象绑定在一起呢？ 这再次表明，在软件技术和需求分析之间有鸿沟。软件技术作为特殊的技术，有它的有限性。也反映了，包含软件应用在内的现实架构已经固定。 如果软件是数据处理，是输入输出，那么软件结构也就可以确定了！ 可视化、用户操作界面解开了另外的软件世界，因为可视化可以代表用户更抽象的逻辑。用户希望操作可视对象，象操作现实对象一样。软件从模拟现实对象的过程中继承了其结构。 工业控制也开启了新的软件世界，因为软件要从分离的输入建立“综合感知”，感知到设备状态，然后做出响应。 软件有其固有的物理属性，也就是计算的量。算法领域，无论算法的论证多么曲折，求得的结果，物化为软件，总是“早已熟知”的软件。这一区分，是定义软件规范的基石。 算法构造领域是和软件完全不同的领域，算法不是软件。算法类似数学系统。也一如数学系统那样多样。 软件构造。算法总要转化为软件，这就是软件构造问题。寻址系统，数组。软件把自己的生成作为问题，给算法开辟了新的领域。软件生成，是一个“构造－编译”问题。手工构造，自动编译。语言的发展，是一个软件生成的历史。所谓统一建模，所谓设计模式，其实都是软件生成的问题。 需求分析。需求分析本质上是独立的。所谓OOA，面向对象的建模，把程序构造概念上升到需求分析领域可能是不对的。一个先验的，复杂的难于掌握的限制，只会让人对需求分析望而却步；即使勉强掌握，难求对需求分析的创造性发展。需求分析应该专注于需求分析本身，独立发展，一切为了准确、快捷的分析。 需求分析层次高一些，抽象一些，自由一些，这样可以充分表达需求的本质。反而可以促进更高级别的程序自动生成。 软件生成的历史。软件生成是为了解决人机沟通，让“计算机语言”更接近普通人的思维逻辑。把这种“高级计算机语言”翻译成可以执行的代码，就是软件生成（代码生成）的任务。而软件编制是专业人员的事情，因此语言问题的本质其实不那么重要。须知，经过培训，莫尔司码的电报发报可以比说话的语速还快！因此，计算机语言的前途迷茫；实际上也确实迷茫，历史上语言的层出不穷本身就说明了问题，至今仍然如此。在当今，必须建立这样的观点：语言是因人而异的；面对一个语言的时候，要清醒，首先明确“这是为谁设计的语言”；也就是说，需求分析之前的需求是要明确，让什么人来设计软件，然后为他们选择合适的语言。软件生成除了代码生成，还包括另外一个意思：软件构造。这在前面已经论述过了。只是，这里的软件构造机制已经在语言中奠定了。手工参与的软件构造只是语言给出的构造机制的应用。手工的软件构造就是语言构造机制的复制，产生大量的代码，应付实际问题的量。 立体构造。这里还有一个立体问题，实际问题的构造可能产生立体构造，如同建筑，基本的构件组装出复杂的立体结构。这里是建筑设计师的功劳。可能目前我们在语言层面上混淆不清的关键也在这里，没有区分语言和立体构造的责任。一个趋势是语言本身总是试图包揽建筑师的责任。把立体构造独立出来，带来的问题是：这个构造本身必须能够证明自己是正确的。1）能产生软件2）构造逻辑上正确，确实能解决应用问题。构造本身有一个属性，它有通用性。根本原理是通用的；总体构造本身具有一般性，也就是抽象性、实际问题无关性；局部构件具有通用性。也就是说，这里存在容器和容量的区别，构造是容器，实际问题是装在容器中的量。一个好的容器要能顶住容量的压力；一个好的建筑架构要能满足负载和抗振性要求。而架构本身的承受能力是客观的，只与架构本身有关。这也就是说，架构本身自我构造的，因此也就是科学。可能软件构造本身是澄清问题的工作，明确“容量”的特点，为软件构造的选择提供准确的依据，杀鸡不要用牛刀。实际问题的“容量”很容易测量，因为它反映为应用的规模，流程的流量。（架构是什么？架构是否存在？如果我们所说非虚，那么如何为架构下一个定义－一定是一个由具体业务流量和模式支撑的架构） 软件（算法）的构造。一个是数据的复杂性（内在互相关系），一个是计算方法（步骤和缓冲）。从宏观角度，数据关系是更根本的东西。目前的高级语言，变量和流程（顺序、分支－步骤；循环－缓冲和迭代）研究的多，而数据复杂性构造不足。 同构现象。CPU指令集合可以说是硬件直接实现的软件。软件帝国从这里提取软件精神，并升华它。从硬件的角度，从寄存器和指令执行流程，体现出的是变量和迭代（顺序更迭，循环往复）。（迭代流程）基于固定寻址的变量，经过寻址接口，可以处理任意数据，从而把迭代流程变成了一般流程。CPU的基本过程，产生了指令和数据，指令天生具有子程序的基因（一般流程），数据天生具有数据结构（寻址能力）的基因。高级的构造一般也是这种结构的类似：设计一套类似CPU的机制，支撑程序和数据；独特的“寻址机制”和“CPU处理能力”是实现构造的核心机制；迭代是所有这种机制的动力学和构造方式。而数据化是“寻址机制”的基础。抽象是数据化的工厂，也因此必须研究抽象技术。 抽象技术。所谓抽象，就是具体化，是范围的界定和比对（两种具体化对象之间的比对）。如果范围界定的完整，那么比对建立的联系就是普遍联系，普遍联系也就是所谓抽象原则。 评价标准。软件架构需要评测。这种评测是“在商言商”似的评测。评测的基础是软件架构的具体化。当掌握了架构的构造方法，每种架构本身也就具体化，是一种具体的架构。一种具体化的架构，就可以识别；可以识别则可以客观评测。可以按照立体架构的“压力”、“流量”等概念进行评测。 需求的把握－需求的变化。我们希望永恒不变的需求，核心需求和需求方式（表现和满足步骤）；而事实上需求总在演化。软件必须无条件、最大限度地方便需求的表达和需求的满足。软件可能永远只是皮肤，需求源于现实核心深处，软件是一件衣服。这种观点下，软件是没有中心的一种架构。软件架构和需求之间联系的定量评测。 软件和算法的分开 软件的构造作为软件的通用属性 需求的独立 推论：算法是应用的算法。比如数学公式的计算、图形图象的处理、频谱分析、词法和语法分析。因此算法不是通用的软件算法。也因此软件构造是软件规范的一部分，因为它是通用的软件构造技术。 计算技术和应用之间有明显的区别，是两种不同的成分。软件规范是纯粹的，只关心计算技术。而不关心应用建模。计算方法本身早已经被发现了（也就是怎么自动计算，或者说什么是可计算的），剩下的问题只是应用问题。把应用问题的解决纳入软件计算模式。自动计算技术在汇编指令集合那里得到了说明。所谓软件设计是把这种计算方式发扬广大。 所谓算法，就是明确问题，然后发现用自动计算的方式解决问题。从这个意义上说，软件是应用问题导向的。那么，也就是要以问题为中心谈论软件。不同类型的问题需要的解决方式有独特的强调。这也就反映为所谓不同的软件技术。所以，区分软件计算技术和应用问题的成分，是软件规范需要首先识别的东西。 解决问题。本质上是把问题装到变量里面的过程，是放大CPU寄存器的过程。表示层：（把局面、环境；起点和终点需要定义在一个世界里）装进去，组织起来。计算层（展开层）：基于表示，定义问题解决步骤（定义运动和过程）。 需求分析。问题描述采用的方法可能应该和软件算法完全分开。否则不能发现问题描述的创造性方法，不能表达问题本质。阐述问题，写文章我们有某篇布局之法；哲学研究我们有严谨的逻辑方法。需求分析，我们一定可以创造自己的方法。这是什么方法？满足使用要求，满足使用流程。离散/隔离各个需求。事实上，面向外部的分析理解和面向内部的分析理解之间有鸿沟。因为这是两个不同的世界。在两个相差悬殊的世界之间，搭建的构造也必然多种多样，以奇为平常。那么，建立联系的媒介少的可怜。可能问题本身也正在于这种联系的分析和设计。 软件的量，是静态的。强调这部分就忽略了活跃的、奇异的、动态的部分。软件的出现不仅仅是被动地适应显示需求，同时也改变了现实需求本身。这种和现实需求融合在一起形成的状态，正是软件活跃的部分。在以前，仅仅以“应用软件”指称是不够的。（操作系统、编译软件、应用软件） 在范畴上，分为三个层次，或说3个范畴域： 1、 活跃的、黏性的动态层次。应用层。和现实之间的界面，是设备逻辑。需求简化、解决方案的奇异性；应用算法的专业性。这是软件形象最活跃的部分。 这里用的是抽象（业务流程）和具体（设备能力）统一的思维方法，构造逻辑的软件过程同时又是可以用具体进行描述的；动态的、物理的分析手段（物理的量）。 业务流程的设计几乎就是艺术设计。 2、 中间层。程序构造层。语言、编译技术、数据结构、设计方法（过程、数据、对象）等可以形式化的计算机科学的任务。对程序能力进行抽象，设计程序自动化生成的一套系统：语言、计算系统、编译系统。这是在静态和活跃部分之间的层次。这里的观念：设计方法、主程序、程序过程（和应用层的过程不是一一对应的）。 3、 静态层。软件的量，度量层。所有程序构造过程的差别消失了。这是软件的静态观点。 每层都有对软件的自己的理念，概念、过程和模型。两个层的对比，则凸显出不可调和的差别。也是所有关于软件的不成熟的印象、抽象产生的地方。 在应用层，抽象的、逻辑过程强一些。想象的部分占据主要的部分。需要对现实的业务，基于设备的具体能力，进行构造。 3个范畴定义了“软件”和“程序”的分别。第1层和第3层论述的是“软件”，而第2层论述的是“程序”。 软件和程序的研究方法不同。程序研究方法是完备的，而软件不完备。 程序开发应当体现软件特性。1）是逻辑的过程，总体的过程和子过程的观察和校验程序。2）软件的量层次上，软件的规模、运行强度和稳定性指标的自测试程序。 第二阶段 一定要有一个标准。软件如衣服，软件的交付文档应当显示出衣服是如何编织起来的。（相对于需求，软件是衣服，非核心；相对于硬件，软件是衣服，包裹） 要有一个理论说明。 架构也是衣服的一个部件，类似衣服的连接方式，模块集合的重心比对。 衣服是一个没有核心的结构。软件也一样要显示出这个特性。 无论如何，我们需要有观察软件的眼光，无论一套软件依据什么样的理论产生。 什么是软件？描述是软件的存在形式（文本格式）。软件一定是可执行的（这是软件的严肃性，精确、定量）。软件是异化的，一般异化为具体、特例（对抽象力最好的归结方式）（没有完美满足需求的软件，相对于需求，软件只能满足固定的需求，而不能满足需求的变化，即一款软件总是具体的；由一般产生出具体的思考方法，也就是构造的方法；或着是磁力打造，一个好的理论一定对现实素材有吸引力，向磁铁一般；这也是在矛盾中建造现实的方法，只要是具体的就肯定是可以分析出潜在矛盾、不完美的，问题不仅仅是分析、认识现实，还要能够构造现实；不存在完美的现实，只存在完美的理论 科学研究的方法是简化。工程的方法是‘相似’，复制发现事物时的状态，那么事物的表现就会复现。 在具体化这里，软件和硬件工作的方法在结果上实现了一致。只是方向不同，软件是从一般进行到具体；硬件一开始就是从具体出发，层层构造，搭建系统。硬件的设计明显具有以工艺、器件为核心的特征。配合器件的特新，进行外围设计。在硬件领域，是‘具体’为上；在软件领域，是‘具体’为下。） 对具体性的解释：组成所有物资的电子、质子、中子是圆的、相同的，但是这些相同的东西组成的原子则有几百种不同。每次量的规模的添加，都导致特殊性的添加。对于软件来说，也是如此。如下的概念是母庸质疑的，软件如同大山，沟壑鲜明。（这种巨大的特殊性，一定是和巨大的需求特殊性相应的）。 “软件以文本形式存在；软件在执行着；软件以个例的形式存在”，归结为在一起就是“软件是具体的”。 低一级别的定义：软件与数据和逻辑相关（数据和逻辑是软件的基本语义）。软件与过程相关（积分（存储，数据的数据化）和步骤（逻辑）；过程是步骤的遍历，是数据的消长变化）。 执行的异化。区分独立执行和整体执行的概念。独立执行的代码称为模块，否则只是‘片段’。独立性和数据完整性相关，数据越庞大那么不独立的代码片段越多，模块就越大。模块独立性具有比和整体执行所要求的更大的自由度，也就是说整体只是使用了模块一部分的执行能力。模块独立执行获得的自由度是应该能够度量；模块的执行设计应该为了获取更大的自由度；自由度是模块可执行性质量的评定指标。对于整体执行的设计来说，自由度设计可能是设计过程的主导方法，它和全面、完整的需求理解相关，也和需求变化相关；因此自由度设计也是需求定位的设计。 软件的量，也就是软件的能力。这是理解软件解决问题的方式的基础。比如逻辑能力、计算能力、存储能力、图象能力等。 软件是运行的，软件是自我构造的，软件的全体的各个环节都有自己的量。编译、操作系统、文件管理等各环节都是不同分工的软件实现的。 需要构造在功能层次上的互相配合，解释这种完整性。显然每个部分都具有独立的完整性；完整性和完整性的配合构成一个总体的系统。因此未必要求系统的完整性、长期性、稳定性。反过来，系统满足需求的快速性、快速变化适应性、和现实一起变化、消长的特性、瞬态响应特性可能更接近系统的本质。 这好比太极拳，要在一个完满的氛围里运动。 软件能力是比代码高一个级别的抽象。又是构成软件内涵的基础语义。 ‘设备能力’的概念更基础，可以统一所有其它能力；又可以作为以硬件为中心的观念的基础。 能力的获得在于‘二分’。在于互相支撑的界面，支撑在一起的双方互为能力。 1．所谓需求分析，我们总是在创造一套新的方法和语言。而最有效的需求分析是自然语言分析。借助人们心目中的全部理解所用到的描述形式。也就是进入到实际存在的需求中去理解需求，分析需求。 因为领域、术语、行业表述习惯的原因，这个阶段千差万别。 2．其次是电脑的使用方式－电脑技术（外设、通信和电脑本身的硬件形态），尝试去设计合适的使用方式和硬件解决方案。 这里有使用环境、专业技术、成本、时间，以及个人习惯等原因，同样是一个精彩的过程。对领域工作方式的熟悉、外设相关的专业技术背景、折中技术决定了这是一个经验至上的活动。这就是电脑使用方式的确定。 3．进一步，确定使用者角色。使用者和使用地点关联。使用地点也就是前面电脑使用方式的一部分。 这是一个沟通过程，也是对有了电脑辅助参与，相关领域习惯改革的问题。 4．然后，进入二元分析阶段：使用者管角度、客观功能角度，分析功能，并完成二者之间的映射。 这个阶段，功能被量化。职能量化。职能和功能之间会有模糊，有授权的转移。这个阶段就是充分考虑这些问题。 5．然后，进入传统的需求分析阶段。 计算架构和功能描述的规格分析。使用者界面规划（详细、规格级别）。 界面规划、功能、架构三者之间组成互动的具体化过程。 最后会产生系统级别的文档。运行实体、接口；系统运行态、实体接口的输入输出规格。 6.然后，实体级别的程序构造阶段。 算法构造和程序构造。主要是从资源占用的角度确定宏观的算法。在这个阶段，是程序文档化阶段。文档这个属于是这个阶段的工具。 最后会产生严格的程序模块的文档。所有这些文档组合起来，可以构成运行流程。这些文档化的程序就是逻辑化的程序本身。 7.最后，编码阶段 用一种具体的语言，按照模块文档的接口、资源、算法要求，编制代码。
东大22春《软件工程与UML建模》在线平时作业3-00001
04-01
1.螺旋模型最初是从（ ）开始第一个螺旋2.关于技术可行性的说法错误的是（ ）3.多个软件工程师合作开发一个项目，各开发者之间需要两两相互通信。假设每一条通信路径的开销为200LOC年（LOC为代码行数）。假设有4名软件工程师，如果单独工作，每个人的生产率是6000LOC年，那么由这4名软件工程师组成的项目组的生产率为（ ）。4.关于输入输出语句错误的编码风格是（ ）5.在真实运行环境中，由用户组织的、以需求规格说明书和合同的基准的测试为（ ）。6.软件工程思想产生于解决20世纪60年代的软件为积极，下述： Ⅰ.软件需求定义不准确 Ⅱ.软件进度难以控制 Ⅲ.软件生产的高成本 Ⅳ.软件质量不易保证 （ ）是当时软件危机的主要表现。7.数据流图描述的是对系统的分解，其中最宏观层面的图称为（ ）8.关于抽象的思想错误的是（ ）9.关于用例说明错误的是（ ）10.JACkson结构图的三种基本结构是（　　）11.IDEF是IDEF方法的一部分，用于建立系统的（　　）12.在需求分析中，开发人员要与用户解决的最重要的问题是（ ）13.软件需求分析的任务不应包括（ ）
论软件项目质量管理
01-31
海尔总裁张瑞敏说：“有缺陷的产品等于废品。”的确，产品质量是企业生存的根本。当前，IT企业越来越重视软件项目的质量，而质量管理对软件项目成败又有着直接的影响。因此，研究软件项目质量管理，探索提升软件项目质量的途径成为一个热门课题。软件项目的实施过程也是软件质量形成的过程，涉及软件产品的各个层面。软件项目质量管理主要包括软件项目质量计划编制、软件项目质量保证和软件项目质量控制三个过程。training.mypm.net软件项目质量计划是软件质量管理的行动纲领，通常由项目经理和质量人员共同协商制定质量计划。它包括确认与项目有关的质量标准以及如何满足这些标准。如果机构有独立的质量人员，就由质量人员起
软件工程知识点
12-02
一、软件工程概述 1．软件特点 软件：计算机程序、方法、规则、相关的文档资料，以及计算机程序运行时所需要的数据。 软件是计算机系统中的逻辑成分，具有无形性。其主要内容包括：程序、配置文件、系统 文档、用户文档等。 2．软件分类 （1）按功能划分：系统软件、支撑软件、应用软件。 （2）按工作方式划分：实时处理软件、分时处理软件、交互式软件、批处理软件。 （3）按规模划分：微型软件、小型软件、中型软件、大型软件。 （4）按服务对象划分：通用软件、定制软件。 3．软件发展阶段 （1）程序设计时代（20世纪50年代）。 （2）程序系统时代（20世纪60年代）。 （3）软件工程时代（20世纪70年代起）。 4．软件危机 （1）危机现象：软件开发成本与进度估计不准确，软件产品与用户要求不一致，软件产品质量可靠性差，软件文档不完整不一致，软件产品可维护性差，软件生产率低。 （2）危机原因：软件的不可见性，系统规模庞大，生产工程化程度低，对用户需求关心不 够，对维护不够重视，开发工具自动化程度低。 5．软件工程 软件工程：运用现代科学技术知识来设计并构造计算机程序及为开发、运行和维护这些程序所必须的相关文件资料。 软件工程是一门关于软件开发与维护的工程学科，它涉及软件生产的各个方面，能够为经济、高效地开发高质量的软件产品提供最有效的支持。 （1）工程方法：结构化方法、JSD方法、面向对象方法。 （2）软件工具：具有自动化特征的软件开发集成支撑环境。 （3）工程过程：在软件工具支持下的一系列工程活动，基本活动是软件定义、软件开发、 软件验证、软件维护。 （4）工程管理：项目规划，项目资源调配，软件产品控制。 （5）工程原则：分阶段生命周期计划，阶段评审制度，严格的产品控制，采用先进的技术， 成果能清楚地审查，开发队伍精练，不断改进工程实践。 （6）工程目标：开发成本较低，软件功能能满足用户需求，软件性能较好，软件可靠性高， 软件易于使用、维护与移植，能按时完成开发任务并及时交付使用。 （7）工程文化：包括工程价值、工程思想和工程行为三个方面的内容。 二、软件工程过程模型 1．软件生命周期 如同任何事物都有一个发生、发展、成熟直至衰亡的全过程一样，软件系统或软件产品也有一个定义、开发、运行维护直至被淘汰这样的全过程，我们把软件将要经历的这个全过程称为软件的生命周期。它包含：软件定义、软件开发、软件运行维护三个时期，并可以细分为可行性研究、项目计划、需求分析、概要设计、详细设计、编码实现与单元测试、系统集成测试、系统确认验证、系统运行与维护等几个阶段。 软件定义期 软件定义是软件项目的早期阶段，主要由软件系统分析人员和用户合作，针对有待开发的软件系统进行分析、规划和规格描述，确定软件是什么，为今后的软件开发做准备。这个时期往往需要分阶段地进行以下几项工作。 1．软件任务立项 软件项目往往开始于任务立项，并需要以“软件任务立项报告”的形式针对项目的名称、性质、目标、意义和规模等作出回答，以此获得对准备着手开发的软件系统的最高层描述。 2．项目可行性分析 在软件任务立项报告被批准以后，接着需要进行项目可行性分析。可行性分析是针对准备进行的软件项目进行的可行性风险评估。因此，需要对准备开发的软件系统提出高层模型，并根据高层模型的特征，从技术可行性、经济可行性和操作可行性这三个方面，以“可行性研究报告”的形式，对项目作出是否值得往下进行的回答，由此决定项 目是否继续进行下去。 3．制定项目计划 在确定项目可以进行以后，接着需要针对项目的开展，从人员、组织、进度、资金、设备等多个方面进行合理的规划，并以“项目开发计划书”的形式提交书面报告。 4．软件需求分析 软件需求分析是软件规格描述的具体化与细节化，是软件定义时期需要达到的目标。 需求分析要求以用户需求为基本依据，从功能、性能、数据、操作等多个方面，对软件系统给出完整、准确、具体的描述，用于确定软件规格。其结果将以“软件需求规格说明书”的形式提交。 在软件项目进行过程中，需求分析是从软件定义到软件开发的最关键步骤，其结论不仅是今后软件开发的基本依据，同时也是今后用户对软件产品进行验收的基本依据。 软件开发期 在对软件规格完成定义以后，接着可以按照“软件需求规格说明书”的要求对软件实施开发，并由此制作出软件产品。这个时期需要分阶段地完成以下几项工作。 1．软件概要设计 概要设计是针对软件系统的结构设计，用于从总体上对软件的构造、接口、全局数据结构和数据环境等给出设计说明，并以“概要设计说明书”的形式提交书面报告，其结果将成为详细设计与系统集成的基本依据。 模块是概要设计时构造软件的基本元素，因此，概要设计中软件也就主要体现在模块的构成与模块接口这两个方面上。结构化设计中的函数、过程，面向对象设计中的类、对象，它们都是模块。概要设计时并不需要说明模块的内部细节，但是需要进行全部的有关它们构造的定义，包括功能特征、数据特征和接口等。 在进行概要设计时，模块的独立性是一个有关质量的重要技术性指标，可以使用模块的内聚、耦合这两个定性参数对模块独立性进行度量。 2．软件详细设计 设计工作的第二步是详细设计，它以概要设计为依据，用于确定软件结构中每个模块的内部细节，为编写程序提供最直接的依据。 详细设计需要从实现每个模块功能的程序算法和模块内部的局部数据结构等细节内容上给出设计说明，并以“详细设计说明书”的形式提交书面报告。 3．编码和单元测试 编码是对软件的实现，一般由程序员完成，并以获得源程序基本模块为目标。 编码必须按照“详细设计说明书”的要求逐个模块地实现。在基于软件工程的软件开发过程中，编码往往只是一项语言转译工作，即把详细设计中的算法描述语言转译成某种适当的高级程序设计语言或汇编语言。 为了方便程序调试，针对基本模块的单元测试也往往和编码结合在一起进行。单元测试也以“详细设计说明书”为依据，用于检验每个基本模块在功能、算法与数据结构上是否符合设计要求。 4．系统集成测试 所谓系统集成也就是根据概要设计中的软件结构，把经过测试的模块，按照某种选定的集成策略，例如渐增集成策略，将系统组装起来。 在组装过程中，需要对整个系统进行集成测试，以确保系统在技术上符合设计要求，在应用上满足需求规格要求。 5．系统确认验证 在完成对系统的集成之后，接着还要对系统进行确认验证。 系统确认验证需要以用户为主体，以需求规格说明书中对软件的定义为依据，由此对软件的各项规格进行逐项地确认，以确保已经完成的软件系统与需求规格的一致性。为了方便用户在系统确认期间能够积极参入，也为了系统在以后的运行过程中能够被用户正确使用，这个时期往往还需要以一定的方式对用户进行必要的培训。 在完成对软件的验收之后，软件系统可以交付用户使用，并需要以“项目开发总结报告”的书面形式对项目进行总结。 软件运行与维护期 软件系统的运行是一个比较长久的过程，跟软件开发机构有关的主要任务是对系统进行经常性的有效维护。 软件的维护过程，也就是修正软件错误，完善软件功能，由此使软件不断进化升级的过程，以使系统更加持久地满足用户的需要。因此，对软件的维护也可以看成为对软件的再一次开发。在这个时期，对软件的维护主要涉及三个方面的任务，即改正性维护、适应性维护和完善性维护。 2．瀑布模型 瀑布模型诞生于20世纪70年代，是最经典的并获得最广泛应用的软件过程模型。瀑布模型中的“瀑布”是对这个模型的形象表达，即山顶倾泻下来的水，自顶向下、逐层细化。 （1）特点：线性化模型、阶段具有里程碑特征、基于文档的驱动、阶段评审机制。 （2）作用：为软件项目按规程管理提供了便利，为其他过程模型的推出提供了一个良好的 拓展平台。 （3）局限性：主要适合于需求明确且无大的需求变更的软件开发，但不适合分析初期需求 模糊的项目。 3．原型模型 （1）快速原型方法：是原型模型在软件分析、设计阶段的应用，用来解决用户对软件系统在需求上的模糊认识，或用来试探某种设计是否能够获得预期结果。 （2）原型进化模型：针对有待开发的软件系统，先开发一个原型给用户使用，然后根据用 户的使用意见，对原型不断修改，使它逐步接近，并最终到达开发目标。 4．增量模型 增量模型结合了瀑布模型与原型进化模型的优点。在整体上按照瀑布模型的流程实施开发，以方便对项目的管理。但在软件的实际创建中，则将软件系统按功能分解为许多增量构件逐个地创建与交付，直到全部构件创建完毕，并都被集成到系统之中交付使用。 比较瀑布模型、原型进化模型，增量模型具有非常显著的优越性。但增量模型对软件设计有更高的技术要求。 5．螺旋模型 螺旋模型是一种引入了风险分析与规避机制的过程模型，是瀑布模型、快速原型方法和风险分析方法的有机结合。其基本方法是，在各个阶段创建原型进行项目试验，以降低各个阶段可能遇到的项目风险。 6．喷泉模型 喷泉模型是专门针对面向对象软件开发方法而提出的。“喷泉”一词用于形象地表达面向对象软件开发过程中的迭代和无缝过渡。 7．组件复用模型 组件复用方法是最近几年发展起来的先进的软件复用技术，在基于组件复用的软件开发中，软件由组件装配而成，这就如同用标准零件装配汽车一样。因此，组件复用模型能够有效地提高软件生产率。 三、项目分析与规划 1.计算机系统分析 （1）计算机系统 计算机系统是一个非常复杂并具有智能特性的开发系统，包括：硬件系统、软件系统、网络通信系统、人工操作系统等诸多子系统。 （2）系统分析 系统分析是对软件项目的高层分析，需要获取的是有关系统的框架描述，并需要使系统从它所处的环境中分离出来，为划分系统边界与确定系统构架提供依据。 （3）系统分析模型 分析模型是指采用作图方式对系统进行直观的描述。系统前期分析过程中经常使用的图形模型有系统框架图和系统流程图。其中，系统框架图用于说明系统的基本构造框架，而系统流程图则用于表现系统的基本加工流程。 2.项目可行性分析 （1）意义 •以少量的费用对项目能否实施尽早作出决断。 •根据项目条件限制，对系统的体系构造、工作模式等作出高层抉择。 •其结果可作为一个高层框架被用于需求分析之中。 （2）分析内容 •技术可行性：从技术与技术资源这两个方面作出可行性评估。 •经济可行性：从项目投资和经济效益这两个方面作出可行性评估。 •应用可行性：从法律法规、用户操作规程等方面作出可行性评估。 （3）分析过程 •建立系统模型。 •进行可行性评估。 •撰写可行性研究报告。 3.项目成本效益分析 （1）项目成本估算方法：基于软件规模的成本估算；基于任务分解的成本估算。 （2）项目效益分析指标：纯收入；投资回收期；投资回收率。 4.项目规划 （1）项目开发计划 项目开发计划涉及的内容包括： •开发团队的组织结构，人员组成与分工。 •项目成本预算。 •项目对硬件、软件的资源需求。 •项目任务分解和每项的任务里程碑标志。 •基于里程碑的进度计划和人员配备计划。 •项目风险计划。 •项目监督计划。 （2）项目进度表 项目进度是基于里程碑制定的，可以使用进度图表来描述项目进度。甘特图表是一种常用的项目进度图表，可以直观地描述项目任务的活动分解，以及活动之间的依赖关系、资源配置情况、各项活动的进展情况等。 四、软件需求分析 1.需求分析任务 （1）用户需求 用户需求是用户关于软件的一系列意图、想法的集中体现，是用户关于软件的外界特征的规格表述。 （2）系统需求 系统需求是比用户需求更具有技术特性的需求陈述，是提供给开发者或用户方技术人员阅读的，并将作为软件开发人员设计系统的起点与基本依据。主要包括：功能、数据、性能、安全等诸多方面的需求问题。 2.需求分析过程 需求分析是对软件系统的后期分析，需要进行的活动包括：分析用户需求、建立需求原型、分析系统需求和进行需求验证等。 3.用户需求获取 （1）用户调查是最基本的用户需求信息收集方法，比较常用的调查方法包括：访谈用户、开座谈会、问卷调查、跟班作业、收集用户资料。 （2）需求原型可被用来解决用户对软件系统在需求认识上的不确定性。一般情况下，开发人员将软件系统中最能够被用户直接感受的那一部分东西构造成为原型。例如，界面、报表或数据查询结果。 4.结构化分析建模 所谓模型，就是对问题所做的一种符号抽象。可以把模型看作为一种思维工具，利用这种工具可以把问题规范地表示出来。主要的分析模型包括： （1）功能层次模型。它使用矩形来表示系统中的子系统或功能模块，使用树形连线结构来表达系统所具有的功能层级关系。 （2）数据流模型。用于描述系统对数据的加工过程，其图形符号是一些具有抽象意义的逻辑符号，主要的图形符号包括：数据接口、数据流、数据存储和数据处理。可以依靠数据流图来实现从用户需求到系统需求的过渡。结构化分析就是基于数据流的细化实现的，它是结构化分析方法的关键。 （3）数据关系模型。也称为ER图，是应用最广泛的数据库建模工具。需要通过数据实体、数据关系和数据属性这三类图形元素建立数据关系模型。 （4）系统状态模型。通过系统的外部事件、内部状态为基本元素来描绘系统的工作流程，这种建模方式比较适合于描述一些依赖于外部事件驱动的实时系统。 5.需求有效性验证 需求有效性验证是指对已经产生的需求结论所要进行的检查与评价。一般需要对需求文档草稿从有效性、一致性、完整性、现实性、可检验性等几个方面进行有效性验证。比较常用的需求有效性验证方法与工具包括：需求评审、需求原型评价和基于CASE工具的需求一致性分析。 6.需求规格定义 需求规格说明书是需求分析阶段需要交付的基本文档，将成为开发者进行软件设计和用户进行软件验证的基本依据，涉及引言、术语定义、用户需求、系统体系结构、系统需求等有关软件需求及其规格的诸多描述与定义。 五、软件概要设计 1．设计过程与任务 概要设计中首先需要进行的是系统构架设计，然后是软件结构、数据结构等方面的设计。主要有以下几个方面的设计任务：制定规范、系统构架设计、软件结构设计、公共数据结构设计、安全性设计、故障处理设计、可维护性设计、编写文档、设计评审。 2．系统构架设计 （1）集中式结构 集中式系统由一台计算机主机和多个终端设备组成。其具有非常好的工作稳定性和安全保密性。但系统建设费用、运行费用比较高，灵活性不够好，结构不便于扩充。 （2）客户机/服务器结构 客户机/服务器结构依靠网络将计算任务分布到许多台不同的计算机上，但通过其中的服务器计算机提供集中式服务。其优越性是结构灵活、便于系统逐步扩充。 （3）多层客户机/服务器结构 •两层结构：将信息表示与应用逻辑处理都放在了客户机上，服务器只需要管理数据库事务。 •三层结构：将两层结构的客户机上的容易发生变化的应用逻辑部分提取出来，并放到一个专门的“应用服务器”上。 •B/S结构：是Web技术与客户机/服务器结构的结合。其优点是不需要对客户机进行专门的维护。 （4）组件对象 分布式结构通过组件进行计算分布。它依赖于对象中间件建立，具有灵活的构架，系统伸缩性好，能够给系统的功能调整与扩充带来便利。 3．软件结构设计 软件结构设计是对组成系统的各个子系统的进一步分解与规划。主要设计内容有：确定模块元素、定义模块功能、定义模块接口、确定模块调用与返回、进行结构优化。 （1）模块概念 •模块化：使用构造程序，可使软件问题简化。 •抽象化：概要设计中的模块被看成是一个抽象化的功能黑盒子。 •信息隐蔽：每个模块的内部实现细节对于其他模块来说是隐蔽的。 （2）模块的独立性 软件系统中每个模块都只涉及自己特定的子功能，并且接口简单，与软件中其他模块没有过多的联系。一般采用耦合和内聚这两个定性的技术指标进行度量。 耦合用来反映模块相互关联程度，模块间连接越紧密，耦合性就越高。内聚用来反映模块内元素的结合程度，模块内元素结合越紧密，则内聚性就越高。为提高模块独立性，要求模块高内聚、低耦合。 耦合形式由低至高是：非直接耦合、数据耦合、控制耦合、公共耦合、内容耦合。 内聚形式由低至高是：偶然内聚、逻辑内聚、时间内聚、过程内聚、通信内聚、顺序内聚、功能内聚。 （3）设计建模 •软件结构图：由Yourdon于20世纪70年代提出，被广泛应用于软件结构设计中，能够有效说明软件中模块之间的调用与通信。 •HIPO图：由美国IBM公司推出。其中，H图用于描述软件的分层调用关系，作用类似软 件结构图，IPO图用于说明描述模块的输入—处理—输出特征。 （4）软件结构优化 主要优化设计原则有：使模块功能完整、使模块大小适中、使模块功能可预测、尽量降低模块接口的复杂程度、使模块作用范围限制在其控制范围之内、模块布局合理。 4．面向数据流的结构设计 （1）变换分析 软件结构由输入、变换和输出三个部分组成。 （2）事务分析 软件结构由接收事务与事务活动两个部分组成。 （3）混合流分析与设计 软件系统是变换流与事务流的混合。对于这样的系统，通常采用变换分析为主、事务分析为辅的方式进行软件结构设计。5.数据库结构设计 （1）逻辑结构设计 •设计数据表 •规范数据表 •关联数据表 •设计数据视图 （2）物理结构设计 •数据存储结构 •数据索引与聚集 •数据完整性 六、面向对象分析与设计 1．面向对象方法学 面向对象技术涉及面向对象分析（OOA）、面向对象设计（OOD）和面向对象编程实现（OOP）这三个方面的问题。 （1）基本概念 •类：面向对象模块单位，作用是为创建对象实例提供模板。其具有数据与行为这两个方面的特征，并需要通过属性、操作和方法进行描述。 •属性、操作与方法：类具有数据与行为这两个方面的特征，并需要通过属性、操作和方法进行描述。 •类的继承性：指上级父类能够把自己的属性、操作传递给下级子类。 •类的多态性：子类对象可以像父类对象那样使用，它们可以共享一个操作名，然而却有不同的实现方法。 •对象：对象是类模块实例化的结果。 •消息：指对象之间的通信。 （2）优越性 •跟现实世界更加接近 •可使软件系统结构更加稳定 •软件具有更好的可重用性 •软件更加便于维护与扩充 2．面向对象分析建模 面向对象分析建模需要建立的是软件系统的用户领域模型，需要从系统业务流程、组织结构和行为过程等几个方面对系统进行分析。 （1）用例图 用例图涉及参入者、用例等元素，用于描述用户与系统之间的交互关系，说明系统所具有的业务能力和业务流程，能够方便开发者理解用户领域的专有术语和业务内容。 （2）活动图 活动图是一种行为模型，主要用于描述用例图中用例的内部活动状态与活动转换过程，以获得对用例的交互行为与工作流程的细节说明。涉及活动状态、活动转换等元素。 （3）分析类图 建立类图的概念模型，描述体现现实世界中数据构造的实体类及其它们之间的关系。 （4）序列图 以用例图中的用例为描述单位，以类图中的类为对象依据，以活动图中的活动转换为行为依据，建立与时间顺序有关的用例中对象之间的交互模型。 3．面向对象设计建模 面向对象设计建模需要把分析阶段的结果扩展成技术解决方案，需要建立的是软件系统的技术构造模型。 （1）设计类图 设计类图中的类是构造系统的基本模块单位，需要在分析类图基础上进行更加完整的面向设计的描述。除了实体类，设计类图中还需要考虑用于向外提供操作接口的边界类和用于实现内部协调的控制类。 （2）协作图 描述对象交互时的链接关系和基于链接而产生的消息通信及其操作接口。 （3）状态图 描述一个特定对象的所有可能的状态以及引起状态转换的事件。 （4）构件图 描述组成系统的物理构件及其它们之间的关系。构件之间关系主要是依赖关系。 （5）部署图 描述系统运行时的物理架构，涉及物理节点、节点之间的连接关系以及部署到各个节点上的构件的实例等。 七、用户界面设计 1．图形用户界面（GUI）所具有的特点 （1）比较容易学习和使用。 （2）用户可利用多屏幕（窗口）与系统进行交互，并可通过任务窗方便地由一个任务转换到另一个任务。 （3）可以实现快速、全屏的交互，能很快在屏幕上的任何地方进行操作。 图形用户界面设计已不是设计人员能够独立解决的了，需要邀请图形设计人员、系统分析人员、系统设计人员、程序员、用户应用领域方面的专家和社会行为学方面的专家以及最终用户的共同参入。 2．基于原型的用户界面设计 用户界面设计是一个迭代的过程，其基本过程包括三个步骤： （1）建立界面需求规格模型。 （2）以界面需求模型为依据创建界面原型。 （3）评价界面原型。 3．界面设计中需要考虑的因素 用户界面设计将会受诸多用户因素的影响，并主要体现在以下几个方面： （1）用户工作环境与工作习惯。 （2）用户操作定势。 （3）界面一致性。 （4）界面动作感。 （5）界面信息反馈。 （6）个性化。 （7）容错性。 （8）审美性与可用性。 4．界面类型 在基于图形界面的应用系统中，用户界面一般由若干个窗体组成，其窗体类型包括： （1）单窗体界面（SDI）。其特点是应用程序一次只能打开一个独立窗体。 （2）多窗体界面（MDI）。由一个MDI主窗体和多个MDI子窗体组成。其中MDI主窗体如同容器用来装载MDI子窗体，而MDI子窗体则被限制于MDI主窗体之内，不能独立存在。诸多公共操作都被放置在MDI主窗体上。 （3）辅助窗体。通常也叫做对话框，它是对主窗体的补充，用于扩展主窗体的功能。辅助窗体的种类主要有：登录窗、消息窗、设置窗等。 （4）Web页面。当采用到基于Web的B/S结构时，系统中的某个Web页面可能会被作为Web应用的进入点，则它可以作为一个特殊的主窗体看待。 5．界面功能特征 在进行用户界面设计时，需要考虑界面的功能问题。大体上说来，用户界面的功能主要体现在以下方面： （1）用户交互。指用户与计算机系统之间的信息交流。 （2）信息表示。指系统提供给用户信息，信息可以采用文本形式表示，也可以采用图形形式表示。 （3）用户联机支持。指系统给用户提供的应用指导。 6．界面导航设计 界面导航所指的是如何由一个界面转换到另一个界面。可以使用活动图来描述界面之间的转换关系，其中活动图中的每一个活动状态可用来表示系统中的每一个界面。 八、程序算法设计与编码 1．结构化程序特征 结构化程序的基本特征是程序的任何位置是单入口、单出口的。因此，结构化程序设计中，GOTO语句的使用受到了限制，并且程序控制也要求采用结构化的控制结构，以确保程序是单入口和单出口的。 2．程序算法设计工具 （1）程序流程图 程序流程图又称为程序框图，其历史悠久、应用广泛，从20世纪40年代末到70年代中期，它一直是程序算法设计的主要工具。程序流程图的主要优点是能够非常直观的描述程序的控制流程。但是，传统的程序流程图却是一种非结构化的程序算法设计工具。 （2）N－S图 为了满足结构化程序设计对算法设计工具的需要，Nassi和Shneiderman推出了盒图，又称为N－S图。它是一种严格符合结构化程序设计原则的图形描述工具。 N－S图的基本特点是通过矩形框描述模块内部程序的各个功能区域，并通过由外到内的矩形框嵌套表示程序的多层控制嵌套。 （3）PAD图 PAD是问题分析图（ProblemAnalysisDiagram）的英文缩写，由日本日立公司首先推出，并得到了广泛的应用。它是符合结构化程序设计原则的图形描述工具。 PAD图的基本特点是使用二维树形结构表示程序的控制流程，从上至下是程序进程方向，从左至右是程序控制嵌套关系。 （4）PDL语言 PDL语言也称为伪码，或过程设计语言，它一般是某种高级语言稍加改造后的产物，可以使用普通的正文编辑软件或文字处理系统进行PDL的书写和编辑。 PDL语言的语法规则分外部语法和内部语法。其中，外部语法用于定义程序中的控制结构和数据结构，内部语法则用于表示程序中的加工计算或条件。 （5）判定表 判定表是算法设计辅助工具，专门用于对复杂的条件组合关系及其对应的动作行为等给出更加清晰的说明，能够简洁而又无歧义地描述涉及条件判断的处理规则。 3．Jackson程序设计方法 1983年法国科学家Jackson提出了一种以软件中的数据结构为基本依据的程序算法设计方法。在以数据处理为主要内容的信息系统开发中，具有一定的应用价值。 Jackson程序设计方法的基本设计途径是通过分析输入数据与输出数据的层次结构，由此对程序算法的层次结构进行推论。 为了方便由数据结构映射出程序结构，Jackson将软件系统中所遇到的数据分为顺序、选择和重复三种结构，并使用图形方式加以表示。Jackson程序结构也是顺序、选择和重复这三种结构，并可以使用与数据结构相同的图形符号表示。 4．程序编码 在完成程序算法设计之后，接着需要编码。 （1）编程语言种类 •低级语言：包括第一代机器语言与汇编语言，它们是直接面向机器的语言。 •高级语言：指面向问题求解过程的语言，使用了与人的思维体系更加接近的概念和符号，一般不依赖于实现这种语言的计算机，具有较好的可移植性。 •第四代语言（4GL）：指一些面向问题的高级语言，第四代语言是在更高一级抽象的层次上表示数据与猜想结构，它不需要规定程序算法细节。 （2）选择编程语言的依据 在对软件系统进行编码之前，必须抉择使用什么样的程序设计语言实现这个软件系统。在选择编程语言时往往需要考虑诸多方面的因素，例如软件项目的应用领域、软件问题的算法复杂性、软件的工作环境、软件在性能上的需要、软件中数据结构的复杂性、软件开发人员的知识水平和心理因素等。 （3）编程风格与质量 编程风格是编写程序时需要遵守的一些规则。在衡量程序质量时，源程序代码的逻辑简明清晰、易读易懂是一个重要因素，而这些都与编程风格有着直接的关系。 （4）影响程序工作效率的因素 一般说来，程序工作效率会受到处理器计算速度、存储器存储容量和输入输出速度等几个方面因素的影响，并与程序设计语言、操作系统、硬件环境等有着直接关系。因此，在考虑程序工作效率时，需要将诸多因素综合起来分析。 5．程序算法复杂性度量 程序算法复杂性主要指模块内程序的复杂性。比较著名的程序算法复杂性度量方法是McCabe度量法，其对程序复杂性的度量采用的是程序的环形复杂度，计算公式是： V（G）=m–n+p 其中，V（G）是程序有向图G中的环数，m是程序有向图G中的弧数，n是程序有向图G中的节点数，p是程序有向图G中分离部分的数目。 九、软件测试 1．测试目标 尽力发现软件中的错误，而不是为了验证软件的正确性。 2．测试方法 （1）黑盒测试：基于程序的外部功能规格而进行的测试，又称为功能测试。 （2）白盒测试：基于程序的内部结构与处理过程而进行的测试，又称为结构测试。 3．单元测试 单元测试的对象是单元模块，一般以白盒测试为主，以黑盒测试为辅。测试内容包括模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试。 单元测试通常在编码阶段进行。测试时需要用到辅助模块，如驱动模块、桩模块。 4．集成测试 系统集成时主要有非渐增组装测试和渐增组装测试这两种方法： （1）非渐增组装测试：一种一次性地进行系统组装的方法。 （2）渐增组装测试：一种将单元模块的确认测试与集成测试结合在一起的测试方法，它比非渐增组装测试是具有更大的优越性。可以自顶向下渐增集成，也可以自底向上渐增集成。5．确认测试 确认测试又称有效性测试，其任务是验证软件的功能、性能及其他特性是否与用户的要求一致。在进行确认测试时，可以采用Alpha测试或Beta测试。其中，Alpha测试是在开发环境下由用户进行的测试，而Beta测试则是由软件用户在软件实际使用环境下进行的测试。 6．测试用例设计 设计测试用例就是为测试准备测试数据。由于测试用例不同，发现程序错误的能力也就不同，为了提高测试效率降低测试成本，应该选用高效的测试用例。 白盒测试用例设计主要采用逻辑覆盖，包括语句覆盖、判定覆盖、条件覆盖、判定—条件覆盖、条件组合覆盖和路径覆盖。 黑盒测试用例设计包括等价划分、边界值分析和错误推测等几种方法。 7．面向对象测试 （1）面向对象单元测试 不能孤立地测试单个操作，而应该把操作作为类的一部分来测试。 （2）面向对象集成测试 •基于线程的测试。 •基于使用的测试。 （3）面向对象确认测试 研究系统的用例模型和活动模型，设计出确认测试时的用户操作脚本。 8．软件调试 软件调试也叫做排错，涉及诊断与排错这两个步骤。但调试的关键是诊断。 常用的调试方法有：输出存储器内容、在程序中插入输出语句、使用自动调式工具。 常用的调试策略有：试探法、回溯法、对分查找法、归纳法、演绎法。 9．自动测试工具 常用的自动测试工具有：测试数据生成程序、动态分析程序、静态分析程序、模块测试、程序。 10．软件可靠性评估 软件可靠性的定义是：程序在给定的时间间隔内，按照规格说明书的规定成功地运行的概率。 软件可用性的定义是：程序在给定的时间点，按照规格说明书的规定，成功地运行的概率。为了方便可用性的计算，一般使用稳态可用性对系统进行可用性评价。 系统平均无故障时间的估算式是：MTTF=1/(K(ET/IT–Ec(t)/IT）） 十、软件维护 1．软件维护定义 软件维护是在软件运行维护阶段，为了改正软件错误或为了满足用户新的应用需要，而对软件进行改错、变更或进化的过程。 维护任务一般分为：改正性维护、适应性维护、完善性维护和预防性维护。 2．影响软件维护工作的因素 主要因素有：系统大小、程序设计语言、系统文档和系统年龄等。 3．非结构化维护 没有按照软件工程原则实施软件开发，以致和软件配套的一系列文档没有建立起来，保留下来的可能只有源程序。 4．结构化维护 建立在严格按照软件工程原则实施软件开发基础上，因此各个阶段的文档完整，能够比较全面地说明软件的功能、性能、软件结构、数据结构、系统接口和设计约束等。 5．软件维护的代价 软件维护代价包括有形与无形这两个方面的代价。其中，有形代价是指软件维护的直接费用支出，无形代价则指其他非直接的维护代价。 6．软件可维护性 软件可维护性是指维护人员理解、改正、改动和改进这个软件的难易程度。 可以从系统的可理解性、可靠性、可测试性、可修改性、可移植性、运行效率和可使用性这七个方面对软件的可维护性进行综合评估。 7．软件维护的实施 软件维护实施过程中，一般涉及以下几个问题：维护机构、维护申请报告、软件维护工作流程、维护记录和维护评价。 8．对老化系统的维护 老化系统是指一些使用早期程序设计语言开发的系统。为了能够有效地对老化系统进维 护，Yourdon提出了以下的几点维护建议： （1）尽可能得到更多的背景信息。 （2）力图熟悉程序的所有控制流程。 （3）评价现有文档的可用性。 （4）充分利用交叉引用信息。 （5）必须非常谨慎地对程序进行修改。 （6）在删除某些代码时，要确认代码确实不再使用。 （7）不要试图共享程序已有的临时变量或工作区。 （8）保持详细的维护活动和维护结果记录。 （9）如果程序结构混乱，修改受到干扰，可抛弃程序重新编写。 （10）插入出错检验。 9．逆向工程与再工程 逆向工程是通过源程序，甚至是目标程序，由此导出设计模型、分析模型的过程。可以把逆向工程描述为一个魔术管道，从管道一端流入的是一些非结构化的无文档的源代码或目标代码，而从管道另一端流出的则是计算机软件的分析、设计文档。 逆向工程被用到了软件维护上，通过从老化系统的源代码中提取程序流程设计、系统结构设计，甚至是数据流图，给老化系统的维护带来方便。 当逆向工程被用于重新构造或重新生成老化系统时，这个过程就叫做再工程。再工程不仅能从已存在的程序中重新获得设计信息，而且还能使用这些信息来改建或重建现有的系统。 10．软件配置管理 配置管理包括软件配置标识、软件变更控制和软件版本控制等方面的内容。 当对软件进行维护时，软件产品发生了变化，这一系列的改变，必须在软件配置中体现出来，以防止因为维护所产生的变更给软件带来混乱。
软件工程基础知识-软件质量
qq_37502042的博客
08-17 2863
归纳容错软件的定义，有以下4种。（1） 规定功能的软件，在一定程度上对自身错误的作用（软件错误）具有屏蔽能力，则称此软件为具有容错功能的软件，即容错软件。（2）规定功能的软件。在一定程度上能从错误状态自动恢复到正常状态。则称之为容错软件。（3） 规定功能的软件，在发生借误时，仍然能在一定程度上完成预期的功能，则把该软件称为容错软件。（4） 规定功能的软件，在一定程度上具有容错能力，则称之为容错软件。......
软件质量概述篇
weixin_72407838的博客
01-09 844
软件质量概述……
软件质量
qq_32746525的博客
10-15 439
ISO质量定义 一个实体的所有特性，基于这些特性可以满足明显的或隐含的需求。而质量就是实体基于这些特性满足需求的程度。 什么是实体？？ 实体： 产品：手机、MP3、汽车、软件、桌子 服务：酒店、出租车、快递、培训、，美容......... 实体特性举例： 榨汁机： 功能：能够榨豆浆、水果汁（苹果、梨、西瓜........） 性能：榨一斤黄豆需要多长时间？ 耗能：榨一公斤黄豆耗电...
软件质量控制的3个要素
似水流年
07-30 8033
软件质量控制指对于一个特定的软件开发项目，在如何计划和控制软件质量，为一个开发团队提供具体组织和实施方面的指导。软件质量控制有3个要素，我们来简单的了解一下。 1、产品在质量控制中应明确的是，一个过程的输出产品不会比输入产品质量更高。如果输入产品有缺陷，那么这些缺陷不仅不会在后续产品中自动消失，甚至它比对后续阶段产品的影响将成倍放大，当发现产品的质量与预想的有很大差别时，要反馈到前面的过程并采取纠正措施。这是产品的一个重要特性，也是软件质量控制的关键要素之一。 2、过程在质量控制中，一些过程是进行质量设计并
软件质量强调三方面内容
qq275860560的专栏
04-18 417
软件需求 是测试软件质量的基础 开发标准 定义了一组用于软件开发方式的准则 隐式需求 定义了用户对某些特性的期望
软件框架设计的艺术
05-27
3.9　如何检查API的质量　37 3.9.1　可理解性　37 3.9.2　一致性　38 3.9.3　可见性　39 3.9.4　简单的任务应该有简单的方案　40 3.9.5　保护投资　40 第4章　不断变化的目标　42 4.1　第一个版本远非完美　...
软件测试经典面试题 (超实用)
02-16
100、请就如何在开发中进行软件质量控制说说你的看法 27 101、一套完整的测试应该由哪些阶段组成？分别阐述一下各个阶段。 27 102、软件测试的类型有那些？分别比较这些不同的测试类型的区别与联系。 27 103、测试...
软件项目进度表：协调与并行提高工作质量
07-06
然而值得指出的是，程序员小组的正常技术交流能改进软件质量，提高软件的可维护性，减少软件错误，降低软件测试和正确性维护的开销。任务、人力、时间三者之间存在最佳组合，必须引起项目负责人的足够重视。  2、...
软件工程之专题七：软件工程专题
06-05
其目的是提高软件生产率、提高软件质量、减低软件成本。 软件工程是1968年在德国的NATO会议上提出的，希望用工程化的原则和方法来克服软件危机；而软件危机就是软件开发和维护过程中的各种问题，由于软件开发阶段...
软件需求（pdf文档）
11-20
本书讲述了软件开发中一个至关重要的问题—软件需求问题。软件开发人员及用户往往容易忽略信息沟通，导致软件开发出来后，不能很好地满足用户的需要。而返工则不仅在技术上给开发人员带来巨大的麻烦，而且软件性能...
软件需求全过程实践pdf
03-13
第三部分 软件需求管理 第16章 需求管理的原则与实现 133 16.1 需求管理和过程能力成熟度模型 133 16.2 需求管理步骤 135 16.3 需求规格说明的版本控制 135 16.4 需求属性 136 16.5 度量需求管理的效果 138 ...
软件工程-期末.doc
07-02
答:软件开发工程的基础 软件质量(可维护性、可理解性、可靠性)很大程度取决于 答:模块分解的合理 程序的三种基本控制结构的共同特点是 答:只有一个入口和一个出口 下面几种白盒测试技术，哪种是最强的覆盖准则 答:...
企业质量大数据的应用.docx
12-24
大数据的4个"V"，其特点有四个层面：第一数据体量巨大。从TB级别跃升到PB级别；第二数据类型繁多。第三处理速度快，1秒定律，可从各种类型的数据中快速获得高价值信息，这一点也和传统数据挖掘技术有着本质的不同。...
软件工程与UML建模.doc
07-02
数据流程图是一个分层的概念模型，分三个层次： ，分别描述系统的不同特征 A).总体图、二级图、三级图 B).总体图、二级图、细节图 C).总体图、零级图、细节图 D).总体图、次级图、细节图 6.以下用例命名中，最合理的...
软件测试的质量模型有哪些
最新发布
05-11
软件测试的质量模型有多种，以下是其中的一些： 1. Boehm的软件质量模型：该模型将软件质量定义为“软件产品在满足用户需要的基础上，满足用户预期的特定需求和标准的程度”。该模型包括了四个阶段：需求阶段、设计阶段、编码阶段和测试阶段。 2. McCall的软件质量模型：该模型将软件质量定义为“软件满足用户需求的程度”。该模型包括了三个方面：产品操作性、产品适应性和产品可维护性。 3. ISO 9126标准：该标准将软件质量定义为“软件满足用户需求和预期性能的程度”。该标准包括了六个特性：功能性、可靠性、可用性、可维护性、可移植性和效率。 4. IEEE标准829-1998：该标准定义了测试文档的样式和结构，包括测试计划、测试设计规范、测试用例规范、测试执行规范等，以确保软件测试的质量和有效性。 5. TMM（测试成熟度模型）：该模型是一种评估软件测试过程成熟度的模型，包括了五个层次：初级测试、重复测试、管理测试、定义测试、优化测试。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值