Lecture 9 Summary and additional issues Telematics systems

Lecture 9: Summary and additional issues Telematics systems and their design Doc. Ing. Ondřej Přibyl, Ph. D. Department of applied mathematics Faculty of Transportation sciences, CTU Ondřej Přibyl L 9: Additional issues page 1

Telematics systems and their design Faculty of Transportation Sciences, CTU Motivation for SAD • Where is SAD relevant and important? What is the ultimate aim? – We aim to develop a new or improved system • An ITS system typically consists of a combination of: – Software – Hardware • There are many different stakeholders with different expectations (Discussion: which? ) – Customer: Cheap and good, many features, high quality, … – Solution provider: Expensive, few features, low expectation on quality, … – Project manager: Meeting deadlines and quality gates – SW developer: A lot of fun staff, not necessarily documenting, … Ondřej Přibyl L 9: Additional issues page 2

Faculty of Transportation Sciences, CTU Telematics systems and their design Each system follows the same development life stages Request for a new system Project Planning Request for modification System Maintenance Post implementation review Prototype / Working version Ondřej Přibyl System Analysis Feasible solutions and system requirements System Design System Implementation Design specification L 9: Additional issues page 3

Telematics systems and their design Faculty of Transportation Sciences, CTU Why to do the analysis and design in a proper way? What are advantages for different stakeholders? • Developer (solution provider) – Knows exactly what is there to be done • Minimizes frustration as well as costs • Can manage and plan in a better way – Has a legal document in hand so does not have to jump as the customer wants – Can reuse some of the components in next projects • Customer – Knows what is there to expect – Has a legal document in hand so can force the expected outcome – The project has higher probability to end successfully (see CHAOS report) – Can reuse some of the components/infrastructure by different solution providers – Can use different solution providers simultaneously (risk minimization) • Public (in large ITS projects) – The overall cost (for the tax payer) is kept low – The outcome is as expected Ondřej Přibyl L 9: Additional issues page 4

Telematics systems and their design Faculty of Transportation Sciences, CTU Relative Cost to Fix an Error Ondřej Přibyl L 9: Additional issues page 5

Telematics systems and their design Faculty of Transportation Sciences, CTU What do you need to meet the development objectives? 1. Proper methodology for SAD (i. e. actual process) – defined activities, roles and deliverables 2. Proper tools for SAD (UML, CASE Tools) 3. Proper management – Defined and regularly held meetings, reports, configuration management, risk management, quality management, … 4. Proper communication – Central repository shared by all stakeholders – Regular meetings – Open mind ; ) Ondřej Přibyl L 9: Additional issues page 6

Telematics systems and their design Faculty of Transportation Sciences, CTU What limits you? • Constraints / resources – Time, – Money, – People, – Knowledge, – Legal conditions – other resources (material, …) Ondřej Přibyl L 9: Additional issues page 7

Faculty of Transportation Sciences, CTU Telematics systems and their design Quality of the solution • The area of the square (= productivity) is constant Quality of the product Development time Ondřej Přibyl Project size + + - - Development price L 9: Additional issues page 8

Telematics systems and their design Faculty of Transportation Sciences, CTU Who can help you? The Systems Analyst • Discussion: What should a system analyst be like? Ondřej Přibyl L 9: Additional issues page 9

Telematics systems and their design Faculty of Transportation Sciences, CTU Skills Needed by the Systems Analyst • Working knowledge of information technology (technical) • Computer programming experience and expertise • General business knowledge • General problem-solving skills • Good interpersonal communication skills • Good interpersonal relations skills • Flexibility and adaptability • Character and ethics Ondřej Přibyl L 9: Additional issues page 10

System design and analysis process Practical guidance Ondřej Přibyl L 9: Additional issues page 11

Faculty of Transportation Sciences, CTU Telematics systems and their design System development Life stages versus SEMP Project Planning Request for a new system Request for modification System Maintenance System Analysis Post implementation review Prototype / Working version System Implementation Feasible solutions and system requirements System Design specification This is true for each system Ondřej Přibyl This is one of the recommended methodologies L 9: Additional issues page 12

Telematics systems and their design Faculty of Transportation Sciences, CTU System Engineering Process – The model overview Ondřej Přibyl L 9: Additional issues page 13

Faculty of Transportation Sciences, CTU Telematics systems and their design System Engineering Process – Main features – Based on common Vee development model • Consists of the following major phases: » » System decomposition (Step 1 – 5) System implementation (Step 6) System composition (Step 7 – 10) System operation (Step 11) – Unified Modeling Language (UML) is used to cover the steps in the model (concept, requirements design, test cases, etc. ) – Defines – Major steps, – Deliverables, and – Responsibilities. Ondřej Přibyl L 9: Additional issues page 14

