|
|
|
|
|
|
|
|
|
|
|
负责具体实施的承建方应该有自己的项目管理，监理方代表项目建设方对承建方提出的工程计划进行监督和协调，对一些关键点进行控制。这些关键点主要属于进度、资金及质量的范畴，但不能涉及管理细节。工程项目管理主要以承建方为主，并强调在项目中组织并制定相关计划。
|
|
|
|
在一个大型信息系统工程项目的建设中，承建方可能有多个，比如硬件提供商、软件开发商和系统集成商等。而在市场竞争日益激烈的今天，专业化能促进生产效率和提高生产质量，故而承建方常常分解成一定的层次结构，如总承包商和分包商等，从而使一部分人或企业专注于项目管理的科学化。
|
|
|
|
从市场的角度看，总承包商既是买方又是卖方；从工程合同的角度来讲，他既要对建设方负全部法律责任，又要根据分包合同对分包商进行管理并履行义务，所有的主合同都会限定总承包商可以分包的最大范围。总承包商只能将某些具体的工程施工分包给分包商，但不能分包合同的责任和义务。总承包商不能期望通过分包逃避自己在合同中的法律和经济责任。
|
|
|
|
作为分包商，一般情况下不与建设方直接发生合同关系。分包商只接受总承包商的统筹安排和调度，它只对总承包商承担分包合同内规定的责任并履行规定的义务。
|
|
|
|
如果总承包商违反分包合同，则应该赔偿分包商的经济损失；分包商违反分包合同并造成建设方对总承包商的罚款或制裁，则分包商应该赔偿总承包商的损失。分包商是从总承包商处按分包合同索回其应得部分的，如果总承包商无力偿还债务，则分包商也同样蒙受损失，因此分包商的利益通常与总承包商的利益密切相关。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
项目监理方服务于信息系统建设合同的建设方与承建方。接受建设方委托后，监理方作为工程承包合同的监督者，所执行的原则是使工程承包合同成为“平等条约”；作为工程承包合同管理和工程款支付的签认者，所执行的原则是等价交换。因此监理方是为双方的利益服务的，而不仅仅为委托方服务。
|
|
|
|
根据工程监理的深入程度不同，信息系统工程监理可分为如下三种。
|
|
|
|
（1）咨询式监理。只解答用户方就企业信息化过程中提出的问题，其性质类似于业务咨询或方案咨询。这种方式费用最少，监理方的责任最轻，适合于对信息化有较好把握，并且技术力量较强的用户方采用。
|
|
|
|
（2）里程碑式监理。将信息系统的建设划分为若干个阶段，在每一个阶段结束都设置一个里程碑，在里程碑到来时通知监理方进行审查或测试。一般来讲，这种方式比咨询式监理的费用要多，监理方也要承担一定的责任。不过，里程碑的确定需要承建方的参与，或者说监理合同的确立需要开发方的参与，否则就会因对里程碑的界定不同而引起纠纷。
|
|
|
|
（3）全程式监理。一种复杂的监理方式，不但要求对系统建设过程中的里程碑进行审查，还应该派相应人员全程跟踪并收集系统开发过程中的信息，不断评估承建方的开发质量和效果。这种方式费用最高，监理方的责任也最大，适合于那些对信息系统的开发不太了解且技术力量偏弱的用户采用。
|
|
|
|
|
|
（1）信息系统工程监理可以帮助建设单位更合理地保证工程的质量、进度和投资，并合理且客观地处理好它们之间的关系。监理由独立的第三方依据相关技术标准来对工程建设进行监督，这样对信息系统工程的建设质量更能起到保驾护航的作用。在项目建设全过程中，监理单位要依据国家有关法律和相关技术标准，遵循守法、公平、公正、独立的原则，对信息系统建设的过程进行监督和控制。即在确保质量、安全和有效性的前提下，合理安排进度和投资。监理单位要帮助建设单位对工程有关方面控制进行再控制，对承建单位项目控制过程进行监督管理。
|
|
|
|
（2）在信息系统工程建设中，建设单位和承建单位有许多问题存在争议，双方都希望由第三方在工程的立项、设计、实施、验收及维护等各个阶段的效果都给予公正、恰当且权威的评价，这就需要监理单位来协调和保障这些工作的顺利进行。
|
|
|
|
（3）由于建设单位在信息技术等相关领域普遍存在缺乏人才和经验不足的问题，实践证明建设单位自行管理对于提高项目投资的效益和建设水平是无益的。通过第三方的专业服务，帮助建设单位对项目实施控制，并对建设单位和承建单位都做出约束，是监理作用一个重要体现。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
建设方是建设项目的主要投资者，有时也是项目的最终使用者，是在工程建设阶段的全权代表，建设项目的经济效益，如投资额度、工程质量、投入使用时间和使用寿命直接关系着建设方的切身利益。虽然承建方、监理方与建设方是平等的市场主体，但由于建设方是投资方，掌握着项目的最终资源——决定了其他方为从属地位，所以说建设方对工程项目管理起着主导性作用。建设方加强和改善对项目的管理是从根本上实现项目按质如期完成的最有效的途径之一。
|
|
|
|
作为项目管理集体中的主要负责人，建设方的作用是阐明本项目的目标并确认各项工作的轻重缓急，组织协调参与各方为此目标而通力合作，在管理决策过程中做出决策。但在某些具体的项目管理事务中，建设方并不总是处于主要负责人的地位，还要作为裁判、支持者、服务员及督促员的角色。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
（1）监督承建单位将合适的软件测试工程方法和工具集成到项目定义的软件过程中。
|
|
|
|
（2）监督承建单位依据项目定义的软件过程，对软件测试进行开发、维护、建立文档和验证，以满足软件测试计划的要求。
|
|
|
|
（3）监督承建单位依据项目定义的软件过程和计划实施软件的确认测试。
|
|
|
|
（4）计划和实施软件系统测试，实施系统测试以保证软件满足软件需求。
|
|
|
|
|
|
在软件测试阶段，监理的主要方法有定期检查、必要抽查、评审。
|
|
|
|
|
|
（2）根据实际需要对软件测试工程活动进行跟踪、审查和评估。
|
|
|
|
（3）对软件测试工程活动和产品进行评审和（或）审核，并报告结果。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
根据《信息系统工程监理暂行规定》，信息系统工程实行总监理工程师负责制。总监理工程师行使合同赋予监理单位的权限，全面负责受委托的监理工作。在监理执行过程中，监理单位取得建设单位书面意见后，可以调换总监理工程师人选。
|
|
|
|
总监理工程师除必须取得监理工程师资格证书和注册证书之外，还应具有相当高的业务技术水平、丰富的管理经验和良好的职业道德，其岗位职责如下。
|
|
|
|
|
|
（2）主持编写项目监理规划、审批项目监理实施细则，负责管理项目监理机构的日常工作。
|
|
|
|
（3）审查分包单位的资质，给建设单位及总包单位提出审查意见。
|
|
|
|
（4）检查和监督监理人员的工作，根据工程项目的进展情况进行人员调配，并在实施监理工作的过程中对不称职的监理人员进行调换。
|
|
|
|
（5）主持监理工作会议（包括监理例会），签发项目监理机构的文件和指令。
|
|
|
|
（6）审查承包单位提交的开工报告、施工组织设计、技术方案及进度计划。
|
|
|
|
（7）审查签署承包单位的申请、支付证书和竣工结算。
|
|
|
|
|
|
|
|
（10）调节建设单位与承包单位的合同争议，处理索赔，审查工程延期。
|
|
|
|
（11）组织编写并签发监理月报、监理工作阶段报告、专题报告和项目监理工作总结。
|
|
|
|
（12）审查签认分部工程和单位工程的质量检验评定资料，审查承包单位的竣工申请，组织监理人员对待验收的工程项目进行质量检查，参与工程项目的竣工验收。
|
|
|
|
|
|
一般来说，在发生下列情况之一时，总监理工程师可下达停工令。
|
|
|
|
|
|
|
|
（3）施工出现了安全隐患，总监理工程师认为有必要停工以消除隐患。
|
|
|
|
|
|
（5）承建单位未经许可擅自施工，或拒绝监理机构管理。
|
|
|
|
（6）实施、开发中出现质量异常情况，经提出后承建单位仍不采取改进措施，或者采取的改进措施不力，还未有使质量状况发生好转的趋势。
|
|
|
|
（7）隐蔽作业（指综合布线及系统集成中埋入墙内或地板下的部分）未经现场监理人员查验自行封闭、掩盖。
|
|
|
|
（8）未经监理工程师审查同意，而擅自变更设计或修改图纸进行施工者。
|
|
|
|
（9）未经技术资质审查的人员或不合格人员进入现场施工。
|
|
|
|
（10）使用没有技术合格证的工程材料、没有授权证书的软件，或者擅自替换、变更工程材料及使用盗版软件。
|
|
|
|
（11）擅自允许未经项目监理机构审查认可的分包单位进场施工。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
主要包括故障监控和性能、流量、负载等状态监控，这些监控关系到集群的健康运行及潜在问题的及时发现与干预。
|
|
|
|
（1）服务故障、状态监控：主要是对服务器自身、上层应用、关联服务数据交互监控；例如针对前端Web Server，就可以有很多种类型的监控，包括应用端口状态监控，便于及时发现服务器或应用本身是否崩溃、通过ICMP包探测服务器健康状态，更上层可能还包括应用各频道业务的监控，这些只是一部分，还有多种监控方式，依应用特点而定。还有一些问题需解决，如集群过大，如何高性能地进行监控也是一个现实问题。
|
|
|
|
（2）集群状态类的监控或统计，为合理管理调优集群提供数据参考，包括服务瓶颈、性能问题、异常流量、攻击等问题。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
系统维护工作的对象是整个系统的配置。由于问题可能来源于系统的各个组成部分，产生于系统开发的各个阶段，因此系统维护工作并不仅仅是针对源程序代码，而且还包括了系统开发过程中的全部开发文档。所以，一旦业务处理出现问题或发生变化，就要修改应用程序及有关文档。软件维护是系统维护最主要的内容。
|
|
|
|
|
|
（1）任何人员不得擅自对系统文件进行删除或修改。软件操作人员不得对系统文件进行任何内容的操作。
|
|
|
|
（2）系统管理员对软件系统进行全面维护，并进行记录。
|
|
|
|
|
|
（4）建立故障报告制度。系统运行或软件操作中发生故障，如属简单故障，由系统管理员现场解决；现场无法解决的，由第一发现者进行故障登记，部门负责人会同系统管理员制定处理方案（方案包括：故障分析、拟采取措施、保障数据安全防范措施等），经核算中心分管主任批准后实施。对于无法排除的故障，由系统管理员及时联系相关单位解决。
|
|
|
|
（5）对软件进行修改、升级时，首先要全面备份系统的数据，做好新旧系统数据的衔接工作。
|
|
|
|
|
|
（1）完善性的维护。完善性维护就是在应用软件系统使用期间为不断改善和加强系统的功能和性能，以满足用户日益增长的需求所进行的维护工作。在整个维护工作量中，完善性维护居第一位。
|
|
|
|
（2）适应性维护。适应性维护是指为了让应用软件系统适应运行环境的变化而进行的维护活动。适应性维护工作量约占整个维护工作量的25%。
|
|
|
|
（3）纠错性维护。纠错性维护的目的在于，纠正在开发期间未能发现的遗留错误。对这些错误的相继发现，对它们进行诊断和改正的过程被称为纠错性维护。这类维护约占总维护工作量的20%。
|
|
|
|
（4）预防性维护。其主要思想是维护人员不应被动地等待用户提出要求才做维护工作，而应该选择哪些还有较长使用寿命的部分加以维护。
|
|
|
|
|
|
自己公司开发的软件、合同开发的软件、市场买的软件，这三种软件的维护途径可以是不同的。
|
|
|
|
|
|
按合同开发的软件产品交付后，开发方应依据开发时签定的合同，负责软件的维护和软件版本升级工作。维护活动一般包括：对顾客使用中出现的软件故障进行测试、分析和修复；在维护阶段，按顾客提出的功能和性能改进要求进行软件版本升级，升级后的软件版本应纳入配置管理，并保存软件维护、升级记录。
|
|
|
|
若购买了某种软件产品且该软件在产品支持周期内，则还可以购买该软件公司的软件维护服务。软件公司为软件产品用户推出专业技术支持服务，服务一般由公司具有丰富产品知识和实践经验的资深软件工程师协同技术中心专家组成专业技术团队共同提供，目的是帮助客户及时、快速、可靠地解决在软件系统的维护过程中所遇到的技术问题，使得客户的软件系统可以更加安全稳定地运行，以保障和促进客户业务的顺利开展并取得更大的成功。
|
|
|
|
软件维护合同一般包括软件的更新和技术支持。两者捆绑在一起每年统一收取一笔费。客户需要签定软件维护合同，以获得技术支持和将来的升级服务。在多数情况下合同的主要目的是软件的更新。
|
|
|
|
系统维护中经常会遇到一些问题。系统维护中的编码本身造成的错误比例并不高，仅占4%左右，而绝大部分问题源于系统分析和设计阶段。通常，理解别人编写的程序是很难的，且难度随着软件配置文档的减少而增加；绝大多数系统在设计和开发时并没有很好地考虑将来可能的修改，如有些模块不够独立，牵一发而动全身；系统维护工作相对缺乏挑战性，使系统维护人员队伍不稳定。所以，一般来说，系统维护人员应当就是系统的原开发人员中的一部分。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
维护阶段是软件生存期中时间最长的阶段。软件一旦交付正式投入运行后便进入软件维护阶段。该阶段的关键任务是通过各种必要的维护活动使系统持久地满足用户的需要。每一项维护活动都应该准确地记录下来，作为正式的文档资料加以保存。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
维护性是指软件产品可被修改的能力。修改可能包括修正、改进或软件适应环境、需求和功能规格说明中的变化。
|
|
|
|
|
|
易分析性是指软件产品诊断软件中的缺陷或失效原因，以及判定待修改的部分的能力。
|
|
|
|
|
|
易改变性是指软件产品使指定的修改可以被实现的能力。
|
|
|
|
|
|
稳定性是指软件产品避免由于软件修改而造成意外结果的能力。
|
|
|
|
|
|
|
|
|
|
维护性依从性是指软件产品依附于同维护性相关的标准或约定的能力。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
该重工集团有自己的管理模型。顶端按照工业4.0，集团管控，包括阿米巴经营模式；相应的流程制度，岗位职责，工作标准，成本绩效。左边是信息化管控，右边是智能化建设，下面是精益管理，底下是企业文化。这样的管理需要用信息化系统去实现。
|
|
|
|
在这架构中，ERP系统是基础，利用CRM系统和客户对接，SRM管理供应链，MES监控生产。利用OA把所有业务打通，而后利用专业软件，实现前端的商务智能分析。
|
|
|
|
下图的物联网设想把MES系统和机床、物流以及检测设备连起来，做成物联化，把ERP升级到CRM或者SCRM，把供应商和客户打通，形成企业的互联网。
|
|
|
|
|
|
|
|
下图是整个业务系统的总体架构图。一个平台、两级部署、三层应用，包括商业分析、移动应用、企业门户和协同管理。
|
|
|
|
|
|
|
|
在业务系统这块，先后上线了ERP系统、PLM系统、OA系统和MES系统。上线的这些系统，虽然参与了生产、管理，打通了业务，却没有让领导层参与，反馈报告依然采用Excel、PPT。作为决策者，领导层更应该参与数据的可视化呈现过程。所以，2014年上线了帆软报表系统，提升了数据前端展示，利用某报表软件承担的BOSS系统决策，将领导层纳入管理体系。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
质量控制是监督并记录质量活动执行结果，以便评估绩效，并推荐必要的变更过程，其主要作用包括：
|
|
|
|
.识别过程低效或产品质量低劣的原因，建议并采取相应措施消除这些原因。
|
|
|
|
.确认项目的可交付成果及工作满足主要干系人的既定需求，足以进行最终验收。
|
|
|
|
|
|
|
|
项目管理计划中包含质量管理计划，用于控制质量。质量管理计划描述将如何在项目中开展质量控制。
|
|
|
|
|
|
质量测量指标描述了项目或产品属性及其测量方式。质量测量指标的例子包括功能点、平均故障间隔时间（MTBF）和平均修复时间（MTTR）。
|
|
|
|
|
|
质量核对单是结构化清单，有助于核实项目工作及其可交付成果是否满足一系列要求。
|
|
|
|
|
|
工作绩效数据包括实际技术性能（与计划比较）、实际进度绩效（与计划比较）和实际成本绩效（与计划比较）。
|
|
|
|
|
|
实施整体变更控制过程中批准的变更请求，可包括各种修正，如缺陷补救、修订的工作方法和修订的进度计划。需要核实批准的变更是否已得到及时实施。
|
|
|
|
|
|
可交付成果是任何独特并可核实的产品、成果或能力，最终将成为项目所需的、确认的可交付成果。
|
|
|
|
|
|
项目文件可能包括协议、质量审计报告和变更日志（附有纠正行动计划）、培训计划和效果评估、过程文档。
|
|
|
|
|
|
可能影响质量控制过程的组织过程资产包括组织的质量标准和政策、标准化的工作指南、问题与缺陷报告程序及沟通政策。
|
|
|
|
|
|
|
|
七种基本质量工具包括因果图、流程图、核查图、帕累托图、直方图、控制图和散点图，如本章第1张图所示。
|
|
|
|
|
|
统抽样是指按照质量管理计划中的规定，抽取和测量样本。
|
|
|
|
|
|
检查是指检验工作产品，以确定是否符合书面标准。检查的结果通常包括相关的测量数据。检查也可称为审查、同行审查、审计或巡检等。
|
|
|
|
|
|
对所有已批准的变更请求进行审查，以核实它们是否已按批准的方式得到实施。
|
|
|
|
|
|
|
|
质量控制测量结果是对质量控制活动结果的书面记录。应该以制订质量管理计划过程中所确定的格式加以记录。
|
|
|
|
|
|
对变更或补救过的对象进行检查，做出接受或拒绝的决定，并把决定通知干系人。被拒绝的对象可能需要返工。
|
|
|
|
|
|
质量控制过程的一个目的就是确定可交付成果的正确性。核实的可交付成果是范围确认过程的一项输入，以便正式验收。
|
|
|
|
|
|
工作绩效信息是从各控制过程收集，并结合相关背景和跨领域关系进行整合分析而得到的绩效数据。
|
|
|
|
|
|
如果推荐的纠正措施、预防措施或缺陷补救导致需要对项目管理计划进行变更，则应按既定的整体变更控制过程的要求，提出变更请求。
|
|
|
|
|
|
项目管理计划中可能需要更新的内容包括质量管理计划和过程改进计划。
|
|
|
|
|
|
可能需要更新的项目文件包括质量标准、协议、质量审计报告和变更日志（附有纠正行动计划）、培训计划和效果评估、过程文档。
|
|
|
|
|
|
可能需要更新的组织过程资产包括完成的核对单和经验教训文档。
|
|
|
|
|
|
|
|
|
|
|
|
|
