How do I create a mature SW design before the implementation itself? And how do I cope with changes?

Question

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).

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.