软件开发流程

传统瀑布流

  1. 项目规划阶段:

    • 定义项目的时间表和里程碑。
    • 确定团队成员的角色和职责。
    • 分配资源和预算。
  2. 需求分析阶段:

    • 产品经理与客户/用户沟通,收集需求,明确项目目标和范围。
    • 确定功能和特性,创建产品需求文档(PRD)或用户故事。
  3. 设计阶段:

    • 进行系统设计,包括数据库设计、架构设计等。
    • UI/UX设计,确定用户界面和交互方式。
    • 确定技术栈和开发工具。
  4. 开发阶段:

    • 开发人员根据设计阶段的规划进行编码。
    • 进行单元测试和集成测试,确保代码的质量和稳定性。
    • 可能采用敏捷开发方法,进行迭代开发。
  5. 测试阶段:

    • 进行功能测试,验证软件是否符合需求。
    • 进行性能测试,确保系统的性能满足要求。
    • 进行用户验收测试(UAT),由客户或最终用户验证软件是否符合预期。
  6. 发布和部署:

    • 部署软件到生产环境。
    • 监测系统运行情况,确保正常运行。
  7. 维护和优化:

    • 监控和处理可能出现的问题和漏洞。
    • 根据用户反馈和需求变化,进行持续优化和更新。

项目规划阶段

在项目规划阶段,我们将完成以下具体的任务:

  • 定义项目的时间表和里程碑

    • 制定项目的时间计划,确定项目的起止日期,安排项目各个阶段的开始和结束时间。
    • 设定项目的里程碑,这是项目重要阶段或目标的关键时间点,用于衡量项目进展。
  • 确定团队成员的角色和职责

    • 根据项目的需求和范围,确定项目团队的组成,明确团队成员的角色和职责。
    • 任命项目经理,并确定其他关键团队成员,如技术专家、项目管理员等。
  • 分配资源和预算

    • 确定项目所需的资源,包括人力资源、硬件设施、软件工具等。
    • 编制项目预算,明确项目的经费来源和开支计划。

需求分析阶段

  • 需求收集:

    • 产品经理或业务分析师与客户、最终用户进行沟通,了解他们的需求、期望和问题。这可能包括面对面会议、电话交流、在线调查等方式。
    • 需求收集也可以通过用户反馈、市场调研、竞争分析等途径获得。
  • 需求澄清与整理:

    • 收集到的需求可能会比较零散,需求澄清阶段的目标是对需求进行整理和归类,确保清晰、一致。
    • 将需求划分为功能性需求(软件需要完成的具体功能)和非功能性需求(关于性能、安全性、可靠性等方面的要求)。
  • 需求分析与建模:

    • 通过不同的方法,如数据流图、用例图、流程图等,将需求进行建模和分析,帮助开发团队更好地理解需求。
    • 建模也有助于发现需求之间的关联和冲突。
  • 需求验证:

    • 在需求分析阶段,需求验证是至关重要的一步。验证需求是否准确、完整、一致,并与客户或用户进行确认,以避免后续开发阶段出现问题。
    • 通过原型演示、会议讨论等方式进行需求验证。
  • 需求文档编写:

    • 将分析和验证后的需求整理成具体的需求文档,例如产品需求文档(PRD)或用户故事。
    • 需求文档应该包含详细的功能描述、用户界面设计、用例场景等信息,确保开发团队理解需求细节。
  • 变更控制:

    • 在需求分析阶段,需求可能会因为客户或用户的反馈而发生变化。因此,要确保变更有明确的控制和管理,避免频繁的需求变更对项目进度和成本造成影响。

产品需求文档(Product Requirements Document)

数据流图

数据流图是一种用于描述系统中数据流动和处理过程的图形化工具。它由一系列符号和箭头组成,表示不同的数据流、数据处理和数据存储。

数据流图的基本符号

  • 工程示例 :工厂订单报表
    假设一家工厂的采购部每天需要一张订货报表,报表按零件编号排序,表中列出所有需要再次订货的零件。对于每个需要再次订货的零件应该列出下述数据:零件编号,零件名称,订货数量,目前价格,主要供应者,次要供应者。零件入库或出库称为事务,通过放在仓库中的设备把事务报告给订货系统。当某种零件的库存数量少于库存量临界值时就应该再次订货。

    分析

绘图

- 顶层抽象图


- 下层 对顶层的具象化

UML用例图

1. 实体类的定义

  • 实体类的名字为首字母大写
  • 属性
可见性 名称:类型 = 缺省值 {约束特性}
- admin:String='admin'
  • 私有 -
  • 保护 #
  • 公有 +
  • 方法
可见性 名称(参数表):返回类型表达式{约束条件}
+ login(admin:String,password:String):Boolean
  • 私有 -
  • 保护 #
  • 公有 +

2. 类之间的关系

  • 泛化(子类对于父类的继承关系 箭头指向父类)

  • 实现(实体类对于接口类的实现 虚线箭头指向接口)

  • 关联(比较弱的关系 单向实线或者双线实线)

    数字表示 一对多的关系 学生有多个老师 老师有多个学生

  • 聚合(部分与主体的关系 并且可以独自存在)

  • 组合(部分与主题的更加强烈的关联关系,部分不能离开主体)

  • 依赖(一种使用关系)

