Project Proposal - Three Archives

NICOLE PETERSEN, University of Cape Town

NOOSRAT HOSSAIN, University of Cape Town
NOXOLO MTHIMKULU, University of Cape Town

1. PROJECT DESCRIPTION
The Centre for Curating the Archive (CCA) of the University of Cape Town is re-
sponsible for the collection, curation and digitisation of various collections. The CCA
makes these collections accessible to artists, scholars, students and other community
members by providing Web access, publications and hosting events and exhibitions to
showcase the materials conserved 1 . Their collections include collections comprising
artefacts and multimedia centred around three distinct historical events occurring in
Cape Town. The Sequins, Self and Struggle archive, a collection containing multime-
dia objects from the Miss Gay Western Cape and Spring Queen beauty pageants 2 ;
the Harfield Village collection, an aggregation of artefacts about the forced removals
of the Claremont residents; Movie Snaps, a collection of photographs taken in and
around central Cape Town before and after apartheid 3 .

The CCA has successfully digitised the items contained in these archives and
has stored the artefacts on local hard drives thus the information is inaccessible
to scholars, artists, researchers and community members outside of the CCA. The
Miss Gay Western Cape and Spring Queen archive has an existing online platform,
however, the information is not presented in a manner deemed usable by the CCA.

The importance of the solution lies in the necessity to digitally preserve the cul-
tural heritage presented in these archives, encourage users to add information
thereby growing the collections and to increase the accessibility of the information
contained. Issues currently being experienced involve the inaccessibility of the infor-
mation in the archives, the manual management of the archived material and lack of
exposure of the archives.

The problem to be solved is the need for an online representation of the multimedia
files pertaining to the aforementioned archives. The solution is the development
and implementation of a digital cultural heritage archive to allow for the storage,
management and access of information representing the cultural heritage of minority
groups in Cape Town.

2. PROBLEM STATEMENT
The aim of the project is to provide the CCA with a digital cultural heritage archive
solution that will provide access to information that has been centrally stored and is
currently inaccessible to society members outside of the CCA.

Together with providing access to cultural heritage information of minority groups in

Cape Town, the aim of the project is to investigate and arrive at a solution that will

1 http://www.cca.uct.ac.za/
2 http://sequins-self-and-struggle.com/
3 http://www.cca.uct.ac.za/projects/movie-snaps-capetown-remembers-differently/
2

allow for the creation and management of additional digital heritage archives by the
CCA.
2.1. Requirements
The Three Archives project has a client, the CCA. Potential users of the system
are researchers, artists, scholars, historians and interested members of the general
public. Below is an outline of the most important requirements to be investigated and
implemented in the software solution to satisfy the needs of the CCA and the users of
the digital archive.

The solution is to allow for the access and exploration of archived heritage arte-
facts via search and browse functionality. The solution will also allow community
members the ability to contribute to the archive resulting in an archive rich in content.
The contribution will be through commenting on and captioning items, as well as
uploading multimedia content to the archive.

In addition to presenting cultural heritage artefacts of different multimedia types,

the solution will house recordings of exhibitions that the CCA has conducted and will
allow for users to construct personalised online exhibitions using the content that is
available in the archive.

The system will allow the client to manage the archives by providing function-
ality to upload data to the archive, edit metadata accompanying the artefacts, and
approve any submissions made by users. Together with the management functionality,
the solution will provide information to the client about where in the world the digital
heritage archive is being accessed from in order to obtain knowledge about the global
reach of the archives.

Over and above the requirements stated, functionality to be provided to the client
includes the ability to create new archives, post implementation, without the need to
implement an entirely new solution.
2.2. Project Scope
The scope of the project does not include the digitisation and preservation of digital
objects. The purpose of preservation is to protect digital objects for access by present
and future generations. The long term preservation of digital objects involves making
sustainable technological decisions for the implementation of the system. It will not
be considered as the core requirement of the project is to create services that allows
users to interact with the digital objects.

Encouraging users to make contributions to the archive is another element which is

out of scope. This is since the objective of the project is to provide an archive for users
that allows for contributions but not necessarily motivates users to contribute.
3. STAKEHOLDERS
This section identifies and describes the various stakeholders of the project and their
roles.

3.1. Project Supervisor

Hussein Suleman
Responsibility: Review project deliverables
 3

3.2. Project Team

