Just as a checklist (includes chapter 13 Software Project | Survival Guide)

On this chapter, detailed design was discussed, it can affect the whole project and it extends design work done during the architecture stage. During stage 1, detailed design  requires verifying the quality of the architecture, if it has bad quality, it’s time to correct it.

Detailed design also uses a staged approach, at each stage developers design the features that’ll be delivered at the end of that stage. A good architecture will let you focus on the current stage. During detailed design is when developers check if they can reuse components.

At the start of each stage, requirements must be clear, if a requirement is not clear is either resolved during that stage, or resolved in a later one, but the leadership should be informed about this delay. Delaying a requirement is a bad idea, if you do it too often you’ll end up delaying the project. And remember, a project is delivered a year late one day at a time.

Requirements flow from requirements to architecture to detailed design to code and test cases. Developers must continue doing detailed design until they get miniature milestones for construction. But how much does that is? It depends on the experience of the developers and the difficulty of the project, the more experienced the team, and the easier the project, the less detailed design you’ll need. Still, more is safer.

After done, detailed design should be reviewed,  and it must have correctness (will it work?), completeness (for everything we intend it to work?) and understandability(is it clear how it works?). With detailed design reviews, more than one person knows each part of the project, so if someone goes missing, you’ll have at least a plan B.

Be sure to use detailed design on your projects, a little overhead, but a safer trip to delivering the project.

Leave a comment