ions and views (Section 4), characteristics of the development steps and processes (Section 5), varying concept of concept (Section 6) and need for restructuring and refactoring after IS deployment (Section 7). Section 8 concludes the paper. These different points of view give - at least partial - answers to our research problems: Why Information Systems modelling is difficult to teach? Why this topic is important to handle? In our
work we recognized problems in learning the principles of Information Systems modelling. If these problems are not understood, the software engineers’ skills are not at the appropriate level in industry. The paper could also be understood as a short version of the main lessons in Software Engineering (SE).
Software development is based on communication intensive collaboration. The communication covers
a variety of aspects: Communication between development team members in the same development
phase, communication between development teams in the transfer from one development phase to the
next one, and communication between a (wide) variety of interest groups. The authors have handled
the problems related to collaboration in t
The elements in Fig. 1 cover different collaboration parties (individual, team, collaborative teams (in the cloud), collaboration between collaborative teams (cloud of clouds) and unknown collaboration party (question mark cloud). The collaboration situations are marked with bidirectional arrows. Without going into the details (of the earlier paper) the main message of the figure is the fast growing complexity in collaboration situations (1*1; 1*n’; nk*n’k’*m’). In increasing amounts there are also unknown parties (question mark cloud; e.g. in IS development for global web use), which increases the complexity. The explicit or implicit (expected needs of unknown parties) communication is based on messages transferred between parties. Interpretation of the message is context-sensitive (i.e., in different contexts the interpretation may vary). The message itself is a construction of concepts. The conceptual model represents the structure of concepts from an individual collaborator’s point of view. An important source of misunderstanding and problems in collaboration is an inability to interact with conceptual models.
In this paper we concentrate on two important roles – the Systems Analysts and the customer
(variety of roles). The starting point is that the Systems Analysts are educated in ICT Curricula and
they should have a deep understanding of the opportunities provided by ICT in business processes.
The customer should present the deep understanding of the application area instead, and they are not
expected to be ICT experts. What about the Systems Analyst – should he/she also be expert in ICT
applications? We will leave the exact answer to this question open. Our opinion is that, first and
foremost, the Systems Analyst should be a model builder who is filtering the customer’s needs and,
based on abstractions, finally establishes a baseline as a joint view – from the point of view of all
interest groups - to the system under development. The joint view is based on communication between
different parties. The Standish Group has reported communication problems between Systems
Analysts and users - lack of user involvement – to be one of the important sources of IS project
failures (Chao
Information System development is based on two different views, the static one and the dynamic one, having a parallel evolution path. All this must be recognized as a whole already at the beginning, including the evolution of requirements through the development life cycle. Figure 2 illustrates flow in the “big picture” of modelling. In the upper level of IS development the approach always follows the principles of a “plan driven” approach, even in the cases where the final work is based on Agile or lean development.
In this paper we do not focus on the discussion of the current trends in software development models. The traditional plan-driven (waterfall model based) approach is used. It is an illustrative way to concretize the basic principles of the constructive approach in software development. The same principles fit in all approaches, from plan-driven (waterfall based) to agile, lean, component based, software reuse based etc. approaches. According to Figure 2 the Information System development has its roots in business processes (understanding and modelling). Business processes represent the dynamic approach to the system development, but also provide the means for the preliminary concept recognition and the operations needed to handle them. The conceptual model is a static structure describing the essential concepts and their relationships. The Information System development continues further by the specification of the system properties (to define the system borders in the form of external dependencies) and transfers the real-world concepts first into the requirement level, and further to the architecture and implementation level concepts. Separation of the structure and behavior is not always easy; people are used to describing behavior by static terms (concepts) and static state by dynamic terms (concepts).
The role of “work product repository” is not always recognized. The development flow produces necessary work products, which are used by other parts of the development flow. Conformity between work products must be guaranteed, but is not always understood clearly. Conformity problems, both in the horizontal (evolution path of work products) and vertical (dynamic vs. static properties) direction are typical.
The IS development is based on abstractions – finding the essence of the system under development. Figure 3 illustrates the role of abstractions in Information Systems modelling.
The Information System is the representative of the real-world (business) processes in the “system world”. The model (set) of Information System describes the real-world from different points of view (viewpoint) and a single model (in the terms of UML: Class diagram, state diagram, sequence diagram, …) provides a single view to certain system properties. Information System is an abstraction of the real-orld covering such structure and functionality that fills the requirements set to the Information System. Such real-world properties that are not included in the Information System are represented by the external connections of it or excluded from the system implementation (based on abstraction). As seen in Figure 3, the starting point of the model is in the real-world processes, which are partially modelled (abstraction) according to the selected modelling principles; both the static and dynamic parts are covered. The individual models are overlapping, as well as the properties in the real-world (processes). This establishes a need for checking the conformity between individual models; this is not easy to recognize. An additional problem related to abstractions is to find the answer to the question “What should be modelled?” and “How to fill the gaps not included in the models?”. No clear answer can be given. However, usually the problems in Information Systems relate more to the features that are not modelled than to those that are included in the models. Models make things visible, even in the case that they include some lacks and errors (which are also becoming visible this way).
The Information System development covers a variety of viewpoints to the system under development. Structuring the viewpoints helps to manage all the details of the Information System related data as well as the dependences between these. In this context, we satisfy by referring to the widely used 4+1 View model introduced originally by Kruchten [Kruchten 1995], because it is referred to widely and was also adopted by the Rational Unified Process specification.
The aim of the 4+1 view model (Figure 4) is to simplify the complexity related to the different views needed to cover all the aspects in Information Systems` development; the relations between different views are not always clear. Views serve different needs: A logical view provides necessary information for a variety of interest groups, a development view for the software developers, a physical view for the system engineers transferring the software to the platforms used in implementation, and the process view to the variety of roles responsible for the final software implementation. Managing the conformity between the variety of views (models) is challenging. Again, to concretize the role of views in Information Systems modelling, we will bind them to UML (static path related) specifications: Logical view – the main artefact is a class diagram; development view – the main artefact is a component diagram; physical view – the main artefact is a deployment diagram; process view - the artefacts cover a variety of communication and timing diagrams. Dynamic path decisions are specified by a variety of specifications, like state charts, activity diagrams, sequence diagrams and timing descriptions.
One detail not discussed above is the role of non-functional (quality) properties, assumptions and limitations. Without going to the details, we state that they are changing along the development work to functionality, system architecture, a part of the development process, or stay as they are to be verified and validated in qualitative manner.
The purpose of the Information Systems development life cycle models is to make the development
flow visible and to provide rational steps to the developer to follow in systems development. There
exists a wide variety of life cycle models – from the waterfall model (from the 1960s) as the original
one to the different variants of it (iterative – e.g. Boehm’s spiral model), incremental, V-model and,
further, to the approaches following different development philosophies (e.g. Agile, Lean);
We selected the V-model to illustrate the development path for two reasons. The origin of the Vmodel is in the middle of 1980s. In the same issue, both Rook [Rook 1986] and Wingrove [Wingrove1986] published its first version, which has since been adopted by the software industry as the main process model for traditional (plan-driven) software development. Firstly, it separates clearly the decomposition part (top-down design) and composition part (bottom-up design) in the system evolution, and, secondly, it shows dependences between the early (design) and late (test) steps. An additional feature, discussed in the next Section, relates to the evolution of the concept of concept along the development path.
The development activity starts (Figure 5; see also Figure 2) from business use cases (processes) that are further cultivated towards user requirements (functionality) and the corresponding static structure. In the top down direction (left side) the system structure evolution starts from conceptual modelling in the terms of the real-world. These are transferred further to the structures representing the requirements set to the Information System (in terms of the requirements specification). Architecture design modifies this structure to fill the requirements of the selected architecture (in terms of the architecture) having focus especially on the external interfaces of the system. The detailed design reflects the implementation principles, including interfaces between system components and their internal responsibilities. Implementation ends the top-down design part of the system development and starts the bottom-up design. The goal of the bottom-up design is to collect the individual system elements and transfer them to the higher level abstractions, first to components (collection of closely related individual elements – in terms of the UML classes) and further to the nodes, which are deployable sub-systems executed by the networked devices. The bottom-up modelling includes the sketching and finalizing phases. An additional degree of difficulty in this “from top-down to bottom-up“ elaboration is its iterative character; the progress is not straightforward, but iterative, and includes both directions in turn.
Along the development path the abstraction level of the system is changing. This reflects also in the used terminology. This is illustrated in Figure 5`s middle part – concept evolution. In the beginning of the development work the modelling is based on the real-world concepts (conceptual model); this terminology is also used in communication between the Systems Analyst and different interest groups. As a part of requirements specification these concepts are transferred to fill the needs of system requirement specification. The terminology (concepts used) represents the requirements level concepts, which do not have (necessarily) 1-1 relation. In architecture design the concepts related to architecture decisions become dominant – i.e. the role of design patterns and architecture style become important. This may also mean that, instead of single concept elements, the communication is based on compound concepts. In practice this may mean that, instead of single elementary concepts (class diagram elements), it becomes more relevant to communicate in the terms of design patterns (observer-triangle, proxy triangle, mediator pair, factory pair, etc.) or in the terms of architecture style (MVC solution, layers, client-server solution, data repository solution). The implementation phase brings the need for programing level concepts (idioms, reusable assets, etc.). To summarize the discussion, the communication is based on different concepts in different parts of the development life cycle – we call it the evolution of concepts.
Programs model real-life systems and are designed for real, currently existing computer hardware. But our real-life – our customs, habits, business practices and hardware are changing rapidly and our computerized systems should reflect these changes in order to perform their tasks better. Thus, software development is never finished – software should be modified and improved constantly and, therefore, should be designed in order to allow changes in the future. Because of that the design should take into account the need for future changes in a proactive manner; otherwise the changes become expensive and difficult to implement and cause quality problems. Proactive modelling is based on the use of interfaces instead of fixed structures, modifiable patterns in design, generalized concepts and inheritance instead of fixed concepts, the use of loose dependencies instead of strong ones, extra complexity in concept to concept relations, etc.
The most common are changes in program structure - structural refactoring, applying a series of
(generally small) transformations, which all preserve a program's functionality, but improve the
program`s design structure and make it easier to read and understand. Programers` folklore has
many names and indices for program sub-structures (design smells), which should be reorganized or
removed: Object abusers (incomplete or incorrect application of object-oriented programing principles),
bloaters (overspecification of code with features which nobody uses, e.g. Microsoft code has often been
called 'bloatware' or 'crapware'), code knots (code which depends on many other places of code
elsewhere, so that if something should be changed in one place in your code you have to make many
changes in other places too, so that program maintenance becomes much more complicated and
expensive). Structural refactoring generally does not change programs` conceptual meaning, thus, in
principle, it may be done (half)-automatically and many methods and tools have been developed for
structural refactoring [Fowler 1999; Kerievsky 2004; Ma
Cases of conceptual refactoring are much more complicated. Our habits and behavior patterns change constantly: we are using new technology that was not used commonly at the time of program design, i.e. when the conceptual model was created; increased competition is forcing new business practices; etc. All these changes should also be reflected in already introduced programs and, generally, they also require re-conceptualization of the programs or some parts of them. We will clarify this in the following examples below.
Microsoft, who have often been accused of coupling useful programs (e.g. the Windows OS) with bloatware and crapware, introduced in 2012 a special new service "Signature Upgrade" for "cleaning" up a new PC – you bring your Windows PC to a Microsoft retail store and for $99 Microsoft technicians remove the junk – a new twist in the Microsoft business model.
An even bigger change in the conceptual model of Microsoft's business practices occurred when
Microsoft introduced Windows 10. With all the previous versions of the Windows OS Microsoft has
been very keen on trying to maximize the income from sales of the program, thus the OS included the
subsystem "Genuine Windows" which has to check that the OS is not a pirated copy but a genuine
Microsoft product (but quite often also raised the alert "This is not a Genuine Windows! " in absolutely
genuine installations). With Windows 10 Microsoft changed by 1800 the conceptual model of
monetizing – it became possible to download and install Windows 10 free of charge! Even more,
Microsoft started to foist Windows 10 intensely onto all users of Windows PC and, for this, even
changed the commonly accepted functionality of some screen elements: in all applications clicking the
small X in windows upper right corner closes the window and its application but, contrary to decades
of practice in windowed User Interfaces (UIs) and normal user expectations, Microsoft equated closing
the window with approving the scheduled upgrade – this click started the (irreversible) installation of
Windows 10. This forced change in the conceptual meaning of a common screen element proved to be
wrong and disastrous to Microsoft. A forced Windows 10 upgrade rendered the computer of a
Californian PC user unusable. When the user could not get help from Microsoft's Customer Support,
she took the company to court, won the case and received a $10,000 settlement from Microsoft;
Microsoft even dropped its appeal [
Many changes in conceptual models of software are caused by changes in the habits and common practices of clients which, in turn, are caused by the improved technology they use. Once functioning of many public services was based on a living queue – the customer/client arrived, established their place in the queue and waited for his/her turn to be served. In [Robinson 2010] a case of conceptual modelling is described for designing a new hospital; a key question was: "How many consultation rooms are required"? The designer`s approach was based on data from current practice: "Patient arrivals were based on the busiest period of the week – a Monday morning. All patients scheduled to arrive for each clinic, on a typical Monday, arrived into the model at the start of the simulation run, that is, 9.00am. For this model (Fig. 6a) we were not concerned with waiting time, so it was not necessary to model when exactly a patient arrived, only the number that arrived".
This approach of conceptual modelling of a hospital's practice ignores totally the communication possibilities of patients. In most European countries, computers and mobile phones are widespread and used in communication between service providers and service customers, and this communication environment should also be included in the conceptual model of servicing. Nowadays, hospitals and other offices servicing many customers mostly all have on-line reservation systems, which allow customers to reserve a time for visit and not to rush with the requirement to reserve a time for the visit on Monday morning or staying in the living queue. A new attribute, Reservation, has been added to the customer object. The current reservation system is illustrated in Fig. 6b.
(a) In 2010 (b) Nowadays
Cultural/age differences can cause different variations of the conceptual model of reservation
systems. For instance, in Tallinn with its large part of older technically not proficient population
(sometimes also non-Estonian, i.e. have language problems) for some other public services (e.g.
obtaining/prolonging passports, obtaining of all kind of permissions/licenses) the practice of reserving
time has not yet become common. In the Tallinn Passport Office (https://www.politsei.ee/en/) everyone
can make a reservation for a suitable time [Re
Practical use of a reservations system sometimes also forces changes to the system itself. For instance, most of the doctors in Estonia, Finland and Slovenia work with reserved times. However, sometimes it happens that a customer who has a reserved time is not able to come. Medical offices require cancellation (some even practice a small fine if cancellation is not done in-time). In order to find a replacement, the office should be able to contact potential customers (who have a reservation for some future time). Thus, two more fields were introduced to the object model of the customer: Mobile phone number, Minimal time required to appear at the service. A new functionality was also added to the reservation system: if somebody cancels, the reservation system compiles a list of potential 'replacement' customers, i.e. customers, who have a future reservation and are able to appear at the service provider in time and the office starts calling them in order to agree a new reservation.
There is a lot of evidence that the most serious mistakes are made in the early phases of
software projects. Savolainen [Savolainen 2011] reports in her Thesis and studies (based on
the analyze of tens of failed software project data) that, in almost all the studied cases, it was possible
to indicate the failure already before the first steps of the software project (pre-phases, in which the
base for the project was built in collaboration between the software company and customer
organization). The errors made in early phasesare tend to accumulate in later phases and cause a lot
of rework. Because of that, the early phase IS models have high importance to guarantee the success
of IS projects. The Standish Group Chaos Reports cover a wide (annual) analyze of problems related to
software projects. The article of Hastie & Wojewoda [Ha
All projects (modern resolution) 2011 2012 2013 2014 29 % 27 % 31 % 28 % 49 % 56 % 50 % 55 % 22 % 17 % 19 % 17 %
The Agile vs. Waterfall results are opposite to the ICSE Conference presentation of Barry Boehm
The purpose of our paper has been to point out important aspects related to IS modelling. The following aspects are discussed: The variety of roles and their responsibilities in IS development; Understanding the big picture of the modelling is difficult; Understanding the abstractions is difficult; Understanding the role of the development path phases and their interrelations is difficult; Concepts are varying along the development life cycles; Understanding the views and the development flow is difficult.
In teaching IS modelling all this must be taken into account. The experience based realizations of these main problem categories cover at least the following aspects: Inadequate skills in using modelling languages – used in an incorrect way (e.g. including dynamic features in static diagrams – functionality in class diagrams; problems to understand what is a class and what is the connection between classes); Low motivation to make modelling – preference given to implementation and coding without modelling; In a teaching context, we never have the opportunity to solve real modelling problems; small sub-problems instead; Difficulties in understanding what is a dynamic and what is a static concept; Models are not complete descriptions of the system – what to leave out and what to include; what are essential concepts and what are not; how to fill the gaps; Business rules are difficult to understand, because students do not know the real application environment; Missing motivation to learn new approaches – “I already know” – syndrome; Expectations of the existing skills – in reality reset and relearn is needed because of the “antipattern” type of behavior; Models are overlapping and it is difficult to get the different views to conform; Models belonging to different abstraction levels are using different concepts – mismatch of conceptual thinking.
Our results are in favor with the analyze and studies discussed above. It is important to benchmark the existing studies and to transfer the “lessons learned” into study modules. The problem also is the fact that the IS modelling is a by-product as a part of other teaching topics and, finally, practicing it remains on the artificial level instead of focusing on the modelling of real (large) information systems. Our original aim was also to handle the topic “How to teach IS modelling?”, but this will be left for further studies that apply the findings of this paper in curriculum and course implementation design in different educational environments. Nevertheless, the authors, as well as other readers, have an opportunity that, on the basis of the research done introduces some innovative steps and solutions out of the box in their own teaching process what will be, together with the reached experiences, an added value to the present paper for the further studies. We also expect a valuable contribution from the discussion at the conference, while changing of the curricula and its implementation is always a demanding step. Why Information System Modelling is Difficult • 4:39