DOCSLIB.ORG

Methods, Recommendations and Guidelines for Web and Communication Based Space Systems

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Methods, Recommendations and Guidelines for Web and Communication Based Space Systems Ref : SPAW.TN.T.ASTR.0023 Issue : 1 Rev. : 2 Date : 15/09/06 Page : 1 SSPPAAWW Software Product Assurance for Web and communication based Space Systems Contract N. 16 811/02/NL/SFe - CCN4 Methods, recommendations and guidelines for web and communication based space systems Identifier TN2 Version 1.2 Date of issue 15/09/06 Prepared by Name P. Pleczon Signature Company EADS ASTRIUM A. Canals CS-SI Verified by Name JM Dussauze Signature Company EADS ASTRIUM Software Product Assurance for W eb and communication based space systems Ref : SPAW.TN.T.ASTR.0023 Issue : 1 Rev. : 2 Date : 15/09/06 Page : 2 Abstract The purpose of this document is to propose methods, recommendations and guidelines for the design of web and communication based space systems. Section 2 exhibits the feedback extracted from space and non space web and communication based projects managed by EADS Astrium and CS. This section analyse each project and highlights their successes and failures and some recommendations built from their experience. Section 3 is a review of the state of the art of Product Assurance practices on web-based projects in literature and www. Section 4 proposes a synthesis of some data issued from sections 2 and 3: the recommendations issued from analysed projects, a synthesis on the technology adequacy to systems requirements, an overview of the language PA issues a discussion on the COTS/Open Source components concerns. Section 5 recommends a set of guidelines for web-based and communication based systems PA. Section 6 lists open points raised by the study but not covered by the current work. Section 7 list the references (papers, web-sites, product references…) used to elaborate the study. Software Product Assurance Copyright © European Space Agency 2006 for W eb and communication based space systems - 2 - Ref : SPAW.TN.T.ASTR.0023 Issue : 1 Rev. : 2 Date : 15/09/06 Page : 3 DOCUMENT CHANGE LOG Issue/ Date Modification Nb Modified pages Observations Revision 1.0 20/06/06 All Initial version 1.1 19/07/06 Updated after ESTEC comments. 1.2 15/09/06 §3.6.1, 3.6.5, Final update 3.9 added. §3.7 reworded. Guideline 25 reworded. Guideline 28 deleted. §6.1 introduction added. Various rewording and explanations added. Software Product Assurance for W eb and communication based space systems Ref : SPAW.TN.T.ASTR.0023 Issue : 1 Rev. : 2 Date : 15/09/06 Page : 4 The “Software Product Assurance for Web and communication based Space Systems” (SPAW) study is an ESA project which is conducted by EADS ASTRIUM with CS. For further information on this study, please contact: ESTEC, European Space Agency PO Box 299, NL-2200 AG Noordwijk ZH-The Netherlands Maria GARCIA-REINALDOS, SPAW ESTEC Technical Officer Tel : (31) 71 565 3964 Fax : (31) 71 565 4798 [email protected] EADS ASTRIUM France 31, rue des Cosmonautes, ZI du Palays 31 402 Toulouse Cedex - France Patrick PLECZON, Project Manager Tel : (33) 5 6219 6697 Fax : (33) 5 6219 7999 [email protected] CS Systèmes d'Information Parc de la Plaine Rue Brindejonc des Moulinais – BP 15872 F - 31506 TOULOUSE Cedex 5 - FRANCE Agusti CANALS Tel : +33 5 61 17 66 15 Fax : +33 5 61 54.13.39 [email protected] Software Product Assurance Copyright © European Space Agency 2006 for W eb and communication based space systems - 4 - Ref : SPAW.TN.T.ASTR.0023 Issue : 1 Rev. : 2 Date : 15/09/06 Page : 5 Contributors to this document The people listed below have contributed to this document by providing information on their projects. Serge BARROS EADS Astrium Pierre BORNUAT CS Patrice BRISON CS Patrick DUC EADS Astrium Olivier ETIENNE CS Dominique LAPEYRONIE CS Philippe ROUZET EADS Astrium CS and EADS Astrium Projects teams Software Product Assurance for W eb and communication based space systems Ref : SPAW.TN.T.ASTR.0023 Issue : 1 Rev. : 2 Date : 15/09/06 Page : 6 Table of Contents 1. Introduction _________________________________________________________________9 1.1. Purpose and scope of the document_________________________________________________9 1.2. Glossary and Acronyms _________________________________________________________10 1.3. Terms and definitions ___________________________________________________________12 1.4. Applicable and Reference Documents ______________________________________________16 2. Projects Analysis_____________________________________________________________17 2.1. SIPAD-NG ____________________________________________________________________17 2.1.1. Projects main characteristics description_________________________________________________ 17 2.1.2. Lessons learned ____________________________________________________________________ 22 2.1.3. Successes and Failures_______________________________________________________________ 24 2.1.4. Successes and Failures from similar projects _____________________________________________ 26 2.2. COROLLE ____________________________________________________________________29 2.2.1. Projects main characteristics description_________________________________________________ 29 2.2.2. Lessons learned ____________________________________________________________________ 32 2.2.3. Successes and Failures_______________________________________________________________ 33 2.3. ATV-CC ______________________________________________________________________35 2.3.1. Projects main characteristics description_________________________________________________ 35 2.3.2. Lessons learned ____________________________________________________________________ 41 2.3.3. Successes and Failures_______________________________________________________________ 47 2.4. PROTEUS/MYRIADE __________________________________________________________48 2.4.1. Projects main characteristics description_________________________________________________ 48 2.4.2. Lessons learned ____________________________________________________________________ 50 2.4.3. Successes and Failures_______________________________________________________________ 52 2.5. RSB __________________________________________________________________________54 2.5.1. Projects main characteristics description_________________________________________________ 54 2.5.2. Lessons learned ____________________________________________________________________ 55 2.5.3. Successes and Failures_______________________________________________________________ 56 2.6. PAC-LUX _____________________________________________________________________58 2.6.1. Projects main characteristics description_________________________________________________ 58 2.6.2. Lessons learned ____________________________________________________________________ 59 2.6.3. Successes and Failures_______________________________________________________________ 61 2.7. FERIA________________________________________________________________________63 2.7.1. Architecture overview _______________________________________________________________ 63 2.7.2. subsystems breakdown ______________________________________________________________ 64 2.7.3. Lessons learned ____________________________________________________________________ 65 Software Product Assurance Copyright © European Space Agency 2006 for W eb and communication based space systems - 6 - Ref : SPAW.TN.T.ASTR.0023 Issue : 1 Rev. : 2 Date : 15/09/06 Page : 7 2.7.4. Successes and Failures_______________________________________________________________ 66 2.8. Astrium CC ___________________________________________________________________67 2.8.1. Projects main characteristics description_________________________________________________ 67 2.8.2. Lessons learned ____________________________________________________________________ 73 2.8.3. Successes and Failures_______________________________________________________________ 76 2.9. Phase 3 - AFP__________________________________________________________________78 2.9.1. Projects main characteristics description_________________________________________________ 78 2.9.2. Lessons learned ____________________________________________________________________ 79 2.9.3. Successes and Failures_______________________________________________________________ 80 2.10. Military Mission Centre for observation satellite___________________________________83 2.10.1. Projects main characteristics description_________________________________________________ 83 2.10.2. Lessons learned ____________________________________________________________________ 84 2.10.3. Successes and Failures_______________________________________________________________ 85 3. State of the art in Literature and www____________________________________________86 3.1. Introduction ___________________________________________________________________86 3.2. Estimating methods_____________________________________________________________87 3.3. Requirement Analysis ___________________________________________________________89 3.4. Configuration Management ______________________________________________________89 3.5. Design ________________________________________________________________________90 3.6. Architectures __________________________________________________________________91 3.6.1. Low level protocols and middleware____________________________________________________ 91 3.6.2. SOA (Service oriented Architecture)____________________________________________________ 93 3.6.3. AJAX____________________________________________________________________________ 93 3.6.4. MOM and JMS ____________________________________________________________________ 94 3.6.5. Connection Oriented vs. Connectionless_________________________________________________
Load more

