商业计划第4章工程项目解决方案.docx

商业计划第4章工程项目解决方案.docx

《商业计划第4章工程项目解决方案.docx》由会员分享，可在线阅读，更多相关《商业计划第4章工程项目解决方案.docx（8页珍藏版）》请在冰豆网上搜索。

商业计划第4章工程项目解决方案

系统需求包括三个不同的层次业务需求用户需求和功能需求也包括非功能需求业务需求反映了组织机构或客户对系统产品高层次的目标要求用户需求指用户使用产品必须要完成的任务功能需求定义了开发人员必须实现的系统功能使得用户能完成他们的任务从而满足了业务需求非功能需求包括产品必须遵从的标准规范和合约外部界面的具体细节性能要求设计或实现的约束条件及质量属性对于我们所拿到的项目需求分析报告往往忽略了很多客户的隐形需求一般而言包括维护需求升级需求易用性需求性能需求现在客户也在不断成熟以上需求会或多或少的提到但是请注意很可能不够全面所以我们需要认认真真的考虑一下这些需求到底应该包含些什么客户对维护的要求一般至少包括这么几个1日志需求日志需求是和客户的隐性需求密切相关并且几乎全部涉及的一种需求例如日志要记录维护信息和升级信息日志还要简单明了一看就知道写的啥意思另外日志记录功能还不能对系统的性能有大的影响2故障定位的能力就是说当系统出现问题时客户希望系统能够通过某种方式迅速查明故障的原因并找到解决或者规避的办法3日常维护通常包括软件和硬件的健康检查4故障报警当系统出现严重故障时能够给出足够的信息并触发故障处理流程一般来说客户对升级的需求有这么几点1可控制的升级即检测是否可升级是否执行升级多个升级目标的选择升级的计划任务等都是可以控制的比如可以设定自动检测是否升级设定自动升级到最高版本设定执行升级必须为手工设置设置手工升级时可以立即升级也可以指定计划任务时间等等2不影响业务的升级基本上客户都希望升级不要影响他们的正常业务但是有些系统实在太老了基于这种旧系统的再开发项目必然受限于原系统的升级方案这时就考虑1能不能通过升级使系统以后升级不再影响业务2如果不能怎样使本次升级对业务的影响最小3升级的简单性升级应该简单快捷没有太多的参数需要配置没有太多需要手工干预的步骤4升级的完整性尤其是对于分布式系统升级时需要考虑各个部件之间版本的一致性一个升级方案必须是完整的不能在升级以后出现由于版本间不兼容的原因而导致系统无法工作例子一个简单的CS系统采用加密通道进行通讯现在升级加密算法该如何设计呢假设是互联网应用有上万个客户端该如何设计呢从这个例子可以看出系统的设计从一开始就必须考虑这些隐性需求否则系统架构可能就要推翻重来通常提到易用性一般觉得无非是界面和帮助没错但是不全让我们看几个例子可以大概理解一下易用性是什么概念同样是微软C语言乘微软之名挟操作系统之利语言和开发环境都不可谓不强大但是结果怎样呢多数人情愿用Java微软更是不得不推出C来与Java抗衡在中文输入法的竞争中强大高效的笔画输入法败给了拼音输入法现在拼音输入法大行其道笔画输入几乎鲜有提起1工程项目开发的前期构思项目可行性分析报告项目需求分析报告方案设计说明书隐形需求维护需求日志需求故障定位的能力日常维护故障报警升级需求可控制不影响业务简单性完整性隐形需求维护需求日志需求故障定位的能力日常维护故障报警升级需求可控制不影响业务简单性完整性易用性需求Unix与Windows笔画输入法与拼音输入法VC与Java常用的功能应该能够直接了当的访问操作应该照顾客户的习惯优雅一般来言易用性的需求还包括1常用的功能应该能够直接了当的访问如财务系统不同的角色有不同的常用功能系统应该设计为可以根据角色来打开不同的初始页面3优雅还是用微软的VisualStudio做例子编译错误可以直接通过双击跳转到源代码所在错误点而不像Makefile那样只是生硬的输出文件和行号打开一个巨大的文件给出一个可度量的进度条总比只显示一个沙漏要好吧1工程项目开发的前期构思项目可行性分析报告项目需求分析报告方案设计说明书隐形需求维护需求日志需求故障定位的能力日常维护故障报警升级需求可控制不影响业务简单性完整性易用性需求Unix与Windows笔画输入法与拼音输入法VC与Java常用的功能应该能够直接了当的访问操作应该照顾客户的习惯优雅性能需求分清楚软件各部分都有什么样的性能需求用户参与的操作性能要求通常高于其他操作极限提示避免瘫痪报价对需要采购商品价格的市场调研如何采集到商品的实际价格虚价与实价如广告中房子的价格微机组装公司的报价1首先分清楚哪些部分各自有什么样的性能需求用户参与的操作性能要求通常高于其他操作2知道自己的承受上限达到上限的时候通过合理的方法让系统给予提示而不是直接瘫痪细节上包括长时间运行要有提示已输过的内容尽量不要再次输必要时用下拉列表框来选命令按钮要有悬停帮助信息因权限或操作条件限制时有关操作元素自动置灰或不可见不离开编辑界面添加新内容时可用鼠标也可用键盘定位至输入字段不能输入不合理的日期完成了项目解决方案书后根据实际需求和市场实际运作效果我们一方面可以确定是开始进行项目产品预研发或者根据新的客户需求完善本项目所有这些取决于市场的反馈信息根据不同的市场反馈做出不同的开发计划只有这样才能避免闭着眼睛走路同时项目更有了明确的开发目标一旦项目列入开发计划我们就应该集中技术人员成立项目组确定项目负责人进行实质性的项目开发工作2工程项目开发期对于软件实现主要包括以下几部分系统结构设计大体体现和概括了业务逻辑和业务流程软件结构设计软件的体系结构性能分析子系统划分等软件模块划分编写代码软件模块集成软件子系统集成软件子系统测试系统联调软件系统整体测试软件部署以上各个步骤为典型的软件设计过程强调的一点是软件实现过程越规范效率和软件质量越高项目可维护性就越好软件实现过程规范企业化软件生产能力个人作坊式的软件生产软件生产的工业化一个软件公司无论大小只要是基于个人作坊式的生产不要说骨干甚至一个主要程序员突然离开都可能会使整个项目拖延严重的情况下甚至会使项目惨遭失败许多用户在软件工程项目签约时要求开发商提供主要工作人员名单和简历并要求保证主要开发人员不得在项目完成前离开一个软件企业要证明该企业的软件开发能力是企业的能力而不是个人能力80年代未一个不同于以往的概念逐渐被接受一个企业的软件能力取决于该企业的过程能力一个企业过程能力越成熟那么该企业的软件生产能力就越有保证大量的实践经验表明在体现企业的软件开发能力的因素中技术或工具并不是第一位的什么是企业的过程能力呢先看基于个人行为的软件开发方式假如一个企业获得了一个软件项目交给一个小组实施所有有关的项目活动均由这个小组或小组负责人决策和执行整个项目的执行对企业近乎是一个黑箱子也许这个项目非常成功这个小组成员是由天才和勤奋的软件工程师组成但企业难以让其他小组共享他们的经验因为他们的天才活动是即兴发挥的然而更可能出现的情况是这个项目不成功同时更糟的是出于同样的原因失败的教训也无法让其他小组吸取换句话说无论这个小组成败与否对于企业今后的软件开发几乎都是没有帮助的我们再看看另一种情况一个软件企业建立了一个软件开发过程并通过政策保证强制实行这个过程项目的执行不再是一个黑箱子企业清楚地知道项目是按规定的过程进行的所设定的过程可能有缺陷但问题会在执行的过程中反映出来企业在该过程执行一段时间后可根据反映的问题来改善这个过程周而复始这个过程逐渐完善成熟由于这个过程不是依赖于某个人的而是企业开发实际经验的结晶因此企业基于这个过程的软件开发能力也随之成熟那么这是否意味着随意建立一个过程都能逐渐成熟起来呢从理论上讲若有足够的时间那么应该是可以的但在实际上却是不现实的任何企业都不会容忍长期缓慢的过程改善在软件开发过程中根据几十年软件工程的发展经验人们已识别出一些关键的过程域KPA利用过去软件工程发展的成果侧重这些关键过程域的实施将会有效地建立起一个过程需要说明的是企业能力是指执行过程的能力因此企业能力的改善应是一个渐进过程而不可能是一个革命性的飞跃过程关键过程域的实施也需逐步进行上世纪90年代初美国卡内基·梅隆大学软件工程研究所提出了软件过程能力成熟模型即SW-CMM详细资料可访问该研究所站点httpwwwseicmuedu目前该模型在美国得到了广泛的应用并成为事实上的软件过程改进的工业标准据悉世界著名的一些软件公司已经开始推广该模型不少印度公司已经应用该模型并已通过SW-CMM5级认证由此也可看出中国与印度软件产业的差距至于项目成功与否除了实现过程要规范外对乙方来说关键取决于项目组成员间的合作工作效率和士气对甲方的要求是全力配合勿推委优秀的项目领导者有效工作的项目团队对项目管理有利的组织结构用户的积极态度是一切项目成功的理想环境项目团队往往因为缺乏充分的授权和支持包括用户单位的全力配合造成逐渐衰落并最终导致项目的失败在软件开发中文件编制规模一般都同软件的规模大小联系起来软件的规模不妨分为四级1小规模软件源程序行数小于5000的软件2中规模软件源程序行数为10000～50000的软件

