The systems development lifecycle (SDLC) is a broad term that encompasses the methods that an organization uses to design, deploy, and maintain the systems that fulfill the information technology (IT) and business strategies. Hoffer, George, and Valacich (2010) define the systems development lifecycle as, “the traditional methodology used to develop, maintain, and replace information systems” (Hoffer, George, and Valcich, 2010, p. 7). One of the key phases of the SDLC is systems analysis and design, which focuses on gathering and analysis of requirements and design of information systems to meet those requirements. Many methodologies have been developed to provide or improve upon systems analysis and design processes. One of the systems analysis and design methodologies is model-driven development (MDD). “Model-driven development: the good, the bad, and the ugly,” by Hailpern and Tarr provides an overview and critique of the model-driven development methodology for systems analysis and design. (Hailpern and Tarr, 2006). An analysis of the Hailpern and Tarr article provides an understanding of the role of model-driven development within the systems development lifecycle.
Hailpern and Tarr begin their review of MDD by defining model-driven development and introducing the key concepts using pseudo-formal notation that borrows from graph theory. Hailpern and Tarr’s definition of MDD is,
A software engineering approach consisting of the application of models and model technologies to raise the level of abstraction at which developers create and evolve software, with the goal of both simplifying (making easier) and formalizing (standardizing, so that automation is possible) the various activities and tasks that comprise the software life cycle (Hailpern and Tarr, 2006, p. 452).
The authors proceed with discussion of the benefits (the good), the harms (the bad), and the challenges (the ugly) that organizations face when implementing the MDD approach.
Hailpern and Tarr’s discussion of the benefits of MDD focuses on the goal of simplification by increased abstraction that results in decreased developer effort and decreased complexity (Hailpern and Tarr, 2006). The authors draw upon the improvements brought about by third generation programming languages like Fortran and Cobol, as well as object-oriented languages like Smalltalk, Simula, and C++, as compared with assembly language to demonstrate the potential that MDD offers. (Hailpern and Tarr, 2006) Hailpern and Tarr describe recent improvements in the Unified Modeling Language (UML) notation for an example of abstract modeling languages that may one day provide the “lingua franca” for systems development (Hailpern and Tarr, 2006).
Hailpern and Tarr describe four areas where MDD, as currently practiced, harms systems development lifecycles. The first harmful effect, as Hailpern and Tarr describe it, is redundancy (i.e., duplication of effort). Model-driven development necessitates, “representing different views of or levels of abstraction on the same concepts” (Hailpern and Tarr, 2006, p. 456). However, MDD seeks to decrease developer effort and, in practice, “to the extent that these are manually created, duplicate work and consistency management are required” (Hailpern and Tarr, 2006, p. 456). So, the practice model-driven development with tools that exist today creates redundancy that is contrary to the methodology’s stated goals. The second harmful effect from MDD discussed in the article is, “rampant round-trip problems” (Hailpern and Tarr, 2006). The issue associated with round-trip problems is centered on the importance of traceability to model-driven development. As the authors state, “the round-trip problem occurs whenever an interrelated artifact changes in ways that affect some or all of its related artifacts” (Hailpern and Tarr, 2006, p. 457). Ensuring that consistency is maintained across all interrelated artifacts is a difficult problem for existing tools and techniques. The third harmful effect of model-driven development derives from the possibility of moving complexity rather than reducing complexity. MDD seeks to reduce complexity through abstraction. However, oversimplification and overgeneralization when performing abstraction may result in greater complexity during implementation. If the abstraction of the models is overly simplistic, what appears to be reduction in complexity is, effectively, moving complexity to the implementation phase of the SDLC (Hailper and Tarr, 2006). The fourth and final harm identified by Hailpern and Tarr is an increase in the level of expertise required to develop systems. While MDD enables subject matter experts to be more focused on the abstractions specific to their tasks, “the interrelationships between multiple types of models, and potentially, different modeling formalisms, suggests that it will be difficult for any given stakeholder […] to understand the impact of a proposed change on all of the related artifacts” (Hailpern and Tarr, 2006, p. 458) Successful use of model-driven development, in practice, requires stakeholders to have greater expertise.
Hailpern and Tarr identify one outstanding challenge associated with adopting a model-driven development approach, which they refer to as, “the ugly” in the article title (Hailpern and Tarr, 2006). The challenge is that the current languages and notation, namely UML, are not sufficient to support successful achievement of MDD’s goals of simplification and automation. While UML and other modeling notations are being actively developed and refined, Hailpern and Tarr note that, “UML – or any other MDD language – faces significant hurdles to demonstrate sufficient value to satisfy the needs of all the different kinds of MDD users” (Hailpern and Tarr, 2006, p. 459).
Hoffer, George, and Valacich (2010) do not specifically address the model-driven development approach in their discussion of the systems development lifecycle (Hoffer, George, and Valachich, 2010). However, Hoffer et al do discuss the role of MDD’s fore-runner, Computer Aided Software Engineering (CASE). In addition, Hoffer et al discuss object-oriented development approaches such as the Rational Unified Process, which shares some aspects with MDD (Hoffer, George, and Valacich, 2010). Hailpern and Tarr note that MDD has the potential to succeed where CASE did not, but shares some of the same risks of failure (Hailpern and Tarr, 2006).
Model-driven development provides an approach to systems analysis and design that simplifies developer effort and enables increased automation, in theory. Hailpern and Tarr’s summary of MDD, “Model-driven development: the good, the bad, and the ugly,” provides an overview of the methodology along with a summary of the potential benefits, harms, and challenges facing organizations adopting this approach. Hailpern and Tarr’s article is a good review of MDD and the associated risks. MDD as summarized by Hailpern and Tarr represents an approach to systems analysis and design that could be integrated into Hoffer et al’s generic SDLC methodology in place of CASE or RUP (the approaches that Hoffer et al discuss).
Hailpern, B., & Tarr, P. (2006). Model-driven development: The good, the bad, and the ugly. IBM Systems Journal, 45(3), 451-461. Retrieved from http://ezproxy.library.capella.edu/login?url=http://search.ebscohost.com/login.aspx?direct=true&db=bth&AN=22198515&site=ehost-live&scope=site
Hoffer, J. A., George, J. F., & Valacich, J. S. (2010). Modern systems analysis and design (Sixth ed.). Upper Saddle River, NJ: Prentice Hall.