1. An Introduction to Software Engineering

2. Objectives
Introduce software engineering and to explain its importance
Set out the answers to key questions about software engineering

3. FAQs about software engineering
What is software engineering?
What is the difference between software engineering, computer science, and systems engineering?
What is the software crisis?
What are the costs of software engineering?
What is software and what are the attributes of good software?
What is a software process and a software process model?
What are software engineering methods?
What is CASE (Computer-Aided Software Engineering)
What are the key challenges facing software engineering?
The economies of ALL developed nations are dependent on software.
More and more systems in our daily lives are software controlled.
Software engineering is concerned with theories, methods and tools for professional software development.
Expenditure on software represents a significant fraction of GNP in all developed countries.
Software engineering is an engineering discipline that 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.

4. What is software engineering?
From Wikipedia
“Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software.’’
Classic Definition (1969)
“The establishment and use of sound engineering principles in order to obtain economically built software that is reliable and works efficiently on real machines.”
IEEE Definition (1993)
The term software engineering was popularized during the 1968 NATO Software Engineering Conference (held in Garmisch, Germany) by its chairman F.L. Bauer, and has been in widespread use since. The discipline of software engineering encompasses knowledge, tools, and methods for defining software requirements, and performing software design, software construction, software testing, and software maintenance tasks.[2] Software engineering also draws on knowledge from fields such as computer engineering, computer science, management, mathematics, project management, quality management, software ergonomics, and systems engineering.[2]
As of 2004, the U. S. Bureau of Labor Statistics counts 760,840 software engineers holding jobs in the U.S.; for comparison, in the U.S. there are some 1.4 million practitioners employed in all other engineering disciplines combined.[3] The term software engineer is used very liberally in the corporate world. Very few of the practicing software engineers actually hold engineering degrees from accredited universities. There are estimated to be about 1.5 million practitioners in the E.U., Asia, and elsewhere[citation needed]. SE pioneers include Barry Boehm, Fred Brooks, C. A. R. Hoare, and David Parnas.
“Software Engineering: (1) The application of a systematic, disciplines, quantifiable approach to the development, operation, and maintenance of software; that is the application of engineering to software. (2) The study of approaches as in (1).”

5. Software Engineering vs. Computer Science
Computer science is concerned with theory and fundamentals; software engineering is concerned with the practicalities of developing and delivering useful software.
Computer science theories are still insufficient to act as a complete underpinning for software engineering (unlike e.g. physics and electrical engineering). 
CS deals mainly with the technical details of SW development, including such things as algorithms, data structures, programming languages, data communication, networking, computer hardware, and study of specific classes of software, such as operating systems, compilers, and databases.
SE deals with the remaining aspects of SW development, which are mainly non-technical. They mainly have to do with the human part of the process. These are actually the hardest aspects of software development, because they are not subject to precise definition and scientific analysis.
SE theory has some characteristics of religion. Views are sometimes very strongly held, but they are largely a matter of faith and personal experience. Much of SE is about how to go about solving problems. More than one way will work. It is hard to prove scientifically that one method works better than another. We can't do the kind of controlled and repeatable experiments that are used to support theory in the hard sciences, but we do try to learn from experience, and some attempts to do controlled experiments have been made. Generally, what one believes has a lot to do with one's personal experience, and training. Having a lot of faith in a method seems to improve one's chance of making it work.
SE teaching is also a bit like religious teaching, or preaching. We say how people should act, with promises that if they do things will work out better for them. We use some very abstract words, that mean very little to a person until she or he has had enough experiences to give them meaning.
SE is a bit more an aspiration than a reality. The aspiration is to emulate traditional engineering disciplines. Recall the origin of the word "engineer". Engineering as a licensed profession evolved from early disasters with steam engine technology. Engineering, as compared to art and science, seeks to use systematic (codified, rule-book) methods to enable ordinary people to routinely produce and maintain technological artifacts without having to start from basic principles each time, and with a low risk of failure.
The negative comparison with other engineering fields may be a bit too idealistic about other kinds of engineering. It has been claimed that theories of electrical engineering are sufficient for a person who knows those theories to be a practicing electrical engineer, and that by contrast the theories of computer science, such as the halting theory, predicate calculus, proofs, regular expressions, are not sufficient for a complete underpinning of a software engineer. I would dispute that. From what I have seen and heard from other kinds of engineers, many of the problem we encounter in software engineering are common to all human enterprises. Projects do not usually fail because of lack of theory or failure to apply the theories, they fail due to mismanagement, poor risk mitigation, performance issues, failure to satisfy the customer.
What we call software engineering in this course tries to fill in the gaps between theory and practice, for students who know the theories and know how to program.

