The purpose of this document is to define the Context of Cain Motors Information System in order to form the basis for the Information System and assessment of the success of the project.
Quality Management Assignment Frisby, Fuller, Hanson and Shirley
Quality Management Assignment
Cain Motors
Debra Frisby
Karen Fuller
Janet Hansen
Steven Shirley
Contents
11.2. Raising Issues
11.3. Issue Log
15.6.1. Use Case Ranking
16.1.1. Class Diagram
Introduction
1.1 The purpose of this document is to define the Context of Cain Motors Information System in order to form the basis for the Information System and assessment of the success of the project.
1.2 This document will allow the Project Board to ensure the project has a sound basis before making a major commitment to the project. It will act as a base document against which the Project Board and Project Manager can assess progress, change management issues, and on-going viability issues.
- Approval of the Project Initiation Document (PID) is sought from the Project Board, together with authorisation to proceed with the next stage of the project.
Business Case
There are eight main stages to using PRINCE2 Quality Management, which is the system we will be using to develop this project.
Cain Motors is a small garage in the east end of London situated under the railway arches. The garage has been running for thirty years and relies mainly on word of mouth and passing trade for its business. It deals with car repairs, MOT’s, servicing and insurance work. There are a total of four workers including the owner Mr Cain.
- Aim of Project
Last year we were brought into update the system from a manual system to a computerised system, which we did but Mr Cain has called us back to update the system and to redevelop the existing information processing system at Cain Motors to resolve defects highlighted by users and Mr Cain, the project will also incorporate certain changes requested by users of the present information system such as to be able to produce a complete MOT history, to produce invoices, web site for advertising and booking appointments (MOT, crash repairs and servicing). Mr Cain has decided to store stock on the premises; therefore he now requires a facility for stock monitoring i.e. a stock table added to the database so he can keep track of what needs to be reordered and what has to be used.
- Importance of Achieving Project Aims
The project aims to provide an information system that will assist staff in the day-to-day operations of Cain Motors, providing an efficient computer system, which reliably and securely stores information manages stock control, customer information and MOT service history.
If the aim of the project if achieved it will make the business more efficient, it will cut down on lost time, because everything should be on the computerised system, which means the company will on lost man hours.
Project Definition
The identified defects are listed below, also the desired improvements
- Changes
Managing change is fundamental to the successful completion of any project. The change management process ensures that each change included within the project, is defined, justifiable and evaluated prior to implementation. Change Requestor
The Change Requestor initially recognises a need for change to the project and formally communicates this requirement. The Change Requestor is formally responsible for:
- The early identification of a need to make a change to the project
- The formal documentation of that need, through the completion of a Change Request Form
- The submission of the Change Request Form to the project board for review
- Change request/evaluation
- Change request number 2
The request to develop an interactive web site for the purpose of advertising and booking appointment for MOT’s, servicing and crash repairs.
The project board for a number of reasons has rejected the request for change:
Whilst the business drivers for this change certainly make it viable to develop this change further. The cost implications do not make the change justifiable at the present moment for a number of reasons:
The need to purchase or lease new hardware to support and on-line booking ...
This is a preview of the whole essay
- Change request/evaluation
- Change request number 2
The request to develop an interactive web site for the purpose of advertising and booking appointment for MOT’s, servicing and crash repairs.
The project board for a number of reasons has rejected the request for change:
Whilst the business drivers for this change certainly make it viable to develop this change further. The cost implications do not make the change justifiable at the present moment for a number of reasons:
The need to purchase or lease new hardware to support and on-line booking system. At present there are not available funds to support this change. Mr Cain has request the database system to be change to support, monitor and control the supplying of stock to be held on the premises. The project board has approved this change, since Cain this is a new venture a large amount of stock is being order in, there large amount of available capital is being channelled into that.
Software development will have to be contracted out to a web site developer, to develop the web site. Again this will incur some costs. Time constraints applied by the project board for the completion of any requests for change do allow adequate time to undertake a through system analysis and complete the work. The project board have decided that there is not sufficient time to complete this change on this occasion or the necessary funds to support it.
- Change request Number 5
The request to redevelop/redefine the MOT search history Query within the application.
The project board have rejected this request for change for a number of reasons:
The defect to be resolved requires the application software vendor to develop an update version of the Cain Motors database redesigning the conceptual layer to search the database and achieved the desired results.
Since at present a large volume of available business capital is being channelled into the new stock system there is at present no available funds to contract Mrs Frisby to develop a new version of the database.
Time constraints applied by the project board to complete any approved request for change do allow sufficient time for this change further at the present time.
- Change request Number 6
The request to redevelop/redefine some users views within the application front end application to print a report rather than taking a screen print of the open window when the print function is executed.
The project board have rejected this request for change for a number of reasons:
The defect to be resolved requires the application software vendor to develop an update version of the Cain Motors database redesigning the user views to print a professional document displaying they required information.
Since at present a large volume of available business capital is being channelled into the new stock system there is at present no available funds to contract Mrs Frisby to develop a new version of the database application.
The change requested is purely cosmetic and the print function does give information that is required, just not in a format that the user might expect. This change is not essential to maintain competitiveness with other garages.
Time constraints applied by the project board to complete any approved request for change do allow sufficient time for this change further at the present time.
- Change request Number 7
The request to redevelop/redefine the delete functions within the database application user views.
The project board have rejected this request for change for a number of reasons:
The defect to be resolved requires the application software vendor to develop an update version of the Cain Motors database redesigning the conceptual layer to search the database and achieved the desired results.
Since at present a large volume of available business capital is being channelled into the new stock system there is at present no available funds to contract Mrs Frisby to develop a new version of the database.
Time constraints applied by the project board to complete any approved request for change do allow sufficient time for this change further at the present time.
Project Plan
Changing the System Analysis
In the previous version, version1 of the project SSADM was used. Short for Structured Systems Analysis and Design Method, a set of standards developed in the early 1980s for systems analysis and application design widely used for government computing projects in the United Kingdom. SSADM uses a combination of text and diagrams throughout the whole life cycle of a system design, from the initial design idea to the actual physical design of the application.
SSADM uses a combination of three techniques:
- Logical Data Modelling -- the process of identifying, modelling and documenting the data requirements of the system being designed. The data is separated into entities (things about which a business needs to record information) and relationships (the associations between the entities.
- Data Flow Modelling -- the process of identifying, modelling and documenting how data moves around an information system. Data Flow Modelling examines processes (activities that transform data from one form to another), data stores (the holding areas for data), external entities (what sends data into a system or receives data from a system, and data flows (routes by which data can flow).
- Entity Behaviour Modelling -- the process of identifying, modelling and documenting the events that affects each entity and the sequence in which these events occur.
Each of these three system models provides a different viewpoint of the same system, and each viewpoint is required to form a complete model of the system being designed. The three techniques are cross-referenced against each other to ensure the completeness and accuracy of the whole application.
SSADM application development projects are divided into five modules that are further broken down into a hierarchy of stages, steps and tasks:
- Feasibility Study -- the business area is analysed to determine whether a system can cost effectively support the business requirements.
- Requirements Analysis -- the requirements of the system to be developed are identified and the current business environment is modelled in terms of the processes carried out and the data structures involved.
- Requirements Specification -- detailed functional and non-functional requirements are identified and new techniques are introduced to define the required processing and data structures.
- Logical System Specification -- technical systems options are produced and the logical design of update and enquiry processing and system dialogues.
- Physical Design -- a physical database design and a set of program specifications are created using the logical system specification and technical system specification.
In this version of the Project for Mr Cain we will use a system recommended by PRINCE2 when using their Project Management system
Rational Rose.
- Rational Rose
In accordance with PRINCE 2 quality management principles we will be following the rational unified process of system analysis in version 2 of Cain Motors Information System.
System Analysis with Rational Rose
Rational Unified Process - (RUP) provides a disciplined approach to assigning tasks and responsibilities within a development organisation. Its goal is to produce high quality software that meets the needs of it’s end-users within a predictable schedule and budget.
RUP allows and makes use of team member environments, by allowing every team member access to a knowledge base with guidelines, templates and tool mentors for all critical development activities. The advantage to this environment, no matter what role you play within the team, is that all team members share a common language, process and view of how to develop software.
RUP is based on the Unified Modelling Language – (UML). RUP is more interested in creating and maintaining models, rather that focusing on large amounts of paper documents as with SSADM. The idea is that from the start you can create small components within a given time scale.
With RUP they do not produce DFD’s, but they do produce “Use Case Diagrams”, these consist of an “Actor” and a “Use Case” and this will give a general view of the system.
There are four phases to the process with major milestone to each individual phase.
- Inception Phase
During the Inception phase, you establish the justification for the system along with any boundaries. To achieve this, actors of the system (roles not physical users) must be investigated and defined at a high level.
The business case is a report that is written in order to justify why the business should do something, this might include, making money, saving money or complying with some industry requirement. It would also include risk assessment and resources needed and would also include the success criteria.
Some of the outcomes of the Inception phase would be
- Initial “Use-Case Model” (10 – 20% complete)
- Initial Business Case
- Project plan showing phases and Iterations
- Elaboration Phase
Identify all requirements, organising by level of complication, its risk of failure and the stability of the requirement (i.e. how likely is this requirement to change). Iterations are then planned based on removing the riskiest requirements first then if the project is to fail it will fail quickly and early. RUP is architecture-centric, this basically means a lot of effort goes into infrastructure, re-use and low maintenance. At the end of this phase the architecture would be fully defined.
Some of the outcomes of the elaboration phase would be
- A software architecture description.
- An executable architectural prototype.
- A mostly complete use-case model (80% complete).
- Construction Phase
During the construction phase you schedule which use cases are to be implemented within which iteration. There will be a number of iterations within this phase, as there was for the elaboration phase. At the end of each Iteration there will be an executable release of the project (even is this is not sent to clients). Each of the use cases will be tested against it’s original requirements.
Some of the outcomes of the construction phase would be
- A product ready for the end users.
- User manuals.
- Transition Phase
The purpose of the transition phase is to deploy the product to the user community. It is once this transition has taken place that issues arise for development of further releases, iterations finish the features that were delayed and correct any problems that may arise. This phase may also include many iteration and can be anything from simple to extremely complex depending on the product that was required.
The primary objectives for the transition phase would be
- User self-supportability.
- Achieving stakeholder agreement that deployment baselines are complete and consistent with the overall criteria.
- Achieving final product baseline as rapidly and cost effectively as practical.
- Iterations
Each phase in RUP can be further broken down into iterations. An iteration is a complete development loop resulting in a release (Internal/External) of an executable product.
- Benefits of an Iterative Approach
Compared to the traditional waterfall process, the iterative process has the following advantages.
- Risks are mitigated earlier.
- Change is more manageable.
- Higher level of reuse.
- The project team can learn along the way.
- Better overall quality.
The Rational Unified Process is not based on a strict waterfall model, but is based around a number of mini-waterfall iterations within four phases.
The Iterative Model graph shows how the process is structured along two dimensions.
- The Architecture of Software Systems
The 4+1 architectural view – shows that RUP is Use Case driven
End User Programmer
Functionality Software Management
Designers/Testers
Behaviour
System Integrators System Engineering
Performance System topology
Scalability Delivery, installation
Throughput Communication
Example of a Use Case Diagram
(Example adapted from Prudential-Bache market research)
Each of the actors would be defined within the UML documentation, including a description of what the role is. Each of the use cases would be expanded into separate documents, which consists of a “happy days” basic flow of events, which provides a simple means of understanding what the use case should be doing. A set of alternate flows will also then be defined, providing the exceptions and conditional events that would also be part of the use case. Use cases are not data flow diagrams and do not define the flow of data. They define the interaction between actors and entities within the system.
- Appropriate SDLC Use and History
SSADM was originally developed during the host-based era of computing (i.e. mainframes). This is the time when computing was expensive and development slow, often requiring very large teams, which is quite rare within modern environments. It is with this backdrop that SSADM was developed, providing a strict framework in which to fully analyse a system before construction begins (often taking months or years).
SSADM is still used within some environments and is popular within government and some large organisations. It has the advantage of being a strict set of guidelines, which can be followed and managed. In the case of maintaining existing systems (perhaps mainframe systems which were originally developed with SSADM), then this provides a consistent and well-documented approach to continued development. It is a strict waterfall method, where the downstream phases are significant and long winded.
The main disadvantage of SSADM is the obvious time delay. Given the highly formal approach used and large number of non-functional artefacts produced, it is very expensive. Further to this, even though a large amount of investment will have been committed to the project during this analysis phase, none of the project risk will have been addressed. This can therefore result in spectacular project failures, where many years of work are finally abandoned because of some high-risk item that finally brought the project down in the latter stages.
The Rational Unified Process was developed from the modelling languages (eventually unified as UML) produced by a number of object-oriented industry leaders (Booch, Rumbaugh and Jackobson). The commercial company of Rational, produce a number of tools (such as Rational Rose) for producing these models (competitors include Select OMT and Visual UML). It also provides a framework and set of best practises, which is known as the Unified Process.
The advantage of the Unified Process (and its associated modelling tools) is that it aims to identify risk and address it early in the project life cycle. This does not mean a project is guaranteed not to fail, it just means that a project destined to fail will do so earlier and more cheaply. The life cycle is not made up with a single large and rigid waterfall model, instead it uses a large number of smaller “mini-waterfalls” within iterations with each producing an executable, in a similar way to the RAD methodology that was popular in the client/server era. The main difference to RAD is that the executable produced is based around the chosen architecture and not a “throw” away implementation. This is a achieved by implementing distinct “use cases” and using an n-tier component-based architecture.
The main disadvantage of the Unified Process is that it is depend on modern object –oriented, component based n-tier technologies. It does not lend itself well to the host-driven computing that SSADM was originally designed for.
- Redefined Terms of Reference
- Cain Motors is a small garage owned solely by Mr Barry Cain, at present it is run on a small-computerised system. Mr Cain had the system changed from a manual to system to a computerised system in June 2002, he feels that the main reason for the computer system is to organise the paper work and optimise the customer information and to increase the workflow. The garage has a steady turn over and has been in business for thirty years, but still has a lot of unutilised resources. The new system proved to have a few problems, so Mr Cain called us into upgrade the system, so that a full MOT history can be shown and stock details can be shown and estimates can be produced and stored on the computer.
- The hardware needed is already in place and available for use at the garage and will not incur any additional cost to Mr Cain as he has already paid for the equipment.
- The garage currently has one PC which will be adequate to run the new system, the current hardware consists of:
- Computer
- Monitor
- Scanner
- Fax
- Photo Copier
- 4 gigabyte hard drive
- 64 mb of RAM
- 32 bit file system
- 32 bit virtual memory
- Removable drive for back up
- I discussed with Mr Cain the feasibility of buying a new system, prior to implementing version, but after looking into the cost of a new system, it was decided that as the present system was adequate enough to run the new database that it would not be a viable outlay, but could be considered at later stage if needed. Once again we discussed with Mr Cain the possibility of upgrading the computer system, but Mr Cain felt that it would be unnecessary expense.
- Mr Cain will also be responsible for maintaining the hardware as it is already supplied and has a maintenance contract.
- The new system should consist of a computer system that should be able to store lists of customers and stock levels and suppliers, store records of all vehicles that the garage deals with, it should be able to produce estimates and invoices.
- It should be able to run searches, produce reports and add, delete records and query dates and vehicle records, so that reminders can be sent to customers.
- Training will be given to Mr Cain and his employees individually so that they understand how to use the new system.
- The system will be password protected to stop unauthorised use, all employees will be able to update records and delete them, but no one except Mr Cain will have access to the staff records.
- It has been agreed that the system will be finished and installed by the 30th March 2003 and that Mr Cain will have paid his account in full by the 31st April 2003.
Feasibility Study
- Technically Feasible
The project is technically feasible because the hardware Mr Cain already has at the garage can be used for an information system, it will meet the needs of the system that is required, the staff are all computer literate and with a some extra training should be able to work the upgraded system.
The overall cost of the upgraded system will cost less than time wasted in manual searches for MOT histories
The solution to the company’s problem is to upgrade the computer system so that it can store the full MOT history, Servicing history, Customer details, to be able to find out when a customer last had a service or MOT and to be able to offer them special offers if they return to the garage to have there next service or MOT done.
An upgraded computerised system is recommended because:
- The business is growing and more MOT’s are coming in every month, there is more paper work to manage all the time as new rules are being introduced for MOT’s and more information has to be stored.
The main objectives for upgrading computerisation are the following:
The garage needs a system that can run searches, so that cars can be looked up by their registration number to find dates of all MOT’s that the vehicle has had at the garage, and to be able to run a search for all the cars that were serviced the same month the year before so reminders can be sent out to customers and local garages.
- Economical Feasibility
The present computing facilities that are at the garage are adequate for the needs of the upgraded system that Cain Motors require. There’s also an adequate power supply to run the system so no electrical points will need to be added. There is plenty of space on the Hard Drive and the memory is large enough for their needs.
- 350 mhz processor
- 4 gigabyte hard drive
- 64 mb of RAM
- 32 bit file system
- 32 bit virtual memory
Apart from the actual cost of having the system redesigned there should be no outlay required for equipment and software.
- Social Feasibility
At present there are only four people working at the garage and they will all need to use the system. Having spoken to the garage employee’s I don’t think they will have any problem adapting to the upgraded system as they are all computer literate, and have a good knowledge of computer software and how it works. They all know how to use the hardware and the present system. Some personnel training should bring them up to date with the new version of the system, each employee will still have a password, and Mr Cain only will have access to the staff records.
Project Organisation
This will consist of the customer or an Executive from the company, someone who will represent the User side and someone to represent the supplier or specialist input. When using Prince 2, these people are known as Customer, Senior User and Senior Supplier.
Project Management Board Customer Mr B Cain
Senior User Mr B Frisby
Senior Supplier Mrs Karen Fuller
Project Board. The project board is responsible for the ultimate outcome of the project. At the outset it approves the project scope. It also approves products delivered at the end of each stage (it may delegate product assurance as appropriate) and authorises the launch of subsequent stages. This provides the primary means for the project board to ensure that the project remains on track. The project manager periodically reports project progress to the project board. The board is responsible for resolving material issues impacting project scope (cost, delivery date, end products, staffing, other resources) brought to its attention by the project manager.
Formal project board meetings should be linked to key events:
• Project Initiation at which the project initiation document is approved
• End Stage Assessments at which the products delivered for that stage are approved. (Products are quality assured against previously agreed specifications).
• Project Closure.
The project manager also conducts checkpoint reviews with project personnel to monitor progress. These form the basis for periodic Highlight Reports issued to inform the project board of progress.
- Project Manager
The Project Manager will select people to do the work on the project and will be responsible for making sure that the work is done properly and completed on time. The Project Manager draws up the plans that describe what the team will actually be doing and when they are expected to finish.
The Project Manager reports regularly to the Project Management board keeping them informed of progress and highlighting any problems he can foresee. The project manager refers matters that will materially impact the scope of the project (products, completion date, cost or personnel) to the project board for resolution.
The Project Board is responsible for providing the Project Manager with the necessary decisions for the project to proceed and to overcome any problems. The project manager is responsible for planning (what will be done) and scheduling (when it will be done and by who), tracking progress and monitoring budgets. The project manager takes day-to-day operational decisions but remains accountable to the project board. The project manager refers matters that will materially impact the scope of the project (products, completion date, cost or personnel) to the project board for resolution.
Role Description
Key Roles & Responsibilities
Key roles and responsibilities should be defined so that all those involved in the project understand the contribution they are expected to make and how this relates to other roles. This interim organisational structure, which is distinct from the organisation applying for business as usual, is established for the duration of the project and disbanded at the end of the project. The roles include:
• Project Board. The project board is responsible for the ultimate outcome of the project. At the outset it approves the project scope. It also approves products delivered at the end of each stage (it may delegate product assurance as appropriate) and authorises the launch of subsequent stages. This provides the primary means for the project board to ensure that the project remains on track. The project manager periodically reports project progress to the project board. The board is responsible for resolving material issues impacting project scope (cost, delivery date, end products, staffing and other resources) brought to its attention by the project manager.
• Project Manager. The project manager is responsible for planning (what will be done) and scheduling (when it will be done and by who), tracking progress and monitoring budgets. The project manager takes day-to-day operational decisions but remains accountable to the project board. The project manager refers matters that will materially impact the scope of the project (products, completion date, cost or personnel) to the project board for resolution.
• Executive. The Executive (or customer) is the person who commissions and authorises the project. The executive is a member of the project board.
• User. The User is the person who will use the result of the project. A User representative is a member of the project board.
• Supplier. The Supplier (or specialist) provides the expertise necessary to do the work. The Supplier is represented on the on the project board.
• Task Manager. The Task Manager is responsible for managing a particular task assigned to him. The Task Manager reports to the project manager in respect of the relevant task.
ROLE DESCRIPTION
Role:
Name:
Prime responsibility:
Responsible to:
Specific Responsibilities:
Project Manager (Executive)
Mr Steven Shirley
The Executive is ultimately responsible for the project, supported by the Senior User and Senior Supplier. The Executive has to ensure that the project is value for money, ensuring a cost-conscious approach to the project, balancing the demands of business, User and Supplier.
Throughout the project, the Executive "owns" the Business Justification.
Cain Motors
- Ensure a tolerance is set for the project;
- Authorise Customer expenditure and set Stage tolerances;
- Approve the End Project Report and Lessons Learned Report;
- Brief Cain Motors about project progress;
- Organise and chair Project Board meetings;
- Recommend future action on the project if tolerances are exceeded;
- Approve the sending of the notification of project closure to corporate or programme Management;
- Overall business assurance, i.e. ensuring that the project remains on target to deliver products which will achieve the expected business benefits, and the project will complete within the agreed tolerances for budget and timescale.
ROLE DESCRIPTION
Role:
Constituency
Owner
Manager
Prime responsibility:
Responsible to:
Specific Responsibilities:
Senior Users
Individuals
Mr Barry Cain
Mr Brian Frisby
The Senior Users are responsible for the specification of the needs of all those who will use the final product, User liaison with the Project Team, and for monitoring that the solution will meet user needs within the constraints of the Business Justification.
The role represents the interests of all those who will use the final products, those for whom the product will achieve an objective, or those who will use the project to deliver benefits. The Senior User role commits User resources, and monitors products against requirements.
Each Senior User will be responsible for representing the particular user constituencies as listed above:
Executive Board
- Ensure the desired outcome of the project is specified;
- Make sure the progress towards the outcome required by Users remains consistent from the User perspective;
- Promote and maintain focus on the desired project outcome;
- Ensure that any User resources required for the project are made available;
- Approve Product Descriptions and ensure that products are signed off once completed;
ROLE DESCRIPTION
Role:
Name:
Prime responsibility:
Responsible to:
Specific Responsibilities:
Senior Supplier
Mrs Karen Fuller
Miss Janet Hanson
Mrs Debra Frisby
Represent the interests of those designing, developing, facilitating, procuring, implementing, operating and maintaining the project products. Has the authority to commit or acquire Supplier resources.
Executive
- Agree objectives for specialist activities;
- Make sure progress towards the outcome remains consistent from the Supplier perspective;
- Promote and maintain focus on the desired outcome from the point of view of Supplier management;
- Ensure the Supplier resources required for the project are made available;
- Approve Product descriptions for specialist products;
- Contribute Supplier opinions on whether to implement recommendations on proposed changer;
- Resolve Supplier requirements and priority conflicts;
- Brief non-technical management on specialist aspects of the project;
- Advise on the selection of specialist strategy, design, and methods;
- Ensure that any specialist and operating standards defined for the project are met and used to good effect;
- Correctness, completeness, and integrity of
Risk Management
Projects always imply uncertainty – and uncertainty always implies risk. The outcome of any project is never a foregone conclusion and project sponsors must understand that when they invest in a project they are, in effect, gambling.
One of the few certainties about projects is that they will involve risk and because of this those risks need to be planned for and managed in a rational and methodical manner.
Risks are the possible occurrence of events that could have a beneficial or adverse effect on a project.
- In PRINCE there are two types of Risk:
- Business e.g.:
- Market change
- Legislation
- Project e.g.:
- Poor performance of a 3rd party supplier
- Resource performance levels
- Problems regarding quality checking
- Risk analysis includes:
- Risk identification i.e. potential risks
- Risk estimation i.e. importance of each risk
- Risk evaluation i.e. determine if the risk is acceptable if not what needs to be done to make it acceptable
- Risk actions (to make the risk acceptable) include:
- Prevention - using counter measures
- Reduction - reduce the likelihood of the risk
- Transference - pass to a third party (insurance company or penalty clause)
- Contingency - planned and organised to come into force as and when the risk occurs
- Acceptance - Project Board decides to go ahead and accept the risk (perhaps the counter measures are too expensive)
- Risks File
- Risk Log
Quality Assurance
Quality Management has to adhere to ISO 9001 and standards if the organisation is following the principles of PRINCE2.
ISO 9001:2000 is an internationally recognised Standard. It is a document, which defines the elements of organisation required by a company to operate & maintain a Quality Management System, i.e. Management Responsibility, Resource Management, Product Realisation, Measurement, Analysis & Improvement.
For the purpose of Accreditation a company must document its practices in a Quality Manual, defining its operating procedures, objectives and policy for achieving them, these documents are assessed to ensure they fulfil the criteria of the standard & satisfactorily envelop all elements of the companies operations. When the documentation is found satisfactory, the company is then audited to ensure they are complying with all elements of their documentation, and that there system is successfully managing all aspects of their business. On satisfactory conclusion of this process a company is certificated, accredited with operating to a system which is compliant to the essence of the ISO 9001:2000 Standard.
Companies are reassessed annually to ensure they are maintaining their system in compliance with the Standard.
Issue Management Process
The Issue Management process is fundamental to the successful delivery of the project. The Issue Management process ensures that each issue identified within the project environment is documented, prioritised and resolved within an appropriate timescale. For the purpose of this project, issues are defined as “any event, which currently adversely affects the ability of the project to produce the required deliverables”.
- Issue Procedures
The following diagram provides an overview of the issue processes and procedures to be undertaken in order to effectively manage project-related issues. Issue Management roles have also been allocated.
- Raising Issues
This process provides the ability for any member of the project team to raise a project-related issue. The following procedures are undertaken:
- Issue Originator identifies an issue applicable to a particular aspect of the project (e.g. scope, deliverables, timescales, organisation).
- Issue Originator completes an Issue Form and distributes the form to the Project Manager.
- Issue Log
This process allows the Project Manager to review all issues raised and determine whether or not each issue is applicable to the project. This decision will be primarily based upon whether or not the issue:
- Impacts a project deliverable specified within the project deliverables register
- Impacts a quality deliverable specified within the quality plan
- Impacts the timescale specified within the project plan
If the issue is considered by the Project Manager to be ‘appropriate to the project’, then a formal issue is raised in the Project Issue Register and an issue number assigned. The Project Manager will furthermore assign an issue ‘priority’ based upon the level of impact of the issue to the project.
Version Control
Where products go through draft stages, or are updated for any other reason, a version control system ensures that everyone is working to the same document version by:
- Product identification (as above)
- Maintaining a document register
- Notifying recipients of product changes
- Product Identification
Each product is identified within itself by:
- An identifier and title
- File identification
- Its current version and revision history
- Date produced or last revise
Distribution Quality Management Project
Version Control
Approval
- Distribution Case Diagram
Version Control
Approval
- Distribution Class Diagram
Version Control
Approval
Revised Systems Analysis of Cain Motors
The use of the unified modeling language enables an iterative/incremental approach to system analysis. This iterative and incremental process is risk-driven which means that each new release is focused on attacking and reducing the most significant risks to the success of the project.
There are four phases in the software development lifecycle:
- Inception
- Elaboration
- Construction
- Transition
A phase is the span of time between two major milestones of the process, when a set of objectives is met and completed decisions will then be made whether to move in the next phase. Within the iteration of each phase, a number of “artifacts” would be produced, which would take the form of documents
The roles used within a project following the Rational Unified process fall into the categories of:
- Analysts
- Developers
- Testers
- Managers
By concentrating on addressing risks, the lifecycle can be seen to compare to the traditional waterfall lifecycle as follows:
Integration is not one "big bang" at the end—elements are incorporated progressively. In reality, the iterative approach is an almost continuous integration. What was hard to plan accurately can now be divided into a number of smaller integrations that start with far fewer elements to integrate.
Inception
During the first stage this would be where you would establish the business case for the system and delimit the projects scope. The business case would include success criteria, risk assessment; estimates of the resources needed and a phase plan showing a schedule of major milestones. During inception, it’s common to create an executable prototype that serves as a proof of concept.
This phase would be where the Cain Motors Feasibility study would sit. Under this phase you would have:
- Technical Feasibility
- Backup and Recovery Scenario
- Economical Feasibility
- Discussions on hardware already available
- Platforms to be used (Software, Operating systems)
- Social Feasibility
- Terms of Reference
- Company Hierarchy Diagram
Along with the above headings it would be good practice to include a prototype or maybe a storyboard, which would act as the proof of concept by laying out the various layer and stages of how the project may take form. This phase is where all future requirements and expectations of the project to be undertaken should take place and be fully documented. It is as this stage draws to conclusion, that you can fully examine the life cycle objectives of the project and decide whether to proceed with the full-scale development.
Using the Unified Modeling Language (UML) rational rose life cycle, it would be at this stage that it would be wise to mention future developments. Although Cain Motors is only one garage at present, developing this new system, so that Cain Motors became computerized, would also lead to maybe future iterations of a presence on the WWW. This would allow new growth in the business, as it would almost be used as a way of advertising the business.
Elaboration
The second stage is where you analyze the problems and establish a sound architectural foundation. It is during this stage that you would develop the project plan and eliminate the highest risk elements of the project. Architectural decisions must be made with an understanding of the whole system; this is where you would describe most of the systems requirements. To verify the architecture of the project use case diagrams would be used to demonstrate the architectural choices of the project.
This phase would be where Cain Motors System Analysis would sit. Under this phase you would have:
- Systems Investigation report
- MOT Tester report
- Insurance Work
- Services
- Recommendations for new system
- Design/Architecture of Information System (Database, including ERD and normalisation)
- Design/Architecture of User Interface (include Storyboarding)
Although there were several data flow diagrams within the original Cain Motors document, these would need to be replaced with use case diagrams, both low and high level that would document the flow of work. Below is a use case diagram for Cain Motors.
Each of the use cases would be defined within these iterations with an overall use case diagram along with the basic and alternate flows for each of the use cases them selves. In addition, the use cases would be ranked in terms of level of risk and level of complexity.
In this way the high-risk and high-complexity use cases should start to be implemented within these elaboration iterations, with the next highest risk/complexity use cases being implemented in the first iterations of the construction phase. This is fundamental to the lifecycle of the Rational Unified Process, in that if the project is going to fail, it should do so as early in the lifecycle as possible.
Case diagram version1.1
The use case diagram uses the Actor (person) to represent a role. A physical person may encompass more than one Actor (role). The elliptical shape represents the processes that are taken by each Actor.
- Make Appointment Use case
Basic Flow (Happy days flow)
- Customer Contacts Garage
- Customer Suggest Time/Date
- Administration looks up calendar
- Administration books appointment (date/time)
Alternate Flows
Time Conflict:
- Find Closest time/date
- Suggests time to customer
- Repeat above steps until agreement
Walk In Conflict:
- No appointments available for walk ins (booked up)
- Suggest another time
- Book appointment
- Make Payment Use case
Basic Flow (Happy days flow)
- Identify if payment is for Service/MOT
- Customer pays account in full
- Customer receives receipt
Alternate Flows
Payment Type:
- Payment made with cash
- Or Payment made with Visa/Master Card
- Or Payment made by cheque
Partial Payment:
- Deposit paid (Partial payment)
- Or Balance paid (balance owed after deposit)
- Customer receives receipt
Insurance Payment:
- Customer pays excess amount agreed by Insurance Company
- Insurance company pay balance
- MOT Cars Use Case
Basic Flow (Happy days flow)
- Car arrives for MOT or Re-test
- MOT or Re-test is carried out
Alternate Flows
Time Conflict:
- Car does not arrive on time for MOT or Re-test
- Re-book MOT or Re-test (or customer waits for time slot)
Cancellation:
- MOT or re-test cancelled
- Remove from appointments
- Service Repairs Use Case
Basic Flow (Happy days flow)
- Car arrives for service or repairs
- Car is serviced or repaired
- Mechanic logs work done and time taken
Alternate Flows
Time Conflict:
- Car arrives late for service or repairs
- Re-book service or repairs
Cancellation:
- Scheduled Service or repairs is cancelled
- Remove from appointments
Insurance work:
- Estimate is made for work
- Copy of estimate given to customer, another copy filed
- If go ahead given by Insurance Company, then begin basic flow
- Generate Invoice Use Case
Basic Flow (Happy days flow)
- Look up transaction details
- Generate report of Invoice with copies
- Give copy of Invoice to customer
- File Garage copy
Alternate Flows
Missing Transaction:
- Query details with mechanic
- MOT Certificate Use Case
Basic Flow (Happy days flow)
- Look up MOT details
- Enter details in MOT Book
- Issue MOT certificate
Alternate Flows
MOT Failure:
- Car failed MOT
- VT30 Certificate issued
MOT Repairs:
- Book car in for MOT repairs
- Use Case Ranking
The use cases are ranked by complexity and risk as follows:
Use Case Complexity Risk
Make Payment Medium Medium
Service Repairs Low Low
MOT Car Medium Low
Make Appointment High High
Generate Invoice Medium Low
MOT Certificate High Medium
From this initial assessment of complexity and risk ranking, we recommend that the use cases be implemented in the following order:
1. Make Appointment
2. MOT Certificate
3. Make Payment
4. MOT Car
5. Generate Invoice
6. Service Repairs
At the end of the elaboration phase, the detailed system objectives and scope would be examined, along with the choice of architecture and resolution for major risks, and a decision made whether to continue with an investment into the construction phase.
Construction
The goal of the construction phase is on clarifying the remaining requirements and completing the development of the system based upon the base-lined architecture. The construction phase is in some sense a manufacturing process, where emphasis is placed on managing resources and controlling operations to optimise costs, schedules, and quality. In this sense the management mindset undergoes a transition from the development of intellectual property during inception and elaboration, to the development of deployable products during construction and transition.
This phase would therefore include the following artifacts:
- The System – iterations of actual implementations (database in Microsoft Access and user interface in Visual BASIC)
- Deployment Plan for rollout of application
- Training Materials including user manuals
- Design Model – updated from elaboration phase
- Data Model – updated from elaboration phase
- Test Suite of cases to validate each iteration of implementation
- Class Diagram
class diagram version 1.1
(Dotted lines indicate a class relationship, where as a solid line indicates an inheritance relationship)
- Transition
The focus of the Transition Phase is to ensure that software is available for its end users. The Transition Phase can span several iterations, and includes testing the product in preparation for release, and making minor adjustments based on user feedback. At this point in the lifecycle, user feedback should focus mainly on fine-tuning the product, configuring, installing and usability issues, all the major structural issues should have been worked out much earlier in the project lifecycle.
This phase would therefore include the following artifacts:
- System implementation – ensuring environment is available and sufficient for the requirements (i.e. hardware, network etc)
- Training materials and end-user manuals – completed from construction phase
- Beta testing of system with subset of users
There are several ways of implementing the change over to the new system.
- Assessment of Issues Addressed
After reviewing the Cain Motors project, we addressed the shortcomings with a more suitable lifecycle and by addressing implementation faults discovered. Many of the original artefacts (i.e. documents, code or other deliverables) were mapped from the traditional waterfall lifecycle into the Unified Process lifecycle.
By following this iterative lifecycle, we believe the product resulting would be of a higher quality. Specifically, the following would be addressed:
- High risk functionality achieved early in project
- Business requirements more closely met
- Iterative approach enables a constant refinement of achieving business requirements
- Future requirements more easily addressed in subsequent iterations
The resulting implementation would address faults identified in the following areas:
- Prototypes would be iteratively used rather than storyboarding
- SQL Server or MSDE used for database layer
- Visual BASIC business components (no user interface) encapsulate business logic, providing building blocks that could be re-used across a large number of requirements
- Visual BASIC user interface (from prototypes) interface with business logic to provide easily changed presentation (following Windows user interface guidelines).
- Changes to user interface can be achieved with minimum risk, given no/reduced impact to lower layers of business components or database
The resulting architecture would follow a more “layered” pattern, in that the database, application logic and user interface would each be more cohesive and less coupled. These are the basic building blocks of a re-usable component-based architecture. The result would be that business requirements could be more easily met with lower cost and lower risk.
Future development is more easily addressed with the new architecture; specifically a web-based front end would be a low cost solution, given the re-use of the business components and database layers. This would be achieved as a new iteration of the current lifecycle, re-using the artefacts already produced (e.g. project documentation).
Glossary of terms
Bibliography