Software Design Knowledge Area

According to the IEEE, software design is an activity that spans the whole software life cycle. It is fundamentally about change management and the maintenance of the requirements in a state that accurately mirrors the software to be, or that has been, built. The knowledge area is divided into six sub-areas.

The first one presents the basic concepts and notions that form an underlying basis to the understanding of the role and scope of software design. These are general concepts, the context of software design, the design process, and the enabling techniques for software design.

The second sub-area regroups the key issues of software design. They include concurrency, control and handling of events, distribution, error and exception handling, interactive systems, and persistence.

The third sub-area is structure and architecture, in particular architectural structures and viewpoints, architectural styles, design patterns, and families of programs and frameworks.

The fourth sub-area describes software design quality analysis and evaluation. While a whole knowledge area is devoted to software quality, this sub-area presents the topics more specifically related to software design. These aspects are quality attributes, quality analysis and evaluation tools and measures.

The fifth sub-area is software design notations, which are divided into structural and behavioral descriptions.

The last sub-area covers software design strategies and methods. First, general strategies are described, followed by function-oriented methods, then object-oriented methods, data-structure centered design and a group of other methods, such as formal and transformational methods.

The above summary was adapted from the Introduction to the IEEE Computer Society's SWEBOK Guide. For more information on the Software Requirements Knowledge Area, read Chapter 3 of the SWEBOK Guide.

Standards

Standard:

Title:

Abstract:

IEEE Std 982.1™-1988

IEEE Standard Dictionary of Measures to Produce Reliable Software

This standard provides a set of measures indicative of software reliability that can be applied to the software product as well as to the development and support processes. It was motivated by the need of software developers and users who are confronted with a plethora of models, techniques, and measures. There is a need for measures that can be applied early in the development process that may be indicators of the reliability of the delivered product. This standard provides a common, consistent definition of a set of measures that may meet those needs.

IEEE Std 1016™-1998

 

IEEE Recommended Practice for Software Design Descriptions

The necessary information content and recommendations for an organization for Software Design Descriptions (SDDs) are described. An SDD is a representation of a software system that is used as a medium for communicating software design information. This recommended practice is applicable to paper documents, automated databases, design description languages, or other means of description.

IEEE Std 1028™-1997

 

IEEE Standard for Software Reviews

This standard defines five types of software reviews, together with procedures required for the execution of each review type. This standard is concerned only with the reviews; it does not define procedures for determining the necessity of a review, nor does it specify the disposition of the results of the review. Review types include management reviews, technical reviews, inspections, walk-throughs, and audits.

IEEE Std 1320.1™-1998

 

IEEE Standard for Functional Modeling Language—Syntax and Semantics for IDEF0

IDEF0 function modeling is designed to represent the decisions, actions, and activities of an existing or prospective organization or system. IDEF0 graphics and accompanying texts are presented in an organized and systematic way to gain understanding, support analysis, provide logic for potential changes, specify requirements, and support system-level design and integration activities. IDEF0 may be used to model a wide variety of systems, composed of people, machines, materials, computers, and information of all varieties and structured by the relationships among them, both automated and nonautomated. For new systems, IDEF0 may be used first to define requirements and to specify functions to be carried out by the future system. As the basis of this architecture, IDEF0 may then be used to design an implementation that meets these requirements and performs these functions. For existing systems, IDEF0 can be used to analyze the functions that the system performs and to record the means by which these are done.

IEEE Std 1320.2™-1998

 

IEEE Standard for Conceptual Modeling Language Syntax and Semantics for IDEF1X97 (IDEFobject)

IDEF1X97 consists of two conceptual modeling languages. The key-style language supports data/information modeling and is downward compatible with the U.S. government’s 1993 standard, FIPS PUB 184. The identity-style language is based on the object model with declarative rules and constraints. IDEF1X97 identity style includes constructs for the distinct but related components of object abstraction: interface, requests, and realization; utilizes graphics to state the interface; and defines a declarative, directly executable Rule and Constraint Language for requests and realizations. IDEF1X97  conceptual modeling supports implementation by relational databases, extended relational databases, object databases, and object programming languages. IDEF1X97 is formally defined in terms of first order logic. A procedure is given whereby any valid IDEF1X97 model can be transformed into an equivalent theory in first order logic. That procedure is then applied to a meta model of IDEF1X97 to define the valid set of IDEF1X97 models.

IEEE Std 1471™-2000

 

IEEE Recommended Practice for Architectural Description of Software Intensive Systems

This recommended practice addresses the activities of the creation, analysis, and sustainment of architectural descriptions. A conceptual framework for architectural description is established. The content of an architectural description is defined. Annexes provide the rationale for key concepts and terminology, the relationships to other standards, and examples of usage.

About IEEE standard numbers.