系统开发与新技术

瀑布模型是让工序像瀑布一样从上游到下游依次推进、确定各工序的成果物后再进入下一步的开发模型。以短迭代开发的是敏捷开发，用原型确定需求的是原型化模型，组合既有服务是mashup的说明。

原型化模型的目的是尽早制作试作品（原型）让用户实际接触，在早期消除需求的模糊之处以及发包方与开发方的认识偏差。它不以减少行数为目的，也不能实现省略测试或免除维护。

敏捷开发是每个短迭代都累积可运行的软件、以规格变更为前提灵活应对的开发理念，Scrum和XP是代表性方法。确定全部需求后一次性开发、完成文档后才动手、用户只在最后参与，都接近瀑布式的做法，不是敏捷的特征。

冲刺是Scrum中作为开发单位的固定短周期，每个周期制定计划、进行开发、做出可运行的软件并回顾，如此循环往复。它不是指需求定义工序或验收测试期间，也不是只做错误修正的期间。

瀑布模型以不回头为前提推进，因此在下游的测试阶段发现需求或设计错误时，返回上游重做的返工成本非常大。它在每个工序都确定规格书、设计书等成果物，掌握进度反而是其所长，并且是适合大规模开发的模型。它也并非无法将需求文档化。

增量模型是把系统按功能单位分割、逐步叠加开发和发布的模型，与迭代型开发模型一样，优点是早期就能使用部分功能。瀑布模型是整体一次性按顺序开发的模型，结构化分析方法是使用DFD等的分析方法，mashup是既有服务的组合，都不符合。

开发从整理用户需求的需求分析开始，接着是设计用户可见部分的外部设计、内部实现方式的内部设计、编程，再到测试，这是基本顺序。设计先于需求分析的顺序，或测试先于编程的顺序，从成果物的依赖关系看都不能成立。

外部设计设计画面规格、报表规格、与其他系统的接口等用户和外部可见的部分。内部算法和物理存储方式的决定是内部设计、程序设计的作业，单个模块的运行确认是单元测试的作业。

单元测试是以模块为单位确认是否按详细设计运行的测试，是测试工序的最初阶段。组合模块确认接口的是集成测试（联调测试），发包方的验收是验收测试，高负荷下的性能确认是负载测试、性能测试的说明。

测试从小单位开始逐层累积：先做各模块的单元测试，再做组合模块的集成测试，然后是确认系统整体的系统测试，最后是发包方和用户进行的验收测试。先做整体确认或验收的顺序，会在部件缺陷混杂的状态下做上层测试，不合理。

验收测试是发包方和用户一方从业务角度确认交付的系统、判断能否验收的最终阶段测试。内部逻辑的确认是开发者进行的单元测试（白盒测试），不执行而确认的是静态测试，模块间连接确认是集成测试，都不是验收测试的说明。

黑盒测试把程序内部当作“黑箱”，只凭输入与输出的关系是否符合规格来确认。白盒测试是着眼于覆盖内部分支和路径的技法，静态测试是不执行程序、通过评审等确认的方法，回归测试是确认修改的影响没有破坏其他部分的测试。

施加大量并发访问和海量数据等高负荷、确认系统能否承受和性能是否保持的是负载测试，它与确认响应时间等的性能测试一起在系统测试阶段进行。单元测试是模块级的确认，静态测试是不执行的确认，白盒测试是着眼于内部结构的技法。

需求定义书是把需求分析的成果——系统应实现的功能、性能和约束——整理成文、由发包方与开发方达成一致的文档，是此后设计、测试和验收的基准。操作手册是面向用户的使用说明，单元测试成绩书是测试结果的记录，网络拓扑图是表示构成的设计类图纸，都不是达成一致的基准文档。

WBS是把项目的成果物及其所需作业分层分解、加以结构化的方法，可防止作业遗漏，并明确估算和分工的单位。用横条表示日程的是甘特图，按挣值管理的是EVM，风险的评估是风险分析的说明。

甘特图用横条表示各作业项目的开始和结束计划，广泛用于日程和进度的可视化。数据流图表示数据的流动，E-R图表示实体间的关系，用例图表示系统与用户的交互，都不是用于日程管理的图。

