What do you think is/are the reasons why the university decided to tapped in-house resources, was it a good decision?

First, I would like to discuss my knowledge on the situation. If I remember it correctly, one of our professors in this university openly discussed matters concerning the previous USEP enrollment system to us. He discussed the said enrollment system as an example on one of our lectures. He stated that the university is paying a large amount of money to a certain company that developed the said system. He also stated that the university is only renting the enrollment system. He elaborated it more by stating that the university is renting the said system but not necessarily on a rent to own basis. By that time he stated that the university is planning to shift on a new enrollment system but he did not stated that in-house resources would develop it. Our professor on that subject is Engr. Michael Angelo Cagape in case you still don’t know. He is one of the developers of the new USEP enrollment system.

Second, let us now focus on the facts from my knowledge. One of the fact is the university is spending a lot of money on the previous enrollment system. There is nothing wrong with that because such systems really do cost that much. Let me be clear that I don’t have an idea on the exact amount of the payment the company receives from the university that is why on my point of view spending money on system such as an enrollment system is a harm for the university. Second fact is that the university is only renting the said system. The first question on my mind is “Why rent?” That question really bothered me until I forced myself to think that maybe renting maybe cheaper than buying the said system. On that point I still don’t know about rent to own basis until our professor told us that such basis do exist. So what is a rent to own basis. On what I have learned on that subject, rent to own basis is a form of renting that a company lends another company a system. The later pays the former on a scheduled basis until the later can own the system. I was relieved to know that such basis exists on the field of system development not knowing that I would be shocked on the next thing my professor would tell me. I was really shocked that the university never opted to rent to own the enrollment system. The question, “Why rent?” came back to me. Alas, I really pondered why the university had chosen to rent and pondered more on why not on a rent to own basis. Such things could never be answered unless you are really a curious type of person. So much for pondering on such things let us discuss on my opinion on tapping the in-house resources.

Third, I would now state my opinion on tapping the in-house resources of the university and later on stating my opinion if that decision was a good one. So maybe you are wondering why did this boy discussed so much before answering the question stated above. It is because my statements above would be the basis of my answer not because I want to reach a thousand words. (Maybe I am doing it to reach a thousand words). So much for that so let us enumerate reasons why did the university opted to choose to tap its in-house resources. One obvious reason is that the university finally had realized that renting such system is a big loss to the university. Imagine renting a multi-thousand system and it could never be yours. Let us be realistic here. Owning a something is way better that renting it. I think funding is the main reason why the university finally opted to tap the in-house resources. Let me be clear again that I am only expressing my opinion here and not all my opinions are correct and I am ready to be corrected by someone who knows better that me. Some great minds in our university had seen that the future would not that be nice if the university would still be renting an enrollment system where in fact we have persons inside the university that can are very well qualified to develop such systems. I think another reason is that in-house resources are present in our university. There could be such no excuse such as lack of resources in terms of manpower. We should give the person that made the university realize that such in-house resources do exist a round of applause. So I think that those two reasons are enough for the university to decide to shift to a new enrollment system. Let me recap the reasons for me are the presence of system developers in our university and the other is the funding of an enrollment system. If you were to ask me if tapping in-house resources is a good decision, I would frankly say yes. Yes, it was a very good decision. Why? I would ask you again, “Why not?” We have the resources and the goal of shifting to a new enrollment system is for the good of the university and directly or indirectly it is also for the good of the students. The university has the manpower so I think there is no excuse for not using existing manpower. We could not justify if the change of system would save money by this early but I think as future system developers we could assume that the university can save money in the long run. Yes, it was indeed a good decision. I think no one would protest in a decision that would somehow save money and only those who benefits on the waste of the universities’ (student’s and Filipino’s) money are the only ones that would protest. Although we cannot assess yet the effectiveness of the new system but I do believe that the system could be developed further for the faster and orderly enrollment and what matters most for me is that the enrollment system of the University of Southeastern Philippines is now owned by the university. It is not rented. It is not leased. It is not borrowed. The university now owns it.

