1 / 23

ISO/IEC 12207 and IEEE/EIA 12207 EEE493 2000

ISO/IEC 12207 and IEEE/EIA 12207 EEE493 2000. Major Greg Phillips greg.phillips@rmc.ca +1-613-541-6000 ext. 6190. Royal Military College of Canada Electrical and Computer Engineering. Dr. Scott Knight knight-s@rmc.ca +1-613-541-6000 ext. 6190. A Standards Family Tree. MIL-STD -7935.

honora
Download Presentation

ISO/IEC 12207 and IEEE/EIA 12207 EEE493 2000

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ISO/IEC 12207 and IEEE/EIA 12207EEE493 2000 Major Greg Phillips greg.phillips@rmc.ca +1-613-541-6000 ext. 6190 Royal Military College of Canada Electrical and Computer Engineering Dr. Scott Knight knight-s@rmc.ca +1-613-541-6000 ext. 6190

  2. A Standards Family Tree MIL-STD -7935 basis of DoD Software Life Cycle (SWLC) Standards influenced MIL-STD -498 DOD-STD -2167A IEEE 1074 Rev IEEE 1074 IEEE standards for developing LC processes Rev ISO/IEC 12207 ISO/IEC 12207 ISO standards for LC Processes J-STD -016 IEEE/EIA commercialisation of DoD SWLC standards IEEE/EIA 12207 US standards for LC Processes

  3. ISO/IEC 12207 • proposed 1988, published August 1995 • defines a top level architecture for the software lifecycle, consisting of seventeen core processes • a process is defined as a set of activities • activities (of which there are 74) are refined into tasks • tasks (of which there are 224) transform inputs to outputs • sometimes referred to as a strategic-level standard

  4. Processes and Interaction Organization Management Infrastructure Training Improvement Project Feedback Acquisition Supply Operation Joint Review Acq Maintenance Audit QA Development V & V V & V Documentation CM Problem Resolution Tailoring

  5. Plan-Do-Check-Act • Plan-Do-Check-Act cycle built into each process • Plan: tasks, work breakdown, schedule, etc. • Do: execution of plans • Check: process-internal evaluations • supplemented by inter-process and improvement evaluations • Act: Closed-loop problem resolutions

  6. IEEE/EIA 12207 (June 1998) • Also called “US 12207” for historical reasons • Represents a “tactical” implementation of ISO 12207 • Focus is on the organizational level rather than the project level • Advantages • coverage of entire software lifecycle • flexible approach regarding process and product data • incorporates specific reference to other US standards • guides the adaptation of its requirements in unusual situations • compatible with ISO 9000 approach • fully compliant with ISO/IEC 12207

  7. IEEE/EIA 12207 Structure • IEEE/EIA 12207.0 • a “sandwich” which wraps US guidance material around the full text of ISO/IEC 12207 • IEEE/EIA 12207.1 • a guidance document which provides recommendations that expand on the objectives of IEEE/EIA 12207.0 • IEEE/EIA 12207.2 • guidance document that provides recommendations on the implementation of IEEE/EIA 12207 processes in the context of U.S. best practices. Based on the core concepts of IEEE/EIA J-STD-016 (MIL-STD-498).

  8. Physical Document Structure IEEE/EIA Part 0 IEEE/EIA Part 1Guide to LifeCycle Data IEEE/EIA Part 2Guide to ProcessImplementation IEEE/EIAFront Matter Body Body IEEE/EIAForeword Quoted clausefrom Part 0 ISO/IEC 12207 Guidance forquoted clause Cross-referencesto Part 0 Body Annexes Annexes Annex Annexes

  9. Data Guidance • Found in Part 1 • May be used as a Guide or a Standard • Defines 84 information items related to data requirements of 12207.0 • Defines seven kinds of data: • Description • Plan • Procedure • Record • Report • Request • Specification

  10. Process Guidance • Part 2, Clauses 5, 6, and 7 • Quotes portions of Part 0 (enclosed in a box) and provides relevant guidance • Some of the guidance is abstracted from prior US standards • Themes: • Additional emphasis on key concepts • Clarification of potential misunderstandings • Clarification of “software unit” and “component” especially in context of “architecture” and configuration management • Deprecation of tailoring • Emphasis on enterprise level compliance • Supplier control of life cycle process implementation

  11. Intended Use • It is intended for voluntary adoption rather than contractual imposition. • It emphasizes specific one-party claims of compliance rather than two-party tailoring. • It has relationships to contextual standards affecting enterprise goals. • It has relationships to process and data standards that may be used to implement its processes. The US DoD’s stated intent is to allow bidders to propose life cycle standards as part of the RFP response. IEEE/EIA 12207 would be one appropriate standard; IEEE/EIA J-STD-016 would be another. Either approach could be supported by other standards from the IEEE (or other) standards collection.

  12. Enterprise Level Adoption Enterprise IEEE/EIA 12207 Enterprise Processes Project Enterprise claims compliance to 12207 Project is able to use enterprise procedures, etc. Procedures, practices, templates, etc. Project Processes Project complies with enterprise processes Procedures, practices, templates, etc. Implied Lesson: 12207 is the basis for implementing repeatable, improving processes.

  13. Initiation describe needs define system reqr define software reqr (?) prepare acquisition plan define acceptance strategy Tender (RFP) document acquisition reqr determine processes define references to contract set review milestones Contract Preparation and Update establish supplier selection procedures select supplier tailor 12207 and involve parties negotiate contract Supplier Monitoring monitor in accordance with joint review and audit process supplement with verification and validation Acceptance and Completion prepare for acceptance including tests conduct acceptance review/testing accept deliverables assume configuration management Acquisition Process

  14. Initiation review RFP decide to bid or accept contract Preparation of Response prepare proposal Contract negotiate and enter into contract with acquirer request modifications Planning review acquisition reqrs select life cycle model establish reqr for plans develop and document project management plans (PMPs) Execution and Control execute PMPs develop, operate, or maintain monitor and control progress and quality manage subcontracts interface with independent V&V team interface with other parties Review and Evaluation coordinate with acquirer joint review audit verification and validation access to acquirer QA per QA process Delivery and Completion deliver product or service provide assistance Supply Process

  15. Process Implementation define and select life cycle models employ regularly documentation, CM, and problem resolution processes select and tailor internal methods and tools develop, document and execute plans may use non-deliverables System Activities perform or support Software Activities perform System Architectural Design produce an architecture of the system identify hardware, software and manual operations Software Architectural Design produce an architecture of the software item identify the components of the software item Software and System Integration integration in aggregates partition and integration paths may be different Development Process

  16. Process Implementation develop operational plan set operational standards establish procedures for and with problem resolutions establish procedures for operational testing establish procedures for interfacing with maintenance process establish procedures for releasing the product for operational use Operational Testing perform operational testing for each release release after criteria met ensure code or database perform as planned System Operation operate in environment User Support provide assistance to users forward user requests to maintenance as needed for temporary fixes, provide option to use it Operation Process

  17. Process Implementation develop, document and execute plan establish procedures for problem reports and modification requests manage modifications Problem Analysis analyze modifications for impacts replicate/verify problems implement modifications document and get approval Modification Implementation determine targets use development process for modifications supplement with testing to ensure modified and unmodified parts are correct Maintenance Review and Acceptance review with authorizing organization Migration develop, document and execute plan notify users do parallel operations do post-operations for impact Software Retirement develop, document and execute plan notify users do parallel operations provide for access to retired data and products Maintenance Process

  18. Views use Acquirer Acquisition Process contract use Supplier employ employ Supply Process employ Supporting Processes Operator User use Operation Process use Developer Maintainer Maintenance Process Development Process use use • Documentation • Configuration Management • Quality Assurance • Verification • Validation • Joint Review • Audit • Problem Resolution Supporter Organizational Processes Manager • Management • Infrastructure • Improvement • Training

  19. Comparison I • No activities in MIL-STD-498 corresponding to processes • acquisition, supply, operation, maintenance or training • ISO/IEC 12207 at a more general level: sometimes referred to as a “strategic” standard vice a “tactical” standard • ISO/IEC 12207 definitely not a “do it yourself” guide: requires insight to interpret for a given organization or project

  20. Comparison II • ISO/IEC 12207 bundles tasks together into higher level activities • ISO/IEC 12207 approach is based on a plan, do, check, act cycle • Similar to MIL-STD-498 in that the activities are conceptually independent and not time sequenced • Developer selects lifecycle; activities and tasks must be explicitly mapped onto the lifecycle

  21. Comparison III • Like MIL-STD-498, ISO/IEC 12207 avoids the “dog and pony show” effect of DOD-STD-2167A • specifies the conduct of joint technical reviews • joint management reviews • audits are defined as a separate process in ISO/IEC 12207 • taken together, these accomplish the same things as MIL-STD-498 reviews and audits • Supports non-hierarchical software design • ISO/IEC 12207 requires developers to create software components and to record their design

  22. Comparison IV • Requirements versus Design • the distinction between requirements, analysis, and design is not clarified by the standard • Documentation • ISO/IEC 12207 is not a documentation standard: does not include DIDs • requires that engineering work be done and recorded, regardless of whether paper documents are delivered • neutral on CASE tools as an alternative to documents • defines joint management and technical reviews, which are a convenient alternative to the traditional documentation and review cycles

  23. Next Class:ISO 9000 for Software

More Related