In this article, we aim to provide information about what outputs we can produce regarding detailed design development and unit construction methods.
Applying the detailed design and unit construction process actually ensures the development of a consistent structure in the creation of detailed software units.
1. SWE.3.BP1: Develop software detailed design
A detailed design document needs to be developed for this base practice. It would be good to include the following contents in the detailed design document.
Flowcharts (representing the prototype)
ER Diagram
Class Diagram
Class Details
Component / Data Models / Database Relationships (Unit We explained the component definition in SWE.2.
Database Tables
Database Table Details
Functions
Addictions
Authorization
Security
Interface definitions related to integration (contact information, parameters, web service information)
Traceability
2. SWE.3.BP2: Define interfaces of software units
In this section, interface definitions for the units are required. Apart from the mock ups we made in the preliminary design in the SWE.2 BP.3 section, we also need to define the software communication interfaces in order to provide this basic practice. Here;
Regarding online interfaces; It may include contact information (TCP/IP sockets, web services (general rule, parameters, request and response information, message information, scenario, example usage).
3. SWE.3.BP3: Describe dynamic behavior
Defining the dynamic behavior, if any, for software units can actually be done by defining the relationship between software units – -class diagrams, software units – data model tables, as well as the diagrams I explained in the SWE.2 BP.4 article.
4. SWE.3.BP4: Evaluate software detailed design
Here we need to verify, as I explained in SWE.1. Again, we can do this through a checklist. The criteria we will look at in the checklist are; (i.e. the questions may be as in the examples below)
- Does the design meet all requirements (direct and derived)?
- Is there traceability between design and requirements?
- Have the risks foreseen in the design been evaluated and recorded in the Risk Analysis document?
- Is the design understood in the same way by all involved?
- Has the data structure been defined in accordance with the analysis model?
- Is the design modular?
- Have new data structures or features emerged during the design phase?
- Have different architectural design options been created?
- Has the architectural model been created in accordance with the analysis model? Is there traceability? Etc.
5. SWE.3.BP5: Establish bidirectional traceability
While explaining the traceability section, I would like to remind you that you must do this work on a tool (jira, doors etc.) to ensure continuity. I have seen traces that were made just to comply with the standard and were not updated. (The traceability examples given at the end of the article are given in Excel.)
Establish bidirectional traceability between
- Software requirements – Software units
- Software architectural design – Software detailed design (mock up and use case items – Class and ER Diagram and other detailed design items or you can treace the requirements – primary and detailed design items)
- Software detailed design – Software units (Class diagram and ER diagram and database table items – Unit)
You know the software units, I said that we need to define them while explaining SWE.2. We must name the software units we define in accordance with the configuration rule and ensure their traceability with requirements and detailed design elements.
6. SWE.3.BP6: Ensure consistency
Ensuring consistency is achieved through traceability records (Software Requirement, Software Architecture, Software Detailed Design and units) and also by reviewing these traceabilities. What is required of us is to both carry out traceability, maintain it and review it. Review; It can be done through meetings, checklists and audits.
7. SWE.3.BP7: Communicate agreed software detailed design
Agreed design means;
First review of the design, which we do with meetings and checklists for all parties,
Afterwards, it is approved and included in the baseline.
It requires that the design in baseline be accessible to all concerned.
Therefore, as I mentioned in the previous article, a strong communication tool must be used with the relevant parties.
8. SWE.3.BP8: Develop software units
Developing software units in accordance with the software detail design actually means that the coding is done and followed in accordance with the detailed design. If Jira is used, it can be easier to track requirements – design and code (which can be divided by unit) when integrated with Git. Apart from this, if a tool that cannot be integrated with coding is used, it would be nice to track traceability on the basis of the developed units.
Gamze Dağloğlu
Co-Founder of Dağloğlu Yazılım
