How much time should you spend on design?

[Banfa]

I was mildly concerned when I saw else where on the forum on of our experts express the opinion that software design saw not required and their prefered design method of development was to just start coding and just let the program evolve the features required.

My concern is no so much the method, everyone uses this design method at sometime (I recon) even if it is just for a test bed investigating the method to perform some operation. However the impression I got was this was the only design method this person used.

There are a lot of design methodologies out there but just jumping in there and writing the code is probably right at the bottom of my list of ways to create a comercial piece of software (and at the top of my list of writing test beds with a lifetime of < 1 month or so).

By now you probably want to know what amazing design methodology I use. Well I can't name one (I have never been good at remembering useless information), however some of the things I do are

• Decide and record how various parts of the system are going to communicate with each other taking particular note of timing and avoidance of race conditions.
• Either record the standard of the protocol to be used in communication or write a protocol document
• Record the class structure if the project uses OOP
• Decide how program data will be store
• Record the data(or table) structures used for data storeage
• Design key classes or modules in detail so they are ready to be used when I start on the main program design.
• Write out any state machines that will be used as art of the program

And this is where I start. I often go back and alter bits as development continues, new requirements come to light or deficiencies of other systems are discovered and have to be programmed round,

[MMcCarthy]

I there is one thing I've learned the hard way it's DESIGN, DESIGN, DESIGN. Particularly when it comes to databases.

If you try to create a database without locking down the design and structure of the tables you are going to need for the database you are only creating work for yourself later on. Sometimes a lot of work. In structured and OO languages you can sometimes imploy the adhoc method. It's not the most efficient but can sometimes based on time contraints the most convenient method but I would never recommend doing it with databases.

A database design starts with the table structure and every query, form and report is dependent on this. Even the changing of a field name in a table can cause you to make numerous changes to queries, forms, reports and VBA code. The first rule of database design is to DESIGN. Work out your user requirements based on the reports they require from the database and the data entry they need to put in and reverse engineer the data that is required to achieve this. Then normalise the data so that you achieve a good table design structure that can not only deliver on these requirements but is adaptable to future requirements and enhancements.

So to answer the question in the title ...

On an average project I would spend 2 weeks on requirements gathering and structural design, 4/5 weeks on designing the forms and reports and system testing, 1 week on documentation and 1/2 weeks on user testing and debugging.

Assuming a 10 week project that is 1 fifth of the project time spent on design.

Mary

[nico5038]

It's obvious you're designing from the OO perspective and in such a case I would start with describing Use Cases as first step to discover the users needs.

Based on that the objectmodel, methods and properties will evolve.

Personally I'm more "traditiona l" in design when developing Access databases. I start with collecting the needed output (reports and forms) and by tracing the root attributes I start grouping them into a user's datamodel.
(Not normalized, but with the definitions a user understands.)
That rude model is used by me to make a normalized datamodel and in the process I verify (using the user model) the definitions to get a sound normalized datamodel.

Finally I start with creating forms around the found "basic" tables and use the Object/Action principle. (I show a main form with all occurrences so the user can filter the set (s)he needs) and add the Action buttons like [Add], [Update], [Delete], [Print], etc.
That will cover some 60/70% of the needs and give me a model to tune with the user and add the additional requirements. (Kind of prototyping)

Finally I finish the database by adding the last specific functions and creating a userguide.

The design is more or less continous during the whole process and will take some 25 %, the database design and form/reports/etc. will take some 50% and the last 25% is for testing and documentation (userguide).

Nic;o)

[MMcCarthy]

Finally I start with creating forms around the found "basic" tables and use the Object/Action principle. (I show a main form with all occurrences so the user can filter the set (s)he needs) and add the Action buttons like [Add], [Update], [Delete], [Print], etc.
That will cover some 60/70% of the needs and give me a model to tune with the user and add the additional requirements. (Kind of prototyping)

