Web Application Development

Section 0: Module Objectives or Competencies

Section 1: Web Application Design Methods

Information systems are entering a new phase, moving beyond the traditional automation of routine organizational processes

• It’s a relatively new area; most significant work only emerged from 1993 onwards.
• Very much in the infancy stages.
• Few approaches have been severely tested, and no one solid method has emerged.
• We have most of the methods and technique components that we need for a web method, but in almost all cases they have just not been integrated.
• Currently we need to work around the issue by forming 'hybrid' methods that share and borrow techniques.

Here is a review page to accompany my notes.

Section 2: Building Web Applications

Section 3: How Web IS Development is Different

Differences in Web Development

The internet software development process evolved rapidly because of three major causal factors:

• Factor One: Desperate rush to market
  • Time-to-market is critical.
  • Companies must keep up with and ahead of the competition.
  • Any advantage is short lived and will be copied quickly.
• Factor Two: Different kind of market environment
  • The environment into which these software products are being placed represents a large and uniquely different marketplace for software products.
    • The software in this marketplace rarely deals with mission-critical or life-critical applications.
    • Lapses in quality in one release can be fixed in successive releases rather quickly.
    • The one-to-many architecture used in the Internet environment makes it possible to use a single backend infrastructure to support a variety of customer needs.
    • A major constraint is the incredibly short time frame for software development imposed by the rush-to-market.
    • There are also narrow technical constraints on the software architecture imposed by the standardized browser clients, the Internet speeds and protocols, and the architecture of existing legacy systems or large-scale backend systems.
• Factor Three: Lack of experience developing software under these conditions
  • Internet software development requires the use of methods, tools and project management techniques that are often different from those used in traditional software development.
  • Though many developers have experience in traditional software development environments, they lack sufficient expertise and experience with the Internet environment.
  • Given the short history of Internet software development, there are no well accepted or established methodologies for it.

The above causal factors led to three outcomes:

• New software process
• Unique development cultures
• Negotiable quality

New Software Process

• As a result of these factors, the software process for Internet software development has to be different.
• The list below explains ten of the key examples of these differences:
  • Parallel development
    • A number of development activities take place at the same time.
    • Sometimes, coding begins even before the requirements have been fully understood.
    • Development proceeds in anticipation of the features that will be required in the final version of the product.
  • Fixed architecture
    • Makes parallel development possible.
    • A three-layer architecture consisting of a database layer, a business logic layer (the detailed processing code), and the user interface layer, or the Web-based "front-end" that is delivered through the browser, is commonly seen.
  • Release orientation
    • Applications are produced incrementally in a series of ever more refined and extensive versions of the product.
  • Prototyping
    • Prototyping can be used as a way to communicate with their customers to validate and refine requirements.
    • The ability to quickly replace the current version of the product with newer versions is another factor justifying this practice.
  • Customer involvement
    • Due to their focus on high speed development, precise definition of requirements is often infeasible as the requirements are often ambiguous, incomplete, and are constantly evolving.
    • Many projects rely on the intimate involvement of customers in the development effort rather than a formalized requirements management process.
    • Close involvement also implies that customers receive immediate feedback on the costs and schedule implications of any changes in requirements.
  • Maintenance marginalized
    • Often maintenance of the software is not given serious consideration.
    • The lack of concern for understandability and maintainability causes serious problems.
  • Reusable Components
    • The Internet speed development can often only be achieved if the software can be assembled with as many reusable components as possible, rather than crafted from scratch.
    • The reuse of components at all levels of the architecture (business logic, interfaces, and back-end infrastructure) is very prevalent.
    • The software development process in many cases is just a process of achieving interoperability and integration among components developed elsewhere or purchased off the shelf.
  • Tool usage
    • Many Internet software developers make heavy use of development tools and environments that speedup the design and coding process.
    • The development process and methodology are tailored to match the needs for quality and speed for the next release.
    • The separation of user interface, business logic, and data management that is enforced by many of these tools indirectly imposes an architecture even if it is not consciously planned.
  • Tailored methodology
    • Because there is no methodology for the development of web-based software, organizations don't use one prescribed method, but instead often use features of many.
    • The software development process is allowed to adapt and evolve as the software product and its marketplace evolves.
• Although there may not be any single characteristic that is particularly unique to this new software process, the collection of characteristics is unique and remarkably common to Internet software development processes.

Unique Development Cultures

• Traditional development thinking will break down when high-speed software development is attempted.
• The factors above have led to a development culture that differs from more traditional software development organizations in that it appreciates less structure, smaller team sizes, diverse team compositions, and individuality.
• The people orientation in the software process, the disregard for tried-and-true methodology, the relative newness of the architecture and tools, the ineffectiveness of traditional thinking, all lead to a need for people who can invent what they need on the fly and learn from other colleagues with different expertise.
• The culture is evolving along with the evolution of the product and markets in which they operate. As the products and markets mature and the demands for quality factors (such as robustness, scalability, and security) overtake the need for speed, the processes used to achieve them begin to resemble traditional software development.

Negotiable Quality

• Values traditionally appreciated by the majority of software developers – such as product scalability and easy maintenance – become much less rational ideals.
• Customers and users seem to appreciate immediate functionality and may be willing to defer a certain amount of reliability and performance.
• Developers can correct badly designed or coded features when time allows.

