TERM PAPER TDT MODELLING OF INFORMATION SYSTEMS, ADVANCED COURSE. Mirna Besirovic MTDT

Transcription

1 TERM PAPER TDT4252 MODELLING OF INFORMATION SYSTEMS, ADVANCED COURSE Mirna Besirovic MTDT

2 Table of content Introduction... 3 Case description... 4 Stakeholders... 4 The company - MAD... 4 The customer - LearnIT... 6 End users... 6 Case description... 6 Requirements... 7 Goals... 8 The Model... 9 Model stakeholders and users... 9 Purposes of the model... 9 Responsibility... 9 Communication and understanding Requirements Documentation Goals and strategies Model description and rationale Domains Organisation People Processes Location Goals Documentation Requirements Product Model Views Goal-view Documentation-view Project team-view Customer-View Matrix Person-role matrix Documentation-process matrix Requirements-product matrix Evaluation of the model Discussion of the model in relation to EA Model Experience References

3 Introduction This assignment is the term paper delivery in the subject TDT4252 Modelling of Information Systems Advanced Course. The paper contains a description of a case, models, modelling aspects and discussion around the models and their purpose. The case I have chosen to model is a project that develops mobile application for vocabulary learning. The case is fictive and made based on experiences I have gained in earlier projects, and some research around mobile applications and vocabulary learning. The models are made using GEM. A lot of the inspiration for this fictive case I have taken from earlier projects in two previous courses I have participated in. In the course design of graphical user interfaces we were a group computer science and design students with the task of making a mobile application for a Hobby, the focus was on human-centered design activities. And in: Software architecture, we were 5 computer science students making a game-application for Android. 3

4 Case description This section contains a description of all the stakeholders involved in this fictive project, roles, a bit about the development process in the company and a description of the case with its goals and requirements. Stakeholders This section contains a description of all the stakeholders involved in the case and what part they play in the project, thus all the people and organisation that have an interest in the application project. The company - MAD MAD (Mobile application development) is a consultant company specialised in making applications for all kinds of touch-based products for the most popular mobile operating systems, like Android, ios and Windows phone. The company was one of the first companies that started in the app-business and has several years of experience, as well as several experienced developers on their team. The main focus of the company is to make user-friendly applications, consequently the users of the applications and the customers are their main priority. In this project the project team from MAD consists of six people, where one is the project manager and the customer contact. Whilst the five others are developers, where three of them have special responsibility areas in the development, like overview of the GUI, testing and technology. Below I have listed the people involved in the development team for this specific project: Table 1: Project Team Project manager and customer contact Developer and GUI manager Developer and test manager Developer and technical manager Developer Developer Aaron Carter Amanda Clarke Emily VanCamp Mark Twain Daniel Grayson Emily Thorne The company has mainly used the waterfall methodology earlier in their development. But times are changing and lately they have gone for a more iterative development cycle. As their main 4

5 priority is user-friendliness, their development is characterised by a strong focus on the humancentered design activities. As the company's focus is user-friendly application for mobiles, and they makes applications for a customer, they are highly dependent on the fact that the users and customer like their product. Therefore it is essential that MAD to keep these stakeholders involved during the whole development process. Based on this MAD has in their development cycle divided the project into smaller periods of time, and in every period they perform 6 steps that are defined in The interdependence of human-centered design activities [1]. After the last step (step 6) they either continue their development or declare it finished, making it an iterative process.the figure is illustrated below and is from ISO 13407: Human-centered design processes for interactive systems. Figure 1: Human-Centered Design Process 5

6 The customer - LearnIT LearnIT is an organisation that sells products specialised in IT learning tools for schools. The organisation general manager is Andrew Vuitton, he is also the customer and their contact person for the project team from MAD, in this project. End users The end users for the application are teenagers in middle school, between the ages and have moderate to over average experience with touch mobile phones. In table 2 you can get an overview of them. Table 2: End users Troy Hanson Nathalie Johnson Andrew Jackson 13 years old 14 years old 16 years old Case description The customer LearnIT has hired MAD to develop a mobile application for vocabulary learning. The main intention for the application is that is should provide children from ages a fun and innovative way of learning norwegian, as well as other languages. To make the application successful the customer, LearnIT, are depending on that the end users get an app they understand, can easily use and that they need. They are also depending on that MAD is able to make the application that they have in mind. MAD depends on the client to be able to provide them with sufficient information of their needs and provide them with feedback during development. MAD is also dependent on that the end users provide sufficient enough feedback during the development. The application is supposed to be a kind of a multiplayer game-app, where you play against friends in a turn-based manner and answer questions and other tasks regarding grammar. Making the applicatoin both innovative, fun and educational. 6

