项目分析与程序设计 学习笔记

第一部分------基础知识

一、项目分析阶段（核心：明确需求，判断可行性，解决「做什么？能不能做？」）

本阶段是项目的源头与基石，决定了项目的方向，核心输出为需求规格说明书，是后续所有工作的唯一基准。

1. 需求获取

• 核心定义：全维度收集项目相关的所有诉求，还原用户真实的业务目标，避免「解决方案先行」。
• 核心动作
  1. 多渠道获取：用户访谈、问卷调研、业务流程梳理、竞品分析、现场观摩
  2. 全内容覆盖：业务需求（项目目标 / 价值）、功能需求（具体要实现的能力）、非功能需求（性能、安全、兼容性、易用性）、约束条件（时间、成本、技术栈、合规要求）
• 考点速记：需求获取的核心是「全面、真实、贴合用户业务本质」
• 实战易错点：误把用户的「解决方案」当成「核心需求」（例：用户说「要加一个按钮」，本质需求是「快速完成 XX 操作」），导致后期需求反复变更。

2. 需求分析

• 核心定义：对原始需求进行梳理、筛选、建模，明确系统边界，把模糊的用户诉求转化为清晰、可实现、可验证的软件需求。
• 核心动作
  1. 需求梳理与分类：划分核心功能 / 非核心功能、必做需求 / 选做需求，剔除不合理、不可实现的需求
  2. 明确系统边界：界定「系统需要做什么」「系统不做什么」，区分人工操作、第三方系统提供的能力
  3. 需求优先级排序：常用 MoSCoW 法则（Must have 必须做、Should have 应该做、Could have 可以做、Won't have 暂不做）
  4. 需求建模：通过用例图、业务流程图可视化需求
• 考点速记：需求分析的核心是「锁定系统边界，杜绝需求蔓延」
• 实战易错点：系统边界模糊，导致开发过程中需求无限新增，项目延期。

3. 可行性研究

• 核心定义：从 4 个核心维度，判断项目「能不能做、值不值得做」，是项目立项的核心决策依据。

• 核心维度（考试必背）

  表格

  维度	核心判断标准
  技术可行性	现有技术栈、团队技术能力、开发周期内能否实现核心功能，是否存在无法突破的技术瓶颈，是否有备选方案
  经济可行性	成本估算（开发、运维、硬件、人力成本）、收益估算（直接 / 间接收益）、投资回报周期，判断投入产出比是否合理
  操作可行性	系统是否贴合目标用户的业务流程与使用习惯，操作门槛是否可控，是否需要额外培训，落地难度是否可接受
  法律可行性	是否符合《数据安全法》《个人信息保护法》等法律法规，是否存在知识产权侵权风险，是否需要相关资质准入

• 考点速记：四大可行性是软件工程核心考点，缺一不可

• 实战易错点：只关注技术可行性，忽略法律与经济可行性，导致项目最终无法落地或无商业价值。

4. 编写需求规格说明书（SRS）

• 核心定义：项目需求的正式、标准化文档，是整个项目的「基准宪法」，是后续设计、开发、测试、验收的唯一依据。
• 核心内容：项目概述、功能需求详情、非功能需求指标、系统边界、验收标准、约束条件、异常处理规则
• 考点速记：合格的 SRS 必须具备 4 个特性：完整性、一致性、无歧义性、可验证性
• 实战易错点：文档描述模糊、有歧义，导致开发结果与用户预期不符，引发验收纠纷。

本阶段背诵口诀

获析可行写规格，需求源头不跑偏

---

二、程序设计阶段（核心：方案落地，解决「怎么做？」）

本阶段是需求到编码的桥梁，核心是把需求转化为可落地的技术方案，遵循「高内聚、低耦合」的黄金设计法则。

1. 概要设计（总体设计）

• 核心定义：搭建系统的整体「骨架」，确定宏观技术方案，不纠结代码细节，决定了系统的整体架构与可扩展性。
• 核心动作
  1. 系统架构设计：根据项目规模选择架构模式（单体架构、分层架构 MVC/MVVM/ 三层架构、微服务架构等）
  2. 功能模块划分：按职责拆分模块，遵循「高内聚、低耦合」原则，明确模块间的调用关系、数据交互规则
  3. 技术选型：确定开发语言、开发框架、数据库、中间件、运行环境，匹配项目需求、团队能力与成本约束
• 考点速记：概要设计的核心是「架构选型与模块拆分，确定系统整体方案」
• 实战易错点：模块划分过粗 / 过细，模块间耦合度过高，导致后期难以维护、迭代成本极高。

2. 详细设计

• 核心定义：给每个模块「填充血肉」，把概要设计的模块细化为可直接编码的逻辑方案，目标是开发人员拿到设计文档即可直接编写代码。
• 核心动作
  1. 模块内部逻辑设计：通过流程图、伪代码，描述模块的业务流程、分支判断、循环逻辑、全场景异常处理
  2. 算法设计：核心业务的算法选型、逻辑优化，评估时间 / 空间复杂度
  3. 数据结构设计：定义模块内核心数据的存储与组织形式（数组、链表、对象、集合等）
  4. 接口设计：明确模块间接口、前后端接口（RESTful 规范）、第三方外部接口，定义入参、出参、请求方式、错误码、权限控制规则
• 考点速记：详细设计的核心是「精准、可落地、无歧义，覆盖全场景流程」
• 实战易错点：只设计正常业务流程，忽略异常分支与边界场景；接口设计不规范，导致前后端联调成本翻倍。

3. 数据库设计

• 核心定义：设计系统数据的存储与组织方案，是数据驱动型项目的核心，直接决定系统的性能、稳定性与可扩展性。
• 核心三阶段（考试 + 实战双重点）
  1. 概念设计 ：与业务深度绑定，不依赖具体数据库，核心输出E-R 图（实体 - 联系图）。核心工作：识别业务实体、实体的属性、实体间的联系（一对一、一对多、多对多）。
  2. 逻辑设计 ：将 E-R 图转化为关系数据表，核心遵循数据库三大范式，消除数据冗余，确定表与表的关联关系（主键、外键）。
  3. 物理设计：结合具体数据库（MySQL、Oracle 等）落地，确定字段类型与长度、非空 / 唯一 / 默认值约束、索引设计、存储引擎、字符集等，兼顾存储效率与查询性能。