Interesting approach. I would find this time consuming as particularly with multi user systems they often ask for things they don't really need and everybody wants their own little special features. I find that requirements gathering and working out with users and management what they actually need during design phase saves an awful lot of time.

[Banfa]

It's obvious you're designing from the OO perspective and in such a case I would start with describing Use Cases as first step to discover the users needs.

A reasonable thing to do but in my case not possible due to the lack of users (although I realise that use cases do not necessarily require users).

I am basically working on a service that when complete will enable a (yet to be designed) web-interface to communicate with the system and perform various activities (which could be seen as use cases). This is complecated by the orignators behind the system idea not actually making a decision about what they want it to do, trying to sell the "we can make it do whatever you want" idea which has caused this 3 year old project to have never never reach a condition where it was actually saleable, and the to be not real specification of exactly what activities and information will need to be exchanged.

I have had to decided what operations I will make available through the service.

Same with the database, you talk about working out what queries, forms and reports will be needed (BTW surely a report is just a query with the data formated for display and a form just a data entry interface backed by another query?) but our database is used with no direct access by any user. We only have queries, no forms or reports.

I think my point is that you have to be flexible you can not force any given design methodology because they wont suit all cases.

Something else that I have noticed from working around my office (where they do use Use Cases a lot) is that everything seems to be done the same way, and because of that everything ends up working in similar ways.

This doesn't necessarily produce the best results for all systems and in a few cases is a positive hinderance.

[nico5038]

The main objective of a method is the fact that you get a number of steps that can be repeated and all lessons learned can be used to prevent to make the same mistake(s) twice :-)

I've been taught to use the "Waterfall" model when I started programming in the seventies. This approach (Volmac Structured Desing/Yourdon) was based on the data. (The other approach is to base the design on the processes and use trigger files for exchanging the data)
This is however a "slow" method and afterwards I've been training people to use evolutionary design based on 4GL "languages" to speedup the process.
This requires to record the metadata in a repository and to generate (or interprit) that data to build a system. Thus faster results can be reached.

The OO approach is new to me. I've had the theory, but never put it into practise.

Remains the fact that the Dutch proverb "Think before acting" is always applicable to software design and too many projects fail because people start without having an overall architecture and without stating the system boundaries.
You've experienced the trouble it gives I see.

Nic;o)

[Killer42]

I was mildly concerned when I saw elsewhere on the forum one of our experts express the opinion that software design was not required and their prefered method of development was to just start coding and just let the program evolve the features required.

That may well be me you're talking about. Hm.. perhaps not, though. I do tend to just jump in and code, but I would never suggest that it's the right way to work. It's simply what I prefer, being a self-taught BASIC spaghetti-coder from way back, and a born tinkerer. Almost all of my VB work has been solely for my own use, or minor utilities for use at work.

For any "real" system I would not touch it until the design work has been done, and then I'd be working from specs. What can I say? I'm not a designer.

I do know that the really big government computer project I worked on in the early 90's was very successful because so much work went into the analysis and design. At the time, big projects at other departments (and outside government) were producing a rash of disasters all over the place.

