软件项目根统计80项目够时提交客户类型项目失败率高什导致项目延期甚失败呢? 文必项目失败原作深入分析提出解决思路 决定项目成功素:高质量团队清晰项目目标项目进行效理效控制客户需求等 CMM 软件成熟度模型5级中第2级中第 KPA(关键程域) 需求理CMM 中第级概念初始状态公司需求理实际CMM模型里面第求实现关键程域见重性 总结年软件项目理实践认:软件项目理程中需求变更法避免果开发商客户说:客户需求开始确定修改估计十八九订单没客户愿意 改善需求理减少需求变更需求变更影响认三方面做相应工作: 1)客户建立良性基理性合作环境 2)软件工程方位量减少需求变更影响 3)建立套行效项目启动阶段应该客户认需求理制度 客户建立良性基理性合作环境 需求程身问题 ·需求确定程中客户会建议解决方法成需求身 ·客户开发者时候会假定方已明白意思需求理然 外部素导致变更 ·营方改变 ·政策素影响够客户变更合约目标范围拒绝变更呢?国软件项目实践中目前客户关系中心销售模式做点非常困难 必须假定需求定会修改 1)客户建立良性基理性关系 客户建立理性良关系呢?首先客户分析解: 国客户分两类: 类国家单位型企业IT部门部门项目成敏感性较低项目成功否否会延期等非常敏感型企业单位里面关系表现 类规模企业类规模企业企业负责(者直接老板)拍板某系统类企业项目成会非常敏感 项目理概念中客户干系概念什项目干系? 需求调研分析阶段项目组客户整体组织结构关员关系工作职责等没足够解致法完整需求终权威户代表确认需求项目理需求分析员工作问题客户参程度部高客户方相关责明确范围需求责心强提出需求具意性项目前期需求确认够积极者户代表说话昨非时希软件早交付项目期需求变化意造成项目范围蔓延进度拖延成扩 造成述现象原系统分析员没全面解项目干系需求重性优先级进行权衡取舍全面需求项目干系项目干系STAKEHOLDER翻译成利益关系利害关系利益干系利益享者涉众等等受项目结果重影响项目干系项目受益者项目风险承担者甚项目受害者项目干系需求包含明确隐含分NEEDWANTWISH等层次 干系愿追求目标相差甚远项目干系愿进行衡相困难事情例政府部门准备建设少群众办公信息系统层理机关希够采集信息项便数进行种样统计分析时信息进行效控制增加审批流程基层外办公窗口办公速度压力希减少信息项输入量甚良基层客户害怕建立透明度高信息系统会影响工作考核成绩消极应付谓反需求客户客户(办事群众)希相关政府机构够简化工作流程加快办事速度客户相关理机构组织会制定关标准规范作项目干系公司领导层会提出技术接口环境需求甚项目组身技术资源进度等原需功进行优先级排序取舍然需求满足特消极反需求接受需求应考虑全面进行衡 软件开发项目目实现项目干系需求愿果项目干系没进行足够沟通影响参项目项目开始时项目范围具体需求够完整清晰某项目干系期认识变化提出新需求造成工期延长成增加甚项目完全失败应项目启动开始需求分析员项目成员分清项目干系包含组织通沟通协调施加影响驱动项目支持调查明确需求愿减项目阻力确保项目获成功效措施: 1快熟悉项目干系全貌 项目做需求调查时受进度求等客观素影响需求分析员建设单位技术部门交流较业务理部门实际者调查够深入造成软件试需求做较调整头部分例高超进度求时间熟悉项目干系全貌进行需求调查第步需求调查基础定制开发项目项目干系中重建设单位中事组织业务关系够组织结构图画出相关单位组织结构责矩阵确定部分调研象建立调研象通讯录保证调研分析期间时沟通时注意项目干系次关系便间需求出现矛盾时够进行合理取舍 熟悉建设单位部相关部门业务划分间相互关系功分析准备必资料时熟悉户方类员时进行广泛效沟通交流特客户方业务技术规划者实际者进行深入探讨收集必原始资料保证需求调查完整性正确性建设单位项目干系中部分(然部分)更解项目干系全貌应建设单位组织结构图基础全体项目干系结构图便更更全面进行需求调研分析 2详细描述项业务利客户确认 全面详细调查描述原系统户希系统具项业务流程业务流程文档化客户进行讨描述错误准确精确进行修改终客户进行确认年开发软件业务处理程解完整性准确性非常重然数说SIDUT(查增删改传)具体业务分干步骤步骤业务名称步骤数集进行操作需调查解清楚设计出适合流程业务节点户业务特点惯软件开发出软件更受欢迎然进行软件概设计时量排业务流程制约流程中项业务结点工作作独立象充分考虑种业务象接口流程间通业务象相互调实现业务流程样业务流程发生限变化时够较方便修改系统程序实现新需求 项业务调查通资料收集整理分析资料种样项目干系:遵循标准组织发放工作手册作业流程关业务级通知关业务办事指南办理业务时需填写登记表种相关统计报表通途径收集类似系统介绍技术资料等等 3视化需求调研引导种客户挖掘需求 客户缺乏计算机知识法提出完整准确隐含潜需求需求满足导致户满需求调研分析员应善想户想确定明确需求善启发方式户探讨隐含潜需求结合种调研分析技术挖掘超出客户期令兴奋需求求需求调研分析员快完整熟悉相关业务够站户立场软件需求想户想做业务计算机间桥梁利视化需求调研方法启发户深入挖掘潜需求视化需求调研图表等工具启发引导户清楚叙述需求需求更加全面完善 高层领导提供系统总体框架图业务理员业务流程图描述新旧系统业务流程客户中技术员数流图实体关系图UML中种图形系统进行种角度描述业务理员客户中技术员层次流程中户画出户界面图进行需求挖掘较效沟通方式 里特说明户界面重性户界面设计理说软件设计责然客户界面特提出求外果提前需求调研时(紧接着原系统调研分析系统模型完成)客户进行讨改善需求调研效果少需求分析著作户界面说成设计层需求时客户系统没形象概念者模糊预想概念需表述验证明晰化完善化笔者验画出户界面草图客户进行讨激发提供更准确全面需求原收集资料描述业务说明系统模型山穷水时候种方法达柳暗花明村效果微软项目:求生法第8章需求开发中头尾围绕着者接口(USERINTERFACE翻译成户界面)进行讨建立简单者接口雏形断修订者接口雏型直者软件感兴趣盎然止完全扩展者接口时区分份非者接口需求文件等等谓需求种相关钮(输入种相关命令)时系统做什谓设计种相关钮(输入种相关命令)时系统做然英语中接口界面实际单词接口含义似界面广泛功间接口软件接口硬件接口等等需求终目实际完整准确描述系统需种接口界面相互关系外部环境关系界面中某钮时产生新界面新钮者调软件硬件完成某功顶界面涉数描述清楚份错需求 4项目组成员协作持续完善系统需求 需求文档完成万事吉扔面设计员事作项目干系项目组成员需求效性起某种程度验证作然软件项目生命周期种开发模型阶段划分阶段结束简单阶段工作成果塞阶段成员特高科技软件开发项目阶段工作成果通次沟通更清晰阶段成员接受效性合理性阶段工作检验通检验时必阶段工作结果进行相应调整需求更阶段员间阶段员间应根需相互协作相互配合完成软件开发务 二软件工程方位量减少需求变更影响 系统模块应该设计成送耦合采OO技术建立易改变加强重性软件系统OO技术想现已什陌生概念: 1封装(Encapsulation)问题影响范围缩外部变化求系统影响限定某类层次某类层次中改变系统部分相简单 2继承(Inheritance)改变基原技术基础程度减少重复开发工作 3态(Polymorphism)应开发设计员相统接口更改系统实现细节改变系统行 4OO类体系结构业界非常清楚明晰描述方式目前规范描述语言UML非常易开发组理解达成识促进开发组成员间合作加强软件开发工作延续性见身种增强软件维护性健壮性保持设计稳定性种分析设计方法身定程度快速需求变更进行反应相减少需求变更需成(OO意义分析设计软件系统思考方式建立象库软件重软件系统开发带质改变建立OO开发体系前程定会段荆棘遍布路需付出加倍努力达成思想转变里误区需澄清C++PBVBDELPHI面象开发实面象工具骨子里然结构化分析设计方法套层OOP外壳已) 扩展性设计(ExtensibleDesign) 次控制软件设计说样进行合适设计程度减少需求变更带代价? 许说设计极灵活已预计客户提出求设计种应方式时候客户提出呵呵已解决样想法错少僵硬设计强谁保证设计者预知需求变化?时达种灵活(万?)设计设计变复杂余设计会?复杂设计增加实现难度提高成带潜Bug系统难维护 设计思想应该转变设计确实灵活体现扩展性面说设计简单定易转变需出便改变接口点重 例现类做TCPConnection代表计算机网络通信中典型TCP连接连接言处种状态:Established(连接已建立)Listening(正侦听)Closed(连接关闭)连接象需象接受请求反应决定连接象处状态(开连接请求)果连接关闭状态进行Open()处状态做反应样果连接建立侦听状态进行Close()连接建立状态进行Acknowledge()接收数 样状况取设计应该系列Switch语句(甚Ifelse语句)进行Hard设计次需求改变需改变源代码接踵系统致性文档更新等工作开发员避免陷入场灾难样果导致原合理设计变更加支离破碎系统维护代价越越算没需求变更发生设计重性会极差 稍设计预先估计设置TCPConnection类状态预先加入设计种需付出更设计开发维护代价难达完美效果说 面介绍种典设计思路种设计充分体现(系统)改变预留接口扩展性(ExtensibleDesign)思想实现思想里引入抽象类TCPState代表TCPConnection类状态出具体种状态通操作接口派生出子类(实现具体操作)实现TCPConnection类状态例派生TCPEstablished类实现TCPConnection类连接建立状态 需TCPConnection类中包含TCPState状态引TCPConnection状态改变时更新前状态引例连接关闭时进行Open()状态引应该TCPClosed变成TCPEstablished样实现原求 设计思路意义远止抽象类TCPState已TCPConnection类状态留出接口需断派生具体状态子类实现状态变更须影响原设计须加入余代码实现现需功优美扩展设计思路非常清晰易维护相信做软件设计时带启发 系统应该采Open技术标准 采SOA 开发架构进步降低系统耦合度措施典软件工程理中瀑布方法原型方法需求分析做起步步构建起形形色色软件系统需求变更挥阴影时刻伴着系统左右实际应系统开发者饱尝系统进入开发阶段测试阶段甚线阶段遭遇应接暇需求变更极端痛苦客户变更需求视bug(错误)测试线阶段问题 解决问题?否场软件开发架构革命?SOA架构提出成样场革命实质系统模型系统实现分割开 1定义SOA新概念CORBADCOM等组件模型成SOA架构前身早1996年GartnerGroup已提出SOA预言时候仅仅预言时软件发展水信息化程度足支撑样概念走进实质性应阶段两年SOA技术实现手段渐渐成熟BEAIBM等软件巨头极力推动慢慢风行起GartnerSOA描述愿景目标实现实时企业(RealTimeEnterprise) 关SOA目前尚未统业界广泛接受定义般认:SOA面服务架构组件模型应程序功单元服务(service)通服务间定义良接口契约(contract)联系起接口采中立方式定义独立具体实现服务硬件台操作系统编程语言构建样系统中服务统标准方式进行通信种具中立接口定义(没强制绑定特定实现)特征称服务间松耦合 定义中面两点: ·软件系统架构:SOA种语言种具体技术更种产品种软件系统架构尝试出特定环境推荐采种架构角度说实更种架构模式(Pattern)种理念架构面应服务解决方案框架 ·服务(service)整SOA实现核心SOA架构基元素服务SOA指定组实体(服务提供者服务消费者服务注册表服务条款服务代理服务契约)实体详细说明提供消费服务遵循SOA观点系统必须服务服务互操作独立模块化位置明确松耦合通网络查找址 2SOA三种角色关系 服务包含状态(stateless)实体组件组成通事先定义界面响应服务请求执行诸编辑处理事务(transaction)等离散性务服务身赖函数程状态什技术实现服务定义中加限制 服务提供者(serviceprovider)提供符合契约(contract)服务发布服务代理 服务请求者(serviceconsumer)服务者发现调软件服务提供商业解决方案概念说SOA质网络传输协议安全细节留特定实现处理服务请求者通常称客户端终端户应程序服务 服务代理者(servicebroker)作储存库电话黄页票交换产生服务提供者发布软件接口 三种SOA参者:服务提供者服务代理者服务请求者通3基操作:发布(publish)查找(find)绑定(bind)相互作服务提供者服务代理者发布服务服务请求者通服务代理者查找需服务绑定服务服务提供者服务请求者间交互 谓服务状态指服务赖事先设定条件状态关(statefree)SOA架构中服务会赖服务状态客户端接受服务请求服务状态编排(orchestrated)序列化(sequenced)成序列(时采流水线机制)执行商业逻辑编排指序列化服务提供数处理逻辑包括数展现功 3SOA特征 基面讨出SOA面特征: ·服务封装(encapsulation)服务封装成业务流程重组件应程序函数提供信息简化业务数效致状态状态转变封装隐藏复杂性服务API保持变户远离具体实施变更·服务重(reuse)服务重性设计显著降低成实现重性服务工作特定处理程文(context)中独立底层实现客户需求变更 ·服务互操作(interoperability)互操作新概念CORBADCOMwebservice中已采互操作技术SOA中通服务间定通信协议进行互操作步异步两种通信机制SOA提供服务互操作特性更利场合重 ·服务治(Autonomous)功实体服务组件组成组合模块包含模块化 SOA非常强调架构中提供服务功实体完全独立力传统组件技术NETRemotingEJBCOM者CORBA需宿(Host者Server)存放理功实体宿运行结束时组件寿命结束样宿身者功部分出现问题时候该宿运行应服务会受影响 SOA架构中非常强调实体理恢复力常见进行恢复技术事务处理(Transaction)消息队列(MessageQueue)冗余部署(RedundantDeployment)集群系统(Cluster)SOA中起关重作 ·服务间松耦合度(LooslyCoupled)服务请求者服务提供者绑定服务间应该松耦合意味着服务请求者知道提供者实现技术细节程序设计语言部署台等等服务请求者通消息调操作请求消息响应通API文件格式 松耦合会话端软件影响端情况发生改变前提消息模式保持变极端情况服务提供者前基遗留代码(例COBOL)实现完全基Java语言新代码取代时服务请求者造成影响种情况真实新代码支持相通信协议 ·服务位置透明(locationtransparency)服务针业务需求设计需反应需求变化谓敏捷(agility)设计想真正实现业务服务分离必须服务设计部署户说完全透明说户完全必知道响应需求服务位置甚必知道具体服务参响应 4三抽象级 概念讲SOA中三抽象级: ·操作:代表单逻辑工作单元(LUW)事务执行操作通常会导致读写修改持久性数SOA操作直接面象(OO)方法相特定结构化接口返回结构化响应完全方法样特定操作执行涉调附加操作 ·服务:代表操作逻辑分组服务分层降低耦合度复杂性服务粒度(granularity)系统性息息相关粒度太会增加服务间互操作通讯开销粒度太会影响服务面需求变化敏捷性 ·业务流程:实现特定业务目标执行组长期运行动作活动业务流程通常包括业务调 SOA中业务流程包括组业务规序序列执行系列操作操作排序选择执行称服务流程编排典型情况调已编排服务响应业务事件建模观点带挑战描述设计良操作服务流程抽象特征系统构造涉服务建模特征抽取问题已成现阶段关注焦点 三建立套行效项目启动阶段应该客户认需求理制度变更容进行严格控制实施需求变更理需遵循原: 1建立需求基线需求基线需求变更开发程中需求确定评审(户参评审)建立第需求基线次变更评审重新确定新需求基线 2制订简单效变更控制流程形成文档建立需求基线提出变更必须遵循控制流程进行控制时流程具定普遍性项目开发项目鉴作 3成立项目变更控制委员会(CCB)相关职类似组织负责裁定接受变更CCB项目涉方员组成应该包括户方开发方决策员 4需求变更定先申请然评估变更相级评审确认 5需求变更受影响软件计划产品活动进行相应变更保持更新需求致 6妥善保存变更产生相关文档 需求变更然避免必须套规范处理流程需求变更处理流程应该分步骤:提出变更à变更评估à实施变更 需求变更处理流程 现实世界软件系统严格程度复杂性事先预言相关需求系统原计划操作环境会改变户需求会改变甚系统角色改变实现测试系统行导致正解决问题产生新理解洞察种新认识导致需求变更CMM提出分配需求变更复审加入软件项目中关键需求发生变更时没必马变更付诸软件开发工作中实际坚持需求变更付诸开发努力企业会形成种混乱稳定氛围进严重破坏项目控制理需求理关键程试图通分配需求变更囤积理组中等开发工作允许时候引相应方法避免产生种混乱氛围结果需求理创建隔绝开发工作真实潜序客户变更缓器允许真实变更注意记录追踪时开发工作会扰乱开发项目应该周期性暂停吸收新需求变更积累时计划设计行根刚刚吸收需求变更影响进行更新 需求变更控制然项目理范畴外纯技术素息息相关面象分析面象设计面象编码方式等等技术发展趋势样变更理变更容易项目变更控制中采取什方法策略项目身变化定时时洞悉处处留意样真正意义项目进行变更控制
文档香网(httpswwwxiangdangnet)户传
《香当网》用户分享的内容,不代表《香当网》观点或立场,请自行判断内容的真实性和可靠性!
该内容是文档的文本内容,更好的格式请下载文档