软件为什么要采用工程化的开发

⑴ 什么是软件生产工程化

软件工程环境是软件工程学科各方面研究发展的物化表现，具有以下特点：
（1）软件工程环境强调支持软件生产的全过程。实践表明：软件工具仅支持生命周期中某些特定活动，工具箱将一些相互关联的工具组织到一起，使其相互通信，从而支持了生命周期中某些成组活动，自动化程序有所提高。软件开发环境旨在通过环境信息库和消息通信机制实现工具的集成，从而为软件生命周期中某些过程的自动化提供了更有效的支持。不同的过程模型导致不同类型的软件开发环境。然而，软件过程领域的最新研究结果表明，软件过程概念已不仅局限在软件开发和软件维护，而是发展到包括系统集成和软件产品的制作与生产。SEE旨在解决软件过程中各个过程和活动如何按照各条路径并行完成。管理、支持、获取、供应等过程贯穿于整个生存周期，特别是管理活动和支持活动，从合作观点来看，对于软件生产具有更为重要的地位。因此，促使人们在更高的层次上考虑如何运用“整体大于各部分之和”的系统工程，提高整个软件过程的整体计算机辅助支持程度。
(2)软件工程环境强调大型软件的工业化生产。软件发展已经形成了大规模的产品市场。因此，软件产品的生产也必将走上工业化的道路。所请的工业化是指能够形成规模经济的生产形式。工程化注重软件生产过程中软件生产者具有一定的工程训练，遵循一定的工程准则。工业化则更加强调软件生产过程中生产资料的作用，表现为把大量的生产者的技能和经验转移到生产工具之中，从而减少生产过程中的劳动比例、减少生产工具的增值比例。SEE是为工业化生产提供一整套的支持设施。
(3)软件工程环境以集成和剪裁作为主要技术路径，实现软件工业化生产的目标。SEE具有多维性，表现在不仅要集成与软件开发技术相关的工具，还要集成与支持技术、管理技术相关的工具，并将它们有机地结合在一起。
(4)标准化。软件生产走向工业化需要建立相应的工业标准。

⑵ 软件工程就是用工程化的方法开发软件同学们这句话是什么意思呢

摘要 软件工程就是用工程化的方法开发软件

⑶ 软件工程的目的是什么

中国的软件行业规模不是很大，有些软件企业在软件制作上，也只是采用了一些软件工程的思想，距离大规模的工业化大生产比较还是有一定的差距；原因有管理体制的问题，市场问题，政策问题，也有软件工程理论不全面和不完善的问题。所以软件工程的研究和应用，以及中国软件行业的进一步发展，都需要一定的既有软件工程的理论基础和研究能力，又有一定的实践经验的软件工程科学技术人员来推动。软件工程的前途是光明的。
软件服务外包属于智力人才密集型现代服务业。大量着名外包企业落户宁波。主要就业去向包括软件外包与服务企业、信息产品与服务企业，担任程序员、软件测试员、项目经理等工作岗位。
软件工程专业是一门研究用工程化方法构建和维护有效的、实用的和高质量的软件的学科。它涉及到程序设计语言，数据库，软件开发工具，系统平台，标准，设计模式等方面。在现代社会中，软件应用于多个方面。典型的软件比如有电子邮件，嵌入式系统，人机界面，办公套件，操作系统，编译器，数据库，游戏等。同时，各个行业几乎都有计算机软件的应用，比如工业，农业，银行，航空，政府部门等。这些应用促进了经济和社会的发展，使得人们的工作更加高效，同时提高了生活质量。
相关学者、组织机构都分别给出了定义：
Boehm：运用现代科学技术知识来设计并构造计算机程序及为开发、运行和维护这些程序所必需的相关文件资料。
IEEE：软件工程是开发、运行、维护和修复软件的系统方法。
Fritz Bauer：建立并使用完善的工程化原则，以较经济的手段获得能在实际机器上有效运行的可靠软件的一系列方法。

