魏东

政府和教育IT外包服务存在较大增长空间

   背景资料

   据易观国际《中国IT外包市场年度综合报告2005-2006》显示，2006年，随着更多政府网站的开通，以及电子政务的深入开展，我国政府信息化将迎来一个新的高潮。由于市级政府电子政务工程建设的一项重要工作是电子政务专网的建设，专网的运营维护成为了政府IT外包的一个重要的环节。而专网最初的承建厂商最有可能成为运营维护服务的提供商。

    在十一五期间，我国政府的信息化将完成从硬件采购为主，到软件和信息服务采购为主的过渡，更加注重从个体到整体的系统整合以及信息安全。根据国外IT外包企业的分行业收入来看，政府的IT外包是其中非常重要的组成部分，占据相当大的份额。我国政府IT外包，尚存在很大的市场增长空间。

     易观国际《中国IT外包市场年度综合报告2005-2006》显示，2005年中国教育行业信息化投资为272.6亿元，比上年增长8.7%。从地域角度分析，东部地区的硬件设施建设较为领先，中西部地区则稍显落后。在十一五期间，教育信息化将进入平稳发展期，东部地区将以应用开发和资源建设为主要目标，而中西部地区的建设重点仍是硬件环境。
在教育逐渐从硬件投入转向软件和应用资源的过程中，厂商的服务能力将受到更多的关注。而数字图书馆、教育资源管理、远程学习等重点应用，则为IT外包服务提供了一定的市场机会。

    易观观点

     易观国际认为，随着信息化的不断深入，政府和教育行业的IT外包存在较大增长空间。其中IT服务厂商可以重点关注政府行业电子政务专网的建设，以及教育行业的数字图书馆、教育资源管理、远程学习等应用的教育机构。

Borland个性化IT管理&治理系统

http://www.borland.com/cn/products/tempo/index.html

Borland® Tempo™ 是一个完整而富有协作精神的IT 管理与治理 系统。它是个性化 Borland IT 管理 & 治理解决方案 的基石，同时通过支持为人员，过程和技术进行量身打造的、可渐进采用的技术，交付可供测定的企业收益。在超过15次放行过程的不断改进中，Borland Tempo（前Legadero Tempo）听取了上千名IT专业人员的反馈意见。

借助Borland Tempo，各个组织可以将个性化过程实现到整个组织的基于成本，收益和风险的有效采集，评估和选择最佳技术投资当中去，Borland Tempo同时包括了一个完整的适用于计划，项目级工作管理的套件，能够将可视性整合到项目业务的进程和状态中，以便于项目和创新成功有效地执行。

---

低风险，快速制胜

各个组织可以通过快速而渐进地实现Borland Tempo，使其所有能力都能够达到成熟的IT管理与治理过程的要求。

使用GUI设置并基于Web的技术: 仅需一到两周的时间，即可对Borland Tempo系统配置完毕，使其能够反映内部过程和目标，安装就绪，随时可供用户登录。该技术安装在一个单一服务器上，并可通过无需applet或plug-in的浏览器进行访问。所有设置（过程，表格，角色等）都可通过无需scripting或定制代码的GUI完成。仅需两周即可实现的支持包括:

易于采用: 通过易于采用，支持低风险和快速制胜。Borland Tempo非常直观，易于用户学习，而且极具灵活性。例如，可以对Borland Tempo进行设置，使其能够反映组织的语言，而非对其本身进行修饰。Borland Tempo同时为所有用户提供了相关和有用的功能性，无需用户进行升级，从而使执行官可以运行报告。而且，由于提供了有用的工具，因此可以在其使用过程中，采集业务级信息。

所有者最低总成本

Borland Tempo提供了前所未有的价值。其成本有效性远远高于业界领先的替代产品和功能，物有所值。

完整的解决方案: Borland Tempo包括了完整的IT管理与治理所需要的所有能力。在IT组织随后扩展业务范围时，无需购买额外的模块。另外，在使用该系统时，即使是大型的实现项目，也无需购买额外的中间件。这样可以极大地降低总体许可费用，同时极大地减少与配置多个技术相关的成本。客户可以选择使用其自己的第三方RDBM或J2EE服务器，但并不要求对其进行使用。

适度的硬件需求实现满足极高的效率: 即使是由用户群组成的大型实现也一样能够承担，例如，在单一的Windows服务器上。

