The Application Lifecycle Methodology (ALM), which comprises the adoption of various “development models”, has a tremendous impact on solution delivery within any organization.
The most common is Agile; however agile has many moving parts and often the existing PDLC, ALM or SLDC in many organizations struggle with the selection of the right model.
The ability to select the right development for the right project is critical.
It is not a one-size fits all mentality; rather those decisions are made based on requirements triage, development team experience (developer skill), referenced projects (prior applications), and a well-established code-base from which to draw.
This is the area most affecting the lead-time, delivery estimates, defect rates and user acceptance satisfaction on projects underway within many companies today. Conversely it is also the area, which represents the highest opportunity for delivery effectiveness within an organization.
Development Methods Affecting an Organization
Life cycle models (the methods used to develop), describe the interrelationships between software development phases. The common life cycle models are:
- Spiral model
- Waterfall model
- Throwaway prototyping model
- Evolutionary prototyping model (eXtreme programming)
- Incremental/iterative development
- Automated software synthesis
Currently most organizations have implemented a custom adaptation of a waterfall model in some form, even though they like to think of it as Agile, in many cases it is not. This form of adaptation involves a combination of several elements of other models across the java solution delivery development process.
Hybrid SDLC using Development Models
While this hybrid model can be effective, like most document-centric methodologies (waterfall), there can be large gaps between outputs due the longer and more rigorous timeframes associated with review, comment, revisions and ratification of functional and system specification artifacts.
To provide context for the analysis performed within this article; these life cycle models are described in very general terms, the models are adaptable and their implementation details at within an organization will vary based on the introduction of new java frameworks – such as “Spring”. More than ever before, any adaptation or combination of models will evolve over time, and will impact the current delivery timelines and estimates for solution delivery within any organization.
The spiral model is the perhaps the model which reflects reality at within an organization today. Most life cycle models can in fact be derived as special instances of the spiral model. Many organizations have elected to mix and match different life cycle models to develop a model more tailored to their java solutions and development capabilities.
A software life cycle model depicts the significant phases or activities of a software project from conception until the product is retired. It specifies the relationships between project phases, including transition criteria, feedback mechanisms, milestones, baselines, reviews, and deliverables. Typically, a life cycle model addresses the following phases of a software project: requirements phase, design phase, implementation, integration, testing, operations and maintenance. Much of the motivation behind utilizing a life cycle model is to provide structure and consistency within an organization. In this aspect, many organizations have developed a sound understanding of the importance of the development model.
Spiral Model
The spiral model is the most generic of the models. Agile by design adopts this as a baseline from which it was founded.
Most life cycle models can be derived as special cases of the spiral model. The spiral model uses a risk management approach to software development. Some advantages of the spiral model are:
- Defers elaboration of low risk software elements
- Incorporates prototyping as a risk reduction strategy
- Provides an early focus to reusable software
- Accommodates life-cycle evolution, growth, and requirement changes
- Incorporates software quality objectives into the product
- Focuses on early error detection and design flaws
- Establishes completion criteria for each project activity
- Uses identical approaches for development and maintenance
- Can be used for both internal projects and external adoption of outsourced system development projects
While this model is well suited for most companies based on their current processes and organizational structure, many companies run the risk of investing too much time in design, which can impact the timeliness of projects, which rely on custom java development.
Waterfall Model
While this model is the least flexible, it is (has) been used since 1970; hence considered by many people to be obsolete. Waterfall is typically well suited for projects that require low risk – such as highly visible initiatives with tight scrutiny. Within most organizations this adaptation has been developed based on compliance to corporate accessibility standards, user interface criteria and engineering constraints.
While this adaptation is used extensively to help mitigate risk, the benefits gained in control over budget and schedule greatly impact delivery time and developer creativity.
With the evolution of java-centric solutions and SOA, a hybrid model has emerged. As previously mentioned, the adoption of agile (using variations such as spiral), is maturing and will continue to evolve over the long-term.
Throwaway Prototyping Model
This model is not being used in many organizations today. It is useful in “proof of concept” or situations where requirements and user’s needs are unclear or poorly specified. The approach is to construct a “quick and dirty” partial implementation of the system during or before the requirements phase.
Often, this model does not employ the use of wireframes or mash-ups. In some cases turnkey open-source solutions are used to provide a context to help vet the initial requirements. Other approaches include duplication of existing applications with minor modifications based on workshops with the user to create a “vision” for the solution.
In some cases, the output of this approach may result in the abandonment of the initiatives since it tests the feasibility of the product before formal project instantiation.
Within any organization the engineered infrastructure to support “non-production applications” is adequate; however the culture within the organization often lacks flexibility to allow the developer the capacity to fully support a “throwaway” model. It may be worthwhile to examine existing developer skills to determine the capacity associated with this type of development and adjust the development lifecycle to accommodate this approach.
Evolutionary Prototyping Model
This model is often applied to “pathfinder projects”, which have a low risk, a floating budget, and a flexible schedule. Predictability and control, large-system integration problems, or coping with information gaps are not well suited for this model. Often this model will introduce new technologies, frameworks, bolt-ons, or high-risk technologies applied to the development of new user interface design, such mobility (smart phones or web-tablets).
This model can provide options, which were not previously considered within many organizations. Iterations of a product produce a series of “prototypes” which are used to understand the “feasibility” of formalizing the initiative (or solution). Once ratified and the benefit / risk assessment is made, a decision to move forward and initiate a custom development project can be formulated. This model is typically used to introduce new and emerging technologies, frameworks, middleware, appliance-based solutions and/or turnkey systems.
With ever increasing demands for innovation from the client community; most organizations will be forced to experiment with this style of development. Depending on the current capacity of the java development team, there may be limited room for this type of development since deadlines consume most of the focus based on current demands and existing projects.
Incremental/iterative Development
This model involves processes for constructing several partial deliverables, each having incrementally more functionality. This is a model well understood within many shops and is more than likely viewed as the current process. Often it will be in a state flux due to constant fine-tuning using internal projects as the catalyst for change.
If a hybrid waterfall model in place, many development shops have adapted to support this style of development with success. In all cases, this is the preferred approach, which has historically been used on custom development projects within most organizations.
As stated previously, it is not a one-size fits all circumstance. Incremental or iterative development styles have a place; however if selected for all requests put forward within any organization impacts will be felt on schedule and budget.
For obvious reasons, this model fits nicely with the project disciplines in use across most shops today, since it is tightly aligned to various project phases within a waterfall SDLC.
Care should be taken in determining the design detail for artifacts which support the various aspects of this model within an organization. If too much weight is being given to “paper-based” deliverables rather than usable objects (wireframes, mash-ups, mock-ups and component reuse), then timelines will suffer.
Automated Software Synthesis
This process relies on tools to transform requirements into operational code. Formal requirements are created and maintained using specification tools. This is an active research area, and practical tools for this approach are yet to be refined.
Vendors, like IBM have developed tightly integrated suites intended to provide some of these capabilities (Rational toolset). In the java world, Oracle has come along way in providing such capabilities as well.
Many organizations have an investment in both Oracle and IBM. From a pure java perspective, Business Process Modeling (BPM) tools are available which can be used to generate code, in addition there are third-party commercially available tools which can also provide pure java object classes.
Java code generation by definition is always going to be much faster than hand coding. With a reasonable large (over 20 tables) database, there is approximately a twenty-fold productivity increase. Java code generation approaches provide a faster and cheaper application development environment, higher quality applications, more predictable and consistent results, faster software product development cycle times, faster time to deploy, reduced project costs, and reduced project risks.
In order for these code generators to be successful, they require a sound mechanism to capture requirements in a consistent manner. In addition, they must be tweaked, (tuned for), the characteristics of the environment in whch they operate.
Code generation is tightly coupled to the Application Architecture disciplines, which have been established within an organization. It is these same disciplines, which guide the configuration of the generated code, the integration characteristics of the application and the inter-operability across applications. Key technical features offered by such tools include:
- Spring MVC scaffolding capabilities for generating Spring-based, Java CRUD applications from new or pre-existing domain models
- Integration with IBM Rational Software Architect 7.5.2 to transform UML into working Spring applications
- Spring Web Flow support and visual flow editor
- DWR (JavaScript/JSON) support for accelerating RIA development using Spring services
- Integration with existing Java code, data objects and Spring Beans
- Code generation customization for generating Spring MVC and Spring Web Flow solutions that adhere to your own coding standards
- Runtime using Spring Framework 2.5 (w/ Hibernate JPA)
While there may be long-term benefits by adopting tools and technologies which can assist in streamlining code, the quality and throughput of the development organization is a key consideration when selecting these technologies.
The procurement constraints associated with tendering for these technologies outweigh the short-term benefits at this time for many organizations. The maturity required to install, configure and maintain these tools would not warrant the investment; however it should be investigated further through existing vendor channels, Request For Information (RFI), and informal vendor briefings.
The Spring framework contains a Aspect-Oriented-Programming (AOP) capabilities which can also support a higher degree of code reuse across development projects and therefore is a preferred option to support the known and established development models in most companies today.
Driven by Unified Modeling Language (UML), these products are able to use visualization techniques via modeling tools to generate classes based on use cases.