The first book I ever wrote was the Oracle Designer 2000 Handbook (1999, Oracle Press) Peter Koletzke was my co-author. Probably the biggest “ah ha!” moment for me was the realization that the tools you use have a HUGE impact on the optimal SDLC. Since the book was about using Designer 2000 to design systems, I was struck by how much changed in the SDLC just because of the use of that tool.
Using a rules-based approach to development has an even bigger impact. Here are the main points:
1) Rules repositories are more-or-less readable by humans. Therefore, analysis = design = development for everything that can go into a rules repository. This is huge. It means that I do not have to perform logical analysis and have it signed off on, but I can simply deliver the system (as soon as the rules are gathered) and get feedback.
2) Since the repositories are readable by humans, there is also a reduced requirement for documentation. If 95% of your system is “self-documented” (meaning that the rules are pretty good documentation in their own right), this means that much of the logical as well as physical documentation is created automatically.
3) Truly Agile development is almost required by a rules-based approach since you can build as fast as you can do the analysis. The only process that makes logical sense is to build very quickly, show a version of the system to the customer, get feedback, fix the issues, and repeat until the system is complete.
4) There is still additional documentation required. You still need a real project plan. You still need a way of identifying and fixing bugs (bug tracker). You still need a place to write down complicated specifications. You still need a place to keep client notes and requirements to make sure that they do not get lost.
5) As mentioned in the last post, there is still some amount of code that has to be hand written. That code needs to be handled in the same way as in any traditional development. You need specifications, testing (preferably test-first).
6) Testing in this case is “weird.” Test-first for a rules system makes no sense. What would you even test? Although some form of automated testing sounds good, I have never been able to make it work (in spite of numerous attempts). I still seem to be left with having someone exhaustively go through all of the system features and test everything, i.e. running though a manual test script. A process flow for one area of the rules is “Traverse the process flow and cross off every transition between states after you have tested an object going through that transition. Do this for each user role in the system.” That single test can involve weeks of work. I am not happy with how conceptually sloppy this sounds, but I have not been able to figure out how to do it better.
The basic SDLC tends to go like this:
1) Create a more-or-less traditional strategy document and create the basic use cases. Don’t worry about scenarios and scenario steps.
2) Create the structural rules (data model in a BRIM® UML class diagram). Walk the user through the model. Use white board screens to help explain.
3) Generate the database.
4) Design and build the basic UI, and attach to the data model.
5) Review and refine UI with users.
6) Create the process model (BRIM® Process Modeler) and generate the code.
7) Show the complete system to the users.
8) Iterate the rules until you get it right.
9) Build the reports.
10) Create the interfaces.
11) Perform integration testing
12) Perform user acceptance testing
Leave a Reply