Database Project Lifecycle Philippe Bonnet, 2006 2 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 Philippe Bonnet, 2006 3 Philippe Bonnet, 2006 4 Project Life Cycle Statement of Objectives Brief statement made by the customer of what the objectives of the system are Project Lifecycle 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 Philippe Bonnet, 2006 5 Philippe Bonnet, 2006 6 1
Project Life Cycle 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 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 Philippe Bonnet, 2006 7 Philippe Bonnet, 2006 8 Project Lifecycle Philippe Bonnet, 2006 9 Philippe Bonnet, 2006 10 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? Philippe Bonnet, 2006 11 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. Philippe Bonnet, 2006 12 2
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 Philippe Bonnet, 2006 13 Philippe Bonnet, 2006 14 Authentication StudentGrade Student/Faculty Information Issues Register Deregister Student Use Case Diagram for the Student Registration System GetGradeHistory GetRegistered Courses GetEnrolled Courses EndOfSession Faculty Member Course Information EndOfSemester GetClassRoster Room OLAP Query 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 Philippe Bonnet, 2006 16 Specification Document Philippe Bonnet, 2006 17 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 Philippe Bonnet, 2006 18 3
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 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 Philippe Bonnet, 2006 19 Philippe Bonnet, 2006 20 UML Sequence Diagrams Student or Faculty Member Web Server Database Enter URL 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 Philippe Bonnet, 2006 21 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 Validate Login Return Status 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 Philippe Bonnet, 2006 23 Philippe Bonnet, 2006 24 4
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 Philippe Bonnet, 2006 25 Philippe Bonnet, 2006 26 Readers of the Design Document 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 Philippe Bonnet, 2006 27 Philippe Bonnet, 2006 28 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 Philippe Bonnet, 2006 29 Philippe Bonnet, 2006 30 5
State Diagram for Class Object Start/Enrollment=0 [Enrollment<MaxEnrollment-1] Register/Enrollment=Enrollment+1 Available Deregister/Enrollment=Enrollment-1 [Enrollment=MaxEnrollment-1] Register/Enrollment=Enrollment+1 Full Deregister/Enrollment=Enrollment-1 A UML State Diagram for the Class Object Philippe Bonnet, 2006 31 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. Philippe Bonnet, 2006 32 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. Philippe Bonnet, 2006 33 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 Philippe Bonnet, 2006 34 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? Philippe Bonnet, 2006 35 Philippe Bonnet, 2006 36 6
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 Philippe Bonnet, 2006 37 Philippe Bonnet, 2006 38 Test Plan 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 Philippe Bonnet, 2006 39 Philippe Bonnet, 2006 40 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 Philippe Bonnet, 2006 41 Philippe Bonnet, 2006 42 7
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 Philippe Bonnet, 2006 43 Philippe Bonnet, 2006 44 Project Planning Document Dependency Chart (PERT Chart) 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 Philippe Bonnet, 2006 45 Critical Path Activity Chart (Gantt Chart) 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 Philippe Bonnet, 2006 47 Philippe Bonnet, 2006 48 8
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 Philippe Bonnet, 2006 49 Philippe Bonnet, 2006 50 Project Management Summary 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 Philippe Bonnet, 2006 51 Critical steps of project lifecycle: Specification Document Design document Test plan Project planning document Philippe Bonnet, 2006 52 9