CPS211 Lecture: Course Intro; Introduction to Software Engineering

last revised July 23, 2008

Objectives:
1. To introduce the course requirements and procedures.
2. To set programming in the larger context of software development/engineering.
3. To introduce the Software Engineering Code of Ethics
4. To introduce basic terms/concepts of SE
5. To introduce the software lifecycle
Materials:
1. Syllabus
2. Software Engineering Code of Ethics (online)
3. Projectable of “Tree Swing”
4. Projectable of text page 305
5. Projectable of requirements for AddressBook and ATM example systems
6. Term project requirements (Handout)
I. Preliminaries - About this Course
A. Writing exercise - When you purchase a product - any product, software or otherwise - how do you evaluate the quality of what you have purchased - i.e. what do
you look for, in general, as marks of quality?
Discuss class answers
B. Distribute, go over syllabus.
C. This course is a continuation of CPS112; but it will differ from CPS112 in some important ways.
1. In CS112, a great deal of your mental energy was invested in learning about programming, and more specifically in learning how to program in Java.
2. While programming in Java is part of the content of this course too, we want to step back from programming per se to set it in the broader context of problem
solving.

a) It turns out that much the same issues arise in any sort of problem solving - whether it be the creation of a piece of software, or the creation of some other
engineered artifact, or the design of a curriculum in education, or the development of a business plan, or
b) In this course, we are specifically concerned with software development - an entire process of which programming is just one part. Software development is the
process of producing a software product that will fulfill some real need for someone.

c) However, since the basic process is similar whenever one is involved in designing a quality solution to a problem someone has - software or otherwise, the basic
approach we will take is broadly applicable to any sort of problem solving.

3. Some of you may wind up developing software professionally, while others will not. However, an understanding of the issues involved in software development is
not just important for practicioners. It is perhaps useful at this point to think a bit about the spectrum of things people with a CS background actually do.

a) Some, of course, do develop software in a variety of settings - whether embedded systems (e.g. the software that controls many of the systems in a modern car) or
moderate sized systems (like web sites) or huge systems (like those that control the telelphone network etc.)

b) Others are involved in research. Often, this research finds practical application in software systems.

c) There is a growing recognition of the need to develop people with cross-disciplinary understanding - i.e. people who understand not only computing, but also some
field where computing is important. In fact, whole new cross-disciplinary areas like this are emerging -
e.g. bioinformatics.

d) Even a person who simply uses software - or helps others do so - can benefit from some understanding of what goes into producing software.

4. The guiding principle in the content of this course comes from the title of a talk I heard at the OOPSLA Educator’s Symposium in 1999: “Teaching Design: the rest
is SMOP”
II. Fundamental Issues; The Idea of Software Engineering
A. Developing quality software is not easy.
1. Software systems are among the most complex systems ever attempted by humanity. There is still much to be learned about how to do this well.
1
 2. Most large-scale software projects exhibit one or more of the following problems to an unacceptable degree:
a) The software is delivered late.
b) The budget is exceeded.
c) The software contains undetected errors. (Note: these are commonly called "bugs". Edgar Dijkstra has pointed out that calling them bugs rather than errors is
a way of avoiding taking responsibility for them.)

d) The software is difficult to maintain/modify - fixing one error often introduces two more.
e) The software does not really meet the user's needs.
f) The software is hard or confusing to use.
3. While quality is an issue with any product of human design, it is a particular issue with software. We do not expect bridges or buildings to collapse - but we are not
surprised when a piece of software “crashes”. We would be unhappy if we had to shut off and restart our car in the middle of an interstate, but we get used to the
idea of periodically rebooting a computer ...

B. The discipline that arose to address these problems in a systematic way has come to be called software engineering. Its goals are to:

1. Produce software that meets the needs of users

2. Produce correct software on time and on budget.
3. Produce software that can be maintained and modified to keep abreast of changing needs. For software that is used over a period of years, the cost of keeping it
current in the face of changing needs often exceeds the cost of originally developing it.Meeting these goals is not easy, and probably never will be, because the
complexity of modern software makes its development one of the greatest intellectual challenges ever faced by humanity. However, applying known principles
can help.

C. Software Engineering compared/contrasted with more traditional engineering professions.

