-3

I am confused, from what i have read the design phase has nothing to do with how the software looks like and its about how it should be build in the next phase which is the developement phase?

My Understanding of Design phase:

how to the software should be build, like its a blueprint of its mechanism i guess?

I want to know if im wrong or if there is more to it.

REF#1:

Phase 3: Design: In this third phase, the system and software design documents are prepared as per the requirement specification document. This helps define overall system architecture.

This design phase serves as input for the next phase of the model.

There are two kinds of design documents developed in this phase:

High-Level Design (HLD)

Brief description and name of each module An outline about the functionality of every module Interface relationship and dependencies between modules Database tables identified along with their key elements Complete architecture diagrams along with technology details Low-Level Design(LLD)

Functional logic of the modules Database tables, which include type and size Complete detail of the interface Addresses all types of dependency issues Listing of error messages Complete input and outputs for every module

REF#2:

Design and prototyping Once the requirements are understood, software architects and developers can begin to design the software. The design process uses established patterns for application architecture and software development. Architects may use an architecture framework such as TOGAF to compose an application from existing components, promoting reuse and standardization.

Developers use proven Design Patterns to solve algorithmic problems in a consistent way. This phase may also include some rapid prototyping, also known as a spike, to compare solutions to find the best fit. The output of this phase includes:

Design documents that list the patterns and components selected for the project Code produced by spikes, used as a starting point for development

REFRENCES:

https://www.guru99.com/software-development-life-cycle-tutorial.html https://raygun.com/blog/software-development-life-cycle/

2
  • From It Came From Planet Architecture: "Software isn't about methodologies, languages, or even operating systems. It is about working applications."
    – Doc Brown
    Commented Feb 18, 2020 at 19:25
  • Why do you need someone to explain a well defined concept for you? Have you looked online for resources?
    – Martin K
    Commented Feb 18, 2020 at 20:57

2 Answers 2

3

The design phases decides the architecture of the system (including the software architecture). Emphasis goes into identifying components and their interactions, and also on identifying entities and their attributes and relationships. Which is all very abstract.

Remember that the design should come from requirements. By the way, tests come from requirements too, but I digress...

The appearance of the software comes first and foremost from the requirements. It is a requirement that the software must run in a terminal, or window system, or web or mobile... it is a requirement that the interface has such reports and such options. And there will be requirements about usability, and about accessibility.

Afterwards, the appearance will be refined as part of the software design. See also User Experience.

The design process should produce the specification for each component of the software that you can give to programmers to write or generate code. And, of course, some programmer has to write the code that deals with the visual appearance of the software, and thus, there will be design documents for that, to some degree of detail.


Please note that the line between requirement analysis and design gets blurry... Should you put as requirements the position in pixels for a button? Also, please notice that the line between design and implementation gets blurry... Should the designers specify in what is effectively a programming language?

Good software engineering should defer decisions. Work on what you are certain first, and do it in such way that the parts of the software that you are not certain of can change.

Also, in practice, software does not always follow the phases of whatever methodology in the same order. Just consider that it is absurd to pretend that your requirement analysis was perfect, or that your design was perfect. Sometimes problems are discovered and you need to go back. And that is without saying that some methodologies will encourage a different order altogether.

2

The only way you will get a good read on how design affects the final product is to design a product and then build it. Otherwise, this is all just theoretical musings.

I can tell you with a high degree of confidence, however, that the design phase does, in fact, profoundly affect the final product, including "what it looks like." How could it be otherwise? Consider the simple example of a calendar: a mechanism to design your day, week or month. Is not the shape and character of that time period profoundly affected by the calendar choices you make?

To put it another way, the descriptions you have quoted are stated in very general terms. To make any conclusions about how a design affects the final software product, you have to get specific: draw a line between the design element and the specific software feature that the design element embodies. There's always such a line, even if it meanders about a bit.

Finally, if you're expecting something akin to a step-by-step recipe for building an application, you can forget it. Software development doesn't work that way. There are always daily, hourly, minutely decisions to be made. The design process just establishes a conceptual and technical framework from which to work within.

Not the answer you're looking for? Browse other questions tagged or ask your own question.