mP_Proc_SOW_TemplateV1.0

stockingssoyaInternet και Εφαρμογές Web

7 Δεκ 2013 (πριν από 3 χρόνια και 6 μήνες)

67 εμφανίσεις

Statement of Work
for










And


<
<Client’s Logo>
>



<
<Type of Service>
>










<
<
Client’s name>
>



SOW for <
<
type of service
>
>

Development on

Liferay

Version 1.0



Page
2

of
12




Table of Contents

1

Introduction

3

2

Scope of Work

3

2.1

In Scope

3

2.2

Scope Exclusions

4

2.3

Assumptions & Dependency

4

3

Implementation Approach

5

3.1

Global Delivery
-

Offshore Team

5

3.2

Iterative Imple
mentation

6

3.2.1

Requirements Analysis

6

3.2.2

Architecture and Design

6

3.2.3

Development

7

3.2.4

Testing

7

3.2.5

Demo and Deployment

7

3.2.6

User Acceptance Testing and Go Live

7

3.2.7

Warranty

8

4

Team organisation

9

5

PROJECT TIMELINES

10

6

Deliverables

10

7

CHANGE MANAGEMENT PROCESS

10

8

Escalation Procedures

11

9

Project Status Reporting

11

10

Pricing and Payment terms

12

9 Signatories

12










<
<
Client’s name>
>



SOW for <
<
type of service
>
>

Development on

Liferay

Version 1.0



Page
3

of
12



This Statement of Wor
k (SOW) is entered into between

<Client name>

and
TransIT mPower
Labs Pvt Ltd. (‘mPower’)

1

INTRODUCTION

<
<Client introd
uction>
>

is the
lorem ipsum lorem ipsum

lorem ipsum lorem ipsum

lorem
ipsum lorem ipsum

lorem ipsum lorem ipsum

lorem ipsum lorem ipsum

lorem ipsum
lorem ipsum

lorem ipsum lorem ipsum

lorem ipsum lorem ipsum

lorem ipsum lorem
ipsum

lorem ipsum lorem ipsum

.

Based out of Bangalore India,
TransIT mPower Labs Pvt. Ltd
focuses on providing
technology solutions that leverage both strategic and tactical expertise to meet vario
us
business requirements of its
clients.

<<
Client>
>

aims at engaging mPower for

develop
ment of
<Type of service>
. This would be in
various

phases and this proposal covers phase 1 features.
<
<Change this text to match the
requirement>
>

This document provides the
items in
scope, the approach that would be followed and the
pricing terms applica
ble

for this engagement
.


2

SCOPE OF WORK

2.1

In Scope

The scope of services that would be provided as part of this SOW covers the following areas:

The following list of functions and features constitute the scope of the project for Phase I

<
<customize to the
requirement>
>

#

Scope

1

Requirement Elicitation

2


Feature 1

3

Feature 2

4

etc


The following list of functions and features constitute the scope of the project for later phase which
is not a part of the current estimate:

<
<change according to the pla
n>
>

1


2


The scope of the project does not include the following:



Services by any third party if rendered.








<
<
Client’s name>
>



SOW for <
<
type of service
>
>

Development on

Liferay

Version 1.0



Page
4

of
12




Integration to any other system.



Any data migration, onsite facilitation, or end user interaction or coordination.

<
<Add or remove the points abov
e according to the need>
>


2.2

Scope Exclusions

1. Any requirements other than those mentioned in the scope inclusion
section of this phase 1
proposal.

2. Hardware and Software procurements, installation, maintenance, upgrade
for any of the source

systems.

3. Enhancements and/or maintenance activities on any of the source or target systems.

4. The phase1 would use the out
-
of
-
box features of Liferay with bare minimum
cust
omization.

5.
Software
licenses

-

<
<client
>
>
needs

to provide us with the de
velopment
licenses

for
the software that they plan to use (Or fast and easy access to machines where such
licensed software is
installed
)

<
<Add or remove the points above according to the need>
>



2.3

Assumptions & Dependency


1.

<
<
Client>
>

will make available st
aff with suitable knowledge, to liaise with mPower
team and to effect rapid turnaround of any points of clarification raised during the
project lifecycle.

2.

All activities for the project are out from offshore development centre of mPower in
India.

3.

During Op
eration readiness, Deployment and Go live access to production
system is required. During this target production system shall be down

4.

mPower is not a par
ty to any agreement between <
<
Client>
>

and third party
software/hardware vendors
.

5.

During Operating rea
diness Client network team and hardware team should
be available to perform necessary checks.

6.

<
<
Client
>
>

will take care of the internal coordination for rapid resolution of any issues
identified during the course of the project. A delay in resolution of an
y issues arising
may impact on the delivery timelines








<
<
Client’s name>
>



SOW for <
<
type of service
>
>

Development on

Liferay

Version 1.0



Page
5

of
12


7.

