客户在决定投资一套软件系统建设的项目前，本身很明确知道希望这套系统能够带来什么价值，但对于如何能够利用科技来达到目标则一概不清楚。希望透过软件工程师的专业知识来告诉他们如何才能够满足他们的愿景，客户希望透过人工智能(AI)去理解顾客的采购习惯,背景，行为和对现有产品的反馈对产品进行改良;他们希望透过企业资源规划(ERP)来减低生产或运营成本，提升资源对企业的价值;希望透过客户关系管理(CRM)软件的应用来保留顾客对企业品牌的忠诚，增加顾客对企业的满意度。这些都是透过科技应用所希望带出来的普遍价值和投资愿景。但技术人员仍然停留在科技应用的层面上，希望客户能够告诉他们需要那些功能来达到这个愿景，让他们能够利用技术完成客户的系统建设。这些构思型或愿景型的项目如何进行交付，是上世纪末期开始对软件行业的一大挑战。
在这种情况下，技术人员如何能够满足客户的愿景，客户如何能够告诉技术人员有关这个投资项目的功能需求，变成项目在实施过程中不断进行修改，不断延误的主要原因。如何解决这个困境是当时急迫需要处理的难题。所以计算机行业新增加了一个岗位，叫做业务分析师(Business Analyst 或简称BA)，业务分析师应该有深厚的行业知识，透过BA对行业的理解，对愿景项目进行流程分析及建设，然后让技术人员对有关流程进行分析，建立功能需求，设计有关模块，为这些构思型或愿景型项目提供所需的基本信息。但可惜行业知识与技术知识两者还是有相当大的距离，BA 未能发挥应有的效益。美国PMI 也是在这个时候订立项目赞助人(Sponsor)及项目干系人(Stakeholders)的角色，在项目开发过程中，项目赞助人需要确认BA 的流程建议，需要取人系统建设每一个阶段的交付。项目干系人需要确认流程及系统功能不会影响部门的正常操作，两者要确保整个项目能够达到预期的交付愿景和目的。
在同一时间开始出现了一些新工具如4GL，和新方法如快速应用开发(Rapid Application Development，RAD)，希望通过这些工具和方法让技术人员与用户能够一起组合出未来系统的功能并达成共识，为投资者建立有关的应用系统。希赛顾问团需求工程首席专家徐锋认为，这些工具和方法误导了这个行业的技术人员，让他们在项目启动的时候便把重心放在把握功能需求，而不是建立项目范围，直到今天，很多软件工匠在项目起动时便尽量希望能够把握项目的功能需求，一些学者更把如何把握需求当作教育重点来让我们不断培育软件工匠。让技术人员忘记了建立范围的重要性，让技术人员未能发挥本身的智慧，为客户建立所需的解决方案，让这些工匠不能够有效地考虑如何利用科技来提供客户期盼的价值，发挥本身的创作力和创思。智能让技术人员不断跟着客户后追寻那些不存在的项目需求。
软件工程在21 世纪的挑战
此文章共有6页 上一页 1 2 3 4 5 6 下一页
文章来源：希赛网
|
Leadge.com首页 > 知识库 