(P.S. That's why I'm something of a technical expert at work - I stick to what I'm good at.)

[r035198x]

I will say it really depends on the size of the system.
For a large system that takes 1 year plus (like the one I'm working on now), you want to really have a go at designing the components of the system well before you go to the compiler. The usecases approach is becoming more and more popular these days and I must say it really simplifies the job for every one. Especially through the Joint Application Development approach (JAD). It seems the managers have now agreed that they do not trust programmers. So what happens is you take some programmers and managers from various departments which will be using the software and have them come up with usecases for the system. The programmer will get an understanding of the business logic while the business people will be able to specify exactly how they want operations to be done the system. All that's left for the programmer to design are the tables for the database. I think this is the way things should be like. Programmers should not design the system flow. It requires knowledge of that application area to be correct and efficient. Also produces very good specifications for the programmer.

[Ganon11]

I think it really depends on the work you are doing.

For official business applications, it's important to understand the interactions between every system, the design, and the components well before the actual coding of the program. If you use the gung-ho approach and launch directly into coding, you're sure to run into some problems before long.

I haven't had any professional experience, but I know in two separate projects I worked on recently I had to do a lot of rethinking because I foolishly started coding without any planning. One, as a few of the senior members/mods know, is Chess. I started writing code for each class before fully understanding how each class would interact, which classes needed which methods, how many classes to use, etc. I ended up spending a lot more time reading code and deciding how to fix it than I would have diagramming the program.

On the other hand, I think you can go overboard. Last year, as I was studying for the AP Computer Science exam, we worked on a demonstration program called the Marine Biology Case Study. The code was coupled with a PDF file explaining every step that was taken in this project. There was endless black box testing, writing, diagramming, and I honestly think it was overboard. In addition, as a High School student I mostly write simple programs - something like creating sum functions to sum the rows and columns of a 2D array. Something this basic requires very little or no planning whatsoever based o the simplicity of the task.

In short, the amount of planning time necessary is directly proportional to the size and anticipated complexity of the program. Bigger, more complicated projects need more time. Smaller, simpler projects require less time.

[carly]

This thread is really good :) as i will be doing a software development project, and knowing all the design techniques that different people use is really useful.
Thanks for sharing your techniques

carly

[Killer42]

This thread is really good :) as i will be doing a software development project, and knowing all the design techniques that different people use is really useful.
Thanks for sharing your techniques

I hope you won't be relying on just what you pick up in this thread... :-)

[AricC]

This thread is really good :) as i will be doing a software development project, and knowing all the design techniques that different people use is really useful.
Thanks for sharing your techniques

carly

Plan ahead like you've heard in the last few threads. I even like to draw my forms/gui out on paper before I start going wild coding. It is very important to plan before you start working or like you've heard you will waste time.

Aric

[Frinavale]

Plan ahead like you've heard in the last few threads. I even like to draw my forms/gui out on paper before I start going wild coding. It is very important to plan before you start working or like you've heard you will waste time.

Aric

I'm only a beginner programmer myself but the experiences I've had developing my bigger projects have varied tremendously.

The best approach I've found to planning a system is to use use-cases.

I've found that spending a good deal of time gathering the requirements from the client is crucial. After getting a clear picture of what needs to be done, I'll design the screen mock-ups for the application and then step through how the application will run with the client. This way I'm sure everyone is clear on how things will work. Once every thing's agreed upon I'll start designing the use-cases and writing up use-case specifications.

I remember that I hated doing use case specifications because its so tedious; I learned very quickly that they are quite necessary because once they're finished, extracting information on the system's objects, their functions and their attributes is really easy. Once I know what objects are required, its really easy to figure out what information needs to be stored into the database.

What's really nice about use-cases is the fact that you can use their specifications later to determine what needs to be tested...and they can be used to refresh yourself on what exactly should be happening in each of the system's components.

All that being said, I'm in the process of developing a system for a client in order to earn a credit for my university course. Last semester we designed a requirements document based on a formal IEEE specification documentation. Its supposed to be a formal report on how your system works that you can give to any developer to develop. Basically any developer's supposed to be able to understand your needs and develop the system for you based on this report.

What I've found is that it is almost impossible to understand what exactly is expected to be developed using this document. Sure all the system's requirements are listed but how they fit together isn't clear right away.

I firmly believe that screen mock-ups and use case diagrams are essential to designing a system that is comprehensible to both the client and developers.

Now that I have finished designing that requirements specification document for school (that took a whole semester to complete), I'm going through and creating a "design document" that includes screen mock-ups and the system's use-cases and their specifications so that we can understand how to properly design our system.

I also agree that some systems are "over-designed" ...the system I'm designing for university is one of those systems.

The amount of documentation the expect from you is truly outrageous and the modifications to these documents during the implementation phase seems endless.

-Frinny