I’m presenting a software design for approval today and as I’m going through the hundreds of pages of design documentation, cherry picking what’s important, I’m unsure if I should start with the activity diagrams or use cases. I was thinking of having it stacked like so:
- Activities Diagrams
- Use Cases Diagrams
- Sequence Diagrams
- Class Models
I’ve spent the last 7 months of my life creating this and I want it to be presented in the most logical order and done with.
8
You should start with one diagram. What are the big parts of this software?
Talk about the responsibility of each at the high level, focus on tying in the boxes to their understanding of the business.
After the one high level diagram, I would get 1-2 layers more detailed. I would make sure that you take time to let people ask questions.
Do not try to let them get mastery of the design, sell them on the idea that you know what you’re doing, and that more often involves making them know that you know the domain (what terms to use for each area, what insights relate between them). They often can’t judge a software design or your technical skills.
If they think you know what you’re doing, that’s what will drive their approval more than any logical presentation.
3
The upper management folk that I’ve met tend to be focused on
- Will it do what I want/need?
- When will I get it?
- What are the risks involved?
and
- Have you done your homework (and/or ‘do you know what you are talking about?’)
Showing them class models might be useful to show that you know what you’re talking about, but beyond that you’ll bore them to tears. Not recommended.
Stick to a very high level overview, sound confident, and be prepared to back up anything with details.
Don’t do any on-the-spot engineering. You will get it wrong. If asked a complex question, write it down and get back to them.
4
Depending on how technically inclined the audience is, you might want to leave some parts out, and add others. If you show them class models, will they understand? Will they care?
Most of the people that I work with who would count as “upper management” do not care very much about implementation details (it sounds like this is what your presentation focuses on), they mostly will care about:
- introduction and general overview (what is the point of this system?)
- high-level architecture (how is it built – at a high level?)
- user stories (what can a user do with this system?)
- data model (sometimes these are useful/necessary, but it depends on the project)
(I would run the presentation in that order as well)
Some members of the audience might care about the other types of diagrams (probably the use-case diagrams more than the others), and the diagrams can be useful in explaining other parts of the presentation, but I’m not sure I’d launch into them straightaway or make them the focus of the presentation.
Of course, if your audience is highly technical and want to see this kind of info, then go for it! But I’d still start off the presentation with some kind of general overview, just to give some context for the rest of the presentation.
1