1 ProSyst Labs ISO 9001:2000 Quality Management System Pavlin Dobrev Research and Development...

1

ProSyst LabsISO 9001:2000 Quality Management

System

Pavlin DobrevResearch and Development Manager

3

ISO 9001:2000 is an international standard for quality management systems. It specifies requirements for a quality management system where an organization needs to demonstrate its ability to provide products that fulfill customer and applicable regulatory requirements and aims to enhance customer satisfaction.

The Quality Management System (QMS) of the company is presented by the internal site:

http://iso9001.devzone.psb/

The QMS process can be divided into four main categories:•Management Responsibility;

•Resource Management;

•Product Realization;

•Measurement, analysis and improvement.

http://iso9001.devzone.psb/qms/qms/general.html

Introduction

4

The management of the organization commits to pursuing the following quality policy:

We work with the aim to satisfy the customer and the market requirements, at the same time achieving optimal technological and economic results, observing the norms and regulations;

Quality is the result of the overall efforts of all the personnel in their everyday activities.

Quality Management is related to a continuous improvement and perfection of all work fields in the organization;

We exert the necessary efforts for the acceptation and application of the quality policy in all organizational levels and we encourage the personnel in their contribution to quality improvement.

We continually improve the effectiveness of the QMS;

Aiming at the above goals we introduce a QMS that complies with the requirements of the international standard ISO 9001:2000.

Quality Policy

5

Quality Objectives

The main objective of the QMS is to ensure the production of high-quality products, responding to the current market requirements. The criteria for quality products are defined by:

Feedback from customers about previous product versions;Customer requirements for a concrete product version;Observation of the market (marketing research, relevant articles, etc.)

http://marketing.devzone.psb/ Observation of competitive products, especially from companies like IBM, SUN,

Microsoft. Compatibility with these products http://marketing.devzone.psb/ Compatibility with established international standards in the field of the concrete

products;The evaluation criteria before releasing the final product are:

Passing through the standard procedure for software development, defined and adopted by the company (Project Lifecycle);

Passing through all standard internal testing packages, applicable for the product;

Covering all kinds of requirements for load conditions (at different modes of work);

6

Quality Objectives

Product Version Plan defines concrete quality goals for corresponding product version.

Every Project Schedule define Iteration Goals as milestones for finishing the iteration.

Every Feature Request in ISO Feature Request tracker that is accepted is set as quality goal.

7

Security Policy

The company management is engaged in performing an Information Security Policy based on the following issues:

Keeping confidentiality related to the work that is performed;

Restricted access to the areas from the building that contain customer property. Access to the customer property is allowed only upon permission from the Project Leader of the corresponding project;

High level of security of internal systems;

Duplication of responsibilities and information between the company offices in Bulgaria and Germany allowing continuity of the process of work;

Confidential information is exchanged always in encrypted form;

Confidential information stored on mobile devices (PGP Desk, Windows XP Folder encryption) is always encrypted;

8

"Need to know" principle for accessing confidential information – access to confidential information is granted only to those employees whose tasks require it;

Tracking of the access rights to the internal systems and removing access rights to the employees that do not need them at the moment;

Prohibition against discussion of confidential information by using unsafe systems for communication (e.g. ICQ).

Security Policy

9

Software Development

Product Management

Customer Specific Solutions

Project Lifecycle

10

Describes the lifecycle of a product – requirements management, version planning, product development, technical support.

The roles, activities and the artifacts of the product management process are presented.

Product Management

11

Product Management

12

Customer Specific Solutions Management

Describes the procedure of managing customer specific

software solutions. The roles, activities and the artifacts

of the customer solutions process are presented.

Customer Solutions

13

Customer Solutions

14

Describes the process lifecycle - the lifecycle

phases inception, elaboration, construction and

transition. The roles, activities and the artifacts of the

software development process are presented.

Project Lifecycle

15

Project Lifecycle

The project life cycle is divided in time into a sequence of four phases, each finishing with the realization of particular goals, represented as major milestone. Each phase is essentially a span of time between two major milestones.

16

Activities- Project Lifecycle

Project Management

Requirements Specification

Design

