2

All of a sudden the need for proper formal documentation has become a thing in our organization. A lot of work I do are enhancements and addition to an existing system. Generally a quick fix or a new method, etc.

I am just not sure what kind of diagrams I should/could use for small projects. For instance I am adding a new functionality to an existing system that verifies format of a field and they want proper "Component design description with diagrams" for a simple regex that verifies format of one field. In the past we only did pseudocode and that was enough for such projects as the system is somewhat legacy with very little original documentation.

Improve this question

3 Answers 3

Reset to default
3

Your main problem seems to be that UML diagrams document systems, not projects. It is indeed completely nonsensical to demand separate UML documentation for a project that consists of adding a small amount of functionality to an existing large system.

Talk to your management about how this discrepancy can be resolved. If all they want is some sort of "formal documentation", propose a standardized form to handle such "small change" projects (with entries such as "system to be changed", "summary of change", "affected assets", etc.). If they insist on UML purely for buzzword compatibility, a use case document (not diagram) is quite similar to that and may satisfy the demand.

Alternatively or additionally, you may want to consider creating some high-level UML documentation for those legacy projects and integrate future changes in that.

Improve this answer
2

It sounds like your existing code isn't really documented, so as you fix the code, you should be documenting all of the final product, not just your stuff. If you change code that was already documented, you should be updating the documentation to make sure it's still accurate.

Improve this answer
2
  • That is the problem. If there were already diagrams, I'd just add to that. But they don't want to spend time on documenting the whole thing as there is a plan for a major change in less than 2 years time. The newer systems I have worked on are well documented. These are kind of legacy systems.
    – Hameed
    Commented Mar 8, 2013 at 4:14
  • 2
    @Hameed: In that case, you should try to pave the way for that major overhaul. Instead of documenting the entire system, just write/update the documentation for the (sub-)module/class that you made your change to, with cross-references to the (not jet existing) documentation of related (sub-)modules/classes. As more parts get documented, the cross-references can be resolved and higher-level documentation can be added.
    – Bart van Ingen Schenau
    Commented Mar 8, 2013 at 8:41
1

For instance I am adding a new functionality to an existing system that verifies format of a field and they want proper...
you can try Use-case diagram

Its hard to define what is a small-project, sometime you may design a small-component but it can turn out that the component will be used in other 100 projects but here my small attempt
For small projects diagrams like user-case, class, activity ,sequence & state diagram can do the job.

If you are using intellij for development then ctrl+alt+shift+u on package and it will auto-generate class diagram for you

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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