Term paper

TDT4252 Modeling of Information Systems - Advanced CourseSpring 2013

Patrick Heia Romstad

Table of contents

1 Introduction 3

2 Case description 4

2.1 LearnIT 4

2.2 The project - VocalIT 4

3 Model design 6

3.1 Users 6

3.2 Purpose of the model 6

3.3 Design of model 6

3.4 Domains in my model 15

3.5 Views in the model 16

3.6 Relationship matrices 17

3.7 Discussion of model 18

3.8 Evaluation of the model 19

3.9 Modeling experience 19

3.10 Enterprise architectures 20

4 Conclusion 21

2

1 IntroductionThis term paper presents the case “A project that will deliver a mobile application for vocabulary learning”. The first part of this paper consists of the case description. This description describes the made-up IT-company that has the project and the project itself along with its requirements and goals. This description is influenced on earlier work and projects in order to make the case as realistic as possible. The second part of this paper consists of the modeling part. This part will present the users, purpose and design of this model, as well as a discussion and evaluation of it. Then I will discuss some modeling experiences and relate this model to Enterprise Architectures. At the end there will be a conclusion.

3

2 Case description

2.1 LearnITA small IT-company that develops IT-applications, and specialises in learning applications. As a consequence of their size, LearnIT usually run small IT-projects in order to be able to choose their own development methods and project management.

LearnIT uses agile development methods like Scrum and Kanban, which fits well with their ideology of involving the customer and users of the system as much as possible. By using agile development methods, the applications will be gradually refined in each iteration enabling the customers and users to give feedback as the application evolves. As a consequence of using agile development methods, the size of the teams are between two to eight people.

As an up and coming IT-company, LearnIT has as a vision to become the best IT-company in developing customized learning applications which should satisfy all customers needs and be delivered in time.

2.2 The project - VocalITA project that will deliver a mobile application for vocabulary learning. The development method that will be used is Scrum, and it is intended to last for 8 weeks which will consist of 4 sprints lasting two weeks each. It is important that the application is easy to use and meets the clients specification. The team will consist of four developers where each one has a field of expertise.

VocalIT is ordered by the Ministry of Education and Research, which have very high expectations for it. They have assigned one person that will be our customer contact, and will give us valuable information during the development. LearnIT also sees this project as a step innside Ministry of Education and Research, and hope that if they deliver a good application they will get more work from the Ministry.

The application shall be used by young people with vocabulary difficulties. Examples of users are pupils in primary and lower school, but also underdeveloped people to a certain degree. Therefore it is of outmost importance that the application is very easy to use, and the time learning how to use the application should be as small as possible.

The name of the application that should be developed is “Fun Words”. Its name is directed towards the users, and is intended to motivate them for using it.

4

2.2.1 Application requirementsThe most important requirements for this application is listed below, with individual priorities. In order to make the game available to as many pupils as possible, the application shall be developed on a cross-platform engine which can run on both iPhones and Android mobiles.

Id Requirements Priority

R1 Log in/out - The user should be able to log in/out to an account High

R2 Save data - The user should be able to save personal data in the application High

R3 Progress - The user should be able to have a tractable progress Medium

R4 Usability - The application should be easy to learn and use High

R5 Usability - the application should support personalization Medium

R6 Gamification - The application should be fun to use High

2.2.2 Project goalsThe goals are listed below and directly influences the development of Fun Words.

• Deliver a good product• Make the Ministry of Education and Research very satisfied, and therefore increase the

possibility of getting more work in the future• Continuously improve the Scrum routines • Continuously improve project management

5

3 Model design

3.1 Users

3.1.1 Project leaderThe project leader is the main user of this model. By using this model, the project leader gets a full overview of all the elements in the project, and is therefore able to make adjustments (s)he observes.

3.1.2 Team membersThe other team members will use this model to find each others area of responsibility and how they are going to accomplish it, as well as see the project goals and methods.

