Information Systems Analysis and Design Project

Team

College of Business, San Francisco State University

MBA Students:

• Lawrence Frelot
• Ilya Kalpin
• Qizhi Liu
• Robert Meyer
• Ralston Paes

Professor:

• Dr. Sameer Verma, Ph.D. Information Systems Department

Introduction

This semester our team had the distinct privilege to work on a special project pertaining to OLPC (One Laptop Per Child), a non-profit association wholeheartedly engaged in a humanitarian effort to revolutionize the way the world’s poorest children learn, share, create, and collaborate. OLPC’s mission is “to provide educational opportunities for the world’s poorest children by providing each child with a rugged, low-cost, low-power, connected laptop with content and software designed for collaborative, joyful, self-empowered learning. To accomplish this mission, OLPC developed the ‘XO’ laptop, a low-cost and innovate computer.

Now that we have a general overview of OLPC, let’s examine the specifics of our project. We were informed that OLPC is dealing with an information flow problem. The purpose of this project is to harness and apply our knowledge to diagnose and analyze ways in which OLPC’s information systems could be improved. This documentation includes the following deliverables: a mind map, context diagrams, use cases, a data flow diagram, and an Entity Relationship diagram.

Maps and Diagrams

The mind map encapsulates the Support, Deployment, and Contribution areas. For the context diagrams, we built one at a project-wide level and one at the Contributor Program level. Note that the use cases, data flow diagrams, and Entity-Relationship (ER) diagram is for the Contributor Program only. These diagrams may help as a blueprint for further work. They may be seen ideally as a foundation for designing more efficient information systems. Many technologies could certainly evolve from these documents. In particular, a database and user-friendly forms for the Contributor Program could be constructed. Please note that these deliverables were created using information gathered from the following sources: phone conferences and face-to-face interviews with OLPC personnel, secondary research, and Dr. Sameer Verma’s lectures.

Mind Map

The Freemind diagram (See map Media:SFSU_ISAD_mindmap.png Source file:File:SFSU ISAD mindmap.mm) was used to conceptualize the OLPC organization’s processes that were to be analyzed during the project. These processes included the Contributor Program, Support, and Deployment. With the diagram, the goals were to understand the roles of each group within the organization, their relationships to one another, and to discern areas for improvement.

Context - OLPC level

Context diagrams are high-level systems engineering diagrams that depict all of the entities and users that may interact with a system. These diagrams also show the inputs and outputs of information that entities send to and receive from the systems, and where that information is stored. In a context diagram, entities are represented by a square, the system is represented by a rounded rectangle, and arrows represent data flows.

High level context diagram

Entities

1. Bright Star: Provider of distribution services for the OLPC organization.
2. Customers: Individual customers who purchase laptops for personal use via programs such as G1G1. Also includes organizations that participate in contributor projects.
3. Deployment: Support group handling mass distribution to institutional customers.
4. Quanta: Manufactures XO laptops and installs software made by Sugar Labs.
5. Sugar Labs: Developer of XO software (user interface).
6. Support: OLPC specialists who provide support to ongoing projects. Support includes the Support Gang, Freelancers, Specialists who edit the wiki, and Specialists who work with deployment.
7. OLPC: U.S. non-profit organization setup to oversee the creation of an affordable educational device for use in the developing world, with a mission to provide an XO to the poorest children using different types of contribution and deployment programs.

Data Flow

1. The data that the Customer inputs into OLPC is a customer order or a proposal, which is then reviewed by OLPC specialists (Support Group). The data flowing out of OLPC to the Customer is a confirmation of the order or results of the review.
2. The data flowing from OLPC to Support is the project data that the Support Gang reviews. The data that is outputted from Support and into OLPC is a direct result (approval/denial/modification needed) of the project proposal review.
3. The data flowing from OLPC to Deployment is project data, which is ready to be deployed. The data flowing from Deployment to the OLPC is the deployment’s status and confirmation of delivery.
4. The data flowing from OLPC to Quanta is the order received by Bright Star for shipment, which may include the quantity of XOs to be manufactured. The data flowing from Quanta to OLPC represents confirmation of order fulfillment.
5. The data flowing from OLPC to Bright Star is the customer order. The data flowing from Bright Star to OLPC is confirmation of the Bright Star order and the fulfillment status.
6. The data flowing from OLPC to Sugar Labs is a software request. The data flowing from Sugar Labs to OLPC is the request’s status.

