Automotive Software

3. Software Engineering

Department of Automotive Engineering, HYU

Soonmin Hwang
E-mail : soonminh@hanyang.ac.kr

This slide is adapted from the “CSE4006 Software Engineering” class materials of Prof. Scott Uk-Jin Lee,
ERICA Campus, Hanyang University, with the written permission of the original author.
1. Introduction to Software Engineering
Successful Software Project
If the project meets

3
Successful Software Project
How many software projects have been successful?
‒ Based on “time”, “budget”, and “quality” (within specification)
‒ Evaluate projects as Succeeded (all) or Challenged or Failed (not finished)

è Over 20+ years, Challenged / Failed projects are not reduced significantly. Why?

CHAOS Report, Standish Group 4

Successful Software Project
Project size vs. Success rate

CHAOS Report, Standish Group 5

Causes of Failures
Lack of
• awareness about the software
• software project management
• knowledge on software engineering

6
Difficulties in Software Project
Reasons
• Communication issue due to invisibility
: Diverse stakeholders with different level of understanding
: Problem is not always well-defined

• Project complexity
: Difference in development duration, number of developers, user levels, etc.

• Various management issues

: Requirements change management, scheduling, code versioning, etc.

• Product of the intellectual activity, not assembly/manufacturing

…

7
Necessity of Engineering Principles
As the size of software grows
• Programming à Process. Planning/tools affect productivity and quality.
• Experiences on project management and development are very important
• The success of software developments depends greatly on the maturity of the
developing group on software engineering [1989, Humphrey]

8
Causes for Errors
Logic design
20% Coding
30%

Misunderstanding
of functionality
15%
Documentation
and others
35%
9
Causes for Errors

Ambiguous points in requirements

Misunderstanding
10
Overview
1. History
2. Definitions and Objectives
3. Software Maintenance
4. Importance of Specification and Design
5. Concept of Team Programming

11
Software Failures - MCO at Mars (NASA, 1998)

13
Software Failures - MCO at Mars (NASA, 1998)
Defect analysis
• Variable ∆𝑉 was calculated to be 4.45 times smaller than its normal value
• Units in MCO thrust data: the international standard unit of 1 (N⋅s)
• But, SM_FORCE program in MCO uses 4.45 (lb⋅s), which is American unit
Expected trajectory

Real trajectory

Mars gravity acting to lower

the trajectory Mars
was greater than expected

14
Software Failures – Remotely Kill a Jeep (2014)

16
Software Failures - Remotely Kill a Jeep (2014)
Hack a Jeep by Miller & Valasek
• Connect to a jeep in motion remotely
• They can monitor, collect, and analyze
bus data between BCM and CAN-C
in the control system
• Attempt to stop a moving vehicle
by controlling vehicle via a remote command

Defect analysis
• Radio module and BCM is connected via CAN
• Vulnerability: data bus is exposed to outside
‒ Able to scan vehicle’s IP and install an app
‒ Send a CAN message to take control
17
Software Crisis
Problems of Software Engineering
• cost overrun, delayed period, poor performance, unreliablility
• impossible to maintain / huge maintenance costs
è Supply and demand imbalance of the software is increasing!

Development
33%
Maintenance
67%

18
1. History of Software Engineering

• 1967, A NATO group coined the term ” Software Engineering“

• 1968, NATO conference concluded that

: software engineering should use the philosophies and paradigms
of established engineering disciplines, to solve the problem of
software crisis

19
2. Software Engineering
Definition
: Applying engineering, scientific, and mathematical principles and methodologies
to economically produce high quality software (Humphrey, SEI)
: Systematic approach to the development, operation, maintenance,
and destruction of software (IEEE computer society)

Objectives
• Quality
• Productivity

20
2. Software Engineering – Quality
Perspective on quality differs
• Depending on where you stand

21
2. Software Engineering – Productivity
Maturity of the organization: CMM (Capability Maturity Model)

1. Initial (chaotic, ad hoc, individual heroics)

: the starting point for use of a new/undocumented repeat process
2. Repeatable
: documented sufficiently, repeating the same steps may be attempted
3. Defined
: defined/confirmed as a standard business process
4. Capable
: quantitatively managed in accordance with agreed-upon metrics
5. Efficient
: management includes deliberate optimization/improvement

22
2. Software Engineering – Productivity
Other factors affecting productivity
• Ability of programmers
• Team communication
• Complexity of the product
• Technology level
• Management skills

