Software Engineering Introduction

Pepper (with credit to both Dr. Chays

and Ian Sommerville book slides)

My Contact Info

My office hours: Office: POST 103 1rst Floor or Post 217 2nd

Floor (or in lab Post 102)Office Hours: Office Hours: Tuesday 12:15

– 1:15Email: pepper@adelphi.edu

My phone: 516-297-5241My Web: www.adelphi.edu/~pe16132 Moodle: ecampus.adelphi.edu

Major Course Objectives

Identify kinds of users, scenarios, and use-cases

for systems presented in class for one system with you as the user!

Experiment with using both iterative (ex:Agile) and plan based (ex: Waterfall) methodologies to design a new small system.

The design documentation - UML diagrams Requirements analysis, select test cases,

design and implement, test, and document. Use design patterns (briefly) Change management – GIT

Assignments

Homework Exercises from the bookProject Exercises

Everyone is assigned to a team A, B, C or D. (3 people per team with one team having only 2)

Teams A & B will design a business system: a patient appointment scheduling system, and serve on the user team for the finch robot game

Teams C & D will design a robotic system: a game using the finch robot, and serve on the user team for the patient appointment system.

Business Finch

User team C & D A & B

Tech team A & B C & D

Textbook

Sommerville, Ian. Software Engineering, New York: Addison-Wesley, 2011 edition 8 or 9 ISBN of edition 9: 0-13-703515-2 OR 978-0-13-703515-1

UML Distilled by Martin Fowler Practical Software Development Techniques. By

Crookshanks, Edward Design Patterns, by Erich Gamma et al Object-Oriented Software Engineering, by

Bernd Bruegge et al Project-Based Software Engineering: An Object-

Oriented Approach, Evelyn Stiller et al The Mythical Man-Month, by Frederick Brooks,

Textbook Case studies

A personal insulin pumpAn 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 stationA data collection system that collects data

about weather conditions in remote areas.

Chapter 1 Introduction 6

Why do we need this course?

Why engineer software?Can’t we just hack at it, until we get

something that works?Many people/companies do this anyway…

Answer: can’t hack it if we care about quality

If a system is not put together in a well-organized manner, the chance for bugs is greater

Another answer: You can’t just hack together a 106 LOC system

Complex systems are impossible to build in an ad-hoc manner

Some more: Budget and Contract

Introduction: software qualitySoftware is often buggyIn critical applications, bugs can lead to

drastic consequencesTherac-25 malfunctions killed or severely

injured several people in 1985-87Ariane 5 launcher crash on 4/6/1996Airbus problemsBanking software failuresHealthcare ExchangeMany more

The main reason for bugs is enormous complexity of software

Need techniques to cope with this complexity

Quality Issues

Software is now an integral part of every facet of our societal infrastructure

Air traffic controlTelecommunicationFinancial infrastructure

Poor quality software menaces the maintenance of that infrastructure

Software is the "Grand Enabler" holding the key to scientific and engineering challenges

Human genome projectSpace explorationWeather prediction

Why isn’t software quality up to snuff?

deliver prototypes"leave it to the marketplace"unsophisticated consumers

don't know what they wanttolerate high failure rates

"the computer is down"misled by "coverups" in banking, finance,

communicationslack of understanding of risks

Year 2000 (Y2K)

Software is everywhere

from Phillips:TV can have 600Kbytes of codeVCR has 265KbytesCell phone has 512KbytesCar radio has 64-256Kbytes

What is software?

CodeVarious design documentsUser manualsDevelopment plans, timelines, and

budgetsMaintenance documentsThe way of producing software

(process)

Desirable qualities of software systems

ReliabilityPerforms the required functions correctlyThe rate of failures is low

MaintainabilityUnderstandabilityChangeabilitySimplicity

ReusabilityThe solution to a problem should be as

general as possibleUser friendlinessEfficiency

Some interesting numbers

About 25% of s/w projects failFailure rate increases as the size of the

project increasesCosts about $100/LOC

Ranges between $10-$600Typical programmer produces about 30

LOCs a dayRanges between 10-100 LOCs

25 faults/KLOCRanges between 3-100 faults/KLOC

Software costs

Development costsgenerally measured in hundreds to

thousands of dollars per delivered LOCmany artifacts associated with a line of

codetesting and analysis is usually 50% of this

costMaintenance costs

2-3 times as much as development

Software Costs

code

reqts and design

testing

15%35%

50%

Development costs

Full lifecycle costs

maintenance

testing

code

reqts/design

Models

