NTNU IME IDI

TDT4175 - Informasjonssystemer

 
Menu
  • Hovedside
  • Fagintroduksjon
  • Fagansvarlige
  • Forelesninger
  • Studentliste
  • Referansegruppe
  • Pensumliste
  • Øvinger
  • Gamle eksamener
  • Tutorials

  • Course introduction, TDT4175 Information Systems

    Course introduction, TDT4175 Information Systems

     

    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.

    1


    Redaktør: Instituttleder : Maria Letizia Jaccheri   Kontaktadresse: tdt4175-undass   Sist oppdatert: