软件生命周期

  1. 立项
  2. 可行性分析+软件开发计划
  3. 需求分析
  4. 架构
  5. 编码
  6. 测试
  7. 项目上线
  8. 维护

立项

做什么东西

可行性分析

  1. 技术可行性
    • 用到哪些技术。如果某个技术是一部分功能会用到的，需要小组内一半人掌握才能使用；如果是所有代码涉及到的，需要全员掌握
    • 列举核心功能
    • 考虑核心功能能否实现
      1. 数据的设计
      2. 逻辑的描述

需求分析

  1. 需求文档
    • 界面划分
    • 界面描述
    • 功能分类
    • 功能概述
    • 优先级
    • 备注
  2. 流程图
    • 使用process on来制作流程框图
  3. 原型图
    • 使用墨刀。不要求一模一样，但数据、内容不能有遗漏
    • 注意设计时形成闭环（有a->b，就得有b->a）。

架构

  1. 什么是架构
    一个项目文件夹里放着数据的设计、函数的声明。
    要求注释详细，函数声明、功能、参数、返回值清晰

  2. 为什么要有架构

    • 明确分工：谁负责哪块代码，出了问题联系谁
    • 技术分配：不同人擅长不同的地方
    • 代码分层：view层与service层（UI与实现相互分离），即接受输入->逻辑判断、修改->程序输出

  3. 搭建架构的最低前提

    • 熟悉用户操作流程、程序运行流程
    • 单人写，择优
    • 可在一开始只写核心功能，后来再完善

编码

  1. 整合
    • 每天进行整合，以函数为单位在git上提交
    • 讲进度、讨论问题、安排拓展架构的分工
    • 布置某项任务时的格式
      • 内容：
      • 负责人：
      • 截止时间
      • 提交方式
      • 接收人

测试

小项目，无需测试工具，便在本地测试

开发过程

  • 9-20：产品经历逐个点评原型图；副组长问大家C语言的掌握程度；大家评判的是用Console还是用EasyX来做。
  • 9-21：副组长确定每个人的安排，但他刚说完自己就记不清了。得事先写好，不能想到哪，说到哪。
  • 9-22：我发布了我写的架构，并让大家提出意见
  • 9-23：我做了个简易五子棋，验证架构可行性，因为自己第一次写架构
  • 9-24：整合代码，开会讨论
  • 9-25：整合代码，开会讨论
  • 9-26：实现了落子，增加了“当前黑|白子”与“当前局数”的功能
  • 9-27：没归零map数组，导致判断胜负出问题，已改正。我以为“五子紧密相连为胜”，实际上“中间隔着空气”也可以。产品经历提出意见，我一开始没听明白，他也不说了，我也不问了，这是大忌！
  • 9-28：美化了UI
  • 9-29：答辩，给出以下评价
  1. 布局清晰，颜色分明，细节到位
  2. 代码注释太少
  3. 有的人没看到我封装的button函数->通知不到位
  4. 路演PPT有待规范

获得了83.5分，7/20的排名。

404