软件工程大作业.docx

软件工程大作业.docx

《软件工程大作业.docx》由会员分享，可在线阅读，更多相关《软件工程大作业.docx（8页珍藏版）》请在冰豆网上搜索。

软件工程大作业

软件工程课设报告书

学院：

软件学院

班级：

16网安

姓名：

范澜灵

学号：

75

浅谈对软件工程项目开发

本人虽是网络工程方向专业的学生，但经过这一学期来所上的软件工程课，收获颇多，就此对软件工程项目整体设计到开发发表一下自己的浅见，不足之处望各位读者老爷海涵。

一个项目总得来说不一定是给了你具体题目的，但总会是给你一个主题，在这个主题范围内找一个合适的题目，对吧？

打个比方，比如我要开发一个项目，然后首先是要拿到这个项目的主题，通俗点来说就是这个项目是要做啥，做游戏？

做网站？

还是做软件应用。

有了主题之后你才能从整体、大局上来构造这个项目的框架——“提纲”。

这个框架就如同你写作文时的提纲，要让开发者清楚的明白自己该做相对于项目来说的什么模块。

我的理解一直就是项目是由多个模块合成的，因此不太可能是大点的项目就只让某一个程序猿来做，每个程序员他总有自己所擅长的和所不擅长的模块，因此“物尽其用人尽其才”就是项目经理所应达到的最高境界，合理的了解你项目内的各成员的性格特征、程序手法的特点来恰当并适宜的让他发挥出自己百分百的能力。

以上呢，都只能算是自己听了软件工程这门课后，一个软件工程菜鸟对软件如何开发谈出了自己的见解，正在学习中，也正在纠错的道路上。

软件开发的方法有下面六种：

1.敏捷;2.瀑布;3.Scrum;4.极限编程5.快速应用程序开发方法;6.螺旋

先讲敏捷这一开发方法。

敏捷软件开发是承担软件工程项目的概念框架。

有许多像Scrum这样的敏捷软件开发方法论（我们将在本文中更多地介绍它），Crystal方法和动态系统开发模型。

敏捷方法的主要目标是通过在短时间内开发软件来降低风险，称为迭代，通常会持续一到四周。

每个时间盒就像一个迷你软件项目，包括发布新增功能的所有必要任务：

规划，需求分析，设计，编码，测试和文档。

迭代可能不会增加足够的功能来保证发布产品，但是敏捷软件项目打算在每次迭代结束时发布新软件。

在此迭代之后，团队重新评估项目优先级。

敏捷方法强调工作产品是进度的主要衡量标准。

相对于其他方法，敏捷产生很少的书面文档-“实时”是更好的通信类型。

大部分开发团队成员（以及企业主）都位于附近，可以面对面沟通。

敏捷软件开发方法学的主要原则：

面对面会议，持续合作，早期和持续交付工作软件，透明度。

每当客户端或内部发生意外或频繁的变化时，该模型就成为经理和团队领导者的最佳选择。

它的优点是：

1.自适应方法对变化做出有利的回应，允许直接沟通以保持透明度;2.通过快速查找和修复缺陷并提前识别期望不匹配来提高质量。

它的缺点是：

专注于使用软件并缺乏文档效率，结果不一致的机会不明确。

下面说的是瀑布这一软件开发方法。

瀑布模型是一种循序渐进的开发方法，其中开发被视为通过几个阶段稳步向下（如瀑布），通常：

1.分析;2.软件需求说明软件设计;3.软件设计;4.测试;5.整合（如果有多个子系统）;6.部署（或安装）;7.维护。

该方法的线性和刚性特性使其易于理解和管理。

所以对于经验不足的经理和团队来说，这是理想之选在这种方法中，完成了不同的目标。

在进入下一个阶段之前，每个阶段必须完成100％，不要回头修改项目或方向。

从理论上讲，这个过程导致项目按时交付，因为每个阶段都有详细的计划。

它可以用于目标明确，需求稳定的项目。

但在实践中，瀑布式开发通常不能达到预期，因为它不包含大多数项目所必需的不可避免的变化和修订。

当一个应用程序正处于测试阶段时，很难回头去改变在概念阶段没有想到的东西。

重点是一次性规划，时间安排，目标日期，预算和整个系统的实施。

