Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I am doing a project in my university where, for the first time in my life, I have to create a system architecture/design and I will be the head of a group of 4 students that are in the beginning of the course.

Basically, I will be able to do everything: I have almost complete independence to choose what exactly the software should do (goals, features, etc), than I have to design it.

Because it is a university project, I do have a lot of time to think about the software concept and design it.

My plans are to create a draft of the idea and refine it with the professor. Once we do have a concrete idea, I want to start the SW design itself. And this is the point where my questions arrives:

I know that creating a design that contemplates everything and will not change during development is impossible, because of that, I am sure the design will be changed once the implementation begins. However, I want to present a mature design, based in logical decisions and good practices, but, of course, I won't be able to develop the SW to identify the traps I am falling into (this will be the student's task).

What tricks do you use to create a mature design and to avoid traps before starting implementing? How do you approach and "study" the software proposal to find inconsistencies or points needing clarification? How do you do to include the changes to your design, without ruining it? (Many of my designs start very nicely, but at the end they are ruined by the changes).

share|improve this question
There are some good answers regarding handling change on this related question: programmers.stackexchange.com/questions/46284/… –  glenatron Mar 22 '11 at 14:56
add comment

5 Answers

up vote 1 down vote accepted

If the problem has any complexity, then no matter how much time you spend on an initial design, it will have to change when you start writing code. So I don't even attempt to produce a design that will cover every use case. Instead, I just design for one use case at a time, and refactor (redesign) as I implement each subsequent use case. This practice has produced the most elegant code.

share|improve this answer
Hi, you are right. But because of the nature of this project (we are not in a company, meeting everyday, and so on), keep tracking of all changes may be very hard. So my intention would be to make the design as mature as possible, so the changes would be few. But I think it is not possible :( –  Oscar Mar 23 '11 at 10:35
One possibility is to design the project into components, but not attempt to do detailed design of the components. For a web application, you could have one person build the client side and have another write all the server side code. They can then work in parallel one use case at a time. –  kevin cline Mar 23 '11 at 12:39
add comment

What helps me in designing software is a plain paper and pencil. In order to get a bigger picture I usually draw and visualize the problem which needs to be solved. Starting globally and then separate it into more detailed and simpler parts where for example pseudo code can be handy. You can achieve a much better overview of the whole system and it's particular parts which needs to be done by visualizing and "serializing" them it on paper. It also helps you to identify modularity or complexity and thus predict the possible future enhancements or pitfalls.

share|improve this answer
Yes, this is a very good advice. I will "mix" it with Péter Török's. thanks! –  Oscar Mar 22 '11 at 12:35
add comment

Start by identifying the planned use cases for the program. Then walk through them one by one, think through the necessary steps, and focus on how the system would deliver the expected results. This helps you discover the key entities / domain concepts and consequently, objects in the system, and their relationships, ensuring that they work together in a meaningful ways and are able to deliver what is expected.

It helps drawing sketches of interacting objects during the walk-through. Initially hand sketches on a piece of paper or whiteboard are completely suitable; later, as your design solidifies, you might want to turn these into e.g. UML diagrams.

share|improve this answer
This is a very detailed explanation. I think I will use it during the process because I have time and because I want really to have a "strong" design. thanks! –  Oscar Mar 22 '11 at 12:35
add comment

If you have free reigh over the system you are developing, you should be able to identify the areas that are likely to change. You can them encapsulate these to show that you have though about future changes of the system. You may want to look at the Strategy Pattern to guideyou on this, or if you are using C#, you can use delegates.

Insofar as documenting things throughout the defvelopment lifecycle that changes, then you need to get constant feedback from the developers of what has changed and more importantly, WHY? You then revise your documentation to show this, not by replacing your original work, but with an addendum detailing why it changed. This is a key learning curve and something your professor should reward you for.

share|improve this answer
This idea of not replacing, but adding the info about the change and the reason is very good. This is a part of my master thesis, so I am going to have almost full control over the software development. Thanks a lot for your advice :) –  Oscar Mar 22 '11 at 12:33
NP. This is what I tend to do with my University projects and generally get top grades. Obviously, I would check with your professor that it's acceptable at your place of study - I suspect that it would be encouraged. –  Darren Young Mar 22 '11 at 13:05
add comment

Focus on your public functions and interfaces the most in the begining: How will one class interact with another? If your public methods keep changing frequently they will resut in many changes in different places leading to greater chances that errors will keep in. Private class methods can change later without hurting much but public methods should remain as stable as possible. This of course, does not mean that you do not change public methods at all but when you do try to minimise the chances that you willhave to do it once again.

share|improve this answer
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.