Software Development Works Agreement Statement of Work

2 Documentation

Referred documents:

3 Solution description

The Mobile Client application will feature the following characteristics:

3.1 Features from User Prospective

The Mobile Client will support the features specified in document [1].

Concerning UI look and feel, document [1] “▇▇▇▇▇▇ Mobile Application Requirements” provides a high level reference framework.

During the work, the user experience of Mobile Client will be jointly agreed with ▇▇▇▇▇▇.

3.2 Quality Target for the application

The quality target of the Mobile Client application software is listed in the following table.

3.3 Support

Support during Warranty will be as per the following Service Level Objectives

4 Qualzoom Responsibilities

4.1 General Description

Qualzoom will design, develop, test, and support the deployment of the ▇▇▇▇▇▇ Mobile Client application and server software. The following tasks are to be completed for application deployment:

Task 1 - Qualzoom Project Management

The purpose of this task is to manage the Qualzoom resources, tasks, and issues. This task consists of the following subtasks:

· Prepare the Project Plan identifying the activities, estimates, resource assignments, and dependencies required to design, port, test, and support the Mobile application.

· Conduct weekly status meetings with ▇▇▇▇▇▇. Items to cover:

- Accomplishments of the period

- Plans for next period

- Issues

- Development Status (summary percentage of developed code and other software metrics)

· Serve as the single point of contact for development

This task is on-going through the term of this SOW and will be complete when the Mobile Application has successfully passed Acceptance Testing.

Task 2 - Software Release development

The purpose of this task is to develop the software releases of the ▇▇▇▇▇▇ Mobile Application solutions.

The development will go through various Beta Releases, Release Candidate for Acceptance and the Final Release.

The Beta releases will provide all the application functions in an incremental fashion. Such releases will be given by the development team to the testing team for verification purposes. The purpose is to verify usability, UI design, Web/DB Server design and compliance with the Klevernet requirement specification.

The final Beta release, referred as the Release Candidate for Acceptance, will be used for Acceptance procedure.

This task will be completed when the ▇▇▇▇▇▇ Mobile Application Release Candidate meets the expected results defined in the Acceptance Test Case Document.

The Release Candidate will be then name as the Final Release to be used for deployment purposes.

Task 3 - IOT and Regression Testing

The purpose of this task is to support the IOT (Inter-Operability Testing) and Regression Testing of the ▇▇▇▇▇▇ Mobile application solution, including mobile and Web/DB Server components on live network.

This task consists in performing test in real case scenarios on Beta Release of the Mobile application. The corresponding results will be document on IOT/Regression Test Reports.

Task 4 - Development during Support phase

The purpose of this task is to provide development support in case defects (as per Table 1 – Service Level Objective) are found during the deployment phase for the duration of the Warranty.

Maintenance releases will be developed to solve defects found during live operation. Each maintenance release will be given to ▇▇▇▇▇▇ and made available to existing customer base through OTA Upgrade.

Task 5 - Verification and Regression Testing during Support phase

The purpose of this task is to provide Verification and Regression Testing support in case defects are found during the deployment phase for the duration of the Warranty.

Each maintenance release will be tested to verify that it fixs the found defects. Such release will also be regression tested to verify that additional bugs have not been added.

A Regression and Verification Testing Summary Report reports the testing result as soon as the maintenance release passes the functional and regression tests criteria.

4.2 Developed Works

The following deliverables are considered Developed Works for the purposes of this SOW. These deliverables were defined in the Responsibilities section and are due in accordance with the estimated schedule in Section 7.

Deliverables of Task 1 -Qualzoom Project Management
· Project Plan

Deliverables of Task 2 -Software Release development
· Release Candidate for Acceptance
· Final Release

Deliverables of Task 3 -IOT and Regression Testing
· IOT/Regression Test Report

Deliverables of Task 4 -Development during Support phase
· Maintenance Release (if any)

Deliverables of Task 5 -Verification and Regression Testing during Support phase
· Verification Testing Summary Report

4.3 Licensed Works

Supplier grants Buyer a fully paid up, exclusive, worldwide, perpetual, irrevocable license to use, execute, install, and deploy the Mobile Application software (“Software”).

4.4 Supplier Restrictions

The license granted herein shall be exclusive to ▇▇▇▇▇▇ and Qualzoom shall not grant any license, or grant any interest whatsoever in, sell, offer for sale to other vendors.

5 ▇▇▇▇▇▇ responsibilities

Task 6 - ▇▇▇▇▇▇ Project Management

The objective of this task is to provide a single point of contact to Qualzoom for development of the Mobile Application software. This task consists of the following subtasks:

· Participate in weekly status meeting with Qualzoom .

· Provide Qualzoom with the ▇▇▇▇▇▇ products, prototypes, accessories, documentation and software identified as dependencies for the development.

Additional requests will be given during the weekly status meetings.