Faculty of Transportation Sciences, CTU Telematics systems and their design REQ. ANALYSIS Initial documents REQ. DISCOVERY INITIATION The Process of Requirements Discovery Draft SRS document Tenders, description of existing systems, customer requests, best practices, Mo. M, … Obtaining relevant materials Fact Finding • Document sampling • Research • Observation • Interviewing • Questionnaires Selection and organizing of requirements • Missing requirements • Conflicting requirements • Infeasible requirements • Inconsistent requirements • Overlapping requirements • Ambiguous requirements Resolving conflicts Review with client FINILIZING Iterate Ondřej Přibyl Formalizing requirements Output Final SRS document L 9: Additional issues page 15

Telematics systems and their design Faculty of Transportation Sciences, CTU Why do we need UML? • Unified communication language – Unify ideas from other modeling languages and incorporate industry best practices. – Everybody understands UML in the same way! • Graphical notation – A picture is worth a thousand words – An easy-to-learn but semantically rich visual modeling language • Provides multiple diagrams for capturing different architectural views • Promotes component reusability • Provide flexibility for applying different processes and mapping to different programming languages. Ondřej Přibyl L 9: Additional issues page 16

Telematics systems and their design Faculty of Transportation Sciences, CTU Discussion CASE STUDY • Team A: – You are a city hall representative responsible for establishing of a new section speed control system A. What major steps would you do? B. How would you choose a system provider C. What deliverables (steps) would you require from the system provider? • Team B: – You are the solution provider who wants to develop the system A. What major steps would you do? B. How would you meet the expectations? C. Provide explanation about particular steps. • Tutor: – I am an independent advisor who wants to ensure the highest quality of the solution (asking questions all) Ondřej Přibyl L 9: Additional issues page 17

Faculty of Transportation Sciences, CTU Telematics systems and their design City hall: Mayer Consultant company City hall: Technical dept. Operator in existing system Company: Sales dept. Company: Development / technical dept. Company: Project mngmt Ondřej Přibyl L 9: Additional issues page 18

Faculty of Transportation Sciences, CTU Telematics systems and their design Summary of major steps and deliverables System concept 1. Preparing system concept 2. Requirement analysis – Define Requirements on the system Functional 3. Functionality analysis architecture – Define actors in the system – Define use cases and assign them to particular actors – Define exact functionality for each use case 4. Data model • Creating of an entity-relationship (E-R) model • Definition of all tables and their relationships 5. Component design/physical design • Major physical components • Assignment of functions (use cases) to physical components • Interface definition Ondřej Přibyl Requirements specification Database design Physical architecture L 9: Additional issues page 19

Telematics systems and their design Faculty of Transportation Sciences, CTU Analysis and Design of ITS Systems (1) Ondřej Přibyl L 9: Additional issues page 20

Telematics systems and their design Faculty of Transportation Sciences, CTU Analysis and Design of ITS Systems (2) Ondřej Přibyl L 9: Additional issues page 21

How to apply UML? Practical Example: 4+1 Architectural Views Ondřej Přibyl L 9: Additional issues page 22

Telematics systems and their design Faculty of Transportation Sciences, CTU • The fundamental organization of a software system can be represented by: – Structural elements and their interfaces that comprise or form a system – Behavior represented by collaboration among the structural elements – Composition of Structural and Behavioral elements into larger subsystems Ondřej Přibyl L 9: Additional issues page 23

Faculty of Transportation Sciences, CTU Telematics systems and their design 4+1 View Architecture with UML 2 Analysts/Designer Programmers End-User Functionality System Integrators System Engineering System topology Delivery, installation Communication Logical View (Functional Reqmts) • Deals with design, packages, subsystems, and classes, layers, … Implementation View • Deals mostly with programming and organization of the software modules & unit test • While the Logical View is at the conceptual level, the diagrams in this view represent the physical-level artifacts that are built by the team. Process View (Process Decomposition) • This view considers non-functional aspects such as performance, scalability and throughput. It addresses the issues of concurrency, distribution and fault tolerance. Deployment or Physical View (Mapping Software to Hardware) • This view encompasses the nodes that form the system’s hardware topology on which the system executes; it focuses on distribution, communication and provisioning. Ondřej Přibyl L 9: Additional issues page 24

Telematics systems and their design Faculty of Transportation Sciences, CTU UML Concepts-The 4+1 view • Use Case view • Understandability • Logical View • Functionality • Process View • Performance • Scalable • Throughput • Implementation View • Software management • Deployment View • System topology • Delivery • Installation Ondřej Přibyl L 9: Additional issues page 26

Telematics systems and their design Faculty of Transportation Sciences, CTU Logical View • Realizing an application’s functionality in terms of structural elements, key abstractions and mechanisms, separation of concerns and distribution of responsibilities. • Architects use this view for functional analysis. Ondřej Přibyl L 9: Additional issues page 27