Taken from Ramesh, B., Pries-Heje, J, and Baskerville, R. (2002). Internet Software Engineering: A Different Class of Processes. Annals of Software Engineering 14, 169–195.

Section 4: Methods

Web development methods encompass a set of technical tasks that enable a developer to understand, characterize, and then build a high-quality web application.

• Communication methods
  • Define the approach used to facilitate communication between web developers and all other web application stakeholders (e.g., end users, business clients, problem domain experts, content designers, team leaders, project managers).
  • Communication is particularly important during requirements gathering and whenever a web application increment is to be evaluated.
• Requirements analysis methods
  • Provide a basis for understanding the content to be delivered by a web application, the functions to be provided for the end user, and the modes of interaction that each class of user will require as navigation through the web application occurs.
• Design methods
  • Encompass a series of design techniques that address web application content, application and information architecture, interface design, and navigation structure
• Construction methods
  • Apply a broad set of languages, tools, and related technology to the creation of web application content and functionality.
• Testing methods
  • Incorporate technical reviews of both the content and the design model and a wide array of testing techniques that address component-level and architectural issues, navigation testing, usability testing, security testing, and configuration testing.

In addition to the technical methods that have just been outlined, a series of umbrella activities (with associated methods) are essential for successful web development.

• These include project management techniques (e.g., estimation, scheduling, risk analysis, software configuration management technique, and review techniques).

Section 5: Tools and Technology

Tools and technology amplify a technologist's ability to build computer-based systems.

• A vast array of tools and technology has evolved over the past decade as web applications have become more sophisticated and pervasive.
• These technologies encompass a wide range of content description and modeling languages (e.g., HTML, virtual reality modeling language (VRML), programming languages (e.g., Java), component- based development resources (e.g., Common Object Request Broker Architecture (CORBA), Component Object Model (COM) architecture, ActiveX, .NET), browsers, multimedia tools, site authoring tools, database connectivity tools, security tools, servers and server utilities, and site management and analysis tools.

When used properly good tools allow us to work faster and to create a higher-quality end product.

However, tools and technology are not enough.

• You will inevitably fail if
  • you don't really understand the problem
  • you have no way of accommodating changes that will invariably occu
  • you have not spent some time laying out a viable solution
  • you have no intention of ensuring the "solution" that you've generated meets the needs of your stakeholders
• Tools and technology are very important, but they'll work well only if they're used within the context of an agile framework for web development and in conjunction with proven methods for understanding the problem, designing a solution, and testing it thoroughly.

Section 6: Best Practices

Web development teams are sometimes under enormous time pressure and will try to take shortcuts – even if these are ill advised and result in more development effort, not less.

Some developers prefer to keep things very informal and reject the notion of a process framework and defined methods as a matter of philosophy.

However, you should utilize the following best practices whenever you build industry-quality web applications.

• Take the time to understand business needs and product objectives, even if the details of the web application are vague.
  • Many web application developers erroneously believe that vague requirements (which are quite common) relieve them from the need to be sure that the system they are about to construct has a legitimate business purpose.
    • The end result is (too often) good technical work that results in the wrong system being built for the wrong reasons and for the wrong audience.
  • If stakeholders cannot enunciate a business need for the web application, proceed with extreme caution.
    • If stakeholders struggle to identify a set of clear objectives for the product (web application), do not proceed until they can.
• Describe how users will interact with the web application using a scenario-based approach like user stories.
  • Stakeholders should be convinced to develop scenarios that reflect how various users will interact with the web application.
  • These scenarios can then be used...
    • for project planning and tracking
    • to guide analysis and design modeling
    • as important input for the design of tests
• Develop a project plan, even if it's very brief.
  • Base the plan on a process model that is acceptable to all stakeholders.
  • Because project time lines are very short, use a "fine" granularity for your schedule; i.e., in many instances, the project should be scheduled and tracked on a daily basis.
• Spend some time modeling what it is that you're going to build.
  • Often, comprehensive analysis and design documentation is not developed as a part of web development work.
  • However, well-targeted graphical models can and do illuminate important development issues.
• Review the models for consistency and quality.
  • Pair walkthroughs and other types of reviews should be conducted throughout a web development project.
  • The time spent on reviews pays important dividends because it often eliminates rework and results in a high-quality web application – thereby increasing customer satisfaction.
• Use tools and technology that enable you to construct the system with as many reusable components as possible.
  • A wide array of web application tools is available for virtually every aspect of the web application construction.
  • Many of these tools enable a web developer to build significant portions of the application using reusable components.
• Don't reinvent when you can reuse.
  • A wide range of design patterns have been developed for web applications.
  • These patterns allow a web development team to develop architectural, navigation, and component-level details quickly using proven templates.
• Don't rely on early users to debug the web application – design comprehensive tests and execute them before releasing the system.
  • Users of a web application will often give it one chance.
  • If it fails to perform, they move elsewhere – never to return.
  • It is for this reason that "test first, then deploy" should be an overriding philosophy, even if deadlines must be stretched.

Section 7: Resources

All notes copied directly from:

• Grove, R.F. (2010). Web-Based Application Development. Sudbury, MA: Jones and Bartlett.
• Pressman, R.S. & Lowe, D. (2009). Web Engineering: A Practitioner's Approach. Boston, MA: McGraw-Hill.