Software Engineering

Zulfiqar Ali
UIT University
 Week 2 - Contents
• Software Engineering Ethics
• Introduction to Software Processs
 Software Engineering Ethics
• 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 but involves following a set of principles that are
morally correct.
 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 outwith their competence.
 Issues of Professional Responsibility
• 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.
• 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 (dissemination of viruses).
 ACM/IEEE Code of Ethics
• The professional societies in the US have cooperated to
produce a code of ethical practice.
• Members of these organisations sign up to the code of
practice when they join.
• The Code contains eight Principles related to the
behaviour of and decisions made by professional
software engineers, including practitioners, educators,
managers, supervisors and policy makers, as well as
trainees and students of the profession.
Rationale for the code of ethics
– Computers have a central and growing role in commerce, industry,
government, medicine, education, entertainment and society at large.
Software engineers are those who contribute by direct participation or
by teaching, to the analysis, specification, design, development,
certification, maintenance and testing of software systems.
– Because of their roles in developing software systems, software
engineers have significant opportunities to do good or cause harm, to
enable others to do good or cause harm, or to influence others to do
good or cause harm. To ensure, as much as possible, that their efforts
will be used for good, software engineers must commit themselves to
making software engineering a beneficial and respected profession.
 The ACM/IEEE Code of Ethics
• Software Engineering Code of Ethics and Professional Practice

• ACM/IEEE-CS Joint Task Force on Software Engineering Ethics and Professional Practices

PREAMBLE
• The short version of the code summarizes aspirations at a high level of the abstraction; the clauses
that are included in the full version give examples and details of how these aspirations change the
way we act as software engineering professionals. Without the aspirations, the details can become
legalistic and tedious; without the details, the aspirations can become high sounding but empty;
together, the aspirations and the details form a cohesive code.
• Software engineers shall commit themselves to making the analysis, specification, design,
development, testing and maintenance of software a beneficial and respected profession. In
accordance with their commitment to the health, safety and welfare of the public, software
engineers shall adhere to the following Eight Principles.
 Ethical principles
•
• 1. PUBLIC - Software engineers shall act consistently with the public interest.
• 2. CLIENT AND EMPLOYER - Software engineers shall act in a manner that is in the best interests of their client and
employer consistent with the public interest.
• 3. PRODUCT - Software engineers shall ensure that their products and related modifications meet the highest
professional standards possible.
• 4. JUDGMENT - Software engineers shall maintain integrity and independence in their professional judgment.
• 5. MANAGEMENT - Software engineering managers and leaders shall subscribe to and promote an ethical
approach to the management of software development and maintenance.
• 6. PROFESSION - Software engineers shall advance the integrity and reputation of the profession consistent with
the public interest.
• 7. COLLEAGUES - Software engineers shall be fair to and supportive of their colleagues.
• 8. SELF - Software engineers shall participate in lifelong learning regarding the practice of their profession and
shall promote an ethical approach to the practice of the profession.
 Case Study
• A personal insulin pump
– An embedded system in an insulin pump used by
diabetics to maintain blood glucose control
 Insulin pump control system
• Collects data from a blood sugar sensor and calculates the
amount of insulin required to be injected.
• Calculation based on the rate of change of blood sugar
levels.
• Sends signals to a micro-pump to deliver the correct dose
of insulin.
• Safety-critical system as low blood sugars can lead to brain
malfunctioning, coma and death; high-blood sugar levels
have long-term consequences such as eye and kidney
damage.
Insulin pump hardware architecture
Activity model of the insulin pump
 Essential high-level requirements
• The system shall be available to deliver insulin
when required.
• The system shall perform reliably and deliver the
correct amount of insulin to counteract the
current level of blood sugar.
• The system must therefore be designed and
implemented to ensure that the system always
meets these requirements.
 Software Processes
• A structured set of activities required to develop a software system.
• Many different software processes but all involve:
– Specification – Defining what the system should do;
– Design and implementation – defining the organization of the system
and implementing the system.
– Validation – checking that it does what the customer wants;
– Evolution – changing the system in response to changing customer
needs.
• A software process model is an abstract representation of a
process. It presents a description of a process from some particular
perspective.
 Software Process Descriptions
• When we describe and discuss processes, we usually talk
about the activities in these processes such as specifying a
data model, designing a user interface, etc. and the
ordering of these activities.
• Process descriptions may also include:
– Products, which are the outcomes of a process activity;
– Roles, which reflect the responsibilities of the people involved in
the process;
– Pre- and post-conditions, which are statements that are true
before and after a process activity has been enacted or a
product produced.
 Plan-driven and agile processes
• Plan-driven processes are processes where all of the
process activities are planned in advance and progress
is measured against this plan.
• In agile processes, planning is incremental and it is
easier to change the process to reflect changing
customer requirements.
• In practice, most practical processes include elements
of both plan-driven and agile approaches.
• There are no right or wrong software processes.
 Software Process Models
• The waterfall model
– Plan-driven model. Separate and distinct phases of specification and
development.
• Incremental development
– Specification, development and validation are interleaved. May be
plan-driven or agile.
• Integration and configuration
– The system is assembled from existing configurable components. May
be plan-driven or agile.
• In practice, most large systems are developed using a process that
incorporates elements from all of these models.
The waterfall model
 Waterfall model phases
