Page 1 TEST in the large RELEASE REWORK ASSESS packaged application documentation models and source code management documents requirement alloc. matrix.

Slides:



Advertisements
Similar presentations
Process and Product Quality Assurance (PPQA)
Advertisements

MODELING THE TESTING PROCESS Formal Testing (1.0) Requirements Software Design Risk Data Approved, Debugged, Eng. Tested Code Automated Test Tools Tested.
Software Quality Assurance Plan
Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall 3.1.
Ahsan Kabir Project Manager Ahsan Kabir Project Manager ………………………….
Software Delivery. Software Delivery Management  Managing Requirements and Changes  Managing Resources  Managing Configuration  Managing Defects 
Project Closure Report Basker George. Project Closure When does a project end? Does it end when the software has been delivered to customer & acceptance-tested?
GAI Proprietary Information
Stepan Potiyenko ISS Sr.SW Developer.
Rational Unified Process
Software Project Transition Planning
APPLICATION DEVELOPMENT BY SYED ADNAN ALI.
Validating and Improving Test-Case Effectiveness Author: Yuri Chernak Presenter: Lam, Man Tat.
Iterative development and The Unified process
The Software Product Life Cycle. Views of the Software Product Life Cycle  Management  Software engineering  Engineering design  Architectural design.
CBIIT Quality Assurance Process Preston Wood NCI CBIIT Government Quality Representative (GQR) January 2014 RS.
X36SSP Správa softwarových produktů 7. přednáška Ing. Martin Molhanec ČVUT – FEL K13113.
Release & Deployment ITIL Version 3
What is Business Analysis Planning & Monitoring?
Table of Content Summary SW development process overview
S/W Project Management
S T A M © 2000, KPA Ltd. Software Trouble Assessment Matrix Software Trouble Assessment Matrix *This presentation is extracted from SOFTWARE PROCESS QUALITY:
Introduction to RUP Spring Sharif Univ. of Tech.2 Outlines What is RUP? RUP Phases –Inception –Elaboration –Construction –Transition.
Page 1 MODEL TEST in the small GENERALIZE PROGRAM PROCESS allocated maintenance changes management documents initial requirement project infrastructure.
RUP Implementation and Testing
Software Inspections. Defect Removal Efficiency The number of defects found prior to releasing a product divided by The number of defects found prior.
1 ISA&D7‏/8‏/ ISA&D7‏/8‏/2013 Systems Development Life Cycle Phases and Activities in the SDLC Variations of the SDLC models.
End HomeWelcome! The Software Development Process.
MSF Overview (Microsoft Solutions Framework) Eran Kolber Vice President – LIH Ltd Regional Director – Microsoft Product Management Advisor – MSF Development.
Creator: ACSession No: 16 Slide No: 1Reviewer: SS CSE300Advanced Software EngineeringFebruary 2006 (Software Quality) Configuration Management CSE300 Advanced.
© 2006 Cisco Systems, Inc. All rights reserved.Cisco Public 1 Version 4.0 Gathering Network Requirements Designing and Supporting Computer Networks – Chapter.
Boston University Project Management Association Website Development Group 3 Team3 CS632 Dr. Vijay Kanabar Team Members Mario Soto Emily Ziegler Kevin.
IT Requirements Management Balancing Needs and Expectations.
ISM 5316 Week 3 Learning Objectives You should be able to: u Define and list issues and steps in Project Integration u List and describe the components.
Quality Activity Matrix Presented by Sandra Toalston President, SanSeek 1.
® IBM Software Group © 2006 IBM Corporation PRJ480 Mastering the Management of Iterative Development v2 Module 6: Phase Management -Transition.
Georgia Institute of Technology CS 4320 Fall 2003.
INFO 637Lecture #101 Software Engineering Process II Review INFO 637 Glenn Booker.
Notes of Rational Related cyt. 2 Outline 3 Capturing business requirements using use cases Practical principles  Find the right boundaries for your.
© 2006 Cisco Systems, Inc. All rights reserved.Cisco Public 1 Version 4.0 Gathering Network Requirements Designing and Supporting Computer Networks – Chapter.
Search Engine Optimization © HiTech Institute. All rights reserved. Slide 1 What is Solution Assessment & Validation?
Page 1 JUSTIFY define and validate REQUIRE- MENTS define initial management DOCUMENTS define INFRA- STRUCTURE allocated maintenance changes management.
Team Skill 6: Building the Right System Assessing Requirements Quality (29)
PRJ566 Project Planning & Management Software Architecture.
ITC Software ITC FUNCTIONAL TESTING SERVICES.
An organizational structure is a mostly hierarchical concept of subordination of entities that collaborate and contribute to serve one common aim... Organizational.
Sistemas de Información Agosto-Diciembre 2007 Sesión # 9.
Software Testing Process
Illuminating Britelite’s Internal Services for Success Strategy for Process Improvement.
RUP RATIONAL UNIFIED PROCESS Behnam Akbari 06 Oct
6/6/ SOFTWARE LIFE CYCLE OVERVIEW Professor Ron Kenett Tel Aviv University School of Engineering.
ISIS Project Status Report May 18, 2006 Prepared by MAXIMUS, Inc Education Systems Division for the ABT Committee.
by: Er. Manu Bansal Deptt of IT Software Quality Assurance.
Strana 1MBA kurz informačního inženýrství INITIATE CONSTRUCT DELIVER MAINTAIN & SUPORT quality assurance, manage project, trainig&education, manage.
IS&T Project Reviews September 9, Project Review Overview Facilitative approach that actively engages a number of key project staff and senior IS&T.
Process Knowledge Playback Maintenance Project Presented By- Alka Mehta(885026) Arpit Saran(838563) Kirti Singh(883796) Kumari Meenu(840291) Rishabh Jha(835286)
Introduction for the Implementation of Software Configuration Management I thought I knew it all !
Software Quality Control and Quality Assurance: Introduction
Managing the Project Lifecycle
Maintaining Quality Test Optimization with Increasing Software Complexity Ankit Goyal Software Engineer II Adobe Systems.
Description of Revision
9/18/2018 Department of Software Engineering and IT Engineering
Engineering Processes
Chapter 1 (pages 4-9); Overview of SDLC
QA Reviews Lecture # 6.
Engineering Processes
Software Reviews.
{Project Name} Organizational Chart, Roles and Responsibilities
SDLC (Software Development Life Cycle) Role Play
Presentation transcript:

