Talk:Top-down and bottom-up design
From Wikipedia, the free encyclopedia
Contents |
[edit] Bottom-up-design discussion
I'd like to see mention of beginning the design of a system starting with the most technically challenging pieces and working down to the grunt work (the stuff that is "in the bag"). Many projects fail to take on the most challenging work and, after a lot of the easy stuff is done, come to a brick wall which cannot be overcome due to technical difficulties. That causes project failure,at last
[edit] Not just software
I wonder if we can rewrite this to make it non-software specific, and then move the software example into its own subparagraph. I think the concepts are useful in any sort of design, from game design to any other sort, no? For example, I randomly came here from International_auxiliary_language.--Sonjaaa 22:31, Nov 26, 2004 (UTC)
-
- I agree we should rewrite this article to make it less specific. Top-down and bottom-up approches are actually very important concepts in nanotechnology and microelectronics too. Guillom 07:56, 23 August 2005 (UTC)
-
- I agree too, but unlike Guillom, I think the issue is much more general than in microelectronics and nanotechnolgy - top-down design concerns engineering design in general, including mechanical, aeronautical, electrical, electronic, chemical engineering. Sangwine 15:19, 8 October 2006 (UTC)
[edit] Merge from 'Top-down programming' ?
These two articles were apparently written independently by authors who were unaware of each other's efforts. Chris the speller 18:26, 31 October 2005 (UTC)
I dont think that the two pages should be merged. top down and bottom up where pioneared by IBM for software design, These design techinques have been developed for software other areas may have taken them on but they still remain software design techinques at heart .
-
- I disagree. See the section above about 'Not just software' - top-down design probably existed before software. It is an engineering design methodology, and software just happens to be one branch of engineering that uses it. Sangwine 15:21, 8 October 2006 (UTC)
Well, since the starting line of the article says it's about information processing, I believe programming can rightly take its place here. Moreover, programming is becoming more universal.
- 1. Why do you know?
- 2. Why do you care?
- 3. Who do you think you are?
- 4. If you thought they should be merged why did you not do it yourself? —The preceding unsigned comment was added by 212.219.57.50 (talk • contribs).
-
- WP:NPA Your first three questions are invalid. On the fourth - while I didn't make the comment you're responding too, it's fairly common for people to ask about major merges and similar edits - a lot of information would be moving, some might be lost as duplicated, and especially it might be considered that any pair of articles that are merging might be unsuitable for merging for some reason. Compare in the same field the business and development articles for the Scrum process - while similar (and someone suggested a merge), they are not close enough for a merge. Someone going ahead and doing it themself would then be doing something that has now been discussed and by consensus resolved as two different things. That's a good reason not to just go ahead and do it. --Firien § 12:29, 30 August 2006 (UTC)
[edit] Examples of bottom-up programming
Right now, i cannot undertand how bottum-up designing is supposed to work. You always start a project with a rough plan which then is described more precisely. With bottom-up design, as it seems to me right now, you start developing something concrete, but actually don't know yet for what to use it ("oh, we just coded a program that can encode music very efficently, but don't know the heck where to use it"). --Abdull 14:03, 24 February 2006 (UTC)
- Pure bottom-up design would probably be as you say ("oh, we just coded a program that can encode music very efficently, but don't know the heck where to use it"). You're correct that such a thing wouldn't work. A rough top-down plan would of course be drawn first. However, in pure top-down design it would be further refined smaller and smaller, whereas in a bottom-up plan you would jump to the bottom, solving small problems first and linking them together to solve bigger ones. For example, you'd decide that you want to make an game. From a top-down approach you'd decide exactly how you want the game to turn out, then break it down into smaller and smaller projects in order to realize that initial vision. With a bottom-up approach you might start working on a combat system, and you might start working on a story, and you might start working on the graphics, and then start fitting the pieces together and see what kind of game you're ending up with. TomTheHand 18:45, 24 February 2006 (UTC)
- Hi TomTheHand, thank you for your quick reply! Your example really helped me getting an idea on how bottom-up design is supposed to work. Bye, --Abdull 00:32, 26 February 2006 (UTC)
- In software and systems design, top down design is really intended for functional decomposition, not for the low level design. In reality I'm not sure that a pure top-down or bottom-up process exists in practice, or was ever intended as anything more than a concept of one extreme or the other. Requirements and design (and testing for that matter) always seem to push back on each other to some extent. That said, bottom-up design is not a model for designing something new or innovative. It is a reality however, due to the ecomony of common parts, reuse of code, the expertise of a detailed designer, and "constraints" (usually the word that someone uses when they ask for bottom-up design). Example: General Motors likes to manufacture a car (minus the powertrain) for 4 years to justify the high tooling expenses. They also like the powertrain to stay relatively stable for 4 years. But the powertrain is introduced into a car design that is two years old, and the new car is designed for a powertrain that is 2 years old. There are also some revolutionary designs, but many car platforms are evolutionary to avoid a complete shake up. So when the top-down guy is writing the requirements for the new chassis, he must take into account the powertrain that already exists. Likewise for the top-down guy that writes the requirements later for the powertrain. Bottom-up design results from a realistic compromise that always seems to creep into a top-down approach. 68.61.94.26 05:53, 9 November 2006 (UTC)
Seperate article for top down and bottom up development of countries etc. in geography needed.
[edit] What about nanotechnology?
This terminology is also used in nanotechnolgy as can be seen from this wikibook extract:
Top-down and bottom-up approaches
Top-down refers to the traditional workshop or microfabrication method where tools are used to cut, mill and shape materials into the desired shape and order. Bottom-up refers to methods where devices 'create themselves' by selfassembly. Chemical synthesis is a good example. Bottom-up should broadly speaking be able to produce devices in parallel and much cheaper than top-down methods, but getting control over the methods is difficult when things become larger and more bulky than what is normally made by chemical synthesis. Of course nature has had time to evolve and optimize self-assembly processes that can do wonders.
Shouldn't this be described as well?Hauberg 14:06, 23 October 2006 (UTC)
- Nice find. I integrated some of this text into a new Nanotech section. Antony-22 21:47, 19 November 2006 (UTC)
[edit] "Top-down" and "bottom-up" disambiguation pages
Is there a reason "top-down" redirects here while "bottom-up" goes straight to the disambiguation page? Shouldn't they be made to be symmetrical? Antony-22 15:53, 21 November 2006 (UTC)
