搜索
第一章：1.1补充一下1.1计算机软件：指计算机系统中的程序及其文档。程序是计算任务的处理对象和处理规则的描述。1.1.2软件的特点：1软件是一种逻辑实体，开发成本和进度难以准确估算；2软件是被开发或被设计的，没有明显的制造过程，一旦开发成功，只需复制，但维护的工作量大3软件使用没有硬件的机械磨损和老化问题，但使用过程有维护问题，维护修改程序的时候可能引入副作用，使故障率升高。1.1.3软件的分类1系统软件：操作系统、编译程序等2支撑软件：数据库管理系统、网络软件等3应用软甲：各类特定应用程序1.21.2.1软件工程定义IEEE：软件工程是：①将系统化的、严格约束的、可量化的方法应用于软件的开发、运行和维护，即将工程化应用于软件；②在①中所述方法的研究。1.2.2软件工程框架：概括为目标、过程和原则目标：生产具有正确性，可用性和开销合宜的产品。过程：生产一个最终满足需求且达到工程目标的软件产品所需要的步骤。原则：①选取适宜的开发模型②采用合适的设计方法③提供高质量的工程支撑④重视软件工程的管理1.2.3软件生存周期：六阶段①计算机系统工程：确定软件开发的要求和范围，估算成本，安排进度，可行性分析。②需求分析：要“做什么”，确定软件功能、性能、数据、界面等要求，生成软件需求规约。③设计：要“怎么做”，分为系统(总体)设计和详细设计。前者设计软件系统的体系结构，包括软件系统的组成部分，各成分的功能和接口，成分间的连接和通信，同时设计全局数据结构；后者设计各个组成成分的实现细节，包括局部数据和算法④编码：用某种程序设计语言，将设计结果转换为可执行代码。⑤测试：任务是发现并纠正软件中的错误和缺陷。主要包括单元测试、集成测试、确认测试和系统测试。⑥运行和维护：软件测试完成即可交付使用。在软件运行期间，需对投入运行的软件进行维护，即当发现软件中潜藏错误或需要增加功能或适应新外部环境变化等，对软件进行修改。1.31.3.1了解ISO/IEC12207软件工程生存周期过程该标准把软件生存周期中可以开展的活动分为5个基本过程，8个支持过程和4个组织过程。每一个过程划分为一组活动，每项活动又进一步划分为一组任务。（内容坑爹，无视，P9~P12约3页的表格，有兴趣的自己看（话说了解比知道要轻..现在我这么觉得1.3.2能力成熟度模型CMM5级：初始级：无秩序或混乱，成功依赖个人或小组的努力可重复级：建立了基本的项目管理过程来跟踪成本、进度和功能特性。制定了必要的过程纪律，能重复早先类似应用项目的成功。已定义级：以将管理和工程活动两方面的软件过程文档化、标准化，并综合成该组织的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件。已管理级：收集对软件过程和产品质量的详细度量值，对软件过程和产品都有定量的理解和控制。优化级：过程的量化反馈和先进的新思想、新技术促使过程不断改进CMM的结构P14有兴趣的..1.3.3知道能力成熟度模型集成CMMI两种表示法：①阶段式模型：同CMM，关注组织成熟度，5级初始的、已管理的、已定义的、定量管理的、优化的。②连续式模型：关注每个过程域的能力，分为6级：CL0：未完成的：未执行或未达到CL1定义的所有目标CL1：已执行的：共性目标是过程将可标识的输入工作产品转换成可标识的输出工作产品，以实现支持过程域的特定目标。CL2：已管理的：共性目标集中于已管理的过程的制度化。CL3：已定义级的：共性目标集中于以定义过程的制度化。CL4：定量管理的：共性目标集中于可定量管理的过程的制度化。CL5：优化的使用量化（统计学）手段改变和优化过程域，以对付客户要求的该百年和持续改进计划中的过程域的功效。1.4常见模型的种类，特点，优缺点，不同模型间对比瀑布模型：一路向下，可倒流回到上一级，7级系统工程-需求分析与规约-设计与规约-编码与单元测试-集成测试系统测试-运行与维护演化模型：先做原型给用户，根据使用意见逐步改造，最终得到令客户满意的产品。典型的模型有：增量模型、原型模型、螺旋模型（..居然这模型和后面这三种在同一级的标题增量模型：将开发过程分成若干个日程时间交错的线性序列，每个线性序列都产生软件的一个可发布“增量版本”。（越看越像流水线原型模型：快速计划-快速设计方式建模-构建原型-部署交付和反馈-交流-快速计划……不断循环。根据原型目的不同可分为：探索型、实验型、演化型。使用策略分为废弃策略、追加策略。螺旋模型：制定计划-风险分析-工程实施-客户评估不断循环。风险太大则可能终止喷泉模型：支持面向对象开发的过程模型，开发各个活动没有明显边界，各个活动经常重复、迭代地进行。“喷泉”体现了面向对象方法的迭代和无间隙特性。六个活动：演化，集成，测试，编码，设计，分析1.5敏捷软件开发基本概念，XP开发特点敏捷软件开发概念：书上没有，自由发挥。简单而言就是软件工程用了，质量提高了，但工作量太大以至于难以准时交付，于是快节奏开发软件的需求就来了，方法也出来了，这些方法就是敏捷软件开发。敏捷软件开发价值观：①个人和交互高于过程和工具②可运行软件高于详尽的文档③与客户协作高于合同(契约)谈判④对变更及时作出反应高于遵循计划敏捷软件开发原则：12条P27有兴趣的话..XP:extremeprogramming极限编程。四个价值观：交流，简单，反馈，勇气（追加第5个谦虚）。XP适用于软件需求模糊且挥发性（今天要求明天可能就不需要了）强，开发团队人数在10人以下，开发地点集中的场合。（这是特点么..?XP方法的12个核心实践P29-30怎么都是这种..1.完整的团队2.计划对策3.系统比喻4.小发布5.测试6.简单设计7.结对编程8.设计改进9.持续集成10.代码全体共享11.编码标准12.可持续步调第二章2.1计算机系统的概念，内容基于计算机的系统：通过处理信息来完成某些预定义目标而组织在一起的元素的集合或排列。组成基于计算机系统的元素主要有：软件、硬件、人员、数据库、文档和规程。软件：计算机程序、数据结构和相关的工作产品，以实现所需要的逻辑方法、规程和控制；硬件：指提供计算能力的电子设备、支持数据流的互连设备、提供外部世界功能的电子机械设备（传感器，马达等）。人员：硬件和软件的用户和操作者。数据库：通过软件访问并持久存储的大型的有组织的信息集合。文档：描绘系统使用或操作的描述性信息。规程：指定义每个系统元素的特定使用或系统所处的过程性语境的步骤。一个基于计算机的系统可以是另一个更大的基于计算机的系统的一个宏元素（组成部分）。2.3可行性分析的概念，分类可行性分析：一个基于计算机的系统通常受到资源和时间上的限制，可行性分析主要从经济、技术、法律等方面分析给出的解决方案是否可行，能否在规定的资源和时间约束下完成。可行性分析分类：①经济可行性：从成本、效益、货币的时间价值（通常可用年利率来表示）、投资回收期、纯收入来分析。②技术可行性：分为风险分析、资源分析、技术分析。③法律可行性。第三章需求工程的角色及其各个阶段//好吧，其实就是全部3.1概述需求工程是应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题，评估可行性，协商合理的解决方案、无歧义地规约方案、确认规约以及将规约转换到可运行的系统时的管理要求，需求工程通过合适的工具和符号系统地描述开发系统及其行为特征和相关约束，形成需求文档，并对用户不断变化的需求演进给予支持。分为6阶段：①需求获取：通过与用户交流，对已有系统的观察及对任务的分析，确定系统或产品范围等。②需求分析与协商：对需求进行分类组织，分析每个需求与其他需求的关系以检查需求的一致性、重叠和遗漏的情况，并根据用户的需要对需求排序。③系统建模：通过合适的工具和符号地描述需求。分析和建模方法有：面向数据流方法、面向数据结构方法和面向对象方法。④需求规约：需求规约是分析任务的最终产品，建立完整的信息描述、详细功能和行为描述、性能需求和设计约束说明、合适的验收标准，给出对目标软件的各种需求。⑤需求验证：对功能的正确性、完整性和清晰性以及其他需求给予评价。⑥需求管理：对需求工程所有相关活动的规划和控制。3.2需求获取3.2.1软件需求①功能需求：系统要做什么，在何时做，在何时及如何修改或升级②性能需求：软件开发的技术性指标③用户或人的因素：用户类型④环境需求：软件应用的环境，包括硬件和软件。⑤界面需求：考虑来自其他系统的输入，到其他系统的输出，对数据格式的特殊规定，对数据存储介质的规定。⑥文档需求：需要什么文档，针对哪些读者⑦数据需求：考虑输入、输出数据的格式，接受、发送数据的频率，数据的准确性和精度，数据流量，数据需保持的时间。⑧资源使用需求：考虑软件运行时所需要的数据、其他软件、内存空间等资源；软件开发、维护所需人力、支撑软件、开发设备等。⑨安全保密要求。⑩可靠性需求①①软件成本消耗与开发进度需求①②其他非功能性要求。3.2.2需求获取方法与策略①建立顺畅的通信途径②访谈与调查③观察用户操作路程④组成联合小组⑤用况3.3需求分析、协商与建模3.3.1需求分析原则·必须能够表示和理解问题的信息域·必须能够定义软件将完成的功能·必须能够表示软件的行为（作为外部事件的结果）·必须划分描述数据、功能和行为的模型，从而可以分层次地揭示细节。·分析过程应该从要素信息移向细节信息。3.3.2信息域信息域包括：信息内容：表示了单个数据和控制对象，目标软件所有处理的信息集合由它们构成。信息流：表示了数据和控制在系统中流动时的变化方式，输入对象被变换为中间信息（数据或控制），然后进一步被变换为输出。信息结构：表示了各种数据和控制项的内部组织形式，比如数据或控制项将被组织为n维表还是树形结构..?等3.3.3抽象、分解与多视点分析问题抽象方法要求分析人员在分析过程中捕捉用户描述或问题本身固有的一般-特殊关系，首先关注一般问题的解决途径，进而指导特殊问题的解决方法。问题分解的目的是要能以层次化的方式对问题进行分解和不断细化。分析人员在整理用户描述的过程中应注意用户视角上的变化，避免由于视角不全引起的需求遗缺。3.3.4需求协商复杂的系统又许多项目相关人员，他们之间的需求必定会出现冲突，协商的过程就是讨论需求冲突，找出每个人都满意的折衷方案。通常会议是解决冲突最快的方式。冲突解决会议应当只关注与冲突相关的需求问题。通常会议分为3个阶段：叙述阶段、讨论阶段和决策阶段。3.3.5需求建模在需求分析阶段，所创建的模型，要着重于描述系统要做什么，而不是如何去做。目标软件的需求模型不应涉及软甲你的实现细节。常用的分析方法有以下几种：面向数据流的结构化分析方法（SA）面向数据结构的分析方法面向对象的分析方法（OOA）3.4需求规约与验证3.4.1需求规约的原则①从现实中分离功能②使用面向处理的规约语言，讨论来自环境的各种刺激可能导致系统做出什么样的功能性反应。③如果被开发软件知识一个基于计算机的系统中的一个元素，那么整个大系统也应包括在规格说明的描述中④规约必须包括系统运行环境。⑤规约必须是一个认识模型，而不是设计或实现的模型。⑥规约必修是可操作的，利用它能够通过测试用例判断已提出的解决方案是否都能满足规约。⑦规约必须允许不完备性并允许扩充。⑧规约必须局部化和松散耦合。3.4.2需求规约软件需求规约的框架IEEE/ANSI830-1993标准：1引言2信息描述3功能描述4行为描述5检验标准6参考书目7附录3.4.3需求验证需求验证的目的是要检验需求是否能够反映用户的意愿。评审人员评审时往往需要检查以下内容：①系统定义的目标是否与用户的要求一致②系统需求分析阶段提供的文档资料是否齐全；文档中的描述是否完整、清晰、准确地反映了用户要求。③被开发项目的数据流与数据结构是否确定且充足。④主要功能是否已包括在规定的软件范围之内，是否都已充分说明⑤设计的约束条件或限制条件是否符合实际。⑥开发的技术风险是什么。⑦是否制定了详细的检验标准，它们能否对系统定义进行确认。3.5需求管理需求管理是一组用于帮助项目组