Chapter1 An Introduction to Software Engineering Software Engineering

  • Slides: 52
Download presentation
Chapter-1 An Introduction to Software Engineering

Chapter-1 An Introduction to Software Engineering

Software Engineering Ø The economies of dependent on software. ALL developed nations are Ø

Software Engineering Ø The economies of dependent on software. ALL developed nations are Ø More and more systems are software controlled Ø Software engineering is concerned with theories, methods and tools for professional software development.

What is Software ? Software can define as: Ø — — — Instruction –

What is Software ? Software can define as: Ø — — — Instruction – executed provide desire features, function & performance. Data structure – to adequately manipulate operation. Documents – operation and use of the program. 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 e. g. PC software such as Excel or Word. – Bespoke (custom) - developed for a single customer according to their specification.

Hardware vs. Software Hardware ü Manufactured ü wear out ü Built using components ü

Hardware vs. Software Hardware ü Manufactured ü wear out ü Built using components ü Relatively simple Software ü Developed/engineered ü deteriorate ü Custom built ü Complex

What is the difference between software engineering and computer science? Ø Computer science is

What is the difference between software engineering and computer science? Ø Computer science is concerned with theory and fundamentals; software engineering is concerned with the practicalities of developing and delivering useful software. Ø Computer science theories are still insufficient to act as a complete foundation for software engineering

What is the difference between software engineering and system engineering? Ø System engineering is

What is the difference between software engineering and system engineering? Ø System engineering is concerned with all aspects of computer- based systems development including hardware, software and process engineering. Software engineering is part of this process concerned with developing the software infrastructure, control, applications and databases in the system. Ø System engineers are involved in system specification, architectural design, integration and deployment.

What is a software process? Ø A set of activities whose goal is the

What is a software process? Ø 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.

What is a software process model? Ø A simplified representation of a software process,

What is a software process model? Ø A simplified representation of a software process, presented from a specific perspective. Ø Examples of process perspectives are — Workflow perspective - sequence of activities; — Data-flow perspective - information flow; — Role/action perspective - who does what.

What are the costs of software engineering? Ø Roughly 60% of costs are development

What are the costs of software engineering? Ø 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.

Software characteristics Ø Software is developed or engineered; it is not manufactured. Ø Software

Software characteristics Ø Software is developed or engineered; it is not manufactured. Ø Software does not “wear out” but it does deteriorate. Ø Software continues to be custom built, as industry is moving toward component based construction.

Manufacturing vs. Development Ø Once a hardware product has been manufactured, it is difficult

Manufacturing vs. Development Ø Once a hardware product has been manufactured, it is difficult or impossible to modify. In contrast, software products are routinely modified and upgraded. Ø In hardware, hiring more people allows you to accomplish more work, but the same does not necessarily hold true in software engineering. Ø Unlike hardware, software costs are concentrated in design rather than production.

Failure curve for Hardware

Failure curve for Hardware

Failure curve for Software

Failure curve for Software

Software does not “wear out” Ø Ø When a hardware component wears out, it

Software does not “wear out” Ø Ø When a hardware component wears out, it is replaced by a spare part. There are no software spare parts. Every software failure indicates an error in design or in the process through which design was translated into machine executable code. Therefore, software maintenance involves considerably more complexity

Component Based vs. Custom Built Ø Hardware products typically employ many standardized design components.

Component Based vs. Custom Built Ø Hardware products typically employ many standardized design components. Ø Most software continues to be custom built. Ø The software industry does seem to be moving (slowly) toward component-based construction.

Changing nature of software Ø Ø Ø System software Application software Embedded software Web

Changing nature of software Ø Ø Ø System software Application software Embedded software Web applications Artificial intelligence software

Changing nature of software Ø System software is a collection of programs written to

Changing nature of software Ø System software is a collection of programs written to service other programs. Ø Some system software (e. g. , compilers, editors, and file management utilities) process complex, but determinate, information structures. Ø Other systems applications (e. g. , operating system components, drivers, telecommunications processors) process largely indeterminate data

Changing nature of software Ø Real-time Software monitors/analyzes/controls real-world events as they occur is

