But in the long term, he postulates, a more sustainable approach to development is required. And he suggests that the principal agents for long term development should be commercial organisations rather than humanitarian or aid oriented ones (Prahalad 2002).

This paper offers a project which tries to encompass some of these ideas and incorporate them into a coherent undertaking. In doing so, it may highlight one way of helping poorer regions of the world to begin to catch up with the west.

So, in the section which follows, the paper offers a discussion of some of the broader economic and development related issues before narrowing down the focus onto some of the specific implementation techniques and technologies which are potentially beneficial.

The paper then introduces the project. It discusses it in some detail, including the methodology and specification language to be used as well as the application and the underlying technology to be deployed.

The paper concludes with some reflections on future directions of further research, and on the likely outcome and potential impact of the project.

BACKGROUND DISCISSION

Parahalad (2002) is of the view that, while there are always a few examples of large international organisations behaving badly, in general the poor are suffering not from too much exposure to the attention of big business but rather from the absence of interest from larger commercial organisations.

He argues that the steady rise in the standard of living of consumers in the west is as a result of the new products and services which these same organisations compete with each other to bring us. If they were to put in a similar level of effort on behalf or the world's poor, we would see similar results in terms of their standard of living.

The problem, he believes, is that big business doesn't believe it can make any money at that level. Prahalad and others are seeking to convince large organisations otherwise. Hart and Christensen (2002) agree but posit that under-served markets are often more likely to be addressed by new companies for whom even the custom of the poor and under-resourced is valuable.

In terms of the most useful technology for the poor, it seems the mobile phone has little to rival it. It appears to be one of the few technologies which the poor can afford (to use if not always to own), which offers opportunities for entrepreneurial activity among the poor, and which offers tangible benefits in terms of access to information and resources which would not otherwise be possible. And it can also provide access to novel but relevant financial services.

Electronic markets are known to reduce transaction costs in the west. But transaction costs are typically prohibitively high in poorer parts of the world. The need for the same kind of cost reducing facility is even greater in developing nations. And thanks to the increasing popularity of the mobile phone in these regions, there is now a means of accessing these new electronic markets.

Marketplaces for physical goods and services as well as agricultural goods and services will certainly prove useful but arguably the most important resources that the poor lack are relevant information and education. A marketplace which can hope to offer these will likely prove particularly valuable.

In order to achieve effective results, the marketplace will need to encourage vendors to be mindful of constructivist, collaborative and lifelong approaches to education while at the same time being aware of the limitations of mobile phones and the need to design the learning material with these limitations in mind.

And in order to minimise development and maintenance costs, appropriate technology should be employed in the construction of the marketplace – open source and object technology seem particularly useful in this regard.

Mobile phones represent a far more heterogeneous environment than PCs. They come in a multitude of specifications with differing levels of features, capabilities, handset prices and network services. A one size fits all approach to product provision is unlikely to work here. Rather a blended learning approach is called for, where a portfolio of products and services is offered and the user decides what and how much to choose at any moment in time.

Therefore podcasting and videocasting based services could be made available for those with more sophisticated handsets, more disposable income and access to a PC; simpler text (or even voice) based services could be offered for the poorest consumers.

Thus, in principle, a marketplace for information and education products; with relevant offerings built on sound pedagogical principles; with an appreciation of the strengths and weaknesses of the technology employed; and with a portfolio of relevant, contemporary products and services ought to be fairly beneficial to the region it serves.

THE PROJECT

We have made the case for the learncasting exchange; let us now turn to its construction. This section specifies in some detail the project to implement the exchange.

Project Brief

The aim of this project is:

• To implement a ‘learncasting exchange’, a generic and flexible blended learning exchange.

A blended learning exchange can be thought of as a shared repository for learning related files. This would include podcasts, videocasts, articles, SMS messages, tutorials and any other files with content which might be used to assist student learning.

Ultimately, the system will be a combination of an exchange for all things learning related and a social network – ie. an online learning community with an extensive range of tools for communication and collaboration.

It should also enable access to most of the content by mobile phone and it will be implemented using open source software.

Thus the features of the exchange will include:

• A repository for a wide variety of learning related material
• Classification of the material (possibly using cross-referencing tags)
• Search tools for finding desired objects
• Tools for aggregating material to create a package of learning content
• Facilities for the submission of content
• A high degree of user control of the content of the exchange
• A portal providing access to Internet based learning resources
• Collaboration and communication tools
• Mobile phone access to the exchange

In order to achieve this, the project has a number of subsidiary objectives, namely:

• To implement the site using an object oriented environment in order to:
  • Minimise implementation effort and
  • Increase the flexibility of the application and the re-use of application components
• To use the unified modelling language (UML 2.0) for the specification
  • This is the widely accepted standard specification language for object oriented systems
• To use a high level implementation environment which requires no (or minimal) programming in order to:
  • Minimise implementation effort and the likely incidence of software errors and thus
  • Maximise the quality of the application
