All Processes

NB: Not all processes are translated and transferred from the old wiki - this work is in progress and will primarily be taken from the Current Methodology (not open).

There are two types of processes:

• the main processes that themselves consist of processes. An example is Tracker Issue Life-Cycle which contains all processes related to tracker issues like bugs, feature requests and patches.

• processes that describe methods, input and output for for example Creation of a Tracker Issue like a bug, a feature request or a patch.

edit

The overall steering process is presented in diagramatical form where squares denotes processes (main processes are denoted by double square) and the responsible role is indicated with a small drawing. The diagrams are accompanied with a table with links to the referred processes and roles.

edit

TODO: Translate http://kb-prod-udv-001.kb.dk/twiki/bin/view/Netarkiv/IBmetodikDec2006SOplaegHovedopgaver

The administrative iteration creation process contains Description, Purpose, Responsible, Method, Time, Input and Output.

Description

Purpose

Responsible
Project Leader

Method
In cooperation with Quality Assurance Coordinator

Time
Before each Steering Committee meeting

Input

Output

edit

TODO: Translate http://kb-prod-udv-001.kb.dk/twiki/bin/view/Netarkiv/IBmetodikDec2006Strategi

The Strategy process contains Description, Purpose, Responsible, Method, Time, Input and Output.

Description

Purpose

Responsible
Steering Committee

Method

Time
At each Steering Committee meeting

Input

Output

edit

The iteration life cycle processes are split into three parts: the Preparation of the Iteration, the the Iteration itself and the the Follow-Up of the Iteration. The preparation and the follow-up can overlap with other iterations, while the iteration itself cannot overlap with other iterations.

Each part is presented in diagramatical form where squares denotes processes (main processes are denoted by double square) and the responsible role is indicated with a small drawing. The diagrams are accompanied with a table with links to the referred processes and roles.

Iteration Preparation
Iteration preparation aims at defining and document contents as well as ensuring a common understanding.

Iteration
The iteration itself consist of implementation of panned activities along with continously evaluation of new tracker issues.

Iteration Follow-Up
Follow-up consist of installation and review which are parallel independent processes.

edit

TODO: Translate http://kb-prod-udv-001.kb.dk/twiki/bin/view/Netarkiv/IBmetodikDec2006SIterationWikiSide

The administrative iteration creation process contains Description, Purpose, Responsible, Method, Time, Input and Output.

Description

Purpose

Responsible
Internal Administrator

Method

• Create Iteration page on bases of template IterationTemplate

• Create Iteration Review Overview on basis of template IterationReviewsOverviewTemplate

  • Create new page named according to the Iteration name formed from the iteration number as follows:

  • "Iteration" + <Iteration number> + "ReviewsOverview" for example Iteration36ReviewsOverview for review overview in Iteration 36

  • Copy the text from the template in edit mode
  • Insert the template it into the new review page and adjust it

• Create Iteration Task List on basis of template IterationTaskListTemplate

• Insert link to new iteration, and update link to current iteration link on Development page.

Time
In end of previous iteration.

Input

Output

edit

TODO: Translate http://kb-prod-udv-001.kb.dk/twiki/bin/view/Netarkiv/IBmetodikDec2006SOplaegOpgaver

The task definitions process contains Description, Purpose, Responsible, Method, Time, Input and Output.

Description

Purpose

Responsible
Project Leader

Method

Time
In end of previous iteration.

Input

Output

edit

TODO: Translate http://kb-prod-udv-001.kb.dk/twiki/bin/view/Netarkiv/IBmetodikDec2006SOplaeg (split between Prioritization and Bugs Suggestion).

The Bugs suggestion process contains Description, Purpose, Responsible, Method, Time, Input and Output.

Description

Purpose

Responsible
Quality Assurance Coordinator

Method
In Cooperation with Operation Manager.

Time
In end of previous iteration.

Input
* Prioritization * Strategy

Output

edit

TODO: Translate http://kb-prod-udv-001.kb.dk/twiki/bin/view/Netarkiv/IBmetodikDec2006SOplaegOpgaveliste