3.1.3 The customer contactThe customer contact will use this model to see which developer (s)he will communicate with and know which documentation that is relevant for her/him.

3.2 Purpose of the modelThe purpose of this model is to get an understanding and overview of how the developing of the vocabulary application is done. The model will show how the different elements in the project (the organization, documents, sprints etc.) will interact with each other and their dependencies.

The model should:

• present the people involved in developing Fun Words.• show the flow of documents• describe the work processes• show the different dependencies of Fun Words• present the goals of the project

It should also only give the users the information they need, i.e. the team leader will use the entire model while the other team members only need part of the model. This is essential for the usability of the model.

3.3 Design of modelThis model is designed using the Meaf template which gave me all the objects and relationships I needed. This meant that I did not need to use any general object or relationship in order to create this model, and therefore it does not contain any of these objects and relationships.

This model consists for four views: the main view, the development team overview, the customer contact overview and the recap project overview. It also has seven aspects that uses five different domains from the Meaf metamodel which are: Document Domain, IT Product Domain,

6

Organization Domain, Process Domain and Strategy Domain. The aspects are: Documents, Requirements, Fun Words, Organization, Development team, Sprints and Goals. The rationale for the domains and views are explained respectively in section 3.4 Domains in the Model and 3.5 Views in the Model.

3.3.1 Main viewThe main view consists of all seven aspects. It also has three action buttons which leads to the other views, as well as a relationship matrix between the roles of each team members and their responsibilities.

Figure 1: Main view

7

3.3.2 Development team overviewThe development team overview consists of all the aspects except for documents and requirements aspects. It also has an action button called “Back” which brings the user back to the main view.

Figure 2: Development team overview

3.3.3 Customer contact overviewThe customer contact overview consists of the aspects organization, development team, documents and requirements. It also has an action button called “Back” which brings the user back to the main view.

8

Figure 3: Customer contact overview

3.3.4 Recap project overviewThe Recap project overview consists of the aspects sprints, organization, development team and goals. It also has an action button called “Back” which brings the user back to the main view.

Figure 4: Recap project overview

3.3.5 AspectsOrganizationThis aspect is created using the Organization Domain. It consist of an organization object which is the LearnIT, an internal organization object which is the development team, an external organization object which is the Ministry of Education and Research and a person object which is the customer contact.

Relationships:

• LearnIT has a customer Ministry of Education and Research • Development Team is evolved from LearnIT • Ministry of Education and Research has a representative Customer Contact.• Customer contact evolved to Customer needs

9

Figure 5: Organization aspect

Development teamThis aspect is created using the Organization Domain. It consists of four person objects (Scrum master, Team member 1, Team member 2 and Team member 3) and four role objects (Team leader, Usability responsible, Architecture responsible and Customer Contact responsible).

Relationships:

• Every person objects fills the Development Team object and a role object each. • The customer contact responsible cooperates with the Customer contact.

Figure 6: Development team aspect

DocumentsThis aspect is created using the Document Domain. It consists of a Document Class object which is the Customer needs and three Document objects: Requirements Document, Product backlog and Sprint backlog.

10

Relationships:

• Customer needs has document Requirement document• Customer needs has document Product backlog• Customer needs evolved to Deliver a good app• Requirements document is evolved to Product backlog• Product backlog has document Sprint backlog

Figure 7: Documents aspect

RequirementsThis aspect is created using the Document Domain. It consists of six Document objects: R1 - log in/out, R2 - Save data, R3 - Progress, R4 - Usability, R5 - Usability and R6 - Gamification.

Relationships:

• Requirements has document Requirements document

11

Figure 8: Requirements aspect

SprintsThis aspect is created using the Process domain. It consists of four Process objects: Sprint 1, Sprint 2, Sprint 3 and Sprint 4. Each Process Object has a Process input object (Sprint backlog and prototypes), Process output object (prototypes and Final application), Process mechanism object (Development team) and Process control object (Standards).

Relationships:

