4.2 Systems Development Methods

4.2 Systems Development Methods

4.2.1 Introduction

A systems development method (SDM) is a work discipline chosen by product developers as a way to ensure successful results. Typically, an SDM specifies a series of stages that include information gathering, designing, developing, testing, delivering, maintaining, and enhancing a system or product.

Before SDMs came into being, developing new systems or products required using the experience and intuition of management and technical personnel. Still, development often took place in a rather chaotic and haphazard manner. With no existing models to use, and no similar practices taking place in other industries, systems developers had to guess when creating systems. Development often occurred in a vacuum , in a world without any predetermined rules or methods. The early systems that were developed reflected this lack of governance. Many were poorly conceived, crudely designed, and subsequently prone to almost constant maintenance and repair.

Fortunately, this time period did not last very long. Because systems developers tend to be somewhat organized in their practices, the early pioneers realized that creating effective and efficient systems required developing and consistently applying useful rules and procedures. The complexity of modern systems and computer products long ago made the need clear for some kind of orderly development process to enable complex solutions.

Frequently, several models are combined into some sort of hybrid process. Record-keeping is important regardless of the type of SDM chosen or devised for any application, and is usually done in parallel with the development process. The choice of method is typically done under time and/or resource constraints.

In this section, we'll take a look at some of the most commonly used development models to see which aspects of them work and which do not, with specific regard to how SDMs can be applied to develop humancentric solutions.

4.2.2 Waterfall Model

The waterfall model, also referred to as the systems development life cycle model (SDLC), is one of the oldest SDMs and is still probably the most commonly used. It provides a linear sequence of steps that progress from start to finish, with distinct goals for each phase of development. Imagine a waterfall. Once the water has flowed over the edge of the cliff, it cannot turn back. It is the same with waterfall development. Once a phase of development is completed, the development proceeds to the next phase and there is no turning back.

The advantage of waterfall development is that it allows for departmentalization and managerial control. A schedule can be set with deadlines for each stage of development, and a product can proceed through the development process like a car in a carwash, and theoretically, be delivered on time. Development moves from concept, through design, implementation, testing, installation, and troubleshooting, and ends up at operation and maintenance. Each phase of development proceeds in strict order, without any overlaps or iterations.

Typically, the following steps are used in the waterfall model.

  • First, the existing system is evaluated and deficiencies are identified. New system requirements are defined, using the deficiencies in the existing system to propose improvements.

  • Next, the new system is designed. The design provides the complete architecture, including hardware, software, and infrastructure.

  • Once the design is ready, development can start. The new components and programs must be obtained and installed. Users of the system must be trained in its use, and all aspects of performance must be tested . If necessary, adjustments are made at this stage.

  • After the test, the system is put into use. This can be done in various ways. The new system can be phased in, according to application or location, and the old system gradually replaced . In some cases, it may be more cost effective to shut down the old system and implement the new system all at once.

  • After a certain period of time, the new system should be exhaustively evaluated. Maintenance must be kept up rigorously at all times. Users of the system should be kept up to date concerning the latest modifications and procedures.

The disadvantage of waterfall development is that it does not allow for much reflection or revision (it would be like climbing the waterfall to change something). It does not allow sufficiently for error discovery and redesign. Once a development stage has been completed, it is very difficult to go back and change something that was not well thought out in the previous stage.

Perhaps the greatest deficiency of the waterfall approach for designing me-centric devices is the assumption that one can conceive a successful user interface at the outset, without experimentation and iteration. That assumption generally proves incorrect. As a result, waterfall design practices work well only for familiar, well-trodden paths.

4.2.3 Participatory Design

Participatory design is a technique in which representative users provide continual feedback to designers as they develop preliminary prototypes in low-fidelity media (e.g., pencil and paper). It can be seen as a democratic approach to design, which encourages participation in the design process by a wide variety of stakeholders, such as designers, developers, management, users, customers, salespeople, and distributors . It enables technical and non-technical project members to participate equally.

This method gives users an opportunity to interact and make suggestions for the product before those suggestions are codified into a program. Often these interactions lead to practical improvements based on user suggestions. Such improvements can result in a product that better fits the need underlying the user's suggestion, as opposed to merely following the suggestion itself. The approach stresses making users not simply the subjects of user testing, but actually empowering them to be a part of the design and decision-making process. Studies have shown that systems designed using mental modeling techniques are better, it's advisable to use a feedback loop such as participatory design before implementing user suggestions in a final product. This proactive user input can both result in better designs and help shorten product development and testing cycles.

At Bellcore [3] , for example, software engineers and prospective users play games in the labs. These games are tools to help the developers, with variables specific to a product, to help design the product. These game methodologies included PANDA (Participatory Analysis, Design, and Assessment), CARD (Collaborative Analysis of Requirements and Design), and PICTIVE (Plastic Interface for Collaborative Technology Initiative through Video Exploration).

