Presented by: Yaseen Ali, Suraj Bhardwaj, Rohan Shah Yaseen Ali, Suraj Bhardwaj, Rohan Shah Mechatronics Engineering Group 302 Instructor: Dr. K. Sartipi.

Slides:



Advertisements
Similar presentations
COMP 110: Introduction to Programming Tyler Johnson Feb 18, 2009 MWF 11:00AM-12:15PM Sitterson 014.
Advertisements

COMP 110: Introduction to Programming Tyler Johnson Mar 16, 2009 MWF 11:00AM-12:15PM Sitterson 014.
COMP 110: Introduction to Programming Tyler Johnson Apr 20, 2009 MWF 11:00AM-12:15PM Sitterson 014.
COMP 110: Introduction to Programming Tyler Johnson Apr 13, 2009 MWF 11:00AM-12:15PM Sitterson 014.
COMP 110: Introduction to Programming Tyler Johnson Mar 25, 2009 MWF 11:00AM-12:15PM Sitterson 014.
COMP 110: Introduction to Programming Tyler Johnson Apr 8, 2009 MWF 11:00AM-12:15PM Sitterson 014.
Wouter Noordkamp The assessment of new platforms on operational performance and manning concepts.
Ziehm Academy - User Guide for online registration portal Nuremberg, February 2009.
1 Cathay Life Insurance Ltd. (Vietnam) 27/11/20091.
Feb Alten Group Started in France in 1988 Currently more than people Presence in 10 countries Active in The Netherlands since 2002.
Presented by Group: 110: Byron Sinclair, Jacob Alexander, and Manmeet Singh.
Prescriptive Process models
1. (c) Alan Rowley Associates Laboratory Accreditation Dr Alan G Rowley Quality Policy based on Quality Objectives Quality Management System Communicate.
30 min Scratch July min intro to Scratch A Quick-and-Dirty approach Leaving lots of exploration for the future. (5 hour lesson plan available)
Systems Development Environment
1 Software Processes A Software process is a set of activities and associated results which lead to the production of a software product. Activities Common.
1COM6030 Systems Analysis and Design © University of Sheffield 2005 COM 6030 Software Analysis and Design Lecture 2- Software Process Models and Project.
Software Project Management
CS487 Software Engineering Omar Aldawud
What is Software Design?. Systems Development Life- Cycle Planning Analysis Design Implementation Design.
Ch 3 System Development Environment
Software Modeling SWE5441 Lecture 3 Eng. Mohammed Timraz
CS 501: Software Engineering
Fundamentals of Information Systems, Second Edition
CS /31 Illinois Institute of Technology CS487 Software Engineering Midterm Review David Lash.
Mastering OOA/OOD with UML. Contents Introduction Requirements Overview OOAOOD.
CHAPTER 19 Building Software.
Software Life Cycle Model
Chapter 1 The Systems Development Environment
The Project AH Computing. Functional Requirements  What the product must do!  Examples attractive welcome screen all options available as clickable.
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Computer Science: An Overview Tenth Edition by J. Glenn Brookshear Chapter.
1.Database plan 2.Information systems plan 3.Technology plan 4.Business strategy plan 5.Enterprise analysis Which of the following serves as a road map.
CIS 321—IS Analysis & Design
Chapter 2: Approaches to System Development
1COM6030 Systems Analysis and Design © University of Sheffield 2005 COM 6030 Software Analysis and Design Lecture 2- Software Process Models and Project.
INFORMATION SYSTEM APPLICATIONS System Development Life Cycle.
CSI315 Web Applications and Technology Overview of Systems Development (342)
Objectives of the Lecture
Information Systems Analysis and Design
Software Processes lecture 8. Topics covered Software process models Process iteration Process activities The Rational Unified Process Computer-aided.
Presented by Khaled Chebaro, Yaser Jafar, Orin Pereira KYO Engineering Consultants Inc. on 27/11/07 Automated Banking Machine for MacBank Inc. SFWR 3M04.
Chapter 10 Information Systems Analysis and Design
Software Engineering Management Lecture 1 The Software Process.
SFWR ENG 3KO4 Software Development Fall 2009 Instructor: Dr. Kamran Sartipi Software Requirement Specification (SRS) for the Automated Banking Machine.
1 Systems Analysis and Design in a Changing World, Thursday, January 18, 2007.
Content The system development life cycle
ABM Machine: AutoMac Software Engineering 3M04 Dr. Kamran Sartipi Software Engineering 3M04 Dr. Kamran Sartipi By: Ramon Tiongson Belal Abou Shaar Monica.
The Systems Development Life Cycle
SYSTEMS ANALYSIS AND DESIGN LIFE CYCLE
Systems Life Cycle A2 Module Heathcote Ch.38.
Rational Requirements Management with Use Cases v5.5 Copyright © Rational Software, all rights reserved 1 Requirements Management with Use Cases.
Systems Analysis and Design in a Changing World, Fourth Edition
1 CS 501 Spring 2004 CS 501: Software Engineering Lecture 2 Software Processes.
Developed by Reneta Barneva, SUNY Fredonia The Process.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
Software Engineering Issues Software Engineering Concepts System Specifications Procedural Design Object-Oriented Design System Testing.
Overview of RUP Lunch and Learn. Overview of RUP © 2008 Cardinal Solutions Group 2 Welcome  Introductions  What is your experience with RUP  What is.
ANALISA & PERANCANGAN SISTEM Disusun Oleh : Dr. Lily Wulandari Program Pasca Sarjana Magister Sistem Informasi Universitas Gunadarma.
Lectures 2 & 3: Software Process Models Neelam Gupta.
© Chinese University, CSE Dept. Software Engineering / Software Engineering Topic 1: Software Engineering: A Preview Your Name: ____________________.
1 slc5 TTYP – C++ revisited 1 Which of the following statements are reasonable after the following statement: char* fred = new char[5]; a. fred = bill;
C_ITIP211 LECTURER: E.DONDO. Unit 1 : The Systems Development Environment.
Chapter 7: Software Engineering
Software Engineering Management
Systems Analysis & Design N106
Classical Waterfall Model
MacBank ABM Demonstration
Chapter 2: Building a System
Presentation transcript:

