DOCSLIB.ORG

An Overview of IEEE Software Engineering Standards and Knowledge Products

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
An Overview of IEEE Software Engineering Standards and Knowledge Products An Overview of IEEE Software Engineering Standards and Paul R. Croll Knowledge Products Chair, IEEE SESC Computer Sciences Corporation [email protected] Objectives l Provide an introduction to The IEEE Software Engineering Standards Committee (SESC) l Provide an overview of the current state and future direction of IEEE Software Engineering Standards and knowledge products u IEEE Software Engineering Standards Collection u Software Engineering Competency Recognition Program u Standards-Based Training l Discuss how you can participate in software engineering standardization efforts ASQ Section 509 SSIG Meeting, 8 November 2000 Paul R. Croll - 2 The IEEE Software Engineering Standards Committee (SESC) http://computer.org/standard/sesc/ ASQ Section 509 SSIG Meeting, 8 November 2000 Paul R. Croll - 3 The SESC Vision l The leading supplier and promoter of a family of software engineering standards and related products and services. ASQ Section 509 SSIG Meeting, 8 November 2000 Paul R. Croll - 4 Software Engineering: An Object View Source: [SESC95] ASQ Section 509 SSIG Meeting, 8 November 2000 Paul R. Croll - 5 SESC in the IEEE Structure IEEE IEEE IEEE Computer Society Standards Board Software Engineering Standards Committee Executive Committee & Management Board Working Group Study Group Planning Group Conferences ASQ Section 509 SSIG Meeting, 8 November 2000 Paul R. Croll - 6 SESC Strategic Program Model ISO and IEC IEEE SESC Standards Standards Program Terminology Terminology Overall Guide Quality Customer Resource Process Product Management Principles or Policies Element Standards Software Engineering Application Guides System “Toolbox” of Disciplines Technique Standards Source: [SESC95] ASQ Section 509 SSIG Meeting, 8 November 2000 Paul R. Croll - 7 The IEEE Software Engineering Standards Collection http://standards.ieee.org/catalog/softwareset.html ASQ Section 509 SSIG Meeting, 8 November 2000 Paul R. Croll - 8 The 2000 Software Engineering Standards Collection l Forty-six Standards u Customer & Terminology u Process u Product u Resource & Technique l Overall guide u Several “views” n Context n Object n Normative intent n Provider and subject u Relationships among Source: [Moore97] standards ASQ Section 509 SSIG Meeting, 8 November 2000 Paul R. Croll - 9 IEEE/EIA 12207: The Life Cycle Process Framework l IEEE/EIA 12207, Standard for Information Technology – Software Life Cycle Processes u Addresses the complete software engineering life cycle, from acquisition and supply, through development, to operations and maintenance u Provides a process framework upon which an organization can build its enterprise-level life cycle processes u These enterprise-level processes are then tailored into projects, in order to meet specific project-level requirements. ASQ Section 509 SSIG Meeting, 8 November 2000 Paul R. Croll - 10 IEEE/EIA 12207 Process Tree ACQUISITION SUPPLY DEVELOPMENT OPERATION MAINTENANCE PRIMARY LIFE CYCLE SUPPORTING DOCUMENTATION CONFIGURATION MANAGEMENT QUALITY ASSURANCE VERIFICATION VALIDATION JOINT REVIEW AUDIT PROBLEM RESOLUTION ORGANIZATIONAL MANAGEMENT INFRASTRUCTURE IMPROVEMENT TRAINING Source: [Singh97] TAILORING ASQ Section 509 SSIG Meeting, 8 November 2000 Paul R. Croll - 11 Unit 2: IEEE/EIA 12207 Overview - Process Interactions 12207 Process Flow ORGANIZATION MANAGEMENT INFRASTRUCTURE IMPROVEMENT TRAINING M F PROJECT OPERATION F F F E: 3 F T ACQUISITION SUPPLY MAINTENANCE T E U: 4 U: 4 T E: 2,3 P JOINT E REVIEW E: ACQ E U E: 3 T: SUB E U E AUDIT P QA DEVELOPMENT E: 3 E: 3 E: 1,2,3 (T)E (I)V&V E V&V E: 3 E: 3 1 2 3 4 E PROBLEM DOCUMENTATION CM RESOLUTION TAILORING ACQ - ACQUISITION. SUB - SUBCONTRACTOR E - EXECUTE Source: [Singh97] F - FEEDBACK. M - MANAGE. P - PARTICIPATE. T - TASK. U - USE PDCA E:N - EXECUTE THE PROCESS NUMBERED N ASQ Section 509 SSIG Meeting, 8 November 2000 Paul R. Croll - 12 Unit 2: IEEE/EIA 12207 Overview - Primary Process Flow Primary Process Flow OPERATION T ACQUISITION SUPPLY MAINTENANCE T E/T U E = EXECUTE T =TASK DEVELOPMENT U =USE Source: [Singh97] PLAN, DO, CHECK & ACT ASQ Section 509 SSIG Meeting, 8 November 2000 Paul R. Croll - 13 Unit 2: IEEE/EIA 12207 Overview - Supporting Process Flow Supporting Process Flow QUALITY ASSURANCE ACQUISITION VERIFICATION SUPPLY DOCUMENTATION VALIDATION DEVELOPMENT JOINT REVIEW CONFIGURATION OPERATION MANAGEMENT AUDIT MAINTENANCE PROBLEM RESOLUTION Source: [Singh97] ASQ Section 509 SSIG Meeting, 8 November 2000 Paul R. Croll - 14 Unit 2: IEEE/EIA 12207 Overview - Organizational Process Flow Organizational Process Flow MANAGEMENT PROCESS INFRASTRUCTURE PROCESS PRIMARY PROCESS IMPROVEMENT SUPPORTING PROCESS PROCESS TRAINING PROCESS Source: [Singh97] ASQ Section 509 SSIG Meeting, 8 November 2000 Paul R. Croll - 15 Unit 2: IEEE/EIA 12207 Overview - Process Roles 12207 Process Roles Role ACQUISITION employ S ACQUIRER ACQUISITION PROCESS ROLE U P contract P O SUPPLY employ SUPPLIER SUPPLY PROCESS R ROLE T employ employ employ I N OPERATING • OPERATOR G OPERATION PROCESS employ ROLE • USER use P R ENGINEERING • DEVELOPER MAINTENANCE use DEVELOPMENT employ O ROLE • MAINTAINER PROCESS PROCESS C E S EMPLOYER SUPPORTING OF • Documentation • Validation S • Configuration management • Joint review ROLE SUPPORTING E PROCESSES • Quality assurance • Audit S • Verification • Problem resolution ORGANIZATIONAL ORGANIZATIONAL• PROCESSES MANAGER ROLE Management • Infrastructure • Improvement • Training Source: [Singh97] ASQ Section 509 SSIG Meeting, 8 November 2000 Paul R. Croll - 16 Unit 2: IEEE/EIA 12207 Overview - Process Roles Role Definitions l Acquirer: u an organization that acquires or procures a system, software product or software service from a supplier l Supplier: u an organization that enters into a contract with the acquirer for the supply of a system, software product or software service under the terms of the contract l Operator: u an organization that operates the system ASQ Section 509 SSIG Meeting, 8 November 2000 Paul R. Croll - 17 Unit 2: IEEE/EIA 12207 Overview - Process Roles Role Definitions - 2 l Developer: u an organization that performs development activities (including requirements analysis, design, testing through acceptance) during the software life cycle process l Maintainer: u an organization that performs maintenance activities l Supporting Process Performer and Manager are undefined ASQ Section 509 SSIG Meeting, 8 November 2000 Paul R. Croll - 18 Unit 2: IEEE/EIA 12207 Overview - Structure IEEE/EIA 12207 Document Structure l IEEE/EIA 12207.0-1996, Software Life Cycle Processes u Industry adoption of ISO/IEC 12207-1995 l IEEE/EIA 12207.1-1997, Life Cycle Data u Industry guide to life cycle data l IEEE/EIA 12207.2-1997, Implementation Considerations u Industry guide to implementation of the life cycle processes contained in 12207.0 ASQ Section 509 SSIG Meeting, 8 November 2000 Paul R. Croll - 19 Unit 2: IEEE/EIA 12207 Overview - Structure IEEE/EIA 12207.0 Document Structure l Foreword to IEEE/EIA 12207.0-1996 l ISO/IEC 12207-1995 u Introduction u Foreword u Clause 1 - Scope u Clause 2 - Normative references u Clause 3 - Definitions u Clause 4 - Application of this International Standard u Clause 5 - Primary life cycle processes u Clause 6 - Supporting processes u Clause 7 - Organizational life cycle processes ASQ Section 509 SSIG Meeting, 8 November 2000 Paul R. Croll - 20 Unit 2: IEEE/EIA 12207 Overview - Structure IEEE/EIA 12207.0 Annexes l ISO/IEC 12207-1995 Annexes u A - Tailoring process u B - Guidance on tailoring u C - Guidance on processes and organizations u D - Bibliography l Additional IEEE/EIA 12207.0 Annexes u E - Basic concepts of ISO/IEC 12207 u F - Compliance u G - Life cycle processes objectives u H - Life cycle data objectives u I - Relationships u J - Errata ASQ Section 509 SSIG Meeting, 8 November 2000 Paul R. Croll - 21 Unit 2: IEEE/EIA 12207 Overview - Structure IEEE/EIA 12207.1 Document Structure u Introduction u Clause 1 - Scope u Clause 2 - Normative references u Clause 3 - Definitions u Clause 4 - Life cycle data n Clause 4.1 Overview n Clause 4.2 Life cycle data objectives n Clause 4.3 Information item matrix n Clause 4.4 Compliance u Clause 5 - Generic information item content guidelines u Clause 6 - Specific information item content guidelines u Annex A - References ASQ Section 509 SSIG Meeting, 8 November 2000 Paul R. Croll - 22 Unit 2: IEEE/EIA 12207 Overview - Structure IEEE/EIA 12207.2 Document Structure l Foreword l Introduction l Clause 1 - Scope l Clause 2 - Normative references l Clause 3 - Definitions l Clause 4 - Application l Clause 5 - Primary life cycle processes l Clause 6 - Supporting processes l Clause 7 - Organizational life cycle processes ASQ Section 509 SSIG Meeting, 8 November 2000 Paul R. Croll - 23 Unit 2: IEEE/EIA 12207 Overview - Structure IEEE/EIA 12207.2 Annexes l IEEE/EIA 12207 Annexes u A - IEEE/EIA 12207.0 Annex A - Tailoring process u B - IEEE/EIA 12207.0 Annex F - Compliance u C - IEEE/EIA 12207.0 Annex G - Life cycle processes objectives u D - IEEE/EIA 12207.0 Annex H - Life cycle data objectives u E - IEEE/EIA 12207.0 Annex J - Errata ASQ Section 509 SSIG Meeting, 8 November 2000 Paul R. Croll - 24 Unit 2: IEEE/EIA 12207 Overview - Structure IEEE/EIA 12207.2 Annexes - 2 l Additional IEEE/EIA 12207.2 Annexes u F - Use of reusable software products u G - Candidate joint management reviews u H - Software measurement categories u I - Guidance on development strategies and build planning u J - Category and priority classifications for problem reporting u K - Software product
Load more

