This document provides an overview and outline of a software engineering concepts course taught by Professor Nancy Leveson in Fall 2005. It discusses some of the challenges of software engineering and why it is a difficult problem. The objectives of the course are for students to be able to evaluate software engineering techniques critically and make informed decisions about approaches for projects based on an understanding of past successes and failures. The course will involve readings, summaries, and short assignments but no programming.
AngularJS: A framework to make your life easierWilson Mendes
AngularJS is a javascript framework built and maintained by Google engineers Group, it uses HTML as a "template engine", all this in order to provide a complete solution for the client-side of your application. Also has full compatibility with the most used javascript libraries such as jQuery. It's a new concept for developing web apps client-site.
ABSE and AtomWeaver : A Quantum Leap in Software DevelopmentRui Curado
ABSE is a Model-Driven Software Development methodology that lets you generate the code you want. Capture your own developments skills into easy reusable assets. AtomWeaver is an IDE that implements ABSE, allowing you to save time and be more productive while developing your software project.
FOSDEM 2020 Presentation: Comparing dependency management issues across packa...Fasten Project
This talk "Comparing dependency management issues across packaging ecosystems" was presented by Tom Mens, from Software Engineering Lab, University of Mons, Belgium, at FOSDEM 2020 during the Devroom Session "Dependency Management".
Inauguration lecture Martin Pinzger, University of Klagenfurt, AustriaMartin Pinzger
Slides of my inauguration lecture at the University of Klagenfurt in Austria. In this talk I outline several challenges of evolving software systems and present several ideas and findings from my research to address them. In particular, I show how we can use the history of software projects to identify critical parts of a software system and how we can use visualization techniques to help software engineers to understand the implementation of large, complex software systems including large spreadsheets.
AngularJS: A framework to make your life easierWilson Mendes
AngularJS is a javascript framework built and maintained by Google engineers Group, it uses HTML as a "template engine", all this in order to provide a complete solution for the client-side of your application. Also has full compatibility with the most used javascript libraries such as jQuery. It's a new concept for developing web apps client-site.
ABSE and AtomWeaver : A Quantum Leap in Software DevelopmentRui Curado
ABSE is a Model-Driven Software Development methodology that lets you generate the code you want. Capture your own developments skills into easy reusable assets. AtomWeaver is an IDE that implements ABSE, allowing you to save time and be more productive while developing your software project.
FOSDEM 2020 Presentation: Comparing dependency management issues across packa...Fasten Project
This talk "Comparing dependency management issues across packaging ecosystems" was presented by Tom Mens, from Software Engineering Lab, University of Mons, Belgium, at FOSDEM 2020 during the Devroom Session "Dependency Management".
Inauguration lecture Martin Pinzger, University of Klagenfurt, AustriaMartin Pinzger
Slides of my inauguration lecture at the University of Klagenfurt in Austria. In this talk I outline several challenges of evolving software systems and present several ideas and findings from my research to address them. In particular, I show how we can use the history of software projects to identify critical parts of a software system and how we can use visualization techniques to help software engineers to understand the implementation of large, complex software systems including large spreadsheets.
Comparing dependency issues across software package distributions (FOSDEM 2020)Tom Mens
This talk reports on our findings based on multiple empirical studies that we have conducted to understand different aspects of dependency management and their practical implications. This includes:
* the outdatedness of package dependencies, the transitive impact of such "technical lag", and its relation to the presence of bugs and security vulnerabilities.
* the impact of using either more permissive or more restrictive version contraints on dependencies.
* the virtues and limitations of being compliant to semantic versioning, a common policy to inform dependents whether new releases of software packages introduce possibly backward incompatible changes.
* the impact of specific characteristics, policies and tools used by the packaging ecosystem and its supporting community on all of the above.
The contents of the talk is primarily based on the following peer-reviewed scientific articles:
* What do package dependencies tell us about semantic versioning? Alexandre Decan, Tom Mens. IEEE Transactions on Software Engineering, 2019. https://doi.org/10.1109/TSE.2019.2918315
* An empirical comparison of dependency network evolution in seven software packaging ecosystems. Alexandre Decan, Tom Mens, Philippe Grosjean. Empirical Software Engineering 24(1):381-416, 2019. https://doi.org/10.1007/s10664-017-9589-y
* A formal framework for measuring technical lag in component repositories and its application to npm. Ahmed Zerouali, Tom Mens, Jesus Gonzalez‐Barahona, Alexandre Decan, Eleni Constantinou, Gregorio Robles. Journal of Software: Evolution and Process 31(8), 2019. https://doi.org/10.1002/smr.2157
* On the Impact of Security Vulnerabilities in the npm Package Dependency Network. Alexandre Decan, Tom Mens, Eleni Constantinou. International Conference on Mining Software Repositories, 2018. https://doi.org/10.1145/3196398.3196401
* On the Evolution of Technical Lag in the npm Package Dependency Network. Alexandre Decan, Tom Mens, Eleni Constantinou. International Conference on Software Maintenance and Evolution, 2018. https://doi.org/10.1109/ICSME.2018.00050
Empirically Analysing the Socio-Technical Health of Software Package ManagersTom Mens
Invited presentation at Concordia University (Montreal, Canada) by Eleni Constantinou and Tom Mens on recent research about the socio-technical health issues in software package management ecosystems.
Abstract: The large majority of today’s software is relying on open software software components. Such components are typically distributed through package managers for a wide variety of programming languages, and developed and maintained through online distributed software development services like GitHub. Software component repositories are perceived as software ecosystems that constitute complex and evolving socio-technical software dependency networks. Because of their complexity and evolution, these ecosystems tend to suffer from a wide variety of software health issues that can be either technical or social in nature. Examples of such issues include the ecosystem fragility due to exponential growth and transitive dependencies; the abundance of outdated, unmaintained or obsolete software components; the prolonged presence of unfixed bugs and security vulnerabilities; the abandonment or high turnover of key contributors, suboptimal collaboration between contributors, and many more. This presentation will report on our past and ongoing empirical research that studies such health factors within and across different software packaging ecosystems (such as npm, RubyGems, Cargo, CRAN, CPAN). We provide empirical evidence of some of the health problems, compare their presence across different ecosystems, and suggest ways to reduce their potential impact by providing concrete guidelines and tools. The presented research Is being conducted by researchers of the Software Engineering Lab at the University of Mons in the context of two ongoing projects SECOHealth and SECO-ASSIST, aiming to analyse and improve the health of software ecosystems.
Taking Open Source Security to the Next LevelSBWebinars
Join us for a webinar featuring Forrester VP and Research Director Amy DeMartine to learn more about why open source security has become critical for securing modern applications, the main considerations when evaluating an open source security and license compliance solution and what she sees in store for the future.
Additionally, WhiteSource Senior Director of Product Marketing, Jeff Crum, will discuss recent analysis of the Software Composition Analysis (SCA) market, including takeaways from The Forrester Wave™: Software Composition Analysis, Q2 2019.
Cloud Operations and Analytics: Improving Distributed Systems Reliability usi...Jorge Cardoso
Lecture given at the Technical University of Munich, 12 December 2016, on Cloud Operations and Analytics: Improving Distributed Systems Reliability using Fault Injection.
Maximize Computer Security With Limited RessourcesSecunia
Presentation from Stefan Frei on how patches are an effective method to escape the arms race with cybercriminals. The majority of vulnerabilities have patches ready on the day of disclosure, which means that the right patch strategy is evident to maximize risk reduction.
Taking Open Source Security to the Next LevelWhiteSource
Join us for a webinar featuring Forrester VP and Research Director Amy DeMartine to learn more about why open source security has become critical for securing modern applications, the main considerations when evaluating an open source security and license compliance solution and what she sees in store for the future.
Additionally, WhiteSource Senior Director of Product Marketing, Jeff Crum, will discuss recent analysis of the Software Composition Analysis (SCA) market, including takeaways from The Forrester Wave™: Software Composition Analysis, Q2 2019.
2. Outline
Is There a Problem?
Why is Software Engineering Hard?
Syllabus and Class Description
c
Copyright Nancy Leveson, Sept. 2000
3. Is there a problem?
Examples:
AAS (FAA Advanced Automation System)
FBI CIC
IRS Modernization Program
C−17
Ariane 5
Head of AF Systems Command: ‘‘Software is the
achilles heel of weapons development
7 out of every 10 major weapons development
programs are encountering software problems
and the rate is increasing.
c
Copyright Nancy Leveson, Sept. 1999
4. Some Data (Myths?)
Development of large applications in excess of
5000 function points (~500,000 LOC) is one of
the most risky business undertakings in the
modern world (Capers Jones)
Risks of cancellation or major delays rise rapidly
as overall application size increases (Capers Jones):
65% of large systems (over 1,000,000 LOC) are
cancelled before completion
50% for systems exceeding half million LOC
25 % for those over 100,000 LOC
Failure or cancellation rate of large software
systems is over 20% (Capers Jones)
c
Copyright Nancy Leveson, Sept. 1999
5. More Data (Myths?)
After surveying 8,000 IT projects, Standish Group
reported about 30% of all projects were cancelled.
Average cancelled project in U.S. is about a year
behind schedule and has consumed 200% of
expected budget (Capers Jones).
Work on cancelled projects comprises about 15%
of total U.S. software efforts, amounting to as much
much as $14 billion in 1993 dollars (Capers Jones).
c
Copyright
Nancy Leveson, Sept. 1999
6. And Yet More
Of completed projects, 2/3 experience schedule
delays and cost overruns (Capers Jones)
[bad estimates?]
2/3 of completed projects experience low reliability
and quality problems in first year of deployment
(Jones).
Software errors in fielded systems typically range
from 0.5 to 3.0 occurrences per 1000 lines of code
Bell Labs survey).
Civilian software: at least 100 English words
produced for every source code statement.
Military: about 400 words (Capers Jones)
c
Copyright Nancy Leveson, Sept. 1999
7. Have you ever been on a project where the
software was never finished or used?
What were some of the problems?
c
Copyright Nancy Leveson, Sept. 1999
8.
9. Death March Projects
Feature (scope) creep
Thrashing
Integration problems
Overwriting source code
Constant re−estimation
Redesign and rewriting during test
No documentation of design decisions
Etc.
c
Copyright Nancy Leveson, Sept. 1999
10. Types of Problem Projects (Yourdan)
Mission Impossible
Likely to succeed, happy workers
Ugly
Likely to succeed, unhappy workers
Kamikaze
Unlikely to succeed, happy workers
Suicide
Unlikely to succeed, unhappy workers
c
Copyright Nancy Leveson, Sept. 1999
11. Understanding the Problem
Development Costs ! # $ %
' % ) + -
. / 1
%
2 % ) 4
Planning Coding
5 + 4 +
Test
1/3 planning
1/6 coding
1/4 component test
Development costs are only
1/4 system test the tip of the iceberg.
c
Copyright Nancy Leveson, Sept. 1999
� :
12. Understanding the Problem (2)
Software Maintenance:
20% error correction
20% adaptation
60% enhancements
Most fielded software errors stem
from requirements not code
c
Copyright Nancy Leveson, Sept. 1999
� �
13. Software Evolution (Maintenance)
Belady and Lehman’s Laws:
Software will continually change.
Software will become increasingly
unstructured as it is changed.
Leveson’s Law:
Introducing computers will not reduce
personnel numbers or costs.
c
Copyright Nancy Leveson, Sept. 1999
�
14. Are Things Improving?
Is software improving at a slower rate than hardware?
Software expands to fill the available memory
(Parkinson)
Software is getting slower more rapidly than
hardware becomes faster (Reiser)
Expectations are changing
c
Copyright Nancy Leveson, Sept. 1999
�
16. Why is software engineering hard?
Curse of flexibility
Organized complexity
Intangibility
Lack of historical usage information
Large discrete state spaces
c
Copyright Nancy Leveson, Sept. 1999
�
17. The Computer Revolution
Design separated from physical representation;
design became a completely abstract concept.
General Special
Purpose + Software = Purpose
Machine Machine
Machines that were physically impossible or
impractical to build become feasible.
Design can be changed without retooling or
manufacturing.
Emphasis on steps to be achieved without worrying
about how steps will be realized physically.
c
Copyright Nancy Leveson, Sept. 1999
�
18. The Curse of Flexibility
Software is the resting place of afterthoughts.
No physical constraints
To enforce discipline on design, construction
and modification
To control complexity
So flexible that start working with it before fully
understanding what need to do
The untrained can get partial success.
Scaling up is hard to do
‘‘And they looked upon the software and saw that it
was good. But they just had to add one other feature ...’’
c
Copyright Nancy Leveson, Sept. 1999
20. What is Complexity?
The underlying factor is intellectual manageability
1. A simple system has a small number of unknowns in its
interactions within the system and with its environment.
2. A system becomes intellectually unmanageable when the
level of interactions reaches the point where they cannot
be thoroughly
planned
understood
anticipated
guarded against
c
Copyright Nancy Leveson, Sept. 1999
�
21. Ways to Cope with Complexity
Analytic Reduction (Descartes)
Divide system into distinct parts for analysis purposes.
Examine the parts separately.
Three important assumptions:
1. The division into parts will not distort the
phenomenon being studied.
2. Components are the same when examined singly
as when playing their part in the whole.
3. Principles governing the assembling of the components
into the whole are themselves straightforward.
c
Copyright Nancy Leveson, Sept. 1999
�
22. Ways to Cope with Complexity (con’t.)
Statistics
Treat as a structureless mass with interchangeable parts.
Use Law of Large Numbers to describe behavior in
terms of averages.
Assumes components sufficiently regular and random
in their behavior that they can be studied statistically.
c
Copyright Nancy Leveson, Sept. 1999
:
23. What about software?
Too complex for complete analysis:
Separation into non−interacting subsystems
distorts the results.
The most important properties are emergent.
Too organized for statistics
Too much underlying structure that distorts
the statistics.
Organized Complexity (Weinberg)
c
Copyright Nancy Leveson, Sept. 1999
�
24. Other Factors
Large discrete state spaces
Continuous vs. discrete math
Lacks repetitive structure found in computer circuitry
Cannot test exhaustively
Intangibility
b b
Invisible interfaces
Hard to experiment with and manage
Transient hardware faults vs. software errors
a a
Hard to diagnose problems
c
Copyright Nancy Leveson, Sept. 1999
¡ ¡
25. And One More
No historical usage information
to allow measurement, evaluation, and
improvement of standard designs over time.
Always specially constructed.
Usually doing new things.
c
Copyright
Nancy Leveson, Sept. 1999
27. Class Objectives
2. Students will be able to exercise professional
judgement in selecting an approach for a particular
project based on an understanding of:
How the present state of software practice came about
What was tried in the past
What worked and what did not work
Why
c
Copyright
Nancy Leveson, Sept. 1999
28. Required Background
gh
Assignments
ef
No programming
Reading summaries:
Main ideas or themes
Critical evaluation
Any additional thoughts
Some additional short assignments
c
Copyright Nancy Leveson, Sept. 1999
¡
29. Reading: Both classic papers and new ones
I would like to see computer science teaching set deliberately
in a historical framework.... The absence of this element in
their training causes people to approach every problem from
first principles. They are apt to propose solutions that have
been found wanting in the past. Instead of standing on the
shoulders of their precursors, they try to go it alone.
Maurice Wilkes
c
Copyright
Nancy Leveson, Sept. 1999