The journey of UNISON Cost Engineering in the field of automotive software cost estimation started in 2018. The expectation is that in 2030 the cost of software will be 50% of the total production cost of a car. To help the OEM get a proper understanding of the software development cost they need to use some form of size measurement to compare, challenge and control the cost of software development by the software vendors.

1. A Software Cost Estimation Approach for the Automotive Industry
Estimate with Confidence.

2. Background
 UNISON Cost Engineering teams, formerly known as PRICE Systems, can be described as the Cost
Engineering pioneers in aeronautics, space & defense, providing innovation since 1975
 We address Hardware, Software, System Engineering and Assembly/Integration/Tests for
Development, Production & Life Cycle phases
 Our solutions are sets of mathematical equations designed using actual data coming from past
real finished projects
 For Software we have 10,000 ish projects in our validation databases and are a partner of
organizations like ISBSG
 We started working with Automotive OEMs in 2018 (at JLR request)
 We first had to validate on the field, the relevance of our approach/models and its added value
which we did on infotainment, braking, and instrument cluster kind of applications

3. Object of this presentation
 Share our main findings / challenges in estimating Software in the Automotive domain:
 Share what could be an approach for SW Cost estimation in Automotive

4. Importance of SW in Automotive
Software has been a key component in modern cars for the last couple of decades. And for nearly
all that time the suppliers of the software and solutions have had a competitive advantage over the
manufacturers
Any data maintained by the manufacturers, which is incredibly limited, would contain this
competitive bias
Widely understood that current practices and processes
to control software costs have not developed at the
same rate as the development itself
Expected that by 2030 the cost of software will account
for 50% of the production costs of a car
© Statista 2020– Used with Permission
https://www.statista.com/statistics/277931/automotive-electronics-cost-as-a-share-of-total-car-cost-
worldwide/

5. We have been working with a number of companies for over 4 years to start to meet this challenge
and we have learned a lot:
 Software is funded as part of development cost, there is not the same focus on cost as there
is for piece parts
 Software is purchased against standards and high-level requirements there is no common
method of specification
 Different teams have different methods of determining and agreeing cost with the suppliers,
generally developed with the supplier and not based on independent information
 There is no dedicated cost engineering support in software engineering and nobody has the
estimating knowledge in their heads
 There is no real structured approach to gathering and sharing knowledge
 There is a general unspoken belief that you cannot estimate software cost so why try
Software in Automotive - High level findings

6. SW Cost Engineering in Automotive
 Software estimation is the single biggest challenge to Cost Engineering in the Automotive sector
 We are where we were with Hardware 30+ years ago and the challenges are the same
 In order to produce a credible software cost estimate you need several things.
 A clear understanding of what the software is intended to do
 Reliable defendable software development knowledge
 Reliable cost rates
 This information together supports the creation of a should cost that supports negotiation with
the supplier

7. Automotive Software Suppliers
 The big word is AGILE
 Moving towards SAFe and DevOps

8.  So far, throughout all my interventions, the AGILE “collaboration” & “interactions”, iow
transparency & visibility, are dramatically missing
What I’ve seen of agile development in automotive

9. What I’ve seen of agile development in automotive
 Agile is used by suppliers (sometimes by OEM engineers) to stay away from « traditional » / « old
fashioned » practices
- “No longer need to estimate - Everything is for the best since you’ll get the best you could possibly expect”
- “Of course, we do measure”:
 With Story Points
 With « subscription » Points
 Even though all these fancy size units are very specific to every single project and prevent any attempt to compare and
perform cross project analysis
 But many challenges are nevertheless valid:

10. Last but not least, Automotive OEMs are facing a big shift
in their System architectures
 Move from suppliers in charge of ECUs as a whole
- The hardware
- The basic software
- The application software, dedicated to a single function (open door, manage rooftop, …)
 Towards a centralized architecture, integrating multiple piece of application software coming from
different suppliers, sharing the same resources (one big ECU and significantly more complex and
wide basic software)

11. Need to understand, evaluate, control, compare
 In this context, the need for OEMs to get a proper understanding of what is happening is key
 More largely, software must be sized!
- From EPICS, from Features, from Stories
- In a way which makes possible to compare, challenge, control
 There are standardized functional sizing techniques:
- COSMIC
- IFPUG
- NESMA
 Effort required to deal with software must be presented / structured in a comprehensive way,
and justified based on:
- A clear and understandable breakdown in activity / resource
- The work to be done on the sized software
 This is valid whether you have the requirement before awarding the contract or starting a PI, or
“a posteriori” (at the end of a PI for example) in order to assess the productivity / velocity of a
development team

12. First Track we are pursuing at this very moment - Sizing
 The first cornerstone of our approach is to deploy on the field a Function Point sizing culture
 Just for historical reasons, we (at UCE) are more familiar with IFPUG Function Points
 One of the experts in IFPUG, David Seaver, used to work at PRICE Systems
 And introduced me to Function Points
 He developed a FAST Function Points approach in order to speed up the counting process and be
more « understandable » (or adopted in a quicker way) by not expert users
- This was in line with Simplified Function Points and Early & Quick Function Points approaches

13. New technique based on key words
 Key words – David Seaver

14. New technique based on key words
 Key words – as I use them
 Key words – in CADENCE App
- Kevin McKeel - https://logapps.com/

15. Second Track we are pursuing at this very moment –
Addressing automotive specific characteristics
 Multiplicity, complexity and imbrication of layers:
- MCAL, Bootloader, Drivers, …
- Basic SoftWare, Hypervisor
- Multiple Autosar (Classic, Adaptive) implementations and Operating Systems (from Linux to specific)
- RTE layer
- Before getting to application modules
 Still requires sizing and complexity assessment in order to derive “configuration & tailoring” effort
as well as “integration & test”
 The increasing involvement and usage of highly complex algorithms (to deal with cameras, radars,
and connected sensors) – more and more often relying on deep learning kind of technology
 The increasing usage of automatic tools (from code generation to testing)
 Very specific activities to collect data from the field/road for validations (at different levels)

16. Wrap-up
 We recognise that the automotive industry faces a tough
challenge (wrt Software)
 Our approach has simplified the problem
 Our solution has delivered transparent, evidence-based
data to provide leverage in supplier negotiations

17. Any question?