W 3 L 1 sh 1 TCTI-V2CCPP1-10 C en C++ Programmeren Week 3, les 1 : Inspection (Fagan style)

Slides:



Advertisements
Similar presentations
Effectively applying ISO9001:2000 clauses 6 and 7.
Advertisements

COMP8130 and 4130Adrian Marshall Verification & Validation INSPECTIONS Adrian Marshall.
In The Name Of GOD.
UL Careers Service Career Development Module Application Forms.
Software Quality Management Dr.S.Sridhar, Ph.D.(JNUD), RACI(Paris, NICE), RMR(USA), RZFM(Germany) Which of these would be the better way to do a project:
Damian Gordon.  Static Testing is the testing of a component or system at a specification or implementation level without execution of the software.
Tietojärjestelmien peruskurssi Software engineering Malin Brännback.
Feb. 2, 2004CS WPI1 CS 509 Design of Software Systems Lecture #3 Monday, Feb. 2, 2004.
Xtreme Programming. Software Life Cycle The activities that take place between the time software program is first conceived and the time it is finally.
 QUALITY ASSURANCE:  QA is defined as a procedure or set of procedures intended to ensure that a product or service under development (before work is.
Quality Manual for Interoperability Testing Morten Bruun-Rasmussen Presented by Jos Devlies, Eurorec.
1 Software Inspections and Walkthroughs Author: A. Frank Ackerman Presented by Cynthia Johnson EEL6883.
SystematicSystematic process that translates quality policy into measurable objectives and requirements, and lays down a sequence of steps for realizing.
Fundamentals of ISO.
Effectively applying ISO9001:2000 clauses 5 and 8
PV213 EIS in Practice: 04 – Quality assurance1 PV213 Enterprise Information Systems in Practice 04 – Quality assurance.
INFO 637Lecture #31 Software Engineering Process II Launching & Strategy INFO 637 Glenn Booker.
Sense of Initiative and Entrepreneurship This project has been funded with support from the European Commission. This [publication] communication reflects.
Software Quality Chapter Software Quality  How can you tell if software has high quality?  How can we measure the quality of software?  How.
Software Inspections and Walkthroughs By. Adnan khan.
FINAL DEMO Apollo Crew, group 3 T SW Development Project.
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
Project co-financed by European Union Project co- financed by Asean European Committee for Standardization Implementing Agency 1 Module 13 GMP Workshop.
SoITSSpecifications of IT systems? 1 Specifications of IT systems checking and validating Jens Bennedsen and Peter Gorm Larsen
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 10: Testing and Inspecting to Ensure High Quality Part 4:
McGraw-Hill/Irwin Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Reaching Goals: Plans and Controls Today’s smart supervisor.
Lecture 16 Formal Technical Reviews (FTRs) (also know as inspections) FOR0383 Software Quality Assurance 9/19/20151Dr Andy Brooks Don´t review in your.
Software Inspection A basic tool for defect removal A basic tool for defect removal Urgent need for QA and removal can be supported by inspection Urgent.
Formal and Informal Peer Reviews
If a publication is going to be distributed on time, deadlines must be met by each person on the staff. Be on-time.
Lecture #9 Project Quality Management Quality Processes- Quality Assurance and Quality Control Ghazala Amin.
1. 2 IMPORTANCE OF MANAGEMENT Some organizations have begun to ask their contractors to provide only project managers who have been certified as professionals.
Z26 Project Management Introduction lecture 1 13 th January 2005
© 2012 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S.
Disciplined Software Engineering Lecture #7 Software Engineering Institute Carnegie Mellon University Pittsburgh, PA Sponsored by the U.S. Department.
MEng projects 2013/14 Semester 2 week 10 update Mike Spann Project coordinator
Overall Quality Assurance, Selecting and managing external consultants and outsourcing Baku Training Module.
Copyright (c) Cem Kaner. 1 Software Testing 1 CSE 3411 SWE 5411 Assignment #1 Replicate and Edit Bugs.
Key Skills: Communications Presented by Bill Haining.
ISO 9001 – an overview Tor Stålhane IDI / NTNU. ISO 9001 and software development ISO 9001 is a general standard – equally applicable to software development.
Evaluation Plan New Jobs “How to Get New Jobs? Innovative Guidance and Counselling 2 nd Meeting Liverpool | 3 – 4 February L Research Institute Roula.
44222: Information Systems Development Documenting a Solution Ian Perry Room:C41C Extension:7287
Part TWO The Process of Software Documentation Chapter 5: Analyzing Your Users Chapter 6: Planning and writing your Doc. Chapter 7: Getting Useful reviews.
INFO 424 Team Project Practicum Week 2 - Launch report, Project tracking, Review report Glenn Booker Notes largely from Prof. Hislop.
Software Testing and Maintenance 1 Code Review  Introduction  How to Conduct Code Review  Practical Tips  Tool Support  Summary.
Applied Software Project Management Andrew Stellman & Jennifer Greene Applied Software Project Management Applied Software.
Planning in Organizations Why supervisors and managers plan: Knowing what the organization is trying to accomplish helps them set priorities and make decisions.
Chapter 1: Fundamental of Testing Systems Testing & Evaluation (MNN1063)
© Michael Crosby and Charles Sacker, 2001 Systematic Software Reviews Software reviews are a “quality improvement process for written material”.
Advances In Software Inspection
Reviews Chapter 5 Applied Software Project Management, Stellman & Greene See also:
44222: Information Systems Development Documenting a Solution Ian Perry Room:C49 Extension:7287
INFO 3: Use of ICT In The Digital World Topic 7: Developing ICT Solutions Factors that contribute to the success and failure of ICT Systems.
Meeting Management Planning and Running Effective Meetings Office of Student Life Montgomery College Rockville Campus.
SQA COMPONENTS IN THE PROJECT LIFE CYCLE C HAPTER 8 Dr. Ahmad F. Shubita.
PERSONAL STATEMENT MISTAKES WHAT TO AVOID IN PERSONAL STATEMENT WRITING.
T Iteration Demo LicenseChecker I2 Iteration
W 3 L 2 sh 1 TCTI-V2CCPP1-10 C en C++ Programmeren Week 3, les 2 : The preprocessor and other odds and ends (assignment: fagan inspection session)
Software Reviews Ashima Wadhwa.
Project Quality Management
Fundamentals of ISO.
GMP Inspection Process
Lean Six Sigma Project Name: Project: Date: Intros Expecations
Applied Software Project Management
QA Reviews Lecture # 6.
Project Closure And Termination
Year 11 Tutorial Sessions Lesson 5 – Creating a tailored CV
Presentation transcript:

W 3 L 1 sh 1 TCTI-V2CCPP1-10 C en C++ Programmeren Week 3, les 1 : Inspection (Fagan style)

W 3 L 1 sh 2 Creating something Make! n No requirements n No control or feedback Creative process A result

W 3 L 1 sh 3 Creating a product Make it! Check it! Creative process Inspection Feedback The result

W 3 L 1 sh 4 Fagan inspection - principles  A product (document, source file,..) has been created,  according to a set of requirements.  Someone wants to make sure that the product meets the requirements.  The author is basically competent but not perfect.  Inspection is NOT used for:  Rating the author  Assigning blame

W 3 L 1 sh 5 Fagan inspection - goals  Either:  state that the product is (sufficiently!) conform the requirements, or  produce a list of non-conformities (and iterate: creative process, inspection) Secondary goals:  Improve standards, requirements and processes  Learn from your peer’s work

W 3 L 1 sh 6 Fagan inspection - steps 1. The mandate for creating the product is established. 2. Requirements are established. 3. The author writes the document. 4. The moderator and inspectors are appointed, tasks are assigned, budget (inspection rate) is established. 5. The inspectors inspect, each on their own. They note the defects (non-conformities) they find. 6. In a moderated round-table session the defects are presented, duplicates are deleted, limited discussion is possible. Defense is not! 7. The author re-works the document according to the defects lists. 8. Depending on the severities, the document is finalized, or a new inspection is held.

W 3 L 1 sh 7 Step 1 : mandate A basic principle! (see also prince2): the mandate must come first. Mandate must include some guidelines as to what is to be done, and a budget to do it. This is mostly outside the scope of the author and the inspection team.

W 3 L 1 sh 8 Step 2 : requirements A defect is by definition a “failure to conform to a requirement”, so without requirements there can be no defects.* It is the job of the one who starts the (sub) project to establish the requirements. Note: it is NOT the job of the author! Requirements must be numbered, so a defect can refer to a specific requirement. * Without requirements you can submit an empty document. Or “main(){}”.

W 3 L 1 sh 9 Step 3 : the document The document is prepared and presented to the moderator. The moderator performs a limited (a few minutes) check to prevent wasting everyone's time. It must be possible to refer to a specific part of the document, so it must have page numbers and line numbers (!). Note: in word you can enable line numbers, or you can use a ‘vertical ruler’ as background. Neither is ideal, but it will do.

W 3 L 1 sh 10 Step 4 : participants, tasks The moderator is an independent guardian of the process, often from a different department (can be QA). The inspectors can be assigned according to the aspects that are deemed important. For instance for a subsystem design document:  A system designer to check that the subsystem fits within the overall design;  A programmer to check that the design can be implemented;  A tester to check that the design can be tested. Each inspector is allocated a time budget (typically 20 pages/hour), and a task to concentrate on.

W 3 L 1 sh 11 Step 5 : inspection Each inspector carefully reads the document and notes any defects he finds. For each defect he notes on a defect list form:  The severity  Its location in the document (page, line)  The requirements document (if there is more than one) and the requirement to which it fails to conform  If needed, a short description of the defect.  Defects must be in the order in which they appear in the document (= sorted by page/line).

W 3 L 1 sh 12 Defect list SeverityLocationRequirementDescription m12, 23CodeStd 12.7The } is one level too deep M18, 55ReqDoc The required screen refersh rate will not be met when the whole screen is refreshed each iteration. M = Major defect:  Not solving this defect will cost the company money.  The repair work on this defect should be re-checked. m = minor defect:  This looks unprofessional, but it won’t cause costly trouble.  It might be wrong, but everyone will read what is meant.  I trust the author to do what is appropriate.

