Table of Contents

1. Fundamentals of Software Engineering

2. Agile Methodology
3. Unified Modeling Language
4. Automotive Software Processes
5. Acceptance Testing
6. Deployment and Maintenance

Day 1: SE Principles
What is software?
 The programs and other operating information used by a computer.
 all or part of an information processing system's programs, procedures,
rules, and associated documentation.
 Instructions (computer programs) that when executed provide desired
features, function, and performance; data structures that enable the
programs to adequately manipulate information; and descriptive
information in both hard copy and virtual forms that describes the
operation and use of the program.

Types of Software
 System Software
 Application software
 Engineering/ Scientific Software
 Embedded software
 Web/ mobile application
 Artificial intelligent software
 Cloud computing

Why Software is different from other products?

 Software is a logical system, rather than a physical system element.
 Only indirectly affected by the law of entropy.
 In theory, the software is not susceptible to environmental maladies i.e.,
the software doesn’t wear out.
 Doesn’t follow the bathtub curve.
Why being ideal is impossible?
 High at the start due to:
o Unidentified requirements
o Undiscovered defects
o Unclear mission statements
 Can Stay ideal only if:
o Technology does not change/improve.
o Hardware does not wear out.
o Business does not grow/shrink.
o Requirements do not change.
o Basically, it is only possible if we live in a still world!
 Software does not wear out but does deteriorate.

What is Software Engineering?

 To cope with the changes, understand the problem before developing
solutions.
 Design is vital for high-quality and maintainable systems.
 Effort should be concerted.
 The application of a systematic, disciplined, quantifiable approach to the
development, operation, and maintenance of software - that is, the
application of engineering to software, the study of approaches as in.

Software Process
 is a collection of activities, actions, and tasks performed to create,
develop, or modify software.

Framework
 Communication
 Planning
 Modeling
 Construction
 Deployment

Umbrella activities
 Project tracking and control
 Risk management
 Quality assurance
 Technical reviews
  Measurement
 Config Management
 Reusability management
 Preparation and production

Communication
 Identify stakeholders.
 Communicate and collaborate with customers/stakeholders.
 Gain an understanding of mission objectives.
 Define scope and boundaries.
 Collect requirements.

Planning
 Identify tasks, jobs, and work.
 Identify resources.
 Create a plan/map/guidance.

Modeling
 Analyses requirements
 Model: users, data, data structure, interface, functions, architecture,
components/classes, sequences, security, etc.

Construction
 Apply the design.
 Create environment, machines, server, network, etc.
 Create a database.
 Create middle layers.
 Establish connectivity.
 Create a user interface.

Deployment
 Pre-launch testing: alpha, beta
 Launch/go live.
 Maintenance/Feedback
 Assessment/Audit

General principles
 The reason it all exists: VALUE.
 Keep It Simple
  Maintain the vision.
 What you produce, others will consume.
 Be open to the future.
 Plan for reuse
 Think

The flow
 The flow is as important as the processes.
 Determines how many resources you need to complete the project.
 Each project is unique.
 You may design your own process and develop your own best practices.

The Linear Flows

The Non-linear Flows

Why process models?
 Expected to bring order to the chaos of software development.
 Introduce useful structure to software engineering.
 Provide an effective roadmap.
 Most effective at the state of ‘the edge of chaos’.
 a natural state between order and chaos, a grand compromise between
structure and surprise
 Chaos induces creativity.
 Structure imposes certainty.
 Software engineering is the art of balancing the two.
 Process models help you with
o Impart order in a chaotic world.
o Being adaptable when things change constantly.

The classic Waterfall model.

  Prescriptive, structured, and ordered.
 Requirements fully understood from the start.
 Cannot advance without completing the current process.
 Change is least accommodated.
 Stable, you get what You Want.

The V model.

 Waterfall but V model with more emphasis on testing modules for each
development process.
 Similar problems: changes cause confusion
 Customers don’t know what they want.
 Too many uncertainties at the start
 Customer must have patience.
  Highly susceptible to ‘blocking state.’
 Not suitable for a fast-paced, dynamic world.

The Incremental model

 Customers expect delivery of a series of limited functionalities.
 End Product is the refinement of each increment.
 Recall: the combination of linear and parallel process
 Effective to deliver the ‘core product’ at the earliest time then add other
functionalities when requirements are fully addressed later.

Prototyping Model
  Can be a stand-alone process or a technique implemented within other
