当mentor给了一个大需求,怎么用软件工程思维解决

背景

最近老师给了一个比较大的需求:现在每间教室可以通过系统控制开关门,然后给当前的系统添加一个功能,每间教室每个电闸加一个plc来控制开关,plc和pc端都由我们写。但是我们一点都不会plc,且这个需求还挺大的,属于第三方也得我们设计。如果没有规划一定会乱成一团。接下来看一下怎么用软件工程的思想来规划。

软件工程的思想

需求分析(重要)

任务:搞清楚"软件要解决什么问题,有什么功能和非功能约束"。

产出:需求规格说明(哪怕是一页纸的列表)。

可行性研究阶段(重要)

任务:找出技术难点,评估是否可行。

产出:一个可以跑通流程的小demo。

设计(重要)

任务:确定"软件的内部怎么搭",包含架构、模块划分、接口、数据结构。

产出:架构图,用例图,流程图,时序图,甘特图等

实现(编码)

任务:把设计翻译成机器可执行的代码。

原则:遵循编码规范,进行必要的单元测试(常与实现穿插)。

测试

任务:验证软件符合需求,发现并修复缺陷。

产出:

单元测试:测试单个函数/类(如"写单个线圈"函数超时后是否正确抛出异常)。

集成测试:测试模块间的交互(如业务层调用通信模块,用仿真器看链路是否通)。

系统测试:端到端测试整个系统(点界面按钮 → 仿真器点状态变 → 界面更新)。

部署与维护

任务:把软件交付到运行环境,并持续修复问题、做适应性修改。

实例

需求分析

一、业务背景与目标

• 现状:现有系统已能通过PC端远程开关教室门。
• 新需求:将每间教室的每个电闸纳入系统管理,通过PLC实现本地与远程双重控制。
• 核心目标:系统能够可靠、安全地控制教室电闸的通断电,并严格遵守手动优先的安全原则。

二、系统边界与角色

• PC端(由我们开发):作为上位机,负责下发控制指令、显示电闸实时状态、记录操作日志。
• PLC(由我们开发):作为下位机,负责接收PC指令、检测本地开关信号、执行控制逻辑、驱动电闸动作。

• 用户角色:

  系统管理员:使用PC端界面,在自动模式下远程控制电闸。
  现场运维人员:使用PLC柜的物理开关,在手动模式下本地控制电闸(用于检修、应急)。
  老师:临时使用教室/换教室手动控制电闸
  

三、功能性需求分析

1. plc的触点:

    输入:3+ n, 输出: n.(n为电闸的开关数量)。

   说明:

    输入: 自动/手动模式, 上电, 下电, 辅助点位(判断每个开关到位没有)。
    输出:开关电闸的实际触点。
   

2. 手动/自动模式切换与控制权

   切换方式:由PLC柜门上的硬件钥匙旋钮或拨动开关实现,该信号为最高优先级。

   手动模式:

    PLC完全忽略来自PC端的所有开/关指令。
    电闸仅受本地"上电"按钮和"下电"按钮控制。
    按钮操作建议为点动逻辑:按下"上电",电闸合闸;按下"下电",电闸分闸。
   

   自动模式:

    PLC完全忽略本地按钮操作。
    电闸仅受PC端通过通信协议下发的指令控制上下电。
    模式切换时的状态处理(重要):切换状态时时,电闸保持当前状态不变,直到PC端发出新指令才改变。这避免了模式切换导致意外跳闸。
   

3. 电闸控制逻辑

   PC端指令:采用"开"和"关"两个独立的脉冲指令。

   PC写入"开"命令后,PLC输出一个500ms的脉冲来驱动合闸,随后自动复位。同样,"关"命令输出一个脉冲来驱动分闸。

   指令保护:

    若电闸已处于合闸状态,再次收到"开"指令,PLC应忽略(防止反复动作)。
    若电闸已处于分闸状态,再次收到"关"指令,同样忽略。
    反馈机制:电闸的真实状态必须通过辅助触点(或电流检测)反馈给PLC,PLC再将此真实状态上传给PC端,而不是简单回传"指令已执行"。
   

4. 安全互锁

   掉电重启安全:PLC断电重启后,所有电闸应默认处于"分闸"状态,直到收到新指令或手动操作。

5. 状态显示

   PC端界面需要实时显示每间教室每个电闸的:

    当前控制模式(手动/自动)
    电闸真实状态(合闸/分闸)
    通信状态(正常/中断)
   

   当处于手动模式时,对应电闸状态显示置为未知。

四、非功能需求分析

1. 性能
   响应延迟:从PC端发出命令,到PLC输出驱动脉冲,耗时 ≤ 500ms(不含网络正常时延)。

   状态刷新:PC端以 ≥1次/秒 的频率轮询所有PLC的状态数据。

2. 可靠性
   通信中断:若PC与PLC持续3秒无有效通信,PLC保持所有电闸当前状态,不自动改变。PC端需弹窗告警并尝试重连。

   重连机制:PC端检测到断线后,每5秒自动尝试重连,连接恢复后自动开始轮询,但不会自动补发断线期间的指令。

   上电初始化:PLC上电后,所有电闸控制输出强制为"分闸"状态,直到收到有效指令。

3. 安全性
   绝对手动优先:硬件手动模式时,软件没有任何途径可以控制电闸。

   操作确认:PC端合闸/分闸操作,需弹出二次确认对话框。

   日志记录:所有远程操作必须记录操作时间、操作人、目标电闸、操作结果。

   plc辅助触点异常: 触发报警系统。

4. 可扩展性
   协议设计应支持按教室和电闸序号线性扩展,新增教室只需增加对应的地址映射,无需改动程序逻辑。

五、假设与约束

以下为本次分析的假设前提,若实际情况不符需立即调整设计:

电闸本体具备电气保持或机械自锁机构,不需要PLC持续输出保持信号。
电闸提供无源辅助触点用于状态反馈。
PLC与PC处于同一个局域网,无跨网段或NAT穿透需求。

可行性研究

需要攻克的难点通常是一个表格:

当然也得写一个小demo。

设计

er图

这里仅展示一部分,这个图就是指导数据库构建。
deepseek_mermaid_20260603_6f5370.png

架构图

这个图大概是为了参与人员大致有一个数据流通的模型参考。
deepseek_mermaid_20260604_832069.png

原型图

此处略,由于画的不好看。这个图主要就开发人员和甲方(老师)看的。根据前台UI,应该有哪些改动。对应当前需求肯定有plc的增删改查页面。

用例图

这个用例图有点不标准,用户应该是人的图标。用例图主要是为了告诉我们有多少中具体情况。用事件驱动接下来的开发。
deepseek_mermaid_20260603_d71b76.png

流程图

这个图主要是给开发人员看的,给编程提供指导。
plc切换状态流程图:
plc状态切换图.png

自动上电流程图:
上电流程图.png

实现

在编码部分应该用自己的编程思想根据流程图进行编程。

测试

根据软件工程中的等价类划分、边界值分析、决策表、状态转换图方法根据用例图和流程图进行编写。

总结

可以看到运用软件工程思想去分析一个大的需求后,思路清明了许多。总结完之后,也需要重头到尾去看一遍,看看哪一块是不通的,实际上,本文章写的方案不一定是对的,但至少构建了一个大体框架。一个项目往往是从零到一的步骤是比较关键的,本文仅展现思路,内容不做参考。

写在最后

希望这篇文章对你有用。