流程图

流程:是指特定主体为了满足特定需求而进行的有特定逻辑关系的一系列操作过程,流程是自然而然就存在的。但是它可以不规范,可以不固定,可以充满问题。

图: 是将基本固化有一定规律的流程进行显性化和书面化,从而有利于传播与沉淀、流程重组参考。

泳道图

流程图是描述一个事件过程的步骤,当这个过程涉及许多不同人、不同部门或不同功能区域时,很难跟踪每个步骤的负责人。解决此问题的有效方法是用泳道图把流程图分栏,这样能清晰地了解任务转交的流程。

  • 示例

设计阶段

在设计阶段,我们将完成以下具体的任务:

  • 系统设计

    • 确定系统的整体架构和组成,选择适合项目的架构模式,例如分层架构或微服务架构。
    • 设计系统所需的数据库结构,包括数据表、关系和字段定义,以支持数据的存储和访问。
    • 定义系统各个模块之间的接口和交互方式,确保模块之间的协作和通信。
  • UI/UX设计

    • 设计系统的用户界面(UI),包括布局、颜色、图标等,以提供美观的用户界面。
    • 关注用户体验(UX),优化用户界面的交互方式,以提高用户满意度和易用性。
  • 技术栈和开发工具的选择

    • 根据项目需求和目标,选择合适的技术栈,包括编程语言、框架、库和其他技术组件。
    • 选择适用于团队和项目的开发工具,包括集成开发环境(IDE)、版本控制系统等。
  • 详细设计文档

    • 将设计阶段的所有内容整理成详细的设计文档,包括系统设计、数据库设计、UI/UX设计和技术栈选择等内容。
    • 确保设计文档对项目的开发提供了清晰的指导和要求,以便团队成员能够有条不紊地实现系统功能。

开发阶段

在开发阶段,我们将完成以下具体的任务:

  • 编码实现

    • 开发人员根据设计阶段的详细设计文档,开始进行编码工作。根据系统架构和模块设计,实现各个功能模块的代码。
    • 遵循编程规范和标准,以保持代码的一致性和可读性。
  • 单元测试和集成测试

    • 进行单元测试,测试每个功能模块的独立性和正确性。
    • 进行集成测试,将各个功能模块整合在一起,确保它们之间的协作和交互正常,同时验证系统的整体功能。
  • 持续集成和持续交付

    • 采用持续集成和持续交付的方法,将代码频繁地集成到主干分支,确保代码的稳定性和可靠性。
    • 实现持续交付,使得软件可以在任何时候进行部署和交付,降低了软件发布的风险。
  • 代码审查和质量保证

    • 进行代码审查,通过同行评审,发现潜在的问题并改进代码质量。
    • 保证代码的质量和可维护性,有助于减少后期的错误和维护成本。
  • 问题解决和改进

    • 及时解决开发过程中出现的问题和挑战,确保项目按计划顺利进行。
    • 持续改进和优化代码和流程,提高开发效率和软件质量。

测试阶段

在测试阶段,我们将完成以下具体的任务:

  • 冒烟测试

    • 冒烟测试不会深入测试所有功能细节,而是重点关注最重要的功能,以迅速发现潜在的严重问题。如果冒烟测试通过,测试团队将会进行更详细的功能和系统测试,以确保软件的所有方面都符合预期。
  • 功能测试

    • 进行功能测试,验证软件是否符合需求,确保各项功能按照规定的要求正常运行。
    • 编写测试用例,覆盖各个功能模块,确保软件的功能完备性。
    • 执行测试用例,记录测试结果并跟踪解决问题,确保软件的功能正确性和稳定性。
  • 性能测试

    • 进行性能测试,评估系统的性能指标,如响应时间、吞吐量和并发用户数,确保系统的性能满足要求。
    • 使用性能测试工具模拟多种负载情况,确定系统在高负载下的表现,并进行性能优化。
  • 用户验收测试(UAT)

    • 进行用户验收测试,由客户或最终用户验证软件是否符合预期,是否满足实际业务需求。
    • 收集用户的反馈意见和建议,对系统进行必要的调整和改进。

发布和部署

在发布和部署阶段,我们将完成以下具体的任务:

  • 部署软件到生产环境

    • 将经过测试的软件部署到生产环境,确保软件能够在真实的运行环境中正常工作。
    • 配置服务器和网络环境,确保软件的顺利部署和运行。
  • 监测系统运行情况

    • 监测系统在生产环境中的运行情况,包括系统的性能、稳定性和安全性。
    • 建立监控系统,及时发现和解决可能出现的问题,保障系统的持续运行。

维护和优化

在维护和优化阶段,我们将完成以下具体的任务:

  • 监控和处理问题和漏洞

    • 持续监控系统运行情况,及时发现并处理可能出现的问题和漏洞,确保系统的稳定性和安全性。
    • 设立问题解决流程,快速响应和解决用户报告的问题。
  • 持续优化和更新

    • 根据用户反馈和需求变化,进行持续优化和更新,改进系统的功能和性能,以满足用户的不断变化的需求。
    • 定期进行系统维护,优化数据库性能,清理无用数据,确保系统的高效运行。