— Nicole Petersen (Project leader)
Responsibility: The project leader is responsible for coordinating aspects of the
project and ensuring team members are on schedule.
— Noxolo Mthimkulu (Secretary)
Responsibility: The responsibility of the secretary is to take minutes at project meet-
ings and to make the minutes available shortly after the meeting.
— Noosrat Hossain (Communicator)
Responsibility: The communicator is responsible for communicating with the project
stakeholders.

3.3. Clients and Users

Client
Siona O’Connel- Centre for Curating Archives

Users
Curator
Student/Researcher
General public interested in Cape Towns heritage

4. PROCEDURES AND METHODS

This section identifies the methods and procedures that will be implemented during
the project life-cycle.

4.1. Development Features

The project will adopt a three-layered architecture for the implementation of the
digital archive. These layers include an interface layer, a service layer and a back-
end/repository layer as can be observed in Figure 1.

Fig. 1. Three Archives three-layered architecture overview

4.1.1. Interface Layer. The interface layer is responsible for linking users to the services
offered by the archive. Given that the three archives are distinct in the context of the
content they represent, three different interfaces will be implemented to allow for user
interaction with the system.
4

4.1.2. Service Layer. The service layer connects the front-end interface to the data
objects located in the back-end. The service layer contains the functionality that is
available to the user to retrieve the information from the repositories.

The table below lists and describes the services to be implemented in the service layer.

Table I. Three Archives Client Services

Service Name Description
This functionality will provide access to and retrieval of the multimedia ob-
jects stored in the archive. The search functionality will be both a basic search
Search and Browse and advanced search.
This service will allow users to view and custom-create exhibitions with nar-
ratives and captions dependent on items that they have selected from the
archives. Once published, these exhibitions can be viewed by any user of
the archive. The exhibition service will be split up into three compontents.
Namely, the exhibition editor, the exhibition template editor and the exhi-
bition viewer. The exhibition editor will allow users to select specific items
from the archive. The exhibition template editor will allow users to select a
template and specify the placement of items identified in the exhibition edi-
tor. The Template viewer will combine the template and editor to produce an
Exhibition exhibition that is viewable by the user.
Users will be able to comment on items in the archive. For example, com-
menting on a dress in an image from the Spring Queen archive. This provides
a mechanism to avoid communication through lengthy comments and conver-
sations that is difficult to keep track of. The annotations will create richer
Comments/Annotations data with more relevant information.
Data items in the Movie Snaps and Harfield Village collections will be dis-
played on a map. The user will be presented with checkpoints on the map
representing where photos were taken. When enlarged, the user will be able
Maps to view the photos.
Users will be given the opportunity to upload and submit items that they
believe are relevant to the archives. E.g. A dress, photo of old home, photo of
great grandparents. We also want to create a simpler way for the curator to
Upload upload albums.
Low Priority/Additional features
Similar to shopping cart of e-commerce websites, this feature allows the user
Download to select particular items within the archives to bulk download.
The curator will be able to view statistics about the users of the archives, such
as their location, time spent on the sites and heat maps. This functionality is
relevant to the curator in order to obtain information about the global reach
Statistics of the archives
This will allow users to track their movement on the archive and see where
they have previously been. It will also be used, together with information
from statistics, to provide a personalised experience for the users in terms of
suggestions on new collections to view based on their previous browsing. The
history functionality will also provide a view of any updates to the archives
History as a whole

4.1.3. Repository layer (Back-end). This layer involves the storage and organisation of
the digital objects. The implementation of the repository layer will involve the user
of an archival tool. This is further discussed in the development platform section to
follow. The artefacts will be separately stored in a database. Throughout the duration
of the project the system will be designed in a manner that will allow for the creation
of new archives.
 5

4.2. Development Platform

The Three Archives system will be developed for use over the Web and the system
will be compatible with any Web browser. The interface will be responsive and will
allow be accessible via mobile devices, however, it will be developed primarily for use
on a personal computer. The front-end interface of each archive will be designed using
HTML and Twitter Bootstrap, a front-end framework providing CSS files that allow
for easier user interface design 4 .

