大家都知道，软件工程化，一定程序上解决了软件危机，使开发出来的软件能够保质，保量。
可是软件还没有像硬件一样，得到质的突破；也没有像建筑工程一样，快速的建造。
我的观点
之所以没有得到硬件的突破，是因为标准太乱，一套JAVA的标准就可以搅乱翻整个世界，而且参与的人良莠不齐，很多系统漏洞很大一部分归结于错误的代码；
没有像建筑工程一样快速生产，软件开发经常变动，需求变动经常会影响到根基，而建筑工程就不会，架构搭好就基本不会变动，偶尔的变动不会涉及到根本，软件频繁的修改势必会影响发展。
大家都讨论一下，软件工程，硬件，建筑工程的话题，互相学习一下。
------解决方案--------------------------------------------------------
主要是人的因素
------解决方案--------------------------------------------------------
顶一顶 顶一顶
软件工作重要的参与的每个元素，其中很重要的一部分为人的因素，我们仅讨论一下关于开发人员的问题吧，因为这里边的角色太多了
软件质量的比较好的方法是通过过程控制、管理。
但是很多开发人员个体还没有能够对自己进行过程化管理，例如对自己的开发进度、时间利用都不是很清晰，这样就等于是一个蚂蚁对堤坝的作用，不仅仅在技术水平方面，我认为更重要的是个人的过程控制和管理。
另外，组长或部门负责人也是一个很重要的角色，往往他们不太关心过程，仅关注，代码写完了吗？测试过了吗？
这还不够，组长或部门负责人要肩负对团队过程的关注和调整责任。
------解决方案--------------------------------------------------------
软件工程化的思想和理论，还是需要不断被实践和被改进的；
个人认为，像软件工程这样标准化的东西在中国严格实施起来恐怕很难，我们似乎都不喜欢循规蹈矩的做事情，我们的语言似乎也很难精确的表达。
------解决方案--------------------------------------------------------
软件本来就是人理解这个世界创造的东西，软件工程是希望能够把软件也做得像硬件一样，软件生产线的建立肯定会促进软件行业的发展，而且标准的制定也不可能让一个人，组织或者国家垄断，这样会造成行业发展的瓶颈，像现在这样才能促进软件像一个有利于整体发展的方向，个人观点！！！
------解决方案--------------------------------------------------------
学习，帮顶
------解决方案--------------------------------------------------------
说的很简洁，很着要点。
------解决方案--------------------------------------------------------
个人理解就是将软件开发的过程量化。
------解决方案--------------------------------------------------------
软件工程只是一定程度上的解决了软件危机，其实就是缓和了危机的发生，并不是真正的解决了软件危机，因为没有更好的办法来解决软件危机，现在就先用软件工程来应付，而且事实证明软件工程是很有作用的。个人浅显之见。
------解决方案--------------------------------------------------------
管理太混乱了吧！！而且写的代码质量也不高~
------解决方案--------------------------------------------------------
软件工程是如何帮助软件生产如期待也如期完成的辅助方法. 如何运用有限的资源满足客户的需求或做出受市场肯定的软件, 还能让开发团队生存下来, 能够获利, 都是需要著墨的课题. 如此, 软件工程应包含需求管理, 项目管理, 配置管理（Configuration Management: 包含SCM与变更管理), 测试管理, 瑕疵管理, 外包管理与采购管理等. 不过有一点还是不可忽略, 很可惜的软件工程没有包到, 就是要接什么样的单, 做什么产品,与采用什么business model的问题, 正如Mr. Tom Demarco(Measurement的启蒙者与最后期限的作者）最近在IEEE写的一篇质疑Software Engineering的文章问的: why on earth are we doing so many projects that deliver such marginal value? (为何我们做了这么多没啥价值的专案呢?)
------解决方案--------------------------------------------------------
同意道士佟的看法, 我听过一个故事, 有个学校要求程式员写一个"如果某堂课选修者已超过10个, 有人要退选的话, 退到第10个的那个人不能退选." 要满足这个需求, 用逻辑想想还真简单. 不过后来系统写好了, 引发很多民怨...结果这个程式员还得多花很多功夫重新改写, 真的很倒楣. 最后问清楚才知道这个要求是基于每种课如果选修者少于10人则无法开班, 但当初程式员也没究竟为什么要这样, 也完全符合规格做好了. 可是....xxxxxx 所以有的时候我们真的不能尽信提需求者所说的规格, 可能要知道其背后到底有什么假设或原因, 真正的目的是什么,再跟提出需求者讨论怎么做比较好.
另一个软件项目常遇到的状况是, 需求者在看到雏形时, 才想到他还要......, (对于建筑工程, 他们知道做了就做了, 很难要求更改, 且cost是看得到的, 软件呢....太无形了,对于需求者来说, 要求修改没什么大不了) 可是价格都谈好了, 要加价通常都很困难, 所以软件公司有时候接越大的单越快倒掉就是在这个问题上....根据赚钱的软件公司的经验, 只要有变更管理, 就需要加价....不过这就要评估市场策略与实际的状况, 有时抱著壮士断脘的决心去谈案子, 反而让公司活更久.....
------解决方案--------------------------------------------------------