1. Software is certainly not like physical engineered artifacts. How? (ASK CLASS)
a) For most physical artifacts, the bulk of the cost is in the manufacturing, not the design. For example, if one builds a bridge and then attempts to build another just
like it, the second bridge costs almost as much to build as the first. However, “manufacturing” software is cheap - the cost of producing a new copy (say on a CD)
is miniscule.

b) Most physical artifacts are costly to change once they have been produced; but making changes to a piece of software is often a matter of editing and
recompiling. (Of course, making correct changes is not necessarily easy!).

c) Physical artifacts wear out and need to be maintained or ultimately replaced - but software never wears out.
d) It is often possible to tell, by looking closely at a physical artifact, that it is defective. Faults in software are often much less obvious until they manifest
themselves in some sort of error.

e) A key difference is reflected in the existence of the “open source” movement. Open source software is software whose source code is made publicly available; in
general, one who acquires open source software is free to modify it to suit his/her own purposes (often with the proviso that he/she share these modifications with the
wider community.)

(1) For example, Linux is an open-source operating system, and much of the software designed for Linux platforms is open source. The same is true of the kernel of
Mac OS X (Darwin).

(2) OTOH, companies like Microsoft have been leading opponents of open source software.
(3) It’s hard to imagine an equivalent to open source in the more traditional engineering disciplines - the last thing anyone would want is thousands of people making
individual modifications to a bridge! However, proponents of open source point out that such software is often more reliable, because may eyes looking at the code
find more of the problems. (Linux is a much better operating system for servers than Windows products, IMO)

f) A profound - and subtle difference - has to do with mathematical foundations.

(1) Continuous mathematics - the calculus - is the mathematical foundation of traditional engineering.
(2) However, discrete mathematics is really the foundation of “software engineering”.
(3) In this distinction lies a profound difference between failure modes of the two entities. Physical systems often have slight errors; catastrophic failure is relatively
rare. Software systems are prone to crashes, or total failures.

2
 2. Despite the differences, there is much to be learned from other engineering disciplines about the process of producing quality software
- though I would resist the notion that software engineering is just another form of engineering.

D. One key characteristic of any profession is the expectation that its practitioners will perform their work in accordance with ethical expectations appropriate to the
profession. In the case of Software Engineering, those ethical expectations were formalized about ten years ago in a document developed jointly by the ACM and the
IEEE/CS, entitled “Software Engineering Code of Ethics and Professional Practice”.
1. Show online (link from course web site)
2. Read through short version Comments/Questions? ASK
3. The fact that this document is fairly recent (1998) is evidence of the relative youthfulness of software engineering as a profession like the other engineering
disciplines, or professions like law or medicine.

4. In considering the ethical ramifications of a decision, one crucial concept is the notion of a stakeholder. A stakeholder is someone who has a legitimate stake in the
outcome of the project.

a) There are four broad types of stakeholders connected with any software project.
(1) Users - those who will eventually use the software.
(2) Clients - those who decide to have the software developed, and pay for doing so.
(3) Developers - those who actually produce the software.
(4) Development managers - those who oversee the work of the developers.
b) For different kinds of software projects, there may be different relationships between these categories of stakeholders - e.g.

(1) The users of the software may be the same as the clients - or may be employees of the client. (E.g. in the case of the software Gordon uses for registration, billing
etc. Gordon is the client, but faculty and staff are users.)

(2) The users of the software may be customers of the client - e.g. if a firm uses an e-commerce web site, it is the client and its customers are the users.
(3) The developers may be part of the client organization, or may be contracted by the client to produce the software for them, or the client may purchase “off the shelf”
software that the developers have produced for a market they believe exists.

(4) In some cases, one individual may be user, client, developer, and development manager for a project - e.g. if you or I write software for our own personal use.
E. This course is not simply about software development, but about a particular approach to software development called object-oriented softwaer development. We
will have more to say about this later, but for now I want to note one emphasis that will occur quite a bit in this course - the use of a formalism called the Unified
Modeling Language (UML).

1. UML is a set of diagramming conventions that allow one to represent a software system by a collection of models. The first version of UML was adopted by the
Object Management Group (OMG) - a consortium of companies - in 1997. The current version (UML 2.0) was adopted in 2004.

2. UML is a graphical language - that is, its vocabulary is composed of graphical symbols. In this respect, it is international in scope. (Example: my experience at
OOPSLA design fest).

