Software Engineering: An Introduction

1
Software EngineeringAn Introduction

• Object-Oriented Software EngineeringCS350

2
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

3
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?

4
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

5
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

6
The Pioneering Era

• The idea of management by schedule was
  non-existent
• Making predictions was almost impossible
• Computer hardware was application-specific
• Scientific and business tasks needed different
  machines
• The notion of reuse flourished

7
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

8
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

9
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

10
1965 to 1985 Property Damage

• Software defects can cause property damage
• Poor software security allows hackers to steal
  identities, costing time, money, and reputations

11
1965 to 1985 Life and Death

• Software defects can kill
• Example Therac 25 incident

12
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)

13
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

14
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

15
1985 to 1989 Tools

• Structured programming
• Object-oriented programming
• CASE tools
• Ada
• Documentation
• Standards

16
1985 to 1989 Discipline

• Was the software crisis due to the lack of
  discipline of programmers?
• Your thoughts?

17
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

18
1985 to 1989 Process

• Capability Maturity Model
• 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.

19
1985 to 1989 Professionalism

• Code of ethics
• Licenses
• Professionalism.

20
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 ....

21
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

22
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

23
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

24
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.

25
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.

26
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.

27
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.

28
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.

29
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.

30
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.

31
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 Geo-scientists 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 BCs Professional Engineers and
  Professional Geo-scientists maintain their
  competitive edge in todays 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.

32
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.

33
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?

34
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

35
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.

36
Engineering process

• The definition, implementation, assessment,
  measurement, management, change, and improvement
  of the software life cycle process itself.