在开始下一阶段之前，通过大量书面文件，正式评审以及用户的批准/签收和大多数阶段结束时发生的信息技术管理，在项目的整个生命周期内保持严密的控制。

书面文件是每个阶段的明确可交付成果。

尽管缺乏灵活性和过时的想法，但这种方法旨在摆脱不必要的文书工作，耗时的定期会议和积压。

因此，对于预先了解开发的所有方面的小型项目而言，这是一个很好的选择，对于复杂项目来说这是一个不好的解决方案，因为它非常不灵活。

在公司或者老板有明确要求和解决方案的情况下，不需要定义流程来开发最终产品。

老板只需在完成项目时设定截止日期，并以开发团队自己的方式完成项目。

优点：

1.易于理解和功能;2.简单到足以处理模型是僵化的;3-节省大量的时间;4.允许简单的测试和分析;5.它允许部门化和管理控制。

缺点：

1.只匹配精确的需求;2.不适用于维护项目;3.不允许在测试阶段进行编辑;4.无法知道项目的可能结果;5.对于长期和正在进行的项目来说不是很好。

下面说的是Scrum这一软件开发方法。

Scrum是一个用于管理产品开发的迭代式和增量式敏捷软件开发框架。

它定义了一个灵活的整体产品开发策略，开发团队作为一个单元实现共同目标。

这种方法使团队能够通过鼓励所有团队成员的实际共同定位或紧密的在线协作以及所有团队成员和所涉及的学科之间的日常面对面交流来自我组织。

Scrum的一个关键原则是双重认识，即客户会改变他们想要或需要的东西（需求波动）并且会改变他们的想法。

Scrum采用基于证据的经验方法-接受事先不能充分理解或定义的问题，而是集中关注如何最大限度地提高团队的快速交付能力，响应新兴需求，并适应不断发展的技术和变化在市场条件下。

Scrum的主要特点：

积极进行优先工作，完成一系列短迭代或冲刺中的固定积压项目，一个简短的每日会议（“scrum”）来解释进展情况，描述即将开展的工作和可能的障碍，一个简短的计划会话，其中将定义sprint的积压项目，当所有团队成员反思过去的冲刺时，一个简短的心跳回顾。

Scrum由Scrummaster提供，它的主要工作是消除阻碍团队实现冲刺目标的能力。

Scrum的主人并不是团队的领导者（因为他们是自组织的），而是团队与任何不稳定影响之间的生产力缓冲区。

该方法鼓励所有团队成员以及项目涉及的所有学科进行口头交流。

与看板不同，Scrum更具时间框架和计划性。

整个项目被分成称为Sprints的时间框，并且所有团队坐在一起并为每个Sprint计划需要完成的任务列表或用户故事列表。

一旦团队同意并承诺在给定的时间框架内完成某些任务，开发团队应该坚持承诺并完成Sprint中的所有任务。

如果延迟成本很高，最后期限应尽可能延迟，Scrum最适合。

当最终产品不清楚或者需求没有得到客户的正确反馈时，经常会使用Scrum。

在这里，客户参与整个过程，确定并关注需要完成的某些sprint产品待办事项（与团队一起）。

Scrum取代了灵活的方法论，适合长期发展，并且频繁更改需求。

换句话说，它适用于需要300多个小时的开发项目。

与瀑布不同的是，Scrum模型采用更灵活的规则，可以适应最后时刻的变化。

团队合作，检查和透明度是Scrum方法的关键因素。

结构：

1.产品积压（一组允许尽快建立MVP的最高优先级任务）;2.冲刺积压（包含开发人员将在2-4周后处理的高优先级功能）;3.冲刺本身;4.这种增长方法用于快速开发软件，其中包括一系列迭代以生成所需软件。

它使有意推进的项目步入正轨。

优点：

1.决策权掌握在团队的手中;2.业务需求文档被认为是不重要的;3.轻轻控制的方法empathizing与不断更新。

缺点：

1.处理方法因成本波动而受损:

2.不适合大型项目:

3.需要高度专业的团队，这对新手来说没有任何地方。

下面说的是极限编程这一软件开发方法。

极限编程方法（XP）指的是敏捷软件工程方法论。

它是为了避免开发目前不需要的功能而创建的。

它旨在创造一流的最终产品，而不考虑需求的频繁变化。

