A Dialogue between a system professional and a department manager.

SAD ASSIGNMENT # 6
A Dialogue between a system professional and a department manager.

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 sympathizes with the most.
b. What method would you propose they take? Why?
With the conversation they have from John Juan (systems professional) and Peter Pedro (department manager), they have different views and opinions about the new information system, first John Juan (systems professional) consider that the first way to go about the analysis is to first examine the existing system while Peter Pedro (department manager) considers the way to about the analysis is to first started with a list of our requirements. For me, I’ve agreed to the idea of the systems professional (John Juan) cause he consider in starting analysis phase it must start on analysis strategy then have an analysis plan then gather some information like what John Juan (systems professional) said to his dialogue such as examining the old system, like reviewing key documents and observing the workers perform their tasks also by conducting an interview with an expert and giving questionnaire to the users to be. Then analyze the existing system then determine exactly what you want the system to do. As a sum up, to their conversation, the right side of this is John Juan the system professional cause professional has more knowledge of this particular issue not with just the department manager Peter Pedro is just concern about it for he is the manager of the department and that they end up only in a modified version of the old system. According to wikipedia, the Information Systems Professional (I.S.P), or Informaticien professionnel agréé (I.P.A. in French), is a professional designation issued by the Canadian Information Processing Society (CIPS). Introduced in 1989, the professional designation is recognized by legislation in most provinces of Canada. Before meeting the entry requirements for professional status an applicant may use the "Candidate Member I.S.P" designation. CIPS has developed the Computer Science Accreditation Council (CSAC), and the Information Systems and Technology Accreditation Council (ISTAC) to accredit baccalaureate programs in Computer Science, Software Engineering, Management Information System, Computer Systems Technology, Applied Information Technology, and post-diploma type programs in Canada. These accredited programs combined with several years of experience lead to the I.S.P. Designation. From its meaning, it needs a lot of experience is required to be a systems professional. And it means that since the system professionals undergone that, we can say that system professionals really an excellent person for the system professionals surpassed that kind of challenge.
And according to the American Society for Information Science and Technology these are the responsibilities of the client/systems user and to the profession. For the clients/system users they must act faithfully for their employers or clients in professional matters, to uphold each user's, provider's, or employer's right to privacy and confidentiality and to respect whatever proprietary rights belong to them, by limiting access to, providing proper security for and ensuring proper disposal of data about clients, patrons or users and to treat all persons fairly. And for the profession they must be truthfully represent themselves and the information systems which they utilize or which they represent, by: not knowingly making false statements or providing erroneous or misleading information, informing their employers, clients or sponsors of any circumstances that create a conflict of interest, not using their position beyond their authorized limits or by not using their credentials to misrepresent themselves, following and promoting standards of conduct in accord with the best current practices, undertaking their research conscientiously, in gathering, tabulating or interpreting data; in following proper approval procedures for subjects; and in producing or disseminating their research results, pursuing ongoing professional development and encouraging and assisting colleagues and others to do the same and lastly adhering to principles of due process and equality of opportunity.
Just a short review from the previous assignments and to what I have research: systems/software development life cycle is a logical process undertaken by system analysts to develop an information system (wikipedia). It involves several phases necessary for the development, such as planning, analysis, design, and implementation. The usual first step in building up a system is initiation or planning. This is where the goals of the project is determined, or shall I say, the analyst or manager identifies the need or opportunity for improvement or a problem perhaps. So the concept is made for a proposal to the upper management. A feasibility study is typically conducted and this is to be submitted to the management in an attempt to gain funding. This is part of the analysis stage.
The analysis phase defines the requirements of the system, independent of how these requirements will be accomplished. It describes all the data, functional and behavioral requirements of the software under production or development. By having the requirements needed we must first observe to know what are needed. This phase defines the problem that the customer is trying to solve. The deliverable result at the end of this phase is a requirement document. Ideally, this document states in a clear and precise fashion what is to be built. This analysis represents the ``what'' phase. The requirement document tries to capture the requirements from the customer's perspective by defining goals and interactions at a level removed from the implementation details. There are several factors that must be checked that would assure the quality of the software and the developed system itself. These factors include security, data integrity, usage difficulty and future upgrades. Analysis Strategy may be looked upon as the starting point of the strategic management process. It consists of the advance work that must be done in order to effectively formulate and implement strategies. Many strategies fail because managers may want to formulate and implement strategies without a careful analysis of the overarching goals of the organization and without a thorough analysis of its external and internal environment. Organizations must have clearly articulated goals and objectives in order to channel the efforts of individuals throughout the organization toward common ends. Goals and objectives also provide a means of allocating resources effectively.
In the analysis stage you must gather some data that you think could help you. But in gathering those data you should have techniques to follow and decide to have an interview and take note all the interviewee answered. For me it’s the most effective technique to have though it takes a lot of courage to perform it successfully.
In analysis phase they must apply a plan overview which I think could introduce what the system is all about, next is the Interview schedule which will handle the session for interview and followed by the Interview questions which contains questions and lastly the Interview transcripts are for the recording and approved documentations coming from the interviewee and lastly the Observation.

