PROJECT CHARTER Kuali Mobility 06/06/2011

miststizzaΚινητά – Ασύρματες Τεχνολογίες

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

193 εμφανίσεις


1




PROJECT CHARTER

Kuali Mobility


06/06
/2011


I.

MISSION


The mission of this project is to
create a long term sustainable community source project and
corresponding
partnership to

build and sustain an enterprise class mobility platform

and set of
applica
tion integration offerings

(mobile tools)

for

higher education
. This offering should

with little
effort
from

each
adopting
institution
,
allow the institution
to
take advantage of

the following:


1.

An institutional mobile web gateway accessible via url

or na
tive application downloaded
through an application store, customized
with

CSS
to effectively market your institution and

to promote the use of

institutional services that can be consumed through mobile devices.

2.

A
n institutional approach to developing mobil
e applications that is sustainable in order to
align ourselves around an approach, which in turn give
s

us the
flexibility

to share solution
sets and enhancements built on top of
the Kuali Mobile framework (which will just be a light
wrapper around best of
breed mobile web frameworks, but providing consistency for our
institutions so that investment and dividends from project work can be shared)
.

3.

Integration with standard authentication protocols (CAS, SHIB, KIM,
etc.
)

4.

Integration with and an approach for se
cure authorization for users interacting with services
that can pass through all layers of technology for a given request, very likely leveraging
open source technology like OAuth

--

http://oauth.net/

, and/or other subseq
uent projects
giving a standard paradigm for approaching integration with our
disparate

systems that is
supported by all major programming languages and tools.

5.

An architecture that allows for developers to write application code for a service to be run
and

projected through the mobile framework while still allowing the author of the application
code to author the service in their preferred backend server technology (java, php, .net,
etc.
). At the same time it is recognized that some institutions may want t
o more tightly
control what applications and kinds of integration that they allow into their mobile
deployments, so flexible runtime policies are a cornerstone of the system.

6.

An architecture
that

allows for deployment of Kuali Mobile, without dependencies
on

other
Kuali implementations at the institution (Rice, KFS,
etc.
). The product need to be able to
run in a standalone fashion and be integrated with whatever backend services exist at the
institution, but standard Kuali connectors and applications shoul
d be delivered as they are
made available by the individual Kuali projects.



The partners that engage on implementing this project charter would consist of Kuali Mobility
project members (see mobility partner guidelines attachment), as well as resources f
rom existing
Kuali projects to engage in the long term enabling of their services to be consumed and presented
appropriately on the alternative form factor of mobile devices.

There are also additional partners in
any application space where those applicat
ions either expose services for which we can write
mobile front ends, or if the applications themselves write the services and mobile front ends which
can be run in a Kuali Mobile environment.

In addition donations of any original IP

from schools that
are

willing to collaborate in this Kuali project w
ill

be leveraged as assets
from which the project
team can pull value and shorten the overall timelines from this project
. On top of one
-
time IP

2


contributions, the project needs to create and sustain a releva
nt code sharing model
, code reviews,
acceptance testing, and clearinghouse functions

that foster

innovation through allowing a given
school to write a compelling application and be able to share that application with other
Universities.


Sharing a fr
amewor
k
-
based approach for mobilizing our applications will enable Universities to
share in the cost of providing world class mobile experiences from our Universities through two
distinct efforts. First and foremost standardizing on a cross platform technology
open source
technology layer that will become our mobile
framework

will allow us to share a common solution
set addressing the delivery side of mobile applications. Secondarily, once we have converged on
a given framework and supporting technologies, then

we can leverage the shared working
environment to
create
sharable applications.


Kuali is already positioned well to take this endeavor
forward in a Sprint based approach because of some of its more recent movements in: KRAD
(Kuali Rapid Application Deve
lopment


the evolution of the (KNS) Kuali Nervous system to
become more relevant with today’s
expectations

for
modern application User model interactions
)
.


Th
e Kuali Mobile

system will be developed under the Kuali umbrella
. It will

use the

legal umbrell
a
of the Kuali Foundation, adhere to the Kuali licensing guidelines, and use the Kuali middleware,
infrastructure,

tools and processes.

The core of the mobile framework will be using best of breed
open source Mobile technologies, and the practices that co
me along with that. Our value
proposition comes more in the opportunities to differentiate
via
aligning in a mobile strategy and
being able to share applications and underlying integrations to common tools across higher
education.


This Charter shall prov
ide overall guidance for the project and the Project Board

must approve any
changes
.



II.

OBJECTIVES

and SUCCESS FACTORS


A.

Objectives


1.


Develop and packag
e a mobile application platform

based on HTML5
, CSS, and
JavaS
cript at the device