The repository layer will be implemented using the open source Fedora reposi-
tory tool. DSpace and Omeka are other digital object management tools which offer
additional services that Fedora does not offer. The additional tools will be investigated
in order to obtain understanding of how they have chosen to implement services to
be made available in the three archives project. The Fedora tool accommodates for
complex digital objects and allows for customisation and flexibility. Fedora provides
basic search and browse services which are exposed as web services and allows
for the introduction of new services. Fedora has been implemented using the Java
programming language and any additions to be made will be in Java. The database
used in Fedora is PostgreSQL 5 which will be used for the Three Archives project.

The implementation of the Three Archives’ services will make use of existing
third party software where applicable. Table II is a description of the implementation
strategies to be adopted for each service.

4 http://getbootstrap.com/2.3.2/
5 http://www.postgresql.org/about/
6

Table II. Services Implementation

Service Name Description
SOLR6 will be used for the implementation of the searching and retrieval
functionality. SOLR is an open source indexing and searching tool. Items in
the archive will be collected then stored in a database using PostgreSQL. Solr
will be used for the indexing of these multimedia items in order to ensure
efficient retrieval when a search is conducted. The browse functionality in-
volves displaying these items as well as a more generalised search through
the archive. Solr will be used and any additional customisation required will
Search and Browse be in Java.
The exhibition functionality will be self implemented. Using HTML and
Javascript to create the exhibition editor as well as creating the templates
Exhibition needed to present the exhibitions
We plan to explore different Annotation tools. Annotator JS is a tool that
allows annotations of text, a plug-in for this tool, called Annotorious, will be
used to annotate images by creating a block around a section of the image the
user wishes to comment on. The interface needs to be designed in such a way
that the user is aware they are able to make these kinds of comments. For
example, affordances where a box appears on the image when moused over as
Comments well as a hint
Google maps. This will be used to create an overview of Cape Town. The
Google Maps Overlay class will be used to place marker of the images at the
specific geographic locations on top of the map. Maps has its own built in pan
Maps and zoom to navigate across the map.
Upload Dublin Core metadata standard
Low Priority/Additional features
Temporary database table holding items to be bulk downloaded. Will be done
using PostgreSQL. Items will be stored in a zip folder for download, bowser
Download settings will control from this point (Where and how stored on PC)
Google Analytics/AWstats will be used. Google has a measurement protocol
that provides a way to measure user activity in new environments and to tie
online to offline behaviour. It allows you to automate reporting of activity and
Statistics customise these reports to the system needs.
The history functionality will use information obtained from the statistics of
the usage of the website and the users’ activity. The personalisation of the
experience and providing updates as to which archives and collections have
History been changed will be implemented in Java.

4.3. Implementation Strategies

4.3.1. Agile. The Agile software methodology will be adopted for the implementation
of the Three Archives project. The Agile methodology is most appropriate as it lends it-
self to changes in requirements and handles time constraints that may be experienced.

Roles and Responsibilities Each team member will have a specific role where
they have specific duties pertaining to the project. Many of the roles will be shared by
all the team members as is indicated in Table III.
 7

Table III. Agile roles and responsibilities

Role Responsibility
Documentation Reviewer/Editor Noxolo Mthimkulu. This member will check the
spelling and grammar in documentation and ensure
that the formatting of documentation is consistent,
readable and neat.
Internal Tester Shared by all team members during the course of the
project. Unit tests will be conducted throughout the
development process. In addition to this, code reviews
will be conducted.
Software Architect Changed over from member to member throughout the
project depending on the feature being tackled. The
member takes responsibility for overall technological
design, integration and implementation of software
foundation; manages and offers resolutions for tech-
nical problems related to software tools.
Developer Shared by all team members during the course of the
project.
Designer Noxolo Mthimkulu, Nicole Petersen. Each mem-
ber will design separate interface for one of the three
archives. The head designers will design the basic
standardised look and feel of the system as a whole.
Systems Analyst Shared by all team members during the course of the
project. All members will be involved in scoping out
the requirements of the project. Identify and document
the requirements of the project, identify project stake-
holders, understand the clients needs and what bene-
fits the client would like to derive from the project.