Presented by: Yaseen Ali, Suraj Bhardwaj, Rohan Shah Yaseen Ali, Suraj Bhardwaj, Rohan Shah Mechatronics Engineering Group 302 Instructor: Dr. K. Sartipi Course: SFWR ENG 3K04 12/4/20091Group 302

Outline Overview SRS SRS to High-Level SDS High-Level SDS to Low-Level SDS Implementation in C# DEMO Conclusion 12/4/2009Group 3022

What is Software Engineering? Application of: Systematic Disciplined Quantifiable Approach to the development, operation and maintenance of software. Study of these approaches is software engineering. 12/4/20093Group 302

Software Engineering Crisis Current state of software technology in dealing with development and maintenance of large and complex software systems. Tackled by: - Providing disciplined processes and methodologies to: Design Implement Maintain Large software systems. 12/4/20094Group 302

12/4/2009Group 3025

Software Engineering Project Consists of computer programs and associated documentation, which includes: o SRS o SDS o Technical Manual o User Manual o Source o Binary Files o Build Files o Version 12/4/20096Group 302

Why is it important? Software engineering has had a major contribution in the development of the modern world. Software engineering is used in a variety of industries and applications: Process automation: 12/4/20097Group 302

Why is it important? Equipment control Scientific problems Entertainment industry Education and office management 12/4/20098Group 302

Software Life Cycle Models Waterfall Model Extensive Programming Throwaway Prototyping Model Spiral Model Evolutionary Prototyping Model OSS Development Model 12/4/20099Group 302

12/4/200910Group 302

Requirements Analysis and Specifications After precise costs and benefits of the software have been defined. Requirements are in end user terms. Helps to make user manuals and system test plans. 12/4/200911Group 302

