Transcript Virtual Environments and Human Depth Perception

Software Engineering
Introduction (The Product)
James Gain
([email protected])
Objectives
 To explain the nature of software
 To debunk some widely held myths about software
 To introduce ethical and professional issues and to
explain why they are of concern to software
engineers
 To give an overview of the Software Engineering
practical component
The Nature of Software
 Software is a set of items or objects that form a
“configuration” that includes:
 Programs
 Documents
 Data
 Software products may be developed for a particular
customer (bespoke) or for a general market (generic)
 Software Characteristics:
 Software is developed or engineered, rather than being
manufactured
 Although the industry is moving toward component-based
assembly, most software continues to be custom built.
 Software doesn’t wear out
 Software is complex
The Life of Software
Beyond the Ivory Tower
 Real software projects are not like practical
exercises at university:
 The real world:
 People can be bankrupted and even die (with safety
critical systems) if your software fails
 You must almost always work within a team
 Poor performance means losing your job (not just a
poor mark)
 You are part of a larger environment of customers, team
members, and managemers
 The cost, complexity and time span of software projects
are much larger.
Software Applications
 Approaches to developing software depend on the
application:
 System software
 Real-time software
 Business software
 Engineering and scientific software
 Embedded software
 Personal computer software
 Web-based software
Software Poses Challenges
 The economies of ALL developed nations are
dependent on software
 More and more systems are software controlled
 There are several challenges in the meetings these
demands:
 How do we ensure the quality of the software that we produce?
 How do we meet growing demand and still maintain budget
control?
 How do we upgrade an aging “software plant” (deal with legacy
systems)?
 How do we avoid disastrous time delays?
 How do we successfully institute new software technologies?
Software Costs
 Software costs often dominate system costs. The
costs of software on a PC are often greater than
the hardware cost
 Software costs more to maintain than it does to
develop. For systems with a long life, maintenance
costs may be several times development costs
 Software engineering is concerned with costeffective software development
Software Quality
 The software should deliver the required functionality and
performance to the user and should be maintainable,
dependable and usable
 Maintainability
 Software must evolve to meet changing needs
 Dependability
 Software must be reliable
 Efficiency
 Software should not make wasteful use of system resources
 Usability
 Software must be usable by the target users
 Software engineering is concerned with producing quality
software.
Management Myths
 Managers are under pressure, tend to grasp at
myths.
 Myth: Having books full of standards is enough
Reality: Not unless they are used
 Myth: Having the latest computers is enough
Reality: The right software (e.g. CASE) is more
important than the latest hardware
 Myth: Mongolian Horde approach works
Reality: Adding people to a late software project
makes it later
Customer Myths
 Myths held by customers often lead to false
expectations and, ultimately, dissatisfaction.
 Myth: A general statement of objectives is sufficient
to start coding
Reality: A poor up-front definition is the major cause
of failed software
 Myth: Changing requirements can be easily
accommodated because software is flexible
Reality: Impact depends on the lateness of the
change. Cost – during definition (1x), after release
(60-100x)
The Cost of Change
Practitioner Myths
 Early attitudes to programming have become entrenched.
 Myth: Once the program is written and it works our job is
done
Reality: 60-80% of effort occurs after software is first
delivered
 Myth: The only deliverable work product for a successful
project is the working program
Reality: Software is only one component of a system
 Myth: Software engineering produces piles of documents and
slows everything down.
Reality: Software is about creating quality not documents.
Better quality leads to reduced rework.
Professional and ethical responsibility
 Software engineering involves wider
responsibilities than simply the application of
technical skills
 Software engineers must behave in an honest and
ethically responsible way if they are to be respected
as professionals
 Ethical behaviour is more than simply upholding
the law.
Issues of professional responsibility
 Confidentiality
 Engineers should normally respect the confidentiality of their
employers or clients irrespective of whether or not a formal
confidentiality agreement has been signed.
 Competence
 Engineers should not misrepresent their level of competence. They
should not knowingly accept work which is beyond their
competence.
 Intellectual property rights
 Engineers should be aware of local laws governing the use of
intellectual property such as patents, copyright, etc. They should be
careful to ensure that the intellectual property of employers and
clients is protected.
Issues of professional responsibility
 Computer misuse
 Software engineers should not use their technical skills
to misuse other people’s computers. Computer misuse
ranges from relatively trivial (game playing on an
employer’s machine, say) to extremely serious
(spreading of viruses).
 The professional societies in the US (ACM/IEEE)
have cooperated to produce a code of ethical
practice. Members who join these societies sign up
to this code of conduct.
Ethical dilemmas
 Sometimes ethical principles are in conflict
 Examples:
 Your employer acts in an unethical way and releases a
safety-critical system without finishing the testing of the
system
 Participation in the development of military weapons
systems or nuclear systems
Software Engineering Project
1. User requirements (1 week)
 Produce: 4-10 Use Case narratives and diagrams
 Hand in: Wed 25/7 Return: Mon 30/7
2. Analysis (1.5 weeks)
 Produce: Requirements Specification
 Hand in: Fri 3/8 Return: Tue 7/8
3. Design (2 weeks)
 Produce: Class, Object, Message and Responsibility designs, a
Human Interface design and a test plan
 Hand in: Fri 17/8 Return: Tue 21/8
4. Coding and Testing (5 weeks)
 Produce: code and test results.
 Final Hand in: Mon 1/10.