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