23
2. Software Engineering – Facts
• Most of the labor spent on software is maintaining current system

• The later the errors are discovery, the higher the cost of correction
• Many errors occur due to the inaccurate requirement definition
• Programming error are less the design errors
• Putting more manpower to a delayed project slow down the completion
• If software is not maintained properly it turns into a complex software

24
3. Software Maintenance
Cost of the entire software process cycle

25
4. Importance of Spec. and Design
Why costs increase later in each development phase
• As the code moves to later stages,
‒ More challenging to remember all the details
and locate issues
‒ Can be time-consuming
to reproduce on a developer’s local environment
‒ Risky to try to fix
: might negatively impact on live users

• Deeper defects
‒ much more challenging to uncover
‒ Often do not become apparent
until the software is in the production phase
e.g., memory leaks or race conditions

26
5. Team Programming
Multi-person construction with multi-version software
• Programming: personal activity
• Software engineering: team activity

The initial (early stage of) programming

• the problem is well defined
• mostly scientific applications written by experts in the area
• user = programmer = maintainer

Separation of user and programmer

• User: specify the problems (tasks)
• Programmer: interprets and translates into code
27
5. Team Programming
Programming-in-the-small
• Good programming skill
• Fluent in programming language
• Skilled in data structure and algorithms

Programming-in-the-large
• Communication skills
• Design approaches (i.e., system abstraction) is important
• top down design / Divide & conquer paradigm / Component based integration
• Interpretation and accurate specification of ambiguous requirement
• Modeling is required
• Ability to manage work according to schedules
28
5. Team Programming
Solutions for the software crisis
• Management techniques
• Team organization
• Better language and tools
• Standard enactment
⇒ Applying Engineering Approach

29
6. Solutions for the crisis – Tools/Infra

30
6. Solutions for the crisis – Tools/Infra
Integrated Development Environment (IDE)
• Syntax highlighting
• Code completion
• Multi-programming language support
• Compiler & Debugger
• Code refactoring
• Version control
…

VSCode (Microsoft) - Opensourced

31
6. Solutions for the crisis – Tools/Infra
Version control
• Git
‒ Tracking changes
‒ Distributed development
‒ Collaboration

Continuous Integration/Delivery (CI/CD)

• Github actions
• Jenkins
• Travis
• Teamcity

32
6. Solutions for the crisis – Tools/Infra
Container deployment
• Docker
‒ A set of platform as a service products
‒ OS-level virtualization

Manage dependencies
• Conda (for python)
‒ Cross platform
‒ Native virtual environment

33
6. Solutions for the crisis – Principles
• Rigor & Formality (time, budget)
• Separation of concerns (divide & conquer)
• Modularity (decoupling with others, increase the sustainability of code)
• Abstraction (for better insights)
• Anticipation of changes (inevitable, need engineering approach)
• Generality (for various platforms/environments/users)
• Incrementality (from small to big, user feedback)
• Documentation (development process, collaboration)

34
2. Software & Software Engineering
Software
The single most important technology in our world
Impacts on the other technologies
• The creation of new technologies (e.g., genetic engineering, nanotechnology)
• The extension of existing technologies (e.g., telecommunications, transportation, medical)
• The radical change in older technologies (e.g., media, education, military)

36
Software
Delivers the most important product of our time: Information
• Transforms data suitable for specified context
• Manages business information to enhance competitiveness
• Provides gateway to worldwide information (Internet)
• Provides means to acquire information

37
Software
Changed significantly
Due to hardware advancements
• Dramatic increase in performance
• Profound changes in computer architecture
• Vast increase in memory and storage capacity
• Variety of exotic I/O options become available

è Developments of more sophisticated & complex software

è Software industry become dominant factor in economic
è Lone programmer à team of software specialists
38
Software
Unchanged concern about software and its development
Why does software development take so long to finish?
Why is software development cost so high?
Why can’t we find all errors before delivering software to customers?
Why spend so much money and time on maintaining existing software?
Why is it so difficult to measure progress on software development or maintenance?
Why …
è Need to adopt Software Engineering practice

39
Software
Definition:
1. [Programs] Instructions
that provides desired features, function, and performance when executed

2. [Data structures]
that enables the program to adequately manipulate information

3. [Documents] Descriptive information in both hard copy and virtual form

describing operations and use of the program

Does this definition give you a better understandings on what Software is?
èTo accomplish that, let’s examine the characteristics of software