3. UML is called the unified modeling language for historical reasons. Prior to UML, there were a number of different graphical notations that were in wide use. UML
represents a unification of these notations in a single system that is now widely used.

4. As you.can see from the schedule in the syllabus, we will make extensive use of UML in this course.
F. There are two key sets of terms used to describe different kinds of software projects. COVER AS TIME PERMITS IN FIRST SESSION

1. Software can be classified into three broad categories.

a) Custom software is developed to meet the requirements of a specific user. Normally, a given piece of custom software is used only by one company. (Example:
the software that manages the financial records of a corporation.)

b) Generic software is developed to meet the perceived needs of a market, and is sold to many users. (Example: a particular word- processor or spreadsheet package or
game). Sometimes this is called COTS, which stands for Commercial Off-the-Shelf Software.

c) Embedded software is incorporated into some other product, and everyone who purchases the product also ends up using the software, though probably without
being aware of it. (Example: a DVD player or the ABS system on a car)
2. Another classification is to classify software as:
3
 a) Data-processing software is used to support the various business functions of a company. This includes systems like payroll systems, customer order systems, airline
reservation systems, etc. etc.
Often, some or all of the processing can be done without direct interaction with a human user, so response time is not critical.

b) Interactive systems involve direct interaction with a human user (e.g. computer games, word-processors, etc.)

c) Real-time systems control mechanical systems, and must respond to events within tight time constraints. (E.g. you would be very unhappy if your car took 5 seconds
to start to accelerate after you press the gas pedal.).
(Note: sometimes these are called hard real time systems, and the term soft real time systems is used for interactive systems where the time constraints aren’t as
inflexible.)
3. Software projects can also be classified into one of several categories:
a) “greenfield” projects - Those that involve starting to develop a system from scratch.
b) evolutionary projects - Those that involve modifying an existing system.

c) framework projects. - Those that involve building most of a new system from existing components, while developing any missing details.
Though there are profound differences between these three types of projects, the same basic approach is used for each.
III. Major Activities in Software Development; The Software Lifecycle. [START AT BEGINNING OF SECOND DAY ON TOPIC - AFTER
STUDENTS HAVE DONE READING ]
A. What were the major points in the reading in Chapter 1 of the book? ASK
We will focus on two issues today:

1. The things that must be done in developing a piece of software (or, indeed, in any problem-solving process that uses an engineering approach)
2. The notion of a systematic process for carrying them out.
3. It is important to keep the distinction between these two in mind. Certain things need to be done, though there might be vastly different frameworks for carrying
them out.
B. Discuss quick check questions a-b in the book.
C. The development of any piece of software involves a number of kinds of activity. At one point, it was common to think of these as discrete steps in the software
development process. Though modern OO development approaches do not view them this way; it remains the case that there are certain things which need to be
done. Most of them were discussed in Table 1.2 on page 6 of the book.
ASK

1. Establishing Requirements - at some point in the process, it is vital is to spell out exactly what is needed.
a) It is very easy to get this part wrong. Some of the worst software disasters that have occurred in the industry have resulted from misunderstanding of what is
really needed.
PROJECT: “Tree Swing”

b) Often, requirements are formalized in terms of some sort of requirements document that explicitly lists the requirements. Sometimes this includes the creation of a
specification for the software - which is a formal statement of what the software will do, and may serve as a legal contract between the software developer and the
client. (This is particularly the case with custom software; rarely true with generic software.)
(1) One of the strengths of the textbook for this course is that it is built around a continuing example: a case study called “Wheels” based on software to support a
bicycle-rental business. An example of a (fairly informal) statement of requirements for this system is found on page 305 of the book
PROJECT text page 305

(2) We will also be referring to two other online examples throughout the course. One is a fairly simple system for maintaining a personal address book.
PROJECT Requirements for AddressBook system

(3) The other online example is a bit more complex - software for controlling an ATM
PROJECT Requrements for ATM System
2. Analysis activities focus on understanding the need
a) In object-oriented software development, probably the most important analysis activity is the identification of use cases, which are formal statements of how the
software will actually be used, and which serve to drive the whole rest of development.

b) Industrial-strength analysis requires expertise both in software development and in the problem domain - e.g. doing analysis for a particular business domain
requires business expertise in that area; doing analysis for software to be used to control laboratory instruments requires scientific expertise, etc. We will discuss this
some, but not at great length.
4
 3. Design - here the goal is to determine how the requirements are going to be met. Design is a broad area that encompasses a large number of issues, like:
a) System design is typically part of creating an embedded system - the partitioning of functionality between hardware and software. (This is usually not an issue
with custom or generic software.)

b) User interface design is typically part of creating custom or generic software - how will users interact with the software? (This is usually not an issue with
embedded software.)

c) Software structure (architecture) - how will the overall task be broken up into component parts?
d) If the software uses a database, then the database will need to be designed. (This is primarily an issue with data-processing software)
e) Design (called detailed design) is also a part of the next activity. Design will be a major emphasis of this course
4. Implementation refers to actually translating the design into reality. In the case of software, this involves:
a) Detailed design of the individual components identified in the overall design phase (e.g. the individual classes in an object-oriented design)
b) Coding the design in a suitable language (e.g. Java).
This was the focus of CS112, but more advanced programming concepts will also be considered in this course.
c) Testing each component as it is implemented
d) Integrating the various components together, and testing the result.
5. Installation and Maintenance
a) Installation includes everything needed to support the use of the software by the users, including documentation and training.
b) Once the software is delivered by the developer to the client, it is put into use by the users. Frequently, this leads to the discovery of the need for changes.
Software maintenance refers to the activity of modifying an existing piece of software.
(1) Maintenance is of three general types:
(a) Corrective maintenance - fixing errors that were not caught before the software was delivered - i.e. to make the software fulfill its original requirements.
Example: The program crashes or freezes when a certain feature is used in a particular way, or the result produced by a certain operation is incorrect or incomplete

(b) Adaptive maintenance - dealing with changing requirements. As a piece of software is used over time, external changes in the environment in which it is being used
may change the tasks the software is required to perform
Example: Tax return preparation software must undergo adaptive maintenance whenever the tax code changes (i.e. most election years!)

(c) Perfective maintenance - adding new features not part of the original release, or improving the user interface.
(2) Note that software maintenance is quite different from hardware maintenance.
(a) Software doesn't wear out. (There is no such thing as “bit rot”).
(b) The purpose of maintenance of a mechanical device such as a car is to bring it back to its original condition when delivered. Software maintenance involves
improving the condition of the software in some way.

c) The table in the book book referred to this stage simply as “installation” because significant maintenance often gives rise to a whole new project.
6. Though not generally regarded as a separate stage, we also need to consider Quality Assurance - also known as Verification and validation
- ensuring that the resulting software is built correctly (verification) and does the right thing (validation).

a) Sometimes there is an activity at the end of development called “testing”. While testing is a major means of doing verification and validation, it is not (and should
not be) the only means of doing verification and validation.
b) The fundamental concepts of quality assurance should pervade the entirety of a project - not confined to a burst of testing at the end of development.

7. Though not properly a stage in the creation of software, we should note that there is an end of life for any given piece of software, commonly called retirement or
obsolescence, when a particular piece of software is no longer maintained and stops being used. This occurs when either
a) The original need for the software no longer exists
b) It is expedient to develop a whole new piece of software rather than continuing to maintain an old piece of software.

5
D. We also need to consider the notion of process, which has to do with how we organize the various things that need to be done.
1. One approach is referred to - somewhat tongue-in-cheek - as “build and fix”.
a) This is a totally non-systematic approach.
(1) One begins work on writing code almost right away. Some analysis and design may be done as needed, but it is not uncommon for someone to write code
without really understanding what he/she is doing.

(2) Once a draft of the code exists, it is tested. Problems are identified and fixed - which in turn gives rise to new problems ...
(3) The process is continued until the product is judged satisfactory.
(4) The dominant attitude is epitomized by the words of a project manager who was cited in a talk I heard - “We’re going to have a lot of debugging to do on this
project, so we’d better get started coding as soon as possible”
b) Problems with this approach? ASK
c) Can you identify with this approach in terms of your prior experience with programming projects in CS112?
ASK
Note that, while build and fix may be an appropriate model for introductory programming projects, it quickly becomes a very bad idea for projects of any size - whether
school projects or in “the real world”

2. At the other extreme, one alternative is to follow a fairly strict sequence: first requirements are identified, then analysis and design are done, then the design is
implemented, and then the finished product is tested (though testing is done throughout the process as well).