Telematics systems and their design Faculty of Transportation Sciences, CTU Process View • Non-functional aspects such as performance, scalability and throughput. It addresses the issues of concurrency, distribution and fault tolerance. • It shows the main abstractions from the Logical View executing over a thread as an operation. Ondřej Přibyl L 9: Additional issues page 28

Faculty of Transportation Sciences, CTU Telematics systems and their design UML Diagrams Are Key Artifacts Produced Have seen this slide before too. Use-Case Diagram Class Diagram State Diagram Use-Case 1 Actor A Actor B Use-Case 2 Domain Expert <<entity>> Customer name addr receive() withdraw() fetch() send() Use-Case 3 Deployment Diagram Class Repository Document. List File. Manager Package Diagram User Interface Definition Collaboration Diagram Document Graphic. File Component Diagram File. List Forward Engineering(Code Generation) and Reverse Engineering Source Code edit, compile, debug, link Sequence Diagram Executable System Ondřej Přibyl L 9: Additional issues page 32

Telematics systems and their design Faculty of Transportation Sciences, CTU Summary of course objectives • Provide an overview of the major steps and methodologies in the analysis and design of an ITS system • Focuses on processes and tools, not the technical know-how needed • You should be familiar with: – Basic terminology in SAD – System life stages – Basic development methodologies – What is (and what is not) UML and to have an overview of the diagrams – To know what is a CASE tool (you have seen it) – Recommendations for ITS • Which steps should be followed by a provider of ITS – Based on practical examples • What deliverables are required by the client – To learn something about formal presentation of the deliverables Ondřej Přibyl L 9: Additional issues page 33

Telematics systems and their design Ondřej Přibyl Faculty of Transportation Sciences, CTU L 9: Additional issues page 35

FINAL REPORT AND PRESENTATION Your next assignment is to prepare a formal presentation of your results Ondřej Přibyl L 9: Additional issues page 37

Telematics systems and their design Faculty of Transportation Sciences, CTU System Proposal – formal presentations Formal presentation – a special meeting used to sell new ideas and gain approval for new systems. They may also be used for any of these purposes: – Sell new system – Sell new ideas – Head off criticism – Address concerns – Verify conclusions – Clarify facts – Report progress Ondřej Přibyl L 9: Additional issues page 38

Faculty of Transportation Sciences, CTU Telematics systems and their design Formats for Written Reports Factual Format Administrative Format I. Introduction II. Methods and procedures II. Conclusions and recommendations III. Facts and details III. Summary and discussion of facts and details IV. Discussion and analysis of facts and details IV. Methods and procedures V. Recommendations V. Final conclusion VI. Conclusion VI. Appendixes with facts and details Traditional and best suited to readers who are interested in facts and details as well as conclusions. Ondřej Přibyl Modern, result-oriented format preferred by managers and executives L 9: Additional issues page 39

Telematics systems and their design Faculty of Transportation Sciences, CTU Typical Outline and Time Allocation for an Oral Presentation I. Introduction (one-sixth of total time available) A. Problem statement B. Work completed to date II. Part of the presentation (two-thirds of total time available) A. Summary of existing problems and limitations B. Summary description of the proposed system C. Feasibility analysis D. Proposed schedule to complete project III. Questions and concerns from the audience (time here is not to be included in the time allotted for presentation and conclusion; it is determined by those asking the questions and voicing their concerns) IV. Conclusion (one-sixth of total time available) A. Summary of proposal B. Call to action (request for whatever authority you require to continue systems development) Ondřej Přibyl L 9: Additional issues page 40

Telematics systems and their design Faculty of Transportation Sciences, CTU Guidelines for Visual Aids Ondřej Přibyl Source: Copyright Keith page 41 L 9: Additional issues London

Telematics systems and their design Faculty of Transportation Sciences, CTU Assignment • Prepare final presentation from the position of a system provider (to persuade the client) • Focus on challenges and your approach to solve them. – Prepare BACK UP slides with details to each step, which do not fit into the standard time to support questionable topics (total overview, rest of the description) • Time 15 minutes! + 5 minutes questions you must know your project but also methodology) PART I 5 minutes PART II 10 minutes Ondřej Přibyl L 9: Additional issues page 42

Telematics systems and their design Faculty of Transportation Sciences, CTU What should be presented (PART II)? 1. Current situation versus target solution (Where are we and where we want to get) 2. Introduction (terminology, major subsystems, principle, constrains, …) 3. Major customer requirements and expectations (process, structure, selected major req. ) 4. Functionality of the system (overview (use cases), structure, description of major processes (activity diagrams)) 5. Conclusions – why your solution, – major features, – What would be next steps in your project + Your conclusion for the project (what was difficult, what was helpful) Ondřej Přibyl L 9: Additional issues page 43

Discussion Presentation next time Ondřej Přibyl L 9: Additional issues page 44