从需求分析看软件开发的挑战

一、至今为止的工作

---

1.1、讨论与分析

　　至今位置，本组进行了多次高强度的线下小组讨论，对这一题目的需求有了较为精准的理解。最初拿到“基于家庭工厂的订单协作系统”这一题目时，我们五位组员对这一标题各有一些自己的简单遐想，能够达成的共识是系统的核心是订单的分解分配，而无需关心消费者下单这一外部流程。从一开始能够将系统的边界划分清楚，对于我们来说，算是开了一个好头，但仅有边界还远远不够，早期我们还无法定位到需求层面，更多的是在讨论如何走通分解分配流程。直到第一次和老师交流，老师点出一个关键的问题，即“如何吸引家庭工厂加入该系统”，同时也提醒我们，家庭工厂拥有极高的自由度，不能对其有过高的要求。自此，我们有了新的思考。

　　我们早期的讨论中给家庭工厂这一用户强加了较为严格的约束，这样可以简化分解分配流程，但是这违背了家庭工厂自主自由的用户身份。所以我们考虑给家庭工厂提供更多的权力，例如家庭工厂可以对该系统上报产能，这一数值由家庭工厂自主提供，新任务到达时也依照工厂上报的产能数额进行分配。这一设定，可以让家庭工厂安排自己流入该系统的生产能力，想同时参与多个协作系统，就可以适当调低本系统的产能设定，因为个人原因想停产休假，也允许将产能设置为0。

　　至于如何吸引别的工厂加入本系统，这一问题我们之前从未考虑过。当老师提出这一问题之后，我们也进行了多次讨论，最终达成共识。我们认为吸引工厂加入系统的最好方式就是保证其收入的稳定，即分配任务时要尽可能雨露均沾。同时也要建立公平的奖惩机制，对于经常违约超时的工厂，需要调低它在系统内的评分，从而影响其获取的订单数量。而信誉良好的工厂则会有更高的评分，从而获取更多的生产任务，达到更高的收入。

 

1.2、设计与实现

　　我们的代码流程的设计主要体现在类图上，核心流程均在图中有所体现。

 

　　

• 订单注入

　　管理员通过接口函数uploadOrder将新增订单注入到控制器的orders数组

• 订单分解

　　订单类的构造函数内，会调用函数Order.generateTask，依照订单的product数组内容计算出tasks数组的内容，task[idx].status均为“Wait”，task[idx].orderId均为当前订单的Id，task[idx].factoryId均为NULL。

• 订单分配

　　订单的分配流程在控制器提供的接口内实现，将订单注入控制器的orders数组后需要调用Controller.splitOrder，该函数依照Controller.factory.produceAbility的数值为末端Order.task赋予factoryId，并将状态修改为”Doing”

• 工厂任务完成

　　家庭工厂完成任务并审核通过后，将会调用finishTask函数，该函数由controller提供的接口定义，由controller实现。该函数会修改task的status为“Finish“，并通过task.orderId找到Controller.orders中对应的order，对其进行下一次任务分配，若该order.task[]中每个任务的状态均为“Finish“，则修改订单状态为”Finish“

• 工厂任务超时

　　家庭工厂任务超时后，会触发failTask函数，该函数由controller提供的接口定义，由controller实现。该函数会依照Controller.factory.producedAbility的数值和未完成任务的余量进行任务再分配，并重新计算工厂评分。

 

1.3、工厂操作界面

　　除了分析之外，还依照分析的结果进行了部分前端代码的实现，采用mock数据进行演示，效果如下。

二、软件开发的思考

---

　　个人认为软件开发的大忌是尚未明确需求就开始着手进行开发，这样的举动会在早期有着较为不错的成果，但很容易在中后期发现对需求理解存在偏差，从而花大量的时间去重构迭代。本组前期花了足够的时间对需求进行分析，能够精准定位到系统存在的价值以及需要解决的问题，同时从代码实现角度整理出一份类图，依照这份类图，可以很快速的梳理出核心代码的逻辑并予以实现。这样的做法虽然前期会显得有些难以言喻，但是中后期的收益是显著的。

　　同时团队合作也是软件开发的关键，五个人开发一个项目和一个人开发是有着明显区别的。我们需要时刻保持每个人对这项目有着统一的看法，出现分歧就需要及时解决，否则各自开发到最后会出现难以对齐，无法联调的现象。

　　需求分析是软件开发的前提，明确了项目的需求，才能明确软件开发的方向。团队合作中，有必要将足够的时间投入到需求分析阶段，如此在后续代码开发的过程中能够更加清楚项目的意义和代码实现的目标，磨刀不误砍柴工便是如此。