What significant design artifacts do you produce?

Question

During the software development life cycle, what significant design artifacts do you produce? What makes them important to your practice?

The project that I am currently implementing has been in production for another 8 years. During this time, this web application has been actively expanded and supported. Despite the fact that we have CMMI-based policies and processes, with a partial implementation of our practice, the design phase is largely ignored. Best practices, anyone?

Answer 1

While working on a large number of waterfall projects in the past and many complex and flexible projects recently, there are a number of constructive artifacts that I like, although I cannot say that it really depends on the details of the project (methodology / team structure / time frame / tools etc.).

For a general server-side "enterprise application", I would like the minimum minimum to be as follows:

• Detailed functional design document (aka spec). In general, something similar to Joel s. An example of the WhatsTimeIsIt example , although probably with some UML usage diagrams.
• Program technical document. Not necessarily detailed for 100% system coverage, but detailed in all key areas and containing all design decisions. Being a little UML freak, it would be nice to see a lot of photos on the diagrams of package diagrams, diagrams of components, class diagrams of the main functions and, possibly, some sequence diagrams that were chosen for a good assessment.
• Infrastructure Design Document. Perhaps with a UML deployment diagram for conceptual uninstallation, and perhaps a network diagram for something more physical.

When I say a document, any of the above can be split into several documents or possibly saved in a wiki / some other tool.

As for their usefulness, my philosophy has always been that the development team should always be able to transfer the application to the support service without having to transfer their phone numbers. If design artifacts do not clean the bone, indicate what the application does, how it does it, and where it does it, then you know that the support team is going to give the application the same care and attention that they will be rabid dogs.

I must mention that I do not justify the practice of transferring software from the development team to the support team after its completion, which causes all kinds of interesting problems. I am simply saying that this should be possible if leadership is so desired.

Answer 2

Work code ... and board drawings.

: R

Answer 3

Projects change so much during development, and then that most of my carefully crafted documents decay in source management and become almost more confusing than helping when the code is in production. I see the project documents as necessary for good communication and in order to clarify your thinking while you are developing something, but after that he makes every effort to maintain them properly.

I take pictures of the boards and save the JPEG files in the source code. These are some of my best docs projects!

Answer 4

In our model (which is quite specific for business process applications), design artifacts include:

• domain data model with comments for each object and attribute
• a properties file that lists all the modification and creation triggers for each object, calculated attributes, validators, and other business logic.
• set of screen definitions (view model)

However, are they really considered constructive artifacts? Our structure is such that these definitions are used to generate the actual system code, so maybe they go beyond design.

But the fact that they serve a dual duty is powerful because they are, by definition, updated and synchronized with code at all times.

Answer 5

This is not a project document in itself, but our unit tests serve the dual purpose of "describing" how the code they test should work. The nice part of this is that they never expire , as our unit tests must pass for the success of our assembly.

Answer 6

I don’t think that something can replace a good old-fashioned design proposal for the following reasons:

• It serves as a means of communication with how you will create the application for others.
• This allows you to get ideas out of your head so you don’t worry about tracking millions of things at once.
• If you need to suspend the project and return to it later, you will not begin your thought process again.

I like to see various pieces of information in the design specification:

• A general explanation of your approach to solving the problem.
• How will you track your application?
• What are security issues and how are they addressed?
• Sequence / Sequence Charts
• Open issues
• Known Limitations

Unit tests, while a fantastic and perhaps important element to be included in your application development, do not cover all of these topics.