itnp23: foundations of information technology · 2016-10-05 · itnp23: foundations of information...
TRANSCRIPT
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 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
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
� 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)