Between the requirements document and the first line of production code, there is a critical moment of translation. Someone — an architect, a senior developer, a designer — must take the abstract statement of what a system must do and convert it into a precise, structured description of how it will actually work. That document is the Software Design Description. And without a rigorous guide to writing one, the translation can go badly wrong.
Software Design Descriptions: A How-To Guide for Project Staff is that guide. Grounded in IEEE Standard 1016, the internationally recognised practice for software design documentation, it provides a clear, practical pathway from design concept to complete, code-ready documentation — the kind that a programmer can pick up, follow without ambiguity, and implement with confidence.
The book opens by establishing what a Software Design Description — an SDD — actually is and why it exists. It is, at its core, the primary reference for code development. As Tuffley makes clear from the outset, the SDD must contain all the information required by a programmer to write code. Nothing more and nothing less. That deceptively simple standard turns out to demand considerable intellectual discipline, and this book provides the framework to meet it.
Before reaching the document structure itself, the book does something that more prescriptive guides often skip: it defines what makes a design description good. A dedicated section on quality criteria examines the design virtues that separate professional software documentation from the kind that causes maintenance headaches for years to come. Traceability ensures every design entity maps to a specific requirement. Completeness demands that no input goes unaccounted for and no output is left without a value. Modularity is explored in depth — the discipline of breaking a complex problem into sub-problems small enough that a reviewer can understand a module on a first reading with only limited knowledge of the complete system.
The treatment of cohesion and coupling is particularly lucid. Poor cohesion — a module that detects messages, runs scheduled tasks, monitors communications links, and attempts error recovery all at once — is shown in stark contrast to the clean, single-purpose module that does one thing well. The four levels of coupling, from acceptable data coupling through the deeply problematic territory of content coupling, give designers a practical compass for evaluating their own work.
The bulk of the book walks through the SDD document structure section by section. Module detailed design descriptions receive the most thorough treatment: purpose, function, subordinates, dependencies, interfaces, resources, internal data, and processing logic are each given precise definitions and requirements. The unit test strategy section — embedded within the module design itself, not treated as an afterthought — reflects a mature understanding of how good design and good testing are inseparable disciplines.
Interface design descriptions, database design, global memory management, and the full message architecture round out the document structure, followed by an appendix on Structured English — the pseudo-code methodology that gives processing descriptions a precise, unambiguous form that bridges human readability and code logic.
For architects, designers, senior developers, and the project managers who must evaluate their work, this book establishes the standard. Design is, as the author himself writes, a plan for arranging elements in the best way to achieve a purpose. This book shows exactly how to document that plan.
"synopsis" may belong to another edition of this title.
David Tuffley PhD is lecturer and researcher at Griffith University in Australia. David is a Software Engineer, though his interests range across Comparative Religion, Philosophy, Psychology, Anthropology, Literature, History, Design and Architecture. David has been an academic since 1999. For 15 years before academia David was a consultant for public and private sector IT clients in Australia and the United Kingdom. He combines theory and practice in a focussed and disciplined way that has proved effective for solving problems for clients.
"About this title" may belong to another edition of this title.
Seller: GreatBookPrices, Columbia, MD, U.S.A.
Condition: As New. Unread book in perfect condition. Seller Inventory # 20947761
Seller: GreatBookPrices, Columbia, MD, U.S.A.
Condition: New. Seller Inventory # 20947761-n
Seller: California Books, Miami, FL, U.S.A.
Condition: New. Print on Demand. Seller Inventory # I-9781461127055
Seller: THE SAINT BOOKSTORE, Southport, United Kingdom
Paperback / softback. Condition: New. This item is printed on demand. New copy - Usually dispatched within 5-9 working days. Seller Inventory # C9781461127055
Quantity: Over 20 available
Seller: GreatBookPricesUK, Woodford Green, United Kingdom
Condition: As New. Unread book in perfect condition. Seller Inventory # 20947761
Quantity: Over 20 available
Seller: GreatBookPricesUK, Woodford Green, United Kingdom
Condition: New. Seller Inventory # 20947761-n
Quantity: Over 20 available
Seller: CitiRetail, Stevenage, United Kingdom
Paperback. Condition: new. Paperback. The task of developing comprehensive Software Design Descriptions (SDDs) is greatly assisted by this book. Written for software development project managers and staff, it is basically a plain-English, simplified version of the IEEE Std 1016 Recommended Practice for Software Design Descriptions. While it infringes no copyright, it still embodies the essential detail of IEEE 1016. It describes the: - Software development context in which an SDD should be created, - Minimum requirements for SDD format and content and, - Qualities of a good SDD. Who is this document for? The SDD is created by the System Architect or designer and is the major deliverable from the detailed design process. What are the Prerequisites? The prerequisite document required for an SDD varies according to the size and complexity of the software product to be developed. For large systems the prerequisite is the System Architecture Specification. In this context the SDD represents a further refinement of the design entities described in the SAS. An SDD may provide descriptions of one or more design entities. For small systems, the SDD prerequisite is a Software Requirements Specification. In this context it is the single source of design solutions to problems stated in the SRS. Who uses the SDD? The SDD is the primary reference for code development. As such, it must contain all the information required by a programmer to write code. Contribution to IS Quality A structured and comprehensive approach to software design is known to be a major factor contributing to Information Systems Quality. Adequate design is however often not performed, contributing to a higher number of software defects which impact the real and perceived quality of the software, as well as leading to time and expense being spent on rework and higher maintenance costs. How to Write Software Design Descriptions is a plain-English, procedural guide to developing high quality SDDs that are both systematic and comprehensive. It contains detailed instructions and templates on the following test documentation. This item is printed on demand. Shipping may be from our UK warehouse or from our Australian or US warehouses, depending on stock availability. Seller Inventory # 9781461127055
Quantity: 1 available