敏捷开发 SCRUM

三大要素

传统瀑布流

  • 活动
    • 计划 需求 设计 实现 测试 发布
  • 角色
    • 项目经理 设计师 程序设计 测试 维护
  • 产物
    • 项目计划 需求文件 分析设计文件 代码 测试用例 最后的产品

SCRUM中三大要素

  • 活动 (四种会议) 强调沟通
    • 计划会议 Sprint Planning Meeting
    • 每日站立会议 Daily Scrum Meeting
    • 展示会议 Sprint Review Meeting
    • 回顾会议 Sprint Retrospective Meeting
  • 三种角色 全功能
    • 产品负责人 PO
      • 代表着客户
      • 当团队中的人员出现需求的问题时,将和PO沟通
      • 决定着团队的方向
    • 团队 Team 并不区分职责 全职能
    • Scrum Master
      • 保证团队所有人员都遵守这Scrum的规范 并且排除一切影响Scrum规范的因素
      • 负责减少团队受到的外来干扰
  • 三种产物 需求第一
    • 产品待办
      • Product Backlog
    • 冲刺待办
      • Sprint Backlog
    • 增量
      • 潜在可交付

Scrum将传统瀑布流中认为一次就可以完成的活动, 进行了迭代处理

Scrum process剖析

用户故事

  • 一个好的用户故事包括以下几个部分
    • 角色:使用者
    • 功能:需要完成什么样的功能
    • 价值:为什么需要这个功能,将带来什么价值
  • 用户故事应该遵循3C标准(Card,Conversation,Confirmation)
  • card
    • 描述用户故事的小卡片
    • 召集3-5名对于产品非常熟悉的人员参与,并按照规则进行书写产品应该做到事情
    • 收集所有的小卡片,由po整理

需求 PB 与工作解析

  • 用户的所有需求都通过Product Owner管理,PO可以进行需求的提出与修改,删除,并有一下两个会议,
    注意: 一个用户故事的大小和复杂度应该在一个迭代中开发完毕为宜。如果做计划时发现有些任务的时间超过了8小时,就说明任务的划分有问题,需要进行子任务的分解。(数据表明加班只在Sprint开始与结束时有些效果)
  • 发布计划会议:product owner负责讲解user story,对其进行估算和排序,发布计划会议的产出就是制定出这一期迭代要完成的story列表,sprint backlog。 ——用户故事确认
  • 迭代计划会议:项目团队对每一个story进行任务分解,分解的标准是完成该story的所有任务,终每个任务都有明确的负责人,并完成工时的初估计。 ——用户故事分解
  • 当sprint backlog被确定后再开发过程中就不能出现修改

开发测试除错

  • daily scrum

    • 前一天的工作内容 对团队项目有贡献的
    • 工作中的困难 有团队共同解决或者Scrum master进行解决
    • 决定今天的任务
    • 目的在于让所有的成员了解当前团队进度
  • 测试阶段

    开发期间外界人员只能通过Scrum Master和团队接触,尽量减少外界对团队的干扰

回馈 内部成员回馈

  • 增量的产出
    • 客户的反馈
    • 团队成员的回馈
  • 演示会议
    • Sprint Review: 在Sprint Review会议中,开发团队向相关的利益相关者(包括产品负责人、客户等)展示已经完成的工作成果。这是一个机会,让团队展示在该Sprint中交付的功能,接收反馈,并讨论项目进度和产品的未来方向。在Sprint Review期间,利益相关者可能提出新的想法或提供有关产品的新需求。
  • 回顾会议
    • Sprint Retrospective: Sprint Retrospective会议旨在帮助团队回顾刚刚结束的Sprint。在这个会议上,团队成员讨论他们的工作流程、合作方式、遇到的问题和解决方案。通过这个过程,团队可以找到改进自己工作的方法,以提高效率和团队表现。

结束Sprint

如果在Sprint Review或Sprint Retrospective会议中提出了新的用户故事或新的需求,这些需求通常会被记录在产品待办列表(Product Backlog)中。产品待办列表是一个优先级排序的需求清单,其中包含了所有的用户故事、功能和其他项目需求。在每个Sprint规划会议之前,产品负责人会与开发团队一起回顾产品待办列表,并确定下一个Sprint中要包含的工作项。

Scrum产物

posted @   AIxuexiH  阅读(104)  评论(0编辑  收藏  举报
相关博文:
阅读排行:
· DeepSeek “源神”启动!「GitHub 热点速览」
· 微软正式发布.NET 10 Preview 1:开启下一代开发框架新篇章
· C# 集成 DeepSeek 模型实现 AI 私有化(本地部署与 API 调用教程)
· DeepSeek R1 简明指南:架构、训练、本地部署及硬件要求
· 2 本地部署DeepSeek模型构建本地知识库+联网搜索详细步骤
点击右上角即可分享
微信分享提示