DOCSLIB.ORG

Overview of Software Reliability Engineering

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Overview of Software Reliability Engineering SENG 637 Dependability, Reliability & Testing of Software Systems Chap ter 1: OiOverview Department of Electrical & Computer Engineering, University of Calgary B.H. Far （[email protected]） http://www.enel.ucalgary.ca/People/far/Lectures/SENG637/ [email protected] 1 Contents Shorter version: How to avoid these? [email protected] 2 Contents Longer version: What is this course about? What factors affect software quality? What is software reliability? What is software reliability engineeringengineering?? What is software reliability engineering process? [email protected] 3 About This Course … The topics discussed include: Concepts and relationships Analytical models and supporting tools Techniques for software reliability improvement, including: Fault avoidance, fault elimination, fault tolerance Error detection and repair FilFailure detect ion and retracti on Risk management [email protected] 4 Terminology & Scope Failures Treats Faults Errors Availability Reliability Safety Attributes Dependability Confidentiality Integrity Maataabtyintainability The ability of a system to deliver Fault prevention Means service that can Fault tolerance FlFault remova l justifiably be Fault forecasting trusted. Reliability Block Diagram Models Fault Tree model Reliability Graph [email protected] 5 Software Reliability Software Reliability Concept Model Process Reliability Single Multiple SRE Availability Failure Failure Process Failure rate Model Model MTTF Failure density Etc. Reliability Growth Model [email protected] 6 Software Testing Software Testing Techniques Process Other: Certification Reliability SRE Black-box Test Growth Process WhiteWhite--boxbox Test Alpha Beta BigBig--bangbang Stress Etc. [email protected] 7 Question to Ask Do I really need to take this course? AddAnswer depend on you! Take this course if you want to avoid these in your career as a software designer , tester and quality controller: Bug Fix [email protected] 8 At The End … What is software reliability engineering (SRE)? Why SRE is important? How does it affect software quality? What are the main factors that affect the reliability of software? Is SRE equivalent to software testing? What makes SRE different from software testing? How can one determine how often will the software fail? How can one determine the current reliability of the software under development? How can one determine whether the ppgroduct is reliable enough to be released? Can SRE methodology be applied to the current ways of software development such as component-based and agile development? What are challenges and difficulties of applying SRE? What are current research topics of SRE? [email protected] 9 Chapter 1 Section 1 FSftFrom Software Quality lit t o Software Reliability Engineering [email protected] 10 What is Quality? QQyppuality popular view: – Something “good” but not quantifiable – Something luxury and classy QliQuality prof essi onal li view: – Conformance to requirement (Crosby, 1979) – Fitness for use (Juran, 1970) SENG521 [email protected] 11 Quality: Various Views AthtiAesthetic DlDeveloper View View Customer View [email protected] 12 What is Software Quality? Conformance to requirement The requirements are clearly stated and the product must conform to it What is Specified? Any deviation from the requirements is regarddded as a dfdefect What A good quality product contains fewer defects SW Fitness for use Does? What user Fit to user expectations: meet user’s needs Needs? A good quality product provides better user satisfaction Both Dependable computing system SENG521 [email protected] 13 Definition: Software Quality ISO 8402 definition of QUALITY: The totality of features and characteristics of a product or a service that bear on its ability to satisfy stated or implied needs Reliability and Maintainability are two majjpor components of QyQuality SENG521 [email protected] 14 Quality Model: ISO 9126 Characteristics Attributes 1. Functionality Suitability Interoperability Accuracy Compliance Security 2. Reliability Maturity Recoverability Fault tolerance Crash frequency 3. Usab ilit y UUdesadabnderstandability Learnab ility Operab ility 4. Efficiency Time behaviour Resource behaviour 5. Maintainability Analyzability Stability Changeability Testa bility 6. Portability Adaptability Installability Conformance Replacability [email protected] 15 Quality Model – Structure SW Qua lity User oriented Quality Quality Quality Factor 1 Factor 2 ... Factor n Quality Quality Quality Quality Criterion Criterion Criterion ... Criterion Software oriented 1 2 3 m Measures [email protected] Example: Attribute Expansion Design by measurable Quality objective objectives: Incremental design is evaluated to check whether Availability the goal for each increment User friendliness was achieved. % of planned Days on job to System uptime learn task supplied By new system Worst: 95% Worst: 7 days Best: 99% Best: 1 day [email protected] 17 What Affects Quality? SENG521 [email protected] 18 What Affects Software Quality? Time: Meeting the project deadline. Quality Reaching the market at the right time. Cost: Cost Time Meeting the anticipated project costs. Quality (reliability): WkififWorking fine for th e designated period on People Technology the designated system. [email protected] 19 Quality vs. Project Costs Cost distribution for a typical software project Product Integration Design and test Release Programming Design Programming Testing What i s wrong with this p ic ture ? SENG521 [email protected] 20 Total Cost Distribution Maintenance is responsible for more that 60% of total cost for a typical software project Product Design Questions: 1) How to Programming build quality into a system? Maintenance 2) How to Integrat i on assess quality and test of a system? Developing better quality system will contribute to lowering maintenance costs SENG521 [email protected] 21 1) How to Build Quality into a System? Developing better quality systems requires: Establishing Quality Assurance (QA) programs Establishing Reliability Engineering (SRE) process SENG521 [email protected] 22 2) How to Assess Quality of a System? Relevant to both pre- release and post- Quality release Assess ment Pre-release: SRE, certification, standards ISO9001 Post-release: evaluati on, valid ati on, RAM SENG521 [email protected] 23 How Do We Assess Quality? AdAd--hochoc (trial and error) approach! Systematic approach SENG521 [email protected] 24 Pre-release Quality Software Facts: inspection and • About 20% of the software projects are canceled. (missed testing schedules, etc.) • About 84% of software projects Methods: are incomplete when released SRE (need patch, etc). • Almost all of the software projects Certification costs exceed initial estimations. Standards (cost overrun) ISO9001, 9126, 25000 SENG521 [email protected] 25 Fatal Software Examples Fatal software related incidents [Gage & McCormick 2004] Date Casualties Detail 2003 3 Software failure contributes of power outage across North-eastern U.S. and Canada. 2001 5 Panamanian cancer patients die following overdoses of radiation, determined by the use of faulty software. 2000 4 Crash of marine corps osprey tilt-rotor aircraft, partially blamed on software anomaly. 1997 225 Radar that could have prevented Korean jet crash hobbled by software problem. 1995 159 Amer ican a iliirlines j jtdet, descen ding itinto CliClCali, Columbi a crash es i itnto a mountain. A cause was that the software presented insufficient and conflicting information to the pilots, who got lost. 1991 28 Software problem prevents Patriot missile battery from picking up SCUD missile, which hits US Army barracks in Saudi Arabia. [email protected] 26 Cost of a Defect … Require- Functional System Field Design Coding ments Test Test Use 50 % Fault 40 % Origin 10 % Fault 50 % Detection 7 % 3 % 5 % 25 % 10 % 20 KDM Cost per Fault 12 KDM 1 KDM 1 KDM 1 KDM 6 KDM 1 KDM = 1,000 Deutsch Marks CMU. Software Engineering Institute [email protected] 27 A Central Question In spite of having many development methodologies, central questions are: 1. Can we remove all bugs before release? 2. How often will the software fail? [email protected] 28 Two Extremes Craftsman SE: fast, cheap, buggy Cleanroom SE: slow, expensive, zero defect Is there a middle solution? Craftsman YES! Cleanroom Software Is there Software Using Software Develop- a middle Develop- Reliability ment solution? ment Engineering (SRE) Process [email protected] 29 Can We Remove All Bugs? Size Faiiilure potential Failure removal rate Faiiilure Density [function points] [development] [at release] 1 1.85 95% 0.09 10 2.45 92% 0.20 100 3.68 90% 0.37 1000 5.00 85% 0.75 10000 7.60 78% 1.67 100000 9.55 75% 2.39 Av erage 5025.02 86% 0910.91 Defect potential and density are expressed in terms of defects per function point The answer is usually NO! [email protected] 30 What Can We Learn from Failures? Time Between Failure vs. ith Failure 1000 900 Does this plot make 800 any sense to you? 700 600 urs 500 oo H 400 300 200 100 0 1 112131415161718191 ith Failure Failure Time [email protected] 31 How to Handle Defects? Table below gives the time between failures for a software system: Failure no . 1 2 3 4 5 6 7 8 9 10 Time since last failure (hours) 64856911141619 What can we learn from this data? System reliability? Approximate number of bugs in the system? Approximate time to remove remaining bugs? [email protected] 32 What to Learn from Data? The inverses of the inter-failure times are the failure intensity (= failure per unit of time) data points Error no. 1 2 3 4 5 6 7 8 9 10 Time since last failure 6 4 8 5 6 9 11 14 16 19 (hours) Failure intensity 0.166 0.25 0.125 0.20 0.166 0.111 0.09 0.071 0.062 0.053 [email protected] 33 What to Learn from Data? Mean-time-to-failures MTTF (or average failure rate) MTTF = (6+4+8+5+6+9+11+14+16+19)/10 = 9. 8 hour System reliability for 1 hour of operation t 1 Ret eMTTF e9.8 0.90299 Fitting a straight line to the graph in (a) would show an x- intercept of about 15 . Using this as an estimate of the total number of original failures, we estimate that there are still five bugs in the software.
Load more

