Mood's In Control


Thursday, June 3, 2010
Consider the following dialogue between a systems professional, John Juan, and a manager of a department targeted for a new information system, Peter Pedro:

Juan: The way to go about the analysis is to first examine the old system, such as reviewing key documents and observing the workers perform their tasks. Then we can determine which aspects are working well and which should be preserved.

Pedro: We have been through these types of projects before and what always ends up happening is that we do not get
the new system we are promised; we get a modified version of the old system.

Juan: Well, I can assure you that will not happen this time. We just want a thorough understanding of what is working well and what isn’t.

Pedro: I would feel much more comfortable if we first started with a list of our requirements. We should spend some time up-front determining exactly what we want the system to do for my department. Then you systems people can come in and determine what portions to salvage if you wish. Just don’t constrain us to the old system.

Required:

a.Obviously these two workers have different views on how the systems analysis phase should be conducted. Comment on whose position you sympathize with the most.
b.What method would you propose they take? Why?


Given this situation, a dialogue between a systems professional, John Juan, and a manager of a department targeted for a new information system, Peter Pedro, I realized that obviously these two workers have different views on how the systems analysis phase should be conducted. However, it is so noted that John Juan actually expressed his views by telling or trying to convince Peter Pedro how an old system could be of help in the implementation of the new system analysis and that in doing so, reviewing of the key documents and actually observing workers perform their task would eventually help them determine which aspects are working well and which should be preserved. For John Juan, by doing so would basically result to the desired need that they wanted to change or upgrade . On the other hand, Peter Pedro, in his point of view, seemed already tired of doing the same old task after some experiences maybe in the past which made him said that "We have been through these types of projects before and what always ends up happening is that we do not get the new system we are promised; we get a modified version of the old system." By saying this, I observed that what he was trying to point out is that after doing the same thing they still didn’t get what they really wanted to have and doing such might have been a waste of time, effort , energy again and not to mention of course, the financial constraints. Peter Pedro is obviously dying to have a change in the system that would facilitate everything in a faster, more accurate and would also guide them through and would advance them in a cadence of time and surely in the world of technology. And who would want this time to stick to the same old and traditional system of analysis when the entire world is already pacing with global competitiveness in science, technology, business and industry?

Quoting John Juan's dialogue,
"Well, I can assure you that will not happen this time. We just want a thorough understanding of what is working well and what isn’t." John Juan's calm , cool and patient gesture was so impressive as he tried to assure Peter Pedro that they still could get what they wanted by reviewing and observing the old system once more yet before a new system has to be implemented. For me, the way i looked at it, John Juan is really right but Just like Peter Pedro's view, it'll take time again. The situation already presented an experience in the past which resulted to a not-so-much favorable condition as what they have wanted which is obviously expressed by Peter Pedro's statement.

Quoting Peter Pedro, he said
"I would feel much more comfortable if we first started with a list of our requirements. We should spend some time up-front determining exactly what we want the system to do for my department. Then you systems people can come in and determine what portions to salvage if you wish. Just don’t constrain us to the old system.” Peter Pedro, in his dialogue obviously displayed a strong-will for a change of the system at the soonest time possible. As I have already mentioned above, he is already dying to have a new system implemented in his department for he is obviously no longer satisfied with how the old system works which John Juan was still trying to review or reconstruct which to Peter Pedro yields the same result. He is therefore suggesting on how to go about with the plan. Obviously, he is done with the old system.

Evaluating and analyzing the situation, my sympathy is with Peter Pedro though John Juan had a point in presenting his views .But as observed, Peter Pedro wouldn’t react in that manner if not enough time was already spent in using the old system. Now the time for the new system to be tried and has to be started has come and true enough, whatever should they observe or notice in the implementation must be a springboard for improvement. They can use their experiences with the old system that John Juan actually already had.

