www.sims.monash.edu.au
IS development:
Quality
Standards
Documentation
IMS9300 IS/IM FUNDAMENTALS
www.sims.monash.edu.au/subjects/ims93002
Lecture Objectives
• At the completion of this topic, you should :– understand the need for, and the role of, quality in systems
development
– be able to define the terms ‘quality’ and ‘standards’;
– be aware of the quality attributes which may be applied to system development products and process;
– be aware of standards and reviews and their relationship to quality
– be familiar with major documents produced in the course of IS development
– understand some major considerations in planning documention
www.sims.monash.edu.au/subjects/ims93003
Some definitions of Quality
• Degree of excellence (Oxford)• Fitness for purpose (AS1057)
– includes quality of design, the degree of conformance to design, it may include such factors as economic or perceived values
• Ability to satisfy stated/implied needs (ISO8402)• Conformance to requirements (Crosby, Horch)
www.sims.monash.edu.au/subjects/ims93004
Determining Quality ..
• when having a meal in a restaurant• when purchasing a car• when buying a computer
The requirements vary immensely, and some of the success measures are very hard to quantify
Quality means different things to different people .. and it varies in different situations
www.sims.monash.edu.au/subjects/ims93005
Why should it concern us?
• Customers expectations and demands are increasing
• Competitors provide it• Substantial savings demonstrated
QUALITY
EFFICIENCY
PRODUCTIVITYCOMPETITIVE POSITION
COST SAVINGS
www.sims.monash.edu.au/subjects/ims93006
• “Effort spent on software maintenance is greater than that spent on software development.”
• “An error is typically 100 times more expensive to correct in the maintenance phase on large projects, than in the requirements phase.”
Boehm, B. (1981) Software Engineering Economics
Error Detection
www.sims.monash.edu.au/subjects/ims93007
Error Detection
The cost of detecting and correcting errors rises greatly during
the systems development cycle.
In addition to this is the cost to the organisation of having an incorrect system
Initiation Analysis Design Implementation
$
www.sims.monash.edu.au/subjects/ims93008
Quality Costs
Review,Inspection,
Re-do,
User complaints, Downtime,Loss of sales, Re-testing,
Re-documenting, Re-training,Overtime, Customer complaints,
Financial losses, Employee turnover
The tip of the Iceberg
The hidden costsof not having quality
Obvious upfront coststo the organisation
www.sims.monash.edu.au/subjects/ims93009
Quality Requirements
• Correctness - Does it accurately do what is intended?
• Reliability - Does it do it right every time?• Efficiency- Does it run as well as it could?• Integrity - Is it precise and unambiguous?• Usability - Is it easy to use?
www.sims.monash.edu.au/subjects/ims930010
Quality Requirements
• Maintainability - Is it easy to fix?• Testability - Is correctness easy to check and
verify?• Flexibility - Is it easy to adapt and extend?• Portability - Can it be easily converted?• Reusability - Does it consist of general purpose
modules?• Interoperability - Will it integrate easily with
other systems?
www.sims.monash.edu.au/subjects/ims930011
The Quality Process
• The quality process involves the functions of:– Quality control - monitoring a process and
eliminating causes of unsatisfactory performance
– Quality assurance - planning and controlling functions required to ensure a quality product or process
www.sims.monash.edu.au/subjects/ims930012
Implementing a Quality System
• Quality must start at the top - Executive sponsorship is vital.
• Everyone must be involved and motivated to realise that they have a responsibility towards the final product, its use, and its quality.
• Improve job processes by using standards, and preparing better documentation (using project control methodologies).
• Use a QA group.• Use reviews.
www.sims.monash.edu.au/subjects/ims930013
Standards
• King’s standard (flag) as a point of reunion in battle (Oxford English Dictionary)
• agreed point of reference
• exemplar of a unit of measure – eg. a measuring rod
• authoritative exemplar of correctness, or
quality
www.sims.monash.edu.au/subjects/ims930014
Standards applied
• Documents/ publications - form, technology• Communication channels - meetings, records
(minutes), information distribution • Security – confidences, privacy, ethics• Behaviour – dress code, punctuality, follow up• Testing/ rigor - analysis, design, software, hardware
agreement to impose standards
www.sims.monash.edu.au/subjects/ims930015
Standards (formal)
• Two levels of standards
– Industry / National / International
– Organisational• Industry (IT procurement)
– Capability Maturity Model (Humphrey 1989)• National / International
– Standards Australia (AS 3563)
– International Standards Organisation (ISO 9000)• Organisational
– The organisation may adopt or tailor industry, national or international standards.
www.sims.monash.edu.au/subjects/ims930016
Other standards in IS Development projects
• deliverable – requires some previous task to have been completed in order for the deliverable to be created
• milestone – indicator (finite document/ finite action) of how far you’ve come, how far to go
www.sims.monash.edu.au/subjects/ims930017
Reviews
• Reviews are used in the quality control and quality assurance functions. There are two main forms of review:– management reviews
– technical reviews
• The review is part of quality control and must produce a report so that the quality assurance function can be satisfied.
www.sims.monash.edu.au/subjects/ims930018
Management or Project Review
• deliverable checked to baseline to see it meets the quality assurance requirements.
• This may involve simply noting that a technical review (meeting quality assurance requirements) has passed a particular deliverable.
www.sims.monash.edu.au/subjects/ims930019
Technical Reviews
• Structured meeting where a piece of work, which has previously been distributed to participants, is checked for errors, omissions, and conformance to standards.
• All deliverables need review. • The report may be a checklist which
indicates that the deliverable passes/fails the quality requirements for that type of deliverable.
www.sims.monash.edu.au/subjects/ims930020
•Not necessarily a piece of paper.•Any permanent medium used to communicate to other people can be classed as documentation
What is documentation?
www.sims.monash.edu.au/subjects/ims930021
Documentation
• to inform – user manual• to communicate – system specifications• to convey knowledge – DFD, ER Diagram• to authorise – credentials, ID• to control or regulate relationships between people
– contracts, task specification• to represent an action or deed – meeting minutes• to provide evidence – system manual
www.sims.monash.edu.au/subjects/ims930022
Typical IS documentation
– Data dictionary
– System specifications
– Feasibility report
– System manual
– Users manual
– Data dictionary
– Process models – DFD
– Data models – database schema
www.sims.monash.edu.au/subjects/ims930023
Documents as deliverables
– Specified document, formal outline, eg. proposal
– Formal detailed requirements within document which must be presented
– Dependent upon underlying tasks being completed in order to create document
– Project management tool
www.sims.monash.edu.au/subjects/ims930024
Bad documentation
– Confusing, inconsistent layout
– Important points buried, not highlighted
– Insufficient reference aids
– Insufficient consideration of the intended audience, purpose
– Use of jargon, without definitions or explanation
– Inappropriate layout for the material being discussed
– Verbose, or too brief
– Difficult to update
– Bulky – overwhelming physical format
www.sims.monash.edu.au/subjects/ims930025
Developing the concept of an audience
• the tone, style, language and emphasis you should use
• the relative level of technological experience
• general background, training, education• possible attitudes towards your message• muticultural backgrounds
www.sims.monash.edu.au/subjects/ims930026
Developing the concept of a purpose
To correctly understand the purpose of a document you need to answer 2 questions:
• What are the specific problems you are addressing?
• What questions will the audience want answered?
www.sims.monash.edu.au/subjects/ims930027
Information Systems Documentation
• User Manual• Systems Manual• Data Manual• Program Specification Manual• Operations Manual
www.sims.monash.edu.au/subjects/ims930028
Good documentation:– reduces the need to refer problems to system
developers– overcomes users’ fears of equipment and software– ensures successful first encounters with a system– enables users to find what they want and
understand it when they find it– is accurate and complete– is written for the intended audience and purpose– has good reference aids (table of contents,
thorough index, cross-referencing)
Good Documentation
www.sims.monash.edu.au/subjects/ims930029
Document organisation - principles
• Make the organisation of material apparent to readers
• Tell them what you are going to tell them before you tell them
• Organise the document in ways expected by readers:
• chronological order• most important to least important• order of need• order of difficulty• question / answer order• alphabetical order
www.sims.monash.edu.au/subjects/ims930030
Planning a Cost-time Schedule for documentation
• Why? - Often documentation is forgotten, ignored or dismissed as not being important.
• Aim - to develop an estimate of the time required for documentation DURING development .. not a trivial task.
• Time vs Cost - be realistic about your estimates ..
• Time saved in the documentation task will be wasted many times over explaining things not included or not clearly described in the documentation provided.
www.sims.monash.edu.au/subjects/ims930031
Reference
• http://www.acs.org.au/national/pospaper/acs131.htm• http://www.iso.ch• WHITTEN, J.L., BENTLEY, L.D. and DITTMAN, K.C. (2001) 5th ed.,
Systems Analysis and Design Methods, Irwin/McGraw-HilI, New York, NY. Chapters 5, 8
• HOFFER, J.A., GEORGE, J.F. and VALACICH (1999) 2nd ed., Modern Systems Analysis and Design, Benjamin/Cummings, Massachusetts.Chapter 9
• ANDERSON, P.V. (1995). Technical writing: A reader-centred approach, 3rd ed. Harcourt, Brace & Co., Fort Worth.
• BROCKMAN, J. R. (1990). Writing better computer user documentation - From paper to hypertext. John Wiley and Sons, Inc., New York.
www.sims.monash.edu.au/subjects/ims930032
References (2)
Standards Association of Australia (1991). Australian Standard 3563.1 -1991: Software Quality Management System. Part 1 Requirements
Standards Association of Australia (1991). Australian Standard 3563.2 -1991: Software Quality Management System. Part 2 Implementation Guide
www.sims.monash.edu.au/subjects/ims930033
ADDITIONAL NOTES
Document planning
www.sims.monash.edu.au/subjects/ims930034
User manual
• Purpose:– a contractual obligation– a marketing tool– a training tool– a reference for non-technical people– a memory in case key staff leave
• Contents:– what the system is about (narrative);– how to use the hardware how to carry out tasks -
details of manual procedures involved; how to enter data, produce output, interpret output;
– how to correct mistakes– how to solve typical problems;– how to ensure security;– how to perform backup and recovery.
www.sims.monash.edu.au/subjects/ims930035
Systems manual
• Purpose:• to enable technical staff to understand the system so that they
can:
– modify the system– evaluate the system’s behaviour– fix errors in the system
• Contents:
– overview of the system– descriptions of all components– system specifications – controls, errors, audit trails.
www.sims.monash.edu.au/subjects/ims930036
• enables (technically-oriented) developers and maintainers to:
– understand what data is used and where.– identify the effects of changes relating to data.
•Contents:– Files - schemas, sub-schemas, file layouts.
– Inputs/Outputs - reports; inputs
– Data Elements
– Data Analysis - logical and physical data model
Data Manual
www.sims.monash.edu.au/subjects/ims930037
Program specification manual
• Purpose:– to support communication between analyst/designer and
programmer;– to describe in detail what the program does
> for initial development;> for maintenance.
• Contents:– design specification (narrative describing the purpose and
general functions of the program),– listing of each program (for maintenance purposes),– layouts of files or database area used, – layouts of screens and reports,– test plan, test data, test conditions, test results
www.sims.monash.edu.au/subjects/ims930038
Operations manual
•Purpose:Large scale systems may need operations support. If so, a separate operations manual is needed to instruct operations staff in operating and controlling the new system.•Contents:
– system overview (purpose/functions of the system)– processing flow– system start-up/shut-down– restart and recovery procedures– security/backup procedures– tape/disk library instructions– user contacts and procedures– priority of jobs– report distribution information
www.sims.monash.edu.au/subjects/ims930039
• Audience - sets the tone, style, language and emphasis
– level of computer sophistication– background, training, or education– attitude towards your message– cultural background
• Purpose - why is the documentation necessary?
– identifies the content– indicates the level of detail required
• Medium
– paper-based manuals and reference cards– on-line documentation– aural and visual training materials
Planning your documentation
www.sims.monash.edu.au/subjects/ims930040
Audience
• Type of documentation Audience
• User Manual users - new, intermediate, experienced
• System Manual client, maintenance team
• Data Manual (Data Dictionary) developers, maintenance team
• Program Manual developers, maintenance team
• Operations Manual operators, technical staff
www.sims.monash.edu.au/subjects/ims930041
Documentation organisation
• Chunking - the rule of seven • Titles - briefly describe upcoming information• Relevance - put related information together• Consistency – style, voice, emotion• Hierarchy of structure - Chapters, Sections, Topics• Integrated graphics – appropriate, support text• Accessible detail - access routes to different levels
of detail (overall/general, specific, fine detail)
www.sims.monash.edu.au/subjects/ims930042
• Manuals– Most common ... not good for trivial problems.
• Brochures– Main capabilities are highlighted ... emphasises
simplicity and elegance, not the detail of manuals. 4 - 8 pages fully describing the system.
• Quick reference guides– 90% of the time 90% of the needs of 90% of the
readers can be met by a simple summary card.• On-line help
– Ideal reminders ... useful as an aid for experienced user BUT are not a replacement for manuals
Choose appropriate media
www.sims.monash.edu.au/subjects/ims930043
Online vs paper-based documentation
• Online easier to distribute and maintain• Printing costs reduced• Online enables different search paths to the same
information• Easier for user to become disoriented• Online documentation must be written differently• Online documentation must be consistent with paper-
based documentation
www.sims.monash.edu.au/subjects/ims930044
Reference Aids
• Information contained in a large, complex document is often inaccessible
• Use:– Glossaries
– Indexes (very important)
– Contents page
– Others
• Numbering systems• Page, Sections, paragraphs, items• Section dividers - tabbed card, coloured pages, • Section/chapter summaries
www.sims.monash.edu.au/subjects/ims930045
Colour and graphics
• Use a minimum number of colours• Be consistent and familiar (eg. red for hot) in your use of colour
codes• Don't rely on colour alone to discriminate between items
• Graphics can make a document more effective:
– points in a text can be emphasised
– can increase reader's interest
– can replace, clarify or simplify the text
www.sims.monash.edu.au/subjects/ims930046
Layout and Pagination
• Layout:– Be consistent in your layout
– Use type size (at least 4 points different) or bolding to indicate relative importance or weight
• Page:
– Use a page size suited to the environment that the document is going to be used in
– Make sure page numbering is clear
www.sims.monash.edu.au/subjects/ims930047
Specify the document
Draft and edit the document
Review the document
Publish the document
Maintain the document
Not OK
OK
The Documentation Process
www.sims.monash.edu.au/subjects/ims930048
Effective documentation check list
• Objective clearly stated• Target audience identified• Consistent approach used (wording, structure,
layout) - templates help• The principles of documentation organisation
and development have been followed • Maintenance process in place• Put yourself in the users’ position - can you
easily find what you’re looking for?
Top Related