⑷ 什么事软件开发的工程化，工程化的软件开发方法与早期的程序设计方法的不同点在哪里

软件开发的工程化 是指将软件的开发企图变成工业化流水线一样的加工，从而保证开发的进度与质量。强调分析与设计，与早期的程序设计方法比，程序员的重要性大为下降。
所以在印度，一个高中生经过短期培训就能成为程序员。

⑸ 谈一谈对软件工程专业的认识

对软件工程的一点看法--希望能够抛砖引玉
在这里看到很多网友的高论，很有启发。而且目前市面上也涌现出一批面向不同方面的软件过程的书籍，可是在这里，我一直没找到真正对实践有指导意义的，可操作的应用方法，所以现在这儿抛块砖，望各位高手指正。
我个人的理解，软件工程就是按照工程学的管理方式，有组织、有计划的，在一定的质量基础、时间限度和成本范围内，实现功能明确的软件系统。而且，软件工程在企业范围内运行，一定需要企业资源的支持，要与企业的经营、决策、管理体系联系在一起，才能够被踏踏实实的落实下来。
软件业作为一个服务业，要想得到发展，首先必须形成一个对软件服务有迫切需要的市场。其次，这个市场中的消费者必须具备足够的购买力。软件的消费群体简单一点，可以分为个体消费和企业消费。中国的企业群体，数量庞大，但是质量不高。上规模的企业极少，因此，中国的企业对大型软件的消费肯定是有限的，软件的个人消费，至少目前在中国，还是不成气候。因此，国内目前能够形成比较大规模的独立市场的，肯定是小规模的软件系统。
此外，质量的好与坏也不能绝对而论。比如说，你花500元，买双皮鞋，只穿了一个月就坏了，肯定是劣质产品。可是如果你只花了5元买这双鞋，还是穿了一个月就坏了，他就是个优质产品了。软件也是一样。
还有一个，就是软件生命周期问题。在国外，很多中、大型企业里，软件系统已经作为企业的命脉在运行，这些企业当然需要长期、稳定的软件服务、开发体系作为保障，因此相对来说，对于软件的功能需求就比较明确，而国内的中小企业在运营方面本来就把灵活多变作为生存武器，当然不可能有比较长期的经营计划，更不可能运用软件系统进行全面企业管理。这就导致对软件系统需求的短期行为，因此，他们更加希望一次性购买功能有限的软件系统，而不是长期连续的软件服务。
如果上面的分析有代表性的话，那就是说我们现在必须对开发这类软件形成一套非常有效的工程方法：
1。规模小。
2。成本低
3。质量要求不高。
4。售后服务有限。
5。生命期短。
我想，对于这类系统，RUP未必是一套好的方法。另外，我还想谈谈对软件人员素质的看法。
从我个人的经历来说，我觉得我们对于软件工程师的培养方法有问题。理论上说，软件只要设计了一个好的结构，解决了所有的技术难点，剩下的代码高中生就能做。实际上我们的很多名牌大学的计算机专业毕业生都不能很好的Coding。尤其是现在有了VB、PB、JAVA之后，大家似乎认为计算机的体系结构都不用关心了。我曾经经手的几个软件项目中，很多工程师对于用C语言开发Win32多线程、事件驱动、死锁、内存分配等问题根本束手无策。我不相信这些问题可以靠很好的文档解决。实际上，能够用OO的工具工作，根本不代表能够进行OO的系统分析与设计。
话又说回来，在中国，有10年以上软件开发背景的人，又有几个？而且他们在过去10年里的经验，更多的是小项目的Coding，而不是大项目的管理与系统分析。而一个好的系统分析师，需要的是实践、实践、再实践。假如说我们的商业环境中根本没有大型的软件项目，怎么可能有优异的系统分析师呢?
所以，我想，目前我们的问题，是工程师的技术水平、知识面与管理意识、管理方法同样重要，在这样的前提下，我们是不是要探索一下真正适合我们的软件工程方法呢？

