Designing and Developing Web-Based Applications (Exam 70-547)

Chapter 1 : Application Requirements and

Design

Before any requirements gathering takes place a feasibility study will probably be performed.

Any application development starts with a Vision defined by the project stakeholders and management. Architects and developers often help business analysts to define the goals and a full set of requirements.

MSF (Microsoft Solutions Framework) for Agile Software Development defines

• a QOS (quality-of-service) requirement as a work item allowing for performance, load, availability, stress, accessibility, serviceability, and maintainability requirements.

• a Scenario work item representing a use case – a path of user activity through the system to reach a specific goal.

MSF for CMMI (Capability Maturity Model Integration) defines a requirement work item with a number of subtypes that can be sub-grouped:

• user requirements with type scenario

• non-functional requirements with types quality of service, safety, security

• functional requirements with types functional, operational, interface

Categories of Requirement Definition

Requirements must be defined from multiple perspectives capturing all the needs across the different types of stakeholders. There are a limited number of tags:

• business requirements – typically defined as high-level requirements by management or stakeholders and define a vision or goal for the system and therefore need to be translated into tangible requirements.

• user requirements – the tasks the users must be able to accomplish to meet the objectives of their jobs. As high-level requirements they are probably defined as one-liners for example - ‘A customer service representative must be able to place an order for a customers.’ A use-case details the how and a specification provides developers with the information they need.

• functional requirements/specifications – are features the developer must build to satisfy the other requirements. Often better defined through application modelling tools to prevent documenting them once on paper and again in the models.

• quality of services – define contractual, non-functional requirements of the system such as performance, scalability, and standards.

Use Cases and Requirements

Typically both Use Cases and Requirements are required for a successful project.

Requirements define what needs to be created for the system to be successful and are useful for:

• defining scope

• determining objectives are met

• provide traceability throughout the project lifecycle (traceability matrices)

Use Cases define a set of steps to reach a common user goal and contribute to reaching a requirement.

Evaluating the Requirements

To determine whether the defined requirements are sufficient there are a number of questions that can be asked :

• Feasible – are the requirements feasible against know constraints such as budget, timeline, and technology?

• Unambiguous_ _– Does each requirement define a specific, actionable scope item? Can each requirement be acted upon? No soft requirements such as ‘The application should be easy to use’ which is simply goal.

• Necessary – do we need all the requirements to complete the system?

• Complete – is further clarification required? Are there missing requirements?

• Requirement perspectives – have the four categories of requirements been covered?

• Actionable – is there enough detail to proceed with the requirement.

• Measurable – can the requirement be measured to understand when it is complete or progress is being made?

Recommending Technologies

Technology choice should be driven by the requirements. Make it a requirement to use existing technologies if this is valid and justified. A choice of one technology over another should be evaluated against the requirements.

Architecture and technology recommendations are mutually exclusive and should be defined separately. The book suggests technology should be defined first and then combined with the requirements to drive the architecture definition – although I’m not sure that’s strictly the best way.

There are a number of layers that can be considered to break down the technology choice :

• Client

  • standard browser-based client

  • _AJAX-enabled client - _(highly interactive/useable possibly having to sacrifice browser-compatibility)

  • _smart client – _a client deployed through a web browser but runs as a Windows application.

  • Microsoft Office client

  • Windows Mobile

• Third-Party Controls

• Application Server – will need to consider the version of IIS and .NET framework.

• Application Libraries – frameworks and libraries are slightly different. Frameworks build on libraries by offering more architectural ‘plumbing’.

• Security – this should include logging on but also any necessary security of data that is required (e.g. encryption.)

• Data Storage

  • File-based storage – for example CSV or XML.

  • Microsoft SQL Server 2005 Express Edition – limited to a single CPU, 1Gb of RAM and a 4Gb database. However it also offers a file-based embedded option.

  • SQL Server Everywhere Edition – _also _SQL Mobile provides a small lightweight database for handheld devices.

  • SQL Server editions and options

  • Other data storage – for example Oracle or DB2.

Existing Options

Don’t forgot pre-built options that can save time, money and testing:

• Corporate assets – anything already built by the company

• Third-party components

• Microsoft Windows SharePoint Services – services for creating collaborative portal solutions using .Net Framework 2.0 to build Web Parts.

