Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


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

1 © 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

2 © 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

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

4 © 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

5 © 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

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

7 © 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

8 © 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

9 © 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........

10 © 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

11 © 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

12 © 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 (-)

13 © 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

14 © 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.

15 © 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

16 © 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

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

18 © 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

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

20 © 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)

21 © 2004, IAS21 Questions/Discussion


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

Similar presentations


Ads by Google