• 考点速记：E-R 图三要素（实体、属性、联系）、数据库三大范式是核心必考点
• 实战易错点：过度范式化导致多表联查性能极差；不做索引设计，大数据量下查询卡顿；字段类型设计不合理，引发数据溢出或存储空间浪费。

4. 界面设计（UI/UE 设计）

• 核心定义：设计用户与系统的交互入口，核心原则是「以用户为中心」，平衡易用性、实用性与美观性。
• 核心动作：页面布局设计、交互流程设计、视觉样式设计、响应式适配设计、容错性设计
• 考点速记：界面设计的核心目标是「降低用户操作成本，提升使用效率」
• 实战易错点：只追求视觉美观，忽略操作易用性，导致用户学习成本高、留存率低。

本阶段背诵口诀

概要搭架详细填，库表界面全闭环

---

三、后续实现与验收阶段（核心：开发落地，交付与长期维护）

本阶段是把设计方案转化为可运行的系统，完成交付并保障长期稳定运行，是软件生命周期中时间最长、成本最高的阶段。

1. 编码实现

• 核心目标：按照详细设计文档，编写规范、可读、可维护的代码，实现模块功能
• 核心要求：遵循团队编码规范、完善代码注释、使用 Git 做版本控制、坚持模块化开发
• 易错点：脱离设计文档私自修改需求、代码无规范无注释，导致后期维护困难

2. 单元测试

• 核心目标：测试最小单元（单个模块、单个函数）的功能正确性，由开发人员完成，常用白盒测试
• 核心要求：覆盖所有代码分支、正常流程、异常分支与边界值
• 易错点：只测正常流程，忽略边界值与异常场景，导致隐藏 Bug 流入后续环节

3. 集成测试

• 核心目标：测试模块与模块之间的调用、数据交互是否正常，验证模块间协作是否符合设计要求，常用黑盒 + 白盒结合测试
• 核心要求：聚焦模块间的接口与数据流转，覆盖全模块联动场景
• 易错点：模块接口变更不同步，导致集成阶段出现大量兼容性问题

4. 系统测试

• 核心目标：对完整系统进行全量测试，验证系统是否完全符合需求规格说明书的所有要求，完全模拟用户真实使用场景，常用黑盒测试
• 核心测试范围：功能测试、性能测试、安全测试、兼容性测试、易用性测试
• 考点速记：系统测试的唯一基准是需求规格说明书
• 易错点：测试用例未覆盖全量需求，导致上线后出现功能缺失

5. 上线部署

• 核心目标：将系统发布到生产环境，供用户正式使用
• 核心动作：生产环境配置、数据迁移、制定部署方案（蓝绿部署、灰度发布）、上线前检查、制定回滚方案
• 易错点：无回滚方案，上线出问题无法快速恢复；生产环境与开发环境不一致，引发线上异常

6. 运行维护

• 核心目标：保障系统生产环境长期稳定运行，持续优化迭代
• 核心工作：Bug 修复、数据备份、性能优化、功能迭代、安全防护
• 考点速记（四大维护类型，考试必背）：纠错性维护、适应性维护、完善性维护、预防性维护
• 易错点：不做定期数据备份，导致数据丢失；不做安全维护，引发系统被攻击、数据泄露等风险

本阶段背诵口诀

编码测试上线后，维护迭代稳运行

---

四、补充学习模块

（一）全流程核心考点汇总（考试必背）

1. 软件生命周期三大核心阶段：项目分析（需求）、程序设计、实现与维护
2. 需求阶段核心输出：需求规格说明书（SRS）
3. 可行性研究四大维度：技术、经济、操作、法律
4. 软件设计黄金法则：高内聚、低耦合
5. 概要设计与详细设计的核心区别：概要设计定整体架构，详细设计定模块落地逻辑
6. 数据库设计三阶段：概念设计（E-R 图）、逻辑设计（三大范式）、物理设计
7. 测试四大核心阶段：单元测试、集成测试、系统测试、验收测试
8. 软件维护四大类型：纠错性、适应性、完善性、预防性

（二）新手实战避坑指南

1. 需求阶段：必须完成需求确认，让用户签字 / 确认需求文档，避免凭主观理解开发
2. 设计阶段：先设计后编码，禁止边写代码边改设计，避免架构混乱、后期无法维护
3. 数据库阶段：禁止无设计建表，表结构变更必须留存记录，避免数据冗余与结构混乱
4. 测试阶段：先完成单元测试，再做集成与系统测试，降低 Bug 定位成本
5. 上线阶段：任何上线都必须有回滚方案，禁止无预案全量上线

（三）极简考试背诵版

1. 需求四步：获析可行写规格，定准项目做什么
2. 设计四步：概要搭架、详细填逻辑、库表定结构、界面做交互，定准项目怎么做
3. 落地六步：编码、单测、集成、系统测、上线、运维，完成项目全闭环落地

第二部分，项目实践------综合新闻资讯 PC 网页 全流程项目分析与程序设计实战

项目定位：面向大众读者的 PC 端综合新闻资讯网页，支持新闻分类展示、搜索阅读、用户互动、后台内容管理，完全贴合课程作业 / 毕业设计 / 实战开发的标准流程，严格匹配前文的通用规范步骤。

---

一、项目分析阶段（解决「做什么？能不能做？」）

1. 需求获取

本次需求的核心沟通对象分为两类：运营管理方（需求方） 、终端用户（读者），全维度收集核心诉求如下：

表格

需求类型	具体收集内容
业务需求	搭建 PC 端新闻资讯门户网站，实现民生、时政、体育、娱乐等多品类新闻的线上发布与传播；提升资讯触达效率，积累用户流量，支持合规的广告位变现；核心目标是打造操作简单、内容权威、加载流畅的新闻阅读平台
功能需求	读者端：新闻分类浏览、新闻详情阅读、关键词搜索、用户注册登录、新闻评论、新闻点赞收藏、热点排行；管理端：管理员账号管理、新闻分类管理、新闻内容发布 / 编辑 / 上下架、内容审核、用户管理、评论审核管理、系统数据统计
非功能需求	性能：首页加载时间≤2s，详情页加载≤1.5s，支持 1000 人同时在线访问；兼容性：兼容 Chrome、Edge、Firefox 等主流浏览器；安全性：用户密码加密存储、权限隔离、内容合规审核、防 SQL 注入 / XSS 攻击；易用性：操作逻辑与主流新闻网站一致，用户零学习成本
使用环境	终端用户：Windows/Mac 系统 PC 端主流浏览器；运营方：Windows 系统 PC 端，支持可视化后台操作
约束条件	开发周期 2 个月；技术栈采用主流前后端分离架构；需符合互联网新闻信息服务相关法规；开发成本控制在千元级（含服务器、域名）

