1 / 48

Chapter 2: SWE Qualities

Chapter 2: SWE Qualities. Prof. Steven A. Demurjian Computer Science & Engineering Department The University of Connecticut 371 Fairfield Road, Box U-2155 Storrs, CT 06269-2155. steve@engr.uconn.edu http://www.engr.uconn.edu/~steve (860) 486 – 4818 (860) 486 – 3719 (office). Introduction.

ayanna-rivas
Download Presentation

Chapter 2: SWE Qualities

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Chapter 2: SWE Qualities Prof. Steven A. Demurjian Computer Science & Engineering Department The University of Connecticut 371 Fairfield Road, Box U-2155 Storrs, CT 06269-2155 steve@engr.uconn.edu http://www.engr.uconn.edu/~steve (860) 486 – 4818 (860) 486 – 3719 (office)

  2. Introduction • What is the Difference between: • Software product and other engineering products • Software process and other engineering processes? • Different from traditional types of products: • Intangible • Difficult to describe and evaluate • Malleable • Human intensive • Involves only trivial “manufacturing”

  3. Introduction • Software engineering (SE): • Intellectual activity, human-intensive • Software product: • Delivers certain functions • Must meet certain qualities • Software development processes: • Also must meet certain qualities • Software qualities are sometimes referred to as “ilities”

  4. Software Engineering Qualities • Software is a Malleable Product that is Human Intensive (High People to Machine Ratio) • Software Engineering Qualities • Correctness and Reliability • Robustness and Performance • User Friendliness, Verifiability, andSecurity • Maintenance and Reusability • RepairabilityandEvolvability • Portability, Understandability, and Interoperability • Productivity, Timeliness, and Visibility • Requirements for Information, Real-Time, Distributed, and Embedded Systems

  5. What is Software Quality Assurance?

  6. What is Software Quality Assurance?

  7. What is a Software Quality? • A Software Quality is a Characteristic to be Attained throughout an Application’s Lifetime • Software Qualities are Goals of Product and Process • Internal vs. External: • External: Visible to the users • Internal: Concern to developers • Product vs. process: • Process: Related to software’s production • Product: Artifacts produced during process • Internal qualities affect External qualities • Process quality affects Product Quality • Software Quality Assurance: Assess and Evaluate the Attainment of Qualities by Finished Product • Security Assurance & Information Assurance

  8. The Correctness Software Quality • Functional Correctness: Software Behaves According to Requirements Specification • Assessing Correctness - Potential Problems • Assumes Requirements Specifications are Available and Up-to-Date • Assumes Correctness Testing is Possible • Assumes Mathematical Properties can be Established Between Software and Specs • Correctness - Absolute Quality (Yes/No) • Correctness in Practice • Focus on Components at Varying Levels • Addressed via Public Interface, Private Implementation, Testing of Classes/Components • Components in Distributed Apps

  9. Correctness Example • Cars • Compute acceleration/decceleration correctly when brakes are applied/released • In this case, correctness can be verified since there is a mathematical equation that expresses acceleration & decceleration for a given speed and level of braking • Is it possible to define correctness for all the types of systems? • How do we define Correctness for Mobile App?

  10. The Reliability Software Quality • Software Performs as User Expects • User Can Depend on Software • Different Reliability Requirements per Domain • Massively multiplayer online games • Computer Games: Low? • Flight Control Software (Mars): High? • Banking, Insurance, Stocks, …: High? • Correct Software is Reliable but Reliable Software May Not be Correct • Reliability in Practice: • Focus on Reliability of Components (Classes) and their Composition into Systems • Critical for Commercial Success of Consumer Products and Services and Mobile Apps!

  11. The Reliability Software Quality Reliability Correctness • Informally, user can rely on it • Defined mathematically as “probability of absence of failures for a certain time period” • If specifications are correct, all correct software is reliable, but not vice-versa (in practice, however, specs can be incorrect …) • Different reliability requirements per domain: • Low reliability • Medium reliability • High reliability

  12. Reliability Examples • Cars: • If the stereo system does not function, the car is still reliable. • If the transmission dies, the car is unreliable. • If the oil leaks, and the oil lamp indicator does not turn on, is the car reliable? • Reliability and Humans Impact One Another • Airline Crash Landing in SF in 2013 • Stall Indicators, Flight Control Vibrating, Alarms Signaling • Still Required Human (Pilot) to Make a Decision • With 1.5 Secs left, tried to Get Airborne to go Around for Another Landing • Auto landing Available may not have been Used

  13. The Robustness Software Quality • Software Behaves Reasonably, Even in Unexpected Circumstances • Different Robustness Requirements per Domain • Computer Games: Low or High? • ATM Machine: High - Hard to Break • Mobile: How Does Robustness Impact? • May Include Hardware Robustness (ATM Story) • Incorrect Behaviors Acceptable, as Long as a Consistent, Workable Outcome Occurs • Robustness in Practice • Java Provides Exception Handling that Can be Built into Each Class (Component) for Robustness • Robustness Transcends D & D Paradigm • Robustness Critical for Commercial Success

  14. Robustness Example • Windows 98: • Plug and play feature would allow you to connect any monitor, printer, keyboard to the computer • However, if the printer crashed, disconnected or turned off the OS crashed! • Unexpected event for the OS • Cars: • Timing belts break, or brakes fail – the car should stop • Muffler breaks – the car can continue to function

  15. The Performance Software Quality • Performance is Equated with Efficiency, Scalability, Reliability, User-Acceptance, etc. • Growing Problem Impacts Strongly on Software • Varied OS Platforms (Linus, WinXP, 7, 8, Solaris) • Different HW Capabilities (Memory Size, 32 vs. 64 bit, Disk Capacity, Display, etc.) • Measurement vs. Queuing Analysis vs. Simulation • Impact from Specification through Delivery • Performance in Practice • Identify Key Classes/Components with Hard Performance Constraints • Embedded Applications (Elevators, Avionics, etc.) • Versions of Classes/Components for OS/HW Platforms? • Performance Revolution: Mobile Platforms!

  16. The Performance Software Quality • Measurement: Measure Actual Performance of Working Systems • Analysis: Build a Model and Analyze • General Understanding of System • Queueing Models During Specification/Design • Redo Queueing Models After Implementation by Providing Hard Numbers to Fine-Tune • Simulation: Model Simulates Actual System • Predict Exact Performance of Components • Expensive and Time Consuming to Build • Yields an Accurate Estimate • System Performance Must Be Addressed from Day One Throughout Lifetime

  17. Performance Example • Cars: • Sufficient power to climb uphill • Accelerate to a given speed in a reasonable amount of time • Efficient in the consumption of gasoline • Airline • Airplanes Able to Reverse Landing w.r.t. Engines and their Power (Thrust) • Time Constrained by • Time to go from Speed 1 to Speed 2 • Location of Plane w.r.t. Ground • Mobile Apps • Deal with Network Bandwidth • Download vs. Storing Data Locally

  18. User Friendliness/Usability • Expected users find the system easy to use • Rather subjective, difficult to evaluate • Affected mostly by user interface • For example: visual vs. textual • Cars: • Controls for A/C, heater etc. should be more readily accessible than the controls to fine tune the stereo system • Impact of New Technologies in Cars with Touch Screens, Plug Ins for Mobile Devices, GPS • What are Issues? • What might Happen?

  19. Security • Ability of the system to protect information (data) and resources: • Availability: • Information must be available when it is needed • Confidentiality: • Prevent disclosure of information to unauthorized individuals or systems • Integrity: • Data cannot be modified undetectably • What are Costs Associated with Security? • What Applications have High Security Need? • E-commerce • Financial sites (banks, brokers, etc.)

  20. Verifiability • How easy it is to verify properties • Mostly an internal quality • Can be external as well (e.g., security critical application) • Cars: • How easy it is to verify that the car can stop within a certain distance? • How easy it is to verify that the car meets emission standards? • Can we verity auto stop if sensor detects motion behind the car? • How do we verify that auto parking works?

  21. The Maintenance Software Quality • Modifications and Enhancements Made to Product After Release - 60% of Total Software Cost • Three Types of Maintenance • Corrective: Remove Errors Post Delivery (20%) • Adaptive: Adjust Per OS/HW Changes (20%) • Perfective: Improve Qualities/Features (50%) • Modification to Legacy Software for Major Improvement or Software Evolution • Maintenance in Practice • Can OO Reduce Corrective Maintenance? • Can OO Facilitate Adaptive and Perfective Maintenance? • How do we Maintain Web/Distributed Apps? • What’s Challenge in Mobile Apps?

  22. Maintenance of Web Applications • Three Types of Maintenance • Corrective, Adaptive, and Perfective • Need to have Strategy for Making Changes • Web Apps Typically Developed in Staged Setting • Development/Testing Environment Web + Application Server on Intranet • Actual Web + Application Servers on Internet • May be Replicated Web/Application Pairs that are Geographically Separated • Changes/Testing on Intranet • Migration to Internet in a Staged Manner for Upgrades • Note: • Maintenance Requires Version Management • Source Code Control System

  23. Maintenance of Mobile Applications • What are Emerging Issues in Mobile Apps re. Maintenance? • Wide Variety of Hardware Platforms • Different Devices • Different Resolution • Different Speeds • Supporting Multiple OS Platforms • Android, iOS, html5, Blackberry, etc. • Also Multiple Versions of Same OS (Android -18) • Difficulty in Source Code Control • Maintain Code Base • Across Multiple HW and OS Platforms • Any Other Issues?

  24. The Reusability Software Quality • Strive for Domain-and-Organization Specific Reuse • Products Most Likely to be Developed in Future • Focused on Software Components • Scientific Math and String Libraries • Windowing and GUI Building Blocks • Java APIs for Enterprise, Embedded, etc. • Reusability Evolving to Larger Components (e.g., Java Beans) and Subsystems

  25. The Repairability Software Quality • Ability to Correct Problems with Limited Amount of Work and a Minimal Impact • A Well Modularized Product is Easier to Modify than a Monolithic Project • Programming Language Role in Repairability • What is Classic Repairability Problem Today? • Repairability Related to Reusability/Evolvability • Repairability in Practice • Repairs Focused on Class or Component • If Public Interface Remains UnchangedThen No Impact as a Result of Repair • May have to Rebuild • Web Application that Must Always be “Up” • Browsers: FF, IE, Safari, Opera, Chrome, etc. and Multiple Versions

  26. Repairability for Mobile Apps • Potential to have to Fix • Multiple Versions for HW Differences • Multiple Versions for OS • Problems in one OS may not Occur in Other • New or Updated APIs • Are all OS Upgrades backward compatible? • Earlier Versions less Desirable? • Dealing with Lifetime of Mobile Devices • Galaxy II, III, IV, IV Active (waterproof) • iPhone 3, 4, 5 • iPad 2 (no SIRI) and 3 (with SIRI) • Galaxy tablet (1.5 yrs old – newest Android unavailable) • Not the Case in PC/Laptop world

  27. The Evolvability Software Quality • Field of Dreams: If you Build it, it Will Change! • Key Evolvability Issues • Ease of Modifications - Add New Features and Change Existing Features • Function of System Size • Modularization vs. Monolithic • Over Time, Evolvability Reduces as Subsequent Versions of Same Software are Released • Reach of Limit of Change w.r.t. Look-and-Feel • Evolvability in Practice • Achieved via Inheritance and Polymorphism • Public Interface Must Remain Unchanged! • Adding Capabilities and Features to Web and Distributed Applications the Norm

  28. Evolvability for Mobile Apps • What are Issues? • HW Differences • OS Upgrades • Do you continue to Release App Upgrades for Old OS? • What do in Rapidly Evolving Environment? • Depracated APIs • Longer Term vs. Short Lived Apps • Workhorse Apps Available Long Term • Keynote, Notability, etc. • What about Apps that Flash and then Burn? • Plan for Change • Is it Difficult to Plan for Future OS Upgrades? • Mobile OSs change more than PC/Laptop OS • How to Achieve Source Code Control?

  29. The Portability Software Quality • Software Works on Different Platforms • Origins and Popularity of C and Unix • Hard in Practice - All C++’s Not Created Equal • Borland C++ vs. Visual C++ vs. Sun C++ • Java – Compiler Addons and Competing Versions • 32 vs. 64 bits • Core Language Same? (Operator Precedence) • Some Languages (Ada95, Java) Stress Ability to Port without Rewriting Any Code • Portability in Practice • Isolate Specifics into Dedicated Classes • Portability Transcends D & D Paradigm • Web – App works in Multiple Browsers/Versions • Mobile Platforms: Titanium, Sensa Touch (html5)

  30. The Understandability Software Quality • System Has Predictable Behavior • Internal Understandability • Is the Software Easy to Learn and Understand? • Varies Based on Application Domain • OS vs. Tool vs. Small Application • External Understandability • From the Perspective of User • Is the Software Easy to Understand and Use? • Emerging Applications/Games for Children starting at 6 months on up • Understandability in Practice • Easy to Change and Evolve • External is Key to Successful Web Apps • Mobile App Process/Tools Easy to Learn?

  31. The Interoperability Software Quality • Enterprise Computing: The Problem of Today and Future! • New Products Must Coexist and Cooperate with Legacy, COTS, Databases, etc. • Success in Interoperability Traced to … • Programming Interface for COTS/Legacy • DCOM/OLE, CORBA, DCE, JINI, .NET • Languages: Java, Active-X, C# • Mobile Platform Development Environments • Open Systems, Standards, Multiple Vendors, etc. • Interoperability in Practice • Focus on Public Interface Concept • Interoperability Transcends D & D Paradigm • Norm for Web and Distributed Applications

  32. Typical Process Qualities • Process Qualities Involve the Steps and Actions that are Integral to Software Development • Productivity • Denotes the Efficiency and Performance of Software • A Measurable Quality (Empirical) • Timeliness • Ability to Deliver a Product on Time • Meeting Deadlines and High Quality Products • Visibility • All of Its Steps and Current Status are Documented Clearly • Open Software Process (All Stakeholders)

  33. Typical Process Qualities • Process Qualities Involve the Steps and Actions that are Integral to Software Development • Productivity • Denotes the Efficiency and Performance of Software • A Measurable Quality (Empirical) • Timeliness • Ability to Deliver a Product on Time • Meeting Deadlines and High Quality Products • Visibility • All of Its Steps and Current Status are Documented Clearly • Open Software Process (All Stakeholders)

  34. The Productivity Software Quality • Efficiency Measure of Software Production Process • Measurable in Many Ways • Individuals • Team • Number of Classes/Lines of Code • Impacted by Problem Domain and its Complexity • Productivity in Practice • Potential for Significant Increases with OO • Short-Term Investment for Long-Term Gain • Can’t Fall Into Trap of Simply Counting Code • Web Code Counts Much Higher (and Often Automatically Generated) • Lousy Developers Often Write More Code • Another metric to measure productivity?

  35. The Timeliness Software Quality • Meeting Deadlines and Market Demands • Requires Careful Scheduling, Accurate Estimation, and Clear Milestones • Impacted by • Changing User Requirements • Skills (or Lack Thereof) of SW Engineers • Incremental Delivery • Product Released in Stages • Complete and Incremental Requirements • Timeliness in Practice • Promotes Increments and Components • Classes Facilitate Evolution, Testing and Integration • For All Applications (Centralized to Distributed)

  36. Timeliness: Visual Description of Mismatch • Often the Development Process Does Not Follow the Evolution of User Requirements • A Mismatch Occurs Between User Requirements And Status of the Product

  37. The Visibility Software Quality • Software Process is an Open and Transparent Activity that is Shared by Developers/Managers • SW Engineers Apprised of Decisions and Choices • Strong Visibility Results in • Team Members Working in Same Direction • Management and Users Understand Problem • Easier Integration of New Personnel • Visibility in Practice • Open Systems, Free Software Foundation • Java, CORBA, ODBC, .NET • New Open Document Standard - Reality • Companies/State/Governments Looking for Guarantees that Today’s Documents Usable Tomorrow • State of MA Standoff with Microsoft (Blinked)

  38. What is OpenDocument? • Open Source Document File Format for Saving and Exchanging Documents Across Multiple Editors • Editors Include: OpenOffice, StarOffice, KOffice, IBM Workplace, and Abiword • All Information is stored in XML Files • Constantly Evolving to Incorporate Newest Ideas • Currently Trying to Become ISO Certified • Developed by OASIS Consortium • OASIS is Composed of Multiple Large Vendors Including: Adobe, Corel, IBM, KDE, and Sun • Based on OpenOffice File Format Modified per Input from Different Vendors

  39. Why is OpenDocument Important? • Allows the Use of Multiple Document Editors • Stored in XML Compared to .Doc Binaries Allows Easy Access to Data • Example Pre-MSWord 95 Unreadable in Office03 • European Union Requiring Document Formats to be Approved by Standards Body • Microsoft – No • Opendocument – Being Reviewed • At one Point, Massachusetts Recommended All State Documents Being in Non Proprietary Format • Microsoft Blinked and Agreed to OpenDocument Format Compatibility

  40. Application-Specific Qualities • Consider Information, Embedded, Distributed, and Web-Based Systems • Many Common Application-Specific Qualities • Data Integrity – Tracking Information Content • Negative Salaries, Dependencies Among Values, etc. • Security – Tracking Access to Information • Who can do What on Which Data When? • Data Availability – Robustness and Accessibility • Is Application Up, Running, and Available? • Transaction – Compartmentalizing Functionality • ATM Transactions • Database Update Transactions • Defined Unit – Fully Executes or Doesn’t • What are Mobile Apps Specific Qualities?

  41. Quality Requirements: Information Systems • Manage and Process Information • Database and Transaction Processing Model • Typically Characterized by • Data Integrity: Reliability • Data Security: Correctness • Data Availability: Correctness/Performance • Transaction Processing: Performance • Employs Client/Server Paradigm • Client: GUI for User - Non-technical • Server: Database Management System • Transactions and Results Across Network • Emerging Fields: • Data Mining, Data Warehousing • Mobile Apps, Big Data Computing

  42. Quality Requirements: Real-Time Systems • Ability of a System to Respond to Events within a Predefined Time • Real-Time Computing via ATMs • Embedded Computing (Elevators, Avionics, etc.) • Mobile Apps Many Real Time Constraints that Impact Potential for “Selling” a Popular App • Often Control Oriented • System Actions Managed to Meet Priorities • Evaluated by Software Quality Assurance • Are Requirements Attained? • Performance, Correctness, Reliability • Safety: The Absence of Undesirable Behavior • User Friendliness Critical from System Operator’s Perspective

  43. Quality Requirements: Distributed Systems • Independent Components Interconnected by Network for Communication • Computing Paradigm for Today and Tomorrow • Web-Based Applications • Client/Server and Multi-Tier • Characterized by • Degree of Distribution • Partitioning of System or Information • Fault Tolerance Across Application • Keys: Correctness, Performance, Reliability • Recent and Emerging Technologies • DOC, CORBA, DCE, DCOM, .NET, JINI, etc. • Java, Jasmine, Oracle, etc.

  44. Quality Requirements: Embedded Systems • Pervasiveness of Computers in • Consumer Electronic Products • Appliances and Automobiles • Keys: Correctness, Performance, Reliability • Embedded Computing and Java • PersonalJava: Java in Game Consoles, Smart Phones, Remote Controls, Touch Screens, etc. • Embedded Java: Java in Mobile Phone, Process Control Network Routers, etc. • Java Card: Smart Card Technology - Credit Card Computer for Personal, Health Data, etc. • Myriad of Commercial Applications • MP3, Microwave, Smart Ovens (Appliances), etc. • Mobile Devices with Increasing Sensors

  45. Quality Measurement • Many Qualities are Subjective • Qualitative Assessment via Criteria • Identify Criteria and See If SW Satisfies Them • No Standard Metrics Defined for Most Qualities • However, Many Metrics for Assessing Software • Many UML Tools have Metrics for: • Lines of Code • Tracking Calls and Dependencies Among Classes • Average Lines of Code/Class or Method • Software Quality Assurance • Security Assurance • Guarantees that Certain Access Control Achieved • Information Assurance • Guarantees on Information Content

  46. Software Qualities in 3 Tier Setting • Which Qualities are Most Important and Why? • Correctness Reliability, Robustness and Performance • User Friendliness, Verifiability • Maintenance, Reusability, Repairability and Evolvability • Portability, Understandability, and Interoperability • Productivity, Timeliness, and Visibility

  47. Software Qualities in 4 Tier Setting • Which Qualities are Most Important and Why? • Correctness Reliability, Robustness and Performance • User Friendliness, Verifiability • Maintenance, Reusability, Repairability and Evolvability • Portability, Understandability, and Interoperability • Productivity, Timeliness, and Visibility

  48. Chapter 2 - Summary • Qualities Determine the Merits of Software • Correctness and Reliability • Robustness and Performance • User Friendliness, Verifiability, and Security • Maintenance and Reusability • Repairability and Evolvability • Portability, Understandability, Interoperability • Productivity, Timeliness, and Visibility • Software Quality Assurance: Focuses on the Attainment of the Qualities of Specification in Working Prototypes/Product • Difficult to Quantitatively Measure

More Related