Date: February 20, 2004
Analyzing Requirements and Defining Microsoft.NET Solution Architectures, Part IV...
Gathering and analysing requirements (operational and infrastructure).
Date: February 20, 2004
The aim of this series of articles is to provide an overview of issues surrounding the architecture of .NET Solutions. In doing so it is following Microsoft's recommended approach and, in particular, looking at the requirements of the related Microsoft certification exam (70-300), which itself is one of the requirements for the MCSD .NET qualification. The main reference for this series of articles is the Que publication: 'Exam Cram2 .NET Solution Architectures'.
We've looked at the following thus far:
Article I: phase 1 of the process, the Envisioning Phase.
Article II: started on phase 2 (gathering and analysing requirements) focussing on business requirements.
Article III: continued with phase 2, focussing on user requirements and issues surrounding globalisation and localisation of your application.
In this article we complete our look at phase 2 with a consideration of operational and infrastructure requirements.
The key areas for consideration are Performance, Availability, Security, Scalability, Maintainability, Accessibility, Deployment and Extensibility (PASSMADE being a useful aide memoire care of Cornish et al.). Briefly considering these in turn:
Performance is particularly key for web applications, as Windows Forms application will use local processing power for the majority of the time. For web-based applications the chief performance criterion is response time. The following major factors affect response time:
In the web environment many of these factors are outside of the scope of your application and will always be an issue. However, you can aim to minimise these issues as far as is possible by keeping a focus on performance from requirements through to implementation. The key aim is to avoid unnecessary complexity or overhead that could further degrade performance (see scalability).
Availability is the amount of time a system or component is online, ready to perform its specified function. Hence availability is closely related to reliability, as availability is reliability plus the time required to bring a system back to normal operations after it goes offline.
It is easy to state a requirement for 99.9% availability but is this really needed and is meeting the requirement worth the extra cost? Start by analysing the current system to discover how often and where failures occur, the root causes of these failures and possible ways to reduce or eliminate them. Considering usage patterns for the application will be helpful. What are customer expectations of availability? Is downtime at night acceptable? Before trying to create an application that never fails, make sure someone actually needs it!
Major areas impacting on availability are:
You may rightly think that given the above the requirements gathering phase may have a reduced impact on availability in comparison to other phases but a consideration of the availability requirements at this stage is key.
A key operational requirement is security. In the requirements-gathering phase the focus is on recognising current and future threats and developing security measures that counteract these real or implied threats. Most security measures are based on the following concepts:
There are several tangible requirements that should be part of any organisations security policies, e.g.
Threats to a business's applications commonly fall into the categories of either data tampering or denial of service attacks.
You should of course consider the nature of the data/ application in deciding an appropriate level of security. You should also ensure security is monitored and improved after the application has been deployed. Taking the example of software patching: as a matter of course security issues with the software used should be monitored and the necessary patches/ remedial actions applied. Alternatively employ tools to ensure this process is automated and in fact this is a feature of Windows 2003 Server.
Scalability is the ability to increase system capacity by upgrading hardware and software without extensive modifications to the application software. Scalability is not an issue for standalone applications but for distributed applications. Most scalability issues are resolved during the design phase and initial implementation. There are still many issues that should be considered when gathering requirements. For example an application’s scalability requires a balance between hardware and software – poor choices regarding scalability in one can adversely affect scalability in the other.
It is also important to note that maximising application performance and maximising scalability are separate issues and maximising performance may in fact compromise scalability and vice versa.
Scaling up is achieving scalability by using faster hardware (single machines).
Scaling out is achieving scalability by using more hardware (multiple machines). This has more significant implications for program design.
Key factors in order of increasing impact on scalability are:
Thus it is key to ensure your requirements right when it comes to scalability.
Your application should be designed in such a way that it can be maintained and repaired easily. Maintainability is defined as the ease with which a software system or component can be modified to correct faults or errors, improve performance or be adaptable to accept new functionality. Maintainability is a measure if how easy it is to keep the system functioning. Maintainability requirements define how the system is to be maintained at an operational level after it has been put into production. For example:
Example objectives of maintainability requirements are:
Key factors affecting maintainability requirements are:
Maintainability requirements should be concerned only with modifications made between major releases of an application and should be specified quantitatively.
This means equal access to computer software to all including people with cognitive and physical disabilities. In terms of software design this has two meanings: making the software as flexible as possible to accommodate as many users as possible as well as making the software compatible with assistive technologies used by people with disabilities (e.g. screen readers).
Accessible design is a requirement to receive the Certified for Windows logo.
General guidelines:
Microsoft Active Accessibility 2.0 is a COM-based technology that improves the way accessibility aids work with applications running on Microsoft Windows operating systems.
If your application is web based give accessibility particular consideration as it is estimated that 8% of all web users are disabled.
Who are your users; where are they and how do you intend to deploy your application to them? Users can usually be separated into 3 categories:
Factors in the deployment strategy are the range of operating systems and configurations of users computers and the specifications of the connecting network infrastructure.
How should the application be distributed? Options are:
For example, if you only have limited bandwidth between sites and a limited number of sites CD deployment may be preferable to network deployment.
Extensibility is the degree to which an application can be enhanced in the future to meet changing requirements or goals. Extensibility is also known as adaptability, changeability, expandability, extendibility, and flexibility.
An extensibility objective might be to ensure that future enhancements to an application can be easily and quickly implemented.
When creating extensibility requirements it is helpful to have a full understanding of the environment your application will reside in and to try to predict in which directions the application may need to evolve in the future.
Extensibility can be tightly coupled with scalability so extensibility requirements should include the ability to enhance data, hardware and software components.
The existing infrastructure might not have the capability to support your new application. Will your application design be unacceptably limited by the current infrastructure? Is this an issue that requires addressing for the project to be successful?
The first step in the process is identifying the current infrastructure and evaluating it against the new requirements, particularly with regard to the PASS MADE operational requirements (above). Some areas for consideration are:
This article completes our look at the requirements analysis phase. Next up we investigate the topic of producing specifications for our project.
Exam Cram 2 .NET Solution Architectures
Cornish et al.
Que
http://msdn.microsoft.com/architecture/