Although there are several important technical areas of concern when developing production-ready software, its success fundamentally depends on having running code that implements the original conceptual ideas and functional requirements. On the surface, this seems to be a straight forward and well understood problem to solve. Talk to the users (or their proxies, the business analysts) to capture the conceptual ideas and requirements – then translate them to design and code. How difficult can that be? Seriously, the more complex and interesting problems will involve addressing the technical concerns of scalability, availability, maintainability, security, etc – right?
Of course, those of us who spent decades in this field learned first-hand that moving from conceptual idea to running code that reflects the functional requirements involves a lot of moving parts. This includes working with a diverse set of people and a lot of "I probably won’t know or understand what I want until after you build it" reality, which make it a very complex problem to solve. The field of software engineering does a nice job of breaking down the basic process elements for attacking the problem. Regardless of the development methodology you use - from the older waterfall through the newer agile variations - they all involve some level of define, design, build, deploy, and test processes.
Bridging the Disconnect between Conceptual Design and Running Code
Looking back at years of real projects and the lessons we can take away from them, it becomes apparent that we have to address key failure points as early in the software development lifecycle as possible. The first failure point is typically traced back to vague, misinterpreted, and missing requirements. Its downstream impact is increased time and money required to address the disconnect from what the user actually wanted and the delivered application, which kills the benefits projected and in effect reduces the success of the project. Typically, these disconnects only come to light after the application is built and the user actually uses the running code. This is the genesis for the area known as functional prototyping. The premise is simple enough – inject the opportunity to validate the functional requirements of the system before actually investing the time and money to build the system.
This area of software engineering has had some level of success, but continues to suffer real uptake in the industry. This is mainly due to the time consuming nature of creating what is essentially a throw away mini-project during the conceptual phase of development using the current tools available in the market. Pure agilest will also argue that functional prototypes become less needed as you reduce the application release cycle times. In essence, these mini-application releases serve the same purpose while also producing usable code. On the surface, this seems a reasonable argument. Interesting enough, the argument can be flipped to say non throw away functional prototypes embed the value of agile principles – focus on producing software often and early - within the waterfall methodology for the complex systems.
Using Scaffolding to Create Functional Prototypes
This is where MyEclipse for Spring provides a modern light-weight solution that makes sense for both simple and complex projects. Use the scaffolding capabilities to produce quick functional prototypes during the conceptual phase of the software development life cycle. The tooling provides full web application scaffolding from a variety of sources including data schemas, JPA entities, Java Beans, and WSDLs.
The most common functional prototyping approach is validating a functional area defined by a set of tables in the data schema. In this scenario, a business analyst with minimal technical skills could run through the scaffolding wizard and generate a working CRUD web application for the selected tables. However more often, a business analyst or set of business analysts are paired with a developer to quickly validate the domain and the expected functional interactions. The beauty of this approach is the minimal time required for the users (or more likely, their proxies the business analyst) to validate and update the functional requirements. It typically takes minutes to scaffold, followed by short iterations to update the domain and the functional requirements.
Functional Prototype created with MyEclipse for Spring
Another common scenario involves validating functional requirements while using web services. Injecting scaffolding into the process involves two steps. In the first, the business analyst or paired developer imports the WSDL to generate the back-end service and data objects. In the next step, the business analyst or paired developer scaffold the web layer from the generated Java Beans that represent the web services domain objects. Again, this light-weight approach takes minutes to create the functional prototype to be used to validate requirements.
Perhaps the best part of using MyEclipse for Spring to scaffold and validate functional requirements is that the scaffold can be re-used and extended in the build phase of the project. In essence, the time invested during the conceptual phase to validate the functional requirements with scaffold prototypes is gained back from reduced build time required - and you have visually validated the functional requirements before starting the build phase of your software development life cycle.
Try it Yourself
MyEclipse for Spring is available for a free, 30-day trial. Start creating your own functional prototypes by downloading from http://www.myeclipseide.com/module-htmlpages-display-pid-4.html.