Implementation (Programming, Test Implementation, Technical Writing)

Testing (Test Design, Test Execution, Test Result Analysis)

Configuration & Change Management

Reviewing (Requirements Reviewing, Design Reviewing, Code Reviewing, Test Reviewing)

17

Activities - Project Management

Objectives - planning, management and control of a software project, risk management (preventive and corrective actions);

Design and Implementation planning and monitoring. Cooperation with the Support and Documentation departments concerning the concrete project.

Project feedback monitoring, participation in the control group for the project.

Initiation of reviews, without the right to determine the participants in the review.

Risk Management.

Artefacts - Software Development Plan, Project Schedule, Risk Management Plan;

Role - Project Leader.

18

Activities - Requirements Specification

Objectives - detailed description of the requirements to the software product, which will be realized;

Artefacts - Software Requirements Specification;

Role - Requirements Specifier.

19

Activities - Design

Objectives - design of the software product architecture;

Artifacts - Software Architecture Document;

Role - Software Architect.

Activities - Design

20

ProgrammingObjectives - writing of program code;Artifacts - Program Code;Role - Programmer.

Test implementationObjectives - test cases realization;Artifacts - Test Case;Role - Programmer.

Technical WritingObjectives - creation of user documentation;Artifacts - User Documentation;Role - Technical Writer.

Activities - Implementation

21

Test Design

Objectives - planning of the test procedures and design of the necessary tests;

Artifacts - Test Plan;

Role - Test Designer.

Test Execution

Objectives - realization of the planned test procedures and the ready tests;

Artifacts - Test Report;

Role - Tester.

Test Result Analysis

Objectives - analysis and summary of the testing results, generation of Bug Reports;

Artifacts - Test Evaluation Summary, Bug Reports;

Role - Test Analyst.

Activities – Testing

22

Activities - Configuration and Change Management

Objectives - management of the artefacts generated during the development process and management of the modifications made during the development cycle. It is done according to the Configuration and Change Management Plan;

Artefacts - not generated;

Role - Project Manager.

23

Activities - Reviewing

Requirement ReviewingObjectives – requirements’ review;Artifacts - Review Report;Role - Requirement Reviewer.

Design ReviewingObjectives - design review;Artifacts - Review Report;Role - Design Reviewer.

Code ReviewingObjectives - program code review;Artifacts - Review Report;Role - Code Reviewer.

Test ReviewingObjectives - test plan and test cases design review;Artifacts - Review Report;Role - Test Reviewer.

Activities - Reviewing

24

Project Lifecycle - Phases

Iterations

A project lifecycle consist of sequence of iterations. Each iteration incorporates a set of activities from requirements, analysis and design, implementation, test, and project management disciplines, in various proportions depending on where in the development cycle the iteration is located. Iterations in the inception and elaboration phases focus on management, requirements, and design activities; iterations in the construction phase focus on design, implementation, and test; and iterations in the transition phase focus on test and deployment. Each phase consist of one ore more iterations, depending of the project.

25

Iteration Planning

26

Phases - Inception

Objectives

Establishing the project's software scope - what is intended to be in the product and what is not

Preparing the environment for the project - organization, people, tools, etc.

Planning phases, iterations and project deliverables

Essential Activities

Project Management


Configuration and Change Management

27

Phases - Inception

28

Phases - Inception

Project Management ActivitiesDevelop Software Plan

Estimate the scope and effort for the project

Develop a coarse-grained plan for the project - phases, iterations major milestones and key deliverables

Determine necessary resources and project organization> Input - Product Version Plan or Statement Of Work> Output - Software Development Plan, Project Schedule

29

Project Management ActivitiesPlan Elaboration phase

develop work breakdown structure prepare detail schedule plan of the activity and responsibility

assignments define phase milestones and deliverables Define Risk Management Plan, Risk List

> Input - Software Development Plan, SRS> Output - Project Schedule, Risk Management Plan

Phases - Inception

30

Phases - Inception

Configuration and Change management

The tools that will be used for design, realization, testing and delivery of the project are determined according to the company Configuration and Change Management Plan. If necessary a Configuration Management Plan is created for the particular project.