2. 需求分析

（1）系统边界明确

✅ 系统核心覆盖范围 ：PC 端 Web 新闻资讯的前台阅读系统 + 后台内容管理系统，聚焦新闻内容的发布、展示、阅读、互动全流程❌ 系统不覆盖范围：不开发移动端 APP、不做短视频 / 直播功能、不做电商带货模块、不承接新闻原创采编业务、不做短信 / 邮件推送服务

（2）需求梳理与优先级划分（MoSCoW 法则）

表格

优先级	具体需求
Must have（必须做）	新闻分类展示、新闻详情阅读、关键词搜索、用户注册登录、后台新闻发布 / 编辑 / 审核、评论发布与审核、分类管理
Should have（应该做）	新闻点赞收藏、热点排行、轮播热点推荐、用户个人中心、管理员权限管理
Could have（可以做）	新闻分享、相关新闻推荐、用户头像修改、夜间模式、阅读量统计
Won't have（暂不做）	短视频播放、用户私信、付费订阅、短信推送、多语言版本

（3）不合理需求剔除

剔除超出系统边界、成本过高的需求，例如：「实时推送新闻到用户手机短信」「用户付费解锁独家新闻」「短视频新闻上传播放」等，避免需求蔓延导致项目延期。

3. 可行性研究

从四大核心维度，全面判断项目落地可行性：

1. 技术可行性：采用成熟的前后端分离架构，前端使用 HTML5+CSS3+JavaScript+Vue3+Element Plus，后端使用 Java SpringBoot，数据库使用 MySQL 8.0，均为行业通用成熟技术，无技术瓶颈；2-3 人开发团队（学生 / 初级开发）可在 2 个月内完成开发，技术落地完全可行。
2. 经济可行性：成本端：域名（年约 30 元）+ 云轻量服务器（学生机 / 入门级，年约 300 元）+ 开发人力（课程作业 / 个人项目无额外成本），总成本可控在千元内；收益端：可通过合规广告位、流量合作实现变现，投入产出比合理，即使是个人学习项目，也几乎零成本，完全可行。
3. 操作可行性：读者端操作逻辑与新浪新闻、网易新闻等主流平台完全一致，用户无需额外学习即可上手；管理端采用可视化富文本编辑、列表化管理，运营人员仅需基础电脑操作能力即可完成内容发布与管理，无操作门槛，落地难度极低。
4. 法律可行性：严格遵守《网络安全法》《互联网新闻信息服务管理规定》《个人信息保护法》，设置完整的内容审核流程，杜绝违规内容发布；用户个人信息加密存储，不泄露、不滥用；不侵犯第三方知识产权，完全合规合法。

4. 编写需求规格说明书（SRS）

形成正式标准化文档，作为后续设计、开发、测试、验收的唯一基准，核心内容如下：

1. 项目概述：项目背景、目标、适用范围、读者对象
2. 总体需求：系统边界、用户角色划分、运行环境、约束条件
3. 功能需求详情：分读者端、管理端，对每个功能点进行无歧义的详细描述，含正常流程、异常流程
4. 非功能需求：性能指标、兼容性要求、安全性要求、易用性要求
5. 验收标准：明确每个核心功能的验收条件、性能验收阈值、上线标准
6. 异常处理规则：网络异常、参数错误、权限不足、服务器故障等场景的处理要求
7. 附录：术语定义、参考文档、版本记录

---

二、程序设计阶段（解决「怎么做？」）

1. 概要设计（总体设计）

（1）系统整体架构设计

采用前后端分离的分层架构，从上到下分为 5 层，职责清晰、高内聚低耦合：

plaintext

前端展示层 → 接口层 → 业务逻辑层 → 数据访问层 → 数据库层

• 前端展示层：负责页面渲染、用户交互、接口请求，独立部署
• 接口层：负责前后端数据交互，统一接口规范、权限校验、异常拦截
• 业务逻辑层：负责核心业务处理，例如新闻审核、评论校验、用户认证
• 数据访问层：负责与数据库交互，执行数据的增删改查
• 数据库层：负责系统全量数据的存储与管理

（2）功能模块划分与调用关系

整体分为前台用户系统（读者端）、** 后台管理系统（运营端）** 两大核心模块，拆分后的子模块及调用关系如下：

plaintext

┌─ 前台用户系统
│  ├─ 用户认证模块（注册/登录/鉴权/退出）
│  ├─ 新闻展示模块（首页/分类列表/详情页/轮播推荐）
│  ├─ 新闻搜索模块（关键词搜索/结果筛选）
│  ├─ 互动评论模块（评论发布/查看/点赞）
│  └─ 个人中心模块（我的收藏/我的评论/个人信息修改）
└─ 后台管理系统
   ├─ 系统管理模块（管理员账号/角色权限/系统配置）
   ├─ 内容管理模块（新闻发布/编辑/上下架/审核）
   ├─ 分类管理模块（新闻分类新增/编辑/排序/删除）
   ├─ 用户管理模块（前台用户查看/禁用/权限管理）
   └─ 评论管理模块（评论查看/审核/删除/举报处理）

核心调用规则：

• 前台所有模块均需依赖用户认证模块的鉴权结果（未登录用户不可评论、收藏）
• 前台新闻展示、搜索模块，调用后台内容管理、分类管理模块的开放接口
• 后台模块间权限隔离，仅超管可访问系统管理模块，普通编辑仅可操作内容管理模块

（3）技术选型与运行环境

表格

分类	具体选型
前端技术栈	HTML5 + CSS3 + JavaScript + Vue3 + Element Plus UI + Axios + Vue Router
后端技术栈	Java JDK 1.8 + SpringBoot 2.7 + MyBatis-Plus + Hutool 工具包
数据库	MySQL 8.0
开发工具	VS Code（前端）、IDEA（后端）、Navicat（数据库）、Postman（接口测试）
运行环境	服务器：CentOS 7；Web 服务器：Nginx；部署方式：Jar 包部署 + Nginx 反向代理

