1. View layer : Designing interface objects
Unit 5
View layer : Designing interface objects

2. Introduction UI(user interface)
Main goal of UI is to display and obtain needed information in an accessible , efficient manner
UI design is a creative process

3. Designing view layer classes
UI layer consists of
objects with which user interacts
Objects needed to manage or control UI
Responsibility of view layer objects
Input :responding to user interaction
Translating user’s action into an appropriate response
Output :displaying or printing business objects

4. Process of designing view layer classes
It has 4 major activities
Macro level UI design process: (identifying view layer object)
Takes place during analysis phase
Identifying classes that interact with human actors by analysing use cases
sequence and collaboration diagram helps to identify UI classes
Micro level UI design activities
Designing the view layer objects by applying design axioms and corollaries
Decide how to use and extend the components so they best support application specific functions and provide the most usable interface
Prototyping the view layer interface
Useful in the early design process
Testing usability and user satisfaction
Refining and iterating the design

5. Macro level design process
The class interacts with a human actor
Zoom in by utilizing sequence or collaboration diagrams
Identify the interface objects for the class
Next class refine and iterate
The class doesn’t interacts with the human actor
Define the relationships among the view objects

6. Relationship among view objects, business objects, access objects

7. Micro level design process
Apply micro level UI design rules and GUI guidelines to each interface object identified to develop the UI
Next interface objects refine and iterate
Done

8. Design rules Making the interface simple ( application of corollary 2)
Ex:
Car engine is complex
But driver interface remains simple
User must be able to work with our screen without asking much questions
Factors affecting UI
Dead lines
Comparative evaluations
Addition features
Shortcuts
Things to be considered while designing UI
Additional features affect performance, complexity
Fixing problem, after the release of product is difficult

9. Software Quality Assurance

10. What is Software? According to the IEEE Software is:
“Computer programs, procedures, and possibly
associated documentation and data pertaining to
the operation of a computer system”.

11. What is Software Quality ?
According to the IEEE
Software quality is:
The degree to which a system, component, or process meets specified requirements.
The degree to which a system, component, or process meets customer or user needs or expectations.
According to Pressman
“Conformance to explicitly stated functional and performance requirements, explicitly documented development standards, and implicit characteristics that are expected of all professionally developed software”.

12. What is Software Quality?
“Achieving high levels of user satisfaction, portability, maintainability, robustness, and fitness for use” by Dr. Barry Boehm.
Quality means “conformance to user requirements” by Phil Crosby.
Edwards Deming considers quality to be “striving for excellence” in reliability and functions by continuous improvement in the process of development, support by statistical analysis of the causes of failure.

13. What is Software Quality?
Watts Humphrey, of the SEI, tends to speak of quality as “achieving excellent levels of fitness for use, conformance to requirements, reliability and maintainability.”
James Martin said that software quality means being on time, within budget and meeting user needs
Tom McCabe, the software complexity specialist, defines quality as “high level of user satisfaction and low defect levels, often associated with low complexity

14. What is Software Quality?
John Musa of Bell Laboratories states that quality means combination of “low defect levels, adherence of software functions to users needs, and high reliability”
Bill Perry, head of Quality Assurance Institute has defined quality as “high levels of user satisfaction and adherence to requirements”.

15. Why Quality is Important?
Quality is critical for survival and success.
Customers demand quality.
Everybody seems to understand quality.
Everybody wants quality
Everybody has a different perception of quality.
Essentially quality means satisfying customer.

16. Why Quality is Important?
Why business should be concerned with quality:
Quality is competitive issue now
Quality is a must for survival
Quality gives you the global reach
Quality is cost effective
Quality helps retain customers and increase profits
Quality is the hallmarks of world-class business

17. Importance of Software Quality
Software is a major component of computer systems
(about 80% of the cost) – used for
– communication (e.g. phone system, system)
– health monitoring,
– transportation (e.g. automobile, aeronautics),
– economic exchanges (e.g. ecommerce),
– entertainment,
– etc.
Software defects are extremely costly in term of
– money
– reputation
– loss of life

18. Importance of Software Quality
Several historic disasters attributed to software
1988 shooting down of Airbus 320 by the USS Vincennes cryptic and misleading output displayed by tracking software
1991 patriot missile failure inaccurate calculation of time due to computer arithmetic errors.
London Ambulance Service Computer Aided Dispatch System – several deaths
On June 3, 1980, the North American Aerospace Defense Command (NORAD) reported that the U.S. was under missile attack.
First operational launch attempt of the space shuttle, whose real-time operating software consists of about 500,000 lines of code, failed synchronization problem among its flight control computers.
9 hour breakdown of AT&T's long distance telephone network caused by an untested code patch

19. Software Quality Factors
Correctness
accuracy, completeness of required output
upto-dateness, availability of the information
Reliability
Minimum failure rate
Efficiency
resources needed to perform software function
Integrity
software system security, access rights
Usability
ability to learn, perform required task