• Development team represents Development team (Organization)• Development team corresponds to Development team (sprints)• Sprint backlog evolved to Sprint backlog (sprints)• Scrum standards evolved to Standards (sprints)• First prototype (Output process) evolved to First prototype (Input process) • Second prototype (Output process) evolved to First prototype (Input process) • Third prototype (Output process) evolved to First prototype (Input process) • Final application (Output process) evolved to Application Fun Words (Output process)

12

Figure 9: Sprints aspect

Fun WordsThis aspect is created using the IT Product Domain. It consists of an IT Product which is the application Fun Words, a Software Product object which is the Platform, two Software Product Version objects iOS and Android, a Hardware Product object which is Database and a Hardware Product Model object which is MySQL.

Relationships:

• Fun Words needs Platform• Fun Words needs Database• Platform has version iOS• Platform has version Android• Platform has responsible Architecture responsible• Database has version MySQL• Database has responsible Architecture responsible

13

Figure 10: Fun Words aspect

GoalsThis aspect is created using the Strategy Domain. It consists of a Vision object which is Vision, four Goal objects and three Strategy objects. The Goal objects are: Deliver a good app, Satisfy the Ministry of Education and Research, Improve Scrum Routines and Improve project management. The Strategy objects are: Involve users, Involve the customer and Recap project.

Relationships:

• Vision leads to• Deliver a good app• Satisfy the Ministry of Education and Research• Improve Scrum routines• Improve project management• Deliver a good app leads to Satisfy the Ministry of Education and Research• Involve users achieves Deliver a good app• Involve users has responsible Usability responsible• Involve the customer achieves Deliver a good app• Involve the customer has responsible Customer contact responsible• Recap project achieves • Improve Scrum routines• Improve project management• Recap project has responsible Team Leader

14

Figure 11: Goals aspect

3.4 Domains in my model

3.4.1 Organization domainOrganizationThis aspect aims to reflect the given hierarchical situation in the company as well as how the development team is interacting with the customer. As you can observe from this aspect, the development team is evolved from the company, LearnIT, and consists of four developers shown in the development team aspect. The connection between the development team and the customer is shown with a customer contact that represents the customer.

Development teamsThis aspect shows all the members in the development team and their roles within it. This aspect is created to give the team leader an overview of all team members as well as help team members see what they are responsible for.

3.4.2 Information domainDocumentsThis aspect aims to give an overview of the most important information, often represented as documents, that the development team has to deal with. Since it is important to have close contact with the customer contact and the fact that the customer contact is their main source of the customer needs, this aspect show that the customer needs is evolved from the customer. From the customer needs the requirements documents and product backlog is made. The sprint backlog which is part of the product backlog, is used in every sprints as a list of what has to be done in each sprint.

15

RequirementsThis aspect presents the most important requirements for the project, and these requirements is written in the Requirements document, shown by the relationship has document.

3.4.3 Process domainSprintsThis aspect aims to give an overview of the development process of the application. It shows that each sprint has four different inputs and one output, except for the first one because no prototype has been made yet. The different inputs are sprint backlog, standards, development team and prototype from last sprint. And the output from each sprint is a prototype, except for the last one when the output is the finished application.

Explanations of each input and output:

• The sprint backlog: described in the documents domain • Standards: the standards for each sprint, e.g. each sprint starts with a “sprint planning

meeting” and ends with a “sprint retrospective”.• Development team: is the team from LearnIT that develops the application.• Prototype (input): the prototype that is developed from the earlier sprint.• Prototype (output): the prototype that is developed in this sprint.• Finished application: is Fun Words, the application that was developed.

3.4.4 Product domainFun WordsThis aspect gives an overview of the parts of Fun Words that it needs to function properly. This includes a database that stores user information and the platforms that Fun Words shall run on. This aspect explains that it should be a MySQL database system and run on iOS and Android platforms.

