itnp23: foundations of information technology · 2016-10-05 · itnp23: foundations of information...

ITNP23: Foundations of Information Technology

Software Engineering

Introduction

•  Define software engineering and motivations •  Determine some of the difficulties associated with developing and maintaining

large software projects •  Examine common methods and tools associated with software engineering •  Identify the standard phases in a project

•  Compare and contrast heavyweight and lightweight models of SE

Computer Science: An Overview, J. G. Brookshear, Chapter 7

2 Software Engineering (Autumn, 2013)

Software Disasters “To err is human, but to really foul things up you need a computer.”

-- Paul Ehrlich

System Year Disaster Effect/cause

Ariane 5 unmanned rocket

1996 Destruction of rocket and cargo Overflow error converting a velocity reading from 64-bits to 16-bits

Wall Street 1987 Market crashed costing $500 billion in a single day

Computer trading programs flooded the market with sell orders

Therac-25 radiation therapy machine

1985 A race condition lead it to deliver lethal radiation doses to its patients. The root cause: poor software engineering practices

Three people killed and three others were critically injured

3 Software Engineering (Autumn, 2013)

Software Engineering �  The discipline concerned with all aspects of developing software products that can

be sold to customers

�  Software products may consist of a number of programs, documentation, configuration data, and contextual systems such as product websites and services to download patches

�  Software engineers attempt to use theories, methods and tools to develop software products and solve problems within organisational and financial constraints

�  They are involved in all aspects of development (technical ones as well as others such as project management)

4 Software Engineering (Autumn, 2013)

Some Software Development Difficulties

�  Complexity �  A large number of components tend to be used in software systems. �  Each component may be in one of many states. �  The components tend to interact non-linearly, and they run in digital computers

which are themselves highly complex.

�  Intangibility and Modifiability �  Software is not physical and does not lead well to visualisation �  Software is easily modifiable but it is notoriously difficult to determine the effects of

change

�  Human resource management �  Software may be developed by a large group of people �  Challenges to do with communication, ability, perspective, assumptions, goals, etc. �  We revisit this in just a moment

5 Software Engineering (Autumn, 2013)

�  Lack of standards and reliable metrics �  Mechanical engineers have tried and tested procedures and can measure the wear and

tear of the components they work with; but no such luxury is afforded the software engineer

�  The business of software �  Rapid technological changes lead to ever greater expectations and scope �  Ever shortening deadlines of delivery �  Software engineering techniques take time to learn and apply

6

Some Software Development Difficulties

Software Engineering (Autumn, 2013)

7

But is it “Engineering” ? �  Two definitions of Software Engineering quoted by Pressman

�  “the establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines”

�  “the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software”

�  These definitions seem to rely too much on the word engineering �  a discipline ensuring that structures won’t fall down …

�  So for example - “Engineering” doesn’t prevent the cost of a project escalating by factors of ten

�  The management dominates …

7 Software Engineering (Autumn, 2013) 8

People �  These points make it clear that the central problem is the co­ordination of

people �  so it’s not “engineering” in the slide-rule sense: it’s “management”

�  Brooks’ rule of thumb: only about one-sixth of software development is coding �  but he was his own customer

�  When we add (as is usual) an external customer, the management challenge becomes much greater �  we are no longer managing downwards �  we are co-ordinating with superiors (because they’re paying) �  with people whose backgrounds and assumption differ from ours in ways

that are hard to predict

8 Software Engineering (Autumn, 2013)

9

Scaling up: early experiences �  A software product is not just a big program:

�  we cannot just scale up from figures about the numbers of statements that a programmer can produce in a day

�  Brooks’ project, OS/360 �  “at the peak over 1000 people were working on it … from 1963 through

1966 probably 5000 man-years went into its design, construction and documentation”

�  Programmers are not bees �  they don’t automatically know what to do

�  Brooks’ most famous chapter: “The Mythical Man-Month” �  Brooks’ Law: Adding manpower to a late software project makes it later

9 Software Engineering (Autumn, 2013)

SE Methods and Tools �  Project phases �  Modelling

�  Documentation

�  Development

�  ...

�  Tools �  Computer-Aided Software Engineering (CASE) tools

�  Modelling packages, model checkers, test suites, debuggers �  Integrated Development Environments (IDE)

�  Development Approaches �  Grouping the phases �  Organising the people doing the work

10 Software Engineering (Autumn, 2013)

Project Phases �  Each phase