Given that the Three Archives project team is small and given the time constraints,
a specific Agile project management methodology will not be followed but rather a
combination of Agile concepts will be considered throughout the implementation of
the Three Archives project. Principles to be adhered to are the iterative development
process, testing will be coducted throughout the project at each iteration forms of
which will be discussed in the evaluation section of the document, and constant client
interaction to ensure satisfaction with the product. Additionally, at the beginning of
each iteration, the tasks will be well defined and difficulty and time will be assigned
to each task - this will be kept track of during the development process. The team
will have daily stand-ups before beginning their tasks for the day to communicate to
the team the progress of their tasks and what they intend on achieving for the day.
Sprint reviews will be held at the end of every sprint to discuss the challenges during
the sprint and how things can be improved for the next. Features will developed in
priority order. All required software engineering deliverables like time sheets and
meeting minutes will be produced during the project and will be handed in with the
final deliverable.

The system will be developed incrementally following an iterative approach where

the first iteration will produce a minimal viable product. The iterations following
will refine any services which have already been implemented and will involve the
implementation of new services. Each iteration will result in a system that is complete
and functional with increased iterations resulting in more complete functionality. The
Agile software development methodology was chosen for the project as it enforces
the requirement of a constantly working and complete system which will ensure a
complete project regardless of time constraints and issues that may be encountered.
8

Agile also lends itself to the development and specification of new requirements
throughout the development process which is fitting for the Three Archives project as
the general idea as to which services are required is present, however, the detail is still
unknown and adopting Agile will allow for sufficient exploration. Each iteration will
enforce the Agile Development Cycle of analysis, development, testing and evaluation.
This Reduces risk, and increases value by delivering some benefits early, results in
more flexibility, and better time management.
4.3.2. User Centered Design. The client and users will be closely involved through-
out the design process. The Three Archives project involves the design of three
distinct interfaces for the three collections being represented. The users’ involve-
ment throughout the process is necessary to ensure that the system is usable and
understandable and that all the services that will be implemented are well understood.

The user centered design cycle is iterative process and involves an initial evalu-
ation phase, followed by design and then a prototyping phase. The evaluation phase
involves the understanding of the different users of the system and the tasks they
intend on completing using the system. This is coupled with an evaluation of how the
users are currently completing these tasks in order to understand how to improve
their experience. The evaluation process is followed by a design process where we will
design the system taking into consideration knowledge obtained from the evaluation
session. The design phase will be followed by prototyping, where a prototype of the
design will be implemented and presented to the users for evaluation. Different
levels of prototyping will be adopted throughout the design process dependent on
which prototype fidelity provides the best feedback from the users. Feedback from
the evaluation of the prototypes will be taken into consideration during the next
iteration of the design cycle where improvements will be discussed, designed and then
prototyped.

This iterative process will take place until the team is satisfied with the users’
interaction with the system and the users’ navigate and interact with the system
intuitively and effortlessly. The CCA will be contacted to find users.
4.3.3. Expected Challenges. We have yet to receive any data from our client and
unaware of where this data is kept. We expect it to be challenging to acquire this data
from our client.

The client is very enthusiastic and often forgets that this is an honours project
for Computer Science. So a challenge we may have already run into is meeting our
clients expectations.

There are a number of services that we aim to provide that the archival tools do
not provide. We expect it to be challenging to offer the specific services the way we
intend. Using a variety of external tools raises the challenge of proper intergration.

The archive includes both sound and video media files besides images. We ex-
pect that to be challenging to deal with different types of media files and note that
some services may work for some types of media types and some not, as well as extra
precautions we may to take to allow for extra multimedia capabilities.

One of the biggest challenges we believe this project will face is providing a sys-
tem that wil give users the ability to be creative and designing the interface, features
and funtionality in such a way where the user is aware of the capabilities.
 9

4.4. Evaluation
We will use Software engineering metrics to evaluate our system. The outcome will be
measured on both an application level as well as a project level.

On a project level calculating the cost of project as well as the time spent on
each task, whether it went overtime, whether some functionality had to be reduced
due to time constraints or whether there was over allocation of time to a specific task.
Then the overall time and cost of the project

We will be using user oriented, performance based and requirement based eval-
uation. Using usability metrics like Learnability, recovery from errors, ease of use etc.
we will evaluate the system using the speed and accuracy of results. We also want to
measure whether the end product met the clients requirements, keeping in mind that
this is still an honours project.

Several tests will be done with typical users of the system. Each test will be
categorised by the user behaviour towards the system being tested, they will be
evaluated against our expected outcomes to specific inputs.

Other tests that will be conducted include unit tests, usability tests , acceptance
tests and integration tests.

4.5. Research Contribution

