Design Tools And Techniques Prototyping

Prototyping Tool

Design of mobile health technology

Plinio Pelegrini Morita , in Design for Health, 2020

The prototyping

Prototyping tools are critical for the design of mHealth apps, as they provide a customized environment for creating the design assets, as well as a platform for testing ideas and user interface with potential end users. The initial stages of prototyping exercise will likely be on paper, using sketches to organize the ideas and to share the thoughts with subject matter experts and representative users. As the fidelity of prototypes evolves, so will the tools that will be used to design the app. Platforms such as Adobe Illustrator or Sketch provide very comprehensive platforms for designers to convert lower fidelity prototypes into medium-to-high-fidelity prototypes. Figs. 5.4 and 5.5 provide examples of high-fidelity prototypes of breathe and the <30 Days app.

The prototypes need to be tested with representative end users and will need to be converted into interactive prototypes that could be presented to participants to allow the users to navigate through the different screens and to experience the app being designed. Through cognitive walkthroughs and usability testing, user performance metrics and user feedback can be collected to be used in the next iteration of the design (Wiklund et al., 2011). The prototyping software available on the market provides the necessary tools for easily transitioning from designing to user testing.

While many of these platforms have been on the market for years, it is important to search for the current gold standards and recent prototyping software. The design community is extremely active and collaborative, so always search for the best tool available at the moment. Some examples of prototyping tools that have been available on the market for several years include, but are not limited to Adobe Illustrator (Adobe, 2019), InVision (InVision, 2019), Axure (Axure, 2019), and Sketch (Sketch, 2019). InVision, for example, provides a comprehensive platform for transforming static assets (e.g., screenshots of the app being designed) into interactive prototypes that can be loaded on a smartphone and given to participants for user testing.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780128164273000051

Validating the Design

Karen Holtzblatt , Hugh Beyer , in Contextual Design (Second Edition), 2017

Building a paper prototype

A primary requirement of the prototyping process is ease and speed of building. Remember that part of the goal is to make it easy to try out design options with users—if it's too hard to build the prototype, people will be less willing to use them as design tools. Off-the-shelf stationary supplies, especially sticky notes in all their varieties, are the basic components of a paper prototype.

Rapid prototyping tools ⁶ are so easy to use these days that it's very tempting to build with them right from the start. Resist that temptation. Even if they were as fast as paper, they won't support the same kind of codesign conversation you'll get in paper. If you're skeptical, try two or three in paper, and a few using your tool of choice. Then, you decide.

A good paper prototype is clean but looks like it can be changed

The key for a successful prototype is to put everything that might have to move during the interview on its own sticky note. This includes pull-down menus, accordion boxes, and the objects of a direct-manipulation interface. (Anything you can drag-and-drop should be a sticky note that you can literally drag-and-drop.) The interviewer will fill in the content of the interface with the user's own data during the interview, so leave room for that. If your system is presenting content, you need to provide it written exactly as called for in the design. Print it and put it in the right place in the mockup. Take extra copies of UI elements, both to write the user's content on and so they can try out different things over the course of the interview.

If the product combines hardware and software (Fig. 17.3), use other kinds of props in addition to the paper mockup. Pens make good bar-code scanners; pen boxes make good handheld devices; and stationary boxes make good tablets. Excellent low-fidelity devices can be built with foam core. Sticky notes can be stuck to the user's own phone or tablet to test interfaces in the places and contexts of use for those devices.

The paper prototype represents the structure and the behavior of the proposed user interface. It's rough and handwritten, but neat and legible—the user needs to be able to read it. If you need to go out before all focus areas have been designed, the ones you didn't get to can be represented as a blank sticky note with a title bar—this gives enough structure to discuss the place with the user, should it be wanted. Organize the paper so that all the parts for a screen are together, with extra parts that appear on demand on a separate sheet. Put the screens in order of expected use. Make a copy of the final prototype and all its pieces for every user to be interviewed—you can copy the parts and cut them into pieces. You are pulling together a little interviewing packet complete with extra supplies for changes. Now you're ready for an interview.