2. 详细设计

针对核心模块进行细化设计，输出可直接编码的落地逻辑，核心模块示例如下：

（1）核心模块 1：新闻展示模块

• 模块职责：负责首页、分类列表、新闻详情页的新闻数据渲染与展示

• 内部逻辑流程

  1. 首页加载流程：用户进入首页 → 前端发起「获取首页新闻列表」请求 → 后端接口校验参数 → 业务层按发布时间倒序查询已审核通过的新闻 → 过滤敏感内容、拼接分类名称 → 按分页规则返回数据 → 前端渲染首页新闻列表、轮播热点
  2. 详情页加载流程：用户点击新闻卡片 → 前端携带新闻 ID 发起「获取新闻详情」请求 → 后端校验新闻 ID 合法性 → 查询新闻详情数据 → 原子性更新新闻阅读量 → 校验新闻状态（已发布 / 已下架） → 返回详情数据 → 前端渲染新闻标题、正文、发布信息、相关推荐

• 算法设计：热点新闻排行采用「阅读量 ×0.7 + 发布时间权重 ×0.3」的加权排序算法，保证热点时效性；新闻搜索采用 MySQL 全文索引实现关键词模糊匹配

• 数据结构设计 ：

  // 新闻列表单条数据结构
  {
    newsId: 1001, // 新闻唯一ID
    title: "XX新闻标题", // 新闻标题
    cover: "https://xxx.com/cover.jpg", // 封面图地址
    summary: "新闻摘要", // 新闻摘要
    categoryId: 1, // 分类ID
    categoryName: "时政", // 分类名称
    author: "XX编辑", // 作者
    publishTime: "2024-05-20 10:00:00", // 发布时间
    readCount: 1024, // 阅读量
    likeCount: 120 // 点赞量
  }

• 接口设计（RESTful 规范）

  表格

  接口地址	请求方式	入参	出参核心内容	异常场景处理
  /api/news/list	GET	pageNum（页码，必填）、pageSize（每页条数，必填）、categoryId（分类 ID，选填）	状态码、提示信息、总条数、新闻列表数组	参数错误返回 400，分类不存在返回空列表，服务器异常返回 500
  /api/news/detail/{newsId}	GET	newsId（路径参数，必填）	状态码、提示信息、新闻详情完整数据	newsId 不存在返回 404，新闻已下架返回 403，参数非法返回 400

（2）核心模块 2：用户认证模块

• 模块职责：负责用户注册、登录、鉴权、密码加密、token 管理
• 核心逻辑流程：用户输入账号密码 → 前端校验参数合法性 → 发起登录请求 → 后端校验账号是否存在 → BCrypt 算法校验密码正确性 → 校验账号状态（正常 / 禁用） → 生成 JWT token 返回给前端 → 前端存储 token，后续请求携带 token 鉴权
• 核心设计：密码采用 BCrypt 不可逆加密存储，不存储明文密码；采用 JWT 无状态鉴权，token 有效期 2 小时；未登录用户自动拦截需鉴权的接口请求

（3）核心模块 3：新闻内容管理模块

• 模块职责：负责后台新闻的新增、编辑、删除、审核、上下架
• 核心逻辑流程：编辑登录后台 → 进入新闻编辑页 → 填写新闻标题、分类、封面、正文等内容 → 提交审核 → 超管 / 审核员进入审核页 → 查看新闻内容 → 审核通过 / 驳回 → 审核通过的新闻自动进入待发布队列，按设置时间发布，前台可展示

3. 数据库设计

严格遵循「概念设计→逻辑设计→物理设计」三阶段流程，贴合新闻业务场景。

（1）概念设计：E-R 图设计

核心实体识别 ：用户、新闻分类、新闻、评论、管理员实体属性与关联关系：

表格

实体	核心属性	关联关系
用户（user）	用户 ID、用户名、加密密码、昵称、手机号、注册时间、账号状态	1 个用户可发布多条评论（一对多）
新闻分类（news_category）	分类 ID、分类名称、排序号、创建时间、状态	1 个分类下包含多条新闻（一对多）
新闻（news）	新闻 ID、标题、封面、摘要、正文、分类 ID、作者 ID、阅读量、点赞量、审核状态、发布时间、创建时间	1 条新闻归属 1 个分类、1 个发布者；1 条新闻对应多条评论（一对多）
评论（comment）	评论 ID、新闻 ID、用户 ID、评论内容、父评论 ID、审核状态、评论时间	1 条评论归属 1 条新闻、1 个用户
管理员（admin）	管理员 ID、账号、加密密码、姓名、角色、创建时间、状态	1 个管理员可发布多条新闻（一对多）

（2）逻辑设计：数据表结构设计

将 E-R 图转化为关系型数据表，严格遵循数据库三大范式，消除数据冗余，明确主键与外键关联：

1. 用户表（user）：存储前台读者用户信息，主键user_id
2. 新闻分类表（news_category）：存储新闻分类信息，主键category_id
3. 新闻表（news）：存储新闻全量内容，主键news_id，外键category_id关联分类表，外键author_id关联管理员表
4. 评论表（comment）：存储用户评论信息，主键comment_id，外键news_id关联新闻表，外键user_id关联用户表
5. 管理员表（admin）：存储后台运营人员信息，主键admin_id

（3）物理设计：落地实现与性能优化

• 数据库环境：MySQL 8.0，存储引擎 InnoDB，字符集 utf8mb4（支持 emoji 表情），排序规则 utf8mb4_general_ci
• 字段精细化设计：主键均采用bigint自增，避免 int 溢出；文本内容采用text类型，短文本采用varchar并设置合理长度；非空字段均设置not null约束，设置合理默认值
• 索引设计：
  • 主键索引：所有表主键自动创建主键索引
  • 普通索引：新闻表category_id、publish_time创建联合索引，提升分类查询与排序效率；评论表news_id创建索引，提升新闻评论查询效率；用户表username创建唯一索引，保证用户名唯一
• 约束设计：设置外键约束保证数据一致性；设置唯一约束避免重复数据；设置检查约束保证状态字段取值合规。

