Course%20Notes%20Set%201:%20Introduction%20to%20Software%20Engineering

1
Course Notes Set 1Introduction toSoftware
Engineering

• Computer Science and Software Engineering
• Auburn University

2
Desirable Attributes of Software

• Maintainability
• It should be possible to evolve software to meet
  the changing needs of customers.
• Dependability
• Software dependability includes a variety of
  things such as reliability, security and safety.
  Dependable software should not cause physical or
  economic damage in the event of a system failure.

3
Desirable Attributes of Software

• Efficiency
• Software should not waste system resources such
  as memory and processor cycles.
• Usability
• Software should have an appropriate user
  interface and adequate documentation.
• Etc., etc.
• Achieving these qualities in software is hard to
  do!

4
No Silver Bullet
But as we look to the horizon of a decade hence,
we see no silver bullet. There is no single
development, either in technology or management
technique, which by itself promises even one
order of magnitude improvement in productivity,
in reliability, in simplicity. Not only are there
no silver bullets in view, the very nature of
software makes it unlikely there will be
any. Frederick Brooks, The Mythical Man Month
5
Software Characteristics

• Software is a crucial element of our society.
• Software is becoming ubiquitous and invisible.
• Software is both a product and a vehicle for
  delivering a product.
• Software consists of programs, documents, and
  data.
• Software is developed or engineered, not
  manufactured.
• Software is primarily custom-built, not assembled
  from existing components.
• Software deteriorates, but doesnt wear out.
• Software has a chronic affliction Pressman 5th
  Ed.

6
Software Death
Adapted from Figure 1.2, Pressman5E
7
Software Has Changed
Then
Now

• Ran on single processor, usually a mainframe
• Input was linear, sequential
• Output was alphanumeric
• System design dominated by
• Transform systems
• Transaction systems

• Delivered across a network distributed, multiple
  processors client-server.
• Input often from multiple concurrent sources
• Output must meet demands for sophisticated
  visualization
• In addition to functional requirements, must also
  address
• network control
• security
• UI issues
• data/object management

Demarco Weve solved the easy problems first.
The ones that are left are the hard ones.
8
Major Agents of Change

• Compressed time-to-market, tight labor market
• Hardware costs down, software costs up
• Powerful computing in small boxes
• Pervasive networking
• Ubiquity of object technology
• Expectation of sophisticated GUIs
• Inappropriateness of classic software development
  process

Adapted from Toward a Discipline of Software
Engineering, IEEE Software, Vol. 13, No. 6.
9
Problems

• Many critical systems are controlled or
  influenced by legacy software which is difficult
  or impossible to maintain, not understandable, or
  irreplaceable.
• Little data exists on the process of developing
  software.
• Software quality is difficult to define and
  measure.
• Software doesnt have spare parts.
• Software project managers are sometimes far
  removed from software development.
• Software developers are sometimes unaware of
  engineering approaches to developing software.
• Programming as an art versus programming as a
  science.
• Many myths pervade the software development
  culture.

10

• I would try to make some improvements in the
  codes. Many codes or subroutines are more than
  40 years old, and the guys who wrote them are
  either in heaven or hell. Some codes are
  impossible to refine because nobody knows what
  the original programmer was trying to do. To
  figure it out, you have to read the code in
  FORTRAN line by line, to try to understand the
  underlying mathematics picture and these codes
  are hundreds of thousands, even millions of line
  long. Once someone found a bug in the code and
  removed it but then the code wouldnt work. So
  they put the bug back in, even though no one knew
  why the program work that way.
• (by a nuclear scientist)
• - Page 113, My Country
  verse Me, Dr. Wen-ho Lee, Hyperion Pub., 2001

11
Myths

• A general statement of objectives is enough to
  get going. Fill in the details later.
• Project requirements continually change, but
  change can be easily accommodated because
  software is flexible.
• Once a program is developed, tested, and
  delivered, the developers job is done.
• Until a program is running, there is no way to
  assess its quality.
• The only deliverable for a successful project is
  a working program.
• We can always add more programmers if the project
  gets behind.
• All programmers are created equal.

Adapted from public domain SEI course notes by
Carter and Conn
12
What is Software Engineering?
design
CASE
coding
maintenance
structured analysis
KLOC
software quality assurance
testing
dataflow diagrams
project management
requirements
metrics
configuration management
structure charts
13
Software Engineering

• The establishment and use of sound engineering
  principles in order to obtain economically
  software that is reliable and works efficiently
  on real machines. Bauer
• The application of a systematic, disciplined,
  quantifiable approach to the development,
  operation, and maintenance of software that is,
  the application of engineering to software. IEEE
  Standard 610.12-1990

Adapted from Pressman 5th Ed
14
Principles of Software Engineering

• Abstraction
• Analysis and Design Methods and Notations
• Prototyping
• Software Architecture
• Reuse
• Measurement
• Tools and Environments
• Software Process

Adapted from Toward a Discipline of Software
Engineering, IEEE Software, Vol. 13, No. 6.
15
Principles

• Abstraction
• Primary tool for managing complexity
• View a system in terms of layers or a hierarchy
  or abstraction

16
Principles

• Analysis and Design Methods and Notations
• Notations
• A formal way of documenting and communicating
  design decisions
• Issues Cognitive aspects, readership skills, no
  standards
• Methods
• A formal or semi-formal approach to building
  models
• Allows for completeness and consistency checks
  (ideally)

17
Principles

• Prototyping
• Help identify requirements
• Explore feasibility
• Simulate functions to be implemented in hardware

18
Principles

• Software Architecture
• Specifies a system in terms of architectural
  units and how they relate
• Good architecture aids implementation, testing,
  maintenance
• Becoming a sub-discipline (e.g., Garlan and Shaw)

19
Principles

• Reuse
• Make use of commonalities among systems to reuse
  requirements, designs, code, test scripts, etc.
• Reusable components can be a business asset
• Barriers to reuse
• Can be faster to build a small component from
  scratch
• May take extra time to build a reusable component
• Potential adopters may hesitate due to SQA
  concerns
• Liability issues in the event of failure or
  needed updates
• Program understanding issues

20
Principles

• Measurement
• Quantification of attributes of product and
  process
• Critical for assessment and improvement

21
Principles

• Tools and Environments
• Automated Software Engineering
• Vertical v. Horizontal tools
• Critical issues include
• Integration
• repositories

22
Principles

• Software Process
• The organization and discipline of the activities
  of developing software
• Process diversity needed