Context - Contributor level

This is a contributor program level context map.

Contributor Program level context map

Entities

1. Bright Star – Provider of distribution services for OLPC organization of XO machines.
2. Sugar Labs – Developer of XO software (user interface).
3. Support – OLPC specialists that provide support to ongoing projects.
   1. Support Gang
   2. Freelancers on mailing lists of Wiki (Support Lists)
   3. Specialists that edit Wiki
   4. Specialists that work with Deployments
4. OLPC – OLPC is a U.S non-profit organization “set up to oversee the creation of an affordable educational device for use in the developing world,” with a mission to provide an XO to every child using different types contribution and deployment programs.

Data System

OLPC Data System – This is the database that holds data concerning OLPC. It differs from the “OLPC” entity in that it represents the database system, whereas “OLPC” represents the actual OLPC organization.

Data Flow

1. The data that flows from OLPC Data System to Bright Star is the XO shipment request after a proposal has been accepted. The data flow that flows from Bright Star to OLPC Data System is the confirmation of the shipment of the XO.
2. The data that flows from OLPC Data System to OLPC is a request for proposal status. The data that flows from OLPC to OLPC Data System is all data that concerns the state of a proposal – the tracking of what stage the proposal is in.
3. The data that flows from OLPC Data System to Sugar Labs is a request for a software (interface) request. The data that flows from Sugar Labs to OLPC Data System is the software interface delivery confirmation.
4. The data that flows from OLPC Data System to Support is a request to review a proposal. The data that flows from Support to OLPC Data System is the results of the review process – approve or deny.
5. The data that flows from Contributor to OLPC Data System is the proposal request. The data that flows from OLPC to Contributor is the feedback concerning the proposal, which comes from Support. The feedback is concerning whether the proposal is approved or denied

Use Cases

Use Case legend

In this section, we cover various use cases for the Contributor Program. A use case documents the steps involved in completing a single business task. The components of a use case include actors, processes, and a sequence of events. Use cases generally contain a description, pre-conditions, and post-conditions. The description is a high-level explanation of the process. The pre-condition of a use case describes the state of the system before any action is taken, whereas post-conditions describe the system after the use case is executed and may include details about where information flows to or where data is stored.

With each use case, we have included a use case diagram to describe the process visually. The icons of a use case diagram are explained in the following legend:

This section contains use cases for several processes:

Hardware requests

Use case - Hardware request

Description: This use case is designed for the Contributor Program hardware application process. This scenario describes the steps that a Contributor must take to apply for hardware and how the Support Gang (OLPC) deals with it.

Actors: Contributor, Support Gang (OLPC)

Pre-Condition: The Contributor has already determined that emulation is insufficient.

Post-Condition: Upon arrival of the hardware, the Contributor confirms the shipment and optionally provides feedback to OLPC.

Basic Flow:

1. The Contributor submits a program application requesting XO hardware.
2. The Support Gang (OLPC) reviews the Contributor’s proposal.
3. After reviewing the proposal, the Support Gang may choose any one of the following actions:
   1. Approve the Proposal
   2. Request Proposal Modification
   3. Re-route to Template
   4. Cancel the Proposal.
4. If the Support Gang renders a decision for ‘Request Proposal Modification,’ feedback will be sent to the Contributor, and he or she will have to resubmit the modified proposal at a later date.
5. Once the proposal is approved, the Support Gang will ship the XO hardware to the appropriate program location.
6. After receiving the XO hardware, the Contributor must confirm shipment.
7. The Contributor may provide optional feedback to the Support Gang.

Software requests

Description: This use case is designed for the Contributor Program’s software application process. This scenario covers how a Contributor submits a software application proposal, such as a request for a paint program upgrade, and how the Support Gang (OLPC) deals with it.

Actors: Contributor, Customer, Support Gang (OLPC), Developer

Pre-Condition: The Contributor submits a software application proposal.

Post-Condition: Once software is approved and completed, it is then made available for use by Customers and Contributors. Contributors and Customers may optionally provide feedback to the Support Gang.

Basic Flow:

