计算机科学vs软件工程 什么是软件工程过程

什么是软件工程过程  

什么是软件工程过程

软件工程过程的定义：
软件工程过程是将用户需求转化为软件所需的软件工程活动的总集。
这个过程可能包括投入、需求分析、规格说明、设计、实施、验证、安装、使用支撑和文档化，还可能包括短长期的修复和升级以满足用户增长的需求。因为维护没有被普遍接受，所以在这里没有包括进来。在美国国防部(DoD)维护包括软件修复和升级，而在商业计算机领域它是指提供服务、修复软件缺陷但不包括升级。
由于用户的需求和使用环境具有不可预知性，因此软件工程过程是一个学习改进的过程。这可能需要专门的研究用户需求，将其具体化在需求定义中，并随着在设计和实现过程中获得的更多知识进行调整。
软件工程过程的范围：
软件工程过程开始于实现软件中某项任务的决定。但它不包括如下这些与系统有关的活动：定义系统的总体目标和需求;在软硬件之间划分系统的功能;定义软硬件的接口;进行软硬件之间的整合和测试;整个系统的可接受性的测试和操作。
虽然上述这些活动是必不可少的，它们或许还需要相当的软件技能，但它们应当划分在系统设计或者系统管理当中，而不应该是软件工程过程的一部分。
软件过程架构：
一个软件过程架构是一个框架，在这个框架中一个项目的具体过程被定义了。
虽然应用在具体项目中的软件工程过程应当反映特殊性，但一个框架却需要提供项目间的共同属性。一个软件架构包括关键检查点，任务，允许采用的通用技术、方法和度量的说明。这样既带来了标准化的许多好处，又能根据项目需要灵活调整。此外，它还提供了一个评估和改进软件工程过程的框架。

软件工程过程包含哪几个过程

围绕工程设计、工程支持以及工程管理已提出了以下四条基本原则：
(1)选取适宜的开发模型
该原则与系统设计有关。在系统设计中，软件需求、硬件需求以及其它因素间是相互制约和影响的，经常需要权衡。因此，必需认识需求定义的易变性，采用适当的开发模型，保证软件产品满足用户的要求。
(2)采用合适的设计方法
在软件设计中，通常需要考虑软件的模块化、抽象与信息隐蔽、局部化、一致性以及适应性等特征。合适的设计方法有助于这些特征的实现，以达到软件工程的目标。
(3)提供高质量的工程支撑
工欲善其事，必先利其器。在软件工程中，软件工具与环境对软件过程的支持颇为重要。软件工程项目的质量与开销直接取决于对软件工程所提供的支撑质量和效用。
(4)重视软件工程的管理
软件工程的管理直接影响可用资源的有效利用，生产满足目标的软件产品以及提高软件组织的生产能力等问题。因此，仅当软件过程予以有效管理时，才能实现有效的软件工程。

软件工程(SoftWare Engineering)的框架可概括为：目标、过程和原则。 (1)软件工程目标：生产具有正确性、可用性以及开销合宜的产品。正确性指软件产品达到预期功能的程度。可用性指软件基本结构、实现及文档为用户可用的程度。开销合宜是指软件开发、运行的整个开销满足用户要求的程度。这些目标的实现不论在理论上还是在实践中均存在很多待解决的问题，它们形成了对过程、过程模型及工程方法选取的约束。 (2)软件工程过程：生产一个最终能满足需求且达到工程目标的软件产品所需要的步骤。软件工程过程主要包括开发过程、运作过程、维护过程。它们覆盖了需求、设计、实现、确认以及维护等活动。需求活动包括问题分析和需求分析。问题分析获取需求定义，又称软件需求规约。需求分析生成功能规约。设计活动一般包括概要设计和详细设计。概要设计建立整个软件系统结构，包括子系统、模块以及相关层次的说明、每一模块的接口定义。详细设计产生程序员可用的模块说明，包括每一模块中数据结构说明及加工描述。实现活动把设计结果转换为可执行的程序代码。确认活动贯穿于整个开发过程，实现完成后的确认，保证最终产品满足用户的要求。维护活动包括使用过程中的扩充、修改与完善。伴随以上过程，还有管理过程、支持过程、培训过程等。 (3)软件工程的原则是指围绕工程设计、工程支持以及工程管理在软件开发过程中必须遵循的原则。

软件工程过程各步骤由什么岗位的人负责

个人软件过程(Personal Sofare Process，PSP)是一种可用于控制、管理和改进个人工作方式的自我持续改进过程，是一个包括软件开发表格、指南和规程的结构化框架。PSP与具体的技术（程序设计语言、工具或者设计方法）相对独立，其原则能够应用到几乎任何的软件工程任务之中。PSP能够说明个体软件过程的原则； 帮助软件工程师作出准确的计划；确定软件工程师为改善产品质量要采取的步骤；建立度量个体软件过程改善的基准；确定过程的改变对软件工程师能力的影响。

软件工程过程通常包含哪四种基本活动？

1.P（Plan）软件规格说明
2.D(Do)软件开发
3.C(Check)软件确认
4A(Action)软件演进

系统验收鉴定书中的软件工程过程怎么写

这其实就是表达一下软件整个实施过程。
第一部分简单说一下方法论及其优势。如瀑布模型、快速原型、迭代模型等。
然后根据模型说下大致的总体计划，并按每个阶段说下一各阶段都做了哪些事情。
基本就可以了。
另外这种鉴定书是组织要求，最好填写之前找鉴定书的要求方或有经验的同时确认一下填法，别填错或填过头了。

软件工程过程有哪几种基本活动？试加以说明

你好哦楼主~
很高兴看到你的问题。
但是又很遗憾到现在还没有人回答你的问题。也可能你现在已经在别的地方找到了答案，那就得恭喜你啦。
对于你的问题我爱莫能助！
可能是你问的问题有些专业了，或者别人没有遇到或者接触过你的问题，所以帮不了你。建议你去问题的相关论坛去求助，那里的人通常比较多，也会比较热心，能快点帮你解决问题。
快过年了，
最后祝您全家幸福健康快乐每一天！

什么是软件工程硕士？

软件工程硕士即软件工程专业的硕士学位。
软件工程是一门研究用工程化方法构建和维护有效的、实用的和高质量的软件的学科。它涉及程序设计语言、数据库、软件开发工具、系统平台、标准、设计模式等方面。在现代社会中，软件应用于多个方面。典型的软件有电子邮件、嵌入式系统、人机界面、办公套件、操作系统、编译器、数据库、游戏等。同时，各个行业几乎都有计算机软件的应用，如工业、农业、银行、航空、政府部门等。这些应用促进了经济和社会的发展，也提高了工作效率和生活效率 。
硕士是一个介于学士及博士之间的研究生学位，拥有硕士学位者通常象征具有对其专注、所研究领域的基础的独立的思考能力。硕士课程通常安排在学士之后，一般而言全职的硕士课程需要二年的时间，但根据国家及科系不同，有的硕士只要一年就能取得，有的则需要三至四年。

什么是软件工程化时代

本文译自著名IT顾问和评论员David M Williams的博客，在这里，他提出了关于软件开发的全新理念。
Tom DeMarco是著名的Peopleware: Productive 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 Sofare 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的说法：实际上，他发现的事实已在我们身边存在了很多年。
现在的问题是，没人敢站出来大声说：我们不再需要软件工程这个概念！