Changing nature of software Ø Real-time Software monitors/analyzes/controls real-world events as they occur is called real time Ø Include a data gathering component that collects and formats information from an external environment

Changing nature of software Engineering and scientific software Ø Characterized by "number crunching" algorithms.

Changing nature of software Engineering and scientific software Ø Characterized by "number crunching" algorithms. Ø Applications range from astronomy to volcano logy, from automotive stress analysis to space shuttle orbital dynamics, and from molecular biology to automated manufacturing. Ex. Computer Aided Design (CAD), system stimulation etc.

Changing nature of software Embedded Software Ø It resides in read-only memory and is

Changing nature of software Embedded Software Ø It resides in read-only memory and is used to control products and systems Ø Embedded software can perform limited and esoteric functions. Ex. keypad control for a microwave oven.

Changing nature of software Web Applications Ø Web apps can be little more than

Changing nature of software Web Applications Ø Web apps can be little more than a set of linked hypertext files. Ø It evolving into sophisticated computing environments that not only provide standalone features, functions but also integrated with corporate database and business applications.

Changing nature of software Artificial Intelligence software Ø AI software makes use of non-numerical

Changing nature of software Artificial Intelligence software Ø AI software makes use of non-numerical algorithms to solve complex problems that are not amenable to computation or straightforward analysis Ex. Robotics, expert system, game playing, etc.

Software engineering ethics Ø Software engineering involves wider responsibilities than simply the application of

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.

Issues of professional responsibility Ø Confidentiality — Engineers should normally respect the confidentiality of

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

Issues of professional responsibility Ø Intellectual property rights — Engineers should be aware of

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

Assignment -1 ACM/IEEE Code of Ethics

Assignment -1 ACM/IEEE Code of Ethics

SAHER JAWAID KAMRAN 27

SAHER JAWAID KAMRAN 27

Characteristics Of Good Software > > A software product can be judged by what

Characteristics Of Good Software > > A software product can be judged by what it offers and how well it can be used. This software must satisfy on the following grounds: — Operational — Transitional — Maintenance > Well-engineered and crafted software is expected to have the following characteristics: SAHER JAWAID KAMRAN 28

Characteristics of Good Software Operational Ø How well the software works in operations. Ø

Characteristics of Good Software Operational Ø How well the software works in operations. Ø It can be measured on: — Budget — Usability — Efficiency — Correctness — Functionality — Dependability — Security — Safety

Characteristics of Good Software Transitional Ø This aspect is important when the software is

Characteristics of Good Software Transitional Ø This aspect is important when the software is moved from one platform to another: — Portability — Interoperability — Reusability — Adaptability SAHER JAWAID KAMRAN 30

Characteristics of Good Software Maintenance Ø This aspect briefs about how well the software

Characteristics of Good Software Maintenance Ø This aspect briefs about how well the software has the capabilities to maintain itself in the ever-changing environment: — — Modularity Maintainability Flexibility Scalability

Software Evolutions • The process of developing a software product using software engineering principles

Software Evolutions • The process of developing a software product using software engineering principles and methods is referred to as Software Evolution. • This includes the initial development of software and its maintenance and updates, till desired software product is developed, which satisfies the expected requirements ØRe-creating software from scratch and to go oneon-one with the requirement not feasible. • The only feasible and economical solution is to update the existing software so that it matches the latest requirements. SAHER JAWAID KAMRAN 32

Software Evolutions • Requirement gathering process • Creation of a prototype of the intended

Software Evolutions • Requirement gathering process • Creation of a prototype of the intended software • Feedback of the user at the early stage of the software product development. • The users suggest changes, on which several consecutive updates and maintenance keep on changing too. • This process changes to the original software, till the desired software is accomplished. SAHER JAWAID KAMRAN 33

software into three different categories: Software Evolutions Types 1. Static-type (S-type) – Ø This

software into three different categories: Software Evolutions Types 1. Static-type (S-type) – Ø This is a software, which works strictly according to defined specifications and solutions. Ø The solution and the method to achieve it, both are immediately understood before coding. Ø The s-type software is least subjected to changes hence this is the simplest of all. Ø For example, calculator program for mathematical computation. 2. Practical-type (P-type) – Ø This is a software with a collection of procedures. Ø This is defined by exactly what procedures can do. Ø In this software, the specifications can be described but SAHER JAWAID KAMRAN 34 the solution is not obviously instant.

