Talk:Software design/Archives/2013

Questions remaining after rewriting the article
I've rewritten this article for clarity and consistency, but there are a few things that made no sense at all. I'd be grateful if someone could explain the meaning of these sentences: -- Sakurambo 桜ん坊  17:57, 5 December 2006 (UTC)
 * 1) "The sponsor and all stakeholders should sign off each deliverable and stage as appropriate."
 * 2) "Document the interface with people (screens, reports) and external components (software and hardware)."
 * 3) "All stageholders should be represented in the testing phase."

The Software design article should be merged here

 * Copied from Talk:Software development process. Reference to here mean Software development process page.

I can see that a lot of work has been done here, but we still have an article called software design which today contains only another enumeration of software development activities. Thus is appears to be both incorrect (in that it introduces many development activities that extend far beyond what most people would consider to be design) and redundant (in that this article already exists to introduce all the activities of software development). Therefore I have suggested it be merged here. I would consider doing the work myself, but I am already working on a rewrite of Web development and Web design articles. Chris Loosley 18:00, 27 December 2006 (UTC)


 * Oppose Merge: I agree that the page introduces many development activities that extend far beyond what most people would consider to be design. Design is only part of the development process, unless you are designing the process. The term was originally directed at software engineering, which is just a more rigorous form of design with more emphasis on the processing engine and efficient code than creativity or content. I originally redirected that term to user experience, because that is the only part of the software that a user need be concerned with aside from the price. But instead SteveMerrick made a separate page, listing "design" as a subset of the "design", contrary to set theory.


 * This article is too broad to say enough about user experience considerations. The main focus of the software design should be what the user gets out of it. Everything else is either business admin, production engineering, routine production, testing, or delivery. All of the above, including design, falls under the category of development. The software design page is now just a lesser version of this page. There's nothing there that isn't covered in this page. I suggest it be deleted altogether and the "software design" term be redirected to "user experience" or user experience design. Unless someone want's to rename this page "software design process", we shouldn't let such an important topic as user experience get buried in all the other development concerns. That would be as bad as merging the software development process article into a product development article. Oicumayberight 22:38, 27 December 2006 (UTC)


 * I don't really follow your arguments related to user experience, since the only reference to user experience on the software design page is in the sentence Software is generally written ... to provide users with an entertaining experience ... in the introduction. You also say: The term was originally directed at software engineering. Which term -- Software design? Chris Loosley 23:29, 27 December 2006 (UTC)


 * Yes. The term "Software design" was directed to "software engineering". Oicumayberight 00:38, 28 December 2006 (UTC)


 * You say that: The software design page is now just a lesser version of this page. There's nothing there that isn't covered in this page. I agree completely -- that was why I suggested merging it. You also say I suggest it be deleted altogether and the "software design" term be redirected to "user experience" or user experience design. Doesn't that amount to merging the contents of software design here? If so, why are you opposing the merge? Chris Loosley 23:29, 27 December 2006 (UTC)


 * It's not technically a merge if the page is deleted. It is technically a merge if the term redirects here. I'm opposed to redirecting "software design" to here. Oicumayberight 00:38, 28 December 2006 (UTC)


 * Software design is a subset of software development, not (as you pointed out) a subset of "design". So we should not have a software design page that describes the entire development process. If you want to see a software design page that has some special focus on UX aspects, I encourage you to write something about that. But that does not lessen the need to remove existing content that is NOT about software design. Chris Loosley 23:29, 27 December 2006 (UTC)


 * I think we are in agreement here. Content that is NOT about software design should not be part of a software design article. There should be a separate article for software design with emphasis on UX. I'm not enough of an expert to write the article. I only redirected it to user experience as a temporary solution with the hope that someone more knowledgeable would go into more specifics with a designated article. I just don't like the idea of "software design" redirecting here since there isn't much said about UX design in this article (not that there should be). If the term doesn't direct to the UX or UX design page, then it should be directed to a disambiguation page at least. Oicumayberight 00:38, 28 December 2006 (UTC)


 * OK. We agree. Someone should delete most of what's in the software design article today because it's not about software design. But we shouldn't delete the topic itself, and eventually, this article should include a link to software design. But first, someone should write a real article about software design, which includes coverage of the UX aspects. It seems that that editor just won't be us, at least not now. But I won't delete the "merge" templates yet, because at least they highlight the problem and point people here. So if anyone reading this discussion feels qualified, please work on this cleanup. Chris Loosley 06:12, 28 December 2006 (UTC)

