Page 1 of 1

Iterative Software Design 6 Step process to better programs

#1 KYA  Icon User is offline

  • g++ jameson.cpp -o beverage
  • member icon

Reputation: 3102
  • View blog
  • Posts: 19,142
  • Joined: 14-September 07

Posted 12 April 2008 - 10:59 PM

The one thing that I have noticed over the past few months is how much people want help on various projects, but often do not fully understand the problem. In order to develop a coherent, robust solution to a problem, one must first seek to understand what is actually being asked. For example, the typical airline reservation problem that we have recently seen a lot of. Before diving into code, one should ask themselves:

How can I model the data needed into various available structure?

How does data flow throughout the program?

Do I need to account for idiot users (i.e. robustness)?

So on and so forth...


This planning is what I believe separates the good coders from the great coders. Flowcharting is critical to the success of any major project and I will go over a few of the development methods in this tutorial in the hopes that readers will absorb the knowledge and apply it to their coding methods/practices. (Most modeling revolves around OOP. but a coder can still plan using paper/pencil/graphics).

In order to model a program's flow, one must use a modeling language. Truth be told it really doesn't matter which one you pick, as long as you can accurately describe on paper what you will implement in code. This tutorial will not cover the deep topics that are model languages, but briefly mention them to move onto the iterative design process.

You could use simple triangles to describe relations between objects/data:

Posted Image

Using a method you developed would come with the problem of having to explain your system to anyone who views your flowchart/plan (in this instance not so much, but in larger projects--yes).

The main "language" of design modeling is Unified Modeling Language (UML). The job of UML is to answer questions like the above mentioned ones. Other question include: How should we draw an inheritance relationship? , etc...

Here is the above diagram drawn in UML fashion:

Posted Image


Those are the bare-bones basics of modeling programs. We shall now look at two different development methods: waterfall and iterative development (emphasis on the latter). While both strive to achieve the same goal (software completion) they go about different ways of doing it. For example, the waterfall approach looks something like this:

Posted Image

The client tells the designer what they want. The clients then sign off on it. The designer hands it off to the programmer and then the programmer hands the "finished" product to QA testers who then give the product to the client. This is not necessarily the best method and can lead to disastrous results. Note the direct linearity of this system. It is difficult to go "back" once you reach the next step and this illustrates some of the drawbacks of using this approach.


The iterative development process on the other hands goes through phases. Consider it the "for" loop of design and planning. Each iteration through the cycle produces better software, irons out bugs, etc... Here are the steps involved in iterative design (with a description/examples of their function):

Step 1. Conceptualization -- this is the "vision"

All software starts with a vision. A person has insight into a product that they think would be good to build. Usually it is a single person with this vision. Ever try to have a group of people decide on a single topic?

The very first part of defining the vision is to write it down in a single sentence. This sentence or short paragraph becomes the guiding light of which people will adhere to during the development process.

As with most things, the idea/vision can evolve over time based on various deadlines or technology changers. This mission statement can be adapted as a company goes along building their product, so there is a continuous “goal” or even “dream”. People achieve greater with a goal set in mind to strive towards then just an idea of what to do.

Step 2. Analysis -- the process of understanding the requirements

How does this work? How will we make it work? What exactly is the problem that needs to be solved? All of these are legitimize questions that are answered during this phase. The following are some things to consider:

Use case: A description of how the software will be used
Domain experts: People with expertise in the area of business for which you are creating the product (any area, including games)
Actor: Any person or other system that interacts with the system/program you are developing

Identifying these parts helps answer many of the questions that arrive during software development. Who is using this? How are they doing it, etc… At this point, the creators would create a domain model. This design using any modeling language one wants, maps out how the actors, domain experts, and use cases all interact.

For example: if we were writing software for an ATM machine, we would need to account for bank software interfaces, users, and the bank employees. We would have to handle information such as bank account #’s, PINs, etc… Planning this out ahead of time can greatly assist in managing the project and mapping out exactly what needs to be solved.

Step 3. Design -- creating models of classes, program flow, etc... NO CODING YET!

Analysis focuses on understanding the problem. Design focuses on actually creating a solution for the already determined problem. This is where a design document comes in.

Ever had a problem of trying to keep too much information inside you head to recall from memory? Imagine trying to keep an enormous program inside your head. A design document can be divided into two sections: Class Design and Architectural mechanisms (this is again assuming an OOP design philosophy).

The class design portion can be further divided into two sections. First is the static section, which describes the classes and their various attributes. The second section is the dynamic design, which overviews how the classes interact. Both are equally important since the second cannot be achieved without the first.

Most everyone knows what a class is, but I’ll go over a basic idea of what one is here. A class is a set of functions/variables that can perform a specific purpose. I could create a Class Cat and have it meow() for example. Defining and using classes allows coders to write code in a modular fashion and cuts down on maintenance. i.e. one can go directly to the section or module that is causing problems without breaking other parts of the code hopefully.

