The Software Development Standards

1. The Software Development Standards Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU

2. OUTLINE • IEEE/EIA 12207 Standard for Information Technology-software life cycle processes • Scope • Life cycle processes • Primary Processes • Development Process • Iterative development and the Unified Process • The IEEE 1471 Software Architecture Standard • Organization of IEEE 1471 • The Conceptual Framework

3. IEEE/EIA 12207 Standard for Information Technology-software life cycle processes IEE/EIA 12207.0 Clause 1-Scope. Purpose: This International Standard establishes a common framework for software life cycle processes, with well-defined terminology, that can be referenced by the software industry. It contains processes, activities, and tasks that are to be applied during the acquisition of a system that contains software, a stand-alone software product, and software service and during the supply, development, operation, and maintenance of software products. Software includes the software portion of firmware.

4. ACQUISITION MAINTENANCE MANAGEMENT OPERATION contract SUPPLY DEVELOPMENT CM DOCUMENTATION PROB. RES. VERIFICATION QA JOINT REVIEW AUDIT VALIDATION SUPPORTING PROCESSES INFRASTRUCTURE TRAINING IMPROVEMENT ORGANIZATIONAL PROCESSES IEEE/EIA 12207 Standard for Information Technology-software life cycle processes

5. The 12207 Primary Processes

6. The IEEE 12207 Development Process

7. The IEEE 12207 Development Process: The System Architecture Design Activity • 5.3.3 System architectural design. This activity consists of the following tasks, which the developer shall perform or support as required by the contract: • 5.3.3.1 A top-level architecture of the system shall be established. The architecture shall identify items of hardware, software, and manual-operations. It shall be ensured that all the system requirements are allocated among the items. Hardware configuration items, software configuration items, and manual operations shall be subsequently identified from these items. The system architecture and the system requirements allocated to the items shall be documented. • 5.3.3.2 The system architecture and the requirements for the items shall be evaluated considering the criteria listed below. The results of the evaluations shall be documented. a) Traceability to the system requirements; b) Consistency with the system requirements; c) Appropriateness of design standards and methods used; d) Feasibility of the software items fulfilling their allocated requirements; e) Feasibility of operation and maintenance.

8. The IEEE 12207 Development Process: The Software Architecture Design Activity 5.3.5 Software architectural design. For each software item (or software configuration item, i f identified), this activity consists of the following tasks: 5.3.5.1 The developer shall transform the requirements for the software item into an architecture that describes its top-level structure and identifies the software components. It shall be ensured that all the requirements for the software item are allocated to its software components and further refined to facilitate detailed design. The architecture of the software item shall be documented. 5.3.5.2 The developer shall develop and document a top-level design for the interfaces external to the software item and between the software components of the software item. 5.3.5.3 The developer shall develop and document a top-level design for the database. 5.3.5.4 The developer should develop and document preliminary versions of user documentation. 5.3.5.5 The developer shall define and document preliminary test requirements and the schedule for Software Integration. 5.3.5.6 The developer shall evaluate the architecture of the software item and the interface and database designs considering the criteria listed below. The results of the evaluations shall be documented. a) Traceability to the requirements of the software item; b) External consistency with the requirements of the software item; c) Internal consistency between the software components; d) Appropriateness of design methods and standards used; e) Feasibility of detailed design; f) Feasibility of operation and maintenance. 5.3.5.7 The developer shall conduct joint review(s) in accordance with 6.6.

9. The IEEE 12207 Development Process

10. The Incremental Development model: Build 1

11. The Incremental Development model: Build 2

12. The Evolutionary Development model: Build 1

13. The Evolutionary Development model: Build 2

14. The Unified process (IBM Rational)Iterative and Incremental development model

15. The Unified process (Cont.)

16. OUTLINE • The IEEE 12207 Software Life Cycle Process Standard • The IEEE 1471 Software Architecture Standard • Definition • Conceptual Framework • Architectural Description

