我对开发生命周期的理解
我觉得开发可以分成 "需求","沟通","业务","设计","原型","编码","测试","部署","维护".
每一个环节处理不好都会对整体开发造成不可估量的后果.
是需要将它们进行分工,并且专业化.
"需求","沟通","业务"应该是项目经理 的责任,
"设计","原型",应该是架构人员 的责任,
"编码","测试","应该是开发人员 的责任,
"部署","维护",应该是维护人员 的责任.
但是有时候具体实施起来是有很大困难的,这是因为
1,相关人员必须齐全而且称职!
需求归纳时，要求得到的需求是完备而且相对稳定的。
业务文档应该是清晰，细化，完整的。
与客户沟通，与项目成员沟通应该是高效的
设计应该具有前瞻性，灵活性，扩展性和简单性！并且能够使他人充分理解设计。
对技术点应该有代码原型，对业务应该有操作原型，能使各种水平的开发人员迅速投入开发。
编码人员应该充分了解所用语言的特性和常用API，能够写出清晰、高效的代码。
测试应该是充分、全面而且容易重复的。有单元测试和集成测试。
2,各个环节的流程配合很难!
。。。
具体的就不展开说了.软件工程是老生常谈了,也是老大难的问题
从上而下开发,迭代开发,UML建模,敏捷开发,数据库导向开发,结对编程,模型驱动编程,用例驱动编程,等等等等.
纷繁芜杂,流派众多,
但是一切都归根到"人"的身上.要有合适的人才能做相应的事情.
我觉得目前在我们公司里,
小项目应该由项目经理负责"需求","沟通","业务","设计","原型"的工作,之后的工作就可以基本脱手了.
中等项目,以上项目经理负责的工作就需要有助手进行协助，分担设计和原型工作。
原则是,业务或设计应该采用集权制 ,由某人总负责,然后再征求他人意见.——避免设计出散乱的系统。
"需求","沟通","业务","设计","原型"之类的工作就是党辉提出的“业务分析组”做的事情——称为“前期工作组”好像更好一些，
。他们的根本目标是得到“设计”，得到一个系统基础平台，这里面架构人员是最关键的角色——因为他承上启下——出于脑力劳动的特性，最好是单人制并拥有设计方面的一票否决权。
待续。正好fangm回来了，去杀魔兽也。
【2007-9 bbs】