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.
The major development phases of the development process are the
requirement analysis phase, the product design phase, the programming
phase, the integration and test phase, and the implementation phase.
Please refer to section 4.2 of this document for the
descriptions on these development phases.
We use the incremental development strategy for developing the products.
At the first phase of the incremental development, the core
capabilities will be included into the system and at the second phase,
the desired capabilities of the system will be implemented. 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. The sections
2.1.1 and 2.1.2 describe about
the required capabilities for each incremental development phases.
The programming, integration and test, and
implementation phases will be performed at each phases of the
incremental development.
Figure 2.1 shows the Gantt chart for the top-level milestones of the
overall development process. All the requirement analysis phase will
be done by the 577a Team until December 8th, 1997. The remaining
development phases will be done by a development team hired by the USC
library. We used COCOMO tool to estimate the time and
budget of the project. It estimated that the project will take four
months to perform the product design, programming, and integration and
test. The two incremental development phases can be overlapped at the end
of the first one, because some desired capabilities can be designed
right after the development of certain core capabilities, on which the
desired capabilities depend.
Please refer to chapter 5 and Appendix A
for the detail description about the COCOMO estimation results.
Figure 2.1 Top-level milestone Gantt Chart
During this first development phase, only the core capabilities of
each subsystems will be implemented. A text-based interface will be
provided for the conversion batch processor and the conversion engine
will support only the SCR specific conversion. An existing text editor
will be used for editing the mapping table and a simple local
indexed-file access program will be developed for the exception record
editor.
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 batch processor generates data for a field of a
SCR, it should consider the three input
sources in a prioritized order to avoid conflicts among
the different input sources.
The user can prioritize the input sources for a SCR field by
using the mapping table editor.
The system will take in priorities of the input sources and based
on those priorities, 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.
The desired capabilities which are described in the design
specification will be implemented during this phase. The GUI interface
will be developed for the record conversion processor and the success
rate of the conversion process will be improved to a rate more than
the minimum success rate. An integrated mapping editor will be
implemented and the exception record repository will be separated from
the exception record editor.
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 browsed 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
specifying the relationship among mapping fields or
indicating a specific mapping algorithm.
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.
During the requirement analysis phase, 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.
All the activities of this phase will be done by 577a team during 1997
Fall semester. The team will show the prototype and deliver the documents
on the WinWin negotiation results, LCO, and LCA to the customer.
Table 2.2 shows the detailed schedule of deliverables in this phase.
Table 2.2 Detailed Schedule of Deliverables for the Requirement
Analysis Phase
During the design phase, all the activities will be done for each
subsystems of the product. Following Figure 2.2 show the product
hierarchy of the SCR builder software product.
Figure 2.2 Product Hierarchy of the SCR Builder
Following Table 2.3 summarizes the detailed schedule of deliverables
in this phase. We assume that the product development will be started
from January 5th, 1998 by the development team hired by the USC
library. Please refer to section 4.3 of this
document for the detail descriptions about the review sessions.
Table 2.3 Detailed Schedule of Deliverables for the Product Design
Phase
In each phase of the incremental development, the programming,
integration and test, and implementation phases will be performed.
The required capabilities for an incremental development phase will
be coded at the programming phase and at the integration and test
phase, all the subsystems will be integrated and tested. During the
implementation phase, installation of the products and acceptance test
will be done.
At the first step of the integration, all the
sub-components of a subsystem in Figure 2.1 will be integrated into
the subsystem. And then the subsystems will be integrated into four products
which will be provided to the user as separate software products.
The acceptance review and tests will be done on each product of the
system and the preparation of detailed implementation and maintenance
plans will be done for each subsystem.
The following are the software products to be provided to the users and
descriptions about the subsystems integrated into the products.
Conversion Batch Processor(minimum success rate)
Exception Record Editor(integrated with the database)
Table 2.4 Detailed Schedule of Deliverables for the Incremental
Development Phases 1
Conversion Batch Processor(more than minimum success rate)
Exception Record Editor
Exception Record Database
Table 2.5 Detailed Schedule of Deliverables for the Incremental
Development Phases 2
The milestones for the requirement analysis phase are comprised of the
WinWin negotiation results, initial prototype, LCO draft, LCO package,
LCO architecture review board, LCA draft, second prototype, LCA
architecture review board, and LCA package. The basic and advanced features
of the system and the system requirements and capabilities are
determined based on these WinWin negotiation results.
The prototypes demonstrate the basic outline and components of
the graphic user interface and the operational mechanism.
The LCO package describes the system boundary and
specifies the scope of the project by defining the top-level
objectives of the system, and the LCA milestone is the elaboration of
the LCO elements.
All the activies of the requirement analysis phase will be done by
577a team during 1997 Fall semester which is ended on December 8th, 1997.
Figure 2.3 shows the detailed milestones and schedules of this phase.
Figure 2.3 Gantt Chart for the Detailed Milestones and Schedule of
the Requirement Analysis Phase
We determine the milestones for the incremental development phases 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.4 Gantt Chart for the Sequence of the Milestones for the
Incremental Development
3.1 Organizational Responsibilities
The stakeholders for this system are from the three major organizations at
USC. The system requirement analysis for the SCR builder will be done
by the team 3 members of the CS577a class during 1997 Fall
semester. The product developers, users and system manager of the SCR builder
are programmers and librarians of USC libraries, and the system
working environment is managed by the University Computing Services(UCS).
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.
The team 3 members of CS577a are responsible for doing the requirement
analysis for the SCR builder system. The Information Services Division
(ISD) is the organization in USC, which provides the university various
services of information archiving, retrieving and processing. This
organization includes the USC libraries and UCS. The public service
core, infrastructure core, and communications core are the major
groups in ISD. All the librarians and programmer who are the system
users and manager are included in the infrastructure core, and the UCS
people who support the infrastructure of the library information
system is under the infrastructure core and communications core.
The programmer and record conversion operators are from the academic
software unit and the mapping coordinators, SCR editors, and exception
database managers are from the technical service unit under the
infrastructure core.
The development team hired by the USC library will develop the
software products of the SCR builder system. The librarians and
programmer of the USC libraries are responsible for the system
operation and management.
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.
The UCS supports and manages the working environment of the SCR
builder. They are not directly related to this system, but they will
support the basic infrastructure and the working environment of this
system. They manage the computer and network environment of the library
information system.
Figure 3.1 Global Organization Chart
These are the description about the responsibilities of the personnel
in each organizations.
The team members are responsible for doing the requirement
analysis for the SCR builder.
This development team will develop all the software products
of the SCR builder. They will develop the products by
performing all the activities of the development process.
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. Also the system manager will manage the user accounts
of the system. He/she can add, modify, or delete a user
by interacting with the authentication subsystem.
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 577a team consists of five students and we are responsible
for the requirement analysis of the SCR builder.
We manage and schedule the project, design the system architectures
and functions based on the required capabilities, and develop
prototypes.
Table 3.1 and 3.2 describe 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 for Requirement Analysis
Table 3.2 Staffing for Product Development
The product 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.
There will be two training sessions and each training session will be
done at the end of each incremental development
phase. After the first development phase, the users will be trained
to interact with the command-line interfaces of the products to
perform the record conversion process. Also the user will learn how to
use an existing text editor to edit the mapping table and the
exception records. After releasing the final version of the products,
the developer will train the users to work the GUI interfaces.
For this second training session, the training time will be less than
that of the first training session, because the GUI will be easier for
the users to learn.
We talked with our client and decided to hire one-full time programmer
to develop our system. By hiring one programmer, we can reduce the risk
of personnel shortfalls. Please refer to Section 4.1 Risk management of
this document.
2.1.2 Incremental Development Phase 2 - Desired Capabilities
This is the table to summarize the capabilities which should be
considered at each phases of the incremental development.
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
LCO Architecture Review Board
Nov.3, 1997
Review
All the stakeholders are agree on LCO
LCA Draft
Nov.26, 1997
Web Page
Show the outline of the LCA documents
Second Prototype
Nov.26, 1997
Web Page
Exercise the range of usage scenarios and resolve major
outstanding risks
LCA Architecture Review Board
Dec.1, 1997
Review
All the stakeholders are agree on LCA
LCA Package
Dec.8, 1997
Documents & Web Pages
Elaborate the LCO elements
2.2.2 Product Design Phase
Title
Delivery Date
Item Format
Completion Criteria
Plans and Requirement Review(PRR)
Jan.9, 1998
Review
All the stakeholders agree on the plans and requirements of LCA
Product Design Specification
Jan.23, 1998
Document
Include all the design specifications for each subsystems
User Design Review(UDR)
Jan.23, 1998
Review
All the stakeholders agree on the interfaces of the system
Preliminary Integration and Test Plan
Jan.30, 1998
Document
Include all the integration and test plan for each software products
Product Design Review
Jan.30, 1998
Review
All the stakeholders agree on the product design
2.2.3 Incremental Development Phases
Following Tables 2.4 and 2.5 summarize the detailed schedule of deliverables
of each incremental development phases. The first incremental development
phase will be started right after the design review. Please refer to
section 4.3 of this
document for the detail descriptions about the review sessions.
Phase
Title
Delivery Date
Item Format
Completion Criteria
Programming
Detailed Design Review(DDR)
Feb.28., 1998
Review
All the stakeholders agree on the detailed design of Phase 1
Integration and Test
Integration and Test Plan
Mar.6, 1998
Document
Include all the integration and test plan for each software
products for the first incremental development phase
Unit Test Completion Review(UTCR)
Mar.11, 1998
Review
Each product meets the its requirements
Implementation
Software Release
Mar.11, 1998
Executable Programs for the Products
Mapping Table Editor(command-line mode)
Software Acceptance Review(SWAR)
Mar.13, 1998
Review
All the stakeholders agree on the capabilities and requirements of
the products
Phase
Title
Delivery Date
Item Format
Completion Criteria
Programming
Detailed Design Review(DDR)
Apr.7, 1998
Review
All the stakeholders agree on the detailed design of Phase 2
Integration and Test
Integration and Test Plan
Apr.17, 1998
Document
Include all the integration and test plan for each software
products for the second incremental development phase
Unit Test Completion Review(UTCR)
Apr.21, 1998
Review
Each product meets the its requirements
Implementation
Software Release
Apr.24, 1998
Executable Programs for the Products
Mapping Table Editor(GUI mode)
Software Acceptance Review(SWAR)
Apr.28, 1998
Review
All the stakeholders agree on the capabilities and requirements of
the products
System Acceptance Review(SAR)
Apr.30, 1998
Review
All the stakeholders agree that the project meet the requirements
2.3.2 Product Design and Incremental Development Phases
The sequence of the milestones is shown in the Figure 2.4. The total time
for developing the system is four months. 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.
3.2 Development Responsibilities
3.2.2 Staffing
Staff Title Number Type Responsibilities
Project Manager
1
Manager
Manages the project and defines the feasibility rationale
Operation Designer
1
Analyst
Defines the operational concept and life-cycle plan
Prototypist
1
Programmer
Develops the initial prototype
Requirement Designer
1
Analyst
Defines the system requirements and life-cycle plan
Architecture Designer
1
Analyst
Defines the system and software architecture
Staff Title Number Type Responsibilities
Project Manager
1
Manager
Manages the product development phases
Programmer
1
Analyst
Designs the detailed architectures of the subsystems
Programmer
Writes the codes for each software products
Analyst
Performs the subsystem integration and acceptance tests
3.2.2 Training
To reduce the risk of the personnel shortfalls, we talked with our
client and decided that we will select the option A. The client will hire
their own programmer who is familiar with the library system.
Because we decide to let one full-time programmer implement this system,
we have to consider the schedule and budget very carefully. We assume
that the client will hire well-qualified programmer. When we estimate the
schedule and budget with COCOMO, we have to be very careful to set the
cost driver values of the personnel attributes to high or very high instead
of normal.
4.2 Development PhasesIn this phase, the stakeholders have to negotiate their win conditions.
The result of negotiation should be satisfied by all stakeholders. After
finishing the negotiation, the developers can make plans and requirements
of this project. At this moment, we don't know whether this project will
be implemented by CS577b students or one full-time programmer. So we have
to consider these two options carefully. Because the number of programmers
are significantly different, the schedule and requirement should
be flexible. To solve this schedule problem, we divided the development
phase by two. The first phase is to implement the core capabilities, and
the second phase is to implement the desired capabilities. The core capabilities
must be implemented within a schedule. However, if the available programmer
is only one or the schedule cannot be met, we can drop the desired capabilities
selectively. In plans and requirements phase, we also have to provide
the top-level life-cycle plan including the milestones, schedules, and
major activities.
4.2.2 Product Design Phase
In product design phase, the developers have to provide the architecture
and prototype of this system. Developers may make a more detailed development
plan in this phase.
4.2.3 Programming Phase
In programming phase, developers will implement the architecture of
this system. The main implementation will be batch processor, mapping table
editor, and exception editor. This phase consists of detailed design,
code, unit test, and integration of individual computer program components.
4.2.4 Test Phase
In test phase, the library client and developers will test
the SCR builder program. They will check whether this software product
is acceptable or not. The acceptance of this program mainly depends on
the number of exceptions. In this phase, we can find the number of exceptions
per record by running the sample data.
4.2.5 Implementation Phase
This is the last phase of the development phase. In implementation
phase, the library client and developers will decide the whole system is
acceptable or not. The whole system includes not only the SCR builder batch
processor but also hypertext help, the user manuals, the authentication,
etc.