⑹ 软件工程是什么未来发展怎么样

软件工程学的主要内容是软件开发技术和软件工程管理。 软件开发技术包含软件工程方法学、软件工具和软件开发环境；软件工程管理学包含软件工程经济学和软件管理学。 专业简介是计算机领域发展最快的学科分支之一，国家非常重视软件行业的发展，对软件人才的培养给予了非常优惠的政策。本专业培养掌握计算机软件基本理论知识，熟悉软件开发和管理技术、能够在计算机软件领域中从事软件设计、开发和管理的高级人才。 主修课程该专业除了学习公共基础课外，还将系统学习离散数学、数据结构、算法分析、面向对象程序设计、现代操作系统、数据库原理与实现技术、编译原理、软件工程、软件项目管理、计算机安全等课程，根据学生的兴趣还可以选修一些其它选修课。 毕业去向除考取国内外名牌大学研究生外，主要毕业去向是计算机软件专业公司﹑信息咨询公司﹑以及金融等其它独资、合资企业。 培养目标本专业培养适应社会发展需求，德、智、体、美全面发展，具有扎实的计算机应用理论和知识基础，掌握软件工程领域的前沿技术和软件开发方法，具有较强的实践能力和创新精神，具备较强的软件项目的系统分析、设计、开发和测试能力，能够按照工程化的原则和方法从事软件项目开发和管理的应用型人才。

⑺ 为什么要进行软件工程标准化,软件工程标准可以分为几个级别

CMM,可分为5级。华为公司目前是5级。

⑻ 什么叫做软件工程为什么要采用软件工程方法开发大型软件

软件工程包括两方面内容：软件开发技术和软件项目管理。 软件开发技术包括软件开发方法学、软件工具和软件工程环境。 软件项目管理包括软件度量、项目估算、进度控制、人员组织、配置管理、项目计划等。 软件工程是六十年代末为了解决软件危机而出现的一门学科，一般来讲它包含开发技术与管理技术。而软件过程是随作软件工程的开展，特别是近年来系ISO900系列与CMM方法的实践而逐渐时髦的一个概念。它基于质量是做出来的，而非检查出来的现代质量理论。在规范化的软件生产中，离开了软件过程是不可思议的。 区别在于“工程”和“过程”的不同，软件工程是指将系统化的、规范的、可度量的方法应用于软件的开发、运行和维护的过程，即将工程化应用于软件过程。工程着重应用，软件工程一定是软件过程的一个“产出”，一个个性化的实例！工程也是由过程组成的。 硬件的一些功能一目了然,形象化,就在那儿,更容易理解,比如盖房子的砖,赛车的轮子,数字电路中的接口电路,以某种方式连结在一块就好了 软件工程的结构开发思想,是在你对语言又很深理解的基础上,实现一些功能模块,使这些模块的使用者以某种方式把它们放在一块就安全高效的实现了所要求的功能 补充： 随着企业信息化的深入，对软件项目的需求日益复杂，并会产生频繁的变更， 传统的个人英雄主义的开发方式已经越来越不能适应发展的需要。从软件企业的发展战略来说，如何在技术日新月异和人员流动频繁的情况下，建立本公司的知识库及经验库，把企业中分散的隐性的财富，即个人的知识及经验，转变为企业的知识和经验，以便提高工作效率，缩短产品周期，加强企业的竞争力，具有至关重要的作用。采用科学的管理思想，辅之以先进的管理工具，已经成为企业未来发展必不可少的手段。 如果软件开发机构不能有效地控制和使用软件资源，则在面对风险时就可能导致软件开发活动出现各种问题。由于不能很好地管理软件过程，会使得一些好的开发方法和技术没有起到预期的作用。项目的成功往往是通过工作组的杰出努力来达到的，这种仅仅建立在依赖特定高素质开发人员基础上的成功，不能保证全组织的持续稳定的软件生产和质量的长期提高。因此，要降低软件开发过程的风险、保证软件产品质量，就必须加强管理，而 软件工程方法开发大型软件是企业过程改善和能力提升的基础。 凡高的左耳 的感言： 谢谢你帮了我大忙！

