SMART Process Acceleration Development Environment
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". 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 process. 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. Details. We will explain creating clear requirements  using the language "SMART notation" which is part of the method "SMART Requirements 2.0" 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: 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" "Sum up the high level results. Double quotes are used to define requirements and help to create a result oriented break down structure. " "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. " "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 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. " "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. "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. SPADE perform the following steps: 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'." "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." "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." 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 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. 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. 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.