1.1 软件危机
1.1.1 软件危机的概念
软件危机是指计算机软件的开发与维护过程中遇到的一系列严重问题。软件危机包含两方面问题：如何开发软件，怎样满足对软件的日益增长的需求；如何维护数量不断膨胀的已有软件。以下为软件危机的一些表现。
• 对软件开发成本和进度的估计通常不准确；实际成本比预估成本可能高出一个数量级；实际进度比预期进度延迟几个月甚至更久。
• 用户对“已完成的”软件不满意；开发人员对用户的需求理解模糊；软件开发人员与用户之间的信息交流不充分。
• 软件产品产生质量问题；软件质量保证技术并没有应用到软件开发的全过程。
• 软件是不可维护的；程序中出现的错误难以改正；软件难以适应新的硬件环境，无法根据用户需求增加或删除一些功能；
• 软件没有完整的文档资料；文档资料无法与最新的代码完全匹配，即文档资料没有更新到最新的版本；文档资料作为软件开发人员的信息交流工具，以及软件维护人员的信息来源，缺乏必要的文档资料或相关文档资料不合格，将会给软件开发人员与软件维护人员带来大量且严重的问题。
• 软件成本在计算机系统中所占比例日益上升；微电子学技术进步，生产自动化程度提高，硬件成本下降，然而随着软件规模的扩大与软件数量的增加，软件成本持续上升。
1.1.2 软件危机的产生原因
①需求频繁变更
• 用户需求难以明确或经常变化，导致开发目标不清晰。
• 软件开发完成后，发现功能无法完全满足用户的实际需求。
②项目管理不善
• 项目缺乏有效的规划和管理，导致资源分配不合理。
• 时间和成本估算不足，进度计划不切实际。
• 团队成员之间缺乏协调，沟通不畅。
③技术复杂性增加
• 随着软件功能和规模的增长，系统变得越来越复杂。
• 新技术和工具的不断引入，增加了团队的学习成本和技术风险。
④开发方法落后
• 使用传统的开发方法（如瀑布模型）在快速变化的需求环境中难以适应。
• 缺乏敏捷开发或其他现代开发方法的灵活性。
⑤质量控制不足
• 软件开发过程缺乏严格的测试和评审，导致错误积累。
• 缺乏版本管理和配置管理工具，导致代码混乱和难以维护。
⑥团队能力不足
• 开发人员技术水平参差不齐，缺乏必要的经验和技能。
• 团队缺乏对新技术、新工具或复杂系统的理解和掌握。
⑦用户与开发团队脱节
• 用户与开发团队之间缺乏有效的沟通和协作。
• 用户需求未能及时反馈，导致开发方向偏离实际需求。
⑧外部环境因素
• 市场竞争压力和交付时间的限制，导致软件质量下降。
• 项目范围因外部因素扩大，资源却没有相应增加。
1.1.3 软件危机的解决途径
①引入现代化的软件开发方法
• 强调迭代开发和持续交付，快速响应需求变化。
• 强化用户与开发团队的沟通，保证开发方向正确。
• 将开发、运维和质量保障相结合，缩短交付周期，提升软件稳定性和效率。
• 通过模型设计简化复杂系统的开发，提高开发效率
②强化项目管理
• 与用户充分沟通，明确需求，减少后期变更的可能性。
• 引入需求优先级管理，确保核心功能优先完成。
• 制定合理的项目计划，包括时间、成本和资源分配。
• 通过甘特图、关键路径法等工具优化项目进度。
• 识别潜在风险并制定应对措施，减少突发问题的影响。
③提高软件开发过程质量
• 建立清晰的软件开发生命周期（SDLC）框架，规范开发活动。
• 在开发过程中进行单元测试、集成测试、系统测试等全覆盖测试。
• 使用自动化测试工具提高效率。
• 引入代码审查流程，确保代码质量和一致性。
• 使用版本控制工具（如 Git）管理代码库，减少冲突和混乱。
④提升团队能力
• 为团队成员提供技术培训，掌握新工具、新技术和开发方法。
• 强化团队间的沟通协作，避免信息孤岛。
• 提倡跨职能团队，增强开发与测试、运维的协同能力。
⑤引入先进的开发工具
• 使用持续集成工具（如 Jenkins、GitLab CI）提升效率。
• 引入自动化测试、部署和监控工具，减少人为错误。
• 使用 Jira、Trello 等工具进行任务跟踪和协作。
• 使用 UML 等建模工具直观表达系统架构和设计。
⑥重视用户参与
• 在开发过程中定期收集用户反馈，及时调整开发方向。
• 通过原型测试、验收测试让用户直接参与，确保软件满足需求。
1.2 软件工程
1.2.1 软件工程的基本原理
软件工程是一门研究如何系统化、规范化和量化地开发和维护软件的学科。其目标是通过工程化的方式，提高软件开发的效率、质量和可维护性，降低开发和维护的成本。
①清晰的需求定义（明确需求）
• 软件开发的首要任务是明确用户的实际需求。
• 需求必须完整、准确、可验证，避免因需求模糊或误解导致开发方向错误。
• 实现需求管理工具和方法，如用户故事、需求文档和原型设计。
②分阶段开发（阶段化）
• 将软件开发过程划分为多个阶段（如需求分析、设计、实现、测试等）。
• 每个阶段有明确的目标和可交付成果，有助于更好地管理和控制开发过程。
• 确保阶段间的评审，减少错误的累积。
③模块化设计（分而治之）
• 将复杂的软件系统分解为若干模块或组件，每个模块独立开发、测试和维护。
• 模块之间的依赖应尽可能减少，以提高系统的灵活性和可扩展性。
• 采用高内聚、低耦合的设计原则。
④软件可维护性
• 软件设计应考虑长期的维护和扩展需求，避免技术债务的积累。
• 编写清晰、简洁的代码，并提供详细的文档支持。
• 遵循编码规范，使用版本控制工具，保证软件的可理解性和可管理性。
⑤软件质量保证
• 在每个开发阶段引入质量控制活动，如代码审查、测试、验证和评审。
• 提前发现和解决缺陷，避免问题积累到后期修复成本高昂。
• 使用自动化测试工具，确保测试的全面性和高效性。
⑥风险管理
• 在开发过程中识别可能的风险（如技术难题、时间延误、预算超支等）。
• 制定应对策略，定期评估和监控风险，确保项目按计划推进。
• 通过原型验证或迭代交付减少风险的不确定性。
⑦不断改进（迭代优化）
• 软件工程是一个持续优化的过程，应根据用户反馈和新需求对软件进行更新和完善。
• 定期复盘项目开发过程，总结经验教训，优化流程。
• 引入敏捷开发等灵活方法，更快速地适应变化。
⑧团队协作
• 强调团队中开发人员、测试人员、产品经理和用户之间的协作与沟通。
• 使用项目管理工具和敏捷实践（如每日站会、看板）提高效率，减少沟通障碍。
1.2.2 软件工程的传统途径
软件工程的传统途径是指一系列经典的、结构化的软件开发方法论和模型，它们以阶段化的方式组织开发活动，旨在提供清晰的流程和规范化的管理方式。这些途径的核心思想是通过规范化、文档化和分阶段的开发流程，减少软件危机带来的问题，提升项目的可控性和成功率。
①核心特点
• 阶段化开发：将整个软件开发过程划分为若干连续的阶段（如需求分析、系统设计、编码实现、测试、部署和维护），每个阶段有明确的任务和交付物。
• 文档驱动：强调文档的重要性，每个阶段需输出详尽的文档作为下一阶段的基础。
• 单向性和线性流程：传统途径大多遵循固定的开发流程，从需求到维护逐步推进，不允许阶段之间频繁回溯。
• 规范化管理：强调通过制定开发规范和标准化流程，减少不确定性和错误，提高开发效率和质量。
②传统途径的代表方法
• 瀑布模型：开发过程严格按照顺序进行，强调各阶段之间的界限清晰。
• 增量模型：分阶段逐步开发和交付软件功能，以减少风险。
• 螺旋模型：以风险分析为核心，结合迭代开发的灵活性。
• 结构化方法：采用模块化设计，通过工具（如数据流图）描述系统结构。
• 面向对象方法：以对象为中心，强调模块化和代码重用。
③传统途径的理念
• 计划优先：在开发前制定全面的计划和流程，尽量减少开发中的不确定性。
• 完整性和一致性：通过详细的文档和流程规范，确保团队成员之间的理解一致。
• 控制与评审：通过阶段性评审和控制，及时发现问题，减少错误的积累。
④适用场景
传统途径适用于需求明确、变化较少的项目（如企业管理系统），以及大型、复杂且需要严格管理的项目（如银行系统、航空控制软件）。
这些传统途径为现代开发方法提供了理论基础，但在应对需求变化、快速交付等方面有局限性。
1.2.3 生命周期各阶段的基本任务
1. 问题定义与可行性研究阶段
这一阶段的任务是明确开发软件的初衷和必要性。首先，通过调查和分析，定义需要解决的问题，了解现有系统的缺陷或业务中的需求。接着，进行可行性研究，从技术可行性（是否有适合的技术和资源）、经济可行性（成本是否在预算范围内，收益是否足够吸引）、操作可行性（用户是否能够接受并使用系统）和法律可行性（项目是否符合相关法律法规）等方面进行综合评估，确定项目是否值得实施。最终输出可行性分析报告，作为项目决策的依据。
2. 需求分析阶段
在需求分析阶段，开发团队通过用户访谈、问卷调查、观察现有流程等方式，全面收集用户对软件功能和非功能特性的要求。这些需求包括软件需要实现的具体功能（如数据录入、查询、报表生成）以及性能需求（如响应时间、并发支持）。之后，通过分析和整理，识别需求中的矛盾、模糊点和遗漏之处，确保需求的完整性和一致性。最终，将分析结果记录在需求规格说明书中，作为软件开发的正式依据，并与用户确认。
3. 系统设计阶段
系统设计分为总体设计和详细设计两部分。在总体设计阶段，确定软件的体系结构（如客户端-服务器架构或微服务架构），进行模块划分，设计模块间的接口，以及制定数据库的初步结构。详细设计阶段则关注每个模块的内部逻辑，定义模块的输入输出、算法和数据处理流程。此阶段的任务是将需求规格说明书中的内容转化为清晰的技术设计方案，并形成设计文档，指导后续开发。
4. 实现阶段
实现阶段是将设计方案转化为实际的软件系统。开发人员根据详细设计文档，编写代码，实现每个模块的功能。此阶段注重遵循编码规范，确保代码的可读性和可维护性。在编码完成后，开发人员对模块进行单元测试，验证其功能是否正确。模块开发完成后，还需准备初步的集成，保证模块之间能够无缝协作。
5. 测试阶段
测试阶段通过单元测试、集成测试、系统测试和验收测试等过程，全面验证软件是否满足需求规格说明书中的要求，确保软件的功能性、可靠性和性能符合预期，并发现和修复潜在的缺陷。
6. 运行与维护阶段
在软件交付用户使用后，进入运行与维护阶段。运行期间需要监控软件的性能，确保其稳定性和可用性。维护工作包括修复用户反馈的问题（纠正性维护）、优化性能或添加新功能（改进性维护），以及适应硬件或业务环境的变化（适应性维护）。维护阶段通常持续多年，是软件生命周期中时间最长的一部分，确保软件能够长期为用户服务。
7. 退役阶段
当软件达到使用寿命，或被新的系统替代时，进入退役阶段。此时需要完成以下任务：迁移或归档相关数据，确保业务连续性；解除系统资源占用，释放硬件或网络资源；妥善关闭系统，避免数据丢失或系统冲突。退役阶段旨在为软件生命周期画上平稳的句号，同时为后续系统的发展提供支持。