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
Requirements Specification
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
Essential Activities
Project Management
Requirements Specification
Requirement Reviewing
Design
Design Reviewing
Programming
Phases - Elaboration
34
Test Design
Test Reviewing
Configuration and Change Management
Phases - Elaboration
35
Phases - Elaboration
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
Phases - Elaboration
37
Requirement Specification Activities
Requirements review is performing
If is necessary, a prototype is creating .
> Input - Software Requirement Specification
> Output - Software Requirement Specification
Phases - Elaboration
38
Requirements Reviewing Activities
Clarifying the project requirements
If is necessary, iterations are made, with the purpose of maximum clarification of the requirements.
> Input - Software Requirement Specification
> Output - Software Requirement Specification
Phases - Elaboration
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.
> Input - Software Requirement Specification
> Output - Software Architecture Document
Phases - Elaboration
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
Phases - Elaboration
41
Programming
If necessary and if an explicit requirement is specified in the SDP, a prototype is created
> Input - Software Requirement Specification
> Output -Prototypes
Phases - Elaboration
42
Test Design The strategy for product testing is defined
> Input - Software Requirement Specification> Output - Test Plan
Phases - Elaboration
43
Test Reviewing The review of the testing strategy is performed
> Input - Test Plan > Output -Review Report
Phases - Elaboration
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
Phases - Elaboration
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.
Phases - Elaboration
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
Essential Activities
Project Management
Requirement Specification
Programming
Design
Design Reviewing
Phases - Construction
47
Test Implementation
Technical writing
Testing
Testing Results Analysis
Code Reviewing
Configuration and Change Management
Phases - Construction
48
Phases - Construction
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
Phases - Construction
50
Requirement Specification Activities If necessary changes in SRS are made.
> Input - Software Requirement Specification> Output - Software Requirement Specification
Phases - Construction
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
Phases - Construction
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
Phases - Construction
53
Design Review Activities Architecture review is performed, if necessary and if specified in the
SDP> Input - Software Architecture Document> Output -Review Report
Phases - Construction
54
Test Implementation Activities The tests planned in the Test Plan are realized
> Input - Test Plan> Output -Test Cases
Phases - Construction
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
Phases - Construction
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
Phases - Construction
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
Phases - Construction
58
Code Reviewing Activities Code Review is made, if required and if specified in the SDP.
> Input - Program Code > Output -Review Report
Phases - Construction
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
Phases - Construction
60
ArtifactsSoftware Development Plan - updated version of the document
Project Schedule - 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
Phases - Construction
61
Objectives
A finishing phase, leading to the final results of the project as they are defined in the SDP
Essential Activities
Project Management
Programming
Test Implementation
Technical writing
Testing
Test Result Analysis
Configuration and Change Management
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
Project Schedule - 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
Requirements Specification
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.
Bug Tracking Guideline
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.
Bug Tracking Guideline
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.
Bug Tracking Guideline
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).
Feature Tracking Guideline
79
Feature Tracking Guideline
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
www.prosyst.com
www.mBeddedServer.com
Contact
Top Related