Tim Bradley Quality Security AS1

8/2/2019 Tim Bradley Quality Security AS1

1/20

Quality & Security Management

Information Sciences

Tim Bradley

December 2010


2/20

Quality and Security Management

Contents1 Introduction ......................................................................................... 32 The necessity of quality assurance ........................................................... 3

3 Quality within the Lifecycle ..................................................................... 43.1 The Triangle of Objectives ................................................................. 54 Quality Management Strategies ............................................................... 6

4.1 Plan (Define and Prioritise) ................................................................ 64.2 Verify and Validate .......................................................................... 7

4.2.1 Process audits. .......................................................................... 74.2.2 Peer reviews ............................................................................. 84.2.3 Work Product Analysis ................................................................ 84.2.4 Testing ..................................................................................... 8

4.3 Improve (Analyse and Tune) ........................................................... 104.4 Manage ........................................................................................ 10

5 Conclusion ......................................................................................... 116 Cause and Effect (Ishikawa) Diagram ..................................................... 127 Priority List ........................................................................................ 138 Self Control ........................................................................................ 14

8.1 Expectations: ................................................................................ 148.2 Knowledge of Performance .............................................................. 148.3 Regulation of Performance .............................................................. 14

9 Quality Control ................................................................................... 1610 Consumer Audit ................................................................................ 18

10.1 Touch ........................................................................................ 1810.2 Sight ......................................................................................... 1810.3 Hearing ...................................................................................... 18

11 References ....................................................................................... 1912 Bibliography ..................................................................................... 20

Tim Bradley December 2010 Page 2


3/20


1 Int roduct ion

In todays economic climate where business competition is fierce, quality has

become an important factor in gaining competitive advantage. Softwaredevelopment organisations use metrics to establish the quality of their productsin order to improve customer satisfaction by reducing errors and implementingbetter programming and testing techniques. Software quality assurance drivesbest practice, ensuring that everyone involved is doing the right things, in theright way at the right time. Lifecycle Quality Management (LQM) enablescompanies to align priorities and customer expectations with the system/projectrequirements. This process reduces costs, maximizes the potential for successand improves customer satisfaction and can therefore give an organisation thecompetitive edge.

2 The necessity of quality assurance

Quality is important to every business whether they provide goods, services orsoftware. Poor quality invariably leads to dissatisfied customers, which reducesthe likelihood of new or repeat business from the supplier. This would havedirect impact on revenue.

Software development companies are under constant pressure to ship products

faster, at lower costs and with fewer resources. Within this complex anddemanding environment it is often all too easy for organisations to overlook theimportance of quality. Within corporate software organisations, only one in threesoftware projects is considered a success, and approximately 70 percent of software projects fail to deliver what was originally intended without going overbudget, missing the deadline or sacrificing quality (Standish Group International,2004).

Many development companies employ a testing department which usuallyverifies quality when coding is complete, or frozen. The testing is often rushedin order to certify the software as soon as possible so that customer and marketcommitments are met. As the stages of the System Development Life Cycle areput under continual pressure the testing prior to deployment becomes lesseffective and the possibility of error increases. It is fairly common that duringthe latter stages of the Implementation phase of the SDLC that new featuresare requested and modifications made. This adds to the testing workload, oftenwithout any additional resource or time factored into the project plan.

When organisations neglect the importance of quality they run the risk of increasing their costs and decreasing their efficiencies. The diagram belowillustrates how cost can spiral sharply upwards during the latter stages of theSDLC. By implementing better quality processes earlier in the lifecyclecompanies can reduce their business costs and become more efficient.



4/20


Figure 1- The cost of discovering defects increases significantly during the latter stages of the SDLC.

Borland (2007).Image Available from:http://www.borland.com/resources/en/pdf/solutions/lqm_driving_quality.pdf

Accessed 6 th January 2010

According to Humphrey (2005) the estimated cost of correcting a defect found insoftware application after its release is ten times more than the cost of defectsrectified during system tests. Organisation can benefit greatly by implementingquality activities earlier in the lifecycle.

3 Quali ty within the Lifecycle

When quality is fused throughout the software lifecycle, organisations deliver higher quality applications and service, while systematically reducing costs, risk and time to market. Borland (2007).