Page 1 TEST in the large RELEASE REWORK ASSESS packaged application documentation models and source code management documents requirement alloc. matrix potential roles during this phase: tested application documentation models requirement alloc. matrix project manager support manager operations manager training manager developer support engineer operations engineer trainer project auditor testing manager test engineer technical writer DELIVER PHASE The main goal here is to deploy the application, including the appropriate documentation, to the user community.

Page 2 TEST IN THE LARGE ACCEPT TEST PLAN packaged application master test quality assurance plan previous test results FUNCTION TEST OPERATIONS TEST STRESS TEST ALPHA/BETA TEST INSTALLATION TEST tested application test results PERFORM METRICS USER ACCEPTANCE TEST RECORD DEFECTS The goal here is to ensure that the application works on its entirety. This includes user testing in which the application is specifically tested by members of user community.

Page 3 Test in the large entrance conditions checklist  The application has been packaged for delivery  The master test/QA plan in available  Previous test results are available  Team members are trained

Page 4 Test in the large to be performed checklist  The master test/QA plan was accepted  Defects have been recorded  All particular tests were performed  Artifacts that are potentially reusable by this project team have been identified and used  Decisions, both made and forgone, have been documented in group memory  Metrics have been collected

Page 5 Test in the large exit conditions checklist  The application has passed testing  Test results were documented

