SMART Process Acceleration Development Environment

Summary

SPADE (SMART Process Acceleration Development Environment) is a software development productivity and quality tool used to create professional software in a short time and with little effort. As seen in the diagram SPADE (green icon) automates many manual activities of the Software development process. It therefore takes less time and effort to perform the full software development cycle.

With SPADE the remaining manual steps are:

Automation of the other steps is possible because the (business) requirements are specified clearly by using the method SMART Requirements 2.0.[1] SPADE then uses intelligent algorithms that incorporate dependency analysis and a set of design patterns to transform these requirements to an optimized business process design, including the flow of user interactive and fully automated steps that are part of this business proces.

SPADE is a domain specific model based software development tool that is well suited for creating both complex as well as simple information processing systems. It is currently less suitable for creating software that can control hardware in real time or advanced graphical user interfaces. One can however add plug-ins for accessing functionality that is not created by SPADE.

SPADE explained in more detail

We will explain creating clear requirements using the language SMART notation[1] which is part of the method SMART Requirements 2.0[1] followed by explaining how and what SPADE will automatically create from these requirements. We will also explain creating and running test cases and the typical architecture of the software solution that is created by SPADE.

Creating clear requirements

The input of SPADE are end result oriented business requirement specifications. These explain:

'What' desired result the process must produce.
'When' the desired result will be produced. In other words the condition under which it should be produced.
'Where' the information comes from. This can be an available piece of information, a calculation or a person.

This information is placed in a document, usually a file of some sort and is written down using a formal specification language. Below is an example in gray with explanation in italic text.

Start by naming the process and its most important piece of information as its subject

Process 'Order products' with subject #('Order': ORDER)

Sum up the high level results. Double quotes are used to define requirements and help to create a result oriented break down structure. 

 The following applies:
     "Customer has ordered products"
     and
     "Customer has an invoice if approved"
     and
     "The order needs to be approved if needed"
Visual specification of requirement "Customer has an invoice"

Define the requirements clearly. Use if-then-else to define 'When' results should apply or should be produced. 'Where' the information is coming from is defined using references. For instance ORDER.approved is a piece of available information that is either produced during the process or is already an available piece of information. Some requirements (results) can be specified visually. To your right the "Customer has an invoice" is specified as an e-mail. 

 "Customer has an invoice if approved" =
     if ORDER.approved then "Customer has an invoice"

 "The order needs to be approved if needed" =
     if   "too expensive"
     then "The order needs to be approved"
     else ORDER.approved = true

 "too expensive" =
     ORDER.total > 500

A person can also be a source of information by stating 'input from' followed by a name that identifies the role of this person or the actual user. In the example below a person with the role CONTROLLER. If this persons in turn need information to be able to give this input, you need to state that this input can be given 'based on' certain other information. In this case the date, the BUYER and the LINES of the ORDER.

 "The order needs to be approved" =
     ORDER.approved = input from CONTROLLER based on #(ORDER.date, ORDER.BUYER, ORDER.LINES)

The actual person that is giving the input at the time the system is used (the current user), can also be used as a piece of information. The example below defines the ORDER and its attributes. One if the attributes is called BUYER and this is filled with the actual CUSTOMER that (at the time the actual process runs) is playing that role, in other words giving the input. 

 "Customer has ordered products" =
     One ORDER exists in ORDERS with:
         date        = currentDate()
         BUYER       = CUSTOMER
         LINES       = "order lines"

 "order lines" =
     Several LINE exist in ORDER_LINES with:
         PRODUCT = input from CUSTOMER
         number  = input from CUSTOMER

The requirements also require a business or logical data model. Most of the logical data model can be derived from the requirements. For instance it knows which entities are needed (ORDERS, ORDER_LINES and PRODUCST) and in some cases it also can derive the type of an attribute. For instance __approved__ can only be true or false because it is used as a condition and LINES should be a relation to ORDER_LINES. Some types however cannot be derived and need to be defined explicitly in this data model. Below is an example of this data model.

   ORDERS =
       date                 : date
       BUYER                : USERS(1)
       LINES                : ORDER_LINES(*) opposite of ORDER
       approved             : boolean
       total                : decimal(10,2) = sum(LINES.total)
       summary              : text displayed = '{total} euro by {BUYER.firstName} {BUYER.lastName} on {date}'
   ORDER_LINES =
       PRODUCT     : PRODUCTS(1)
       number      : integer
       ORDER       : ORDERS(1) opposite of LINES
       total       : decimal(10,2) = number * PRODUCT.price
   PRODUCTS =
       name         : text
       price        : decimal(10,2)
       summary      : text displayed = '{name} ({price} euro)'

Most of this data model is pretty straight forward and resemble other data modelling techniques. Some things stand out:

SPADE automates design and the creation of code

A process design created automatically by SPADE.

SPADE perform the following steps:

  1. Parse: in other words read the business requirements
  2. Analyse dependencies: the dependencies between the different parts of the business requirements are analysed.
  3. Create process designs: an intelligent algorithm transform dependencies to process designs. It uses a set of design patterns and several optimization techniques to create an optimized process design that has no waste in it. The design is both a high level design (e.g. chains of business processes) as well as a low level design (e.g. at statement level).
  4. Generate sources: for the work flow and all the screens and steps in the process design.
Form1 - Enter order lines by customer
Form2 - Enter approval by controller