7 Requirements Below is a list of some of the functional and nonfunctional requirements that the customer and MAD prepared for the application. Functional requirements A functional requirement is a requirement that defines a function of component. F1: The app sshould improve vocabulary skills F2: The app should provide the user with several tasks that can be solved F3: It should be easy to expand the application F3.1: Should be able to make it possible to add new tasks F3.2: Is should be easy to add additional languages F4: Should provide several modes to play in F4.1: should be multiplayer and turn-based. Like quiz game - competition F4.2: should also have training mode where you practice alone (not multiplayer) F5: The app should be compatible with latest mobile operating systems for ios, Android and Windows Nonfunctional requirements A nonfunctional requirement is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviour. Modifiability NF1: It should be easy for developers to expand the application with more features or quizzes Performance NF2: It should not take more than 2 seconds for moving from one screen to another Availability NF3: The application should not be down for more than 12 hours Usability NF4: The user should be able to start a multiplayer quiz game within 2 minutes from starting the application Testability NF5: 90% of the functions should be test covered 7

8 Goals Every project has an intention or goal. The goals that MAD has in this project are: To become recognised for the application and through that enter new markets. MAD hasn t much previous experience in making applications for schools. So by having LearnIT as a customer and making this new application they want to seize the opportunity to enter new markets like education. Offer the most user friendly application for middle schools MAD has in every project an internal goal of always offer their customers the best application in user friendliness. Deliver application to client before launch date MAD wants to deliver the application before launch date, showing their customer that they are conscious and serious. It is also important to keep deadlines regarding to time schedules and resources. 8

9 The Model In this section I will give an introduction to the models stakeholders and intended users and the purposes for the model. Model stakeholders and users The users of the model are the company MAD. They will use the model internally to control if the processes are effective and good enough, to evaluate their methods, control if they need to make some changes, if the customer involvement is good and so on. New employees are also users of the model. They can use the model to learn about the development methods used in MAD, how the company work, what kind of responsibilities the different roles have etc. The customer is also a user for the model, in the sense that he can use it to see how they as a customer are involved in the project, in which process. They can also use it to see if all their requirements are being considered in the final product, and to get a better understanding of how MAD works. Potential new customers can look at the model to get information about and a better understanding of how MAD works, and what their involvement would normally be. Purposes of the model There are several purposes for the making of the model. The model is created on behalf of MAD and will be used mainly by them and fulfill their needs. Beneath each purpose I will also put up some point or questions that will be useful when evaluating the model. The main purposes are: Responsibility It is important that the model can help clarifying in a project the different responsibilities for all the stakeholders. Thus showing all their roles and tasks in the process associated to the roles. For the customers it can be used to show them their involvement and role in the project. Through this the users of the model can easily see who the different stakeholders in the project are, where they come from (organisation and department). They can also easily detect roles that 9

10 have too many tasks or too few tasks, persons with too many or too few roles and their linked tasks etc. - Which positions has which roles? - Which tasks does a role have in the process? - Which person has which role? - How are the users involved in the project and process? - How are the customers involved? Communication and understanding Another purpose of the model is to communicate the development. It can communicate the project's structure and development to the customer(s), and in that sense give them an insight in how the company works. For the project team and head office of LearnIT, the model can give an overview of their development process and be able to give them an overview of how they work. They can figure out if the process is efficient enough and if the project team is put together the best possible way. For new employees at LearnIT the model can provide an insight in how the company carries out their projects and how they work. The model can also bee used as a guide for future similar projects in the company, and for potential new customers as a portfolio. - Communicate the development to the customer - Provide an understandable overview of the project for the stakeholders - Overview of the process and team for the head office - Portfolio for potential new customers Requirements The model can be used to control that all the requirements have been met in the final product. This is good for both the customer and the team, in the sense that they can control that all requirements have been considered. This is especially important if the product has many requirements and/or if new requirements are added during the project. - Are all the requirements realised in the product? - Are all requirements considered? 10