process models.
 Work quickly on the general objective > generate a prototype > gradually
refine the requirements.
 Developers use it as a test case to identify requirements.
 Prototyping = rapid communication + quick planning + quick design.
 Prototype is supposed to be ‘the first system’ that developers throw
away at the later stages.
 In most projects, the first system built is barely usable. It may be too
slow, too big, awkward in use, or all three.
 However, some treat prototypes as the ‘basic’ system that slowly
evolves into the actual system.
 Potential problems:
o False expectation > Stakeholders see prototypes as the ‘real’
product, while in reality prototype is held together haphazardly.
There are no measures of quality and maintainability in the
prototype.
o Dirty product > Developers compromise too much to get the
prototype ‘working’, and in the end keep this inefficient,
inappropriate version as the ‘real’ product. Again, no measures of
quality and integrity
 Prototyping is the first instance of evolutionary process models.

The Spiral model

 Spiral = waterfall + prototyping

 Risk-driven, involves multi-stakeholders.
 Cyclic approach to incrementally grow definition and implementation
and reduce risk.
 Anchor points out milestones to ensure stakeholders’ involvement.
 LCO: Life Cycle Objective
 LCA: Life Cycle Architecture
 IOC: Initial Operational Capability
 First circuit produces product specs > prototypes > more sophisticated
versions.
 Ideal for large-scaled systems
 Highly dependent on risk-assessment expertise.
Component-based Development

 Utilized commercial off-the-shelf (COTS).

 Promotes reusability.
 Domain engineering generates component library.
 Available components are evaluated and assessed for compliance.
 Other integration issues assessed.
 A software architecture is designed.
 Components are integrated into the design.
 Comprehensive testing is conducted.
Formal Methods
 Mathematically based.
 Uses propositional algebra, Z language.
 A rigorous Attempt to deal with contradictions, ambiguities, vagueness,
incomplete statements, and mixed levels of abstraction coming from
natural language.
 Used to produce specs and as a verifier.
 Hard to do, time-consuming, and expensive.
 Only developers with proper training can do it.
 Hard to communicate with customers.
 Ideal for safety-critical systems.
The Unified Process
 Use case driven, architecture-centric, iterative, and incremental.
 Inception > use cases
 Elaboration > use case model, analysis model, design model,
implementation model, deployment model.
Day 2: Agile Development

What is agility in Software Engineering?

 Changes are what software development is very much about. Changes in
the software being built, changes to the team members, changes
because of new technology, and changes of all kinds may have an
impact on the product they build or the project that creates the
product. Support for changes should be built-in in everything we do in
software, something we embrace because it is the heart and soul of
software.
 Agility can be applied to any project, not just software engineering.
 Requires a strong supporting environment, i.e., people, technology, and
tools.

Agile process
 Started in 2001 by the Agile Alliance signing the Agile Manifesto
 Individuals and interactions over processes and tools Working software
over comprehensive documentation Customer collaboration over
contract negotiation Responding to change over following a plan.
 Agile process only works on the assumptions that:
o Prediction is hard to do, and changes are inevitable.
o Design and construction should be interleaved.
o Analysis, design, construction, and testing are not predictable.
 Agility = (adaptability + increments) – unpredictability

Agile principles
1. Our highest priority is to satisfy the customer through early and
continuous delivery of valuable software.
2. Working software is the primary measure of progress.
3. Welcome changing requirements, even late in development. Agile
processes harness change for the customer’s competitive advantage.
4. Agile processes promote sustainable development. The sponsors,
developers, and users should be able to maintain a constant pace
indefinitely.
5. Deliver working software frequently, from a couple of weeks to a couple
of months, with a preference for a shorter timescale.
6. Continuous attention to technical excellence and good design enhances
agility.
 7. Businesspeople and developers must work together daily throughout the
project.
8. Simplicity–the art of maximizing the amount of work not done–is
essential.
9. Build projects around motivated individuals. Give them the environment
and support they need and trust them to get the job done.
10. The best architecture, requirements, and designs emerge from self-
organizing teams.
11. The most efficient and effective method of conveying information to and
within a development team is face-to-face conversation.
12.At regular intervals, the team reflects on how to become more effective,
then tunes and adjusts its behavior accordingly.

The Pros and the cons

 Agilists: traditional methodologists are a bunch of stick-in-the-muds
who’d rather produce flawless documentation than a working system
that meets business needs.
 Traditionalists: lightweight, er, agile methodologists are a bunch of
