UML软件工程组织
开始学习微软的缺陷管理方法

 
　　来源:TestWin 软件测试之窗（袁琳）

 

微软缺陷管理方法

一．团队组织

　１． 微软团队模型

项目经理，开发，测试人员比例为５％，３１％，６４％。

产品团队中，权威仅仅来自于知识，而不是来自于职位。

People are most productive working in small teams with tight budgets, time deadlines, and the freedom to solve their own problems. – Bill Gates

通过有效的风险管理，使不确定因素达到最小

使用小团队并行工作，达到最多的同步点

定期编译与快速测试，使产品的稳定性和可用性达到最佳

　２. 各角色的职责

　1）Product Management Team　　 让客户满意

  • Target：确定产品远景，获取并确定用户需求，开发并维护商业安全，满足用户需求。
  • Role： 部门负责人为 Product General Manager，下设Product Unit Manger，Product Planning，Market and Research，Evangelism与Public Relation的部门负责人；evangelism：说服别人，产品推销，原意为“战斗似的热情”
  • Task：进行Group Program Management，清楚地知道用户的需求，并给出详细定义，即用专业术语描述；确保新产品带来利润；控制用户的期望值；设计大概的产品特性和进度表；管理市场，推销及公共关系。

　 2) Program Management　　　　 在项目约束条件下交付

  • Target：制定开发功能规范，在团队内沟通与协商，维持产品进度并报告产品状态，保证在产品约束条件下按时发布产品。
  • Role ：project coordination, product architecture,　release management
  • Task：管理产品细节，如feature的详细设计；促进团队沟通与交流，如plan following up；控制全局，保证项目按时完成，生产过程中的trade off。

3) Software Development Management 　 按产品规格交付

  • Target：开发出满足设计规范和用户要求的产品。
  • Team Role ：软件架构师(Software Architect) 与 软件开发工程师(Software Development Engineer )
  • Task：进行Software Development Management，包括database，system service，user interface。

4）Software Testing 解决所有问题后发布

  • Target：开发测试策略和计划，保证解决了所有已知问题后，再发布产品。
  • Team Role　：测试工具软件开发工程师（Software Development Engineer in Test , SDE/T）与　软件测试工程师(STE) 。
  • Task：进行test management，compliance testing，configuration testing，integration testing，stress testing 测试工具的编写 - 开始于，Test Case 确定之后，并根据Test Case来设计。
  • 通过使用来发现bug不是真正的测试，只能发现一般用户问题，属于最基本测试范畴；
  • 测试要考虑所有出错的可能性，错误的承受力，运行的性能问题，软件的兼容性；
  • 一流的测试人员，不仅要找出bug，还要定位引起bug 的代码行；对设计缺陷，测试人员应提出一个更合理的设计，并确保此设计易于开发人员实现。 Active Bug 指 当前必须修改的defect。

5）User Enducation Team 提高用户胜任力
　文档编写，用户培训；保证使用文档要全部清除地写出来，提高用户使用产品的技能，保证大多数用户能够充分利用产品的功能。

6) Logistic management 平滑产品部署　　　
　产品实施与维护。

　3. 开发过程特点

　1) 文档齐备：每人清楚了解自己需要做的工作；功能规范由一个3-5人的小组负责完成。
　2) 相互阅读代码：实现目标为同一个feature，代码间可能相互依赖，有助于整体提高效率；避免核心代码由一人完全控制。
　3) 代码注释：包含详尽的调试信息，便于理解与问题解决。