> Input - Product Version Plan or Statement Of Work> Output - Software Development Plan, Project Schedule

31

Requirements Specification ActivitiesDevelop Initial Software Requirements Specification

Analyze Business Requirements

Define functional sub-subsystems (for larger projects)

Define actors & use cases for each sub-system

Specify non-functional requirements

> Input - Software Development Plan> Output - Software Requirement Specification(s)

Phases - Inception

32

ArtifactsSoftware Development Plan - contains all information required to

manage the project. The document is maintained throughout the whole lifecycle of project.

Project Schedule - defines timeline plan for phases & iterations, as well as detailed plan of the activities and responsibility assignments for the current (next) iteration. The document is updated before each project iteration.

Initial SRS - specifies the requirements in a degree of detail at least sufficient for the purposes of the planning.

Risk Management Plan/Risk List – specify risks monitored during the project lifecycle

Phases - Inception

33

Objectives

Clarification of the project requirements

Creating the project architecture and detailed planning for the next phase


Project Management


Requirement Reviewing

Design

Design Reviewing

Programming

Phases - Elaboration

34

Test Design

Test Reviewing



35


36

Project Management Activities

Planning the next phase of the development cycle

Risks are identified, and if any, preventive and corrective actions are taken.

> Input - Software Development Plan, Project Schedule

> Output - Software Development Plan, Project Schedule


37

Requirement Specification Activities

Requirements review is performing

If is necessary, a prototype is creating .

> Input - Software Requirement Specification

> Output - Software Requirement Specification


38

Requirements Reviewing Activities

Clarifying the project requirements

If is necessary, iterations are made, with the purpose of maximum clarification of the requirements.


> Output - Software Requirement Specification


39

Design Activities

It is performed on the basis of the requirements defined in the SRS and requirements, which have emerged from the prototype development, if such is created

The architecture is designed according to the stipulated requirements.


> Output - Software Architecture Document


40

Design Reviewing Activities

Architecture review performing

If necessary several iterations are made with the purpose of maximum clarification of the architecture.

> Input - Software Architecture Document

> Output -Review Report


41

Programming

If necessary and if an explicit requirement is specified in the SDP, a prototype is created


> Output -Prototypes


42

Test Design The strategy for product testing is defined

> Input - Software Requirement Specification> Output - Test Plan


43

Test Reviewing The review of the testing strategy is performed

> Input - Test Plan > Output -Review Report


44

Configuration and Change Management The observation of "Configuration and Change Management Plan" is

monitored> Input - Configuration and Change Management Plan> Output -no artifacts are generated


45

ArtifactsSoftware Development Plan - updated version of the document

Project Schedule - updated version of the document

SRS - detailed description of the requirements

SAD - detailed design of the system or of some components of the system (if necessary)

Test Plan - description of testing methods and strategy

Review Report - for each performed review.


46

Objectives

Performing the basic generation of program code

additional clarifications of the project requirements and its design are made as well as detailed planning for the next phase


Project Management

Requirement Specification

Programming

Design

Design Reviewing

Phases - Construction

47

Test Implementation

Technical writing

Testing

Testing Results Analysis

Code Reviewing



48


49

Project Management Activities

Planning the next phase of the development cycle

Risks are identified, and if any, preventive and corrective actions are taken.

> Input - Software Development Plan, Project Schedule

> Output - Software Development Plan, Project Schedule


50

Requirement Specification Activities If necessary changes in SRS are made.

> Input - Software Requirement Specification> Output - Software Requirement Specification


51

Programming Activities The program code is developed based on the SRS and the SAD

documents If necessary this activity is reflected in changes made to the SRS and

SAD documents> Input - Software Requirement Specification, Software

Architecture Document> Output -Program Code


52

Design Activities Additional clarification of the design is made based on results from

the Programming activity> Input - Software Requirement Specification, Program Code> Output - Software Architecture Document


53

Design Review Activities Architecture review is performed, if necessary and if specified in the

SDP> Input - Software Architecture Document> Output -Review Report


54

Test Implementation Activities The tests planned in the Test Plan are realized

