Software/Systesm Development Life Cycle (Part II)

The classical or legacy attitude approach to information systems development has to be reengineered, as mentioned in many places in these assignments. But not just that. The classical "waterfall methodology" needs to be also reengineered, because it has major limitations that ultimately lead to end-user dissatisfaction, as a minimum, not talking about the business impact, as above exposed. The following are described in quite detail, two modern approaches.

Rapid Application Development—RAD for short—is an approach to building computer systems which combines Computer-Assisted Software Engineering (CASE) tools and techniques, user-driven prototyping, and stringent project delivery time limits into a potent, tested, reliable formula for top-notch quality and productivity. RAD drastically raises the quality of finished systems while reducing the time it takes to build them.

The typical RAD project delivers a fully functional computer system—not a prototype or a toy, but a real system that does real work for the organization—in 90 days, give or take 30. System developer productivity on RAD projects, as measured on hundreds of projects, exceeds productivity on traditionally managed projects by a factor of 10 to 25.

The RAD philosophy and techniques that enable a shop to consistently build systems faster and better, practiced on a small scale, result in a shop that's doing things a little bit better overall. The RAD techniques are learnable and repeatable. On a large scale, they are equivalent of Business Process Redesign (BPR) for an Information Systems (IS) organization, and as such they can transform the organization in profound ways. By BPR, we mean a fundamental reexamination of the work process in an organization.

Gartner Group noted recently that "Many of the business processes devised after World War II...have remained essentially the same. Corporations are now finding that work organized stepwise, incurs unavoidable delays and errors as paper is handed off from person to person and unit to unit...." Garner Group further notes that "information Technology is a key enabler of BPR. IT is the single most powerful tool for breaking traditional assumptions and rules about business, and it is the tool that makes new ways of operation possible."

It is fair to say that the processes used to organize and carry out work in most IS organizations have not changed substantially in the last 25 years. (Not coincidentally, many IS organizations are essentially structured around systems built 25 years ago.) This is so even though the tools and techniques available to restructure the work process in IS have changed at least as dramatically as those available to the rest of the organization.

RAD takes advantage of automated tools and techniques to restructure the process of building systems. This new process, extrapolated to the entire IS organization, results in a profound transformation of IS. The transformation can occur in at least two ways:

Stability. RAD replaces hand-design and coding processes—which , like it or not, are utterly dependent on the talents of isolated individuals—with automated design and coding. This process is inherently much more stable and predictable than hand-design and coding techniques. Because a process isn't really subject to improvement until it's stabilized, RAD can give an IS organization its first real basis for continuous improvement.

Capability. The RAD process is not only more stable; it is a more capable process. IT concentrates human beings on business issues and relies on machines to translate business decisions into working systems. This process is faster and much less error prone than hand coding.

BPR is not trivial. Taking RAD to this level will require plenty of management effort to prepare the IS organization for major change.

At the project development level, RAD has been described as "automated Joint Application Development (JAD) with a time limit. The description id oversimplified, but is makes a good starting point for discussion.

JAD is a process developed by IBM in the late 1970s to enable rapid definition of requirements for computer systems. The process has several key components:

• Explicit, early identification of project objectives and scope, as defined by key players, such as the project sponsor.

• Use of a neutral facilitator to drive development of system requirements in consensus-based group meetings. These meetings are typically conducted in "JAD sessions" which last from 1 to 3 days. Each session is tightly focused on a specific set of deliverables, A project large enough to require many JAD sessions may be broken down into smaller pieces, each requiring a few sessions to complete. In this way, JAD can be used to develop requirements for very large systems.

• Heavy reliance on group agendas and ground rules to focus JAD session discussions on issues related to project requirements and to drive private agendas out into the open.

• Heavy use of administrative support personnel to enable rapid (overnight or better) turnaround of documentation from JAD sessions to all interested parties (i.e., participants and sponsors).

JAD has been used in various incarnations in hundreds or organizations in the last 10 years, and it is an established part of the requirements development process in many companies, with good reason. The techniques can be learned and repeated and are measurably effective at improving both the speed and quality of the requirements definition process.

JAD by itself, however, is insufficient for RAD because it stops at the point when requirements for a project are delivered to a development team. RAD doesn't stop until a working system is hands of the users. This is where the "automated" part of our simplified definition of RAD comes in.

RAD uses the requirements documents produced during JAD—data models and definitions, process models and descriptions, screen and report layouts, business rules, etc.,—as input to intelligent code generators which automate the process of producing computer-readable code. It is only in the last few years that tools (such as Knowledgeware's Information Engineering Workbench and Texas Instruments's Information Engineering Facility) have appeared on the market which are flexible enough to capture a full range of requirements and intelligent enough to generate solid code from those requirements definition. JAD provides the means to improve the quality and speed of requirements development; the new, powerful tools extend that quality and speed right through to delivery of a functioning system. Automation of this part of the systems development process is critical to the speed demanded by RAD. Experienced practitioners state flatly that RAD can't be done in a hand-coding environment.

The key tactical element in RAD development is iterative prototyping of the full system. The development team concentrates on delivering a series of fully functional prototypes to designated user experts. Each prototype is tested by those users, critiqued, and returned as soon as possible—generally within a day or two—to the development team for reworking, at which point the cycle repeats. The series of prototypes evolves quickly into a version which is fully acceptable to the users, and this version is implemented as the first production release of the system.

The final element of this simplified description—the time limit—is perhaps the most important. RAD demands that a fully functional system be delivered in 60 to 120 days. This limits both the size and type of projects that can be done successfully with RAD. RAD is not well suited to development of highly complex technical software, such as a computer operating system. It is very well suited to development of carefully scoped business applications. As with JAD, large applications can sometimes be broken down into pieces that can be attacked separately via RAD. If not, RAD won't work.

The time limit—called a "timebox" in the earliest RAD projects—is so important that it overrides all other considerations in a RAD project. When the project scope conflicts with the time limit, the scope is reduced to fit the time limit.

A few additional elements are necessary to complete the definition of RAD at the project level:

• RAD assumes a small team—one to six—of highly trained developers. The team should include individuals with extensive experience in system analysis and design, JAD techniques, the automated tool set, and the business area for which the system is being developed. Ideally, more than one person is capable in any given skill.

• RAD team members are assigned to a project full-time. They are empowered to do what needs to be done, when it needs to be done, to complete the job.

• Every RAD team includes at least one full-time user participant, whose roles include both initial requirements definition and feedback on successive prototype versions.

RAD as a means to transforming the organization (i.e., as BPR) is probably impossible in an organization that has not already succeeded in making RAD work at the project level. Without that success at the primary level, it's hard to create the organizational environment that fosters a continuous cycle of experiments, learning, and scaling up of successful methods and techniques.

That said, the key differences between RAD at the project level and RAD at the organization level are environmental. The RAD project team, at least initially, relies on its own resources. The team builds most of what it needs on its own resources. The team builds most of what it needs to get the job done, assisted by powerful tools. This is necessary because the systems environment surrounding the first RAD projects in almost any organization is not organized in a way RAD projects in almost any organization is not organized in a way that makes it easy for the team to use existing resources.

The successful RAD organization has created an environment in which powerful, highly organized resources for systems development can be used and reused by every RAD project team. The team need not create database models and designs from scratch; such designs are readily available and can be used as is or with slight modifications. The team's tools, in addition to generating necessary procedural code, can access libraries of code already written, quality-checked, and catalogued for reuse. The resources of the organization are focused on improving both the quality and flexibility of this organized resource for development and the skills of the people who work within it.

In effect, the RAD organization is a highly organized, continuously improving factory for software development. The available literature on Total Quality Management describes continuous improvement extensively. The philosophy of continuous improvement is at odds with the traditional systems development in a number of respects:

• Traditional systems development relies heavily on had coding to deliver systems.

• Traditional systems development treats each new system as a unique problem to be attacked on its own terms.

• Traditional systems development delivers finished systems at long intervals, with few interim products to provide bases for discussion between development personnel and business users.

Traditional systems development methods are dangerously outmoded in a world that is moving toward power tools for systems development operated by hybrid trained people in a highly organized environment. Systems development managers who think otherwise are invited to bet their careers, and probably their companies as well, on their opinions.

The components of the RAD environment which must be implemented over time to support continuous improvement of systems development process at the organizational level are:

An ongoing measurement program that measures and compares effort and quality within and across projects.

Well-documented processes for performing the tasks associated with developing and maintaining systems.

Inventories of reusable systems components. Line any inventory, these must be organized, catalogued, and checked periodically to ensure that the inventory is not damaged or otherwise useless.

Components that can be stored for reuse include business- and systems-level designs, such as:

Business models. Graphic and textual descriptions of the information flow between business units, including units external to the organization.

Data models. Graphic and textual descriptions of the information used by the organization and of its structure and meaning.

Process models. Graphic and textual descriptions of the functions performed by the business, the activities and tasks which comprise those functions, and the relationship between those functions in terms of inputs and outputs.

Other components of the RAD environment include:

An ongoing commitment to training. This includes training in both technologies and methods, specifically including methods derived from in-house experiences.

Extensive automation of analysis, design, and coding via CASE tools. These tools are tightly intertwined with the reusable inventory described above. they are to analyze, design, and created that inventory, and they draw from the inventory in creating new systems.

Standards for interfaces between systems components. The systems world is becoming a very complex place. A single client-server application may span three or more operating systems platforms, database management systems, and computer languages. Without standard protocols for communications and exchanges between those components, technical issue can become overwhelming.

The other popular alternative to the classical ‘waterfall methodology" that actually works in conjunction with RAD and JAD is Prototyping. Although the word "prototyping" has not made it into the dictionary yet, Webster has several definitions for the noun "prototype." The last applies best.

prototype: a first full-scale and usually functional form of a new type or design of a construction (as an airplane).

We in Information Systems (IS) are not the first to use the word "prototype," anymore than we are first to prototype. As Webster notes, our friends in aerospace build prototypes, and they started long before we did.

In particular, "software prototyping," may be defined as follows:

Software prototyping is an information system development methodology based on building and using a model of a system for designing, implementing, testing, and installing the system.