To your right is an example process design that was created by SPADE. The whole process is the business process, the yellow steps are the user interactive steps or the steps in which the system interacts with an external actor, for instance an external system. The blue steps are the fully automated steps. Example screen captures of the forms are added below the process diagram.

Creating and running test cases

When you are using the created solution, you are also recording test cases at the same time. Those test cases are then expanded with asserts that verify the outcome of the process. Below is an example in gray with explanation in italic text.

Each test scenario starts with stating which process is started by which user. In this case process 'Order products' for user 'edwinh'.

START_PROCESS = Order products, edwinh

The next part describes which roles and users will claim and then enter data in which task. In this case a customer with user name marcusk will enter 2 LINEs and each line will have a selected product and a number of products. The second task is for the manager with user name edwinh and he will fill approved with true.

   # -------- FIRST CLAIM AND ENTER THE 1ST TASK ----------
   task01.CLAIM_NEXT_GROUP_TASK = customer, marcusk
   task01.LINEs = 2
   task01.LINEs[0]-c-product = 1
   task01.LINEs[0]-c-number = 10
   task01.LINEs[1]-c-product = 2
   task01.LINEs[1]-c-number = 20
   
   # -------- FIRST CLAIM AND ENTER THE 2ND TASK ----------
   task02.CLAIM_NEXT_GROUP_TASK = manager, edwinh
   task02.approved = true

The next part are the asserts the check if the process achieved the predicted end result. These are not recorded and need to be added manually. In this example we have added 2 asserts. The first checks if there is +1 more instance of ORDERS with attribute approved filled with TRUE. The second checks if +2 new instances of ORDER_LINES have been added.

   ASSERT_PROCESS_VALUE_COUNT_01 = ORDERS.approved = TRUE, +1
   ASSERT_PROCESS_ROW_COUNT_02   = ORDER_LINES, +2

Deploying the solution

SPADE can run on its own but it often runs as an Apache Maven plugin and is therefore part of a Maven build cycle. This build cycle also includes running the test scenarios, which in turn

  1. deploys the generated functionality as a .jar file,
  2. loads tests data,
  3. executes the test scenario's and
  4. verifies the result.

The Maven build cycle can be used in daily builds all the way up to continuous delivery / deployment. For demo purposes, the steps mentioned can also be executed in the standard front-end of the resulting software solution. With the standard front end it is also possible to automate the following:

Migrating data from an old database or from the old release to the new release is also performed automated. However, the migration software (e.g. by using SQL or ETL) is created manually.

Note that automation that SPADE provides during deployment is often used for smaller systems and for sprint demos. For deploying bigger projects, other more advanced deployment tools are more commonly used.

Global Architecture of SPADE and the solution it creates

The resulting software solution

The diagram to your right shows how SPADE relates to the created solution, as well as a global architecture of this solution. Below the different elements of the diagram are explained:

Which software development activities are automated and which are manual?

The next table shows which software development activities are automated by SPADE and which exceptions apply.

Software development activity Manual or Automated Exceptions
Requirements Manual n.a.
Design Automated Designs for incoming interfaces to external systems and complex or fancy graphical user interfaces need to be created manually.
Coding / programming Automated parts that are designed manually
Testing preparation Manual n.a.
Performing tests Automated smoke tests for first releases and testing the user interfaces should be performed manually.
Deployment Automated creating the data migration is often done manually. As mentioned above, other deployments tools and techniques are often used for larger systems. Configuring these is also done manually.
Documentation Automated The designs and the generated source are documented automatically. This is often complimented with a small amount of manually created documentation.

History

Advantages, disadvantages and considerations

On the upside SPADE shows remarkable development speeds. International benchmarks show that the complete development cycle will be completed on average 20 times faster when compared to conventional techniques and in many cases it is even faster to completely recreate the functionality of existing software solutions compared to buying and configuring them. This development speed of course makes it easier for clients to see and try out the newly created solution. Of course by automating design and coding there will be almost no design and coding errors. The fact that the resulting solutions has no vendor-lock and is completely based on free to use open source components is also a big plus. Of course SPADE is also easy to learn.

On the downside SPADE will remains a domain specific language and will therefore not be suitable for any type of functionality. This will require conventional development or other tools. Besides this real-time performance and the ability to change the GUI more easily is something that needs extra development. SPADE is also rather new and is not yet considered a mainstream development tool. Of course creating SMART requirements takes more effort and skill compared to just describing them in a couple of sentences.

One should always consider that in normal software development the requirements define a fixed "contract" of the functionality that should be created. For instance the user story in a Scrum development team should also be fixed before the user story can be developed during a sprint. This is the same for SPADE projects. However when the requirements or the user stories are ready to be developed, the sprint will be performed by SPADE and this will take only a couple of minutes. This has resulted in the tendency to move the requirements phase (the creation of the user stories) to the sprint. This is therefore considered to be a bad practice in both normal Agile development as well as Agile development using SPADE.

Another consideration is that it is so easy to large and complex functionality. Although this poses no problem for SPADE, it does make it hard for certain people to handle the sheer size and complexity of the functionality of system. It is therefore advisable to still tackle size and complexity in the same way as you would in normal system development. By chopping up and structuring functionality in comprehensible pieces.

See also

References

  1. 1 2 3 4 5 6 7 8 Aydinli, Hendriks, Zandvliet, SMART Requirements 2.0. Sdu Uitgevers, 2003, ch. 5.
Wikimedia Commons has media related to SMART Process Acceleration Development Environment.

Category:Agile software development

This article is issued from Wikipedia - version of the 11/30/2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.