Install, Configure and Test a Recommended Development Solution

Reading: Install, configure and test a recommended development solution

Install, configure and test a recommended development solution

Inside this reading:

Configuring hardware 2

System architecture issues 4

Vendor guidelines and issues 5

Configuration management 6

Documenting system settings 6

Testing/tracking errors 8

Test schedules 8

Validation 9

Evaluation 10

Producing support materials 11

Agreements 12

Summary 13

Configuring hardware

There are numerous steps and related issues to assembling the appropriate hardware for development and then final implementation. They include:

· Initial approval—Obtaining management signoff to allocate the appropriate funds.

· Purchasing—In some large organisations this process can take an excruciating amount of time and ‘blow–out’ implementation and delivery timetables.

· Installation—Often servers will need to be installed by others who, in some cases, do not fully understand multimedia. This means that work must be monitored carefully to ensure everything is assembled correctly.

· Testing—Is performance acceptable? Does it satisfy the functional requirements?

· Commissioning—Final move to the production environment with full backup and redundancy systems in place, as well as a ‘back out’ plan.

For more information about these issues read the article ‘Managing Large-scale Multimedia Development Projects’ in The International Journal of Engineering Education, Volume 14, Number 6. Available at: http://www.ijee.dit.ie

A note on testing

One of the most common problems that project managers and developers deal with is obtaining the right hardware to test their systems. It is not uncommon for projects to be delayed due to specialist hardware (on order) taking longer to arrive and be installed than expected. This is exacerbated for external consultants who are relying on internal staff to do these tasks, but are not under the same delivery pressure or time constraints. (This fact needs to always be addressed in initial contract negotiations with the client or management.)

Hardware setup

Figure 1: Diagram illustrating a proposed system

The setup of development hardware is also very important. Diagrams such Figure 1 illustrate the way the system is proposed and are useful for discussing the hardware setup in a conceptual form early in the project. It is obviously much more difficult to make changes once expensive equipment is purchased and set up. When documenting configurations, graphics describe systems quickly and easily.

System architecture issues

Installing and implementing an IT solution onto a large system can be quite complicated. It is true that many of the issue and risks should be identified and addressed in the design phase. Although, while it is easy to design a system on paper, it is a different thing to physically monitor how an information system functions.

There are numerous issues to address. For larger-scale projects, some of the key points to focus on include:

· Does the system falter when a large number of concurrent users log on to the system?

· Does the system perform efficiently from remote sites?

· Is data access a problem? Should the database be installed on its own server?

· Are applications distributed across the organisation and, if so, what type of middleware is involved?

· Does the firewall affect performance?

· In what way is important information protected?

· Can users access applications when they are needed?

· Is network capacity (bandwidth) appropriate?

Vendor guidelines and issues

Software development, installation, implementation and use are not an exact science. As we know, there are many platforms, operating systems, hardware differences and computer configuration settings that can interrupt the way a software application works.

Many vendors do not guarantee their products to work in every environment. Notice that every time you install a Microsoft tool, you generally have to accept the agreements before being able to load it. Most users do not read these agreements, they just click ‘Yes’ and get on with using the software.

Vendor agreements generally state that their software will work on most modern systems, but the ultimate responsibility lay with you, the user. For simple applications like Microsoft Word or Excel, the licence agreements (vendor instructions) do not matter so much, as the software is designed to run on a stand–alone computer in a simple format.

However, some enterprise software applications are much more complex, and a full understanding of the vendor guidelines is of greater importance.

For example, if an email project involves installing an off-the-shelf solution onto a corporate server/environment, who then takes responsibility for the support?

From a vendor’s point of view, how can they be responsible for their software when it is being installed on a system they know nothing about? (eg the vendor may not know anything about the server/firewall security settings, the database conventions, nor the users’ desktop environments). If this is the case, then how can they support the product and, if they do, how much would they charge and how long would it take for them to understand the problems?

The above example is just one issue, but it does highlight that large enterprise solutions are complicated and often costly to support. Therefore, the vendor guidelines need to be understood and adhered to in a professional manner.

Configuration management

Documenting processes, procedures and configuration is an important part of quality assurance. It can be time consuming but the advantages are significant and worthwhile.

Documentation provides stakeholders with a common point of reference, and allows for problems to be spotted early on, which may prove more costly to correct at a later stage. The types of document which are typically produced or updated in the implementation stage of project are:

· project management scope and critical constraints

· file storage and backup procedures

· alpha and beta testing procedures

· implementation procedures

· user manuals, technical manuals, configuration settings

· help files

· evaluation report

· final report.

It is important for the development team and the client to have a clear understanding of the importance of the content of these documents, and this is facilitated by effective communication channels.

Documenting system settings

Documentation is always essential to have; however, if others are going to be responsible for supporting the application then it increases in importance.

Hardware

In terms of the system hardware, documentation should include:

· server type and number

· workstation type and number

· hardware specifications of each server or workstation

· links (types of connections, cables, speeds, etc)

· specifications of the development environment

· hard disk configuration

· chipset type and number.

Software

In terms of the system software, documentation should include:

· settings (resolution settings, eg if designed for 800x600, 8 bit colour, etc)

· versions (eg of the authoring software, browsers, etc)