• Microsoft Commerce Server – a platform for building business applications that centr on e-Commerce and specifically works with ASP.NET 2.0, BizTalk Server, SQL Server, SQL Server Reporting Services and others.

• Microsoft BizTalk Server – manages business process and integration. BizTalk 2006 integrates with VS2005.

• Microsoft Host Integration Server – provides integration with IBM mainframes by connecting to data sources, messaging and security.

• Microsoft SQL Server SSIS (SQL Server Integration Services) – provides functionality to extract, export and transfer.

• Microsoft SQL Server Reporting Services – provides SQL-based reporting from either an OLAP database or OLTP.

• Microsoft SQL Server Analysis Services – converts data to a queryable cube.

Creating a High-Level Application Design

At this point there will be:

• A set of evaluated and confirmed requirements

• A technology recommendation based on the requirements

The high-level application design will explain the application intended to be created and therefore will define the technologies to be used and how they’ll be connected.

Typically this seems to be envisaged by Microsoft as an application diagram created in Visual Studio that highlights the different areas in the system (e.g. web UI, office integration, web services, application services) and the constraints that govern their configuration (e.g. the version of Windows and IIS ASP.NET is installed on.)

Creating Proof-of-Concept Prototype

Design might follow the High-Level Application Design but often it is necessary to produce a prototype to mitigate risk due to requirements missing detail and answer any remaining questions. There should be an expectation that a prototype may feedback on the requirements and change them.

Ultimately a prototype will result in a presentation to the stakeholders and re-enforce the usability, estimated effort, technology recommendation, design challenges and the missing or poor requirements.

There are a number of different types of prototype:

• UI prototype

• architecture prototype

• feasibility study (for example for BizTalk or Commerce Server)

However, there are only two categories of prototype:

• Mockup (also_ horizontal prototype_) – take a single, horizontal picture through the system and often help to validate use cases, navigational structure and logical interactions. However, they don’t prove any of the architecture or technology decisions.

• Proof-of-concept (also vertical prototype _**and **_reference architectures)_ _– validates requirements and confirms the technology recommendations and high-level design usually through all the layers (UI, services, business objects, and database.) Typically a riskier requirement is chosen in order to mitigate any risk further down the development cycle.

Key to a prototypes success is that it answers questions or risks arising from the requirements. For example, there are the following risks:

• _Confirm a server-side versus client-side experience – _this might for example prove that the added complexity of javascript for client-side validation is worthwhile due to the reduce server trips.

• Confirm the application container – this relates to the master-page or MDI style UI design that dictates the way all other UI elements are brought together in the final solution.

• Define user interface elements – classifying the screens required in the system help to understand the scope of the system. Once classified their complexity can be defined in terms of functionality (read/write), the number of elements, the user interactivity, and the access to and from the screen. There are a limited number of screen types:

  • data entry form

  • data list form

  • wizard

  • _report
    _

• Evaluate web service recommendations – consider:

  • how will users be connected?

  • how will the application behave if the connection is lost or is slow?

  • how will transaction reliability be managed?

  • will all calls be synchronous?

  • how will concurrency be managed?

  • will the calls require securing and how?

• Evaluate the proposed security model – consider:

  • feasibility – for example do all users have accounts and do all target browsers support the authentication type?

  • authentication

  • authorization – at what level(s) will the authorization occur?

  • access rights to resources – how should internal application elements be secured (e.g. database connection string.)

  • connectivity between resources – are there firewalls to consider?

• Evaluate third-party applications or controls

• Evaluate proposed data access and storage methods

• Evaluate your state management decisions

• _Confirm and refine the recommended architecture – _this might include confirming a proposed new framework fulfils its purpose. This would also prototype the layering proposed in the architecture.

Chapter 2 : Decompose Specifications for Developers

Creating a Logical Model

The logical is the first step to bridging the gap between documented requirements and a finished application and represents the logical objects, attributes, relationships, and constraints of your domain. The logical model is applied against the technology recommendations and target architecture to create developer specifications (a physical model.)

Logical models should remain fixed unless they’re wrong (!) or the real world concepts, on which they’re based, change. Logical models are independent of architectures and technology.

Object Role Modeling

Entity-Relationship diagrams tend to be primarily associated with databases, and class diagrams are associated to physical, object-oriented development. ORM diagrams are purely logical and allow users, business analysts, and developers to all understand the domain.