The purpose of this document is
a) to explain the learning goals of the
course in more detail than what can be done in the study plan
b) to explain the relationship between
the course and previous courses that it builds upon, in particular TDT4140
Software Engineering and TDT4145 Data modelling and database management
systems, and also briefly explain the relationship between the course and 4th
year courses that build upon it
c) to explain how the contents of the course
fit together to support the learning goals. This latter part is needed because
the reading materials for the course is composed of excerpts from various
sources, rather than being based primarily on one core textbook.
1.
Learning goals
An information system is a system for
processing, storing, and communicating information. This definition, however,
leaves room for many different interpretations. For instance, we could
distinguish between a computerized
information system, encompassing only the automated parts, and an organizational information system, which
also encompasses the humans around the computers and the information processing
and communication that they perform manually. This course addresses both these
levels. The crucial point for an organization would be that their overall
information processing is effective – whether automated or manual – not that
the computerized information system is “good” as such.
The overall learning goal of this course is to gain knowledge of the fundamental principles
of how to develop information systems, and practical skills in some selected
systems analysis techniques. This can be broken down into several more
detailed learning goals:
1) ability to analyze the current
situation in an organization (the “as-is” situation) and assess whether there
is a problem with their information system (whether automated or manual)
2) ability to suggest a new or improved
information system (the “to-be” situation). This requires abilities on several
levels:
a) high level strategic considerations
about information systems (e.g., What are the key goals that the organization
wants to reach? Where does the organization want to be ten years from now
concerning IT support for its information processing?),
b) writing precise requirements specifications
for the information system to be (both concerning the computerized IS and/or
improving the manual business processes), and
c) making build vs. buy decisions (or
partly buy, partly build), and being able to assess competing products or
competing developers when the to-be system is to be realized
3) knowledge of different types of information
systems and what is typically available in the marketplace. (This is necessary
for instance to be able to make build vs. buy decisions – if you do not know
what is available, you will not know that you could buy and instead end up
building, possibly at a much greater cost)
For several of these learning goals (in
particular 1 and 2b-c) modelling is
an essential skill. Computerized information systems may consist of several
million code lines, which should again play effectively together with the even
more complex doings of humans, possibly in organizations with thousands of
employees. If these systems are described only in prose (e.g., natural
language), one will easily lose overview, and neither is it possible to go
directly to coding except in very limited cases. While prototyping is a
well-known technique in software engineering, it may not always be appropriate
in a wider IS analysis context – for instance, a prototype may be a wasted
effort if the best solution turns out to be purchase of a package solution or
an improvement of manual business processes, rather than development of a new
computerized IS. There are hundreds of modelling techniques available in the field
of information systems, and obviously, our course cannot cover all these.
Hence, our learning goals with respect to modelling have to be more restricted:
4) knowledge of, and practical skills with, some
of the most common modelling techniques in IS analysis, with particular focus
on techniques not covered in previous courses. The most common types of models
in IS analysis are:
a) (business) process models (e.g.,
data flow diagrams, EPC, IDEF0, BPMN,
UML activity diagrams)
b) information models (e.g.,
ER-diagrams, UML class diagrams)
c) use cases
Since b and c have been covered in
previous courses you have taken (Databases and Software Engineering), the
primary focus in this course is on process models
So, having summed up the learning goals, who is this course for? It should be
useful for you if, in your future worklife, you take
part in IS development projects or make decisions about IS purchase in an
organization. In particular, it will be useful for you if you ever find
yourself in one of the following roles:
- consultant
/ IS analyst (whether internal or external) to
- assess
an organization’s current IS solution
- improve
an organization’s business processes and deciding on the optimal boundary
of automation
- make
build vs buy decisions, and in case of buying:
assessing competing products; in case of building: assessing competing
developers
- IT
manager
- requirements
engineer
- any other stakeholder in an IS development
project, e.g., a representative for employees who will be affected by the
new IS, a domain expert contributing requirements, or a designer,
programmer, tester or maintainer of computerized information systems. Even
if this course focuses on what is traditionally termed the early phases,
it is also relevant for students whose interests are more towards the
later phases – e.g., to do well as a programmer or tester, you must also
be good at interpreting requirements specifications, so that you know what
to implement or test for.
2. Relationship to other
courses
Here we concentrate on the courses that are
most closely connected to this course, namely TDT4140 Software Engineering and
TDT4145 Data Modelling and Databases. Both these courses also have considerable
focus on modelling and methodology for developing something. However, TDT4175
Information Systems is essentially different from these two courses in two
respects:
- different
phase focus: While the other two
courses have more focus on the later phases (design, implementation,
testing), Information Systems has more focus on the earlier phases, such
as IT-strategy, prestudy
/ problem analysis (i.e., understanding the organization’s need) and
requirements specification (specifying WHAT the system should do, but not
going into the HOW). True, the textbook of the Software Engineering course
does contain one chapter about Requirements, but this is a topic that
could easily mandate an entire textbook of its own. A 30 page chapter can
thus only be a quite shallow introduction. Moreover, the cross-course
project that is done in these courses starts with given requirements, thus
necessarily exposing the students mainly to design, coding and testing –
as well as project planning.
- different scope:
As follows from the names of the courses, Software Engineering and
Databases are both courses for developing software (as a database is one
particular kind of software), i.e., they typically deal with problems
where it is assumed that software is the solution, and suggests methods
for developing that software. (The same, by the way, can partly be said of
the course in Human-Computer Interaction, as this concerns itself with the
design of user interfaces, which is an essential part of most software
systems) The Information Systems course addresses a wider scope, where
- it
is not necessarily given that the solution is software (and hardware to
run that software) – it might also be to achieve more effective
information processing by improving the manual business processes of the
organization
- even
if the solution is (partly) to automate some business processes by means
of software, it is not given that the solution is to develop that
software – it might also be to buy some off-the-shelf software that can
be used directly, or some package IS solution that can be configured or
adapted to fit the organization’s need
- even
when the solution includes the development of some new software from
scratch, the system that we
teach you how to develop is not just that software, but the larger organizational information system
that also includes the human activities around the computerized system
Of course, this does not mean that we consider
Information Systems to be a better course than Software Engineering or
Databases, only that it is different. Indeed, these courses supplement each
other, and should all be considered equally important for a future IT
specialist.
Later courses that build on Information
Systems:
Again, we concentrate on the most clearly
related courses:
- TDT4290 Customer-driven
project: is
the chance to practice some of the stuff which is learnt only in theory in
the Information Systems course, performing a full project from prestudy and requirements specification through coding
and testing, with a real customer who has a real problem to be solved.
- TDT4250 Modelling of
Information Systems: takes a more theoretical perspective to modelling than what can be
done in the introductory Information Systems course, categorising
modelling languages, discussing quality of models and languages, and
presenting some new modelling techniques and modelling perspectives not
covered in previous courses.
- TDT4215 Document management and
text mining: deals
with content management systems (systems for managing huge collections of
documents) and techniques for eliciting knowledge from these systems.
- TDT4245 Computer supported
collaborative work: presents CSCW systems, which is one
particular type of information system
- MNFIT282 Digital libraries: presents digital libraries,
which can be considered another type of information system.
- MNFIT364 Systems development,
work and organizations: discusses the organizational and human
aspects of systems development
3.Concluding remarks
Technological progress happens in the
intersection between organizational need and
technological opportunity. I.e.,
there are many solutions that might be technologically possible, but which does
not satisfy any need, and there are also many potential needs that cannot be
satisfied, at least not with the current technology. Changes in needs inspire
changes in technology, and on the other hand, changes in technology may also
change your needs (for instance, your competitor acquires new technology,
therefore you feel you have to do it too)
To be a good IS analyst,
you need sound knowledge about both these topics. If you do not know what IS
technologies are currently available, you will not know whether a given need
can be fulfilled within reasonable cost or not. On the other hand, if you are
not able to analyze organizational needs, all the
world’s knowledge about current technologies will not help you – you will still
not be able to put these technologies to effective use in a given organization.
The reading materials of this course can thus
be divided in two major parts:
- techniques
for analyzing needs and specifying IS requirements
- knowledge
about available IS technologies
There is more focus on the needs part than the
technology part. This is a conscious choice: Technologies change quickly – the
IS package solutions you will work with ten years from now might easily be
quite different from anything we would be able to cover in this course. The
basic principles and methods for analyzing needs and specifying requirements,
however, are more long-lived. For instance, data flow diagrams and ER diagrams
were invented in the 70s and are still used in many IS projects all around the
world. And even object oriented analysis and use cases – although “new” in
comparison – are more than ten years old now. Hence, a course primarily
focussing on the needs side is a better basis for life-long learning than a
course primarily focussing on the technology side. Besides, many of the other
courses you have taken during this study have a stronger focus on the
technology side, so a different focus in the IS course also makes sense from a
point of completeness and balance of the study programme as a whole.
Although this course will hopefully give you
valuable knowledge, you must not think that one course is enough to master the
complex field of information systems. The knowledge from this course alone will
not make you a big-shot consultant, champion requirements engineer or brilliant
leader of a huge IS development project, partly buying and partly developing a
system with several million code lines for an organization with thousands of
employees. So first and foremost the course is a basis for learning more –
whether this be in some of the Master level courses you take, or through summer
jobs and later work-life. Anyway, we hereby wish you good luck with this course
– and with the future use of the knowledge you gain from it.