　二．项目管理
　1． 管理机制

  • 组织架构
    • 产品开发行政结构，一个Product Unit Manger，下设三个平级的部门经理，团队项目经理(Product Unit Manager),软件开发经理(Development Manager)和测试经理(Test Manager)；每个部门经理管几个组长，每个组长下再有3到5个具体工作人员，如项目经理，软件开发人员与测试人员。
    • 产品设计，产品实现和产品测试，三权分立，相互配合，相互制约，相互依赖，有助于建立明确责任制，从而保证产品开发的顺利完成。
    • 软件开发与测试经理/组长，均为专业技术人员出身，能够指导部下工作或代替他们完成任务；这样人员的行政管理就是领域专家式管理，保证了开发从技术上思考和评判设计方面的问题。员工也会乐意接受能真正了解他具体工作的人领导，并给与充分的尊重，同时也能避免开发人员虚报所需工作日的情况。
    • 微软行政级别决定员工工资，股权等福利待遇，而职务头衔与行政级别并不是直接挂钩的。技术人员只要能力强，贡献大，行政级别与工资，福利待遇可能同高层一样，不需成为经理或领导才能获得较高级别的待遇。这样他们可安心自己擅长的工作，其能力和贡献，可经不断的提级来得到认可和回报。
  • 项目经理配置
    • 随着软件产品项目规模增大，产品质量问题，开发周期问题，内部管理等问题越来越突出，必须从根本上加强项目的组织管理，从而微软产生了项目经理这一职位。
    • 项目经理全权负责产品的最终完成，其任务涉及：了解用户需求；进行产品的功能定义，规划和设计；做各种复杂决策，保证开发队伍顺利开展工作，及跟踪程序的错误等。项目经理占开发总人数的1/5，即每个开发小组中，有一个项目经理，两个软件工程师，与两个软件测试工程师。
  • 具体工作描述：
    • 1） 制定产品远景计划，写出项目规格说明书；
      • 确定商业机会后，产品单元经理制定出粗略的商业计划书，交项目经理准备项目计划草案，包括远景描述，主要功能，建议的时间表，里程碑及所需的资源。
      • 主持由开发测试骨干参加的会议，对计划草案进行全面的分析讨论，确定主要功能模块。
      • 对每一模块编写一页纸规模的设计说明书，包括功能优先级的制定与理由，对资源的估算，时间表的估算，风险评估，同其他功能块的关系；目的要评估实现这个功能块的成本，目标与条件。
      • 召集产品单元经理，各部门经理参加的设计说明书评审会，汇总所有功能块说明书，对进度，功能块的取舍做总结和决定。
    • 2） 制定工作详细任务表，跟踪任务的执行情况，保证其符合规格说明书的原始设计。
    • 3） 指导项目开发的过程设计与实现；对各种具体方案进行取舍并做出决定。
    • 4） 组织会议，评审程序错误；协调成员之间交互配合。
    • 5） 产品完成后，主持项目总结报告会，讨论此次的经验与教训；下一版本的改进，及具体的行动计划。
  • 项目经理要求
    • 项目经理通过产品单元经理，对软件设计工程师和测试工程师的资源和任务分配进行调整，但不会直接下达行政命令；其核心任务是业务领导，掌握产品全局观念和进度，协调开发人员与测试人员的工作进度，及同与产品有关的其他人员接触，如市场，用户支持，客户教育等。
    • 对团队的领导，主要依靠其个人威信(credit)，开发人员和测试人员的尊重和配合；其威信来自于工作中表现出的领导力，洞察力和判断力，以及高素质的技术专长和出色的协调沟通能力。
      1） 领导能力保证项目组的高效运作，如，召集每周的项目进度会议，确定工作日程并进行跟踪，提交项目进度报告。
      2） 洞察力和判断力，有助于在复杂情况下，迅速找到问题症结所在，并提供解决对策。
      3） 技术专长使其能真正帮助开发人员解决设计上难题，帮助测试人员分析和判断程序错误；懂得开发人员和测试人员的共同语言，使之感到你对他们的理解和尊重，从而赢得大家的信任。
  • 项目经理面试问题：
    1） 在过去做过的产品项目中，哪一个你觉得最自豪 ? 为什么 ?
    2） 你解决过的最难的技术设计问题是什麽？为什麽采用那种解决方案？
    3） 你有什麽项目是按计划的时间完成的？未能按时完成的原因主要是哪些方面？