Lastly, I would like to share what I have learned by this activity. Although we have already discussed ways of developing systems (in-house, outsourcing, and others), it is still good to recap on such things so that as future system developers we could decide on how is the best way to develop a system. Although it seems on my answer that I am favoring in-house development more than anything else but that is wrong. I don’t favor and way of development. It so just happened that the situation favors in-house development but that could be another topic. Thanks for reading what I had worked hard for and any comments are greatly appreciated.

HELLOOOOOOOO

Hi I'm Ace Andrion Sandoval, a 4th year Bachelor of Science in Computer Science student.
I'm an eager learner.
Most of the time, I challenge myself to do something better than someone else.
I'm expecting to learn more about system development through group sharing and class sharing.
I expect to be a part of a development that I would be proud of.

To Be System Use Case Diagram

As- Is system Use Case Diagram

Assignment 6A

Round 1: Project Proposal

Having consultation with Dr. Randy S. Gamboa is such a thrilling and unforgettable experience. Each time we step inside the faculty room, my heart pounds hard as if anticipating something big would happen. Yes! Something big would happen. Honestly i don't know how would our professor react to our proposal. Honestly our system is somewhat a punch to the moon (translate: suntok sa buwan) but I believe in my team. I believe we could do it. So there we are standing in front our professor, eager to have his approval for our proposed system. We convinced our professor to take our proposal as if our life depended on it. Our team and our professor have agreed to limit the scope of our study because our professor is concerned of the difficulty of what we are proposing. I think we did great in our proposal but my team was exhausted after that.

Round 2: 1st Consultation

Here we go again. After finishing our planning phase and furnishing the papers, it is time again to meet with our professor. We were the first one to have a consultation with our professor for that day. (I still dont know if it's better first or last) Surprisingly our professor didnt read our paper first. He threw us questions (hard ones) before reading the paper. I did not expect it to go like that but we managed to answer (partial answers) his question. Altough i can feel the pressure building, we still managed to pick ourselves up and deliver the concept of our paper. Defending it at all cost because we worked hard for that paper. Our goal is to have minimal revisions so that we can proceed in the next phase as soon as possible. I think we did great but its not over yet.

Round 3: 2nd Consultation (Coming Soon)

Here we can see the activity diagram that I made based on my previous answer on assignment 4. Actors including the automated system are separated by a rectangle. Each actor has there own rectangle where use cases are designated. We can see which use case an actor use and also the flow of the enrollment system. We can observe that not all actors can use the automated system that is because customers are only limited to giving information and payments and the users are the one that has direct access to the automated system.

This image above shows my interpretation of the USEP enrollment system using a use case diagram. According to "wikipedia.com", use case diagram consists of use cases (actions done or processed in the system) , actors (persons involved in the system), relations (determines which actor performs a use case) and boundaries (system boundaries and system boundaries). I based my answer on that description of a use case diagrams.

I will discuss the objects involved in my use case diagrams.

Actors:

Enrollee is considered the customer of this enrollment system. He is the basis of all basic use cases inside the use case diagram.

Treasurer is the actor that collects and assess a student in student fees such as local council fees, publication fees, organization fees and other student collected fees.

Adviser is the actor that identifies the subjects allowed for a student to enroll upon.

Librarian is the actor that registers the student as an officical bearer of an library card.

Cashier is the actor that assess the payments needed for an enrolle to enroll and also collects tuition fees and other university fees.

Encoder is the actor that encodes the subjects of the enrollee.

Registrar is the actor that register the subjects of the enrollee as official subjects of the enrollee.

Use Cases:

Assess Student is the use case used when an actor needs to assess an enrollee.

Pay Assesment is the use case used when an actor performs an action related to payment and collection.

Identify Subjects is the use case used when an actor performs an action that relates to determining subjects which the enrollee wants.

Encode Subjects is the use case used when an action is related to encoding of subjects.

Register Students is the use case used when an actor performs an action that relates to registration.

I would like to further discuss my diagram. As you can see I placed actor on two sides. Those actors seen in the left side are actors that has no direct access to the automated system while those in the right side are the one that has access to the automated system. If you can see no all actors have relationship with uses cases because that action is not done by the actor. He may be involved but he does not directly performs that action. Like the use case "Encode Subjects", only the encoder has access to the computer and it is not the enrollee that directly encodes the subjetcs in the software. The above statement are also used to justify why i did not relate other actors into a use case.