项目开发学习经验

摘自：http://www.cnblogs.com/xuhuan/articles/1417286.html

前面看了前两次的需求分析，虽然其条目扯清了，但仍没有抓住根本，有的甚至把需求分析和类的设计相混淆了。我在这你有必要理清一下做一个项目的思路。学了这么久的程序，也做了不少的项目，但从来都没有顺心过。希望后期有所长进。

一个项目，从客户需求到项目交付，其间要经历很几个阶段，而往往阶段与阶段之间存在这很强的逻辑联系，很有可能错一子而满盘输。即便在软件工业化的今天，阶段之间的逻辑也必不可少，因此，才出现了软件工程。

（待续 09-03-20）

下面我们就来谈谈软件工程。

软件工程通常包含了以下四种基本的过程活动：

1，软件需求规格说明，确定被开发软件的功能及性能指标，给出软件运行的约束。

2，软件开发，开发出满足软件需求规格说明的软件。

3，软件认证，确认开发出的软件以满足用户的需求。

4，软件维护，为满足用户对软件提出的新要求，软件必须在使用中不断维护，以适应用户。

首先，我们看看软件需求规格说明。

一个软件产品从成形的初始概念，经过设计、开发、维护直至最后的退役，这个过程称为软件的生存周期。而一般在设计时把软件的生存周期划分为问题定义，可行性研究，需求分析，概要设计，详细设计，编码，测试，运行，维护和退役几个阶段。

一、软件定义（系统分析，由系统分析员完成）~~~~~~~~~~~~~~~~~~~~~~~~~~

软件定义的任务是确定软件系统必须完成的总目标；

确定工程的可行性，分析实现系统工程目标应采取的技术和软件系统必须完成的功能和性能；

估计完成该工程所需的资源和成本，给出工程的开发进度表。

其又可细分：问题定义、可行性研究、需求分析。

（1）问题定义：（要解决的问题是什么）与客户交流，弄清问题的本质和界限，与客户达成共识。（一天左右）

（2）可行性研究：（对于问题定义阶段所确定的问题是否有可行的解决方案）深入了解、调查显示环境。分：技术可行性、操作可行性、经济可行性，应对不同技术方案进行可行性比较和研究，并向使用负责部门提交书面报告，使其决定是否继续本工程。

（3）需求分析：（目标系统必须做什么）深入描述软件的功能和性能，确定软件设计的限制和软件与其他系统元素的接口；定义软件的其他有效性需求。与用户密切配合，导出用户满意的系统的逻辑模型，他通常是由数据流图、数据字典和算法表示的；在需求阶段必须全面理解用户的各项需求，并合理区别对待。

相对与前面所讲到的内容，在我们做项目的是侯几乎没有用的上，甚至根本就没有考虑。自然后面也就漏洞百出了。特别是对于上面提到的需求分析这一块我们从来就没有明确过，重视过。看来以后要注意了！



二、软件开发~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

软件开发分为概要设计、详细设计、编码和测试四各阶段。

（1）概要设计：（应该如何宏观的解决这个问题）首先，有软件工程师选择适当的设计方案；其次，设计软件的结构，确定软件由那些模块组成，以及模块间的关系。[用层次图或结构图来描述软件的概要设计]

（2）详细设计：（如何具体的实现这个系统）软件工程师对概要设计得到的软件功能模块逐步细化形成软件模块的详细规格说明。它包含足够的细节，程序员可以那他直接写代码。[HIPO（层次图加输入/处理/输出图）图也可以描述详细设计结果]

（3）编码：（怎样写出正确的、容易理解的、容易维护的程序模块）选择一种语言实现详细设计结果，并验证程序模块的接口与详细设计的一致性。

（4）测试：（通过怎样的测试[及相应的调试]，使软件系统达到用户预期的要求）分为：模块测试、集成测试（即整体测试）、验收测试（即有效性测试）。并把测试计划、方案和结果用真是的文档保存下来，作为软件配置的一部分。

（待续 09-03-23）



前面讲了很多的理论，似乎不是那么容易理解，虽然理论是实践的总结，但也要依靠实践来考验的。

这两天通过做项目，加上仔细观察，感触颇多，收益也不少。其中暴露出来的问题更是惊人。我在这里晒一晒，也当检讨。

说起来，做项目也做了几个了，但从来没有进入过了理想状态。不是早期设计漏洞百出就是后期编码迷迷糊糊，项目意见不统一，模块分配不满意，进度拿不上来，效率提不起来，做个人项目------。似乎可以罗列一长串的问题。然而至今未能找到合理解决问题的答案。

03-15：

老师正式把项目布置下来，个个兴奋激动，血起云涌，讨论着自己的框架（似乎用方向更好点），彼此对这个S2的第一个项目充满期待，更充满幻想。

03-16：

小组基本上没有什么动静，不知是在蓄势待发，还是在闭门造车。

03-17：

有一部分小组今天开会了。着重讨论了一下项目问题。

03-18：