glorified hackers who are going to be in for a heck of a surprise when
they try to scale up their toys into enterprise-wide software.

The XP process:
 Object-oriented
 Delivers functionality only as needed at one time > does not tinker much
on complete end-product.
 Embraces changes even at the later stage of development Work fast,
work smart, work together (managers, customers, developers)
 Principles:
o Communication
o Simplicity
o Feedback
o Respect
o Courage
XP: Planning

 User stories are written.

 Release planning creates the release schedule.
 Make frequent small releases.
 The project is divided into iterations.
 Iteration planning starts each iteration.

XP: Design
 Simplicity > Keep It Simple.
 Choose a system metaphor.
 Use CRC cards for design sessions.
 Create spike solution to reduce risks.
 No functionality is added early.
 Refactor wherever and whenever possible.

XP: Coding
 The customer is always available.
 Code must be written to agreed standards.
 Write the unit test first.
 All production codes are pair programmed.
 Only one pair integrates code at a time.
  Integrate often.
 Set up dedicated integration computer.
 Use collective ownership.

XP: Testing
 All code must have unit tests.
 All code must pass 100% of all unit tests before it can be released.
 When a bug is found, other tests are generated.
 Acceptance tests are run often, and the score is published.

Scrum
 Conceived in the 90s by Jeff Sutherland, further development by
Schwaber and Beedle.
 Name derived from the Rugby’s scrum.
 Framework activities:
o Requirements
o Analysis
o Design
o Evolution
o Delivery

Scrum pillars
  Transparency
o Process and work must be visible to all.
o Decisions made based on the three artifacts.
o Artifacts with low transparency can lead to decisions that
diminish their value and increase risk.
o Transparency enables inspection.
o Inspection without transparency is misleading and wasteful.
 Inspection
o Artifacts and progress must be inspected frequently to detect
problems.
o To help with the inspection are the five events.
o Inspection enables adaptation.
o Inspection without adaptation is pointless.
o Scrum events are designed to provoke change.
 Adaptation
o If the process and product deviate from expectation, they must be
adjusted.
o Adjustment must be made as soon as possible to minimize further
deviation.
o Adaptation becomes more difficult when the people involved are
not empowered or self-managing.
o A scrum team is expected to adapt every time it learns anything
new through inspection.

Scrum Team
 Product Owner
o Product owner is a person, not a committee.
o Responsible for maximizing the value of the product.
o is accountable for effective Product Backlog management,
including:
o Developing and explicitly communicating the Product Goal.
o Creating and clearly communicating Product Backlog items
o Ordering Product Backlog items, and ensuring that the Product
Backlog is transparent, visible, and understood Work may be
delegated, but accountability remains with PO.
 Scrum Master
o is accountable for establishing Scrum, making sure everyone and
everything is in line.
o Strive for effectiveness.
o A true leader serving the team and the larger organization.
  Developer
o Committed to creating a usable increment in each Sprint.
o Skillful, easy to work with, adaptive.
o Accountable for:
 Creating a plan for the Sprint, i.e., the Sprint Backlog.
 Instilling quality by adhering to the Definition of Done.
 Adapting her plan towards the Sprint Goal.
 Holding each other accountable as professionals


Scrum events: The Sprint

 Heartbeat of Scrum
 Fixed length, 1-4 weeks. The new cycle starts immediately after the
conclusion of the previous one.
 Includes: Sprint Planning, Daily Scrum, Sprint Review, Sprint
Retrospective.
 Rules:
o No changes during Sprint to create stability.
o Focused on achieving the Sprint Goal.
o Quality does not decrease.
o Product Backlog is refined as needed.
o Enables predictability < monthly inspection and adaptation.
o Keep the horizon close.
o The shorter a Sprint, the lower the risk.
o Decision-making should be based on past data, not future
unknown.
o Can be cancelled if goals become obsolete.
o Only the Product Owner can cancel.
Scrum events: Sprint Planning
 Product Owner starts with a discussion: which are the most important
Product Backlog items.
 Selected items must be mapped toward the Product Goal.
 Other stakeholders, outside the team, can be invited.

Scrum events
 Inspects progress toward the Sprint Goal
 Adjusts the Sprint Backlog as necessary.
 15-minute event
 3 main questions:
o What did you do yesterday?
o What will you do today?
o Are there any impediments in your way?
 Sprint Review