The system implemented will provide an easy means to create new archives using the
same platform and providing the same services. An example of this would be another
party needing to create an additional archive, the user will be presented with an API
whose services will be used. We hope this project will be analysed and used in case
studies, leading to a theoretical outcome.

5. ETHICAL, PROFESSIONAL AND LEGAL ISSUES

This section identifies the ethical issues involved in the various project phases, such
as user testing, populating the database and the software implementation.

5.1. Testing
Ethical clearance is to be obtained as user testing will be conducted. It is necessary
to obtain this timeously and before testing occurs in order to avoid any delays and
issues that may arise. The ethical clearance will be accompanied by a form for the
users to sign that ensures their confidentiality and anonymity in participation in the
tests. Users representative of the client from the CCA and community members will
be sourced for the testing of the system. Users will consent to the observation of their
actions throughout the testing session and will be asked to provide feedback after the
testing session.

5.2. Software
Software to be used in the development of the solution is all open source. The open
source software will be utilised according to the terms specified. These are the tools
that have been discussed in the Development Platform section above. Additionally, the
solution will use services provided by third party software such as Google Analytics
and will abide by the terms stipulated in the agreement of use of this software.
10

5.3. Data
The multimedia data to be presented on the digital cultural heritage archive solution
will be sourced from the CCA. The digital archive will stipulate via the terms of use
clause, to what capacity and in what manner the content of the archive can be used.
This information will be obtained from the CCA and will be presented to the users.
There is no obligation of the users to use the material as stipulated, however, full
disclosure of the CCA’s terms is the measure to be taken by the Three Archives project.

The developed tool will be the intellectual property of Nicole Petersen, Noosrat
Hossain, Noxolo Mthimkulu; and the University of Cape Town.
6. RELATED WORK
This section outlines example digital archives that are related to the Three Archives
project. The architectural implementation decisions, services offered and content are
elements which make these archives related. Below is a brief discussion of what was
notable in each implementation and which factors about the collections will be consid-
ered during the development of the Three Archives solution.
6.1. Zamani Data Archive Project
The Zamani Data Archive Project 7 is a project that was completed in 2014 by
students from the University of Cape town. The project involved the implementation
of a digital data archive for the Zamani Project8 . The relevance of this project to the
Three Archives project is the back-end implementation. The project was implemented
using the Fedora9 framework as the repository layer. Fedora, as discussed above, is
an extensible digital content repository service providing services for the storage,
management and distribution of digital objects [Lagoze et al. 2006]. The Fedora
repository architecture focuses on the object model which are templates for data
objects and links to tools and services for managing these data objects. [Staples et al.
2003].

The Zamani Data Archive project used Fedora to store their dataset. The dataset was
represented using the Fedora Object Extensible Mark-up Language (FOXML) which
is an expression of the Fedora Digital Object Model. This would be relevant to the way
in which the Three Archives project can store the data objects. Using Fedora digital
objects will ensure that the objects use the Dublin Core metadata standard which will
allow efficient object management. Zamani made use of the isMemeberOf relationship
functionality provided by Fedora to assist in the grouping and association of the data
objects as well as the SOLR platform to assist in the indexing, searching and browsing
functionality.

6.2. Nelson Mandela Cultural Heritage Archive

The Nelson Mandela Cultural Heritage Archive10 is a multimedia online archive con-
taining books, photographs and videos about Nelson Mandelas life as well as interac-
tions with family, comrades and friends. The archive has services for browsing, search-
ing, making comparisons and an exhibition service. The comparison service allows the

7 http://pubs.cs.uct.ac.za/honsproj/cgi-bin/view/2014/benson ferguson.zip/
8 http://www.zamaniproject.org/
9 http://fedorarepository.org/
10 http://archive.nelsonmandela.org/home
 11

user to conduct a side-by-side comparison of two items in the archive as per Figure 2.
The exhibition functionality provides a compilation of related items as decided by cu-
rators of the archive. The exhibitions are well captioned with descriptions in order to
guide the user when viewing the exhibition. An example of this can be seen in Figure
3. This image represents an exhibition of all items grouped under the Nelson Mandela
presidential years theme.

Fig. 2. Artefact comparison page from Nelson Mandela Cultural Heritage Archive

