Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
The OpenOffice.org Specification Process Demystified <ul><li>Christian Jansen, Jörg Sievers </li></ul><ul><ul><li>Sun Micr...
<ul><li>Why do we need specifications? </li></ul><ul><li>Writing a specification </li></ul><ul><li>A specification templat...
Why do we Need Specifications?
How many test cases have to be created after this change? Negative values can now be entered here
... Way too many But...
At least 12 test case representatives are needed for methodical testing
Examplary Test Case Design <ul><li>To reduce the count of test cases some black-box methods (here:  equivalence class part...
Test Case Representatives
More Impacts...
Errors & Costs Ebert C., Dumke R (Hrsg.), Software-Metriken in der Praxis, Springer, Berlin/Heidelberg, 1996
Errors & Efforts on OOo <ul><li>QA  evaluates issue </li></ul><ul><li>Program Management  sets target </li></ul><ul><li>De...
<ul><li>Specifiying saves your time </li></ul><ul><li>You increase the product quality </li></ul><ul><li>You save others' ...
Writing a Specification
Todays Process Plan Do Review / Improve
Tomorrows Process
No Waterfall Model
<ul><li>These pre-requisites are needed </li></ul><ul><ul><li>A requirement (customer need).... </li></ul></ul><ul><ul><li...
<ul><li>Develop a common sense of the goal </li></ul><ul><ul><li>Introduce the feature </li></ul></ul><ul><li>Nail down th...
<ul><li>Nail down the responsibilities </li></ul><ul><ul><li>State clearly who is responsible for what </li></ul></ul><ul>...
<ul><li>Don't: </li></ul><ul><ul><li>Design the feature: This chat is for planning only. If there's design to be done, sch...
<ul><li>I-Team Kickoff </li></ul><ul><li>Detailed feature / sub-feature planning </li></ul><ul><li>First design sessions <...
<ul><li>Create prototypes </li></ul><ul><li>Write specification </li></ul>Do
Review <ul><li>i-Team reviews specification </li></ul><ul><li>Based on three essential rules </li></ul><ul><ul><li>R1:  Co...
Specification Rules <ul><li>R1:  Complete First and foremost a specification has to be complete. That means all relevant a...
<ul><li>Reduction of defects in specification. </li></ul><ul><li>Reduction of defects in implementation. </li></ul>Improve
Finish <ul><li>Specification and implementation must be identical </li></ul>Implementation Specification
A Specification Template - Why?
A Specification Template - Why? <ul><li>It  simplifies   writing  specifications, </li></ul><ul><li>It  centralizes all in...
A Specification Template -Why? ...and thus it saves you and others time...
Issues of the Old Spec. Template <ul><li>Separation between specification template and specification guide </li></ul><ul><...
The New Specification Template
There is Lots More Stuff in it ... A Help which guides you through the template
There is Lots More Stuff in it ... Specification Status Section Abstract Section: The source for the “Guide to new features”
There is Lots More Stuff in it ... The i-Team
There is Lots More Stuff in it ... Links to important reference documents
There is Lots More Stuff in it ... Tooling for “automatic” User Interface specification
There is Lots More Stuff in it ... Concrete examples for junior specification writers
Further Information and Feedback <ul><li>Specification Project on OOo Wiki http://wiki.services.openoffice.org/wiki/Catego...
The OpenOffice.org Specification Process Demystified <ul><li>Christian Jansen, Jörg Sievers </li></ul><ul><ul><li>Sun Micr...
Upcoming SlideShare
Loading in …5
×

The OpenOffice.org specification process demystified

1,582 views

Published on

Goal of this presentation is to bring the specification process closer to the OpenOffice.org community.

Specifications are an essential and central part of the OpenOffice.org development process. They serve as working base for Development, User Experience, Quality Assurance and Documentation.

  • Be the first to comment

  • Be the first to like this

The OpenOffice.org specification process demystified

  1. 1. The OpenOffice.org Specification Process Demystified <ul><li>Christian Jansen, Jörg Sievers </li></ul><ul><ul><li>Sun Microsystems </li></ul></ul>The OpenOffice.org Specification Process Demistyfied <ul><li>Christian Jansen, Jörg Sievers </li></ul><ul><ul><ul><li>Sun Microsystems </li></ul></ul></ul>
  2. 2. <ul><li>Why do we need specifications? </li></ul><ul><li>Writing a specification </li></ul><ul><li>A specification template - Why? </li></ul><ul><li>Q&A </li></ul>Agenda
  3. 3. Why do we Need Specifications?
  4. 4. How many test cases have to be created after this change? Negative values can now be entered here
  5. 5. ... Way too many But...
  6. 6. At least 12 test case representatives are needed for methodical testing
  7. 7. Examplary Test Case Design <ul><li>To reduce the count of test cases some black-box methods (here: equivalence class partitioning with boundary value analysis ) are being used. </li></ul><ul><ul><li>Find for each equivalence class a representative test case. </li></ul></ul><ul><ul><li>Combine all valid classes with one invalid class. </li></ul></ul>
  8. 8. Test Case Representatives
  9. 9. More Impacts...
  10. 10. Errors & Costs Ebert C., Dumke R (Hrsg.), Software-Metriken in der Praxis, Springer, Berlin/Heidelberg, 1996
  11. 11. Errors & Efforts on OOo <ul><li>QA evaluates issue </li></ul><ul><li>Program Management sets target </li></ul><ul><li>Developer </li></ul><ul><ul><li>Evaluates issue </li></ul></ul><ul><ul><li>Sets up workspace </li></ul></ul><ul><ul><li>Fixes issue </li></ul></ul><ul><ul><li>Builds workspaces </li></ul></ul><ul><ul><li>Evaluates fix </li></ul></ul><ul><li>QA evaluates fix in installation set </li></ul><ul><li>Release Engineering integrates workspace </li></ul><ul><li>QA </li></ul><ul><ul><li>Evaluates fix on master workspace </li></ul></ul><ul><ul><li>Closes issue </li></ul></ul><ul><li>Customer installs fixed version </li></ul>
  12. 12. <ul><li>Specifiying saves your time </li></ul><ul><li>You increase the product quality </li></ul><ul><li>You save others' time </li></ul><ul><li>You can increase test coverage systematically if needed </li></ul>Conclusion
  13. 13. Writing a Specification
  14. 14. Todays Process Plan Do Review / Improve
  15. 15. Tomorrows Process
  16. 16. No Waterfall Model
  17. 17. <ul><li>These pre-requisites are needed </li></ul><ul><ul><li>A requirement (customer need).... </li></ul></ul><ul><ul><li>... and an i-Team </li></ul></ul><ul><li>Development starts with a kickoff chat (IRC #openoffice, GAIM, ...) </li></ul>How to Write a Specification?
  18. 18. <ul><li>Develop a common sense of the goal </li></ul><ul><ul><li>Introduce the feature </li></ul></ul><ul><li>Nail down the priorities </li></ul><ul><ul><li>Prioritize the sub-feature </li></ul></ul>Kicking off a New Feature...
  19. 19. <ul><li>Nail down the responsibilities </li></ul><ul><ul><li>State clearly who is responsible for what </li></ul></ul><ul><ul><li>Let the i-Team know who delivers what </li></ul></ul><ul><li>Always keep the customer in mind </li></ul><ul><ul><li>Wether an internal stakeholder or external client, the customers satisfaction must be top priority </li></ul></ul>Kicking off a New Feature...
  20. 20. <ul><li>Don't: </li></ul><ul><ul><li>Design the feature: This chat is for planning only. If there's design to be done, schedule another chat for that. </li></ul></ul><ul><ul><li>Try to solve technical problems Don't get bogged down in details at this first chat. </li></ul></ul><ul><ul><li>No Agenda As this is a planning chat, this chat needs to be prepared. L ong, unproductive chats exhaust people. </li></ul></ul>The Dont's in a Kickoff
  21. 21. <ul><li>I-Team Kickoff </li></ul><ul><li>Detailed feature / sub-feature planning </li></ul><ul><li>First design sessions </li></ul>Plan
  22. 22. <ul><li>Create prototypes </li></ul><ul><li>Write specification </li></ul>Do
  23. 23. Review <ul><li>i-Team reviews specification </li></ul><ul><li>Based on three essential rules </li></ul><ul><ul><li>R1: Complete </li></ul></ul><ul><ul><li>R2: Clear </li></ul></ul><ul><ul><li>R3: Simple </li></ul></ul>
  24. 24. Specification Rules <ul><li>R1: Complete First and foremost a specification has to be complete. That means all relevant aspects of a feature have to be captured. </li></ul><ul><li>R2: Clear Each statement has to be unambiguously clear to Development, QA, User Experience, Documentation. </li></ul><ul><li>R3: Simple Each statement shall be as short and as simple as possible. </li></ul>
  25. 25. <ul><li>Reduction of defects in specification. </li></ul><ul><li>Reduction of defects in implementation. </li></ul>Improve
  26. 26. Finish <ul><li>Specification and implementation must be identical </li></ul>Implementation Specification
  27. 27. A Specification Template - Why?
  28. 28. A Specification Template - Why? <ul><li>It simplifies writing specifications, </li></ul><ul><li>It centralizes all information </li></ul><ul><li>It gives you clear guidance on: </li></ul><ul><ul><li>“ What ” belongs to a specification, </li></ul></ul><ul><ul><li>“ How ” to write a specification, and... </li></ul></ul><ul><li>...It automates common tasks like specifying user interfaces </li></ul>
  29. 29. A Specification Template -Why? ...and thus it saves you and others time...
  30. 30. Issues of the Old Spec. Template <ul><li>Separation between specification template and specification guide </li></ul><ul><li>No links to required companion documents </li></ul><ul><li>Unnecessary sections </li></ul><ul><ul><li>Process related aspects (e.g. i-Team approvals) </li></ul></ul><ul><ul><li>A motivation section, an user scenarios section, etc. </li></ul></ul><ul><li>Missing rules on how to write and read a specification </li></ul><ul><li>Lack of examples </li></ul>
  31. 31. The New Specification Template
  32. 32. There is Lots More Stuff in it ... A Help which guides you through the template
  33. 33. There is Lots More Stuff in it ... Specification Status Section Abstract Section: The source for the “Guide to new features”
  34. 34. There is Lots More Stuff in it ... The i-Team
  35. 35. There is Lots More Stuff in it ... Links to important reference documents
  36. 36. There is Lots More Stuff in it ... Tooling for “automatic” User Interface specification
  37. 37. There is Lots More Stuff in it ... Concrete examples for junior specification writers
  38. 38. Further Information and Feedback <ul><li>Specification Project on OOo Wiki http://wiki.services.openoffice.org/wiki/Category:Specification </li></ul><ul><li>Specifaction Project Website http://specs.openoffice.org/ </li></ul><ul><li>Specification Template http://specs.openoffice.org/collaterals/template/OpenOffice-org-Specification-Template.ott </li></ul><ul><li>Feedback [email_address] </li></ul>
  39. 39. The OpenOffice.org Specification Process Demystified <ul><li>Christian Jansen, Jörg Sievers </li></ul><ul><ul><li>Sun Microsystems </li></ul></ul>Thank You! <ul><li>Christian Jansen, Jörg Sievers </li></ul><ul><ul><ul><li>Sun Microsystems </li></ul></ul></ul>

×