40
Software doesn’t “wear out”
Failure curves Hardware Software

Example) Starcraft
New feature
: LAN Multiplay CPU Throttling
(2002) (2008)

First release Support Korean Remaster: Support Latest OS

(1998) (2005) Win 7/8/10, macOS (2017) 41
Software doesn’t “wear out”
Failure curves Hardware Software

Software is logical rather than physical

: Does not wear out but deteriorate
• During its life, software will undergo change
à likely that errors will be introduced
à causing the failure rate curve to spike!
à slowly, the minimum failure rate level begins to rise. 42
Software is …
A set of items or objects that creates “Configuration”
• Programs, Documents, Data, …

èEntire information required for a program

: development, operation, maintenance
Intangible
Developed or engineered, not manufactured
Sophisticated and complex
Custom build
43
Legacy Software
Developed decades ago
• Supportive to core business functions and indispensable to business
à Characterized by longevity & business criticality

• Continuously modified to meet changes in

ü business requirements and
ü computing platform

• Needs to evolve when it must:

• Be adapted to meet the needs of new computing environments or technology
• Be enhanced to implement new business requirements
• Be enhanced to make it interoperable with other (more modern) systems or databases

44
Software Engineering
Software Engineering: A framework for building software
• A systematic, disciplined and quantifiable approach
in order to economically develop, operate, and maintain software
that is reliable and works efficiently on real machines
à And yet, “systematic, disciplined and quantifiable” approach applied by one team
may be burdensome to another
à We need discipline, but also need adaptability and agility

• Indispensable if we want to achieve good quality software

45
Software Engineering
Force behind the emergence of Software Engineering
• Management’s incompetence in predicting the development cost, time, and effort
• Low quality software
• Increased importance of maintenance
• Developments of hardware and software technologies
• Increased demands on software

46
Software Engineering Layers
1. A quality Focus
: Any engineering approach should be based on the organization’s commitment to quality

2. Process – forms basis for:

: enables rational and timely development of computer software
• Management control of software project
• Establish context in which technical methods are applied
• Work products (e.g., models, docs, data, reports, …) are produced
• Milestones are established
• Quality ensured
• Change managed properly

Software engineering layers 47

Software Engineering Layers
3. Methods
: provides technical how-to’s for building software
(rely on set of basic principles that govern each area of technology)
• Communication, requirement analysis, design modeling, program construction
• Testing and support

4. Tools
: enables rational and timely development of computer software
• (Semi-) Automated support for process/methods
• When tools are integrated
à Info. Created by one tool can be used by another
è Computer-Aided Software Engineering

Software engineering layers 48

Software Process
Process – A collection of:
• Activity: strives to achieve a broad objective,
ü applied regardless of the application domain, size of the project,
ü complexity of the effort, degree of rigor
• Action: encompasses a set of tasks that produce a major work product
• Task: focuses on a small but well-defined objective (that produces a tangible outcome)
è An adaptable approach to pick and choose the appropriate set of work actions and tasks
è Intent: always to deliver software in a timely manner and with sufficient quality

49
Software Process
Generic Process Framework: the foundation of S/E process
: by identifying a small number of framework activities
: applicable to all software projects, regardless of their size or complexity

Five activities – applied repeatedly

ü Communication
: to understand stakeholders’ objectives for the project
: to gather requirements that help define software features and functions
ü Planning
: creates a “map” that helps guide the team (software project plan)
: describing tasks to be conducted, risks, resources, work products, and a schedule
ü Modeling
: a “sketch” of the thing so that you’ll understand the big picture
ü Construction
: code generation and the testing
ü Deployment
: deliver the software to the customer 50
Software Process
Umbrella Activities
: applied throughout project to help software team manage/control
progress, quality, change, and risk

Typical umbrella activities

1. Project tracking and control: assess progress against the project plan
2. Risk management
3. Software quality assurance
4. Technical reviews
5. Measurement
6. Software configuration management
7. Reusability management: defines criteria for work product reuse
8. Work product preparation and production
But, don’t forget the adaptability and agility
51
Software Engineering Practice
The essence of software engineering practice
1. Understand the problem
: communication and analysis
2. Plan a solution
: modeling and software design
3. Carry out the plan
: code generation
4. Examine the result for accuracy
: testing and quality assurance

è These commonsense steps lead to a series of essential questions

52
Software Engineering Practice
1. Understand the Problem
• Who are the stakeholders?

• What are the knowns?

‒ What data, functions, and features are required to properly solve the problem?

