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)
9
Embed
ITNP23: Foundations of Information Technology · 2016-10-05 · ITNP23: Foundations of Information Technology Software Engineering Introduction • Define software engineering and
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
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
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:
� 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