and successor
approaches using the most popular and proven
open source mobile frameworks. The system
should provide
:


1.

Authentication

hooks and default implementation

2.

Authorization

hooks and default implementation

3.

A
Core Mobile Web Application for administration of mobi
le services, customized
service projection based on ACL’s, roles, and other criteria as needed

4.

A d
istributed model for primary
/secondary

development

approach

5.

A s
ervices integration model for primary/secondary development approach

6.

A s
hared
centralized
C
SS

f
or all tools and the core Mobile Web App

7.

A s
hared centralized JAVASCRIPT

for all tools and the core Mobile Web App

8.

A publishing service for the mobile platform to define services
, screens, and dynamic
mobile home screen rendering page to present the mobile

tools the user has access to

9.

A p
ersonalization

service on top

of the mobile experience to allow for rationalizing the
palette of tools for each
user’s

personal preferences.

10.

A development language a
gnostic

approach

for tool development if desired
.


2.

Cre
ate a process and select a technology that enables web based mobile applications to
be packaged into distributable applications in the application stores that exist for all major

3


platforms. There are several technologies out there that do this function an
d fit the open
source licensing requirem
ents of the Kuali foundation. O
ne such technology is PhoneGap.





3
.

Create a governance structure based upon other Kuali projects

and
that
manages scope,
resources, and timelines effectively.


4
.


Design the syst
em so that the

addition of applications can be accomplished through
deploying a set of web applications or web services, and then can be correspondingly
pub
lished into the mobile platform. W
hen defining the publishing requirements the system
should respec
t the ability to publish services to vario
us constituencies

through roles,
groups, official campus affiliations,
etc.

to allow for targeted services to coexist with
generally applicable services
to uniquely fit the needs of the

users individual experience.


5
.


Ensure the system is sustainable

over time. Enhancements that institutions will desire
must also be considered.


6
.


Provide a

healthy ecosystem

for commercial partners to become successful in partnering
with the
Project

Team.


7
.

The system will be

designed in such a way that

wherever possible,

changes can be made
to meet the changing requirements and environments of schools without requiring
programming changes and new releases.


8
.

Use existing components
and best practices
as much as possible.




B.

Success Factors


1.


Delivery

of releases, in scope and timeli
ne, as agreed upon by the Board,
Functional
Council

and Development Team
.


2.


Implementation
s and commitments for implementations in a timely fashion to truly pivot
resource investments tow
ards a new solution set, and foster innovation on the shared
solution set, rather than continue on disintegrated paths to build out larger and larger
investments in

one off mobile application frameworks
. IU would like to pivot if feasible for
fall

of 2011

and help spearhead a move in higher education to get as modern as we can
and focus investments in similar technologies to enable increased sharing across
institutions and a more widely adopted marketplace

for shared innovation.



3.


Business model for
Ku
ali
C
ommercial
A
ffiliates (
K
CA
s
)

and Universities to effectively
collaborate, share, innovate and create markets for mobile applications.


4.

Quantity and Quality of other open source and commercial applications that adaptors are
written for to enable us
age of those applications within the general Kuali Mobile
application framework


5.

Once the core framework is in place, we should see a true focus on adapters to other
applications, as this is the primary area where we stand to offset cost using a shared
development and investment model.




4



III.

SCOPE and
TIMELINE


A.

Scope


Core Mobile Web Application (Framework)

-

The Core Mobile Web Application consists of services, screens, and software
components that are generally required to support a mobile web applicat
ion presence,
and should be limited in scope to those things that are considered globally applicable
to having a Mobile Web Application approach and strategy for an institution.

While
there are a handful of tools that are globally applicable that would co
me with the Core
Mobile Web Application Framework, the line for what should be in the core, and what
should be in a tool is drawn based on whether the tool is a requisite for proper
administration of the core, or whether it is truly a standalone mobile web

application
without which the core could still perform its specified functions.

-

Hosting of shared CSS and JavaScript files that are used by the
core

and the tools to
adapt the mobile web framework and applications for a mobile centric web application
deve
lopment HTML5 based approach.

-

Mobile Web Applicatio
n registry, which is backed by
database storage, and is used to
render the gallery of tools that a user has access to, as well as to store the preferred
layout as defined by publishers within a Chain of Co
mmand paradigm at the institution.

-

Mobile Web Application publishing, a workflow based request system to publish
applications into the Mobile Web Application registry, as well as to update any settings
for a mobile web application.

-

Mobile publishing org hi
erarchy adapter

publishing

system

hooks;