Fig. 3. 1994-1999 Nelson Mandela Presidential Years exhibition from Nelson Mandela Digital Cultural
Heritage Archive website. Here we see a compilation of images of interactions and diary entries relevant to
the exhibition title. 12
12

6.3. Europeana
Europeana13 is a digital library that provides access to multimedia material located in
digital libraries, museums and archives across Europe. The digital library, in addition
to allowing for search and browse functionality to explore the archive, provides the
users with virtual exhibitions that are themed dependent on what is selected by the
user. Along with this they provide an aggregation of the latest contributions of all the
different museums, libraries and archives that Europeana represents.

The Archive houses text, images, video, sound and virtual 3D representations.
Europeana personalises the digital archive experience by allowing a user to save the
search that they have conducted, allowing the user to add a tag to items and to store
the items for later view.

During the exploration of collections, users have the option to include content
which was contributed by other users. Europeana, thus, also allows a contribution
mechanism which is observed in their Europeana 1914-1918 collection14 as seen
in figure 4. The contribution is done by signing up to the site, adding information
about the contribution, attaching a digital version of the object and submitting the
contribution. Europeana then reviews the story before it is accepted and published15 .

Fig. 4. Europeana 1914-1918 project - collection of stories, films and historical material about the First
World War. Allows contribution

The elements discussed about the Nelson Mandela Cultural heritage archive, Eu-
ropeana Digital Library and the Zamani data archive will be considered and incorpo-
rated in the implementation of the Three Archives project.

13 http://www.europeana.eu/portal/
14 http://www.europeana1914-1918.eu/en/contributor
15 http://www.europeana1914-1918.eu/en/contributor
 13

7. ANTICIPATED OUTCOMES
The identification of anticipated outcomes of the project will allow us to evaluate the
progress of the system. The outcomes include the implemented system functionality,
implementation challenges and success factors.

7.1. Project Outcomes

The Three Archives project is expected to make the three archives accessible to users.
It will consist of three integrated layers whose expected outcomes are described below.
7.1.1. Back end. The back-end is expected to provide a foundation for the management
and storage of the digital objects. The back-end includes a database for the digital ob-
jects. The digital objects will be managed using DSpace, Omeka or Fedora, as discussed
above.
7.1.2. Services. The services that are expected to be made available include:

— Browsing and Searching

— Curator uploads
— Curator acceptance/rejection of user contributions
— User uploads
— User Comments
— Creating an exhibition
— Map of content uploads
Low priority/additional services that could possibly be implemented include:
— Website Statistics
— User History
— Downloading content
7.1.3. Front end. The front-end is expected to provide three distinct user interfaces for
the Three Archive collections. The interfaces will expose the services available to the
users and will provide a channel to perform system services.

7.2. Challenges
Design challenges that may arise originate from the data that is currently available
and the tool selected for the foundation of the system. Missing metadata fields may
result in inconsistent data which will affect the results represented to the user. It is
therefore required that the data be curated. Another design challenge involving data
is the size of elements that need to be uploaded. The database must be designed to
handle large files while maintaining their quality.

The restrictive nature of repository tools available may result in the inability to
customise services based on the requirements of the Three Archives project.

Additional difficulties that may be experienced involve the integration of all the
tools to be used as the implementation of the project involves the use of various
existing tools. Together with the integration, various difficulties are expected during
the implementation of the actual services of the archive. These difficulties include
presentation of an archive to a creative audience, the integration of sensible workflows
in order to allow users to use services such as exhibitions and the annotations,
the interpretation of the statistics and history of the archives in order to provide a
personalised user experience and the implementation of a fluid browsing interface.
14

7.3. Success Factors

The success of the project is based on the ability of users to access cultural heritage
information effectively from the three archives. Additionally, users should have the
ability to add information to the collections and should enjoy a personalised archive
experience. A successful implementation of the Three Archives project will include the
ability for the number of archives to increase.

8. PROJECT PLAN
The following section describes the life cycle of the project. The description involves an
identification of potential risks, resources required, deliverables, milestones and work
allocation.
8.1. Risks Matrix

Risk Consequence Mitigation Monitoring Management