> Input - Test Plan> Output -Test Cases


55

Technical Writing Activities Based on the technical documentation, following the requirements to

the documentation described in the SDP and SRS, user documentation is created.

> Input - Software Requirement Specification> Output -User Documentation


56

Testing Activities The planned testing is executed on the platforms specified in the

Test Report.> Input - Program Code, User Documentation, Test Cases> Output -Test Report


57

Testing Result Analysis Activities The planned testing is executed on the platforms specified in the

Test Report.> Input - Test Report > Output -Test Evaluation Summary, Change Request, Bug Report


58

Code Reviewing Activities Code Review is made, if required and if specified in the SDP.

> Input - Program Code > Output -Review Report


59

Configuration and Change Management Activities Monitoring is done in compliance with the Configuration and Change

Management Plan> Input - Configuration and Change Management Plan> Output -no artifacts are generated


60

ArtifactsSoftware Development Plan - updated version of the document


SRS - updated version of the document

SAD - updated version of the document

Test Plan - updated version of the document

Beta Version

Change Request with decisions made on their realization

Test Reports with ready test results

Test Evaluation Summary - containing summery results of testing

Bug Report

Review Report - for each review


61

Objectives

A finishing phase, leading to the final results of the project as they are defined in the SDP


Project Management

Programming

Test Implementation

Technical writing

Testing

Test Result Analysis


Phases - Transition

62

Phases - Transition

63

Project Management Activities If present, risks are identified, and preventive and corrective

measures are taken> Input - Software Development Plan, Project Schedule> Output - Software Development Plan, Project Schedule

Phases - Transition

64

Programming Activities It consists mainly in correcting the problems identified by testing

> Input - Program Code, Test Evaluation Summary, Bug Report

> Output -Program Code

Phases - Transition

65

Test Implementation Activities It consists mainly in correcting the problems identified in the test

case> Input - Test Cases, Program Code, Test Evaluation

Summary, Bug Reports> Output -Test Cases

Phases - Transition

66

Technical Writing Activities It consists mainly in correcting the problems found during the

testing> Input - User Documentation, Test Evaluation Summary, Bug

Reports> Output - User Documentation

Phases - Transition

67

Testing Activities

> Input - Beta Version> Output - Test Report

Phases - Transition

68

Test Result Analysis Activities It is analysis of the test results

> Input - Test Report > Output - Test Evaluation Summary, Change Request, Bug

Reports

Phases - Transition

69

Configuration and Change Management Activities Monitoring is made of the activities compliance with the Configuration

and Change Management Plan> Input - Configuration and Change Management Plan> Output -no artifacts are generated

Phases - Transition

70

ArtifactsSDP - updated version of the document


Final Version

Test Reports with ready test results

Change Request with final decisions for their realization

Test Evaluation Summary - containing summery results of testing

Bug Report

Review Report - for each review

Phases - Transition

71

Other procedures and related documents and links

Guidelines for tools and activities

Support

Purchasing

System Administration

Configuration and Change Management Plan

Documents Management

Internal audits

Corrective Actions

Preventive Actions

Internal audits, Corrective and Preventive Actions

Resource Management

72

Guidelines for tools and activities

Presents guidelines for working with Source Forge and Microsoft Project, and guidelines for the activities:

Project Management


Design

Implementation

Reviewing

Testing

http://iso9001.devzone.psb/index.html

Guideline for Activities

73

Guidelines for tools

Basic Principles

All categories in a project should be appointed a project member to “Auto Assign To” requests. In addition, each project feature request tracker should have a “General” category with auto-assign to the Project Leader.

In the “Groups” field you specify the names of the builds. When working in CVS, you use the group, dedicated to the next planned build.

The “Client” field contains the name of the client the bug comes from (the default value is ProSyst).

Bug reports are reviewed in the beginning of every iteration in order to plan the bug fixing activities.

Bug Tracking Guideline

74

Bug Priority and Severity

Bug Priority – The priority of a bug should be determined and set by the Project Leader only. The submitter of the bug should not set the bug priority. The default priority value is 5.