保持独到的成本有效性: 保持独特的成本有效性：支持快速实现的基于相同web的架构，同样可以进行快速，轻松和不间断的更新。基于相同GUI的设置支持快速而有效的实现递增过程改进或政策调整。

软件需求读书笔记_2006年4月18日 需求的开发与管理

　　软件需求工程可以划分为需求开发和需求管理。
　　软件需求工程的组成
　　需求工程由需求开发和需求管理组成，需求开发是由获取、分析、编写规约、确认组成。

需求开发

　　需求开发可进一步细分为获取（Elicitation）、分析（analysis）、规格说明（specification）和确认（Validation）。
　　为软件和软件相关产品收集、评估和记录需求相关的所有活动，包括：

• 确定产品将要面对的各类用户。
• 从各类用户的代表处收集需求。
• 了解用户的任务和目标，以及这些任务要实现的业务目标。
• 分析从用户处得到的信息，将用户的任务目标与功能需求、非功能需求、业务规则、解决方案建议及其他无关信息区分开来。
• 将顶层的需求分配到系统构架内定义好的软件组件中。
• 了解各质量属性的相对重要性。
• 协商需求的实现优先级。
• 将收集的用户需求表述为书面的需求规格说明和模型。
• 审阅需求文档，以确保在认识上与用户声明的需求相一致。应在开发小组接受需求之前解决所有分岐。

　　迭代（iteration）是需求开发成功的关键。需求开发计划应包含多个周期，每个周期包括研究需求，细化高层需求以及请用户确认需求的正确性。这一过程很费时而且可能会遇到挫折，但却是定义软件新产品时消除不确定性所必需的过程。

需求管理

　　需求管理的任务是“与客户就软件项目的需求达成并保持一致”。这种一致应体现在书面的需求规格说明和模型中。取得用户认可只满足了批准需求所需的一半条件，还必须让开发人员接受需求规格说明并同意在产品中加以实现。需求管理活动包括下列活动：

• 定义需求基线（某一时刻，对特定版本中已达成一致的需求内容的描述）
• 审查需求变更请求，评估其可能产生的影响以决定是否批准
• 以可控的方式将批准的需求变更融入项目中
• 保持项目计划与需求的同步
• 估计需求变更的影响，在此基础上协商新的需求约定
• 跟踪每项需求，找到与其对应的设计、源代码和测试用例（test case）
• 在项目开发过程中，始终跟踪需求的状态和变更

　　定义需求基线是需求开发与需求管理的分界。

IBM.Rational.Portfolio.Manager

Show Panel Unshow PanelWednesday, April 12th 2006
IBM.Rational.Portfolio.Manager.Client.v6.2
IBM.Rational.Portfolio.Manager.Database.v6.2
IBM.Rational.Portfolio.Manager.EAR.v6.2
IBM.Rational.Portfolio.Manager.Server.API.v6.2
IBM.Rational.Portfolio.Manager.Server.v6.2
IBM.Rational.Portfolio.Manager.PJC.Metrics.Kit.v6.2
最新发布的 IBM Rational Portfolio Manager 提供了软件开发项目的可见性，让过程流线化。
新的过程功能允许用户自动地应用行业领先的最佳实践来进行项目计划，创建在实际开发项目中可行的方法学。
新的图形化工作流功能允许用户快速而轻松地创建、审查和自动化工作流。
新的分析功能为用户提供了一个指示板，用于查看数据、度量和预测整个项目组合的趋势。
阅读有关 Rational Portfolio Manager 的增强功能 (PDF，2.65MB)
让产品组合投资与业务目标保持一致
获得实时可见性，快速做出明智的决策
利用内置的模型和工作流
实施 IT 宏观管理过程
增强管理团队和交付团队之间的协作。
实施最佳实践并自动化产品组合过程。
监视和控制跨产品组合的风险、问题和财务情况。
管理技能库和平衡资源需求。
获得跨 IT 和开发项目的全方位视图。
[摘自IBM官方网站]
http://www-900.ibm.com/cn/software/rational/products/awdtools/portfolio/
Posted by peoyu in 行业相关 at 17:43 for 2006.04.12
 

软件需求读书笔记_2006年4月5日