By using appropriate quality processes in each phase of the lifecycle anorganisation can reduce overall development cost by addressing quality issues attheir root causes.

Defining quality can often be complex and difficult because it means differentthings to different people. However in terms of software engineering quality cangenerally be defined as a software package that meets the requirements, hascorrect code, minimal defects and enables the organisation to fulfil their businessgoals.

When organisations concentrate solely on post production testing they eliminatethe opportunity for detecting problems earlier in the development lifecycle. Byaddressing quality issues earlier the organisation can ensure that an application(complete with its source code) is complete, scalable, adaptable and

maintainable. The following list of quality issues cannot be detected by testing

http://www.borland.com/resources/en/pdf/solutions/lqm_driving_quality.pdfhttp://www.borland.com/resources/en/pdf/solutions/lqm_driving_quality.pdf


5/20


alone, however they can all be addressed through Lifecycle QualityManagement:

Poorly defined or ambiguous system requirements can result in costly re-working.

Violations in code licensing can increase legal risks. Poor overall design of an application can limit the performance and

scalability of the software. Tightly coupled interfaces can make it difficult to integrate software with

existing systems. The use of platform specific code can affect the portability of a product. Poorly commented or hard to read code can increase maintenance costs. Security vulnerabilities which can expose users to attacks.

Reactive software testing (at the end of the lifecycle) provides no quality

guarantees as the application moves through the development lifecycle. This canresult in software that gradually becomes misaligned and does not end upmeeting the customers needs. Conversely, proactive quality managementenables management to monitor the success, risk and progress of a project. Thisapproach focuses on tracking key indicators throughout the lifecycle to ensurethe project is delivered on time, on budget and to the specifications.

Testing can be a costly and time consuming process for an organisation andtherefore can often be neglected. By investing a more proactive approachorganisations can remove defects earlier and therefore spend less time onrework and testing.

To ensure quality software there needs to be skilled people using effectiveprocesses. When software bugs are found within an application they are oftenrecorded using a defect management system. This tracking software is useful formonitoring a defect until it is fixed, however a greater gain can be achieved byexploring the cause of the defect. Analysis of software defects can alloworganisations to train their staff better and improve their processes.

3.1 The Triangle of Objectives

In the mid 1980s Dr Martin Barnes devised a theory to demonstrate that thethree primary objectives of cost, quality and time are interrelated. According toBarnes it is often necessary for development companies and customers toprioritise two of the primary objectives at the expense of the third. For example,if a project had to be completed quickly and the owner had sufficient funds, theproject manager may recommend a generous budget and plenty of resources inorder to deliver the project in the shortest possible time; this would however beat the detriment of quality. To deliver quality software solution the customermust be willing to either invest sufficient funds or be prepared to agree on alonger development schedule.



6/20


Figure 2 - The triangle of objectives.

4 Quality Management Strategies

There are a variety of different practices an organisation could adopt to instilquality into each stage of the Systems Development Life Cycle. The diagrambelow illustrates best practices in Lifecycle Quality Management.

Figure 3 - The four key process areas within Lifecycle Quality.

Borland (2007).Image Available from:http://www.borland.com/resources/en/pdf/solutions/lqm_driving_quality.pdf

Accessed 6 th January 2010

4.1 Plan (Define and Prioritise)

High quality system requirements provide the foundation for successful softwareprojects as they align all stakeholders to clearly defined, common goals. Thesehigh quality requirements should be prioritised based on the needs of thecustomers business. Initial requirements should also contain details of testingand quality measures, both of which should be explicitly documented. Beynon(2010) argues that clear conceptual design is central to developing systems thatare understandable and that meet customers expectations and preferences.

http://www.borland.com/resources/en/pdf/solutions/lqm_driving_quality.pdfhttp://www.borland.com/resources/en/pdf/solutions/lqm_driving_quality.pdf


7/20


Analysis and prioritisation should involve IT and business stakeholders in orderto ensure that there is a balance between customer needs and business costs.

Risk management is the ability to anticipate what might go wrong in a project.Hoffer et al. (2004) . All software projects carry certain risks. Through carefulanalysis plans can be implemented to minimise the potential impact of suchrisks. Broadly speaking risks can fall into the two following categories.

Product related risks Integration with legacy systems, dealing withleading edge technologies, out manoeuvring the competition.

