Sample process definitions for critique.


Select any one of the sample process definitions below and rewrite it so that it conforms to the standard for a formal process definition.


I. Code review process

Meet with the author of the module to review.
Print out a copy of the module source code.
Record start time.
Go through each block of code 3 to 7 lines per block.
Record start time for that block. Bracket the lines in the block.
Restate what the code does to the author.
Ask if that is correct. If it is correct, continue. Otherwise, ask them to explain it to you then repeat.

When you are done with each block add a check mark next to the bracket.
Record the end time and duration for the block next to it.
Record end time for the module.
Entrance criteria. The module to understand and its author.
Exit criteria. All lines of code are within a bracket and each bracket is checked. Start, end, and duration times are recorded.
Required personnel. Reviewer, module author.
Materials required. Printed copy of module code, pencil, clock.
Metrics produced. Time to understand by block, and total time to understand.


II. Developer task tracking process.

Purpose: to provide a consistent and highly visible means to track binary milestones, developer workload, and project status.

Entry criteria: a task in mind with a clear defined and measurable metric to judge the task complete or incomplete.
Exit criteria: a completed task and useful metrics such as completion time.
Directions:
1. Manager: create a ticket for the task including due date who the task is for, a clear and concise description, and the metric by which the task will be considered done.
2. Developer: Mark the ticket has accepted or ask for clarification reassigning to manager with question then accept the ticket when clarified.
3. Developer: complete task by fulfilling the metric that makes the task done.
4. Developer: change ticket status to"works for me"and reassigned to manager.
5. Manager: verify task is completed to the metric specified if so close take it. If task is not actually complete change ticket to"in progress"and reassigned to developer with description of why task is not done. Go to step two.
Resources: trac
constraints: binary milestones only. Multipart tasks must be broken into binary tasks for this process.
Output: completed trac ticket.



III. Code review process.
Entry criteria: completed unit code for module.
Preparation: create a review ticket and attach the unit code to the ticket. Assign the ticket to the quality assurance manager.
Directions: quality assurance manager copies ticket to any other relevant team members and accepts ticket. Relevant people review code and write comments in the description box, and reassign ticket to module owner.
If there are changes to be made, module owner will make them in and reassign ticket to the quality assurance manager for follow-up review.
Exit criteria: the module is except that it is ready for integration. The ticket can be closed and marked as done.




IV. Change control procedure.
1. Identify the desired change.
1.5. Verify no other documents or changes address this issue.
2. Document the scope of the change. Indicate what classes, interfaces, etc. the changes.
3. Identify stakeholders.
4. Send a change request to stakeholders.
5. If approved, inform implementers, and implement change.
6. Inform the rest of the group through the change summary log sent weekly and full documentation available on the change control website.




V. Formal status meeting process.
Directions1. Have one person run this meeting at the start of every lab.
2 make sure everyone is prepared for the meeting and not distracted.
3. For each of the following categories give each team member a chance to speak:
accomplishments. What action items or other tasks were completed since the last meeting.
Unfinished tasks. What is still being worked on. Not necessarily late.
Problems. Report any problems that were revealed. Do not discuss problems too much, this meeting is just to report status.
4. Next assign tasks that were scheduled to start today in any tasks brought up in the discussion.
5. Update the schedule if needed.
Notes: remember the purpose of this meeting is to bring everyone to the same page not to solve problems immediately.
This should not be the first time anyone has heard of a problem, but it may be the first time some group members here it.




VI. Design change control process.
1. You need to add, modify, remove, the method signature or a class.
2. Fill out the formal change request form with detailed information about proposed change in potential project impacts then e-mail to group alias.
3. Designer, change manager, and the group at large respond with feedback if necessary.
4. Change manager decides after a reasonable amount of dialogue to improve or deny the request.
5. If request is not approved and further discussions as required bring a change request at the team meeting.




VII. Customer meeting process.
First we had to make an appointment with him or make sure he was available. Then the analysts would meet with the manager and they would discuss what the analysts should show the customer. Next the analyst would meet with the customer and show him the product and anything else decided on earlier. The analyst records the customers input and preferred changes. Once the customer leaves the analyst assigns priorities to the changes and e-mails them to the team. The team then responds with what they can or can't do in the time available. The analyst notifies the customer of the things the team doesn't have time for and tries to come up with a compromise. Make the changes and show the customer again using the same process.




VIII. Meeting log process.
Purpose: document what happens at a team meeting.
Output: a written log that can be referenced at later dates.
Directions: team members should take turns leading and logging meetings. They should record who was present and who is missing at the meeting. Next they should log what team members have accomplished since the last meeting and what needs to be accomplished for the next one. Finally they should log any problems encountered since the last meeting and assign tasks to specific team members. The log should be saved and made available online for easy access.


IX. Task tracking process.
Purpose passed tracking is the use of task tickets to define an artifact to be produced, the owner of the task, when the task is due, and what the task relates to such that an individual knows what he or she needs to do at any given time.
Directions:
1. Create a new ticket.
2. Write a condensed description of the task to be performed.
3. Write a detailed description of all needed information for the task to be completed.
4. Assign the task at due time and date.
5. Assign the task of priority.
6. Assign the task stage.
7. Assign the task and owner.
The owner must then accept the ticket to verify that they have read it and agree to perform it.




X. Design process.
Purpose: to create a software design for a desired application.
Directions:
1. Create a structure of classes such as a UML diagram showing relationships training classes. This allows your team to visualize how the product will come together.
2. Create stub classes based on the diagram and make sure it compiles. Great classes with no and local variables constructor headers and method headers and the Javadoc comments only.
3. Write pseudocode. Do not write any actual code yet. Instead, explain the underlying implementation with comments. The project will really start to take shape here, showing you which classes will need the most work based on lines of code. You may realize some changes to design are necessary at this point. This is good because it saves you time later after code has been written.


XI. Coding standard process.
Purpose using a coding standard help standardize the code the team wrote making it easier to read and maintain.
Entry criteria: an agreed-upon coding standard. Checkstyle installed. Coding standard configuration for checkstyle.
Directions: run checkstyle after writing code to ensure it follows the coding standards.
Exit criteria:checkstyle passes with no errors.
Output: the daily report the passing checkstyle output