in order to
effect
ively serve multiple campus locations
, schools, and departments with their
publishing of their tools to their respective audiences we need an organizational
hierarchy subsystem that is flexible eno
ugh to allow for various publishing scenarios of
tools to applicable users

associated with the nodes in the org hierarchy adapter
. For
example, say an i
nstitution with multiple campuse
s wanted to project a mobile
presence and toolset that was tailored to
their campus
. T
his subsystem would allow
them to define the view and tools displayed to the set of
users

that are relevant for that
particular campus. In the same way, if a school within a campus had some
contributions of tools that are specific only to
persons with an affiliation to that school,
then they could additionally combine their tools into the University
-
> Campus
-
>
School offering, such that at each level of desired granularity the tools and
administration of the layout can be delegated down a
ppropriately, but through the
hierarchy and chain of command style approach a lower organizational unit could not
substantively alter the desired tools defined at a higher level in the hierarchy. This
type of service targeting, can help to prevent an expl
osion of mobile investments on
our campus if we can find the right balance within the chain of command. Some
Universities with a single campus
and

only shared global tools would be unlikely to
avail of this service, while others would be forced to install

multiple versions of the
mobile web framework without it.

This should be substantively generic enough to use
for other reports to affiliations dealing with alternative relationships to the University,
for example being able to support chapter based publi
shing for alumni of the
University, or prospect based publishing for recruited students.

-

Mobile Preferences subsystem and corresponding web services, a common
preferences system to be used by the Core Mobile Web Application, as well as by
Tools that provid
e storable preferences for each user.

-

Mobile Web Authentication and default implementation, for any mobile system to allow
for user specific functionality and data transmission, we need to ensure that we have

5


the identity of the user at hand in our core mo
bile framework and for any tools that
offer a user specific experience (such as
LMS

or personal calendar integration).

-

User impersonation service, in order to support appropriate testing, diagnosis, and
perhaps in some cases help desk type services to our
mobile constituency, it will be
important that key authorized personnel are able to assume the identity of another
person. This becomes extremely important once authenticated services are in play at
an institution as the combinatorial explosion of possibl
e variations of a given user’s
authenticated mobile web experience will differ from others based on their
associations and roles within the institution, as well as their preference selections for
personalizing their mobile web experience. In many intuition
s this type of functionality
would be limited to non
-
production environments, and therefore needs to be very
configurable to suit the use cases as they exist for the institution implementing the
software.

-

Mobile Web Services Integration Authorization frame
work, in order to create abstract
systems for the mobile world

that call into many of our established core systems in the
University
,
in many cases
we will need to call web services from other applications. In
order to ensure that the communication betwee
n the mobile

application and the
backend services is secure, validated, and authorized we need to adopt a common
approach to calling these services that is wrapped with all the appropriate checks and
balances to ensure appropriate and authorized only use t
o those services. In addition
the identity of the user for whom backend services are being invoked needs to be
passed along to the application being called so that the service exposed by the
integrated application can apply its authorization checks.

-

Confi
guration service, in order to allow for an institution to quickly setup and deploy
the mobile web core, as well as mobile web applications, it is important that
configuration information for wiring up the system for a given installation is all pushed
to a
central configuration service backed with a database backend that can be
updated during runtime. This
is a generalized service, and the value comes from the
core and the tools adhering to pushing out configuration details to this service so that
an admini
strator can easily alter settings to get setup, or to change the behavior of the
mobile web application at runtime. One relevant example could be to have each tool
have a configuration indicator of whether that tool was currently active (enabled), by
bein
g able to toggle that switch at runtime, we would be able to isolate and quarantine
tools that are having problems, without bringing the rest of the system down by
hanging all available processing threads with requests to that tool.

-

Campus alerts subsystem
,
a critical element to most if not all campus’s since the
tragedy at Virginia tech, has been having as many avenue’s to push urgent
notifications out as fast as they can be pushed. Because of this, we thing a campus
alerts component belongs in the Core M
obile Webapp as the rendering of the main
page is done by the framework, and needs to be altered visually when there are active
alerts. The alerting needs to support at least multi campus institutions, where an alert
may show up on one campus’s mobile gat
eway that presents its tools, but not on
another campus in the same institution to prevent unnecessary noise in this critical
communications channel that is irrelevant to the other campus’s. Ideally these
notifications can be further embellished by whatev
er efforts we put into wrapping our
HTML5 Mobile Web Framework with tools like PhoneGap that allow us to tie into
platform specific API’s like alerting through PhoneGap’s abstraction of the platform
api’s for all of the platforms that PhoneGap supports.

-

An
alytics
, to effectively monitor usage trends, we should have the concept of an
abstract analytics component, that in many cases would just leverage the google
analytics service. For those institutions where that is not possible due to policy they
should h
ave the appropriate hooks to integrate with a similar service at their institution.

