gathering use cases
sverma at sfsu.edu
Fri Nov 2 16:15:57 EDT 2012
There are several use cases that may or may not get addressed when
designing a particular software stack to address a requirement.
The XS 0.7 is designed to be a single image install and comes with Moodle.
Given that I work with Moodle everyday, I see the pros and cons of it being
central on the XS. I am in fact fairly happy with its current design, but
also realize that it was built for a specific use case or three that OLPC
needed at the time.
There is also an effort (currently dubbed XS Community Edition) that is
attempting to address certain other use cases where Moodle and other
services could possibly become optional. We saw this at the OLPC SF
Community Summit. I hope it will grow up to be the next XS (but that's
My concern is that perhaps, if we don't do our homework right, we will once
again build something that will fail to address a use case or two. Can one
design address all use cases? Maybe not. But it's good to know what those
use cases are.
To this end, I would like to collect data on different possible use cases
from all kinds of deployments. I have a student (cc'd) who is working on
this project currently. She will gather data from various deployments
(suitcase, boutique, MoE etc) as much as possible (with the cooperation of
projects, of course) and write a report on what we see out there. We'll
gladly make the report available once it is done.
Is this useful?
What should the scope be? Initially I had thought of the server side, but
that may be limiting. What should we gather?
Location, school, size, personnel, skills, electricity, Internet access,
language, sugar version, ...
Sameer Verma, Ph.D.
Professor, Information Systems
San Francisco State University
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Devel