W 3 L 1 sh 13 Defect list – off the scale G = Giga major defect:  Anything that puts the rework of the document at risk. The author is not competent, the requirement documents are totally wrong, the company has dropped this line of work, this is against the law, etc.  This should be very rare! Follow-up is often on the moderator, or on the initiator of the document, rather than on the author. M = Major m = minor µ = micro  Layout issues, misspelling, non-optimal wording, punctuation. etc.  Don’t put this on your defect list, just annotate your copy of the document and hand it over to the author.

W 3 L 1 sh 14 Step 7 : session The moderator holds a round-table session with the author and all inspectors. The document is scanned (page-by-page, or even line- by-line), each inspector mentions the defects he deems important enough to mention. The aim is that the author understands what the inspectors mean, NOT that he agrees with them. The only discussion that is allowed is to get the opinion of the inspector clear. Clarification of the document is not allowed (the document should speak for itself). The moderator receives the defects lists, notes the statistics, hands copies to the author.

W 3 L 1 sh 15 Step 8 : rework, finalization The author re-works the document. Handling of micro and minor defects is his responsibility. The reworking of major defects can require a check by the inspector or the moderator. The author presents the reworked document to the moderator. The moderation checks that all majors are appropriately corrected. Depending on the amount and severity of the defects the document is either finalized (gets the moderators OK stamp) or it enters a re-inspection.

W 3 L 1 sh 16 Fagan assignment 1 - input  You will all inspect a game conceptdocument.  The requirements documents are the Game conceptdocument specificaties and the Basic document requirements (can be found on sharepoint).  Inspection time is the allotted time for the assignment.  Four inspectors inspect each document. They each fill in a defect form.  The defect form template can be found on sharepoint.  Each inspector basically checks the full document on all aspects, but there are ‘specialist’ roles.

W 3 L 1 sh 17 Fagan assignment 1 – specialist roles 1. Author Are all requirements from the Game conceptdocument specificaties fulfilled? During the session: do I understand all defects found by the others? 2. User Is an interesting game (for the intended audience)? 3. Techie Are the technical requirements fulfilled, and are they achievable? 4. Moderator Is it conform the Basic document requirements The ‘author’ is a person from the group that wrote the conceptdocument, the others are from other groups.

W 3 L 1 sh 18 Fagan assignment 1 – output Each inspector 1. Annotates micro deficiencies on his hardcopy of the input document. 2. Enters minor, major (and giga) defects on the defect form. Prints a hardcopy of this defect form. The next assignment will be a Fagan Inspection session. You will need the above documents (and the requirement documents) for that session.