• To use open source software as far as is practical in order to
  • Minimise implementation costs and
  • Maximise access to the source code (when needed)
• To use the eZ publish application as it appears to be the only one which offers the following collection of benefits:
  • Open source
  • Object oriented
  • Built on the widely used Linux/Windows, Apache, MySQL, PHP stack
  • Allows the creation and modification of application classes
  • Has built-in e-commerce functionality
  • Offers extensive functional flexibility
  • Designed to be implemented without the need for (much) programming
  • Implemented in PHP (thus there are many free and low cost resources available to support the application).

Project Framework

This is an ambitious project. It will require a careful and systematic approach to its implementation. It is thus necessary that an orderly approach is adopted on at least two levels. First of all, UML is to be used for the specification of all elements of the system; and secondly an appropriate process framework such as Open/Basic Unified Process (OpenUP) is to be applied.

UML 2.0 has emerged as the de facto specification language for object oriented systems so it’s use on the project, given that the implementation is to be object oriented, requires little justification.

In enterprise class implementations, the (Rational) Unified Process (RUP) is typically the preferred framework/methodology for object oriented implementations. This is however a heavyweight framework; far too heavy for a project (team) of this size. A recent alternative, the Agile Unified Process is significantly more flexible but is still arguably too heavy for this project (in terms of the amount of documentary evidence of progress required).

An even more recent derivative of RUP is the Basic Unified Process (lately renamed the Open Unified Process or OpenUP). In principle this seems much more appropriate as it is designed for projects with teams of three to six people involved; it is far simpler than either of the others and will suffice, in all probability, for this project’s requirements.

OpenUP has four phases. The phases and their objectives are listed below (Balduino):

• Inception Phase
  • Understand what to build
  • Identify key system functionality
  • Determine at least one possible solution
  • Understand the cost, schedule and risks associated with the project
• Elaboration Phase
  • Get a more detailed understanding of the requirements
  • Design, implement, validate, and baseline an architecture
  • Mitigate essential risks, and produce accurate schedule and cost estimates
• Construction Phase
  • Iteratively develop a complete product that is ready to transition to its user community
  • Minimize development costs and achieve some degree of parallelism
• Transition Phase
  • Beta test to validate that user expectations are met
  • Achieve stakeholder concurrence that deployment is complete

Within each phase there may be a number of iterations and key deliverables (Balduino), as outlined in the example below:

• Open Unified Process
  • Inception Phase Iteration (I1)
  • Elaboration Phase Iteration (E1)
  • Elaboration Phase Iteration (E2)
  • Construction Phase Iteration (C1)
  • Construction Phase Iteration (C2)
  • Construction Phase Iteration (C3)
  • Transition Phase Iteration (T1)

Project Phase Iterations

A similar pattern of iterations and key deliverables will take place in this project. The phase iterations follow:

• Inception Phase Iteration I1 – Outline Specification
• Inception Phase Iteration I2 – eZ publish Installation
• Inception Phase Iteration I3 – eZ publish Familiarisation
• Inception Phase Iteration I4 – Outline Planning
• Inception Phase Iteration I5 – Simple Exchange Implementation
• Inception Phase Iteration I6 – Community Exchange Implementation
• Inception Phase Iteration I7 – Test Deployment (Online)
• Elaboration Phase Iteration E1 – Review Content Licensing Options
• Elaboration Phase Iteration E2 – Evaluate Existing Learning Exchanges
• Elaboration Phase Iteration E3 – Detailed Requirements and Planning
• Elaboration Phase Iteration E4 – Improved Site Design Implementation
• Elaboration Phase Iteration E5 – Test Deployment II (Online)
• Construction Phase Iteration C1 – Server setup
• Construction Phase Iteration C2 – Comprehensive Exchange Implementation
• Construction Phase Iteration C3 – Mobile Enabled Exchange Implementation
• Construction Phase Iteration C4 – Social Network/Exchange Implementation
• Transition Phase Iteration T1 – Documentation
• Transition Phase Iteration T2 – Full Deployment
• Transition Phase Iteration T3 – Acceptance Testing

This is going to be a challenging project. It is quite possible that not all that is specified here will be implemented successfully (or at all). Furthermore, it is quite likely that some of the iterations will take longer (possibly much longer) than anticipated.

This is largely because one significant downside to the eZ publish application is its complexity. It is therefore important to phase the implementation and start with the simplest elements of the requirement.

Thus the first few iterations are all about the outline requirements definition and specification, and familiarisation with the software. The contents of each phase are as follows:

The first inception phase iteration (I1) relates to the production of the outline requirements definition and specification.
The next inception phase iteration (I2) covers the eZ publish installation process.
The next phase iteration (I3) starts with one of the default applications built into eZ publish, the online shop. It then enhances this in line with a published article (Farstad 2005) or part of the eZ publish site documentation (eZ systems a and eZ systems b). The article and documentation offer step-by-step guidelines for the implementation.
The next iteration (I4) relates to the production of an outline plan for the project.
The next phase iteration (I5) relates to the implementation of the most critical of the main application components, the exchange. This covers the implementation of a simple initial version of the exchange.
The next iteration (I6) covers the implementation of a community exchange. Most of the features required for this iteration are provided by pre-existing eZ publish application components; they provide simple user communication and collaboration tools.
The next phase iteration (I7) covers a test deployment of the application including appropriate application configuration.
The first elaboration phase iteration (E1) involves the evaluation of the main content licensing options open to the project.
The next elaboration phase iteration (E2) is concerned with an evaluation of existing learning exchanges with a view to noting good practice, interesting functionality and attractive features; and including them in the requirements and appropriate specifications of the blended learning exchange.
The next iteration (E3) provides a detailed definition of requirements and project plan.
And the purpose of the next iteration (E4) is to improve the design (aesthetics) of the site.
The next iteration (E5) covers a test deployment of the application including appropriate application configuration.
The first construction phase iteration (C1) is concerned with setting up the servers for hosting this application and others. Perhaps a dedicated server would be most appropriate for the application itself but a virtualisation server with a number of virtual machines would be a useful test environment.
The next construction phase iteration (C2) covers the implementation of a comprehensive exchange/marketplace.
The next construction iteration (C3) is about making the learning exchange mobile enabled; it covers facilitating access via mobile phone (and PDA). It will provide SMS and WAP access facilities. It will also introduce a mechanism for facilitating mobile payments.
The following construction iteration (C4) is concerned with creating a social network with extensive communication and collaboration tools.
The first transition phase iteration (T1) covers the production of appropriate user and administration documentation.
The next iteration (T2) addresses fully deploying the application in a production environment. This phase iteration is also concerned with scaling, security and other performance issues.
The final iteration (T3) is concerned with planning and conducting acceptance testing.

The UML Specifications

As mentioned above, the specification language for this project will be UML, the widely adopted specification language for object oriented systems. In addition to being the de facto standard for this kind of specification, it also appears to be consistent with the structure of eZ publish.

There are a few diagrams which are likely to prove much more useful than others for an eZ publish implementation, namely:

• Use case diagrams
• Class diagrams
• Package diagrams
• Object diagrams
• Activity diagrams

In keeping with the nature and philosophy of OpenUP, the development of the specification should be seen as an iterative process, starting with a relatively simple representation of the aspect of the system under consideration and progressing to a more complete and comprehensive representation.

Furthermore, the specifications may well be drawn in part from other suitable specifications in the public domain (with appropriate acknowledgment of sources).

CONCLUSIONS & RECOMMENDATIONS

There are a number of further potential research publications which could result from this project. Some of the possibilities are highlighted below:

• A paper comparing the performance and satisfaction ratings of the blended learning exchange with those of similar applications implemented elsewhere
• A paper reviewing the inherent value and attractiveness of blended learning environments
• A literature review on blended learning, perhaps highlighting the success factors of such sites
• A paper reviewing the educational and economic impact of the exchange on the region it serves

These are a few of the possibilities. There are, of course, many more potential publications and potential lines of further research.

In principle, there does seem to be good reason for optimism that the learncasting exchange might make a useful contribution to the educational and economic development of the region it serves.

In practice there are likely to be many misconceptions built into its implementation, many required features which have been omitted and redundant ones included, many important political considerations which have been overlooked, and many technical challenges which have compromised functionality.

It is likely to require a substantial amount of effort to implement it, a substantial amount of effort to sell it, and a substantial amount of effort to maintain and refine it in the light of the likely future demands of its customers and the emerging competitive landscape.

And yet, there may nonetheless be good reason for optimism. It may just be that in time it manages to deliver some of the benefits it promises. It may just be that it, and a number of other initiatives in the poorer parts of the globe, begin to make an impact on the enormity of the problems faced.

We can only hope that this turns out to be the case.

REFERENCES

Prahalad, C.K. (2002) “Strategies for the Bottom of the Economic Pyramid: India as a Source of Innovation”, Reflections, Vol. 3 Issue 4, p6-17

Balduino, Ricardo, “Basic Unified Process: A Process for Small and Agile Projects”, IBM, http://www.eclipse.org/proposals/beacon/Basic%20Unified%20Process.pdf (Accessed 13/6/06)

eZ systems a “Building an eZ publish site”, eZ systems, http://ez.no/products/ez_publish/documentation/building_an_ez_publish_site (Accessed 5/6/06)

eZ systems b “Building an eZ publish shop”, eZ systems, http://ez.no/products/ez_publish/documentation/building_an_ez_publish_shop (Accessed 5/6/06)

Farstad, Bard (2005) “Build an eCommerce Website with eZ publish”, Sitepoint.com, http://www.sitepoint.com/print/ecommerce-website-ez-publish (Accessed 7/6/06)

Hart, Stuart L., & Christensen, Clayton M. (2002) “The Great Leap”, MIT Sloan Management Review, Vol. 44 Issue 1, p51-56