EX-10 2 b_kleverex106.htm SOFTWARE DEVELOPMENT WORKS AGREEMENT Software Development Works Agreement Statement of Work

EX-10 2 b_kleverex106.htm SOFTWARE DEVELOPMENT WORKS AGREEMENT

   

Software Development Works Agreement

Statement of Work

 

This Statement of Work ("SOW") adopts and incorporates by reference the terms and conditions of the Software Development Works Agree ment (“Agreement”)

BETWEEN

 

Qualzoom Inc., whose registered office is at ▇▇▇▇ ▇▇▇▇▇▇▇ ▇▇▇▇▇▇▇▇▇▇ / ▇▇▇ ▇▇▇▇, ▇▇▇, ▇▇ ▇▇▇▇▇ ▇▇▇ (“Qualzoom”/Supplier)

AND

 

▇▇▇▇▇▇ Marketing (“▇▇▇▇▇▇”/”Buyer”), whose registered office is at

This SOW is effective upon signature date of this SOW and will remain in effect until the end of the Warranty Period. Transactions performed under this SOW will be conducted in accordance with and be subject to the terms and conditions of this SOW, the Base Agreement, and any applicable Work Authorizations.

The following is incorporated in and made part of this SOW:

· Appendix A Project Change Control Procedure

· Appendix B: Quality Requirements For Commercially Available Software

1 Scope of Work

This Statement of Work defines the effort to develop, test, and support a mobile application solution (mobile client and server) for ▇▇▇▇▇▇ Media’s Giving Cart technology.

The work consists of developing, porting test/integration, deploying and supporting a complete end-to-end mobile application system including client application and backend web application + database development as outlined in ▇▇▇▇▇▇ Mobile Application Requirement v1.0 (Requirement Spec).

The work will be carried out by Qualzoom personnel, with qualification of software developers and system/UI tester and seniority that ranges from Senior to Expert.

The scope of work includes software testing and commercial support. Completion criteria are the successful execution of the test cases during Acceptance Testing.

2 Documentation

Referred documents:

# Title	Version
[1] ▇▇▇▇▇▇ Mobile Application Requirements	1.0
[2]
[3] Other product documentation will be defined during the work

 

3 Solution description

The Mobile Client application will feature the following characteristics:

Platform developing environment	iPhone OS, Android
Tailored for the following handset	iPhone 3GS, iPhone4
models	Android Platform based mobile handsets (tbd)
Supported Localization	English
Over the Air Upgrade	Possible updates will be performed over the air.
	The content server will be hosted by Klevernet

 

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.

Perceived quality parameters	Coverage
Power Management	Addressed, limited to the capability of the OS in
	the mobile handset
Usability and MMI interface	Addressed
Phone application integration	Addressed
SIM and address book integration	Addressed
Standards and Protocols
Standard Compliance and	To achieve interoperability with external system
interoperability	and network APIs
Software related parameters
Exception Handling	Covering most network faults or conditions
Optimization	Addressing optimal usage of the network
	connections
Engineering mode and service mode	Not addressed

 

3.3 Support

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

	Table 1 – Service Level Objective
Category	Definition	Response	Resolution
Critical	Problem reported	24 Hours	Fixes provided as
	halts the application		quickly as possible
	operation completely.		based on
	Users cannot		commercially
	continue using		feasible best efforts
	application until the
	problem is resolved
High Importance	Problem reported	5 days	Fixes provided as
	halts portions of the		quickly as possible
	application operation.		based on
	Users can continue		commercially
	with a subset of		feasible best efforts
	features until the
	problem is resolved
Medium	Problem reported	15 days	During deployment
	negatively impacts
	user experience.
	Users can continue
	with using the
	application.
Low	New feature requests	N/A. Document for	Out of Scope for this
	and improvement	future analysis and	document
	suggestions	resolution

 

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.

Items	Milestones & Deliverables	Responsible	Involved
M1	Signing of the Development Agreement	Joint	Joint
M2	Definition & Approval of all functional requirements	▇▇▇▇▇▇	Review
M3	Design of backed web application & database	Qualzoom	Review
M4	Core mobile client application design	Qualzoom	Review
M5	User Interface Design & Definition	Qualzoom	Review
M6	Test & Integration Plan	Qualzoom	Review
M7	Backend web & database development	Qualzoom	Review
M8	Core mobile client application development	Qualzoom	Review
M9	iPhone implementation	Qualzoom	Review
M10	CPG/Retail coordination and access for data	Joint	Joint
	migration into backend web system
M11	iPhone usability tuning	Qualzoom	Review
M12	System integration & testing	Qualzoom	Review
M13	Beta Release	Qualzoom	Review
M14	Android platform implementation	Qualzoom	Review
M15	Android usability tuning	Qualzoom	Review
M16	Complete system integration	Qualzoom	Review
M17	Deployment	Joint	Joint

 

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:

High level tasks	Resources	Roles
Overall Project management	Program manager	Project manager
Mobile Client Design &	Development Engineer1	Lead Engineer
Development	Development Engineer2	Engineer
Backend Web & database	Development Engineer1	Lead Engineer
design & Development	Development Engineer2	Engineer
Test Plan & Execution	Test Engineer1	Engineer

 

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.

PAYMENT AND MILESTONE SCHEDULE
Milestone	Payment
M1 - Upon on execution of this Agreement	$65,000
M13 – Beta Release	$65,000
M17 – Commercial Release	$65,000

 

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:

	Business Coordinators
For Qualzoom	For
	▇▇▇▇▇▇
Name	Name	▇▇▇▇▇▇ ▇. ▇▇▇▇▇▇▇▇
Title	Title
Address	Address
Phone	Phone	▇▇▇-▇▇▇-▇▇▇▇
E-mail	E-mail	▇▇▇▇▇▇▇▇▇@▇▇▇▇▇.▇▇▇

 

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.

Appendix A

Project Change Control Procedure

 

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.

APPENDIX B

QUALITY REQUIREMENTS FOR

COMMERCIALLY AVAILABLE SOFTWARE

 

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.

   

APPENDIX C

Warranties

 

Supplier warrants to Buyer as follows:

The Delivered Software will be free from errors, will conform to and perform in accordance with the Specifications including User documentation and will function properly.

The Delivered Software will be compatible with and operate with other software, hardware and products configured in accordance with user documentation.

The initial warranty period shall begin upon delivery of the Delivered Software and continue for one (1) year (”Warranty Period”).

The performance warranty shall begin upon Acceptance of the Delivered Software and continue for the period during which Buyer shall be entitled to receive maintenance.

Repaired and replacement Delivered Software shall be warranted as set forth above in this clause. THE FOREGOING WARRANTY IS IN LIEU OF AND EXCLUDES ALL OTHER EXPRESS OR IMPLIED WARRANTIES, INCLUDING BUT NOT LIMITED TO WARRANTY OF MERCHANTABILITY AND WARRANTY OF FITNESS FOR A PARTICULAR PURPOSE.