2． 软件开发过程 software development in Mircosoft

　1) New product project 提议 ；
　2）市场分析预测 <是否有用，是否是需要的>；
　3）技术可行性分析 <是否能够实现>；
　4）产品研发计划和实施步骤；
　5）高层论证和审批 <支持者>；
　6）项目确立和执行 <人力资源和财务资源的配置>

　3． 微软项目管理-- 多里程碑式流程

  • 每个里程碑完成部分功能；便于团队集中力量完成一个又一个功能；提供多个机会以适应需求的更改
    如何完成一个里程碑
  • 步骤一： 达成共识 Vision / Scope Approved Milestone
    • 基本完成需求调研和分析 （产品经理负责）； 确定大方向和长中短期目标，Vision来说明，并激励团队； 评估Opportunities & Risks；分析可利用资源限制，证明该产品值得去做；
    • 项目管理团队：设计新产品目标，具体实现方法；描述产品结构，用户情景覆盖80%以上功能。
    • 软件开发团队：开发技术原型，检验新产品价值，并展示产品未来预期。
  • 步骤二： 完成项目计划 Project Plan Approved Milestone
    • 定义详细的逻辑设计，功能设计规范（项目经理负责），其优先级；所有角色参与审阅功能规范；
    • 评估进度控制风险，功能技术风险； Risk Assessment 通常在物理设计之后，立即执行。
    • 制订总体开发计划和进度表，包括 资源与职责的分配，制订测试，开发计划和进度表；
    • 产品管理团队：概念设计和市场推销计划/进度表；
    • 软件开发团队：物理设计和开发计划/进度表，Task-level Estimating。
  • 步骤三： 完成功能 Scope Complete / First Use Milestone α Version Phrase
    • 版本化的功能规范，完成全部功能代码的编写； All features built to specification
    • 及时进行模块间的整合，及时发现问题（daily build）；版本控制工具 VSS ；
    • 测试团队：测试规范 与Test Case 设计，BMS缺陷跟踪，实现解决Bug自动流程；
    • 产品管理团队：控制用户的期望，推销，价格，包装（正式产品为 Golden Release）
    • 项目管理团队：项目跟踪/沟通，按照综合进度表不断检查进度； 制定β版本计划。
  • 步骤四： 稳定与发布 Release Milestone β Version Phrase
    • 全面地测试功能；开发组全力配合解决Bug；决定哪些Bug到下个版本中解决；
    • 预测发布日期 ；编写操作手册与帮助文档；
    • 基于版本发布：每一个版本有明确清晰的目标，解决或终结产品中的某些问题；
    • 成立Triage小组：由PM，Dev与Test的负责人组成，决定对发现Bug的处理。

三． 微软的开发管理经验：100%以Bug为核心

　Bug 追踪归类：
　Fixed：已修复或更正； Duplicated: 某bug以被别人找出来了； Won't fix：可忽略不计
　Postponed：此bug不很重要，可推迟到下一阶段解决，或更正风险太大，bug本身影响有限；
　By design ：不符合逻辑，也不符用户需求，但同设计吻合；
　Not repro ：某bug自动消失，可能处理其他bug时，一并修复了。

1．Bug 及常见类型

  • 功能未实现，和规格说明书不一致； 不能工作：死机，没反应；不兼容； 边界条件
  • 界面、消息、提示不够准确，不友好；把尚未完成的工作也作为一个Bug；文档与帮助信息中的缺陷

4． RAID/BMS的基本功能

  • 完整的Bug数据库； 整个产品组的中央记录和控制； 强大的查询功能，有效地跟踪项目的状态
  • 所有的记录无法删除，对于每个记录只能一直添加内容；丰富的报表功能，为产品发布提供判断标准

5． Bug 记录中的有效信息

  • 状态； 负责人； 问题种类； 严重级； 优先级； 修改时间； 登记时间
  • 缺陷来源； 解决方案； 运行环境； 缺陷关联； 附件； 附图； 缺陷细节

