1 INTRODUCTION
1.1 PURPOSE
This document is intended to provide a client who wishes to outsource a web development effort with a summary of commercial, scope-of-work and project management considerations applicable to his contract with the software developer.
The issues are presented as a combination of both general considerations or topic items that should be negotiated with the developer, and recommended “bolt in” clauses. In both cases, the issues must be adapted and configured to be consistent with the broader context of the work actually undertaken by the developer.
2 SCOPE
Ensure that the scope of the outsourced effort is defined within the contract. An example of a high-level scope definition is:
The developer shall:
• Define requirements
• Create the documentation
• Perform a system design
• Create copy (displayable content)
• Write the code
• Create iterative software releases
• Perform tests to prove the code conforms with specifications
• Host the code on a suitable server
• Administer the system
• Provide on-going maintenance of the system
3 SCHEDULE
Ensure that the contract specifies the dates of all significant milestones, such as:
• Iterative software releases
• Key inputs from the client
• Test dates
• Final release
• Document submissions
• Payment dates
Having milestones or review points on a weekly or fortnightly basis is a good way—once the project is running—to measure whether the project is proceeding on schedule and is thus likely to finish on time.
4 PAYMENTS
The contract should specify the total project price, when each partial payment is to occur, the conditions that are to be satisfied to claim the payment (e.g., successful iterative software release and test), and all recurring costs such as on-going maintenance.
Other payment considerations include:
• How are payments tied to milestones that are of significance to the client?
• Do incentives exist for on-time performance? It can be useful to structure the payments such that a portion of the total sum is paid as a “bonus” for early or on-time delivery or to apply penalties for late deliverables. Although they are essentially the same thing, the former employs better psychology.
• What payment withhold provisions are in place should bugs be discovered during testing of the iterative releases, the final release or within, say, six months of the final release?
5 REQUIREMENTS
The most important task in creating a software product is defining the requirements—a process which is generally called requirements analysis. Clients often only describe an abstract idea of what they want as an end result. The danger is that the final product fails to meet client expectations.
The following sections can aid clients in reducing this risk:
5.1 FUNCTIONAL REQUIREMENTS USING “USE CASES”
A use case describes the software behaviour from an external perspective. In other words, a use case describes who can do what with the system. Use cases are deceptively simple tools for describing the behaviour of software and systems. A use case contains a description of all of the ways which the intended users could work with the software or system, but they do not describe any internal workings of the system, nor do they explain how that system will be implemented. They simply show the steps that a user follows to perform a task.
Use cases are typically written in the language of the end user and avoid technical language, and are often co-authored by the systems analysts and end users. A simple example of a use case is:
1. The system prompts the user to log on.
2. The user enters his name and password.
3. The system verifies the logon information and determines his class.
4. The system logs the user onto the system and presents the menus available only to that user’s class.
5.2 ITERATIVE SOFTWARE RELEASES
Iterative development is where initially small but ever larger portions of a software project are released to help uncover issues early—before problems or faulty assumptions can lead to project delays and budget overruns.
Iterative processes are often preferred by commercial developers because it allows a potential of reaching the design goals of a customer who is not necessarily experienced in defining exactly what they want.
Software changes and bug fixes applied in earlier project stages are significantly cheaper compared to those implemented in later releases.
5.3 GENERAL REQUIREMENTS
Define general requirements such as which CMS platform (e.g., Joomla) shall be used, user interface style definitions (e.g., colours, “look and feel”-type descriptions, etc), performance milestones (e.g., database size—perhaps defined as number of users, response time with x simultaneous requests occurring, etc), and general web design requirements as listed in Section 11.
5.4 FINAL DELIVERY REQUIREMENTS
Specify how the deliverable copy of the released software is to be delivered and verified that it is complete. For example, in the context of a development utising a SQL database: “Separate front end and SQL database backups are to be provided on DVD, and they shall be verified by firstly deleting all content on the live server, and by then performing a restoration of the server using the backups from this DVD.”
6 TESTING
Software testing is used to ensure that the product meets the client’s expectations—as defined in the requirements. Generally, it should be proven that every requirement is satisfied by the delivered system. Testing can be performed both during the software development process (e.g., at each iterative software release) and/or upon release of the final software.
For larger development efforts the details of the testing process can be formally documented within a Test Plan which specifies the “how, what, when and where” of the testing, or it can be a relatively informal process—such as annotating against each requirement when (i.e., in which release) the requirement will be tested.
Comprehensive system testing can be expensive, so one option is for the client to do some or all of the testing themselves.
7 SUPPORT
Define ongoing maintenance requirements and agreed turn-around times (e.g., “fix major bugs within 48 hours and minor bugs within one week of notification”) and define what constitutes a major and minor bug.
Define software administrative requirements, such as system backups (frequency of backups, where backup media is to be stored, etc).
8 DOCUMENTATION
There are several documents that clients should require from their developer:
8.1 SYSTEM DESIGN DOCUMENT
Documenting the internal structure of software during design and development is important to support future maintenance and improvements. At minimum, this document should include:
• A list of all configured items and their configuration parameters
• A list of all external (or “bolt in”) products, modules with their version numbers
• Details of the licensing provisions of all third-party products used within the design
• A copy of all source code used in the design
• Security considerations, including all accounts for the front end, back end and hosting domain—such as the “username” and password that the CMS platform code uses to access the database—and all security measures in place within the code, such as unauthorised access countermeasures, whether the .htaccess file disables directory listings for the inner folders, whether a robots.txt file is used, all file permission settings, etc.
8.2 ADMINISTRATOR’S GUIDE
This document should list the administrative and configuration considerations of both the CMS backend and the SQL database, such as hosting platform URL and access details.
8.3 USER’S GUIDE
This should be aimed at non-technical users who will do copy updates (e.g., article publishing or editing)—based upon whichever CMS platform is being utilised.
9 TRAINING
At minimum, a training outline or training guide is necessary for the subsequent provision of training to the non-technical staff who will do the day-to-day publishing updates using the CMS backend.
For complex systems, consider obtaining training from the development company itself.
10 SOFTWARE SUPPORT
Maintenance and software enhancements to cope with newly discovered problems or new requirements can take more time than the initial development of the software. How will this be handled by the developer? A discounted hourly support rate is often specified within contracts.
11 MISCELLANEOUS WEB DEVELOPMENT CONSIDERATIONS
The following sections define issues that should be addressed within the scope of work (SOW) of any web application development, and are presented in clauses suitable for inclusion in a SOW or contract.
11.1 COPY
• Copy shall be produced by the developer and shall be submitted to the client for review.
• Copy shall be checked for spelling, punctuation and grammar.
• Copy shall employ consistent use of capitalisation, writing tense and style, recurring phrases, variations of the same expressions, and list endings.
11.2 LEGAL
• The web site shall contain the registered company details. (Note: This is an ASIC requirement for all company “documents”.)
• User-editable footer copyright date and text shall be present on each page.
• All external copyright and trademark products shall be cited.
• Adequate privacy disclosures shall be included on sign-up pages.
• If needed, provision shall be made for a user to easily “opt out” of any subscription.
• No links or meta descriptions to the developer shall be present in the code without the written consent of the client
11.2.1 Intellectual property
Ownership of intellectual property rights and moral rights to the final delivered product, including that of all third-party code used within the product (including but not limited to the templates, modules, plug-ins, photographs, etc) shall revert to the client upon final payment from the client for the product.
11.3 FORMAT
• Email or telephone contact details shall be included at each footer and/or in the contact page.
• All pages should be capable of being printed from a browser to ensure correct printed appearance.
• An easy means for users to increase or decrease the displayed text size shall be provided.
• All forms shall be checked to determine that they work as intended and that they are not easily broken by users—such as by entering numerical values into text input fields.
• The pages shall view correctly on a 1024×768 resolution screen. (Note: Many developers have larger screens.)
• The site shall appear reasonably consistent on the following browsers:
o Internet Explorer versions 6, 7 and 8
o Firefox 3
o Chrome
(Note: Internet Explorer and Firefox possess approximately 90% of the browser market.)
• Users must be able to navigate the site without Java, Flash, or any other browser “plug-ins” enabled. (Note: Approximately 5% of web users do not have Java enabled.)
• A favicon.ico site icon shall be created and utilised in the design. (Note: This is the unique site icon that appears in the browsers’ tabs and in the bookmarked lists.)
11.4 SEARCH ENGINE OPTIMISATION (SEO)
• Appropriate “alt” attributes (e.g., title and description tags) shall be set for all images and hyperlinks.
• Provision shall be made to enter a unique meta title (which shall be independent of the title displayed on each page), meta description, and keywords for each page.
• Meta tags that are unique to each page shall incorporated into an easily editable section of the backend code. A summary of the meta data, and how it shall appear in Google results pages, shall be provided to the client.
• Content headings shall be supported by H1 through H5 HTML formatting.
• An XML Sitemap file shall be created which shall define every user-accessible page, and the format of the file shall be consistent with Google Webmaster Tools requirements.
• The value of the "rel" attribute of links to external sites (or to internal pages containing public comments) shall be set to "nofollow”. (Note: A site's reputation can be adversely affected by the content from external links.)
• Each virtual HTML page code shall incorporate Google analytics code. (Note: This sets up analytics to easily monitor user traffic patterns.)
11.5 NAVIGATION
• All navigation menus, categories and filenames shall be in a human-friendly format.
• Breadcrumbs, being the text descriptions at the top or footer of pages, shall be used to help users navigate through the site.
• The site shall contain a sitemap page that automatically lists all new content without operator intervention.
• The site shall contain a site search facility.
• The site shall contain a back-end configurable "error 404" page to gracefully handle users who follow a broken link or type the wrong URL.
• The XHTML code shall be validated to check grammar, vocabulary and syntax, such as at http://validator.w3.org/
• The CSS code shall be validated to check grammar, vocabulary and syntax, such as at http://jigsaw.w3.org/css-validator/
11.6 SECURITY
• An analysis shall be performed by the contractor at project commencement to identify the likely security risks and the methodology proposed to reduce these risks.
• All necessary read/write permissions for files and directories shall be set to appropriate levels, and details of this shall be recorded and provided to the client.
• A robots.txt file shall be created to prevent search engine access to inappropriate parts of the site.
• Email or SMS alerts shall be sent to at least two of the client’s representatives in the event of a system error or failure.
| < Prev | Next > |
|---|