Project related risks Managing resource levels, meeting schedules,financial considerations.

Quality measures can be costly and time consuming to organisations; thereforeit is imperative that quality initiatives provide a reasonable return on theirinvestment. The project teams should prioritise quality activities according to theneeds of the business and the level of risk they are seeking to mitigate. Forexample, certain aspects of the software may be considered mission critical andthus should be tested carefully with the highest level of priority. Effectivecommunication systems should exist between all stakeholders so that all qualityactivities are carried out with the correct level of priority.

Most software development organisations have detailed policies and proceduresthat define their Software Development Life Cycle (SDLC). To deliver qualitythroughout the SDLC a project plan should contain the following:

A clear definition of the roles and responsibilities. How resources will be allocated. Timelines, milestones and deliverables. The reports that will be required.

The criteria upon which application quality goals are based should always bealigned to meet the needs of the business.

4.2 Verify and Validate

Once a quality plan has been drawn up and documented the project team canbegin to perform the quality activities. Through the systems design phase of theSDLC developers can measure application quality status and quality progressusing a variety of methods.

4.2.1 Process audits.Clearly defined processes enable teams to work efficiently and effectively. Theyensure that each member of the team understand their role and responsibilitythroughout the project. Sometimes it is necessary for an organisation to tailortheir processes in order to best fit the requirements of a project.Process audits are carried out to ensure that as the project moves through the

SDLC the development teams are following the correct processes andprocedures. Feedback from such audits can be used to make adjustments to the



8/20


processes as the project progresses. By reacting to audit feedback proactivelythe project team can use the data to its advantage in delivery a quality product.

4.2.2 Peer reviewsTo ensure software quality peer reviews can be a particularly useful tool. Peerswithin the project are able to offer feedback on all types of work products(requirements, design code, tests) to ensure that they meet with both customerand project requirements. Once again this proactive approach can help identifyissues early and therefore allow rectification before the project moves into thesubsequent phase.

4.2.3 Work Product AnalysisPrior to coding aspects of architecture and system design require thoroughanalysis. Proactive quality approaches could include architecture modelling toprovide alternative design approaches. For example, some technologies or

platforms may initially appear suitable until detailed modelling indicates thatthey might not scale to meet the customer needs. This early type of analysiswhich may include the use of static models or simulations can provide theassurance that the system design can be coded, safe in the knowledge that itwill meet performance requirements.

4.2.4 TestingTests are designed to measure the difference between observed and expectedsoftware behaviour . Stair and Reynolds (2008) assert that good testingprocedures are essential to make sure that new of modified software operates asintended. Testing is an effective process for identifying quality issues once thecode has been written. Tests can be used to indentify:

Functional defects Missed service level objectives Performance bottlenecks Usability issues Security vulnerabilities

Test can be performed manually or through automation. Automated testing isuseful for repetitive tasks or where manual testing is inappropriate due to

repeatability and scalability (e.g. load or performance testing). The cost of removing software defects grows exponentially as the application move throughSDLC phases. Therefore it is important that organisations start testing early inthe development phase.

There are a variety of techniques that can be used for testing systems. Jones(1996) identifies 18 types of testing, the most common of which are subroutine,unit, new function, regression, integration and system testing. Testing strategiesare commonly divided into two categories: black-box and white-box testing.



9/20


Black-Box Testing

Black box testing (as the name suggests) requires no knowledge of the internallogic or code structure within the given system. It is sometimes referred to asopaque testing, functional/behavioural testing or closed box testing.In order to carry out effective black-box testing it is imperative the tester has athorough understanding of the requirement specifications and as a user shouldknow exactly how the system should behave in response to any particularaction. Testing can be divided into two sub categories; a) tests requiring a userand b) tests where a user or role is not required.

The following methodologies can be applied where a user is not required.

Functional Tests are conducted on the system software, they are writtenin order to check the application behaves correctly.

Stress testing applications is where the tester loads the system withcomplex numerical values, large quantities of input and complex queries.This is done to ensure the application can withstand high workloads.

Load Testing is conducted by applying high levels of input or makingdemanding requests until the systems performance degrades oreventually crashes.

Usability Testing is done to the user friendliness of the system. Theuser interface should be suited the needs and ability of the end user.

Recovery Testing looks at how an application recovers after a hardwareor software failure. Applications should be designed to recover quicklywith data loss minimized.