6． Bug 的严重程度

1）死机，数据丢失，主要功能组完全丧失，系统悬挂；
　2) 主要功能丧失，或致命的错误声明
　3) 次要功能丧失，不太严重，如提示信息不太准确 ；
　4) 微小的问题，对功能几乎没有影响，仍可使用.

7． 激活的Bug数量的趋势

  • 代码完成前：很少； 代码完成后：增长很快； 接近Beta: 下降； 接近RC: 奔向零 ；
  • 产品质量和里程碑的信号
  • 每天新建的Bug 与 修正的 Bug 相比较 ； Active 状态 Bug 的总数

四．微软的一天

　1．每日构造Daily Build
　Daily Build是所有工作的核心，而且是在半夜自动启动。

  • Daily Build的意义： 模块得以及时整合； 要求程序员及时把最新代码放入代码库
  • 用脚本语言和编译/链接工具实现
  • BVT Build Verification Test ：对Build进行验证
  • Blocking Bug ：让Build无法完成的问题； BVT中发现的问题

2．程序员每天上班前最担心什么？
　答案：因为自己昨天的代码check-in，造成Blocking Bug.每天的Build是所有人当天工作的基础，程序员需要Build验证与其他模块的接口；测试需要Build发现新Bug，并验证新Build中已解决的Bug。

　有Blocking Bug怎么办？ 　解决问题，并对今天的Build打Patch。

　答案：打开缺陷跟踪工具，查看指定给自己的Bug，解决高优先度的Bug；为质量重于新功能。

　从版本控制工具中Check out代码； 修改代码（解决Bug或实现新功能）；取得版本工具中最新变化，在本机Build和单元测试；请开发组同事作Code Review ； Check in代码

3．测试人员第一件事做什么？
　答案：打开Raid/BMS，查看指定给自己的Bug，验证已解决的Bug；根据测试用例检验今天的Build ； 在Raid/BMS中记录新发现的Bug

　4．专家会诊

  • 参加者：项目经理和开发组长、测试组长
  • 通过Raid/BMS评估每个未解决的Bug：决定Bug优先度； 可否等到下个里程碑或版本？谁来解决
  • 预测项目实际进度和发布时间缺陷走势图

5．回顾微软的一天

  • 构造: daily build ； 开发: 解决blocking bugs, 实现功能, check-out, code review, check-in
  • 测试: BVT, 使用测试用例进行测试； 项目经理/组长: 专家会诊

6．微软的做法解决了那些常见问题？
　质量问题
　以前解决过的问题发布时又出现了，需要返工 ；无法预估发布时间 过早发布，带来质量和维护问题
　测试发现的问题被忘却或不了了之；无法衡量测试员和开发员的工作；程序中的问题往往在发布后才发现
　文档管理问题
　文档与程序脱节，文档成为程序结果的描述； 项目组把写文档看成负担
　团队协调问题
　开发人员各自为战，进行整合时发现模块衔接中的严重问题 需要作大的改动
　没有保管好公司以往的版本和代码，无法满足用户对旧版本的更改要求； 开发人员离职对项目带来很大冲击，没有人知道代码在哪，或无法读懂

五．提高软件管理的步骤
　1. 使用Raid/BMS，将流程管理自动化；
　2. 使用测试用例管理工具；
　3. 使用文档管理工具；
　4. 使用版本控制工具，进行Daily Build　　　
　5. 建立代码标准；
　6. 建立Code Review机制；
　7. 建立专家会诊机制；
　8. 建立团队沟通机制 ； 　　　　　　　　
　9. 根据需要调整团队结构

　产品设计考虑问题
　1 Who : 为谁设计，用户是谁？不能为所有人服务；
　2 What：要解决哪些用户问题？
　3 Why： 为什麽要解决这些用户问题？例：曲别针，餐馆中尖头筷子，一正一反可供参考。