6. Software Engineering vs. Computer Science
CUSTOMER
Problem
Theories
Computer
Functions
SOFTWARE
ENGINEERING
Here computer science teaches the theories, and computer functions --- programming.
But the customer does not have a theory that needs resolved nor does he know what program he wants.
He just knows he has a problem and things computing may help.
Software engineering helps to give you the tools and techniques to solve the customers problem.
Tools and
Techniques to
Solve Problem

7. Software vs. Hardware You can’t see, touch, or feel software
Software is only engineered, not manufactured
Software doesn’t wear out
Software is complex
Software is a differentiator
Software can behave like an aging factory
We often hear from hardware engineers that SE engineers should learn from them, because they are more successful in building products that work, on time, and on schedule.
This is not so easy, because SE differs from hardware engineering.
We do not have much of a manufacturing phase, which is very important in hardware production.
Most of SE has to do with design.
Software is intrinsically less stable, less tolerant of faults (manufacturing defects), than hardware.
Unlike a building, where one or several bricks may be destroyed without the building falling down, changing a random bit in a piece of software is very likely to cause total failure.
People expect software to be more easily changed than hardware. In the middle of the construction of a bridge, if the customer asked for it to be made a foot longer, or widened to include another lane, no one would expect this to be done quickly or cheaply. However, in software, it is common to see a customer ask for major changes in requirements late in the development process, or in production. We should not be surprised that making such changes may be very expensive.

8. Communication is a critical element.
This is very old cartoon that captures the communication difficulties in software engineering.
Perhaps the hardest part of SE is communication. Software can be viewed as a fully specified communication of a human intent to a computer, which is sufficient for the computer to carry out the intent of the human.
The development process starts out with communication between humans – customers or users and developers -- as to what the customers/users want the software to do. The rest of the process consists of refining this initial communication.
Communication failures along the way result in defects in the final product.

9. This is a prettier and newer version of the old cartoon
This is a prettier and newer version of the old cartoon. The details are different, but the core idea is the same.

10. Software Engineering vs. System Engineering
System engineering is concerned with all aspects of computer-based systems development including hardware, software and process engineering.
Software engineering is part of this process concerned with developing the software infrastructure, control, applications and databases in the system.
System engineers are involved in system specification, architectural design, integration and deployment.
Systems engineering is usually in the engineering school since it involves hardware and control system.
The boundaries between system engineering, software engineering, and computer science are fuzzy. A computer scientist can become a software engineer, and long-term software engineers may to become system engineers, as they learn more about the larger systems in which the software resides.
Software engineering can be located in the School of Engineering (as with UF), School of Arts and Sciences (as with FSU), or even a school of their own (Carnegie Mellon).

11. What to Study in Software Engineering?
Products produced
Processes used to produce the products
The final products are software components. They may be fully executables components, programs, modules, systems, or simply methods. There are many software deliverables between the specification of the products and the actual products.
The software development life cycle describes the development process for producing software products. However there are many other items within the process. We will investigate the full process of software engineering.
Its all about the process and the products (deliverables).
The process we will be using is the unified process.
The products we are producing are in UML and we call them deliverables.

12. Some core questions What is the software product?
Who does software engineering of the product?
Why is software important?
What are the steps in software engineering?
What is the work product of the engineering process?
How do we ensure products are built correctly and that the correct product is built?