Create a complete interview packet for each user—they write on the prototype!

Building a paper prototype

The screen: Use a sheet of card stock as the background to represent the screen, in whatever size fits your platform. This gives you a stiffer base to the prototype, which is useful when manipulating the parts during the interview.

Windows and panes: Use a sheet of paper or a large sticky note of about the same size as the card you're using for a screen. In the interview, watch for issues caused by multiple overlapping windows, if you're on a desktop, or for users getting lost in multiple panes, on a touch screen.

Decorate windows with a title bar and any permanent contents. Draw a menu bar and write in the names of pull-down menus. Draw scroll bars if any.

Tables and textual content: Often useful to have this on its own piece of paper. That makes it more convenient to swap in and out, and to replace with the user's own content. Bring extra to every interview.

Pull-down menus, including hamburger menus: The name of the pull-down menu goes on the window because it's always visible. The contents of the menu go on a smaller sticky note. Write the name of the pull-down menu at the top. In the interview, keep the menu to one side and put it on the window when the user clicks on pull-down icon to simulate pulling it down.

Tool pallets and button bars: If they are permanent, draw the space for them on the window but put each tool or button icon on its own sticky note (cut these small by hand). In the interview, you'll want to talk about what needs to go on the bar or pallet and having them on their own note makes it easier to reconfigure them. It also makes them appear more manipulable and inviting to press.

If you're designing a floating pallet, put the whole thing on its own sticky note. Either draw the tools on it directly or put them on their own small notes, if you want to design exactly what goes on the pallet.

Radio buttons, check boxes, controls: Draw directly on the screen. Use highlighter if you want them to stand out.

Dialog boxes, pop-up boxes: Use smaller-sized sticky notes for these. Draw permanent content directly; use separate notes for things that may change.

Special techniques: The more interactive your design is, the more you'll want to extend these basic techniques to represent your design. Drag-and-drop is easy if you put the element you want to drag on its own sticky note, so the user can pick it up and move it. If you want to represent an overlay of information—such as annotations on a document—use clear plastic and put sticky notes on it. If you're designing a tabbed interface, use flags to represent the tabs. Play with the medium—anything that represents your intent and isn't too complicated to create or use is fair game.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B978012800894200017X

A Developer's Dilemma

Nevin Berger , ... Fred Sampson , in Effective Prototyping with Excel, 2009

Introduction

This book is about how to prototype with Excel (or another spreadsheet application with similar functionality).

This book will also touch lightly on the larger topic of prototyping. Although the book does not attempt to completely cover the topic of prototyping, it will discuss prototyping as it relates to prototyping with Excel. For a comprehensive discussion on prototyping, we refer the reader to our first book, Effective Prototyping for Software Makers.

Excel is an amazing prototyping tool. It is amazing because it is the only tool we know that combines these advantages into a single tool:

▪: Prototyping flexibility
▪: Efficiency and ease of use
▪: Professional results
▪: No special skills required
▪: Readily available

Excel Prototyping

"Using Excel for prototyping? I don't get it!"

This is a common reaction from people when we first try to describe prototyping with Excel. The concept is far from what you use Excel for in your daily work. For some it is like claiming that their washing machine can mow the lawn. People cannot visualize how it can be done until they see it.

When you look at Excel, you probably just see a spreadsheet; you just can't think outside the table cell. To understand Excel as a prototyping tool, you will have to step out of the mental model that says Excel is only a spreadsheet application. This book will show you how.

Prototyping Flexibility

As a prototyping tool, Excel is not only easy to use, it is quite flexible for the various methods of prototyping. You can create static screen wireframes, screens with click-through interaction and navigation, and even prototypes that can be optimized for different types of usability testing.