Updates or modifications to the agreed requirements would impact further project
life cycle.

8.

UAT will be performed by Client team. SMEs and Business users should be
made available to perform UAT.

9.

Chang
es to project scope as mentioned in the Scope of Work section of this
document would follow Change Management Process

<
<Add or remove the points above according to the need>>


3

IMPLEMENTATION
APPROACH

For Effective Implementation we propose the following

approach :

3.1

Global Delivery
-

Offshore Team

All activities for the project are out from offshore development centre of
mPower in India
, t
he team gets the right requirements, does the end user
interactions, solution deployment, front ends the technical de
sign and
overall planni
ng,
followed by the team focusing

on

execution and delivery in
terms of use case analysis, detailed designs, development,
testing,
build and
d
eployment support to
<
<Client
>
>
Team
.

<
<following is a offshore only model, for onsite
-
offsh
ore model replace the
pic below and modify verbose>
>









<
<
Client’s name>
>



SOW for <
<
type of service
>
>

Development on

Liferay

Version 1.0



Page
6

of
12


3.2

Iterative
Implementation

<<Appropriate Implementation approach>>

The items mentioned in scope section would be delivered
in an iterative manner
following the steps mentioned below



Requirements Analysi
s



Architecture and Design



Development



Testing



Delivery



Training



UAT

3.2.1

Requirements Analysis

Requirements Analysis is a broad term given to Elicitation, Analysis, Specifications and
Validation of Requirements from an end user and result perspective.



Elicit
ation



Proactively identifying requirements
through various techniques with an end
result of joint discovery with the client



Goes beyond requirements gathering



Analysis



Understanding and exploring each requirement in relationship to other
requirements



Spec
ification



Describing and documenting requirements in an appropriate language or
notation



Validation



Checking the specification to ensure that it meets the client needs


The result of the analysis would be documented as Use Cases and reviewed with
LuLu
Exc
hange

3.2.2

Architecture and Design

The basic objective is to transform the requirements
finalized in the previous step
into
technical solution and arrive at architecture and design decisions

Architecture decisions
may
include



Application Type
/ Solutions Deli
very Vehicles


decisions about Web Hosted
Solutions,
Client Server
Model or Desktop Based Computing or Hybrid



Conceptual, Logical and Deployment Architecture








<
<
Client’s name>
>



SOW for <
<
type of service
>
>

Development on

Liferay

Version 1.0



Page
7

of
12




FURPS



Integration mechanisms

3.2.3

Development

This
actual software coding of the application
activity
based on the requirements identified
in the requirement stage and Design carried out in the previous stage is carried out here.

The development stage
includes



Coding



by implementing the design carried out in the previous stage



Complying

with the functions

defined in the requirements stage.



Unit testing

3.2.4

Testing

The objective of the testing phase is to verify the developed application against the defined
requirements and objectives of the project. Apart from verification of the compliance to
requirements t
he other important objective of testing is to ensure that the application to be
delivered is of expected standard and quality.


Testing all the functions of the application following real life business sequences or
functional scenarios in an integrated man
ner and is called as integration testing.




3.2.5

Demo and Deployment



Release of the application to client



Types of releases



Intermediate


for verification/ discussion



Final


after implementation of feedback



Deliverables



Application Executables



Release Docu
ment

mPower would demo the deliverables and would subsequently deploy the same for
verification by the client.

3.2.6

User Acceptance Testing and Go Live

Testing all the functions of the application following real life business sequences or
functional scenarios
by client in staging/test environment provided by client is called as user
acceptance testing.








<
<
Client’s name>
>



SOW for <
<
type of service
>
>

Development on

Liferay

Version 1.0



Page
8

of
12


Post the UAT by <<Client>>

the application is taken into production which stage is called as
‘Go Live’ stage.

3.2.7

Warranty

mPower
would provide warranty support by
fixing priority 1 and priority 2 critical i
ssues
reported for a period of 1 month

post the delivery of software. Priority 3 and Priority 4 bugs
would be fixed with mutual consent.

Priority of the issues would be considered according to the following defin
ition

P1
-

Show Stopper (There is no work around)



Examples : Pages/ Forms break, Save Does not work, flow/ data is lost

P2


Critical (There is a work around but is not feasible)



Examples: Functionality works but the behaviour is unacceptable, v
alidations
are missing

P3
-

Moderate (There is an acceptable workaround)



Examples: Null and Mandatory field checks, mismatch with master functions

P4
-

Cosmetic (Minor change)



Examples: Wrong navigation, incorrect placement of fields, format
s

The following are the applicable SLAs:

2.

P1

12 Working Hours


80% Efficiency

3.

P2

12 Working Hours


80% Efficiency

4.

P3

24 Working Hours


60% Efficiency

5.

P4

Mutual Agreement





















<
<
Client’s name>
>



SOW for <
<
type of service
>
>

Development on

Liferay