Bug Severity – The severity of a bug, which designates the extent of the damage the bug brings to the application, should be set by the bug submitter. Classification of Severity: Blocker, Critical, Major, Minor, Trivial.


75

Bug Management

Assign – When a bug is submitted, it is assigned to a person participating in the project, either through the auto-assign property of the chosen category or manually by the submitter.

Resolution – After the bug is assigned (it automatically receives resolution SUBMITTED), within one working week the bug should be reviewed ant its resolution changed to ACCEPTED, REJECTED, INVALID, DUPLICATE or POSTPONED. The bug tracking system automatically sends an e-mail message to the Project Leader every time the bug status or resolution is changed. Subsequently, the Project Leader determines the bug Priority.


76

Bug Management

Change Resolution – The bug assignee can set the resolution of the bug to any value except REJECTED. Resolution REJECTED can be set only by the bug submitter in case the bug is set to FIXED, but it still exists.

Change Status – The bug submitter changes the bug status. The combination of status CLOSED and resolution FIXED means that the bug is fixed and the fix is confirmed in a build. Bugs should be closed only after being FIXED and the fix is present and confirmed in a build. If a conflict on the status of a bug (e.g. after the resolution is set to INVALID, DUPLICATE, or REJECTED) arises between the submitter and the assignee, then the Project Leader is responsible to determine and set the proper bug status. Bugs should not be set to status CLOSED, when they are still being fixed, or if they have resolution POSTPONED.


77

Guidelines for tools

Basic Principles

A feature request should be put in the Feature Request Tracker of the Source Forge project, to which the request is related. If a request cannot be associated with a particular project (or if it concerns more than one project), it should be submitted in the General SF project for the product.

The feature tracker should have the following groups:

vX.Y.Z – Shows the product’s version or the package’s build number (for projects).

Current Version – Used for requests that will be currently implemented.

Future Versions – Used for requests that will be included in future versions.

Feature Tracking Guideline

78

Basic Principles

All categories in a project should be appointed a project member to “Auto Assign To” requests. In addition, each project feature request tracker should have a “General” category with auto-assign to the Project Leader.

The “Client” field contains the name of the client the request comes from (the default value is ProSyst).

The Project Leader sets a proper request Priority. Subsequently, when planning the work, the requests with higher priority will be included first.

Feature requests are reviewed in the beginning of every iteration (mainly to update request priorities and groups as a result of the planning process.)

Feature requests should be closed only by the Project Leader, the Technology Leader or the Product Manager (or by a person, appointed by them).


79


Feature Request Statuses and MeaningSUMBITTED – The request is posted. It is still not examined and is a

subject of consideration when planning the next iteration.

ACCEPTED – The request is accepted for implementation. The request group should be changed to indicate the version of the product/project, for which it will be implemented.

DONE – The request is implemented (its status can be changed to CLOSED). If a request is done, its group should be changed to correspond to the version of the product/project, for which it is fulfilled.

DUPLICATE – The request duplicates a preceding request. It is recommended to provide a comment about the preceding request. The request status can be changed to CLOSED.

NOT ACCEPTED – The request is not accepted. It is recommended to provide a comment why. The request status can be changed to CLOSED.

80

The procedure describes the order in which the product servicing is done, after delivery and installations. All support requests and complaints received by customers are handled in a specified order through the web-based Developer Zone (dz.prosyst.com). support and improvement of Developer Zone.

http://iso9001.devzone.psb/product/support/support.html

Specifies preparing of marketing documents: preparing DataSheets, ReleaseNotes, SupportedPlatforms, ProductNotes; preparing marketing reports; review of sites and forums.

http://iso9001.devzone.psb/product/marketing/marketing.html

Support

Marketing

Support and Marketing

81

The procedure specifies the order for purchasing and procurement of technical equipment like hardware, software, office furniture. It also specifies the order for verification of purchased products and evaluation of suppliers.

http://iso9001.devzone.psb/product/purchase/purchase.html

Purchasing

82

The procedure specifies the order in which is performed the System Administration activity in the company.

It also specifies the order for making product backups.

http://iso9001.devzone.psb/product/sysadmin/sysadmin.html

System Administration

83