4. 界面设计

以「用户为中心」，兼顾易用性、专业性与美观性，贴合新闻媒体的正式属性。

（1）前台读者端界面设计

• 整体布局 ：采用经典新闻网站三段式布局，适配 19201080 主流分辨率，向下兼容 1366 768 笔记本分辨率
  1. 顶部通栏导航区：左侧平台 logo，中间新闻全分类导航菜单，右侧搜索框、登录 / 注册 / 个人中心入口
  2. 首页主体区：
     • 顶部轮播区：4 张轮播图，展示当日热点头条新闻
     • 左侧主内容区（70% 宽度）：最新新闻列表、分板块展示时政、民生、体育、娱乐等分类新闻，每条新闻含封面、标题、摘要、发布时间、阅读量
     • 右侧侧边栏（30% 宽度）：24 小时热点排行、热门推荐、合规广告位
  3. 新闻详情页：顶部导航栏，主体左侧新闻标题、发布信息、正文内容，下方评论输入区与评论列表，右侧相关新闻推荐、热点排行
  4. 底部页脚：备案信息、版权声明、联系方式、免责声明
• 交互流程：用户进入首页 → 点击分类切换对应新闻列表 → 点击新闻卡片进入详情页 → 登录后可发布评论、点赞收藏 → 顶部搜索框输入关键词，跳转搜索结果页
• UI 样式：主色调采用深蓝色（体现新闻媒体的权威、正式），辅助色用浅灰色与红色；字体采用思源黑体，正文 14px，标题层级清晰（一级标题 24px、二级 20px、三级 18px）；页面留白充足，无视觉杂乱感，阅读体验舒适。

（2）后台管理端界面设计

• 采用经典后台管理布局：左侧固定侧边栏功能菜单，顶部导航栏（管理员信息、退出登录），右侧主内容操作区
• 核心页面设计：新闻编辑页集成富文本编辑器，支持图片、视频、段落格式编辑；新闻列表页采用表格分页展示，支持按分类、时间、审核状态筛选，操作栏含编辑、审核、上下架、删除按钮
• 交互逻辑：操作流程极简，所有核心操作不超过 3 步，操作结果有明确的成功 / 失败提示，降低运营人员操作成本。

---

三、后续实现与验收阶段（开发落地与长期维护）

1. 编码实现

严格按照详细设计文档进行开发，遵循前后端分离开发规范：

• 前端开发：搭建 Vue3 项目脚手架，封装全局组件、Axios 请求拦截器、路由鉴权，按页面模块实现布局与交互逻辑，完成接口联调
• 后端开发：搭建 SpringBoot 项目，采用 Controller-Service-Mapper 三层架构开发，实现接口逻辑、业务处理、数据库操作，统一异常处理、统一返回结果、权限拦截
• 编码规范：遵循《Java 开发手册》与前端 ESLint 规范，核心代码添加清晰注释，采用 Git 进行版本控制，分 dev（开发）、test（测试）、prod（生产）三个分支管理，禁止直接在生产分支编码。

2. 单元测试

由开发人员完成，采用白盒测试，聚焦单个模块、单个接口、单个函数的功能正确性：

• 后端测试：使用 JUnit 框架，对每个接口进行单元测试，覆盖正常流程、参数异常、权限不足、数据不存在等全场景，例如登录接口测试：正常登录、密码错误、账号不存在、账号禁用等场景
• 前端测试：使用 Jest 框架，对核心组件、工具函数进行单元测试，保证渲染正常、逻辑正确
• 核心要求：核心功能代码覆盖率≥90%，所有分支场景均完成测试，无隐藏 Bug。

3. 集成测试

聚焦模块间的协作与数据流，采用黑盒 + 白盒结合测试，验证模块间接口调用、数据交互是否符合设计要求：

• 核心测试场景：用户登录→发布评论→后台收到评论审核通知→审核通过→前台详情页展示评论；编辑发布新闻→提交审核→审核通过→前台分类列表展示新闻→用户点击阅读→阅读量正常更新
• 核心目标：验证跨模块的业务流程是否闭环，模块间耦合是否符合设计要求，接口联调是否无兼容性问题，数据流转是否正常。

4. 系统测试

完全模拟用户真实使用场景，以需求规格说明书为唯一基准，对完整系统进行全量测试：

• 功能测试：全覆盖需求文档中的所有功能点，验证每个功能是否符合预期，无遗漏、无偏差
• 性能测试：使用 JMeter 工具进行压测，验证 1000 人同时在线访问时，页面加载时间≤2s，接口响应时间≤500ms，无服务器宕机、内存溢出问题
• 安全测试：测试 SQL 注入、XSS 跨站脚本攻击、越权访问、密码明文传输等风险，验证系统安全性
• 兼容性测试：在 Chrome、Edge、Firefox 等主流浏览器中测试，验证页面无样式错乱、功能无异常
• 易用性测试：邀请测试用户进行真实操作，验证操作逻辑是否符合用户习惯，无操作障碍。

5. 上线部署

完成测试验收后，将系统发布到生产环境，正式对外开放访问：

1. 环境准备：完成域名备案、云服务器配置，服务器安装 CentOS 7、JDK1.8、MySQL 8.0、Nginx，配置防火墙、端口开放
2. 项目打包：前端项目打包生成 dist 静态资源包，后端项目打包成可执行 Jar 包
3. 部署上线：前端资源上传至服务器 Nginx 静态资源目录，配置 Nginx 反向代理；后端 Jar 包上传至服务器，后台启动运行；配置域名解析、HTTPS 安全证书
4. 上线检查：初始化数据库，验证数据库连接正常，页面可正常访问，所有接口无异常，功能完整可用
5. 发布方案：采用灰度发布，先小范围开放访问，验证无异常后，全量对外开放；提前制定回滚方案，出现重大问题可立即回滚至上一个稳定版本。

6. 运行维护

软件生命周期中时间最长的阶段，保障系统长期稳定运行，持续优化迭代：

