Home arrow Practices arrow Page 7 - The Art Of Software Development (part 2): Designing For Simplicity

Different Strokes, Different Folks - Practices

In the first part of this article, you got a crash course inrequirements analysis. Now that you've figured out what your customerneeds, it's time to design it - easily the most challenging and creativephase of the project cycle. Find out more, inside.

TABLE OF CONTENTS:
  1. The Art Of Software Development (part 2): Designing For Simplicity
  2. The Best Laid Plans...
  3. Building Blocks
  4. Drawing Class
  5. All Used Up
  6. Testing Times
  7. Different Strokes, Different Folks
By: Vikram Vaswani, (c) Melonfire
Rating: starstarstarstarstar / 4
September 03, 2002

print this article
SEARCH DEV SHED

TOOLS YOU CAN USE

advertisement
And that's about it. At this point, you, the developer, have enoughinformation to actually get down to writing the code, secure in theknowledge that you've successfully reduced the scope for changes ordeviations. This does not mean that changes or deviations will notoccur; however, as you'll see in the subsequent parts of this tutorial,you can reduce their impact on the overall development plan by managingthem carefully.

After reading the material above, you might be tempted to think thatthere's way too much paperwork involved in the pre-implementation phaseof a project. You're right - there is - but much of it is aimed atprotecting both you and your customer from creeping changes, andensuring that the final product is delivered in an efficient andcost-effective manner.

It should be clearly understood, also, that the processes outlined abovemay not work for every Web project. For smaller projects or teams, itmay not be practical to develop extensive documentation in the earlystages of pitching a project. However, an effort should be made toensure that requirements are formally captured and signed off on priorto development, and that there exists clear communication on thedeliverables between customer and vendor, so as to avoid problems at alater stage. Time should also be taken to have a clear process ofmanaging change requests, so that the overall development of the programis not unduly affected.

If you're interested in improving your design skills, here are a fewarticles you might find interesting:

The principles of good design, athttp://www.w3.org/DesignIssues/Principles.html

Jakob Nielsen's usability Web site, at http://www.useit.com/

Principles of user interface design, athttp://www.asktog.com/basics/firstPrinciples.html

An article on simplicity in software design, athttp://construx.com/stevemcc/ieeesoftware/bp06.htm

Quotes on simplicity in software design, athttp://www.vanderburg.org/soft-quotes.html

I hope you enjoyed this article, and that it gave you some insights andideas on how to manage your software development projects moreefficiently. In the next part of this article, I'll be spending time onthe third part of the development cycle - actual code development - andoffering some general tips and tricks on how you can simplify andstreamline the process to account for changes at a later date. See youthen!

Note: Examples are illustrative only, and are not meant for a productionenvironment. Melonfire provides no warranties or support for the sourcecode described in this article. YMMV!

 
 
>>> More Practices Articles          >>> More By Vikram Vaswani, (c) Melonfire
 

blog comments powered by Disqus
escort Bursa Bursa escort Antalya eskort
   

PRACTICES ARTICLES

- Calculating Development Project Costs
- More Techniques for Finding Things
- Finding Things
- Finishing the System`s Outlines
- The System in So Many Words
- Basic Data Types and Calculations
- What`s the Address? Pointers
- Design with ArgoUML
- Pragmatic Guidelines: Diagrams That Work
- Five-Step UML: OOAD for Short Attention Span...
- Five-Step UML: OOAD for Short Attention Span...
- Introducing UML: Object-Oriented Analysis an...
- Class and Object Diagrams
- Class Relationships
- Classes

Developer Shed Affiliates

 


Dev Shed Tutorial Topics: