Email:

michal.chalamish@gmail.com

Grade consists of:

Introduction
Faculty of Engineering, Bar-Ilan University

70% Test 30% Exercises

Slides are based on slides by Ian Sommerville, by Mira Balaban and by Peter Bunus

Software Engineering , 9th Edition, by Ian Sommerville, Harlow, England: Addison-Wesley (2010). Applying UML and Patterns, 3rd Edition, by C. Larman: Prentice Hall (2005). Object-Oriented Modeling and Design with UML, 2nd Edition, by M. Blaha and J. Rumbaugh: Prentice Hall (2005). A Practical Theory of Programming, 2nd Edition, by E.C.R. Hehner: Springer-Verlag (2004).

Computer programs and associated documentation Software products may be developed for a particular customer or may be developed for a general market Software products may be
Generic - developed to be sold to a range of different customers Bespoke (custom) - developed for a single customer according to their specification

Application of a systematic, disciplined, quantifiable approach to

That form of engineering that applies

a systematic disciplined quantifiable approach the principles of computer science, design, engineering, management, mathematics, psychology, sociology, and other disciplines as necessary and sometimes just plain invention Software Engineering requires the identification of a problem, a computer to carry and execute a software product, and a user environment (composed of people, tools, methodologies, etc.)

structures machines products systems processes

Software engineers should

adopt a systematic and organised approach to their work use appropriate tools and techniques depending on
the problem to be solved the development constraints the resources available

Software engineering deals with the development of high-quality software systems Software engineering is abstract no physical limitations: leads to unlimited complexity Software engineering coined in 1968: within discussion of software crisis

Major projects are meaningfully late Software costs more than predicted Software is unreliable Software is difficult to maintain Poor performance While hardware costs were decreasing, software costs were rising requires techniques to control the complexity of large software systems

Software development is hard! Important to distinguish between easy systems (single developer, single user, experimental use only) and hard systems (multiple developers, multiple users, products) Experience with easy systems is misleading: One person techniques do not scale up Analogy with bridge building: Over a stream = easy, one person job Over a big River ? (the techniques do not scale)

10

Different kinds of problems:

we are used to problems where there are prestated specifications (e.g. ,write a program to find the shortest path...), where it makes sense to talk about the correctness of a solution real world problems: (e.g., software to help people control nuclear reactors): acceptability is defined by user satisfaction (validation vs. verification). Implies evolution is intrinsic

Different kinds of problems:

wicked problems: define and solve concurrently no unique definition or solution always room for improvement in definition and solution new problem, not previously encountered many stakeholders, with different goals

12

13

Complexity
software is more complex for its size than any other human construct; no two parts are alike (e.g. car, microchips,...) science advances by simplifying, while software cannot ignore/simplify details of real world

Changeability
once delivered, most engineered products (hardware, cars, buildings) are rarely changed because the cost to change would be a large fraction of the cost to make. The (unfortunate) perception is that software is cheap to change. And pressure to change comes from successful use, and aging hardware platform

Conformity
among {hardware, software, people, organizations} it is software which is chosen to bend or adapt because it is more malleable, last to arrive on the scene, usually only one developed on site
14

Invisibility
since it has no physical reality, software is not properly visualized with diagrams, etc. in the way in which houses, circuits, etc are
15

The main problem is complexity Many sources, but size is the key:
UNIX contains 4 million lines of code Windows 2000 contains 108 lines of code

Computer Science is concerned with:

Theory Methods Fundamentals

Software Engineering is concerned with:

The practicalities of developing Delivering useful software

Software engineering is about managing this complexity

Computer science theories are currently insufficient to act as a complete underpinning for software engineering, BUT it is a foundation for practical aspects of software engineering
16 17

Software engineering is part of System engineering System Engineering is concerned with all aspects of computer-based systems development including
Hardware Software Process engineering

System engineers are involved in system specification, architectural design, integration and deployment

Systematic ways of organizing teams and tasks so that there is a clear, traceable path from customer requirements to the final product. (e.g.,:Waterfall, Prototyping, Spiral etc.) Processes help organize and coordinate teams, prepare documentation, reduce bugs, manage risk, increase productivity, etc

18

19

Well-defined formal or informal languages and techniques for organizing and communicating arguments and decisions about software. e.g: specification languages (Z, etc), design models (UML, etc) Models help stake-holders communicate: customers with developers, designers and developers, developers and testers etc. If they are formal, they also can help support automation
20

Programs which automate or otherwise support software development tasks: e.g.: Eclipse, Make, CVS, etc. Tools increase productivity, quality and can reduce costs

21

1.

Problem statement
Needs analysis Requirements specification: functional, non-functional

3.

Implementation
Coding Testing:
Module Integration

Documentation
4.

A set of activities whose goal is the development or evolution of software Generic activities in all software processes are:
Specification - what the system should do and its development constraints Development - production of the software system Validation - checking that the software is what the customer wants Evolution - changing the software in response to changing demands
22

2.

Design
Architectural Detailed Communication, Database

Maintenance
Corrective Adaptive Enhancement

An abstraction of a software process, presented from a specific perspective Examples of process perspectives: Workflow perspective
represents inputs, outputs and dependencies

Generic process models: Waterfall Iterative development Formal transformation Integration from reusable components

Data-flow perspective
represents data transformation activities

Role/action perspective
represents the roles/activities of the people involved in software process

24

25

Roughly 60% of costs are development costs, 40% are testing costs. For custom software, evolution costs often exceed development costs Costs vary depending on the type of system being developed and the requirements of system attributes such as performance and system reliability Distribution of costs depends on the development model that is used
26

Software systems which are intended to provide automated support for software process activities, such as requirements analysis, system modelling, debugging and testing Upper-CASE
Tools to support the early process activities of requirements and design