When asked as to what method could I propose for them to take is based on what I had read on an article in the internet which suggests vital method for such purpose that gave me insight on how to go about with their plan initially. Well, sound planning of the implementation is crucial to its success as poor planning and inadequate resourcing are often primary causes of implementation failures. The scope of a pan-organizational software system implementation can be huge and is fraught with potential difficulties that may have long-term implications for the company. Not only does it include installation of the new software and the hardware it is to run on, but also precipitates panoply of potentially difficult and unavoidable human factors, many of which are completely unpredictable. Appreciating the conflicts that may arise will enable the organization to avoid these problems and for the management to anticipate likely trouble spots and mitigate accordingly and in good timing.

The first principal point that is required is for the company’s management to understand that the new system by itself is not some sort of silver bullet that will solve all problems hitherto experienced by the organization. The entire implementation process involves the complete business process and/or pedagogic practice, customer service, interaction with suppliers and a bond with all other interested stakeholders. Many less tangible activities are crucial and those involved must: Have a sound understanding of the organization, particularly in terms of its culture and values.

The rationale behind any new system implementation should have thoroughly considered how the system is likely to help provide a better service to all concerned with it. Communicate this understanding to all concerned parties. Undertake a very comprehensive review of all business processes and, where necessary, pedagogic practice, and begin to develop and introduce new policies and procedures before tuning the system to meet the agreed requirements; Have a complete appreciation of the complexity and flexibility of the system; Have an understanding of the inherent dangers of customization of any software and how these can be mitigated against; Conduct a thorough set systems testing procedures, whilst accepting the potential need for software 'bug fixes' and upgrades; Budget for the real costs of internal staff time and their training and development; Train all users to use the system; Train all users and supervisors to fault-find and correct autonomously; Acknowledge the critical nature of system documentation and maintain accordingly. Careful planning and efficient management of the implementation are vital to success and to negate the threats of spiraling costs, extended timescales, losing key personnel and general dissatisfaction with the outcome.

Finally, it is crucial that the “go live” day causes as little disruption to the day-to-day business as is reasonably practicable. Issues that only arise at this juncture become magnified and will undeniably adversely affect the organization's reputation, sometimes irrevocably, with all stakeholders. It is important to remember that poor project management and lack of communication at this crucial stage can ruin an otherwise faultless implementation. cheers

Posted by ♪_TARIZTA_♪ at 12:02 AM | 0 comments
Wednesday, June 2, 2010
Consider your school, how do you know that the life cycle was developed specifically for the university. How do we know it meets our needs?

Understanding the question given was quite confusing to me. As I first read the question, I instantly got stuck passing the words “life cycle”, got baffled and kept on thinking what it was referring to before finishing reading the problem for there are lots and various meanings that we can get . Then suddenly I realized that it was the Systems Development Life Cycle being referred to since it was the only “life cycle” I knew with regards to the subject. Very Happy

Distinctly, a systems development life cycle (SDLC) has three primary objectives. If I am not mistaken, these are: ensure that high quality systems are delivered, provide strong management controls over the projects, and maximize the productivity of the systems staff.

Based on what I've read, in order to meet these objectives, the SDLC has many specific requirements it must meet,including: being able to support projects and systems of various scopes and types, supporting all of the technical activities, supporting all of the management activities, being highly usable, and providing guidance on how to install it. And in order to meet all of the SDLC's objectives and requirements there are certain design approaches that are required: the SDLC must be an example of a system created using the techniques it espouses; it must keep distinct the "what" from the "how" in regards to doing the tasks and creating the outputs. The SDLC should clearly separate what tasks must be done from how they are done. The SDLC must clearly separate what information a task produces from how that information is displayed. This is required to ensure flexibility and maintainability in the lifecycle. It must organize its information in a hierarchical manner so that users with varying degrees of familiarity can find what they want easily and quickly.

Now, relating to our own university,
how do you know that the life cycle was developed specifically for the university?
For me, If it provides the university with an opportunity to improve its employees’ professionalism, if it produces better quality of the systems. This means less scrap and rework to cover omissions, easier maintenance changes and fewer midnight calls to fix bugs. If it is appropriate for the geographical situation, if it is appropriate for the size and complexity of the university’s software, if it is appropriate for the type of projects our university do. Moreover, if the life cycle of the university can meet all the standards of an ideal SDLC such as those objectives and requirements I have mentioned above that best suits the university, then I can say that it is specifically developed.