�  Is defined, documented and agreed �  Treated as a milestone with deliverables �  Different methodologies identify different stages

�  Phases (popular Waterfall model):

1.  Analysis 2.  Design 3.  Implement 4.  Test 5.  Maintenance 6.  ...

Brooks’ timings rules of thumb 1/3 of the development schedule 1/6 of the development schedule 1/2 of the development schedule

11 Software Engineering (Autumn, 2013)

1. Analysis Phase �  Determines:

�  What the system should do �  Who is the product being sold to?

�  The market �  A client

�  Who will use the software?

�  Activities a)  Problem definition b)  Feasibility study c)  Requirements elicitation

12 Software Engineering (Autumn, 2013)

1.a Problem definition �  Input: Initial description of client�s current situation/problem

�  Purpose: �  Determine the objectives of new system �  Define the scope of project and the key stakeholders involved �  Sketch out possible preliminary solutions

�  Outcome: �  Report for the next stage (Feasibility Study)

13 Software Engineering (Autumn, 2013)

1.b Feasibility study

�  Input: The problem definition, the business case, and an outline of the system

�  Purpose: �  Determine whether a working system (in the client environment)

be produced given cost, schedule and technological constraints �  Decide whether or not the development

should go ahead �  If so, define what changes to the scope, schedule, and budget are

necessary

�  Outcome: �  Report for the next stage (Requirements Elicitation/Engineering)

14 Software Engineering (Autumn, 2013)

�  Terminology: often referred to as Requirements Engineering

�  Input: The problem definition report and the feasibility study

�  Purpose: Work with stakeholders to specify: �  the current physical model: what they do now, physically �  the current logical model: what they do now, conceptually �  The required logical model: requirements of the new system

�  Outcome: �  A specification

1.c Requirements Elicitation

15 Software Engineering (Autumn, 2013)

2. Design Phase

�  How the system will accomplish its goals (large task/issue!)

�  Produce a project for your system suitable to drive actual implementation and other phases

�  Alternative designs may be considered (and presented to clients at different prices)

�  The design can impact: �  Scope �  Performance �  Safety and security �  Maintainability

16 Software Engineering (Autumn, 2013)

3. Implementation

�  Actually code programs (finally!)

�  Procure hardware

�  Develop databases and harvest data

�  Other specialised tasks such as train neural nets

�  Write unit tests

�  Put the system together

�  Write administration and user documentation

17 Software Engineering (Autumn, 2013)

4. Testing

�  Unit tests

�  Integration tests

�  Debugging, fixing and patching

�  Release testing �  Alpha and beta versions

�  Performance testing

�  Interface testing

�  Acceptance testing

18 Software Engineering (Autumn, 2013)

5. Maintenance

�  System maintenance is inevitable

�  Environmental changes bring about new requirements and expose invalid assumptions

�  Bugs may be discovered that were missed during testing and need to be fixed

�  Software systems evolve

�  They tend to get even more complex

19 Software Engineering (Autumn, 2013)

Summary so far �  Software engineering involves all aspects of developing software products �  Software is complex, abstract, intangible, evolving...

�  Software engineers use common methods and tools to help produce quality products

�  Standard phases are used in projects, although the ordering of these may differ (as we�ll see in the next lecture)

20 Software Engineering (Autumn, 2013)

SE approaches

�  We looked at general SE procedures and phases

�  Now: SE approaches to managing these, including:

�  Heavyweight �  Lightweight (agile) �  Cowboy coding �  Open Source

21 Software Engineering (Autumn, 2013)

Heavyweight Approaches �  Traditional approaches to SE, such

�  Managerial and contractual benefits �  Inflexible - do not adapt (easily) to changes

�  Each of the phases is clearly established and completed before moving on to the next one �  Heavily reliant on documentation

�  Examples �  Waterfall �  Prototyping �  Incremental �  Spiral

22

�  These perhaps come from the “engineering” metaphor �  where design is cheap (and well understood) (10% of a

bridge’s cost?) �  but construction is dear (and can be routine) �  … so getting the design (almost) exactly right is both

possible and highly desirable.

Software Engineering (Autumn, 2013)

The Waterfall Approach �  The earliest published approach (1970) �  Attempts to limit variance and risk in large projects by “cascading” from one

completed phase to the next

�  Documents are approved before the subsequent phases can begin

�  Fits well with other forms of engineering, especially when the requirements are well-known, but it is inflexible to change

Analysis

Design

Implementation

Testing

Operation and Maintenance

23 Software Engineering (Autumn, 2013)

