Project: 30 % (Doc 1: 20 in week 8 + Doc 2: 10 in week 12)
Tutorial participation: 10 %
Grades: (no one failed in CP3110 in the last 5 years !!)
Pass : get at least a total of 50 marks (out of 100).
Credit : total > 65 and Exam > 30 Marks
Distinction : total > 75 and Exam > 39 Marks
High Distinction : total > 85 Marks
Questions released on Friday
Bring your solutions to the tutorial
Participate at least 10 tutorial sessions
from a colleague in Netherlands (1990)
A short story
Move to a new large house ?
No! Too good a location + sentiments
House too small
Study room became a child’s bedroom
Wife thought kitchen too small
Consulted an architect about renovation
Blueprint for large kitchen + 4 new rooms
Attractive and apparently cheaper than moving
Brother (building industry) warned of the mess
but, thought they can handle it
Applied for permission and got it in 6 months
Short story - cont.
In Aug 1991, contract signed for a fixed price
September: 1 week’s work done in the 1st month
Oct: part of the roof to be removed
Surprise: more to be demolished
Nov: roof up (lucky, only 2 days rain)
New kitchen to be installed: remove a brick wall
problem: old heating systems right behind the wall
Finished in January
many tiny expenses (unaccounted for) added up to a pretty sum
Lot of trouble (big brother is right again!)
estimated time: 60 working days (November finish)
extra things: wiring, new central heating
estimated on the back of an envelop
Story is true for many software projects
Software too often delivered late
More expensive (time and money both)
Does not meet its specifications
Underestimate non-technical factors
The Software Crisis
Want to avoid ?
Take CP3110 seriously
The economies of ALL developed nations are dependent on software
More and more systems are software controlled
Software engineering expenditure represents a significant fraction of GNP in all developed countries
Therefore, cost-effective software production is essential to national & international economies
Software engineering is concerned with theories, methods and tools for professional software development
What is software?
Computer programs and associated documentation
Software products may be developed for a particular customer or may be developed for a general market
Software products may be
Generic - developed to be sold to a range of different customers
Bespoke (custom) - developed for a single customer according to their specification
What is software engineering?
Software engineering is an engineering discipline which is concerned with all aspects of software production
Software engineers should adopt a systematic and organised approach to their work and use appropriate tools and techniques depending on the problem to be solved, the development constraints and the resources available
What is a software process?
A set of activities whose goal is the development or evolution of software
Generic activities in all software processes are:
Generic process models
Integration from reusable components
Software costs often dominate system costs. The costs of software on a PC are often greater than the hardware cost
Software costs more to maintain than it does to develop. For systems with a long life, maintenance costs may be several times development costs
Roughly 60% of costs are development costs, 40% are testing costs.
Distribution of costs depends on the system being developed and the development model used
Software engineering is concerned with cost-effective software development
What are the attributes of good software?
The software should deliver the required functionality and performance to the user and should be maintainable, dependable and usable
Software must evolve to meet changing needs
Software must be trustworthy
Software should not make wasteful use of system resources
Software must be usable by the users for which it was designed
Properties of the system as a whole rather than properties that can be derived from the properties of components of a system
Emergent properties are a consequence of the relationships between system components
They can therefore only be assessed and measured once the components have been integrated into a system
Examples of emergent properties
The overall weight of the system
This is an example of an emergent property that can be computed from individual component properties.
The reliability of the system
This depends on the reliability of system components and the relationships between the components.
The usability of a system
This is a complex property which is not simply dependent on the system hardware and software but also depends on the system operators and the environment where it is used.
Types of emergent property
These appear when all the parts of a system work together to achieve some objective. For example, a bicycle has the functional property of being a transportation device once it has been assembled from its components.
Non-functional emergent properties
Examples are reliability, performance, safety, and security. These relate to the behaviour of the system in its operational environment. They are often critical for computer-based systems as failure to achieve some minimal defined level in these properties may make the system unusable.
What are the key challenges facing software engineering?
Coping with legacy systems, coping with increasing diversity and coping with demands for reduced delivery times
Old, valuable systems must be maintained and updated
Systems are distributed and include a mix of hardware and software
There is increasing pressure for faster delivery of software
Professional and ethical responsibility
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.
Issues of professional responsibility
Engineers should normally respect the confidentiality of their employers or clients (even if no confidentiality agreement).
Engineers should not misrepresent their level of competence. Should not knowingly accept work beyond their competence.
Intellectual property rights
Engineers should be aware of local laws governing the use of intellectual property such as patents, copyright, etc.
Should not misuse their technical skills (virus).
Code of ethics - principles from IEEE/ACM
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.
Software engineers shall ensure that their products and related modifications meet the highest professional standards possible.
Code of ethics - principles
Software engineers shall maintain integrity and independence in their professional judgment.
Software engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance.
Software engineers shall advance the integrity and reputation of the profession consistent with the public interest.
Code of ethics - principles
Software engineers shall be fair to and supportive of their colleagues.
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.
Software Myths (from Pressman)
Myth: It’s in the software. So, we can easily change it.
Reality: Requirements changes are a major cause of software degradation
Myth : We can solve schedule problems by adding more programmers.
Reality: Maybe. It increases coordination efforts and may slow things down .
Myth : While we don’t have all requirements in writing yet, we know what we want and can start writing code .
Reality: Incomplete up-front definition is the major cause of software project failures.
Myth: I can’t tell you how well we are doing until I get parts of it running .
Reality: Formal reviews of various types
can give good information and
are critical to success in large projects.
Myth: The only deliverable that matters is working code .
Reality: Documentation, test history, and program configuration are critical parts of the delivery.
Myth: I am a (super) programmer. Let me program it, and I will get it done .
Reality: A sign of immaturity. A formula for failure. Software projects are done by teams, not individuals, and success requires much more than just coding.
Software engineering is an engineering discipline which is concerned with all aspects of software production.
Software products consist of developed programs and associated documentation. Essential product attributes are maintainability, dependability, efficiency and usability.
Emergent properties are properties that are characteristic of the system as a whole and not its component parts
The software process consists of activities which are involved in developing software products. Basic activities are software specification, development, validation and evolution.
Software engineers have responsibilities to the engineering profession and society. They should not simply be concerned with technical issues.
10 minute break: a brain teaser
Your are in the cellar of your house. There are three light switches which individually switch on or off three light bulbs in your attic. You may go from your cellar to your attic only once. How can you find out which bulb is connected to which switch?
Initially, all switches are in the "off" position. Further tools or persons are not available. All bulbs are in perfect working order, you cannot see from the cellar to the attic, metaphysical and esoteric phenomena are not permitted.
Solution to the brain teaser
switch 1 on
wait 5 minutes
switch 1 off
switch 2 on
go to your attic
feel: the hot bulb is connected with switch 1
look: the shining bulb is connected with switch 2
conclude: the last bulb is connected with switch 3
First lesson about modeling . If you use the simple model "bulb has 2 states (on/off)" to solve the problem, you forget an additional implicit aspect of the real world ("heat"), which must be taken into consideration.
Ch.3: Software Processes
Coherent sets of activities for specifying, designing, implementing and testing software systems
To introduce software process models
To describe a number of different process models and when they may be used
To describe outline process models for requirements engineering, software development, testing and evolution
To introduce CASE technology to support software process activities
The software process
A structured set of activities required to develop a software system
A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective
3.1 Generic software process models
The waterfall model
Separate and distinct phases of specification and development
Specification, development and validation are interleaved
Formal systems development
A mathematical system model is formally transformed to an implementation
The system is assembled from existing components
Waterfall model problems
The drawback of the waterfall model is the difficulty of accommodating change after the process is underway
Inflexible partitioning of the project into distinct stages
This makes it difficult to respond to changing customer requirements
Therefore, this model is only appropriate when the requirements are well-understood
Objective is to work with customers and to evolve a final system from an initial outline specification. Should start with well-understood requirements
Objective is to understand the system requirements. Should start with poorly understood requirements