1、问题定义和可行性报告博文 问题定义和可行性报告今天交了张老师的软件工程的作业，写一篇有关私家车平安监控系统的问题定义和可行性报告。对于这个作业，我个人觉得第一要务是明确问题的要求，也就是说这个问题的关注的是私家车平安监控，因此作为开发者他们的目标就是开发出相应的系统，并将这个系统买给私家车主来获取利润。也就是说我们的开发的目标就是针对私家车主的，是满足私家车主的需要，而不能在设计的时候附加的损害到他们的利益。但是在整个作业的分析过程中，大家对此的理解不一，无视了对私家车主的利益关注。第二个我们要关注的是我们写的问题定义是直接面对客户的，因此我们必须以最简介明了的方式来突出我们的重点，让客户非常
2、容易的了解我们的问题定义和可行性的报告。虽然我们在更多的时候是利用ppt向客户介绍的，但是作为备用的给客户的文档简介明了是必要的。第三个就是利用通用而又明了的制图工具。画出相应的ER图，既便于画图又利于大家理解和交流。以上只是我个人的观点，下面附上一份可行性报告的样本。IT监理目标控制过程中的问题管理 对于信息系统工程目标采用动态控制是监理工作的根本方法之一。依照信息化工程监理标准，监理工作的顺利开展取决于建立一整套完备的监理机制，包括监理机构、监理活动根本流程、文档管理标准、沟通机制、问题管理机制等等。信息系统工程建设一般分为六个阶段，即：工程准备阶段、总体设计阶段、设计开发阶段、实施阶段、
3、验收阶段和运行维护阶段。根据不同工程的特点和具体情况，监理介入有早有晚，可能是全过程监理，也可能只针对某一个或某几个阶段实施监理。大型信息系统工程周期可长达两年、三年，甚至更长。周期越长说明工程越复杂，建设过程中可能出的问题越多。尤其对于一些“先天缺乏的工程（建设过程中并没有完全遵照信息系统建设的根本客观规律），不可防止地会随着工程建设的推进，暴露出越来越多的各种问题。在这一类型工程的监理中，毫无疑问，问题分析、管理和解决机制扮演着重要角色，因为整个工程建设就是在不断地发现问题、解决问题的过程中一步一步走向最终目标。监理方必须及时了解问题、跟踪问题的开展和解决进程，并有义务向系统各方通报现状和
4、提出监理方观点。监理价值也正是在发现问题、预警风险、促进解决问题的过程中得到充分表达。本文即是充分运用了问题管理的概念和方法,力图特定工程建立起特定的、有可操作性的问题管理机制。以下通过对发现问题、分析问题、处理问题等几个方面的分析探讨问题管理机制。1问题定义并不是所有人反响的问题都是真正的问题，监理方必须做出一系列判断。是不是问题？是暂时的问题还是长久的？有多严重？比方在我们监理过的某个政府信息化工程中，由于更换了开发商而新开发了一套软件，新软件替换旧软件上线后不久，用户方主管部门反响软件操作不方便导致咨询 不断，甚至某些用户产生怨言。这算不算问题？通常在软件重大版本更新很可能发生使用习惯问
5、题，更何况案例中的软件开发商也更换了。因此，用户的某些不理解和应用习惯未必意味着开发商的设计问题。问题定义：“问题是工程建设过程中出现的会对系统产生不利影响的故障、变化、和风险的总称。2发现问题监理方和承建方、用户方都应该建立标准、稳定的沟通渠道。对于某些特殊的工程监理方的客户和信息系统的用户可能不是同一个单位，即系统的投资方和用户方不一致，在这种情况下监理方需要建立和三方的沟通渠道。沟通渠道的完备为及时发现问题打下了根底，一般来说，问题会通过以下几种方式反响出来：用户方通过已建立的沟通渠道直接向监理方反响系统问题； 承建方通过已建立的沟通渠道直接向监理方反响用户方出现的业务问题、流程问题、管
6、理问题等； 客户方通过已建立的沟通渠道直接向监理方反响系统建设问题； 在监理会议上各方都可能反响系统建设问题； 用户方向承建方提交系统运行故障单，承建方再抄送监理方； 监理方在工作中主动发现问题。3分析问题对于信息化工程建设中出现的问题，往往是公说公有理、婆说婆有理。大型信息化工程，特别是涉及假设干个不同部门的工程，扯皮推委现象是造成工程延期的重要原因之一。因此“监理应运而生。人们常说成功的工程七分考管理，监理工作也是如此，技术层面的问题和分歧往往更容易解决。作为工程建设第三方，监理方既要保持公正、公平、公开的立场，又要建立和维持各方之间友好、一致的工作气氛。因此，监理方除了从技术角度为工程把
7、关，还要充分发挥管理艺术，这样才能协调处理好工程建设各方的关系，更有效率地解决问题，推开工程的进展。在工程建设中，对于各方反响的问题监理方首先必须做出判断。做出判断后才可以对问题立项，跟踪问题的开展和解决进程。那么是不是我们对待所有问题都一概而论呢？答案显然是否认的。问题的轻重缓急、问题提出方的态度、问题对系统影响的大小等因素都决定了监理方需要对问题分类处理，采取不同的监理策略区别对待。也只有如此才能面向工程，以到达最大限度地减少分歧、提高整体工作效率、表达监理价值。通常的监理工程中的问题可分为四类，如以下图：根据上图，很显然，A类问题最有可能表达监理方价值。这类问题往往涉及到多方关系协调，因
8、为只涉及到一方的问题大多可以通过该方的内部工作解决。如果问题涉及到多方，只能靠协调解决。这种时候最常见的消极情况是互不配合、只关注和自己有关的环节，扯皮、推卸责任。此时监理的一项重要作用得以发挥，即组织协调。例如，在我们监理的某个投资巨大的电子政务工程中出现了一个问题。由于相关的业务流程复杂，环节多，涉及到的单位多，协调困难，谁都不认为自己有问题，甚至出了问题都不知道该向谁反响，结果导致系统的最终效劳对象老百姓的利益受损。僵持了一段时间后，监理方意识到了问题的严重性。经过大量调研，发现在流程中假设干环节相对问题集中，而且这几个环节都由一个单位（甲）负责，于是提出问题解决方案，包括详细的处理流程
9、。两个层次，第一层次是：出了问题将直接向甲单位反响，该单位负责协调相关各方解决问题；第二层次是：成立问题协调小组，成员包括各单位领导，假设有甲单位协调解决不了的问题向协调小组汇报，由协调小组协调解决。解决问题的机制建立后，对最终用户来说有了反响问题的场所，各方责任清楚，提高了解决问题的效率，和政府的办事效率，老百姓的利益得到了保障。后来事实证明只有少数问题反响到了协调小组。在这个问题上，监理作用得到充分发挥。B类问题既然其他各方可以把它解决好，那么此时如果监理方再试图推动的话，会让其他各方感到多余，甚至更糟的话可能会有干预对方内部工作的嫌疑。比方在某工程中，用户方反响承建方对系统故障排查和效劳
10、相应的速度太慢，在这个问题上，承建方没有异议。事实上，问题的存在是由于他们的其他工作太忙而没有顾得上及时解决。因此，对于这个问题上，监理方在态度上立场鲜明，支持用户方的态度。C类问题同A类一样也有可能表达监理价值，但不同的是，其他各方没有意识到问题的严重性，甚至根本没有注意到问题的存在，这种情况下监理方必须立场鲜明地站出来，并指出问题的隐患，这是监理的职责所在。例如在某工程中，由于用户方的需求改动频繁，而且往往没有给承建方流出合理的时间，造成承建方疲于应付新需求变动而缺少时间完善系统。此时监理方注意到这个问题是由于缺少标准的需求管理造成的，于是我们拟订出管理制度文件并最终促成各方签署。在监理方
11、屡次说明利害关系之后，各方均认识到需求管理流程被标准后会提高系统建设总体效率，对谁都有好处。有很多问题在我们初步调研后即发现它们不影响大局，或者向“问题定义一节中提到的操作适应性等问题，这些问题各方都不关注，也确实不重要，甚至过了一段时间问题的提出者都把这件事忘了。这就是图中表示的D类问题，这类问题自然不用花费很多精力。4问题跟踪根据问题分类原那么确定了监理方策略后，监理方需要跟踪问题开展状况和解决进程。我们的问题跟踪机制总的思路是：建立问题列表，所有问题按某一特定的顺序排列，比方提出的时间。每个问题需包括问题编号、提出时间、提出人、描述、重要性级别、解决方案、解决方案批准人、要求解决时间、目
12、前状态等信息。而对于某一具体问题，我们建立XX问题跟踪表，目的是记录问题发生、开展、解决整个过程中与问题有关的活动、讨论、决议和监理方观点。表中应该包括问题编号、活动类型、活动日期、决议、监理方观点等信息。这样做可以为将来撰写问题报告打好根底。XX问题跟踪表和问题列表通过两个表中某些共同工程建立映射关系，比方问题编号或问题描述，如果是电子文件可以考虑建立超级链接。当然，由问题的重要程度不同，并不是每个具体问题都有必要建立问题跟踪表。41问题跟踪流程（如以下图所示）42流程说明根据问题跟踪表的内容，每周定期更新问题列表的“当前状态； 如有新问题产生，问题列表将即时更新，并即时产生该问题的问题跟踪
13、表； 跟踪一般分为两条线路，即承建方和用户方，因为每个问题都可能涉及到系统和业务两个方面； 每个问题一般由两个人共同跟踪，分别负责承建方和用户方两条线，其中一个是该问题的负责人； 针对重点问题跟踪所获得的全部信息都及时按时间顺序记录在一个确定的问题跟踪表中。问题跟踪表和问题列表通过两个表中某些共同工程建立映射关系，比方问题编号或问题描述，如果是电子文件可以考虑建立超级链接。； 由问题负责人即时更新问题跟踪表，并且每周三下午确定时间更新问题列表中的相应问题工程；5问题报告问题报告是在问题的某一阶段监理方对该问题认识的总结，可以是在问题发现阶段、问题解决阶段，也可以在问题解决后。问题报告的对象是监理方的客户，在客户的授权下可以抄送给工程其他相关各方。因此问题报告是监理方客户了解工程进展的重要渠道。报告的内容应包括对问题的描述，即问题的发生和开展过程，信息来源于问题跟踪表，还应包括监理方对问题的分析和监理方建议。问题报告是监理方客户了解工程进展的重要渠道，监理方应尽量多报告。