The procedure describes the process of configuration and change management. It defines the general elements of a product configuration, the way they are stored, and the way they are changed.

It also defines the rules for making product installations, client projects deliveries, build releases, build.xml files, etc. It defines the CVS directory structure of the Source Forge projects.

http://iso9001.devzone.psb/product/ccmp/CCMP.html

Configuration and Change Management Plan

84

Submit Change Request

Analyze Change Request

Rework Change Request

Reject

Implement Changes

Inform Everyone

Scedule Changes

Accept

Change Control

Change Control

85

The procedure describes the order in which documents and records are managed. It specifies the controls needed for documents approval prior issue, documents review and update, identification of changes, legibility and identification, prevention of unintended use of obsolete documents.

http://iso9001.devzone.psb/qms/qms/general/docs.html

Documents Management

86

The internal quality audits are conducted according to Annual Internal Audits Plan. The annual plan covers every element of the quality system, and the audits are made twice a year for each of the elements.

A separate Audit Plan is made for each internal audit that is to be conducted. The plan specifies: the department or team under audit; the audit team; the related ISO 9001 quality procedures; and the audit date and hour.

The results from the internal audits are described in internal audit reports. All the nonconformities found during the audits are described in the report and corrective action reports are generated for all nonconformities. The corrective actions are handled according the Corrective Actions procedure (described in the next point).

The plans and the reports from internal quality audits are stored in the CVS system.

http://iso9001.devzone.psb/measurement/monitor/audit.html

Internal Audits

87

Corrective Actions

The corrective actions within the company are divided in two types:

1) Corrective Actions for eliminating the cause of nonconformities in the product/project (bugs found during the development process or bugs reported by the client).

2) Corrective Actions that for eliminating the cause of nonconformities related to the Quality Management System and the software development process.

For both types of nonconformities Bug Reports are generated. Bug Reports are accessible through the Source Forge Bug Tracking System.

Case 1: the bug is reported in the Bug Tracker for the project and is assigned to the project manager or to another person responsible for the related functionality.

Case 2: the bug (the nonconformity) is reported in the Bug Tracker of the ISO 9001 Source Forge project and is assigned to the Quality Manager, the ISO Documentation Supervisor or another person related to the specific nonconformity area.

http://iso9001.devzone.psb/measurement/improve/correct.html

88

Preventive Actions

Preventive actions usually arise as a result of the Management Reviews, the internal audits or during the software development process, when employees have certain ideas for improvements of the process. Preventive actions are also considered all suggestions related to the product/project, which foresee eventual nonconformities in the product/project that could lead to client dissatisfaction.

The Source Forge Feature Tracking System is the tool used for management of all preventive actions. Each preventive action is reported as a feature request.

The preventive actions related to a product/project area are reported to the Feature Tracker of the project and are assigned to the project manager or to another person responsible for the related functionality.

The preventive actions that are related to the Quality Management System and software process are reported to the Feature Tracker of the ISO 9001 Source Forge project.

The submitter of the feature request checks the status of the preventive action, after the feature request’s resolution is changed to ‘Done’.

http://iso9001.devzone.psb/measurement/improve/prevent.html

89

The section defines the order in which resources are managed. It specifies the management of human resources, i.e. the means to determine the necessary competence of the personnel and the way to provide an adequate training necessary for their work.

It also specifies the infrastructure and the work environment needed to achieve conformity to product requirements.

http://iso9001.devzone.psb/resource/index.html

Resource Management

90

References

Links to procedures, document, blanks, conventions

http://iso9001.devzone.psb/qms/qms/reference.html

91

Thank you!

Pavlin Dobrev, Research and Development Manager

ProSyst Labs EOOD,

48 Vladaiska Str., Sofia, Bulgaria,

Tel. (+359 2) 954 91 62 . Fax. (+359 2) 953 26 17

[email protected]

www.prosyst.com

www.mBeddedServer.com

Contact

1 ProSyst Labs ISO 9001:2000 Quality Management System Pavlin Dobrev Research and Development...

Documents

Transcript of 1 ProSyst Labs ISO 9001:2000 Quality Management System Pavlin Dobrev Research and Development...