SDLC – Software Development Lifecycle … designing the blueprint (part 7 of many)

Continued from SDLC – Software Development Lifecycle … analyzing the battle ahead (part 6 of many).


Group Of Gold People Seated And Holding A Meeting At A Round Golden Conference Table Clipart Illustration ImageDuring the previous phase, analysis, we communicated, we documented and we visualised. The meetings, the exploration, the observations, the surveys and the expert consultancy has hopefully not only created an analysis domain representing different points of view of the business requirements, but most importantly clarifies the requirements. At this stage we are entering the design world and need to ensure that inconsistencies, omissions and misunderstandings are minimised, if not eradicated … if we are unsure, it is the right time to cycle back, for another iteration of analysis.

We should share one common vision and a visual model of the business requirements. We are one …

Deliverable Chunks

Blue Man Holding a Pencil and Drawing a Circle on a Blueprint Clipart IllustrationThe design phase is the phase that most of us dream of … it allows us to take a whiteboard, like an artist would take a new sheet of paper, and start modelling and designing the solution.

The design should be based on well known and proven principles, concepts, blueprints and practices. Experience and well proven patterns create solid and usually maintainable solutions, just like the sowing patterns allow factories to create high quality clothes, again and again. Giving a factory the green light to experiment with new knitting machines, material and styles would most likely result in a drop in production, drop in quality and rise in production costs … with little reproducibility and predictability. Now imagine giving systems analysts and especially developers the same freedom …

During the design we take the analysis artefacts, which document the “big picture”, and drill down into the detail, defining subsystems, interaction, communication, security and interfaces, etc. We define the detail of the solution to be developed, the blueprint that will allow the developers, the integrators and the testers to build the ultimate business solution.

I personally love simplicity and visualisation, so my recommendations would be to:

  • Keep it simple!
  • Visualize as much as possible and shred the thesis!
  • Aim for low coupling (minimise dependency on others) and high cohesion (focused on core responsibilities).
  • Did I mention simplicity and visualisation?

The possible (not comprehensive list) artefacts mentioned in the analysis post included:

  • Data Models
  • Use Cases
  • Use Case Diagram
  • Universal Modelling Language (UML ) Diagrams, including Activity, State, Class and Sequence diagram
  • Data Flow Diagram (DFD)
  • Class Responsibility Collaborator (CRC) Model
  • … and more!

    The artefacts emerging from the refinement of analysis artefacts include:

    • Architecture design
    • Subsystem design
    • User interface design, including technical, navigation and graphical user interface (GUI) design
    • Diagrams
      • Collaboration
      • Activity
      • Sequence
      • Component
      • Deployment
    • … and lots more

    Listing all the deliverables of the analysis and design phases is way beyond the scope of this post. What we are trying to emphasise are the core visualization deliverables (models), so that we can draw some conclusions as to the value-add of VSTS 2010.

    Once again we investigate Team Foundation Server (TFS) and Visual Studio team System (VSTS) in this world

    To avoid looking for our helmets, we will assume that we are in a VSTS 2010 world, where the emergence of the new architecture edition and tools brings great relief. Again invest a peek at previous posts Rosario 2010 CTP2 Agile Planning, Design, Reviewing a Solution and A close encounter with Sequence Diagram to get an idea of what is coming and the breath of support for visualisation and modelling, or better download the latest Community Technology Preview (CTP) and have a critical look yourself.

    The diagrams introduced and supported with CTP2 include:

    • Activity diagram
      • Visualise the workflow through a system
    • Use Case diagram
      • Visualise the interaction between users (actors) and the system
    • Sequence diagram
      • Visualise the sequence of interaction between users (actors) and the system
    • image_thumb14Component diagram
      • Visualise the functional division of a system
    • Logical Class diagram
      • Visualise the classes and interfaces, as well as relationships in the solution
    • Class diagram
      • Visualise the classes and interfaces, as well as relationships within a project
    • image_thumb9Layer diagram (see below)
      • Visualise the various pieces of a system and their dependencies
      • The layer diagram, as shown, reminds me of the old system, application and deployment diagram, but closer inspection reveals a visualisation tool that is really exciting: 
      • Not only can we finally visualise the main areas and layers of our solution, but also enjoy code association and code validation, which is an exceptional solution review and solution maintenance feature.
    • Branching diagram
      • Visualise the hierarchy and timeline of branches
    • Architecture Explorer
      • Visualise the various pieces of a system and their dependencies
      • Models
        • Cass view
        • Solution view
        • UML Model view
      • Visualization by …
        • Assembly
        • Namespace
        • Class

    What, if anything, is missing in terms of modelling in your opinion? Is the UML deployment diagram essential? What UML diagram would you add to the mix?
    Blue Man Holding a Clipboard While Reviewing Employess Clipart Illustration


    With the analysis and design efforts complete, we will explore architecture and testing .. but more on that the next time 🙂

  • Comments (4)

    1. OsirisTerje says:


      It’s great these diagrams are coming into VS.  You asked about the UML deployment diagram, and YES – it should be there. The deployment diagram is very useful when documenting distributed solutions, or just an enterprise solution covering multiple computers and multiple interacting components.

      Regarding the other diagram, IMHO the sequence diagram can be replaced with the newer communication diagram. The activity diagram can be dangerous, because it’s very easy to fall back to a procedural thinking instead of a domain driven thinking.  

      best regards


    2. Continued from SDLC – Software Development Lifecycle … designing the blueprint (part 7 of many) . Overview

    3. Incredible presentation of the SDLC. I just want brief about UML diagram.

    Skip to main content