这种方法的另一个目的是降低软件必需品的成本。

为了实现这一点，应用持续测试和计划。

与其他方法相比，XP需要更多时间和人力资源。

至于XP主要用于在非常不平衡的环境中制作软件，并在建模过程中提供更好的易用性，这对于复杂的项目来说是完美的。

如果您的客户有最后期限来交付产品，但没有清楚地了解其工作方式，并且风险更高，那么这是最佳选择。

XP技术的设立是为了解决和缓解风险并提高成功的可能性。

与瀑布方法不同的是，系统的需求被确定并且通常被“冻结”，XP意味着在项目后期阶段改变需求的成本可能非常高。

XP团队应该在现场设立一个客户，为团队指定工作的优先次序，以及谁可以在问题出现时立即回答问题。

简单的代码更有可能工作。

因此，极端的程序员只能编写代码来满足当前项目中的实际需求。

为了回顾XP程序员编写的代码，共享一个屏幕和键盘（这也改善了通信），以便在编写代码时对所有代码进行审阅。

在极限编程中，测试是在编写代码之前编写的。

代码在通过测试时被认为是完整的（但是之后需要重构以消除复杂性）。

尽管人们认为XP只能在少于12人的小团队中工作，但它已被成功应用于超过一百名开发人员的团队。

优点：

1.它着重于客户参与:

2.制定合理的计划和时间表:

3.开发人员特别致力于该项目:

4.配备高质量软件的现代化方法。

缺点：

1.有效性取决于涉及的人员:

2.需要频繁召开会议以提高总成本:

3.需要过度的发展变化:

4.确切的可能性和未来的结果真的是未知的。

下面说的是螺旋这一软件开发方法。

螺旋方法扩展了瀑布模型，增加了快速原型，以结合自上而下和自下而上的概念。

它在重点领域重点考虑迭代风险分析。

它适合于大型复杂系统。

对于大型，昂贵和复杂的项目，螺旋通常选择瀑布方法。

螺旋生命周期模型是一个复杂的生命周期模型，重点在于及早识别和减少项目风险。

一个螺旋型项目从小规模开始，探索风险，制定一个处理风险的计划，然后决定是否采取下一步的项目（做下一轮迭代）。

它源于不断降低项目风险水平带来的快速发展收益。

成功使用螺旋生命周期模型取决于认真，细心和知识渊博的管理。

您可以在螺旋模型中找到以下步骤：

1.新的系统要求详细定义。

2.初步设计创建。

3.初步设计构建了新系统的第一个原型。

第二个原型使用四个步骤演变：

-第一个原型的评估;-确定第二个原型的要求;-计划和设计第二个原型;-构建并测试第二个原型。

如果风险很大，项目可能会中止。

风险因素可能涉及开发成本超支现有原型的评估方式与之前的原型相同，如果需要，还可以从中开发另一个原型，重复前面的步骤直到客户满意。

最终系统的构建（基于精制原型），最终的系统经过彻底的评估和测试，日常维护是持续进行的，以防止大规模故障并最大限度地减少停机时间，重点在于风险评估以及通过将项目分解成更小的部分并在开发过程中提供更多的易变性来降低项目风险。

开发者打算制定一个迭代螺旋的计划。

每个周期都涉及产品各个部分的相同步骤以及每个层次的细化。

任何螺旋生命周期模型的完成都基于对项目的一致，细致和熟悉的管理。

优点：

1.风险因素大大减少;2.非常适合大型和复杂的项目;3.稍后允许其他功能;4.适用于各种业务需求的高风险项目。

缺点：

1.昂贵的软件开发模式;2.风险分析阶段失败可能会损害整个项目;3.不适合低风险项目;4.可能会继续，永远不会完成。

上面讲出了软件开发的六种方法。

下面所列出的就是软件开发流程（个人的理解开发思路就是开发流程，若有不足之处望指出）：

1.软件分析时期：

a.可行性研究，可项目开发。

b.需求分析

2.软件设计时期：

a.概要设计。

b.详细设计

3.编码和测试时期：

a.编码。

b.测试。

c.运行。

d.维护

以上就是软件开发流程，也可以看做一个软件的生命周期

下面就是对上面所说软件开发流程的一个分析。

