Active10 months ago
- Software Design Documentation
- Software System Design Example Online
- Software Design Specification Template
- Software System Design Example For Kids
- Sample Software Design Document
- Software System
votes
Could someone explain the difference between Software Design and Software Architecture?
Detailed System Design. Most components described in the System Architecture section will require a more detailed discussion. Other lower-level components and subcomponents may need to be described as well. Each subsection of this section will refer to or contain a detailed description of a system software component. The architecture/design document should identify major system components and describe their static attributes and dynamic patterns of interaction. Software architecture and designs are typically expressed with a mix of UML models (class and sequence diagrams being the two most common) and prose.
- Software Architecture Example The easiest way to create a software architecture diagram is editing an existing template. This software architecture template can save many hours in creating great software architecture by using built-in symbols right next to the canvas.
- In the Software Design and Architecture Specialization, you will learn how to apply design principles, patterns, and architectures to create reusable and flexible software applications and systems. You will learn how to express and document the design and architecture of a software system using a visual notation.
More specifically; if you tell someone to present you the 'design' - what would you expect them to present? Same goes for 'architecture'.
My current understanding is:
- Design: UML diagram/flow chart/simple wireframes (for UI) for a specific module/part of the system
- Architecture: component diagram (showing how the different modules of the system communicates with each other and other systems), what language is to be used, patterns..?
Correct me if I'm wrong. I have referred Wikipedia has articles on http://en.wikipedia.org/wiki/Software_design and http://en.wikipedia.org/wiki/Software_architecture, but I'm not sure if I have understood them correctly.
user3956566.20.7k1616 gold badges7272 silver badges115115 bronze badges
Mads MobækMads Mobæk19.5k2020 gold badges6363 silver badges7373 bronze badges
closed as primarily opinion-based by George Stocker♦Dec 19 '13 at 21:22
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
locked by user3956566.Nov 30 '18 at 21:00
This question exists because it has historical significance, but it is not considered a good, on-topic question for this site so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. See the help center for guidance on writing a good question.
Read more about locked posts here.
41 Answers
12 next
votes
You're right yes. The architecture of a system is its 'skeleton'. It's the highest level of abstraction of a system. What kind of data storage is present, how do modules interact with each other, what recovery systems are in place. Just like design patterns, there are architectural patterns: MVC, 3-tier layered design, etc.
Software design is about designing the individual modules / components. What are the responsibilities, functions, of module x? Of class Y? What can it do, and what not? What design patterns can be used?
So in short, Software architecture is more about the design of the entire system, while software design emphasizes on module / component / class level.
Robert Harvey153k3838 gold badges296296 silver badges436436 bronze badges
RazzieRazzie24.3k1010 gold badges5454 silver badges7171 bronze badges
votes
In some descriptions of the SDLC (Software Development Life Cycle) they are interchangeable, but the consesus is that they are distinct. They are at the same time: different (1) stages, (2) areas of responsibility, and (3) levels of decision-making.
- Architecture is the bigger picture: the choice of frameworks, languages, scope, goals, and high-level methodologies (Rational, waterfall, agile, etc.).
- Design is the smaller picture: the plan for how code will be organized; how the contracts between different parts of the system will look; the ongoing implementation of the project's methodologies and goals. Specification are written during this stage.
These two stages will seem to blend together for different reasons.
- Smaller projects often don't have enough scope to separate out planning into these to stages.
- A project might be a part of a larger project, and hence parts of both stages are already decided. (There are already existing databases, conventions, standards, protocols, frameworks, reusable code, etc.)
- Newer ways of thinking about the SDLC (see Agile methodologies) somewhat rearrange this traditional approach. Design (architecture to a lesser extent) takes place throughout the SDLC on purpose. There are often more iterations where the whole process happens over and over.
- Software development is complicated and difficult to plan anyway, but clients/managers/salespeople usually make it harder by changing goals and requirements mid-stream. Design and even architectural decisions must bemade later in the project whether that is the plan or not.
Even if the stages or areas of responsibility blend together and happen all over the place, it is always good to know what level of decision-making is happening. (We could go on forever with this. I'm trying to keep it a summary.) I'll end with: Even if it seems your project has no formal architectural or design stage/AOR/documentaiton, it IS happening whether anyone is consciously doing it or not. If no one decides to do architecture, then a default one happens that is probably poor. Ditto for design. These concepts are almost more important if there are no formal stages representing them.
Patrick KarcherPatrick Karcher19.6k55 gold badges4747 silver badges6363 bronze badges
votes
Architecture is strategic, while Design is tactical.
Architecture comprises the frameworks, tools, programming paradigms, component-based software engineering standards, high-level principles.
While design is an activity concerned with local constraints, such as design patterns, programming idioms, and refactorings.
Chris KannonChris Kannon4,51044 gold badges2121 silver badges3232 bronze badges
votes
I found this as I was looking for simple distinction between architecture and design myself;
What do you think of this way of looking at them:
What do you think of this way of looking at them:
- architecture is 'what' we're building;
- design is 'how' we're building;
80.5k1818 gold badges129129 silver badges187187 bronze badges
George S.George S.
votes
- Architecture means the conceptual structure and logical organization of a computer or computer-based system.Design means a plan or drawing produced to show the look and function or workings of a system or an object before it is made.
- If you are “architecting” a component, you are defining how it behaves in the larger system.If you are “designing” the same component, you are defining how it behaves internally.
All architecture is design but NOT all design is architecture.
What
part is the Design, the How
is the concrete implementation and the intersection of What
and How
is Architecture.Image for differentiating Architecture and Design:
There are also design decisions, that are not architecturally significant, i.e. does not belongs to the architecture branch of design. For example, some component’s internal design decisions, like- choice of algorithm, selection of data structure etc.
Any design decision, which isn’t visible outside of its component boundary is a component’s internal design and is non-architectural. These are the design decisions a system architect would leave on module designer’s discretion or the implementation team as long as their design don’t break the architectural constraints imposed by the system level architecture.
The link that gives good analogy
TryinHardTryinHard2,94122 gold badges2323 silver badges4646 bronze badges
votes
I'd say you are right, in my own words;
Architecture is the allocation of system requirements to system elements. Four statements about an architecture:
- It can introduce non-functional requirements like language or patterns.
- It defines the interaction between components, interfaces, timing, etc.
- It shall not introduce new functionality,
- It allocates the (designed) functions that the system is intended to perform to elements.
Architecture is an essential engineering step when a complexity of the system is subdivided.
Example: Think about your house, you don't need an architect for your kitchen (only one element involved) but the complete building needs some interaction definitions, like doors, and a roof.
Design is a informative representation of the (proposed) implementation of the function. It is intended to elicit feedback and to discuss with stakeholders. It might be good practice but is not an essential engineering step.
It would be nice to see the kitchen design see before the kitchen is installed but it is not essential for the cooking requirement:
If I think about it you can state:
- architecture is for a public/engineers on a more detailed abstraction level
- design is intended for public on a less detailed abstraction level
11.7k99 gold badges4242 silver badges7272 bronze badges
Software Design Documentation
user662182user662182
votes
My reminder:
- We can change the Design without asking someone
- If we change the Architecture we need to communicate it to someone (team, client, stakeholder, ..)
5,89677 gold badges4747 silver badges5353 bronze badges
votes
I think we should use the following rule to determine when we talk about Design vs Architecture: If the elements of a software picture you created can be mapped one to one to a programming language syntactical construction, then is Design, if not is Architecture.
So, for example, if you are seeing a class diagram or a sequence diagram, you are able to map a class and their relationships to an Object Oriented Programming language using the Class syntactical construction. This is clearly Design. In addition, this might bring to the table that this discussion has a relation with the programming language you will use to implement a software system. If you use Java, the previous example applies, as Java is an Object Oriented Programming Language. If you come up with a diagram that shows packages and its dependencies, that is Design too. You can map the element (a package in this case) to a Java syntactical construction.
Now, suppose your Java application is divided in modules, and each module is a set of packages (represented as a jar file deployment unit), and you are presented with a diagram containing modules and its dependencies, then, that is Architecture. There isn’t a way in Java (at least not until Java 7) to map a module (a set of packages) to a syntactical construction. You might also notice that this diagram represents a step higher in the level of abstraction of your software model. Any diagram above (coarse grained than) a package diagram, represents an Architectural view when developing in the Java programming language. On the other hand, if you are developing in Modula-2, then, a module diagram represents a Design.
(A fragment from http://www.copypasteisforword.com/notes/software-architecture-vs-software-design)
Enrique MolinariEnrique Molinari
votes
Personally, I like this one:
'The designer is concerned with what happens when a user presses a button, and the architect is concerned with what happens when ten thousand users press a button.'
SCEA for Java™ EE Study Guide by Mark Cade and Humphrey Sheil
TaviTavi
votes
I agree with many of the explanations; essentially we are recognizing the distinction between the architectural design and the detailed design of the software systems.
While the goal of the designer is to be as precise and concrete in the specifications as it will be necessary for the development; the architect essentially aims at specifying the structure and global behavior of the system just as much as required for the detailed design to begin with.
A good architect will prevent hyper-specifications - the architecture must not be overly specified but just enough, the (architectural) decisions established only for the aspects that present costliest risks to handle, and effectively provide a framework ('commonality') within which the detailed design can be worked upon i.e. variability for local functionality.
Indeed, the architecture process or life-cycle just follows this theme - adequate level of abstraction to outline the structure for the (architecturally) significant business requirements, and leave more details to the design phase for more concrete deliverables.
Ajay ShendyeAjay Shendye
votes
Architecture is design, but not all design is architectural. Therefore, strictly speaking, it would make more sense to try to differentiate between architectural design and non-architectural design. And what is the difference? It depends! Each software architect may have a different answer (ymmv!). We develop our heuristics to come up with an answer, such as 'class diagrams are architecture and sequence diagrams are design'. See DSA book for more.
It's common to say that architecture is at a higher abstraction level than design, or architecture is logical and design is physical. But this notion, albeit commonly accepted, is in practice useless. Where do you draw the line between high or low abstraction, between logical and physical? It depends!
So, my suggestion is:
- create a single design document.
- name this design document the way you want or, better, the way the readers are more accustomed to. Examples: 'Software Architecture', 'Software Design Specification'.
- break this document into views and keep in mind you can create a view as a refinement of another view.
- make the views in the document navigable by adding cross-references or hyperlinks
- then you'll have higher level views showing broad but shallow overview of the design, and closer-to-implementation views showing narrow but deeper design details.
- you may want to take a look at an example of multi-view architecture document (here).
Having said all that.. a more relevant question we need to ask is: how much design is enough? That is, when should I stop describing the design (in diagrams or prose) and should move on to coding?
Paulo MersonPaulo Merson6,65744 gold badges4343 silver badges4444 bronze badges
votes
Yep that sounds right to me. The design is what you're going to do, and architecture is the way in which the bits and pieces of the design will be joined together. It could be language agnostic, but would normally specify the technologies to be used ie LAMP v Windows, Web Service v RPC.
MrTellyMrTelly
votes
The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships between them.
(from Wikipedia, http://en.wikipedia.org/wiki/Software_architecture)
Software design is a process of problem-solving and planning for a software solution. After the purpose and specifications of software are determined, software developers will design or employ designers to develop a plan for a solution. It includes low-level component and algorithm implementation issues as well as the architectural view.
(from Wikipedia, http://en.wikipedia.org/wiki/Software_design)
Couldn't have said it better myself :)
Larry WatanabeLarry Watanabe8,64788 gold badges3636 silver badges4444 bronze badges
votes
I view architecture as Patrick Karcher does - the big picture. For example, you can provide the architecture to a building, view its structural support, the windows, entries and exits, water drainage, etc. But you have not 'designed' the floor layout's, cubicle positions etc.
So while you've architected the building you have not designed the layout of each office.I think the same holds true for software.
You could view designing the layout, as 'architecting the layout' though ..
mr-skmr-sk10.3k66 gold badges5252 silver badges8989 bronze badges
votes
Good question.. Although the line between them is hardly a bright sharp line, imho, if you are using both terms, then Architecture encompasses more technical or structural decisions about how to build or construct something, especially those decisions that will be hard (or harder) to change once implemeneted, whereas Design encompasses those decisions that either are easy to change later (like method names, class <-> file organizational structure, design patterns, whether to use a singleton or a static class to solve some specific problem, etc. ) and/or those that effect the appearance or esthetic aspects of a system or application (Human Interface, ease of use, look and feel, etc.)
Charles BretanaCharles Bretana119k2222 gold badges130130 silver badges202202 bronze badges
votes
Software architecture is“concerned with issues..beyond the algorithms and data structures of the computation.
Architecture is specifically not about…details of implementations (e.g., algorithms and data structures.) Architectural design involves a richer collection of abstractions than is typically provided by OOD” (object-oriented design).
Design is concerned with the modularization and detailed interfaces of the design elements, their algorithms and procedures, and the data types needed to support the architecture and to satisfy the requirements.
“architecture” is often used as a mere synonym for “design” (sometimes preceded with the adjective “high-level”). And many people use the term “architectural patterns” as a synonym for “design patterns.”
Check out this link.
TeboTebo7,2361111 gold badges4242 silver badges6161 bronze badges
Software System Design Example Online
votes
Architecture:
Structural design work at higher levels of abstraction which realize technically significant requirements into the system. The architecture lays down foundation for further design.
Structural design work at higher levels of abstraction which realize technically significant requirements into the system. The architecture lays down foundation for further design.
Design:
The art of filling in what the architecture does not through an iterative process at each layer of abstraction.
The art of filling in what the architecture does not through an iterative process at each layer of abstraction.
Joshua RamirezJoshua Ramirez
votes
I really liked this paper for a rule of thumb on separating architecture from design:
It's called the Intension/Locality hypothesis. Statements on the nature of the software that are non-local and intensional are architectural. Statements that are local and intensional are design.
LindsayBradfordLindsayBradford
votes
..long time ago in a faraway place philosophers worried about the distinction between the one and the many. Architecture is about relationship, which requires the many. Architecture has components. Design is about content, which requires the one. Design has properties, qualities, characteristics. We typically think that design is within architecture. Dualistic thinking gives the many as primordial. But architecture is also within design. It's all how we choose to view what is before us - the one or the many.
buzzcodabuzzcoda
votes
Pretty subjective but my take:
ArchitectureThe overall design of the system including interactions with other systems, hardware requirement, overall component design, and data flow.
DesignThe organization and flow of a component in the overall system. This would also include the component's API for interaction with other components.
ErikE35.3k1414 gold badges122122 silver badges167167 bronze badges
Jesse VogtJesse Vogt9,2031212 gold badges4949 silver badges6767 bronze badges
votes
Software architecture is best used at the system level, when you need to project business and functions identify by higher architecture levels into applications.
For instance, your business is about 'Profit and Loss' for traders, and your main functions involved 'portfolio evaluation' and 'risk computation'.
But when a Software Architect will details his solution, he will realize that:
'portfolio evaluation' can not be just one application. It needs to be refined in manageable projects like:
- GUI
- Launcher
- Dispatcher
- ..
(because the operations involved are so huge they need to be split between several computers, while still being monitored at all times through a common GUI)
a Software design will examine the different applications, their technical relationship and their internal sub-components.
It will produce the specifications needed for the last Architecture layer (the 'Technical Architecture') to work on (in term of technical framework or transversal components), and for the project teams (more oriented on the implementation of the business functions) to begin their respective projects.
It will produce the specifications needed for the last Architecture layer (the 'Technical Architecture') to work on (in term of technical framework or transversal components), and for the project teams (more oriented on the implementation of the business functions) to begin their respective projects.
Community♦
VonCVonC898k330330 gold badges29192919 silver badges35123512 bronze badges
votes
if somebody constructs a ship, then engine, hull, electric-circuits etc. will be his 'architectural elements'. For him, engine-construction will be 'design work'.
If he then delegates the construction of the engine to another team, they will create an 'engine architecture'..
So - it depends on the level of abstraction or detail. One persons' architecture might be anothers' design! Download camera 360.
Gernot StarkeGernot Starke
votes
Architecture are 'the design decisions that are hard to change.'
After working with TDD, which practically means that your design changes all the time, I often found myself struggling with this question. The definition above is extracted from Patterns of Enterprise Application Architecture, By Martin Fowler
It means that the architecture depends on the Language, Framework and the Domain of your system. If your can just extract an interface from your Java Class in 5 minutes it is no longer and architecture decision.
ekerenekeren2,33333 gold badges2424 silver badges5050 bronze badges
vote
Cliff Notes version:
Design: Implementing a solution based on the specifications of the desired product.
Software Design Specification Template
Architecture: The foundation/tools/infrastructure/components that support your design.
This is a pretty broad question that will invoke a lot of responses.
kd7kd726.4k1010 gold badges6565 silver badges9494 bronze badges
vote
Architecture is the resulting collection of design patterns to build a system.
I guess Design is the creativity used to put all this together?
Mark RedmanMark Redman16.9k1717 gold badges8181 silver badges125125 bronze badges
vote
Software design has a longer history while the term software architecture is barely 20 years old. Hence, it is going through growing pains right now.
Software System Design Example For Kids
Academics tend to see Architecture as part of the larger field of software design. Although there is growing recognition that Arch is a field within it's own.
Practitioners tend to see Arch as high-level design decisions that are strategic and can be costly in a project to undo.
The exact line between Arch and design depends on the software domain. For instance, in the domain of Web Applications, the layered architecture is gaining the most popularity currently (Biz Logic Layer, Data Access Layer, etc.) The lower level parts of this Arch are considered design (class diagrams, method signatures, etc.) This would be defined differently in the domains of embedded systems, operating systems, compilers, etc.
LeWoodyLeWoody2,80333 gold badges2020 silver badges2727 bronze badges
vote
Architecture is high level, abstract and logical design whereas software design is low level,detailed and physical design.
imranimran
vote
Also, refer to:http://en.wikipedia.org/wiki/4%2B1_Architectural_View_Model
Durga VaddiDurga Vaddi
vote
I like Roy Thomas Fielding's definition and explanation about what is software architecture in his paper:Architectural Styles and the Design of Network-based Software Architectures
A software architecture is an abstraction of the run-time elements of a software system during some phase of its operation. A system may be composed of many levels of abstraction and many phases of operation, each with its own software architecture.
He emphasizes 'run-time elements' and 'levels of abstraction'.
JackyJacky5,68577 gold badges3030 silver badges3838 bronze badges
vote
There is no definitive answer to this because 'software architecture' and 'software design' have quite a number of definitions and there isn't a canonical definition for either.
A good way of thinking of it is Len Bass, Paul Clements and Rick Kazman's statement that 'all architecture is design but not all design is architecture' [Software Architecture in Practice]. I'm not sure I quite agree with that (because architecture can include other activities) but it captures the essence that architecture is a design activity that deals with the critical subset of design.
My slightly flippant definition (found on the SEI definitions page) is that it's the set of decisions which, if made wrongly, cause your project to get cancelled.
A useful attempt at separating architecture, design and implementation as concepts was done by Amnon Eden and Rick Kazman some years ago in a research paper entitled 'Architecture, Design, Implementation' which can be found here: http://www.sei.cmu.edu/library/assets/ICSE03-1.pdf. Their language is quite abstract but simplistically they say that architecture is design that can be used in many contexts and is meant to be applied across the system, design is (err) design that can be used in many contexts but is applied in a specific part of the system, and implementation is design specific to a context and applied in that context.
So an architectural decision could be a decision to integrate the system via messaging rather than RPC (so it's a general principle that could be applied in many places and is intended to apply to the whole system), a design decision might be to use a master/slave thread structure in the input request handling module of the system (a general principle that could be used anywhere but in this case is just used in one module) and finally, an implementation decision might be to move responsibilities for security from the Request Router to the Request Handler in the Request Manager module (a decision relevant only to that context, used in that context).
I hope this helps!
EoinEoin
12 next
Not the answer you're looking for? Browse other questions tagged architecturedefinition or ask your own question.
Systems design is the process of defining the architecture, modules, interfaces, and data for a system to satisfy specified requirements. Systems design could be seen as the application of systems theory to product development. There is some overlap with the disciplines of systems analysis, systems architecture and systems engineering.[1][2]
- 1Overview
- 3Alternative design methodologies
Overview[edit]
If the broader topic of product development 'blends the perspective of marketing, design, and manufacturing into a single approach to product development,'[3] then design is the act of taking the marketing information and creating the design of the product to be manufactured. Systems design is therefore the process of defining and developing systems to satisfy specified requirements of the user.
Until the 1990s, systems design had a crucial and respected role in the data processing industry. In the 1990s, standardization of hardware and software resulted in the ability to build modular systems. The increasing importance of software running on generic platforms has enhanced the discipline of software engineering.
Architectural design[edit]
The architectural design of a system emphasizes the design of the system architecture that describes the structure, behavior and more views of that system and analysis.
Logical design[edit]
The logical design of a system pertains to an abstract representation of the data flows, inputs and outputs of the system. This is often conducted via modelling, using an over-abstract (and sometimes graphical) model of the actual system. In the context of systems, designs are included. Logical design includes entity-relationship diagrams (ER diagrams).
Physical design[edit]
The physical design relates to the actual input and output processes of the system. This is explained in terms of how data is input into a system, how it is verified/authenticated, how it is processed, and how it is displayed.In physical design, the following requirements about the system are decided.
- Input requirement,
- Output requirements,
- Storage requirements,
- Processing requirements,
- System control and backup or recovery.
Put another way, the physical portion of system design can generally be broken down into three sub-tasks:
- User Interface Design
- Data Design
- Process Design
User Interface Design is concerned with how users add information to the system and with how the system presents information back to them. Data Design is concerned with how the data is represented and stored within the system. Finally, Process Design is concerned with how data moves through the system, and with how and where it is validated, secured and/or transformed as it flows into, through and out of the system. At the end of the system design phase, documentation describing the three sub-tasks is produced and made available for use in the next phase.
Physical design, in this context, does not refer to the tangible physical design of an information system. To use an analogy, a personal computer's physical design involves input via a keyboard, processing within the CPU, and output via a monitor, printer, etc. It would not concern the actual layout of the tangible hardware, which for a PC would be a monitor, CPU, motherboard, hard drive, modems, video/graphics cards, USB slots, etc.It involves a detailed design of a user and a product database structure processor and a control processor. The H/S personal specification is developed for the proposed system.
Related disciplines[edit]
Sample Software Design Document
- Benchmarking – is an effort to evaluate how current systems perform
- Computer programming and debugging in the software world, or detailed design in the consumer, enterprise or commercial world - specifies the final system components.
- Design – designers will produce one or more 'models' of what they see a system eventually looking like, with ideas from the analysis section either used or discarded. A document will be produced with a description of the system, but nothing is specific – they might say 'touchscreen' or 'GUI operating system', but not mention any specific brands;
- Requirements analysis – analyzes the needs of the end users or customers
- System architecture – creates a blueprint for the design with the necessary structure and behavior specifications for the hardware, software, people and data resources. In many cases, multiple architectures are evaluated before one is selected.
- System testing – evaluates the system's actual functionality in relation to expected or intended functionality, including all integration aspects.
Alternative design methodologies[edit]
Rapid application development (RAD)[edit]
Rapid application development (RAD) is a methodology in which a system designer produces prototypes for an end-user. The end-user reviews the prototype, and offers feedback on its suitability. This process is repeated until the end-user is satisfied with the final system.
Joint application design (JAD)[edit]
Joint application design (JAD) is a methodology which evolved from RAD, in which a system designer consults with a group consisting of the following parties:
- Executive sponsor
- System Designer
- Managers of the system
JAD involves a number of stages, in which the group collectively develops an agreed pattern for the design and implementation of the system.
See also[edit]
- Electronic design automation (EDA)
- Electronic system-level (ESL)
- System development life cycle (SDLC)
References[edit]
- ^ This article incorporates public domain material from the General Services Administration document 'Federal Standard 1037C'.
- ^ This article incorporates public domain material from the United States Department of Defense document 'Dictionary of Military and Associated Terms'.
- ^Ulrich & Eppinger (2000). Product Design & Development. Irwin McGraw-Hill. ISBN0-07-229647-X.
Further reading[edit]
- Bentley, Lonnie D., Kevin C. Dittman, and Jeffrey L. Whitten. System analysis and design methods. (1986, 1997, 2004).
- C. West Churchman (1971). The Design of Inquiring Systems: Basic Concepts of Systems and Organization. New York: Basic Books. ISBN0-465-01608-1.
- William Gosling (1962). The design of engineering systems. New York: Wiley.
- Hawryszkiewycz, Igor T.Introduction to system analysis and design. Prentice Hall PTR, 1994.
- Levin, Mark Sh. Modular system design and evaluation. Springer, 2015.
- Maier, Mark W., and Rechtin, Eberhardt (2000). The Art of System Architecting (Second ed.). Boca Raton: CRC Press.CS1 maint: uses authors parameter (link)
- Saltzer, J.H.; et al. (November 1984). 'End-to-End arguments in System Design'(PDF). ACM Transactions on Computer Systems. 2 (4): 277–288. doi:10.1145/357401.357402.
- Ulrich, Karl T.; Eppinger, Steven D. (2000). Product Design and Development (Second ed.). Boston: Irwin McGraw-Hill.
- Whitten, Jeffrey L.; Bentley, Lonnie D.; Dittman, Kevin C. (2004). Fundamentals of system analysis and design methods.
External links[edit]
Look up systems design in Wiktionary, the free dictionary. |
Software System
- Interactive System Design. Course by Chris Johnson, 1993
Retrieved from 'https://en.wikipedia.org/w/index.php?title=Systems_design&oldid=911003406'