Volume Testing subjects the system to extreme quantities of data toobserve how it reacts.

The following methodologies can be applied where a user is required.

User Acceptance Testing , the software is tested by the user todetermine whether it meets their expectations and requirements.

Alpha Testing is usually carried out at the development centre. Users areinvited to perform tasks and any abnormal behaviour is documented andrectified.

Beta Testing , at his stage the software is distributed users who test theapplication at their site. Any abnormalities or defects are documented andreported to the developers.

White Box TestingWhite-box testing deals with the internal logic and structure of code. White-boxtesting is also referred to as clear box, glass box or structural testing. To be ableto carry out white-box testing the tester must possess knowledge of the codingand logic on which the system runs. Therefore white-box testing is a specialistskill and can only be carried out by trained personnel. The purpose of white boxtesting is to correct errors, to reduce unnecessary code and optimize the

efficiency of the code. The disadvantages of white-box testing are that it is costly



10/20


due to the high skill level required and that in most complex applications it isalmost impossible to check every bit of code.

White-box testing may utilize some of the following methodologies:

Unit Testing is conducted upon completion of a unit of code or when aparticular functionality is built. This testing is carried out at a very basiclevel, usually by the developer.

Static & Dynamic Analysis . Static analysis requires the tester toexamine each line of code individually to identify defects, whereasdynamic analysis involves executing the code and examining the output.

Statement Coverage tests that every statement within the code isexecuted at least once. This enables the tester to identify any side effectsrelating to individual statements.

Branch Coverage tests any branches within the code ensuring that allbranches link seamlessly and execute correctly.

Security Testing requires the tester to ensure the system is protectedfrom unauthorized access, hacks, cracks or other malware.

Mutation Testing takes place after bugs have been identified and fixed.It ensures the new code executes correctly and that the modificationshave had no undesired side effects.

4.3 Improve (Analyse and Tune)

After a software application has been released the project team can look toimprove further developments by analysing the results of their verification andvalidation activities. Once a root cause has been identified the skill, process ortechnology can be addressed and improved. This swift action may save a greatdeal of time and resources on future development projects; it also helps toreduce any finger pointing between team members. 4.4 Manage

Throughout the SDLC it is critical that managers have the right information tomake decisions. They should be able to access real time reports on quality statusand project progress. These reports should cover the results of reviews, testingresults, coverage and find-fix rates. Equipped with this information managersshould be able to direct resources and understand release readiness.

To minimise project costs all resources need to be managed efficiently. The useof control systems within an organisation will help manage the activities andassets that contribute to quality results.

Quality Assurance procedures have been formalised in the British StandardBS5750 Part 1 and the international equivalent ISO 9001. Bocij et al. (2006).These procedures do not guarantee a quality software application but theyensure that the relevant phases of the SDLC, such as requirements capture,

design and testing are carried out consistently.



11/20


5 Conclusion

Software quality should be delivered in every phase of the SystemsDevelopment Life Cycle; it should not be an afterthought. Lifecycle QualityManagement enables businesses to effectively align their priorities and qualityexpectations within the project system requirements. By eliminatingunnecessary risks inherent in software development organisations can minimisecosts and maximise the commercial success of their applications.

This approach to quality can enhance the confidence of the development teamby combining people process and technology aspects to ensure that quality isbuilt into an application from the initial requirements through to delivery.

Software quality assurance is not a black art but a basic good management practice that complements sound technical skill and experience.

McManus (2010).



12/20


6 Cause and Effect (Ishikawa) Diagram



13/20


7 Prior ity L ist

The cause and effect diagram above illustrates the relationship between a given

outcome (post graduates failing to find employment) and the factors thatinfluence this outcome.

The most likely causes can be indentified and then a priority list can be devisedso that the causes can be tackled in a rational order.

The following priority list identifies the most important cause of post graduateunemployment in descending order of importance.

Motivation An individual must have the motivation to want to work andalso the drive to search and apply for employment.

Preparation Students should know their prospective employer andprepare themselves for interview. This might included research into the

job/company, creating a portfolio, practice interviews, prepare questionsand dressing appropriately.

Experience Students should try and gain as much possible experienceeither through art time work, placements or voluntary positions.

