软件需求开发与管理
1概述
需求是从系统外部能发现系统所具有的满足于用户的特点、功能及属性等。需求是指明必须实现什么的规格说明。它描述了系统的行为、特性或属性，是在开发过程中对系统的约束。
软件需求工程划分为需求开发和需求管理，其中需求开发可进一步分为问题获取(elicitation)、分析(analysis)、编写规格说明(specification)和验证(verification)四个阶段, 需求开发活动包括以下几个方面：
(1)确定产品所期望的用户类
(2)获取每个用户类的需求
(3)了解实际用户任务和目标以及这些任务所支持的业务需求
(4)分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决
方法和附加信息
(5)将系统级的需求分为几个子系统，并将需求中的一部分分配给软件组件
(6)了解相关质量属性的重要性
(7)商讨实施优先级的划分
(8)将所发现的用户需求编写成规格说明和用例模型
(9)评审用例和需求规格说明，确保对用户需求达到共同的理解与认识，并在整个开发小组
接受说明之前将问题都弄清楚。
需求管理活动包括以下几个方面：
(1)定义需求基线(迅速制定需求文档的主体)
(2)评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它
(3)以一种可控制的方式将需求变更融入到项目中
(4)使当前的项目计划与需求一致
(5)估计变更需求所产生的影响并在此基础上协商新的承诺。
(6)让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪
(7)在整个项目过程中跟踪需求状态及其变更情况。
2需求工程的推荐方法
需求工程推荐方法
需求开发
2.1需求获取
（1）编写前景文档：前景文档应该包括高层的产品业务目标，所有的用例和功能需求都必须遵从能达到的业务需求。项目前景文档中的说明使所有项目参与者对
项目的目标能达成共识。
（2）确定用户类：为避免出现疏忽某一用户群需求的情况，要将可能使用产品的客户分成不同组别。他们可能在使用频率、使用特性、优先等级或熟练程度等方
面都有所差异。详细描述出它们的个性特点及任务状况，将有助于产品设计（3）在每个用户类中确定适当的代表：为每类用户至少选择一位能真正代表他们需求的人作为那一类用户的代表并能作出决策。
（4）运用需求获取方法对系统的重要部分进行用例开发并设置优先级
（5）确定用例：从用户代表处收集他们使用软件完成所需任务的描述，编写用例，描述用户与系统间的交互方式和对话要求。
（6）召开应用程序开发联系会议：应用程序开发联系会议是范围广的、简便的专题讨论会，也是分析人员与客户代表之间一种很好的合作办法，可以在会上就已
完成的工作或未完成的工作与客户展开讨论，并能由此拟出需求文档的底稿。
（7）分析用户工作流程：观察用户执行业务任务的过程。画一张简单的示意图（最好是数据流图）来描绘用户什么时候获得什么数据，并怎样使用这些数据。并
与客户讨论此内容。
（8）确定质量属性和其它非功能需求：在功能需求之外再考虑一下非功能的质量特点。这些特点包括性能、有效性、可靠性、可用性等，而这些质量属性上客户
提供的信息相对来说就非常重要了。
（9）通过检查当前系统的问题报告来进一步完善需求：客户的问题报告及补充需求为新产品或新版本提供了大量丰富的改进及增加特性的想法，负责提供用户支
持及帮助的人能为需求过程提供极有价值的信息。
（10）跨项目重用需求：如果客户要求的功能与已有产品很相近，则可查看需求是否有足够的灵活性以允许重用一些已有的软件组件。
2.2需求分析
需求分析（requirement analysis）包括提炼、分析和仔细审查已收集到的需求，以确保所有的stakeholder 都明白其含义并找出其中的错误、遗漏或其它不足的地方。分析员通过评价来确定是否所有的用例和软件需求规格说明都达到了优秀需求说明的要求。分析的目的
在于开发出高质量和具体的需求，这样你就能作出实用的项目估算并可以进行设计、构造和测试。
通常，把需求中的一部分用多种形式来描述，如同时用文本和图形来描述。分析这些不
同的视图将揭示出一些更深的问题，这是单一视图无法提供的。分析还包括与客户的交流以澄清某些易混淆的问题，并明确哪些需求更为重要。其目的是确保所有stakeholder 尽早地对项目达成共识并对将来的产品有个相同而清晰的认识。
1)绘制系统关联图:这种关联图是用于定义系统与系统外部实体间的界限和接口的简单
模型。同时它也明确了通过接口的信息流和物质流。
2) 创建用户接口原型:当开发人员或用户不能确定需求时，开发一个用户接口原型—一
个可能的局部实现—这样使得许多概念和可能发生的事更为直观明了。用户通过评价原型将使项目参与者能更好地相互理解所要解决的问题。注意要找出需求文档与原型之间所有的冲突之处。
3) 分析需求可行性:在允许的成本、性能要求下，分析每项需求实施的可行性，明确与
每项需求实现相联系的风险，包括与其它需求的冲突，对外界因素的依赖和技术障碍。
4) 确定需求的优先级别:应用分析方法来确定用例、产品特性或单项需求实现的优先级别。以优先级为基础确定产品版本将包括哪些特性或哪类需求。当允许需求变更时，在特定的版本中加入每一项变更，并在那个版本计划中作出需要的变更。给每个需求建立优先级有助于解决冲突，安排阶段交付，并且做出必要的取舍。需求的优先级可以设为三类，①基本的－只有在这些需求上达成一致意见，软件才会被接收；②条件的－实现这些需求将增强产品的性能，但如果忽略这些需求，产品也是可以被接受的；③可选的－一个功能类，实现或不实现均可
5) 为需求建立模型：需求的图形分析模型是软件需求规格说明极好的补充说明。它们能提供不同的信息与关系以有助于找到不正确的、不一致的、遗漏的和冗余的需求。这样的模型包括数据流图、实体关系图、状态变换图、对象类及交互作用图。
6) 创建数据字典：数据字典是对系统用到的所有数据项和结构的定义，以确保开发人员
使用统一的数据定义。在需求阶段，数据字典至少应定义客户数据项以确保客户与开发小组是使用一致的定义和术语。数据字典可以用术语表代替。
2.3需求规格说明
无论你的需求从何而来，也不管你是怎样得到的，得到的形式是什么，你都必须用一种统一的方式来将它们编写成可视文档。业务需求要写成前景文档。用户需求要编成用例及用例规约和补充规约。而软件需求规格说明（requirement specification）则包含了软件的功能需求和非功能需求。
1) 采用S R S模板：在组织中要为编写软件需求文档定义一种标准模板。该模板为记录
功能需求和各种其它与需求相关的重要信息提供了统一的结构。模板是很有用的，但有时要根据项目特点进行适当的改动。
2) 指明需求的来源：为了让所有stakeholder明白S R S中为何提供这些功能需求，要都能追溯每项需求的来源，这可能是一种使用实例或其它客户要求，也可能是某项更高层系统需求、业务规范、政府法规、标准或别的外部来源。
3) 为每项需求注上标号:制定一种惯例来为S R S中的每项需求提供一个独立的可识别的标号或记号。这种惯例应当很健全，允许增加、删除和修改。作了标号的需求使得需求能被跟踪，记录需求变更并为需求状态和变更活动建立度量。
4) 记录业务规范:业务规范是指关于产品的操作原则，比如谁能在什么情况下采取什么动作。将这些编写成S R S中的一个独立部分，或一独立的业务规范文档。某些业务规范将引出相应的功能需求；当然这些需求也应能追溯相应业务规范。
5) 创建需求跟踪能力矩阵:建立一个矩阵把每项需求与实现、测试它的设计和代码部分
联系起来。这样的需求跟踪能力矩阵同时也把功能需求和高层的需求及其它相关需求联系起来了。
2.4需求验证
验证是为了确保需求说明准确、完整地表达必要的质量特点。当你阅读软件需求规格说明（S R S）时，可能觉得需求是对的，但实现时，却很可能会出现问题。当以需求说明为依据编写测试用例时，你可能会发现说明中的二义性。而所有这些都必须改善，因为需求说明要作为设计和最终系统验证的依据。客户的参与在需求验证（ requirement verification）中占有重要的位置。
1) 审查需求文档:对需求文档进行正式审查是保证软件质量的很有效的方法。组织一个
由不同代表（如分析人员，客户，设计人员，测试人员）组成的小组，对S R S及相关模型进行仔细的检查。另外在需求开发期间所做的非正式评审也是有所裨益的。
2) 以需求为依据编写测试用例:根据用户需求所要求的产品特性写出黑盒功能测试用例。客户通过使用测试用例以确认是否达到了期望的要求。还要从测试用例追溯回功能需求以确保没有需求被疏忽，并且确保所有测试结果与测试用例相一致。同时，要使用测试用例来验证需求模型的正确性，如对话框图和原型等。
3) 确定合格的标准:让用户描述什么样的产品才算满足他们的要求和适合他们使用的。
将合格的测试建立在使用情景描述或使用用例的基础之上
2.5需求管理
当你完成需求说明之后，不可避免地还会遇到项目需求的变更。有效的变更管理需要对
变更带来的潜在影响及可能的成本费用进行评估。变更控制委员会与关键的项目风险承担者要进行协商，以确定哪些需求可以变更。同时，无论是在开发阶段还是在系统测试阶段，还应跟踪每项需求的状态。建立起良好的配置管理方法是进行有效需求管理（ requirement management）的先决条件。
可以使用版本控制和其它管理配置技术来管理代码和文档，
1) 确定需求变更控制过程：确定一个选择、分析和决策需求变更的过程。所有的需求变更都需遵循此过程，商业化的问题跟踪工具都能支持变更控制过程。
2) 建立变更控制委员会：组织一个由项目风险承担者组成的小组作为变更控制委员会，由他们来确定进行哪些需求变更，此变更是否在项目范围内，估价它们，并对此评估作出决策以确定选择哪些，放弃哪些，并设置实现的优先顺序，制定目标版本。
3) 进行需求变更影响分析：应评估每项选择的需求变更，以确定它对项目计划安排和其它需求的影响。明确与变更相关的任务并评估完成这些任务需要的工作量。通过这些分析将有助于变更控制委员会作出更好的决策。
4) 跟踪所有受需求变更影响的工作产品：当进行某项需求变更时，参照需求跟踪能力矩阵找到相关的其它需求、设计模板、源代码和测试用例，这些相关部分可能也需要修改。这样能减少因疏忽而不得不变更产品的机会，这种变更在变更需求的情况下是必须进行的。5) 建立需求基准版本和需求控制版本文档：确定一个需求基准，这是一致性需求在特定时刻的快照。之后的需求变更就遵循变更控制过程即可。每个版本的需求规格说明都必须是独立说明，以避免将底稿和基准或新旧版本相混淆。最好的办法是使用合适的配置管理工具在版本控制下为需求文档定位。
6) 维护需求变更的历史记录：记录变更需求文档版本的日期以及所做的变更、原因，还包括由谁负责更新和更新的新版本号等。
7) 跟踪每项需求的状态：建立一个数据库，其中每一条记录保存一项功能需求。保存每
项功能需求的重要属性，它包括状态（如已推荐的，已通过的，已实施的，或已验证的），这样在任何时候都能得到每个状态类的需求数量。
8) 衡量需求稳定性：记录基准需求的数量和每周或每月的变更（添加、修改、删除）数量。过多的需求变更“是一个报警信号”，意味着问题并未真正弄清楚，项目范围并未很好地确定下来或是政策变化较大。
9) 使用需求管理工具：商业化的需求管理工具能帮助在数据库中存储不同类型的需求，为每项需求确定属性，可跟踪其状态，并在需求与其它软件开发工作产品间建立跟踪能力联系链。
2.6项目管理
软件工程管理方法在本质上与项目的需求过程是紧密相关的。项目计划建立在功能基础之上，而需求变更会影响这些计划。因此，项目计划应能允许一定程度的需求变更或项目范围的扩展。如果刚开始，需求不能确定，可以选择一种软件开发方法生存周期以允许这种
1) 选择一种合适的软件开发方法生存周期：如果需求说明在项目早期无法全部确定，则从最为清晰易懂的需求开始，建立一个健壮的可修改的结构，再逐渐增加补充。实现了部分特性的产品可作为早期版本发布。
2) 基于需求的项目计划：随着需求细节不断变得清晰、完善，项目开发计划的进度安排
将会不断改变。一开始可以根据前景对开发功能需求所需的工作量作一个估算，建立在不甚完善的需求基础之上的成本、进度安排的估计很不可靠，但随着需求说明的完善，估计也会得到不断改善。
3) 发生需求变更时协商项目约定：当在项目中添加新的需求时，估计一下你是否能在目
前安排下，利用现有资源保质保量完成。如果不能，将项目的实现与管理联系起来，协商一下新的、切实可行的约定。如果协商不成功则将可能的后果和更新项目风险管理计划联系起来，以反映出对项目成功的新的不利因素。
4) 编写文档和管理与需求相关的风险：采用自由讨论的方法并将与需求相关的项目风险
编写成文档。利用各种方法来减轻或阻止这些风险，实施这些方法并跟踪其发展及效果。
3与需求有关的风险
下面介绍的风险因素是按需求工程中获取、分析、编写规格说明、验证和管理汇总起来的，并推荐了一些方法用于降低风险发生的可能性或减轻风险发生给项目带来的影响。
3.1需求获取
1) 前景：如果团队成员没有对他们要做的产品功能达成一个清晰的共识，则很可能导致项目范围的逐渐扩大。因此最好在项目早期写一份项目前景文档将业务需求涵盖在内，并将其作为新的需求及修改需求的指导。
2) 需求开发所需时间：紧张的工程进度安排给管理者造成很大的压力，使他们觉得不赶紧开始编码将无法按时完成项目，因而对需求一带而过。项目因其规模和应用种类不同（如信息系统，系统软件，商业的或军事的应用）而有着很大的不同。粗略的统计表明：需求开发工作应占全部工作量的1 5 %。记录你参与的每个项目中实际需求开发的工作量，这样就能知道所花的时间是否合适并改进将来项目的工作计划。
3) 需求规格说明的完整性和正确性：为确保需求是客户真正需要的，要以用户的任务为中心，应用用例获取需求。根据不同的使用情景编写需求用例，建立原型，使需求对用户来说更加直观，同时获取用户的反馈信息。让客户代表对需求规格说明和分析模型进行正式的评审。
4) 对革新产品的需求：有时容易忽略市场对产品的反馈信息。故要强调市场调查研究，建
立原型，并运用客户核心小组来获得革新产品任务的反馈信息。
5) 明确非功能需求：由于一般强调产品的功能性要求，非常容易忽略产品的非功能性的需求。询问客户关于产品性能、使用性、完整性、可靠性等质量特性，编写非功能需求文档和验收标准，（像在S R S中一样）作为可接受的标准。
6) 客户赞同产品需求：如果不同的客户对产品有不同的意见，那最后必将有些客户会不
满意。确定出主要的客户，并采用产品代表的方法来确保客户代表的积极参与，确保在需求决定权上有正确的人选。
7) 未加说明的需求：客户可能会有一些隐含的期望要求，但并未说明。要尽量识别并记
录这些假设。提出大量的问题来提示客户以充分表达他们的想法、主意和应关注的一切。8) 把已有的产品作为需求基线：在升级或重做的项目中需求开发可能显得不很重要。开
发人员有时被迫把已有的产品作为需求说明的来源。“只是修改一些错误和增加一些新特性”，这时的开发人员不得不通过现有产品的逆向工程(reverse engineering)来获取需求。可是，逆向工程对收集需求是一种既不充分也不完整的方法。因此新系统很可能会有一些与现有系统同样的缺陷。将在逆向工程中收集的需求编写成文档，并让客户评审以确保其正确性。
9) 给出期望的解决办法：用户推荐的解决方法往往掩盖了用户的实际需求，导致业务处
理的低效，或者给开发人员带来压力以至做出很差的设计方案。因此分析人员应尽力从客户叙说的解决方法中提炼出其本质核心。
3.2需求分析
1) 划分需求优先级：划分出每项需求、特性或使用实例的优先级并安排在特定的产品版
本或实现步骤中。评估每项新需求的优先级并与已有的工作主体相对比以做出相应的决策。
2) 带来技术困难的特性：分析每项需求的可行性以确定是否能按计划实现。成功好象总是悬于一线的，应该运用项目状态跟踪的办法管理那些落后于计划安排的需求，并尽早采取措施纠正。
3) 不熟悉的技术、方法、语言、工具或硬件平台：不要低估了学习曲线中表明的满足某项需求所需要的新技术的速度跟进情况。明确那些高风险的需求并留出一段充裕时间从错误中学习、实验及测试原型。
3.3需求规格说明
1) 需求理解开发人员和客户对需求的不同理解会带来彼此间的期望差异，将导致最终产品无法满足客户的要求。对需求文档进行正式评审的团队应包括开发人员，测试人员和客户。训练有素且颇有经验的需求分析人员能通过询问客户一些合适的问题，从而写出更好的规格说明。模型和原型能从不同角度说明需求，这样可使一些模糊的需求变得清晰。
2) 时间压力对T B D的影响：将S R S中需要将来进一步解决的需求注上T B D记号，但如果这些T B D并未解决，则将给结构设计与项目的继续进行带来很大风险。因此应记录解决每项T B D的负责人的名字，如何解决的以及解决的截止日期。
3) 具有二义性的术语：建立一本术语和数据字典，用于定义所有的业务和技术词汇，以
防止它被不同的读者理解为不同的意思。特别是要说明清楚那些既有普通含义又有专用领域含义的词语。对S R S的评审能够帮助参与者对关键术语、概念等达成一致的共识。
4) 需求说明中包括了设计：包含在S R S中的设计方法将对开发人员造成不必要的限制并妨碍他们发挥创造性设计出最佳的方案。仔细评审需求说明以确保它是在强调解决业务问题需要做什么，而不是在说怎么做。
3.4需求验证
1) 未经验证的需求：审查相当篇幅的S R S是有些令人沮丧，正如要在开发过程早期编写测
试用例一样。但如果在构造设计开始之前通过验证基于需求的测试计划和原型测试来验证需求的正确性及其质量，就能大大减少项目后期的返工现象。在项目计划中应为这些保证质量的活动预留时间并提供资源。从客户代表方获得参与需求评审的赞同（承诺），并尽早且以尽可能低的成本通过非正式的评审逐渐到正式评审来找出其存在的问题。
2) 审查的有效性：如果评审人员不懂得怎样正确地评审需求文档和怎样做到有效评审，那么很可能会遗留一些严重的问题。故要对参与需求文档评审的所有团队成员进行培训，请组织内部有经验的评审专家或外界的咨询顾问来讲课、授教以使评审工作更加有效。
3.5需求管理
1) 变更需求：将前景文档作为变更的参照可以减少项目范围的延伸。用户积
极参与的具有良好合作精神的需求获取过程可把需求变更减少近一半。能在早期发现需求错误的质量控制方法可以减少以后发生变更的可能。而为了减少需求变更的影响，将那些易于变更的需求用多种方案实现，并在设计时更要注重其可修改性。
2) 需求变更过程：需求变更的风险来源于未曾明确的变更过程或采用的变动机制无效或不按计划的过程来做出变更。应当在开发的各阶层都建立变更管理的纪律和氛围，当然这需要时间。需求变更过程包括对变更的影响评估，提供决策的变更控制委员会，以及支持确定重要起点步骤的工具。
3) 未实现的需求：需求跟踪能力矩阵有助于避免在设计、结构建立及测试期间遗漏的任何需求。也有助于确保不会因为交流不充分而导致多个开发人员都未实现某项需求。
4) 扩充项目范围：如果开始未很好定义需求，那么很可能隔段时间就要扩充项目的范围。产品中未说明白的地方将耗费比预料中更多的工作量，而且按最初需求所分配好的项目资源也可能不按实际更改后用户的需求而调整。为减少这些风险，要对阶段递增式的生存期制定计划，在早期版本中实现核心功能，并在以后的阶段中逐步增加实现需求。
3.6风险管理是你的好助手
项目管理人员可以运用风险管理来提高对造成项目损失的条件的警惕，在需求获取阶段
要有用户的积极参与。精明的管理者不仅要能认识到它能带来风险的条件，而且将它编入风险清单，并依据以往项目的经验估计其可能性和影响。如果用户一直没有参与，风险危害值将会扩大以至危害项目的成功。周期性的风险跟踪能使管理人员保持对风险危害变化的了解，对那些并未得到完全控制的风险能得到高层管理人员的注意。他们要么开始采取一些修正措施，要么不管风险，依旧按原业务决策思路进行。即使不能控制项目可能遇到的所有风险，风险管理也能使你看清形势，做出的决策是有所依据。
软件配置管理（Software configuration management，SCM） 目录 软件配置管理 (1) 什么是软件配置管理 (2) 配置管理的任务 (2) 实施软件配置管理的优点 (2) 配置软件管理实施的流程 (3) 软件配置管理与CMMI (4) 软件配置管理案例分析 (4) 案例：配置管理在软件企业中的应用 (4)
软件配置管理(SCM)是一种标识、组织和控制修改的技术。软件配置管理应用于整个软件工程过程。SCM活动的目标就是为了配置管理是对产品进行标识、存储和控制，以维护其完整性、可追溯性以及正确性的学科。目的是使错误降为最小并最有效地提高生产效率。 1.维护和编制公司配置管理规划、流程和策略。 2.负责日常运行维护及系统优化，负责配置管理工作，包括权限分配、基线管理、版本管理、变更管理、配置审计等;负责配置管理报告的编写和分析。 3.监督和审核项目过程中配置管理规范的实施情况,为项目组提供配置管理流程、工具方面的咨询、培训和支持，参与公司产品及体系认证与维护工作 4.负责建立和优化公司配置管理的相关规范和流程并进行相关推广。 不断优化公司配置管理方法和工具 (1)定义配置项：软件配置项(SCI)即软件配置管理的对象。软件开发过程中产生的所有信息构成软件配置，它们是：代码(源代码、目标代码)以及数据结构(内部数据、外部数据)、文档(技术文档、管理文档、需方文档)、报告，其中每一项称为 (2)标识配置项：正确标识软件配置项对整个管理活动非常重要，对软件开发过程中的所有软件项目赋予唯一的标识符，便于对其进行状态控制和管理。 (3)定义基线：基线标志着软件开发过程一个阶段的结束，任一软件配置项，一旦形成文档并审议通过，即成为基线。基本的作用在于把各阶段的工作划分得更明确，使本来连续的工作在这些点上断开，以便检验和肯定阶段成果。 (4)定义软件配置库：软件配置库内容涵盖开发的全过程. 实施软件配置管理的优点 ?节约费用：缩短开发周期、减少施工费用 ?利于知识库的建立：代码对象库、业务及经验库 ?规范管理：量化工作量考核、规范测试、加强协调与沟通。
需求说明书（软件项目管理系统） §1、前言 1.1概述 1.1.1 项目名称：软件项目管理系统 项目代码：ProjectManager 1.1.2 开发目的：本系统应能 a．管理软件项目和项目组； b．管理与项目相关的数据项和数据结构； c．管理与项目相关的系统功能描述和分组； d．管理与项目相关的项目任务和项目任务进度； e．管理与项目相关的问题，并且能进行问题跟踪； f．管理与项目相关的文档。 1.1.3 相关读者：部门经理，项目经理，测试人员，设计人员，编程人员。 1.1.4 本项目与其它产品（软件）关系。 1.2术语 本分析书所使用的专门术语定义： 部门经理——能建立项目和项目组的系统使用者； 项目经理——能进行§1.1.2.b - §1.1.2.f管理的系统使用者； 设计人员——能进行§1.1.2.b - §1.1.2.f管理的系统使用者； 编程人员——能进行§1.1.2.d - §1.1.2.f管理的系统使用者； 数据项——目标系统中的最小信息单位； 数据结构——数据项的有意义集合； 系统功能——通过目标系统能完成的有效活动； 项目任务——开发项目中要求完成的有效活动； 1.3参考资料 列举编写本分析书时所参考资料的详细信息、标题、作者、版本号、发表日期和来源等。 1.4运行环境 操作系统：Windows 2000 Professional； 数据库：MS SQL 2000 或Oracle。 1.5条件和限制 开发环境：Microsoft Visual Studio .NET 2003； 使用工具：C# §2、系统需求 1.1 功能说明 根据用户编码和用户密码校核该用户是否合法； 在校验用户密码后，可修改用户自己的密码；
软件项目管理实验报告1
软件项目管理实验报告 学院计算机学院专业软件工程班级12级（4）班学号3112006291 姓名林炳城指导教师胡欣如 （2015年6月）
计算机学院软件工程专业 4 班学号：3112006291 姓名：林炳城协作者：________ 教师评定： 实验__一__题目__ 建立项目管理文件___ 实验__二__题目__ _创建项目任务_ 实验__三__题目__ ____任务分解 实验__四__题目__ _ 安排任务工期____ 实验__五__题目__ _ __任务的链接__ __ 实验__六__题目__ ___ 资源分配____ 实验__七__题目__ __ _ 项目管理____ 实验平台： Windows系统 Microsoft Office Project Pro 2003
实验要求 本课程实验通过使用项目管理软件工具完成项目管理的一些工作，目的是了解项目管理软件工具的使用和项目管理的相关知识。 项目启动 假定： 你是一家IT公司的项目经理，该公司的PMO任命你为一个新软件项目的项目经理，PMO召开项目启动会，召开大会的日期是2015年4月1日。大会重申这个项目的关键要求： 时间要求：在2015年7月之前正式上线。 质量要求：提交一套符合此次合同要求的软件产品。 费用要求：控制在人民币3万元以内。 会议结束时，PMO主管要求你在５个工作日内提交Project格式的项目计划，包括项目进度计划、资源计划、成本计划等。 项目简介 1、项目名称《图书管理系统》 2、项目简介 本图书馆管理系统适应于中小规模公共图书馆、中小学及各院校图书馆
软件开发项目配置管理工具的选择 通过软件配置管理，将对软件系统中的多重版本实施系统的管理；全面记载系统开发的历史过程，包括为什么修改，谁作了修改，修改了什么；管理和追踪开发过程中危害软件质量以及影响开发周期的缺陷和变化。并对开发过程进行有效地管理和控制，完整、明确地记载开发过程中的历史变更，形成规范化的文档，不仅使日后的维护和升级得到保证，而且更重要的是，这还会保护宝贵的代码资源，积累软件财富，提高软件重用率，加快投资回报…… 每一个软件项目，无论是工程类项目，还是产品类项目，都必须经历需求分析、系统设计、编码实现、集成测试、部署、交付、维护和支持的过程。在这个过程中，将生成各种各样不同的工件，包括文档、源程序、可执行代码、支持库。更可怕的是，频繁出现的变更是不可避免的，因此面向如此庞大且不断变动的信息集，如何使其有序、高效地存放、查找和利用就成为了一个突出的问题。 针对这一问题，最早的开发人员尝试过的解决办法是通过手工来实现： 1)文档：每次修改时都另存为一个新的文件，然后通过文件名进行区分，例如"XXX 软件需求说明书V1.0，XXX软件需求说明书V1.1，XXX 软件需求说明书V2.0."，并且在文件中注明每次版本变化的内容； 2) 源代码：每次要修改时就将整个工程目录复制一份，将原来的文件夹进行改名，例如"XX 项目V1.0、XX 项目1.01、."，然后在新的目录中进行修改； 但是这种方法，不仅十分繁琐，容易出错，而且会带来大量的垃圾数据。如果是团队协同开发或者是项目规模较大时，还是会造成很大的混乱。很显然，这样简陋的方法是无法应对这一问题的。后来，有人尝试从制造工业领域引入了"配置管理"这一概念，通过不懈的研究与实践，最终形成了一套管理办法和活动原则，这也就是软件配置管理。 通过软件配置管理，将对软件系统中的多重版本实施系统的管理；全面记载系统开发的历史过程，包括为什么修改，谁作了修改，修改了什么；管理和追踪开发过程中危害软件质量以及影响开发周期的缺陷和变化。并对开发过程进行有效地管理和控制，完整、明确地记载开发过程中的历史变更，形成规范化的文档，不仅使日后的维护和升级得到保证，而且更重要的是，这还会保护宝贵的代码资源，积累软件财富，提高软件重用率，加快投资回报。 常见的配置管理工具 正如前面所述，由于软件配置管理过程十分繁杂，管理对象错综复杂，如果是采用人工的办法不仅费时费力，还容易出错，产生大量的废品。因此，引入一些自动化工具是十分有裨益的，这也是做好配置管理的必要条件。 正是因为如此，市场上出现了大量的自动化配置管理工具，这些工具的实现原理与基本机制
学生实验报告 （理工类） 课程名称：软件项目管理专业班级： 13NIIT 学生学号： 1305105026 学生姓名：沈红兵 所属院部：软件工程学院指导教师：张海涛 2015 ——2016学年第 1学期 金陵科技学院教务处制
实验报告书写要求 实验报告原则上要求学生手写，要求书写工整。若因课程特点需打印的，要遵照以下字体、字号、间距等的具体要求。纸张一律采用A4的纸张。 实验报告书写说明 实验报告中一至四项内容为必填项，包括实验目的和要求；实验仪器和设备；实验内容与过程；实验结果与分析。各院部可根据学科特点和实验具体要求增加项目。 填写注意事项 （1）细致观察，及时、准确、如实记录。 （2）准确说明，层次清晰。 （3）尽量采用专用术语来说明事物。 （4）外文、符号、公式要准确，应使用统一规定的名词和符号。 （5）应独立完成实验报告的书写，严禁抄袭、复印，一经发现，以零分论处。 实验报告批改说明 实验报告的批改要及时、认真、仔细，一律用红色笔批改。实验报告的批改成绩采用百分制，具体评分标准由各院部自行制定。 实验报告装订要求 实验批改完毕后，任课老师将每门课程的每个实验项目的实验报告以自然班为单位、按学号升序排列，装订成册，并附上一份该门课程的实验大纲。
实验项目名称： Project2010运用实验学时： 2 同组学生姓名：陈妤涵/徐铭/王婵实验地点： 1512 实验日期： 2015/10/26 实验成绩： 批改教师：批改时间： 一、实验目的和要求 实验目的: 1.了解IT项目管理的基本概念和项目管理核心领域的一般知识 2.熟练项目管理软件Microsoft Project 2010基本操作 3.学会如何建立项目管理文件，创建项目任务，任务工期安排，任务链接 4.熟练掌握项目资源分配 实验要求： 按照实验题目的要求，在Project 2010中创建项目 二、实验仪器和设备 需要准备一台安装了Microsoft Project Professional 2010软件的计算机。 三、实验过程 1、在开始制定项目计划之前，明确定义项目的一些基本属性信息，或者对项目有一个基本定义，给出项目的名称、内容、开始时间、结束时间等。在Project2010中创建此项目。 2、初步熟悉创建项目任务，任务是构成项目的基本单元，所有的任务完成了，项目才可以完成。实验步骤如下： （1）任务建立 (i) 打开项目文件XXX.mpp; (ii) 选择[视图] –>[甘特图]切换到“甘特图”视图，在“任务名称” 域中输入项目的任务名称；输入所有的任务直到最后。
软件开发管理制度 为加强对公司软件研发部门工作管理，缩短开发周期，提高软件开发质量，降低开发成本，提高开发效率，特制定软件研发部管理制度。 第一章、总则 为保证日常工作正常有序的进行，让开发中各个环节更紧凑，更可控，需要尽可能实现软件研发部项目管理的正规化，工作过程的流程化，以便提高软件质量和开发效率，达到项目能按质按量按期交付的目标。 1、软件开发总体遵循项目管理和软件工程的基本原则。 2、项目管理涉及项目立项、项目计划和监控、配置管理。 3、软件工程涉及需求分析、系统设计、软件实现、系统测试、用户测试、试运行、系统验收、系统上线和数据迁移、产品维护。 第二章、阶段成果 根据软件工程的过程理论并结合公司目前的实际情况，制定以下工作流程，并规定了各个重要环节需要提交的交付物。 1、立项：市场需求分析（或者合同）、项目立项申请表、项目风险分析清单。 2、需求分析：软件需求报告或设计方案、需求规格说明书。 3、总体设计：概要设计说明书或功能模块描述。 4、详细设计：详细设计说明书，包括软件接口说明、单元测试计划。 5、软件实现：软件功能说明、源代码、源代码说明或者注释 6、产品测试：测试报告 7、产品发布：产品说明书、使用手册 8、产品维护：问题反馈记录 9、项目总结：提交客户方的项目总结和公司项目汇报的PPT。 软件过程成果表：
第三章、岗位设置 根据公司目前的开发过程主要分为分析、开发、测试三个阶段。分析阶段完成用户需求文档的编写，系统总体设计的编写；开发阶段完成设计文档的编写，代码的编写、代码的维护。测试阶段完成系统的测试，测试文档及其他材料。通过逐渐的调整岗位，明确工作职责，逐步实现项目经理，需求分析工程师，高级软件开发工程师，软件开发工程师，测试工程师的岗位设置。
山西大学 软件项目管理课程设计报告 题目：教务管理系统 班级： 14 班 学号：14 姓名： 2016年12月
实习目的： 为了将理论用于实践,巩固所学知识,提高自己发现问题并用所学知识分析问题和解决问题的能力,锻炼自己的工作能力,适应社会能力,自我管理能力,了解目前软件的应用情况,需求情况,发展方向及前景,为顺利毕业做好充分的准备,也为自己能顺利的与社会环境接轨做好准备.此次实习由学校统一组织安排,分两个阶段，两个方向进行系统的实习。 实习要求： 1、要求学生在实习过程中认真学习技术知识，积极与指导老师和同学配合; 2、在前期，按时到勤，认真学习。积极做好实习日志，能够理解当天的内容。对技术的理论知识要及时实践; 在后期，积极与同学沟通，认真完成项目要求的内容。在这个过程中要与老师同学多做沟通，通过探讨项目的解决方案以及进展。 教务系统招标书 根据《中华人民共和国招投标法》和学校有关规定，对我校的教务管理信息系统软件项目（以下简称该项目）进行国内邀请招标。 一．系统要求 教务管理信息系统的主要功能模块包括：系统应该包括教务和教学两部分，教务和教学可以灵活组合、自由搭配，可以组成学校教务管理或教学管理系统。教务管理信息系统涵盖教务业务中的各个功能部件，从学籍、注册、排课、选课、考试、成绩、教学评价、教材等诸多方面形成一体化管理模式， 教务部门主要负责学校各类专科生的教学管理，主要负责5个方面的工作：基本教学活动管理。主要包括：各类教学计划管理、教学运行管理、教学考评管理；教学基本建设管理。主要包括：专业建设、课程建设、教学基地建设、教学管理制度和学风建设。组织开展相关的教育科学研究、教学改革和教学成果评审；学历与学籍管理。主要包括：在校专科生的学历与学籍管理工作，负责历届本（专）科生的学历和学位管理；教师队伍建设的有关工作。组织教师和管理干部队伍
配置管理控制程序 历史记录
目录
1.引言 1.1目的 本程序文件定义了本组织的配置管理的过程，目的是规范公司的软件配置管理活动，使公司的所有软件开发项目的软件配置管理活动都能按照统一的要求进行。 1.2 使用范围 本文件适用于公司的所有软件项目。 1.3 名词和缩写 CM(Configuration Management) 配置管理 SCCB (Software Configuration Control Board) 软件配置管理控制委员会 CC (Configuration Controller) 配置管理员 工作产品（Work Products）：项目技术开发和管理工作中产生的有价值的成果，例如源代码、数据和各种文档。 配置项（Configuration Item, CI）：纳入到配置管理范畴作为单个实体对待的工作产品称为配置项[IEEE Std 610.12 - 1990 ]；配置项包括：项目计划书、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需的各种数据，它们经评审和检查通过后进入软件配置管理。 基线（Baseline）：一组拥有唯一标识号的需求、设计、源代码文卷以及相应的可执行代码、构造文卷和用户文档构成一条基线。基线一经放行，就可以作为从配置管理系统检索源代码文卷（配置项）和生成可执行文卷的工具。 2角色与职责 2.1软件配置管理组（CM） CM组是项目里的一个小组，根据项目大小，可以由一个人，或者多人组成,小组的成员称为配置管理员(CC),通常由公司的质量保证组安排，加入到项目组，由项目经理领导。
CM组建立并管理配置管理库系统。 CM组负责组织相关部门和人员进行有关CM活动的培训。 项目组的CM组负责在该项目的整个生命周期中进行配置管理活动。 2.2软件配置管理控制委员会(SCCB) SCCB建立在项目级，通常由项目经理、该项目的技术经理、软件开发工程师、资深工程师、测试经理/测试工程师以及CC组成。SCCB在项目策划阶段由项目经理负责筹建。 配置管理控制委员会负责审批软件配置管理计划； 配置管理控制委员会负责审批软件基线的建立； 配置管理控制委员会负责审批对软件基线配置项的变更； 配置管理控制委员会负责审核和批准产品发布。 2.3 SCCB负责人 SCCB负责人通常由项目经理担任，代表SCCB在有关文件上签署意见。 2.4 项目经理 定期或事件驱动地评审或审核CM活动。 2.5 测试组 负责审核《配置管理计划》任务列表中与测试有关的内容 2.6 开发组 负责审核《配置管理计划》任务列表中与开发有关的内容 2.7 QA组 负责审核《配置管理计划》任务列表中与QA有关的内容
一、技术要求 工作条件 1．除非在技术规格中另有说明，所有仪器、设备和系统都应符合下列要求：2．适于在气温为摄氏0℃～＋40℃和相对湿度为90％的环境条件下运输和贮存。 3．适于在电源220V（ 10％）/50Hz、气温摄氏-5℃～＋40℃和相对湿度85％的环境条件下运行。连续正常运行的时间应不少于8小时。 4．配置符合中国有关标准要求的插头，如果没有，则需提供适当的转换插座。 5．如产品达不到上述要求，供应人应注明其偏差。如仪器设备需要特殊工作条件（如水、电源、磁场强度、温度、湿度、动强度等）供应人应在供应文件中加以说明。 其它要求： 1．为便于采购人进行接收仪器的准备工作，成交供应商应在合同生效后60天内向用户提供一套完整的使用说明书、操作手册、维修及安装说明等文件。另一套完整上述资料应在交货时随货包装提供给采购人，这些费用应计入总报价中。 2．对于需安装、校准、试运行的仪器设备，如果有必要的安装准备条件，成交供应商应在合同生效后一个月内向采购人提出详细的要求或计划。设备安装调试的费用由供应人承担，需计入成交总价中，并应单独列出，供采购人参考。 3．对于人员培训所需的仪器、设备，供应文件中应注明。 4．对于在采购人所在地进行的培训，供应人培训人员的旅费、食宿费用等费用由供应人自理。 5．对于需到制造厂家所在地进行的培训，供应文件中将注明培训日程和时间要求。受训人员的旅费、食宿费、培训场地费及培训资料费等培训费用均应由供应人支付。 6．在评审过程中，谈判小组有权向供应人索取任何与评审有关的资料，供应人务必在接到此类要求后，在规定时间内予以答复。对于无答复的供应人，谈
封面 软件项目管理报告 姓名：何文斌 班级：111122 信息工程学院 2015年1月 内容要求 一、论述软件项目管理的重要性[15分] 软件项目管理是一种科学的管理手段，它是为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对成本、人员、进度、质量、风险等进行分析和管理的活动。从软件工程的角度讲，软件开发主要分为六个阶段：需求分析阶段、概要设计阶段、详细设计阶段、编码阶段、测试阶段、安装及维护阶段。不论是作坊式开发，还是团队协作式开发，这六个阶段都是不可缺少的。从用户的角度来看，软件项目的生命周期应该包括项目前期的论证工作、项目计划、软件开发、运行、维护及项目评价。由此可见，软件项目管理的范围不仅包括传统的软件开发过程，还应该包括开发前的准备工作以及运行中的维护工作和对项目的总结工作，因此具有极其重要的作用。 二、项目失败的原因有哪些？[10分] 1.需求定义不明确；
2.缺乏一个好的软件开发过程； 3.没有一个统一领导的产品研发小组； 4.子合同管理不严格； 5.没有经常注意改善软件过程； 6.对软件构架很不重视； 7.软件界面定义不善且缺乏合适的控制； 8.软件升级暴露了硬件的缺点； 9.关心创新而不关心费用和风险； 10.军用标准太少且不够完善等等。 三、请论述项目范围、进度、成本和质量之间的关系。[20分] 项目范围、项目进度和项目成本是相互制约的关系，而项目的质量是受这三个因素的平衡关系所决定的。在项目管理中,对于项目进度、成本的管理是其最主要的活动,保证项目进度顺利完成,成本不超出预算是项目管理的目标,围绕这两点的管理才是项目管理的重中之重。当然,项目进度中包含着质量因素,因为如果不能保证质量,那就会有返工的风险,同样是对进度的一种威胁。这四者者之间互相牵制、相互影响,相互制约。若要保证项目进度、有时不得不追加成本投资和减小项目范围；想要严格控制预算,有时又会以牺牲项目质量和缩小项目范围为代价；要保质保量完工,进度很可能就会受到影响。 尤其是在软件项目管理中,面对一项软件开发任务,如何能在保 证质量的前提下,科学有效的对项目进度和成本进行调度，具有很大的意义。
IBM 软件产品需求管理流程 1. 简介 IBM 软件产品的版本(V.R.M.F)从市场规划和客户需求开始，到研发以及后续的交付遵循IB M软件部集成产品设计(IPD)流程。IBM 软件产品需求管理流程是IPD的一个体现，也就是一个由市场/客户驱动的，跨市场部门、研发产品管理部门及研发工程部门的端到端需求管理流程。同时，此次内容我们将描述IPD和产品需求管理流程，及流程中的角色（市场、研发产品管理部门及研发工程部门），以及他们之间是如何通过协作来管理需求的。 2. 背景——IPD IPD指导如何对软件产品发布版本进行投资决策和如何协调部门间工作以实现这些决策所 定义目标，IBM软件产品需求管理基于IPD流程，要了解这个需求管理的流程，首先我们要了解IBM所有产品开发所遵循的IPD的流程，包括其决策点。 IPD流程分为六个步骤： 1.概念：即概念验证阶段，主要对需求包进行评审，以确定其是否有足够的商业价值； 2.计划：即资源投入计划阶段，主要对需求包进行评估，以确定是否有足够的资源且在 一定的时间范围内将需求包开发出来； 3.开发：即对需求包进行开发成产品阶段； 4.验证：即对产品进行验证阶段； 5.交付：即将产品交付市场阶段； 6.生命周期：即产品在市场上销售，使用，维护和退出市场的阶段。 其中包括了几个重要的决策检查点(DCP)：
1.概念决策检查点：即经过概念阶段各方面进行的一系列评审，在此检查点确定（1） 我们对需求包是否有足够的理解；（2）需求包是否有足够的商业价值。如果是，继续进入计划阶段； 2.计划决策检查点：即经过计划阶段的评估，在此检查点确定（1）我们是否有足够的 资源在既定的时间范围内完成需求包的开发（2）研发部门是否能在(1)的估计上承诺进行开发。如果是，继续进入开发阶段； 3.可交付决策检查点：即经过开发和验证阶段，在此检查点确定（1）产品是否质量合 格以交付给客户（2）我们产品的相应支持和销售是否已经准备好服务客户,如果是，产品交付市场； 4.生命周期结束决策检查点：即产品在市场使用一定时期后，在此检查点确定产品是否 退出市场。 一个产品从市场需求开始，经过概念验证，时间、资源等计划的支持，然后进行开发，验证，直至发布到市场供客户使用，最后在某个特定的时候结束产品在市场上的销售，在IBM都遵循着IPD流程。在其中过程中，这个产品的概念是否被接受，是否能得到资源上的投入的承诺，是否通过最终验证可以在市场上发布，以及什么时候在市场上停售，这些关键的决策都通过相应的委员会在不同的决策点上进行决策。 3. IPD 与产品需求管理流程 以上描述了IBM IPD的基本概念，我们接下来看IBM软件产品的需求管理是如何基于IPD 的。首先，请看下图一：产品需求管理流程。
软件研发部管理制度 为加强对公司软件研发部门工作管理，缩短开发周期，提高软件开发质量，降低开发成本，提高开发效率，特制定软件研发部管理制度。 第一章、总则 为保证日常工作正常有序的进行，让开发中各个环节更紧凑，更可控，需要尽可能实现软件研发部项目管理的正规化，工作过程的流程化，以便提高软件质量和开发效率，达到项目能按质按量按期交付的目标。 1、软件开发总体遵循项目管理和软件工程的基本原则。 2、项目管理涉及项目立项、项目计划和监控、配置管理。 3、软件工程涉及需求分析、系统设计、软件实现、系统测试、用户测试、试运行、系统验收、系统上线和数据迁移、产品维护。 第二章、阶段成果 根据软件工程的过程理论并结合公司目前的实际情况，制定以下工作流程，并规定了各个重要环节需要提交的交付物。 1、立项：市场需求分析（或者合同）、项目立项申请表、项目风险分析清单。 2、需求分析：软件需求报告或设计方案、需求规格说明书。 3、总体设计：概要设计说明书或功能模块描述。 4、详细设计：详细设计说明书，包括软件接口说明、单元测试计
划。 5、软件实现：软件功能说明、源代码、源代码说明或者注释 6、产品测试：测试报告 7、产品发布：产品说明书、使用手册 8、产品维护：问题反馈记录 9、项目总结：提交客户方的项目总结和公司项目汇报的PPT。软件过程成果表：
第三章、岗位设置 根据公司目前的开发过程主要分为分析、开发、测试三个阶段。分析阶段完成用户需求文档的编写，系统总体设计的编写；开发阶段完成设计文档的编写，代码的编写、代码的维护。测试阶段完成系统的测试，测试文档及其他材料。通过逐渐的调整岗位，明确工作职责，逐步实现项目经理，需求分析工程师，高级软件开发工程师，软件开发工程师，测试工程师的岗位设置。
项目管理系统需求说明书
成都鼎域前沿科技有限公司 2015.4 目录 一引言 (1) 1编写目的 (1) 2范围 (1) 2.1软件系统的名称 (1) 2.2软件功能概述 (1) 二项目概述 (2) 1项目描述 (2) 2产品功能 (3) 2.1系统角色定义 (3) 2.2系统功能 (3) 3用户特点 (3) 3.1管理员及超级管理员用户 (3) 3.2企业领导、项目经理和项目成员 (4)
3.3用户使用本系统相关说明 (4) 3.4一般约束 (4) 三项目需求 (6) 1功能需求 (6) 1.1功能结构一览 (6) 1.2登陆 (7) 1.3项目管理 (7) 1.3.1项目立项 (7) 1.3.2项目新增 (7) 1.3.3项目过程管理 (8) 1.3.4项目群管理 (11) 1.4项目工具 (15) 1.4.1原因分析工具 (15) 1.4.2数据收集分析工具 (15) 1.4.3评估工具和决策工具 (15) 1.4.4TRIZ系列工具 (15) 1.5人才管理 (15) 1.6知识管理 (16) 1.7权限管理 (17) 1.7.1用户信息管理 (17) 1.7.2系统模块管理 (17)
1.7.3角色管理 (17) 1.7.4权限分配 (17) 2外部接口需求 (18) 2.1用户接口 (18) 2.2硬件接口 (18) 3性能需求 (18) 3.1静态数值需求 (18) 3.2动态数值需求 (19) 3.3硬件限制..................................................... 错误!未定义书签。4属性. (19) 4.1可用性 (19) 4.2安全性 (19) 4.3可靠性 (21) 4.4系统性能 (22) 4.5易用性 (23) 4.6可维护性 (23) 4.7其他需求 (24)
一可行性研究报告 1．可行性研究的前提 1.1要求 通过调查,要求系统需要有以下功能: ⑴要求有良好的人机界面; ⑵较好的权限管理; ⑶原始数据修改简单方便,支持多条件修改 ⑷方便的数据查询，支持多条件查询; ⑸相应的权限下，删除数据方便简单，数据稳定性好； ⑹数据计算自动完成，尽量减少人工干预; 1.2目标 a.人力与设备费用的节省； b.处理速度的提高； c.控制精度或生产能力的提高； d.管理信息服务的改进； e.决策系统的改进； f.人员工作效率的提高。 1.3条件、假定和限制 a.开发软件运行的最短寿命为一年。 b.进行系统方案选择比较的期限：2周。 c.经费来源和使用限制：自筹资金。 d.法律和政策方面的限制：本软件公司版权所有，未经作者允许，非法传播、 复制，违者追究法律责任，后果自负。 e.硬件CPU p3、内存256M.。 f.软件：access2003。 g.运行环境：本软件应使用Windows2003、Windows xp操作系统。 h.开发环境：本软件应使用Windows2003、Windows xp开发。 i.开发软件投入使用的最迟时间为2013年10月01日。 1.4可行性研究方法 由于本系统管理的对象单一,都是在校学生，且每个数据内容具有较强的关 联性，涉及的计算过程不是很复杂。因此，比较适合于采用数据库管理。且学校 用于学生管理的微机都是PIII以上的机器，在存储量、速度方面都能满足数据 库运行的要求。在技术难度方面，由于有指导老师的指导和相关参考文献，特别是网上资料，特别是参考其它程序的功能，因此完全可以实现。 2．对现有系统的分析 2.1处理流程和数据流程 班级管理业务流程图：
《软件项目管理》报告 班级：计算机06级1班 姓名：宋凯嵩 学号：200601050118 指导教师：田刚
目录 ●项目背景介绍—————————————————————————3 ●项目任务分解结构和字典————————————————————4 ●项目的规模成本估算——————————————————————6 ●项目的进度计划表和甘特图———————————————————9 ●补充习题1——————————————————————————16 ●补充习题2——————————————————————————17 ●补充习题3——————————————————————————19 ●项目的组织结构图———————————————————————20 ●项目的配置管理计划——————————————————————21 ●项目集成计划—————————————————————————24 ●GQM技术进行项目度量————————————————————30 ●项目的成本，进度挣值分析———————————————————31
项目介绍 概述 客户资源决定企业的核心竞争力，更多的关心自己的销售群体（客户群），关心他们的想法，需求，购买目的，并与之建立良好的，长期的客户关系，提升客户价值，对全面提升企业竞争力和盈利能力具有重要作用。 系统分析 需求分析 1.有良好的人机界面，可以简单方便地管理各种客户信息。 2.方便的数据查询功能。 3.管理客户的详细信息：包括客户的基本信息，联系人信息，业务往来信息。 4.设置客户服务模块，用以记录客户的反馈信息及投诉信息，并对反馈信息及投诉信息进行图表 分析。 5.与客户联系人之间通过邮件（E-mai）进行联系，对联系人邮箱地址进行管理。 6.提供各种信息列表的打印功能，并可实现客户信封打印。 7.在相应的权限下，可以删除或修改数据。 可行性 传统的手工管理方法，工作效率低，不能及时了解各类客户的实际情况，也无法快速地进行客户信息的查询，不便于动态及时了解客户的需求及反馈信息，致使企业不能更好地适应当前的经济形势发展需要。同时还存在着许多弊端：由于不可避免的人为因素，造成数据的遗漏误报。计算机信息管理有着储存信息量大，速度快的许多优点，提供给用户的处理信息及时，准确，快捷，同时也能提高企业员工的自身素质。 目标 1．对客户信息（客户基本信息，联系人信息，业务往来信息）进行全面管理 2．及时查看库存信息，并通过网站对入库，出库信息进行管理 3．强大的客户信息，联系人信息及投诉信息，并以图表形式对数据进行分析 4．实现各种信息查询功能 5．对用户输入的数据，系统进行严格的数据检验，尽可能排除人为的错误 6．操作员可以随时修改配置的口令 7．数据保密性强，为每个用户设置相应的权限级别 8．提供辅助工具，方便用户操作及使用 9．系统运行稳定，安全可靠
论如何进行有效的需求管理 很多人会有这种感受，一个项目做了很久，感觉总是做不完，就像一个“无底洞”。你想加人尽快完成这个项目，而用户总是有新的需求要项目开发方来做，就像用户是一个不知廉耻的要求者，而开发方是在苦苦接收的接受者。实际上，这里涉及到一个需求管理的概念。项目中哪些该做，哪些不该做，做到什么程度，都是由需求管理来决定的。需求管理是软件项目中一项十分重要的工作，据调查显示在众多失败的软件项目中，由于需求原因导致的约占了很大的一部分，因此，需求工作将对软件项目能否最终实现产生至关重要的影响。 在软件项目的开发过程中，需求变更贯穿了软件项目的整个生命周期，从软件的项目立项，研发，维护，用户的经验在增加，对使用软件的感受有变化，以及整个行业的新动态，都为软件带来不断完善功能，优化性能，提高用户友好性的要求。在软件项目管理过程中，项目经理经常面对用户的需求变更。如果不能有效处理这些需求变更，项目计划会一再调整，软件交付日期一再拖延，项目研发人员的士气将越来越低落，将直接导致项目成本增加、质量下降及项目交付日期推后。这决定了项目组必须拥有需求管理策略。 下面主要针对需求开发及需求管理两个方面对需求进行分析。 1. 需求开发，从目前我们的实际工作情况来看按顺序主要分成如下几个部分： ?请教行业专家 行业客户对信息化的需求越来越细化，对专业性以及行业能力的全面性要求越来越高，惟有深入行业，洞察其需求，研发出更适合客户需求的产品，才能成功。因此有必要先请这方面的行业专家对于客户的业务需求进行从流程上的梳理。为什么请行业专家，而不是直接请客户进行交谈，得到其实需求，个人认为主要是因为目前各政府部门、企事业单位对于信息化与业需求的整合这一块缺少经验，大部分情况还不能完全整理出完善、清晰的系统需求来。只有通过行业专家对其实业务流程进行梳理，一方面更容易与客户产生共鸣，另一方面也可以大大减少因为知识方面的差异导致错识需求的产生。 ?和客户交谈 你要面对“正确”的客户区分不同层次的客户需求，要面对不同层级，不同部门的客户，把客户分类，区分需求的优先级别。如果你做的项目业务是你熟悉的，那还好，如果是你不熟悉的，一定要花点精力学习一下这个行业业务的背景资料，这也是我上面谈到的先请行业专家的原因。毕竟，客户是不可能给你系统地介绍业务的。只有你通晓了行业业务，才能和用户交流，并正确而有效地引导客户，做好需求分析，你不能指望客户能明确地说出需求。
品高项目管理系统 软件开发需求
目录 1引言 (2) 1.1编写目的 (2) 2功能性需求 (2) 2.1系统登录 (3) 2.2对内项目管理子系统 (6) 2.3对外项目交流系统 (22)
1 引言 1.1 编写目的 本文档可作为 1. 设计人员进行系统设计的输入源。 2. 开发人员对系统功能开发的依据。 3. 测试人员编写系统测试计划，测试案例编写的输入源。 4. 产品经理检查系统实现程度的依据。 5. 项目团队外人员进行沟通的外部接口，用于他们评审和理解系统。 6. 项目需求阶段的主要交付物。 7. 收集并记录所有的外部接口，以用于作为完成设计和实现系统的参考。 2 系统概貌 2.1 系统背景 随着公司发展，客户范围不断增长,项目数量多且繁杂,给公司的和客户了解项目实际情况带来很大不便,公司及客户之间缺乏有效快速的沟通交流环境. 基于上诉背景，我们提出需建立一套完善的项目管理系统，作为公司及客户之间对项目信息的了解及在线交流, 以满足公司发展的需求。 2.2 用户描述 本系统用户为我们公司业务人员、项目成员、项目经理、管理中心、财务合同管理员、部门经理，项目管理层等。 2.3 系统角色权限 系统的不同角色对信息的权限见附件表 角色权限表.xlsx 2.4 一般限制 ? 应用系统应采用B/S 结构，客户端支持IE6.0 以上的版本。 ? 应用系统的开发工具与技术应采用Microsoft .NET 的技术体系。 ? 应用系统中所有数据统一保存到SQL Server 数据库。
2.5出错处理 ?所有的应用系统错误都应记录到系统日志文件中。 ?所有的Windows服务错误都应记录到Windows服务日志文件中。 ?所有的Web服务错误都应记录到Web服务日志文件中。 2.6假设和依赖条件 ?本系统假设.Net Framework 4.0平台稳定可靠，性能满足实际需求。系统构建在Microsoft .Net Framework平台中，严重依赖于该平台的可靠性，稳定性和性能。 ?本系统假设Microsoft SQL Server数据库稳定可靠，性能满足实际需求。系统数据存储于Microsoft SQL Server数据库中，依赖Microsoft SQL Server数据库的可靠性，稳定性和性能。 ?本系统假设涉及的外部接口可靠运行，提供正确数据。系统部分数据展现依赖于外部接口，当外部接口不能正确工作时，可能会导致部分展示数据不正确或无法显示。 ?本系统假设网络状态良好。本系统和客户端交互时依赖于网络状况，当网络故障或者性能低下时，可能会造成系统无法访问，系统响应速度变慢，数据无法提交等现象。但不应出现数据完整性和一致性的损坏。 ?本系统假设工作流引擎稳定可靠，性能满足要求。 ?本系统假设硬件服务器工作状态良好。 3功能性需求 3.1系统登录 【REQ_1】使用系统的用户分2类,内部用户及外部用户 【REQ_2】内部用户访问系统的时候,需要输入AD帐号密码进行身份验证检查 【REQ_3】外部用户访问系统的时候,需要输入用户名和密码进行身份验证检查 3.2首页 【REQ_4】每个用户登录后都可进入自己所属角色的首页 3.2.1.1业务人员 【REQ_5】列出业务人员本人的预立项的项目列表，已完成的合同列表，个人待办事宜，如下图示：
软件项目管理规范 一、软件项目管理的定义 软件项目管理是软件工程和项目管理的交叉学科，软件项目管理的概念涵盖了管理软件产品开发所必须的知识、技术及工具。根据美国项目管理协会PMI对项目管理的定义可以将软件项目管理定义为：在软件项目活动中运用一系列知识、技能、工具和技术，以满足软件需求方的整体要求。 软件工程的活动包括问题定义、可行性研究、需求分析、设计、实现、确认、支持等，所有这些活动都必须进行管理，软件项目管理贯穿于软件工程的演化过程之中，如图1所示。 图1 软件工程的演化过程 二、软件项目管理的过程 为保证软件项目获得成功，必须清楚其工作范围、要完成的任务、需要的资源、需要的工作量、进度的安排、可能遇到的风险等。软件项目的管理工作在技术工作开始之前就应开始，而在软件从概念到实现的过程中继续进行，且只有当软件开发工作最后结束时才终止。管理的过程分为如下几个步骤： （1）启动软件项目 启动软件项目是指必须明确项目的目标和范围、考虑可能的解决方案以及技术和管理上的要求等，这些信息是软件项目运行和管理的基础。 （2）制定项目计划 软件项目一旦启动，就必须制定项目计划。计划的制定以下面的活动为依据。 ●估算项目所需要的工作量 ●估算项目所需要的资源 ●根据工作量制定进度计划，继而进行资源分配 ●做出配置管理计划 （3）跟踪及控制项目计划 在软件项目进行过程中，严格遵守项目计划，对于一些不可避免的变更，要进行适当的控
制和调整，但要确保计划的完整性和一致性。 （4）评审项目计划 对项目计划的完成程度进行评审。并对项目的执行情况进行评价。 （5）编写管理文档 项目管理人员根据软件合同确定软件项目是否完成。项目一旦完成，则检查项目完成的结果和中间记录文档，并把所有的结果记录下来形成文档而保存。 三、软件项目管理的内容 软件项目管理的内容涉及上述软件项目管理过程的方方面面，概括起来主要有如下几项。 （1）软件项目需求管理 软件需求是软件工程过程中的重要一环，是软件设计的基础，也是用户和软件工程人员之间的桥梁。简单地说，软件需求就是确定系统需要做什么，严格意义上，软件需求是系统或软件必须达到的目标与能力。 1、目标 需求管理是一种获取、组织并记录软件需求的系统化方案，同时也是一个使客户与项目开发组对不断变更的软件需求达成并保持一致的过程。在需求管理中，软件工程组的工作是采取适当的措施来保证分配的需求，即要将分配的需求文档化，控制需求的变化，负责项目实施过程中需求的实现情况。需求管理的目的是在客户和处理客户需求的软件项目组之间建立对客户需求的共同理解。需求管理的目标有两个： ●使软件需求受控，并建立供软件工程和管理使用的需求基线。 ●使软件计划、产品和活动与软件需求保持一致。 在需求管理过程，为实现第一个目标，必须控制需求基线的变动，按照变更控制的标准和规范的过程进行需求变更控制和版本控制；为实现第二个目标，必须就变更和软件项目各小组达成共识，对软件项目计划做出调整，其中包括人员的安排、用户的沟通、成本的调整、进度的调整等。 2、原则 为进行有效的需求管理，一般要遵循如下五条原则： ●需求一定要分类管理 进行软件项目管理的时候，一定要将软件需求分出层次。不同层次需求的侧重点、描述方式、管理方式是不同的。 ●需求必须分优先级
软件项目需求说明 书模板
中央国家机关住房资金管理中心 管理信息系统 需求说明书 ( 范本) 中央国家机关住房资金管理中心二○一○年月日
文档修改历史记录 目录
1概述.................................................................. 错误!未定义书签。 1.1引言......................................................... 错误!未定义书签。 1.1.1 软件项目名称............................... 错误!未定义书签。 1.1.2软件项目开发背景和目的........... 错误!未定义书签。 1.1.3软件项目应用范围 ....................... 错误!未定义书签。 1.2参考资料................................................. 错误!未定义书签。 1.3术语定义................................................. 错误!未定义书签。 2 功能一 ............................................................. 错误!未定义书签。 2.1功能分解一............................................. 错误!未定义书签。 2.1.1定义 ............................................... 错误!未定义书签。 2.1.2功能表述 ....................................... 错误!未定义书签。 2.1.3性能要求 ....................................... 错误!未定义书签。 2.1.4相关表单 ....................................... 错误!未定义书签。 2.1.5流程图 ........................................... 错误!未定义书签。 2.1.6特殊要求 ....................................... 错误!未定义书签。 2.2功能分解二............................................. 错误!未定义书签。 2.3特殊要求................................................. 错误!未定义书签。 3 附录 ................................................................. 错误!未定义书签。1概述 1.1引言 ( 本需求说明书的编写目的以及阅读对象)