![0f5e29e5e5b5c06b2bd725101545cf29.png](https://img-blog.csdnimg.cn/img_convert/0f5e29e5e5b5c06b2bd725101545cf29.png)
开发软件最少需要三种不同立场的角色来共同协作完成:客户、开发人员和测试人员。
一般来说,通常是由客户方(产品负责人或者是需求分析师)来决定需求,制定需求分析报告、开发验收测试和设定将要开发功能的优先级。软件开发人员专注于实现客户的需要并确保实现的代码能够满足验收测试的要求。测试人员关注于帮助客户创建验收测试并帮助开发人员通过哪些测试。
这些角色和职责体现了关注点分离的特点。
在传统而经典的软件开发流程瀑布模型中,一般是从客户提出需求开始,接着分析需求并检查分析结果与初始需求的一致性,并且确保开发人员能够理解该需求的实际含义。
开发人员创建设计规范来描述如何实现这个需求,编写实际的软件代码来实现那些设计规范,并将完成的后可运行测试的代码交付给测试人员。
测试人员阅读需求文档,接着创建一些功能测试用例来验证这一程序是否满足需求,或者需要修改返工,最终当程序满足了预期的结果并通过了诸如性能与稳定性测试,那么就可以准备发布部署了。
在理想的情况下,上述开发流程会线性的逐一完成,但是实际情况是残酷的,由于沟通误解,说了什么和听到什么往往南辕北辙导致产生交流障碍,由此也就产生了错误,而由于错误的追溯和修改需要回溯多个线性步奏,增加了项目成本,更为可能的是由于理解有误增加了不需要的功能被添加到系统中,使得系统繁杂臃肿,难易维护。
为了减少沟通障碍,降低浪费,更为敏捷的提供对客户有价值的软件产品,软件开发界又推出了敏捷开发流程,该流程强调以交付和迭代为核心的方法(包含确定优先级、最小化可行产品MVP,及时获取反馈),让软件产品在实际环境中去工作并迭代得到实际需求。
“这种架构(敏捷)之所以奏效,原因很简单,因为我看到的是人们实际上怎么工作的,而不是他们嘴上宣称自己是如何工作的!”— 敏捷领袖 杰夫·萨瑟兰
看完了外界软件开发的现实状况,再回到我们身边实际的LabVIEW开发过程中,不管是瀑布式线性模式,还是敏捷迭代式的模式都很少采用,因为一般使用LabVIEW作为开发工具的工程师们都是个人独狼式的开发方式居多。
![d9023dce66419135f74d8f5c427a1c65.png](https://img-blog.csdnimg.cn/img_convert/d9023dce66419135f74d8f5c427a1c65.png)
该方式无需与他人进行沟通和协作来共同开发软件产品,往往是一人身兼数职:自己开发程序代码(开发人员角色),满足自己使用需求(客户角色),开发文档和需求文书则基本上没有,依仗着脑子好—全都记在心中,日常实际工程使用代替了测试。
类似于运动员的以赛代练(测试人员角色),应用过程中发现问题有时间就自己改,没时间就纯手工补救一下