To illustrate what we mean, the following images are prototypes created in Excel. You can experience these prototypes for yourself by visiting the book's Website and downloading each of these examples as native Excel files: www.effectiveprototyping.com/ep_excel/.

An interaction flow diagram in Excel, which might be the most basic visualization of a software concept, is illustrated in Figure 1.1.

Storyboard Prototypes

A storyboard is a narrative prototype, usually created in the early stages of the software-making process, to articulate business and marketing requirements in the form of a usage scenario or story. These stories narrate the user actions needed to perform tasks as specified by marketplace, customer, and user requirements. These requirements are interpreted into a scenario before the storyboarding process begins. Because requirements drive the storyboarding process, they provide early insight into what users, the software, and the system are meant to do in conjunction with each other. The primary goal of a storyboard is to align the design team's thinking to the goals and behaviors of the software, regardless of the screen design.

Figure 1.2 is an example of a storyboard in which an interactive narrative is shown through text and images. The user interface design embodied in an Excel prototype reflects this narrative as you click from one screen to another, with each screen contained in a worksheet.

Wireframe Prototypes

A wireframe is a narrative prototype, usually created in the beginning of the design process. The narration is usually derived from a use case or scenario, often the same scenario used in a storyboard. This prototype shows flowcharts, high-level sketches visualizing conceptual assumptions about the product structure and general interaction. The primary goal of this method is to get a design team to agree on basic concepts.

Figure 1.3 shows a rough wireframe of a Website that was created in minutes. This tool allows functional and rough conceptual issues to be separated from the detailed, more precise designs that should come later.

Figure 1.4 shows a medium-fidelity wireframe that evolved from the rough wireframe shown in Figure 1.3. The design of a medium-fidelity wireframe can help establish a visual design direction. It can also show a more evolved concept that includes interaction. As a result, stakeholders get a better idea of the design commitment without your prototyping a finished product.

Figure 1.5 shows a similar design to the previous two figures but with higher visual and content fidelity, to serve as the specification.

Paper Prototypes

A paper prototype is an interactive prototype that consists of a paper mockup of the user interface. The interface represents a fully functional interface that allows you to usability-test a design. The intended audiences are targeted users who test the design and the software makers who use the prototype as a means to implement the software.

Digital Interactive Prototypes

A digital interactive prototype is a digital version of a paper prototype. Interactive prototyping shares the same objectives as paper prototyping; that is, they can both be used to

▪: Understand task flow and context of use
▪: Validate assumptions in scenarios, requirements, and user profiles
▪: Shape task sequencing and interaction design direction
▪: Evolve prototypes from early rough sketches to the next level of detail
▪: Validate a visual design direction

Figure 1.6 shows that Excel can also be used to create interactive prototypes of list-driven products such as email clients.

Figure 1.7 shows that Excel can also be used to prototype interactive business software. Notice the drop-down list, which was activated by a user clicking on the menu button.

Excel can also be used to prototype a range of designs, from Windows applications to AJAX-enabled Websites. Figure 1.8 (page 14) shows an example of a Windows application prototyped in Excel.

Efficient and Easy

By using Excel, the user can quickly and easily create user interface prototypes. The results are both quick and professional looking. We know of few other tools that offer this level of quality for a minimum of effort. Nearly all the effort involves using features that you probably already know: cut, copy, paste, cell formatting, and so on.

Professional Results

Regardless of the level of prototyping, Excel's adapted layout grid ensures that you get professional-looking layouts. Field alignment and spatial distribution have never been easier. Applying company colors and graphics can also be automated, allowing you to leverage the work of professional designers in your company to achieve professional-looking results.

No Special Skills Required

Prototyping in Excel requires only the use of basic desktop and Excel functionality. You can create forms, tabs, and tables using simple cell formatting. You can create 3-D borders for buttons or input fields simply by using cell borders. Field length can be changed via drag and drop or copy and paste. The only mental shift required is to stop thinking of the Excel grid as a spreadsheet, instead thinking of it as a graphics layout grid.