6


This is critical to evaluate usage patterns and trends and will help us evolve the toolset
we provide over time.

-

Feedback tool
, as with any service we want a common way fo
r users to provide
feedback for the service, whether that comes in the form of a suggestion or a bug, we
want to know about it. Providing an out of the box feedback tool that can be
back
ended

by either a database, or via changing the storage API for feed
back, could push
it into help desk queue’s or perhaps even into issue tracking systems like Jira is
needed. We must recognize institutions will use different back

end systems

to
manage their workflows for feedback, so we need an abstract API that can be
o
verridden for localized deployments.




Mobile Web Applications (Tools)



basic set


-

News Application, the news application will be responsible for providing an aggregated
list of news articles via certain news channels. Much like content time on tv, wher
e
you are on tv on a given timeslot (article) on a given network (channel). There needs
to be the ability to have newsfeeds defined and implemented at the top level campus

channels

for an institution.

-

Campus Maps
, the campu
s maps service should provide
re
levant views for your
campus;

this tool must support a multi campus institution with appropriate renderings
for each campus offering. There should be relevant search functions, way finding
functions, search functions, and location relevance functions avai
lable, and directed
through appropriate layering on GIS related software efforts for each of our
institutions. The leverage point, becomes when we can agree on a set of layers that a
given institution needs, and once we have those layers defined for an in
stitution this
service could shine.

-

Events
, the central events service should be able to aggregate feeds from the primary
central calendaring service for the institution, as well as any augmentation calendaring
and scheduling systems that exist across camp
us. Data
interchange

of calendar
information, and defining an institutional calendar with
this information is likely an
institutional investment, however the offering up of this information through a
consistently usable interface should be the domain of
the Kuali mobility project.

-

Athletics
, many institutions of higher education have athletics departments that
sponsor many sports. This application would give you access to news, sports scores,
team rosters, and likely link in with social networking framew
orks that have been
established to market those sports. This application would also need to be multi
campus aware.

-

People Finder
, the people finder is simply a person directory that allows you to search
for someone by the typical search attributes. Once
you have located this person,
depending on their campus affiliation, you may have click to call, click to email, and
the ability to add the contact to your local devices address book.

-

Computer Labs
, the computer labs system allows for finding an open seat

in a
computer lab on campus. It requires a live feed of free/busy
computer

workstations in
order to perform its function.

-

Personal Calendar
, leveraging a personal calendaring system, as well as the
institutionally known calendaring information (class sch
edules and locations), this tool
will give each user an institutional view of their day. It will also allow the user to
interact and subscribe to calendar feeds from the
institution
, like women’s basketball
so that they can manage their calendar with the
information and filters that they like.

-

KB type system for IT
answers; provide

a searchable index of questions and answers
to common computing questions on campus.


7


-

Ask your Campus service
, the ability to send off a question to your campus, and
receive back

an answer via email shortly thereafter. This service requires manned
resources to be able to answer questions, like a helpdesk function for the university.

-

Dining Service for on campus residents
, most applicable for on campus residents this
would tap int
o the dining menu or the residence halls and allow the user to see the
menus and make their choices for where they choose to dine.

-

Campus card balance service
, most institutions of higher education have a campus
card. Many of those campus cards hold balan
ces in cash. The ability to check your
balance, and add cash through credit card payment is a core service for those who
rely on their cards for everyday living.

-

Emergency Contacts service
, a listing of the emergency contacts based on the
location of your

campus, police, fire, hospitals, and of course a distinguished dial 911
feature if this is a true emergency taking place.

-

Email Service
, for many institutions key partnerships are emerging with offsite
managed email via Google or Microsoft or other vendor
. This simple app would
determine which mail services the person was eligible for, and if those providers have
a mobile web view then they would be allowed to click out to that mobile web view of
their email. In addition, this would give instructions for

at the institution how to setup
mail on your local device.

-

Kuali
Action List
, given that Kuali organizes business transactions in an action list for
the user, the
Kuali

mobile framework should expose a mobilized version of the action
list that

allows the
user to click into a mobilized version of the document. This is going
to require work within each
Kuali

application to define the mobilized view of a
document, but the standard needs to be set on how that behavior should manifest
itself.

-

Kuali
Document Ha
ndlers for Mobile via KRAD
, although not the work of this project,
we need to work to define how
K
uali documents can be mobilized, and how they
should go about doing that when the applications are ready.

-

Campus tours
, a presentation framework for deliverin
g online campus tours that are
interwoven with campus maps and allow people to navigate and learn the campus
through the tours.

-