CV- A well written and presented CV will make an applicant stand out. Willingness to learn new skills Every employer has their own

methodologies, processes and procedures. Post graduates should beadaptable, receptive to change and willing to learn new skills.

Communication and social skills- Most organisations rely on teamwork toproduce a quality end product or service. It is important that applicantsare able to fit in, communicate and work effectively with others.

Qualifications Applicants should have high quality academicqualifications, but these could also be supported with professional/vendorcertifications.

Portfolio A interviewee should be able to demonstrate their past workand showcase their talent and ability.

Flexibility Organisations need employees how can be flexible in terms of hours worked, geographical location and the types of role they perform.

Expectations Most Post graduates will NOT earn 30,000 a year rightout of University. They won't be a vice-president with a mansion until theyearn both.



14/20


8 Sel f Control

In my position as an IT Technician at a secondary school I am required to ensure

that the maximum number of workstations are available to students throughoutschool opening hours.

Kineton High School has an attendance of approximately 900 pupils. The schoolhas over 200 workstations in 7 different classrooms.

It is important that I can manage the quality of results I attain and that Imresponsible for the outcomes I deliver. Through self control I am able tomanage my workload and a quality service to my customers (Teachers andstudents).

8.1 Expectations:Through a clearly defined Service Level Agreement I aware that at least 95% of the schools workstations should be available during school open/working hours.Non functional workstations are reported via a helpdesk system, which tracksthe number of PCs that are unavailable, this can be up to 10 PCs before the ICTdepartment falls behind the targets stated in the SLA.This target is monitored on a daily bases and is a reasonable reflection of theeffectiveness on my departments role within the school. The SLA clearlycommunicates to me what I am required to do and how I can measure my ownsuccess. Through coaching and feedback from my Line Manager and colleagues I

am also kept informed of what is expected from me. My responsibilities are alsodocumented in my job description. This comprehensive method of communication ensures that I have a clearly defined and unambiguous job role.Expectations are made clear; I know what I should be doing and how to do it.

8.2 Knowledge of PerformanceI am able to measure my success and that of my department via a computerisedmanagement dashboard. The system tracks the number of malfunctioningworkstations, when they were reported, by whom, who is responsible for fixingthem and how long they were out of service. Reports can be run that showavailability statistics on a daily, weekly and monthly basis. The reports also showpatterns in hardware/software failure, causes of faults, remedies, locations,success rates and other trends that are useful in improving the ICT services.Feedback about my performance can also come from Line Management or peer-coaching, audits, process reviews and feedback from teaching staff. Thefeedback provided enables me to review and improve my working practices. Ican continually work towards providing higher availability, shorter Out of Service times, better performance, improved service and generally betterquality in the services and products I deliver.

8.3 Regulation of Performance

If I am failing to meet the organisations targets it is important that I am awareof the situation. Individuals cannot be held responsible for delivering poor quality



15/20


if they are unaware that they are not meeting the expectations required of them.In my position I will receive feedback from various sources if I fail to deliverquality in my role.

The ICT management systems will inform me that I have dropped below thestandards specified in the SLA. Management would also be aware and this wouldbe communicated to me immediately. At this point my manager and I wouldcreate a plan describing how I improve my performance in order to return to theexpected standard. I would be offered support, training and recourses if required.

Only a monthly basis I complete a formal review with my manager whomeasures the success of each task within my role. The review document is usedto create a development plan, which focuses on future training and personalimprovement. I am also set longer term objectives (6-12 months) whichchallenge me to improve the over quality of service offered by the ICT team.

I also seek 360 feedback from my peers and staff in other departments of theschool such as teachers, pupils, support and administrative staff.



16/20


9 Qual ity Cont ro l

The table below illustrates how as a consumer I can measure the quality of

goods, services and software. Each table describes the quality control subjectand then provides a suggested method of measurement which the supplier couldutilize to improve their performance.

Goods Services Software

Quality ControlSubject 1:

Fitness for purpose Success of overallservice provided Fitness for purpose

Unit of Measure

Number of product

returns orcomplaints forevery 1000products sold.Consumer Reviews.

Number of follow-

up visits or calloutsrequired tocomplete work tocustomersrequirements

Does the productmeet the specified

systemrequirements andhas in helped toimprove thebusiness in the waywhich was intended