Prototyping �  Develop an experimental (prototypal) system �  The system is used to help the customer and engineers understand and validate the

requirements; not meant for customer delivery

�  Throw-away prototyping: System is intended to be thrown away, so performance and reliability are of little concern

�  Evolutionary prototyping: The prototype evolves into the delivered product

�  Issues �  Customers may not understand the prototype limitations (why should they

bother spending more time and money if they have a working version?) �  Shortcuts made in prototype get built-in to final system

24 Software Engineering (Autumn, 2013)

Incremental Approach �  The Incremental model is a combination of the classic model and iteration �  A number of staggered passes through the classic cycle are planned

�  Each pass delivers a defined increment of the system

�  Prioritise features

�  Customers can start to use the system after the delivery of the first increment

�  Lower risk of complete failure

�  Problems with component reuse and integration

25

Analysis Design Code Test

Analysis Design Code Test

Analysis Design Code Test

Simple

Feature rich

Software Engineering (Autumn, 2013)

The Spiral Model

26

�  This approach explicitly identifies and attempts to reduce risk

�  Each phase is represented as a loop in a spiral

�  The inner loop is feasibility study for instance

�  Different approaches may be used for each loop

�  Each loop is split into four sectors:

�  Objective setting and risk analysis

�  Risk reduction

�  Development

�  Project review

Development

Risk Reduction

Review and planning

Objectives

Software Engineering (Autumn, 2013)

Agile Approaches

�  Business is global and change reigns supreme �  Software exists everywhere in business environments �  Rapid delivery and adaptation is critical

�  Heavyweight approaches �  Agile approaches attempt to meet these demands

�  Manifesto for Agile Software Development (http://agilemanifesto.org/)

�  Individuals and interactions over processes and tools �  Working software over comprehensive documentation �  Customer collaboration over contract negotiation �  Responding to change over following a plan Examples

27

�  But with software - design is hard and expensive, but construction is cheap

�  So perhaps we don’t need to aim for a precise design, to be constructed in a separate phase

�  And perhaps we can’t anyhow �  “the requirements keep changing”

Agile Issues

28

�  Customers need to be willing to spend time with the development team and need to represent the various stakeholders

�  They also have to accept that they cannot have a fixed product at a fixed price

�  The development team members need to be able to “play nicely together”

�  Different stakeholder have different priorities, so how do you prioritise changes?

�  Elegant solutions take time, understanding and focus

Software Engineering (Autumn, 2013)

eXtreme Programming (XP) �  The most famous agile approach to SE (but there are others such as Scrum)

http://www.extremeprogramming.org/

�  Requirements are expressed by the customers as (short) user stories

�  Time estimation (1-3 weeks of ideal dev time)

�  Acceptance test

�  Pair programming

�  Unit tests are written before the code

�  Continuous integration with all unit tests passing

�  The code is collectively owned

�  Stand up meetings at the beginning of each day

�  Heavy emphasis on refactoring to simplify designs

29 Software Engineering (Autumn, 2013)

Other Approaches

�  Heavyweight and agile approaches presume engineering within a business environment

�  Software systems can, however, be engineered using less controlled approaches

�  Examples: �  Cowboy Coding �  Free Software/Open Source

30 Software Engineering (Autumn, 2013)

Cowboy Coding

�  The SE anti-pattern

�  Programmers do as they please �  Can be lone wolf or a pack

�  Limited interference from management and clients

�  Reliance on the quick and dirty

�  Lack of analysis

�  Can be useful for small projects and sometimes these payoff.

31

Some projects that started out Cowboy

32

�  Adobe Photoshop �  Apache HTTP Server

�  Facebook

�  Google

�  Linux �  MySQL

�  Most student projects

Software Engineering (Autumn, 2013)

Free Software: Open Source Development

�  Free as in freedom �  The software can be used, studied, modified and redistributed without

restriction �  The source code is made available with the distribution on the software

�  The software evolves by the users, for the users

�  Cooperative development undertaken voluntarily

�  Examples �  Linux �  Apache HTTP Server �  Eclipse IDE �  Mozilla Firefox

33 Software Engineering (Autumn, 2013)

Summary �  There are a number of approaches to SE including:

�  Heavyweight �  Lightweight (agile) �  Cowboy coding �  Open Source

�  They each have strength and weaknesses

�  Influencing factors include

�  Size of project �  Knowledge of requirements �  Delivery environment �  Philosophy

34 Software Engineering (Autumn, 2013)