My Skills

• Computer Literate

• Programming

• Fundamentals of Computer Science

• Networking

• Website Developer

Enterprise Resource Planning (ERP)

From news article or internet information, find an example of an organization that is installing an ERP package. If possible get a copy of the over-all project plans and analyze the various activities and compare them with a standard SDLC.

This the article that discussed the implementation of ERD to Matsushita Communication Industrial Corporation of the Philippines (MCP), now Panasonic Mobile Communications Corporation of the Philippines.

Matsushita Communication Industrial Corporation of the Philippines

• Industries: Manufacturing
• Offering Groups: Solutions
• Solution Areas: Enterprise Resource Planning
• Regions: Philippines

The Matsushita Communication had a direction to standardize the operations of all its overseas companies through the implementation of an Enterprise Resource Planning (ERP) solution.

The company decided to use Glovia, an ERP solution that addresses the needs of the discrete manufacturing market, developed by Glovia International. Glovia defined their global standards in production planning, production, and inventory control systems. The project was successfully completed in 4.5 months and with the outstanding performance of the Fujitsu Philippines team in this activity, MCI decided to partner with the company in all other Matsushita implementations around the globe.

The article does not discuss the overall project plans it only discusses the phase of the implementation was focused on the cellular phone business of the Overseas Mobile Telephone Division (OMTD). This also led to the development of specific add-on functions, which were done by Fujitsu Japan.

Enterprise Resource Planning (ERP)

In this assignment we would know all about ERP-its advantages and disadvantages that can be made to the organization and companies that installing this package.

ERP

ERP is Enterprise Resource Planning. It is the present evolution of manufacturing resources planning systems. ERP provides the foundation for integrating enterprise-wide information systems. These systems will link all aspects of a company's operations including human resources, financial planning, manufacturing, and distribution, as well as connect the organization to its customers and suppliers. Examples of ERP packages are HRMS, Financials, Manufacturing, Distribution, and Sales. Each ERP Package may offer different functionality for different industries. ERP (Enterprise Resource Planning) systems typically include the following characteristics: (1) An integrated system that operates in real time (or next to real time), without relying on periodic updates. (2) A common database, which supports all applications. (3) A consistent look and feel throughout each module. (4) Installation of the system without elaborate application/data integration by the Information Technology (IT) department. Advantages of an ERP system:

- Information entered once into system .

- Forces use of the best practices.

- Allows customization.

- Based on reliable file structure.

- Provides functionality to interact with other elements in the process.

- Provides tools for ad hoc queries.

And also according to ERP Software Solutions there are five major benefits of ERP:

• On-line/real time information throughout all the functional areas of an organization.
• Data standardization and accuracy across the enterprise.
• Best-practices or optimized solutions are included in the applications.
• Creates efficiencies that organizations would not otherwise have.
• The analysis and reporting that can be used for long-term planning.

In implementation, ERP systems include several basic features. They are installed on a Database Management System. Database platforms to choose from are: DB2/400, DB2/MVS, DB2/Unix, Informix, MS SQL Server, Oracle, SQLBase, and Sybase. They require initial setup according to the organization's process. They may be customized according to the organization's process through the ERP's tool set. Work flow can be setup to automate approval processes through chains of command. Once installed, the user only enters data at one point, and the information is transferred through processes to other modules. Finally, the ERP system includes reporting tools for main reports.

ERP and SDLC

There are many differences of Enterprise Resource Planning and System Development Life Cycle such as the in the ERP’s features. The ERD system is the foundation of the company-wide Integrated Information System, performing foundations corporate activities and increases customer service, belief that it is the only solution for better Project Management compared to the other planning tools, addressing not only the current requirements of the company but also providing the opportunity of continually improving and refining business processes and above all, providing business intelligence tools like Decision Support Systems (DSS), Executive Information System (EIS),Reporting and many more that can help the company in the decision making to improve its business process.

References:

http://en.wikipedia.org/wiki/Enterprise_resource_planning

http://www.fujitsu.com/ph/casestudies/matsushita.html

http://erp.cc/erpinfo.htm

ASSIGNMENT 11

You were tasked by the IC-dean to evaluate the enrollment system of the university, list and briefly describe the characteristics that an analyst (you) examines when choosing or defining deployment environment.

As an assignment I was tasked by the IC-dean to evaluate the enrollment system of the university. In evaluating the enrollment system of the university there are many things to consider in evaluating it. And one of the primary considerations in developing a new information system is the application deployment environment. As the definition says that deployment environment is a collection of configured clusters, servers, and middleware that collaborate to provide an environment to host software modules. An important part of any project is ensuring that the application deployment environment is defined and well matched to application requirements. At this life cycle stage, the analyst’s goal is to define the environment in sufficient detail to be able to choose from among competing alternatives and to provide sufficient information for design to begin.

These are the characteristics examines when choosing or defining deployment environment:

Consider the configuration
In this characteristic the Analyst must consider the configuration of computer equipment, the operating systems, and also the networks that will exist when the new application system is deployed.