[3] http://www.bellcore.com/

Although the focus and precise rules of these games vary, they have the following common properties: engineers and end-users working together on a design, using low-tech tools like different colors of index cards, sticky notes, and felt pens; an initial focus on user tasks quite apart from GUI design; and resultant software specs that demonstrably shorten GUI development and testing cycles.

A complete participatory design exercise always includes the following top-level outcomes :

  • Task flows Task flows describe what the users want to accomplish with the proposed tool. These flows do not refer to underlying system architecture or data representations but describe the real-world steps the user must go through in any environment.

  • Task object design Task object design describes the attributes and actions for each task object and regroups them, eliminating redundancies as they appear, into a hierarchy of parent and child objects.

  • GUI object design GUI object definition translates their task objects into screens, lists, and controls and their representation.

This paper prototype, consisting of sketches , block diagrams of screens, and textual descriptions of the behavior, is handed over to the development team. This input is used to improve the design.

4.2.4 Exploratory Model

The exploratory model consists of planning and trying different designs until one of them seems to be the right one to develop. This model works best in situations where few, or none, of the system or product requirements are known in detail ahead of time. This model is largely based on educated guesswork.

There are several steps in the exploratory model.

  • First of all, a starting point is determined for the work. All the information available is gathered together in an attempt to get an idea of what the new system will be expected to do, and how it can be done.

  • Once that has been done, a rudimentary first-generation system is put together, based on the information gathered and the ideas formulated in the first step.

  • It is then tested to see how it performs , what it can and cannot do, and what might be done to improve it.

  • Based on the feedback, a second-generation system is developed from the first one, based on the improvements proposed in the previous step.

  • It is tested, like the first. Its performance is again evaluated, and possible improvements are determined. This process is repeated as many times as necessary to obtain user satisfaction, or until it is decided that the project is unworkable.

This model resembles a prototyping approach, but it begins more nebulous and is less formal. It is not particularly cost effective and can result in less-than -optimal systems, so it should be used only when no viable alternative seems to exist. It could be used, for example, in situations, where a company is trying to extend their business into a new focus area, with little or no knowledge in that area.

4.2.5 Rapid Application Development

Rapid Application Development (RAD) refers to a development life cycle designed to give much faster development and higher quality systems than the traditional life cycle. It is designed to take advantage of powerful development software like computer-aided software engineering (CASE) tools, prototyping tools, and code generators. The key objectives of RAD are: high speed, high quality, and low cost. These goals are achieved by gathering requirements using workshops or focus groups, by prototyping, and by engaging in early, reiterative user testing of designs, through the reuse of software components, a rigidly paced schedule that defers design improvements to the next product version, and less formality in reviews and other team communication.

RAD is a people-centered and incremental development approach. Active user involvement, as well as collaboration and cooperation between all stakeholders, are imperative. Testing is integrated throughout the development life cycle so that the system is tested and reviewed by both developers and users incrementally.

RAD is a methodology for compressing the analysis, design, build, and test phases into a series of short, iterative development cycles. This has a number of distinct advantages over the traditional sequential development model. RAD projects are typically staffed with small integrated teams comprised of developers, end-users, and IT technical resources. Small teams , combined with short, iterative development cycles, optimize speed, unity of vision and purpose, effective informal communication, and simple project management.

Historically, RAD systems have tended to emphasize reducing development time, sometimes at the expense of generating efficient executable code. Nowadays, though, many RAD systems produce extremely fast code. Conversely, many traditional programming environments now come with a number of visual tools to aid development. Therefore, the line between RAD systems and other development environments has become blurred.

4.2.6 Shared Meanings Design Framework

Shared Meanings Design Framework (SMDF) [4] is a novel HCI-centered methodology that was initially conceived to support the development of human-centered systems. The approach offers support for developers, as it is focused on the semantics (i.e., meanings) of an interface, both the intended and unintended meanings it transmits. This approach is derived from an explicit semiotic paradigm and is still under development.

[4] http://www.smdf.org/

SMDF seeks to support the development of systems that are semiotically and logically valid, which engender trust and security, are not overly complex in terms of surface features, and are culturally neutral. SMDF provides a set of tools and technologies to help developers build human-centered systems. Therefore, it provides tools for crosscultural design allowing for globalization and localization activities. To share the design with others, the Shared Meanings Markup Language (SMML) is being developed, and a Semiotic Textual Analysis (STA) tool is available for languages such as XML, XHTML, WML, and XSL.

Human-centered design is much more like designing for mass media than building a stakeholder-led application. Mass media has only an idea of the intended audience and the corresponding message. Semiotics has been successfully utilized to help make sense of such media.

4.2.7 Solution-Based Modeling