• 纠错性维护：7×24 小时监控系统运行状态，及时修复线上出现的 Bug、页面异常、接口故障等问题
• 适应性维护：适配浏览器版本更新、服务器系统升级、数据库版本迭代，保证系统持续可用
• 完善性维护：根据用户反馈与运营需求，优化页面体验、新增功能模块、优化接口性能、提升系统并发能力
• 预防性维护：每日自动备份数据库，定期进行服务器安全巡检、漏洞修复、日志清理，提前预防服务器宕机、数据丢失、网络攻击等风险，保障系统长期稳定运行。

---

全流程核心输出物汇总（作业 / 考试 / 项目验收必备）

1. 项目分析阶段：《需求规格说明书》《可行性研究报告》
2. 程序设计阶段：《概要设计说明书》《系统架构图》《模块划分图》《详细设计说明书》《接口文档》《数据库设计文档》《E-R 图》《UI 原型图 / 高保真设计稿》
3. 实现验收阶段：项目源代码、单元测试用例、集成测试用例、系统测试报告、部署文档、用户操作手册、运维手册

第三部分，项目全阶段文档 / 图表 编写规范 + 核心注意事项

以下内容严格按照项目落地的先后逻辑排序，明确每个文档 / 图表的核心定位、标准编写框架、必守规则和新手避坑点，兼顾毕设 / 作业规范与企业级项目实战要求。

通用核心原则（所有文档必须遵守）

1. 边界清晰：明确区分「做什么」（需求分析阶段）和「怎么做」（设计阶段），严禁越界编写。
2. 一致性闭环：所有文档内容必须前后呼应，需求→设计→图表完全匹配，无遗漏、无矛盾。
3. 可落地、可验证：所有描述必须量化、无歧义，拒绝「体验好、性能高」等模糊表述，每个条目都能对应开发、测试、验收动作。
4. 版本管控：所有文档必须标注版本号、编写人、编写日期、修改记录、审核人，变更必更新版本。
5. 面向读者：给审批人看的文档重收益与风险，给开发看的文档重逻辑与细节，给测试看的文档重规则与验收标准。

---

一、项目分析阶段（立项锚定，先定「做不做、做什么」）

1. 《可行性研究报告》

核心定位

项目立项的核心审批依据，核心目标是论证「项目该不该做、能不能做成、值不值得投入」，只讲可行性判断，不涉及具体实现方案。

标准编写框架

1. 项目概述：项目背景、建设目标、核心价值、项目范围、建设周期、交付物清单
2. 市场与业务分析：业务痛点、目标用户群体、市场现状、竞品分析、项目必要性
3. 核心可行性论证（核心章节）
   • 技术可行性：技术栈选型、团队能力匹配度、现有技术支撑、技术风险与解决方案
   • 经济可行性：成本估算（人力、服务器、运维等）、收益测算（直接 / 间接收益）、投资回报率、成本回收周期
   • 操作可行性：用户使用门槛、团队执行能力、落地流程顺畅度
   • 法律与合规性：是否符合数据安全、个人信息保护、行业监管等相关法律法规
4. 项目实施计划：里程碑节点、人员分工、进度安排
5. 风险评估与应对：核心风险点、发生概率、影响等级、规避 / 应对措施
6. 结论与建议：明确给出「可行 / 不可行 / 暂缓」的结论，以及核心落地建议

关键注意事项

• 严禁只写「项目可行」，必须用量化数据支撑判断，比如技术可行性要明确「现有 SpringBoot+Vue 技术栈可完全覆盖需求，团队有 3 个以上同类型项目落地经验」，而非空泛表述。
• 必须明确项目边界，清晰标注「项目不包含的内容」，从源头规避后期需求蔓延。
• 风险不能只罗列，必须配套可落地的应对措施，无应对方案的风险描述无效。
• 经济测算必须贴合实际，严禁虚高收益、低估成本。

2. 《需求规格说明书》（SRS）

核心定位

项目开发、测试、验收的唯一法定基准文档，核心目标是把「用户的口语化需求」翻译成「开发可落地、测试可验证、验收可对标」的标准化需求，只讲「系统必须做什么」，绝对不写「怎么做」。

标准编写框架

1. 文档概述：编写目的、适用范围、读者对象、术语定义、参考文档、版本记录
2. 项目整体描述：业务背景、项目目标、目标用户、运行环境、约束条件（技术、时间、成本等）
3. 功能性需求（核心章节，按模块拆分）每个功能必须包含：功能编号、功能名称、适用场景、功能描述、输入规则、输出要求、业务规则、异常处理流程、前置 / 后置条件
4. 非功能性需求（可量化，验收核心依据）
   • 性能需求：接口响应时间、并发量、吞吐量、数据处理时长
   • 安全性需求：权限管控、数据加密、防 SQL 注入、防 XSS 攻击、日志审计
   • 兼容性需求：适配浏览器、操作系统、设备型号、版本范围
   • 易用性需求：操作步骤上限、页面加载时长、新手引导规则
   • 可维护性、可扩展性需求
5. 接口需求：与第三方系统、硬件设备的对接需求
6. 数据需求：数据存储、备份、恢复、归档要求
7. 验收标准：每个功能 / 性能指标的合格判定规则，可量化、可执行
8. 附录：需求优先级、需求变更流程、其他补充说明

关键注意事项

• 绝对禁止模糊表述，比如不能写「页面加载要快」，必须写「页面首屏加载时间≤2s，接口平均响应时间≤200ms」。
• 每个需求必须可验证，即能直接对应编写测试用例，无法测试的需求描述无效。
• 必须明确「不做的需求」，划定系统边界，从源头规避后期需求变更扯皮。
• 业务规则必须全覆盖，包括正常流程、分支流程、异常流程，不能只写主流程，忽略异常场景。
• 文档必须经需求方 / 用户确认签字，作为后续需求变更的基准依据。

---

二、程序设计阶段（落地实现，定「怎么做」）

本阶段遵循从宏观到微观、从整体到局部的逻辑：先定整体骨架（概要设计→架构图→模块划分图），再填落地细节（详细设计→接口文档→数据库设计→UI 设计）。

1. 《概要设计说明书》（HLD）

核心定位

系统的「整体骨架设计文档」，核心目标是搭建系统的整体技术体系，明确系统分层、模块划分、技术选型，衔接需求与详细设计，只讲「系统整体怎么组织」，不涉及模块内部的代码级逻辑。

标准编写框架

