定义范围

• 客观地根据用例定义项目范围，及获取商业方同意
  • 在项目开发期间更改范围会严重影响进度及降低员工士气
  • 当商业方在开发期间增加额外需求，记录入用例中及安排它们在未来的版本中。或者简略评估每个用例，并向商业方提供资料以便他们作出决定
• 获取项目投资者对用例的同意
  • 因为用例是以商业述语编写的，可以作为一份商业方与管理层之间，关于何时交付什么的“合约”
  • 与商业方共同选出本次项目将会被实现的用例，其它的保留作下一版本（或另一项目）
  • 就算范围是口头上的，也要被记录及以电子邮件通知所有项目相关的人。确保保留一个幅本。
• 当项目范围被确认后，强制跟从

评估的基础

• 在项目初期的评估在有更详细计划及设计后，应该定期地细化及重新评估
• 当完成外部接口、完整物件及数据模型的定义后，应该可以更准确地作出评估
• 以项目组中最慢的资源作为评估
• 评估应该是合比例的
  • 因为计划及设计阶段包括了用例分析，这应占据整个项目生命周期的50%
• 考虑开发、测试及生产所需的环境搭建时间
• 开发人员评估编码及单元测试任务会比较合理

一个评估的算法
技术架构师只负责以小时计算评估，项目经理应因其它项目的工作及假期所引至的缺席等因素

1. 确定每个用例的画面、接口、数据表及转换等的数量
   为项包括的用例组作以下的评估。并非每个用例都有齐所有项目，括号中的基准评估适合开发组尚未成立，如果开发组已经成立，应该可以评估得更准确。因对象模型尚未完成，此时的评估受到对象数量未知的因素影响而未能准确评估
   
   • 用户界面（2人/星期）
   • 外部应用程序接口（4人/星期）
   • 数据表（2人/星期）
   • 表或文件转换（2人/星期）
2. 评估每个用例所需编码及单元测试所需的时间
   基于第1步的评估，计算基准评估是简单地计算各用例的结合，如：所有用例合计有4个画面，2个外部应用程序接口，5个数据表，0个数据转换及2个环境设置，则基准评估如下：
   (4x2) + (2x4) + (5x2) + (0x2) = 26人/星期，或1,040人/小时 
3. 将第2步中的基准评估值乘2.5
   如果编码及单元测试占每个用例的整体开销的1/3，则总开销应是基准评估的3倍。因为在此阶段约完成了50%的分析工作，总开销应是基准评估的2.5倍，因此，剩余的总项目小时是：1,040 x 2.5 = 2,600 
4. 为项目中每个额外的开发人员增加20%
   因基准评估假设项目只有1个开发员，每增加1个开发员都会增加沟通及调配的时间约20%，虽然这些时间并非用于开发，但这是必需的开销。因此，如果项目有5个开发人员，估计时间是：2,600 x (1.2)⁴  = 5,391hr。为说明这只是一个评估而非实际用时，最好取四舍五入为5,500hr。假设每周工作32小时（其余时间可能用于行政等工作），即开发组每周可以工作160小时，约8至9个月可以交付系统。此时以月或季度作为评估时间可避免给人一个准确交付期的观念
5. 与开发组成员共同讨论（review）这个评估
   开发人员在未得到更详细资料前，不会感受到这个评估范围。告诉他们当设计完成后会重新评估是很重要的

更多的人手很少能挽救一个被延误的项目
因为必承担沟通、调配、行政等开销，加入更多人手只会令一个已被延误的项目更延迟更多。架构师通常会被要求在所有分析完成前做一个活动领域评估（ballpark estimates）。虽然并非是字面上正确，你可以在活动领域评估中加入各项假设。

• 开发任何应用程序的第一步是通过分析定义用途、范围及目标
• 定义项目是项目经理、商业逻辑分析员及最终用户的工作，技术架构师并不直接参与
• 架构师的责任是确保项目的定义中有足够的连贯性，实际设计及实现时有足够的细节
• 架构师必须要有分析技能，否则不能识别项目定义中的弱点及缺口
• 在分析过程中，用例是一项重要的工具
• 用户界面原型可帮助精化用例

