© 2004, IAS1/6/20161 Automated Specification of Automotive Software Functions based on Expert Interviews By Md. Shariful Islam Supervisor: Prof. P. Göhner.

Slides:



Advertisements
Similar presentations
Performance Assessment
Advertisements

Lecture # 2 : Process Models
9/10/2004Use Case Workshop 1 CSC480 Software Engineering Workshop 1 Requirements Modeling.
CS3773 Software Engineering Lecture 03 UML Use Cases.
Use Case Diagram © copyright 2001 SNU OOPSLA Lab..
Object-Oriented Analysis and Design
The Role of Software Engineering Brief overview of relationship of SE to managing DSD risks 1.
Systems Analysis and Design in a Changing World, Fourth Edition
CAP 252 Lecture Topic: Requirement Analysis Class Exercise: Use Cases.
Chapter 15 Design, Coding, and Testing. Copyright © 2005 Pearson Addison-Wesley. All rights reserved Design Document The next step in the Software.
Requirements Specification
Software Engineering CSE470: Requirements Analysis 1 Requirements Analysis Defining the WHAT.
Analysis Concepts and Principles
Creating Architectural Descriptions. Outline Standardizing architectural descriptions: The IEEE has published, “Recommended Practice for Architectural.
Overview of Software Requirements
THE OBJECT-ORIENTED DESIGN WORKFLOW Statechart Diagrams.
Adding the Detail Filling in Use Case Templates. Use Case Template The use case diagram is important for visualizing a system and as a communication tool.
1 CMPT 275 Software Engineering Requirements Analysis Process Janice Regan,
CASE Tools And Their Effect On Software Quality Peter Geddis – pxg07u.
S/W Project Management
® IBM Software Group © 2006 IBM Corporation Writing Good Use Cases Module 4: Detailing a Use Case.
Database System Development Lifecycle © Pearson Education Limited 1995, 2005.
Overview of the Database Development Process
Systems Analysis And Design © Systems Analysis And Design © V. Rajaraman MODULE 14 CASE TOOLS Learning Units 14.1 CASE tools and their importance 14.2.
Abstract A software development life cycle can be divided into requirements elicitation, specification, design, implementation, testing, and maintenance.
Lecture 1 What is Modeling? What is Modeling? Creating a simplified version of reality Working with this version to understand or control some.
® IBM Software Group © 2006 IBM Corporation Rational Software France Object-Oriented Analysis and Design with UML2 and Rational Software Modeler 06. Requirements.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1 Requirements Engineering Processes l Processes used to discover, analyse and.
SOFTWARE ENGINEERING1 Introduction. Software Software (IEEE): collection of programs, procedures, rules, and associated documentation and data SOFTWARE.
REUSE-Re-Engineering The Software Process By Venkat Praveen Medikonda.
Requirements Elicitation. Who are the stakeholders in determining system requirements, and how does their viewpoint influence the process? How are non-technical.
Eliciting integration scenarios Proposal for Meeting
Requirements Engineering Requirements Elicitation Process Lecture-8.
Requirement Engineering. Review of Last Lecture Problems with requirement Requirement Engineering –Inception (Set of Questions) –Elicitation (Collaborative.
Chapter 6 Use Cases. Use Cases: –Text stories Some “actor” using system to achieve a goal –Used to discover and record requirements –Serve as input to.
Chapter 11 Analysis Concepts and Principles
1 CMPT 275 Software Engineering Requirements Gathering Activity Janice Regan,
University of Piraeus Department of Technology Education and Digital Systems Centre for Research and Technology - Hellas(C.E.R.T.H.) Informatics and Telematics.
Introduction Complex and large SW. SW crises Expensive HW. Custom SW. Batch execution Structured programming Product SW.
Requirements Reference: Chapters 5, 6, & 8. CMSC 345, Fall Objectives To introduce the concepts of user and system requirements To explain functional.
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.
Eliciting Integration Scenarios As discussed during Meeting
1 Quality Attributes of Requirements Documents Lecture # 25.
Data Structures and Algorithms Dr. Tehseen Zia Assistant Professor Dept. Computer Science and IT University of Sargodha Lecture 1.
Requirements Validation
Systems Analysis and Design in a Changing World, Fourth Edition
Requirements Engineering Requirements Engineering in Agile Methods Lecture-28.
Software Reuse Course: # The Johns-Hopkins University Montgomery County Campus Fall 2000 Session 4 Lecture # 3 - September 28, 2004.
UML (Unified Modeling Language)
Introduction Complex and large SW. SW crises Expensive HW. Custom SW. Batch execution Structured programming Product SW.
Requirements Analysis
Requirements engineering The process of establishing the services that the customer requires from a system and the constraints under which it operates.
Search Engine Optimization © HiTech Institute. All rights reserved. Slide 1 Click to edit Master title style What is Business Analysis Body of Knowledge?
21/1/ Analysis - Model of real-world situation - What ? System Design - Overall architecture (sub-systems) Object Design - Refinement of Design.
CSCI 383 Object-Oriented Programming & Design Lecture 7 Martin van Bommel.
Supporting the design of interactive systems a perspective on supporting people’s work Hans de Graaff 27 april 2000.
Chapter 7 Part II Structuring System Process Requirements MIS 215 System Analysis and Design.
7 Systems Analysis – ITEC 3155 The Object Oriented Approach – Use Cases.
Requirement Elicitation Review – Class 8 Functional Requirements Nonfunctional Requirements Software Requirements document Requirements Validation and.
Requirements. Outline Definition Requirements Process Requirements Documentation Next Steps 1.
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.
Systems Analysis and Design in a Changing World, Fourth Edition
Welcome to M301 P2 Software Systems & their Development
GRASP – Designing Objects with Responsibilities
Lecture 3 Prescriptive Process Models
Introduction Edited by Enas Naffar using the following textbooks: - A concise introduction to Software Engineering - Software Engineering for students-
CMPE 280 Web UI Design and Development August 29 Class Meeting
Complexity Time: 2 Hours.
Introduction Edited by Enas Naffar using the following textbooks: - A concise introduction to Software Engineering - Software Engineering for students-
Use Case Modeling.
Presentation transcript:

© 2004, IAS1/6/20161 Automated Specification of Automotive Software Functions based on Expert Interviews By Md. Shariful Islam Supervisor: Prof. P. Göhner Advisors: J. Konnertz Dr. H. Omasreiter (DaimlerChrysler) Master Thesis Universität Stuttgart Institut of Industrial Automation and Software Engineering Prof. Dr.-Ing. Dr. h.c. P. Göhner

© 2004, IAS2 Wants to create specification Influence the process $ 1 $ 5 $ 20 $ 50 $ 100 Requirements Design Coding Testing Maintenance Boehm, B., Software Engineering Economics, Prentice-Hall, 1981 Errors which originate in requirements tend to be the most expensive and troublesome to eliminate later The more you late, the more you pay  Complete and concise specification should be elicited  Error free and correct specification should be elicited Motivation Classical unsystematically process, Undefined brainstorming, Personality effect, Time consuming, Does not achieve the goal

© 2004, IAS3 Outline of Presentation Motivation Behind the Concept - Basic Developed Concept - Automated Specification Prototype Design Conclusion & Future Work

© 2004, IAS4 Predetermined systematically expert interview process Based on a sequence of intelligent questions and answers Generates the use cases automatically Basic What is a Use Case (UC)? Sequences of interactions between the system under discussion and its users, relating to a particular goal Can be represented by text or by diagram Serve as a means of communication from one person to another, often among people with no special training Simple text embedded in a table is usually the best choice  Unstructured paragraphs of text are inherently ambiguous and difficult to understand Task

© 2004, IAS5 Use Case Template UC-ID UC-Name Short Description Preconditions Primary Path Alternative Paths Postconditions sequence number (1 or 2 or 3...) is described user/actor intentions i.e. goal the least summary of the scenario conditions to invoke the UC, Critical situations as preconditions states main success scenario in steps describe the state after successful completion of the single use case A style guide to promote consistency among multiple people and multiple UCs Structured with necessary information to describe UC Basic

© 2004, IAS6 Outline of Presentation Motivation Behind the Concept - Basic Developed Concept - Automated Specification Prototype Design Conclusion & Future Work

© 2004, IAS7 Developed Concept AS2F-EI Static Process (SP) Dynamic Process (DP) Plan for the ProcessInterview ProcessPost Process Work Find the expert Intention & Time Appointment Materials (e.g. PC, Tool) Information given to expert Questions bank Review Process Automated Specification of Automotive Software Functions based on Expert Interviews

© 2004, IAS8 Goal Driven ApproachContext Driven Approach Static Process (SP) Static Process What Search for different user goals plays a pivotal role What Describe the behavior of contextual sub-functions Support driver to control the doors Check the doors Open the doors Close the doors... Car changing the lane On coming vehicle in the same lane Foggy weather... Maintain defined distance Bus Doors Control Distronic Function

© 2004, IAS9 yes no Completel y filled? UC speci- fication ? Fill the template Questions sequence What is the overall or top goal of the system? Control the bus doors Expert’s answers Who achieves this goal? The driver Can you please give an overview of this use case? What are the conditions to be true prior to drive this UC scenario? The driver controls the bus doors UC-Name: Short Description Preconditions The driver controls and manages the the bus doors The driver sits in the bus Goal Driven Approach Static Process - Goal Driven

© 2004, IAS10 Context Driven Approach yes no Completel y filled? UC speci- fication ? Expert’s answers Fill the template Questions sequence Use Case Context Matrix Use case context matrix to discover the critical situations systematically Uses input and context variables and valuations of those Use Case Context Matrix (UCCM) Static Process - Context Driven Distronic Function Input: Control lever (Activated or Deactivated), Brake (Pressed or Not pressed) Context: Traffic situation (Vehicle changing the lane), Weather (Dry or Foggy) Critical Situation: The other vehicle changing the lane

© 2004, IAS11 VariablesValuations Critical Situations (CS) CS1CS2CS3... Input Context Control lever Brake Accelerator pedal Traffic condition Weather Activated Deactivated Foggy Pressed Not pressed Oncoming vehicle in the same lane Vehicle changing the lane Dry x x x x x x x x x x x x x What could be the possible inputs of the system from user point of view? What could be the context variables of the system? Creation of UCCM -- Interview What could be the relevant values of those inputs? What could be the relevant values of those? The driver wants to maintain defined distance in case of other vehicle changing the lane Static Process – Context Driven Pressed Not pressed What could be the critical situations that we could specify the behavior of the system? Distronic Function

© 2004, IAS12 Static Process - Result 3 interviews for each approach of static process  Conduct both approaches to create a complete & concise user specification Approach Result-Criteria Goal Driven ApproachContext Driven Approach Kinds of system General functionality Context-dependent functionality Critical situations Can easily be divided in to sub-functions (+) Highly context-dependent (+) Elicits (+) Misses (-) Systematically figure those out (+) Misses (-)

© 2004, IAS13 Paradigm of Dynamic Process (DP) Dynamic Process SW function domain Selected SW function Retrieve UC from existing function Present the UC to expert Question s sequence UC specification Question s sequence Explicit Classification of SW Function Same functionality of software (SW) functions, developing day by day Improvement of the quality and reliability as well as saving time and money Main Aspect: Reuse of Requirements Existing UCs Why Reuse? Collection of automotive vehicle systems

© 2004, IAS14 Dynamic Process - Classification Explicit Classification Automotive vehicle SW domain Type of communication InsideOutside Assistance systems Telematic systems Cruise Control System Distronic System Electronic Stability Program, etc Does driver act? yes no Other functions How would you classify the system? Is it communicating with inside car system or outside car system? Does the system interfere with driver‘s action? Who is the main user and what is the goal achieved by the main user? The driver wants to maintain the defined distance.

© 2004, IAS15 UCUC UCUC Modifications UCUC UCUC Retrieve UC UCUC UCUC New UC Reuse Technique Which part of this UC can be used to your system? Which part of your system can be added with this UC? Are there other functionalities that you can describe it with a new UC? Dynamic Process - Reuse Common Variable Adding UCUC UCUC UCUC UCUC Complete Specification

© 2004, IAS16 Dynamic Process - Result + Less time + Increases correctness + Efficient - Possibility to mislead 2 Interviews for dynamic approach Selected function was speedtronic  More correct and error free user requirements specification

© 2004, IAS17 Motivation Behind the Concept - Basic Developed Concept - Automated Specification Prototype Design Conclusion & Future Work Outline of Presentation

© 2004, IAS18 AS2F-EI GUI Prototype A GUI- prototype has been designed for the interview process Name: AS2F-EI RS Tool, RS stand for Requirements Specification

© 2004, IAS19 Outline of Presentation Motivation Behind the Concept - Basic Developed Concept - Automated Specification Prototype Design Conclusion & Future Work

© 2004, IAS20 Conclusion & Future Work Static process does work well for creating specification from scratch Takes less time and creates more quality specification than workshop Dynamic process does work well on reuse concern It costs less time (approx 50%) than static process and an efficient process Interviewing tool to facilitate the gathering of user requirements Conclusion Future Work In dynamic process classification can be done for all kinds of system More advanced tool can be developed (e.g. web based tool)

© 2004, IAS21 Questions/Discussion