设计之源：在于用户；设计之本：要满足用户需求，方便用户使用，并且使生产制造工艺尽可能简单；不能把软件设计单纯当作自我技术水准，个人才智表达的方式。（用户场景： 用户使用软件的特定环境或场合。）

The Program Management Role Today

Development team organization chart:

Marketing, Deve Lead, PM, Test Lead, Documentation

Developer: Mostly C.S. majors； Input: Spec, Bugs；Output: Source Code；Resolve build breaks；Conduct unit testing； Buddy Testing； Reality check: what's possible

Testers: Many different majors；Input：Spec, Compiled Code；Output：Bugs, Sign-off；Types of Testing:
Manual vs Automated(regression), Basic　vs Functional vs Stress；Performance & Reliability；Buddy Testing

Marketing: Mostly Business majors；Input: Market Research ；Outputs: Long-term Planning , Advertising, Packaging, Distribution Channels, Interaction with Sales groups

Documentation: Input: Specs, Product；Outputs: Books, Online Help, Training classes, online tutorials

PM : not have authority；Plans & Specs reviewed by marketing, dev lead, test lead and vp；everyone has thr right to ask question, and could disagree with it.

What do Program Managers do?

1) Design the product；2) Write product plans and specifications；３）Drive day-to-day development process; 4) Triage；　５）Coordinate with other departments - location, Lrgal, other product groups, etc. 6) Communicate project status & schhedule；　7) Hold Post-Mortem

Design PM focus on 1)-4)aspects；Release PM address on 3)-7) aspects.

7 key PM Roles

1 Design the product
- Organize a design team；Modular architecture -> low interdependency；What's the target market?
Usability studies & customer feedback；Put together a prototype & demo；How many people will you need? How many months will it take to develop? Get VP approval

2 Write Product Plans and Specifications ->Build a Consensus
- Vision Document: What the VP approved；
- Functional Specification: What features will the product have? What will they look like? What features will the product NOT have? What are the project milestones?
Review documents with all teams

Example vision statement: Internet Explorer

Increase IE's market share to 65% in 1998 by delivering the premimer internet client for corporations and end users, a fast and robust experience, the lowest ownership cost, and the best complement to Microsoft Office.

3 Drive day-to-day Development Process

- Use Persuasion, not authority
Persuasion styles: Logos - use logical reasoning；Pathos - appeal to the person's emotions；Ethos - appeal to the person's character and core values
Keep the Dev's coding, the builds building and the bugs flowing ; Spot trouble before it happens

- Typical Trouble Spots
Unforeseen vacation, familiy leav；Job changes - people promote or leav/join team in mid-product cycle；Higher priority projects

- From Development
Workload imbanlance - one Dev gets way behind；Too feature-focused -> huge backlog of bugs；Time estimates were too optimistic；Product performance(speed)left to the end; requires major architectural change to fix

- From Test
Build aren't ready(aren't testable); Tool changes; Virues attack Test labs
- From Build
Build Breaks from destabilizing checkins; Code Forks & Merges; Build tools are complex, customized and break easily.

4 Triage Meeting

- Origin: Battlefield Hospitals; Players: Dev, Test, and PM( Later on Loc, Maketing, Books,VP and PSS)
- Decision: What do we fix and when? (Persuation: logis, pathos, ethos)
- Status of last meeting''s Action Items; -Assign Action items

5 Coordination with Other Groups
- Other Product Groups; Localization (foreign language translation); Books(product documentation); Marketing; legal; Beta Sites; Web Site & manufacturing
You can't do it all; delegate and monitor

6 Communicate status & Schedule - No surprises
- Weekly Status Report
Give a 1-3 sentence summary: Focus the team on core metric; use peer pressure; update the schedule
- Monthly Presentation to VP
- annual Product review with Bill Gated

7 Hold a Post-Mortem
- What worked well? What didn't work well?
- What can we do to improve next time?
- Sort the improvement ideas by priority and send results to entire team

Performance review goal for PM:
- Implement 3 of the top 5 improvement ideas in the next project

Program vs Project Management