路径有A→B→D→F（3＋5＋4＋2＝14天）和A→C→E→F（3＋4＋6＋2＝15天）两条，F要等两条路径都完成，因此整体最短所需天数取较长的15天。这条最长路径A→C→E→F就是关键路径。14天是只看A→B→D→F一侧的值，12天和13天与任何路径的合计都不一致。

路径有A→B→D→F（2＋4＋3＋1＝10天）、A→C→D→F（2＋6＋3＋1＝12天）、A→C→E→F（2＋6＋4＋1＝13天）三条，最长的A→C→E→F＝13天就是关键路径。10天和12天是其他路径的合计，14天与任何路径都不一致。关键路径上的作业（A、C、E、F）的延误会直接变成整体的延误。

功能点法把输入输出、查询、内部文件等功能的数量和复杂度打分来估算软件规模，不依赖程序行数，可在开发早期估算。LOC是基于行数的另一种估算尺度，德尔菲法是通过对专家反复问卷使意见收敛的方法，KJ法是用卡片整理和分组信息的创意方法。

风险管理按以下顺序推进：先是找出风险的风险识别，然后是评估发生概率和影响程度的风险分析（定性和定量），再是决定应对措施的风险应对计划，最后是执行中跟踪状况的风险监视与控制。在识别之前做应对计划或监视，对象风险尚未确定，无法成立。

规格变更应遵循变更管理流程，在评估对进度、成本和质量的影响后，由变更管理委员会（CCB）判断批准或驳回。无条件接受会导致延期和质量下降，全部拒绝则连必要的变更也会失去。由负责人当场修改的做法会造成与配置和文档的不一致，失去管控。

利益相关者是发包方、用户、开发者、经营层等与项目结果存在利害关系的个人和组织的总称，把握并协调他们的期望是项目管理的重要活动。日程图是甘特图，分层的作业分解是WBS，风险清单对应风险登记册。

SLA是服务提供者与使用者之间就开机率、故障恢复时间、支持时间段等服务质量水准达成一致的约定，是运行服务的评价基准。著作权的保护是许可合同，作业分解图是WBS，设备租借是租赁合同的说明，都不是SLA。

ITIL（Information Technology Infrastructure Library）是把IT服务运行管理的最佳实践体系化的文档群，作为故障管理、变更管理、服务台等服务管理的框架被广泛参照。编程语言的规格、规范化理论和无线LAN规格都是别的领域的内容。

开机率用MTBF÷（MTBF＋MTTR）求得：570÷（570＋30）＝570÷600＝0.95。MTBF是从一次故障到下一次故障的平均运行时间，MTTR是修理所需的平均时间。0.90和0.98即使把分母分子弄错也对不上，0.93也不符合计算。

容量管理是预测数据量、访问量等未来使用量，有计划地确保和扩充服务器、存储和网络的容量，防患性能下降和容量不足于未然的管理活动。故障时的联络体制属于故障管理和应急响应，密码的管理属于用户管理，许可证数量的管理属于软件资源管理。

服务器虚拟化是借助虚拟化软件在1台物理服务器上运行多台虚拟机的技术，通过服务器整合提高资源利用效率，并获得配置变更和恢复的灵活性。物理分散安放和机箱小型化是硬件层面的事，纸面保管与虚拟化无关。

SaaS（Software as a Service）是把应用程序本身作为服务经网络提供的形态，使用者无需安装软件即可使用。IaaS提供服务器等基础设施，PaaS提供到应用程序运行环境为止的形态；本地部署是在自己组织内持有并运营设备的形态，不是云的提供形态。

Society5.0是通过IoT等把现实世界的数据汇集到赛博空间进行分析、再把结果回馈给现实世界，借助赛博空间与物理空间的高度融合实现经济发展与社会课题解决兼得的社会构想。在现实上叠加信息的技术是AR，计算的分担是分布式处理，开发管理的知识体系是PMBOK的说明。

有监督学习是给出带正确答案标签的数据、训练由输入预测正确答案的模型的方法，用于图像分类和数值预测等。不给正确答案、让机器发现数据结构和分组的是无监督学习。面向人的用户培训不是机器学习，用随机数随机生成输出也与学习无关。