Readily Available

If you want your prototyping process to empower your software makers, you need a tool that everyone can use. Excel is a readily available tool; it is frequently included on business computers. For the few of you who don't have Excel, there are alternatives such as OpenOffice, available for free, that put 90 percent of the techniques from this book to use, although some commands will differ.

Still Not Convinced?

As we start to explain the process of prototyping with Excel, you will eventually understand how it is done. The figures in this chapter help, but you might need some quick, hands-on experience, which we cover in the next chapter.

At our tutorials and seminars at PeopleSoft, Ziff Davis Media, Google, and SAP Labs, we encountered the same doubt. After our demonstrations, the results were the same at all these venues: Excel became an important tool in the audience's prototyping toolbox. This is not to say that Excel is the essential tool; Excel does not fulfill all prototyping needs. But for basic wireframes and digital interactive prototypes, Excel is an efficient tool you will not want to be without.

Who Should Consider Using Excel?

This book is for anyone who needs to prototype an interface for desktop software or the Web. It is intended not only for designers but for anyone who is part of the software-making process. Software makers include the full range of participants, from people with extensive graphics experience to those with little or no graphics background.

Some of the professionals we have seen using Excel for prototyping include

▪: Developers and programmers
▪: Web designers
▪: Product managers
▪: Information architects
▪: User experience professionals
▪: Usability engineers
▪: Graphic designers

In short, any stakeholder who needs to express a software idea or requirement visually or interactively can use Excel. We want to emphasize that this book is about how to prototype with Excel, not how to prototype in general.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780120885824000019

Prototyping

Rex Hartson , Partha S. Pyla , in The UX Book, 2012

11.9 Software tools for prototyping

In a previous section we mentioned a hope for the future about tools that would allow us to replace paper prototypes with low-fidelity programmed prototypes, but with the same ease of building, modifying, and executing low-fidelity prototypes as we had in the paper medium. The human–computer interaction (HCI) research community has not been unaware of this need and has tried to address it over the years (Carey & Mason, 1989; Gutierrez, 1989; Hix & Schulman, 1991; Landay & Myers, 1995). However, the technical challenges of designing and building such a software tool have been steep. We are not there yet, but such a software tool would certainly be valuable.

In the 1990s, user interface management systems (UIMSs), broad tool suites for defining, implementing, and executing interaction designs and prototypes (Myers, 1989, 1993, 1995; Myers, Hudson, & Pausch, 2000 ), and software prototyping tools were hot topics. Hix and Schulman (1991) also did some work on software tool evaluation methods.

There were different and competing looks, feels, and interaction styles built into many of these tools, such as CUA (IBM), OpenLook (Next), Toolbook (Asymetrix), Altia design (Altia, Inc.), Delphi (Borlund), Visual Basic (Microsoft Windows), and Dreamweaver (from Macromedia, for Web-based interaction). Some were not available commercially but were developed by the organizations that used them (e.g., TAE Plus by NASA). And some tools depended on a variety of different "standards," such as OSF Motif, not to mention Windows vs. Macintosh.

Many of the first tools for prototyping of interactive systems required a great deal of programming. Thus, interaction designers lacking programming skills could not use them directly, and "compiling" a new design iteration into executable form could be lengthy, complex, and fraught with bugs. Because many of the early UIMSs had a strong connection to computer graphics, resulting prototypes could be very realistic and could exhibit rather complex graphical behavior.

Some tools were, and some still are, based on interpretable interface definitions of the design entered declaratively, possibly along with some behavior structuring code. The interpretive approach offered more speed and flexibility in accommodating changes but, because of early hardware limitations, almost always caused the prototype execution to suffer slow performance. As the ability to produce user interface façades advanced in the tools, provision was made to program or at least stub non-interface functionality, moving the technology slowly toward whole system prototypes.