1. 文档概述：编写目的、适用范围、术语定义、参考文档、版本记录
2. 总体设计：系统目标、设计原则（高内聚低耦合、开闭原则等）、运行环境、整体技术栈选型
3. 系统总体架构设计：对应《系统架构图》，分层说明每层的职责、技术实现、组件组成、层间交互规则
4. 功能模块划分：对应《模块划分图》，明确一级模块、二级子模块的职责、边界、模块间的依赖与交互关系
5. 核心功能模块总体设计：每个核心模块的功能范围、输入输出、与其他模块的关联关系
6. 数据库总体设计：数据库选型、库表整体规划、核心业务实体关系
7. 接口总体设计：接口规范、鉴权方案、通用调用规则、内外网接口隔离方案
8. 通用方案设计：安全设计、异常处理通用规则、日志规范、缓存方案、部署架构
9. 性能、兼容性、可扩展性设计总体方案

关键注意事项

• 模块划分必须严格遵循「高内聚、低耦合、职责单一」原则，一个模块只负责一个业务域，严禁职责交叉。
• 必须 100% 覆盖《需求规格说明书》中的所有功能需求，无遗漏、无偏差。
• 只讲整体架构与模块边界，严禁深入模块内部的代码逻辑、具体算法，那是详细设计的范畴。
• 技术选型必须与《可行性研究报告》保持一致，重大变更必须补充说明与审批。

2. 《系统架构图》

核心定位

可视化系统的整体技术分层、组件组成、交互关系，让所有角色一眼看懂系统的技术架构，是概要设计的可视化配套文件。

标准写法与注意事项

• 主流类型：最常用分层架构图（用户端→前端层→网关层→应用服务层→数据持久层→基础设施层），配套可补充部署架构图、业务架构图。
• 核心规范：
  1. 分层逻辑清晰，从上到下遵循「用户请求→数据处理→数据存储」的完整链路，箭头标注明确的调用方向与通信协议（HTTP/HTTPS/RPC 等）。
  2. 每个组件必须标注名称、核心职责、技术选型，比如「前端层：Vue3 + Vite，负责页面渲染与用户交互」。
  3. 突出核心组件，区分核心链路与非核心链路，避免无关细节堆砌。
  4. 宏观视角，严禁画入单个类、单个接口等细粒度内容，保持架构的整体性。
• 避坑：不要和模块划分图混淆，架构图讲技术分层与组件关系 ，模块划分图讲业务功能拆分。

3. 《模块划分图》

核心定位

可视化系统的业务功能拆分结果，明确每个模块的职责、边界、父子层级与依赖关系，是概要设计的业务可视化配套文件。

标准写法与注意事项

• 主流类型：最常用树形结构图、UML 包图，按业务域拆分。
• 核心规范：
  1. 层级清晰，先拆一级业务模块，再拆二级子模块，比如一级模块「用户管理」，二级子模块「用户注册、用户登录、用户信息管理、权限管控」。
  2. 每个模块标注核心职责，明确模块边界，遵循职责单一原则，无功能交叉。
  3. 标注模块间的依赖关系，比如「订单模块依赖用户模块、商品模块」。
  4. 粒度适中，既不能一个模块包含所有功能，也不能一个功能拆成一个模块。
  5. 100% 覆盖需求中的所有功能，无遗漏。
• 避坑：不要把技术分层和业务模块混为一谈，严禁把「Controller 层、Service 层」和「用户模块、订单模块」放在同一层级。

4. 《详细设计说明书》（LLD）

核心定位

给开发工程师的「编码直接依据」，核心目标是把概要设计的模块拆解到可直接写代码的粒度，解决「每个模块内部具体怎么实现」的问题。

标准编写框架

1. 文档概述：编写目的、适用范围、术语定义、参考文档、版本记录
2. 通用设计规范：编码规范、异常处理规范、日志规范、公共工具类说明
3. 模块详细设计（核心章节，每个模块单独编写）
   • 模块概述：模块职责、依赖的其他模块、关联的需求编号
   • 类设计：UML 类图、类的职责、属性定义、方法定义、类之间的关系
   • 核心方法设计：方法名、入参 / 出参定义、权限修饰符、业务逻辑流程、伪代码、流程图
   • 核心算法设计：算法原理、实现步骤、输入输出、边界条件、效率说明
   • 异常处理：每个异常场景、触发条件、处理方式、错误码定义
4. 公共组件 / 工具类详细设计
5. 安全、性能、兼容性详细实现方案

关键注意事项

• 粒度必须细到「开发工程师可直接照着文档写代码，无需额外做逻辑设计」。
• 核心业务流程必须配套标准 UML 流程图，复杂逻辑必须补充伪代码，严禁纯文字描述。
• 必须和概要设计的模块划分完全一致，严禁私自新增 / 修改模块，变更必须有记录。
• 必须覆盖所有分支流程、异常场景，不能只写主流程，忽略边界条件与异常处理。
• 不强制绑定具体代码，优先写逻辑与流程，避免因语法迭代导致文档失效。

5. 《接口文档》

核心定位

前后端开发、第三方系统对接的唯一联调依据，核心目标是明确「接口怎么调用、传什么参数、返回什么数据」，是联调、测试、对接的核心文档。

企业级常用工具：Apifox、Swagger/OpenAPI、YApi，可同步生成在线文档与自动化测试用例。

标准编写框架

1. 文档概述：编写目的、适用范围、术语定义、版本记录
2. 通用规范：接口域名、请求协议、鉴权方式（Token/Sign 等）、通用请求头、通用响应结构、统一错误码字典、签名规则、数据格式规范
3. 接口详情（按模块分类，每个接口必填以下内容）
   • 基础信息：接口名称、接口路径、请求方式（GET/POST/PUT/DELETE 等）、接口版本、适用场景、接口负责人
   • 请求参数：路径参数、Query 参数、Header 参数、Body 参数，每个参数必须标注：参数名、字段类型、是否必填、默认值、校验规则、描述、示例值
   • 响应参数：整体响应结构、每个字段的参数名、字段类型、描述、示例值
   • 请求 / 响应示例：完整的成功请求示例、成功响应示例、失败响应示例
   • 异常说明：错误码、错误描述、触发场景

关键注意事项