⑼ 什么是软件工程化时代

本文译自着名IT顾问和评论员David M Williams的博客，在这里，他提出了关于软件开发的全新理念。
Tom DeMarco是着名的Peopleware: Proctive Projects and Teams一书的合着者，然而在这个月，DeMarco向IEEE的计算机协会提出个人意见：软件工程时代结束了。

大多数计算机软件开发者必读书目中都包含Peopleware一书，它于1987年首次出版，1999年再版。

尽管出版多年，Peopleware依然具有重要参考价值，因为它并不注重软件技术本身，而是关注人的因素。

因此，DeMarco给这本书起了一个带People的名字。也许并不像Steve Ballmer，Steve Jobs或者Linus Torvalds这些大师们演讲时拥有那么多粉丝听众，但DeMarco依然是全世界高质量软件开发从业者们执着追随的对象。

一个类似的公告出现在今年7月Computing Now杂志（IEEE计算机协会的出版物）的DeMarco视角专栏，标题为《软件工程：一个过时的概念？》。

这在很多层面上都是很吸引眼球的，除了DeMarco的作者身份以外，标题还蕴含着出人意料的观点：软件工程是一个正在消失的概念。

实际上，DeMarco本人就一直引领着软件工程的现代观念，在Peopleware之前，他写了Controlling Software Projects: Management, Measurement and Estimation（《控制软件开发项目：管理，测算和评价》）一书。

这本1982年销量冠军的第一行文字在接下来的27年中被广泛引用，DeMarco在其中写道：一个人无法控制他不能测算的东西。为了解决这个问题，软件工程师们克服重重困难，勇敢地一次次去分析和揭示一切软件里可能的规律。

可是，随着时间的推移，DeMarco现在显露出对其原先所持观点的不安。

那句引文中（书名也是）暗示了控制是一个重要的方面，他说，也许对任何软件项目来说都是最重要的方面。

但现在不是了。他说，接着举了Google Earth和Wikipedia这两个典型例子，它们都是在发展中不进行多少控制的软件。

为了说明他已改变了的推理，DeMarco引用了两个假定的项目：最后都要花费大约100万美元，但项目A将产生大约110万美元的效益，项目B将产生超过5000万美元的效益。

很明显项目A会有更严格的控制，如果预算超支或软件发布推迟或质量不达标，项目会冒很大的亏损风险。

相比之下，项目B由于投入和产出差异巨大，控制可以很松。很明显的是，在这里面成本、期限和质量问题依然存在，但项目最终会赚钱。如果不赚钱的话，一切都会乱掉。

由此，DeMarco沉思自语道：实际上一位主管越是注重控制，他的团队越是可能在开发一个只能艰难盈利的项目。

接着他说，管理软件开发的问题应该不是关于严格的控制和软件工程所规定的规律，相反，开发团队应当开发产生真正效益的项目，主管应当降低对项目控制的期望。

这是在假设DeMarco以上第一个建议更关注企业领导者或分析师，因为是由他们确定一个软件解决方案是必要的，而不是开发者被指派去编写这些代码。

普通公司里的程序员并没有选择他们开发项目的权利，但显而易见，主管们应该在投入资源开发之前确定一个项目数量上的效益和质量上的效益，他们得在这方面多下功夫。

一个软件工程之父，不停地在告诉人们要放松，不要整天盯着开发项目的成本和时间要求，这听起来让人感到困惑。