There is still no single prototyping platform capable of facilitating rapid prototype construction while meeting requirements to simulate today's complex interaction paradigms. This has been a persistent problem in HCI, where the prototyping tools are always a little behind on the state of the art of interaction possibilities.

For example, in a study we conducted with eight student teams working on building a real-world software system, we observed a situation where the interaction designers in the team needed an autocomplete feature in a pull-down menu as a core feature of their prototype. But because they could not get autocompletion in a prototype without a database, the software engineers in the team ended up having to build the database to support this one interaction design feature.

That software investment could not be used in the product itself, however, because it was on the wrong platform. We have to keep repeating the difficult prototype programming it takes to provide the functional behaviors that are becoming expected in any interactive software system, such as log-in sequences, auto-completion functions, or data entry validation sequences. Nowadays more and more of these complex interaction patterns are being communicated using static or click-through wireframes. We hope the state of the art in prototyping tools will soon evolve to support such patterns more effectively.

11.9.1 Desiderata for Prototyping Tools

As we have said, prototyping tools so far have almost always shared the same downside: it takes too long to make changes, as even the smallest amount of programming distracts from the purpose of a low-fidelity prototype and, as the prototype grows in size, it becomes less amenable to changes. Therefore, we (especially the user interface software community) continue on a quest for the perfect software prototyping tool, among the desired features of which are:

▪

Fast and effortless changes

▪: Ease on the order of that of paper prototypes: as natural as changing a paper prototype
▪: Tool transparency: Needs so little focus on the software that it does not distract from the design and prototype building
▪: Fast turnaround to executability so there is almost no wait before it can be executed again

▪

Non-programmer ease of prototype definition and use

▪: Non-programmers must be able to define and modify design features

▪

Built-in common behaviors and access to large varieties of other behaviors via a library of plug-ins

▪: Easily include realism of features and behavior commensurate with expectations for modern interaction styles

▪

Supports a wide variety of interaction styles and devices, including various pointing and selecting devices, touchscreens, speech/audio, tactile/haptic, and gesture

▪

Ease of creating and modifying links to various points within the interaction design (e.g., buttons, icons, and menu choices to particular screens) to simulate user navigational behavior

▪

Communication with external procedures and programs (e.g., calls, call-backs, data transfer) to include some functionality and additional application behavior

▪

Capability to import text, graphics, and other media from other sources

▪

Capability to export look and feel components for eventual transition to final product code

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780123852410000117

Volume 1

Bruce K. Gale , ... Tammy Ho , in Comprehensive Microsystems, 2008

1.12.5.2.1 Applications

The use of casting has been an important rapid prototyping tool for microfluidics researchers. The Whitesides and Quake Research groups highlighted the advantages of casting PDMS for microfluidic systems. Duffey et al. demonstrated the implementation of a CE microfluidic configuration in an oxidized PDMS chip (Duffy et al. 1998). Anderson et al. showed the possibility of creating complex 3D microfluidic networks using casting techniques. Interweaving channels and serpentine channels were cast using multilayer lithography steps (Anderson et al. 2000). Unger et al. illustrated the capabilities of multilayer PDMS devices that could be used for the active movement and control of fluids through pneumatic actuation of a thin membrane. Microvalves and peristaltic micropumps have been characterized and reported (Studer et al. 2004, Unger et al. 2000). Since these initial demonstrations of casting for microfluidics, complex microfluidic devices for biological assays and protein deposition have also been reported. McDonald et al. (2001), by utilizing PDMS casting, created a disposable microfluidic network for an enzyme-linked immunosorbent assay (ELISA) detection assay. Bernard et al. utilized reactive ion etching to etch channels in a silicon wafer for casting microfluidic biomolecule deposition tools in PDMS. The PDMS deposition tool confined solutions of interest to channels that would pattern a substrate with biomolecules. A second deposition tool will replace the first perpendicular to the original flow lanes, creating intersecting regions where binding events can take place (Bernard et al. 2001). Xurography (see Section 1.12.3.5) has also been used to form a casting master for direct molding with PDMS (Bartholomeusz et al. 2005). The development of novel, low-cost mold patterning techniques will continue to make casting an integral part of rapid prototyping in research development applications.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780444521903000112