• 全文档规范绝对统一：参数命名风格（驼峰 / 下划线）、请求方式、响应结构、错误码必须完全一致，严禁混用。
• 所有参数必须明确必填规则、校验规则，比如「手机号：char (11)，必填，必须符合 11 位手机号正则规则」。
• 必须覆盖所有异常场景，给出对应的错误码与处理方案，不能只写成功情况。
• 接口变更必须同步更新版本，记录变更内容，严禁私自修改已上线的接口，避免影响对接方。
• 鉴权规则必须写清 Token 的获取方式、存放位置、过期处理、刷新机制，无遗漏。

6. 《E-R 图》

核心定位

数据库概念设计的可视化文件，核心目标是梳理业务实体、实体属性、实体之间的关联关系，是数据库设计的核心依据，先画 E-R 图，再写数据库设计文档。

标准写法与注意事项

• 核心三要素：实体（矩形，对应业务对象，如用户、订单、商品）、属性（圆角矩形，对应实体的特征）、关系（菱形，标注 1 对 1/1 对多 / 多对多）。
• 核心规范：
  1. 每个实体必须有唯一主键标识，明确标注主键、外键属性。
  2. 实体关系必须精准：1 对 1（如用户与用户详情）、1 对多（如用户与订单）、多对多（如学生与课程，必须配套中间表）。
  3. 属性必须贴合业务，区分核心属性与非核心属性，无冗余、无遗漏。
  4. 命名无歧义，统一用中文标注，与需求中的业务对象完全匹配。
• 避坑：不要堆砌无关属性，重点突出实体与实体间的关联关系，而非全量字段罗列。

7. 《数据库设计文档》

核心定位

数据库建表、维护、数据交互的唯一依据，核心目标是明确每个库、每个表、每个字段的设计规则，是 DBA、开发工程师建表与数据操作的直接基准。

标准编写框架

1. 文档概述：编写目的、适用范围、术语定义、参考文档、版本记录
2. 数据库环境说明：开发 / 测试 / 生产环境的数据库信息、数据库选型、字符集、排序规则、命名规范
3. 库表整体规划：数据库名、核心表清单、表所属模块、表间整体关联关系
4. 表详细设计（核心章节，每个表单独编写）
   • 基础信息：表名、表中文名、所属模块、表说明、存储引擎、字符集
   • 字段详情：字段名、字段类型、长度、是否主键、是否外键、是否可为空、默认值、自动递增、约束规则、字段注释
   • 索引设计：索引名、索引类型（主键 / 唯一 / 普通 / 联合）、包含字段、索引说明
   • 表关系：与其他表的关联关系、外键规则
5. 视图、存储过程、函数设计（如有）
6. 数据字典：全量表字段汇总清单
7. 通用规则：创建时间 / 更新时间 / 逻辑删除字段规范、数据备份与恢复规则

关键注意事项

• 命名规范统一：表名、字段名推荐用小写 + 下划线，见名知意，严禁中文、特殊字符、关键字。
• 字段类型必须合理：手机号用 char (11)，状态用 tinyint，金额用 decimal（严禁用 float/double），时间用 datetime/timestamp，避免类型溢出与精度丢失。
• 强制通用字段：每个表必须有主键、create_time（创建时间）、update_time（更新时间）、is_deleted（逻辑删除标识），降低后期维护成本。
• 索引设计合理：查询频繁的字段建索引，联合索引遵循最左匹配原则，严禁过度建索引、无差别建索引。
• 字段注释必须完整清晰，尤其是状态字段，必须标注枚举值含义，比如status tinyint NOT NULL COMMENT '用户状态 0-禁用 1-正常'，严禁只写「状态」。
• 遵循数据库三大范式，减少数据冗余；互联网项目推荐用逻辑外键，不使用物理外键，避免联表更新的性能问题，需在文档中明确说明。

8. 《UI 原型图 / 高保真设计稿》

核心区分

• 低保真原型图：核心是确认功能布局、交互逻辑、页面跳转，给产品、开发、测试确认需求用，不纠结视觉样式。
• 高保真设计稿：核心是确定视觉规范、页面样式、尺寸配色，给前端开发做页面还原的标准，1:1 匹配最终上线效果。

低保真原型图 编写规范与注意事项

• 常用工具：Axure、墨刀、Figma
• 核心规范：
  1. 按业务流程梳理完整页面清单，覆盖所有功能的页面入口，无遗漏。
  2. 每个页面标注：页面名称、所属模块、页面元素、按钮功能、输入框规则、表单校验规则。
  3. 明确页面跳转逻辑，用箭头标注「点击什么元素、从哪个页面跳转到哪个页面」。
  4. 标注核心交互规则，比如弹窗、分页、下拉刷新、加载状态、空状态。
  5. 重点聚焦功能与交互，无需纠结配色、字体、样式，避免本末倒置。

高保真设计稿 编写规范与注意事项

• 常用工具：Figma、Sketch、PS
• 核心规范：
  1. 先制定统一的设计系统：配色体系、字体规范、组件规范（按钮、输入框、表格、弹窗等）、间距、圆角规范，保证全项目风格统一。
  2. 每个页面标注完整的尺寸、间距、色值、字体大小、字重、图标尺寸，前端可直接对标开发。
  3. 覆盖所有元素的状态：按钮的正常 /hover/ 点击 / 禁用状态、输入框的正常 / 聚焦 / 错误状态、列表的加载 / 空 / 异常状态。
  4. 明确屏幕适配规则，PC 端标注响应式规则，移动端标注不同机型的适配方案。
  5. 必须与原型图的功能、布局、交互逻辑完全一致，严禁私自修改功能。
  6. 配套提供完整切图，标注切图的格式、尺寸、适用场景。

---

新手避坑 TOP5

1. 边界混淆：需求文档写「怎么做」，设计文档写「做什么」，完全颠倒文档定位。
2. 粒度失控：概要设计写得太细，详细设计写得太粗，架构图、模块划分图画得过于碎片化。
3. 只写主流程：需求、设计、接口文档只覆盖正常场景，忽略异常流程、边界条件，导致开发出来的系统 bug 频发。
4. 文档不一致：需求变更后，未同步更新所有设计文档，出现需求与设计、接口与数据库、原型与设计稿相互矛盾的情况。
5. 模糊不可验证：大量使用「性能好、体验佳」等无量化标准的表述，无法用于开发、测试与验收，最终导致项目交付扯皮。