Schedule
Too much The entire project Only test tools Monitor whether Adjust the project
time spent will be delayed or that have been the project sched- schedule and
on explor- may result in a so- successfully used ule is being make scope reduc-
ing which lution that needs in similar projects adhered to. tions if necessary.
repository to be newly devel- and set a time
tool is best oped. frame for explor-
suited. ing each tool.
Milestones The entire project Adhere to the Monitor whether Adjust the project
not being will be delayed project plan so the project sched- schedule and have
met in time that tasks begin ule is being an emergency
on schedule. adhered to. group meeting.
Unrealistic The project might Ensure enough Monitor whether Adjust the project
schedule not be completed time is allocated the project sched- schedule and
in time, resulting for each task. ule is being make scope reduc-
in less time for adhered to. tions if necessary.
system testing.
Poor time The project will Always keep The project leader Adjust the sched-
manage- run over time if things organized should check ule or reassign
ment members do not and have weekly whether team tasks.
manage their time team progress members are
properly. meetings. coping with the
workload.
Project Scope
 15

The scope of Team members Regular meetings Monitor the Change the sched-
the project will not have time will be conducted project scope ule if the scope is
changes last to implement the with the project changed
minute changes supervisor and
client.
Development
Difficulties The development Ensure tasks are Ensure that the Adjust the project
in the devel- of other tasks assigned effec- tasks are be- scope or adjust the
opment of a which depend on tively and take ing carried out project schedule.
major task . that task will be into account task on schedule by
delayed dependencies having weekly
when making this progress meetings
decision
Stakeholder
Stakeholders Schedule delays Agree on days No more than Discuss the issue
such as the may arise if the when the stake- 2 consecutive with the project
project su- project cannot holders will be meetings should client/supervisor
pervisor continue with- available. be missed with to either adjust
or client out consulting stakeholders due time or services
become the respective to unavailability offered
unavailable stakeholder.
Communication
Lack of Project tasks Team members Team members A meeting must
commu- might overlap will meet regu- must contact and be held to discuss
nication while others larly. Make use of update each other the current com-
between might be over- Google drive to en- at least once in 36 munication meth-
team mem- looked. This may sure all resources hours range. ods and make sug-
bers lead to confu- are accessible to gestions on adopt-
sion and conflict team members ing new ones
between team
members result-
ing in the failure
to meet the needs
of the project.
Lack of The needs of the Ensure that there Be able to commu- Discuss the issue
communi- client may not be are communica- nicate with stake- with the project
cation with met. tion links between holders at least client to either ad-
stakehold- stakeholders and once in a week. just time or ser-
ers project team at vices offered
the early stage
of the project.
Agree on the pre-
ferred method of
communication
Resources
16

Unable to The results of the Ensure users are Ensure users will Find alternative
obtain users user tests will be available to test be available for users to test the
that re- unreliable the system when testing a week system with
flect actual the testing phase before the test-
real world is scheduled ing session is
users of the scheduled
system for
testing.
Delays in The solution will Design database Create dummy
receiving not be able to in such a way that data to populate
data from be tested due it only requires the database.
the client to the database information that
having insuf- is available and
ficient/missing accessible.
information.
The tool The system will Ensure that the Have progress Adjust the ser-
selected not meet the phase of exploring meetings with the vices to be offered
to develop needs of the user the various tools is team to discuss or select another
the sys- or the client. done effectively. any difficulties tool if there is
tem is too arising from the sufficient time
restrictive tool.
Team mem- Scheduled time Ensure work Have regular Tasks can be reas-
bers drop- will be lost re- is allocated in team meetings signed in the team
ping the sulting in the such a way that to check whether if this were to hap-
course or project being it reduces task a team member pen.
being sick late. The work dependencies is delay another
of other team between team team member’s
members could members. work.
also be delayed if
they depend on
the missing team
member.
Table IV: Risks Matrix

8.2. Timeline, Including Gantt Chart

The Gantt chart shown in Appendix A identifies the three iterations of the project
life cycle as well as the project deliverables and milestones. The implementation of a
service is not expected to be fully functional at the end of the first and second iterations.
The Gantt Chart identifies when the implementation of the services must begin.
8.3. Resources Required
The project requires various resources such as a software tool to form the foundation
of the system, users to test the system and content to populate the database.

The content required to populate the database is information from the three
archives previously mentioned.

The users that are required to test the system include researchers/scholars, cu-
 17

rators and the general public interested in Cape Towns cultural heritage.

Three tools will be considered to provide the foundation of the system. Possible
tools includes Fedora, DSpace and Omeka.

