Roadmap. Software Engineering. Software Engineering. Project Life Cycle. Database. Project Lifecycle

(1)

Database Project Lifecycle

Roadmap

• Software Engineering

• Requirements

• Specification

• Design

• Coding

• Testing

• Project Management

Software Engineering

• The implementation of a database application is a significant engineering endeavor

– The project must complete

• On time

• On budget

– The completed system must

• Satisfy the customer’s needs

• Meet every one of its requirements

• Operate efficiently and reliably

Software Engineering

• Those goals are surprisingly difficult to achieve

• According to a published study of 16,000 IT projects

– Only 16% completed successfully – on time and on budget

– Of those that did not complete successfully

• Average completion time was 222% over schedule

• Average cost was 189% over budget

• 31% were cancelled before they were completed

Project Life Cycle

• Statement of Objectives

– Brief statement made by the customer of what the objectives of the system are

Project Lifecycle

• Requirements Document

– Expansion of Statement of Objectives – Describes what the system is supposed to do

• Not how it does it (that is in the Design Document) – Prepared by customer

– In some contexts, the Requirements Document is a request for proposal from the customer to various implementation groups that might want to build the system

(2)

Project Life Cycle

• Specification Document

– An expanded version of the Requirements Document – Describes in great detail exactly what the system is

supposed to do

• In particular the entire user interface must be specified, including all screens, all controls, etc

– Prepared by implementation group in collaboration with customer

– In some contexts, the Specification Document is a contract between the implementation group and the customer as to what will be delivered

Project Lifecycle

• Design Document

– Describes in great detail exactly how the system does what it is supposed to do – Database design

– Transaction design

• Test Plan

– Describes test cases: what the system is supposed to do

Project Lifecycle

• Coding

• Testing

Roadmap

• Requirements

• Specification

• Design

• Coding

• Testing

Use Cases

• A common way to describe requirements is with Use Cases

• A use case is a set of actions that produce benefits to one or more users called actors

– Students register for a course

• Analysts develop the requirements as a set of use cases

– Analysts work with the users to develop the use cases by asking them “how do you want to do such and such?”

Example

Registration

Purpose:Register a student for a course Actor: A student

Input: A course number

Result: The student is registered for the course and an appropriate message is displayed

Exception: The student shall not be registered for the course for any of the following reasons, which shall be contained in the output:

There exists a prerequisite course that the … etc. etc.

(3)

Universal Modeling Language

• Use cases are part of the UML

– UML is a graphic language for modeling various static and dynamic aspects of a systems behavior

– Provides a set of diagrams, each of which models a different aspect of the system behavior.

• Because UML is graphic it is particularly appropriate for communicating between the analyst and the customer and between various members of the implementation team

Use Case Diagrams

• UML provides a graphic way to display all the use cases in an application

• These diagrams can be used to communicate with the

– Customer to determine if the current set of use cases is adequate

– Implementors to determine what the system is supposed to do from the customer’s viewpoint

StudentGrade

Authentication

Register

Deregister

Student Faculty

Member GetGradeHistory

GetRegistered Courses

GetEnrolled Courses

EndOfSession

OLAP Query Room GetClassRoster

EndOfSemester Course Information Student/Faculty Information

Use Case Diagram for the Student Registration System

Issues

• Frequently while analyzing the Requirements Document to produce the Specification Document, issues arise that must be brought to the attention of the customer and resolved

– The Requirements Document might be inconsistent or incomplete in certain areas

– It is important to get such issues resolved early in the project, since it becomes increasingly expensive to made changes as the project proceeds

Roadmap

• Requirements

• Specification

• Design

• Coding

• Testing

Specification Document

• A picture of every form on the GUI with every control specified

• A description of what happens when each control is used – What application procedure is executed

– What changes in the form occur

– What error situations can occur and what happens

• A description of each interaction with the system – Information input by user

– Textual description of what happens

– List of conditions under which it succeeds or fails and what happens in each case

