software design

IEEE Std 1016 - IEEE Standard for Information Technology-Systems Design - Software Design Descriptions

Body

From IEEE Software Engineering Standards Collection:

IEEE Std 1016. A software design description is a representation of a software system. It is used as a medium for communicating software design information. This recommended practice describes that documentation of software designs. It specifies the necessary information content and the recommended organisation for a software design description.

Defined by
IEEE Std 1016-2009 - IEEE Standard for Information Technology-Systems Design - Software Design Descriptions

Def Stan 05-95: "Quality System Requirements for the Design Development, Supply and Maintenance of Software"

Defined by
Def Stan 05-95: "Quality System Requirements for the Design Development, Supply and Maintenance of Software": Issue 3
Defining documents
Document title Document identifier Document date File size File
Def Stan 05-95: "Quality System Requirements for the Design Development, Supply and Maintenance of Software": Issue 3 DEF STAN 05-95/3 99.09 KB   DOWNLOAD!
Document title Document identifier Document date File size File
Def Stan 05-95: "Quality System Requirements for the Design Development, Supply and Maintenance of Software": Issue 3 DEF STAN 05-95/3 1995-06-23 99.09 KB   DOWNLOAD!

IDEF9 Business Constraint Discovery

IDEF9 or Integrated Definition for Business Constraint Discovery is designed to assist in the discovery and analysis of constraints in a business system. A primary motivation driving the development of IDEF9 was an acknowledgment that the collection of constraints that forge an enterprise system is generally poorly defined. The knowledge of what constraints exist and how those constraints interact is incomplete, disjoint, distributed, and often completely unknown. This situation is not necessarily alarming. Just as living organisms do not need to be aware of the genetic or autonomous constraints that govern certain behaviors, organizations can (and most do) perform well without explicit knowledge of the glue that structures the system. However, if the desire exists to modify the business in a predictable manner, the knowledge of these constraints is as critical as knowledge of genetics is to the genetic engineer. concepts in terms of familiar, concrete objects and experiences.

http://en.wikipedia.org/wiki/IDEF2#IDEF9

IDEF8 Human-System Interaction Design

IDEF8 or Integrated Definition for Human-System Interaction Design is a method for producing high-quality designs of the interactions that occur between users and the systems they operate. Systems are characterized as a collection of objects which perform functions to accomplish a particular goal. The system with which the user interacts can be any system, not necessarily a computer program. Human-system interactions are designed at three levels of specification within the IDEF8 method. The first level defines the philosophy of system operation and produces a set of models and textual descriptions of overall system processes. The second level of design specifies role-centered scenarios of system use. The third level of IDEF8 design is for human-system design detailing. At this level of design, IDEF8 provides a library of metaphors to help users and designers specify the desired behavior in terms of other objects whose behavior is more familiar. Metaphors provide a model of abstract concepts in terms of familiar, concrete objects and experiences.

http://en.wikipedia.org/wiki/IDEF2#IDEF8

IDEF6 Design Rationale Capture

IDEF6 or Integrated Definition for Design Rationale Capture is a method to facilitate the acquisition, representation, and manipulation of the design rationale used in the development of enterprise systems. Rationale is the reason, justification, underlying motivation, or excuse that moved the designer to select a particular strategy or design feature. More simply, rationale is interpreted as the answer to the question, “Why is this design being done in this manner?” Most design methods focus on the what the design is (i.e., on the final product, rather than why the design is the way it is).

IDEF6 will be a method that possesses the conceptual resources and linguistic capabilities needed (i) to represent the nature and structure of the information that constitutes design rationale within a given system, and (ii) to associate that rationale with design specifications, models, and documentation for the system. The scope of IDEF6 applicability covers all phases of the information system development process, from initial conceptualization through both preliminary and detailed design activities. To the extent that detailed design decisions for software systems are relegated to the coding phase, the IDEF6 technique should be usable during the software construction process as well.

http://en.wikipedia.org/wiki/IDEF2#IDEF6

Dr. Peter Pin-Shan Chen

Organisation(s)
Association for Computing Machinery (ACM)
Harvard University
Massachusetts Institute of Technology (MIT)
National Taiwan University
UCLA Management School
University of California, Los Angeles (UCLA)
Related standards/methodologies
Entity-Relationship Model
IDEF1 Information Modeling
IDEF1X Information Modeling

The initial approach to IDEF information modeling (IDEF1) was published by the ICAM program in 1981, based on current research and industry needs. The theoretical roots for this approach stemmed from the early work of Edgar F. Codd on relational theory and Peter Chen on the entity-relationship model. The initial IDEF1 technique was based on the work of Dr. R.R. Brown and Mr. T.L. Ramey of Hughes Aircraft and Mr. D.S. Coleman of D. Appleton & Company, with critical review and influence by Charles Bachman, Peter Chen, Dr. M.A. Melkanoff, and Dr. G.M. Nijssen.

http://en.wikipedia.org/wiki/IDEF1X#History
Subscribe to software design