Requirements and Specifications(ABM) 15 min interview with TA posing as MacBank representative. RFP provided Included basic banking requirements. Staff requirements. 12/4/200912Group 302

SRS Benefits SRS is the initial step in the software life cycle. SRS should contain everything there is to know about the system. Focuses on the “what” not the “how” It allows easy communication between individuals.

SRS and Quality The Software Requirement Specification is an important step in providing a high quality software solution. "The hardest single part of building a software system is deciding precisely what to build" (Frederick Brooks) 12/4/200914Group 302

Features of SRS Complete document specifying the goals of the system. Clearly defined what qualities the application must exhibit. Identified all stakeholders and defined the operating environment. Did NOT include how the solution was to be implemented. 12/4/200915Group 302

SRS Environment From the RFP : Able to understand the operating environment. Translated requirements to Specifications document (SRS) 12/4/200916Group 302

USE Case Diagram Use Case diagram was used to specify the actors and actions in the system 12/4/200917Group 302

Design and Specification 2 Sub-phases: – Architectural or High Level Design – Detailed or Low Level Design High Level : deals with overall module structure and organization Low Level : high level is then refined by Designing each module in detail. Solving individual problems 12/4/200918Group 302

Design and Specification (ABM) High Level – Component Diagrams – State Diagram Low Level – Detailed Modules: Functions performed by each module. – Individual State Diagrams for each module. 12/4/200919Group 302

Making of High-Level SDS The SRS required the system to interact with two types of users: – Staff – Customers The staff user should be able to perform the following operation: – Starting and stopping ABM services. – Refill the vault when it is low. The customer should be able to perform the following operations: – Withdraw money – View Balance – Transfer Money within accounts. – Deposit money Also, Bank should perform the following main functions: – Verify card and PIN number 12/4/200920Group 302

12/4/200921Group 302

12/4/200922Group 302

High-Level to Low-Level SDS Listed activities and entities Split up similar activities (functionalities) High Cohesion, Low Coupling Address functions and respective variables Classes Real life modularity 12/4/200923Group 302

Code and Module Testing Actual code is produced. Individual modules are tested ABM Implementation: – Bank – Transactions – User Interface 12/4/200924Group 302

Integration and System Testing Individually tested modules put together. ABM implementation 12/4/200925Group 302

Delivery and Maintenance Most important part of designing a software system Delivered to the customer after all the tests are passed. Modifications come under maintenance. ABM Implementation – out of the scope of the course 12/4/200926Group 302

ABM Implementation 12/4/2009Group 30227

User Interface Visual Studio (C#) GUI vs. Command Line Calling on different classes – Forms – Limited access to information User Functions 12/4/200928Group 302

Transactions Class Basic Functions: Deposit, Withdraw, Transfer, Balance Inquiry. Supporting functions: Account Initiliazer, Get Balance, Set Balance. Modularized format. High cohesion Low coupling between classes. 12/4/200929Group 302

Bank Class Functions included: – verify_pin – verify_card – Get_Balance – Set_Balance – Get_Deposit – Set_deposit – Vault_amount GemBox Application 12/4/200930Group 302

DEMO 12/4/2009Group 30231

Team Work Efficient division of Tasks. Weekly meetings to plan next step and follow up on progress Dedicated/Passionate team members Organizational Tools : GANTT Chart. 12/4/200932Group 302

Organizational Tools: GANTT Chart 12/4/200933Group 302

Gains from the course New perception of software design (not just coding). Transformed basic requirements into a software product. How to manage projects Most practical course ever taken; saw material in action. 12/4/200934Group 302

Time Breakdown ActivityTime (hours) SRS5 SDS High level10 SDS low Level10 Coding30 Debugging10 Other5 Total70 12/4/200935Group 302

Comments and Suggestions More parallelism between lectures and labs. More time for implementation. Overall great learning experience! 12/4/200936Group 302

Thank You! Questions?

12/4/2009Group 30238

12/4/2009Group 30239

12/4/2009Group 30240

12/4/2009Group 30241

12/4/2009Group 30242

12/4/2009Group 30243

12/4/2009Group 30244