11 Documentation The model can give an overview of all the documentations made and used in the project, thus control that all necessary documentation is made and used. - Are all the necessary documents made during the project? - Are the necessary documentations used in the project? Goals and strategies Can use the model to get an overview of the goals, control that the goals for the project are realistic and that they have strategies. The model can also help in controlling that there are people or departments responsible for making sure the strategies are followed up and the goals reached. - What are the companies goals for this project? - What are the strategies to reach the goals? - Which departments are responsible for the different strategies? 11

12 Model description and rationale The model is made using GEM, Generic Enterprise Model. GEM is an object library that defines the classes of objects that are generic across a type of enterprise, such as manufacturing or banking, and can be used in defining a specific enterprise. I chose to use GEM because I felt that this was the language we had the most introduction to with examples, in the lecture. I also felt that it had all the relevant features for covering my case, as well as that it was easy to learn. The model has 9 folders. The largest folder is Vocabulary Learning App which is a placeholder for the different domains, and represents the whole project. The model has 8 domains: organisation, people, process, location, goals, documentation, requirements and product. Each domain is placed in a folder. In requirements I have placed two folders, making it easier to see that requirements consists of both functional and nonfunctional requirements. In the right upper corner I have collected all the buttons for when the user wants to see the different views and matrixes. I have made in all 5 views and 3 matrixes. Figure 2: Vocabular Learning App Model 12

13 Domains Figure 3: Organisation Domain Organisation The organisation domain is modelled in a relatively superficial manner. I have only chosen to model the aspects relevant in this case, that is the development part of MAD and the part of LearnITs organisation where their contact person is employed. The folder gives a nice overview of how MAD is put together from the development view. The head office consists of the leaders of MAD, beneath them we have HR, administration and development. In administration you have the people working with all the administrative and economics, since there are so few people working there administration has no sub departments. While in the development department, that is the biggest one in the company, as they are a IT development company, has three sub divisions. In every level of the organisation you have people working. LearnIT consists of more departments, but since this is a model made for MAD I chose just to include the parts of the organisation relevant in this case. This knowledge of which part of the 13

14 customer company their contact person belongs to can be used as an advantage by MAD, as it can help them in getting an insight in the background of the customers contact person. It can for example answer questions like if the person has any technical experience or just economics. The folder has relationships to three other folders: Location, Goals and people. The relationship to location shows where the different organisations and their departments are located. So the relationships are from the head office/department to a location in the location folder. The relationships to goals are representing which parts/departments of the organisation MAD, has the responsibilities for the different strategies that needs to put in action to reach the companies goals for the project. The relationships to people gives an overview of which part of the organisation the different people belong to, or are employees of. 14

15 People The people domain gives an good overview of the people involved in the project. The folder is also easily updated. For new similar projects the same model can be used, by just switching the names in the people objects in the folder, or making an additional people-domain for the new project. Figure 4: People Domain The folder has relationships to process and organisation, where the people are linked to specific roles in the process. This way we can easily get an overview of what roles the different people fill in the process and which department they belong to. 15

16 Processes Figure 5: Processes Domain The process folder consists of processes and roles tied to the different process steps. Since the roles are a bit difficult to interpret in my screenshot I will explain them when describing the different process steps. MAD uses a human centered design process when developing, making the first step in their process the step of identifying the need for human-centered design. The roles belonging to this step are the customer representative, Andrew Vuitton in this case, and a representative from MAD, usually the project manager who in this case is Aaron Carter. These two would usually meet up in a meeting to identify the need. The next step is to understanding and specifying the context of use. Here the same roles as in the step before are relevant, and a meeting between the two is in order. This step is important for further development and cooperation in the project. It is in this step that MAD can get answers of 16

17 why the customer wants to make this application, who will use it, and what the customer has in mind. In general this step is important to create a common understanding and a common ground. By clarifying the stakeholders stands, goals and visions from the start you can avoid ambiguity and misunderstandings later on in the project. When the stakeholders have an common understanding and ground the process can continue with the next step of specifying the user and organisational requirements. The step of identifying the requirements for both the user and organisation(s) involves both the project manager (customer contact), the customer and end users. Here they make the requirements specification for the product by identifying both the functional and nonfunctional requirements. In the fourth step a design solution is to be produced based on the requirements and specifications. Here both the developers, technical manager and GUI manager needs to be involved in developing the application. The managers need to obtain an overview throughout the whole process-step. The fifth step is to evaluate the design against requirements. Here the test manager is the responsible and end users are involved when performing user testing. This is an important part of the process, if the product passes the testing the team continue to the next step, if not the iteration continues by going back to step two. If the tests have passed with none/minor errors and the customer is satisfied, the last step in the process is completed and the application is finished. Process has relationships to documentation and people. the relationships to people is from roles, and show which roles different people fill. The relationships to documentation gives an overview of which documents are used where in the process and which are made during the process. By showing the relationships between documentation and process the company can get an overview of the necessary documentations made and used in their process. Some processes have documentation as input, like evaluation of design against requirements, while others make documents in the process, like the step of specifying requirements. It can also answer questions like if the process they use need all the documentation made and available or not. Process has also relationship to the product folder, where the last step has the final product as output. Here I used a General relationship as I did not find any predefined relationship between a process step and a product with the labels output/output from. 17

