Database System Development Lifecycle

Transparencies

1
Objectives
 How problems associated with the software
development led to the software crisis.
 How the software crisis led to a structured approach
to software development called the information
systems lifecycle.
 About the relationship between the information
systems lifecycle and the database system
development lifecycle.

©Pearson Education 2009 2

Objectives
 The stages of the database system development
lifecycle.
 The activities associated with each stage of the
database system development lifecycle.

©Pearson Education 2009 3

Software crisis
 Last few decades have seen proliferation of software
applications, many requiring constant maintenance
involving:
 correcting faults,
 implementing new user requirements,
 modifying software to run on new or upgraded
platforms.

©Pearson Education 2009 4

Software crisis
 Effort spent on maintenance of software began to
absorb resources at an alarming rate.
 As a result, many major software projects were
 late,
 over budget,
 unreliable,
 difficult to maintain,
 performed poorly.

©Pearson Education 2009 5

Software crisis
 Problems with software projects at this time
referred to as the ‘software crisis’.
 Major reasons for failure of software projects
includes:
 Lack of a complete requirements specification;
 Lack of appropriate development methodology;
 Poor decomposition of design into manageable
components.

©Pearson Education 2009 6

Information system lifecycle
 Solution was to propose a structured approach to
software development called information systems
(IS) lifecycle or software development lifecycle
(SDLC).

©Pearson Education 2009 7

Information system
 Resources that enable collection, management,
control, and dissemination of data/information
throughout an organization.
 Database is fundamental component of and
Information Systems (IS). Development/usage should
be viewed from perspective of the wider requirements
of the organization.
 Structured approach to development of the database
component of an IS is required.

©Pearson Education 2009 8

Database system development
lifecycle - stages

©Pearson Education 2009 9

Stages of database system
development lifecycle
 Database planning
 System definition
 Requirements collection and analysis
 Database design
 DBMS selection (optional)

©Pearson Education 2009 10

Stages of database system
development lifecycle
 Application design
 Prototyping (optional)
 Implementation
 Data conversion and loading
 Testing
 Operational maintenance.

©Pearson Education 2009 11

Database planning
 Management activities that allow stages of
database system development lifecycle to be
realized as efficiently and effectively as
possible.
 Should be integrated with overall IS strategy of
the organization.
 Includes creation of the mission statement and
mission objectives for the database system.

©Pearson Education 2009 12

Mission statement
 Those driving database project normally define the
mission statement.
 Defines major aims of database system.
 Helps clarify purpose of the database system and
provides clearer path towards the efficient and
effective creation of required database system.

©Pearson Education 2009 13

Mission objectives
 Once mission statement is defined, mission
objectives are defined.
 Each objective should identify a particular task that
the database system must support.
 Should also include additional information that
specifies the work to be done, the resources with
which to do it, and the money to pay for it all.

©Pearson Education 2009 14

Database planning
 Database planning may also include development
of standards that govern:
 how data will be collected,
 how the format should be specified,
 what necessary documentation will be needed,
 how design and implementation should proceed.

©Pearson Education 2009 15

System definition
 Describes scope and boundaries of database
system, including its major user views.
 Describes how database system will interface
with other parts of the organization’s
information system.

©Pearson Education 2009 16

System definition
 User view defines what is required of a database
system from the perspective of:
 a particular job (such as Manager or Supervisor) or
 business application area (such as marketing,
personnel, or stock control).
 Database system may have one or more user views.

©Pearson Education 2009 17

System definition
 Identifying user views helps ensure that no major
users of the database are forgotten when
developing requirements for new application.
 User views also help in development of complex
database system allowing requirements to be
broken down into manageable pieces.

©Pearson Education 2009 18

Extended version of the StayHome
Online case study

©Pearson Education 2009 19

Database system with multiple user
views

©Pearson Education 2009 20

Requirements collection and analysis
 Process of collecting and analyzing information
