1.1 System Objectives
The Serial Control Record(SCR) Builder is a software system for the University
of Southern California(USC) to automate the process of building the SCR
database. The SCR database contains information about serial
publications like magazines and journals and is used by the SIRSI library
information system. Currently, the database building process is being done
manually by the librarians. By using the SCR builder, the SCR database
can be built more quickly and efficiently.
Please refer to Section 1.1
of the Operational Concept Definition for a more
detailed description of the system objectives.
1.2 Development Plan Objectives
2.1 Overall Development Strategy
We are using the Waterfall model as the software development process model for
our project. The SCR Builder project is a software development process to
simply automate the current manual tasks which is well understood by
the stakeholders and simply takes long time. The growth envelop for
the project is limited to medium, because only the number of users
for the client programs - the mapping editor and the exception editor can be
increased slightly but for the conversion batch processor. To ensure
the reliable record conversion, the system should be robust. The system
should detect all the system errors occurred during the conversion
process. For the minor and recoverable errors the system should log the problem
and do certain actions to recover from the problem. In case of critical
system errors, the system should stop the conversion process and let
the users to fix the problem and start again the process.
We cannot find any available commercial-off-the-shelf(COTS) technology
for the record conversion process. It is because the conversion
process completely depends on the source and destination data
formats.
Based on the process model decision table, the Waterfall model is the
most applicable software development
process model for our project which has medium limited growth envelop, highly
understandable requirements, robustness constraints, and no available
COTS technology.
We are considering two baselines for determining the life-cycle of
this project, because it is uncertain whether or not CS577b students
on next Spring semester will take this project or the USC library
client will hire their own development team. To define the the key
system features for each baseline, we divide the development process
into two phases. The first phase is the development phase to include the
the core capabilities into the system and the second phase is to develop
the desired capabilities. In each phase, the required capabilities are
categorized by the program components of the SCR builder system - the
conversion batch processor, the mapping table editor and the exception
editor.
2.1.1 Phase 1 - Core Capabilities
Instead of supporting the Graphic User Interface(GUI)
which causes the development process to spend more
labor and time, a text-based command-line interface
will be provided for the conversion batch processor during
this phase. This interface relates to building all algorithms and
base classes which are necessary to build the engine of the batch
processor. Once these are completed, a simple command-line
interface can be added on.
For the conversion processor, the GUI is not so critical required
feature, because the interface is needed only for starting
or stop the processor and monitor the status of its
working. Those interface components are simple and can be
fully represented through the text-based interface.
The status messages include the number of records
processed, number of exception records, number of
non-exception records, number of system errors, time
elapsed and expected time to completion. The status
information is essential for the converter
because the user needs these metrics not only as an
indicator that processing is going on but also to measure
the efficiency of the system.
Since there is no GUI at this phase, all the status
messages are displayed on the screen with text-based form.
The user needs the error messages to figure out the system
errors occurred during the conversion process.
The error messages are kept concise but enough for the
user to decipher and correct the offending problem.
The error messages may be either displayed directly to the screen
when the errors are detected or logged into a error repository.
The librarian suggested a guideline of the success rate of
the record conversion. It is about 70% of the total
records from the source files. The record conversion
process should satisfy this guideline and generate
exception records less than 30% of the total records.
In this phase, the conversion process only can do the
conversion task which maps the well-known legacy data
formats into the SCR format. There are three major legacy
data formats - the USC record format, the Orion record
format, and the FAXON record format. These different input
sources are referenced by the conversion processor to
generate a SCR for a serial publication.
The general mapping problem which maps record formats
between two arbitrary record formats will be considered in
the next phase.
When the conversion process converts a record for a serial
publication, it should consider the three input sources in a
prioritized order to avoid the conflicts among the
different input data for a data item of the publication.
The system will take in priority numbers and based on those
number, resolve any conflicts that arise from the
different input formats.
To provide flexible conversion process, the mapping table
editor should be supported. The user may need to specify
specific mapping conditions for the conversion process to
reduce the number of exception records and improve the
accuracy of the conversion.
The most simple way to provide the user the ability to edit
the mapping table is using the existing text editors like
'emacs' or 'vi'. All the mapping conditions in the mapping
table will be stored in a text file, and the user can open
and edit the file by using the existing text editors.
All the exception records generated during the conversion
process should be saved in a repository, and edited by the
user through a certain editing tool to be converted into
the valid SCRs.
The exception record repository can be built by making an
indexed file that supports random access.
All the exception records will be stored in the exception
record file with being indexed by record IDs, and can be
accessed and edited by the user through a simple program which
can manage the index files.
The exception record file and the editing program can be
integrated together to make the system simpler.
It will be more flexible and usable to separate the
exception record repository from the exception record
editor. However, it will make the system more complex
because it needs a communication mechanism between the
two components.
The exception editor will be a simple local indexed-file
access program which can read, browse and edit the records
in the indexed file. Care must be taken to build the
monolithic system modularly since we need to break these
two components into two separate entities later.
In addition to access and edit the exception record file,
the system should support the user to save the modified
exception record and print the content of an exception record
in a human readable form.
In addition to the text-based user interface, the GUI
is supported at this phase. The GUI has more user-friendly
features and the user can learn how to use the system
more easily and quickly through the GUI.
The GUI also help the users to operate the system more
efficiently and correctly because the user can initiate or
stop the conversion process by pressing buttons instead of
writing command strings into the text-based interface.
The user can select the interface mode when he/she runs
the conversion batch processor by specifying an option. If
the user want to run the program through a text mode
terminal, he/she can select the text-mode interface
instead of the GUI.
If the user run the conversion processor in the
GUI-mode, all the status information will be displayed on
the same GUI interface instead of printing the status
message to the screen.
All the quantitative information can be displayed through
the graphical progress bars in the GUI. This allow the
user to monitor and understand the system status more
easily and clearly.
More information and insight is added as part of the error
messages. This includes possible sources of error,
possible reason of error and possible corrective procedures.
Those descriptive error messages are also logged into the
error repository and can be browed by the user through the
error message browser.
The success rate of the record conversion can be improved
by designing more complex and intelligent conversion
algorithm or adding more input sources to the conversion
process. In this phase, more elaborated work can be done on
the conversion algorithm.
This system can be extended to solve the general record
conversion problems in addition to the SCR specific
conversion. The record mapping algorithm can be extended
so that it can do the conversion task between arbitrary
record formats.
More complicate and flexible mapping table and mapping
algorithm should be developed to perform the generalized
conversion process.
Instead of using a existing text editor, we can preformat
the mapping table as seen in the prototype. This would enable the
user to modify the mapping table easily.
The user can modify the predefined mapping conditions in
the mapping table by editing the related fields in the mapping
table editor or add more mapping conditions by
connecting the new condition to the existing conditions
with a boolean operator.
To provide the multiple access to the exception record
repository and improve the usability, the exception record
repository should be separated from the exception record
editor. More than one librarian can access and edit the exception
records at the same time if the exception record
repository is maintained as a separate database in a
designated server machine.
The communication mechanism is needed to establish the
connection and exchange messages between the exception
record database server and the exception editor client.
A synchronization mechanism should be considered to
provide the multiple access to the exception record
repository.
Satisfy the Minimum Success Rate of the Record Conversion
SCR Specific Conversion Process
Prioritize the Input Sources
Encapsulate the Status Messages in the GUI
Full Descriptive Error Messages and Error Logging
Satisfy More than the Minimum Success Rate
Generalized Conversion Process
Prioritize the Input Sources
Table 2.1 Required Capabilities in Each Phases
We determine the milestones for the development of the system based on
the development of the major program components. These milestones
include both phases of the development cycle. Followings are the
detailed descriptions of the milestones.
Figure 2.1 Gantt Chart for the Sequence of the Milestones
During the development process, we used the WinWin negotiation tool
to develop the project artifacts among different stakeholders.
The negotiated artifacts related to the basic and advanced features
of the system and the system requirements and capabilities are
determined based on these WinWin negotiation results.
The prototype is developed to show the basic outline and components of
the graphic user interface and the operational mechanism. It includes
the three major program components of the system - the conversion batch
processor, the mapping table editor, and the exception record editor.
This prototype can be implemented after determining the system
requirements and capabilities. Please refer to the
prototype document
for detailed description and feature of the prototype.
There are two critical project milestones - the Life Cycle
Objectives(LCO) and the Life Cycle Architecture(LCA).
The LCO milestone involves establishing the system boundary and
specifies the scope of the project by defining the top-level
objectives of the system. The basic requirements, core and desired
capabilities, basic architecture, software development plan, and
feasibility rationale are the major elements of the LCO.
The LCA milestone is the elaboration of the LCO elements. The
definition of the system architecture is the most critical element of
the LCA. The architecture definition includes the definitions of the
system components, connectors, configurations, and constraints. The
specifications of quality attribute levels and architectural evolution
are also the key features of the LCA.
In this semester, we will show the prototype and deliver the documents
on the WinWin negotiation results, LCO, and LCA to the customer.
Figure 2.2 shows the detailed schedule of the deliverables, and Table 2.2
summaries the deliverable items.
Figure 2.2 Gantt Chart for the Detailed Schedule of Deliverables
Table 2.2 Summary of Deliverable Items
None for the LCO.
3.1 Organizational Responsibilities
The stakeholders for this system are from the three major organizations at
USC. The system developers of the SCR builder are the team 3 members of the
CS577a class on Fall 1997. The users and system manager of the SCR builder
are librarian of USC libraries, and the system working environment is managed
by the University Computing Services(UCS).
3.1.1 Global Organization Charts
Figure 3.1 Global Organization Chart
Three major organizations related to this project are part of the USC.
The team 3 members of CS577a are responsible for the development of the
SCR builder system. The librarians and programmer of the USC libraries
are responsible for the system operation and management. The UCS supports
and manages the working environment of the SCR builder.
The librarians are the library staff and faculty and can be classified into
three groups by their roles on the SCR database system. The record conversion
operators initiate and monitor the conversion batch processor. The record
mapping coordinators use the mapping table editor and the exception record
editor to adjust the mapping conditions and add information into the exception
records. The SCR database managers are not directly related to the SCR builder,
but they are responsible to manage the SCR database which is build by the
SCR builder.
3.1.2 Organizational Commitment Responsibilities
These are the description about the responsibilities of the personnel
in each organizations.
The team members are responsible for developing the SCR builder.
For detailed description on the personnel responsibilities,
please refer to the next section.
Among the system users, the record conversion operators are
the people who initiate the conversion batch processor and
keep track of the correct operation of the conversion
processing by checking the status messages generated.
These are the people among the system users who can determines
the mapping conditions and decide what the reasonable
information is needed to be
filled into the exception records. They are the main users for
the mapping editor and the exception editor.
All the converted data of the serial publications will be
loaded into the existing SIRSI's SCR database, and after that,
the SCR database managers manage the database to insert a new
record, delete an obsolete record, and modify incorrect
information of a record.
The USC library has one computer programmer who can manage and
develop computer softwares for the library information
system. This person will be the major system manager of the
SCR database builder. He will manage all the server and client
site programs and detects abnormal operations of the system.
He/She can solve minor problems on the computer system or the
software system, and in case of the major software problems,
he/she can contact to the system developer to solve the problem.
All the system working environment including the servers and
the network systems are operated and managed by the UCS people.
They are experts on computer systems and network systems.
The team 3 of CS577a class consists of five students and we are responsible
for developing the SCR builder.
We manage and schedule the project, design the system architectures
and functions based on the required capabilities, and develop
prototypes. For detailed description on the personnel responsibilities,
please refer to the next section.
3.2.1 Development Organization Charts
Figure 3.2 Development Organization Chart
The operation designer defines the top-level system objectives and scope
by determining the system boundary, working environment, assumptions, and
evolution parameters. He designs the operational concept, which is about
the operations and maintenance scenarios, and organizational life-cycle
responsibilities. He also identifies the life-cycle stake holders of the
project.
The initial prototype of the system is developed by the prototypest.
Through the prototyping, developers can exercise the key usage scenarios and
resolve the critical risks.
The requirement designer defines the top-level functions, interfaces and
quality attribute levels which includes the growth vectors and priorities.
He also identifies the approach, resources, and assumptions of the
development life-cycle.
The architecture designer defines the feasible architecture which includes
the physical and logical elements and relationships, and choices of COTS
and reusable software elements. He identifies the infeasible architecture options.
3.2.2 Staffing
Table 3.1 describes the types of personnel required by the project, the
number of personnel required to perform each major functions, and their
responsibilities.
Table 3.1 Staffing Description
This system will be implemented by either the CS577b team on Spring semester
in 1998 or a programming team which will be hired by the library.
The final system developer who will implement the system will train
the librarians and programmer who will work with the system.
For operators and mapping coordinators, they will guide the way to run and
interact with the system. They will train the programmer to learn the basic
managing functions for the system.
4.1 Risk Management
4.2.1 Plans and Requirements Phase
4.2.2 Product Design Phase
4.2.3 Programming Phase
4.2.4 Test Phase
4.4 Documentation
4.6 Quality Assurance
5.1 Work Breakdown Structure
2.1.2 Phase 2 - Desired Capabilities
This is the table to summarize the capabilities which should be
considered at each phases of the development process.
Program Components
Phase 1 - Core Capabilities
Phase 2 - Desired Capabilities
Conversion Batch Processor
Run in Command-line Mode
Status Messages on the Text Screen
Simple Error Messages and Error LoggingRun in Both Command-line and GUI-mode
Mapping Table Editor
Use Existing Text Editor
Integrated Mapping Table Editor
Exception Record Repository and Editor
Monolithic Support by Indexed File with File Operations
Separate the Exception Record Repository from Its Editor
2.1.3 Milestones of the Development Process
The sequence of the milestones is shown in the Figure 2.1. The total time
for developing the system based on a semester term. The development
process for the exception record database and editor(Milestone 2) can
begin after implementing major parts of the conversion batch
processor(Milestone 1). The separation of the exception record editor
and exception record database(Milestone 3) can be done after
constructing the monolithic version. The generalized record
converter(Milestone 4) can be developed after building the SCR specific
converter and in parallel with other development steps. The development
of the GUI-based mapping table editor(Milestone 5) can start right
after implementing the command-line version.
2.2 Detailed Schedule of Deliverables
Title
Delivery Date
Item Format
Completion Criteria
WinWin Results
Oct.15, 1997
Document & Web Page
All the Win conditions are covered, issues are resolved, and options are
determined
Initial Prototype
Oct.15, 1997
Web Page
Include all the major system components and shows the outline of the
interface and operational mechanism
LCO Draft
Oct.22, 1997
Web Page
Show the outline of the LCO documents
LCO Package
Oct.29, 1997
Documents & Web Pages
Specify the system boundary and project scope
LCA Draft
Nov.26, 1997
Web Page
Show the outline of the LCA documents
LCA Package
Dec.8, 1997
Documents & Web Pages
Elaborate the LCO elements
2.3 Detailed Development Milestones and Schedules
Figure 3.1 is the global organization hierarchy. It shows the responsibility
relations between the various organizations involve the system development
process, and identify the key responsible personnel.
3.2 Development Responsibilities
The project manager manages the project and is responsible for the feasibility
rationale. He assures the consistency among all the elements of the project
via analysis, measurement, etc. He analyze the business case for requirements
and feasible architectures.
Staff Title Type Number Responsibilities
Project Manager
Manager
1
Manages the project and defines the feasibility rationale
Operation Designer
Analyst
1
Defines the operational concept and life-cycle plan
Prototypest
Programmer
1
Develops the initial prototype
Requirement Designer
Analyst
1
Define the system requirements and life-cycle plan
Architecture Designer
Analyst
1
Define the system and software architecture
3.2.2 Training
4.2 Development Phases
4.2.5 Implementation Phase
4.3 Review
The following documents are required by the project:
4.5 Configuration Management
Please refer to Section 6 of Software and System Requirements Definition.
Please refer to Fig. 5-1.
5.2 Budgets
Please refer to the Section 3.1 of Feasibility Rationale.