Skip to content

DA4. Importance of modeling

statement

  • Explain why it is important to model the context of a system that is being developed.
  • Give two examples of possible errors if software engineers do not understand the system context.

solution

  • Software engineering is difficult since the problems it solves are unique, and no standard methods or rules can be followed when developing a system or software solution.
  • The most important source of information when designing a software solution to a problem is the problem itself, along with less important information sources such as the company rules, the laws, technologies available …etc.
  • To extract the most out of the problem statement, the developer must deeply and carefully read, understand, and imagine every possible aspect of the customer statement of work and the requirements.
  • In a simple product, the developer can imagine everything in their head skipping the modeling process; this may work in a simple system with a limited number of objects where the cost of change -if things are misunderstood- is fairly low.
  • In real life, systems are complicated and involve many objects making remembering all of them an impossible task. Also, the relationships between these objects are complex, and there is no way to think about them without modeling.
  • In real life, the cost of implementing a piece of the system is fairly high. Implementing software components to only change them later because of requirement misunderstanding makes the development process much more difficult and costly.
  • So the benefits of modeling are:
    • Gives the developer an overview of the system context before its being implemented.
    • Illustrates all system components and the relationship between them for a clearer understanding of the problem domain.
    • Reduces the cost of development by thinking everything ahead before writing any code.
    • Ensures that all teams participate in the decision-making process; since modeling uses symbols that can be understood by non-developers, it is a good idea to invite all teams to look at the diagrams and give feedback, which may open the eyes of the developers to some hidden problems.
    • Reduces the need to change critical parts of the system at later stages of development; since these details are well-discussed before the implementations.

Example 1

  • In a workplace (HR) management system. The requirements ask for a way to fire or remove existing employees.
  • Developers take this task and develop it simply as deleting an employee record.
  • The product is being rejected after delivery since the implemented solution must comply with local law and tax audit rules.
  • The cost of fixing this issue is much higher than getting it right in the first place.
  • If the modeling has been used, there is a much higher chance that this issue will be discovered very early in the development process.

Example 2

  • In a store management system. The requirements ask for one way to take payments using cash only.
  • The developers omit the payment sub-system since the process will be done manually by the store cashier.
  • A few months later, the store management wishes to add card payments to their system.
  • The payment sub-system has been omitted in the first implementation because the requirements did not mention it properly.
  • The cost of adding the new card payments will be higher since the payment sub-system needs to be created and integrated into the whole system.
  • If modeling has been used, there is a much higher chance that this issue will be discovered very early in the development process.

References