Read an Excerpt
Beginning Microsoft Visual Studio LightSwitch Development
By István Novák
John Wiley & SonsCopyright © 2011 John Wiley & Sons, Ltd
All right reserved.
Chapter OnePrototyping and Rapid Application Development
WHAT YOU WILL LEARN IN THIS CHAPTER
* Coping with the main challenges of line-of-business software
development * Understanding how application prototyping can help you cope with
those challenges * Understanding rapid application development, and how it is related
to Visual Studio LightSwitch
Microsoft is known as a company delivering great development tools. To create data-centric applications, for a long time, Microsoft has been offering only two tools that target separate audiences:
* Visual Studio is to be used by a wide range of developers from students and hobbyists,
to enterprise developers and architects. * Microsoft Access (a part of the Office Plus bundle) provides an easy-to-use approach to
create data-centric applications for users with very basic development skills.
With Visual Studio, a wide range of applications can be created from the smallest console utilities to highly scalable web applications. The price of this freedom and scalability is that developers must invest a relatively high amount of work to create their applications. Although Visual Studio provides a number of productivity enhancement functions to create data-centric applications, using them requires advanced programming knowledge.
In contrast to Visual Studio, Microsoft Access requires only basic development skills. The simplicity of Access allows users without strong development backgrounds to create their database tables, forms, and reports. However, the price of this simplicity is that Microsoft Access has strong architecture limitations — it supports only monolith or traditional client-server application architectures. Creating a bit more complex user interface (UI) logic or data validation with Access than the default one requires advanced programming skills.
As a member of the Visual Studio family, Visual Studio LightSwitch is a great new development tool. Microsoft developed this product especially to support rapid application development (RAD) techniques in line-of-business (LOB) application development.
LightSwitch is the golden mean between the simplicity of Access and the flexibility of Visual Studio. With LightSwitch, you can easily create data-centric applications by simply designing data structure and the related UI. To create your own data validation or UI logic requires writing only a few lines of code — and most importantly, you not need to have advanced programming skills. Without any change in your application's structure, you can deploy it either as a desktop application or a scalable web application in the cloud.
When you need to extend an existing LightSwitch application, you can load it into the Professional, Premium, or Ultimate editions of Visual Studio 2010, and extend it with pretty complex business logic, UI behavior, or integrate it with your own back-end systems. Of course, it requires advanced software development knowledge. But you can use the existing LightSwitch application as a springboard, and do not have to create a new one from scratch.
This chapter provides overview about application prototyping and RAD techniques. Here you will learn how these techniques can answer LOB software development challenges, and also understand how Visual Studio LightSwitch does it.
LINE-OF-BUSINESS SOFTWARE DEVELOPMENT CHALLENGES
Today, most companies cannot survive without IT infrastructure supporting their operations. For a long time, infrastructure meant only hardware, operating system, and database management systems. Later, other services such as e-mail, collaboration platforms, and systems management services became standard parts of the IT infrastructure. Today, enterprise resource planning (ERP) and customer relationship management (CRM) systems are also part of the IT infrastructure in small and medium businesses.
Although many companies use almost the same IT infrastructure in terms of operating system, database and communication platforms, ERP, CRM, and so on, they still work in different ways with those systems. They all have some unique factors that differentiate them — and their businesses — from competitors on the same market segment. To be unique in this sense, they often need specific software tailored to their requirements and imaginations.
Because of these differences in how businesses use and think about their IT infrastructures, they also need to consider what kind of software to develop to best support their specific business processes. These management applications are often called line-of-business (LOB) applications, or LOB software.
LOB Software Development
There are many reasons why companies may need to develop LOB software, including the following:
* To create an application that meets business needs not currently met by existing systems
* To develop satellite applications to support existing systems
* To establish an ergonomic user interface (UI) for a legacy system
Traditionally, software development projects involve team members and stakeholders both from the business side and from the IT side. Generally, the business side is responsible for defining the business context and the issues (tasks) to be solved by the LOB application. Also, the business side undertakes managing user acceptance tests — and related quality tests — that validate the solution. The IT side is generally responsible for implementation of the LOB application, including system design, infrastructure, coding, testing, and deployment.
For some activities this division of labor is not so clear-cut. For example, in some companies web design is controlled by business stakeholders, while other companies delegate it to the IT side.
Developing LOB applications is a challenging task. Some of these challenges arise from technical or functional complexity, but the toughest ones reflect the different mindsets of the people involved. In this chapter, you will learn ways to meet many of these challenges.
Changing Project Environment
The traditional software development life cycle known as the waterfall model — whereby the design, implementation, test, and deployment phases follow each other without overlapping — does not work well in today's LOB application projects. Any project that takes more than one day — and most projects (if not all) belong in this category — must meet the challenges of the continuously changing environment surrounding the project. Accordingly, the original requirements, goals, and (at the end of the day) application features change, too. These changes can be legal, political, economic, technological, human, and so on. LOB applications are similarly affected by such changes, because the business environment also undergoes continual, and often rapid, change.
Creating a Requirements Specification
New LOB applications, or functional extensions of existing LOB systems, generally begin their lives with a requirement specification. This document summarizes all functional requirements (what the system is expected to do) and all quality requirements (performance, service level, UI, robustness, security, and so on), which form the basis for the detailed system specification or system design.
Creating a clear requirements specification is an integral part of developing a LOB application. If this specification fails to mirror the real-world expectations and uses of the application to be implemented, the result may be a poor or even useless system. In some cases, it may conform to the specification but key users won't like it. Keep in mind that stakeholders from both sides of the aisle (business and IT) generally speak separate languages. Whereas some people quickly grasp a few simple sentences, others process information using screenshots and storyboards, and still others prefer formal descriptions, such as Universal Modeling Language (UML) use cases or activity diagrams.
Very often, a requirements specification is presented to stakeholders as one long document, and the stakeholders must weed through numerous details to find the information they are seeking. These documents typically use the language style of legal contracts, and digesting them is extremely laborious. The best requirements specifications are simple documents, but they can be anything that unambiguously communicates to stakeholders the LOB system to be developed.
While a LOB application is under development, feedback from key users and business stakeholders about the burgeoning system is critical. If users see the new system only at the very end of the implementation phase, any issues or problems that are found can be time-consuming and expensive to fix, in some cases requiring expenditures that exceed the planned budget. Conversely, if key users want to see the new system's progress every day, that can cause a lot of overhead for development and support.
Finding the right balance for feedback frequency is a challenge whose solution will vary according to the project. For some projects, three days or a week might be fine, whereas several weeks might be optimal for others.
For example, while you are in the UI design phase of the project, having two feedback meetings in a week can help you to progress faster. Later, when you are about to elaborate specific business modules, having a review meeting every two weeks could be enough.
You can even vary how often you provide feedback to your users. At the beginning (during the conception phase or while designing the application), it might be appropriate to communicate progress every few days. In some cases, you can even carry out a feedback cycle within one day.
For example, in a morning meeting, you might ask key users for feedback about a new screen issued the previous day. In the afternoon, you could present how you plan to address that feedback. Later, after implementing the desired feature(s), you could ease the initial frequency. When you are about to prepare for a pilot deployment or the production deployment, feedback frequency should again be increased.
There are many ways to manage the challenges mentioned previously and mitigate the risks associated with them. The goal is to prevent risks that result from wrong information or insufficient information. For example, if an order management process is not entirely clear because you do not know the CRM system that stores customer information, the lack of this information is a risk. Similarly, not knowing all the attributes that should be entered for a new order is also a risk.
Application prototyping is a tool for managing such situations — and many challenges related to the human factor — as well as mitigating associated risks. While it is not the only tool, it is one of the best.
Prototyping, and the resulting application prototype, is defined in various ways. The essence of prototyping is the creation of a functional, and perhaps somewhat limited, model of the final application. Unlike specification and design documents that use literal or formal descriptions, this working model can be readily understood by key users.
For example, try to explain a UML user activity diagram to key users! Even if they understand it, they cannot truly appreciate how it will be implemented. Conversely, if you create a prototype of the activity, such as an order process, using a storyboard that represents the same UML diagram, users will have a greater level of confidence that the final product will be the right one.
You can also use application prototyping to obtain required information from users in an indirect way. If users are unable to clearly explain exactly what they want — which is not uncommon — you can create a prototype that implements an incomplete, or even obviously inferior, model. When you present such a prototype to key users, they can usually tell you what's wrong with it immediately, or what's missing.
The rest of this section describes the various kinds of prototypes you can use. Depending on your goals — that is, what you want to communicate — you might use one or more on a single LOB project.
The term wireframe has been used in three-dimensional (3D) modeling for a long time, especially in 3D computer graphics. This term is also used to describe UI prototypes, mainly for presenting website illustrations. A "wireframe" in this context depicts the layout of the fundamental elements in the user interface. Figure 1-1 shows an example of a wireframe describing the home page of a fictional company.
Note the simplicity of this wireframe. It does not contain a high-level, sophisticated design because its aim is not to present the graphical look of the home page but rather to enable key users to focus on its structure and elements. The colors used in this wireframe are just for separating layout segments visually; they are not the real colors to be used in the final design.
You may be wondering why it is useful to create a wireframe instead of a model that more closely resembles the final state of the home page. Wireframe models offer a few advantages over more detailed prototypes, including the following:
* They are relatively cheap to create. Even a whiteboard can be used to create them. Using
wireframes, you can save time and the expense of creating possible unsuitable UI models.
* You can give a wireframe to key users and they will quickly have a basic understanding of
your intention. If something is wrong, it can be corrected instantly.
* When you present a graphically designed home page prototype to users, their attention is
focused on the style of the page — the logo used, the font type, and so on — instead of the
structure of the page. Of course, later you must present them with the graphical design. But
first the structure should be grabbed.
* A wireframe is also a good start for the final web design, because it relays a lot of
information about the intentions of key users that is useful to the experts who create the
For any project, any piece of information you are lacking is a source of risk. If you are unsure how to carry out any of the tasks in your to-do list, then that is also a source of risk. In situations where you know what you are expected to do, but not how you do it, you need to do some research.
A great method for performing this research is to use a prototyping technique called proof-of-concept modeling. Instead of thinking and making plans about how to solve a specific issue, you build a very simplified working model to prove the feasibility of your idea. If that is usable, you can use this model later, of course, with the necessary modifications.
Excerpted from Beginning Microsoft Visual Studio LightSwitch Development by István Novák Copyright © 2011 by John Wiley & Sons, Ltd. Excerpted by permission.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.