Recommended publications
  • ASSESSING the MAINTAINABILITY of C++ SOURCE CODE by MARIUS SUNDBAKKEN a Thesis Submitted in Partial Fulfillment of the Requireme
    ASSESSING THE MAINTAINABILITY OF C++ SOURCE CODE By MARIUS SUNDBAKKEN A thesis submitted in partial fulfillment of the requirements for the degree of Master of Science in Computer Science WASHINGTON STATE UNIVERSITY School of Electrical Engineering and Computer Science DECEMBER 2001 To the Faculty of Washington State University: The members of the Committee appointed to examine the thesis of MARIUS SUNDBAKKEN find it satisfactory and recommend that it be accepted. Chair ii ASSESSING THE MAINTAINABILITY OF C++ SOURCE CODE Abstract by Marius Sundbakken, M.S. Washington State University December 2001 Chair: David Bakken Maintenance refers to the modifications made to software systems after their first release. It is not possible to develop a significant software system that does not need maintenance because change, and hence maintenance, is an inherent characteristic of software systems. It has been estimated that it costs 80% more to maintain software than to develop it. Clearly, maintenance is the major expense in the lifetime of a software product. Predicting the maintenance effort is therefore vital for cost-effective design and development. Automated techniques that can quantify the maintainability of object- oriented designs would be very useful. Models based on metrics for object-oriented source code are necessary to assess software quality and predict engineering effort. This thesis will look at C++, one of the most widely used object-oriented programming languages in academia and industry today. Metrics based models that assess the maintainability of the source code using object-oriented software metrics are developed. iii Table of Contents 1. Introduction .................................................................................................................1 1.1. Maintenance and Maintainability.......................................................................
    [Show full text]
  • Testing E-Commerce Systems: a Practical Guide - Wing Lam
    Testing E-Commerce Systems: A Practical Guide - Wing Lam As e-customers (whether business or consumer), we are unlikely to have confidence in a Web site that suffers frequent downtime, hangs in the middle of a transaction, or has a poor sense of usability. Testing, therefore, has a crucial role in the overall development process. Given unlimited time and resources, you could test a system to exhaustion. However, most projects operate within fixed budgets and time scales, so project managers need a systematic and cost- effective approach to testing that maximizes test confidence. This article provides a quick and practical introduction to testing medium- to large-scale transactional e-commerce systems based on project experiences developing tailored solutions for B2C Web retailing and B2B procurement. Typical of most e-commerce systems, the application architecture includes front-end content delivery and management systems, and back-end transaction processing and legacy integration. Aimed primarily at project and test managers, this article explains how to · establish a systematic test process, and · test e-commerce systems. The Test Process You would normally expect to spend between 25 to 40 percent of total project effort on testing and validation activities. Most seasoned project managers would agree that test planning needs to be carried out early in the project lifecycle. This will ensure the time needed for test preparation (establishing a test environment, finding test personnel, writing test scripts, and so on) before any testing can actually start. The different kinds of testing (unit, system, functional, black-box, and others) are well documented in the literature.
    [Show full text]
  • Interpreting Reliability and Availability Requirements for Network-Centric Systems What MCOTEA Does
    Marine Corps Operational Test and Evaluation Activity Interpreting Reliability and Availability Requirements for Network-Centric Systems What MCOTEA Does Planning Testing Reporting Expeditionary, C4ISR & Plan Naval, and IT/Business Amphibious Systems Systems Test Evaluation Plans Evaluation Reports Assessment Plans Assessment Reports Test Plans Test Data Reports Observation Plans Observation Reports Combat Ground Service Combat Support Initial Operational Test Systems Systems Follow-on Operational Test Multi-service Test Quick Reaction Test Test Observations 2 Purpose • To engage test community in a discussion about methods in testing and evaluating RAM for software-intensive systems 3 Software-intensive systems – U.S. military one of the largest users of information technology and software in the world [1] – Dependence on these types of systems is increasing – Software failures have had disastrous consequences Therefore, software must be highly reliable and available to support mission success 4 Interpreting Requirements Excerpts from capabilities documents for software intensive systems: Availability Reliability “The system is capable of achieving “Average duration of 716 hours a threshold operational without experiencing an availability of 95% with an operational mission fault” objective of 98%” “Mission duration of 24 hours” “Operationally Available in its intended operating environment “Completion of its mission in its with at least a 0.90 probability” intended operating environment with at least a 0.90 probability” 5 Defining Reliability & Availability What do we mean reliability and availability for software intensive systems? – One consideration: unlike traditional hardware systems, a highly reliable and maintainable system will not necessarily be highly available - Highly recoverable systems can be less available - A system that restarts quickly after failures can be highly available, but not necessarily reliable - Risk in inflating availability and underestimating reliability if traditional equations are used.
    [Show full text]
  • QA and Testing Have Become More of a Concurrent Process
    Special Feature: SW Testing “QA and testing have become more of a concurrent process rather than an end of lifecycle process” Manish Tandon, VP & Head– Independent Validation and Testing Solutions, Infosys Interview by: Anil Chopra, PCQuest n an exclusive interview with the PCQuest Editor, Manish talks become a software tester? about the global trends in software testing, skillsets required Software testing has evolved into a very special function and Ito enter the field, how technology has evolved in this area to anybody wanting to enter the domain requires two special provide higher ROI, and much more. An IIT and IIM graduate, skillsets. One is deep functional or domain skills to understand Manish is responsible for formulating and executing the business the functionality. Plus, you need specialized technical skills strategy for Independent Validation and Testing Solutions practice as well because you want to do automation, middleware, and at Infosys. He mentors the unit specifically in meeting business performance testing. It’s a unique combination, and we focus goals and targets. In addition, he manages critical relationships very strongly on both these dimensions. A good software tester with client executives, industry analysts, deal consultants, and should always have an eye for detail. So people who have a slightly anchors the training and development of key personnel. Provided critical eye and are willing to dig deeper always make much better here are his expert comments on the subject. testers than people who want to fly at 30k feet. Q> What are some of the global trends in the software Q> You mentioned that software testing is now required testing business? How do you see the market moving? for front-end applications.
    [Show full text]
  • A Quantitative Reliability, Maintainability and Supportability Approach for NASA's Second Generation Reusable Launch Vehicle
    A Quantitative Reliability, Maintainability and Supportability Approach for NASA's Second Generation Reusable Launch Vehicle Fayssai M. Safie, Ph. D. Marshall Space Flight Center Huntsville, Alabama Tel: 256-544-5278 E-mail: Fayssal.Safie @ msfc.nasa.gov Charles Daniel, Ph.D. Marshall Space Flight Center Huntsville, Alabama Tel: 256-544-5278 E-mail: Charles.Daniel @msfc.nasa.gov Prince Kalia Raytheon ITSS Marshall Space Flight Center Huntsville, Alabama Tel: 256-544-6871 E-mail: Prince.Kalia @ msfc.nasa.gov ABSTRACT The United States National Aeronautics and Space Administration (NASA) is in the midst of a 10-year Second Generation Reusable Launch Vehicle (RLV) program to improve its space transportation capabilities for both cargo and crewed missions. The objectives of the program are to: significantly increase safety and reliability, reduce the cost of accessing low-earth orbit, attempt to leverage commercial launch capabilities, and provide a growth path for manned space exploration. The safety, reliability and life cycle cost of the next generation vehicles are major concerns, and NASA aims to achieve orders of magnitude improvement in these areas. To get these significant improvements, requires a rigorous process that addresses Reliability, Maintainability and Supportability (RMS) and safety through all the phases of the life cycle of the program. This paper discusses the RMS process being implemented for the Second Generation RLV program. 1.0 INTRODUCTION The 2nd Generation RLV program has in place quantitative Level-I RMS, and cost requirements [Ref 1] as shown in Table 1, a paradigm shift from the Space Shuttle program. This paradigm shift is generating a change in how space flight system design is approached.
    [Show full text]
  • Software Quality Management
    Software Quality Management 2004-2005 Marco Scotto ([email protected]) Software Quality Management Contents ¾Definitions ¾Quality of the software product ¾Special features of software ¾ Early software quality models •Boehm model • McCall model ¾ Standard ISO 9126 Software Quality Management 2 Definitions ¾ Software: intellectual product consisting of information stored on a storage device (ISO/DIS 9000: 2000) • Software may occur as concepts, transactions, procedures. One example of software is a computer program • Software is "intellectual creation comprising the programs, procedures, rules and any associated documentation pertaining to the operation of a data processing system" •A software product is the "complete set of computer programs, procedures and associated documentation and data designated for delivery to a user" [ISO 9000-3] • Software is independent of the medium on which it is recorded Software Quality Management 3 Quality of the software product ¾The product should, on the highest level… • Ensure the satisfaction of the user needs • Ensure its proper use ¾ Earlier: 1 developer, 1 user • The program should run and produce results similar to those expected ¾ Later: more developers, more users • Need to economical use of the storage devices • Understandability, portability • User-friendliness, learnability ¾ Nowadays: • Efficiency, reliability, no errors, able to restart without using data Software Quality Management 4 Special features of software (1/6) ¾ Why is software ”different”? • Does not really have “physical” existence
    [Show full text]
  • Software Maintainability and Usability in Agile Environment
    Software Maintainability and Usability in Agile Environment {tag} {/tag} International Journal of Computer Applications © 2013 by IJCA Journal Volume 68 - Number 4 Year of Publication: 2013 Authors: Monika Agarwal Rana Majumdar 10.5120/11569-6873 {bibtex}pxc3886873.bib{/bibtex} Abstract This research is based on software maintainability and usability in the agile environment. Maintainability of the system is the ability to undergo changes relatively easily. These changes can affect components, services, interfaces and functionality when adding or changing functions, errors, and respond to business needs. Usability is defined as the application that meets the requirements of users and consumers by providing an intuitive, easy to locate and globalize and provides good access for disabled users and leads to a good overall user experience. In the conventional method of the software development, there are many metrics to calculate the maintenance and use of software. This research is to determine whether the same measures apply to Agile, or there is a need to change some metrics used for the agile environment. The goal of software engineering is to develop good quality maintainable software in schedule and budget. Inflated software costing, delayed time frame, or not meeting quality standards express a failure. A survey suggests about 45% of software fails due to the lack of quality. It is therefore one of the most important aspects for the success of software. Refer ences 1 / 3 Software Maintainability and Usability in Agile Environment - P. Antonellis, D. Antoniou, Y. Kanellopoulos, C. Makris, E. Theodoridis, C. Tjortjis, and N. Tsirakis, "A data mining methodology for evaluating maintainability according to ISO/IEC-9126 software engineering – product quality standard," in Special Session on System Quality and Maintainability - SQM2007, 2007.
    [Show full text]
  • Adaptability Evaluation at Software Architecture Level Pentti Tarvainen*
    The Open Software Engineering Journal, 2008, 2, 1-30 1 Open Access Adaptability Evaluation at Software Architecture Level Pentti Tarvainen* VTT Technical Research Centre of Finland, Kaitoväylä 1, P.O. Box 1100, FIN-90571 Oulu, Finland Abstract: Quality of software is one of the major issues in software intensive systems and it is important to analyze it as early as possible. An increasingly important quality attribute of complex software systems is adaptability. Software archi- tecture for adaptive software systems should be flexible enough to allow components to change their behaviors depending upon the environmental and stakeholders' changes and goals of the system. Evaluating adaptability at software architec- ture level to identify the weaknesses of the architecture and further to improve adaptability of the architecture are very important tasks for software architects today. Our contribution is an Adaptability Evaluation Method (AEM) that defines, before system implementation, how adaptability requirements can be negotiated and mapped to the architecture, how they can be represented in architectural models, and how the architecture can be evaluated and analyzed in order to validate whether or not the requirements are met. AEM fills the gap from requirements engineering to evaluation and provides an approach for adaptability evaluation at the software architecture level. In this paper AEM is described and validated with a real-world wireless environment control system. Furthermore, adaptability aspects, role of quality attributes, and diversity of adaptability definitions at software architecture level are discussed. Keywords: Adaptability, adaptation, adaptive software architecture, software quality, software quality attribute. INTRODUCTION understand the system [6]. Examples of design decisions are the decisions such as “we shall separate user interface from Today, quality of a software system plays an increasingly the rest of the application to make both user interface and important role in the domain of software engineering.
    [Show full text]
  • Usage of Prototyping in Software Testing
    Multi-Knowledge Electronic Comprehensive Journal For Education And Science Publications (MECSJ) ISSUE (14), Nov (2018) www.mescj.com USAGE OF PROTOTYPING IN SOFTWARE TESTING 1st Khansaa Azeez Obayes Al-Husseini Babylon Technical Insitute , Al-Furat Al-Awsat Technical University,51015 Babylon,Iraq. 1st [email protected] 2nd Ali Hamzah Obaid Babylon Technical Insitute , Al-Furat Al-Awsat Technical University,51015 Babylon,Iraq. 2nd [email protected] Abstract: Prototyping process is an important part of software development. This article describes usage of prototyping using Question – and – Answer memory and visual prototype diesign to realize Prototyping software development model. It also includes review of different models of software lifecycle with comparison them with Prototyping model. Key word: Question – and – Answer , Prototype, Software Development, RAD model. 1. Introduction One of the most important parts of software development is project design. Software project designing as a process of project creation can be divided in two large parts (very conditional): design of the functionality and design of user interface. To design the functionality, tools such as UML and IDEF0 are used, which have already become industry standards for software development. In the design of the graphical user interface there are no established standards, there are separate recommendations, techniques, design features, traditions, operating conditions for software, etc. At the same time, an important, but not always properly performed, part of this process is prototyping, i.e. the creation of a prototype or prototype of a future system. Prototypes can be different: paper, presentation, imitation, etc., up to exact correspondence to the future program. Most of the modern integrated development environments for software (IDE) allows to create something similar to prototypes, but it is connected with specific knowledge of IDE and programming language.
    [Show full text]
  • Lecturer: Ting Wang (王挺)
    Lecturer: Ting Wang (王挺) 利物浦大学计算机博士 清华大学计算机博士后 电子信息技术高级工程师 上海外国语大学网络与新媒体副教授 浙江清华长三角研究院海纳认知与智能研究中心主任 New Media Product DevelopmentDesign and Dr. Ting WANG School of Journalism and Communication Haina Cognition and Intelligence Research Center Shanghai International Studies University Yangtze Delta Region Institute of Tsinghua University, Zhejiang An overview to Part 01 software testing Testing in the software development Project Manager (Requirement Analyzer) System Analysis Release Structure Designer System Analysis Quality Assurance Engineer Requirement Analyzer Structure Design Testing Structure Design Programmer Structure Designer V-model Coding Coding Programmer Waterfall model Testing Quality Assurance Engineer Release Project Manager What is software testing? Software Testing Definition according to ANSI/IEEE 1059 standard -- A process of analyzing a software item to detect the differences between existing and required conditions (i.e., defects) and to evaluate the features of the software item. https://www.softwaretestingmaterial.com/software-testing/ “Testing shows the presence, not the absence of bugs.” —Edsger W. Dijkstra Edsger W. Dijkstra (May 11, 1930 - Aug 06, 2002) was a Dutch systems scientist, programmer, software engineer, science essayist, and pioneer in computing science. Bug Fault (also called “defect” or “bug”) is an erroneous hardware or software element of a system that can cause the system to fail. Reasons why software has bugs human mistakes in software design and coding. The longer a software bug exists throughout the product life-cycle, the more it costs. In 2002, software bugs cost the United States economy approximately $59.5 billion. In 2016, that number jumped to $1.1 trillion. https://dzone.com/articles/api-testing-best-practices 20 reasons for software bugs Reasons in development Reasons in testing #1) Miscommunication or No Communication #11) Not having a proper test setup (test environment) for testing all requirements.
    [Show full text]
  • Software Maintainability and Reusability Using Cohesion Metrics
    International Journal of Computer Trends and Technology (IJCTT) – Volume 54 Issue 2-December2017 Software Maintainability and Reusability using Cohesion Metrics Adekola, O.D#1, Idowu, S.A*2, Okolie, S.O#3, Joshua, J.V#4, Akinsanya, A.O*5, Eze, M.O#6, EbiesuwaSeun#7 #1Faculty, Computer Science Department, Babcock University,Ilishan-Remo, Ogun State, Nigeria *2Faculty, Computer Science Department, Babcock University,Ilishan-Remo, Ogun State, Nigeria #3Faculty, Computer Science Department, Babcock University,Ilishan-Remo, Ogun State, Nigeria #4Faculty, Computer Science Department, Babcock University,Ilishan-Remo, Ogun State, Nigeria *5Faculty, Computer Science Department, Babcock University,Ilishan-Remo, Ogun State, Nigeria #6Faculty, Computer Science Department, Babcock University,Ilishan-Remo, Ogun State, Nigeria #7Faculty, Computer Science Department, Babcock University,Ilishan-Remo, Ogun State, Nigeria Abstract - Among others, remarkable external software’s lifetime. Ahn et al., (2003) estimated that quality attributes of interest to software practitioners/ maintenance takes up to 80% of the total costof engineers include testability, maintainability and producing software applications. Expectation of reusability.Software engineers still combat achieving more reliable, quicker time-to-market and softwarecrisis and even chronic software affliction maintainable systems. A lot of research has gone into not because there is no standardized software the areas of software reuse and maintenance due to development process but because enough attention is the fact that these among other issues concern not given to seemingly insignificant but crucial intimately system developers/architects/engineers details of internal design attributes such as cohesion rather than end-users. Therehas been enormous and coupling especially in object-oriented systems. growth in software reuse research from the days of Consequently, the aftermath is increased structured programming concepts to object-oriented maintenance cost, effort and time which negatively methods and beyond (e.g.
    [Show full text]
  • Automated Testing of Firmware Installation and Update Scenarios for Peripheral Devices
    DEGREE PROJECT IN COMPUTER SCIENCE AND ENGINEERING, SECOND CYCLE, 30 CREDITS STOCKHOLM, SWEDEN 2019 Automated testing of firmware installation and update scenarios for peripheral devices DAG REUTERSKIÖLD KTH ROYAL INSTITUTE OF TECHNOLOGY SCHOOL OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCE Automated testing of firmware installation and update scenarios for peripheral devices DAG REUTERSKIÖLD Master in Computer Science Date: August 12, 2019 Supervisor: Hamid Faragardi Examiner: Elena Troubitsyna School of Electrical Engineering and Computer Science Host company: Tobii AB Swedish title: Automatisering av enhetsinstallation, uppdatering och testning med hjälp av virtuella maskiner iii Abstract This research presents an approach to transition from manual to automated testing of hardware specific firmware. The manual approach for firmware test- ing can be repetitive and time consuming. A significant proportion of the time is spent on cleaning and re-installing operating systems so that old firmware does not interfere with the newer firmware that is being tested. The approach in this research utilizes virtual machines and presents an automation framework. One component of the automation framework is an application to imitate con- nected peripheral devices to bypass hardware dependencies of firmware in- stallers. The framework also consists of automation and pipeline scripts with the objective to execute firmware installers and detect errors and abnormalities in the installation and updating processes. The framework can run on locally hosted virtual machines, but is most applicable using cloud hosted virtual ma- chines, where it is part of a continuous integration that builds, downloads, installs, updates and tests new firmware versions, in a completely automated manner. The framework is evaluated by measuring and comparing execution times with manually conducted installation and updating tests, and the result shows that the framework complete tests much faster than the manual approach.
    [Show full text]