18 Location Figure 6: Location Domain The location domain shows in which parts of the world the different organisations are located. This is good to have in the model when dealing with several customers in a project allocated in different parts of Norway or the world. It is also good to have if MAD chooses to expand their company with branches in other parts of the world/country. By having a location folder in their model MAD can provide their employees, new and existing, and customers with an overview of where they are located. A overview of locations is also good to have if a development team is sourced out to work at the customers office in another city or country from MADs location. The location folder has relationship to the organisation folder, showing that the company LearnIT has their main office in Trondheim, but their sales branch in Oslo. While MAD has their whole company in Oslo. 18

19 Goals Figure 7: Goals Domain The goals folder gives a view of the goals that MAD has for this project and their strategies for reaching the goals. The goals has relationships to organisation, showing which parts of the MAD organisation has the responsibility for the strategies being followed. By having a goals folder the involved stakeholders in the project can easily get an insight in what the projects goals are and how they tend to reach the. 19

20 Documentation Figure 8: Documentation Domain The document folders contains overview of the different documents made and used in the project. Documentation is very useful, especially when working on getting a common understanding of the project and for later references. The folder contains 5 documents and the purpose of it is to provide the model users with an overview of the documentation needed in the project, both that is going to be used and made. The documents presented in the folder are just the minimum amount needed in a project, making it important to update the model regularly if new documents are made or used in the project. Documentation has relationships to the process folder, requirements and product. Most of the relationships are to the process folder. Before the testing the process uses the test plan, and after testing is done the process has created a test report with results from the testing process. 20

21 The relationships to the requirements are between the requirements specification and the whole requirements folder, as it is in this document that all the requirements, both functional and nonfunctional, are specified. The manual has a relationship to the final product, as it describes the app. And a relationship to the process last step, where it is made. I use general relationship between the document requirement specification and Evaluate design against requirements step in the process, with the labels uses/used in. This shows that the document is an input for the process. Same goes for the relationship between system architecture document and process step evaluate design against requirements. I did not find a predefined relationship showing that a document could be used as an input for a process, thus the general relationships. 21

22 Requirements Figure 9: Requirements Domain The requirements folders consists of two additional folders, one for the functional requirements and one for the nonfunctional. The requirements are explained earlier in the report. The amount of requirements in this model are considerably smaller in number than in a real project. The main reason for this is that I want to show the concept in this model, without the need for going in further details in the specific projects requirements for the product. The requirements I have listed can be an example of the minimum amount of requirements needed for such a project. By modelling this domain both the company MAD and their customer can easily get an overview of all the requirements and where they will be considered in the final product. And not the least it shows that all the requirements have been considered (or not). 22

23 The requirements have mainly relationships to the product, showing which parts of the product has which requirements. Each requirement is connected to a part of the final product by the has requirement/requirement to relationship. It has also relationship to the requirements document, these relationships are explained earlier in the documentation domain section. Product Figure 10: Product Domain The product folders shows the application and what parts it consists of. The development platform is a part of the application and it consists of four parts, a part that contains the functions and logic related to the application, a database which stores user data etc., network as it is a multiplayer game (turn-based) and GUI (Graphical User Interface). By using all the functionality the platform contributes with the developers can make the application. 23

24 All the parts have relationships to different requirements, showing that all the parts are needed and required in the application. In some projects there may be no use for some parts. So one of the reasons for making a product folder is to get a better overview of the different parts of the final product and if they are all relevant according to the requirements provided. By modelling this domain it is also easy to detect lacks in the relationship requirement-product. Model Views Views are made with the intention to serve different purposes of the model, and show different users perspectives. Goal-view Figure 11: Goal View 24