Software Evolutions Types 3. Embedded-type (E-type) – ØThis software works closely as the requirement

Software Evolutions Types 3. Embedded-type (E-type) – ØThis software works closely as the requirement of realworld environment. ØThis software has a high degree of evolution as there are various changes in laws, taxes etc. in the real world situations. ØFor example, Online trading software. SAHER JAWAID KAMRAN 35

E- Types Software Evolution Laws Lehman has given eight laws for E-Type software evolution

E- Types Software Evolution Laws Lehman has given eight laws for E-Type software evolution 1. Continuing change – Ø An E-type software system must continue to adapt to the real world changes, else it becomes progressively less useful. 2. Increasing complexity – ØAs an E-type software system evolves, its complexity tends to increase unless work is done to maintain or reduce it. 3. Conservation of familiarity – ØThe familiarity with the software or the knowledge about how it was developed, why was it developed in that particular manner etc. , must be retained at any cost, to implement the changes in the system. SAHER JAWAID KAMRAN 36

E- Types Software Evolution Laws 4. Continuing growthØIn order for an E-type system intended

E- Types Software Evolution Laws 4. Continuing growthØIn order for an E-type system intended to resolve some business problem, its size of implementing the changes grows according to the lifestyle changes of the business. 5. Reducing/ Declining quality – ØAn E-type software system declines in quality unless rigorously maintained and adapted to a changing operational environment. 6. Feedback systemsØThe E-type software systems constitute multi-loop, multi-level feedback systems and must be treated as such to be successfully modified or improved. SAHER JAWAID KAMRAN 37

E- Types Software Evolution Laws 7. Self-regulation – ØE-type system evolution processes are self-regulating

E- Types Software Evolution Laws 7. Self-regulation – ØE-type system evolution processes are self-regulating with the distribution of product and process measures close to normal. ØThe software exists within a framework of people, management, rules and goals which create a system of checks and balances which shape software evolution 8. Organizational stability – ØThe average effective global activity rate in an evolving E-type system is invariant over the lifetime of the product. ØOver the lifetime of a system the amount of work performed on it is essentially the same as external factors beyond anyone’s control drive the evolution SAHER JAWAID KAMRAN 38

Case Studies Ø A personal insulin pump — An embedded system in an insulin

Case Studies Ø 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.

Insulin pump control system Ø Collects data from a blood sugar sensor and calculates

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

Activity model of the insulin pump

Activity model of the insulin pump

Essential high-level requirements Ø The system shall be available to deliver insulin when required

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.

A patient information system for mental health care Ø A patient information system to

A patient information system for mental health care Ø 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.

MHC-PMS Ø The MHC-PMS (Mental Health Care-Patient Management System) is an information system that

MHC-PMS Ø 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

MHC-PMS goals Ø To generate management information that allows health service managers to assess

MHC-PMS goals Ø 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.

The organization of the MHC-PMS

The organization of the MHC-PMS

MHC-PMS key features Ø Individual care management Clinicians can create records for patients, edit

MHC-PMS key features Ø Individual care management 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 The system monitors the records of patients that are involved in treatment and issues warnings if possible problems are detected Ø 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

MHC-PMS key concerns Ø Privacy It is essential that patient information is confidential and

MHC-PMS key concerns Ø 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

Wilderness weather station Ø The government of a country with large areas of wilderness

Wilderness weather station Ø 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 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.

The weather station’s environment

The weather station’s environment

Weather information system Ø The weather station system This is responsible for collecting weather

Weather information system Ø The weather station system This is responsible for collecting weather data, carrying out some initial data processing and transmitting it to the data management system. Ø The data management and archiving system This 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 This system can communicate by satellite with all wilderness weather stations to monitor the health of these systems and provide reports of problems.

Additional software functionality Ø Monitor the instruments, power and communication hardware and report faults

Additional software functionality Ø 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.