The task lists suggestion process contains Description, Purpose, Responsible, Method, Time, Input and Output.

Description

Purpose

Responsible
Project Leader

Method

Time
In end of previous iteration.

Input
Input for tasks to be included is taken from:

• from process Prioritization

• from process Strategy

Output

edit

TODO: Translate http://kb-prod-udv-001.kb.dk/twiki/bin/view/Netarkiv/IBmetodikDec2006SQuestionReleaseKandidat

The decide release type process contains Description, Purpose, Responsible, Method, Time, Input and Output.

Description

Purpose

Responsible
Project Leader

Method

Time
Close to end of previous iteration.

Input

Output

edit

TODO: Translate http://kb-prod-udv-001.kb.dk/twiki/bin/view/Netarkiv/IBmetodikDec2006SConcensus

The Common Understanding process contains Description, Purpose, Responsible, Method, Time, Input and Output.

Description

Purpose

Responsible
Project Leader

Method

Time
Close to end of previous iteration.

Input

Output

edit

TODO: Translate http://kb-prod-udv-001.kb.dk/twiki/bin/view/Netarkiv/IBmetodikDec2006SFordeling

The Task Distribution contains Description, Purpose, Responsible, Method, Time, Input and Output.

Description

Purpose

Responsible
Project Leader

Method

Time
Close to end of previous iteration.

Input

Output

edit

The Evaluation of a Tracker Issue process contains Description, Purpose, Responsible, Method, Time, Input and Output.

Description
To have new tracker issues evaluated adn possibly fixed as quick as possible When a tracker issue is created and assigned a module, it must be evaluated and possibly handled by the Module Owner. Further more tracker issue that needs additional information must be followed up.

Purpose
To have new tracker issues evaluated adn possibly fixed as quick as possible

Responsible
Module Owner. Please refer to Staffing for overview of modules, owners and backups.

Method
Overview of tracker issue fields can be found on Tracker Issue Field Description

1. Find tracker issues for module via the trackers in GForge

2. Check if the tracker issue is assigned to the right module.
3. If the tracker issue shoud be assigned to another known module do following
   1. Change the 'Module' field to what seems the right module
   2. Change the 'Assigned To' field to the owner of this module.
   3. If appropriate make a comment on the reason of the change in the 'OR Attach A Comment' field.
4. If the tracker issue shoud be assigned to another NOT known module do following
   1. Change the 'Module' field to "None"

   2. Change the 'Assigned To' field to the name of the QA Coordinator.

   3. If appropriate make a comment on the reason of the change in the 'OR Attach A Comment' field.

Only proceed with issues for actual module

1. Set priority according to how important the tracker issue seem to be.

2. If the priority is set to the highest priority (5) then contact QA Coordinator who will take action according to the Prioritization process.

Only proceed with issues with priority is less than 5

1. If we currently do NOT have a code freeze at evaluation time
   1. If there is an easy solution to fix the tracker issue (guideline maximum 1 md.):
      1. Set the 'Status' field to "In Progress"

      2. Follow the Implementation process

   2. If there are a need for additional information before evaluation can be completed:
      1. Sent request for nedded information
      2. Set the 'Status' field to "Need Info"
      3. Write information about request of information in the 'OR Attach A Comment' field
   3. If there is a little more complex solution to fix the tracker issue:
      1. Make a description of how the tracker issue should be fixed in the 'OR Attach A Comment' field
      2. Write and estimate (with uncertaincy description if appropriate) of the fix in the 'OR Attach A Comment' field
   4. If the solution is complex:
      1. Make a description of creation of an assignement in the 'OR Attach A Comment' field
      2. Write and estimate (with uncertaincy description if appropriate) of the creation of such an assignment in the 'OR Attach A Comment' field
   5. Set the 'Status' field to "Evaluated"
2. If we currently DO have a code freeze at evaluation time
   1. Evaluate if the tracker issue should be fixed before release.
   2. If it should be fixed before release then

      1. Contact QA Coordinator and Test Coordinator.

   3. If it should NOT be fixed before release then
      1. Evaluate the tracker issue after codefreeze