Determine the constraints
The second one is that the analyst must determine the limitation that are imposed on the system development and its alternatives.

Define Environment
The third one is that the analyst must define its environment or its multiple environmental choices that can match the application requirements.

Define Application
The analyst must define the organization’s strategic application.

Define Plans
The analyst must define technology architecture plans.

Determining Alternatives
Prioritizing the requirements is determining what alternatives are possible for developing the solution.

In conclusion with this deployment environment choices, specifically with its operating system, the Database Management System, and also the distribution of the software in the case of its standardization, the tendency to limit the development tool choices. With this, the analyst should consider all the development and the development environments together when it comes in determining on fitting to a particular application.

Assinment 10: With reference to assignments 8 and 9, what characteristics does an analyst(you) examine when evalauating DFD quality? (1500 words)

As an introduction to the assignment ten, base on the assignment eight and nine we are task to make an UML Unified Modeling Diagram-different diagrams that can illustrate a process or system, in our case we are task to illustrate the pre-enrollment of University of Southeastern Philippines. In assignment eight we are task to develop an activity diagram and a fully developed description for a use case. Activity Diagrams are usually used to a business process model, for modeling the logic captured by a single use case of a business or a system, it is also for modeling the detailed logic of a business rule or the rules of the system how it works. Creating activity diagrams are very useful in describing the flow control of the target system. It is also helpful in determining the use cases and the business processes of a company or a system that a company may use. With the assignment nine we are task to create at least 3 different types of Data flow diagram of USEP's pre-enrollment system. First we defined what data flow diagram is all about. Data flow diagram is a graphical representation of data on how the process goes in the system or business. According to Scott W. Ambler data flow diagram shows the flow of the data from external entities into the system, how the data moved from one process to another as well as its logical storage. Data flow diagram can also be used for the visualization of data processing. A Data flow diagram provides no information about the timing of processes, or about whether processes will operate in sequence or in parallel. It is therefore quite different from a flowchart, which shows the flow of control through an algorithm, allowing a reader to determine what operations will be performed, in what order, and under what circumstances, but not what kinds of data will be input to and output from the system, nor where the data will come from and go to, nor where the data will be stored. Also according to Hoffer, George and Valacich there are two defined data flow diagrams, includes context diagram and level-O diagrams. To differentiate, context diagram is a data flow diagram (DFD) of the scope of an organizational system that shows the system boundaries external entities that interact with the system and the major information flows between the entities and the system. On the other hand, level-O diagram is a data flow diagram (DFD) that simply represents a system’s major processes, data flows and data stores at a high level detail.

The data flow diagram has a purpose and it provide the meaning between users and systems developers. And it diagrams are first graphical, eliminating thousands of words; second is logical representations, modeling WHAT a system does, rather than physical models showing HOW it does it; third is hierarchical, showing systems at any level of detail; and allow the user to understand review the process.

There are characteristics examined in evaluating the data flow diagram. First is Remember, also referred to as recognition or recall. Be able to remember or recognize terminologies, definitions, facts, ideas, materials, patterns, sequences, methodologies and principles. Second is to Understand. Will be able to read and understand descriptions, communications, reports, tables, diagrams, directions and regulations. Third is to Apply. Be able to apply the ideas, procedures, methods, formulas, principles, theories and to the related situation that can be apply on the diagram. Fourth is Analyze. To be able to break down information into its constituent parts and recognize the parts’ relationship to one another and how they are organized; understand the data’s from a complex process. The fifth one is to Evaluate. To be able to make judgments regarding the value of proposed ideas, solutions, methodologies, and many more by using the proper standards to estimate accuracy, effectiveness, economic benefits, and many more. The last one is to Create. Be able to identify which data or information from a complex set is appropriate to examine further or from which its supported conclusions can be drawn.

Data flow diagram has the following symbols: Process flow diagrams. It has the following entities, process number, where the activity is happening and its process name. Data flow datagram. It symbolizes the transformation of data, there must be data flowing into/out of the process, process can have several inputs to it or output to it and process with no out becomes a null process. Data store Symbol. Consist of the following entities, data store number and name of data store. The function of data store is to designate the storage of data in a DFD diagram. Rules of Data store-First rule is that the data flow diagram data store do not by level but they may reappear incase needed and secondly that the symbol and the numbering remain the same. Data flow symbol. Data flow symbol may appear in different shape and they signify the movement of data. They do not signify the movement of people, goods. Doubles an arrow signifies that activities occur at the same time which is wrong and Data flow in is never equal to data flow out. Extended entity symbol. Extended entity is sources and destination of data. This means that source is the origin and destination is the sink of data.

Dos and Don’ts of external entity
• External entity never communicate with each other, this signify that there is no need for the process
• External entity should not communicate directly with data store because external entities can be identifier with the record of files and databases

How to develop Logical data flow diagram

Below are the guidelines in developing data flow diagrams
1. Develop a physical DFD
2. Explore the process for more details
3. Maintain consistency between the process
4. Following meaningful leveling convention
5. Ensure that DFD diagrams clarifies what is happening in the system
6. Remember DFD audience
7. Add control on the lower level DFD only
8. Assign meaningful level
9. Evaluate DFD for correctness

