PRODUCT IMPLEMENTATION Chapter 8 Tawatchai Iempairote September 23, 2041.

Slides:



Advertisements
Similar presentations
Object Oriented Analysis And Design-IT0207 iiI Semester
Advertisements

Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 1 Disciplined Software Engineering Lecture #7 Software Engineering.
Sponsored by the U.S. Department of Defense © 2002 by Carnegie Mellon University July 2002 Pittsburgh, PA Lecture 6: Team Planning.
Personal Software Process
6/19/2007SE _06_19_Overview_Inspections.ppt1 Team Software Project (TSP) June 19, 2007 High Level Designs, Code Inspections & Measurement.
6/19/2007SE _6_19_TSPImp_SVT_Lecture.ppt1 Implementation Phase Inputs: Development strategy & plan Completed, inspected & baselined SRS & SDS.
Illinois Institute of Technology
SE 450 Software Processes & Product Metrics 1 Defect Removal.
06/12/2007SE _6_12_Design.ppt1 Design Phase Outputs: Completed & Inspected SDS & Integration Test Plan Completed & Inspected System Test Plan.
8/7/2007SE _8_07_Misc_PostMortem.ppt1 Additional Topics & Team Project Post-Mortem.
Project Execution & Termination Life Cycle Execution Presented by: Basker George.
Personal Software Process Overview CIS 376 Bruce R. Maxim UM-Dearborn.
Estimating Software Size Part I. This chapter first discuss the size estimating problem and then describes the PROBE estimating method used in this book.
The Pseudocode Programming Process Chapter 9. Summary of Steps in Building Classes and Routines.
CCSB223/SAD/CHAPTER141 Chapter 14 Implementing and Maintaining the System.
1 Software Construction Software Construction Chapter 1.
INFO 637Lecture #81 Software Engineering Process II Integration and System Testing INFO 637 Glenn Booker.
CHEP2000 February 2000 Impact of Software Review and Inspection Doris Burckhart CERN ATLAS DAQ/EF-1 Back-end software.
CS 501: Software Engineering Fall 1999 Lecture 16 Verification and Validation.
INFO 637Lecture #61 Software Engineering Process II Designing with Teams INFO 637 Glenn Booker.
สาขาวิชาเทคโนโลยี สารสนเทศ คณะเทคโนโลยีสารสนเทศ และการสื่อสาร.
INFO 637Lecture #41 Software Engineering Process II Development Plan INFO 637 Glenn Booker.
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.
CS 350, slide set 8 M. Overstreet Old Dominion University Spring 2005.
Phil Cronin Anne Hill Allen Schones CIS841 Summer on Campus 1998 IN-PROCESS INSPECTIONS FOR OBJECT ORIENTED DESIGNS.
14-1 © Prentice Hall, 2004 Chapter 14: OOSAD Implementation and Operation Object-Oriented Systems Analysis and Design Joey F. George, Dinesh Batra, Joseph.
DEFECTS By K.KARTHIKE. WHAT IS DEFECTS? Software bug, a failure of computer software to meet requirements Software bug The term defect and its relationship.
Software Engineering - Spring 2003 (C) Vasudeva Varma, IIITHClass of 39 CS3600: Software Engineering: Standards in Process Modeling CMM and PSP.
Preparing for the Launch Mohammed El- Affendi. Launch Major Tasks  The Launch is performed according to script “LAU1”, table 3.1 in the book (page 39),
14-1 © Prentice Hall, 2004 Chapter 14: OOSAD Implementation and Operation Object-Oriented Systems Analysis and Design Joey F. George, Dinesh Batra, Joseph.
1 The Software Development Process  Systems analysis  Systems design  Implementation  Testing  Documentation  Evaluation  Maintenance.
INFO 637Lecture #21 Software Engineering Process II TSP Roles and Overview INFO 637 Glenn Booker.
Disciplined Software Engineering Lecture #7 Software Engineering Institute Carnegie Mellon University Pittsburgh, PA Sponsored by the U.S. Department.
© 1998 Carnegie Mellon UniversityTutorial The Personal Software Process (PSP) The overview of the PSP that follows has been built from material made.
SE: CHAPTER 7 Writing The Program
This material is approved for public release. Distribution is limited by the Software Engineering Institute to attendees. Sponsored by the U.S. Department.
INFO 637Lecture #101 Software Engineering Process II Review INFO 637 Glenn Booker.
Team Software Process (TSPi) CS4320 Fall TSP Strategy Provide a simple process framework based on the PSP. Use modest, well-defined problems. Develop.
CS 350, slide set 5 M. Overstreet Old Dominion University Spring 2005.
CHAPTER 9 INSPECTIONS AS AN UP-FRONT QUALITY TECHNIQUE
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 3 1 Software Size Estimation I Material adapted from: Disciplined.
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 1 Disciplined Software Engineering Lecture #4 Software Engineering.
Lecture Introduction to Software Development SW Engg. Development Process Instructor :Muhammad Janas khan Thursday, September.
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 7 1 Design and Code Reviews - Overview What are design and code.
Disciplined Software Engineering Lecture #3 Software Engineering Institute Carnegie Mellon University Pittsburgh, PA Sponsored by the U.S. Department.
Introduction to Software Project Estimation I (Condensed) Barry Schrag Software Engineering Consultant MCSD, MCAD, MCDBA Bellevue.
CS 350, slide set 9 M. Overstreet Old Dominion University Spring 2006.
Implementation Phase CS4311 – Spring 2008 References: Shach, Object Oriented and Classical Software Engineering E. Braude, Software Engineering, an Object-Oriented.
The Software Development Process
Sponsored by the U.S. Department of Defense © 2002 by Carnegie Mellon University July 2002 PSP-TSPi Faculty Workshop Pittsburgh, PA Lecture.
Chapter 8. The Process Phases 1. Launching teams 2. The development strategy 3. Team planning 4. The requirements process 5. Designing with teams 6. Implementation.
THE POSTMORTEM Chapter 10 Introduction to Team Software Process.
INFO 637Lecture #71 Software Engineering Process II Product Implementation INFO 637 Glenn Booker.
Focus on design principles and on a process for doing design = To produce a precise, complete, high- quality foundation for product implementation.
CS 350, slide set 9 M. Overstreet Old Dominion University Fall 2005.
HNDIT23082 Lecture 09:Software Testing. Validations and Verification Validation and verification ( V & V ) is the name given to the checking and analysis.
Advances In Software Inspection
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
CS 350, slide set 10 M. Overstreet Old Dominion University Spring 2005.
TMP3413 Software Engineering Lab Lab 01: TSPi Tool Support.
SQA COMPONENTS IN THE PROJECT LIFE CYCLE C HAPTER 8 Dr. Ahmad F. Shubita.
CSC 480 Software Engineering Team Issues. Essence of a Successful Team To be successful, teams must  Plan their projects  Track their progress  Coordinate.
Chapter 29: Program Security Dr. Wayne Summers Department of Computer Science Columbus State University
Coupling and Cohesion Schach, S, R. Object-Oriented and Classical Software Engineering. McGraw-Hill, 2002.
SOFTWARE TESTING Date: 29-Dec-2016 By: Ram Karthick.
Applied Software Implementation & Testing
Lecture 09:Software Testing
PPT and video are due no later than March 1, 2019
Software System Integration
Team Software Process (TSP)
Presentation transcript:

