Software Engineering:
An Introduction
Object-Oriented Software Engineering
CS350
Software Engineering

The application of a systematic,
disciplined, quantifiable approach to
the design, development, operation,
and maintenance of software, and the
study of these approaches
Software Engineering

Emergence as a profession
◦ Early 1980s: Software engineering had
emerged as a bonafide profession

Role of women
◦ 1940s, 1950s, and 1960s: Grace Hopper,
Jamie Fenton and many other unsung
women filled many programming jobs during
the first several decades of software
engineering
◦ Today: fewer women work in software
engineering than in other profesions
◦ Why?
Software Engineering

Processes
◦ Have become a big part of SE
◦ Hailed for their potential to improve software and sharply
criticized for their potential to constrict programmers

Cost of hardware
◦ Computers are now more numerous and more powerful
◦ Market can support large projects to create commercial off
the shelf software
◦ Cheap machines allow each programmer to have a
terminal capable of fairly rapid compilation
◦ Can use techniques such as garbage collection
◦ Organizations use commercial off the shelf software
instead of employing programmers for large custom
software projects
The Pioneering Era
New computers were coming out
almost every year or two
 Software people had to rewrite all their
programs to run on these new
machines
 “Machine room”: Jobs were run by …

◦ Signing up for machine time or by
operational staff
◦ Using punched cards for and waiting for
results to come back
The Pioneering Era
The idea of management by schedule
was non-existent
 Making predictions was almost
impossible
 Computer hardware was applicationspecific
 Scientific and business tasks needed
different machines
 The notion of reuse flourished

1945 to 1965:
The Origins
The term software engineering first
appeared in the late 1950s and early
1960s
 Programmers have always known
about civil, electrical, and computer
engineering and debated what
engineering might mean for software

1965 to 1985:
The Software Crisis
Spurred by the so-called software
crisis of the 1960s, 1970s, and 1980s
 Many software projects ran over
budget and schedule
 Some projects caused property
damage
 A few projects caused loss of life

1965 to 1985:
Cost and Budget Overruns

Example: OS/360 operating system
◦ Decade-long project from the 1960s
eventually produced one of the most
complex software systems at the time
◦ One of the first large (1000 programmers)
software projects
◦ Fred Brooks (The Mythical Man Month)
claims he made a mistake of not
developing a coherent architecture before
starting development
1965 to 1985:
Property Damage
Software defects can cause property
damage
 Poor software security allows hackers
to steal identities, costing time, money,
and reputations

1965 to 1985:
Life and Death
Software defects can kill
 Example: Therac 25 incident

1965 to 1985:
Main source of SE difficulties is a lack
of specialization
 There is a need for a "normal practice"
of software engineering, a prerequisite
if software engineering is to become
an engineering science

(Michael Jackson, "Engineering and Software Engineering" in The
Future of Software Engineering, Springer Verlag 2010; Michael
Jackson, Problem Frames: Analyzing and Structuring Software
Development Problems; Addison-Wesley, 2001)
1985 to 1989:
No Silver Bullet
For decades, solving the software
crisis meant producing software tools
 But the cost of owning/maintaining
software in the 1980s was double
developing the software
 By 1995, half of surveyed
development projects were
operational, but not successful

1985 to 1989:
Software projects
Every new technology and practice
was trumpeted as a silver
 Tools, discipline, formal methods,
process, and professionalism were
touted as silver bullets

1985 to 1989:
Tools
Structured programming
 Object-oriented programming
 CASE tools
 Ada
 Documentation
 Standards

1985 to 1989:
Discipline
Was the software crisis due to the lack
of discipline of programmers?
 Your thoughts?

1985 to 1989:
Formal methods
If formal engineering methodologies
were applied to software development
 Then production of software could bee
as predictable as other branches of
engineering
 Think programs correctness

1985 to 1989:
Process

Capability Maturity Model:
1.
2.
3.
4.
5.
Initial (chaotic, ad hoc, individual heroics) - the
starting point for use of a new or undocumented
repeat process.
Repeatable - the process is at least documented
sufficiently such that repeating the same steps may
be attempted.
Defined - the process is defined/confirmed as a
standard business process, and decomposed to
levels 0, 1 and 2 (the latter being Work
Instructions).
Managed - the process is quantitatively managed in
accordance with agreed-upon metrics.
Optimizing - process management includes
deliberate process optimization/improvement.
1985 to 1989:
Professionalism
Code of ethics
 Licenses
 Professionalism.

1985 to 1989:

No Silver Bullet article (Fred Brooks,
1986)
◦ No individual technology or practice would
ever make a 10-fold improvement in
productivity within 10 years
◦ Eventually, almost everyone accepted that no
silver bullet would ever be found
◦ Does no silver bullet mean that software
engineering failed?
◦ Brooks says, “We will surely make
substantial progress over the next 40 years;
an order of magnitude over 40 years is hardly
magical ...”.
1985 to 1989:

It could be said that there are, in fact, a
range of silver bullets today, including
◦
◦
◦
◦
◦
◦
Lightweight methodologies
Spreadsheet calculators
Customized browsers
In-site search engines
Database report generators
Integrated design-test coding-editors with
memory/differences/undo
◦ Specialty shops
1990 to 1999:
Prominence of the Internet

The rise of the Internet led to a demand for …
◦
◦
◦
◦

Illustrations
Maps
Photographs
Simple animation
Issues:
◦ Widespread network connections led to the growth &
prevention of international computer viruses
◦ Vast proliferation of spam e-mail became a major
design issue in e-mail systems
◦ Keyword-search systems evolved into web-based
search engines
◦ Human natural-language translation systems were
needed
2000 to Present:
Lightweight Methodologies


Expanding demand for software in many
smaller organizations meant the need for
inexpensive software
Rapid-prototyping evolved to entire
lightweight methodologies
◦ Extreme Programming (XP)
Very large software systems still used
heavily-documented methodologies
 Smaller systems had a simpler, faster
alternative approach

Current Trends

Aspects: Help software engineers deal with
quality attributes by providing tools to add or
remove boilerplate code from many areas in
the source code. Aspects describe how all
objects or functions should behave in
particular circumstances. For example,
aspects can add debugging, logging, or
locking control into all objects of particular
types. Researchers are currently working to
understand how to use aspects to design
general-purpose code. Related concepts
include generative programming and
templates.
Current Trends

Agile: Agile software development guides
software development projects that evolve
rapidly with changing expectations and
competitive markets. Proponents of this
method believe that heavy, document-driven
processes (like TickIT, CMM and ISO 9000)
are fading in importance. Some people
believe that companies and agencies export
many of the jobs that can be guided by
heavy-weight processes. Related concepts
include extreme programming, scrum, and
lean software development.
Current Trends

Experimental: experimental software
engineering is a branch of software
engineering interested in devising
experiments on software, in collecting
data from the experiments, and in
devising laws and theories from this
data. Proponents of this method
advocate that the nature of software is
such that we can advance the
knowledge on software through
experiments only.
Current Trends

Model-driven: model driven design
develops textual and graphical models
as primary design artifacts.
Development tools are available that
use model transformation and code
generation to generate well-organized
code fragments that serve as a basis
for producing complete applications.
Current Trends

Software product lines : software
product lines is a systematic way to
produce families of software systems,
instead of creating a succession of
completely individual products. This
method emphasizes extensive,
systematic, formal code reuse, to try
to industrialize the software
development process.
Software engineering today
The profession is trying to define its boundary
and content. The Software Engineering Body
of Knowledge SWEBOK has been tabled as
an ISO standard during 2006 (ISO/IEC TR
19759).
 In 2006, Money Magazine and Salary.com
rated software engineering as the best job in
America in terms of growth, pay, stress
levels, flexibility in hours and working
environment, creativity, and how easy it is to
enter and advance in the field.

Ethical considerations



Software engineering ethics is a large field. In some ways it began as an
unrealistic attempt to define bugs as unethical. More recently it has been defined
as the application of both computer science and engineering philosophy,
principles, and practices to the design and development of software systems. Due
to this engineering focus and the increased use of software in mission critical and
human critical systems, where failure can result in large losses of capital but more
importantly lives such as the Therac-25 system, many ethical codes have been
developed by a number of societies, associations and organizations. These
entities, such as the ACM, IEEE, APEGBC and Institute for Certification of
Computing Professionals (ICCP) have formal codes of ethics. Adherence to the
code of ethics is required as a condition of membership or certification. According
to the ICCP, violation of the code can result in revocation of the certificate. Also, all
engineering societies require conformance to their ethical codes; violation of the
code results in the revocation of the license to practice engineering in the society's
jurisdiction.
These codes of ethics usually have much in common. They typically relate the
need to act consistently with the client's interest, employer's interest, and most
importantly the public's interest. They also outline the need to act with
professionalism and to promote an ethical approach to the profession.
A Software Engineering Code of Ethics has been approved by the ACM and the
IEEE-CS as the standard for teaching and practicing software engineering.
Examples of Codes of Conduct



The following are examples of Codes of conduct for Professional Engineers.
These 2 have been chosen because both jurisdictions have a designation for
Professional Software Engineers.
Association of Professional Engineers and Geo-scientists of British Columbia
(APEGBC): All members in the association's code of Ethics must ensure that
government, the public can rely on BC's professional engineers and Geoscientists to act at all times with fairness, courtesy and good faith to their
employers, employee and customers, and to uphold the truth, honesty and
trustworthiness, and to safe guard human life and the environment. This is just
one of the many ways in which BC’s Professional Engineers and Professional
Geo-scientists maintain their competitive edge in today’s global marketplace.
Association of Professional Engineers, Geo-scientists and Geophysicists of
Alberta(APEGGA): Different with British Columbia, the Alberta Government
granted self governance to engineers, Geo-scientists and geophysicists. All
members in the APEGGA have to accept legal and ethical responsibility for the
work and to hold the interest of the public and society. The APEGGA is a
standards guideline of professional practice to uphold the protection of public
interest for engineering, Geo-scientists and geophysics in Alberta.
Opinions on ethics
Bill Joy argued that "better software" can only enable its privileged
end users, make reality more power-pointy as opposed to more
humane, and ultimately run away with itself so that "the future
doesn't need us." He openly questioned the goals of software
engineering in this respect, asking why it isn't trying to be more
ethical rather than more efficient. In his book Code and Other Laws
of Cyberspace, Lawrence Lessig argues that computer code can
regulate conduct in much the same way as the legal code. Lessig
and Joy urge people to think about the consequences of the
software being developed, not only in a functional way, but also in
how it affects the public and society as a whole.
 Overall, due to the youth of software engineering, many of the
ethical codes and values have been borrowed from other fields,
such as mechanical and civil engineering. However, there are many
ethical questions that even these, much older, disciplines have not
encountered. Questions about the ethical impact of internet
applications, which have a global reach, have never been
encountered until recently and other ethical questions are still to be
encountered. This means the ethical codes for software engineering
are a work in progress, that will change and update as more
questions arise.

Professional responsibilities in
developing software



Who's Responsible?
The developers work with clients and
users to define system requirements.
Once the system is built if any accidents
occur, such as economical harm or other,
who is responsible?
If an independent QA team does
integration testing and does not discover
a critical fault in the system, who is
ethically responsible for damage caused
by that fault?
Responsibilities for Engineering
and Geo-science Software

Developing software is a highly risky
proposition. The software development
process is a complex undertaking consisting
of specifying, designing, implementing, and
testing. Any small mistake or fault will cause
unlimited damage to society. Professional
Members contribute to the success of
software development projects. However,
Association of Professional Engineering and
Geo-science is primarily concerned with their
responsibility for minimizing the risk of failure
and protecting the public interest
Systems Engineering

Systems engineers deal primarily with
the overall system requirements and
design, including hardware and
human issues. They are often
concerned with partitioning
functionality to hardware, software or
human operators. Therefore, the
output of the systems engineering
process serves as an input to the
software engineering process.
Engineering process

The definition, implementation,
assessment, measurement,
management, change, and
improvement of the software life cycle
process itself.