13. Problems Behind the “Software Crisis”
Increased size and complexity of systems
Cost overruns
Design bugs after implementation
Maintenance ripple effect
Requirements and design needed development tools, not just in the programming tools
In the 1970’s the US Government and large corporations discovered they had a “software crisis”. They were spending more and more money on software, with less and less satisfactory results. Software costs outstripped hardware costs, and software reliability became a major concern. I high proportion of software development projects failed totally, and a larger number ended behind schedule and over budget.
The field of software engineering grew out of a need to address this crisis.
We have managed to survive, but not without costs. At one point there was a prediction that by now every person on the earth would need to be a computer programmer. That prediction has gone the way of an earlier prediction that every person would need to become a telephone operator. Some of the ways we have adapted include:
less customized software, more use of generic
use of higher-level programming constructs and reusable components: libraries, templates, application generator tools, visual programming
end-user "programming" - e.g., spreadsheets.
It seemed for a while in the 1990’s that the crisis had been solved, but it is popping up again in the 2000’s.
It is important to recognize that most of the problems behind the current software crisis relate to scale, and to applying methods that are appropriate for small-scale projects with large-scale projects.
If you are going to write a program of 100,000 lines of code, you may not need a process or products. I can write 100,000 LOC without either IF 1) I have a team of only 5 to 6 people and 2) the requirements are well understood or at least totally under my control.
The issue is large projects with communicating teams of 10 or greater that have to satisfy some customer requirements that must be understood (clearly).
Ultimate Cause of the Software Crisis => Inability to deal with the complexity of software solutions
That’s when costs overruns happen – the customer gets your prototype and says this is not at all what I had in mind. WOW!
All of a sudden after the program is complete the response time is 30 minutes between transactions because you designed the user interface incorrectly or the database tables incorrectly or wrote the code with too much recursion or memory leaks, etc.
Cost overruns also happen because the more you maintain code the more it begins to be degraded structurally… You do things to get the maintenance done and the code begins to SMELL.
Requirements from a customer get very complex. In installing a system for an electrical company, I spent one entire week trying to balance their daily cash. After a week, I went to the customer and told them of the problem…. We were OFF every day…..short I did not know why….
Well seems as though they allowed people to take their lunch money from the till and put it back in a box over the refrigerator. Hmmmmm One week lost.

14. Software Crisis
Research from Standish Group Data on 9236 development projects completed in 2004.
Despite many software success stories, an unacceptably large proportion of software products are still being delivered late, over budget, and with residual faults.
DURING 2004, less than 1 software development project in three (29%) was successful
Standish Group is a research firm that analyzes software development projects
18% were canceled before completion or were never implemented
53% were completed and installed on the client’s computer but were over budget, late, or had fewer features or functionality than initially specified

15. Abandoned or Cancelled Projects
Percentage of surveyed organizations' software projects that have been abandoned or cancelled due to significant cost or time overruns in the past three years (source [12])

16. Software Crisis
2002 survey of information technology organizations by Cutter Consortium Data
78% have been involved in disputes ending in litigation
In 67% of the disputes, the functionality of the information system as delivered did not meet up to the claims of the developers
In 56% of the disputes, the promised delivery date slipped several times
In 45% of the disputes, the defects were so severe that the information system was unusable
It is clear that far too little software is delivered on time, within budget, fault free, and meeting its client’s needs.
The software crisis is still with us, over 35 years later

17. New Aspects of Crisis
(In)security - we have allowed ourselves to become too dependent on software (and hardware) that was never designed to be robust or secure
Over complexity - competition for more features, ease of use, and integration are making products too large to comprehend and maintain
Internationalization – this is a problem for the US, which has been presumptuously complacent about its leadership
Software patents - these legal "land mines" are beginning to choke the software industry
Rapid changes – tower of Babel, multicore, etc.
Just as computer science does not provide technical solutions to all of of software engineering’s problems, software engineering methodology does not provide solutions to all of the above problems.
Internationalization, yes.
Security and complexity are harder.
Patents are another thing.

18. Weapons Against Software Crisis
Improving software engineering methodologies
High-level languages and tools that encourage and enforce these principles
There are some 600 different software engineering methodologies---- all have their plusses and minuses.
The latest trend is the Unified Process for large processes. Things like Extreme Programming or Agile are also new but are called lightweight methodologies which don’t scale up to large projects.
Remember if you only have 5 people and total control of the project…. You don’t necessarily need a process. So go figure why those courses in Extreme Programming cost $5000 per week. But in the 30 years software engineering has been evolving, the processes have gotten better… The “silver bullet” is simply not here yet…. Soon, maybe?