8.4. Deliverables
— Initial Feasibility Demonstration
— First Implementation/Experiment/Performance Test + Writeup
— Final Prototype/Experiment/Performance Test + Writeup
— Chapters on Implementation and Testing
— Final Complete Draft of Report
— Project Report Final Submission
— Project Poster
— Project Report Final Submission
— Poster
— Website
— Reflection Paper

8.5. Milestones
8.5.1. Project milestones

— Initial Feasibility Demonstration 2015-07-20

— Background chapter complete 2015-07-24
— First Implementation 2015-09-11
— Final Prototype 2015-09-21
— Chapters on implementation and testing 2015-09-25
— Final implementation 2015-09-25
— Final Complete Draft of Report 2015-10-16
— Project Report Final Submission 2015-10-26

8.5.2. Software milestones

— Back end (repository and foundation of the system)
— Services (Service functionality)
— Front end (interfaces to the services)

8.6. Work Allocation

Work will be allocated according to the expected difficulty of each task as well as
the ability for the back-end tool to provide support for these tasks. The table below
identifies the services to be implemented by each team member and during which
iteration the implementation is to begin.

During the first iteration all team members are expected to explore different
repository tools that will form the foundation of the digital archive. Thereafter, each
team member will implement their respective services. During the third iteration no
implementation of new services are expected to take place as this iteration improves
the functionality implemented during the first two iterations.
18

Table V. Work Allocation

Iteration Nicole Noxolo Noosrat
1 Omeka Fedora DSpace
1 View an exhibition Basic Search Map geo-tagging
2 — Create an exhibi-
tion — Advanced Search — Comments (Anno-
— Uploads — Browse tations)
— History and Statis-
tics

3 Refine services

REFERENCES
Carl Lagoze, Sandy Payette, Edwin Shin, and Chris Wilper. 2006. Fedora: an architecture for complex objects
and their relationships. International Journal on Digital Libraries 6, 2 (2006), 124–138.
Thornton Staples, Ross Wayland, and Sandra Payette. 2003. The Fedora Project. D-Lib Magazine 9, 4 (2003),
1082–9873.
 APPENDIX A

Jul 2015 Aug 2015 Sep 2015 Oct 2015

ID Task Name Start Finish Duration
5-7 12-7 19-7 26-7 2-8 9-8 16-8 23-8 30-8 6-9 13-9 20-9 27-9 4-10 11-10 18-10 25-10

1 Feasibility assessment 2015-07-01 2015-07-17 13d

2 Tool assessment 2015-07-01 2015-07-03 3d

3 Assess data 2015-07-03 2015-07-06 2d

4 User meetings 2015-07-06 2015-07-07 2d

5 Set up database layer and foundation 2015-07-07 2015-07-10 4d

6 Implement basic search 2015-07-10 2015-07-20 7d

7 Implement basic exhibition view 2015-07-10 2015-07-20 7d

8 Implement basic Geo-tagging 2015-07-10 2015-07-20 7d

9 Initial feasibility demonstration 2015-07-20 2015-07-20 0d

10 Final paper: Back groud section 2015-07-24 2015-07-24 0d

11 Final paper: Design section 2015-08-21 2015-08-21 0d

12 First implementation refinement phase 2015-08-03 2015-08-24 16d

13 Refine first solution 2015-08-03 2015-08-24 16d

14 Performance Test of first solution 2015-08-24 2015-08-28 5d

15 Write up of first solution 2015-08-28 2015-09-03 5d

16 First implementation due 2015-09-11 2015-09-11 0d

17 Final prototype phase 2015-09-11 2015-09-21 7d

18 Implement final protoype 2015-09-11 2015-09-18 6d

19 Performance test 2015-09-18 2015-09-21 2d

20 Write up 2015-09-18 2015-09-21 2d

21 Final prototype due 2015-09-21 2015-09-21 0d

22 Final implementation 2015-09-25 2015-09-25 0d

23 Final testing 2015-09-25 2015-09-25 0d

24 Report outline due 2015-10-02 2015-10-02 0d

25 Report draft due 2015-10-16 2015-10-16 0d

26 Final project report due 2015-10-26 2015-10-26 0d

27 Poster 2015-11-02 2015-11-02 0d

28 Website due 2015-11-09 2015-11-09 0d

29 Reflection due 2015-11-13 2015-11-13 0d