How do we know it meets our needs? The life cycle is selected after an analysis of the requirements. As with acquiring any package, we must do some level of tailoring to adapt it to our organization, the university. The tailoring required should be relatively minor. The basic tasks and techniques required to build and support systems does not vary much from company to company, nor even from industry to industry.


Defining or selecting an SDLC should be undertaken as a project with full time resources who have the appropriate level of expertise. It is an extremely high leverage effort. It also represents a major cultural change for the staff. It must be planned and executed in as professional a manner as possible. cheers

Posted by ♪_TARIZTA_♪ at 11:59 PM | 0 comments
Identify and discuss at least 3 systems development models .. discuss each phases ...

The trends of increasing technical complexity of the systems, coupled with the need for repeatable and predictable process methodologies, have driven System Developers to establish system development models or software development life cycle models. As what I have learned about the system development models, it is an abstract representation of a process. Also, it presents a description of a process from some particular perspective. System development model specifies how activities of development process are organized in the total system development effort.

Now, let me discuss some of the system development models which are commonly used as to what I have researched, read, and learned.


Arrow THE WATERFALL MODEL

To start, Waterfall approach was first Process Model to be introduced and followed widely in Software Engineering to ensure success of the project. In "The Waterfall" approach, the whole process of software development is divided into separate process phases. This is the classic SDLC model, with a linear and sequential method that has goals for each development phase. The waterfall model simplifies task scheduling, because there are no iterative or overlapping steps. One drawback of the waterfall is that it does not allow for much revision. In waterfall model phases, one phase has to be complete before moving on to the next phase.

With the waterfall model, the activities performed in a software development project are requirements analysis, project planning, system design, detailed design, coding and unit testing, system integration and testing. Linear ordering of activities has some important consequences. First, to clearly identify the end of a phase and beginning of the others. Some certification mechanism has to be employed at the end of each phase. This is usually done by some verification and validation. Validation means confirming the output of a phase is consistent with its input (which is the output of the previous phase) and that the output of the phase is consistent with overall requirements of the system.

For a successful project resulting in a successful product, all phases listed in the waterfall model must be performed anyway. Any different ordering of the phases will result in a less successful software product.

During our Software Engineering I, system development models were also discussed such as this waterfall model. In that time, I have found out some problems regarding this kind of model. First, inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements. Second, few business systems have stable requirements. Third, it is appropriate only when the requirements are well understood and changes will be fairly limited during the design process.

The
advantages of this model is that it is easy to understand and easy to use, it provides structures to inexperienced staff, sets requirements stability, and is good for management control such as plan, staff and track. A schedule can be set with deadlines for each stage of development and a product can proceed through the development process like a car in a carwash, and theoretically, be delivered on time. Development moves from concept, through design, implementation, testing, installation, troubleshooting, and ends up at operation and maintenance. Each phase of development proceeds in strict order, without any overlapping or iterative steps.

The
disadvantage of waterfall development is that it does not allow for much reflection or revision. Once an application is in the testing stage, it is very difficult to go back and change something that was not well-thought out in the concept stage. Alternatives to the waterfall model include joint application development (JAD), rapid application development (RAD), synch and stabilize, build and fix, and the spiral model. There are also limitations in using this model. All requirements must be known upfront, system can be frozen before the design begins, and little opportunity for customer to preview the system (until it may be too late).

This model best applies for large systems engineering projects where a system is developed at several sites.



Arrow THE PROTOTYPING MODEL

A prototype is a working model that is functionally equivalent to a component of the product.

In many instances the client only has a general view of what is expected from the software product. In such a scenario where there is an absence of detailed information regarding the input to the system, the processing needs and the output requirements, the prototyping model may be employed.

This model reflects an attempt to increase the flexibility of the development process by allowing the client to interact and experiment with a working representation of the product. The developmental process only continues once the client is satisfied with the functioning of the prototype. At that stage the developer determines the specifications of the client’s real needs.

In this model, a prototype (an early approximation of a final system or product) is built, tested, and then reworked as necessary until an acceptable prototype is finally achieved from which the complete system or product can now be developed.

As for the
advantages of his model, let me indicate some: Customers can “see” the system requirements as they are being gathered, More accurate end product, Unexpected requirements accommodated, Allows for flexible design and development, and Lower overall development costs when requirements change frequently.

Same with the waterfall model, prototyping has
limitations too. Prototyping can lead to false expectations. Prototyping can lead to poorly designed systems.

For any company engaged in rapid prototyping and manufacturing or functional testing, prototype models are crucial for troubleshooting potential problems in the design process. Prototype models allow product designers and engineers to quickly test the parts of their designs that are most likely to have problems, solve those problems, and then build the complete design. While prototype models are by definition cheap to produce, it can be expensive to build multiple iterations during therapid prototype tooling process, and turnaround times can be too lengthy for today's tight deadlines.

With a knowledge of this kind of model, I couldn’t keep asking myself on to what are the best projects to use prototyping. It has been argued that prototyping, in some form or another, should be used all the time. However, prototyping is most beneficial in systems that will have many interactions with the users.

It has been found that prototyping is very effective in the analysis and design of on-line systems, especially for transaction processing, where the use of screen dialogs is much more in evidence. The greater the interaction between the computer and the user, the greater the benefit is that can be obtained from building a quick system and letting the user play with it.

Systems with little user interaction, such as batch processing or systems that mostly do calculations, benefit little from prototyping. Sometimes, the coding needed to perform the system functions may be too intensive and the potential gains that prototyping could provide are too small.

Prototyping is especially good for designing good human-computer interfaces. "One of the most productive uses of rapid prototyping to date has been as a tool for iterative user requirements engineering and human-computer interface design."


Arrow THE SPIRAL MODEL

The spiral model was defined by Barry Boehm in his 1988 article A Spiral Model of Software Development and Enhancement. This model was not the first model to discuss iterative development, but it was the first model to explain why the iteration matters. As originally envisioned, the iterations were typically 6 months to 2 years long. Each phase starts with a design goal and ends with the client (who may be internal) reviewing the progress thus far. Analysis and engineering efforts are applied at each phase of the project, with an eye toward the end goal of the project.

The spiral model, also known as the spiral lifecycle model, is a systems development method (SDM) used in information technology (IT). This model of development combines the features of the prototyping model and the waterfall model. The spiral model is intended for large, expensive, and complicated projects.

In Spiral development, process is represented as a spiral rather than as a sequence of activities with backtracking, each loop in the spiral represents a phase in the process, no fixed phases such as specification or design - loops in the spiral are chosen depending on what is required, and risks are explicitly assessed and resolved throughout the process.

About the model’s sectors, there are these, Objective setting in which specific objectives for the phase are identified, Risk assessment and reduction in which risks are assessed and activities put in place to reduce the key risks, Development and validation in which a development model for the system is chosen which can be any of the generic models, and Planning in which the project is reviewed and the next phase of the spiral is planned.

There are many
advantages to using the spiral model in software development. Spiral model Estimates (i.e. budget, schedule, etc.) become more realistic as work progresses, because important issues are discovered earlier. It is more able to cope with the (nearly inevitable) changes that software development generally entails. Software engineers (who can get restless with protracted design processes) can get their hands in and start working on a project earlier.

Using, or perhaps misusing, spiral modeling can also have
disadvantages. Highly customized limiting re-usability, Applied differently for each application, Risk of not meeting budget or schedule, and Risk of not meeting budget or schedule.


With the support of my learnings in our Software Engineering I and with the aid of my references, I can now identify the different system development models. I learned that the systems development life cycle model was developed as a structured approach to information system development that guides all the processes involved from an initial feasibility study through to maintenance of the finished application. SDLC models take a variety of approaches to development and each process model follows a particular life cycle in order to ensure success in process of software development. cheers




References:

http://onestoptesting.com

Posted by ♪_TARIZTA_♪ at 11:55 PM | 0 comments
Discuss the role of a systems analyst as a project manager.