Bursar balances, payments, history, etc
, scope to be determined

-

Open Washers and Dryers, by campus, by dorm

-

Parking

-

Student recr
eation

-

Sched
ule of classes



Contribution Model


TBD





B.


Timeline



Phase 1 (Mobile Sprint, baseline offering)


Now through August 2011


Phase 2 (Onboarding staff and institutions, and refinement of mobile framework to suit
expanded institutional requ
irements)


August 2011 trhough December 2011


Phase 3 (Shared tools development, and refinement of mobile framework)


January 2012
through May 2012


Phase 4 (Evolution, shared tools development, planned system integrations)


May 2012
through December 20
12


Phase 5 (Sustainment model, contribution process ready)


January 2013 ongoing


8




IV.


GOVERNANCE AND ROLES



As with other Kuali Projects, the following roles will be filled and will provide governance for this
project.

[
Below is the way Kuali project
s are governed; changes to this model will be considered,
but must include justification
.]


1.

Project Board
. Each investing partner shall have one seat on the Project Board. The Board
will provide overall guidance to the Project, ensure that the element
s of the Project Charter are
met, and assist when issues arise which cannot be addressed by the Project Manager or
Functional Council. A Chair and Vice Chair shall be elected by the Board. The Chair, or the
Vice Chair in the Chair’s absence, shall conven
e meetings, manage agendas, hold votes as
needed, and ensure communication transparency.


2.

Lead School
. This is the institution that will take the
lead in moving the project forward

to the
Kuali Foundation Board, and be the lead in

advocacy for the proje
ct and

recruiting additional
partners and resources
if

needed.

If possible, the Project Manager should be an employee of
the Lead School.


3
.

Functional Council
. Each investing partner shall have one seat on the Functional Council.
The Functional Counci
l will be responsible for scope details, prioritization, and detailed
specifications. They convene SME groups as needed. A Chair shall be appointed by the
Board, and will convene meetings, manage agendas, hold votes as needed, and ensure
communication tr
ansparency.

The Chair shall also work closely with the P
roject
M
anager

to
address resource and scope issues.


4
.

The
Project Manager

is responsible for task and resource management. The PM works
closely with the FC Chair

to address resource and scope iss
ues.

The PM should be one of the
committed resources and should come from the
Lead School

if possible.


5
.

Committed Resources
.
These resources would include Development Managers,
Developers,
QA

Managers

and Testing Coordinators, Business Analysts
,
Funct
ional and Technical
Documenters, etc.

All of these resources are committed 100% to the project by investing
partners
.


6
.

Tendered
Subject Matter Experts (
SME
s
)
.
These functional resources are assigned on a part
-
time basis by investing institutions to do

requirements analysis, complete specification
documents, and do functional testing. Some investing partners may tender more SMEs for
certain areas and less for others, but on balance, it should be fairly equal among investing
partners.





V.


INVESTING
PARTNERS


Indiana University

(Defined Scope of investment in MOU)

UC System (Defined Scope of investment in MOU)



A Memorandum of Understanding will be executed by the investing partners to describe the
commitment to this project.



9



VI.


GUIDELINES


As wi
th other Kuali Projects, the following guidelines shall be followed.


1
.

Licensing
. This project, as part of the Kuali Foundation, will use the Educational Community
License V2.0. The Educational Community License (ECL V2.0) consists of a set of copyrigh
t
licensing terms that may be found at http://opensource.org/licenses/ecl2.php. The ECL was
certified by the Open Source Initiative in June of 2007.


2.

The Golden Rule
: “those who bring the gold make the rules.” Defined in the governance
structure ab
ove, those investing partners who provide resources have seats at the table on the
board and functional council.


3
.

Functionally D
riven
. The project is driven from functional needs. Technology supports the
functional vision and functional deliverables.


4
.

Use of

existing model(s) or system(s)
,

As much as possible, ,the system is based upon
existing systems or models, although specifications and technologies will need to be brought
up to date and revised in order to meet functional needs.


5
.

Financials
. All financial (cash) resources will be held in the

Kuali

Foundation account
ing
system
, but be used at the
discretion

of the project manager and project board.


6.

Technology
. The project will
leverage appropriately licensed open source software to run
the
front end delivery mechanisms via HTML5, CSS3, and JavaScript. In addition it will use
appropriately licensed augmentation technologies to make our mobile applications available in
the applications stores via application wrapper technologies. The
use

the Rice middleware,

and or installation of other software components from Kuali will not be required, and if they are
required in order to integrate cleanly with Kuali system will be embedded in the system and will
not add an extra burden on deployment o
f Kuali Mobile for institutions only seeking Kuali
mobile.