Step in drawing DFD diagrams
1. Make a list of all business activities and use it to determine the various external entities, data flows, process and data store
2. Create a context diagram which shows external entity and data flows to and from the system
3. Do not show any detailed process or data store
4. Draw diagram zero or the next level to show process but keep them general. Show data stores and the level
5. Create a child diagram for each of the process in diagram zero
6. Check for errors and make sure the levels you assign to each process and data flow are meaningful
7. Develop a physical DFD diagram from the logical DFD and distinguish between the manual and automated protocol, describe actual files and report by name and controls to indicate when the process are complete or errors occurs
8. Portion the physical DFD by separating or grouping parts of the diagram in order to facilitate programming and implementation

Advantages of data flow diagrams
• It gives further understanding of the interestedness of the system and sub-systems
• It is useful from communicating current system knowledge to the user
• Used as part of the system documentation files
• Dataflow diagram helps to substantiate the logic underlining the dataflow of the organization
• It gives the summary of the system
• DFD is very easy to follow errors and it is also useful for quick reference to the development team for locating and controlling errors

Disadvantages of data flow diagram
• DFD is likely to take many alteration before agreement with the user
• Physical consideration are usually left out
• It is difficult to understand because it ambiguous to the user who have little or no knowledge.

Data Flow Diagram Principles

* The general principle in Data Flow Diagramming is that a system can be decomposed into subsystems, and subsystems can be decomposed into lower level subsystems, and so on.
* Each subsystem represents a process or activity in which data is processed. At the lowest level, processes can no longer be decomposed.
* Each 'process' (and from now on, by 'process' we mean subsystem and activity) in a DFD has the characteristics of a system.
* Just as a system must have input and output (if it is not dead), so a process must have input and output.
* Data enters the system from the environment; data flows between processes within the system; and data is produced as output from the system


1. A system can be decomposed into subsystems, and
subsystems can be further decomposed into lower level
subsystems.
2. Each subsystem represents a process or activity in which
data is processed.
3. At the lowest level, processes can no longer be decomposed.
4. Each 'process' has the characteristics of a system. A process
must have input and output.
5. Data enters the system from the environment, data flows
between processes within the system and data is produced
as output from the system.

General Data Flow Rules
1. Entities are either 'sources of' or 'sinks' for data input and outputs - i.e. they are the originators or terminators for data flows.
2. Data flows from Entities must flow into Processes
3. Data flows to Entities must come from Processes
4. Processes and Data Stores must have both inputs and outputs (What goes in must come out!)
5. Inputs to Data Stores only come from Processes.
6. Outputs from Data Stores only go to Processes.

Now, back to the main question, what characteristics does an analyst (you) examine when evaluating DFD quality? To be honest, I really had a hard time thinking of how to create good and perfect data flow diagrams. But with the guidelines above information that is mentioned I think I can evaluate A data flow diagram.

References:

http://hubpages.com/hub/What-is-a-data-flow-diagram

http://www.agilemodeling.com/artifacts/dataFlowDiagram.htm

http://www.asq.org/certification/quality-process-analyst/bok.html

http://www.cmp.jobs/qa-analyst-1153.php

http://spot.colorado.edu/~kozar/DFDtechnique.html

Usep's Pre-Enrollment Activity Diagram and its USe Case Description

USEP's Pre-Enrollment System (A use-case diagram)

In order to be admitted to the University of Southeastern Philippines, prospective students must gain official admission to the university and must undergo the first step--the pre-enrollment process and it is best describe in this

USE CASE DIAGRAM

Use Case: APPLICATION

Actors: student, UGTO
Description: The student will submit all the necessary requirements for enrollment at the University Guidance and Testing Office (UGTO).

Use Case: PAYMENT OF THE ENTRANCE EXAMINATION
Actors: student, cashier
Description: Student presents the POS to the cashier and pays the examination fee. In return, the cashier will issue official receipt.

Use Case: EXAMINATION PROCESS
Actors: student, UGTO
Description: The student presents the receipt to UGTO and asks the UGTO for the examination schedule. The student will take the entrance exam on the said date in which the UGTO personnel shall administer the testing process. After a few days, the applicant gets the results of the exam, and after verifying the results, pass the results to the college.

Use Case: INTERVIEW
Actors: student, college adviser
Description: If the student passes the exam, the student presents the result to the college adviser of the respective college depending on the student what course they may choose. The student shall now undergo the interview process conducted by the college adviser. The student will be given an admission slip or notice of acceptance if ever the student will be accepted.

Use Case: ENGLISH BRIDGE PROCESS
Actors: student , English teacher
Description: This use case is for the student who has failed the English examination. The student shall take the English bridge program of the university before enrolling.

Use case: MEDICAL
Actors: student, University Doctor
Description: The student must undergo a medical examination before enrolling. The student will be examined by the University doctor in the university clinic to check the health condition of the student.

And if the student passes all the tests that the use case diagram describes, the student can now proceed to the proper enrollment process.

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.