为了给他的观点进行辩护，DeMarco拿青少年来做类比。对于青少年，你怎样在他们身上找到一个人无法控制他不能测算的东西的理论依据？例如，一位称职的家长会如何客观地评价他子女的道德水平、教养和同情心？

在这种情况下，你无法控制一个抚养对社会有益成员的育人项目，相反，在软件项目中你管理的是员工，控制的是时间和成本，从根本上说，在这过程中你得尽可能在拥有极少反馈信息的情况下掌控大局。

用同样的方法，一支软件开发团队应当在开发过程中按照相关价值大小、文档和测试结果不断向项目中增加程序块，在项目主管宣布项目完成的任何可能时候都能立刻将产品打包并发布。

DeMarco说，去设计规划一套软件依然有其意义，但那并不是软件工程这个术语所要真正表达的意思，设计策划软件是一整套规则，过程，检视，度量，规划，追踪以及许多其他元素的总和。

几十年来，开发团队们都在成本预算和时间限制上痛苦地挣扎着，但这不该是他们追求的至上目标。

更重要的目标是要转变。DeMarco现在说，去切实改变这个世界或一家公司或它运作的模式才是更重要的。

几乎是为了向自己推行了几十年将工程化原则应用于软件开发的想法表示忏悔，DeMarco说这场转变是我们一向应该关注实施的。

在我个人看来，DeMarco说设计规划一套软件的做法与词语软件开发是不同的，这毫无疑问，的确，有很多人开始怀疑开发软件到底是不是一种包含度
量控制和管理控制的工程化实务，而事实却是，软件本身并不像物理学那样有着坚实的科学理论基础，而是充满了抽象的概念，虚幻的构想甚至是一次次的试验研
究。

我职业生涯的美好回忆中就有自己提出的解决方案帮助公司进行重大转变的一系列例子，其实谦虚地说，我的这些方案在技术层面上一点也不特别，但它们对公司起到的效果却是立竿见影。这些直到现在我还能如数家珍般列出。

之前我说过这样一个例子，在这个例子中我给那个老板设计了使公司的毛利率报表自动化生成的方案，这确确实实改变了整个公司的文化。现在，这是一个有着巨大甚至是无限价值的软件项目。

具有讽刺意味的是，DeMarco的新式哲学有可能很早以前就存在了。2003年我读了Ed
Yourden所着的第二版《Deathmarch》（Deathmarch预示失败的开发项目），惊异于其中一部分内容，在那里面，Yourden试图
界定适用于类似Microsoft Word这样巨型开发项目的度量标准。

Yourden详细叙述了他打电话给微软，询问软件有多少行代码的事，结果微软技术服务人员在电话另一头说不知道，他又问这个项目有多少开发人员，
答复依然是不知道。Yourden继续问着这些叫人无法回答的问题，最后那个技术服务人员火了：你难道不知道吗？我们卖出了数千万套软件，谁管开发成本是
多少？

当然，随着今年早些时候的裁员，微软也许现在会计算成本，但Yourden之类的作者们在最近十年早些时候肯定有证据表明项目的成本和可度量性会随着回报率的升高而重要性降低。

我认为没有人去超越这个观点的原因是众所周知的将软件与已确定的工程化原则相关联的必要性，尽管二者之间存在着明显不同，比方说建造一幢建筑与开发一款文字处理软件。

确实，有人经常说相比一门科学来说，开发软件可能更是一门艺术，我越来越倾向于这种说法。我把它看成是一种工艺，一项技巧，一个创造过程。当编程理
论能被教授时，它更像是一套音乐或绘画的理论，除非你有天生的创造表现力，否则你不可能立志要成为有史以来最伟大的程序员或音乐家或艺术家。

与Agile Development严格的瀑布方法论和在它之前的应用程序快速开发（RAD）渐行渐远的当代趋势同样支持了DeMarco的说法：实际上，他发现的事实已在我们身边存在了很多年。
现在的问题是，没人敢站出来大声说：我们不再需要软件工程这个概念！