20. Software Quality Factors
Maintainability
effort to identify and fix software failures (modularity, documentation, etc)
Flexibility
degree of adaptability (to new customers, tasks, etc)
Testability
support for testing (e.g. log files, automatic diagnostics, etc)
Portability
adaptation to other environments (hardware, software)
Reusability
use of software components for other projects
Interoperability
ability to interface with other components/systems

21. Software Quality Challenges
The measures for quality differ from project to project and organization to organization
Quality measures used for small systems may not be appropriate for the large ones.
Criteria for quality vary as a function of the specific characteristics of the project, the needs of the users and stakeholders, and the application requirements of the system and software.
Criteria for quality applied to real-time applications are not always relevant when dealing with systems that are not real-time.

22. What is Software Quality Assurance?
According to the IEEE
Software quality assurance is:
A planned and systematic pattern of all actions necessary to provide adequate confidence that an item or product conforms to established technical requirements.
A set of activities designed to evaluate the process by which the products are developed or manufactured. Contrast with: quality control.

23. What is Software Quality Assurance?
According to D. Galin Software quality assurance is: “A systematic, planned set of actions necessary to provide adequate confidence that the software development process or the maintenance process of a software system product conforms to established functional technical requirements as well as with the managerial requirements of keeping the schedule and operating within the budgetary confines.”

24. Objectives of SQA Development: Maintenance:
Assuring an acceptable level of confidence that the software will conform to functional technical requirements.
Assuring an acceptable level of confidence that the software will conform to managerial scheduling and budgetary requirements.
Initiation and management of activities for the improvement and greater efficiency of software development and SQA activities.
Maintenance:
Assuring an acceptable level of confidence that the software maintenance activities will conform to the functional technical requirements.
Assuring an acceptable level of confidence that the software maintenance activities will conform to managerial scheduling and budgetary requirements.
Initiate and manage activities to improve and increase the efficiency of software maintenance and SQA activities.

25. Three General Principles of QA
Know what you are doing
Know what you should be doing
Know how to measure the difference

26. Three General Principles of QA
Know what you are doing
understand what is being built, how it is being built and what it currently does.
suppose a software development process with
management structure (milestones, scheduling)
reporting policies
tracking

27. Three General Principles of QA
Know what you should be doing
having explicit requirements and specifications
suppose a software development process with
requirements analysis,
acceptance tests,
frequent user feedback

28. Three General Principles of QA
Know how to measure the difference
having explicit measures comparing what is being done from what should be done
four complementary methods:
formal methods – verify mathematically specified properties
testing – explicit input to exercise software and check for expected output
inspections – human examination of requirements, design, code, ... based on checklists
metrics – measures a known set of properties related to quality.

29. Software Quality Challenges
Complex Software requires different monitoring procedures than trivial applications.
Quality criteria vary dramatically depending on the phase of the project at which the evaluation takes place
The measures of the quality must be specific to the project being evaluated and must assess the effectiveness of the entire development process, not just individual segments.

30. Software Quality Challenges
Quality cannot be directly checked in the product; it must planned right from the beginning.
Quality goals must be clearly defined, effectively monitored, and rigorously enforced.
The project must focus on the quality issues of the project from the beginning, ensuring that quality criteria are consistent with defined requirements.
Quality must be planed into the project structure, constantly evaluated, and corrections applied when deficiencies are identified.

31. Changing View of Quality
Past
Present
Quality is the responsibility of blue collar workers and direct labor employees working on the product
Quality is everyone’s responsibility, including, white-collar workers, the indirect labor force and the overhead staff
Quality defects should be hidden from the customers and management
Defects should be highlighted and brought to the surface for corrective actions
Quality problems lead to blame, faulty justification and excuses
Quality problems lead to cooperative solutions
Corrections-to-quality problems should be accompanied with minimum documentation
Documentation is essential for “lessons learnt” so the mistakes are not repeated.

32. Changing View of Quality
Past
Present
Increased quality will increase project costs
Improved quality saves money and increase business
Quality is internally focused
Quality is customer focused
Quality will not occur without close supervision of people
People want to produce quality products
Quality occurs during project execution
Quality occurs at project initiation and must be planned for within the project

33. Quality Control v/s Quality Assurance
Quality means meeting requirements and meeting customer needs, which means a defect-free product from both the producer’s and the customer’s viewpoint.
Both quality control and quality assurance are used to make quality happen.
Quality is an attribute of a product. A product is something produced, such as a requirement document, test data, source code etc.

34. Quality Control v/s Quality Assurance
Quality Assurance (QA) is the set of activities (including facilitation, training, measurement and analysis) needed to provide adequate confidence that processes are established and continuously improved in order to produce products or services that conform to requirements and are fit for use.
Quality Control (QC) is defined as the processes and methods used to compare product quality to requirements and applicable standards, and the action taken when a nonconformance is detected.