The second part of the design document covers Architectural mechanisms. How is data transmitted? What path does it take? These are important questions that are often answered when the class diagrams are drawn. It is worth covering, but sometimes a separate section since data may be coming from outside sources (i.e. not your immediate program). Having a diagram depicting the flow of data is supportive to the class diagram noted above.


Step 4. Implementation -- The actual writing of code

There’s not much to say here. This is everyone’s favorite part. *cough* This is the phase where one sits down and actually hammers out the code. There are always many ways of doing this from an all night code fest to a spaced out week of pleasant coding, but the idea is the same—get what is on the paper into a workable computer program.

Step 5. Testing -- QA to iron out bugs, logic errors, etc...
The nature of software is that it will have bugs. It will have errors. This is unavoidable, even with good design philosophy. No software is perfect, but the idea is to strive towards perfection while maintaining your vision. (Remember the vision? It was way back there).The vision can be lost and needs to be communicated to the team to keep morale and spirit high (this isn’t the army, but the same concept applies here.) There is often a separate branch dedicated to QA testing, since having the same people who wrote the program test it will not often deliver the desired results.

Step 6. Roll out -- getting the finished product to customers

This is the very self explanatory phase of getting the product to the customer. Be it a manufactured disc, or a digitally distributed program, it is the goal to get it into the hands of the consumer. The goal of any business is to make money and not having your product out to be bought is not in the best interest of making money. The iterative method can be repeated with the rephrasing, rehashing, etc… of any portion. The beauty of this method is it’s ability to cycle through and continually update the software while one is adding new features or getting rid of bugs.

It is IMPORTANT to see how much planning and work is done BEFORE ANY code is actually written. This is just a brief overview of each design implementation and can be delved into if one has any interest in it. Note that in iterative development, a team can go through the steps at any time to modify or change their vision or implementation of that vision. It is controversy over what exactly happens in each step of the iterative cycle. The truth is: it doesn't really matter! As long as you and your team adhere to a cycle that gets better each time around, it really doesn't matter if you add extra steps to the analysis or implementation phase. To be an effective programmer, you must know how to structure them. By planning and designing before you start coding, you will build better, more effective programs (this applies in any language).

Hopefully this was somewhat enlightening and I encourage both members and guests of </DIC> to plan out code before sitting down to grind it out. It helps the process and relives headaches (as well as bugs!). Happy coding!


(Mods use this revised edition if you see more then one submitted).

Is This A Good Question/Topic? 3
  • +

Replies To: Iterative Software Design

#2 EZESPMAN  Icon User is offline

  • New D.I.C Head

Reputation: 1
  • View blog
  • Posts: 4
  • Joined: 16-May 08

Posted 05 June 2008 - 02:01 PM

Good article implementing software design before writing codes, much better explained than most books, that I have been studying, some don't even has this type of software analysis. I will start using the software Desing approach before implementing any codes. Thanks.
Was This Post Helpful? 0
  • +
  • -

#3 KYA  Icon User is offline

  • g++ jameson.cpp -o beverage
  • member icon

Reputation: 3102
  • View blog
  • Posts: 19,142
  • Joined: 14-September 07

Posted 05 June 2008 - 04:06 PM

I'm glad it helped. :)
Was This Post Helpful? 0
  • +
  • -

#4 mensahero  Icon User is offline

  • I Desire...
  • member icon

Reputation: 17
  • View blog
  • Posts: 678
  • Joined: 26-May 08

Posted 09 June 2008 - 11:02 PM

This should be taught in school.. lmao..

This solved my greatest problem.. I'm always very eager to start coding immediately without any IDEA on what I want to do.. well it is good for small apps but when it gets bigger and code become more develop.. I end up recoding it because I got the full vision of what I want to accomplish.. lmao.. such a waste of time..

very very helpful indeed.. :blink:
Was This Post Helpful? 0
  • +
  • -

#5 rissvann  Icon User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 11
  • Joined: 19-September 06

Posted 20 December 2008 - 03:40 PM

This is great tutorial and i really appreciated your efforts to describe it clearly. But i noticed that people, including me get these ideas easily but when it comes to develop a real world software/application, they got stuck or failed and lost their ways.

So here is my request, if you teach us how to develop/build any real-world software/application, then we'll learn lot of things and as well as improve ourselves to build other applications.

Here are my suggestions to work on:

1. Airline Reservation System or
2. CRM or
3. Hotel Management System or
4. Student Application System or
5. Pharmacy Management System or
6. Any other small size software
Was This Post Helpful? 0
  • +
  • -

#6 sparkart  Icon User is offline

  • D.I.C Addict
  • member icon

Reputation: 113
  • View blog
  • Posts: 688
  • Joined: 16-February 09

Posted 11 October 2010 - 09:04 AM

I don't see how this is different from the waterfall model.
They both summarize to Plan, Implement, Test.
Was This Post Helpful? 0
  • +
  • -

Page 1 of 1