Safety demands strict documentation management (from initial requirements to the final design of the system) Bojan Zalar

Slides:



Advertisements
Similar presentations
Configuration Management
Advertisements

Medical Device Software Development
Sorenson Medical, West Jordan, Utah USA Medical Device Development Robert Hitchcock, Ph.D. Director of Engineering & Technology Development Sorenson Medical,
Project Scope Management (Day 2)
System Integration Verification and Validation
Chapter 4 Quality Assurance in Context
ISO 9001 : 2000.
1 Software Requirement Analysis Deployment Package for the Basic Profile Version 0.1, January 11th 2008.
Stepan Potiyenko ISS Sr.SW Developer.
Software Testing and Quality Assurance
Overview Lesson 10,11 - Software Quality Assurance
Recall The Team Skills 1. Analyzing the Problem 2. Understanding User and Stakeholder Needs 3. Defining the System 4. Managing Scope 5. Refining the System.
Computer Engineering 203 R Smith Requirements Management 6/ Requirements IEEE Standard Glossary A condition or capability needed by a user to solve.
Business Area Analysis Focus: Domain View (selected business area) Goals: –Isolate functions and procedures that allow the area to meet its goals –Define.
Major Exam II Reschedule 5:30 – 7:30 pm in Tue Dec 5 th.
Hazards Analysis & Risks Assessment By Sebastien A. Daleyden Vincent M. Goussen.
EMS Training, Awareness & Competence Norma Murphy
What is Business Analysis Planning & Monitoring?
QUALITY MANAGEMENT SYSTEM ACCORDING TO ISO
SQA Architecture Software Quality By: MSMZ.
How To Apply Quality Management
Product Quality, Testing, Reviews and Standards
ISO Tor Stålhane IDI / NTNU. What is ISO ISO 9001 was developed for the production industry but has a rather general structure ISO describes.
Thirteenth Lecture Hour 8:30 – 9:20 am, Sunday, September 16 Software Management Disciplines Process Automation (from Part III, Chapter 12 of Royce’ book)
Software Quality Assurance Activities
Project Tracking. Questions... Why should we track a project that is underway? What aspects of a project need tracking?
S Q A.
Systems Design Approaches The Waterfall vs. Iterative Methodologies.
IT Requirements Management Balancing Needs and Expectations.
16 1 Installation  After development and testing, system must be put into operation  Important planning considerations Costs of operating both systems.
Product Documentation Chapter 5. Required Medical Device Documentation  Business proposal  Product specification  Design specification  Software.
LSST Camera CD-3 Review Brookhaven National Laboratory, Brookhaven, NY LSST Safety Council Camera Review Bremerton, WA 2015 LSST Camera Environment,
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
J1879 Robustness Validation Hand Book A Joint SAE, ZVEI, JSAE, AEC Automotive Electronics Robustness Validation Plan The current qualification and verification.
Review of Software Process Models Review Class 1 Software Process Models CEN 4021 Class 2 – 01/12.
Continuing Analysis and Surveillance System (CASS) 03/06/59 1 AIRCRAFT MAINTENANCE Section 10.
Historical Aspects Origin of software engineering –NATO study group coined the term in 1967 Software crisis –Low quality, schedule delay, and cost overrun.
1 TenStep Project Management Process ™ PM00.9 PM00.9 Project Management Preparation for Success * Manage Quality *
Software Safety Case Why, what and how… Jon Arvid Børretzen.
Software Architecture Evaluation Methodologies Presented By: Anthony Register.
Business Analysis. Business Analysis Concepts Enterprise Analysis ► Identify business opportunities ► Understand the business strategy ► Identify Business.
Joel Gerber Zachary Reaver Kurt Schilling.  Provides physical proof of development  Maintains product design knowledge base  Meets government and corporate.
Manufacturing Plant maintenance Materials management Quality management.
Copyright 2013 John Wiley & Sons, Inc. Chapter 3 Monitoring and Controlling the Transformation System.
Project Management Basics
CSC 480 Software Engineering Test Planning. Test Cases and Test Plans A test case is an explicit set of instructions designed to detect a particular class.
ISO Registration Common Areas of Nonconformances.
CS352 – Software Engineering II Lecture 17: SW Quality Assurance Landscape Slides by Mohammad El-Ramly, PhD.
® IBM Software Group © 2009 IBM Corporation Essentials of Modeling with the IBM Rational Software Architect, V7.5 Module 15: Traceability and Static Analysis.
Checking and Corrective Action EPA Regions 9 & 10 and The Federal Network for Sustainability 2005.
[Project Title], #[Proj. ID] Lessons Learned Presented by [Name] [Date] Lessons Learned Template Version /07/2015.
Project Planning Goal 1 - Estimates are documented for use in tracking and planning project. Goal 2 - Project Activities and commitments planned and documented.
Copyright 2015, Robert W. Hasker. Classic Model Gathering Requirements Specification Scenarios Sequences Design Architecture Class, state models Implementation.
Project Planning: Scope and the Work Breakdown Structure
Configuration Management
How To Apply Quality Management
Software Testing Basics
Raechel Huebner Ruthanne Sherer
Software Requirements
Chapter 21 Software Quality Assurance
Quality Management Systems – Requirements
Chapter 21 Software Quality Assurance
Baisc Of Software Testing
Software Quality Assurance
PSS verification and validation
Hazards Analysis & Risks Assessment
PFMEA Summary Process Steps
Corey Beth Monarch Lindsey Novak Michael Seikel Whitney Young
Presentation transcript:

Safety demands strict documentation management (from initial requirements to the final design of the system) Bojan Zalar the best people make cosylab

Cosylab part I – we are building a medical device How can you assure the final system meets all requirements? How do you know the final system is fully tested? How do you know, which requirements are more important than others?

How to achieve it? Requirements must be traceable throughout entire development process  all requirements are: agreed, evaluated, and met  … therefore we need traceability Risks must be identified and mitigated Work-flow environment and tools must support the above Cosylab

Requirements must be traceable All requirements must be met  link from initial requirements to final verification Every component of the system must be there for a reason Proof of traceability:  traceability matrix. Cosylab

All requirements must be met Cosylab Req#1 Comp#1 Comp#2 Comp#3 Test Case #1 Test Case #2 Test Case #3 Test Case #4 Test Report #1 Test Report #2 Test Report #3 Test Report #4 Req#2 Comp#1Comp#2Comp#3 Test Case #1x Test Case #2x Test Case #3xx Test Case #4x Req#1Req#2 Comp#1xx Comp#2x Comp#3x

Every component of the system must be there for a reason Cosylab Prevent over-engineering Reduce maintenance and upgrade Req#1 Comp#1 Comp#2 Comp#3 Test Case #1 Test Case #2 Test Case #3 Test Case #4 Test Report #1 Test Report #2 Test Report #3 Test Report #4 Req#2 Comp#4 Test Case #5 Test Report #5 Req#1Req#2 Comp#1xx Comp#2x Comp#3x Comp#4

Traceability matrix Cosylab

Risks must be identified and mitigated Certain device risks can result from faults Take appropriate actions to minimize the risks Verify that taken actions minimize the risks Cosylab Requirements Architecture & Design Test Plan Test Report Risk Analysis Risk Mitigation DFMEA

DFMEA Design Failure Mode and Effects Analysis Key functions of the design are inspected Primary potential failures and causes of each failure are identified Actions are taken to reduce final risk Cosylab

Work-flow environment and tools The tool must work well on big projects The environment must be set in a way to allow tracking changes and keeping team aligned Cosylab

The tool must work well on big projects MS Word is not enough, we need specialized tools Custom made applications are too expensive Enterprise Architect can easily handle big projects Cosylab

Implementing The model in Enterprise Architect Cosylab Reqs A&D Tests Reports The model  Documents  Requirements  Architecture & Design  Test Plan  Test Report  Traceability Matrix  People  Architects  Developers  Testers

Cosylab part II – hands-on in practice

Collect information Adding/modifying requirements  Attributes, Figures Linking requirements to Architecture and Test Cases  No requirement is forgotten  Each Component is there for a reason Cosylab

Collect information Cosylab

Traceability Cosylab

Generate reports covering different perspectives Templates are defined according the EBG/MedAustron styles  Easy changing, creating new ones Generating a MS Word document form the model is simple Easily Searching for the specific information in the model  Search/Generate for Approval Requirements Cosylab

Cosylab Generate reports covering different perspectives

Traceability matrix Cosylab

Auditing - track model changes Cosylab

We are building medical device Requirements must be traceable throughout entire development process Risks must be identified and mitigated Work-flow environment and tools must support the above Cosylab