3.4.5 Strategy domainGoalsThis aspect is aimed to presents the goals of VocalIT, the strategies to achieve them and the vision of the company. It is a total of four goals where two of them is specific to Fun Words and two of them are goals that LearnIT projects always have. The goals specific to Fun Words is “Deliver a good app” and “Satisfy the Ministry of Education and Research. The strategies to achieve these are to involve the users and the customer. The other goals are to improve Scrum routines and improve project management, which are achieved by recapping the project. These goals are part of the overall company vision, and therefore important in all projects.

3.5 Views in the model

3.5.1 Development team overviewThe development team is one of the users of this model, but they do not need to see the entire model. What is interesting for the development team members is what they are responsible and how

16

they are going to achieve it. This view presents the different team members with their roles, and also what kind of strategies they are responsible for.

For example, team member one is the usability responsible and is responsible for the involving the users during this project. The architecture responsible must know what kind of platforms the application should run on and what kind of database it should use, and this information is included in the Fun Words aspect which is in this view.

The sprint aspect is also added as a reminder of which development method they are going to use, and it presents the number of sprints project will consist of. By knowing the number of sprints, the usability responsible know how many iterations (s)he can have with the users when designing and refining the user interface.

3.5.2 Customer needs overviewThe customer contact is not interested in how LearnIT develops the application, nor LearnITs internal goals for this project. On the other side, the customer contact is very interested in knowing which team member to have contact with, and have a big influence on the requirements for the application and which requirements that should be developed first, second and so on.

As a consequence of this, the aspects added in this view is the organization, development team, requirements and documents aspects. The development aspect shows the team member responsible for communication with the customer contact, while the document and requirements aspects presents the requirements for the application and in which order they should be developed in the sprints.

3.5.3 Recap project overviewThe goals “Improve Scrum routines” and “Improve project management” are as explained earlier goals that every project LearnIT have, and they play an important role in LearnITs vision of becoming the best IT-company in developing specialized learning applications. The strategy to fulfill these goals are “Recap project” and this view aims to give the team leader an overview of the development team and the development method. This view will also be used as a tool to discuss how the development process and management went in a meeting with other team leaders in the company.

3.6 Relationship matrices

3.6.1 Role relationship matrixThe role relationship matrix is intended to give the team leader a quick and good overview of the responsibilities to the different roles that each team member fills. As a pilot project for LearnIT to Ministry of Education and Research, it is essential that the application is good and that the customer gets satisfied, therefore having as much control and overview of the project is vital to the team leader. When the matrix was created, the other goals and visions from the goal aspect was excluded as well as the other objects in the Fun Words aspect. By doing this, the relationship matrix becomes small enough to be effective in use and the only elements on the two axes are relevant.

17

Figure 12: Role responsibilities matrix

3.7 Discussion of model

3.7.1 Purpose of the modelThe purpose of the model was always used when creating the model in order to model only the most relevant aspects of this project, which are those who directly affects and is affected by the development of the application Fun Words. This resulted in the seven different aspects presented in the design chapter. As part of the purpose was to give the different users the information they need, three views was created to address this.

3.7.2 UsersThe main user is the one who will use the model the most and it directed much of the modeling. This made it easier to grasp what was important to incorporate in the model, as well as holding the size of the model as a minimum. Everything that the main user might not need, had to be thought thoroughly before modeled, and it would be added only if other users of the model had use for it.

3.7.3 External relationships External relationships was added in order to show how the different aspects affects each other, e.g. the strategy “Involve customer” has a relationship “has responsible” to “Customer contact” in the Development team aspect. This increases the value of the model since not only does it show the different developers and strategies, but how they are connected as well, as in this case it shows

18

which developers are responsible for which strategies. This is done between all relevant objects and aspects, as shown in the images of the model.

3.8 Evaluation of the modelThe model was designed with the purpose of the model in mind. As such, all of the components that the model should include was included and appropriate views was created for each user.