（1）首先我会组织我们项目组讨论关于这个项目的可行性分析，也就是每个人对这个项目的看法以及能否实现，也就是软件的生命周期的可行性研究，当然了，如果领导能接下这个任务的话，当然也知道我们应该能够拿下这个项目，当这一步完事之后，我们也就确定了可以开发这个项目，接着我们就要实施第二步。

（2）第二步我觉得我们应该开始和客户联系了，了解客户到底需要什么，这时候我觉得和客户联系的时候我们至少要去两个有开发经验的人，因为当客户说出需求的时候，他们应该是最能理解客户需要什么的，当他们第一次谈完之后，大体的需求在他们的脑子里面就已经具备了，这时候他们就要将这些需求转换成文字在word或者文字处理软件里面展示出来，同时这个阶段我觉得美工和数据库的前期设计应该也在进行，当我们将需求转换成文字之后，我们在会和客户确认信息是否这样开发，当和用户再次的商议之后我们再次的修改需求之后，这样我就觉得和客户的交互也就差不多了，这时候我们美工大致也能设计出来几个页面，让用户看一下，提出意见，然后修改，这样我们的第二步就完成了。

　　（3）当第二步完成的时候，接下来就是软件设计生命周期里面的概要设计和详细设计，但是我发现很多的项目团队都不太注重这块，当第二步完成的时候直接就进行编码，我个人认为这样做虽然前期比较快，但是在后期项目出现Bug的时候，就能体现出这块的重要性了，所以我建议这块我们大概设计一下，我觉得大家应该差不多知道概要设计和详细设计是什么意思吧，如果不知道的话可以给我留言，或者XX查找一下就清楚了，这样我们第三步就完成了。

　　（4）当我们第三步完成的时候，我认为我们的数据库设计也应该设计完了，如果没有，让其快速设计完成或者我们帮助他一块弄完，这时候就是我们开发人员的天下了，我们要和美工配合并且整理好没一个模块，我们在项目中经常会遇到这种现象，某一个模块出现了问题，而被迫让很多程序员停下工作等待，这种现象普遍存在，那么我们如何解决呢，个人认为当我们编码的时候我们开发人员应该多去相互沟通，以及应急的解决方案都很重要，这样我们就能减少那样的现象，对于我们程序员来说，Bug永远存在，记得曾经看到过这样一段话“大名鼎鼎的微软，可曾有连续三个月不发补丁的时候吗？

答案是：

从来没有”，这时候再我们开发人员和美工的同时努力下，我们的编码阶段就算是完成了，这时候，我们的项目就要进行测试了。

　　（5）测试：

一个好的项目必须经得住测试人员的测试，测试有好多方法，什么黑盒，白盒，站内，站外等等，我对测试的了解不是很多，所以具体也不知道测试人员是如何测试的，当我们测试完我们的项目之后，交给用户进行使用，用户使用后感觉可以，也就是测试完成之时，当我们完成测试之后，我们需要写一些帮助文档之类的记录，这样我们前期的软件测试就算是完了，当然后期我们可能还会进行测试，因为我们不可能一下子开发一个非常完美的项目，这样我们第五步就完成了。

　　（6）第六步我们就要开始对软件的交付进行准备工作，其实这个阶段我觉得挺重要的，因为是和用户的接触，当我们软件测试完成我们的软件测试，并且达到了要求之后，我们的软件开发者应该向客户提交开发的产品，用户手册，用户如何使用等一些客户需要的东西，然后将客户的产品发布上线，这一阶段我们就完成了。

（7）最后，当用户验收过项目之后，我们的项目团队的一个项目就完成了，只有后期的维护工作，这时候我们项目组织庆祝的庆祝，该拿项目奖金的拿项目奖金。

以上呢，有些软件开发的知识最先不是很了解，通过通读网上的有些相关文章，也慢慢的明白了软件开发的流程及思路和软件开发过程中所要用到的六大方法，当然说自己毕竟也没亲身经历过软件开发，所以其中有一些见解和体会可能属于“纸上谈兵”，不足之处望多多包涵。

但通过这门软件工程课的学习和做的这个有关软件开发的大作业，让我了解学习了一些软件工程方面的相关知识。

感谢老师所布置的作业，同时也感谢自己能不再懒惰地去认真实践搜索了解了相关内容！