19. Software Engineering Definition
The software crisis yielded yet another definition of software engineering:
Discipline whose aim is the production of fault- free software, delivered on time and within budget, that satisfies the client’s needs.
Systematic and organized approach to the production of high- quality software
Engineering discipline whose goal is the cost-effective development of software systems
Engineering discipline which is concerned with all aspects of software production from the early stages of system specification to maintaining the system after it has gone into use
Still have problems today in meeting user requirements and in delivering on time and to budget
As our ability to produce software has increased, the complexity of the software systems has also increased
Success Factors for Software Development
Software system must effectively meet the stated business need.
Software system must be flexible and maintainable.
Integrity and reliability must be built into the software.
The software system should be completed on time and within budget.

20. Costs of Software Engineering
Software costs dominate computer systems costs.
Roughly 60% of costs are development costs, 40% are testing costs. For custom software, evolution costs often exceed development costs.
Software maintenance costs are more than software development costs.
For systems with a long life the maintenance may be several times the development costs. And often even bad software has a long life.
The costs of software on a PC are often greater than the hardware cost.
Software engineering is concerned with cost-effective software development.

21. Costs of Software Engineering
Costs vary depending on the type of system being developed.
The costs depend of the requirements of system attributes such as performance and system reliability as well as the complexity of the type of system being developed.
Distribution of costs depends on the development model that is used.
If your requirements for performance and reliability are high…. The cost is MUCH greater.
If your system is very complex….again more cost.

22. Activity cost distribution
Here are some pictures that show the type of system and how the costs are spread across the development cycle.

23. Product development costs
This is a general categorization of what currently happens.

24. Maintenance Costs (a) Between 1976 and 1981 (b) Between 1992 and 1998
Time of Post delivery Maintenance
Remember time is money in business
The figure on the left (a) shows costs from 1976 – 1981
The figure on the right (b) shows costs from
The cost is still 2/3 of the total software costs went to postdelivery maintenance
Because postdelivery maintenance is so important, a major aspect of software engineering consists of those techniques, tools, and practices that lead to a reduction in postdelivery maintenance costs
(a) Between 1976 and 1981
(b) Between 1992 and 1998

25. Changing View of Maintenance
Postdelivery maintenance
Development-then-maintenance model
Temporal definition
Modern maintenance
Occurs whenever a fault is fixed or the requirements change, irrespective of whether it takes place before or after installation of the product
Post delivery maintenance
Any change to software after installation on the client’s computer and acceptance by the client
Temporal definition
Activity is classified as development or maintenance depending on WHEN it is performed (before or after product has been installed on client’s computer)
Changes in today’s software production lead to changing view of maintenance
Because of length of time in development, client starts requesting changes to requirements during development.
Software reuse means continued development (maintenance) of reused code; effects of updates can ripple in hard-to-predict ways.

26. An error that is made during the requirements phase and is undetected will appear in the specifications, design, and the code.
Earlier we correct an error, the better
This chart shows the high cost of correcting problems during the maintenance phase ($30 during specification phase, $40 during design, $2000 during maintenance)
Why so high? Have to edit code, recompile and relink, test, make sure that change has not created a new problem elsewhere in the product, change all relevant document (including the user manual), deliver and install corrected product

27. Why So Costly? To correct a fault early in the life cycle
Usually just a document needs to be changed
To correct a fault late in the life cycle
Change the code and the documentation
Test the change itself
Perform regression testing
Reinstall the product on the client’s computer(s)
What is the product is installed on 100 computer’s of the client???
Why so high? Have to edit code, recompile and relink, test, make sure that change has not created a new problem elsewhere in the product, change all relevant document (including the user manual), deliver and install corrected product.

28. Wear vs. Deterioration Failure rate change actual curve
idealized curve
change
actual curve
Failure
rate
Time
increased failure
rate due to side effects
In software we have a very malleable medium. It can be changed over and over. There is no cost for "materials", just for intellectual effort. This is convenient, but tempts us to make many changes, which lead to problems.
What are some of the reasons for the spikes in the curve above? Why is the trend in the troughs upward?
Note when you first install a system the failure rate is the HIGHEST…. Lots of problems when you first install…. Many sleepless nights……As the software ages….you would expect the problems to minimize…
Not true… note while that is the ideal…..the actual curve shows that that maintenance that degraded the code causes the failure rate to increase as time increases….Most all software behaves in this manner.
Roger S. Pressman, Software Engineering: A Practitioner's Approach, Fourth Edition 1997

