4

The project I am putted in is running awful. :-) Main Problem is a missing architecture and a missing guidline how to organize projects. In this case I have done a sample project architecture with UML class and component diagrams and layer diagrams. The main problem is, that I have to present this architecture to the management. But the management is not familiar with UML or Layer Diagrams and for most of them its not possible to understand the logic behind it.

In that case I want to present the management a visualized project structure with easy understanding. I've searched for some ressources and examples with easy understanding visualizations, but was not able to find one.

So my question is how you would visualize your software architecture to the management, which techniques do you use?

Little Note: its a very big sharepoint project with more than 50 sub projects.

Smokefoot
  • 753

2 Answers2

3

UML is a great way to communicate design to technical resources on a project, though in my experience, the vast majority of non-technical project resources get lost with it. UML does indeed require a minimal level of training to fully understand it or formulate it. Some non-technical peers may be experts in Use Case diagrams lets say, but when they see a component diagram it might as well be written in kanji.

I find that knowing your audience for the diagram is important before you start drawing. Non-technical peers generally have an easier time understanding and following Flowchart diagrams rather than Activity or Sequence diagrams. They may also just want labeled boxes and arrows instead of a full UML component diagram or deployment diagram. Sometimes I will do two sets of documents, one simplified for non-technical peers and one in UML for technical peers. Other times if I am running short on time I don't even bother with the UML diagrams because most of the time the technical person can generally understand the complexities in the simplified diagram anyway.

Another important question you have to ask yourself is why your non-technical manager finds these documents important? Is it because the project is running into problems and the urge to micro-manage is setting in? Is it to assist a quasi-technical sales person in better explaining the advantages of your software and architecture to prospective clients? It could be as shallow as a manager wanting to pin up complicated looking diagrams in his office or technical area to try and impress visitors he brings to the office (true story). The bottom line is to know your audience and know it well.

maple_shaft
  • 26,570
1

Main Problem is a missing architecture

What problem does your architecture solve? Even the most poorly designed application has an architecture, so unless you're starting from scratch, one exists. In your case, maybe no one bothered to document it. Management wants to know that you have one that gives the project some sort of advantage (e.g. performance, ease of maintenance, code reuse, accepted standards, etc.).

missing guidline how to organize projects.

They'll feel more comfortable if you don't appear to be working in chaos. Prioritize the 50 sub projects. Designate someone who is tracking the progress. Show them you have a system, so you know developers are getting things done. Can you show the architecture is conducive to this type of project?

Unfortunately, they really want to know: How Long? and How Much? You should be able to answer these questions, but it may not be as accurate as they want.

JeffO
  • 36,956