Recommended publications
  • Openfog Reference Architecture for Fog Computing
    OpenFog Reference Architecture for Fog Computing Produced by the OpenFog Consortium Architecture Working Group www.OpenFogConsortium.org February 2017 1 OPFRA001.020817 © OpenFog Consortium. All rights reserved. Use of this Document Copyright © 2017 OpenFog Consortium. All rights reserved. Published in the USA. Published February 2017. This is an OpenFog Consortium document and is to be used in accordance with the terms and conditions set forth below. The information contained in this document is subject to change without notice. The information in this publication was developed under the OpenFog Consortium Intellectual Property Rights policy and is provided as is. OpenFog Consortium makes no representations or warranties of any kind with respect to the information in this publication, and specifically disclaims implied warranties of fitness for a particular purpose. This document contains content that is protected by copyright. Copying or distributing the content from this document without permission is prohibited. OpenFog Consortium and the OpenFog Consortium logo are registered trademarks of OpenFog Consortium in the United States and other countries. All other trademarks used herein are the property of their respective owners. Acknowledgements The OpenFog Reference Architecture is the product of the OpenFog Architecture Workgroup, co-chaired by Charles Byers (Cisco) and Robert Swanson (Intel). It represents the collaborative work of the global membership of the OpenFog Consortium. We wish to thank these organizations for contributing
    [Show full text]
  • Core System Architecture Viewpoints
    Core System System Architecture Document (SAD) www.its.dot.gov/index.htm Draft — September 6, 2011 Produced by Lockheed Martin ITS Joint Program Office Research and Innovative Technology Administration U.S. Department of Transportation Notice This document is disseminated under the sponsorship of the Department of Transportation in the interest of information exchange. The United States Govern- ment assumes no liability for its contents or use thereof. Report Documentation Page Form Approved OMB No. 0704-0188 The public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing the burden, to Department of Defense, Washington Headquarters Services, Directorate for Informa- tion Operations and Reports (0704-0188), 1215 Jefferson Davis Highway, Suite 1204, Arlington, VA 22202-4302. Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to any penalty for failing to comply with a collection of information if it does not display a currently valid OMB control number. PLEASE DO NOT RETURN YOUR FORM TO THE ABOVE ADDRESS. 1. REPORT DATE (DD MM YYYY) 2. REPORT TYPE 3. DATES COVERED 06 09 2011 (Draft Specification) Month YYYY – Month YYYY 4. TITLE AND SUBTITLE 5a. CONTRACT NUMBER Core System: System Architecture Document (SAD) Draft GS-23F-0150S 5b. GRANT NUMBER Xxxx 6. AUTHOR(S) 5c. PROGRAM ELEMENT NUMBER Core System Engineering Team Xxxx 5d.
    [Show full text]
  • ANSI/IEEE 1471 and Systems Engineering•
    ANSI/IEEE 1471 and Systems Engineering• Mark W. Maier David Emery The Aerospace Corporation The MITRE Corporation 15049 Conference Center Dr 7515 Colshire Drive, MS N110 Chantilly, VA 20151 McLean, VA 22102-3481 [email protected] [email protected] Rich Hilliard P.O. Box 396 Littleton, MA 01460 [email protected] Abstract: ANSI/IEEE Standard 1471-2000 is the Recommended Practice for Architectural Description of Software- Intensive Systems, developed by the IEEE’s Architecture Working Group (AWG) under the sponsorship of the Software Engineering Standards Committee of IEEE. ANSI/IEEE 1471 is the first formal standard1 to address the content and organization of architectural descriptions. The standard defines the structure and content of an architectural description (AD) and incorporates a broad consensus on best practices for such descriptions. Although ANSI/IEEE 1471 was conceived as a software-focused standard, this paper argues that it is equally applicable to any system; hence appropriate for use as a part of systems engineering to describe system architectures. This article reviews the concepts of ANSI/IEEE 1471, the rationale for their selection, and demonstrates its application in systems engineering. ARCHITECTURE FRAMEWORKS The notion of architecture has entered into both the domains of software and systems engineering in recent decades. There are several threads to this entry. Many invoke a direct analogy with the notion in civil engineering, while others are built on particular practices largely drawn from the information technology industry. Some background on what problems are being addressed by what goes by the term “architecture” is helpful in understand the motivation for the ANSI/IEEE 1471 work and related frameworks.
    [Show full text]
  • Architectural Description
    Reference number of working document: ISO/IEC JTC 1/SC 7 N 000 Date: 2007-07-04 Reference number of document: ISO/IEC WD1 42010 IEEE P42010/D1 Committee identification: ISO/IEC JTC 1/SC 7/WG 42 Secretariat: Sweden Systems and Software Engineering — Architectural Description Élément introductif — Élément principal — Partie n: Titre de la partie Warning This document is not an ISO International Standard. It is distributed for review and comment. It is subject to change without notice and may not be referred to as an International Standard. Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation. Document type: International standard Document subtype: if applicable Document stage: (20) Preparation Document language: E ISO/IEC WD1 42010 IEEE P42010/D1 Copyright notice This ISO/IEC and IEEE document is a Draft International Standard and is copyright-protected by ISO/IEC and IEEE. Except as permitted under the applicable laws of the user's country, neither this draft document nor any extract from it may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, photocopying, recording or otherwise, without prior written permission being secured. Requests for permission to reproduce should be addressed to either ISO or IEEE at the address below or ISO's member body in the country of the requester. ISO copyright office Case postale 55 CH-1211 Geneva 20 Tel. +41 22 749 01 11 Fax. +41 22 749 09 47 E-mail: [email protected] Web: www.iso.org IEEE Standards Association Manager, Standards Intellectual Property 445 Hoes Lane Piscataway, NJ 08854 E-mail: [email protected] Web: standards.ieee.org Reproduction may be subject to royalty payments or a licensing agreement.
    [Show full text]
  • Towards Harmonizing Multiple Architecture Description Languages for Real-Time Embedded Systems
    Towards Harmonizing Multiple Architecture Description Languages for Real-Time Embedded Systems Tahir Naseer Qureshi, Martin Törngren, Magnus Persson, De-Jiu Chen, Carl-Johan Sjöstedt Division of Mechatronics, Department of Machine Design KTH-The Royal Institute of Technology Stockholm, Sweden {tnqu, martin, magnper, chen, carlj}@md.kth.se Abstract— The increasing complexity of real-time embedded solutions in model-based development. It exists in different systems requires appropriate methods and techniques to support forms depending on the applied industrial or application the development including the specification and analysis of domain. According to IEEE 1471 standard [3], an architecture different architectural aspects. A large number of architectural is defined as: description languages (ADL) have been proposed with varying focus and application domains. There is a need for “The fundamental organization of a system embodied in its harmonization of these ADLs. This can be from develoloping and components, their relationships to each other, and to the understanding of how they differ or could be synergistically environment and the principles guiding its design and combined for increasing the overall development efficiency and evolution” fulfilling the ever increasing functional and non-functional requirements on a system. This paper addresses this issue and While an architectural description is the specification of an focuses on four different ADLs: EAST-ADL, AUTOSAR, AADL architecture, an ADL provides the syntax, either textual or and Rubus. In this work we compare these ADLs, identify graphical, for an architecture description. The need for possible usage scenarios involving more than one ADL and expressing and describing architectures of real-time embedded discuss some of the underlying challenges.
    [Show full text]
  • Competency Models
    SCIENCE, TECHNOLOGY, ENGINEERING & MATHEMATICS Architectural and Engineering Managers ACCCP Engineering and Technology Alabama Competency Model Architectural and Engineering Managers Code 1 Tier 1: Personal Effectiveness Competencies 1.1 Interpersonal Skills: Displaying the skills to work effectively with others from diverse backgrounds. 1.1.1 Demonstrating sensitivity/empathy 1.1.1.1 Show sincere interest in others and their concerns. 1.1.1.2 Demonstrate sensitivity to the needs and feelings of others. 1.1.1.3 Look for ways to help people and deliver assistance. 1.1.2 Demonstrating insight into behavior Recognize and accurately interpret the communications of others as expressed through various 1.1.2.1 formats (e.g., writing, speech, American Sign Language, computers, etc.). 1.1.2.2 Recognize when relationships with others are strained. 1.1.2.3 Show understanding of others’ behaviors and motives by demonstrating appropriate responses. 1.1.2.4 Demonstrate flexibility for change based on the ideas and actions of others. 1.1.3 Maintaining open relationships 1.1.3.1 Maintain open lines of communication with others. 1.1.3.2 Encourage others to share problems and successes. 1.1.3.3 Establish a high degree of trust and credibility with others. 1.1.4 Respecting diversity 1.1.4.1 Demonstrate respect for coworkers, colleagues, and customers. Interact respectfully and cooperatively with others who are of a different race, culture, or age, or 1.1.4.2 have different abilities, gender, or sexual orientation. Demonstrate sensitivity, flexibility, and open-mindedness when dealing with different values, 1.1.4.3 beliefs, perspectives, customs, or opinions.
    [Show full text]
  • SIMULATION of BASIC MULTI-HOP BROADCAST TECHNIQUES in VEHICULAR Ad-Hoc NETWORKS USING VEINS SIMULATOR”
    “SIMULATION OF BASIC MULTI-HOP BROADCAST TECHNIQUES IN VEHICULAR Ad-Hoc NETWORKS USING VEINS SIMULATOR” A Master's Thesis Submitted to the Faculty of the Escola Tècnica d'Enginyeria de Telecomunicació de Barcelona Universitat Politècnica de Catalunya by David Leonardo Renjifo Herrera In partial fulfilment of the requirements for the degree of MASTER IN TELECOMMUNICATIONS ENGINEERING Advisor: Mónica Aguilar Igartua Co-Advisor: Cristhian Iza Barcelona, February 2016 Title of the thesis: “Simulation of basic multi-hop broadcast techniques in Vehicular Ad-hoc Networks using VEINS simulator”. Author: David Leonardo Renjifo Herrera Advisor: Mónica Aguilar Igartua Co-advisor: Cristhian Iza Abstract This project presents to the reader an incursion into the world of smart cities and vehicles, intelligent transport systems, and vehicular ad-hoc networks (VANETs). They are conceptually analyzed, studied in terms of requirements, framework, architecture, applications and standardization. The main objective of this project is the simulation of basic techniques of message dissemination in VANETs, this project shows a brief description of broadcast dissemination techniques. Also, it is necessary to analyze simulation of VANETs. For this reason, it presents a brief description of mobility generators, network simulators and VANETs simulators paying attention to the open source ones. The main focus is set on the VEINS simulation framework, due to its high performance results and a bidirectional coupling between the network and the traffic simulators. From that point, the project is aimed at analyzing the basic paradigms of VEINS components (OMNeT++, SUMO and the TraCI module) and providing a study on their features. Three techniques are simulated (Flooding, Counter and Probability schemes) in two different scenarios (urban and highway), the simulation results are shown focused on the amount of retransmitting nodes, percentage of reached nodes, amount of packets sent, average packet delay, and percentage of packets received.
    [Show full text]
  • IEEE RS Standards Status and Descriptions, and Collaboration Efforts Lou Gullo June 9, 2010 Summary
    IEEE RS Standards Status and Descriptions, and Collaboration Efforts Lou Gullo June 9, 2010 Summary • IEEE Reliability Standards Status • Collaboration with IEEE Computer Society Standards • Collaboration with military and other standards bodies IEEE RS Status • IEEE 1624-2008 (Standard for Organizational Reliability Capability) - Initially Published in 2009 • IEEE 1633-2008 (Recommended Practice on Software Reliability) - Initially Published in 2009 • IEEE 1413-2010 (Standard for Reliability Predictions) – Approved by the Standards Board in March 2010 • IEEE 1332 (Standard Reliability Program For The Development And Production Of Electronic Systems And Equipment ) – PAR approved by NesCom on 26 March, 2008 – held working group kick-off meeting on January 31, 2008 – Planning to complete by 2010 • IEEE 1413.1 (Guide for Selection and Using Reliability Predictions Based on IEEE ) – PAR approved by NesCom on 26 March, 2008 – Activity on 1413.1 will begin when 1413 is done. What is IEEE 1624? • Standard for Organizational Reliability Capability • Sponsored by the IEEE Reliability Society • A method to assist designers in the selection of suppliers that includes assessment of the suppliers’ capability to design and manufacture products meeting the customers’ reliability requirements. • A method to identify the shortcomings in reliability programs which can be rectified by subsequent improvement actions • Developed in cooperation with Carnegie Mellon University (CMU) Software Engineering Institute (SEI) Purpose of IEEE 1624 • The purpose for assessing the reliability capability of an organization is to facilitate improvement of the product reliability. • This document does not define an audit process, but rather an assessment process that is suitable for providing data and results as input into an audit process.
    [Show full text]
  • Croll [Read-Only]
    Best Practice Information Aids for CMMISM-Compliant Paul R. Croll Chair, IEEE Software Engineering Standards Process Engineering Committee Vice Chair, ISO/IEC JTC1/SC7 U.S. TAG Computer Sciences Corporation [email protected] A Preparatory Exercise 14th Annual DoD Software Technology Conference - IEEE-Sponsored Track -1 May 2002 Paul R. Croll - 2 How many of you know that there are two Framework Standards for System and Software Life Cycle Processes? 14th Annual DoD Software Technology Conference - IEEE-Sponsored Track -1 May 2002 Paul R. Croll - 3 How many of you know that there are thirty+ Supporting Standards for Software and Systems Process Engineering? 14th Annual DoD Software Technology Conference - IEEE-Sponsored Track -1 May 2002 Paul R. Croll - 4 8 Steps to Success With Best Practice Information Aids Understand Look to the Look to Look to 1 your business 2 CMMISM for 3 Framework 4 Supporting processes Process Standards for Life Standards for Completeness Cycle Definition Process Detail 5 Build or Refine 6 Execute Your 7 Measure Your 8 Confirm Your Your Process Processes Results - Modify Status With Architecture Processes as Independent Necessary Appraisals 3 3 3 3 2nd Annual CMMISM Technology Conference and Users Group – Practical Guidance Part 1 –13 November 2002 Paul R. Croll - 5 Step 1 – Understand your business processes 2nd Annual CMMISM Technology Conference and Users Group – Practical Guidance Part 1 –13 November 2002 Paul R. Croll - 6 Your Business is Your Business – It’s Not CMMISM Implementation l You must fully understand your business Decision Branch processes before you can address process Else completeness or process compliance.
    [Show full text]
  • Software Architectures for Healthcare Cyber-Physical Systems: a Systematic 3 Literature Review
    1 2 Software Architectures for Healthcare Cyber-Physical Systems: A Systematic 3 Literature Review 4 Andrea M. Plaza+,*, Jessica Díaz+, Jennifer Pérez+ 5 +Universidad Politécnica de Madrid-CITSEM, Madrid, Spain 6 *Universidad Politécnica Salesiana, Cuenca, Ecuador 7 [email protected], [email protected], [email protected] 8 9 Abstract. Cyber-Physical Systems (CPS) refer to the next generation of ICT systems that mainly integrate sensing, 10 computing, and communication to monitor, control, and interact with a physical process to provide citizens and busi- 11 nesses with smart applications and services: healthcare, smart homes, smart cities, and so on. In recent years, healthcare 12 has become one of the most important services due to the continuous increases in its costs. This has motivated extensive 13 research on healthcare CPS, and some of that research has focused on describing the software architecture behind these 14 systems. However, there is no secondary study to consolidate the research. This paper aims to identify and compare 15 existing research on software architectures for healthcare CPS in order to determine successful solutions that could guide 16 other architects and practitioners in their healthcare projects. We conducted a systematic literature review (SLR) and 17 compared the selected studies based on a characterization schema. The research synthesis results in a knowledge base of 18 software architectures for healthcare CPS, describing their stakeholders, functional and non-functional features, quality 19 attributes architectural views and styles, components, and implementation technologies. This SLR also identifies research 20 gaps, such as the lack of open common platforms, as well as directions for future research.
    [Show full text]
  • NUREG/CR-7151 Vol 1 "Development of a Fault Injection
    NUREG/CR-7151, Vol. 1 Development of a Fault Injection-Based Dependability Assessment Methodology for Digital I&C Systems Volume 1 Office of Nuclear Regulatory Research AVAILABILITY OF REFERENCE MATERIALS IN NRC PUBLICATIONS NRC Reference Material Non-NRC Reference Material As of November 1999, you may electronically access Documents available from public and special technical NUREG-series publications and other NRC records at libraries include all open literature items, such as books, NRC’s Public Electronic Reading Room at journal articles, transactions, Federal Register notices, http://www.nrc.gov/reading-rm.html. Publicly released Federal and State legislation, and congressional reports. records include, to name a few, NUREG-series Such documents as theses, dissertations, foreign reports publications; Federal Register notices; applicant, and translations, and non-NRC conference proceedings licensee, and vendor documents and correspondence; may be purchased from their sponsoring organization. NRC correspondence and internal memoranda; bulletins and information notices; inspection and investigative Copies of industry codes and standards used in a reports; licensee event reports; and Commission papers substantive manner in the NRC regulatory process are and their attachments. maintained at— The NRC Technical Library NRC publications in the NUREG series, NRC Two White Flint North regulations, and Title 10, “Energy,” in the Code of 11545 Rockville Pike Federal Regulations may also be purchased from one Rockville, MD 20852–2738 of these two sources. 1. The Superintendent of Documents These standards are available in the library for reference U.S. Government Printing Office Mail Stop SSOP use by the public. Codes and standards are usually Washington, DC 20402–0001 copyrighted and may be purchased from the originating Internet: bookstore.gpo.gov organization or, if they are American National Standards, Telephone: 202-512-1800 from— Fax: 202-512-2250 American National Standards Institute nd 2.
    [Show full text]
  • CENELEC Project Report Smart House Roadmap
    draft CENELEC Project Report Smart House Roadmap Date 15 October 2010 Author(s) Frank den Hartog, Tom Suters, John Parsons, Josef Faller Version Draft 1.0 for Open Enquiry This CENELEC project report has been drafted by a project team and steering group of representatives of interested parties and is to be endorsed on 2010-11-23. Neither the national members of CENELEC nor the CEN-CENELEC Management Centre can be held accountable for the draft technical content of this CENELEC project report or possible conflicts with standards or legislation. This CENELEC project report can in no way be held as being an official standard developed by CENELEC and its members. This CENELEC project report is publicly available as a reference document from the CENELEC members. CENELEC members are the national electrotechnical committees of Austria, Belgium, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Slovakia, Slovenia, Spain, Sweden, Switzerland and United Kingdom. CENELEC European Committee for Electrotechnical Standardization Comité Européen de Normalisation Electrotechnique Europäisches Komitee für Elektrotechnische Normung CEN-CENELEC Management Centre: Avenue Marnix 17, 1000 Brussels © 2010 CENELEC - All rights of exploitation in any form and by any means reserved worldwide for CENELEC members. 2 1 Contents List of2 Figures and Tables ..............................................................................................................5
    [Show full text]