1 Case Study: Starting the Student Registration System Chapter 3.

Slides:



Advertisements
Similar presentations
Software Requirements
Advertisements

Database Planning, Design, and Administration
Software Development Languages and Environments. Programming languages High level languages are problem orientated contain many English words are easier.
P5, M1, D1.
Case Tools Trisha Cummings. Our Definition of CASE  CASE is the use of computer-based support in the software development process.  A CASE tool is a.
Information System Design IT60105 Lecture 3 System Requirement Specification.
©Silberschatz, Korth and Sudarshan1.1Database System Concepts Chapter 1: Introduction Purpose of Database Systems View of Data Data Models Data Definition.
Informatics 43 – May 7, Restatement of Goals for Testing Want to verify software’s correctness  Need to test  Need to decide on test cases  No.
Chapter 14 Requirements and Specifications. Copyright © 2005 Pearson Addison-Wesley. All rights reserved Software Engineering The implementation.
The Unified Software Development Process - Workflows Ivar Jacobson, Grady Booch, James Rumbaugh Addison Wesley, 1999.
Automating Tasks With Macros
Chapter 15 Design, Coding, and Testing. Copyright © 2005 Pearson Addison-Wesley. All rights reserved Design Document The next step in the Software.
Software Requirements
©Silberschatz, Korth and Sudarshan1.1Database System Concepts Chapter 1: Introduction Purpose of Database Systems View of Data Data Models Data Definition.
Chapter 9 Using Data Flow Diagrams
1 Software Requirements Specification Lecture 14.
TIBCO Designer TIBCO BusinessWorks is a scalable, extensible, and easy to use integration platform that allows you to develop, deploy, and run integration.
Microsoft Visual Basic 2005 CHAPTER 1 Introduction to Visual Basic 2005 Programming.
University of Palestine software engineering department Testing of Software Systems Fundamentals of testing instructor: Tasneem Darwish.
Chapter 2 Build Your First Project A Step-by-Step Approach 2 Exploring Microsoft Visual Basic 6.0 Copyright © 1999 Prentice-Hall, Inc. By Carlotta Eaton.
1 Integrated Development Environment Building Your First Project (A Step-By-Step Approach)
Project Management Chapter 5, PG 92. Introduction Why is software management particularly difficult?  The product is intangible Cannot be seen or touched.
Pre-Project Activities Text Chapters 5 and 6. Pre-Project Activities 1.Contract Review 2.Development Plan 3.Quality Plan.
Chapter 9 Database Planning, Design, and Administration Sungchul Hong.
Database System Development Lifecycle © Pearson Education Limited 1995, 2005.
Systems Analysis – Analyzing Requirements.  Analyzing requirement stage identifies user information needs and new systems requirements  IS dev team.
Introduction to Databases
COMPUTER SOFTWARE Section 2 “System Software: Computer System Management ” CHAPTER 4 Lecture-6/ T. Nouf Almujally 1.
المحاضرة الثالثة. Software Requirements Topics covered Functional and non-functional requirements User requirements System requirements Interface specification.
Part3 Database Analysis and Design Techniques Chapter 04- Overview of Database Planning, Design and Administration Database Systems Lu Wei College of Software.
Understand Application Lifecycle Management
Event Driven Programming
 Explain the role of a system analyst.  Identify the important parts of SRS document.  Identify the important problems that an organization would face.
Interaction Modeling Interaction model describes how objects interact to produce useful results. Interactions can be modeled at different levels of abstraction:
Chapter 8: Writing Graphical User Interfaces Visual Basic.NET Programming: From Problem Analysis to Program Design.
What is a Business Analyst? A Business Analyst is someone who works as a liaison among stakeholders in order to elicit, analyze, communicate and validate.
University of Virginia Software Development Processes (CS340 John Knight 2005) 1 Software Development Processes.
1 Introduction to Software Engineering Lecture 1.
CHAPTER TWO INTRODUCTION TO VISUAL BASIC © Prepared By: Razif Razali 1.
Lesson Overview 3.1 Components of the DBMS 3.1 Components of the DBMS 3.2 Components of The Database Application 3.2 Components of The Database Application.
A Use Case Primer 1. The Benefits of Use Cases  Compared to traditional methods, use cases are easy to write and to read.  Use cases force the developers.
CONTENTS OF THE SRS REPORT. Software Requirements Specification (SRS) template The SRS document describes recommended approaches for the specification.
Software Requirements: A More Rigorous Look 1. Features and Use Cases at a High Level of Abstraction  Helps to better understand the main characteristics.
Requirements Engineering Lesson 2. Terminologies:  Software Acquisition is where requirement engineering significantly meets business strategy.  Software.
Systems Development Life Cycle
Software Engineering1  Verification: The software should conform to its specification  Validation: The software should do what the user really requires.
Click to add text Systems Analysis, Prototyping and Iteration.
Topic 4 - Database Design Unit 1 – Database Analysis and Design Advanced Higher Information Systems St Kentigern’s Academy.
Winter 2011SEG Chapter 11 Chapter 1 (Part 1) Review from previous courses Subject 1: The Software Development Process.
Mr.Prasad Sawant, MIT Pune India Introduction to DBMS.
ANALYSIS PHASE OF BUSINESS SYSTEM DEVELOPMENT METHODOLOGY.
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
Chapter – 8 Software Tools.
MIT App Inventor Lesson 3 Algorithms Variables Procedures.
1 Chapter 2 SW Process Models. 2 Objectives  Understand various process models  Understand the pros and cons of each model  Evaluate the applicability.
Chapter 2 Build Your First Project A Step-by-Step Approach 2 Exploring Microsoft Visual Basic 6.0 Copyright © 1999 Prentice-Hall, Inc. By Carlotta Eaton.
 System Requirement Specification and System Planning.