识别项目范围

• 在用例分析前对项目作出一个高层次的项目定义及对范围有初步的构想是需要的， 配合使用原型会更有效
• 高层次定义无需过于详细，它的用途只为确定用例分析的范围

例子：建立一个协助项目经理计划任务，跟踪所有组成员活动及评估完成日期的系统。这个程序可以允许用户完成以下的工作：

• 定义项目及它的任务
• 记录被分配入项目的人的任务及估计完成每项任务所需的时间
• 记录任务被完成的次序
• 记录项目进展及标记已完成任务
• 自动安排项目进度表
• 建立项目进展报告

识别参与者

• 用例分析的第一步是识别参与者
• 参与者可以是用户或外部服务系统，或受影响的用例
• 一个使用者可能同代表数个参与者
• 考虑在大型应用程序中加入应用程序管理员作为参与者
• 确保所有参与者都是直接使用系统的
• 由一个小组识开始别参与者会更便利

编写用例

• 一个用例是对参与者使用系统的描述
• 应以商业述语编写用例，应做到任何一个商业方人员无传释或技术术语表而可明白其中内容。否则，这表明在编写用例时已对所开发的程序有了技术上的假设
• 用例可充当为商业及开发方之间的非正式的合约，表明将会交付一套怎样的系统
• 用例应以“本系统（或本应用程序）将会”开始。如果发现不能以这种语句开始的话，很可能这只是另一个用例的其中一部份
• 用例通常牵涉多个参与者，应在用列中列出所有受影响的参与者
• 并无规则规定一个用例有多长，越详细越好。有不超过两句作为概要更佳
• 避免使用用例图，只会浪费时间
• 编写用例时需要商业方的深入参与
• 以一个小组展开用例分析
• 可考虑将用例加入数据库中管理
• 在用例讨论时， 征召某人作为记录员
• 当有更多资料时，修改现时用例
• 当组成员感觉已有足够资料可以评估每个用例实施所需时间，用例分析可以结束
• 确保包括有安全、可扩展性及可用性方面的需求
• 当有需求有涵接问题时不要慢下来，作假设然后继续。对方有责任告诉你是什么地方错了及应如何更正。（对此点有保留，如果只是一个独立的问题可以这样处理，但很可能其它的用例会依赖于这个用例，最好还是先搞清楚需求再作分析）

例子：一个报表系统的用例

• 本系统将提供一个界面以接受由现存MVS/CICS应用程序生成报表模板定义
• 本系统将允许应用程序管理员控制受信任的客户机构成员使用报表模板
• 本系统将在运行报表时至少达到原系统的平均速度
• 本系统将会限制所有受信任的客户用户只可接收到该受信任用户所属机构的数据
• 本系统将会允许银行支持客户使用来自任何受信任客户机构的数据执行所有报表模板

常见错误

• 强加技术设计的假设作为需求
• 包含实际设计在用例中
• 分析会议效率不能保持，如无人主导、过于细节的讨论、资料不足等
• 用例没有文档化
• 在每个用例都重复定义术语

• 瀑布式（Waterfall approach）
• 所有的分析及设计都在编码及测试前完成
• 所开发出的软件往往是巨大及有较长的交付期，承担更多的风险
• 不在过程的初期提供反馈，但交付更完整的方案
• 由于需要较长的开发期而引致需求经常更改，项目经理可能要面对不修改商业逻辑则不能提供最大利益，而修改需求引致资源不足的两难局面
• 迭代式（Iterative approaches）
• 尽量分柝项目为细小的组件块，需要较少资源
• 其中一种最流行的方式是XP（Extreme Programming）
• 在长开发周期中，越早发现错误成本越低
• 在长开发周期中，减低复杂性同时也减低技术风险及成本
• Rational Unified Process （RUP）
• 形式化的开发方法
• 在分析及设计阶段采用瀑布式方法，在建构及交付时采用迭代式方法
• 鼓励尽早收集及分析需求，尽量满足使用者的祈望
• 鼓励先开发最具风险部份，以便有更多时间识别及回应问题，同时也减少重新设计所需的改写工作量