Prototyping for Navigation

Mario Pérez-Montoro , Lluís Codina , in Navigation Design and SEO for Content-Intensive Websites, 2017

4.4.1.4 Justinmind

Justinmind (justinmind.com ) is another highly popular commercial prototyping tool among information architects. It is available both for Windows and Apple operating systems.

It is a highly flexible desktop tool designed for creating web prototyping environments (wireframes and blueprints, including responsive designs), apps (Android and iOS), enterprise apps, and, even cards for Google Glass apps.

It has a similar aesthetic to other solutions, including Photoshop and Illustrator, and it offers, in addition to these diagramming types, various capabilities related to interaction. It facilitates interaction with prototypes for webs and mobile apps (Android and iOS), mobile gestures and transitions. Visually, it permits image synchronization with Photoshop, integration (copy/paste as SVG file) with Adobe Illustration, and it allows images to be dragged and dropped directly from the browser or file system. In the case of simulation, it enables integration with user testing tools and services, and emulates Android and iOS (iPhone and iPad) mobile environments for testing.

Like the tools already discussed, Justinmind allows the export of prototyping proposals to different formats including, for example, HTML + JS and PDF, generating documentation in MS Word and Open Office formats. Interestingly, it can also automatically generate the site map from the wireframes developed.

It also offers the possibility of including annotations and legends in the prototypes developed and also the possibility of creating and editing prototyping projects in a team.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780081006764000043

Collaboration Life Cycle

Jack Moffett , in Bridging UX and Web Development, 2014

Benefit 5: Prototyping

There are many different ways to create prototypes. There are prototyping tools, such as Axure and Balsamiq, that allow you to build interactive prototypes without knowing how to code. You can use presentation software, such as Apple's Keynote or Microsoft PowerPoint. Tools like these can get you a long way down the road, and in many cases, they're sufficient to get the answers you need. However, the ability to prototype using the same technology that will be used in implementation does have additional benefits. It's often easier to create behaviors with the native technology than to reproduce them with a different technology. For example, once you understand how to create a scrolling pane with the rubber-band effect in an iPhone app, I'm sure it's much easier to do it that way than to mimic the rubber-band effect in Adobe After Effects, and then you can actually experience using it on the target device rather than watching it. Furthermore, when you prototype with the actual technology, you know that what you see is what you get. It's not possible to prototype something that's impossible to build. And, of course, there's the potential to turn your prototype into the actual software, although that's usually not the goal of a prototype. Depending on your circumstances, there may be reason enough to learn to code for purposes of prototyping.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780124202450000031

Localization and tracking

Klaus Witrisal , ... Thomas Wilding , in Inclusive Radio Communications for 5G and Beyond, 2021

9.6.1 Testbeds for GNSS-based localization activities

The swiftly evolving landscape of GNSS signals and systems demands rapid prototyping tools in order to explore receivers' full capability, including radically new uses of those signals. That flexibility is hard to find in today's GNSS receiver technology, realized by application-specific integrated circuits (ASIC) and system-on-chip (SoC) implementations with high development costs and very limited degree of reconfigurability, thus hampering experimentation and fair trials of new approaches.

An example of testbed aimed to the research on Global Navigation Satellite Systems signals is GESTALT (see Fig. 9.21), a loose acronym for GNSS Signal Testbed, a facility located at CTTC's headquarters in Castelldefels, Spain. The facility is equipped with an assortment of GNSS antennas; GNSS signal generators for controlled experiments; state-of-the-art radio-frequency front-ends able to work concurrently in three GNSS frequency bands, with configurable bandwidth, frequency downshifting and filtering; digitation working at sample rates as high as 80 MSps with 8-bit, coherent I/Q samples; high-speed interfaces to a host computer; and an open source GNSS software receiver in charge of signal processing and generation of suitable outputs in standard formats [AFPC15].

