软件工程实战-需求分析

        这段时间，我们几个人组成一个团队，正在进行一个系统的开发，这个系统已经有了两版的积累，但是我们这次的任务是重构，需要我们对系统做到合适的优化，加入一些新的需求！在这个过程中，我们要在前人的基础上深入地研究需求，提出一个更好的优化方案。

      在讨论几次后，总感觉少了点什么东西，我们开始反思我们的整个流程，我们想到了软件工程，有过项目经验的同学说，最后都会落实到软件工程中，我们先来看看软工的定义：

一，软工定义

IEEE：在软件工程术语汇编中的定义：软件工程是：1.将系统化的、严格约束的、可量化的方法应用于软件的开发、运行和维护，即将工程化应用于软件；2.在1中所述方法的研究

 

  在前人实验了无数次的经验摆在了我们的面前，在面临实际的项目时，有时就容易按照自己的想法来，往往走了很多弯路，好在这是第一次，也是我们发现的早，及时修正管理方案！今天主要是通过实际的情况来了解一下软件工程的思想，今天是第一篇，以后会跟随进度陆续出来一个软工的系列，请大家关注！

二，方案对比

1，学校方案

      今天我们先来看看软工的第一个阶段，定义阶段，考虑到这是学习，我们又是学生，维护过旧版考试系统一年的时间，软件的开发是可行的！

   软件的需求获取，我们经过一系列的交流和讨论，对比公司和学校的需求分析过程，我

总结的改正方案是：

       1，与用户在某一块交流需求

       2，确认需求

       3，与开发人员一起研究，确定可行性

       4，讨论下一个需求

       5，需求完成后，形成文档，用户签字

2，公司方案

 

这个和公司的开发过程有些不同，我们看看公司的开发过程

 

       1，简单的用户接触，了解大概的需求

       2，公司讨论可行性

       3，确定可行后，专员负责与用户进行需求协商

       4，确定N套方案，用户选择

       5，确定方案

       6，项目组长审查方案，确定可操作性

       7，修改方案

       8，与用户协商

       9，如协商有问题，双方进行深层次的谈判，会有各自的负责人交流

       10，确定方案，确定开发计划

       11，双方签字

       12，开始开发

 

       由学校的情况有别，分析后我们不难发现，公司的需求分析阶段进行的确认和反复工作较多，这是考虑时间和人力成本后作出的一个较为平衡的选择！将需求封装在一层，没有特殊需要，底层的代码人员是不会和用户接触的，学校的情况是，一直来就是代码人员的接触，这样保证了充分的了解需求，但是这是学习阶段，人力物力的消耗是可以接受的！

三，总结

      今天的项目实战是对以前知识的应用与重温，课本上的知识，和实际的应用还是有一定的差距的，应为现实总是比较复杂，而课本是现实一个抽象的代表，我们要将抽象的知识，进行适配，找到适合的方案解决问题，就像软工，适应实际情况的变化才是合适的软工思想！