终于，我们小组开会了，似乎是在被迫而又刻不容缓的情况下开的。理所当然的话题依旧是项目问题。大家聚在一起整体先滤清了思路，构思出了大概的框架，这大概就是软件工程里面的软件定义阶段（当然可行性研究和需求分析就算了，作为练习项目自然可以不考虑可行性问题，因此可行性研究报告也就免了。然而对于需求问题，他因包含的面太广，包括程序的设计和扩展，以及实现程序的大概类，接口，及框架，把软件的使用逻辑流程详细的表现出来，以及理解软件设计的限制和对其他接口的连接，最后还要全面理解和实现用户的需求）吧。毕竟只用了半天时间。自然后面的许多祸根就在这里被深深的种下了。拿出了不是文档的文档。不是框架的框架。

（待续 09-03-27）

03-19：

小组再次对项目的一些细节进行了分析，并对小组成员的工作划分大致进行了分配，看看周围的其他组，发现我们还处于上游地区，心里不免一阵窃喜。通过后期项目答辩是老师给我们的指导，发现我们在这里有出现了一个严重错误---因人员、能力等因素导致了工作划分不均，部分组员被边缘化，而一部分组员又所干并非意愿之事。因此到后期出现了进展放慢的迹象，并在项目答辩时受到了答辩老师的批评。事实上，在这一点上，使所有组都存在的一个共同毛病，可能只是我在这里说出来了罢！

03-20---03-25：

对前面的工作的一个继续，我和组长的任务是为我们项目的三层架构搭建框架。事实上我主要做辅助工作，帮助组长出谋划策，想解决方案、策略。这段时间一直维系到3月25日。也是在这段时间前期的矛盾加剧！我和组长搭建框架，一组员做窗体美工。而另外两名组员完全被凉拌了。也许是项目本身并不太大，所以无法分下去。然而我更多的是看到的是组长对于成员的不放心态度。我曾和组长交流多次。而我每次都听到的是：这个项目无法在划分了，在这个阶段出了核心框架，就是窗体美化。核心框架他们会吗？窗体美化要统一，一个人就够了，再说他们也没有美术功底，能做什么？

我郁闷了。思来想去我也找不到什么办法！参考参考周围其他组的情况，其境况也不甚良好，甚至比我们更差。一组的组员也就因为分工问题甚至与组长发生了争执。而另一组也是因为组长的原因，一个人完全包揽了整个项目的设计到框架实现，而其他组员只能做一做窗体。另外一组默默无闻的组织着自己的进度。前面的几个组因组长有能力，加之组员或多或少的帮助，项目进展还过得去。而另一组，因组长和组员的能力有限，整个项目毫无建树，做得一塌糊涂。当然这还只是概要设计和详细设计阶段。在这里暴露出了两个极端：当组长有能力时，想到的更多是项目，他忽视了人员的分配问题。当组长无能力时，更致命的是组员之中也无人能敌，那也只能宣告项目的破产了。

在这里我更关心的是关于组长对于组员工作的划分问题。至今我没找到合适的答案。！

03-26：

按照我们组的初始进度：26划分窗体模块；27--28各组员对划分到的窗体进行填码工作；28合并项目；29有时间做分布式以及进行调试工作。当初以为框架做完就完成了80%，然而事实上只完成了40%。26号各组员所负责窗体模块划分下来后，组长对整个框架进行了讲解，方便组员对框架中的方法调用。然而事实上他们依然很多没有弄清楚。在校集中编码其间，因前期需求分析所做不足，在这个阶段导致很多组员对窗体控件命名不规范。对窗体设计修修改改。甚至对框架中的实体类及其相关联类都进行了不小的调整。在这里足以看出前期需求分析详细的重要性。

03-27---03-28：

真真正正累的两天，完全陷入了窗体逻辑之中。

03-29：

与黄倩组通宵作业，加紧赶工，明日项目答辩！

03-30：

终于在项目答辩前的一刻，整合了项目。幸而不幸，我们组第一个答辩，原本紧张的心情就更加紧张了。前面进展似乎还挺顺利（主要是我们组长不却场，又善于演讲）。然而后来一个个上去后状态始终未能赶上。紧张，不自信，不会讲，加之演讲时出现了bug，更慌神了。后来答辩老师总结了我们的失误：缺乏上台锻炼，紧张，对自己的项目不自信。（项目是用来卖钱的，是拿来给客户演示的，用的。首先介绍就抓不住客户的心理，如何让客户有兴趣购买你的产品！你对自己做的东西都没有信心，又如何让客户有信心购买！），说道了我们的症结。后来又讲到了关于团队的问题。可能是由于项目演示的时候我们模块与模块之间的衔接得不是很好，老师又看出了我们团队配合不默契的问题。也提到了项目分工的问题，正如前面所说的那样。

还有就是，针对我们上台演示时暴露出了很多bug的问题，授课老师交给了我们一些经验：项目演示的前一晚不要做任何的代码修改，专作调试，演示时以调试数据为准。

总的来说，通过这次项目答辩，收获不少。在此记录下来，希望下次引以为戒。少走弯路，冲刺出更好的项目。！



通过对这次项目的总结，以此为标杆吧！！！

同学习，共进退！

（完结 2009-04-05 晚）