Browse Topic: Systems management

Items (173)
This Standard specifies the Habitability processes throughout planning, design, development, test, production, use and disposal of a system. Depending on contract phase and/or complexity of the program, tailoring of this standard may be applied. The primary goals of a contractor Habitability program include: Ensuring that the system design complies with the customer Habitability requirements and that discrepancies are reported to management and the customer. Identifying, coordinating, tracking, prioritizing, and resolving Habitability risks and issues and ensuring that they are: ○ Reflected in the contractor proposal, budgets, and plans ○ Raised at design, management, and program reviews ○ Debated in Working Group meetings ○ Coordinated with Training, Logistics, and the other HSI disciplines ○ Included appropriately in documentation and deliverable data items Ensuring that Habitability requirements are applied to all personnel environments, including operators, maintainers, trainers, and support personnnel. Identifying and pursuing opportunities to reduce Habitability costs. Ensuring that Habitability considerations are addressed in analyses, design decisions, trade-offs, and design changes (e.g., Engineering Change Proposals (ECP)). Conducting Habitability analysis activities and supporting human factors analyses (e.g., workload analysis) and other HSI domain analyses to provide evidence to support design decisions and trade-offs and to coordinate shared data. Ensuring that Habitability analyses, results and recommendations are timely, technically competent/complete, and included in design decisions, tradeoffs, and changes. Ensuring that environments experienced by subjects in experiments, simulations, tests, evaluations, and demonstrations are consistent with the customer’s Habitability requirements and meet the U.S. Government and DoD policies for protecton of human subjects. Ensuring that Habitability issues discovered in test, evaluation, demonstration, Operational Test and Evaluation (OT&E), and operations are resolved in a technically competent/complete and timely manner.
G-45 Human Systems Integration
The purpose of this Standard is to support the development and improvement of systems engineering capability.
G-47 Systems Engineering
The purpose of this Standard is to provide an integrated set of fundamental processes to aid a developer in the engineering or reengineering of a system. Use of this Standard is intended to help developers a) establish and evolve a complete and consistent set of requirements that will enable delivery of feasible and cost-effective system solutions; b) satisfy requirements within cost, schedule, and risk constraints; c) provide a system, or any portion of a system, that satisfies stakeholders over the life of the products that make up the system. NOTE—The term product is used in this standard to mean: a physical item, such as a satellite (end product), or any of its component parts (end products); a software item such as a stand-alone application to run within an existing system (end product); or a document such as a plan, or a service such as test, training, or maintenance support, or equipment such as a simulator (enabling products). d) provide for the safe and/or cost-effective disposal or retirement of a system.
G-47 Systems Engineering
This Standard covers Manpower and Personnel (M&P) processes throughout planning, design, development, test, production, use, and disposal of a system. Depending on contract phase and/or complexity of the program, tailoring can be applied. The scope of this standard includes Prime and Sub-contractor M&P activities; it does not include Government M&P activities. The primary goals of a contractor M&P program typically include: Ensuring that the system design complies with the latest customer manpower estimates (numbers and mix of personnel, plus availability) and that discrepancies are reported to management and the customer. Ensuring that the system design is regularly compared to the latest customer Personnel estimates (capabilities and limitations) and that discrepancies are reported to management and the customer. Identifying, coordinating, tracking, and resolving M&P risks and issues and ensuring that they are: ○ Reflected in the contractor proposal, budgets, and plans. ○ Raised at design, management, and program reviews. ○ Debated in Working Group meetings. ○ Coordinated with Training, Logistics, and the other HSI disciplines. ○ Included appropriately in documentation and deliverable data items. Identifying and pursuing opportunities to reduce Manpower and Personnel demands and costs. Ensuring that M&P considerations are addressed in analyses, design decisions, trade-offs, and design changes (e.g., ECPs). Conducting Manpower and Personnel analysis activities and supporting human factors analyses (e.g., workload analysis) and other HSI domain analyses to provide evidence to support design decisions and trade-offs and to coordinate shared data (e.g., task analyses). Ensuring that M&P analyses and results are timely, technically competent/complete, and in a format that enables them to be included in design decisions, tradeoffs, and changes. Ensuring that M&P issues discovered in test, evaluation, demonstration, Operational Test and Evaluation (OT&E), and operations are tracked and resolved in a technically competent/complete and timely manner. Ensuring that the subjects used in experiments, simulations, tests, evaluations, and demonstrations are consistent with the customer’s latest projected target audiences.
G-45 Human Systems Integration
This document applies to hardware and software and provides CM requirements to be placed on contracts after being tailored by the Acquirer. The requirements have been organized by the following five CM functions: a Configuration Planning and Management b Configuration Identification c Configuration Change Management d Configuration Status Accounting e Configuration Verification and Audit
G-33 Configuration Management
The Road to the Top is Not on the Map: Conversations with Top Women of the Automotive IndustryR-4919/4/2019
Carla Bailo, CEO of the Center for Automotive Research, and Terry Barclay, CEO of Inforum, bring together over 30 of the most influential women in the automotive industry to share their insight and advice. From suppliers to OEMs, they hail from every corner of the industry. Readers will learn how to take charge of their own careers by understanding the experiences these professionals. Topics include: • Work-Life Integration - How can you be whole at home, at work, and in the community? • Education and Lifelong Learning - Do you really need a graduate degree? • Mentor and Sponsor Relationships - How do you find mentors and sponsors and form productive relationships with them? • Career Challenges - How do you evaluate when to take career risks? How do you say yes when all the boxes aren't checked? • Resilience - Where do you find the internal fortitude to keep going? • Personal Satisfaction - What do these leaders find most joyful about their careers? The Road to the Top is Not on the Map features female leaders who candidly share the habits, motivations, triumphs, defeats, and lessons learned that helped them achieve top jobs in the industry. Their insights have relevance for women at all stages in their careers, whether its young women interested in pursuing a career in the auto industry, those looking for their next strategic move, or those seeking insight and inspiration. "The women in this book share a passion for their careers and a passion for the industry. They have encountered obstacles and the occasional failure, as well as successes, but they have embraced all their earned wisdom and generously agreed to share it." Creating a book club during office hours is a great way for team members to draw upon the eperiences of thought leaders. The Road to the Top is Not on the Map is the perfect book to start with as the leaders profiled share their experiences, and challenge readers to evaluate their own choices. Book Club Kirs are available for companies wishing to start an employee Book Club. For special pricing on quantity orders (minimum 25 copies), please contact an SAE International Sales Representative: (P) 1-888-875-3976 (US) (P) 1-724-772-4086 (Outside US) Fax: 724-776-3087 E-Mail: customersales@sae.org
Bailo, CarlaBarclay, Terry
Configuration Management StandardEIA649C (Current)2/7/2019
This standard defines five CM functions and their underlying principles. The functions are detailed in Section 5. The principles, highlighted in text boxes, are designed to individually identify the essence of the related CM function and can be used to collectively create a checklist of “best practice” criteria to evaluate a CM program. The CM principles defined in this standard apply equally to internally focused enterprise information, processes, and supporting systems (i.e., Enterprise CM - policy driven, supporting the internal goals needed to achieve an efficient, effective and lean enterprise), as well as to the working relationships supported by the enterprise (i.e., Acquirer/Supplier CM - contracted relationship to support external trusted interaction with suppliers). In an Enterprise CM context there are several methodologies for principle use by the enterprise: The principles of this standard provide direction for developing enterprise or functional CM plans focused on identifying, defining, authorizing, and managing CM activities. These plans identify the participants involved in activities, their responsibilities, their authority, and how accountability is administered to serve enterprise/activity objectives. The Enterprise uses CM’s integrity-based traceability and management capabilities as a foundation to support the “best practice” initiatives of data/information management, quality assurance, program/project management, systems engineering and life cycle logistics, by providing principle-guided functions to achieve a more efficient, effective and lean enterprise. In the Acquirer/Supplier CM context there are several methodologies for conformance by a supplier: Acquirer requires a CM plan consistent with the principles of this standard from the supplier. Acquirer uses this standard to develop a checklist with which to evaluate supplier CM plans. Acquirer reviews and approves the supplier CM plan and makes it a requirement of the contract. This method requires both parties to the acquisition to understand both the concepts and the tailoring. Acquirer uses the principles of this standard as the basis for developing either or both an enterprise CM requirements document or a specific project CM requirements document to impose on suppliers. The requirements documents may state this standard’s principles as requirements and reference this standard’s paragraphs. Compliance with the contractual requirements constitutes conformance with this standard. In describing each CM function and its principles, this standard utilizes neutral Configuration Management terminology, while also providing equivalent terms, that have historically been used in various product environments (see Table 2). There is no intent to express a preference for any particular set of terminology. Similarly, this standard uses a neutral set of names for the phases of a product’s life cycle, which are generic enough to be easily mapped to the myriad of different life cycle models in use. Table 1 illustrates some of the aliases for each phase name and identifies characteristics that apply to each one. Regardless of the titles chosen for these phases, or what the product is (i.e., a facility, software, an airplane or a machine screw), at some point in its history a product will go through all or most of these phases. The phases can have considerable overlap, or the sequence of the phases might change or be repeated, e.g., for product improvements and enhancements. Approved configurations of a product can be in the build, distribution, operation, and disposal phases simultaneously, and changes to those configurations may occur during all life cycle phases. Appropriate application of CM functions enables a user of this standard to plan and implement a CM program for a product, project, or enterprise. All functions apply during every phase of the product’s life cycle but the degree to which each of the CM principles applies may vary. A scalable CM process should be defined, measured, continuously improved, and adhered to, that is commensurate with the product’s complexity, its intended use, and its value over the product life cycle. An organization that has the responsibility for performing Configuration Management for a product during any period of its life cycle could be a commercial enterprise, e.g., contractor, subcontractor, supplier, or government agency. References in this standard to the acquirer (i.e., customer) should be interpreted as the entity that specifies requirements (functional and performance attributes) for the product or that acquires and uses the product. An acquirer may be external to the developing and producing organization or may be internal such as marketing, management, or the using department. Configuration Management functions related to a product may be the responsibility of several organizations during its life cycle. For example, an organization with the responsibility to design and build a product will perform Configuration Management during the definition and build phases; other organizations or government activities with responsibility for upgrading the product and servicing units will perform Configuration Management during the operation phase. GEIA-HB-649 “Configuration Management Standard Implementation Guide,” provides additional “how to” guidance for planning, managing, and implementing CM functions and principles.
G-33 Configuration Management
Standard Best Practices for System Safety Program Development and ExecutionGEIASTD0010A (Current)10/18/2018
This document outlines a standard practice for conducting system safety. In some cases, these principles may be captured in other standards that apply to specific commodities such as commercial aircraft and automobiles. For example, those manufacturers that produce commercial aircraft should use SAE ARP4754 or SAE ARP4761 (see Section 2 below) to meet FAA or other regulatory agency system safety-related requirements. The system safety practice as defined herein provides a consistent means of evaluating identified risks. Mishap risk should be identified, evaluated, and mitigated to a level as low as reasonably practicable. The mishap risk should be accepted by the appropriate authority and comply with federal (and state, where applicable) laws and regulations, executive orders, treaties, and agreements. Program trade studies associated with mitigating mishap risk should consider total life cycle cost in any decision. This document is intended for use as one of the elements of project solicitation for complex systems requiring a systematic evaluation of hazards and mitigating measures. The Managing Authority may identify, in the solicitation and system specification, specific system safety requirements to be met by the Developer. These may include risk assessment and acceptance criteria, unique classifications and certifications, or mishap reduction needs unique to their program. Additional information in meeting program specific requirements is located in the Appendixes.
G-48 System Safety
Systems EngineeringEIAIS632 (Current)6/16/2016
This standard defines a total system approach for the development of systems. The standard requires: establishing and implementing a structured, disciplined, and documented systems engineering effort incorporating the systems engineering process; multidisciplinary teamwork; and the simultaneous development of the products and processes needed to satisfy user needs. The systems engineering process is defined generically to facilitate broad application. This standard defines the requirements for technical reviews. The tasks in this standard provide a methodology for evaluating progress in achieving system objectives. This standard provides a comprehensive, structured, and disciplined approach for all life-cycle phases, including new system product and process developments, upgrades, modifications, and engineering efforts conducted to resolve problems in fielded systems. This standard is applicable to technical efforts in support of advancement and development of new technologies and their application. It applies to large and small scale systems; to single or multiple procurements; and to the replacement of current products and processes. The standard is applicable to systems irrespective of composition including those that are integrated from diverse elements, hardware dominant, and software dominant. This document should be tailored for effective and efficient program implementation. Systems engineering involves design and management of a total system which includes hardware and software, as well as other system elements. All system elements should be considered in analyses, trade-offs, and engineering methodology.
G-47 Systems Engineering
CDIF - Transfer Format General Rules for Syntaxes and EncodingsEIAIS108 (Current)6/15/2016
The CDIF Family of Standards is primarily designed to be used as a description of a mechanism for transferring information between CASE tools. It facilitates a successful transfer when the authors of the importing and exporting tools have nothing in common except an agreement to conform to CDIF. The language that is defined for the Transfer Format also has applicability as a general language for Import/Export from repositories. The CDIF Integrated Meta-model defined for CASE also has applicability as the basis of standard definitions for use in repositories. The standards which form the complete family of CDIF Standards are documented in EIA/IS-106 CDIF - CASE Data Interchange Format - Overview. These standards cover the overall framework, the transfer format and the CDIF Integrated Meta-model. The diagram in Figure 1 depicts the various standards that comprise the CDIF Family of Standards. The shaded box depicts this Standard and its position in the CDIF Family of Standards. This document describes the way that CDIF meta-models are concretely represented during a transfer and the way that CDIF supports multiple exchange Syntaxes and Encodings. No specific exchange Syntaxes or Encodings are described in this document. EIA/IS-109 CDIF - Transfer Format - Syntax SYNTAX.1 and EIA/IS-110 CDIF - Transfer Format - Encoding ENCODING.1 describe one specific CDIF Syntax and one specific CDIF Encoding.
Systems Management Council
Items per page:
1 – 50 of 173