Time
Every time a new tracker issue is created.

The reaction time on evaluation of a tracker issue should be no more than a week.

All tracker issues must be evaluated or fixed before Code Freeze.

Input
Tracker issue

• that has been assigned to a specific module (set by creater of issue or in the Monitoring Trackers process)

• that awaits additional information before evaluation can be completed

Output
Evaluated or fix in progress of tracker issue

edit

TODO: Translate http://kb-prod-udv-001.kb.dk/twiki/bin/view/Netarkiv/IBmetodikDec2006SOplaeg (split between Prioritization and Bugs Suggestion).

The Prioritization process contains Description, Purpose, Responsible, Method, Time, Input and Output.

Description

Purpose

Responsible
Quality Assurance Coordinator

Method
In Cooperation with Operation Manager.

Must also include following in translated form:

• Ved kritiske produktions bugs kan det være nødvendigt at branche den aktuelle released produktionskode.

Time

Input

Output

edit

The Implementation process contains Description, Purpose, Responsible, Method, Time, Input and Output.

Description
Implementation covers implementation of a bug, a feature request a patch or a task from the current iteration task overview.

This means that implementation can cover anything e.g. code implementation, script implementations, documentation updates, software upgrades etc.

Purpose
To get implementations of high quality ready for release test, release or patch into production.

Responsible
This can either be

• Task holder according to Iteration plan for iterations tasks or

• Module Owner of new tracker issue for that specific module.

Method

1. For tasks: examined and unclear point clarified.

2. Set tracker issue status to "In progress" (Overview of tracker issue fields can be found on Tracker Issue Field Description)

3. Definition of the implementation is to be release tested based predefined success criteria. Involve test coordinator if necessary. For implementation that are not in an iteration task list the test coordinator must be informed in all cases, even though the test is covered by unit tests, since they must be noted in the release test description and release note for the next stabile release.

4. Use development tools, e.g. as suggested in Development Tools Guideline

5. For code, Unit test must be implemented, see unit test guideline

6. Make implementation:
   1. Note: for priority 5 bugs that needs to be patched into production it may be necessary to branch the actual released productions code.

   2. For code use coding guideline

   3. For release documentation use guideline for maintaining documentation

   4. For assignment writing use guideline for assignment writing

   5. For new processes/roles use guideline for new processes

7. Make release test description, involve test coordinator if necessary.

8. Sanity test, i.e. try to execute the described release test for the implemented task

9. Update documentation and note in the current iteration review overview if any release documentation (e.g. manuals) are affected

10. Review work:

    1. For code, make code review on success criteria and the unit tested, sanity tested code with updated documentation

    2. For documentation, make document review on success criteria and updated documentation

    3. For other, make review inspired by document review

11. Release test description is accepted by test coordinator

12. Set tracker issue status to "Fixed". Always write a comment describing you fix, and the relevant commit SVN revisions. (Overview of tracker issue fields can be found on Tracker Issue Field Description)

Time

• After iteration has been started and tasks distributed by project leader

• Before code freeze within the iteration

Input
This can either be

• A task from current iteration task overview or

• A tracker issue that is evaluated to have small implementation time by the Module Owner of new tracker issue for that specific module.

Output

• Release test input to test coordinator (may be that there are none)

• Implemented, sanity checked (if code) and reviewed implementation of task
• Documentation update (if any needed)

edit

The Code Review process covers: Purpose, Responsible, Method (Planning, Review Session, Follow-Up), Time, Input, Output, Background for Code Review process, Resource Usage, Literature

Purpose
We use code reviews to improve correctness and stability of our code. The main purposes of code reviews are traditionally

• to reduce the overall error rate
• to improve productivity

Another equally important effect of code-reviews is

• to distribute information about the code and establish common coding practices

Responsible
This can either be

• Task Holder of implementation task involving code changes. tasks are specified in the current iteration task overview.

• Module Owner for small corrections.

