• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Software Depression
 

Software Depression

on

  • 1,086 views

 

Statistics

Views

Total Views
1,086
Views on SlideShare
1,086
Embed Views
0

Actions

Likes
0
Downloads
6
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Software Depression Software Depression Document Transcript

    • Database Planning, Design, and Administration Software Depression Main components of an information system. Last few decades have seen Main stages of database application lifecycle. proliferation of software applications, Main phases of database design: conceptual, many requiring constant maintenance logical, and physical design. involving: Benefits of CASE tools. correcting faults, How to evaluate and select a DBMS. implementing new user requirements, Distinction between data administration and modifying software to run on new or upgraded database administration. platforms. Purpose and tasks associated with data Effort spent on maintenance began to administration and database administration. absorb resources at an alarming rate. 2 Software Depression Software Depression As a result, many major software projects Major reasons for failure of software projects were includes: late, - lack of a complete requirements specification; over budget, - lack of appropriate development unreliable, methodology; difficult to maintain, performed poorly. - poor decomposition of design into manageable components. In late 1960s, led to ‘software crisis’, now referred to as the ‘software depression’. Structured approach to development was proposed called information systems lifecycle. Information System Database Application Lifecycle Resources that enable collection, Database planning management, control, and dissemination of information System definition throughout an organisation. Requirements collection and analysis Database is fundamental component of Database design I.S., and its development/usage should be viewed from perspective of the DBMS selection (optional) wider requirements of the organisation. 1
    • Stages of the Database Database Application Lifecycle Application Lifecycle Application design Prototyping (optional) Implementation Data conversion and loading Testing Operational maintenance. Database Planning – Mission Database Planning Statement Management activities that allow stages Mission statement for the database project defines major aims of database application. of database application lifecycle to be realized as efficiently and effectively as Those driving database project normally possible. define the mission statement. Mission statement helps clarify purpose of Must be integrated with overall IS the database project and provides clearer path towards the efficient and effective strategy of the organisation. creation of required database application. Database Planning – Mission Objectives Database Planning Once mission statement is defined, mission Database planning should also include objectives are defined. development of standards that govern: Each objective should identify a particular how data will be collected, task that the database must support. how the format should be specified, what necessary documentation will be needed, May be accompanied by some additional information that specifies the work to be how design and implementation should done, the resources with which to do it, and proceed. the money to pay for it all. 2
    • System Definition System Definition Describes scope and boundaries of database Database application may have one or more application and the major user views. user views. Identifying user views helps ensure that no User view defines what is required of a major users of the database are forgotten database application from perspective of: when developing requirements for new a particular job role (such as Manager or application. Supervisor) or enterprise application area (such as marketing, User views also help in development of personnel, or stock control). complex database application allowing requirements to be broken down into manageable pieces. Representation of a Database Requirements Collection and Application with Multiple User Views Analysis Collect and analyse information about the part of organisation to be supported by the database application Identify users’ requirements of 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. Information is analysed to identify requirements to be included in new database. Requirements Collection and Requirements Collection and Analysis Analysis Another important activity is deciding Centralised approach how to manage database application Requirements for each user view are merged into a single set of requirements. with multiple user views. A global data model is created based on Three main approaches: the merged requirements (which centralised approach; represents all user views). view integration approach; View integration approach combination of both approaches. Requirements for each user view are used to build a separate data model. 3
    • Centralised Approach to Requirements Collection and Managing Multiple User Views Analysis Data model representing single user view is called a local data model, composed of diagrams and documentation describing requirements of a particular user view of database. Local data models are then merged to produce a global data model, which represents all user views for the database. View Integration Approach to Managing Multiple User Views Database Design Process of creating a design for a database that will support the enterprise’s operations and objectives. Represent data and relationships between data required by all major application areas and user groups Provide data model that supports any transactions required on the data. Specify a minimal design that is appropriately structured to achieve stated performance requirements for system (e.g. response times). Database Design Database Design Approaches include: Building data model requires answering Top-down questions about entities, relationships, Bottom-up Inside-out and attributes. Mixed A data model ensures we understand: Main purposes of data modeling include: - each user’s perspective of the data; to assist in understanding the meaning (semantics) of data; - nature of the data itself, independent of its to facilitate communication about the information physical representations; requirements. - use of data across user views. 4
    • Criteria to Produce an Optimal Data Model Database Design Three phases of database design: Conceptual database design Logical database design Physical database design. Conceptual Database Design Logical Database Design Process of constructing a model of the Process of constructing a model of the information used in an enterprise, information used in an enterprise based independent of all physical considerations. on a specific data model (e.g. relational), but independent of a Data model is built using the information in particular DBMS and other physical users’ requirements specification. considerations. Source of information for logical design Conceptual data model is refined and phase. mapped on to a logical data model. 3-Level ANSI-SPARC Architecture and Physical Database Design Phases of Database Design Process of producing a description of the database implementation on secondary storage. Describes storage structures and access methods used to achieve efficient access to data. Tailored to a specific DBMS system. 5
    • DBMS Selection DBMS Evaluation Features Selection of an appropriate DBMS to support the database application. Undertaken at any time prior to logical design provided sufficient information is available regarding system requirements. Main steps to selecting a DBMS: define Terms of Reference of study; shortlist two or three products; evaluate products; recommend selection and produce report. Example - Evaluation of DBMS DBMS Evaluation Features Product Application Design - Application Design Transactions Design of user interface and application An action, or series of actions, carried programs that use and process the database. out by a single user or application Database and application design are parallel program, which accesses or changes activities. content of the database. Includes two important activities: Should define and document the high- transaction design; level characteristics of the transactions user interface design. required. 6
    • Application Design - Transactions Prototyping Important characteristics of transactions: Building working model of a database data to be used by the transaction; application. functional characteristics of the transaction; output of the transaction; Purpose importance to the users; to identify features of a system that work well, or are expected rate of usage. inadequate; to suggest improvements or even new features; Three main types of transactions: retrieval, to clarify the users’ requirements; update, and mixed. to evaluate feasibility of a particular system design. Implementation Data Conversion and Loading Physical realization of the database and Transferring any existing data into new database and converting any existing applications to run on application designs. new database. Use DDL to create database schemas and empty database files. Only required when new database system is Use DDL to create any specified user views. replacing an old system. Use 3GL or 4GL to create the application programs. DBMS normally has utility that loads existing files into new database. This will include the database transactions implemented using the DML, possibly embedded in May be possible to convert and use application a host programming language. programs from old system for use by new system. Testing Operational Maintenance Process of executing application programs with Process of monitoring and maintaining intent of finding errors. system following installation. Use carefully planned test strategies and realistic Monitoring performance of system. data. if performance falls, may require tuning or reorganisation of the database. Testing cannot show absence of faults; it can show only that software faults are present. Maintaining and upgrading database Demonstrates that database and application application (when required). programs appear to be working according to Incorporating new requirements into requirements. database application. 7
    • CASE Tools CASE Tools Support provided by CASE tools Provide following benefits: include: standards; - data dictionary to store information about integration; database application’s data; support for standard methods; - design tools to support data analysis; consistency; - tools to permit development of corporate data model, and conceptual and logical automation . data models; - tools to enable prototyping of applications. CASE Tools and Database Data Administration and Application Lifecycle Database Administration Data Administrator (DA) and Database Administrator (DBA) are responsible for managing and controlling activities associated with corporate data and corporate database, respectively. DA is more concerned with early stages of lifecycle and DBA is more concerned with later stages. Data Administration Database Administration Management of data resource Management of physical realization of a including: database application including: database planning, physical database design and implementation, development and maintenance of setting security and integrity controls, standards, policies and procedures, and monitoring system performance, and conceptual and logical database design. reorganising the database. 8