The following are posts since copy from Talk:Software development process:


 * I'd appreciate your feedback on the general structure I'm proposing in my rewrite of the Web development and Web design articles, where we have the problem of having all the current content in Web design and very little in Web development.
 * -- I'm first defining an overall framework of development "activities" (I also use the term "phases") in the Web development article.
 * -- Next I'm organizing the Web design article accordingly, but it will discuss only Web design aspects as they relate to each phase.
 * -- Next I'm going to shift existing content from Web design into Web development, where appropriate, and edit for continuity
 * -- Finally, in the Web development article I will include only short references to any Web design activities, pointing to the Web design article for more details.
 * Do you forsee any problems with this approach? If not so, a parallel approach could work for the Software development and Software design articles (not that I am volunteering :).


 * I'd also particularly appreciate your review of the new material I just drafted in the "Web Design" section of the Web development rewrite. Chris Loosley 23:30, 29 December 2006 (UTC)


 * I think this is a good approach. I've briefly reviewed the web development draft page and liked what I read so far, which is why I commended your efforts on your talk page. My main concern is that anyone reading gets the full story or the full details of whatever part of software design/development or web design/development they are interested in, without having to dig through lengthy articles and subjects they are not concerned with. This may mean fewer smaller articles all linked under the umbrella of web development and software development. The parts of web development and software development that don't require technical skills in order to contribute to them should also not require technical knowledge in order to read about them.


 * I understand, and that does sound like a reasonable objective. However, I don't think you can ever be really good at design (in any engineering context) without understanding a lot about the capabilities and constraints of the technology you are designing for. That limits the depth of a non-technical explanation. But I'll try to follow your guideline and see what happens. Chris Loosley 06:15, 30 December 2006 (UTC)


 * Some of the best designers in the world don't know a lick of technology. They are the ones who inspire people to find ways of doing what was once thought to be impossible because they didn't know it was impossible. It's the Gene Roddenberry effect of designing but not engineering the future. It's always a balancing act between creative and analytical talent. It's the lack of constraints that allow us to imagine things that challenge our analytical minds to engineer the impossible. It is helpful if one can design within constraints. It's also helpful if one can think outside the box of constraints. The goal is to have collaboration between the technical and non-technical in a symbiotic relationship rather than have individuals spread themselves thin trying to know everything. Even if one knows everything, it still makes it difficult to switch gears when moving between creativity and technical analysis. The design thinking article touches on this, although that article needs a lot of work. Oicumayberight 10:32, 30 December 2006 (UTC)


 * There also needs to be a clear distinction made between an internet application, web application and web pages. Applications that may be used offline or outside of the web should be clearly understood as simply software or stand-alone applications if a browser is not required for access. I'm not sure how much that needs to be emphasized in web development or software development, but I'm certain the distinction needs mention on any page where it applies. Oicumayberight 00:42, 30 December 2006 (UTC)


 * I agree that it would be good to make such distinctions, and again, I will do my best. But the problem one runs into is in attempting to define the boundaries of the term "design". The more I think about this the more it seems that there exists a continuum of applications, with no clear dividing line between those involving some Web design (and therefore, by extension, some Web development, since design is considered to be a development activity) and those involving no Web design. Is software configuration a design activity? When you configure a blog using an application like Blogger, or create your own MySpace page, are you doing design? When you select configuration options for your email software, are you doing design? Where is the dividing line? (Is this discussion getting too philosphical?!) Chris Loosley 06:15, 30 December 2006 (UTC)


 * I think it's OK to get philosophical in the talk page. Much of design has it's roots in philosophy anyway. As for the boundaries of design, there are none. Design is problem solving of any sort. From there it just gets subdivided into the type of design. In computing, there is a clear distinction between designing for the user and designing for the machine. Anything designed for the user is independent of any one particular technology over time. In other words, the goals (problems) for user centered design (problem-solving) don't change as often as the technology changes for machine centered design (engineering).


 * I know that doesn't make clear boundaries between everything you mentioned, but it's something to keep in mind. Reality is never static. Things will change in the future. What is considered multidisciplinary now may be seen as one discipline a decade from now. For all we know, something may eventually make the web obsolete or at least it's terminology. Programing may be obsolete if programs write themselves. Ubiquitous computing is on the horizon. A future where most of us only need to know how to speak in order to get what we want out of computers may come sooner than we expect.


 * For now we just have to go with the flow of what terms and areas of expertise are widely accepted as being part of the same discipline. I wouldn't call configuring software "software design", but it may be called "system design" if only on a micro scale. I wouldn't call a MySpace page a "web design", but it may be called a very simplistic form of "communication design". To sum it up, every bit of problem-solving on any level is a form of design, just maybe not as broad of focus as web design or software design. Oicumayberight 10:32, 30 December 2006 (UTC)


 * By the way, while we're discussing design, the particular paragraph I would really like your opinion about is the Draft of new material here. Chris Loosley 06:15, 30 December 2006 (UTC)


 * I like the general direction it's going in. I will read it closer over the next few days and scan for changes periodically. I think you have the right idea about how the page should be structured. I'm a pretty critical person too, so I wouldn't pull your leg if I thought something was inaccurate or incomplete. Oicumayberight 10:32, 30 December 2006 (UTC)


 * Oppose Merge: The term design document may have its strongest presence in the software industry, but it is beginning to be used more widely. As the usage of this term changes (and usage always does), a separate entry makes it possible to follow this process meaningfully. One other note, if design document is not widely used, another term currently defined in Wikipedia as being used for software engineering, vision document, certainly is. Even creative brief in Wikipedia seems bent towards software engineering, and it in standard usage in graphic design, to name one discipline. GoodNobody 16:58, 11 May 2007 (UTC)