Lower-CASE
Tools to support activities such as programming, debugging and testing

27

The software should deliver the required functionality and performance to the user and should be maintainable, dependable, efficient and usable Maintainability
Software must evolve to meet changing needs

Software engineering in the 21st century faces three key challenges: 1. Heterogeneity
Systems are distributed and include a mix of hardware and software Legacy systems (old valuable systems) must be maintained, updated and integrated into new systems
2.

Dependability
Software must be trustworthy

Efficiency
Software should not make wasteful use of system resources

Delivery
There is an increasing pressure for faster delivery of software

Usability
Software must be usable by the users for which it was designed
28

3.

Trust
Software must be trusted by its nave users
29

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

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 out with their competence

30

31

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 peoples computers. Computer misuse ranges from relatively trivial (game playing on an employers machine) to extremely serious (dissemination of viruses)
32

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
33

1.

Public
Software engineers shall act consistently with the public interest

4.

Judgment
Software engineers shall maintain integrity and independence in their professional judgment

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

5.

Management
Software engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance

3.

Product
Software engineers shall ensure that their products and related modifications meet the highest professional standards possible
34

6.

Profession
Software engineers shall advance the integrity and reputation of the profession consistent with the public interest

35

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

Disagreement in principle with the policies of senior management 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

36

37

A personal insulin pump

An embedded system in an insulin pump used by diabetics to maintain blood glucose control

A mental health case patient management system

A system used to maintain records of people receiving care for mental health problems

A wilderness weather station

A data collection system that collects data about weather conditions in remote areas

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
38 39

Insulin reservoir
Needle assembly Pump Clock

Blood sensor

Analyze sensor reading

Blood sugar

Compute insulin

Blood sensor

Sensor

Controller

Alarm Insulin pump

Control insulin pump

Blood sugar

Display 1

Display 2

Pump data

Compute insulin

Compute insulin

Power supply

40

41

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

A patient information system to support mental health care is a medical information system that maintains information about patients suffering from mental health problems and the treatments that they have received Most mental health patients do not require dedicated hospital treatment but need to attend specialist clinics regularly where they can meet a doctor who has detailed knowledge of their problems To make it easier for patients to attend, these clinics are not just run in hospitals. They may also be held in local medical practices or community centres

42

43

The MHC-PMS (Mental Health Care-Patient Management System) is an information system that is intended for use in clinics. It makes use of a centralized database of patient information but has also been designed to run on a PC, so that it may be accessed and used from sites that do not have secure network connectivity. When the local systems have secure network access, they use patient information in the database but they can download and use local copies of patient records when they are disconnected.

To generate management information that allows health service managers to assess performance against local and government targets To provide medical staff with timely information to support the treatment of patients

44

45

Individual care management

MHC-PMS local MHC-PMS local MHC-PMS local

MHC-PMS server

Clinicians can create records for patients, edit the information in the system, view patient history, etc. The system supports data summaries so that doctors can quickly learn about the key problems and treatments that have been prescribed

Patient monitoring
Patient database

The system monitors the records of patients that are involved in treatment and issues warnings if possible problems are detected

46

47

Administrative reporting
The system generates monthly management reports showing the number of patients treated at each clinic, the number of patients who have entered and left the care system, number of patients sectioned, the drugs prescribed and their costs, etc

Privacy
It is essential that patient information is confidential and is never disclosed to anyone apart from authorised medical staff and the patient themselves

Safety
Some mental illnesses cause patients to become suicidal or a danger to other people. Wherever possible, the system should warn medical staff about potentially suicidal or dangerous patients The system must be available when needed otherwise safety may be compromised and it may be impossible to prescribe the correct medication to patients

48

49

The government of a country with large areas of wilderness decides to deploy several hundred weather stations in remote areas Weather stations collect data from a set of instruments that measure temperature and pressure, sunshine, rainfall, wind speed and wind direction
The weather station includes a number of instruments that measure weather parameters such as the wind speed and direction, the ground and air temperatures, the barometric pressure and the rainfall over a 24-hour period. Each of these instruments is controlled by a software system that takes parameter readings periodically and manages the data collected from the instruments
50

<system> Weather station

<system> Data management and archiving

<system> Station maintenance

51

The weather station system

Collects weather data, carries out some initial data processing and transmits it to the data management system

The data management and archiving system

Collects the data from all of the wilderness weather stations, carries out data processing and analysis and archives the data

The station maintenance system

Can communicate by satellite with all wilderness weather stations to monitor the health of these systems and provide reports of problems

Monitor the instruments, power and communication hardware and report faults to the management system Manage the system power, ensuring that batteries are charged whenever the environmental conditions permit but also that generators are shut down in potentially damaging weather conditions, such as high wind Support dynamic reconfiguration where parts of the software are replaced with new versions and where backup instruments are switched into the system in the event of system failure

52

53

Software engineering is an engineering discipline that is concerned with all aspects of software production Software products consist of developed programs and associated documentation. Essential product attributes are maintainability, dependability, efficiency and usability The software process consists of activities that are involved in developing software products. Basic activities are software specification, development, validation and evolution
54

Methods are organised ways of producing software. They include suggestions for the process to be followed, the notations to be used, rules governing the system descriptions which are produced and design guidelines CASE tools are software systems which are designed to support routine activities in the software process such as editing design diagrams, checking diagram consistency and keeping track of program tests which have been run

55

Software engineers have responsibilities to the engineering profession and society. They should not simply be concerned with technical issues Professional societies publish codes of conduct which set out the standards of behaviour expected of their members Three case studies:
An embedded insulin pump control system A system for mental health care patient management A wilderness weather station
56