Software code is too complex to reason about it directly

Need a higher level representation, called design

Captures only the most important relevant characteristics of the problem

Needs to capture the behavior of the problem accurately

Software code must conform to its design

Software Engineering

Name coined at the NATO Science Committee Conference, October 1968

Engineering-- established, scientifically sound practices that well trained practitioners follow

Software Engineering-- the application of scientific knowledge to the the development and maintenance of software systems

Software-- ALL associated artifacts to assist with the development, operation, validation, and maintenance of programs/software systems

e.g., code, documentation, designs, requirements, user manuals, installation manuals, test cases, test results, bug reports, revision history, make files,...

Industry’s short term focus

"bottom line orientation"emphasis on time to market

not life cyclereturn on investment

startups cannot invest in R&D until product established in marketplace

without the R&D, takes too long for next or improved product

market strategy driven by investors who want impressive short term gains

The nature of software

Software is a complex, intricately interconnected data aggregate

Software Development is the process of creating such a complex product, while continuously assuring that it remains consistent

Software Engineering is the systematic design and management of the software development.

What is novel about software, compared to other fields of engineering?product is unprecedentedly complexapplication horizons expand too fast--

with human demands/imaginationconstruction is human-intensive solutions require unusual rigor extremely malleable--can modify the

product all too easily

Barriers to engineering software

Industry’s short term focusShortage of skilled personnelInadequate investment in R&DPoor technology transfer modelsInsufficient standards

Industry’s short term focus

software housesintensely competitiveoften don't use own technologykeep development cost down, fix later

unsophisticated industrieslack of technical expertiselack of administrative experience

overselling the technology

Software Causing Disaster

http://www.wired.com/software/coolapps/news/2005/11/69355?currentPage=all

Ariane 5 - rocketModule from prior version of code not

needed, but not removedBackup system fails for same reason as

main systemFailure sends directional commands, not

seen as failure code but taken as directionVelocity exceeded maximum for 16 bit

unsigned integer when converted from original 64 bit size

What do we need?

Scientific basisOrganized disciplineR&D strategyTrained professionalsTechnology transfer strategiesQuality control

High-level Goals of Software Engineeringimprove productivity

reduce resourcese.g., time, cost, personnel

improve predictabilityimprove maintainabilityimprove quality

How to increase Software Quality

Treat software as a PRODUCT produced in a systematic way by a PROCESS designed and implemented to achieve explicit quality objectives

Build quality in Define software product formallyDefine software process formallyReason about the product and process

formallyIncorporate validation as integral steps in

the processReuse when appropriateConsider incremental releases

Certification and Licensing?

Currently, software engineering is not one of the 36 engineering professions recognized and licensed in the United States.

48 states prohibit using the term "engineer" without a license

Texas has forced universities to stop MSSE Tennessee prohibits the use of "software

engineering" in business literature and advertising New Jersey considered, but did not pass, a

regulation that would have required licensing of all SW professionals

IEEE/CS & ACM established Commission on Software Engineering in 1993

2009 Software Engineering Consortium NCEES/IEEE Principles and Practices Exam of

Software in 2013 – Not required

Software Process Models

• Software Process Activities• General Model Types• Specific Models

The software processActivities Needed

Specification – defining what the system should do;

Design and implementation (development) – 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.

30Chapter 2 Software Processes

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. (ex: waterfall)

In incremental processes, planning is incremental and it is easier to change the process to reflect changing customer requirements. (ex: Agile, Extreme Programming)

In practice, most practical processes include elements of both plan-driven and agile

There are no right or wrong software processes.

31Chapter 2 Software Processes

No One Best Method

Heterogeneity distributed systems across networks - different

types of computer and mobile devices. Business and social change

Business and society changesEmerging economiesNew technologies

System typesEmbedded – like insulin pump systemInformation / transactional – like medical

recordsData collection – like Wilderness Weather

systemDeveloper skill levelsChapter 1 Introduction 32

#1 Waterfall Method – Plan based with GatesRequirements

System Design

Coding (Implementation)

Integration

Maintenance

reqts. analysis

validation

Unit test

revalidation

System Test

Waterfall Model - RequirementsRequirements-- a complete,consistent

specification of what is neededFeasibility study

Is it technically and financially feasible to build the system?

Requirements elicitation and analysisWhat do the system stakeholders require

or expect from the system?Requirements specification

Defining the requirements in detailRequirements analysis

Checking the validity, completeness and correctness of the requirements

Risk Assessment

The requirements engineering process

35Chapter 2 Software Processes