As for this 3rd assignment given to us, still we need to interview an analyst/project manager. But last time during our interview to Mr. James Bautista for assignment two, we didn’t miss the opportunity to ask him questions in relation to this problem about the role of a systems analyst as project manager.

Project manager as he may say manages the entire team and the entire project. When you say manages the entire project, most of the time, the project manager will be
talking to the client, talking to the team. He/she will be doing the design model, etc. He/she will be talking to the developers. Aside from talking, the other role of the project manager is that he will get the overall specification of the project. When you say overall specification, you are talking about the overall scope. Then Sir James started asking us if we already have developed a system even in a simplest way and we answered “Yes”. He then asked if who our clients were and begins talking about the client. He said that the client should be the one who are not using the system but the one who needed the system. An example was given to us. There is a mother in the grocery store. The mother is holding a baby. The mother is buying diapers for the baby. Now, who is the client for this situation? Some of us answered the mother and some of us answered the baby for the reason that the baby needs the diaper. But when Sir James give the answer, some of us got confused. The client is the mother, he said. He added that the clients are the people who have money. Now I got his point. Though the baby is in need of the diaper, still, the baby cannot have the diapers if the mother won’t buy it. Just like if a client wants to have a system because he needs it. He can have it if he has the money to pay to the company of his choice for the service of making his system. But why is Sir James talking about that? As a project manager, you really have to know and really have to identify the people involved in the project. There will be the client and there will be the end-users. Sometimes a client and an end-user can be different. Back to what he said about the project manager will get the specifications, he added that the project specifications are not really the details but the idea. Example, a client wants to have a website that will generate another website. So inside the website, the client can make another website from the website ID – something like that. Then the client will give an overview and will talk to the project manager about the details of the website. The project manager will get the specifications. But before the project manager will return to the client, the project manager should see the team first, talk to the developers and will talk about the modeling process, etc., get the details like how many days can the project be done, how many hours, the problems involved, what to need, and what to require. Just the time the project manager gets the information from the team, the project manager will talk to the client again then send out any communication as discussing the overall specifications, presenting the things to do, sorting of the tasks broken down and the timeline. The project manager will delegate tasks to the team .In making a timeline, there is what they call padding. A week before the deadline or earlier, the tasks should be done. The purpose of this timeline is for flexibility allowance in case something might go wrong. Remember the Murphy’s Law, “If anything can go wrong, it will.

Project management is not that hard given the strong confidence of your team when you know the skills of every one in your team. But the hard part here according to Sir James is the communication with the client.
“As a project manager, you have this role knowing that one of the clients will ask updates. You should always be the one to give the update first and not to wait for the client to ask for it.”, Sir James said. He also told us about the two kinds of client: the Pinoy client, and the U.S. client. In project management, there is a big difference when it comes to the project in the Philippines and the project in the U.S. in his point of view, it is so easy to deal with the Pinoy client for the reasons that they don’t set deadlines or if they do, you can ask and have an extension, don’t ask updates from time to time, and majority will not give you a hard time. Pinoy client actually doesn’t care about how the project will be made as long as they get what they want when they put it into operation and will not ask you in the middle but just ask on the 30th day at the end of the project. In U.S. clients, everyday is update day. So they have a common rule that at the beginning of the day, they will tell the client about the updates of the project, informing them about what they did on that day. On the following day, they will put things that they worked on like showing the things they completed for the day. After this, they will point out that after all the work, they will be working on the next phase of the project like another set of list. Consequently, there are three lists all in all: things you have done, things you will do for today, and the things you will do for tomorrow. That’s the kind of update they want and you have to give that update twice a day, at the beginning of the day, and the end of the day. That’s how it is. Very tasky but it works. In U.S. clients, when they say deadline it is always deadline. This client is expecting something to be done at the due date or before. If you cannot make it on the deadline, tell your client maybe a week before, the earlier the better so that they will not expect, stop the client from expecting anything on the completion date. Lastly, the last but not the least, is the most important role of the project manager, is to make the client “Happy”. Happy client equals Money. Smile

Posted by ♪_TARIZTA_♪ at 11:52 PM | 0 comments
Interview a Systems Analyst and ask what skills and characteristics must a systems analyst develop in order to be more effective in any design modeling process.