Copy-paste registration
In this edit the textblock was copy-paste (and rearranged) from here. -- Mdd (talk) 09:38, 20 October 2009 (UTC)

"Stages and Phases of Design"
This section reads like Gibberish. Does any 'value' in this section save it from the fact that erasing it would make the article less confusing? - Xgkkp 188.220.93.96 (talk) 23:55, 7 February 2010 (UTC)

Alteranative definition
Should this article mention alternative definitions of software desing? E.g. “Software design” describes all appearance and behaviors visible to a user... from http://worrydream.com/MagicInk/? 2 april boy talk 13:04, 11 March 2012 (UTC)
 * Yes, but not this one. The article sucks anyway. Full of buzzwords good for a dozen of resumes, but says nothing useful for a person not familiar with the topic. So, your suggesiton to actually follow wikipedia rules and cite the sources (and read them before citing) makes a good sense, even if being a bit off mark. Staszek Lem (talk) 01:43, 8 May 2012 (UTC)
 * P.S. if the authors of the article don't believe that the article is B.S., just tell me how "a process of problem solving and planning for a software solution" (from the definition) may be a "text describing a planned sequence of events" (from an "explanation"). Staszek Lem (talk) 01:43, 8 May 2012 (UTC)

After a thorough read of the article I agree that it has problems related to buzz-words, lack of citations and a general bias toward an idealized engineering process that does not reflect the realities of software development. I rewrote the introduction to clarify the relationship between this article and the software development article, added more precise defintions and academic citations. If these changes get positive (or no) reaction over the next few days I'll see about improving more of the article. Paul Ralph (Lancaster University) (talk) 11:35, 16 March 2013 (UTC)