openerp-community-leaders team mailing list archive
-
openerp-community-leaders team
-
Mailing list archive
-
Message #00117
Proposal for extended bugfix/development procedures
Dear communityleaders,
As a result of a discussion held in the openerp-expert-accounting list
https://lists.launchpad.net/openerp-expert-accounting/
with topic "OpenERP v6 order lines to invoice lines relations..."
there seems to be some need for procedures in how we do bugfixing in
stable versions and developing in a final stage of almost go live in trunk.
The software is getting that big that there should be domain owners that
will check every single solution provided by a developer before it is
committed.
Where people are working, mistakes will happen, but we should make that
happen less.
After a IRC meeting 1,5 year ago, where this issue is discussed also, I
have send on request of Fabien on 10 March 2009 a email to Fabien and
Christophe S. with a detailed proposal that could be the base for making
such procedure. But till now I guess nothing has happened. At least we
didn't see anything.
I hope the 2 given examples by Raphael and Kaspers (and there are more
to find) justify the need of this.
Herewith I will copy below my given proposal. I don't say it should be
used that way, but it could serve as a base for OpenERP's procedure. I
have written it for 2 other Open Source projects and it is based on my
working experiences in development and maintenance at a commercial ERP
company. It is written in Wiki markup language. I am searching for the
mentioned images on my systems. I couldn't find them yet.
+++++++++++++++++++++++++++++++++++++++++++
=Quality Control Procedures=
----
==Why Quality Control for OpenERP==
As growing of the installed base of OpenERP is a main goal, to be the
only open source ERP package relevant for users worldwide and relevant
for other software packages to connect to (like e.g. OSCommerce),
Quality Control is key to secure the quality of the delivered OpenERP
software.
Quality Control describes the procedures where Software Maintenance and
Software Development are in place.
OpenERP will deliver a central place where users can register there
found bugs, feature requests and post their self made contributions
(patches) as a request to adopt them into the standard software.
Stick to the procedures..........'''procedures are there to follow'''!!
If a procedure is not working, the procedure needs to be changed.
This procedure is not editable by the community. If you have comments to
this procedure please send a message to [link to person_y]
==Which tool do we use==
We will be using the [link to tool] on the xxxxx project page.
=Maintenance Processes=
'''Purpose:'''
We have written this process to efficiently assess incoming user issues
within OpenERP Maintenance and to deliver a timely, quality solution in
a manner that maximizes user satisfaction.
'''Scope:'''
This Process is designed to meet Internal OpenERP requirements, External
user requirements, and Development quality standards.
The Work Instructions are written to remind developers what needs to be
done. They are not written to exhaustively instruct developers on how to
do their job. Where detailed instructions are necessary, they are linked
as separate documents so that they do not clutter this wiki.
This Process is subdivided into five phases. Each phase contains a
logical grouping of activities that should be executed as a unit. The
phases are:
1. Tracker Validation
2. Tracker Acquisition
3. Solution Design
4. Solution Implementation
5. Solution Delivery
PURPOSE:
* Resolve reporter issues through solutions, explanations, and
recommendations.
PRE-CONDITIONS:
* A tracker is created by reporter or developer.
PROCESS REQUIREMENTS:
* The Tracker Validation phase is completed within 2 business days
of Tracker creation.
DELIVERABLES:
* Solutions for "accepted" Trackers, delivering a fix or an
enhancement.
* Resolutions for "rejected" Trackers, explaining why a Tracker
cannot be resolved in the manner
the reporter or Developer requests and offering recommendations
or workarounds.
OWNERSHIP:
* Quality Control Manager owns the procedure
* OpenERP Management are responsible for enforcing commitment to
process
* Module Owners and Developers are responsible for knowing and
following the process as well
as providing feedback to Management and Quality Control Manager
== Outline of procedure ==
[[Afbeelding:Defect_procedure.jpg]]
==Decision 1: Is tracker valid?==
Decision 1: Is Tracker valid?
Yes: Goto Activity 2: Acquire Tracker
===Task 1: Verify if Category is correct===
Responsibility: Domain Owner
Guideline:
PURPOSE:
* Ensure that a Tracker is logged in the proper Category
PRE-CONDITIONS:
* None.
EXPECTATIONS:
* None.
DELIVERABLES:
* A Tracker in the proper Category
* A comment on the Tracker as to why the Tracker was moved to
another Category.
WORK INSTRUCTIONS:
Step 1: Read the Tracker summary and all comments. Quick source
code checks are ok.
Step 2: Decide if the described issue belongs in the current
Category or another.
Step 3: If you move the Tracker to a new Category, add a comment
explaining why.
ADDITIONAL RESOURCES:
Consideration for this Process:
===Task 2: Verify if tracker information is complete===
Responsibility: Domain Owner
PURPOSE:
* Ensure that the Tracker text and/or comments contain all
necessary information to reproduce.
PRE-CONDITIONS:
* None.
EXPECTATIONS:
* None.
DELIVERABLES:
* An effectively documented Tracker.
WORK INSTRUCTIONS:
Step 1: Read the Tracker and all comments.
Step 2: Verify that the Tracker contains all "necessary"
information from the Tracker template.
Step 3: If Tracker information is acceptable, continue to the next
task.
Provide a comment on the Tracker explaining anything out of
the ordinary.
Step 4: If Tracker requires more information:
* Add your name to the "Assignee" field
* Email the Reporter via xxxxxxx, identify what is missing
and what you need
* Set the Status of the Tracker on "Pending" and the
Groupstatus on "Waiting"
ADDITIONAL RESOURCES:
See document "Acceptance criteria"
Consideration for this Process:
===Task 3: Accept or reject tracker===
Responsibility: Domain Owner
PURPOSE:
* To accept a Tracker as an issue/enhancement or reject it with
explanation.
PRE-CONDITIONS:
* The Tracker needs to be in the right Category, with adequate
information for determining fault or functionality.
EXPECTATIONS:
* The Domain Owner will not close the Tracker without agreement by
the Reporter.
DELIVERABLES:
* A "Previewed" Tracker
* Rejected Tracker with Clear Resolution Text.
WORK INSTRUCTIONS:
Step 1: Understand the Reporters Issue.
* Read the comments on the tracker
* Reproduce the issue or examine Reporter's reproduction
* Read help text and/or design documentation
Step 2: Evaluate the reported problem.
Three outcomes exist: Enhancement, Accepted, or Rejected.
Enhancement:
* Change Datatype from "Bugs" to "Feature Requests"
Accepted:
* Set Tracker Groupstatus to "Previewed"
* Assign Tracker to the proper specific Category
* Add a comment to the Tracker and include any
appropriate comments or instructions for the Developer.
Rejected:
* Write a resolution text following the Resolution Text
template, and completely fill in all Capitalized sections.
This is important. If we cannot satisfactorily explain
the rejection to the Reporter, the user community
will also never be satisfactorily accepting the
explanation.
* Set the Tracker Groupstatus through to "Review" and
assign it to the Domain Owner for review
* Email the Reporter via xxxxxxxx with the Resolution
Text and discuss it
Step 3: In case the reporter does not accept the outcome
"Enhancement" and/or "Rejected" request an other developer
to give a second opinion.
ADDITIONAL RESOURCES:
See template " Resolution text "
See document " Resolution text "
Consideration for this Process:
==Activity 2: Acquire tracker==
===Task 1: Search the appropriate queues===
Responsibility: Developer
PURPOSE:
* Find a Tracker to solve.
PRE-CONDITIONS:
* The Tracker chosen must be "Previewed" by a Domain Owner.
EXPECTATIONS:
* The Developer will work FIFO based a manner as possible. No
"cherry picking".
DELIVERABLES:
* A new Tracker in the personal queue of an Developer.
WORK INSTRUCTIONS:
Step 1: Sort the "Previewed" Trackers by order of weight in the Group.
Step 2: Start at the top of the list (highest weight) and perform a
fast analysis of each Tracker.
Step 3: Select one you are capable of effectively solving.
Step 4: Assign the Tracker to yourself.
ADDITIONAL RESOURCES:
Consideration for this Process:
==Activity 3: Analyze Issue==
PURPOSE:
Determine if the Tracker is an actual problem.
Identify the breadth of the problem.
Develop a complete understanding of the issue, reporters expectation,
and intended functionality.
Begin the process of planning a solution.
PRE-CONDITIONS:
Previewed Tracker assigned to an Developer. Tracker Groupstatus should
be in "Design" in Developers queue.
EXPECTATIONS:
The Developer will put thorough effort into understanding what the
reporter, what the software is
actually doing, and what the software is intended/designed to do.
DELIVERABLES:
The Tracker goes into the "Design" phase
DESCRIPTION:
With "Analyze the Tracker" begins the solution design phase.
The design phase includes:
1.Analyze Tracker (Activity 3)
2.Is this a Bad Fix? (Decision 4)
3.Does tracker lead to a Functional Change? (Decision 5)
4.Plan to resolve Reporters Issue (Activity 6)
===Task 1: Read tracker information===
Responsibility: Developer
Guideline:
PURPOSE:
* Understand the Reporters issue.
* Understand the Domain Owner's instructions.
* Understand the software design (if one exists)
PRE-CONDITIONS:
* A Previewed Tracker in your name.
EXPECTATIONS:
* The Developer will take time to understand the Reporters issue
and their expectations.
* The Developer will pay attention to any instructions or hints
given by the Domain Owner.
DELIVERABLES:
* None.
WORK INSTRUCTIONS:
Step 1: Set Tracker Groupstatus from "Previewed" to "Design".
Step 2: Read the Tracker summary and all comments.
Step 3: Read any available design/development documentation.
ADDITIONAL RESOURCES:
None
Consideration for this Process:
===Task 2: Reproduce problem===
Responsibility: Developer
Guideline:
PURPOSE:
* Gain an understanding of how the reported issue occurs so that an
Developer can determine if it is actually
a bug in the software or standard functionality.
* Have test data prepared for efficient solution testing.
PRE-CONDITIONS:
* The Developer understands the reporters expectations as written
on the Tracker
EXPECTATIONS:
* An Developer will think critically about the reproduction steps
and keep in mind:
- The reporters expectations for the session
- The intended functionality (design) of the session
DELIVERABLES:
A Tracker ready for a solution design or a Resolution text.
WORK INSTRUCTIONS:
Step 1: Reproduce the issue (or review reproduction) on an up-
to-date server.
ADDITIONAL RESOURCES:
Consideration for this Process:
===Task 3: Check other modules===
Responsibility: Developer
Guideline:
PURPOSE:
* Understand the depth or extent of the problem to help determine:
- how one addresses the issue
- who must be involved
- how long it could take to resolve it
* Understand how similar sessions or modules deal with the same issue.
PRE-CONDITIONS:
* Developer understands the reporters expectations as expressed on
the Tracker
* Developer understands the intended/designed functionality of the
session
* Developer understands how the session is actually functioning
EXPECTATIONS:
* The Developer will carefully look at similar sessions and other
modules.
DELIVERABLES:
* A Tracker ready for further analysis or a Resolution Text.
WORK INSTRUCTIONS:
Step 1: Look for sessions with similar functionality within the module.
Step 2: Consult with other developers or the Domain Owner.
ADDITIONAL RESOURCES:
Consideration for this Process:
==Decision 4: Is Issue a bad fix?==
===Task 1: Determine if the issue is a result of a former bad fix===
Responsibility: Developer
Guideline:
PURPOSE:
* Determine if a solution less than 1 year old caused the problem.
PRE-CONDITIONS:
* The Developer understands:
- The reporters expectations
- What the intended functionality is
- What the session is currently doing and why
- Where else the problem may occur
* The Developer is fairly confident that the issue is a problem and
not standard functionality.
EXPECTATIONS:
* The Developer will inform the "bad fix Developer" about the bad
solution found and discuss the background of it.
DELIVERABLES:
* None.
WORK INSTRUCTIONS:
Step 1: Look in the scripts. Determine if the problem is caused by
a solution.
Step 2: If a solution caused the problem, check the date of the
solution in the Script header.
Step 3: If the solution is older than 1 year, this task is
complete. Do nothing.
Step 4: If the solution is less than 1 year old, then update the
following on the Tracker:
- Enter the offending Trackernumber into a comment in the
Tracker.
Step 5: Call, or email the Developer who created the bad fix and
discuss it.
ADDITIONAL RESOURCES:
Consideration for this Process:
==Decision 5: Does tracker lead to a Functional Change?==
===Task 1: Is the required Functional Change a Functional Modification
or a Functional Addition?===
Responsibility: Developer and Domain Owner
Guideline:
PURPOSE:
* Determine if the Tracker leads to a Functional Change and needs
to be discussed in leadership team.
PRE-CONDITIONS:
* The Developer is convinced that the Tracker leads to a functional
change
EXPECTATIONS:
* None.
DELIVERABLES:
* The Tracker processed through the leaderships team.
WORK INSTRUCTIONS:
Step 1: Start the leaderships evaluation process with the Tracker.
ADDITIONAL RESOURCES:
Consideration for this Process
==Activity 6: Resolve reporters issue==
===Task 1: Determine if resolution or solution is required===
Responsibility: Developer
Guideline:
PURPOSE:
* To finally decide if the issue on the Tracker can (or should) be
solved through a software fix or a resolution text.
PRE-CONDITIONS:
* The Developer understands what the reporter wants and what the
session actually does.
* For Resolution Text: The Developer is convinced that the session
is functioning correctly or
that the requested change is not possible or acceptable.
EXPECTATIONS:
* The Developer must consider and provide as many workarounds and
recommendations as possible
in the Resolution Text.
* A Tracker will not be solved with a Resolution Text until the
Module Owner agrees that the resolution
is complete and acceptable.
DELIVERABLES:
* Clear Resolution Text
WORK INSTRUCTIONS:
Step 1: Weigh all the information gathered from reading,
discussing, and reproduction.
Step 2: Decide whether to accept the Tracker or reject it.
Step 3: If the Tracker is accepted, set the Groupstatus to "Design"
and proceed to Solution Design.
Step 4: If the Tracker is rejected, then a clear, complete
resolution is required.
Step 5: Write the resolution text.
* Email the Module Owner with the resolution Text and discuss it
* Set the Tracker Groupstatus through to "Review" and assign it to
the Module Owner for review
ADDITIONAL RESOURCES:
Consideration for this Process:
===Task 2: Determine optimal solution===
Responsibility: Developer
Guideline:
PURPOSE:
* Identify multiple solution designs and choose the best blend of
"complete" and "possible"
PRE-CONDITIONS:
* The developer understands what the reporter wants, what the
session actually does, and what the session is supposed to do.
EXPECTATIONS:
* The solution will not decrease session/system performance
* The solution will fit within current functionality
DELIVERABLES:
WORK INSTRUCTIONS:
Step 1: If multiple solution options exist, document in a comment
the different solutions options.
Step 2: Include in the comment the reason why one solution design
is chosen over another.
ADDITIONAL RESOURCES:
Consideration for this Process
===Task 3: Create "Analysis and Design"===
Responsibility: Developer
Guideline:
PURPOSE:
* Create the "Analysis and Design" comment, if required by the
Domain Owner.
PRE-CONDITIONS:
* The Developer understands what the reporter wants, what the
session actually does, and what the session is supposed to do.
* The Domain Owner requests an "Analysis and Design" to be created.
EXPECTATIONS:
* The "Analysis and Design" will be created before any coding is done.
* The Domain Owner will review the "Analysis and Design"
DELIVERABLES:
* Tracker with an "Analysis and Design" comment, in "Review" status
WORK INSTRUCTIONS:
Step 1: This task is only executed upon the request of the Domain
Owner.
Create a new comment named "Analysis and Design" for the
Tracker.
Step 2: Select "Analysis and Design Template" from the Template
selection.
Step 3: Fully complete the template.
The intension is to fully document your Tracker analysis
and solution design for review.
Step 4: Submit the Tracker for review to the Domain Owner
ADDITIONAL RESOURCES:
Consideration for this Process:
This step exists for those situations where the Domain Owner wants to
review the Tracker analysis and
approve of the solution design before any code change occurs. Three
common instances exist where this task is useful:
* Training new Developers
* Tracker requiring significant modifications
* Tracker requiring changes in multiple packages and modules
==Activity 7: Implement solution==
===Task 2: Implement Solution in latest version===
Responsibility: Developer
Guideline:
PURPOSE:
* Modify components to create a solution to the issue.
PRE-CONDITIONS:
* None.
EXPECTATIONS:
* None.
DELIVERABLES:
* None.
WORK INSTRUCTIONS:
Step 1: Set the Groupstatus on the Tracker to "In Process"
Step 2: Make modifications
Step 3: Test your modifications.
ADDITIONAL RESOURCES:
None.
Consideration for this Process:
==Activity 8: Submit Solution for Review==
===Task 1: Create "Technical Release Notes" and "Solution Text"===
Responsibility: Developer
Guideline:
PURPOSE:
* Create Technical Release Notes to describe what was wrong, what
is right, how to fix it,
what has been changed, and the testing results.
* Create the text for the Solution Comment.
PRE-CONDITIONS:
* The Developer has developed, coded, and tested a solution to the
problem.
EXPECTATIONS:
* The Technical Release Notes must fully document all information
on the solution for the problem.
* Writing standards must be followed.
* The template should be used.
DELIVERABLES:
* A Tracker ready for Domain Owner review.
WORK INSTRUCTIONS:
Step 1: Fill out the Solution template fields.
Step 2: Fill out the Technical Release Notes template fields.
Step 3: Run spell checker.
ADDITIONAL RESOURCES:
OpenERP Writing standards
Consideration for this Process:
===Task 2: Assign Tracker to Domain Owner===
Responsibility: Developer
Guideline:
PURPOSE:
* Move the Tracker to the Domain Owner for review.
PRE-CONDITIONS:
* Technical Release Notes is written, solution is written, and
everything is tested and ready for the quality review.
EXPECTATIONS:
* None
DELIVERABLES:
* A Tracker assigned to Domain Owner
WORK INSTRUCTIONS:
Step 1: Assign the Tracker to the Domain Owner
Step 3: Set the Tracker Groupstatus to "Review"
ADDITIONAL RESOURCES:
Consideration for this Process:
==Activity 9: Review Design or Solution==
===Task 1: Review Design===
Responsibility: Domain Owner
Guideline:
PURPOSE:
* Verify that the problem analysis is on target and the Developers
solution proposal is both correct and doable.
PRE-CONDITIONS:
* The Domain Owner has requested an Analysis and Design.
* The Developer has researched the problem and created an Analysis
and Design.
EXPECTATIONS:
* The Domain Owner will determine if the proposal is correct and
possible to do.
DELIVERABLES:
* The Analysis and Design is approved (Tracker returned to
Developer "In Process")
* The Analysis and Design is rejected (Tracker returned to
Developer "In Design") and a Resolution Text is requested.
* A comment is created stating that the Design is approved or
rejected with reasons.
WORK INSTRUCTIONS:
Step 1: Read the comments on the Tracker, pay close attention to
the Analysis and Design.
Step 2: Judge if the Developers analysis of the problem is complete
and correct.
Identify anything missing and record in the Design Review
comment.
Step 3: Judge if the Developers solution proposal is complete correct.
Identify anything missing and record in the Design Review
comment.
Step 4: Determine if the proposal can be implemented.
The change may be too drastic or cause too much difficulty.
A resolution text may still be required.
ADDITIONAL RESOURCES:
Consideration for this Process:
===Task 2: Review Solution (Technical Review)===
Responsibility: Domain Owner
Guideline:
PURPOSE:
* Common Sense Quality Control
* Review the solution from a technical viewpoint to ensure correct
implementation.
PRE-CONDITIONS:
* The Developer has implemented and tested a solution.
* Technical Release Notes exists.
* Solution comment exists.
EXPECTATIONS:
* The Domain Owner will:
- Catch bad fixes before they are delivered.
- Verify all OpenERP standards are followed.
- Ensure that the solution exists in all the necessary places
(nothing missing).
DELIVERABLES:
* A Review Comment on the Tracker.
* If rejected, the Tracker returned to the Developer with a
Groupstatus of "In Process".
WORK INSTRUCTIONS:
Step 1: Read all the comments on the Tracker, pay close attention
to the Technical Release Notes.
Step 2: Do a Technical Review of code/component changes and check
for:
- Correct markings and spacing
- Programming Standards
- Impact on session performance
- Future maintainability of the solution
Step 3: Identify anything that must be fixed from the Technical
Review in a Review Comment.
If all is well, state that the Technical Review is good.
Step 4: If the Tracker fails, return it to the Developer with
Groupstatus "In Process".
Step 5: If the Tracker passes the Technical review, continue to
the Functional review.
ADDITIONAL RESOURCES:
Consideration for this Process:
===Task 3: Review Solution (Functional Review)===
Responsibility: Domain Owner
Guideline:
PURPOSE:
* Common Sense Quality Control.
* Ensure that the solution works as intended and functions properly
within the larger business process.
PRE-CONDITIONS:
* The Developer has implemented and tested a solution.
* Technical Release Notes exists.
* Solution comment exists.
EXPECTATIONS:
* The Domain Owner will:
- Catch bad fixes before they are delivered.
- Verify all Development standards are followed.
- Ensure that the solution exists in all the necessary places
(nothing missing).
DELIVERABLES:
* A Review Comment on the Tracker.
* The Tracker returned to the Developer with a Groupstatus of "In
Process" if rejected or "Deliver" if accepted.
WORK INSTRUCTIONS:
Step 1: Read all the comments on the Tracker, pay close attention
to the Technical Release Notes.
Step 2: Do a functional review of the solution for completeness
and correctness.
- Does the fix fit the current or intended design of the
session?
- Does the fix impact the current/intended design of
subsequent sessions in a business process?
- Did the Developer consider and handle all aspects of
the problem?
Step 3: Identify anything that must be fixed from the Functional
Review in a Review Comment.
If all is well, state that the Functional Review is good.
Step 4: If the Tracker fails the Functional Review:
- Identify the reasons for failure in the Review Comment.
- Return the Tracker to the Developer with Groupstatus
"In Process".
Step 5: If the Tracker passes the Functional review, continue to
the Solution comment review.
ADDITIONAL RESOURCES:
Consideration for this Process:
===Task 4: Review Solution (Solution comment Review)===
Responsibility: Domain Owner
Guideline:
PURPOSE:
* Common Sense Quality Control
PRE-CONDITIONS:
* The Developer has implemented and tested a solution.
* Technical Release Notes exists.
* Solution comment exists.
EXPECTATIONS:
* The Domain Owner will:
- Catch or Correct poorly written solution comment.
- Verify all OpenERP standards are followed.
- Review the Solution comment for proper English usage and
descriptions.
DELIVERABLES:
* A Review Comment on the Tracker.
* The Tracker returned to the Developer with a Groupstatus of "In
Process" if rejected or "Deliver" if accepted.
WORK INSTRUCTIONS:
Step 1: Read all the comments on the Tracker, pay close attention
to the Technical Release Notes.
Step 2: Review the Solution comment.
- Verify correct use of English language and grammar.
- Ensure compliance with osFinancials writing standards.
Step 3: If all is approved or fixed on the Solution comment, put
Tracker on status "Deliver" to the Developer.
Step 4: Identify any changes necessary to the Solution comment in
the Review Comment.
At the discretion of the Review, he or she may make the
necessary changes to the Solution Document.
If all is well, state that the Solution comment is good.
Step 5: If the Solution comment fails, return to the Developer
with Groupstatus "In Process".
Step 6: If the Solution Doc passes, continue to Final Review Tasks.
ADDITIONAL RESOURCES:
Consideration for this Process:
===Task 5: Review Solution (Final tasks)===
Responsibility: Domain Owner
Guideline:
PURPOSE:
* Common Sense Quality Control.
PRE-CONDITIONS:
* The Technical, Functional, and Solution comment reviews have been
successfully completed.
EXPECTATIONS:
* The Domain Owner will ensure that the solution exists in all the
necessary places (nothing missing).
DELIVERABLES:
* A Review Comment on the Tracker.
* The Tracker returned to the Developer with a status of "Deliver"
if all is acceptable.
WORK INSTRUCTIONS:
Step 1: Reminder: If all the reviews are acceptable, create a
Review Comment that states:
- Code/Component Changes are reviewed and approved.
- Functional Test/Behavior is approved.
- Solution comment is reviewed and approved.
Step 3: If further testing is required, assign Tracker to the
testing Developer.
Step 4: If all is well, assign the Tracker to the Developer in
Groupstatus "Deliver".
ADDITIONAL RESOURCES:
Consideration for this Process:
===Task 6: Extra Testing===
Responsibility: Domain Owner & Developer
Guideline:
PURPOSE:
* Do a deep, unit and/or system test on a solution to verify
correctness.
* Have a second pair of eyes test the solution.
PRE-CONDITIONS:
* The Developer has implemented and tested a solution.
* The Domain Owner (or designate) has reviewed and tentatively
approved the solution.
EXPECTATIONS:
* The Test Developer will test the specific solution as well as the
business process surrounding the defect.
DELIVERABLES:
* A Test Comment on the Tracker.
* The Tracker returned to the Developer with a Groupstatus of "In
Process" if rejected or "Deliver" if accepted.
WORK INSTRUCTIONS:
Step 1: Read all the comments on the Tracker, pay close attention
to the Module Owners Comments.
Step 2: Execute any actions requested by the Owner.
Step 3: Determine if the Developer took into account all relevant
functional issues.
Step 4: Write up all results in a Testing Comment on the Tracker.
Step 5: If the solution requires rework, assign back to the
Developer with Groupstatus "In Process".
Step 6: If all is well, state so in the comment and assign to
Developer with Groupstatus "Deliver".
ADDITIONAL RESOURCES:
Consideration for this Process:
==Activity 10: Deliver Solution==
===Task 1: Export solution to SourceForce download===
Responsibility: Developer
Guideline:
PURPOSE:
* Export the solution to the Web.
PRE-CONDITIONS:
* The Domain Owner has reviewed the solution and approved.
* The Developer has fixed anything requested by the Domain Owner.
* If necessary, a follow-up review was done (if the solution failed
a previous review)
EXPECTATIONS:
* None
DELIVERABLES:
* Exported solution.
WORK INSTRUCTIONS:
Step 1: Export the modified program.
ADDITIONAL RESOURCES:
Consideration for this Process:
===Task 2: Set tracker in Solved and Closed status===
Responsibility: Developer
Guideline:
PURPOSE:
* Complete Delivery Process by solving defect.
PRE-CONDITIONS:
* Tracker has Groupstatus "Deliver"
EXPECTATIONS:
* None
DELIVERABLES:
* Tracker is set to "Solved" and "Closed".
WORK INSTRUCTIONS:
Step 1: Review Solution comment one final time. Make sure that:
Step 2: If the solution contains a new generic correction program,
contact person_x.
Person_x maintains the list of generic correction programs.
Step 3: Set Groupstatus of the Tracker to "Solved".
Step 4: Set the Status of the Tracker to "Closed".
ADDITIONAL RESOURCES:
Consideration for this Process:
------------------------------------------------------------------------
Met vriendelijke groet,
*Veritos - Open Source Business Solutions
Jan Verlaan CPIM*
Follow ups
