2020ASE第二次博客—由需求分析来看软件开发的挑战
由需求分析来看软件开发的挑战
前言
这篇博客的主题是：由需求分析来看软件开发的挑战。那么问题来了，软件开发的挑战到底在哪些地方，在需求分析阶段又是如何体现的？借着刚结束的需求分析评审，我打算结合自己这段时间的课程经历回答一下这个问题。
领域分析
“领域分析！！！领域分析是什么？”第一次听说这个名词时，我感到很诧异，软件工程里有这么一环吗？遂查阅了一下，领域可以以如下三种形式描述：
- 一组或一族相关系统，所有这些系统共享一种能力和 / 或数据集。
- 具有相同需求的一个应用程序族描述的问题空间。
- 一个问题或任务领域，在其中可以开发出多重高度相似的应用系统，以满足各种不同用户的特定需求。
上面的不同描述形式说明了领域的基本组成成分是相关系统，所有这些系统间存在某种依赖关系，来实现一个共同的目标，综合以上定义，领域的一个描述性定义如下:
领域是由具有相同需求的一组或一族相关系统所组成的，是为重用的系统开发和基于重用的系统开发所形成的系统仓库。
所以领域分析要回答的问题是:
- 系统的核心价值是什么？
- 系统的范围包括哪些方面？
- 系统涉及的核心数据有哪些？
从领域分析报告模板里也可以看出这一点：
于是我们小组就按照上述条目分工，大家就吭哧吭哧做自己的部分；做完之后小组开会讨论的时候，发现大事不好，小组五位成员就有五个版本，特别是在术语方面体现得最为明显，大家显然都有自己专属的命名方式；后来经过大家长时间的讨论与磨合，终于，最初的一个版本出来了，经过老师的评审反馈，我认为领域分析报告中体现出了两个大问题：
- 对领域系统定义模糊不清，不够确切；
- 对系统的核心价值定位不准。
针对以上过程中出现的问题，小组做了两个方面的改进：
第一，合作模式的变化，在分析设计阶段小组遵循这样的模式：
- 小组讨论，确定大框架
- 成员分工，细化小细节
- 小组开会，互相评审
- 迭代优化，直到到达目标效果
第二，自我定位的变化：
我们发现，如果把自己看作成创业者，自己的小组看成一个创业团队，把自己的项目（领域分析模型、需求分析模型）看成要去融资的项目，用这个视角来看的话，我们对项目的核心价值的认识又有了新的发现，对系统涉及到的角色的特点，与其利益相关最大的地方才是这个系统最大的价值。
需求分析
通过与我们的天使投资人--吴老师的讨论，我们发现，给客户提供便利廉价的一条龙产品服务，给家庭工厂带来持续稳定的订单，是所需系统的核心价值，也是最重要的卖点。
根据这一指导思想，小组对需求模型进行了优化与改进，在满足核心价值的基础上充分考虑实际运行过程中可能存在的问题，以期设计出尽可能完美的模型，规避尽可能多的风险。当然我认为最出彩的地方便是，将生产任务分配给家庭工厂时，并没有采用一成不变的静态分配模式，也没有采用风险系数极高的抢单模式，而是别出心裁的提出了意愿值这个概念，既能容纳家庭工厂生产能力波动的实际情况，又能最大可能规避订单无法顺利完成的风险。
当然类图和用例图也对很对地方都进行了对应的优化，当我们对系统有了更清晰的认识时，类图也就更加完整和准确了。
软件开发的挑战
从软件开发的过程和整个过程设计到的人员来看，当今软件开发中面临的挑战主要有以下方面：
- 开发模式，瀑布型、迭代型、螺旋型，针对某一特定问题，哪一种才是最高效的开发模式？
- 软件工程的可视化管理，如何对开发模式的各个阶段进行管理，合理掌控全局？
- 团队开发与合作，团队容量与团队配置，以及如何分工和合作？
从领域分析和需求分析过程开看，可以勉强回答第一个和第三个问题。
- 瀑布模式每一阶段明确定义哪些工作及可交付物，允许少量反馈、修改、重叠；
- 迭代模式：是n个小瀑布模式，每一迭代周期短，可接受的需求变化空间大；
- 螺旋模式： 每一个活动都有三个部分组成：定义目标、方案、限制； 评估风险；验证并执行；
显然对于那些需求固定，并不容易发生更迭的项目而言，瀑布模式是相对来说比较适合的；而对于适用周期短，迭代频率快，后两种方式往往能表现出更好的效果。简言之，需求变更的频率一定程度上决定了不同的开发模式；
对于团队开发和协作中的挑战，我认为对于不同的阶段可以采取大致这样的模式，总览--分工--评审--分工--评审，总览，团队整体对项目或者问题有一个最基础的共识；分工，根据团队成员技术栈进行分工；团队成员互相评审，或者不同团队之间互相评审，之后便重复分工、评审的过程，直到达到目标效果。
最后
感谢各位认真靠谱的队友们，从到到尾都可以协调时间来线下会议进行小组讨论。