They're very similar, and the primary diference + Program Management has no authority
- People with innovative & creative ideas are less intimidated about suggesting them.

Typical college of major of Nicrosoft PM's

Computer Science, Business, Engineering(Electrical, Mechanical, etc): Psychology, Music, History, Architecture, almost anything
It's not what subject you learn, it's how you learn and what you do with it.

Developing PM Characteristics

-passion: Have a vision and then move mountain to make it happen
-Persuation: Logic, Emotion, and trust；How do your friend/ family persuade others? What techniques work or dont't? Why?
-Communication：List 30 ways to send & receive massage；Make a mental map of how people in your group interact?

-User Empathy：Use your own product; Start in Product Support or Sales; How do people use the thing you make? What do they like or not about it? Why? Certification programs.

-Fast Learner: Find the key concepts and find out the rest; Use failures as learning opportunities.
-Good Judgment: Which path agrees most with my core values? Is this fight worth fighting?

Developing PM Skills

-Coding Skills: Need to speak same language as Developers; Need to know what's possible and not.
-Architectural Design: Make it modular, reduce interdependency; Make it extensible , so you don't have to start from scratch with version 2.0.
-User Interface (UI) Design: Usability studies; Know how people think, remember & recall

-Application Program Interface(API) Design

-Financial Acumen: What is or not profitable,What's realistic to ask of a Test/Developer
-Basic legal Knowledge: Patent Law, Copright Law, Contract Law

设计是功能和性能的逻辑实现；以体系结构为中心的软件设计重点在，定义构件的规格说明与接口，分析构件间的关系；大的体系结构是由小的轻量级的体系结构组成。

框架为某个问题涉及的各个方面，以及这些方面的相互关系；相互关系可以是结构性的，但更多的是非结构性的。如：两国就某河水利用问题达成框架协议。
MSF为微软就应该做哪些方面工作，以及如何做才能得到较好解决方案的建议。

MSF优势在于迅速将前沿技术迅速转化为工程应用，而不强调理论的完美性；对体系结构的设计与实现基于未来的需求，而非当前现状；需求的获取，回避过早，过严的需求规格说明，在应用和系统设计完成之前，详细的需求定义一直在修改与增补。

企业服务框架ESF(Enterprise Service Framework)

为微软为用户提供的开发企业级应用的规范，由三个子框架组成，MRF(Microsoft Readiness Framework)准备框架，MSF，与MOF(Microsoft Operation Framework)营运框架。
MRF：ESF的准备阶段，提供一种结构化方法，来评估个人与组织的信息技术需求，以便规划，建造和管理微软平台上的IT解决方案。
MSF： ESF的核心部分，为项目计划，建造及部署阶段提供指南，涉及EA(enterprise architecture)企业体系结构，应用开发(application development)，构件设计(component design)，及基础设施部署(infrastructure deployment)等多个方面。
MOF：ESF的管理阶段，为关键系统提供技术指南，保证其可靠性，可用性与可管理性；涉及评估工具，最佳实践，案例研究及支持工具等。

企业体系结构 BAIT模型

1 业务（Business）
　1）组织的目的和目标 业务是什麽？
　2）组织的结构 负责人?
　3) 关键的业务过程与活动 组织如何做业务？
　4）与客户的关系 谁是最终客户？
　5) 与供应商/制造商的关系 组织需要和谁协同工作？

2 应用（Application）
　自动化服务支持的业务过程；识别冗余的应用；识别重用的机会。

3 信息（Information）
　识别信息的来源与消费者；描述关键业务和数据对象，及其相互间关系。
数据为记录上下文的原始事实的符号；信息为有组织的数据；而知识为表现某种观点的有组织的数据和信息。

4 技术（Technology）
定义了执行业务使命所需的技术服务，如拓朴结构，开发环境，应用编程接口，网络服务，数据库系统，技术规范，操作系统等；在部署工作站，服务器，应用程序，基础设施服务，网络连接及系统软件平台时，提供建立标准和指导原则。
描述构件和技术，用以建造和运行该组织的系统；描述基础设施和营运环境；连接应用和信息体系结构的技术。