Product Life Span Customer Care Customer Support

Unit of MeasureThe time betweenrepeat purchases

Customersatisfactionquestionnaireresults.

Total number of support calls raisedand the % resolved.



Availability of goods

Availability of Service Delivery on time

Unit of Measure

Is there a waitinglist for the productbeing produced? Atwhat % of the timeis the productavailable forpurchase by theend customer?

At what % of thetime is resourceavailable to providethe specifiedservice to thecustomer? Howlong do customershave to wait toreceive the servicethey seek?

Has the fullyoperational, testedsoftware beendelivered to thecustomer within theguidelines definedin the project plan?




17/20


Quality ControlSubject 4: Usability Speed of service Usability

Unit of Measure

Consumer trialresults. Focusgroup feedback.Reviews by critics.

Completion time.How long did ittake to provide asatisfactory servicefrom the initialrequest?

Feedback fromusers,

questionnaires.Reduced systemtraining hours.



18/20


10 Consumer Audit

During a recent visit to an electronic goods retail outlet I observed how

customers used their senses to observe the quality of items they were interestedin. Because the store sold only electronic goods I was restricted to observingtheir use of touch, sight and hearing. In another environment i.e. a greengrocers I may have observed them using their sense of taste and smell, thiswould of course be deemed somewhat unusual in and electronics outlet.

10.1 TouchMost technological products require the user to psychically interact with them.Most items have switches, dials, knobs, sliders, keys, touch input surfaces orother means of interacting. I observed that most customers used their sense of touch to measure two different things. Firstly they measured the productsresponsiveness and build quality, and then secondly they judged the products interms of how tactile they were. Customers seemed to prefer controls that feltpositive and well made. Flimsy engineering and poor build quality left customersdissatisfied. Positive, responsive controls gave users a sense of empowermentand satisfaction.

10.2 SightThe overall aesthetics of a product can have a significant impact on productssuccess. Many consumer electronic items now come in a variety of colours anddesigns in order to meet the ever changing tastes of potential customers. I

observed several customers who considered the look of the product to be one of the most important considerations prior to purchase.However, other than pure aesthetics some consumers used their sense of sightto make decisions about the build quality of the item. Some customers viewedthe items from all angles to ensure that it met their requirements.

10.3 HearingI observed various customers listening to sounds made by the moving parts of an item i.e. buttons being pressed, dials being turned, thing being opened andclosed. Hollow, tinny sounds seemed to give the impression of poor build qualitywhereas nice deep clunky sounds seemed to reassure the customer that theywere handling a quality product. This premise has been exploited in advertisingcampaigns run by Volkswagen, who argue that customers perceive positive, solidsounds to be indicative of high quality.



19/20


11 References

Beynon-Davies, P. (2010)

Designing Interactive Systems, Second Edition.Harlow: Pearson Education Limited.

Bocij, P., Chaffey, D,. Greasley, A., Hickie, S. (2006)Business Information Systems (Third Edition)Prentice Hall, London.

Borland (2007)Driving Quality Throughout the Software Delivery Lifecycle.Austin, USA.

Hoffer, J., George, J., Valacich, J. (2004)Modern Systems Analysis and Design (Fourth Edition).Prentice Hall, London.

Humphrey, W. (2005)A Discipline for Software Engineering.Addison Wesley Publishing, Massachusetts.

Jones, C. (1996)Software Quality: Analysis and Guidelines for Success.

Thomson Computer Press, London.McManus J (2010)IT Now - Quality AssuredOxford University Press, UK

Stair, M and Reynolds, G. (2008)Fundamentals of Information Systems, Fourth Edition.Thomson Course Technology, Boston

Standish Group International. (2004)The CHAOS ReportMassachusetts, USA.



20/20


12 Bibliography

Anderson, H. Yull, S. and Hellingsworth B. (2004)

Higher National Computing (Second Edition)Oxford, Elsevier.

Long, L. and Long, N. (2005)Computers: Information Technology in Perspective (Twelfth Edition)New Jersey, Pearson Education.

Rudshill, M., Lewis, C., Polson, P., McKay, T. (1996)Human Computer Interface DesignMorgan Kraufmann, USA

Schneider, G (2003)Electronic CommerceThompson Course Technology, Boston


Tim Bradley Quality Security AS1

Documents