Prototyping is a methodology. Since a methodology is a collection of methods, you may organize the methods into steps. You may write them down in the order in which they should be executed. You may teach both the steps and the order in which they should be done. Prototyping is done in a systematic way, and that way can be described, i.e., can be taught, scheduled, measured, compared, and modified - which are the components of any methodology.

Prototyping, as a methodology is important in building fast, better, more reliable, better quality systems. Here is why and how that can be achieved.

Prototyping is based on building a model of a system to be developed. Moreover, the initial model should include the major program modules, the database, screens, reports, and the inputs and outputs that the system will use for communicating with other (interfacing) systems.

Prototyping uses the model for designing the system. The initial version of the prototype is not full system, but it does contain its designer's understanding of the database, screens, and reports. As the user and Information Systems people begin to work with the prototype, it will change. The initial version of the prototype is a skeletal version of the system; it does not contain all the processing and validation rules that the system will ultimately have. As those working with the prototype modify it and add to it, they will be completing the design of the system. So, the prototype will be a vehicle for designing the final version of the system.

Prototyping uses the model to implement the system. In today's average organization, you write programs in some problem solution language, such as COBOL, to implement a system. The initial version of the prototype will consist of programs written in some language (possible a fourth generation language) to move data back and forth between the screens, the database, reports, and the inputs and outputs used to communicate with interfacing systems. At first, these programs may do little processing; they may actually dummy it. As prototyping process continues, newer versions of programs, that perform more closely to those of the ultimate system, will replace the original versions. For example, a program that actually extracts data for a report from a database may replace one that dummied out data.

Prototyping uses the model to perform both the system and the acceptance testing of the system. The initial version of the prototype, as well as all subsequent versions, will communicate with system test versions of feeding systems and systems to be fed. So, the prototyping will always run in "system test" mode. And, since the user will be working with the prototype from the beginning, the user will be performing "acceptance testing" of the prototype from the beginning.

Prototyping does not go beyond a mock-up if, after building and experimenting with the initial model of the system, and possibly making a few modifications to it, you abandon it when you have gained a good understanding of the requirements. A prototype as a mock-up is valuable. With the Prototyping Methodology, even though a prototype may be little more than a mock-up when it is first built, it becomes the first one of its kind by the time it is finished. So, when the prototyping process ends, the prototype has become the system.

The prototyping as a methodology evolved from the engineering discipline. Even more, a classical life cycle had been a prerequisite to prototyping. If the present system is to be studied, Information Systems professionals usually do it. The present system may be manual or a combination of manual and office machine processes. In most of today's medium to large size organizations, systems also contain some computerized processes.

The components of Systems Development Methodology are: Study Present System, Determine Feasibility of New System, Define Requirements, Design, Program, Test, Acceptance Test, Train Users, Convert from Old System, Install. The plan for a classical, non-prototyping "life cycle" style project should look something like the process just previously described: linear, perhaps containing couple of iterations. In a "life cycle" methodology, the various project phases usually follow each other serially. About the only overlapping that is done is training the users at the same time as converting to the new system.

The "life cycle" methodologies emphasize scheduling and meeting milestones, producing documentation at the milestones and getting signoffs on it, no signoff being more important than the user's signoff of the requirements or the final acceptance of the product.

The steps described above for the "life cycle" methodologies, are still being followed by the prototyping methodology. The only difference is the overlapping. One thing that is different about the prototyping is therefore the overlapping of most of the project phases with each other. This implies that prototyping provides the iteration which is often sought in developing Information Systems. Actually, prototyping provides more than an iteration of phases; it provides a continuation of phases.

The requirements definition begins after the present system has been studied. Before the requirements definition is completed, the design begins. Soon after it has begun, the programming begins. Shortly after that the testing, acceptance testing, the user training begin. The milestone dates for completing the requirements definition, design, programming, testing, and acceptance testing are usually the same date. The completion of user training is probably the same date as the completion of conversion. Installation begins after that.

The prototyping methodology emphasizes the streamlined aspect. The streamlined phases are: Define Prototype, Build Prototype, Exercise Prototype.

Currently Prototyping Methodology is having a larger and larger use in more and more organization. Part of the reason is the creation of software tools that allow the implementation of such methodology or approach to develop software.

Also, because the above described Prototyping Methodology presents the following principal advantages:

• Please users

• Reduces development cost

• Decreases communication problems

• Lowers operations costs

• Slashes calendar time required

• Produces the right system the first time

• Cuts manpower needed.

However, Prototyping Methodology has also disadvantages. Her are some of the possible ones:

• Visible use of computer resources

• Object system may be less efficient

• Requires cooperation between user and Information Systems

• Some view prototyping as an art not a methodology.

The current methodologies, as said, have a series of problems. Here is a partial list:

• Are thorough BUT DON'T please users

• Produce extensive documentation BUT DON'T decrease communication problems

• Identify project steps BUT DON'T decrease calendar time needed

• Describe system thoroughly BUT DON'T guarantee it's the right system

• Delineate skills needed BUT DON'T cut manpower needed

• Track project costs BUT DON'T reduce them.