Solution Based Modeling (SBM) is a software development process by Neal Goldstein and Jeff Alger. [5] Their book, a bit overtaken by Rational Unified Processes (RUP) [6] , etc., had more of an outside-in design approach than RUP, more like Smalltalk than like Java. In fact, Smalltalk had one really key motivating concept: the simulation is the application.

[5] Neal Goldstein and Jeff Alger (1992), Developing Object-Oriented Software for the Macintosh , New York: Addison Wesley

[6] http://www.rational.com/products/rup/

SBM has its origins in the Macintosh software development community. It is based on the idea that any software development project is a process of constructing models . The models consist of elements, relationships among those elements, and frames . Elements include natural world and program objects, categories, and classes. The relationship between a pair of elements can be structural (e.g., membership, instance, container, whole-part), behavioral (e.g., collaboration, creation, destruction), or calibration (e.g., implement, replace, same as).

Their idea was to model the world and to let the user interact with and control it. The simple principle behind this dictates that we observe how users interact with the model, how they work to solve problems, and then we design in such a way that lets them work that way. That orientation towards creating an application was very much an early landmark on the path toward me-centric systems, since the user gets to interact with an interface that is (virtually) a direct control of entities that themselves interact in realistically physical and natural ways. Humans control the entities through the application's modelview-controller (MVC) paradigm.

4.2.8 Conclusion

As you can see it is possible to use any of the above approaches, but as mentioned some have more and some have fewer advantages when creating human-centered solutions. Important in any case is to keep the user in the loop to make sure that the system you are designing and implementing will be of use. Building without involving the target user group will make it at least twice as hard to be successful.

The key is the user and not the system. It used to be the other way round, and as a result, we now have personal computers with highly complex applications that require lots of training. Instead of training millions of users, the applications and devices should be trained to adapt.

Although financial success is not the primary motivation for many inventions , it helps to keep an eye on finances. This not only means that the company that will produce the device will make money, but it also means that the device and its associated services are financially accessible by the customers.

Therefore, one should not forget to set business goals. Invest in research about the target market, intended customers, and primary competition. It always helps to see what the competition is doing, learn from their mistakes, and make sure that your project is competitive. Once you know who your audience will be, you should investigate in more detail the cognitive, social, and physical aspects to understand how they can best be supported. Find out about their expectations, motivations, and technical abilities , and try to generalize usage behavior relative to a certain context.

Then the associated processes should be reviewed and the expectations actively managed. The design should include all experiences and interactions of the user with the device and/or service. Therefore, the SDMs that integrate the customers are best, as they allow the designer to verify whether every way in which the person sees and touches the product or service has been considered and designed into the solution. This enables continuous evaluation of the design, and in some SDMs the evaluation is done only after implementation. The evaluation should continue when the product has been launched into the market, as customer feedback throughout the life of the product can be used to enhance it over time.

A good evaluation of the product takes into account productivity, figures of merit (e.g., time, errors, learnability, design for guessing, and preference), usability testing techniques, and linking testing to specifications.

There are many tactics and tools for implementation. You need to take into account the relationships among design, evaluation, and implementation when creating a new solution. Make sure that the device and the application are independent, which allows for maximum reusability, but tie the interface as much as possible to the device to get the most from the device. Prototyping as proposed by some SDMs can also help to reduce the amount of rework when reviewing the product in a later development stage. Typical prototyping techniques include storyboarding, video, and rapid prototype implementations . These prototypes can be easily implemented through toolkits, such as MacApp, PowerPoint, and HyperCard. But prototypes can also be done on paper, with interactive sketches that show the key functionality. Usability testing gives people tasks to accomplish with prototypes and heuristic evaluations help experts make assessments based on guidelines. This catches major problems before costly development and focuses design priorities on people using the product, not the people designing it.

In the future, human software developers will act as consultants to users, who with little computer training will be able to develop their own programs. Such a system will contain the specification subsystem (which could use voice input, for example), the generation and optimization subsystem, and the runtime and lifetime management subsystem. The architecture of such a system would be a combination of current CASE technology and expert systems. This would make it easier for users to participate in the development of complex systems, as they could provide smaller parts of the overall system themselves.

While possible, this prospect is less compelling than the idea that users, or product designers will be able to put together appliances from a set of reusable building blocks that can be linked to known services, it provides the semantic linkages between the user interface and the functionality. Lots of tools and end-user applications today have a similar kind of GUI for building a customized application (e.g. with VisualBasic or simCity)



Radical Simplicity. Transforming Computers Into Me-centric Appliances
Radical Simplicity: Transforming Computers Into Me-centric Appliances (Hewlett-Packard Press Strategic Books)
ISBN: 0131002910
EAN: 2147483647
Year: 2002
Pages: 88

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net