Com646 Process Management Assessment Answer

Question:

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 ‘Release Outline Process’ contained in Appendix A and the accompanying textual description of this process given in Appendix B. With reference to either the CMMI or any other published literature on software release processes, complete the following steps:

1. Suggest (with some justification based on what you have read) a proposed change to the process depicted in Appendix A, with a view to optimising it.

2. If the change requires additional process steps then explain these carefully.

3. State any assumptions you make with respect to the process provided in Appendix A leading to your suggestion.

4. For this identified change, indicate an improvement goal that this change might be associated with, and using the Goal-Question-Metric approach of Basili, develop some questions and at least one metric that could be used to determine if the change you suggested was actually leading to an ‘improvement’.

5. Document your proposed change using the CMMI M&A process area’s four specific practices for specific goal 1.

6. Reflect on how the work you have completed in stages 1-5 above fits with the five principal stages of the Six Sigma DMAIC model.

7. Ensure that you properly reference published source(s) for the refinement/improvement goal you propose.

The following text provides a narrative for the Release Process and is intended to help with understanding the detail within this process. It refers to the activities, records and subprocesses contained in the Release Process using the process component numbers as indicated on the Release Process flowchart.

This overall process begins when the development team has completed their work. The software has been developed and unit and integration testing will already have been executed, by the development team, in order to get the overall product into a good shape for final system testing prior to its release to the customer. The Release Process therefore begins with a ‘code-freeze’ so that system testing can be completed on a fixed system, without fear of ending up testing an ‘out of date’ product. While the release process is ongoing, no further development work can proceed.

1. Perform Testing

This sub-process will involve creating suitable conditions to mimic the customer’s intended use and executing the test plans, which will detail all the test cases required to be passed.

2. Requirements Specification The requirements specification is a feed into the testing sub-process because the testers may need to refer to the original requirements while they perform the tests, in order to clarify any points of detail that may be missing from the test plans.

3. Test Plan This is the set of test cases that the testers must execute.

4. Record Test Results This is the activity of recording the observed behaviour of the software system and comparing that to the expected results as detailed in the test plan. Deviance from the expected results must be recorded.

5. Test Results

This is a document containing the record of the results from executing all the test cases. It will identify the version of the software that was tested.

6. Evaluate Test Results During this activity, the testers will analyse the ‘actual’ versus ‘expected’ test results and

decide whether the tests can be considered as “Passed”, “Failed” or “To be Considered”  which means that a further decision is required after other information has been gathered (see components 7 and 8 to follow).

7. Check Verification Matrix Coverage The test plan referred to in component 3 will have included mappings of test cases onto the requirements (the Verification Matrix), in order to ensure that all requirements have been adequately covered in the test cases to be executed. In activity 7, in the light of the test results, the extent to which the software product meets those requirements is being assessed. This information is also used in the decision taken later (component 9) regarding whether or not the test results are acceptable for a release of the product to be made to the customer at this stage.

8. Check Product Support Documentation

This documentation will include installation and initial setup instructions for the product together with a user manual, contact information and details on the procedure for reporting faults. In this activity, a check will be made to ensure that all necessary documentation has been completed and is to a good standard suitable for release to the customer.

9. Checks and Test Results Acceptable? This is a decision point where the outcomes from activities 6, 7 and 8 will all be considered.

In the real world, it is not always possible to withhold a release simply because some tests do not yield the expected behaviour. The decisions made here will consider known issues from the test results etc and decide if a software release to the customer should proceed at

this time, or should the known issues be feed into a Change Control Board for further action/change/correction.

10. Change Control Board (CCB)

The CCB will have been invoked because some significant issues were discovered during system testing. The CCB needs to address these issues and decide where change is needed to components in the underlying software or associated documentation. This may involve updating the schedule for release.

11. Create Customer Release Baseline If the checks on documentation and software test results are acceptable then a baseline for

customer release will be created. This will identify the versions of every software component and document to be sent to the customer at this stage.

12. Perform Functional and Management Configuration Audits Making releases to a customer is not taken lightly. The perception and reputation of the

development company is on the line here and it is important that everything is in order before a release is made to the customer. In this activity, final checks are made to ensure that the correct versions of everything being released are correctly recorded and that any known “issues” in the system to be released have been documented and already discussed/approved with the customer prior to final release.

13. Is Customer Ready to Receive Product?

This is an important decision. The development company needs to liaise with the customerto ensure that they are ready to receive the release. The contract with the customer willdetail how releases are to be made to the customer and the precise protocol to be followed.

14. Support establishment of Customer environment

The customer will wish to perform ‘due diligence’ on the systems it receives before ever putting these systems into operation. This is part of the hand-over process. The development organisation should work with the customer to assist with the establishment of the necessary environment into which the system is received.

15. RELEASE

When the customer is ready to receive the product release then the hand-over should take place in what way has been detailed in the contract. At this stage, the Release Process is complete for this particular version of eth developed system.