o Inspects the outcome of the Sprint.
o Determines future adaptations.
o The Team presents their work to key stakeholders.
o Progress referred to Product Goal
o Product Backlog may be adjusted.
o Two-way discussion, 4 hours max
 Sprint Retrospective
o Plans ways to increase the quality and effectiveness of the next
Sprint.
o Inspects individuals, interactions, processes, and goals.
o Results can be added to the Sprint Backlog for the next one.
o Concludes the current Sprint.
o 3 hours max.

Scrum artifact: Product Backlog

 An ordered list of what is needed to improve the product.
 Scrum Team’s work comes from this only.
 Select items that can be done within one Sprint, others may need
refinement.
 Refinement is the act of breaking down and further defining Product
Backlog items into smaller more precise items.
 This is an ongoing activity to add details, such as a description, order,
and size.
  The Developers who will be doing the work are responsible for the
sizing.
 The Product Owner may influence the Developers by helping them
understand and select trade-offs.
 Commits to Product Goal.

Scrum artifact: Sprint Backlog

 Composed of the Sprint Goal (why), the selected Product Backlog items
(what), and the Increment plan(how).
 A plan by and for the Developers
 It is a highly visible, real-time picture of the work that the Developers
plan to accomplish during the Sprint in order to achieve the Sprint Goal
 Consequently, the Sprint Backlog is updated throughout Sprint as more
is learned.
 It should have enough detail that they can inspect their progress in the
Daily Scrum.
 Commits to Sprint Goal.

Scrum artifact: Increment

 A concrete steppingstone toward the Product Goal
 Each Increment is additive to all prior Increments and thoroughly
verified, ensuring that all Increments work together.
 Increment must be usable.
 Multiple Increments may be created within a Sprint.
 The sum of the Increments is presented at the Sprint Review
 An Increment may also be delivered to stakeholders prior to the end of
the Sprint.
 Commits to the Definition of Done, i.e., work cannot be considered part
of an Increment unless it meets the Definition.
Day 3: The Unified Modeling Language

UML
 The Unified Modeling Language (UML) is a graphical language for
visualizing, specifying, constructing, and documenting the artifacts of a
software-intensive system. The UML offers a standard way to write a
system's blueprints, including conceptual things such as business
processes and system functions as well as concrete things such as
programming language statements, database schemas, and reusable
software components.
 UML is a language to specify, not a method < but heavily used/related to
Rational Unified Process, Agile Unified Process, etc.
 One of the primary goals of UML is to advance the state of the industry
by enabling object visual modeling tool interoperability.

Class Activity
UML
 Notation and semantics:
o The User Interaction or Use Case Model - describes the boundary
and interaction between the system and users. Corresponds in
some respects to a requirement model.
o The Interaction or Communication Model - describes how objects
in the system will interact with each other to get work done.
o The State or Dynamic Model - State charts describe the states or
conditions that classes assume over time. Activity graphs describe
the workflows the system will implement.
o The Logical or Class Model - describes the classes and objects
that will make up the system.
o The Physical Component Model - describes the software (and
sometimes hardware components) that make up the system.
o The Physical Deployment Model - describes the physical
architecture and the deployment of components on that hardware
architecture.
Modeling
Day 4: Vehicle Development Process

Principle in Vehicle development

 Subsystems: powertrain, chassis, body, multimedia
 Divide further into secondary subsystems and components.
 Components developed separately but in parallel.
 Integrate subsystems, then the whole system

Development of electronic parts

 Common practice: the V model.
 Need to sync hardware (ECU, sensors, actuators) and software.
 Requires a great measure of interaction between engineers working on
different parts.
 Integration may be a big problem > What about bottle neck?
  Trend: software-based development
 Put more strain on software, than on hardware
 Example: implementation of open/closed-loop control and monitoring
functions of cabin climate
 Provide a higher degree of freedom > not afraid of late changes.
o Adaptive or learning algorithms.
o Safety and diagnostic concepts
o Installation space.
o Manufacturing constraints.

Product lifecycle
 Electronic components are a lot shorter > How does it impact the
production of electronic spare parts?
 Software architecture needs to be standardized.
 Software needs to be hardware independent.
 More frequent updates for on-road vehicles (and ECUs) > flash
programming via offboard diagnostic interface.


Supporting Processes
 The core process must be accompanied.