• Can the problem be compartmentalized? (Divide & Conquer)

‒ Is it possible to represent smaller problems that may be easier to understand?

• Can the problem be represented graphically?

‒ Can an analysis model be created?

53
Software Engineering Practice
2. Plan the Solution
• Have you seen similar problems before?
‒ Are there patterns that are recognizable in a potential solution?
‒ Is there existing software that implements the required data, functions, and features?

• Has a similar problem been solved?

‒ If so, are elements of the solution reusable?

• Can subproblems be defined?

‒ If so, are solutions readily apparent for the subproblems?

• Can you represent a solution in a manner that leads to

effective implementation?
‒ Can a design model be created?
54
Software Engineering Practice
3. Carry Out the Plan
• Does the solution conform to the plan?

• Is source code traceable to the design model?

• Is each component part of the solution provably correct?

‒ Have the design and code been reviewed?
‒ Have the correctness proofs been applied to the algorithm?

55
Software Engineering Practice
4. Examine the Result
• Is it possible to test each component part of the solution?

• Has a reasonable testing strategy been implemented?

• Does the solution produce results that conform to the data, functions,
and features that are required?

• Has the software been validated against all stakeholder requirements?

56
Software Engineering: General Principles
Seven General Principles from David Hooker
: helps you establish a mind-set for solid software engineering practice

A. The Reason it all exists

: Software system exists to provide value to its users.
: All decisions should be made with this in mind.
: Ask yourself, “Does this add real value to the system?” If the answer is no, don’t do it.

B. KISS (Keep It Simple, Stupid!)

: All design should be as simple as possible, but no simpler.
: Not to say that features should be discarded in the name of simplicity.
: Simple does not mean “quick and dirty”

57
Software Engineering: General Principles
Seven General Principles from David Hooker
: helps you establish a mind-set for solid software engineering practice

C. Maintain the Vision (Project & Product)

: without conceptual integrity, a system might become a patchwork of incompatible designs

D. What You Produce, Others Will Consume

: Always specify, design, document, and implement knowing someone else
will have to understand what you are doing

Please don’t do this. 58

Software Engineering: General Principles
Seven General Principles from David Hooker
: helps you establish a mind-set for solid software engineering practice

E. Be Open to the Future

: Be ready to adapt to changes.
: Always ask “what if,” and prepare for all possible answers.

F. Plan Ahead for Reuse

: Reuse saves time and effort.
: A major benefit of using object-oriented technologies.

https://www.innofied.com/7-ways-make-code-reusable/ 59
Software Engineering: General Principles
Seven General Principles from David Hooker
: helps you establish a mind-set for solid software engineering practice

G. Think!
: Placing clear/complete thought before action almost always produces better results.
: If you do think about something and still do it wrong, it becomes a valuable experience.

60
Software Development Myths
Managers
• Often under pressure: budgets, schedules, quality
• Like a drowning person, a manager often grasps at belief in a software myth
Management myths
• We have all the standard and procedures for software developments.
è Are software practitioners aware of its existence? Is it complete? Is it adaptable? …

• If we get behind schedule, we can hire more programmers to catch up.

è Software development is not a mechanistic process like manufacturing.
è People who were working must spend time educating the newcomers.

• If we decide to outsource the software project to a third party,

we can just relax and let that firm build it.
61
Software Development Myths
Customers
• Believes myths about software because software managers/practitioners do littl
e to correct misinformation.
• Myths lead to false expectations by the customer à dissatisfaction

Customer myths
• A general statements of objectives is sufficient to begin writing programs.
We can fill in the details later.
è An ambiguous “statement of objectives” is a recipe for disaster.

• Software requirements continually change,

but change can be easily accommodated because software is flexible.
è Impact of change varies with the time at which it is introduced.
62
Software Development Myths
Practitioner’s myths
• Once we write the program and get it to work, our job is done.
è Industry data shows that 60-80% of effort is spent after the first delivery.

• Until I get the program running, I have no way of assessing its quality.
è Software reviews are a “quality filter” that have been found to be more effective
than testing for finding certain classes of software defects.

• The only deliverable product for a successful project is the working program.
è A working program is only one part. A variety of work products (e.g., models, docs, plans)
provide a foundation for successful engineering and guidance for software support.

• Software engineering will make us create voluminous and

unnecessary documentation and will invariably slow us down.
è It is not about creating documents, it’s about creating a quality product. 63
Thank you!