If you look at the model with the team leaders eyes, you will see the flow of documents in the documents aspect and requirements aspect, the work processes represented as sprints, the people involved in this project in the organization aspect and development team aspect, the goals in the goal aspect and Fun Words dependencies in the Fun Words aspect. Together all of this aspects give him a clear view of the developing of Fun Words. The other users of this model also has its own views as stated in the purpose, and these views all have a clear rationale for making them.

What could have been improved are adding more requirements. If all requirements for the project had been added, the model could have shown how all the tasks in the product backlog was originated from the requirements. Then the tasks could be given a responsible team member, and divided in the different sprint backlogs. This would have made the model a lot bigger, but using views could have simplified it and made the model very easy to use.

Overall the model serves the purpose of the model to a high degree.

3.9 Modeling experience

3.9.1 First draft:Modeling in Metis can be a time consuming affair. The first hours of using Metis was used to learning the software, and find the shortcuts that I often use in order to model more effective. When the technical part of modeling in Metis went well, I started focusing on what I wanted to model.

In the beginning I used the GEM template, but I wanted to model the processes in my model a bit more detailed. After looking at some other templates, I chose the Meaf template which gave me more modeling domains and more elements in each of them.

In the first draft, I chose to model the organization, processes and information relevant to VocalIT. Of these three domains, the processes was the most complex but when I got familiar with Metis my only problem was to not model everything.

3.9.2 Second draft:In the second draft I added the goal and product domains. When I added more and more domains, I saw that it became necessary for views in order to use the model efficiently. Since I had most of the elements and domains needed, I started on the views. I made three different views for different use cases, and started to modify them in order to only show relevant information in them.

19

3.9.3 Presenting the modelPresenting the model didn’t just give me experience in how to present my own model, but also more awareness of my own model. This resulted in ideas how to improve my model, which I used in the final draft.

3.9.4 Final draftIn the final draft I refined my model and my views, as well as made the relationship matrix. Most of the refining was on the views, since I wanted them to reflect the users need as much as possible. It took me some time to get a good grasp on the relationship matrix, but after some trying and failing, I learned how to create them. I also had to decide what parts of the model I wanted to be represented in a relationship matrix. After some studying of the model, I chose to show the relationships between the roles of each team member and their responsibilities.

3.10 Enterprise architecturesWhile this model tries to get an understanding of the project VocalIT, Enterprise Architecture would try to get an understanding of the most important elements in the organization LearnIT. As such the EA is much more comprehensive and extensive than this model is and will be.

Compared to Zachman, TOGAF, FEAF and Gartner, this model resembles the Zachman Framework the most. This model does not say something about how things will be in the future, but rather explain how the project is being developed right now by using several different aspects. These aspects again resembles the different aspects in Zachman: what, how, where, who, when and why.

• The what could be transferred to the Fun Words, documents and requirements aspects, since they explains the conditions for developing the application.

• The how could be transferred to the sprints aspect since it explains how the developing team is going to work.

• The who could be transferred to the development team aspect since it presents the team members in the group and the responsibilities they have. Could also be transferred to the organization aspect since it explains the work allocation.

• The why could be transferred to the goals aspect.

It is harder to find similarities to the when and where, but this model was not meant to be part of the Zachman Framework to begin with. The views in Zachman also resembles the different views in this model, because each of the different views have their own user.

The other EA frameworks and Gartner focuses on a method of creating an EA, which clearly is not the case with this model. This model is just a “screenshot” of how the development of the application Fun Words is done, but it could contribute as a model of how projects are done in LearnIT.

20

4 ConclusionCreating a model of this magnitude has been a good and interesting experience. By modeling a case yourself, you have to think more about why you are modeling and what elements you want to add to your model This is something that comes through experience rather than reading about it, and thus gave this assignment a great practical value for further modeling projects.

The model I ended up with fitted the purpose very well, and this is mostly because of the mindset I had when I created this model, i.e. I always had the purpose of the model in mind when I modeled. Then comparing this to Enterprise Architecture made me realised the magnitude of work creating an Enterprise Architecture consist of.

21