25 This view is intended for employes of MAD. The view focuses on the goals, their strategies and responsible departments. It provides an overview for the involved departments and employees of which departments have the responsibilities for the coordination and execution of the different strategies. It does not consider other parts of the organisation that are not involved in the strategies. In projects with more strategies and goals this view can help the head office control and adjust the amount in case some departments have too much responsibility or are responsible for strategies not relevant to their competence in the department. For example if the HR department was to have the responsibility for a user centered design during development, the head office should react. 25

26 Documentation-view Figure 12: Documentation- View The documentation view is mainly intended for the project team, to provide them with an overview of which documents is to be made and used, and when. Maybe there is no need for all the documentation, or they should be made more? It can also be used by the leaders of MAD when considering new development processes and methods where the question about the amount of documentation needed and made comes up. Many Scrum fanatics mean that documentation isn't that important, by using this kind of view it can make it in some cases easier to explain why documentation is important by showing its use areas and intention. This view is also nice for new employes of the company to get an understanding of where different documentation is to be used and written. 26

27 Project team-view Figure 13: Project Team - View This view is intended for the project team from MAD. The views is made with the intention of making the different responsibility areas for the different roles clear, and the people fulfilling the roles. So the whole team can see who does what. It also gives a nice overview of the different responsibilities, you can easily see if some persons have more responsibility ands tasks than others and vica versa. It is also a view to show who the people in the development part of the project team are. By keeping the relationship to the organisation it is also easier to see which departments are involved in the case. 27

28 This view can get clustered in big projects with many people involved, but in this case it gives a nice view of the different responsibilities for the project team. Customer-view Figure 14: Customer- View This view is intended for the customer, to provide them with a clear understanding of what their role is in the project and what is to be expected of them. I personally think this view is very important and good to have as it gives the customer a clear idea of what is expected from them in the projects and the process. 28

29 Matrix Person-role matrix Figure 15: Person- Role Matrix This matrix provides an overview of which roles the different persons in the project have, and where in the process the roles are to play a part. This matrix can help new employees in understanding what responsibilities the different roles have. It also provides the stakeholders a view of their tasks in the process. The matrix can also be used if we wish to trace backwards from a task in the process to a person, to see who was responsible for the task. 29

30 Documentation-process matrix Figure 16: Documentation- Process Matrix This matrix gives a good overview of where the different documents are used and made in the process. As mentioned earlier in the views, such an overview can help in getting a better understanding of the documentations needed and made in a project. And also when evaluating the need for more/less documentation. It is also nice to have this overview for new employees who are new with processes where documentation is made meanwhile developing. 30

31 Requirements-product matrix Figure 17: Requirements- Product Matrix This matrix shows the requirements-product relationship. In the view for this it can easily get clustered and difficult to get a good overview to which extend all the requirements have been considered in the product, especially if the amount of requirements is high. By using a matrix the overview gets more organised and easier to read. Here we can easily see that all requirements are connected to a part in the product. And every part of the product has a requirement. The matrix i nice to have both for the customer, to see that the requirements are fulfilled in the product. And for the project team so they can guarantee that all their requirements have been considered, it can also help in finding breaches by giving the opportunity to trace back from a requirement to a part where it should have been realised. 31

32 Evaluation of the model For evaluation of the model I will use the questions and keynotes I defined earlier in the model purpose part of the assignment, and check if my model fulfills the purposes listed. Responsibility In responsibility I listed some questions that my model should be able to answer: - Which positions has which roles? - Which tasks does a role have in the process? - Which person has which role? - How are the users involved in the project and process? - How are the customers involved? In my model I have domains for persons and process, where I also define the different roles. Between these domains I have relationships, that both the customer and MAD can use in order to get all the information they need regarding their responsibilities in the project. All the questions above can be answered by the model, by the process and person domains. I also made a customer view and project team view, which helps the customer and project team in getting an overview over their roles and responsibilities easier. I also made a matrix showing the different roles-person relationship, the matrix gives info about the process-step connected to each role. It also provides both the customer and MAD a quick and more clean overview of the roles and responsibilities. Communication and understanding In communication and understanding I listed several key points: - Communicate the development to the customer - Provide an understandable overview of the project for the stakeholders - Overview of the process and team for the head office - Portfolio for potential new customers With my model I believe that the both the customer, potential new customers and head office is provided with an insight easily in how the project is set up. The model does not contain any to 32