哪种方法最流行？

• 考虑采用混合模式（Hybird approach）
• XP所强调的测试具有非常大的价值
• XP可用于针对复杂的的问题
• RUP所强调的集中分析及设计具有非常大的价值
• 需要控制与最终用户间的沟通

• 技术架构师（Technical architect）
  • 识别项目所需用到的技术
  • 建议项目开发小组所采用方法（methodologies）及框架（frameworks）
  • 提供整体设计及应用程序的结构
  • 确保项目已被适当地定义
  • 确保应用程序设计已被适当地文档化
  • 制定编码指引及确保有被跟从
  • 帮助项目经理识别需要执行的任务，评估项目造价及得益
  • 面对困难的任务时，作为开发人员的导师
  • 协助管理层对开发员职位上的安排
• 项目经理（Project manager）
  • 负责为项目组所有成员协调及计划任务
  • 向管理层及最终用户代表汇报项目状态
  • 向管理层要求项目所需的资源
  • 技术架构师应向项目经理提供技术方面的建议及指引
• 商业逻辑分析员（Business analyst）
  • 负责与最终使用者共同定义应用程序的需求
  • 负责制定术语表
  • 应对最终用户方及资讯方的企业流程有经验
  • 技术架构师有责任确保商业逻辑分析员所确认的应用程序需求是适当的
• 界面设计师（Layout designer）
  • 与商业逻辑分析员及客户方代表共同设计出界面
  • 与表示层开发员共同建立应用程序原型（prototype）
  • 技术架构师有责任确保界面设计师所设计出来的界面是技术上可行的
• 表示层开发员（Presentation-tier developer）
  • 负责对应用程序中所有界面相关的编码
  • 与界面设计师共同建立应用程序的原型及工作版本
  • 与技术架构师共同界定前台浏览的结构及设计
  • 技术架构师有责任确保设计模式的可维护性及可扩展性
• 商业逻辑层开发员（Business logic developer）
  • 负责应用程序中所有非可视部份的编码
  • 协助技术架构师对应用程序在开发语言相关方面进行性能调整 
  • 技术架构师应向商业逻辑层开发人员提供指引
• 数据模型师（Data modeler）
  • 使用商业逻辑分析员所提供的资料识别、定义及分类应用程序在数据库中储存的数据
  • 为应用程序建立ER图及文档，主要读者为数据库管理员
  • 此角色一般可与数据库管理员合并
  • 技术架构师有责任确保数据模型是适当的
• 数据库管理员（Database administrator）
  • 负责基于应用程序的商业需求阐明数据库设计
  • 为应用程序建立、维护数据库环境
  • 提供性能调整方面的协助
  • 协助商业逻辑开发员诊断与数据存取相关的应用程序开发问题
  • 经常会兼任商业逻辑开发员或数据升级专员
  • 技术架构师需与数据库管理员共同解决数据储存的难题
• 数据升级专员（Data migration specialist）
  • 负责持续地编写及管理所有应用程序数据库所需的脚本及程序
  • 当应用程序无须或只须少量数据升级要求时，此角色通常与数据库管理员合并
  • 技术架构师需为数据升级专员制定数据升级需求
• 系统建构专员/系统管理员（Infrastructure specialist/System administator）
  • 负责提供所有开发、测试及生产的环境，与及其配置方法
  • 编写配置脚本
  • 以测试环境协助开发人员诊断问题
  • 技术架构师需为系统建构专员制定系统建构需求
• 测试专员/测试员（Testing specialist/Tester）
  • 通常是比较细心的人
  • 确保应用程序符合规格及只包含合理数量的BUG
  • 通常对所开发的商业领域有基本知识
  • 技术架构师需与测试员共同识别任何建构需求及所需支持