itnp23: foundations of information technology · • identify the standard phases in a project •...

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


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)


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


  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 coordination 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


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


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


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


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


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)


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)


  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


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


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


4. Testing

  Unit tests

  Integration tests

  Debugging, fixing and patching

  Release testing   Alpha and beta versions

  Performance testing

  Interface testing

  Acceptance testing


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


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)


SE approaches

  We looked at general SE procedures and phases

  Now: SE approaches to managing these, including:

  Heavyweight   Lightweight (agile)   Cowboy coding   Open Source


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.


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


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


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



Simple

Feature rich


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


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


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


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


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


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


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