With the definition of the analysis phase the requirements is essential to build a solution because It’s difficult to build a solution if you don’t know the requirements (in spite of the fact that many teams still try to do it today). The “elicitation” step is where the requirements are first gathered from the client. Many techniques are available for gathering requirements. Each has value in certain circumstances, and in many cases, you need multiple techniques to gain a complete picture from a diverse set of clients and stakeholders.
Analysis phase aim is to discover problems with the system requirements and reach agreement on changes to satisfy all system stakeholders. It is a transition phase from problem understanding to solution specification. It is a set of requirements that are of high quality, having the following characteristics: unambiguous, complete, consistent, realistic, conform to business goals, verifiable, traceable, and required. Also all stakeholders must agree it. However, analysis is difficult, identifying problems and understanding requirements’ implications is difficult. Most large software systems address wicked problems. Different stakeholders have different requirements and priorities. There is a constantly shifting compromise in defining the requirements. Therefore, requirements are normally both incomplete and inconsistent. Modeling is also part of analysis. Building an abstraction or what we called model of the problem enables us to answer questions about the system. Requirements collected during requirement elicitation are transformed into a model that describes the system. The development of models of the problem is fundamental to requirements analysis. Requirements analysis is a modeling activity. We build models so that, we can comprehend the problem better, to communicate with stakeholders, to deal with complexity and also to find errors or omissions. Several kinds of models that can be developed include: Data and control flows, State models, Event traces, User interactions and also Object models. One factor influencing the choice of models is the nature of the problem, like for example the control flow and state models are likely to be more important for real-time systems than for an information system. Another factor is the expertise of the requirements engineer, the process requirements of the customer, the availability of methods and tools. No single model is sufficient. Every nontrivial system is best approached. Analysis Methods are methods for requirements analysis that are sometimes characterized by orientation. The Process or function-oriented is one of the analysis method, like the Classical structured analysis (SA), Structured analysis and design techniques (SADT) are one of the methods. Another method is the Data-oriented like the Entity-Relationship (ER) modeling. Another method is the Control-oriented like the Flowcharting. Another method is the Formal method like Z, VDM, and Object-Z. And lastly, the Object-oriented like OMT, Booch, UML is another method of analysis. I propose that the method they will use is the Object oriented because it is easy to understand. The Object-Oriented Lifecycle is an Object-oriented approach that can be used with any lifecycle model. Object-oriented approaches encourage object evolution - analysis objects evolve into design objects, which evolve into implementation objects. Object evolution - simplifies trace ability and verification of implementation. UML defines a notation a set of diagrams, the notation is the graphical stuff to build models; it is the concrete syntax of the modeling language, the meta-model defines the abstract syntax and the static and dynamic semantics of modeling concepts provided in UML Graphical notation for System structure and System behavior. It also covers multiple system views like Static structure (class/object/use case diagrams), Distribution structure (component/deployment diagrams), Interaction (sequence/collaboration diagrams), State change (state-charts), and Use cases/services (Use case/activity diagrams). It is also a tool for systematic development of component-oriented software architectures.
Wherein the use of Case Modeling Objectives is to define the functional and operational requirements of the system by defining a scenario of usage that is agreed upon by the end-user and the developer team. Also, to provide a clear and unambiguous description of how the end-user and the system interact. A use case presents business functionality in many cases, a functional requirement maps directly to a use case. An actor represents whoever or whatever that interacts with a use case. Hence, use cases are determined from the analysis of: functional requirements, and the identification of actors and their tasks.
As a summary, in analysis phase you must have an analysis strategy then have an analysis then gather information like examine the old system, such as reviewing key documents and observing the workers perform their tasks also by conducting an interview with an expert and giving questionnaire to the users to be. Then analyzing the existing files and determining the exact system you want to do. I propose that they will follow Object Oriented method. Object-oriented are specified and documented through process of building models. Modelling process starts with identification of use cases and problem domain classes or things in users’ work environment.