Location:
[CPSC 333]
[Listing by Topic]
[Listing by Date]
[Next Topic]
About This Course
This material was covered during lectures on January 8-10, 1997.
The lecture began with the claim that ``much of what you know about
software development is incorrect (sort of).''
This means that the experience of participating in an undergraduate
course in programming, or even of doing an entry-level job in
programming, differs substantially from the development and
maintenance of complex software in a commercial or industrial setting
- so that some of the conclusions you might make about software
development after participating in an undergraduate programming course
are invalid.
-
Requirements for software are thoroughly specified when you're
given a problem to solve, and they almost never change while you're
working on it.
-
You are expected to do a small amount of design, write code, and then
submit the result for assessment; your responsibilities almost always
end after that (and you move on to another problem).
-
You are generally required to work alone; you're ``cheating'' if you
work in a group without being told first that this is permitted.
First, it should be noted that ``commercial software
development'' is very diverse, so that almost no statement made here
will apply in every case. However, most of the statements that follow
are valid for projects involving complex software, that is either
being developed for a single client or is to be sold commercially,
provided that it's too large to be developed by a single person, and
provided that this software is to be used and maintained for a period
of years or decades - as is frequently the case.
- Requirements for software are not well specified
when software is requested. You might begin development of a large
piece of software with a problem description that is only one or two
paragraphs long.
- Requirements are often so complex that no single person
understands all of them. Furthermore, the software might be requested
or (potentially) used by a group of people that have conflicting or
contradictory desires. Therefore, requirements analysis will include
discussions with a group of people, and can involve determining
priorities that can be made in order make choices or tradeoffs.
- Requirements will almost certainly change over
time. Frequently, one or more ``prototypes'' of software are developed
during requirements analysis. The experience of working with a
prototype often causes ``customers'' or potential ``users'' of
software to consider issues they'd have overlooked otherwise, or
sometimes for them to change their minds about interface details, and
so on. Later on - after software has been delivered and used for some
time - additional useful functions may be requested, there may be
requests to extend existing ones, the underlying hardware and
operating system may change (requiring the software to be ported from
one platform to another), and so on. All of these changes can be
considered to be ``changes in requirements.''
- Maintenance is extremely important - it is frequently more
expensive than all the other development activities
combined. Unfortunately, maintenance is almost never conducted by the
developers who developed the software in the first place, and the
original developers are often unavailable for consulation when
maintenance is to be performed.
- The responsibilities of a software developer may include
- requirements analysis and specification
- software design
- coding
- testing
- maintenance of software
With the exception of ``coding'' and, to some extent, ``software
design,'' these are things that haven't been introduced in the courses
that are prerequisites for CPSC 333.
This list is not complete; it only includes activities that will be
considered in this course or that have been considered already in
prerequisites. Coding, and maintenance, are frequently performed by
junior developers, so that developers often (but don't always) find
themselves less involved with coding as their careers progress. As
mentioned above, maintenance can be more expensive than all the other
development activities combined.
- For complex software, each of the above activities is too
demanding or complex to be performed by a single person. As a
developer, you will spend much of your time working as part of a
development group, rather than working on your own.
- Since maintenance can be so much more expensive than the other
activities, development methods can be considered to be ``successful''
if they decrease maintenance costs - even if they increase the costs
of other activities. The methods for requirements analysis and
specification introduced in this course certainly
will delay the time before coding can begin, and
might increase the cost of development excluding
maintenance - but (since they can decrease
maintenance costs) they can be valuable anyway.
- Complex software always contains errors or bugs
when it is being developed, and some of these errors are not
discovered and corrected until years after the software has been
delivered. The cost to correct an error increases -
drastically - as development proceeds, so it is a
good idea to examine requirements specifications, design documents,
and code carefully, as soon as possible, in order to look for and
correct errors, and to test software thoroughly, as soon as possible,
as well.
- One reason why requirements analysis and
specification is important is that, as explained above, the
original developers of software are frequently unavailable when
software is being maintained. Code isn't usually sufficiently
``self-documenting'' so that it can be easily (and safely) changed
without additional information, so a carefully prepared (and
maintained) specification of requirements can be useful throughout the
lifetime of the software it describes. Another reason why requirements
analysis and specification is important is that the specification is
extremely useful for test design; see the comments about the cost of
finding and correcting errors given above!
- The demand for new software and for the maintenance of existing
software has exceeded our abilities to supply it for the past few
decades, and this is still the case. Development practices are
improving, and this helps. However this problem persists, and it
should be expected that development methods will continue to change,
in order to try to deal with it. For example, it has been recognized
for some time now that developers must learn to reuse
software (as well as design documents, parts of specifications, etc.)
much more effectively than they have in the past, if we're ever to
meet existing and future demands. Newer methods, such as
object-oriented and formal methods, are partly motivated by efforts to
increase (safe) software reuse. However, this is still not as well
understood as we'd like it to be, and it's to be expected that methods
will continue to change as our understanding of ``software reuse''
improves. Therefore: it is unreasonable to expect that the methods
introduced in this course will still be in use when you graduate
without being changed, since the methods in use when
you graduate are somewhat unpredictable, and might not exist yet at
all. Part of your job as a professional developer of software will be
to keep yourself informed of changes in methods for software
development.
- Finally, software quality has many different
aspects, or relates to many different things, including correctness,
efficiency, maintainability, and useability - not
generally in order of importance! Experience suggests that it is
not generally possible to ignore ``quality'' during
development and try to add it in during development. Instead, it is
generally necessary to be considering quality throughout development,
by developing a complete and useful requirements specification and
then designing and implementing
``quality software.''
There have now been quite a few attempts to define software
engineering. Here is an early (but useful) definition given
by Fritz Bauer:
Software Engineering is the establishment and use of
sound engineering principles in order to obtain
economically software that is
reliable and works efficiently on
real machines.
As an exercise, you should reread the material that precedes this (and
what follows it), and see how it relates to this definition!
We will consider the software development cycle from the perspective
of a developer of software (rather than the perspective a manager,
customer, user, etc.). Requirements analysis and specification,
software design, and testing will be emphasized. Very little will be said
about maintenance because of lack of time, and because this involves
many of the things that will be introduced when requirements analysis,
design, and testing are discussed. Very little will be said about
coding, because this has already been discussed in CPSC 231, 233, and
(to some extent) 331.
Sound development principles will be introduced and
discussed. It's likely that these principles will endure, even though
development methods are changing.
Methods for requirements analysis and specification,
software design, and testing will be introduced. Some time will be
spent on methods that might be useful for the maintenance of old
software (chiefly, ``structured'' or ``function-oriented'' methods),
newer methods that are frequently recommended for the development of
new software (chiefly, ``object-oriented'' methods), and methods
that aren't yet widely used in industry but that might be used more
extensively in the future (in particular, the course will include an
introduction to formal methods for the specification of requirements
and for program verification, if time permits).
Some of the material introduced in this course will likely be seen
again in senior computing courses. For example, some of the
requirements specification models and methods (notably, state
transition diagrams) may appear again in CPSC 481; entity-relationship
diagrams may be used in CPSC 461. You will be participating
in a development project as part of a large group in CPSC 451, and may
be applying several of the methods introduced in CPSC 333 when you
work on that course's project.
This is sometimes called function-oriented
development - or process-oriented development. The
version that will be discussed in this course might even be called
data-oriented development, since we will be
discussing the design of a relational database (first) as part of
this.
Stored data may be stored in either a set of files,
or in a relational database.
Programs will consist of many independent functions, such that each
has a clearly identified task to perform. Ideally, none of these
functions has side effects, no function will perform more than one of
these tasks, and no single task will be split among several functions.
C, Pascal, or Modula are programming languages providing the features
needed to code software developed using this paradigm. If you're
``lucky,'' then the older software you get to maintain will have been
developed this way.
In object-oriented software, data is ``encapsulated'' along with
functions to form objects. The data inside these
objects can only be accessed or modified (by the rest of the system)
through the object's interface. Thus,
implementation details are hidden from the rest of
the system, and can be changed as needed in a relatively safe way.
Objects with similar characteristics belong to the same
classes.
Software consists of multiple objects that communicate, and cause work
to be done, by sending messages from one to another
(again, using the objects' interfaces).
Inheritance mechanisms and
templates allow large software components to be
modified and reused more easily than is possible using other
development approaches. This allows developers, development teams, or
businesses to produce and refine their own software
libraries as they work on projects, reducing the amount of
software that will be needed to be developed ``from scratch'' in the
future. It also allows software to be developed more easily in an
incremental fashion - so that (for example) a small
number of functions can be supported initially, and extended or added
to later, making it possible for working (sub)systems can be assessed
and refined before work on other subsystems have started.
C++, Java, and Smalltalk are all ``object-oriented'' programming
languages that support many of the features needed for this kind of
development.
Three development activities will be considered in this course in some
detail:
- Requirements Analysis and Specification
- Software Design
- Software Testing
For each of these topics we will begin by considering
goals and principles for this
activity. For the first two topics, we will consider methods for
performing the activity as part of structured
development as well as object-oriented
development. This may be more difficult for the third topic, since
not much has been written yet about ``object-oriented testing,'' but
testing objects will also be discussed, if possible.
If time permits, then the course will end with a brief introduction to
``formal methods'' for the specification of requirements and for the
verification of programs.
Location:
[CPSC 333]
[Listing by Topic]
[Listing by Date]
[Next Topic]
About This Course
Department of Computer Science
University of Calgary
Office: (403) 220-5073
Fax: (403) 284-4707
eberly@cpsc.ucalgary.ca