· Provide reviews and approvals on Qualzoom deliverables in accordance with agreed-to timeframes in the Project Plan

· Serve as the single point of contact for Problem Reporting during the UI Testing and Acceptance Testing

This task will be complete when the Acceptance Testing has been successfully completed.

Task 7 - Conduct Acceptance Testing

· Support and attend Acceptance Testing activities

· Finalize the Acceptance Testing Report based on results of the Acceptance Testing procedure

This task completes when the Mobile Application Release Candidate meets the expected results defined in the Acceptance Test Case Document.

5.1 Deliverables

The following deliverables were defined in the previous section and are due in accordance with the estimated schedule in Section 7.

Deliverables of Task 6 -▇▇▇▇▇▇ Project Management
· Supporting docs, Required SW licenses, HW, accessories as required

Deliverables of Task 7 -Conduct Acceptance Testing
· Acceptance Testing Report

6 External Dependencies

Ext 1 - According to section 6 “External interface requirements” and section 8 “Open Issues” of document [1] “▇▇▇▇▇▇ Mobile Application Requirements”.

7 Major Milestones and Overall Schedules

A detailed Project Plan will be developed as part of this agreement by Qualzoom. The following table lists summary of major deliverables. The nature of the work is collaborative, and both Qualzoom and ▇▇▇▇▇▇ will team up to complete the work with the target dates.

The following schedule provides overall schedule for activities listed above. These estimates may be superseded by schedules developed as part of detailed project plan.

8 Overall Resource Allocation

According to the overall deliverables and timelines as described above, Qualzoom will allocate the following resources for the duration of the project:

9 PROJECT COMPLETION AND ▇▇▇▇▇▇ ACCEPTANCE CRITERIA

The development of the ▇▇▇▇▇▇ Mobile Application will be completed when the deliverables defined in Sections 4 of this SOW have been approved with written notification by the ▇▇▇▇▇▇ Project Manager, the Beta trial evaluation period has been completed, and the reported in-scope defects (functional and load) have been successfully resolved and approved by the ▇▇▇▇▇▇ Project Manager.

10 SCHEDULE AND PAYMENT TERMS

10.1 Fixed Fee

Subject to the conditions expressed in this Agreement and SOW, Klever shall pay Qualzoom a fixed price of $210,000 on the schedule set forth in the below for the completed work that is performed under this SOW.

Upon execution of this SOW, Klever shall provide Qualzoom with a supporting purchasing order (PO).

Any additional requirements for funding must be requested first via the Project Change Request (PCR) and finalized with an executed amendment to this SOW.

10.2 Invoicing

Within thirty (30) days of receipt of a correct invoice ISSUED BY QUALZOOM, provided ▇▇▇▇▇▇ has accepted each Deliverable identified in this SOW, Klever will pay Qualzoom the amounts listed in this SOW in accordance with the corresponding payment schedule. All payments shall mean the agreed-upon price and currency in US Dollar.

10.3 Payments

All the payments to Qualzoom, shall be made to the following bank account:

11 Confidential Disclosure Agreements

The disclosure of confidential information between ▇▇▇▇▇▇ and Qualzoom is subject to the terms and conditions of a Confidential Disclosure Agreement and any relevant Supplements thereto. No confidential information exchange between Qualzoom and ▇▇▇▇▇▇ shall occur until after a NDA is signed, which specifies what information is being exchanged.

12 Quality Measurements

Qualzoom represents that it has a product and service quality program that includes:

· Performance targets;
· Assessment of engineering, development and test processes;

· Configuration and change management processes;

· Assessment of the quality of Deliverables, Products and Services;

· Documents non-conformances; and

· Processes to correct errors or other non-conformances. Supplier will periodically, as negotiated, provide Buyer its standard product development life cycle and error metrics.

An example of the data of interest is included in the Appendix entitled “Sample D ata Collection Form for Supplier”.

The parties agree that the Appendix entitled "Quality Requirements for Commercially Available Software" is hereby incorporated by reference into this Agreement.

13 Communications

All communications between the parties will be carried out through the following designated coordinators:

14 Governing Law

This Agreement shall be governed by and construed in accordance with the laws of the State of California, the United States of America, without regard to provisions concerning conflicts of law. The United Nations Convention on Contracts for the International Sale of Goods shall not apply to this Agreement. In the event any proceeding or lawsuit is brought by either Party in connection with this Agreement, the prevailing Party in such proceeding or lawsuit shall be entitled to receive its costs for such action, including its reasonable attorneys' fees and expert witness fees.

Either party may request changes to this SOW at any time. Both the ▇▇▇▇▇▇ and Qualzoom Project Managers must approve each change before implementing it. Any change to the scope of this SOW must be made by a formal Amendment to the SOW executed by the parties. Until a change is agreed in writing, both parties will continue to act in accordance with the latest agreed version of the SOW