1 Team Skill 3 Defining the System Part 1: Use Case Modeling Noureddine Abbadeni Al-Ain University of Science and Technology College of Engineering and.
Classifications of Software Requirements
Chapter 1: Introduction
Introduction to Visual Basic 2008 Programming
Chapter 1: Introduction
SNS College of Engineering Coimbatore
Computer Programming.
Introduction to Database Systems
Analysis models and design models
Chapter 1: Introduction
Chapter 1: Introduction
Chapter 1: Introduction
Chapter 1: Introduction
Presentation transcript:

1 Case Study: Starting the Student Registration System Chapter 3

2 Software Engineering The implementation of a transaction processing 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

3 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

4 Good Software Engineering Practice Bases on many years of experience, the recommended steps in carrying out a Software Engineering project are: Statement of Objectives –Brief statement made by the customer of what the objectives of the system are

5 Steps in a Software Engineering Project (cont’d) 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

6 Steps in a Software Engineering Project (cont’d) 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

7 Steps in a Software Engineering Project (cont’d) The remaining steps are described in Chapter 12 –Design Document –Test Plan –Code –Testing –Delivery

8 Requirements Document for the Student Registration System A complete Requirements Document for the Student Registration System is given in the text –Requirements are numbered so they can be referred to in other documents, such as the Test Plan, which must ensure that a test exists for each requirement –Requirements are stated with words such as “must” and “shall” Words such as “should” and “can” do not connote a mandatory requirement and should be avoided

9 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

10 Application Generators The Student Registration System requires a sophisticated user interface, which must be described in its Specification Document An application generator can be of significant help in specifying and building such an interface and, in fact, in implementing the entire system

11 Components of an Application Generator A Graphical User Interface Designer to help design and implement the GUI A programming language that can be used to write application programs An Integrated Programming Development Environment, including a program editor, debugger, etc. A mechanism to allow the application programs to connect to the database and execute SQL statements

12 Visual Objects The GUI Designer contains built in objects for forms and controls on those forms –Pushbuttons, textboxes, etc. These forms and controls can be thought of as visual objects Visual objects have two data structures –A data structure that represents the semantic, non-visual aspects of the object For a textbox, its name and the text string stored in it –A data structure that represents the visual aspects of the object For a textbox, its location on the screen, shape, size, color, etc

13 Visual Objects (cont’d) Visual objects also contain a set of methods we call a drawing engine –Uses the information in the visual attributes of the object to draw its visual representation –Keeps the visual representation and the visual attributes consistent If the location attribute is changed, it moves the visual representation If the visual representation is moved (with the mouse), it changes the location attribute

14 GUI Generation Using the built-in visual objects, and perhaps customizing them, the GUI designer can quickly design a GUI –The existence of the built-in objects with their drawing engines considerably simplifies the task of designing and building the GUI –A proposed GUI should be shown to the customer at an early stage to get his feedback so that any requested changes can be made

15 Events and Procedures After designing the GUI, the application designer must design and implement the application procedures that –Cause forms to be displayed –Gather the information from the screen –Initiate transactions to access the database –Display the results of the transaction –Produce appropriate printed reports These application procedures are event driven

16 Events An event is some action (usually) initiated by the user at run time –A particular button is clicked The application programmer can associate a particular application program with a particular event –When a particular button is clicked, a particular program is executed

17 Referring to GUI Objects Application programs can refer to attributes of objects on the screen st = IDbox.txt outbox.txt = “This is the text” where st is a variable in the application program IDbox and outbox are the names of objects corresponding to controls on the screen txt is an attribute of both IDbox and outbox

18 Specification Document Now that we have discussed how application generators can be used to design and build GUIs, we return to our discussion of the Specification Document, which includes a specification of the GUI

19 Partial Contents of a 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

20 Partial Contents of a Specification Document (cont’d) 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

21 Specification Document for the Student Registration System Preparing the Specification Document for the Student Registration System is an exercise for the students Initial portions of some sections are given in the text