C857 Software Questions and answers. 100% Accurate.

C857 Software Questions and answers. 100% Accurate. CMMI - -as project management, quality management, and engineering all glued together by process management. The CMMI® provides detailed practice descriptions to guide the development of technical processes as well as management processes and service processes.However, as previously stated, the main focus needs to be on the organization's vision and business objectives. about supporting measurable business objectives. Types of Reviews - --peer reviews -project manager reviews -milestone reviews -buddy check -circulation reviews -technical reviews Reviews - -A review is an evaluation of a life-cycle work product(s) or project status to determine if there are any deviations from planned results and to recommend improvement. Reviews are conducted for these reasons: ● Detect defects. ● Remove defects as close to the point of insertion as possible. ● Determine product progress/status. ● Identify potential improvements. ● Produce technical work of a more uniform and predictable quality. ● Gain ownership by the project team. ● Assist employees with cross-training. ● Reduce costs to build and maintain better products. ● Reduce development time. ● Reduce testing cost and time. ● Reduce total system maintenance cost dramatically (as much as 10 to 1 according to recent statistics). Project Manager Reviews - -weekly project meeting that is called by the project manager. the project manager and development staff are in attendance. Representatives from systems engineering, QA, CM, and testing should also be in attendance. items discussed: -tracking of the standard issues of technical activities -cost -schedule performance against the plan. -staffing concerns -resources used vs what was planned for -risks -stakeholder involvement -corrective actions -updating documentation Milestone Reviews - -Formal milestone dates are documented in the project management plan, tracked, and reviewed. Typical milestone reviews include examination of technical progress, planned engineering activities, commitments, and plans. Peer Reviews - -a work product (document, code, or other) is examined by its author and one or more colleagues, in order to evaluate its technical content and quality; human-based testing. types of Peer Reviews: -Buddy Checks -Circulation reviews -Tech reviews -Inspections -Walkthroughs -Structured Walkthroughs Buddy Check - -A buddy check is normally thought of as an informal verification technique in which the life-cycle work product is examined by the author and one other person. The author walks the "buddy" through the life-cycle work product and describes what is intended in each section. The "buddy" offers comments for improvement on technical correctness, style, order of presentation, clarity, and understandability. The author may or may not accept the buddy's suggestions for improvement. used to: ● Improve the life-cycle work product; ● Consider alternative implementations; ● Exchange techniques and style variations; ● Point out problems with clarity and understandability; ● Allow the author to look at the life-cycle work product from a different "angle" or point of view; ● Mentoring of others in the concepts embedded in the life-cycle work product. Circulation Reviews - -Circulation reviews can be informal or follow strict rules. The life-cycle work product is circulated to each reviewer who reviews it and either attaches comments, questions, and recommendations directly on the life-cycle work product or places them into a separate document. -Normally, the author has the authority to accept the reviewers' comments and suggestions or ignore them. Circulation reviews are especially useful in these situations: ● Reviewers are geographically separated and face-to-face or teleconferencing is not possible. ● Individuals who are asked to be reviewers are willing to "work in" the review but not take the time out of their schedule to participate in a more formal review. ● The author is looking for a large cross section of opinions regardless of background or experience. ● A large population of stakeholders must be satisfied. ● The time during which the review must be completed is not a constraint, but the author needs as detailed a look at the life-cycle work product as possible. The objectives of circulation reviews include: ● Improve the life-cycle work product; ● Consider alternative implementations; ● Point out problems with clarity and understandability; ● Point out areas of concern and offer comments and suggestions; ● Gain consensus from a large population of reviewers; ● Gain input from valuable contributors who cannot be present for a face-to-face review. Technical Review - -A technical review is a formal team evaluation of a life-cycle work product to: ● Identify any discrepancies from specifications and standards; ● Determine its suitability for use; ● Provide recommendations after the examination of various alternatives. -evaluate the impacts of hardware anomalies or deficiencies of the software. The objectives of technical reviews are to ensure that: ● The life-cycle work product conforms to its specifications; ● The development or maintenance of the life-cycle work product is being done according to plans, standards, and guidelines applicable to the project; ● Changes to the life-cycle work product are properly implemented and affect only those areas of the system identified by the change specification. Inspections - -An inspection is a formal verification technique in which life-cycle work products are examined in detail by a group of peers for the explicit purpose of detecting and identifying defects. -A code inspection is a set of procedures and error-detection techniques for group code reading. The process is led by a moderator or facilitator or inspection leader who is not the author and is impartial to the life-cycle work product under review. Written action on all major defects is mandatory. Rework due to corrections of major defects is formally verified. Defect data is systematically collected and stored in an inspection database. This defect data is analyzed to improve the product, the process, and the effectiveness of the inspection process. agenda: - The programmer narrates, statement by statement, the logic of the program. During the discourse, other participants should raise questions, which should be pursued to determine whether errors exist. It is likely that the programmer, rather than the other team members, will find many of the errors identified during this narration. In other words, the simple act of reading aloud a program to an audience seems to be a remarkably effective error-detection technique. - The program is analyzed with respect to checklists of historically common programming errors (such a checklist is discussed in the next section). Inspection Team Members - -4 people; leader is moderator. Moderator duties include: ● Distributing materials for, and scheduling, the inspection session. ● Leading the session. ● Recording all errors found. ● Ensuring that the errors are subsequently corrected. The moderator is responsible for ensuring that the discussions proceed along productive lines and that the participants focus their attention on finding errors, not correcting them. (The programmer corrects errors after the inspection session.) other people involved: programmer of the program, program designer, and a test specialist inspection error detection agenda - -● Focuses on error discovery, not error correction ● Investigates program with respect to checklist of historically common programming errors human error detection agenda - -● Focuses on quality improvement rather than attacking the programmer ● Recommends that the inspection results must be kept confidential walkthrough - -Walkthroughs were designed to be a less formal verification technique in which life-cycle work products are examined by a group of peers for the purpose of finding defects, omissions, and contradictions. The walkthrough is normally led by the author or the producer of the material being reviewed. During the meeting, test cases are mentally executed; that is, the test data are "walked through" the logic of the program. The consolidated notes are taken by the author for review and revision as the author sees fit. The objectives of walkthroughs in addition to detecting defects are to: ● Improve the life-cycle work product; ● Consider alternative implementations; ● Point out efficiency and readability problems, or modularity problems if the life-cycle work product is code; ● Exchange techniques and style variations; ● Educate the participants. Walkthroughs should provide data for the analysis of: ● The quality of the product; ● The effectiveness of the acquisition, supply, development, operation, and maintenance processes; ● Efficiency of the walkthrough itself. walkthrough team members - -The walkthrough -three to five people total. -leader (leads the session) -secretary (a person who records all errors found); -tester(brings test cases to session) -other suggested people: A highly experienced programmer, A programming-language expert, A new programmer (to give a fresh, unbiased outlook), The person who will eventually maintain the program, Someone from a different project, Someone from the same programming team as the programmer structured walkthrough - -more formal version of a standard walkthrough. has the same requirements as the inspection with the only difference being that the structured walkthrough is led by the author