· security settings (for IIS, firewalls, etc).

Testing/tracking errors

Generally, final testing is best done by users not involved with the project. They will, more than likely, approach the software from a different perspective and see elements of the solution that the developers could not see.

The beta test is a full systematic test of the final product. Beta testing should occur on software that is close to production release and has gone through rigorous alpha testing previously. It has clearly documented procedures for testing, including what to examine and how to examine it.

The idea of beta testing is to complete a collaborative test. The main beta test group should represent ‘everyday’ end users. They should have had little exposure to the system before and not been involved with the development process. The idea is that they provide generic feedback on the system, what they like, what they don’t like and what issues or problems they have generated.

Any feedback should be recorded and collated, then analysed by the developers to determine what fixes or revisions are needed. This can be complicated, especially when the feedback is contradictory. If mixed results are produced, the sampling number will have to be increased to produce a clearer result.

Test schedules

The creation of testing schedules generally does two things.

Firstly, it adds to the structure of the testing process and generally increases the systematic approach that should be taken. Ad-hoc testing, while useful in an in-house environment, should be avoided when moving towards the beta testing phase.

Secondly, it creates an artificial timeframe that motivates different groups to complete the testing faster and on time. It many ways it gives stakeholders (especially end users) a sign that the project is reaching a point of closure. Without a published schedule, projects can drag on indefinitely.

Validation

Validation is the process of testing whether the final program meets the original goals. This is done by assessing real scenarios where users complete a process from start to end. The testing components, alpha and beta, are usually considered a sub-part of validation, with validation the larger process.

It is the study of the effectiveness of design prototypes, acknowledging any weaknesses encountered. The purpose of validation is to check to see if the program meets its specified objectives. Realising the objectives of the validation process requires clear testing procedures to be devised.

The process of testing, trialling and revision is cyclical. Program revision sends the team back to the debugging process and on to field testing again. One of the common problems in the process is that 100% testing of the system is impossible, given the limited time and resources available for the project’s lifetime. The pressures to demonstrate working models to clients prematurely is a mistake. This is one aspect of which the developer or Project Manager needs to always remind the development team.

Finally, it must be emphasised to all stakeholders who want to ‘finish the job off’ that validation, while it is usually a painstaking procedure, is an essential part of the total quality assurance process and has to be allowed to be completed professionally.

Evaluation

An effective product user checklist should provide an opportunity for global and generic user feedback on the prototype. As an example, a final checklist may answer the following types of questions.

Does the product:

· Generally meet the client’s functional requirements?

· Provide a professional ‘look and feel’ to gain the user’s attention?

· Use media elements (eg sound, animation, graphics, video) to clarify, explain, and support textual information?

· The product functions on all platforms (eg Mac, PC)?

· Text is grammatically correct with no spelling mistakes?

· The product has a consistent and intuitive navigational interface?

· The product is completely functional and all components work?

· The product provides enough interactive opportunities?

· The product contains a main menu of major program sections?

· There is a set beginning, middle, and end point so that users can tell how much information the program addresses and where they are within it?

· There are appropriate title screens and/or headings?

· Feedback is provided to the user that is immediate?

· Help files are provided (eg readme.txt)?

· There are references or links to additional information for those interested in the topic and who want more information?

· The product engages the user?

Producing support materials

When the final product is completed, or nearing completion, support materials (user documentation) need to be produced. This documentation, aimed at clients and end users, is important in creating a professional feel about the product.

Support materials might include digital ‘Read me’ files, ‘Help’ resources, printed technical, training or user materials, user-licence agreements and copyright notices.

Often, the design of these materials is left as one of the last things done, with the result that user documentation is sub-standard and does not do the job for which it is intended. In projects running behind schedule, one often finds software being trialled in advance of the production of support materials. Some consider that this isn’t satisfactory and compromises the reliability of trialling. On the other hand, some feel that it is not wise to put too much time into the support materials until the final product is 100% complete.

When developing the support materials, remember that staff change in organisations and it is possible that someone new may have to pick up a manual and ‘run with it’.

One tip is to utilise screen dumps, graphic displays and diagrams as much as possible to ensure the instructions are as simple as possible.

Also, if at all possible, place the user and help resources on the organisation’s intranet or the Internet. The reason for this is that it is so much easier to maintain version control.

Agreements

Agreements between client and hardware/software installers are important in making clear the obligations of each party. This agreement should be documented in a service level agreement. This document should go about trying to limit the consequences of settling any disagreement at a later stage, as could this could affect the project in terms of lost time and cost.

If the client is accepting that a new development project is installed and implemented, then the written agreement should deal with:

· the installation structure and specifications

· the ownership of the hardware and software

· future contract rates for hardware/software support

· future maintenance and support conditions

· licence details for existing software

· duration of licences

· whether the software is restricted to a particular place or equipment

· resolutions for installation problems.

The idea behind the (sometimes excessive) documentation is to protect both parties.

Summary

When commencing the commissioning of a professional software application project there are numerous hardware and software issues to consider. As the system progresses, continual evaluation (fine tuning) of the hardware and software components should occur to achieve a polished product. Once the installation is complete and signed off, then it is time to move on to the final areas of end user delivery, marketing and project/business evaluation.

1735_Reading.doc