3大规模软件源程序行数为100000～500000的软件

4特大规模软件源程序行数大于500000的软件项目开发计划为软件项目实施方案制订出具体计划应该包括各部分工作的负责人员开发的进度开发经费的预算所需的硬件及软件资源等软件需求说明书软件规格说明书对所开发软件的功能性能用户界面及运行环境等作出详细的说明它是在用户与开发人员双方对软件需求取得共同理解并达成协议的条件下编写的也是实施开发工作的基础该说明书应给出数据逻辑和数据采集的各项要求为生成和维护系统数据文件做好准备概要设计说明书说明功能分配模块划分程序的总体结构输入输出以及接口设计运行设计数据结构设计和出错处理设计等为详细设计提供基础详细设计说明书着重描述每一模块是怎样实现的包括实现算法逻辑流程等用户操作手册本手册详细描述软件的功能性能和用户界面使用户对如何使用该软件得到具体的了解为操作人员提供该软件各种运行情况的有关知识特别是操作方法的具体细节测试计划为做好集成测试和验收测试需为如何组织测试制订实施计划计划应包括测试的内容进度条件人员测试用例的选取原则测试结果允许的偏差范围等测试分析报告测试工作完成以后应提交测试计划执行情况的说明对测试结果加以分析并提出测试的结论意见项目开发总结报告软件项目开发完成以后应与项目实施计划对照总结实际执行的情况如进度成果资源利用成本和投入的人力此外还需对开发工作做出评价总结出经验和教训软件维护手册主要包括软件系统说明程序模块说明操作环境支持软件的说明维护过程的说明便于软件的维护软件问题报告指出软件问题的登记情况如日期发现人状态问题所属模块等为软件修改提供准备文档软件修改报告软件产品投入运行以后发现了需对其进行修正更改等问题应将存在的问题修改的考虑以及修改的影响作出详细的描述提交审批必要的市场调研对需要采购的商品价格进行市场调研完善项目的开发计划草拟合同文本主要文档的内容项目开发计划软件需求说明书软件规格说明书概要设计说明书详细设计说明书用户操作手册测试计划测试分析报告项目开发总结报告软件维护手册软件问题报告软件修改报告开发进度月报可行性分析报告仅以软件需求说明书起草为例来说明我们应具备的能力需求说明书所说明的功能需求充分描述了软件系统所应具有的外部行为需求说明书在开发测试质量保证项目管理以及相关项目功能中起着重要作用对一个连锁超市用户甲方来说他们后面是成百上千个供应商前面是成千上万个消费顾客怎样利用软件管理错综复杂的供应商和消费顾客如何做好精细到一个小小调料包的进销调存的商品流通工作这些都是连锁超市企业需要信息管理系统的理由软件开发的意义也就在于此而弄清商业用户如此复杂需求的真面目正是软件开发成功的关键所在经理我们要建立一套完整的商业管理软件系统包括商品的进销调存管理实现总部-门店的连锁经营的计算机管理模式达到门店自动订货供应商自动结算卖场通过扫条码实现销售管理人员能够随时查询门店商品销售和库存情况分析员我已经明白这个项目的大体结构框架这非常重要但在制定计划之前我们必须收集一些需求经理觉得奇怪我不是刚告诉你我的需求了吗分析员实际上您只说明了整个项目的概貌和目标这些高层次的业务需求不足以提供开发的内容和时间我需要与实际将要使用系统的业务人员进行讨论然后才能真正明白达到业务目标所需功能和用户要求了解清楚后才可以发现哪些是现有组件即可实现的哪些是需要开发的这样可节省很多时间分析员尽量解释从用户处收集需求的合理性如果我们只是凭空猜想用户的要求结果不会令人满意我们只是软件开发人员而不是采购专家营运专家或是财务专家我们并不真正明白您这个企业内部运营需要做些什么无数的案例表明未真正明白这些问题就开始编码结果没有人对产品满意下一层次需求用户需求必须从使用产品的用户处收集因此这些用户构成了另一种软件客户他们清楚要使用该产品完成什么任务即功能性的特性需求此外还有一些非功能性的特性需求例如软件产品必须遵从的标准规范程序的易用性健壮性和可靠性等而这些特性将会使用户很好地接受具有该特点的软件产品233需求风险以上我们看到的是某客户项目经理与系统开发小组的分析人员讨论业务需求在项目开发中所有的项目风险承担者都对需求分析阶段倍感兴趣这里所指的风险承担者包括客户方面的项目负责人和用户开发方面的需求分析人员和项目管理者这部分工作做得到位是开发出一个优秀的软件产品的基础同时也会令客户满意若处理不好则会导致误解挫折障碍以及潜在的质量和业务价值上的威胁由此可见需求分析奠定了软件工程和项目管理的基础开发软件系统最困难的事情就是准确说明开发什么最为困难的工作便是编写出详细技术需求这包括所有面向用户面向机器和其它软件系统的接口同时这也是一旦做错将最终会给系统带来极大损害的部分并且以后再对它进行修改也极为困难　　　　为什么这么说呢因为在大多数的软件系统中最终用户可能都不清楚他的需求是什么这是千真万确的如果你的用户告诉你需求就是这些了不要相信他继续刨根问底直到你们都筋疲力尽了　　虽然听上去有些不可思议但这是教训之谈几乎没有一个用户在软件接近完成的时候会不提出更改要求客户项目经理通常阐明产品的高层次概貌即各模块的主要业务内容为后继工作建立了一个指导性的框架其他任何说明都应遵循各模块的主要业务需求的规定经理层有时试图代替实际用户说话但通常他们无法准确说明用户需求用户需求来自产品的真正使用者必须让实际用户参与到收集需求的过程中如果不这样做产品很可能会因缺乏足够的信息而遗留不少隐患在实际需求分析过程中如果您希望软件成功那么必须要花上数天时间来消除需求中模糊不清的地方和一些使开发者感到困惑的方面优秀的软件产品建立在优秀的需求基础之上而优秀的需求源于客户与开发人员之间有效的交流和合作只有双方参与者都明白自己需要什么成功的合作需要什么时才能建立起一种良好的合作关系由于项目的压力与日俱增所有项目风险承担者有着一个共同目标那就是大家都想开发出一个既能实现商业价值又能满足用户要求还能使开发者感到满足的优秀软件产品开发人员与客户交流需要好的方法下面建议20条法则客户和开发人员可以通过评审以下内容并达成共识如果遇到分歧将通过协商达成对各自义务的相互理解以便减少以后的磨擦如一方要求而另一方不愿意或不能够满足要求1分析人员要使用符合客户语言习惯的表达2分析人员要了解客户的业务及目标3分析人员必须编写软件需求报告4报告中各种图表的解释说明5开发人员要尊重客户的意见6开发人员要对需求及产品实施提出建议和解决方案7描述产品使用特性8允许重用已有的软件组件9对变更的代价提供真实可靠的评估10满足客户功能和质量要求11给分析人员讲解您的业务12抽出时间清楚地说明并完善需求13准确而详细地说明需求14及时作出决定15尊重开发人员的需求可行性及成本评估16划分需求的优先级17评审需求文档和原型用户体验设计18需求变更要立即联系并按规定处理19遵照项目变更控制过程要求进行变更20尊重开发人员采用的需求分析过程对需求说明书的签名是建立在一个需求协议的基础上因此我们对签名应该这样理解我同意这份需求文档表述了我们对项目软件需求的了解进一步的变更可在此基础上通过项目定义的变更过程来进行我知道变更可能会使我们重新协商成本资源和项目阶段任务等事宜对需求分析达成一定的共识会使双方易于忍受将来的摩擦这些摩擦来源于项目的改进和需求的误差或市场和业务的新要求等需求确认将迷雾拨散显现需求的真面目给初步的需求开发工作画上了双方都明确的句号并有助于形成一个持续良好的客户与开发人员的关系为项目的成功奠定了坚实的基础沟通是一门艺术也是能力不论您的目的是为了自信地演说轻松地谈判还是愉快地销售它都将协助您有效的增进信息传递沟通的技巧交流沟通是人类行为的基础但是您的交流沟通是否能准确传达出您的愿望或对某事的态度11工程项目沟通的含义项目相关人员间的问题交流和项目进展等信息的共享工程项目尤其大型工程项目参与单位多涉及设计方案工程进度安全质量变更索赔等所以项目团队的交流沟通不仅信息数量大而且信息处理复杂如何实现项目科学高效的沟通管理呢12沟通分类121按沟通的形式正式沟通会议非正式沟通和报告报表正式沟通指按照合同规定的程序或格式进行的具有一定合同约束效力的沟通包括信函传真现在很多信函传真经相关人员的草拟审核完毕后经过合同授权人签字或盖章扫描后利用合同指定的项目邮箱进行传送当对方收到后通过邮箱发送回执确认而不必要送达原件到对方会议包括按照合同规定召开正式例会和不定期的专项会议并形成会议纪要备查参加会议的人员应具有所讨论问题的决策权力由于信函传真会议纪要具有相应的约束力双方交流时都比较慎重导致沟通过程中很多真实的信息不愿意透露23文档编写应具备的能力连锁超市的信息管理系统开发人员与客户交流20条法则非正式沟通指口头交流电话联系私人间邮件往来这种沟通方式更方便快捷由于沟通的信息或结果没有合同的约束力所以交流时彼此警惕性不高表达的信息有些比较真实对方的某位人士可能会透露目前项目存在的一些问题报告报表指按照合同规定定期提交的日报周报月报或者按照合同提交的各种审批表单如材料审批单加班许可申请表等121按沟通的对象注意交流沟通的时效一般国际工程项目都规定某类问题提出和答复期限比如一般的国际项目发生索赔时索赔方要在发生28天内提出索赔申请超过28天索赔无效对方提出的变更申请单一般要在7个工作日内答复超过期限不答复就等于同意对方的变更申请不要轻视非正式交流在对外交流沟通中正式沟通的形式很重要但是非正式交流也不能轻视很多正式交流沟通前都要先做大量的非正式交流以增进双方的理解和共识为正式沟通排除障碍铺平道路这样正式沟通中才能比较容易的达成结果提高正式交流的效率对外沟通中要把握以下原则以合同为依据以非正式交流为铺垫以正式交流为准绳以书面双方签字的书面材料为结果履行好合同义务和权利建立维护良好的客户关系提倡非正式交流发挥主管领导的协调作用一家国际工程公司设置了采购部和项目部两大部门采购部负责工程项目大型设备的招标采购项目部负责工程的设计与实施采购部采购设备时需要项目部提供完整的设备技术规范书于是就向项目部写函正式索取建立开放的交流沟通团队文化一个论资排辈工作岗位级别鲜明的团队里表达观点时就会谨小慎微不敢轻易发言很难做到集思广益协同配合一个开放的团队里踊跃发言各抒己见不自觉地表达意见可发挥每个人的聪明才智项目经理在遇到不符合开放交流文化的做法时要坚决制止不要放纵在员工看来不制止就等于提倡开会讨论是团队交流沟通的一个有效手段团队内部的会议不同于对外沟通的会议其目的是把多人召集起来集思广益寻找问题的最佳解决方案既然是讨论就难免有人表达的观点不恰当进行反驳时要注意讲话的方式要做到对事不对人不要给人造成有人身攻击的感觉影响发言人的热情伤害同事间的感情多人交流话题容易跑偏作为会议的组织者要及时纠正讨论的话题不同解决方案的争论在对探讨解决方案效果不大作为部门领导要在适当的时候终止争论进行总结发言确定解决问题的最佳方案项目沟通首先要有明确目的沟通前项目经理要弄清楚作这个沟通的真正目的是什么要对方理解什么确定了沟通目标沟通的内容就围绕沟通要达到的目标组织规划也可以根据不同的目的选择不同的沟通方式其次要做到充分的听与艺术的说项目经理只有集中精力地听才能领会讲话者的意图只有领会了讲话者的意图才能选择合适的语言和方法进行沟通沟通是人们获取信息并在其指导下更加出色地进行工作必经的核心过程良好的沟通不仅意味着把自己的思想整理得井然有序并将其进行适当的表述使别人一听就懂而且还要深入人心促使听者全神贯注4良好沟通的益处能获得更佳更多的合作能减少误解能使人更乐于作答　　能使人觉得你的话值得聆听　　能使你办事更加井井有条　　能提高你进行清晰思考的能力　　能使你感觉现能把握所做的事