33 technical aspects that can be difficult to interpret. Metis also provides the ability to close and open domains, making it easier to give both a more detailed overview of parts of the project. Requirements - Are all the requirements realised in the product? - Are all requirements considered? For requirements I listed two questions that I believe can been answered very good by the model. The domains product and requirements gives the user a good overview of all the requirements and which part of the product has which requirement. When having many requirements the model can give a very cluttered view, making it a bit difficult to verify that all requirements are being considered in the product. Therefor I also made a matrix, which gives a very good list of all requirements, by checking the matrix both questions can be answered easily. Documentation In documentation I had two questions: - Are all the necessary documents made during the project? - Are the necessary documentations used in the project? With the document domain and relationships to process gives a good view and answers the questions above in a satisfying manner. We can also see through the document matrix in a more uncluttered environment, how and where in the process the different documents are used and made. Goals and strategies - What are the companies goals for this project? - What are the strategies to reach the goals? - Which departments are responsible for the different strategies? The model provides the users of the model with a goals domain containing goals and strategies for the project, and relationships to the organisation, showing departments responsible for the strategy. thus satisfying the purposes of the model regarding goals. Based on the purposes I made and described earlier in this report I would say that my model fulfills all of them. 33

34 Discussion of the model in relation to EA There are several definitions of an Enterprise Architecture. According to Roger Sessions [2] an enterprise architecture is an architecture in which the system in question is the whole enterprise, especially the business processes, technologies, and information systems of the enterprise. Wikipedia defines it as the practice of applying a comprehensive and rigorous method for describing a current and/or future structures and behaviour for an organisation's process, systems, personnel and organisational sub-units, so that they align with the organisation's core goals and strategic direction. Enterprise architecture is needed to get an overview of the business processes, systems, technology, structures and capabilities. Enterprise architecture has a long history, and there exists several different methodologies, and even though they are different from one another, they all agree upon that an enterprise architecture bridges the gap between business and IT. Thus the primary purpose of creating an enterprise architecture is to ensure that business strategy and IT investment align. In my model I have described all the components in a project and the relations. The model provides an overview of the process and the organisation structure. I have mentioned the goals, but not in the extend I believe it should be done when having a enterprise architecture. I have mentioned some goals and related strategies, but my model does not provide any information about the future plans for the organisation or their future business goals, which is an important part of enterprise architecture. The model provides an overview of the process used to develop the product, but these are not aligned with any business goals. Overall my model is not made on the basis that I was to create an enterprise architecture. I rather chose to focus, as the assignment specified, on a set of domain important for my case. So for my case the focus was the development process in a company when developing an application. Based on this basis I would say that my model fulfills some of the aspects of an enterprise architecture, but that it lacks a more focus on business goals and strategies. The model has a focus on the development cycle and the aspects surrounding the development, not considering the whole organisation with its whole structure, all organisation systems and technologies. To have a complete enterprise architecture you need to both consider todays status and include future plans. One need to have a path from start to finish. Based on this I think that my model can be used as a basis or a nice starting point for developing a whole enterprise architecture, for example for the company MAD, but it is not a full enterprise architecture as it is today. 34

35 Model Experience The last months I have improved my understanding and skills regarding modelling significantly. Before the course I had only experience with modeling of databases, system modelling and BPMN. Through this practical term paper I have not just learned what modelling is, but I have learned how to model and how to think when designing and making a model. Through trial and error I have learned how to use the modelling tool Metis and the modelling language: GEM. I have learned how to make a good model based on the tools available. I have also realised the importance of having a model, and how an organisation's development process can become more transparent and easier to communicate to other parties through a good model. Metis has served all my needs in this paper and case. GEM had all the necessary features that I needed when making my model, with only some lackings in a few situations, where I used the Metis Model metamodel and the General Component Relationship to fulfill the needs. As I got to learn GEM better I ended up with a lot less general Relationships than first assumed, showing that the language was pretty good for my case and the way I designed it. As one negative part of the tool Metis and GEM I would say it would be the ability to create a pretty model. I have seen other students that used MEAF who got a more nicer and less cluttered model and views. For my next modelling case I think that I will use MEAF, not only to get a prettier model, but also to gain experience in that language, and its capabilities and constraints. All in all I would say I have gained a lot of new modeling experience that I did not possess before this course. It has been very informative and useful knowledge which I have acquired, and I hope I will use in the future both in other school projects and work. 35

36 References [1] ISO 13407: Human-centered design processes for interactive systems. [2] Paper: Comparisons of the top four enterprise architecture methodologies - Roger Sessions 36