Joint Application Development/Design

Emphasizes user involvement with software design

Joint Application Design™ (JAD) evolved in parallel with many of the software methodologies. “Joint” work became important as IT systems expanded to support multiple business areas. This became very important as organizations began to recognize that data values could be shared. Separate business areas were brought together to develop a shared understanding of their information. As IT departments became larger and more sophisticated, they also became more isolated. Joint design acknowledged that the IT team members needed to work closely with business subject matter experts (Wood and Silver, 1995). Using JAD or facilitated information gathering sessions for requirements elicitation was discussed in Chapter 4.

Rapid Application Development

Adds prototyping and faster development concepts

Rapid application development (RAD) approaches typically used JAD to speed up the development process. They were developed as an alternative to the structured waterfall/ IE, documentation-heavy approaches. With RAD came prototyping and a focus on involving users in the development/coding work. Groups of business people were brought together for extended JAD workshops where prototypes and system designs were agreed upon and quickly rolled out (McConnell, 1996). This approach is the forerunner to the latest group of methodologies known as agile.

Iterative/Incremental Development Approaches

Recognize the value of revisiting phases to catch missed requirements Break projects into smaller deliverables that can be implemented faster

Iterative is so named because to iterate is to repeat and rework based on the work from the first iteration. The phases are still used, but this approach recognizes that one phase of a project may not be completely finished before the next is started. It gives permission for the team to revisit earlier work to pick up missed pieces. Incremental approaches recommend breaking large products into pieces and building each piece to fit with the existing whole. Pieces are integrated as they are completed.

These development approaches have been very well accepted by most IT departments. Iterative approaches recognize that all requirements may not be completely discovered and detailed during the first attempt. As IT architects begin to design solutions to meet business requirements, they will find holes or inconsistencies. The iterative approach allows time for the BA to go back to requirements elicitation to fill in the pieces that are missing or unclear. Incremental work requires that an overall plan is developed and then broken into small, more manageable-size pieces. This approach allows functionality to be delivered to business people faster and helps the team to prioritize the most important work first.

Object-Oriented Analysis and Design

Introduced reusable components in program code

Utilizes the concept of encapsulation, making software components more independent

Building on the concept of IE and data-centric design, object-oriented (OO) techniques and approaches were developed. OO design creates software systems that are built in a modular fashion, allowing relatively independent pieces of code (objects) to communicate with each other (Jacobson, 1992). This approach caused a radical change in software coding. Programming languages (previously procedural) were created, allowing developers to build objects (small, independent pieces of code) that could be reused in other systems. Introducing true reusability into software development rapidly increased the speed at which software can be created. Once OO programming languages were proven successful, software analysis and design techniques were developed to make a smooth transition for IT teams. OO analysis models include class diagrams and use case descriptions. The Unified Modeling Language (UML) has been developed to provide consistency for OO analysis and design (www.uml.org).

Unfortunately, OO development has not met the promise of reusability. The emergence of service-oriented architecture (SOA) concepts is another attempt to increase the reusability and maintainability of software components.

In addition, OO analysis has not proven useful to most BAs. OO analysis diagrams are too technical for most business stakeholders. In addition, the transition from analysis (business requirements) to design (functional requirements) is still one of the most difficult tasks in the software development life cycle. Many methodologists have tried to develop methods and techniques for automating and easing this transition, but it remains a very complex, manual task that is best accomplished by a team of knowledgeable business analysis professionals and software architects.