Quality and Information Systems

1. Quality and Information Systems Panagiotis Kanellis, Επιστημονικός Συνεργάτης Τμήματος Πληροφορικής ΕΚΠΑ Business Consulting, 377 Syngrou Ave., 175 64 Athens, Greece Email: kanellis@di.uoa.gr Δρακούλης Μαρτάκος, Επίκουρος Καθηγητής Τμήματος Πληροφορικής ΕΚΠΑ Κτίρια Πληροφορικής, Πανεπιστιμιόπολη, 157 84Αθήνα Email: martakoσ@di.uoa.gr

2. Talk about: • The Need for Software Quality Assurance • Software quality measurement and control • The Development Infrastructure • Software Process Management • Participative Design

3. The Need for Software Quality Assurance • The Y2K Problem • Quality more important than ever as software becomes an integral part of the products sold • Defining user needs and judging the quality of the completed system have proved to be major challenges • Meeting specifications does not necessarily mean quality - there exist numerous factors that determine the success of a system

4. Maintenance • Maintenance is the most expensive phase of the systems development process • Systems are maintained because of: • organizational changes • software complexity • faulty systems analysis and design

5. What is Quality in IS? • Any definition of IS quality must be broad in scope and specific enough to encompass the satisfaction of user needs. A quality system must do the following: • Achieve the business goals articulated by the user department • operate at an acceptable cost, commensurate with the value produced for the firm • Meet carefully defined performance standards (such as response time and system availability) • produce accurate, reliable output with assurance that its dependability is “good enough” for the purpose intended • Be easy to learn and use • Be flexible

6. Means to Ensure Quality • Use of appropriate systems development methodology • Proper resource allocation during development • Use of software metrics • Attention to testing • Use of quality tools

7. The Role of Methodologies A collection of methods, one or more for every activity within every phase of a development project. Normally a methodology includes the following: • Proven methods for determining and documenting both system specifications and system design • programming standards that result in understandable, maintainable code that is not overly complex • Guidelines for developing quality measurements to be agreed on by all interested parties prior to development • Standards and methods for testing the system • Software tools to be used at every phase to standardize the work in the project and to improve the quality of the output • Project control methods, including numerous project milestones at which user approval will be required

8. Resource Allocation • Determination of how costs, time, and personnel are assigned to different activities of a systems development project • 1/4 of a project’s time and cost should be expended in specifications and analysis • 2/4 should be allocated to design and programming • 1/4 should be allocated to installation and postimplementation

9. Software Metrics • Objective assessments of the software used in a system in the form of quantified measurements • Input metrics (educational and experience of system developers • Capacity metrics (transaction levels) • Output metrics (Number of checks printed per hour) • Performance/Quality metrics (Number of bugs per hundred lines of code) • Value metrics (Business value of a transaction)

10. Traditional Tools and Methodologies for Quality Assurance • Structured Refers to the fact that techniques are instructions that are carefully drawn up, often step-by-step, with each step building on the previous one

11. Structured Analysis Structured Analysis Top-down method for defining system inputs, processes, and outputs and for partitioning systems into subsystems or modules that show a logical graphic model of information flow • Data Flow Diagram (DFD) Primary tool in structured analysis that graphically illustrates a system’s component processes and the flow of data between them

12. Data Flow Diagrams Data Flows The movement of data between processes, external entities, and data stores in a data flow diagram Processes Portray the transformation of input data flows in a data flow diagram. Each has a unique reference number and is named with a verb-object phase Data stores manual or automated inventories of data External entities Originators or receivers of information outside the scope of the system portrayed in the data flow diagram Getting down to the lowest level possible

13. Structured Design Software design discipline, encompassing a set of design rules and techniques for designing a system from the top down in a hierarchical fashion Flowcharts Describe the processes taking place within an individula program in the system and the sequence in which they must be executed Structured Design

14. Limitations of Traditional Methods • Slow and unresponsive to today’s fast changing business world • It is linear • Slowness translates into increased cost • Are process based in contrast to being data based (The storage of the data is described as an appentage to those processes)

15. Object-Oriented Software Development • Object-Oriented Software Development Approach to software development that deemphasizes procedures and shifts the focus from modelling business processes and data to combining data and procedures to create objects • The system is viewed as a collection of classes and objects and the relationships between among them. The objects are defined, programmed, documented, and saved for use with future applications • High reusability, low maintenance costs

16. Computer-Aided Software Engineering (CASE) • Computer-Aided Software Engineering (CASE) The automation of step-by-step methodologies for software and systems development to reduce the amount of repetitive work the developer needs to do • Supporting a standard development methodology and design discipline • Improving communication between users and design specialists • Organizing and correlating design components and providing rapid access to the via a design repository • Automating tedious and error-prone portions of analysis, design, amd code generation

17. Elements of CASE • Diagramming Tools • Syntax verifier • Prototyping tools • Information repository • Code generators • Development methodology • Project management tools

18. Capability Maturity Model (CMM) • The CMM is the result of a United States Department of Defense (DoD) initiative to improve the development of military software: • Cost reduction • Schedule and quality improvement • Assessment and evaluation • Statistical control and measurement • Certification*

19. The Maturity Levels Continuously Improving Process Optimizing (5) Predictable Process Managed (4) Standard, Consistent Process Defined (3) Disciplined Process Repeatable (2) Initial (1)

20. CMM Structure Maturity Levels indicate contain Process Capability Key Process Areas achieve organized by Goals Common Features address contain Implementation or Institutionalization Key Practices describe Infrastructure or Activities

21. Advantages of CMM • The advantages of CMM are argued to be: • Risk reduction • Cost and schedule adherence • Improved quality • Improved communication and customer satisfaction

22. Potential Limitations of CMM • Several potential limitations may also be noted (non-exhaustive list): • Effort and cost involved in implementation (v size) • Tends to ignore the ‘unique’ aspect of projects • Validity of scale and maturity questionnaire • Application of assessment/evaluation method

23. What you really need... “…few people in industry know what constitutes a system. Many people think machinery and data processing when I mention systems. Few of them know that requirement, training, supervision and aids to production workers are part of the system.” Deming (1989)

24. A Quality Oriented Organizational System[Ravichandran and Rai, MISQ (forthcoming)]