17. The IEEE 1471 Software Architecture Standard [from Rich Hilliard’s Presentation:All About IEEE Std 1471, 2007] Organization of IEEE 1471 1 Overview 2 References 3 Definitions 4 Conceptual Framework 5 Architectural Description Practices (normative) A Bibliography B On The Definition Of Architecture C Views And Viewpoints D Examples Of Viewpoints E Relationship To Other Standards

18. The IEEE 1471 Software Architecture Standard

19. The IEEE 1471 Software Architecture Standard Using IEEE 1471 • IEEE 1471 is intended for use in a variety of life cycle contexts, e.g.: • Architecture of Single Systems – Whether applications, systems, products, systems of systems, product lines, product families… • Iterative Architecture for Evolutionary Systems • Discovering the Architecture of Existing Systems

20. The IEEE 1471 Software Architecture Standard: Definition Defining “Architecture” in IEEE 1471 • Architecture: the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution. where: – fundamental = essential, unifying concepts and principles – system = application, system, platform, system-of-systems, enterprise, product line, ... – environment = developmental, operational, programmatic, … context • Every system has an architecture

21. The IEEE 1471 Software Architecture Standard: Conceptual Framework Role of the Conceptual Framework • To establish terms and concepts for architectural thinking • To provide a means to talk about Architectural Descriptions within the context of – System Stakeholders – Life Cycle – Uses of Architectural Description • To serve as a basis for evolution of knowledge in a field where little common terminology existed

22. The IEEE 1471 Software Architecture Standard

23. The IEEE 1471 Software Architecture Standard

24. The IEEE 1471 Software Architecture Standard The IEE 1471 Conceptual Framework: Architectural Description • Architectural description (AD): a collection of products to document an architecture • An AD is addressed to the system’s stakeholders to answer their architectural concerns about the system • An AD is organized into one or more views of the system • Each view addresses one or more concerns of the stakeholders

25. The IEEE 1471 Software Architecture Standard The IEEE 1471 Conceptual Framework: Stakeholders and Concerns • stakeholder: an individual, team, or organization (or collections thereof) with interests in, or concerns relative to, a system • concerns: those stakeholders’ interests which pertain to the development, operation, or other key characteristics of the system (e.g., performance, reliability, security, evolvability, distribution, …) • Some Typical System (Architecture) Stakeholders • Client • Acquirer • Owner • User • Operator • Architect • System Engineer • Developer • Designer • Builder • Maintainer • Service Provider • Vendor • Subcontractor • Planner

26. Stakeholders and Concerns

27. The IEEE 1471 Software Architecture Standard The IEEE 1471 Conceptual Framework: Architectural Views • An AD consists of one or more views • view: a representation of a whole system from the perspective of a related set of concerns – The architectural views are the actual description of the system • Support multiple audiences each with their own concerns • Reduce perceived complexity through separation of concerns

28. The IEEE 1471 Software Architecture Standard IEEE 1471 Conceptual Framework: Architectural Views Definition: A view is a representation of one or more structural aspects of an architecture that illustrates how the architecture addresses one or more concerns held by one or more of its stakeholders. • Views are not “orthogonal” but each view generally contains new information • Views are modular: – A view may contain one or more architectural models, allowing (1) a view to utilize multiple notations, and (2) a model to be shared between multiple views • Consistency between views in an AD: – An AD documents any known inconsistencies among the views it contains

29. The IEEE 1471 Software Architecture Standard:Example Architecture Views according to the SEI literature. • Architecture viewsprovide the basis for reasoning about the appropriateness and quality of the architecture for achieving system quality goals. • Some common architectural views include • the logical view, which represents system functions; key system abstractions and their dependencies; and data flows • the module decomposition view, which represents the hierarchical decomposition of the system's functionality into units of implementation. This decomposition can include objects, procedures, functions, and their relationships. • the communicating-processes view, which represents processing threads, their synchronization, and the data flows between them • the deployment view, which shows how the software is allocated to hardware including processors, storage, and external devices or sensors, along with the communications paths that connect them

