目录

软件工程2:从需求分析看软件开发的挑战

软件工程:2.从需求分析看软件开发的挑战

1. 背景:

从第一节课带着本科时对软件工程的三脚猫功夫,选题:基于家庭工厂的订单协作系统,随缘的组队,到现在课程过半,我们让自己较为满意的完成了需求分析。我们已经走过了软件工程的前两个步骤,领域分析和需求分析。在此将过程中的感悟和收获梳理总结。

2. 心路历程:

2.1. 选择题目:

基于家庭工厂的订单协作系统:典型的生活日用品制造业往往由一组家庭式工厂协同配合,共同生产和组装,完成最终订单。系统有几个关键功能:下单(接单)、订单分解、订单分配、订单进度追踪、订单完成风险评估、订单完成效果分析等。要求实现基于网页或手机端的系统。

最初我选择这个题目的初心:选择一个相对简单的项目,能够利用课上所学,从分析到实现,能全过程走完,对真实开发场景下的全流程有基本认识就算成功。现在应该还没有偏离路线。

2.2 领域分析:

当我们选定后题目后,先针对系统是什么进行了讨论。这里主要借助老师提供的模版,让我们有较为明确的思考和讨论方向。

第一次讨论时,我们大致对我们的系统是什么有了基础的认识,但没有记录并同一术语,这为后来的讨论以及分工协作的合成埋下了隐患,增加了我们讨论的成本,过程中的记录是尤为关键的,对关键的讨论结果要有记录,回顾起来,在每次会议前,应该明确会议的议程,需要的关键产出和讨论结果,并且轮流担任记录的方式,这样可能会使合作更加高效。

最初对系统的理解,包括在头几次讨论时,还局限在我们作为一个提供软件解决方案的公司,根据客户需求为他们定制这样一个系统,所有讨论也完全是从需求和功能出发,而忽视了系统的核心价值。

这和真实场景可能类似,一家公司想做这个系统,找我们来做,已经有了一些构想和关键功能的要求,从服务商的角度出发,很容易陷入【完成用户提出的需求即可,而不在乎是否帮用户实现了价值】,这在一开始顺着客户的思路走可能较为简单,易于开展工作,但实际我们发现,用户提出的需求可能并不能很好的满足其核心价值,因此这样的需求易于变动,因此在领域分析时,应当充分思考对于这个领域,我所设计的系统的核心价值在哪里。

除此之外,在实际生产中,为了确保我自己的利益,我是否需要充分为客户着想,还是满足其要求即可,也是软件开发的挑战。这也涉及到我们对系统的定价,在上周的课程中,也进行了讨论。

理想情况下,我们应当充分从客户角度出发,分析出系统的核心价值,为客户最大化利益,从而实现我系统的价值,赚取最大的利润,但这未必能在真实生产中的复杂博弈下开展。

2.3 需求分析:

在认识到我们系统的价值后,核心的用例就是需求拆解和体现,我们首先通过用例图明确了核心用例,对于关键用例,我们采用集体讨论而非分工,从用例和核心业务流程出发,通过状态图梳理并用例规约梳理出业务主流程,此时术语的不规范,让我们沟通多次出现问题,导致理解的偏差,使得有些部分反复讨论在最终明确。

在类图的设计上,可谓绞尽脑汁,一方面是经验不足,另一方面一些用例的具体细节在未讨论清楚之前,类图是不知道怎么设计的。我们在这一部分投入了相当多的时间,大家齐心协力,才最终统一并得到了一个符合直觉和逻辑的设计。

这里我发现核心的困难在于随着细节的进入,使所有人同步变得异常困难,这需要严格的术语规范,并且合理的会议管理,否则一旦走神,很可能会使后续工作出现偏差。

另外,相对于我们这个小项目尚且如此,对于庞大的系统,每个人需要从哪个粒度清晰理解系统也是关键,让所有人对设计的全部内容充分理解并形成统一是不现实的,这一点我们还没有找到合适的解决方法,直觉上,这对工作的划分有很高的要求。

2.4 后续工作

后面进入设计阶段,我们有了一些经验后,采用了前后端分离scram的开发模式,明确了分工,我负责一部分前端工作,统一了技术栈,然后开始设计接口。这个阶段又是全新的挑战。

3. 感想

确实很不容易,坚持听课、听懂再实践需要很强的意志力。据我观察,我们组可能是唯一一个每次课都能全员到场并听课的组吧。当然这也不是评判工作的很好标准,课下投入的时间还是最关键的因素。

非常幸运的遇到我的队友们,很感动,我们互为动力,走到了这个阶段,我也要继续加油呀。