Waterfall Model - Design

design specifications--a description of how the requirements are to be realized

high-level architectural designlow-level detailed design

design validationtraceability between requirements and

design decisionsinternal consistency

A general model of the design process

37Chapter 2 Software Processes

Waterfall Model - Implement

code--realization of the design in executable instructions

code validation – Unit Test assure coding and documentation

standards have been maintainedinternal consistency

e.g., syntactic analysis, semantic analysis, type checking, interface consistency

consistency between design/requirements and code

Waterfall Model Integrate and System TestIntegrate modulesSystem testing--reveal problems,

demonstrate behavior, assess reliability, evaluate non-functional requirements (e.g., performance, ease of use)

integration testingsystem testingacceptance testingregression testingtesting validation

adequacy of the testcases

Stages of testing

40Chapter 2 Software Processes

Testing phases in a plan-driven software process

41Chapter 2 Software Processes

Waterfall Model - Maintenance

maintenance--the process of modifying existing software while leaving its primary functionality intact

corrective maintenance-- fix problems (20%) adaptive maintenance-- add new functionality/enhance

existing features (30%) perfective maintenance-- improve product (50%)

e.g., performance, maintainability

Regression Test maintenance involves all the previous phases of

the lifecycle

System evolution

43Chapter 2 Software Processes

Is the waterfall model an appropriate process model? Recognizes distinct activities Cheaper design before construction, but .. .

too long a wait before hands on result Business requirements can change before system

goes live

Clear structure facilities multi-group dev, but .. .

Lower level surprises Programmer design changes

Actual processes are more complex numerous iterations among phases not purely top down decomposition into subsystems

many variations of the waterfall model Prototyping, re-engineering, risk reduction

#2 Incremental development

45Chapter 2 Software Processes

• Prototypes• Phases• Agile Cycles• Test Releases

Incremental development benefits

The cost of accommodating changing customer requirements is reduced. (less analysis and doc)

It is easier to get customer feedback on the development work that has been done.

More rapid delivery and deployment of useful software to the customer is possible.

Incremental development problemsThe process is not visible. System structure tends to degrade as

new increments are added. 46Chapter 2 Software Processes

#3 Reuse-oriented software engineering

47Chapter 2 Software Processes

#4 Boehm’s spiral model

48Chapter 2 Software Processes

RISKAdverse

Spiral model sectors

Objective settingSpecific objectives for the phase are identified.

Risk assessment and reductionRisks are assessed and activities put in place

to reduce the key risks.Development and validation

A development model for the system is chosen which can be any of the generic models.

PlanningThe project is reviewed and the next phase of

the spiral is planned.In practice – affects thought, but not used

49Chapter 2 Software Processes

#5: The Rational Unified Process

A modern generic process derived from the work on the UML and associated process.

Brings together aspects of the 3 generic process models discussed previously.

Normally described from 3 perspectives

A dynamic perspective that shows phases over time;

A static perspective that shows process activities;

A practice perspective that suggests good practice. 50Chapter 2 Software

Processes

Phases in the Rational Unified Process

51Chapter 2 Software Processes

High LevelRequirements

RequirementsDesign / Architecture

Detail Design, Code, testDeploy, Train

RUP iteration

In-phase iterationEach phase is iterative with results

developed incrementally.Cross-phase iteration

As shown by the loop in the RUP model, the whole set of phases may be enacted incrementally.

Chapter 2 Software Processes

52

Static workflows in the Rational Unified Process

53Chapter 2 Software Processes

Static workflows in the Rational Unified Process

54Chapter 2 Software Processes

RUP good practice

Develop software iteratively customer priorities / deliver in increments

Manage requirements document initial and changed

requirements.Use component-based architectures

make reusable when possibleVisually model software using UMLVerify software qualityControl changes to software

Change management for requirementsConfiguration management for code55Chapter 2 Software

Processes

Summary - Software Process Models

Plan based – WaterfallIncremental – AgileReuse COTS (commercial off the shelf) Boehm’s Spiral - RiskRational Unified Process – UML

iterative phases

Ethics

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

Ethical principles

Chapter 1 Introduction 61

 

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.

ACM / IEEE-CS Code of Ethics

Ethical dilemmas

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.

Summary

Course StructureWhy Software Engineering is importantSoftware Process ActivitiesSoftware Process Models

Plan based – WaterfallIncremental – AgileReuse COTS (commercial off the shelf) Boehm’s Spiral - RiskRational Unified Process – UML iterative

phasesCode of Ethics