COM674 Project And Process Management

COM674 Project and Process Management
Question
Answered

Questions:
For this assignment you are required to work individually. 
When submitting your assignment you are agreeing to the following statement:
I declare that this is all my own work and does not contain unreferenced material copied from any other source. I have read the University’s policy on plagiarism and understand the definition of plagiarism. If it is shown that material has been plagiarised, or I have otherwise attempted to obtain an unfair advantage for myself or others, I understand that I may face sanctions in accordance with the policies and procedures of the University. A mark of zero may be awarded and the reason for that mark will be recorded on my file.
 
Refer to the process description called ‘Outline Peer Review Process’ contained in Appendix A and supporting description in Appendix B. 
For this process, analyse each of its 16 components (numbered 1-16, ignoring the ‘Complete’ component) against CMMI V1.3 and identify the process areas and specific practices, which relate to each of these components. Give some justification for each process area/specific practice you identify. NOTE: you should restrict your analysis of the CMMI to the following sub-set of process areas: PP, PMC, PPQA, CM, MA, ReqM, TS, VER, DAR, RskM, OPF, OPD and CAR.
 
Hand In Instructions:
This assignment should be completed individually. 
The assignment solution is to be submitted electronically to Blackboard on or before noon on Monday 1st November 2021. 
Please ensure that you keep a secure backup electronic copy of your assignment.
Please ensure you take a screenshot of/print to pdf your TurnItIn/Blackboard submission receipt.  

Marks:

Description

Marks

Mapping of CMMI PAs/SPs to supplied process components.

60%. (i.e. between 2-6 marks each for the 15 components in the supplied process flow chart – varies since some components touch on more specific practices than others).

Justifications for the mappings

40%. (2-4 marks per component varying according to the significance of each component).

Marking Guide for assessment of coursework #1 (indicative thresholds):

70+

60-69

50-59

40-49

0-39

· Analysis of components against benchmark model is very accurate and comprehensive

· Benchmarking model very well understood

· Comprehensive justifications given for each ascribed specific practice against process components

· Analysis of components against benchmark model is clear and reasonably complete

· Benchmarking model well understood

· justifications given for each ascribed specific practice against process components

· Analysis of components against benchmark model is clear in places, but there may be some missing specific practices

· Benchmarking model is reasonably well understood

· Reasonable justifications given for some of the ascribed specific practice against process components

· Analysis of components against benchmark model displays many gaps or too little discrimination when ascribing specific practices to components

· Benchmarking model not well understood

· justifications for ascribed specific practice against process components either missing or not well described.

· Analysis of components against benchmark model displays largely missing

· Benchmarking model poorly understood

· justifications for ascribed specific practice against process components mostly either missing or not well described.

Appendix B – ‘Outline Peer Review Process’ Supporting Description
 
The following text provides a narrative for the Outline Peer Review Process and is intended to help with understanding the detail within this process. It refers to the activities, records and sub-processes contained in the Peer Review Process using the process component numbers as indicated on the flowchart.
 
This process begins when a member of the development team has completed their work resulting in a work-product that needs to be checked for correctness, completeness and consistency within the overall project before being approved. 
1. Moderator Sends Review Invitations
Someone associated with the project is assigned the role of ‘moderator’. This person is responsible for deciding who should be invited to participate in the review of the work-product. People invited will review the work-product from different points of view. For example, other team members may review the work product for completeness and consistency with other work-products from this project. A quality assurance representative may review the product for adherence with the company’s in-house standards. A project manager may review the work product from the viewpoint of its suitability for distribution to a customer, for example.
 
2. Reviewers Prepare for Review Meeting
All those who were invited to, and have agreed to participate in the review, are given sufficient time to read/review the work product prior to the actual meeting. It is likely they will produce their own sets of comments and questions for discussion during the review meeting.
 
3. Work Product for Review
This is the actual work product that is the subject of the review. It may be a requirements specification, a test plan, a project plan, a set of source code files, etc. 
 
4. Organisation’s standards/guidelines/templates for that type of work product.
Some reviewers will be guided by in-house standards that all such work-products are expected to adhere to. For example, there may be a set of coding standards that source code must adhere to. Comparing the source code to these standards will help identify any opportunities for improvement prior to the approval of the source code.

5. Everyone Ready?
It is important that all participants are given adequate time to study the work product and produce their set of comments and questions.
 
6. Present Work Product
The author of the work-product must provide an overview of their work. This helps guide the reviewers by providing some context and provides an introduction to the review meeting.
 
7. Conduct Review
The actual review meeting is conducted. This may be a physical face-to-face meeting of all involved parties around a table, or it may be conducted remotely via Skype or Teams, for example.
 
8. Issue Tracking System Database
As the review meeting progresses, everyone’s comments and questions are tabled and discussed. Where genuine issues/problems are identified, these are recorded and result in a list of actions for the work-product author to complete after the meeting ends. These issues are recorded in a database with target dates for completion and some identification of the originator and who has responsibility for signing-off /verifying that the issue has been satisfactorily completed at some point in time after the end of the review meeting.
 
9. Review Complete
The end of the review is reached when everyone’s concerns/comments/questions have been discussed.
 
10. Review Report
This report will document who attended, what was reviewed, how long the review lasted, together with a list of actions for the work product author to complete after the review meeting concludes.
 
11. Post Review Performance Analysis
Most organisations wish to understand the value they get out of conducting peer reviews. This can be accomplished by analysing the number of minor, medium and serious issues identified from the review and the amount of effort consumed in conducting the review. If many person-days of effort were consumed, costing perhaps many thousands of pounds and only a small set of minor (maybe cosmetic) issues were identified, then perhaps the peer review was a waste of money. Analysis will therefore help determine the value derived from the review session.
 
12. Take Action to analyse and handle issues
All the issues raised in the review must now be corrected. Most will be the responsibility of the work product author, but sometimes other people may also need to get involved in addressing issues raised.
 
13. Need for CCB Decision?
Sometimes issues in one work-product ripple into associated work products and force changes to be made to other (perhaps already approved) work products. If the changes are significant then there may be a need for a Change Control Board (CCB) to convene to approve changes and assess their widespread effects.
 
14. Change Control Board Process
The change control board is a collection of knowledgeable people who can best evaluate the ramifications of changes to existing approved work products on a project. 
 
15. All Issues Addressed?
The work-product author must work down through the list of actions produced from the review meeting. When all have been completed then it it is time to decide if simple sign-off and approval of the work product can be achieved.
 
16. Need for Re-Review?
If many significant changes have been made to the reviewed work-product then there may be a need to set up a re-review of that changed work product and begin the whole process over again.
 

Marking Guide for assessment of coursework #1
(indicative thresholds)

70+

60-69

50-59

40-49

0-39

· Analysis of components against benchmark model is very accurate and comprehensive

· Benchmarking model very well understood

· Comprehensive justifications given for each ascribed specific practice against process components

· Analysis of components against benchmark model is clear and reasonably complete

· Benchmarking model well understood

· justifications given for each ascribed specific practice against process components

· Analysis of components against benchmark model is clear in places, but there may be some missing specific practices

· Benchmarking model is reasonably well understood

· Reasonable justifications given for some of the ascribed specific practice against process components

· Analysis of components against benchmark model displays many gaps or too little discrimination when ascribing specific practices to components

· Benchmarking model not well understood

· justifications for ascribed specific practice against process components either missing or not well described.

· Analysis of components against benchmark model displays largely missing

· Benchmarking model poorly understood

· justifications for ascribed specific practice against process components mostly either missing or not well described.