In today's modern office, information technology is necessary to conduct business. A systems analyst helps organizations achieve goals by utilizing information technology. Through the use of software and hardware, he may help design new computer systems or figure out ways to fine-tune existing systems. A systems analyst is also known as a computer systems analyst. Computer system analysts are concerned more with the computer system itself - and you'd need experience/training in whatever computer system that particular company is using. This does not mean you could not become a computer systems analyst - as most companies would feel that your managerial experience is more welcome than your computer knowledge. What the company would want is someone who understands the basic workings of their system to be able to fix, create, evolve as the company evolves.

SAMULCO stands for Sta. Ana Multipurpose Cooperative and is the company that we have chosen to have an interview to their systems analyst in regards to this assignment given to us. Samulco is currently run by people of diverse profession in the community, such as doctors, teachers, bankers, businessmen, accountant, policemen, and IT professionals. One of these people is Mr. James Bautista, an IT graduate, and the company’s systems analyst.

We started the interview by asking, “What skills and characteristics must a systems analyst develop in order to be more productive in any design modeling process?” Mr. James Bautista, the Samulco’s Management Information Systems supervisor answered us by defining first what a systems analyst is. According to him, a systems analyst should see the problem alone. Meaning, problem must be seen first before the solution. A systems analyst also needs to analyze and solve problems in an efficient manner so as to achieve results and meet deadlines. He or she should be able to mentally handle having several projects to monitor simultaneously, while possessing the ability to organize, prioritize, and show initiative in attacking the problem at hand. Now, going back to the first question, he gave us four answers.
First, is that the systems analyst must be a keen observer. A systems analyst must be keen to detail, must be observant in every single detail. Mr. James added that in any modeling process, if you miss a detail when the development had already started it signifies waste of human resource, time, and money. Second, a systems analyst must have developed basic programming skills. Although an analyst is not a programmer, he/she must have the knowledge about programming even just the basics. I think it is because a systems analyst and the developer/programmer is dependent with each other. The systems analyst looks at the requirements and designs the solution at the systems level. The analyst will often design the external interfaces and functionality of each piece, but will not get down to the implementation or code level since there’s a programmer to do that. The programmer takes the design from the analyst, and implements or codes each component, testing along the way to ensure that the implementation meets the design. This is also a two-way street. Say for example, during the implementation, the programmer may realize there is a need to revise the system design, and will go back to the analyst. The analyst will then integrate the required change/s into the design. Sometimes, these roles overlap. Certainly, if the project is small, the analyst and programmer can be the same person. Next, are the two characteristics that sir James define and differentiate. A systems analyst is a global thinker which means that an analyst should look in the overall of the project and not just the details while a developer is a systematic thinker or a local thinker that all he sees is the piece of codes and solutions to the problem. To further understand the difference between the two, here’s a sample situation: Two men were digging a hole in the ground. Someone stopped and asked what they are doing. First man answered that they are digging a hole in the ground. The second man said that they are building a house. Here, the local thinker is the first man while the global thinker is the second man. Fourth, an analyst should have a good communication skills. Communication skill is important in a systems analyst especially when dealing with clients, said sir James. Communicating with clients and coworkers is a very important step for a systems analysis to success on the job. A systems analyst must be really able to communicate well. Excellent verbal and written communication skills are a must for anyone wishing to pursue a career as a systems analyst. He or she also needs to be able to cooperate and get along with others while thriving in a team-oriented environment. A systems analyst must posses good interpersonal communication skills because they must be able to converse back and forth with the client over what the problem is and how to go about finding the best solution. This is the point where good problem solving skills come into play. In order to find the best possible solution, the systems analyst will have to define the problem and come up with a way to solve it that is most beneficial to everyone.

On that interview, I gained more knowledge about the systems analyst. I learned that an analyst must possess various skills to effectively carry out the job and that systems analysts need to be independent thinkers-people who can “think out of the box” by grasping concepts quickly and seeing the big picture as opposed to the small details. I am lucky having that chance to interview a real systems analyst for the reason that I clarified some queries in my mind regarding about
my systems analyst (personal thoughts, own conception) and the real systems analyst. The purpose of this interview is not just to have an answer on this assignment but to help us understand what really a systems analyst is. Thanks to sir James for allowing us to take some of his precious time for us to have an interview with him. Smile