30. Example Architecture ViewsThe 4+1 view model P. Kruchten. Architectural Blueprints - The “4+1” View Model of Software Architecture. IEEE Software, 12(6):42–50, 1995.

32. The IEEE 1471 Software Architecture Standard IEEE 1471 Conceptual Framework: Architectural Viewpoints Definition: A viewpoint is a collection of patterns, templates, and conventions for constructing one type of view. It defines the stakeholders whose concerns are reflected in the viewpoint and the guidelines, principles, and template models for constructing its views. • Views should be well-formed: – Each view corresponds to exactly one viewpoint – Viewpoints define the resources and rules for constructing views • Concerns drive the selection of the viewpoints to be used: – A viewpoint establishes the purposes and audience for a view and the techniques or methods employed in constructing a view – Each concern is addressed by some architectural view • Viewpoints are first-class: – Each viewpoint used in an AD is “declared” before use

33. The IEEE 1471 Software Architecture Standard How to declare a Viewpoint • Each architectural viewpoint is determined by: – Viewpoint name – The stakeholders addressed by the viewpoint – The architectural concerns “framed” by the viewpoint – The viewpoint language, or modeling techniques, or analytical methods used to construct, depict and analyze the resulting view – The source, if any, of the viewpoint (e.g., author, literature citation) • A viewpoint may optionally include: – Consistency or completeness checks associated with the underlying method to be applied to models within the view – Evaluation or analysis techniques to be applied to models within the view – Heuristics, patterns, or other guidelines which aid in the synthesis of an associated view or its models

34. Examples of Viewpoints and ViewsD. Norris. Communicating Complex Architectures with UML and the Rational ADS. In Proceedings ofthe IBM Rational Software Development User Conference, 2004.

35. Examples of Viewpoints and ViewsDesign Viewpoint, Logical View

36. Examples of Viewpoints and ViewsRealizationViewpoint, Implementation View A Viewpoint Example: Capability • Its name: Capability • Its Stakeholders: – producers, developers and integrators • The architectural concerns it frames: – How is functionality packaged? – How is it fielded? – What interfaces are managed? • The viewpoint language it uses: – Components and their dependencies (UML component diagrams) – Interfaces and their attributes (UML class diagrams) • Its source: also known as Static, Application, Structural viewpoints

37. The IEEE 1471 Software Architecture Standard

38. The IEEE 1471 Software Architecture Standard Why separate View and Viewpoint? • Originally derived from experience – Noticed 'patterns' in good architectural descriptions, addressing the same issues on different systems • E.g. Security, performance, structure, data, etc – Capturing the 'pattern' made it easier to do the next architecture, by providing a known starting point • Literature survey produced several approaches with well defined views – RM-ODP, Zachman, Kruchten’s 4+1, etc – But no separate name for view and viewpoint concepts • Also influenced by programming language design and the software patterns movement – Explicitly capturing and declaring the pattern before use considered to be good engineering view : viewpoint :: program : programming language Objects : OOAD

39. The IEEE 1471 Software Architecture Standard IEEE 1471 Requirements • IEEE 1471 is written in terms of “shall”, “should” and “may” – To facilitate conformance checking • An Architectural Description (AD) must contain at least the following: – Identification of stakeholders and concerns – Selection and declaration of the viewpoints used – Architectural views, each conforming to a viewpoint – Any known inconsistencies – Architectural rationale

40. Extensions to the 1471conceptual framework

41. Architectural Frameworks • An Architecture Framework is defined as: - a predefined set of concerns, stakeholders, viewpoints, and viewpoint correspondence rules; established to capture common practice for architecture descriptions within specific domains or user communities

42. Example of an Architectural Framework: the 4+1 view

43. The IEEE 1471 Software Architecture Standard More About IEEE 1471 • Web site http://www.iso-architecture.org/ieee-1471/ • Users group (see website) • Bibliography (see website) • Example: Aspects in Architectural Descriptions Thoughts about Quality of Service David Emery, DSCI, Jan 2007 • Applying IEEE 1471/ISO 42010: On the course website