1. 论信息系统项目的成本管理
软件成本估算是一个十分容易被忽视却又十分重要的一个内容。如果没有成本估算，项目计划就会失去基础；而容易被忽视却是由于大部分软件开发组织未能够有效掌握它。
软件估算包括规模估算，工作量估算，进度估算，成本估算。整个估算的过程是：首先根据软件需求进行规模估算，也就是预计软件的规模，通常以代码行数，功能点数为单位，然后在估计规模的基础上，根据项目的特定因素（技术能力，使用的语言平台，团队稳定性，性能复杂度）开发生产率经验数字来估算开发的工作量，通常以人天，人月，人年为单位；最后根据客户提出的进度需求估算进度，根据人员及其他成本（设备，房租，差旅）对总的开发成本进行估算。软件估算的基础是经验数字和经验模型。
规模估算常用的方法包括LOC代码行估算法，FP功能点估算法。LOC估算法主要根据历史项目记录，以经验数据进行推测；而FP估算法是一种比较流行的软件规模估算方法。
而工作量的估算可以采用的模型方法和技术就比较多了，大致可以分为算法方法，类比估算法，自底向上估算法三种。
- 算法方法
算法方法估算是按自顶向下的方式实现，使用数字方式表达出估算所含的各种参数之间的关系，如规模，工作量，进度和复杂度之间的关系。它可以是静态的也可以是动态的。
算法估算法虽然定义严谨，但是由于这些算法只是源于几十个项目的数据总结，因此结果并不是准确的，但其仍然具有较高的参考价值。 - 类比估算法
是自顶向下的查看系统，它借助经验丰富的人员的本能感受去识别待估项目和已经来完成的项目之间的相似与差异之处，并评估这些差异对评估结果的影响。这种方式主观意识强，估算结果的精确度与估算人员的经验有很大的关系。 - 自底向上估算法
将项目分解成为较小的活动和任务，对每个较低层的任务做估算，然后将所有较低层的任务估算值加在一起，就可以得到项目总的工作量估算值。由于这种估算当时通常是由程序员来进行小任务快的估算，因此很容易让程序员产生责任感，进度更加有保障。
有了工作量估算后就可以估算出工作人员的成本，但在进行开发成本估算时还应该考虑硬件，软件，通信，差旅，培训以及其他管理成本。
心得：
- 项目的复杂度，涉及的关键技术，团队情况等因素都是成本估算模型的参数依据。
- 工作量估算是成本估算的关键，其估算的结果决定了成本估算，而成本估算则是在工作量的基础之上做一些简单的财务计算，因此可以理解为工作量估算的方法和模型。
- 在项目结束后，对于估算产生的误差，要进行分析，找到产生误差的地方在哪里。
2. 论项目的进度管理
-
软件开发小组人数与软件生产率
从理论上讲，一个软件任务由一个人单独开发，生产率最高。但在实际开发中，这是不现实的，稍大的软件开发，都必须组织一个开发小组，一般在2-8人为宜。
人与人之间必须通过交流来解决各自担当任务之间的接口问题，即所谓的通信问题。通信需花费时间和代价，会引起软件错误的增加，降低软件生产率。 -
任务的确定与并行性
软件开发进程中要设置许多里程碑。里程碑为管理人员提供了指示项目进度的可靠依据。当一个软件工程任务成功地通过了评审并产生了文档之后，一个里程碑就完成了。
软件工程项目的并行性提出了一系列的进度要求。因为并行任务是同时发生的，所以进度计划必须决定任务之间的从属关系，确定各个任务的先后次序和衔接，以及各个任务完成的持续时间，此外，应注意构成关键路径的任务，即要保证整个项目按进度完成，就必须保证这些任务按进度要求完成，这样就可以确定在进度安排中应保证的重点。 -
制定开发进度计划
按照经典的软件工程424原则，即编码工作量占20%，编码前工作量占40%，编码后工作量占40%。 -
进度安排的方法
甘特图中，每一个任务的完成标准是以必须交付应交付的文档与通过评审为标准。而不是以能否继续下一个阶段任务为标准。因此甘特图中的文档编制与评审是软件开发进度的里程碑。甘特图的优点是标明了各任务的计划进度和当前进度，能动态地反映软件开发进展情况，缺点就是难以反映多个任务之间存在的复杂逻辑关系。
- PERT计划评审技术和CPM关键路径法
这两个技术方法都为项目计划人员提供了一些定量的工具。用来确定关键路径，应用统计模型，对每一个单独的任务确定最可能的开发持续时间的估算值；计算边界时间，以便为具体的任务定义时间窗口，边界时间的计算对软件项目的计划调度是非常有用的。
在组织较为复杂的项目任务或需要对特定任务做更为详细的计划时，可以使用分层的任务网络图。
- 进度控制
- 定期举行项目进度会议，在会上每一个成员报告进展和遇到的问题。
- 评价在软件工程过程中所产生的所有评审的结果。
- 确定项目的计划进度所安排的可能选择的正式的里程碑。
- 比较在项目资源表中所列出的每一个项目任务实际开始时间和计划开始时间
- 非正式地与开发人员交谈，以得到他们对开发进展和刚出现的问题的客观评价。
项目经理还要应用控制来管理项目资源，覆盖问题以及指导项目工作人员，如果项目进展顺利，那么控制是轻微的，当出现问题的时候，项目管理人员必须实行控制，并尽快地排解他们，当诊断出问题之后，在应用领域中可能需要一些追加资源，人员可能要重新部署，或者项目进度要重新调整。
必须处理好软件工程项目中进度与质量的关系，因为在软件开发过程中常常会遇到这样的事情：当任务未能按时完成，只好加快进度赶上去，但事实告诉我们，在进度压力下赶项目，结果往往是以牺牲产品的质量为代价的。
具体说明项目进度控制的基本步骤，以及你所参与的项目中这些步骤的实施规程。
1. 分析进度，找出哪些地方需要纠正措施
2. 确定应采取哪种具体纠正措施
3. 修改计划，将纠正措施列入计划
4. 重新计算进度，估计计划采取的纠正措施的效果。
加速项目进度的重点应放在有负时差的路径上，时差负值越大的路径其考察的优先级越高。在分析有负时差的活动路径时，应把精力主要放在近期内的活动和工期较长的活动上，因为这些活动越早采取措施就越有效，而工期越长的活动其活动时间的可能性越大，效果也就越明显。
当项目的实际进度滞后于计划进度的时候，应采取哪些措施？结合实际项目阐述这些措施的实施过程及取得的具体效果。
1. 投入更多资源加速活动进程
2. 指派经验丰富的人去完成或帮助完成项目工作
3. 在甲方同意的前提下，缩小活动范围或降低活动质量要求
4. 通过改进方法或技术提高生产效率。
对项目进度的控制，应当重点关注项目进展和执行状况报告，它反映了项目当前的进度，费用，质量等方面的指向情况和实施情况，是进行进度控制的重要依据。
对于没有负时差项目，重要的是不要使它出现耽误或延误而最终造成时差的减少，如果项目进展快于进度，要尽力保持这种状况。另外举行定期的项目会议也是处理进度控制问题的很好的手段。
3. 论项目的风险管理
-
风险识别
风险识别不是一次就可以完成的事，应自始至终定期进行。
识别风险的一种最好的办法就是利用一组提问来帮助项目计划人员了解在项目和技术方面有哪些风险。
因此建议使用一个风险项目检查表，列出所有可能与每一个风险因素有关的提问，从产品规模，商业影响，客户特征，过程定义，开发环境，建造技术，人员数量及经验等几个方面识别已知的或可预测的风险。
从宏观上来看，可将风险分为项目风险，技术风险，商业风险。项目风险威胁到项目计划，一旦项目风险成为现实，可能会拖延项目进度，增加项目成本。项目风险是指潜在的预算，进度，个人（包括人员和组织），资源，用户和需求方面的问题，以及他们对软件项目的影响。除此之外，项目的复杂性，规模和结构的不确定性也项目（估算）风险的构成因素。
五种主要的商业风险扫描二维码关注公众号，回复： 10876153 查看本文章
- 建立的软件虽然优秀但不是市场真正想要的（市场风险）
- 建立的软件不再符合公司的整个软件产品战略（策略风险）
- 建立了销售部门不清楚如何推销软件
- 由于重点转移或人员变动而失去上级管理部门的支持（管理风险）
- 没有得到预算或人员的保证（预算风险）
-
风险评估
确定风险发生的概率和后果。风险评价则是确定该风险的经济意义及处理的费用效率分析。
风险评估从两个方面估计每一种风险。一方面估计一个风险发生的可能性，另一方面是估计与风险相关的问题出现后将会产生的后果。通常项目计划人员与管理人员，技术人员一切进行四种风险估计活动。建立一个尺度来表明风险发生的可能性，描述风险的后果；估计风险对项目和产品的影响；指明风险估计的正确性以便消除误解。
风险出现的概率可以通过从过去项目，直觉或其他信息收集来的度量数据进行统计估算出来。例如从45个项目中收集的度量表明，有37个项目遇到的用户要求的变更次数达到两次。作为预测，新项目将遇到的极端的要求变更的概率是0.82，因而这是一个极可能的风险。
在进行风险评价时，可建立一个三元祖：风险；风险出现的可能性概率；风险产生的影响。还要在评估风险时进一步审查在风险估计时所得到的估计的准确性，尝试对已发现的风险进行优先排队，并着手考虑考虑控制和消除可能出现风险的方法。
在做风险评价时时常采用的一个非常有效的方法就是定义风险参照水准。性能，支持，成本，进度就是典型的风险参照水准。就是说对于成本超支，进度延期，性能降低，支持困难或它们之间的组合所产生的问题导致超出一个或多个这样的参照水准，工作就要终止。
一个风险参照水准有一个点，叫做参照点或奔溃点。在这个点上，要公平地判断是继续执行项目工作还是终止它们。
在做风险评价时可以按照以下步骤实施- 定义项目的各种风险参照水准
- 找出在三元数组和各参照水准之间的关系
- 预测一组参照点以定义一个项目终止区域，用一条曲线或一些不确定性来界定
- 预测各种复合的风险将如何影响参照水准
-
风险量化
依据风险管理计划，风险及风险条件排序表，历史资料，专家判断及其他计划结果，利用面谈，敏感度分析，决策分析和模拟的方法和技术，得出量化序列表，项目确认研究，以及所需应急资源等量化结果。风险量化之后，还要继续进行风险的评价。 -
规划风险应对
- 风险控制法：主动采取措施避免风险，消灭风险，中和风险或采用紧急方案降低风险
- 风险自留：当风险量不大时可以预留风险
- 风险转移
-
风险监控
跟踪已识别风险，识别剩余风险和出现的风险，修改风险管理计划，保证风险计划的实施，并评估消减风险的效果。
为了执行风险驾驭与监控活动，必须考虑与每一个风险相关的三元组（风险描述，风险发生概率，风险影响）它们构成风险驾驭（消除）步骤的基础。
假如人员频繁流动是一项风险，基于过去的历史和管理经验，频繁流动可能性的估算值为0.70，而影响的估计值是开发时间增加15%，总成本增加12%。为了缓解这一风险，项目管理必须建立一个策略来降低人员的流动造成的影响。- 与现有人员一起探讨人员流动的原因
- 在项目启动开始前，把缓解这些原因的工作列入计划中
- 在项目启动时，做好出现人员流动的准备，采取一些技术确保一旦人员离开后项目仍然继续
- 建立良好的项目组织和通信渠道，使大家对每一个有关开发活动的信息都有了解
- 制定文档标准并建立相应机制，保证文档能够及时建立
- 对所有工作组织做细致的评审，使大多数人能够按计划进度完成自己的工作
- 要培养每一个关键性的技术人员的后背人员
这些风险应对步骤带来了额外的成本。例如培养关键技术人员的后背需要花钱，花时间。因此通过某个风险应对步骤得到的收益超出实现它的成本时，要对风险应对部分进行评分，进行传统的成本效益分析。
对于一个大型的软件项目，可能识别30～40项风险，如果每一项风险有3-4个风险应对步骤，那么风险监控本身也可能成为一个项目。
所有项目风险的80%即可能导致项目失败的八成的潜在因素能够通过20%的已识别风险来说明。在早期风险分析步骤中所做的工作可以帮助计划人员确定哪些风险属于20%之内。因此，某些被识别过估计过及评价过的风险可以不写入风险监控计划中，它们不属于关键的20%。
信息系统项目经常面临的主要风险，产生的根源和可以采取的应对措施
- 需求风险
IT人员并不是业务领域的专家对业务的理解存在偏差；业务人员很多时候并不知道他们自己想要的东西，信息系统需求从来源就是不明确的；即使是业务领域的专家与IT人员也有沟通和理解的问题，对于同样的问题，业务领域的专家表述出来的，不同的IT人员也会产生不同的理解；除此之外，由于方法和技巧的问题，在需求阶段也会引入各种各样的误差。 - 技术风险
IT项目是技术型项目，会应用到各种各样的技术方法，不恰当的选择和应用技术则会对项目带来很大的问题，在IT项目中，造成技术风险的原因大都是不恰当地应用了技术或应用了不成熟的技术，但其表现是多方面的。
例如没有评估过需求人员使用用例分析技术的能力就采用用例分析技术分析用户需求，这是在项目中不恰当的使用，造成了技术上的风险。
在比如项目中使用的技术架构没有经过验证，或者仅仅做了简单的评估，可能在项目后期发现技术架构不能满足项目的要求，这也是技术的不恰当使用。
技术在不断的发展，更新的技术可能带来更高的效率和更加强大的功能，保证组织的竞争优势，在项目中导入新技术是需要相当谨慎的，新技术常常意味着不成熟，在最初的阶段可能会产生各种各样的问题，还有不要在同一个项目中导入多种新技术，其后果可能是灾难性的。 - 团队风险
项目不可能独立完成，必须要有一支可以胜任的团队。IT项目要求明确的职责和高度畅通的沟通渠道，但现实是团队人员可能不稳定，经常出现人员流失的情况；往往项目启动后才组建团队，团队缺乏凝聚力。团队成员主要从事技术工作，沟通能力欠缺。那么无法确定团队聚合后的能力将成为项目风险之一。 - 关键人员风险
这些关键人员的稳定对于项目的结果有非常重大的影响。若有可能发生关键人员的离职或被调到其他项目组的情况，则必须作为项目组的风险来管理。 - 预算风险
紧张的预算会对项目经理决策造成影响。例如可能会使用工资水平比较低的人员，选用廉价的工具等，这些决策都可能会对后面的工作造成影响。由此可见预算是否充足，是否能够及时到位，一旦发生问题或者项目延期的时候是否仍然能够保证相对充足的预算，都是必须预先考虑的。 - 范围风险
指范围扩大的风险，其原因往往是多方面的，既有可能是需求调研时漏掉了某些功能，也有可能是双方对合同的理解不同等。范围变动的风险一旦发生，将对项目造成巨大的影响。一般情况下范围变动往往发生在项目的后期，此时开发基本完成，系统设计可能完全不支持要增加的功能，项目面临巨大变更。
项目经理可以通过范围的控制来细化项目目标，从而降低风险发生的概率，通过变更控制管理来降低范围风险造成的影响。
一般来说，项目组在需求分析之前就要列一张风险清单，直到项目结束前不断更新这张清单，要为主要风险清单中每一种风险制定详细的风险应对计划，包括为什么会出现这个风险，怎样做，用什么方法，谁来做，什么时候做，需要什么代价。
4. 论软件质量保证
在具体项目中具体侧重哪些质量属性开展软件质量保证的。
质量因素:软件是逻辑产品，其质量属性有不同的特点，通常从下面六个方面来衡量一个软件的质量。
- 性能
系统的响应能力，即需要经过多长时间才能对某个事件做出响应。经常用单位时间内所处理事务的数量或系统完成某个事务处理所需的时间来对性能进行定量的表示。性能测试经常要用到基准测试程序 - 可靠性
软件系统在应用或系统错误面前，在意外或错误使用的情况下维持软件系统的功能特征的基本能力。通常用它来衡量在规定的条件和时间内，软件完成规定功能的能力。可靠性通常使用平均失效等待时间和平均失效间隔时间来衡量。
而可靠性又可以分为容错和健壮性两个方面。
容错：在错误发生时却确保系统正确的行为，并进行内部修复。
健壮性：它只能保证软件按照某种已经定义好的方式终止执行。软件体系结构对软件系统的可靠性有巨大的影响。在遇到意外错误事件时确保应用系统处于已经定义好的状态。 - 可用性
系统能够正常运行的时间比例。它通常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。 - 安全性
系统在向合法用户提供服务的同时能够阻止非授权用户企图使用的或拒绝服务的能力。 - 可修改性
能够快速的以较高的性价比对系统进行变更的能力。通常过考查变更的代价来衡量可修改性。它具体包括了可维护性，可扩展性，结构重组，可移植性。 - 功能性
系统完成所期望的工作的能力。完成一项任务需要许多或大多数构件的相互协作。
软件产品质量有哪些特点：
- 对于不同的软件产品，其质量属性的侧重点是不一样的，例如：对于实时系统来说，性能和效率是首要的考虑因素，而对一个公安身份证系统来说，安全性则是第一位的。
- 软件质量很难量化，也没有相应的国际标准，对软件产品而言使用每千行代码缺陷数量来度量软件的质量，但缺陷的等级，种类，性质，影响不同，每千行缺陷数量小的软件不一定比数量大的的软件质量更好。
- 没有一个通用标准衡量软件质量的好坏，所以软件产品质量没有绝对的合格和不合格界限。一般凡事满足用户需求的就是好的软件。
- 软件不可能做到零缺陷，因为测试不可能穷尽所有的情况。
具体叙述在项目中是怎样进行软件的质量保证的，包括SQA活动所采用的方法。
SQA的六项活动
- 制订SQA计划：需要进行的评价，需要进行的审计和评审，项目采用的标准，错误报告的要求和跟踪过程，产生的SQA文档，为软件项目组提供反馈数量。
- 参与开发该软件项目的软件过程描述：软件开发小组为将要开展的工作选择软件过程，SQA小组要评审过程说明，以保证该过程与组织政策，内部的软件标准，外界所制定的标准，以及软件项目计划的其他部分相符。
- 评审：评审各项软件工程活动，核实其是否符合已定义的软件过程。还要识别记录，跟踪所有偏离过程的偏差，核实其是否已经改正。
- 审计：定期向项目负责人报告工作结果。
- 记录并处理偏差：确保软件工作及工作产品中的偏差已记录在案，并根据预定规程进行处理。
- 报告：记录所有不符合部分，并向上级管理部门报告。跟踪不符合的部分直到问题解决。
