4.2 Systems Development Methods4.2.1 IntroductionA 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 ModelThe 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.
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 DesignParticipatory 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).
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 :
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 ModelThe 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.
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 DevelopmentRapid 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 FrameworkShared 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.
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 ModelingSolution 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.
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 ConclusionAs 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) |