DOCSLIB.ORG

ECP Software Technology Capability Assessment Report–Public

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
ECP Software Technology Capability Assessment Report–Public ECP-RPT-ST-0002-2020{Public ECP Software Technology Capability Assessment Report{Public Michael A. Heroux, Director ECP ST Jonathan Carter, Deputy Director ECP ST Rajeev Thakur, Programming Models & Runtimes Lead Jeffrey S. Vetter, Development Tools Lead Lois Curfman McInnes, Mathematical Libraries Lead James Ahrens, Data & Visualization Lead Todd Munson, Software Ecosystem & Delivery Lead J. Robert Neely, NNSA ST Lead February 1, 2020 DOCUMENT AVAILABILITY Reports produced after January 1, 1996, are generally available free via US Department of Energy (DOE) SciTech Connect. Website http://www.osti.gov/scitech/ Reports produced before January 1, 1996, may be purchased by members of the public from the following source: National Technical Information Service 5285 Port Royal Road Springfield, VA 22161 Telephone 703-605-6000 (1-800-553-6847) TDD 703-487-4639 Fax 703-605-6900 E-mail [email protected] Website http://www.ntis.gov/help/ordermethods.aspx Reports are available to DOE employees, DOE contractors, Energy Technology Data Exchange representatives, and International Nuclear Information System representatives from the following source: Office of Scientific and Technical Information PO Box 62 Oak Ridge, TN 37831 Telephone 865-576-8401 Fax 865-576-5728 E-mail [email protected] Website http://www.osti.gov/contact.html This report was prepared as an account of work sponsored by an agency of the United States Government. Neither the United States Government nor any agency thereof, nor any of their employees, makes any warranty, express or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, apparatus, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial product, process, or service by trade name, trademark, manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, or favoring by the United States Government or any agency thereof. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government or any agency thereof. ECP-RPT-ST-0002-2020{Public ECP Software Technology Capability Assessment Report{Public Office of Advanced Scientific Computing Research Office of Science US Department of Energy Office of Advanced Simulation and Computing National Nuclear Security Administration US Department of Energy February 1, 2020 Exascale Computing Project (ECP) iii ECP-RPT-ST-0002-2020{Public REVISION LOG Version Date Description 1.0 July 1, 2018 ECP ST Capability Assessment Report 1.5 February 1, 2019 Second release 2.0 February 1, 2020 Third release Exascale Computing Project (ECP) iv ECP-RPT-ST-0002-2020{Public EXECUTIVE SUMMARY The Exascale Computing Project (ECP) Software Technology (ST) Focus Area is responsible for developing critical software capabilities that will enable successful execution of ECP applications, and for providing key components of a productive and sustainable Exascale computing ecosystem that will position the US Department of Energy (DOE) and the broader high performance (HPC) community with a firm foundation for future extreme-scale computing capabilities. This ECP ST Capability Assessment Report (CAR) provides an overview and assessment of current ECP ST capabilities and activities, giving stakeholders and the broader HPC community information that can be used to assess ECP ST progress and plan their own efforts accordingly. ECP ST leaders commit to updating this document on regular basis (every six to 12 months). Highlights from this version of the report are presented here. What is new in CAR V2.0: CAR V2.0 contains the following updates relative to CAR V1.5. • We introduce the FY20{23 project structure. ECP ST now consists of 6 (up from 5) level-3 (L3) technical areas, introducing the NNSA ST L3 area, which brings into one L3 the ECP open source development efforts at NNSA labs that are of particular importance to the rest of ECP. The number of ECP ST level-4 (L4) subprojects has been reduced from 55 to 33. The strategic aggregation of projects into fewer and larger units enables us to better manage L4 subprojects consistently as a portfolio. See Section 1.2. • We describe new and enhanced project management processes and resources including our iterative planning process, new KPP-3 capability integration process, a product dictionary and dependency management database. These new project features and related dashboards enable more insight and better information to effectively manage efforts across ECP. See Section2. • The two-page summaries of each ECP L4 projects have been updated to reflect recent progress and next steps. See Section4. • The Extreme-scale Scientific Software Stack (E4S) is further described. The third release, which is also the first major public release Version 1.0, was November 18, 2019. E4S is the primary integration and delivery vehicle for ECP ST capabilities. See Section 2.1.1. • The ECP ST SDK effort has further refined its groupings. See Section 2.1.2. The Exascale Computing Project Software Technology (ECP ST) focus area represents the key bridge between Exascale systems and the scientists developing applications that will run on those platforms. ECP ST efforts contribute to 70 software products (Section 2.1.3) in six technical areas (Table1). Since the publishing of CAR V1.5, we have introduced a product dictionary of official product names, which enables more rigorous mapping of ECP ST deliverables to stakeholders (Section 2.1.4). Programming Models & Runtimes: In addition to developing key enhancements to MPI and OpenMP for scalable systems with accelerated node architectures, we are working on performance portability layers (Kokkos and RAJA) and participating in OpenMP and OpenACC software design and development that will enable applications to write much of their source code without the need to provide vendor-specific implementations for each exascale system. We anticipate that one legacy of ECP ST efforts will be a software stack that supports Intel and AMD accelerators in addition to Nvidia. See Section 4.1. Development Tools: We are enhancing existing widely used compilers (LLVM) and performance tools for next-generation platforms. Compilers are critical for heterogeneous architectures, and LLVM is the most popular compiler for heterogeneous systems. As node architectures become more complicated and concurrency even more necessary, compilers must generate optimized code for many architectures, and the impediments to performance and scalability become even harder to diagnose and fix. Development tools provide essential insight into these performance challenges and code transformation and support capabilities that help software teams generate efficient code, utilize new memory systems and more. See Section 4.2. Mathematical Libraries: High-performance scalable math libraries have enabled parallel execution of many applications for decades. ECP ST is providing the next generation of these libraries to address needs for latency hiding, improved vectorization, threading and strong scaling. In addition, we are addressing Exascale Computing Project (ECP) v ECP-RPT-ST-0002-2020{Public new demands for system-wide scalability including improved support for coupled systems and ensemble calculations. See Section 4.3. The math libraries teams are also spearheading the software development kit (SDK) initiative that is a pillar of the ECP ST software delivery strategy (Section 2.1.2). Data & Visualization: ECP ST has a large collection of data management and visualization products that provide essential capabilities for compressing, analyzing, moving and managing data. These tools are becoming even more important as the volume of simulation data we produce grows faster than our ability to capture and interpret it. See Section 4.4. SW Ecosystem & Delivery: This technical area of ECP ST provides important enabling technologies such as Spack [1], a from-source build and package manager, and container environments for high-performance computers. This area also provides the critical resources and staffing that will enable ECP ST to perform continuous integration testing, and product releases. Finally, this area engages with software and system vendors, and DOE facilities staff to assure coordinated planning and support of ECP ST products. See Section 4.5. NNSA ST: This technical area brings into one L3 area all of the NNSA-funded work in ECP ST for easier coordination with other project work at the NNSA labs. Introducing this L3 enables continued integrated planning with the rest of ECP ST while permitting flexible coordination within the NNSA labs. See Section 4.6. ECP ST Software Delivery mechanisms: ECP ST delivers software capabilities to users via several mechanisms (Section3). Almost all products are delivered via source code to at least some of their users. Each of the major DOE computing facilities provides direct support of some users for about 20 ECP ST products. About 10 products are available via vendor software stack and via binary distributions such as Linux distributions. ECP ST Project Restructuring: ECP ST completed a significant restructuring in October 2019 (Section 1.2). We increased the number of technical areas from 5 to 6 and reduced the number of L4 projects from 55 to 33. We introduced a new L4 subproject for software packaging and delivery in the L3 technical area (SW Ecosystem & Delivery) that enhances existing NNSA funding for Spack and creates
Load more

Recommended publications
  • Writing Quality Software
    Writing Quality Software About this white paper: This whitepaper was written by David C. Young, an employee of General Dynamics Information Technology (GDIT). Dr. Young is part of a team of GDIT employees who maintain, and support high performance computing systems at the Alabama Supercomputer Center (ASC). This was written in 2020. This paper is written for people who want to write good software, but don’t have a master’s degree in software architecture (or someone managing the project who does). Much of what is here would be covered in a software development practices class, often taught at the master’s degree level. Writing quality software is not only about the satisfaction of a job well done. It is also reflects on you and your professional reputation amongst your peers. In some cases writing quality software can be a factor in getting a job, losing a job, or even life or death. Furthermore, writing quality software should be considered an implicit requirement in every software development project. If the intended useful life of the software is many years, that is yet another reason to do a good job writing it. Introduction Consider this situation, which is all too common. You have written a really neat piece of software. You put it out on github, then tell your colleagues about it. Soon you are bombarded with a series of complaints from people who tried to install, and use your software. Some of those complaints might be; • It won’t install on their version of Linux. • They did the same thing you reported, but got a different answer.
    [Show full text]
  • Studying the Feasibility and Importance of Software Testing: an Analysis
    Dr. S.S.Riaz Ahamed / Internatinal Journal of Engineering Science and Technology Vol.1(3), 2009, 119-128 STUDYING THE FEASIBILITY AND IMPORTANCE OF SOFTWARE TESTING: AN ANALYSIS Dr.S.S.Riaz Ahamed Principal, Sathak Institute of Technology, Ramanathapuram,India. Email:[email protected], [email protected] ABSTRACT Software testing is a critical element of software quality assurance and represents the ultimate review of specification, design and coding. Software testing is the process of testing the functionality and correctness of software by running it. Software testing is usually performed for one of two reasons: defect detection, and reliability estimation. The problem of applying software testing to defect detection is that software can only suggest the presence of flaws, not their absence (unless the testing is exhaustive). The problem of applying software testing to reliability estimation is that the input distribution used for selecting test cases may be flawed. The key to software testing is trying to find the modes of failure - something that requires exhaustively testing the code on all possible inputs. Software Testing, depending on the testing method employed, can be implemented at any time in the development process. Keywords: verification and validation (V & V) 1 INTRODUCTION Testing is a set of activities that could be planned ahead and conducted systematically. The main objective of testing is to find an error by executing a program. The objective of testing is to check whether the designed software meets the customer specification. The Testing should fulfill the following criteria: ¾ Test should begin at the module level and work “outward” toward the integration of the entire computer based system.
    [Show full text]
  • Reliability: Software Software Vs
    Reliability Theory SENG 521 Re lia bility th eory d evel oped apart f rom th e mainstream of probability and statistics, and Software Reliability & was usedid primar ily as a tool to h hlelp Software Quality nineteenth century maritime and life iifiblinsurance companies compute profitable rates Chapter 5: Overview of Software to charge their customers. Even today, the Reliability Engineering terms “failure rate” and “hazard rate” are often used interchangeably. Department of Electrical & Computer Engineering, University of Calgary Probability of survival of merchandize after B.H. Far （[email protected]） 1 http://www. enel.ucalgary . ca/People/far/Lectures/SENG521/ ooene MTTF is R e 0.37 From Engineering Statistics Handbook [email protected] 1 [email protected] 2 Reliability: Natural System Reliability: Hardware Natural system Hardware life life cycle. cycle. Aging effect: Useful life span Life span of a of a hardware natural system is system is limited limited by the by the age (wear maximum out) of the system. reproduction rate of the cells. Figure from Pressman’s book Figure from Pressman’s book [email protected] 3 [email protected] 4 Reliability: Software Software vs. Hardware So ftware life cyc le. Software reliability doesn’t decrease with Software systems time, i.e., software doesn’t wear out. are changed (updated) many Hardware faults are mostly physical faults, times during their e. g., fatigue. life cycle. Each update adds to Software faults are mostly design faults the structural which are harder to measure, model, detect deterioration of the and correct. software system. Figure from Pressman’s book [email protected] 5 [email protected] 6 Software vs.
    [Show full text]
  • Manual on Quality Assurance for Computer Software Related to the Safety of Nuclear Power Plants
    SIMPLIFIED SOFTWARE LIFE-CYCLE DIAGRAM FEASIBILITY STUDY PROJECT TIME I SOFTWARE P FUNCTIONAL I SPECIFICATION! SOFTWARE SYSTEM DESIGN DETAILED MODULES CECIFICATION MODULES DESIGN SOFTWARE INTEGRATION AND TESTING SYSTEM TESTING ••COMMISSIONING I AND HANDOVER | DECOMMISSION DESIGN DESIGN SPECIFICATION VERIFICATION OPERATION AND MAINTENANCE SOFTWARE LIFE-CYCLE PHASES TECHNICAL REPORTS SERIES No. 282 Manual on Quality Assurance for Computer Software Related to the Safety of Nuclear Power Plants f INTERNATIONAL ATOMIC ENERGY AGENCY, VIENNA, 1988 MANUAL ON QUALITY ASSURANCE FOR COMPUTER SOFTWARE RELATED TO THE SAFETY OF NUCLEAR POWER PLANTS The following States are Members of the International Atomic Energy Agency: AFGHANISTAN GUATEMALA PARAGUAY ALBANIA HAITI PERU ALGERIA HOLY SEE PHILIPPINES ARGENTINA HUNGARY POLAND AUSTRALIA ICELAND PORTUGAL AUSTRIA INDIA QATAR BANGLADESH INDONESIA ROMANIA BELGIUM IRAN, ISLAMIC REPUBLIC OF SAUDI ARABIA BOLIVIA IRAQ SENEGAL BRAZIL IRELAND SIERRA LEONE BULGARIA ISRAEL SINGAPORE BURMA ITALY SOUTH AFRICA BYELORUSSIAN SOVIET JAMAICA SPAIN SOCIALIST REPUBLIC JAPAN SRI LANKA CAMEROON JORDAN SUDAN CANADA KENYA SWEDEN CHILE KOREA, REPUBLIC OF SWITZERLAND CHINA KUWAIT SYRIAN ARAB REPUBLIC COLOMBIA LEBANON THAILAND COSTA RICA LIBERIA TUNISIA COTE D'lVOIRE LIBYAN ARAB JAMAHIRIYA TURKEY CUBA LIECHTENSTEIN UGANDA CYPRUS LUXEMBOURG UKRAINIAN SOVIET SOCIALIST CZECHOSLOVAKIA MADAGASCAR REPUBLIC DEMOCRATIC KAMPUCHEA MALAYSIA UNION OF SOVIET SOCIALIST DEMOCRATIC PEOPLE'S MALI REPUBLICS REPUBLIC OF KOREA MAURITIUS UNITED ARAB
    [Show full text]
  • Software Quality Assurance Activities in Software Testing
    Software Quality Assurance Activities In Software Testing Tony never synopsizing any recidivist gazetting thus, is Brooke oncogenic and insolvable enough? Monogenous Chadd externalises, his disciplinarians denudes spring-clean Germanically. Spindliest Antoni never humors so edgewise or attain any shells lyingly. Each module performs one or two tasks, and thenpasses control to another module. Perform test automation for web application using Cucumber. Identify and describe safety software procurement methods, including supplier evaluation and source inspection processes. He previously worked at IBM SWS Toronto Lab. The information maintained in status accounting should enable the rebuild of any previous baseline. Beta Breakers supports all industry sectors. Thank you save time for all the lack of that includes test software assurance and must often. Focus on demonstrating pos next column containing algorithms, activities in software quality assurance testing activities of testing programs for their findings from his piece of skills, validate features to refresh teh page object. XML data sets to simulate production, using LLdap and ALTOVA. Schedule information should be expressed as absolute dates, as dates relative to either SCM or project milestones, or as a simple sequence of events. Its scope of software quality assurance and the correct email list all testshave been completely correct, in software quality assurance activities to be precisely known about its process on a familiarity level. These exercises are performed at every step along the way in the workshop. However, you have to balance driving out quality with production value. The second step is the validation of the computer system implementation against the computer system requirements. Software development tools, whose output becomes part of the program implementation and which can therefore introduce errors.
    [Show full text]
  • Renesas' Synergy Software Quality Handbook
    User’s Manual Synergy Software Quality Handbook Notice 1. Renesas Synergy™ Platform User’s Manual Synergy Software Software Quality Assurance All information contained in these materials, including products and product specifications, represents information on the product at the time of publication and is subject to change by Renesas Electronics Corp. without notice. Please review the latest information published by Renesas Electronics Corp. through various means, including the Renesas Electronics Corp. website (http://www.renesas.com). www.renesas.com Rev. 4.0 April 2019 Synergy Software Quality Handbook Descriptions of circuits, software and other related information in this document are provided only to illustrate the operation of semiconductor products and application examples. You are fully responsible for the incorporation or any other use of the circuits, software, and information in the design of your product or system. Renesas Electronics disclaims any and all liability for any losses and damages incurred by you or third parties arising from the use of these circuits, software, or information. 2. Renesas Electronics hereby expressly disclaims any warranties against and liability for infringement or any other disputes involving patents, copyrights, or other intellectual property rights of third parties, by or arising from the use of Renesas Electronics products or technical information described in this document, including but not limited to, the product data, drawing, chart, program, algorithm, application examples. 3. No license, express, implied or otherwise, is granted hereby under any patents, copyrights or other intellectual property rights of Renesas Electronics or others. 4. You shall not alter, modify, copy, or otherwise misappropriate any Renesas Electronics product, whether in whole or in part.
    [Show full text]
  • Literature Review and Implementation Overview: High Performance
    LITERATURE REVIEW AND IMPLEMENTATION OVERVIEW: HIGH PERFORMANCE COMPUTING WITH GRAPHICS PROCESSING UNITS FOR CLASSROOM AND RESEARCH USE APREPRINT Nathan George Department of Data Sciences Regis University Denver, CO 80221 [email protected] May 18, 2020 ABSTRACT In this report, I discuss the history and current state of GPU HPC systems. Although high-power GPUs have only existed a short time, they have found rapid adoption in deep learning applications. I also discuss an implementation of a commodity-hardware NVIDIA GPU HPC cluster for deep learning research and academic teaching use. Keywords GPU · Neural Networks · Deep Learning · HPC 1 Introduction, Background, and GPU HPC History High performance computing (HPC) is typically characterized by large amounts of memory and processing power. HPC, sometimes also called supercomputing, has been around since the 1960s with the introduction of the CDC STAR-100, and continues to push the limits of computing power and capabilities for large-scale problems [1, 2]. However, use of graphics processing unit (GPU) in HPC supercomputers has only started in the mid to late 2000s [3, 4]. Although graphics processing chips have been around since the 1970s, GPUs were not widely used for computations until the 2000s. During the early 2000s, GPU clusters began to appear for HPC applications. Most of these clusters were designed to run large calculations requiring vast computing power, and many clusters are still designed for that purpose [5]. GPUs have been increasingly used for computations due to their commodification, following Moore’s Law (demonstrated arXiv:2005.07598v1 [cs.DC] 13 May 2020 in Figure 1), and usage in specific applications like neural networks.
    [Show full text]
  • Evaluating and Improving Software Quality Using Text Analysis Techniques - a Mapping Study
    Evaluating and Improving Software Quality Using Text Analysis Techniques - A Mapping Study Faiz Shah, Dietmar Pfahl Institute of Computer Science, University of Tartu J. Liivi 2, Tartu 50490, Estonia {shah, dietmar.pfahl}@ut.ee Abstract: Improvement and evaluation of software quality is a recurring and crucial activ- ity in the software development life-cycle. During software development, soft- ware artifacts such as requirement documents, comments in source code, design documents, and change requests are created containing natural language text. For analyzing natural text, specialized text analysis techniques are available. However, a consolidated body of knowledge about research using text analysis techniques to improve and evaluate software quality still needs to be estab- lished. To contribute to the establishment of such a body of knowledge, we aimed at extracting relevant information from the scientific literature about data sources, research contributions, and the usage of text analysis techniques for the im- provement and evaluation of software quality. We conducted a mapping study by performing the following steps: define re- search questions, prepare search string and find relevant literature, apply screening process, classify, and extract data. Bug classification and bug severity assignment activities within defect manage- ment are frequently improved using the text analysis techniques of classifica- tion and concept extraction. Non-functional requirements elicitation activity of requirements engineering is mostly improved using the technique of concept extraction. The quality characteristic which is frequently evaluated for the prod- uct quality model is operability. The most commonly used data sources are: bug report, requirement documents, and software reviews. The dominant type of re- search contributions are solution proposals and validation research.
    [Show full text]
  • Proposing a Methodology to Evaluate Usability of E-Commerce Websites: QUEM Model
    International Journal of Computer Applications (0975 – 8887) Volume 52 – No. 6, August 2012 Proposing a Methodology to Evaluate Usability of E-Commerce Websites: QUEM Model Nasrin Dehbozorgi Shahram Jafari School of e-Learning, School of Electrical and Computer Engineering Shiraz University Shiraz University ABSTRACT e-commerce websites. For customizing these characteristics In this work we propose a methodology named QUEM specifically for e-commerce websites, a wide range of usability (Quantitative Usability Evaluation Model) for quantitative guidelines and checklists were studied, which were mainly usability evaluation of e-commerce websites. Many centered on works done by Nielsen, IBM and W3G guidelines. e-commerce websites lack user friendliness. The main factor Hence, in our model -which is named QUEM model- we that prevents these firms to conduct usability testing is the high propose a generic set of sub-characteristics for evaluation of e- costs and the need for usability experts. In this work, commerce websites. ISO/IEC 9126-1:2001 quality model was selected as a basis for defining usability characteristics of our model. Based on these In the following sections we will have an overview on existing standard usability characteristics a set of usability factors is quality evaluation methods and approaches. Then the research proposed specifically for evaluation of e-commerce websites. methodology will be discussed. Finally in the experimental The usability factors of QUEM model have been extracted from result section, the presented QUEM model is applied on two a wide range of usability guidelines and checklists. Since all of e-commerce systems and their usability is assessed and the usability factors do not have the same significance in the quantified into numerical values and compared with each other.
    [Show full text]
  • Arm HPC Software Stack and HPC Tools
    Arm HPC Software Stack and HPC Tools Centre for Development of Advanced Computing (C-DAC) / National Supercomputing Mission (NSM) Arm in HPC Course Phil Ridley [email protected] 2nd March 2021 © 2021 Arm Agenda • HPC Software Ecosystem • Overview • Applications • Community Support • Compilers, Libraries and Tools • Open-source and Commercial – Compilers – Maths Libraries • Profiling and Debugging 2 © 2021 Arm Software Ecosystem © 2021 Arm HPC Ecosystem Applications Performance Open-source, owned, coMMercial ISV codes, … Engineering … PBS Pro, Altair LSF, IBM SLURM, ArM Forge (DDT, MAP), Rogue Wave, HPC Toolkit, Schedulers Containers, Interpreters, etc. Management Cluster Scalasca, VaMpir, TAU, … Singularity, PodMan, Docker, Python, … HPE CMU, Bright, Middleware Mellanox IB/OFED/HPC-X, OpenMPI, MPICH, MVAPICH2, OpenSHMEM, OpenUCX, HPE MPI xCat Compilers Libraries Filesystems , Warewulf OEM/ODM’s ArM, GNU, LLVM, Clang, Flang, ArMPL, FFTW, OpenBLAS, BeeGFS, Lustre, ZFS, Cray-HPE, ATOS-Bull, Cray, PGI/NVIDIA, Fujitsu, … NuMPy, SciPy, Trilinos, PETSc, HDF5, NetCDF, GPFS, … Fujitsu, Gigabyte, … Hypre, SuperLU, ScaLAPACK, … , … Silicon OS RHEL, SUSE, CentOS, Ubuntu, … Suppliers Marvell, Fujitsu, Arm Server Ready Platform Mellanox, NVIDIA, … Standard firMware and RAS 4 © 2021 Arm General Software Ecosystem Workloads Drone.io Language & Library CI/CD Container & Virtualization Operating System Networking 5 © 2021 Arm – Easy HPC stack deployment on Arm https://developer.arm.com/solutions/hpc/hpc-software/openhpc Functional Areas Components include OpenHPC is a community effort to provide a Base OS CentOS 8.0, OpenSUSE Leap 15 common, verified set of open source packages for Administrative Tools Conman, Ganglia, Lmod, LosF, Nagios, pdsh, pdsh-mod- slurm, prun, EasyBuild, ClusterShell, mrsh, Genders, HPC deployments Shine, test-suite Arm and partners actively involved: Provisioning Warewulf Resource Mgmt.
    [Show full text]
  • Pdf: Software Testing
    Software Testing Gregory M. Kapfhammer Department of Computer Science Allegheny College [email protected] I shall not deny that the construction of these testing programs has been a major intellectual effort: to convince oneself that one has not overlooked “a relevant state” and to convince oneself that the testing programs generate them all is no simple matter. The encouraging thing is that (as far as we know!) it could be done. Edsger W. Dijkstra [Dijkstra, 1968] 1 Introduction When a program is implemented to provide a concrete representation of an algorithm, the developers of this program are naturally concerned with the correctness and performance of the implementation. Soft- ware engineers must ensure that their software systems achieve an appropriate level of quality. Software verification is the process of ensuring that a program meets its intended specification [Kaner et al., 1993]. One technique that can assist during the specification, design, and implementation of a software system is software verification through correctness proof. Software testing, or the process of assessing the func- tionality and correctness of a program through execution or analysis, is another alternative for verifying a software system. As noted by Bowen, Hinchley, and Geller, software testing can be appropriately used in conjunction with correctness proofs and other types of formal approaches in order to develop high quality software systems [Bowen and Hinchley, 1995, Geller, 1978]. Yet, it is also possible to use software testing techniques in isolation from program correctness proofs or other formal methods. Software testing is not a “silver bullet” that can guarantee the production of high quality software systems.
    [Show full text]
  • Beginners Guide to Software Testing
    Beginners Guide To Software Testing Beginners Guide To Software Testing - Padmini C Page 1 Beginners Guide To Software Testing Table of Contents: 1. Overview ........................................................................................................ 5 The Big Picture ............................................................................................... 5 What is software? Why should it be tested? ................................................. 6 What is Quality? How important is it? ........................................................... 6 What exactly does a software tester do? ...................................................... 7 What makes a good tester? ........................................................................... 8 Guidelines for new testers ............................................................................. 9 2. Introduction .................................................................................................. 11 Software Life Cycle ....................................................................................... 11 Various Life Cycle Models ............................................................................ 12 Software Testing Life Cycle .......................................................................... 13 What is a bug? Why do bugs occur? ............................................................ 15 Bug Life Cycle ............................................................................................... 16 Cost of fixing bugs .......................................................................................
    [Show full text]