Page 6 REWORK PRIORITIZE DEFECTS tested application tested results, documents models, source code requirement alloc. matrix organizational priorities REMODEL TEST IN THE SMALL UPDATE DOCUMENTA- TION PERFORM METRICS REPROGRAM reworked application models, source code documentation requirement alloc. matrix The focus of this process is to fix the critical defects discovered by the “test in the large” process to ensure the successful deployment of the application. It is like a miniature version of the “construct” process.

Page 7 Rework entrance conditions checklist  The test results are available  The organization priorities are known  The current version of software is able to be reworked  Team members are trained

Page 8 Rework to be performed checklist  Defects have been prioritized  The models have been reworked  The requirement allocation matrix has been reworked  The support documentation has been reworked  The user documentation has been reworked  The operations documentation has been reworked  The source code has been reworked  The application was tested in the small (system tests)  Reusable artifacts were used  Risk assessment document was updated  Decisions, both made and forgone, have been documented in group memory  Metrics have been collected

Page 9 Rework exit conditions checklist  The selected and prioritized defects have been reworked  The construct phase deliverables (code, doc, models) are consistent  The application has been repackaged for testing

Page 10 RELEASE ACCEPT TRAINING AND RELEASE PLANS release procedures training plans application package operations and support documentation ACCEPT USER SUPPORT AND OPERATIONS DOCUMENTS DEPLOY THE OPERATION PROCESS FINALIZE CONVERSION OF LEGACY DATA DEPLOY THE SUPPORT PROCESS TRAIN OPERATIONS STAFF ANNONCE ACTUAL RELEASE TO USERS TRAIN SUPPORT STAFF PACKAGE APPLICATION released application procedures documentation TRAIN USERS PERFORM METRICS DEPLOY THE APPLICATION The goal of this process is to deploy the application and its corresponding documentation successfully to the user community (end users and also operations department staff that will help the users work with the application effectively).

Page 11 Release entrance conditions checklist  The application has been packaged for release  Organization release procedures are available  The training plan for user, operations and support communities are available  The documentation is available to be deployed  Team members are trained

Page 12 Release to be performed checklist  The training and release plans have been accepted  The user, support and operations documentation has been accepted  The legacy data has been converted  The product baseline and version description has been finalized  The release notes have been finalized  The installation procedures have been finalized  The operation staff has been trained  The support staff has been trained  The release was announced  The user community was trained  The application was deployed to user community  Risk management document was updated  Decisions, both made and forgone, have been documented in group memory  Metrics have been collected

Page 13 Release exit conditions checklist  The user, support, and operations communities have been trained  The application has been deployed  The application and its documentation has been accepted  The support environment has been installed

Page 14 ASSESS project deliverables project metrics group knowledge base REVIEW PROJECT DELIVERA- BLES ASSESS TEAM MEMBER PERFORMANCE DEVELOP LEARNING HISTORY DEVELOP PROJECT ASSESSMENT learning history project and staff assessment process improvement plan ANALYZE METRICS DEVELOP STAFF ASSESSMENT ASSESS USER INVOLVEMENT DEVELOP SOFTWARE PROCESS IMPROV. PLAN This process has two goals: a) for the project team, to learn from its experiences developing the application b) to provide an opportunity to evaluate the members of the project team to support their personal growth

Page 15 Assess entrance conditions checklist  Management support exists  Project members and key user representatives are available  Project deliverables, including the group memory and collected metrics are available  Team members are trained

Page 16 Assess to be performed checklist  Project deliverables were reviewed  Metrics collected during the project were presented and analyzed  The performance of individual team members was assessed  The involvement of user community was assessed  The involvement of support community was assessed  The involvement of operations community was assessed  The project assessment was documented  The learning history was developed  The software process improvement plan was developed  Risk assessment document has been updated  Decisions, both made and forgone, have been documented in group memory  Metrics have been collected

Page 17 Assess exit conditions checklist  All staff assessments are complete  The project assessment has been presented to senior management  The software process improvement plan has been accepted