人性对赞赏比较认同在适当时候不妨用欣赏的眼光赞美他人的优点这样对方就会产生成就感容易认同你为知己而继续深入交往

结交他人应寻找双方的共同点谈一些互相感兴趣的话题只有志同方可道合

对人提出批评应该先肯定对方优点再讲自已的看法不可力争要嬴

11成信院参加青海三江源信息传输分系统应用软件开发及系统集成项目申报书业务运行监控系统doc12校园网设计方案13新型银行办公系统14企业银行系统解决方案设计机房摆放计算机240台写出这些计算机的硬件配置清单价格考虑作为学校机房的计算机应安装哪些必备的硬件画出网络布线图计算网络设备构造的成本给出总的报价需求确认意味着什么第一节工程项目的开发过程甲方用户乙方开发单位试用项目成果准备验收文档一般按功能模块签字认可其他文档3项目开发的后期这一工作完成的是否出色对获取客户后期合同和产品的推广至关重要可获取项目的第2笔付款第三节有效沟通1概述第三节有效沟通软件需求规格说明规范《计算机软件需求说明编制指南》GBT93851988GBT9385-2008第三节有效沟通日本某大型电机厂的科长A某为了选定项目供应商而赴中国考察时的事从今以后就请多关照了只是一个礼节上的问候第三节有效沟通工程项目沟通项目相关人员间的问题交流项目团队间的交流沟通沟通分类按沟通的形式正式沟通会议非正式沟通和报告报表一定合同约束效力1概述对外沟通凡是以经济合同为基础进行合作的项目团队叫外部单位与外部单位进行的交流沟通叫对外沟通内部沟通内部沟通指团队内部各个职能部门间的交流讨论2如何正确的与外部进行交流沟通对外沟通尽量采用正式沟通和会议的方式进行　对外沟通要以合同条款为依据合同是双方交流的基础也是判断双方对错的唯一标准所以首先我们要深入学习合同不论是商务条款还是技术标准与交流问题相关的都要清楚知晓否则就会显得我们很不专业21与外部进行交流沟通依据22与外部进行交流沟通应注意的问题23如何建立项目团队高效的交流沟通机制领导要求两个部门联合办公省去了过去的信函往来增加了广泛的口头交流讨论在他们充分的交流中彼此了解了对方的工作程序工作进展现状和后续工作安排制定了一个采购设计工作交叉进行的方案解决了采购设计二者互相制约不能推进的现状项目部没有设备技术资料提供不了要求的技术资料在一个团队内过多的正式交流会导致大家过分的责任分明阻碍了双方充分交流的渠道影响了部门间协同配合的深度导致一些工作推动无力工程项目实施本来就是在问题中寻找办法逐步推进的过程只有大家集思广益密切配合精诚合作才能把项目完成同时也看到领导在项目团队中的重要作用对项目团队遇到的问题要善于判断问题的症结积极协调敢于拍板勇于承担责任综上所述团队内部沟通要坚持发挥领导的协调带头作用以非正式交流为主导建立开放的团队交流文化3沟通技巧恰当的时间终止明