Design methodologies lay down a set of rules programmers follow when designing an application. Below, are 5 main methodologies that describe how they come in to designing an application and how they may or may not use them in the course of a project.
RAD
RAD (Rapid Application Development) is about building programs quickly so they are operational as soon as possible.
There are 6 core ideas that define RAD design, and these are called prototyping, iterative development, time boxing, team members, management approach, and RAD tools
Prototyping is all about the quick production of a feature-light application that fills the basic requirements of the project. The aim of this stage is to create a functional application to show you client how the final application would work. This allows them to spot potential problems early and to further refine the projects requirements early on.
The second stage of development is 'Iterative Development'. In this stage the programming team takes there prototype program and adds to its complexity and make sure it properly fills all design criteria for the final system. After each stage of quick upgrades to the program, it is sent to the client for review. the next version of the program is then started, all the changes being based on the comments made by the client.
The third idea in RAD is 'Time Boxing'. This is basically strategically managing when new features are implemented. No feature should be implemented before it is needed; this keeps each Iterative Development to the shortest time possible.
RAD design favors small experienced teams. Large teams are harder to manage, which in turn slows down a programs development cycle. the more experienced and motivated team members are, the quicker a program can be developed.
RAD recommends that the management approach for a project should be aimed at keeping the development cycles as short as possible. All deadlines should be enforced and any potential problems with reaching them should be sorted out quickly. Management should try and keep there team as motivated as possible.
Development speed is worth more than new tools. When using the RAD methodology, the cost of new tools is trivial if they will speed up the development cycle so the newest technologies should be available to the programmers.
The two major advantages of this methodology are development speed and quality. Because of the nature of the process the final program is made quickly and has all needed features.
Disadvantages include lack of features (As only the most needed feature ever get implemented) and a very specialized code base making code reusability hard.
Top Down & Bottom Up
In the Top Down design methodology, a programmer starts by looking at the whole problem, and then gradually breaks it down in to smaller problems (functional decomposition). An example of this would be designing the UI for a program and then designing how each part of that UI works.
Bottom up design is the complete opposite. A programmer starts with the code to complete each individual part of the problem and builds that up in to a complete application.
Some advantages of top down design are:
α All aspects of the program are know before programming starts
α Programmers are focused on the task, because they know every aspect of the program.
α The code should be clean and easy to understand, because it all has purpose.
Disadvantages include:
α Testing is hard until near the end of the project, because no code is written until it is all properly designed.
α Any mistakes made early on in the development cycle can be hard to fix.
Some advantages of bottom up design include:
α The code can be properly tested at any sage in the development cycle.
α Design flaws can be easily spotted and fixed. Because all design work is done through the code.
Some disadvantages of bottom up design are:
α Programmers may come across many problems during development because they don’t have a structured well though out design plan.
α It can be easy to deviate from the task during development.
α The code may be messy, because the task was misunderstood early ion development and code has to be changed a lot.
Data Driven
The goal of Data Driven Design is to design a program that’s function can be change not by editing the programs code, but by changing the data fed in to the program. This methodology is not suited to our application, but more for applications that use large databases or read a lot of data from script files.
Event driven
Event driven design focuses on the idea of events (surprisingly) every action a program can perform is an event, and the program waits for criteria to be met before. For example, if a program displays a windows form, every button on the form would have an event attached to them. Each even would call a different piece of code. This methodology works very well with languages like visual basic, which are event driven by nature.
The methodologies I will be applying to the application while designing it are Event driven and top down design. These two methodologies allow me to design the program to be user friendly, have a good understanding of how each part of the program will work and designed in a way that work well with my chosen development language.
Data structures
 |
Copyright Open Source Institute, 2006 