A key GESTALT feature is its openness. In addition to the fact that it can be fully operated remotely, the core software DSP receiver engine is a free and open source project with a lively community of users and developers (http://gnss-sdr.org). Accordingly, a partial testbed replication can be done on a limited budget with commodity computers and low cost, over-the-counter antennas and radio-frequency front-ends. This allows for the practical implementation of new concepts, reproducible research and short assessment and validation times.

Besides, a set of software-defined GNSS receivers run in the cloud can be used to overcome the limited computational resources of IoT nodes needing localization functionalities. In this solution, the GNSS receiver is no longer a physical device but a virtualized function which is provided as a service. In [FPA⁺17], authors proposed a system architecture based on optical networks and automated orchestration tools to deliver continuous service with high-accuracy performance to users with high-bandwidth connectivity, which could be provided by 5G networks.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780128205815000158

Getting Started

Nevin Berger , ... Fred Sampson , in Effective Prototyping with Excel, 2009

Examples of Excel Prototypes

You need a quick and easy way to create prototypes. The prototyping tool should make credible-looking prototypes in variable degrees of fidelity. The tool should allow varying degrees of interactivity appropriate to your prototyping goals but not require you to code extensively. The ideal tool would also leverage skills that you already have so that you do not need to learn anything new. And the truly ideal tool would already be on your computer—for example, Microsoft Excel.

Look at the examples that follow (Figures 2.1–2.4, pages 20–21). These prototypes look as though they were made in a graphics tool, not a spreadsheet application. These prototypes were made possible by users learning to think of Excel as a graphics-based design tool rather than an application for spreadsheet calculations. After you make that mental leap, you will use styles, copy and paste, and drag and drop to unlock a new, very powerful prototyping tool.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780120885824000020

Computer Assisted Systems Engineering (CASE)

Donna Weaver McCloskey , in Encyclopedia of Information Systems, 2003

II.A. Upper Case

Upper CASE tools (sometimes also referred to as front end CASE tools) are typically used by analysts and designers and include diagramming tools, prototyping tools that include form, report, and user interface generators, and the repository. Upper CASE tools primarily focus on the analysis and design of the information system.

One of the early steps in the traditional system development life cycle is analysis, the modeling of the logical system. This step would include using a number of diagramming techniques to present the scope of the information system, the individuals and other systems that the new information system will interact with, the flow of data, the processes that are done, and the data that is stored and used. Context diagrams, data flow diagrams, and entity-relationship diagrams are commonly used diagrams to model the information system. A CASE tool allows the analyst to create these diagrams relatively easily and professionally, thus saving the analyst the time required to manually draw and then continually redraw the diagrams as changes and additions are made. The tool can also provide some basic checks to ensure that the correct data modeling rules are followed. For example, a CASE tool will not allow a data flow to go unnamed or for a child data flow diagram to have flows that do not match those is the parent data flow diagram. Analysts would rarely work alone on such large projects. Because the project diagrams are stored in a repository, multiple participants will have access and have the ability to make changes and corrections. The automated diagramming tool helps the analyst maintain the same naming conventions and ensures the interoperability of diagrams. The ability to create and maintain data flow diagrams and the data dictionary have been found to have the highest ranking in critical components for a CASE tool.

Prototyping tools allow the developer to quickly develop screens, reports, and forms to give end users the "look and feel" of the information system. By presenting a prototype to the end users early, the developer can gain valuable feedback and additional support for the project. The process of developing the templates is very straightforward. The establishment of templates allows the developer to set common features, such as headings, footers, function key assignments, buttons, and formatting constraints so that each screen, report, and form are consistent. A change to the shared template would then "ripple through" to each item without the need to edit each one.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B0122272404000137