35. Quality Control v/s Quality Assurance
QA is an activity that establishes and evaluates the processes that produce the products. If there is no process, there is no role for QA.
QC is an activity that verifies whether or not the product produced meets standards.

36. Quality Control v/s Quality Assurance
QA helps establish processes
QC relates to a specific product or service
QA sets up measurement programs to evaluate processes
QC verified whether particular attributes exist, or do not exist, in a specific product or service
QA identifies weakness in processes and improves them
QC identifies defect for the primary purpose of correcting defects.

37. Quality Control v/s Quality Assurance
QA is a management responsibility, frequently performed by a staff function
QC is the responsibility of the worker
QA evaluates whether or not quality control is working for the primary purpose of determining whether or not there is weakness in the process

38. Quality Control v/s Quality Assurance
Defining Processes
Walkthrough
Quality Audit
Testing
Selection of Tools
Inspection
Training
Checkpoint review

39. Impediments to Software Quality Control
Quality control is often viewed as a police action
IT is often considered an art
Unclear or ineffective standards and processes
Lack of process training

40. Impediments to Software Quality Assurance
Management does not insist on compliance to processes
Workers are not convinced of the value of processes
Processes become obsolete
Processes are difficult to use
Workers lack training in processes
Processes are not measurable
Measurement can threaten employees
Processes do not focus on critical aspects of products

41. Quality Assurance at each phase of SDLC
Requirements Analysis Phase:
Three major activities that foster quality
Measurement of process attributes
Verification and Validation
Management
Managing quality in the analysis stage is a challenge.

42. Quality Assurance at each phase of SDLC
Good Quality Requirements
They are precise, with no room for misinterpretation by users or implementers
They specify just what the system must do, not how to do it. They avoid specifying implementation details
They show conceptual integrity, building on a simple set of facilities that interact well with each other

43. Quality Assurance at each phase of SDLC
Major management deficiencies in most software development projects:
Incorrect schedules
Incorrect cost estimates
Inadequate project accountability procedures
Inadequate quality assurance procedures
Imprecise goals and success criteria

44. Quality Assurance at each phase of SDLC
Design phase:
A lack of quality in the design process can invalidate good requirements specification and can make correct implementation impossible.
Industry practice shows that use of checklist during design helps improve design quality.

45. A test strategy is an outline that describes the testing approach of the software development cycle. It is created to inform project managers, testers, and developers about some key issues of the testing process.

47. Module or unit testing.
Integration testing,
Function testing.
Performance testing.
Acceptance testing.
Installation testing.

48. What is Test case?
A test case is a document, which has a set of test data, preconditions, expected results
and postconditions, developed for a particular test scenario in order to verify compliance against a specific requirement.
Test Case acts as the starting point for the test execution, and after applying a set of input values, the application has a definitive outcome and leaves the system at some end point or also known as execution postcondition.

49. Typical Test Case Parameters:
Test Case ID
Test Scenario
Test Case Description
Test Steps
Prerequisite
Test Data
Expected Result
Test Parameters
Actual Result
Environment Information
Comments

50. System usability and measuring user satisfaction

51. issues 2 main issues in software quality Validation Verification
User satisfaction
Verification
Quality assurance

52. Usability testing ISO defines usability as ISO requires Effectiveness
Efficiency
Satisfaction
With which a specified set of users can achieve a set of tasks in particular environments
ISO requires
Defining tasks
Defining users
A mean for measuring effectiveness, efficiency, satisfaction

53. Usability testing Definition
Measures the ease of use as well as the degree of comfort and satisfaction users have with the software
Testing begins in the early stages of product development

54. Quality assurance test cases User satisfaction test cases Usability
OOA use case model
Quality assurance test cases
User satisfaction test cases
Usability
test cases

55. Guidelines for developing testing
Include all of a software components
Need not be very expensive or elaborate
All subjects need not involve all subjects
Design problems can be studied with few users
Apply testing early and often

56. Recording the usability test
Provide comfortable location for participants
Don’t interrupt participants
Record the techniques and search patterns users employ when attempting to work through a difficulty
Record the time taken to perform a task, and problems faced by them
Record the results using portable tape recorder or camera
This is followed by user satisfaction test and questionair

57. User satisfaction test
Process of quantifying usability test with measurable attributes of the test such as functionality , cost or ease of use
Ex: 90 5 of the people should know to withdraw money from ATM without training or error

58. objectives
Used as communication vehicle bw designers, and also bw users and designers
To detect and evaluate changes during the design process
To provide a periodic indication of divergence of opinion about current design

59. Guidelines for developing user satisfaction test
Must work with users or clients to find out what attributes should be included in the test
Limit the number of attributes
some attributes are
ease of ues
functionality
Cost
reliability

60. Tool for user satisfaction test
Commercial Off the Shelf (COTS)
User Satisfaction Test Spreadsheet (USTS)