Method
A code review consists of 2 or more persons that read the code and in a structured way identify changes that will improve the overall quality of the code. Unit test are usually not included. Code review is the third phase of implementation (following unit test writing and implementation of the code). It is normally done when the relevant part of the code is fully implemented, i.e. passes all the unit tests, has been sanity tested and documented. Our process for code review contain planning, review session and follow-up as described below.

Planning

1. Review participants are specified in the current iteration task overview. Usually it is the implementor and another developer.

2. The implementor specifies the code to be reviewed in Crucible

   1. Log on to Crucible (http://kb-prod-udv-001.kb.dk:8060). Please refer to Crucible Guidelines for sign-up if you have no account already.

   2. Go to your Crucible DashBoard (using the link "My Crucible DashBoard")

   3. Click on "Create new review" in the top right corner

   4. Select a proper titel (e.g. Feature request Y, og Bug Y plus description). If it corresponds to a task in the current iteration task overview, it should have the same title, as is written there.

   5. Set yourself both as 'moderator', and 'author' (unless code is authored by somebody else).
   6. Write relevant comments in the "Statement of Objects" for instance genral comments to the review and list of deleted file or class names that for obvious reasons cannot be included.
   7. Add the files included in the review. This can be done by selecting files in different changesets. Note that we do not review code in the test-branch.
   8. Add a revision comment to each of the files with specific lines to be review (or ALL LINES). Also note what happened here if relevant e.g. lines that have been removed (fil/class name and revision of file is given automatically by Crucible)

   9. You notify the reviewer of the existence of a review, by clicking "Start Review".
      Note that it is best to make wiki review entry (as explained in the next step) before notification.

3. Make an entry with review information for the review in the wiki current review table. (see for example Review table for iteration 36).

4. The participants agree on a time to review.
5. Before the review time, each participant reads the code thoroughly and note problems - big or small - that should be discussed. Place the comments at the relevant places in Crucible. For instance:

   • Add a new general comment:
     For general problems like design problems or problems concerning most of the files like missing '.' in end of JavaDoc.

   • Add a revision comment:
     For general problems in a specific file like generally missing JavaDoc in this particular file.

   • On specific line (mark line will result in a comment field to appear):
     For problems on specific lines of a file like lack of white space around delimiters.
     REMEMBER to post the comments by clicking "Post" for each of the comments.

Review Session
This part, while central to the whole process, should not be allowed to drag on forever. If the reviewers cannot agree on how to fix a problem within a few minutes, the item should be marked as "consider how to..." rather than prolonging the discussion.

A typical review session should take no more than an hour (and most take less than that). If it takes longer, the review should be stopped and a time to continue should be agreed upon. More than an hour of straight review reduces the efficiency.

1. The participants meet on the phone (only physical meeting if possible)
2. Before starting check that
   1. Code has been unit tested
   2. Code has been sanity tested
   3. Functionality has been document in manuals
   4. If any of these are missing than the Review should be postponed.
3. Use Crucible to go through the review
   1. Log on to Crucible - preferable both reviewers.
   2. Discuss each posted comment in order of appearance.
      • General comments
      • Revision comments
      • Specific line comments

   3. Those items that the participants don't agree to discard are marked by clicking on the "Defect" box which enables selection of rank in the "Select rank" drop-down list. When the Defect and Rank is specified the item is posted by clicking "Post".

   4. Note it is only the author of the comment that can post the comment. If only one of the reviewers have access to Crucible, the non-owned comments must be copied into new comment that can be posted with the mentioned information.

   5. Make a Crucible General Comment on the review and remember to mark the as defect, otherwise rank cannot be selected.

   6. Note the time used for the task in the General comment for the review using following wording:
      Time use (Coding,Documentation,Review)
      <IinitialsOf1Reviewer>: <NoOfManDaysUsed>
      <IinitialsOf2Reviewer>: <NoOfManDaysUsed>
      Remember to set selection of rank in the "Select rank" drop-down list to "Time Used". This is used for the [Iteration review] made in the end of the iteration.

   7. Post the General comment - otherwise this information will not be passed to the wiki afterwards.
   8. Complete the review by clicking "Summarize"
4. Agree to who is doing follow-up in case flaws are found during code review. Usually, this will be the implementor.
5. If there are found faults, you can correct it by clicking "Reopen", do the update and click "Summarize" again.

6. Update the table in the current reviews page with

   • Review date

   • Issues found - using the Crucible export function and insert result on page IssuesFromNsXX where XX is the number in the Crucible review id.

     • Create new Issue page
     • Insert text from the export function
     • save the page

   • Follow-up - initials of person decided to do the follow-up.

Follow-up

1. The follow-up person goes through the list of items and handles each of them. Depending on how an item is dealt with, the item is marked as either OK, REJECTED or POSTPONED under "Status" on the Issue page (reached via current reviews. When committing the follow-up changes, please refer to the review identifier (NS-XX) in the commit comments like this:  Follow-up after review NS-XX  

2. The follow-up person fills out the DONE column for the review on the current reviews page once all items have been handled. If some items are marked POSTPONED, the review is marked OK-wp. Otherwise it is just marked OK.

3. If the implementor feels the changes are significant enough to require a new review, another review cycle starts. The first review is left as-is. This rarely happens, and should only happen when design issues have been identified and resolved during the review process.

Time
The input must be review as soon after actual code implementation as possible. In case of changes in code, it cannot be passed to quality assurance (before release test) before it has been reviewed.

Input
The input is code implementing of a Tracker Issue which have been

• unit tested
• sanity tested
• documented in manuals

Output
Reviewed and followed-up input, ready for quality assurance before it can be marked as ready for release test.

Background for Code Review process
The code review process was inspired by NASA's ideas for code inspection. The process has however been simplified in order to ease the transition to inspection. As the project group gains experience with inspection it is recommended that the inspection process is refined. The description focuses on code-inspection.

Resource Usage
Code review takes time, of course. The actual time spent discussing the code is typically roughly the same as is spent going over the code beforehand. Follow-up can take a varying amount of time, depending on the starting quality of the code and whether significant changes have been found necessary. Some kinds of code take longer to review than others, for instance straight-forward getter-and-setter style classes go very fast, while a review of a few lines of change in a complex method can take much longer. In the start of the NetarchiveSuite project, we kept track of the time spent preparing for and executing the review (but not doing the follow-up changes to the code). The ratio of preparation time to review time varied, but there was never more than a factor 2 difference to either side, on average the two were about the same. The number of lines of code reviewed per hour (LoC/h) varied from 88 to 300, with a mean and average value of about 170 LoC/h. Later code review times were not recorded, but is likely to be slightly faster due to a better system for taking notes.

Literature

• NASA's ideas for code inspection

• Steve McConnell, Rapid Development. Taming Wild Software Schedules. Microsoft Press, 1996, page 73-74

edit

The Document Review process covers: Purpose, Responsible, Method (Planning, Review Session, Follow-Up), Time, Input, Output

Purpose
We use document reviews to improve correctness of documentation.

Responsible
This can either be

• Task Holder of implementation task doing or correcting document or script. Tasks are specified in the current iteration task overview.

• Module Owner for Documentation module for small corrections.

Method
A document review consists of 2 or more persons that read the document/script/assignment and in a structured way identify changes that will improve it. Our process for document review contain planning, review session and follow-up as described below.

Planning

1. Review participants are specified in the current Iteration task list. Usually it is the implementor and another developer.

2. The implementor specifies the document (parts) to be reviewed in a new row in the document review table on the current Iteration review overview (the meaning of the different columns are also described in the end of iteration review page):

   1. "Document": Link to issue review page for document named with identification of the document, e.g. http://netarchive.dk/suite/AssignmentDeploy1 - See example in Iteration 36. A new review is inserted in the top of the page in order always to see newest review text first.

   2. If the document review page do not already exist, make a new Document Review page on basis of template ReviewDocumentPageTemplate:

      1. Create new page named according to the document name as follows:

      2. !DocumentReview/<Unique name for document> + "Review"

      3. where each part of the name starts by upper case and continuous in lower case (as WikiWords), for example DocumentReview/NetarchiveSuiteInstallationManualReview for review of the New version of installation manual

      4. Copy the text from the template in edit mode
      5. Insert the template it into the new review page and adjust it
      6. If an old review page exists on another media/wiki then this link should be referenced.

   3. Version: The SVN, CVS or date for revision of document/script to be reviewed.

   4. Parts/lines: Specifies the parts/section/lines of the document/script to review (if less than the whole file).

   5. Task: The assignment or tracker issue that the code has been updated for, e.g. Bug 1512.

   6. `Author(s)": The person(s) who have made changes or additions to the code. Only Initials are given, e.g. ELZI.

   7. ~+`Reviewer(s)": The person(s) who have not been involved in changes, who will participate in the review. If the task is in the Iteration task list the reviewer is suggested with the task in this task list.

3. The participants agree on a time to review, this date is noted under "Review date" on the document review entry on the Iteration review overview page

4. Before the review time, each participant reads the document thoroughly and note problems - big or small - that should be discussed. These can be written into the document review page (e.g. DocumentReview/NetarchiveSuiteDeveloperManualReview), or entered during the review as described below.

Review Session
This part, while central to the whole process, should not be allowed to drag on forever. If the reviewers cannot agree on how to fix a problem within a few minutes, the item should be marked as "consider how to..." rather than prolonging the discussion.

A typical review session should take no more than an hour (and most take less than that). If it takes longer, the review should be stopped and a time to continue should be agreed upon. More than an hour of straight review reduces the efficiency.

1. The participants meet on the phone (only physical meeting if possible)

2. Note ~+Time use (Documentation,Review) in the header, given in number of person days used.

3. Discuss each comment in order of appearance in the document. Those items that the participants don't agree to discard are marked with status "rejected".

4. Fill in severity, and in case thios is "major" or "showstopper" a tracker issue must be reported as well.

5. Agree to who is doing follow-up in case flaws are found during code review. Usually, this will be the implementor.

6. Update the table in the current Iteration review overview in the entry for the actual review:

   • Review date

   • Follow-up - initials of person decided to do the follow-up.

Follow-up

1. The follow-up person goes through the list of items and handles each of them. Depending on how an item is handled, the item is marked under Status on the document review page.

2. The follow-up person mark the file as fully reviewed on the Iteration review overview in the entry for the actual review, once all items have been handled.

3. If the implementor feels the changes are significant enough to require a new review, another review cycle starts. The first review is left as-is. This rarely happens, and should only happen when design issues have been identified and resolved during the review process.

Time
The input must be review as soon after actual update or creation of documentation as possible.

Input
Usually the input is implementing a Tracker Issue for documentation, but it could also be script or an assignment.

Output
Reviewed and followed-up input, ready for release test or release.

Background for Document Review process
The document review process is inspired by the code review process.

edit

Translate "At checke at vores kodemodel overholdes, det vil sige at der skrives unit tests før kode, og at kode reviewes før code freeze" part of http://kb-prod-udv-001.kb.dk/twiki/bin/view/Netarkiv/KvalitetssikringRollen

The Quality Assurance of Implementation process contains Description, Purpose, Responsible, Method, Time, Input and Output.

Description

Purpose

Responsible
Quality Assurance Coordinator

Method

Time

• After status of tracker issues ralted to implementation has status set to "Finished".

• Before code freeze within the iteration.

Input

Output

edit

The Prepare Release Test process contains Description, Purpose, Responsible, Method, Time, Input and Output.

Description

• the overall preparation is continuously defined and implemented
• setting the exact successcriteria together with the developers for each implementation task
• preparing the release test description, data and platform for the releasetest

Purpose

• a reliable releasetest for all changes made in the actual iteration
• a releasetest ready for execution just after the last iteration task is finished

Responsible

• Test Coordinator

Method

During the implementation of the iteration following task need to be done or verified by a proactive Testcoordinator:

• The creation of the Wiki test release page happens soon after the start of the iteration.
• The Test Coordinator will work together with the developer to decide who is responsible for implementing the releasetest
• Before the implementation of a task the deleloper defines how the release test can be implemented. Unit tests may be sufficient testing so that a proper release test is not necessary.
  • Accepted by the test coordinator
• The tests covers the need for each iteration. By development iterations - not production releases - the test focus is only on the code areas, that may be affected by the changes.
• That documentation will be verified.
• That each release test is checked as far as possible before the start of the release test
• That there is clean up of the releasetest page for old test cases and and bug test items.
• That the time for preparation and execution of the releasetest is fair.
• That the platform has sufficient capacity (disk space platforms ..)
• That each test ready for execution is spread out to different testpeople

Time

• After the iteration has been started and tasks distributed by project leader

• Before code freeze within the iteration

Input

• Component owners are responsible for testdata and sanity checks and for providing the test coordinator with a list of bugs fixes and a sanity check descriptions

Output

• a reliable releasetest - just in time

edit

TODO: Translate http://kb-prod-udv-001.kb.dk/twiki/bin/view/Netarkiv/IBmetodikDec2006SCodeFreeze and "At iværksætte codefreeze og holde øje med at den overholdes" part of http://kb-prod-udv-001.kb.dk/twiki/bin/view/Netarkiv/KvalitetssikringRollen

The Start Code Freeze process contains Description, Purpose, Responsible, Method, Time, Input and Output.

Description

Purpose

Responsible
Quality Assurance Coordinator

Method

Time

Input

Output

edit

The Release Test process contains Description, Purpose, Responsible, Method, Time, Input and Output.

Description

It is the Testcoodinator's responsibility to coordinate the given manpower for the releasetest and support the different testusers in fullfilling the testcases.

Purpose

A reliable release ready for accept test. The quality of the release is decided by the QA-role and Project-leader.

Responsible

• Test Coordinator

Method

Testing and reviewing all releasetestcases and documentation described on the releasetest twiki page. All cases must be tested/reviewed.

Time

The process starts when code freeze is established and stops when all test cases and documentation reviews are ended without any "blockers"

Input

The prepared releasetest.

Output

The release of tested code and documentation.

edit

TODO: Translate http://kb-prod-udv-001.kb.dk/twiki/bin/view/Netarkiv/IBmetodikDec2006SReleaseOfCodeFreeze and see also "At iværksætte codefreeze og holde øje med at den overholdes" part of http://kb-prod-udv-001.kb.dk/twiki/bin/view/Netarkiv/KvalitetssikringRollen

The Stop Code Freeze process contains Description, Purpose, Responsible, Method, Time, Input and Output.

Description

Purpose

Responsible
Quality Assurance Coordinator

Method

Time

Input

Output

edit

TODO: Translate http://kb-prod-udv-001.kb.dk/twiki/bin/view/Netarkiv/IBmetodikDec2006SReleaseProduktionskode and "At lave releases, og sikre at release notes laves" part of http://kb-prod-udv-001.kb.dk/twiki/bin/view/Netarkiv/KvalitetssikringRollen

The Release process contains Description, Purpose, Responsible, Method, Time, Input and Output.

Description
Distinguish between Development Release and Stable Release

Purpose

Responsible
Quality Assurance Coordinator

Method
Remember

• document update on NetarchiveSuite wiki

• update of news on NetarchiveSuite wiki

Time

Input

Output

edit

TODO: Translate http://kb-prod-udv-001.kb.dk/twiki/bin/view/Netarkiv/IBmetodikDec2006SAcceptTest

The Accept Test process contains Description, Purpose, Responsible, Method, Time, Input and Output.

Description

Purpose

Responsible
Operation Manager

Method

Time

Input

Output

edit

TODO: Translate http://kb-prod-udv-001.kb.dk/twiki/bin/view/Netarkiv/IBmetodikDec2006SReviewIteration

The Iteration Review process contains Description, Purpose, Responsible, Method, Time, Input and Output.

Description

Purpose

Responsible
Project Leader

Method

Time
Shortly after iteration has been finished, all though accept test does not necessarily need to be finished.

Input

Output

edit

The Process Update process contains Description, Purpose, Responsible, Method, Time, Input and Output.

Description

Purpose

Responsible
For existing processes, the responsibility is with the the role responsible for the process.

If it is a main process or additions, the reposibility lies with the Documentation Coordinator.

Method

Time
After Iteration Review.

Input
Minutes of Iteration Review

Output
Updated processes and possibly tracker issues concerning bigger changes.

edit

TODO: Translate http://kb-prod-udv-001.kb.dk/twiki/bin/view/Netarkiv/IBmetodikDec2006SInstallation

The Installation process contains Description, Purpose, Responsible, Method, Time, Input and Output.

Description

Purpose

Responsible
Operation Manager

Method

Time
Time defined by operation manager after accept test.

Input

Output

edit

The tracker issue life cycle processes for bugs, feature requests and patches contains Life-Cycle, Monitoring. Each part is presented in diagramatical form where squares denotes processes and the responsible role is indicated with a small drawing. The diagrams are accompanied with a table with links to the referred processes and roles.

Life-Cycle
Below you find a diagram of the tracker issue life-cycle, followed by references to processes and roles.

Monitoring
Below you find a diagram of the tracker issue monitoring followed by references to processes and roles.

edit

The Creation of a Tracker Issue process contains Description, Purpose, Responsible, Method, Time, Input and Output.

Description
Anyone with access to the internet can create a Tracker Issue in form of a Bug, a Feature Request or a Patch.

It is important to give enough information when the tracker issue is created. Some information is hard to complement a Tracker Issue later. This is due to the way that GForge works, and therefore not in our power to change.

Purpose
To make a formal report of a tracker issue (bug, feature request or patch) in a way that enables tracking of the life-cycle of the issue.

Responsible
Anybody

Method

• Classify your issueas a bg, feature request or a patch, i.e. find the 'Data Type' of your Tracker (bug, feature request or patch, see 'Data Type' for further description)

• Go to tracker issue in NetarchiveSuite GForge matching your issue classification (bugs, feature request, patch) and click 'Submit New'.

• Fill in the fields (described under Fields for different Tracker Issues marked with "new").
  Most importantly are the fields:

  • Summary

  • Detailed description:

    • remember to include name of reporting person, in case you are not a user in the system.

    • remember to include version, if it does not exist in the drop down list for the 'Version'

  • Attach Files - where

    • in case of a bug, logs must be attached (please refer to Hints to Where to Find Log-files)
      If you forgot to attach files at creation, it is only possible for internal users to attached them afterwards. External users will have to send them to the developer group via mail.

    • in case of a patch, files with diffs/additions must be attached

  • Version

• If known it is desireble if the fields 'Assigned To', 'Module' are set.
  Fileds like 'Priority', 'Status' and 'Duplicate Of' will rarely be set at creation time.

• Click 'Submit New'

Time
Any time

Input
Any issue to be reported as a bug, a feature request of a patch.

Output
A new Tracker issue registered in the NetarchiveSuite GForge tracker system.

edit

The Collection of Needed Information process contains Description, Purpose, Responsible, Method, Time, Input and Output.

Description

Purpose

Responsible
Module Owner. Please refer to Staffing for overview of modules, owners and backups.

Method

Time

Input

Output

edit

Translate "At holde styr på vores bugliste" part of http://kb-prod-udv-001.kb.dk/twiki/bin/view/Netarkiv/KvalitetssikringRollen

The Monitoring Tracker Issues process contains Description, Purpose, Responsible, Method, Time, Input and Output.

Description

Purpose

Responsible
Quality Assurance Coordinator

Method
Must also include following in translated form:

• QA via automatisk mail fra bugzilla for assigning af nye bugs, samt at evt. bugsløsning følger de sædvanlige procedurer.

Time

Input

Output