1. The Contributor submits a software application proposal.
2. After receiving the proposal, the Support Gang (OLPC) reviews it.
3. The Support Gang can choose from the following options:
   1. Approve Software for Development
   2. Request Proposal Modification
   3. Re-route to Template
   4. Cancel Proposal.
4. If the Support Gang chooses ‘Request Proposal Modification,’ feedback will be sent to the Contributor, and the proposal will have to be resubmitted.
5. If the Support Gang decides to approve the software for development, then they will forward the software proposal to the Developers.
6. The Developers will develop the software.
7. After building the program, the Developers will deploy the software.
8. Once the software is developed and deployed, Contributors and/or Customers may utilize the newly created software by downloading and installing it.
9. The Contributor or the Customer may optionally provide feedback to the Support Gang.

Developer Program

Use case - Developer program

Description: This use case is designed for the Contributor Program software application process, where the Contributor requests and also builds the application. This is also known as the “Developer’s Program.” This use case covers the steps that a Contributor takes to submit a software development request and how the Support Gang (OLPC) deals with it.

Actors: Contributor, Support Gang (OLPC)

Pre-Condition: The Contributor submits a proposal or contributes to existing projects.

Post-Condition: The Contributor requests, builds, and uploads the program and may provide feedback to the Support Gang.

Basic Flow:

1. The Contributor requests a “developer’s key.” More information is available at <http://wiki.laptop.org/go/Activation_and_Developer_Keys>
2. The Contributor may contribute to an existing project by checking the current list at <http://wiki.laptop.org/go/Projects_and_proposals>
3. Or, the Contributor may submit his or her own software proposal.
4. The Support Gang (OLPC) reviews the proposal.
5. The Support Gang may choose from the following options:
   1. Approve the Proposal
   2. Request Proposal Modification
   3. Cancel the Proposal.
6. If the Support Gang chooses ‘Request Proposal Modification,’ feedback will be sent to the Contributor, and the Contributor will have to resend the modified proposal.
7. If the Support Gang decides to approve the proposal, then they communicate with the Contributor and update the software project list.
8. The Contributor will build the program or add to an existing project.
9. The Support Gang will deploy the program.
10. The Contributor may provide optional feedback to the Support Gang.

Content Creation

Description: This use case is for the Contributor Program’s Content / e-book development process. The use case shows the process of a contributor project submission and other functions of the e-book development project and how the Support Gang (OLPC) deals with it.

Actors: Contributor, Support Gang (OLPC), Developer

Pre-Condition: Submission of e-book development proposal

Post-Condition: After the e-book is developed, it is made available for customer use.

Basic Flow:

1. The Contributor submits an e-book / Wikipedia bundle proposal.
2. After receiving an e-book proposal, the Support Gang (OLPC) reviews it.
3. The Support Gang may choose from the following options:
   1. Approve e-book proposition
   2. Offer suggestion for modification
   3. Cancel e-book proposition.
4. If the Support Gang chooses ‘Offer suggestion for modification,’ feedback will be sent to the Contributor, and the Contributor will have to resubmit the modified e-book proposal.
5. If the Support Gang decides to approve the e-book development, the e-book information will be forwarded to Developers.
6. The Developers will contribute to the development of the e-book, since the Contributor is the main project developer.
7. Once the project is realized, the Developer will deploy the e-book.
8. The Developer may provide optional feedback to the Contributor during project development.
9. Likewise, the Contributor may provide optional feedback to the Developer.

Peripheral Hardware Proposal Application

Description: This use case is for the Contributor Program’s proposal process for developing peripheral hardware. The use case shows the process of a contributor project submission for hardware proposals and how the Support Gang (OLPC) deals with it.

Actors: Support Gang, Contributor

Pre-Condition: Submission of XO Hardware development proposal

Basic Flow:

1. Contributor submits proposal for XO for Hardware Development.
2. Support Gang reviews the proposal after receiving it.
3. Support Gang can:
   1. reject proposal
   2. ask for proposal modification
   3. approve the proposal.
4. If proposal is approved, a XO Computer is shipped to Contributor.
5. Contributor confirms receipt of shipment of XO.
6. Contributor offers feedback to Support Gang.

Data Flow diagram

Contributor Program - Data Flow diagram

Entity Relationship Diagram

Contributor Program - Entity Relationship Diagram