29. The Cost of Change 60-100x 1.5-6x 1x Definition Development
After release 1x
1.5-6x
60-100x
The later in the life of the product, the more expensive is the change. How is this different from hardware?
Here is an important point….. If you have a requirement and you miss it in the definition (specification) of the solution then the cost to add that requirement is low….lets say 1 times some number x
If you begin coding and you find a requirement that has been missed…. The cost increases to 1.5 or 6 times X
If you find the problem AFTER the software is released the cost is 60 to 100 times X…
So you should be able to specify software well enough for your colleagues and the customer to UNDERSTAND if their requirements are COMPLETE and CORRECT.
Roger S. Pressman, Chapter 1 Page 19, Software Engineering: A Practitioner's Approach, Fourth Edition 1997

30. What is a Software Product?
A set of items or objects called a configuration. It includes things like:
Multiple separate programs
Configuration files which are used to set up these programs
System documentation which describes the structure of the system
Developer and User documentation which explains how to use the system
Data for the system
Web sites for users to download recent product information
Software is not just code in a machine-readable form. Documentation and data may be included, as well as support service.

31. What is software?
Computer programs and associated documentation such as requirements, design models and user manuals.
Software products may be developed for a particular customer or may be developed for a general market.
New software can be created by developing new programs, configuring generic software systems or reusing existing software.

32. What is software? Software products may be GENERIC
developed to be sold to a range of different customers e.g. PC software such as Excel or Word.
referred to as commercial off-the-shelf (COTS) software or clickware supplied by a vendor
BESPOKE (custom) - developed for a single customer according to their specification.
Product specification controlled by the product developer
Know these terms.
Generic software products are intended for sale in the open market, to any customer that wants to buy them. They are sometimes called “off-the-shelf” or “shrink-wrapped” software. Generic software is generally produced by a software development business.
Custom software is commissioned by a particular customer, and developed specifically to meet requirements of that customer. It may be developed by a software contractor, by done in-house by the end user.
Costs and risks can be reduced by using generic products. Witness the success of MS Office, Oracle and the ERP business (SAP, PeopleSoft).
Using a generic product may mean the user adapts to the software, rather than vice versa, but sometimes that is cheaper. If the software is well designed, this change in behavior may have other positive benefits… but beware the potential tyranny and inflexibility of the software. (“I’m sorry, our system will not allow that.”)
Many aspects of software engineering process can be quite different for generic vs. custom products.
“Bespoke” is a British term, that is used the way “custom” is used in American English.

33. Software Terminology Open-source software
Developed and maintained by a team of volunteers
May be downloaded and used free of charge
Examples:
Linux operating system
Firefox web browser
Apache web server
Open-source software
Open sources refers to the availability of the source code to all, unlike most commercial products where only the executable version is sold
Many open-source software products are of high quality
Linus’s Law states that “given enough eyeballs, all bugs are shallow”
If enough individuals scrutinize the source code of an open- source software product, someone should be able to locate that fault and suggest how to fix it
Richard Stallman distinguishes “open source” from “free” software. The critical distinction is whether you an just see the source, or whether you are free to modify, re-use, and redistribute the source code. .
Read the Gnu public license at .

34. Software Types system software real-time software business software
engineering/scientific software
embedded software
PC software
AI software
WebApps (Web applications)
These illustrate the wide range of variation in functionality and characteristics of software. Some dimensions of variation include input determinacy, algorithmic determinacy, consequences of failure, volume of users, response time constraints.
SE techniques tend to differentiate according to the software area. That is, some techniques may be more important or better suited for some kinds of software than for others.

35. 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 acceptable.
Maintainability
Software must evolve to meet changing needs;
Dependability
Software must be trustworthy;
Efficiency
Software should not make wasteful use of system resources;
Acceptability
Software must accepted by the users for which it was designed. This means it must be understandable, usable and compatible with other systems.