目标：企业长期战略的组成部分，为业务要实现的东西；
目的：企业长期战略目的的细化，是可以测量及完成的事情，必须是明确的，有优先级和时间限制。

找出关键业务过程
　1） 确定企业体系结构的范围；
　2） 寻求更高的收入，节约开销的方式，客户界面，更广泛的使用（高容量/高频率）。

业务功能分解 功能-过程-活动-任务
如：功能（财务管理）- 过程（会计接收）- 活动（做单据）- 任务（计算客人的收费和清单）

业务过程，活动，任务，步骤四个环节，逐级定义；场景是指定角色，执行任务序列的文档化，是用例的实例。

风险管理
　1　风险的标识
　从两个方向入手：1) 潜在问题一旦出现，会产生什麽后果；2)　可能的后果，引起的原因

　2 风险分析
　1) 估计风险出现的概率
　概率采用简化模量，如：1= 低，2= 中，3=高，分别相当于 <25%，=50%，与>75%。
　2) 估计风险的影响
　灭顶之灾(catastrophic)=4，严重(critical=3)，非紧要(marginal=2)，轻微(negligible=1)。
　3) 量化风险灾害　RE = 概率P×影响C relative evaluation

　3 风险计划 (Risk Mitigation, Monitoring & Management) RMMM

　4 风险追踪与控制
　1 Envisioning Phrase 工作产品为三个文档
　1）前景文档(vision document): 以业务用例形式，表达项目的目标和约束。

  • 问题陈述：说明项目要解决的业务问题，是前景文档开发的基础；
  • 前景陈述：工作产品要达成的目标，为产品开发的基础；
  • 解决方案概念：描述前景的业务过程，是目标的具体化。业务场景为动态业务过程的快照，是解决方案实施后的结果；而解决方案为设计的目标，其实现为设计过程。
  • 用户概述user profile: 指出最终用户，找出所有可能潜在的用户；产品的开发为小组与用户共同提高的过程。
  • 业务目标：实现的产品功能和性能，体现产品的业务优势；明确目标的相对优先级，说明产品的非目标no-goals，界定范围；制定评估产品的量化指标。
  • 设计目标：怎样实现这些功能和性能；重申产品的需求与约束，为下一步计划，开发的基础。

2） 风险评估文档：项目风险的初步考察与处理策略。
　3） 项目结构文档：项目人员的组织结构，管理过程的基础。

2 Planning Phrase
　1) 设计过程

  • 概念设计：对业务前景用软件术语描述或解释，如订票，出票，入账改为输入，输出，入库等。
    获取问题，解决方案的业务和用户视图；标识业务需要及其运作环境，理解用户操作和需求的大框架；不能期望从概念设计得到完整的功能规范；输出工件为场景，场景为理解需求，与用户交流的有效方法。
  • 逻辑设计：把概念设计的表达(概念元素及其关系)，映射成程序世界能够接受的逻辑表达；侧重体系结构的创建。
    描述设计组织的解决方案及其元素间通讯，给出解决方案的初步视图；基于前一阶段的成果-场景，设计对象与服务，用户界面原型，以及逻辑数据库。
  • 物理设计：设计的实现，同样不用编程语言表示；精确定义元素及其交互接口，进行数据库物理设计，提供用户界面规格说明；重点在于编写各对象/模块/构件的规范说明，接口和关键的算法描述。
    一种基于服务的方法，将解决方案映射到分布的单元上，考虑实现的技术约束与性能问题。

2) 提交成果

  • 功能规范：
    产品及其特性集的详细描述；为客户与项目组间契约，也是制定主计划和主进度表的基础。
    内容包括：前景概述，设计目标，产品需求（优先需求与冲突平衡），用户概述，特性，产品依赖性（高层依赖为外部系统，底层依赖为共享构件），进度描述，风险，附录(设计过程的输出)。
  • 项目主计划：汇总各分计划，说明产品如何构造；包括：开发计划，测试计划，培训计划，用户支持计划，市场宣传计划，部署计划等。
  • 项目主进度表：同项目主计划一一对应
  • 主风险评估文档：提供项目风险整体视图，导出高层决策和工作的优先级。