• There are separate identified phases in the waterfall model:
– Requirements analysis and definition
– System and software design
– Implementation and unit testing
– Integration and system testing
– Operation and maintenance
• The main drawback of the waterfall model is the difficulty
of accommodating change after the process is underway. In
principle, a phase has to be complete before moving onto
the next phase.
 Waterfall model problems
• Inflexible partitioning of the project into distinct stages
makes it difficult to respond to changing customer
requirements.
– Therefore, this model is only appropriate when the
requirements are well-understood and changes will be fairly
limited during the design process.
– Few business systems have stable requirements.
• The waterfall model is mostly used for large systems
engineering projects where a system is developed at
several sites.
– In those circumstances, the plan-driven nature of the waterfall
model helps coordinate the work.
Incremental development
Incremental development benefits
• The cost of accommodating changing customer requirements is
reduced.
– The amount of analysis and documentation that has to be redone is
much less than is required with the waterfall model.
• It is easier to get customer feedback on the development work that
has been done.
– Customers can comment on demonstrations of the software and see
how much has been implemented.
• More rapid delivery and deployment of useful software to the
customer is possible.
– Customers are able to use and gain value from the software earlier
than is possible with a waterfall process.
 Incremental development problems
• The process is not visible.
– Managers need regular deliverables to measure progress. If
systems are developed quickly, it is not cost-effective to produce
documents that reflect every version of the system.
• System structure tends to degrade as new increments are
added.
– Unless time and money is spent on refactoring to improve the
software, regular change tends to corrupt its structure.
Incorporating further software changes becomes increasingly
difficult and costly.
 Integration and configuration
• Based on software reuse where systems are integrated
from existing components or application systems
(sometimes called COTS -Commercial-off-the-shelf)
systems).
• Reused elements may be configured to adapt their
behaviour and functionality to a user’s requirements
• Reuse is now the standard approach for building many
types of business system
 Types of reusable software
• Stand-alone application systems (sometimes called
COTS) that are configured for use in a particular
environment.
• Collections of objects that are developed as a package
to be integrated with a component framework such as
.NET or J2EE.
• Web services that are developed according to service
standards and which are available for remote
invocation.
Reuse-oriented software engineering
 Key process stages
• Requirements specification
• Software discovery and evaluation
• Requirements refinement
• Application system configuration
• Component adaptation and integration
 Advantages & Disadvantages
• Reduced costs and risks as less software is
developed from scratch
• Faster delivery and deployment of system
• But requirements compromises are inevitable so
system may not meet real needs of users
• Loss of control over evolution of reused system
elements
 Process activities
• Real software processes are inter-leaved sequences of
technical, collaborative and managerial activities with the
overall goal of specifying, designing, implementing and
testing a software system.
• The four basic process activities of specification,
development, validation and evolution are organized
differently in different development processes.
• For example, in the waterfall model, they are organized in
sequence, whereas in incremental development they are
interleaved.
The requirements engineering process
 Software specification
• The process of establishing what services are required and
the constraints on the system’s operation and
development.
• Requirements engineering process
– Requirements elicitation and analysis
• What do the system stakeholders require or expect from the system?
– Requirements specification
• Defining the requirements in detail
– Requirements validation
• Checking the validity of the requirements
 Software design and implementation
• The process of converting the system specification into
an executable system.
• Software design
– Design a software structure that realises the specification;
• Implementation
– Translate this structure into an executable program;
• The activities of design and implementation are closely
related and may be inter-leaved.
A general model of the design process
 Design activities
• Architectural design, where you identify the overall
structure of the system, the principal components
(subsystems or modules), their relationships and how they
are distributed.
• Database design, where you design the system data
structures and how these are to be represented in a
database.
• Interface design, where you define the interfaces between
system components.
• Component selection and design, where you search for
reusable components. If unavailable, you design how it will
operate.
 System implementation
• The software is implemented either by developing a
program or programs or by configuring an application
system.
• Design and implementation are interleaved activities
for most types of software system.
• Programming is an individual activity with no standard
process.
• Debugging is the activity of finding program faults and
correcting these faults.
 Software validation
• Verification and validation (V & V) is intended to show
that a system conforms to its specification and meets
the requirements of the system customer.
• Involves checking and review processes and system
testing.
• System testing involves executing the system with test
cases that are derived from the specification of the real
data to be processed by the system.
• Testing is the most commonly used V & V activity.
Stages of Testing
 Testing stages
• Component testing
– Individual components are tested independently;
– Components may be functions or objects or coherent groupings
of these entities.
• System testing
– Testing of the system as a whole. Testing of emergent properties
is particularly important.
• Customer testing
– Testing with customer data to check that the system meets the
customer’s needs.
Testing phases in a plan-driven
software process (V-model)
 Software evolution
• Software is inherently flexible and can change.
• As requirements change through changing business
circumstances, the software that supports the business
must also evolve and change.
• Although there has been a demarcation between
development and evolution (maintenance) this is
increasingly irrelevant as fewer and fewer systems are
completely new.
System evolution
 Weekly Task
• Suggest the most appropriate generic software process model
that might be used as a basis for managing the development
of the following systems. Explain your answer according to the
type of system being developed:
– A system to control antilock breaking in a car
– A virtual reality system to support software maintenance
– A university accounting system that replaces an existing system
 References
• Software engineering : Ian Sommerville 10th edition