(4)

Specification Document

• Integrity constraints of the enterprise

• System issues

– Hardware and software used by the system

• Throughput and response time constraints

• Project planning information – Milestones

– Deliverables – Costs

Readers of the Spec. Document

• Customer, who uses it to determine that the system will satisfy its needs and that the delivered version is correct

• Design Group, which uses it to perform the design

• Quality Control Group, which uses it to design tests

• Maintenance Group, which will use it, at a later time, to implement system enhancements

UML Sequence Diagrams

• Part of the plan for preparing the

Specification Document might be to expand each use case into a UML Sequence Diagram

– A graphic display of the temporal ordering of the interactions between the actors in a use case and the other modules in the system

Database Web Server

Student or Faculty Member

Validate Login

Return Status Enter URL

Display Welcome Page Enter ID & Password

Click OK

[Status=Student] Display Student Options Page

[Status=Faculty] Display Faculty Options [ Page [Status=Error] Display Authentication Error Page [Status=Fail] Click OK

[Status=Fail] Display Welcome Page

A Sequence Diagram for the Authentication Use Case

Sequence Diagrams

• The actors and pertinent modules are labelled at the top of the diagram

• Time moves downward

• The boxes show when a module or actor is active

• The horizontal lines show the actions taken by the modules or actors

– Note the notation for conditional actions [status=student] Display Student Options Page

Roadmap

• Requirements

• Specification

• Design

• Coding

• Testing

(5)

Design Document

• The next step in the Software Engineering process after preparing the Specification Document is to perform the design and prepare the Design Document

• In contrast with the Specification Document that describes what the system is supposed to do, the Design Document describes how the system is to do what it does

Design Document

• The design document includes

– The (compilable) declaration of every global data structure used in the system

• The complete database schema (possible with an E-R diagram)

• Any objects used in the application programs – The decomposition of each database interaction into

transactions and procedures

– Detailed description of the behavior of every module, object, procedure, and transaction

Readers of the Design Document

• Coding Group, which use it to produce the code

• Quality Control Group, which use it to design tests

• Maintenance Group, which will use it, at a later time, to implement system enhancements

Database Design

• The Design Document must contain a complete design of the database including executable statements that declare the database schema – E-R or UML diagrams are used to model the

business objects in the enterprise

– These diagrams are converted into relational schemas

– The schemas are normalized and tuned – Topics discussed in Chapters 4, 6, 9, and 12

Transaction Design

• How the execution of a transaction changes the internal state of the objects in the database

UML State Diagrams

• UML class diagrams and E-R diagrams provide static models of the business objects in an enterprise

• UML state diagrams can be used to model the dynamic behavior of those objects

– How their internal state changes when their methods are invoked

(6)

Available Full

Start/Enrollment=0

Deregister/Enrollment=Enrollment-1 [Enrollment<MaxEnrollment-1]

Register/Enrollment=Enrollment+1

[Enrollment=MaxEnrollment-1]

Register/Enrollment=Enrollment+1

Deregister/Enrollment=Enrollment-1

A UML State Diagram for the Class Object

State Diagram for Class Object

• Class has two states Available and Full – Based on integrity constraint that class size cannot

exceed MaxEnrollment

• Transitions between states are of the form [guard] operation / action

– Guard: specifies when the transition can take place – Operation: the method that causes the transition – Action: how the internal attributes of the object

change when the transaction takes place.

Uses of State Diagrams

• Can be used to communicate the design to:

– Other designers

– Coders who must implement the design – Test designers who must test the final system

• A good test set must visit all the states in the diagram.

Description of a Transaction

• Name

• Brief Description

• Arguments -- in and out, and Return Values

• Called from, and Calls

– The event or procedure that calls it and those it calls

• Preconditions (what is true when it starts)

• Isolation level

• Actions

– Detailed description of what it does, what tables it accesses, what validity checks it makes, what constraints it checks, what it does if it finds an error, etc

Design Review

• When Design Document is complete, designers hold a Design Review with technical peers

– Is the Design Document consistent with the Specification Document?

– Is the Design Document inconsistent, incomplete, ambigious?

– Can the design be improved?

– What are the risks involved in the design?

Roadmap

• Requirements

• Specification

• Design

• Coding

• Testing

(7)

Coding

• Highest priorities are correctness and clarity

• All coders should use the same style

• Comments

– Each module and procedure should have a preamble, including a description of what the code is supposed to do and a revision history – Comments in code should be application-oriented

• Give all employees a 5% raise

Incremental Development

• Many projects take a long period of time – System requirements might change during that time

• Incremental development involves building the system in stages, each of which can be implemented in a short period of time

– Initially a core version with limited capability is built

– Later, new versions are built with increased functionality and based on new customer requirements and on customer experience with older versions

Roadmap

• Requirements

• Specification

• Design

• Coding

• Testing

Test Plan

• Testing is an important part of the project, not an informal ad hoc activity that starts after the code is complete

– Module tests – each programmer checks his code before submitting it

– Integration Tests – as the modules are integrated into the system

– Quality Assurance Tests – when the implementers think the system works

Quality Assurance Tests

• Black Box Tests

– Designed without looking inside the design and code – Does the system meet its specifications

– There must be at least one test for each numbered specification

• Glass Box Tests

– Designed looking at the design and code

– Tests must visit every line of code, every branch, check boundary conditions of every loop, invoke every event, execute every integrity check, check all error situations

• Stress Tests

– Does the system meet its specifications for throughput and response time

Test Plan Document

• Contains scripts of all tests and the correct result for each

• Highly desirable to employ a test driver or scripting mechanism to perform test automatically because tests will be repeated many times

• Must include some mechanism for reporting bugs and ensuring that the final version includes all bug fixes

• Contains the rationale for each test, so test plan can be maintained and enhanced as the system evolves

• If the implementors are in a different organization than the customer, the Test Plan Document is often a deliverable with the product

(8)

Acceptance and Beta Testing

• Acceptance Testing

– Before accepting and paying for the system, the customer runs its own acceptance tests – Using real data from the application

• Beta Testing

– If the system is a product and there are many customers, developers might select a subset of the customers to be beta testers

– Beta testers use the system and report errors

• After delivery, the system is often run in parallel with the existing system until its reliability has been demonstrated

Roadmap

• Requirements

• Specification

• Design

• Coding

• Testing

Project Planning Document

• Project Planning is a key aspect of any Software Engineering project

– Initial plan should be made while specification is being done and refined while design is being done.

• Manager divides the project into tasks – The completion of each task can be precisely defined – Task can be completed in some short period of time – Estimating the time for task completion takes experience and

knowledge

– Manager then determines task dependencies

• Task 6 cannot be started until Task 2 completes

• Tasks 1 and Task 2 can be done at the same time

• Plan can be documented using charts

Dependency Chart (PERT Chart)

Critical Path

• The longest path through the PERT chart is called the critical path

– Lower bound on the time required to complete the project

– In the example, Tasks 2, 6, and 7 form the critical path and the corresponding lower bound on project completion time is 27 days

Activity Chart (Gantt Chart)

(9)

Staff Allocation Chart

Planning

• To be accurate, charts must take into account such factors as

– Experience and competence of people assigned to each task

– Holidays and vacations

– Percentage of time people will spend on project

• Although project planning software can automate the generation of charts, the preparation and monitoring of a project plan requires considerable skill and experience

– Poor project management is the cause of most failures

Project Management

• The project manager schedules periodic (weekly) project meetings

• Team members report on status and expected completion time of their tasks compared to scheduled completion time

• Project manager takes appropriate steps to ensure project completes on time

Summary

Critical steps of project lifecycle:

• Requirements

• Specification – Specification Document

• Design – Design document

• Coding

• Testing – Test plan

• Project Management – Project planning document