about the organization to be supported by the
database system, and using this information to
identify the requirements for the new system.
 Information is gathered for each major user view
including:
 a description of data used or generated;
 details of how data is to be used/generated;
 any additional requirements for new database
system.

©Pearson Education 2009 21

Requirements collection and analysis
 Information is analyzed to identify requirements
for new database system.
 Another important activity is deciding how to
manage database system with multiple user views.
 Three main approaches:
 centralized approach;
 view integration approach;
 combination of both approaches.

©Pearson Education 2009 22

Centralized approach
 Requirements for each user view are merged
into a single set of requirements for the new
database system.
 A data model representing all user views is
created during the database design stage.

©Pearson Education 2009 23

Centralized approach

©Pearson Education 2009 24

View integration approach
 Requirements for each user view remain as
separate lists. Data models representing each user
view are created and then merged during the
database design stage.
 Data model representing one or more but not all
user views is called a local data model.
 Local data models are then merged to produce a
global data model to represent all user views.

©Pearson Education 2009 25

View integration approach

©Pearson Education 2009 26

Database design
 Process of creating a design that will support the
organization’s mission statement and objectives
for the required database system.
 Three main phases of database design:
 conceptual database design,
 logical database design,
 physical database design.

©Pearson Education 2009 27

DBMS selection
 Selection of an appropriate DBMS to support the
database system.
 Undertaken at any time prior to logical design
provided sufficient information is available
regarding system requirements.

©Pearson Education 2009 28

Application design
 Design of user interface and application programs
that use and process the database.
 Database and application design are parallel
activities.
 Transaction is an action, or series of actions,
carried out by a single user or application program
that accesses or changes content of the database.
 Should define and document the high-level
characteristics of the transactions required.

©Pearson Education 2009 29

Application design
 Important characteristics of transactions:
 data to be used by the transaction;
 functional characteristics of the transaction;
 output of the transaction;
 importance to the users;
 Expected rate of usage.
 Three main types of transactions:
 retrieval transactions
 update transactions
 mixed transactions

©Pearson Education 2009 30

Guidelines for form/report design

©Pearson Education 2009 31

Prototyping
 Building working model of a database system.
 Purpose is to:
 to identify features of a system that work well, or
are inadequate;
 to suggest improvements or even new features;
 to clarify the users’ requirements;
 to evaluate feasibility of a particular system
design.

©Pearson Education 2009 32

Prototyping
 There are two prototyping strategies:
 Requirements prototyping determines the
requirements of a proposed database system and
then the prototype is discarded.
 Evolutionary prototyping is used for the same
purposes, but the prototype is not discarded and
with further development becomes the working
database system.

©Pearson Education 2009 33

Implementation
 Physical realization of the database and
application designs.
 Use DDL to create database schemas and empty
database files.
 Use DDL to create user views.
 Use 3GL or 4GL to create the application
programs, which includes database transactions.
 Use DDL to implement security and integrity
controls. However, some may be defined using
DBMS utilities or operating system.
©Pearson Education 2009 34
Data conversion and loading
 Transferring any existing data into new database
and converting any existing applications to run on
new database.
 only required when a new database system is
replacing an old system.
 common for a DBMS to have a utility that loads
existing files into the new database.
 May be possible to convert and use application
programs from the old system for use by the new
system.
©Pearson Education 2009 35
Testing
 Process of running the database system with the
intent of finding errors.
 Use carefully planned test strategies and realistic
data.
 Testing cannot show absence of faults; it can
show only that software faults are present.
 Demonstrates that database and application
programs appear to be working according to
requirements.

©Pearson Education 2009 36

Operational maintenance
 Process of monitoring and maintaining the
database system following installation and
involves:
 monitoring performance of system. If performance
falls, may require tuning or reorganization of the
database.
 maintaining and upgrading database system
(when required).
 incorporating new requirements into database
system.

©Pearson Education 2009 37