The following describes the procedure to be used if a change to this SOW is required:

· A Project Change Request (PCR) will be the initial vehicle for communicating change. The PCR must describe the change, the rationale for the change, and the effect the change will have on the project.

· The designated Project Managers of the requesting party will review the change and determine whether to submit the request to the other party. Both Project Managers will review the proposed change and approve it for further investigation or reject it.

· Prior to amending this SOW, the PCR must signed by both parties.

Supplier will verify the performance of the following processes in order to ensure their ability to support fielded Supplier product and respond to Buyer requirements.

1 SUPPLIER’S DEVELOPMENT AND SUPPORT MANAGEMENT

Supplier will initially document and provide to Buyer the measurement of size of product, the product errata data (e.g., number of defects reported and fixed in the product, number and size of maintenance releases, etc.), and size and makeup of product management, development, and support teams. Supplier’s quality assurance team will periodically measure tracking activities and review with Buyer (Buyer and Supplier will determine frequency of project management reviews, which will not be more than one per year).

2 CHANGE MANAGEMENT PROCESS ASSESSMENT

2.1 Assessment Elements

Supplier’s quality assurance team will determine the status of product support activities by making appropriate periodic measurements and reviewing with Supplier project management, Supplier senior management and Buyer. An initial assessment of product support and change management processes has been made by Buyer, with presentation by Supplier’s quality assurance team. Ongoing assessments, as appropriate, will be made at twelve (12) month intervals, or otherwise as agreed by Buyer and Supplier.

Assessment Elements will consist of the following, at a minimum.

a) Review of the overall change management (CM) process used by Supplier to manage change and/or enhancement requests for the base product and any Buyer specific deliverables.

b) Review of the CM plan and status of CM activities against plan for Buyer specific deliverables and base product changes and enhancements.

c) Change request summary and status for Buyer specific deliverables and base product changes and enhancements.

d) Trouble report summary and status for Buyer specific deliverables and base product changes and enhancements.

e) Completed work, expended effort and resources in CM activities for Buyer specific deliverables and base product changes and enhancements.

f) Results of configuration item baseline audits for Buyer specific deliverables and base product changes and enhancements.

g) Review of project schedules, issues, concerns, relevant technical specifications, and testing status for Buyer specific deliverables and base product changes and enhancements.

h) Buyer participation in testing process prior to release including scenarios, test plans, integration and scalability testing and beta release.

3 REVIEWS

On a periodic basis, if deemed necessary due to high defect rates experienced by Buyer in Supplier’s product, Buyer or Buyer’s quality representative may conduct reviews at Supplier’s and Supplier’s sub - tier supplier’s development locations. Supplier may, at

Buyer’s request and at a mutually agreeable time, permit access to Buyer to Software

Development operations and inspection of interim and final change management deliverables for Buyer specific and base product deliverables, including access to the sub -tier supplier facilities. Reviews shall include review of Supplier product process control, quality inspection test data, internal audit reports, and other information related to the product being procured to verify compliance to the terms of this Software Supplier Quality Appendix (SSQA). Under normal circumstances Supplier shall be given at least a two week advance notice by Buyer representatives of their intent to visit. Supplier shall ensure access for Buyer’s auditors to all the s ites where work is being performed or materials being delivered to Supplier in performance of Supplier’s change management work for Buyer specific and base product deliverables. A high defect rate is defined as more than two occurrences of a production out age of Supplier’s product found to be due to Supplier product flaws, or two or more defects in Supplier’s product which affect Buyer by requiring code fixes by Supplier to resolve in any one Supplier product release.

4 DOCUMENT CONTROL

Supplier shall ensure that all documents pertinent to its product, such as software change management specifications and designs, contracts, policies, procedures, software development process flow chart, and work instructions (including test procedures) are under configuration control and are available to all necessary personnel in the development environment. Supplier shall a have a document configuration control system for the effective updating/removal of any obsolete documentation from all development areas.

5 QUALITY RECORDS

Supplier shall establish and maintain procedures for identification, collection, indexing, filing, storage, maintenance, and disposition of all quality records.

6 QUALITY PROBLEM NOTIFICATION TO BUYER

Supplier must notify Buyer of any quality or reliability problems, using Suppliers standard procedures or those negotiated between Buyer and Supplier that may affect Buyer’s use of Supplier’s product. These problems may have been identified by Supplier's internal testing (i.e., process control data, internal test data, quality data, etc.), by third parties who produce products on behalf of Buyer, or by another customer (see ISO 9001).

7 CHANGES

Buyer’s quality representative shall be notified of all software development life cycle process changes, development, test, and support location changes, or development, test, or support outsourcing decisions for Supplier’s product(s) covered by this agreement, at least ninety (90) days prior to their implementation as these changes may significantly affect form, fit, function, quality, reliability or support for Supplier’s product.