o Systematic identification and documentation of requirements
o Fault tracking
o Project planning
o Archiving of variant data, etc.
 Typical tasks:
 o Examination of standards and regulations
o Establishing supply-demand line internal and external.
o Intermediate system development, e.g., prototype
o Synchronize point between development steps, between
subsystems, between teams, so on

Supply chain managed: Simultaneous engineering.

 Needs for concurrent handling of development tasks.
 i.e., simultaneous engineering
 Software processes for different functions are run simultaneously > even
at different development sites.
 Requires great coordination > keyword: standardization.

Model-based development
 Use common language, i.e., graphical function model, UML, block
diagrams.
 Models unambiguous
 (Digital) specs clear and ready to execute/simulate.
 Real-life experience gained early through rapid prototyping.
 Use automated code generation for ECUs, if necessary.
 Lab cars enable testing.

Validation and verification

 Keyword: fault detection < carried out after as many individual tasks
 Validation: the process of evaluating a system or a component of the
system to establish that it is satisfactory for its intended application
and that it meets customer expectations
 Accordingly, function validation as a process has the aim of establishing
that the specification meets customer expectations and that it will have
customer acceptance.
 Verification: the process of evaluating a system or a component of a
system to establish that the results of a given development phase meet
the requirements for that phase.
 Accordingly, software verification establishes that an implementation
adequately meets the specifications defined for the respective
development step.
Day 5: User Acceptance Testing

Do you remember this?

Preliminary pointers
 Business requirements must be available.
 Application code should be fully developed.
 Unit testing, integration testing and system testing should be completed
beforehand.
 No showstoppers, high or medium defects in system integration Only
cosmetic error is acceptable before UAT.
 Regression testing should be completed with no major defects.
 All reported defects should be fixed and tested before UAT.
 Traceability matrix for all testing should be completed.
 UAT environment must be ready.

User Acceptance Testing

 UAT is to validate end-to-end business flow.
 Black-box testing
 Who’s involved? Client and end users
 The final piece of the puzzle > The product/software must pass the unit
test, component test, and integration test first.
  Close the gap between client/end-users and developers.
 Gaps: [1] developers applied their own understanding of the users’
needs, and [2] late changes are not captured properly

Steps:
 Planning
o Analyze business requirements < business use cases, process flow
diagrams, business requirement documents, system requirements
specification.
o Create UAT plan < assign test manager, identify resources.
 Preparing test data, scenarios, and environment
o Identify test scenarios and test cases < high-level business
process, look up business cases.
o Prepare test data < best to use live data, don’t forget to scramble.
o Prepare environment < on-board, off-board, development
environment, live environment.
 Executing
o Aim to find priority defects.
o Follow with root cause analysis.
 Confirming business objectives
o All parties agree.
o Exit criteria: No critical defects open.
o Business process works satisfactorily.

Types of test case

 Requirement-based
o Satisfy business requirements.
o Each test case is linked to specific requirements.
o Test case can be written early > remember XP.
 Business process-based
o Must be satisfied or be in line with business processes.
o Double-check against use cases.
o A test case must show how requirements are met, i.e., how the
organization is going to use the system.
 Interface-based
o Focus on interaction between users and the system.
o Interface is the main test subject.
o Test cases are based on data entry and interaction via screen.
o Attributes to test include:
 Robustness
 Ease of use
 Easy to maintain.
 Usability
 Reliability
 Security
Day 6: Maintenance

Process model

 Inventory analysis
o No more than a spreadsheet model.
o Containing information on every active application > size, age,
business criticality, maintainability, supportability.

 Document restructuring
o Problem: Weak documentation
o Creating/recreating documents is costly.
o Create documents start only when changes occur.
o Give emphasis on critical systems/changes.

 Reverse engineering
o Analyze program/system/codebase to create higher-level
abstraction models.
o Design recovery.
o Extract data, architectural, and procedural design information
from an existing program.
 Code restructuring
o Analyze legacy codebase/source code.
 o Identify tangles/knots/unstructured codes.
o Refactor them to easily understand, test, and maintain in the
future > include naming.

 Data restructuring
o Legacy systems usually have a weak data architecture.
o Full-scale reengineering
o Current architecture dissected.
o Necessary data models are defined.
o Data objects and attributes identified.
o Review for quality + restructure

 Forward engineering
o Use information on the legacy system to alter and reconstitute.
o Reengineering must improve the overall value.
o In most cases, reengineering means recreating existing functions
and adding new ones.