爱华网计算机种类繁多。实际来看，计算机总体上是处理信息的工具。根据图灵机理论，一部具有最基本功能的计算机应当能够完成任何其它计算机能做的事情。下面是小编给大家推荐的大学计算机专业相关论文范文，希望大家喜欢!
大学计算机专业相关论文范文篇一
《浅析软件项目过程管理矩阵模型研究与实践》
关键词：软件项目管理;过程控制;矩阵模型;需求管理
摘要：软件项目由于应用的领域不同，一般涉及众多的业务知识领域，项目成果也应以软件的逻辑产品来体现，其最终成果及实现过程的可见性、可度量性相对较弱。因此，软件项目管理比一般工程项目要复杂得多。基于软件项目管理的特点分析，并结合软件项目开发管理经验，讨论了软件项目组织架构、计划与过程控制等软件项目管理要素，提出了矩阵式项目管理模型，分析了该模型中业务知识与计算机技术共同作用所能达到的最佳效果，讨论了需求管理模型及其应用，实践证明该模型是行之有效的。
O引言
项目管理是伴随着项目进行而进行的，是一种为了满足甚至超越项目所有者对项目的期望而将理论知识、技能、工具和技巧应用到项目中的管理活动，是一门关于项目资金、时间、人力等资源控制的管理科学。
顾名思义，软件项目管理就是项目管理在软件领域的应用，是一种为了能够按照预定的工期、质量顺利完成软件项目而对成本、人员、进度、质量、风险等进行控制管理的活动。其核心在于通过有效的管理，明确项目范围，合理调配人力资源，提高项目团队的整体开发能力，优化项目执行过程，控制项目成本，为用户提供满意的软件产品。
1软件项目管理的特点
软件是一种特殊的产品，这种产品的特殊性之一就是它的生产活动是以项目的形式进行的，因此，项目管理对软件生产具有决定性的意义。软件项目管理除了具有一般项目管理的特点外，还有其独特之处，主要表现在：
(1)软件产品缺乏硬性度量指标。
软件的最大特点在于一个“软”字，它不像建筑项目，最终可以有一个实物，可以用某一个标准去刚性的度量评价。而软件产品客观上具有“不可见性”，表现在它没有一个可见的实物，还表现在其度量指标也不能像度量实物那样具有明确性。有效的项目管理就是要使软件及其生产过程由不可见、不可度量变成可见和可度量。
(2)重视应用领域的业务知识。
对于计算机应用软件来说，它并不单纯是计算机技术问题，更多地表现在它所服务的业务领域的知识技能。如企业ERP、SCM等应用软件项目，计算机只是它的载体，计算机技术往往并不起决定作用，而与之相关的业务知识、管理知识显得更加重要。
(3)管理比技术本身更重要。
软件项目是一项计算机技术、信息技术、管理科学等多学科交叉的系统工程。随着信息技术的发展，软件项目应用领域不断扩张、项目规模不断扩大、项目业务日趋复杂，一个软件从构想到完成，需要大量的从事不同工作的人共同努力，个人单打独斗的作坊式开发方式显然已经无法适应这种信息技术发展的需要。在一个大型信息系统工程项目里，需要系统策划人员、分析设计人员、编程人员、测试人员和用户等众多人员的共同参与和密切配合，如何将可用资源有效地结合在一起，并使之发挥最大效率，如何保证项目按照预定的时间将预先约定的软件产品提交给客户是软件项目管理的核心任务。项目管理往往成为决定软件项目成败的重要因素。
(4)强调文档的重要性。
文档是软件产品的重要组成部分，软件项目管理以工程化的管理方法，强调规范文档的重要性，在软件生命周期的各个阶段，强调对里程碑文档的评审，并把文档作为阶段成果的重要体现和下阶段的基础。
(5)重视培训与服务的价值。
培训与服务是发掘软件产品价值的重要手段。一个软件产品，如果没有人使用就不能形成价值，如果不会使用，就可能降低软件的价值。服务的优劣已经直接影响软件的使用价值并决定软件产品的生命周期。总之，软件项目管理重视培训与服务在软件增值中的意义。
2管理架构矩阵模型
规范化的管理体现在：有完整的基于软件开发标准(如CMM、ISO等)的开发流程;有基于这个流程的完整详细的开发计划;有基于开发计划的成本预算和成本控制方法;有明确的阶段检查措施和评价标准;有明确的质量管理体系和质量保证实施手段，保证项目在可控状态下进行。而这一切都需要有一个组织有效的管理团队和运作规范的管理架构。
在软件项目管理过程中，项目经理起着至关重要的作用。对于项目经理，目前有两种观点：一种认为软件项目经理应该是计算机某方面的应用专家，能够对项目组成员给予技术指导，如此才有能力合理安排工作。另一种观点则认为，项目经理应该是职业经理，他可以不是计算机技术专家，但应该是管理专家，具备轻松调配各部门资源的技巧和有效地组织、管理开发队伍、协调沟通的能力，他的作用主要体现在协调、管理、合理安排成员的工作，控制项目进度和费用，与用户沟通，等等。事实上，在一般意义上，不管是技术型专家还是管理型专家都无法满足现代软件项目管理的需要。在传统的垂直型管理模式中，项目经理要直接管理到具体的程序员，一般只适用于不太复杂的技术型项目，它忽视了中间层的作用，不便于发挥员工的积极性。而扁平化管理意味着要面对很多的直接下级，对管理者提出了很高的管理要求，特别对于大型项目来说，可能涉及到很多业务领域知识，他都要面面俱到，这对于一个不管是技术型还是管理型项目经理来说似乎都很难做到，即使对于所谓既懂专业又懂管理的全才专家来说，也不可能要求他在各个方面都是最优秀的。
众所周知的事实是，找一个既懂专业又有项目管理经验的专家往往比较困难，但如果找几个或懂专业或懂项目管理的专家也许并不困难。一个好的软件项目团队就应该是它可以有效整合各成员的能力，使集体的能量达到最大化。因此，与其找一个所谓全才的项目经理，还不如构建规范的管理架构。根据笔者多年的软件开发、项目管理的实践和经验，提出了“矩阵式”软件项目管理模型。在这个模型中，项目经理也只是其中的一个角色而已。他并不需要面面俱到，也不需要掌握项目的全部细节，他要做的全部工作就是按管理规范要求完成项目经理这个角色所特有的工作。在这个架构下，更便于发挥项目团队中备人所长，使集体的智慧得以充分张扬。每个人所做的工作(包括他的知识)都已经留存下来了，即使项目经理因故离职，接任者也可以从容接手，从而降低了因为人员流动可能对项目造成的风险。
如表1所示，是某项目管理架构的矩阵模型。每个业务子系统有一个业务专家负责，他们一般都精通某一个方面的业务，由他们直接面对用户，可以与用户业务人员有更多的共同语言，便于交流，更容易捕获用户需求。而在软件开发的每个阶段，按软件工程生命周期，各阶段由具有技术专长的技术人员负责。所以，整体上可以充分发挥各业务负责人精通业务领域知识和阶段负责人精通相关技术的优势，使项目团队整体成为名副其实的既懂专业又懂管理的专家。
矩阵管理可以更好地发挥各专业人员的业务专长，又能更好地发挥各技术层面技术人员的特长，项目经理重要的工作就是协调，重点在于如何结合众多资源控制整个开发进程。矩阵模型也有利于软件公司人才战略，有利于组织内部人才的培养，充分展现个人的发展空间。大多数软件企业也许都很难有精通所有专业的全才，但都拥有为数众多精通某一类业务的系统分析师，或精通某一类专门技术的专门人才。根据矩阵模型，公司可以培养员工向不同方向发展，有技术特长的，培养他发展技术的深度，有其他专业特长的，比如精通税务、金融、企业管理等，则培养成业务专家。这样，在人尽其才的同时，又有利于留住人才，稳定了软件开发队伍。
3计划与过程控制
项目计划包括风险管理计划、质量管理计划、人力资源计划、环境资源计划等。软件项目计划和过程控制为消除或削弱软件的“不可见”带来的不确定性提供了很好的保障措施。基于任务分解(WBS)的工作分配和项目组织结构，明确每个项目开发人员的责任以及他们之间的连接，把整个项目周期划分为若干个小的阶段，每个阶段都有明确的目标和阶段成果及其确认准则。由于把每个阶段要完成的工作、预期的成果都清晰地描述出来了，一方面，可以使用户不断看到一个个阶段成果，而不是在项目全部完工后才看到一个大的成果，增强了用户的信心;另一方面。通过明确的阶段结果，随时收集有关项目进程数据，按计划规定进行进度管理，使开发过程和阶段成果都是可见的，也便于发现问题、控制开发过程，不至于什么问题都要到最后才一次暴露，减少了项目风险。
当然，如果仅仅有好的项目计划而缺乏有效的执行机制和监督措施，项目仍然可能失去控制。成功项目的标志是在规定的时间、合理开支的条件下，完成约定的需求，实现系统的最终目标。有效实施项目进度控制是项目成功的重要保障，是每一个项目经理必须非常重视的工作。实现有效项目过程控制的方法主要是通过定期和不定期的检查体现的。
(1)阶段检查。
不定期的阶段性检查，一般在关键任务或里程碑任务的计划完成时进行的，即在项目的每个阶段结束时都要经过详细的评估。检查的重点是该阶段里程碑任务是否完整地实现了，是否可以转入下阶段的工作。
(2)定期检查。
为了随时掌控项目进度执行情况，建立定期信息报告制度是一个行之有效的措施。定期的检查一般分周例会和月例会，例会检查的重点是：需求列表、风险列表、计划执行情况、质量保证情况等。通过周报月报，沟通并掌握各方信息，对存在的问题和困难进行汇总，提交例会处理解决，降低不确定性因素对项目工期的影响，保证项目顺利进行。
定期或不定期地对项目进度计划表进行检查，对于不合格的项目进度计划表或未按照项目进度计划表执行的项目给予相应处理，及时发现问题，尽早调整计划偏差，最大限度地避免损失。这样，在项目进行过程中就比较容易把握每个阶段项目的进展情况，方便对项目组成员的绩效进行阶段性评估，便于统一项目经理和客户的认识。增加项目风险的可控性。
4需求管理矩阵模型
软件项目的最大难点往往在于需求的不确定性，所以，有人认为好的需求是软件项目成功的一半。需求的困难主要表现在计算机技术人员与用户业务人员由于不同的语境，存在沟通困难。用户业务人员可能不清楚计算机系统实现细节，或并不知道需求人员到底需要了解什么，而计算机技术人员可能由于不熟悉业务，往往又缺乏引导用户表达需求的业务素质和技巧，所以，影响了双方沟通和交流，造成的结果可能是用户往往不能清楚地描述自己的需求或计算机人员不能准确地理解需求，从而影响了需求的最终描述。另一方面，对于管理信息系统来说，需求的不确定还表现在业务流程的变化上，特别对于现阶段还处于不断变革时期的我国企业来说，情况更是如此。
一般来说，用户在看到最终系统以后，通过不断地应用实践，激发了用户的联想，就可能提出新的或改进的需求。所以，在项目一开始，技术人员就必须对此有充分的认识，既要尽可能全面了解现有需求，也要充分预计到可能的需求变更，为系统设计留有变更或扩充的余地。另一方面，应该尽可能让用户尽早介入，直接参与阶段评审和验收，以便及时发现需求执行偏失，不至于什么都等到全部完工后才发现问题，才一并解决问题。在项目的后期改正一个错误的代价往往是在前期的数倍。所以，需求管理成为软件项目成败的另一个关键因索之一。
根据笔者的经验，建立需求矩阵跟踪表是进行需求管理很好的工具。通过跟踪表，项目涉众可以随时了解关于软件需求的实现过程。用户可以从中随时看到阶段性成果，方便用户及时测试、确认已实现的需求，便于用户积极参与，便于及时发现问题，改正问题。
5结束语
当代信息技术正以超乎寻常的速度发展，软件项目规模不断扩大，应用日趋复杂，失败的案例屡见不鲜，人们逐渐把眼光聚焦到关于软件项目管理方法的研究，项目管理正逐渐成为当今世界解决软件危机的一种主流管理方法。矩阵模型已在大量的工程实践中被证明是行之有效的。
大学计算机专业相关论文范文篇二
《基于TCP的拥塞控制策略研究》
摘要：随着网络技术的发展，网络拥塞日益严重，如何解决拥塞，充分、高效地利用网络资源，成为当今急需解决的问题。由于Internet上大多数业务都采用TCP协议，因此TCP的拥塞控制机制对控制网络拥塞具有特别重要的意义。本文分析了TCP的四个交互式拥塞控制算法：慢启动、拥塞避免、快速重传和快速恢复，介绍了TCP基于窗口的拥塞控制策略和目前常用端到端拥塞控制算法，并对它们的性能进行仿真比较。
关键字：AIMD;拥塞控制;TCP;NS
1引言
在Internet上，随着信息传送量的逐渐增大和网络组成的日益复杂，网络发生拥塞的可能性越来越大。网络中的拥塞来源于网络资源和网络流量分布的不均衡性，它不会随着网络处理能力的提高而消除。目前为止拥塞问题还没有得到很好的解决，因此网络拥塞的避免和控制成为越来越重要和急待解决的问题。
Internet中拥塞控制的大部分工作是由TCP完成的，目前标准的TCP协议实现都包含了一些避免和控制网络拥塞的算法。当今Internet的可靠性和稳定性与TCP拥塞控制机制密不可分，而TCP的成功也要归功于其稳固的拥塞控制机制。拥塞控制是确保Internet鲁棒性(robustness)的关键因素，因此成为当前网络研究的一个热点问题。
2TCP基于窗口的拥塞控制策略2.1加法增加乘法减少(AIMD)窗口算法
TCP是Internet中最流行的端到端传输协议，为主机之间提供可靠按序的传输服务。在现有的TCP/IP协议体系下，TCP拥塞控制机制主要基于加法增加乘法减少(AIMD)算法。在该算法中主要用到三个窗口变量：
(1)拥塞窗口(cwnd)：限定源端在拥塞控制中在一定时间内允许传送的最大数据量，是来自源端的流量控制。
(2)通告窗口(awnd)：连接建立及传输过程中，接收端向源端通告的最大可接收速率，是来自接收端的流量控制。
(3)有效窗口(win)：源端数据发送的实际窗口大小，限定为win=min(cwnd，awnd)。
由于计算机计算能力和存储能力的提高，通告窗口一般都比较大，因此当前发送窗口的大小大多数情况下等于拥塞窗口的大小。
AIMD的具体工作过程为：
(1)源端每收到一个ACK，拥塞窗口按下式增加：
Incr=MSS×(MSS/cwnd)(MSS为分组大小)
cwnd=cwnd+Incr
也就是，如果每个发出的分组都在最近的RTT(往返时延)时间内获得确认，源端就将cwnd增加1，即加法增加。
(2)当发生超时，TCP将超时看作拥塞的标志，并减小发送速率。每发生一次超时，源端重新计算拥塞窗口值：
cwnd=cwnd/2
也就是，一次超时，拥塞窗口值减为当前值的一半，即乘法减少。
2.2TCP拥塞控制的四个阶段
2.2.1启动阶段
当连接刚建立或超时时，进入慢启动阶段。
当新建TCP连接时，拥塞窗口(cwnd)被初始化为一个数据包大小。源端按cwnd大小发送数据，每收到一个ACK确认，就增加一个数据包发送量，这样慢启动阶段cwnd随RTT呈指数级增长。
慢启动采用逐渐增大cwnd的方法，可以防止TCP在启动一个连接时向网络发送过多的数据包而造成不必要的数据丢失和网络拥塞，并且它还能够避免采用单纯的AIMD算法造成的吞吐量增加过慢的问题。
为了防止cwnd的无限制增长引起网络拥塞，引入一个状态变量：慢启动阈值ssthresh。
当cwnd
当cwnd>ssthresh时，使用拥塞避免算法，减缓cwnd的增长速度。
2.2.2拥塞避免阶段
当TCP源端发现超时或收到3个相同的ACK确认帧时，即认为网络将发生拥塞，此时进入拥塞避免阶段。
在拥塞避免阶段，慢启动域值ssthresh将被设置为当前cwnd的一半，当发生超时时，cwnd被置为初始值1。此时，如果cwnd=ssthresh，则执行拥塞避免算法，即cwnd在每次收到一个ACK确认时只增加1/cwnd个数据包。拥塞避免阶段cwnd随RTT呈线性增长。
2.2.3快速重传和快速恢复阶段
在拥塞避免阶段，当数据包超时时，cwnd被置为1，重新进入慢启动阶段，这会导致过大地减小发送窗口尺寸，降低TCP连接的吞吐量。因此，引入了快速重传和快速恢复机制。
在快速重传阶段，当源端收到3个或3个以上重复的ACK时，就判定数据包丢失，同时将ssthresh设置为当前cwnd的一半，并重传丢失的包，进入快速恢复阶段。
在快速恢复阶段，每收到重复的ACK，则cwnd加1;收到非重复ACK时，置cwnd=ssthresh，转入拥塞避免阶段;如果发生超时重传，则置ssthresh为当前cwnd的一半，cwnd=1，重新进入慢启动阶段。
这种方法避免了数据包超时后就重新进入慢启动阶段，提高了TCP连接的吞吐量。
3典型TCP拥塞控制算法分析
3.1TCPTahoe算法
Tahoe算法是TCP的早期版本。它的核心思想是：让cwnd以指数增长方式迅速逼进可用信道容量，然后慢慢接近均衡。Tahoe包括3个基本的拥塞控制算法：“慢启动”、“拥塞避免”和“快速重传”。
(1)慢启动：避免了连接建立时突发数据流对网络的冲击。
初始设置cwnd为1，并按指数型方式增长，直至cwnd超过ssthresh。
当cwnd>=ssthresh时，Tahoe进入拥塞避免阶段。
(2)拥塞避免：限制传输过程中无限制的速率增长，避免由此可能导致的拥塞。
cwnd以线性方式增长。
如果发生超时或者连续收到3个重复ACK，Tahoe认为发生了拥塞。
对于超时，置ssthresh为当前拥塞窗口的一半，cwnd=1，转入慢启动。
如果收到3个连续ACK，则Tahoe进入快速重传阶段。
(3)快速重传：根据3个重复的应答报文来判断丢包，减少了超时重传的发生，加快了源端对拥塞的响应，使得拥塞能快速消除。立即重传丢失的分组，同时置ssthresh为当前拥塞窗口的一半，cwnd=1，转入慢启动。
Tahoe算法存在着不足之处：在收到3个重复ACK或在超时的情况下，Tahoe置cwnd为1，然后进入慢启动阶段。这一方面会引起网络的激烈振荡，另一方面大大降低了网络的利用率。
3.2TCPReno
针对Tahoe算法的不足之处，1990年Jacobson在Tahoe的基础上提出了改进算法Reno。改进主要有两个方面：一是对于收到连续3个重复ACK，算法不经过慢启动，而直接进入拥塞避免阶段;二是增加了快速重传/快速恢复机制。具体实现过程为：
(1)收到三个重复的ACK，进入快速重传/快速恢复，此时ssthresh设置为当前拥塞窗口的一半。
(2)重传丢失的数据包，并置cwnd=cwnd+ndup(ndup为收到的重复ACK数)。
(3)发送新的数据包。
(4)当收到非重复的ACK时，cwnd=ssthresh。
(5)进入拥塞避免阶段。
从上面的过程可以看出，Reno在收到3个重复ACK后，就转入快速重传/快速恢复阶段;而遇到超时时，Reno和Tahoe一样进入慢启动阶段。
Reno目前被广泛采用，以其算法的简单、有效和鲁棒性成为TCP源算法的主流。但是如果在一个发送窗口内有多个包丢失时，该算法不能有效恢复出来，为此提出了一些改进，如NewReno、Sack等。
3.3 TCP NewReno
NewReno对Reno中“快速恢复”算法进行了补充，它考虑了一个发送窗口内多个报文同时丢失的情况。在Reno算法中，发送方收到一个不重复的应答后就退出“快速恢复”状态。而在NewReno中，只有当所有报文都被应答后才退出“快速恢复”状态。
具体执行过程是：在快速恢复期间，TCP发送端收到一个ACK后，发送端通过此ACK应答推断出下一个丢失的数据包序列号，并且立即重传那个数据包。这样，NewReno在每个RTT内重传一个丢失的数据包，直到发生多个数据包丢失的窗口中所有丢失数据包被重传，而不是等到超时。在这个期间如果还有其它重复的ACK到来，则继续快速恢复算法，直到在快速恢复初始时所有未确认数据包都被确认。
NewReno的实现只要修改TCP发送端的实 现代码，实现简单。
3.4 SACK(selective acknowledgement，选择性应答)
SACK也关注一个窗口内有多个报文的丢失，它使用“选择性重传”策略，提高TCP在拥塞较严重且一个窗口中有多个分组丢失时的性能。SACK的基本思想是：接收方TCP发送SACK分组来通知发送方接收数据的情况，这样源端就能准确的知道哪些数据包被正确的传到接收端，从而避免不必要的重传，减少时延，提高网络吞吐量。
SACK算法是对Reno算法的改进。它的改进之处在于：在快速恢复阶段，SACK保持一个变量pipe来表示出现在路由器上报文的估计数量。当pipe小于拥塞窗口大小时，源端只发送一个新报文分组或重发一个老报文，pipe加1;当发送端接收到一个带SACK选项的重复ACK时，表明新数据已被接收端接收，pipe减1;此外，对收到的“恢复ACK”使用特殊的处理方法，对pipe变量值减2。
SACK算法降低了不必要的重传，能有效的从多个数据包丢失中恢复。但是它的实现需要修改TCP发送端和接收端的实现代码，增加了TCP的复杂性，不易大规模的应用。
3.5Vegas算法
Vegas算法是一个得到普遍认可，但是未能获得广泛应用的算法。Vegas与上述介绍的算法不同，它以RTT的变化作为拥塞信号，调节源端的发送速率。如果发现RTT变大，Vegas就认为网络发生拥塞，开始减小cwnd;如果RTT变小，Vegas则解除拥塞，再次增加cwnd。这样，在理想情况下，cwnd值会稳定在一个合适的范围内。Vegas的重传策略与上述算法也不同，它是在收到一个重复ACK后，比较数据包发出的时间和当前时间，然后决定是否重发。这样能更及时地重传丢失的数据包，提高响应速度。
该算法采用RTT的改变来判断网络的可用带宽，能较好的预测网络带宽的使用情况，其公平性、效率都较好。但是，由于Vegas与其它算法在竞争带宽方面存在不公平现象，因此未能在Internet上普遍采用，还需不断改进。
4算法性能比较
在上述介绍的几种拥塞控制算法中，Tahoe在快速重传后转向慢启动算法，这样不能有效地利用网络带宽并且还引入较大的时延;Reno在Tahoe的基础上提出了快速恢复算法，对于单个数据包的丢失在传输性能上有显著的提高，但是它不能有效的处理多个包丢失的情况;于是提出了改进算法NewReno和SACK，两种改进措施都大大提高了TCP的传输性能;Vegas在理论上是可行的，但是在实际应用中存在着局限性，因而未能得到广泛应用。TCP的拥塞控制算法还在不断的改进。
5总结
端到端的拥塞控制是网络拥塞控制的基本前提，只有将端到端的拥塞控制工作做好，才能为网络中的整体拥塞控制措施打下良好的基础。随着Internet的迅速扩展，网络中的数据流负载处理会快速加重，如果端节点与网络拥塞控制关系能够很好的配合，网络负载将会大大减轻，有利于传输性能和资源利用。如何建立有限的协调机制，有待于进一步研究。
现有的TCP拥塞控制算法都存在一些局限性，因此，对网络拥塞控制的进一步研究具有极其重要的理论和应用价值。
参考文献
[1]冯波，基于NS的TCP/IP拥塞控制算法研究，燕山大学硕士学位论文，2003.9
[2]徐恪，吴建平，徐明伟高等计算机网络—体系结构、协议机制、算法设计与路由器技术，机械工业出版社，2003.9，Page299-322
[3]章淼，吴建平，林闯互联网端到端拥塞控制研究综述，软件学报，2002.13，Page354-363
[4] Sally Floyd，A Report on Some Recent Developments in TCP Congestion Control，IEEE Communications Magazine，April 2001，Page1-7
[5] Sally Floyd，Senior Member，IEEE，and Kevin Fall，Promoting the Use of End-to-End Congestion Control in the Internet，IEEE/ACM TRANSACTIONS ON NETWORKING，August 1999，Page458-472
