Maintenance Agreements

After development of a site and 90 day code warranty period is up, a Proactive or Reactive Maintenance agreement will need to be in place if Salva O'Renick will continue to host a site. Below are the details that make up the respective maintenance agreements.

1. Proactive maintenance agreement

1.1 Architecture

The website architecture for a content based site is generally comprised of the follwing entities that need updating: server and server dependencies, framework or language code base, CMS, and CMS plug-ins.

1.2 Frequency of Proactive Maintenance

At an agreed upon frequency (example: every month on the 15th) for the duration of the agreement, Salva O'Renick will check all available components that can be updated that are associated with the site architecture.

1.3 Documentation of Proactive Maintenance

Proactive maintenance will entail checking against a list of all server dependencies, plug-ins, versions of code and CMS, and updating each entity if an update is available. If no update is available, details will be documented of the date and the site used to verify that an update was not available.

1.4 Notifications during Proactive Maintenance

Salva O'Renick will notify the client through the proper channels of the items that will be updated and when that update is complete. Due to the unpredictable nature of what an update can entail from subject matter and file size, estimates will not be provided before work is executed. Rather, work will be executed at an agreed upon rate and charged to actuals. A similar approach will be taken regarding the amount of time it will take to complete the updates.

1.5 Tasks performed during Proactive Maintenance

Tasks that are performed as part of a pro-active maintenance approach include research, documentation, executing updates, QA, and AM/PM time.

Research:

Comparing against the list of all entities that make up the client website and finding if any updates are available.

Documentation:

Documenting the date of when the item was checked, what version the applicable update is if available, the site referenced for looking if an update is available, what changes are expected with the update, the standardized script that was used to test.

Executing Updates:

Due to the unpredictable nature of how frequently updates are available and varying file sizes, the act of updating can vary in the amount of time it takes to perform all updates.

Quality Assurance:

QA will take place on a standard script to test each element. Everytime an update takes place, the same test will be performed to validate functionality. The only deviation that will take place is if the update in question has changed behavior or the nature of the entity. If said change has occurred, the testing script will be updated and tested against for future versions.

Note: No guarantee can be placed that an updated entity does not have an ill effect on performance another part of the site outside of the core area of concern for the entity. Bugs that are found as a result of a newly updated entity will be handled separately.

AM/PM Time:

AM/PM time will be used to check against the list of all available entities for the website. AM/PMs will also communicate with the client the status of updates, as well as updating internal task management systems to provide developers with the necessary items and information to execute updates.

2. Reactive Maintenance Agreement

2.1 Architecture

The website architecture for a content based site is generally comprised of the follwing entities that need updating: server and server dependencies, framework or language code base, CMS, and CMS plug-ins.

2.2 Frequency of Reactive Maintenance

Bugs or architecture updates not as a result of code misconfiguration or server setup, will be dealt with on a case by case basis when reported to Salva O'Renick by the client.

2.3 Documentation of Reactive Maintenance

Reactive maintenance will entail documenting for the client the findings of troubleshooting and/or research of the bug or update.

2.4 Notifications during Reactive Maintenance

Salva O'Renick will notify the client through the proper channels of the items that will be updated or steps executed or proposed for troubleshooting and estimated timelines. If estimated time for troubleshooting exceeds the allotted hours agreed upon in the reactive maintenance agreement, notification will be given and the option to use hours from the following month or a separate scope can be determined.

2.5 Tasks performed during Reactive Maintenance

Tasks that are performed as part of a reactive maintenance approach include research, documentation, troubleshooting and/or execution of updates, QA, and AM/PM time.

Research:

Research into the nature of the issue or updates in order to be able to estimate and scope executable steps.

Documentation:

Documenting the date of when the item was checked, what version the applicable update is if available, the site referenced for looking if an update is available, what changes are expected with the update, the standardized script that was used to test.

Executing Updates:

Development time to alter the code for all originally scoped devices.

Quality Assurance:

QA will take place against a script to test each functional element across the originally scoped compatible devices.

Note: No guarantee can be placed that an updated entity does not have an ill effect on performance another part of the site outside of the core area of concern for the entity. Bugs that are found as a result of a newly updated entity will be handled separately.

AM/PM Time:

AM/PM time will be used to communicate with the client to obtain the necessary information for the update or bug request, as well as the status of updates when they are in workflow. AM/PM time will also be spent updating internal task management systems to provide developers with the necessary items and information to execute updates.