3 Developping Phrase
　Code Review: 提高代码质量，加快开发进度（节约了测试与维护时间），提供培训开发者的方法，增强代码的可维护性。
　Daily Build：隔离缺陷，减少集成风险；较早发现缺陷；保持对项目进度的监控。

　4 Stablizing Phrase 产品测试，项目总结评审

property: 表示对象状态的数据集；attribute：不是早期面向对象数据集统称的属性，而是说明对象性质与方法的metadata，特别是共享对象。

构件：一个应用逻辑单元，提供一组只能通过已发布的接口或契约，来访问的服务集合；从程序角度，构件即共享的类对象。

接口：构件与外界的界面，方法的简要规格说明，包括方法类型，方法名及参数表；是对构件中提供的服务的引用端口。

契约：一种特殊接口，对象间商定的相对固定的接口。如：构件P为了实现服务C，要求对象Q为它提供服务E，接口E即 PQ间的契约。接口类也是一种契约，规定该做什麽，而构件实现怎麽做。

RPC为底层的交互标准，可用来调用远程动态链接库；DCOM正是在RPC技术上构建的。 TCP/IP协议套接字组成了另一种供构件在网络上交互的底层协议。

远程数据对象RDO (Remote Data Object)，数据访问对象DAO (Data Access Object)，及开放数据库连接 ODBC (Open Data Base Connection)，为构件用来与数据库交互的三种数据访问技术。ODBC 性能最好，其次是 RDO和 DAO；而DAO 提供了丰富的编程接口，易于使用，其次才为RDO 与ODBC。

微软测试阶段
　planning: test manager 写test plan,关于资源，测试目标；
　coding：制定详尽的测试用例，放入database；CC要实现产品的最基本功能，推出一个可测试的版本！
　fix bug: 从cc到release进行多次测试迭代；产品的specification在此阶段，也不断动态更新；
　alpha，beta：进入beta测试阶段，UI被freezed，不能修改； 写帮助文档的启动工作；
　release candidate: RC阶段不允许提交代码，遇到非改不可的bug则推出下一个RC；针对每一个，对应一次完成的测试过程；
　release：此版本的尚存的bug应是可以容忍
　bug court 由test manager ，developer manager，requirement manager 三人裁决；specification 由designer制定；　detail design由程序员完成，并提交详细设计报告；一般而言，此报告比较简单，关键还要看代码；代码的注释通常清晰详尽。
　BVT, stress, full test pass, adhoc test, bug regress, risk areas, change role test
MS的BVT测试自动化进行，验证底层的service or driver，覆盖到每一个build；此类测试用在界面上GUI方面，结果不太可靠。
　full test pass：比较消耗时间，一般在一个里程碑处才进行；full test pass, bug regress在项目后期，bug较少时进行才有意义。
　change role: 当一个RC测试时间较长时，如两周，为了保证对bug的敏感度，可考虑人员交换模块测试；但一个release内仍以专人负责制定部分为主。

测试报告字段
　Title，Severity，Priority，Reproduce Steps，Assigned To，Status(active, resolved,closed)，attachment，link to previous bug(Bugs in database are not allowed to be deleted)，Test enviroment，Build No.，Areas(modular)，Reasons(filled by developer)
　不可复现的bug不能添入数据库；因为不知造成问题的真正原因，无从查起！
　测试经理提交每周发现的，解决的，及每个成员bug统计的周报；并绘制趋势曲线图，展示bug发现与解决的相对速率。
　工作分配的再调整，依据团队发现bug的统计规律；个人绩效评估很大程度上依据发现的bug数量。

 

版权所有：UML软件工程组织