PRODUCT IMPLEMENTATION Chapter 8 Tawatchai Iempairote September 23, 2041

AGENDA  Design Completion Criteria  Implementation Standards  Implementation Strategy  Reviews and Inspections  Implementation Process

Design Completion Criteria  For large systems, high-level design often requires several stages :  At the first level, you subdivide the system into subsystems, components, or modules. DES1, DESn  If these subsystems are reasonably large, repeat the high-level design process for each subsystem or component ;  At the end, you should have the external specifications for each subsystem, component, or module and should also have the detailed design of the highest level logic for the system.

Implementation Standards The implementation standards add to and extend the standards defined during the design phase  Standards review  Naming, interface, and message standards  Coding standards  Size standards  Defect standards  Defect prevention

Implementation Standards: Standards Review  Review the name, interface and message standards developed during the design phase  Check that the list of the reusable routines is complete and that all the team members are using it  Review the name glossary: complete & used  Check the component and subelement names and review the shared variable, parameter and file names for consistency  Check the standard interfaces and messages. Start with reasonable draft Known & used by all team members

Implementation Standards: Coding Standards  Same language, same standards.  Ensured that the entire team agree to use the same standard.  The commenting practices => speed code review + enhance + code sharing REUSE

Implementation Standards: Size Standards Some product elements might need size measures.  Requirements (SRS) (count text page, paragraph, shall statement)  High-Level Design (templates pages, txt lines, use cases)  Detailed design (pseudocode txt lines, LOC)  Screens & Reports  Databases  Messages  Text scripts & test materials

