The fifth course on The Hague University of Applied Science was another Major course. This course was the first course of my second school year and I was very excited what we were going to do. This course mostly involved managing an operational system and applying big and complex changes, which required us to track individual components of those changes. We had to manage an information system and support it according to the operational ASL processes. This course continues on the knowledge that we gained during I-1 (Or the G-course for us) and I-2.
Overview
Course: I-4: Application building and management
Finished: November 2010
Gained knowledge
Working with ASL Processes
Working with different roles within a project team.
Incident and change management.
Testing changes.
Working with Linux.
Hibernate, O/R Mapping.
JSP and Beans
Java Sockets
Working with CMWare
Working with separate OTAP environments.
Executed Beroepstaken(Competences, tasks, qualities etc)
Below you see the list of beroepstaken(for lack of better English definition) that I have done in this course:
| 1.1 | Selecting methods, techniques and tools | niveau 2 |
| 2.2 | Designing, building and inquiring a database. | niveau 2 herhaling |
| 2.3 | Executing dataconversion | niveau 1 |
| 3.1 | Designing softwarearchitecture | niveau 2 |
| 3.2 | Designing system components | niveau 2 herhaling |
| 3.3 | Building application | niveau 3 |
| 3.5 | Executing of and reporting about the testproces. | niveau 2 |
| 4.1 | Managing configurations (Configuration management) | niveau 2 |
| 4.2 | Managing application | niveau 2 |
| 4.3 | Managing changes | niveau 2 |
| 4.4 | Managing and distributing of sofrware. | niveau 2 |
Course Review
I really found this a valuable course. I formed a team with Quiriën and Roy, which really paid off from the start. We formed the group, divided the roles for the first release of the application and went to work. In this course we had to work with the ASL processes. We had to manage and expand the FlyAWay application, that was already built by someone else and was already in “use”. The managing and expanding of the application was done according to the managing procedures that were dictated by ASL. To accomplish this, we had to divide the group into different roles that each of us had to take on during the course of the project: Helpdesk employee, Functional Manager, Teamleader Development and Change coördinator. We were expected to rotate these roles between ourselves, so that everyone had at least one of these roles during a release of the FlyAWay application. We were also expected to use the Open-Soruce application OTRS. This is an online ticket system that we had to use to record incidents and changes according to a certain procedure, since this is also used in the “real” world. I really had to get used to this in the beginning, since it was pretty annoying to incorporate this into our “let’s fix this right away” mentality, since we had to make time to record the changes/incidents into OTRS.
These are the roles as I have defined them for my group:
Helpdesk employee
The Helpdesk employee is responsible for the managing of the e-mails that we receive with incidents or RFC’s for the application. The Helpdesk employee tries to solve the problems himself, first. If the problem is too much to handle, the problem will be passed along to the second line. The Helpdesk employee records the incident/RFC tickets into OTRS, which are then taken over by others.
Functional Manager
The Functional manager is the person that has all the knowledge about the application. Thus he is responsible for requesting changes. The Functional manager analyses every change, makes plans for this change and lets it be approved by the Teamleader development. Work on the change can begin once it has been approved.
Teamleader Development
The Teamleader development is responsible for all the programming. The teamleader receives the plan that tells him what to do and begins to build it. The Teamleader can delegate tasks to other maintainers/developers to share the workload. When everything has been build, then it is the task of the Teamleader to test his product according to the test methods that have been defined.
Change Coördinator
The Change coördinator is responsible for applying the changes. The coordinator judges the changes that have been made by the teamleader, reviews the testplans and makes sure that everything is in good order. Only approved changes can be passed along to the production environment, so if the coördinator isn’t satisfied, then the change can’t be passed along.
As you can see, the roles are tightly related to each other. All 4 members of the group had to rotate between the mentioned roles, and everyone had the role of maintainer, so the Teamleader could make use of their time and skills.
In the first few weeks we mostly had to deal with a few incident mails that resulted in a few simple releases. The mails that we received had to be solved within 24 hours, otherwise it took too long (In case of escalation we had a bit more time, but that had to be communicated with the customer). The Helpdesk employee processes the e-mail, sends a confirmation that he received it and tries to solve the problem. Usually this problem was fixed in no time, since most incident mails were very easy. One of the emails we had, for example, we had the problem that someone was logging in with someone elses account, and didn’t have her own. We fixed this by making an account for her and sending her the credentials. Eventually we were meant to release 5 different versions of the application, that were an improvement over the former release.
Here is a list of the releases that we had to put out:
| Release | Deadline |
| Release 1: Linux Environment | Week 3 |
| Robuust BV wants the FlyAWay applicatin to be compatible with Linux. Linux can’t work with MS-Access. The database has to be converted to another DBMS, namely MYSQL. The management also wants to change a few things about the existing database. Data that’s currently outside the database (Located in two Excel Sheets) have to be included in the new database. Make two class diagrams, one for the old situation and one for the new and make a Mappingschedule.
The application has to run in the production environment (Without using Netbeans). |
|
| Release 2: Own Schedule | Week 4 |
| The management wants the functionality that booked employees can look at their own schedule. The rule for this schedule is that the employee is also booked the day after the original date. This means that a pilot that is scheduled on january 20th 2010 is also booked on january 21st 2010, since that would be his return flight. This also has to be seen in the schedule of the employee. This also means that the employees should all have their own account to log in with, so that they can view their own schedules. They can’t plan any flights or look at the schedule of someone else. | |
| Release 3: Hibernate | Week 5 |
| Keeping future changes into account, Robuust BV wants Hibernate to handle the communication between the application and the database. Change the application accordingly so only Hibernate communicates with the database. This version of the application has to run on the production environment. Change the designs before you start implementing this change. This release requires the preparation of a test report and release advice. | |
| Release 4: Webapp Schedules | Week 6 |
| FlyAWay wants its employees to access their schedules via the internet. Make a web application which realizes this. Make sure that employees can only view their own schedules. Use JSP and Java Bean for this implementation. This application has to run in the production environment. This release requires the preparation of a test report and release advice. | |
| Release 5: Licentie Server | Week 8 |
| The management of Robuust B.V. wants to sell the FlyAWay application to multiple companies and wants to prevent the illegal use of the application. The following idea was proposed for security: Every application will have a licensenumber. A license server will be installed in the office of Robuust B.V., which will communicate with every FlyAWay application. The application logs into the server and gives its licensenumber. If the number is valid, then the application can boot up and work properly. If the number is invalid, then the program shuts down with the message that the number isn’t valid.
Hints:
This release requires the preparation of a test report and release advice.
|
|
As you can see we had a lot of work to do. We were busy with incident mails until release 3, but when we started working on Hibernateand beyond, we were only busy with development. I made the decision to not get too involved in the developing side of things, to give my fellow members the opportunity to practice and learn more with Java. However, when we hit Release 5 I started to get quite bored, so I took the task on me to build the entire License Server. This was a lot of fun! I created a console application which the FlyAWay application could communicate with. It had an error log, reported all the events that was going on into the console of the application and everything worked perfectly. There was always room for improvement, of course, but I was proud of my server.
I also was slightly involved with the implementing of Hibernate. My other group members couldn’t figure one part of Hibernate out towards the end, so I assisted them with it. Hibernate really is a nice way to work. We made a few errors with naming a few tables, objects, and Hibernate folders, but eventually everything worked smoothly.
I-4 was a very fun course. Despite the fact that using different environments in Linux through an image was a bit cumbersome, we still managed to finish this course with positive results.