Posted by ♪_TARIZTA_♪ at 11:43 PM | 0 comments
Based on your learnings of chapter 1, identify and discuss some charateristics you have as a good Systems Analyst.

A thinker who focuses on the problem as stated and tries to synthesize information and knowledge to achieve a solution, is a problem solver. A Systems analyst as defined is a business professional who uses analysis and design techniques to solve business problems using information technology. Therefore, a systems analyst is a problem solver. That is what I learned last Wednesday as we started discussing the world of information system analyst as the first topic of our Systems Analysis and Design I subject.

I learned many things about the systems analyst even the various characteristics an analyst should possess. An analyst as a business problem solver has computer technology knowledge and programming expertise that is, an analyst must certainly know about computers and computer programs, understands business problems, uses logical methods for solving problems, has fundamental curiosity which is an analyst must also bring to the job a fundamental curiosity to explore how things are done, wants to make things better and is more of a business problem solver than a technical programmer.
Now, the characteristics that I have that are similar to a good systems analysts are the following:
• Has computer technology knowledge and programming expertise. I may not be an expert in programming but I can slowly develop expertise in it and also possess special skills.
• Has fundamental curiosity. Since I like to know and explore how things are made and done.
• Has the determination to work better.

In chapter 1, I also learned about the required knowledge and skills for a systems analyst, the technical knowledge and technical skills where an analyst needs a technical expertise that should understand the fundamentals about computers, tools and techniques for developing systems, business knowledge and business skills which are those that apply to understanding business organizations, and people knowledge and people skills where interpersonal skills are involved. Interpersonal skills in business contexts often used to refer to the measure of a person’s ability to operate within business organization through social communication and interaction. Meaning, it is how people relate to one another.

Having recognized those knowledge and skills, I can tell that I possess some of those characteristics an analyst has. Talking about the technical knowledge and skills, since I am a computer literate and having some knowledge about technicalities, I may possess this kind of skill. For the business knowledge and business skills, systems analysts benefit from a fairly broad understanding of businesses, so during college years they typically study business administration. Computer information systems or management information systems majors are often included in the college of business for that reason. Just like what we have in our school for information technology students, management information systems were also included as one of our subjects. Including this kind of subject in a curriculum let the students learn and gain knowledge on how to manage businesses and how to deal with the information systems as well as the processes in a business organization. One must understand the organization, its culture, its mission, and its objectives before jumping to conclusions about system solutions. You cannot manage if you don’t have any idea on how an organization should be dealt with. It is a big help for us students to have at least an idea on how businesses perform in the real world especially when a student graduated and started to work. The learnings and the importance of it should not be overlooked for this is in fact, very useful and beneficial as they continue working on their future to achieve a successful career and have a better life. The last knowledge and skill which is the people knowledge and people skill is where I can relate most. This is where a lot should take notice of because of its involvement in people. People knowledge and people skills are perhaps the most important skill of an analyst because they rely on others such as the manager, users, programmers, technical specialists, customers, and vendors to take a system from initial idea to final implementation. To be a translator for all projects participants, translating business objectives, and even technical jargon and details into terms that nontechnical personnel can easily understand is a form of people skill. Also, being an effective communicator is another form of people skill.

Possessing those different characteristics of a good systems analyst proved me that I, even just a student can be an analyst too. It’s not always that one should hold a title on his profession and have been certified or should have all the required knowledge and skills and other specific characteristics for him to consider oneself that he/she is a good analyst. Those who do not hold any profession may think and analyze better than those who do. No one thinks the same as the other. They may have the same idea yet, they have their own special way of explaining and expressing their ideas in such a way others can understand what they were thinking and what exactly they were trying to convey to their listeners. A person differs from the other person. Always remember,
“You are unique, just like everyone else.” Smile

Posted by ♪_TARIZTA_♪ at 11:37 PM | 0 comments