Implementation Standards: Defect Prevention  Pick the defect types that seem to be causing the most trouble. These defects may waste the most test time, be hardest to diagnose and fix, or otherwise be most annoying.  Examine a number of defects of this type to identify particular defect causes and divide which ones to address.  When you see a defect you think you can prevent, make a process change to prevent it.  Assuming this action is effective, start looking for the next defect category and handle it the same way.  (initialize variable => coding standards) An understanding of defect causes can help in defect prevention

Implementation Strategy The implementation strategy should generally conform to the design strategy.  Review (detail => big picture)  Reuse (use standard comment)  Testing

Reviews and Inspections  Many implementation defects are simple transcription mistakes that result from random keystroke errors.  Finding some of these errors in test can be exceptionally hard.  Reviews and inspections can consider all the paths and data values for a logical program segment.  That is why reviews and inspections are much more efficient than testing.

Design Inspections  It is hard to find sophisticated design defects when doing a review or inspection of a source program.  To produce quality programs, you must produce thorough and complete design documents and then review, inspect, and fix them before you start coding.

Implementation Process Entry Criteria  A completed development strategy and plan  Completed, reviewed and updated SRS and SDS specifications  A defined and documented coding standard  Available copies of routine functional specification list, name glossary, and all the other standards the team has adopted.

Implementation Planning  The development manager leads the work to Define and plan the implementation tasks ( SUMP, SUMQ). Task Allocation  The team leader allocates the tasks among the team members and obtains commitments for when they will complete these tasks.

Detailed Design and Design Review  The engineers produce the detailed design.  Do a design review using thorough design review methods.  Complete forms LOGD and LOGT.

Unit Test Plan  The engineers produce the unit test plans.  The engineers follow script UT to develop the unit test cases, test procedures and test data.

Detailed-Design Inspection  The quality/process manager leads the team in a DLD inspection of each component.  Complete forms LOGD and INS.

Detailed-Design Inspection  The quality/process manager leads the team in a DLD inspection of each component.  Complete forms LOGD and INS.

Coding and Code Review  The engineers produce the component source code.  Do a code review using a personal checklist.  Compile and fix the code until it compiles without error.  Complete forms LOGD and LOGT.

Code Inspection  The quality/process manager leads the team in a code inspection of each component.  Complete forms INS, LOGD and LOGT.

Unit Test  The engineers, following script UT  Conduct the unit tests.  Complete forms LOGD and LOGT.

Component Quality Review  The quality/process manager reviews each component’s data to determine if component quality meets established team criteria.  If so, the component is accepted for integration testing.  If not, the quality/process manager recommends  Either that the product be re-inspected and reworked  Or that it be scrapped and redeveloped.

Component Release  When the components are satisfactorily implemented and inspected, the engineers release them to the support manager.  The support manager enters the components in the configuration management system.

Exit Criteria  Completed, reviewed, and inspected components.  Completed INS/LOGD forms for the design and code inspections.  Updated SUMP, SUMQ, SUMS, LOGT LOGD.  Updated project notebook.