Dariusz on Software Quality & Performance

09/12/2011

CRUD Matrix As a Software Design And Estimation Tool

Filed under: en — Tags: , — dariusz.cieslak @

I don't get UML designers. They skipped in UML very useful design tool: data flow diagrams (DFD) and placed cheap substitute called "activity diagram". Why? Because data flow is not object oriented (no encapsulation). Should we skip this useful tool and use only diagrams defined by UML? I don't think so.

On the other hand general problem with DFD (and any diagramming technique) is scalability. If you want to express many flows using DFD you have to make DFD hierarchical, thus overall picture may be hidden here. If you place too many (>9 items) details on one diagram you are lost again.

There's simple and very powerful, but forgotten technique called "CRUD tables". What's "CRUD"? It's a table (can be implemented by a spreadsheet) that for every process in a system defines it's interactions with main entities: Create, Read, Update, Delete. CRUD table was used mainly during database design, but I think this technique can be used for every data flow in a system (including external actors and entities).

I'll show you how you can utilize CRUD table to make initial design and get software complexity estimation.

First of all, a specification:

I need to sell products on my website. I'd like an order is created in my ERP system just after instant payments are finished.

Pretty short, but let's start design!

We can see how basic processes interacts with internal data (Product, Order, Item) and external entities (Payment, ERP Order). Let's check first rule:

Every process should have at least one input (R) and one output (CUD)

We can see rule is not valid for few processes, so let's add some Entities to fulfill this rule:

As you can see we added actor (Customer) to be a source (trigger) for some processes.

Now we can add estimation part. First: for every entity we can add complexity (we know that one entities can be more complicated than another), complexity of processes will result from used entities complexity:

Formula used for computation of "complexity" column:

=counta(C3)*$C$2+counta(D3)*D$2+counta(E3)*E$2+counta(F3)*F$2+counta(G3)*G$2+counta(H3)*H$2

So we know now that more complicated process will be sending order to an ERP system. If we added proper weights to operations (CRUD) and measure single activity we could estimate full effort needed to implement specified system.

Above CRUD translates into the following DFD:

I'd like to hear about your experience with CRUD modeling.

2 Comments »

  1. Hi Dariusz
    I can not read the dataflow diagram .png file as it is too small, do you have the original file of this diagram?
    thanks
    neil

    Comment by neil — 03/04/2013 @

  2. Nope, it's just an illustration for classic DFD syntax, you can grab any example from DFD modelling guides instead.

    Comment by dariusz.cieslak — 04/04/2013 @

RSS feed for comments on this post. TrackBack URL

Leave a comment

Powered by WordPress