精彩专题 |
如何做好项目沟通计划
软件项目质量管理
国际工程索赔与反索赔
|
| 更多：
|
|
联系社区管理员 |
咨询电话 010-82273401/11
斑竹申请 admin@mypm.net
版权所有 © 2003-2004
京ICP证070584号
BBS业务许可2007第353号
最佳显示模式：1024*768像素
|
|
 |
 Re:软件工程能帮我解决这些烦恼吗？——一个刚毕业的学生的疑惑
[回复于 2005/6/30]
|
这几个问题我觉得主要源头是需求部分没有做好，当然做好一个需求确实也不是容易的事情；
1.了解客户的业务，了解他们想要的（如果软件比较小或者功能单一而且稳定的话这个可以省略了），设计一个软件，本身就会和市场和业务要紧密结合的，如果说对用户业务方面都不怎么熟悉，自然需求是很难做的，所以如果楼主对客户的业务不是很熟悉的话最好还是能花点时间在这个上面，
2.用户需求分析时多花点时间，有的时候如果比较大的产品，其实用户本身也不一定很清楚他们自己要的是什么样的，只是大致有个想法，这时候就需要能花一定的时间和他们沟通，在这个过程中学习用户的业务，开发他们的需求，让他们了解在这个项目或公司允许的成本范围内可以达到一个什么样的程度，同时进认识他们要的是什么，在讨论需求的过程中形成一个有效的文档，并要求客户对这个文档进行确认（签字），需求分析做的越细到后面的时候我们的主动权就越大，在签订合同的时候可以增加对因用户需求改动引起的工作量而进行补偿的条款，一般20％以内的改动是允许的，超出的部分则可以按照超出部分的工作量和公司成本进行协商（工作量应按照改动部分的代码，文档，测试及维护总和来计算）；
3.对于你说的做了一半然后发现流程有问题这个现象，只能说设计不充分了，应用软件的开发是属于工程性质的，不是理论上大致能走的通就一定没问题的，工程是一个很现实的东西，其实做了一些东西后可以发现一个软件中真正技术上的难点可能只有一两个，开始的时候一直觉得解决了这几个难点，那整个软件的开发就水到渠成了，但到了后来却会发现原来一直不起眼的地方可能成为软件流程中解不开的死结；所以设计文档这个东西一定要有的，哪怕再简洁至少自己要把整个流程想通一遍才行；版本控制的软件是有，但是那主要是用来在有多人开发的情况下避免互相修改的代码被最后一个人覆盖了的情况，对于你这种情况只有每次大规模修改的时候，自己以日期或者别的重要性标志保存到不同的目录下才行，再高级的软件也没办法知道这次你改了哪些功能，下次又删掉了哪些模块；
4.文档这个东西是一定要的，不过哪些要哪些可以不要，各人看法不一，我觉得文档是给人看的，如果花了很大的力气却得到一个没人愿意看或者看不懂的doc文件，那不如多花点力气到程序里去算了，至少用户可能会得到更多的功能或者后来者可以看到更多的注释；个人认为用户需求分析文档、概要设计、数据库设计（如果涉及到）、源代码说明这几个一定要有，其它的如测试报告、需求跟踪、详细设计、维护手册、操作手册等可以根据用户要求或者项目大小，项目工期进行一定的调整，本身CMM规范给出的就是一个可裁减的文档；
|
|
|
|
1楼
 XO
职务 无
军衔 少将
来自 上海
发帖 436篇
注册 2005/1/7
PM币 10955
经验 
 
|
|
Re:软件工程能帮我解决这些烦恼吗？——一个刚毕业的学生的疑惑
[回复于 2005/6/30]
|
|
需求一定要做详细了,将界面设计用例和草图Demo给客户看完后再望下做,不要怕麻烦,这点很重要.至于你要的报酬多少的问题应该按合同来,合同中应该有说明主要是系统需求和应用需求分清晰,属于应用需求的需要额外的资金来提供维护.
|
|
|
|
2楼
 大漠
职务 无
军衔 三等兵
来自 广东省
发帖 19篇
注册 2011/5/24
PM币 -5
经验
|
|
Re:软件工程能帮我解决这些烦恼吗？——一个刚毕业的学生的疑惑
[回复于 2005/7/3]
|
|
文档不仅需要，而且要保持随时更新！我曾经遇到过这样的情况，在前期做需求和设计的时候，完成了设计文档，定义好各接口和模块；随后开始编码，在编码过程中发现当初设计时有很多细微的问题，随手就在代码中更改了，没有及时更新文档，直到编码完成后才发现，当初文档中的接口和最后的编码实现的已经有很大的不同了。
|
|
|
|
3楼
irfair
职务 无
军衔 三等兵
来自 广西
发帖 5篇
注册 2005/6/29
PM币 20
经验
|
|
|
项目型组织
项目管理
工程项目
科技项目
资格认证
职业休闲