36. What are the attributes of good software?
From the Users Perspective
Correctness
Reliability
Efficiency
Maintainability
Usability
Robustness
From the Developers Perspective
Consistency
Understandability
Testability
Compactness
Compatibility
Integrity
Correctness
Does the product do what it is supposed to do?
Does it fulfill the requirements?
2)Reliability
Does it compute accurately every time?
3)Efficiency
Can the product run fast enough?
4)Maintainability
Can the product be fixed or adapted?
Can it be enhanced or extended?
Can it be moved to another hardware (portability)?
5)Usability
Can the typical user run it easily?
6)Robustness
Does it handle bad data well?
Just a few of the characteristics of quality software from the developer’s perspective:
1)Consistency
Are the terminology and naming conventions uniform?
2)Understandability
Are the documents understandable?
3)Testability
Can it be tested?
4)Compactness
Does it use a minimum of memory?
5)Compatibility
Does it work with other systems?
6)Integrity
Is the system secure?

37. Software Process
A set of activities and associated results which produce a software product
Incorporates a software life-cycle model, techniques, the tools used, and the software developers
Software Process
The way we produce software
Differs from organization to organization (some build self- documenting code with no other documentation while others build code and much other documentation; testing levels differ – some test thoroughly while others test little and let the user be the tester)
Important because it imposes consistency and structure on a set of activities
No “ideal” software process; some are more suitable than others for certain types of applications
These are really GENERIC phases that occur in some form in all software development
Regardless of exact procedure, the software process follows these same basic seven phases (names may vary but actions done are basically same)

38. What is a software process model?
A simplified representation of a software process, presented from a specific perspective.
Examples of process perspectives are
Workflow perspective - sequence of activities;
Data-flow perspective - information flow;
Role/action perspective - who does what.
Generic process models
Waterfall;
Iterative development;
Component-based software engineering.
Software development methodologies as mentioned earlier are also called PROCESS MODELS in software engineering. It is the process or methodology that you use to develop your software….
The unified process uses the workflow perspective as we will be learning..

39. Software Life-cycle Models
Specifies the various phases of the software process and the order in which they are to be carried out.
Covered in Chapter 1 Dennis
Software Life-cycle Model
for many large systems, there is no single software life-cycle model used (different models are used to develop different parts of the system)
Note that there is a difference here between a process model and a life-cycle model. Can you explain it?

40. What are software engineering methods?
Structured approaches to software development which include system models, notations, rules, design advice and process guidance.
Model descriptions
Descriptions of graphical models which should be produced;
Rules
Constraints applied to system models;
Recommendations
Advice on good design practice;
Process guidance
What activities to follow.
Here are some of the methods that might be in a methodology or process model.
Here is third kind of model, a *system* model.

41. What is CASE? Computer-Aided Software Engineering
Software systems that are intended to provide automated support for software process activities.
CASE systems are often used for method support.
Upper-CASE
Tools to support the early process activities of requirements and design;
Lower-CASE
Tools to support later activities such as programming, debugging and testing.
As a side note.
In the 70’s a man called Albert Case started a company for software engineering … He had his own process and tools to help him do software development and thought they were so great that people would be flocking to hire him. But alas he had trouble getting work..
So he decided to market his process in a little conference in Atlanta at a hotel room. He got some names of business that he thought should be using his services and sent them invitations AND told them to bring anyone else interested. He called the expo CASE his last name or computer aided software engineering. He took out an add in the Atlanta paper and scheduled a small hotel room for people to come….2000 showed up…. WHEW…. He was not prepared but he did coin a term and added value to SE.

42. What are the key challenges facing software engineering?
Heterogeneity - platforms and execution environments
Delivery – faster time to market
Trust –includes reliability, security
Shifts in economics of computing
Lower hardware costs and greater development and maintenance costs.
Shifts in technology
Extensive networking
Availability and adoption of OO technology
Graphical user interfaces
Budgets and costs
Maintaining quality
And don’t forget the issues of internationalization, and software patents, mentioned earlier.

43. Key points
SWE is an engineering discipline that 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.
The software process consists of activities that are involved in developing software products. Basic activities are software specification, development, validation and evolution.
CASE tools are software systems which are designed to support routine activities in the software process such as editing design diagrams, checking diagram consistency and keeping track of program tests which have been run.