a) In this model, the various things that need to be done are regarded as sequential steps. Each is done to completion before we move on to the next activity; and once
we move on, we avoid going backward if at all possible. This approach is often called the waterfall model, because just as water goes down a waterfall but never
goes back up, so the process aims to carry out each stage and then move on.

b) Though this approach can be very efficient, it runs into some serious problems of its own. What are they?
ASK.

(1) It is often very hard to fully understand the requirements for a piece of software early in its development. Missed requirements are quite common, even when an
effort is made to do a thorough job of requirements analysis before moving on to the next phase.

(2) It is not possible, in practice, to carry out a significant software development process with a totally one-way flow of activity. Sometimes later work necessitates
clarification of issues considered earlier.

(3) Nothing is available for use until the end of the process, which can one or more years from start to finish. This can be years!

(4) Changes in the external environment can result in changes to the requirements for a piece of software. (Example: years ago I developed a software system for one
aspect of the work of the registrar’s office which, among other things, had to keep track of student grades. While I was working on the project, the faculty voted to
change from straight letter grades (A, B ...) to plus-minus grading (e.g. A, A-, B+, B ...)

c) The waterfall model is sometimes called the “traditional waterfall model”, because there was a time when this model was strongly advocated as the right way to
produce quality software. It was, at the time it was introduced, a major advance over the prevalent “build and fix” approach.

3. Recognizing the difficulty of fully capturing requirements, many projects are done now using iterative, incremental development. This is not a single model, but
rather a family of models.

a) In incremental models, after some initial analysis and design, a subset of the complete functionality is implemented, and then additional capabilities are added
incrementally. (Indeed, in many cases the earlier version can be used even as it is being extended.)
These models are called incremental because they grow the software by increments, rather than trying to implement everything at once; and they are called iterative,
because they repeat the basic life-cycle activities for each increment.
b) An incremental approach has at least three major advantages:

(1) The client gets to begin making some use of the software fairly early, rather than having to wait for everything to be completed.
(2) Experience with using the first part of the software implemented can help to refine the requirements for subsequent parts.
(3) A significant disadvantage is that an incremental model can degenerate to build and fix or an opportunistic approach if the developer is not careful. The key lies in
planning what features are to be developed for each increment.

4. Carrying this futher leads to a family of approaches known as agile approaches.

6
a) These approaches are sometimes referred to as “low ceremony” approaches, because there is little emphasis on any sort of formal documentation.
b) Agile approaches have been very successful for projects characterized by changing or hard to pin down requirements.

c) Agile approaches are generally not used with large scale projects, or ones that are life-critical, though.
d) A significant danger with agile approaches is that they can degenerate to build and fix.

5. As the book points out, Object-Oriented projects tend to decouple the schedule of a project from specific tasks. In the OO world, it is common to talk about project
phases: inception, elaboration, construction, and transition. Although no effort is made to limit specific activities to specific phases, it is common to find that early
phases (inception and elaboration) tend to mostly focus on requirements and analysis (with some design), while construction tends to focus on design,
implementation and testing and transition focusses on installation activities.
Discuss quick-check questions e-i from the book
E. To give you practive with these activities, you will do a single, semester- long project.
DISTRIBUTE, GO OVER PROJECT HANDOUT
This semester project will involve you in activities of all these kinds
1. A fair amount of the requirements work has already been done for you
- there is a quite detailed statement of the system requirements in the project document. (In a real project, requirements elicitation would be a major activity early
in the project.)
2. Use case development (milestones 1-1, 2-1) is an analysis activity.
3. Design activities:
a) The development of a class diagram (milestone 1-2)
b) You will do some user interface design for milestone 1-3.
c) CRC cards (milestones 1-2, 2-1)
d) Sequence diagrams (milestones 1-3, 2-1)
4. Coding (milestones 1-4, 2-2, and 3-2) is an implementation activity.
5. Though you won’t deal with installation issues per se, iteration 3 will give you experience with a key issue involved in maintaining someone else’s work - namely
figuring it out!

6. Test plan creation and execution (milestones 2-3, and 3-2) are verification and validation activities.
7. Your software will no doubt be retired to a hallowed spot on your server volume when the end of December rolls around. (I don’t actually have a contract to sell
your projects to a local video store and get enough money to go to Bermuda for Christmas break :-) )
8. What model are we using for the course project?
ASK