Version 1.0



Page
9

of
12


4

TEAM ORGANISATION

The proposed team structure comprises of the fol
lowing




Project Manager/ Architect



Liferay Developers

Team

Formal modes of communication would include one on one meeting, reviews, status
meetings, brainstorming sessions, etc. The medium of communication would include verbal
and written communication th
rough minutes of meeting (MOM), teleconferencing,
videoconferencing, e
-
mail, web
-
enabled tools etc.

<<Modify the depiction below and the verbose as required>>
















The project team shall be organized as depicted above. The boxes on the left side of the
picture depict the roles
onsite at
<<Client>>
and on the right, that of
offshore at
mPower

Global




Key Contacts from mPower Global

Role

Name

Email ID

Phone

Account Manager




Project Manager




Liferay Tech Lead




Liferay Architect




Senior Project Manager




Sr. Vice President Delivery




CEO







<<Client>>

Architect /PM and
Team

Offshore @
mPower

Team

mPower
Project
Manage
r
/
Architect
/Account
Manager

___
_
Reporting

Relationship


-----
-

Communication Channel








<
<
Client’s name>
>



SOW for <
<
type of service
>
>

Development on

Liferay

Version 1.0



Page
10

of
12


5

PROJECT TIMELINE
S

<<following is a sample for reference>>



Note: The above high level time
-
lines are with following assumptions

<<add or remove
points>>

1.

The above timelines are based on our current understanding of the
requirement and can change after getting more clarity

2.

Timely inputs from
<<Client>>

on the requirements.

3.

The training would be o
nline by sharing screens and the Training M
anual
customized for <<Client>>

would be published.

4.

The UAT wi
ndow would be of <<x>>

weeks, It is expected from
<<Client>>

to
provide all the comments/defects within this window.

6

DELIVERABLES

The following would b
e the deliverables for the application development

S.No.

Deliverable

Stage

1

Use Cases/
UI
Prototype

Post Requirements Analysis

2

Architecture and Design

Post Design

3

Test Plans and Cases

Post Design

4

Demo and deployment of executables

On completio
n of testing

7

CHANGE MANAGEMENT PR
OCESS

1.

Any requirement (which is
not a part of the agreed scope
would be
handled
as a
Change Request.

2.

The Change Request would be initiated and the requirement would be analysed
and effort is estimated.

3.

The Change Control B
oard would take a decision if this change can go in the next
release.








<
<
Client’s name>
>



SOW for <
<
type of service
>
>

Development on

Liferay

Version 1.0



Page
11

of
12


4.

After approval from Lulu team on the estimates the development team would
implement the change and these changes when developed would be migrated
.

5.

Please refer the below work flow diagra
m, depicting the Change Management
process.

<<Change the name of the client from the picture above>>


8

ESCALATION PROCEDURE
S


1.

All Project issues
and risks
be technical or non
-
technical are first escalated to mPower’s
designated Project Manager with a copy
to the Senior Project Manager and Sr. Vice
President Delivery.

2.


Issue
s/ Risks

pertaining to Project Management
shall be
escalated
to mPower
Senior Project
Manager
,
with a Copy to Sr. Vice President Delivery.

3.

In the unlikely event of total failure of com
munication with the project management team,
or gross violation of agreement terms,
the issues / risks shal
l be escalated to the
Sr. Vice
President Delivery
with a copy to
mPower
Account Manager and CEO


9

PROJECT STATUS REPOR
TING

There will be weekly and mo
nthly documented project status updates from mPower to
<<Client>>

through emails and scheduled calls
wherein the status of the project with respect to schedule,
deliverable status, issues, risks and action items
-
open/closed, will be discussed with the
<<Cl
ient>>

point of contact.










<
<
Client’s name>
>



SOW for <
<
type of service
>
>

Development on

Liferay

Version 1.0



Page
12

of
12


10

PRICING AND PAYMENT
TERMS

This section deals with the commercials applicable for this SOW.

Note: The cost & effort and these are Ball Park estimate which has a variance of 20%

Payment Terms

Project Phase

To be paid

Advance

20
%

Requirement and UI Signoff

20
%

Demo of Working Solution

30%

UAT

30%

9

Signatories

L
ETTER OF ACCEPTANCE

LULU
International Exchange
accepts this proposal as set forth herein and authorizes
mPower Global to commence activities related to the identified efforts, effective with the
acceptance date evidenced below.

IN WITNESS WHEREOF,
<<Clien
t>>

and mPower Global have executed this Agreement as of
the date provided below.

<<Client>>




TransIT mPower Labs Pvt. Ltd
.

Signature:____________________



Signature:_______________

Name:







Name:

Title:







Title:

Dat
e:







Date:

<<

Phase One
>>

Effort in hours

Cost per hour
(US$)

Total Cost
(US$)

Requirement Validation




Design




CUT




Testing




UAT Support




Deployment




Total