2006年4月5日
需求的层次
　　软件需求包括3个不同的层次――业务需求、用户需求和功能需求。
　　除此之外，每个系统还有各种非功能需求。
　　业务需求（Business requirement）表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一个系统，即组织希望达到的目标。使用前景和范围（vision and scope）文档来记录业务需求，这份文档有时也被称作项目轮廓图或市场需求（project charter 或 market requirement）文档。
　　用户需求（user requirement）描述的是用户的目标，或用户要求系统必须能完成的任务。用例、场景描述和事件――响应表都是表达用户需求的有效途径。也就是说用户需求描述了用户能使用系统来做些什么。
　　功能需求（functional requirement）规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。功能需求有时也被称作行为需求（behavioral requirement），因为习惯上总是用“应该”对其进行描述：“系统应该发送电子邮件来通知用户已接受其预定”。功能需求描述是开发人员需要实现什么。
　　系统需求（system requirement）用于描述包含多个子系统的产品（即系统）的顶级需求。系统可以只包含软件系统，也可以既包含软件又包含硬件子系统。人也可以是系统的一部分，因此某些系统功能可能要由人来承担。
　　业务规则包括企业方针、政府条例、工业标准、会计准则和计算方法等。业务规划本身并非软件需求，因为它们不属于任何特定软件系统的范围。然而，业务规则常常会限制谁能够执行某些特定用例，或者规定系统为符合相关规则必须实现某些特定功能。有时，功能中特定的质量属性（通过功能实现）也源于业务规则。所以，对某些功能需求进行追溯时，会发现其来源正是一条特定的业务规则。
　　功能需求记录在软件需求规格说明（SRS）中。SRS完整地描述了软件系统的预期特性。SRS我们一般把它当作文档，其实，SRS还可以是包含需求信息的数据库或电子表格；或者是存储在商业需求管理工具中的信息；而对于小型项目，甚至可能是一叠索引卡片。开发、测试、质量保证、项目管理和其他相关的项目功能都要用到SRS。
　　除了功能需求外，SRS中还包含非功能需求，包括性能指标和对质量属性的描述。
　　质量属性（quality attribute）对产品的功能描述作了补充，它从不同方面描述了产品的各种特性。这些特性包括可用性、可移植性、完整性、效率和健壮性，它们对用户或开发人员都很重要。其他的非功能需求包括系统与外部世界的外部界面，以及对设计与实现的约束。
　　约束（constraint）限制了开发人员设计和构建系统时的选择范围。
　　产品特性。所谓特性（feature），是指一组逻辑上相关的功能需求，它们为用户提供某项功能，使业务目标得以满足。对商业软件而言，特性则是一组能被客户识别，并帮助他决定是否购买的需求，也就是产品说明书中用着重号标明的部分。客户希望得到的产品特性和用户的任务相关的需求不完全是一回事。一项特性可以包括多个用例，每个用例又要求实现多项功能需求，以便用户能够执行某项任务。
　　还有一项称为可用性（usability）的质量属性，它规定了业务需求中“有效”（efficiently）一词的含义。
　　管理人员或市场营销人员负责定义软件的业务需求，以提高公司的运营效率（对信息系统而言）或产品的市场竞争力（对商业软件而言）。所有的用户需求都必须符合业务需求。需求分析员从用户需求中推导出产品应具备哪些对用户有帮助的功能。开发人员则根据功能需求和非功能需求设计解决方案，在约束条件的限制范围内实现必需的功能，并达到规定的质量和性能指标。
　　当一项新的特性、用例或功能需求被提出时，需求分析员必须思考一个问题：“它在范围内吗？”。如果答案是肯定的，则该需求属于需求规格说明，反之则不属于。但答案也许是“不在，但应该在”，这时必须由业务需求的负责人或投资管理人来决定：是否扩大项目范围以容纳新的需求。这是一个可能影响项目进度和预算的商业决策。

不属于需求的内容
　　需求规格说明中不包括（除已知约束外的）设计和实现的细节、项目的计划信息，以及测试信息（Leffingwell 和 Widrig 2000）。把这些内容与需求分开，就可以把需求活动的注意力集中到了解开发小组需要开发的产品特性上。项目中通常还包括其他类型的需求，如开发环境需求，进度或预算限制，帮助新用户跟上进度的培训需求，或者发布产品使其转入支持环境的需求。这些都属于项目需求而不是产品需求，因此不属于软件需求的讨论范围。