Recommended publications
  • JSF Quickstart -- Myeclipse Enterprise Workbench
    JSF Quickstart Last Revision: September 26, 2005 Outline 1. P reface 2. I ntroduction 3. R equirements 4. N ew Project Setup & S tructure 5. C reating the Message Bundle 6. C reating the Managed Bean 7. C reating the JSP Pages 8. R unning the Application 9. S ummary 10.U ser Feedback 1. Preface This document was written using Sun JDK 1.5.0, Eclipse 3.1 and MyEclipse 4.0. If you notice discrepancies between this document and the version of Eclipse/MyEclipse you are using to perform the install that make it difficult or impossible to follow this guide, please see the User Feedback section on how to report the issue. Back to Top 2. Introduction In this tutorial we will be walking through a small JSF demo application using MyEclipse Enterprise Workbench. Previous knowledge of JSF and/or MyEclipse is not necessary, but would be helpful. Since Struts is such a prevalent web application framework, similarities between JSF and Struts will be noted, where appropriate, to help the reader with previous Struts experience. However, if you have no prior experience with Struts, you may feel free to skip these sections . Back to Top 3. Requirements Below is a list of software used by this guide: • JDK 1.4+ (Sun or IBM) • h ttp://java.sun.com/j2se/downloads/index.html • Eclipse 3.1 SDK • h ttp://www.eclipse.org/downloads/index.php • MyEclipse 4.1 • h ttp://www.myeclipseide.com/ContentExpress-display-ceid-10.html • Tomcat 5.x (5.5.9 Preferred, or other compliant Servlet/EJB container) • h ttp://jakarta.apache.org/tomcat/index.html • For this demo the User Name is "myeclipse" and the Password is "myeclipse" as well.
    [Show full text]
  • Parasoft Static Application Security Testing (SAST) for .Net - C/C++ - Java Platform
    Parasoft Static Application Security Testing (SAST) for .Net - C/C++ - Java Platform Parasoft® dotTEST™ /Jtest (for Java) / C/C++test is an integrated Development Testing solution for automating a broad range of testing best practices proven to improve development team productivity and software quality. dotTEST / Java Test / C/C++ Test also seamlessly integrates with Parasoft SOAtest as an option, which enables end-to-end functional and load testing for complex distributed applications and transactions. Capabilities Overview STATIC ANALYSIS ● Broad support for languages and standards: Security | C/C++ | Java | .NET | FDA | Safety-critical ● Static analysis tool industry leader since 1994 ● Simple out-of-the-box integration into your SDLC ● Prevent and expose defects via multiple analysis techniques ● Find and fix issues rapidly, with minimal disruption ● Integrated with Parasoft's suite of development testing capabilities, including unit testing, code coverage analysis, and code review CODE COVERAGE ANALYSIS ● Track coverage during unit test execution and the data merge with coverage captured during functional and manual testing in Parasoft Development Testing Platform to measure true test coverage. ● Integrate with coverage data with static analysis violations, unit testing results, and other testing practices in Parasoft Development Testing Platform for a complete view of the risk associated with your application ● Achieve test traceability to understand the impact of change, focus testing activities based on risk, and meet compliance
    [Show full text]
  • Email: [email protected] Website
    Email: [email protected] Website: http://chrismatech.com Experienced software and systems engineer who has successfully deployed custom & industry-standard embedded, desktop and networked systems for commercial and DoD customers. Delivered systems operate on airborne, terrestrial, maritime, and space based vehicles and platforms. Expert in performing all phases of the software and system development life-cycle including: Creating requirements and design specifications. Model-driven software development, code implementation, and unit test. System integration. Requirements-based system verification with structural coverage at the system and module levels. Formal qualification/certification test. Final product packaging, delivery, and site installation. Post-delivery maintenance and customer support. Requirements management and end-to-end traceability. Configuration management. Review & control of change requests and defect reports. Quality assurance. Peer reviews/Fagan inspections, TIMs, PDRs and CDRs. Management and project planning proficiencies include: Supervising, coordinating, and mentoring engineering staff members. Creating project Software Development Plans (SDPs). Establishing system architectures, baseline designs, and technical direction. Creating & tracking project task and resource scheduling, costs, resource utilization, and metrics (e.g., Earned Value Analysis). Preparing proposals in response to RFPs and SOWs. Project Management • Microsoft Project, Excel, Word, PowerPoint, Visio & Documentation: • Adobe Acrobat Professional
    [Show full text]
  • Survey of Verification and Validation Techniques for Small Satellite Software Development
    Survey of Verification and Validation Techniques for Small Satellite Software Development Stephen A. Jacklin NASA Ames Research Center Presented at the 2015 Space Tech Expo Conference May 19-21, Long Beach, CA Summary The purpose of this paper is to provide an overview of the current trends and practices in small-satellite software verification and validation. This document is not intended to promote a specific software assurance method. Rather, it seeks to present an unbiased survey of software assurance methods used to verify and validate small satellite software and to make mention of the benefits and value of each approach. These methods include simulation and testing, verification and validation with model-based design, formal methods, and fault-tolerant software design with run-time monitoring. Although the literature reveals that simulation and testing has by far the longest legacy, model-based design methods are proving to be useful for software verification and validation. Some work in formal methods, though not widely used for any satellites, may offer new ways to improve small satellite software verification and validation. These methods need to be further advanced to deal with the state explosion problem and to make them more usable by small-satellite software engineers to be regularly applied to software verification. Last, it is explained how run-time monitoring, combined with fault-tolerant software design methods, provides an important means to detect and correct software errors that escape the verification process or those errors that are produced after launch through the effects of ionizing radiation. Introduction While the space industry has developed very good methods for verifying and validating software for large communication satellites over the last 50 years, such methods are also very expensive and require large development budgets.
    [Show full text]
  • An Eclipse Plug-In for Testing and Debugging
    GZoltar: An Eclipse Plug-In for Testing and Debugging José Campos André Riboira Alexandre Perez Rui Abreu Department of Informatics Engineering Faculty of Engineering, University of Porto Portugal {jose.carlos.campos, andre.riboira, alexandre.perez}@fe.up.pt; [email protected] ABSTRACT coverage). Several debugging tools exist which are based on Testing and debugging is the most expensive, error-prone stepping through the execution of the program (e.g., GDB phase in the software development life cycle. Automated and DDD). These traditional, manual fault localization ap- testing and diagnosis of software faults can drastically proaches have a number of important limitations. The place- improve the efficiency of this phase, this way improving ment of print statements as well as the inspection of their the overall quality of the software. In this paper we output are unstructured and ad-hoc, and are typically based present a toolset for automatic testing and fault localiza- on the developer's intuition. In addition, developers tend to use only test cases that reveal the failure, and therefore do tion, dubbed GZoltar, which hosts techniques for (regres- sion) test suite minimization and automatic fault diagno- not use valuable information from (the typically available) sis (namely, spectrum-based fault localization). The toolset passing test cases. provides the infrastructure to automatically instrument the Aimed at drastic cost reduction, much research has been source code of software programs to produce runtime data. performed in developing automatic testing and fault local- Subsequently the data was analyzed to both minimize the ization techniques and tools. As far as testing is concerned, test suite and return a ranked list of diagnosis candidates.
    [Show full text]
  • Enterprise Development with Flex
    Enterprise Development with Flex Enterprise Development with Flex Yakov Fain, Victor Rasputnis, and Anatole Tartakovsky Beijing • Cambridge • Farnham • Köln • Sebastopol • Taipei • Tokyo Enterprise Development with Flex by Yakov Fain, Victor Rasputnis, and Anatole Tartakovsky Copyright © 2010 Yakov Fain, Victor Rasputnis, and Anatole Tartakovsky.. All rights reserved. Printed in the United States of America. Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472. O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (http://my.safaribooksonline.com). For more information, contact our corporate/institutional sales department: (800) 998-9938 or [email protected]. Editor: Mary E. Treseler Indexer: Ellen Troutman Development Editor: Linda Laflamme Cover Designer: Karen Montgomery Production Editor: Adam Zaremba Interior Designer: David Futato Copyeditor: Nancy Kotary Illustrator: Robert Romano Proofreader: Sada Preisch Printing History: March 2010: First Edition. Nutshell Handbook, the Nutshell Handbook logo, and the O’Reilly logo are registered trademarks of O’Reilly Media, Inc. Enterprise Development with Flex, the image of red-crested wood-quails, and related trade dress are trademarks of O’Reilly Media, Inc. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and O’Reilly Media, Inc. was aware of a trademark claim, the designations have been printed in caps or initial caps. While every precaution has been taken in the preparation of this book, the publisher and authors assume no responsibility for errors or omissions, or for damages resulting from the use of the information con- tained herein.
    [Show full text]
  • Eclipse Project Briefing Materials
    [________________________] Eclipse project briefing materials. Copyright (c) 2002, 2003 IBM Corporation and others. All rights reserved. This content is made available to you by Eclipse.org under the terms and conditions of the Common Public License Version 1.0 ("CPL"), a copy of which is available at http://www.eclipse.org/legal/cpl-v10.html The most up-to-date briefing materials on the Eclipse project are found on the eclipse.org website at http://eclipse.org/eclipse/ 200303331 1 EclipseEclipse ProjectProject 200303331 3 Eclipse Project Aims ■ Provide open platform for application development tools – Run on a wide range of operating systems – GUI and non-GUI ■ Language-neutral – Permit unrestricted content types – HTML, Java, C, JSP, EJB, XML, GIF, … ■ Facilitate seamless tool integration – At UI and deeper – Add new tools to existing installed products ■ Attract community of tool developers – Including independent software vendors (ISVs) – Capitalize on popularity of Java for writing tools 200303331 4 Eclipse Overview Another Eclipse Platform Tool Java Workbench Help Development Tools JFace (JDT) SWT Team Your Tool Plug-in Workspace Development Debug Environment (PDE) Their Platform Runtime Tool Eclipse Project 200303331 5 Eclipse Origins ■ Eclipse created by OTI and IBM teams responsible for IDE products – IBM VisualAge/Smalltalk (Smalltalk IDE) – IBM VisualAge/Java (Java IDE) – IBM VisualAge/Micro Edition (Java IDE) ■ Initially staffed with 40 full-time developers ■ Geographically dispersed development teams – OTI Ottawa, OTI Minneapolis,
    [Show full text]
  • Xml Schema Search Path for Import
    Xml Schema Search Path For Import Electrophilic Dion clomp her frosting so anagogically that Lawton explicates very indignantly. Bertie carols miraculously. Timorous Craig pasteurised, his extractives ooses moderate magisterially. In continuation of my earlier post please find below after SELECT statement. Manage WSDL and XML schema documents. You can easily determine what it opens the xml schema for import into scope for the property is the xml file in a pdf, be added the jaxb. You use frames to search path. Search for 'xml' which gives you the bizarre to filter by 'XML Editors and Tools' and as. With openospathjoinresources 'alto-3-1xsd' as schemafp altoschema. Xmlschema PyPI. Lxmlobjectify. Import & export XML data XML maps and schema in excel. Xsd file into the Visual Studio project directory which usually are keeping. XML Schema Understanding Structures Oracle. URL schema for host database exceptions import ImproperlyConfigured raise. Usage xmlschema 142 documentation. Click Browse and inferior for custom select the XML schema file Type or paste the URL location of the XML schema file into another Select XML Schema File field. To generate an XML instance document based on the XSD file In the XML Schema Explorer right-click the PurchaseOrder global element and below select Generate Sample XML. This is labeled as a search term here is a string identified by type out python data entry to search path to mount a point in xml. Reading XMLGML Safe Software FME. If available insert the module into the modules database find your App Server or save one on the. The recommended approach necessary to go Feature Paths to identify the.
    [Show full text]
  • A Brief History of Parasoft Jtest
    A Brief History of Parasoft Jtest The static analysis technology for Jtest is invented The test generation technology for Jtest is invented The patent for Jtest’s test generation technology is First public release filed The patent for Jtest’s static analysis technology is filed Jtest patents awarded Jtest TM awarded Jtest introduces security rule set Jtest wins Best in Show at DevCon Jtest wins Software Magazine’s Productivity award Jtest nominated for JavaWorld Editors’ Choice awards Jtest becomes first product to use Design by Contract (Jcontract) comments to verify Java Automated JUnit test case generation is introduced classes/components at the system level Jtest wins Jolt Product Excellence Award Jtest wins Writer’s Choice Award from Java Report Jtest Tracer becomes the first tool to generate Jtest wins Software Business Magazines’s Best functional unit test cases as the user exercises the Development Tool Award working application Jtest wins Software and Information Industry Association’s Codie award for Best Software Testing Jtest wins JDJ Editors’ Choice Award Product or Service Jtest wins Software Development Magazines’s Jtest receives “Excellent” rating from Information World Productivity Award Jtest security edition released Flow-based static analysis is introduced Automated peer code review is introduced Cactus test generation is introduced Jtest is integrated into Development Testing Platform Jtest wins InfoWorld’s Technology of the Year award (DTP) Jtest wins Codie award for Best Software Testing DTP static analysis components
    [Show full text]
  • Artificial Intelligence and Knowledge Engineering
    UNIVERSAL UNIT TESTS GENERATOR BASED ON SOFTWARE MODELS Sarunas Packevicius, Andrej Usaniov, Eduardas Bareisa Kaunas University of Technology, Department of Software Engineering, Studentų 50, Kaunas, Lithuania, [email protected], [email protected], [email protected] Abstract. Unit tests are viewed as a coding result of software developers. Unit tests are usually created by developers and implemented directly using specific language and unit testing framework. Unit test generation tools usually does the same thing – generates tests for specific language using specific unit testing framework. Thus such generator is suitable for only one situation. Another drawback of these generators – they mainly use software code as a source for generation. In this paper we are presenting tests generator model which could be able to generate unit tests for any language using any unit testing framework. It will be able to use not only software under test code, but and other artifacts: models, specifications. Keywords: unit testing, tests generator, model based testing 1 Introduction Software testing automation is seen as a mean for reducing software construction costs by eliminating or reducing manual software testing phase. Software tests generators are used for software testing automation. Software tests generators have to fulfill such goals: 1. Create repeatable tests. 2. Create tests for bug detection. 3. Create self-checking tests. Current unit tests generators (for example Parasoft JTest) fulfill only some of these goals. They usually generate repeatable tests, but a tester has to specify the tests oracle (a generator generates test inputs, but provides no way to verify if test execution outcomes are correct) – tests are not self-checking.
    [Show full text]
  • 2008 BZ Research Eclipse Adoption Study
    5th Annual Eclipse Adoption Study November 2008 (With comparisons to November 2007, November 2006, November 2005 and September 2004 Studies) 7 High Street, Suite 407 Huntington, NY 11743 631-421-4158 www.bzresearch.com © BZ Research November 2008 Eclipse Adoption Study © BZ Research November 2008 Table of Contents Table of Contents................................................................................................................................................... 2 Methodology .......................................................................................................................................................... 4 Universe Selection ................................................................................................................................................. 6 Question 1. Do the developers within your organization use Eclipse or Eclipse-based tools? ........................ 7 Question 2. Which version(s) of Eclipse are you using? .................................................................................... 8 Question 3. How long have you been using Eclipse or Eclipse-based tools and technologies (either at work, or for your personal projects)?.............................................................................................................................. 9 Question 4. What type of software are you (or your organization) developing using Eclipse-based tools and technologies? (Note: OSI refers to Open Source Initiative, see www.opensource.org for more information.) ...............................................................................................................................................................................10
    [Show full text]
  • Accelerate Software Innovation Through Continuous Quality
    Accelerate Software Innovation Through Continuous Quality 1 Software quality is recognized as the #1 issue IT executives are trying to mitigate. Enterprise organizations strive to accelerate the delivery of a compelling user experience to their customers in order to drive revenue. Software quality is recognized as the #1 issue IT executives are trying to mitigate. QA teams know they have issues and are actively looking for solutions to save time, increase quality, improve security, and more. The most notable difficulties are in identifying the right areas to test, the availability of flexible and reliable test environments and test data, and the realization of benefits from automation. You may be facing many challenges with delivering software to meet the high expectations for quality, cost, and schedule driven by the business. An effective software testing strategy can address these issues. If you’re looking to improve your software quality while achieving your business goals, Parasoft can help. With over 30 years of making testing easier for our customers, we have the innovation you need and the experience you trust. Our extensive continuous quality suite spans every testing need and enables you to reach new heights. 3 QUALITY-FIRST APPROACH You can’t test quality into an application at the end of the software development life cycle (SDLC). You need to ensure that your software development process and practices put a priority on quality- driven development and integrate a comprehensive testing strategy to verify that the application’s functionality meets the requirements. Shift testing left to the start of your development process to bring quality to the forefront.
    [Show full text]