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.

Openbravo is an award-winning developer of professional open source solutions for businesses, offering the industry's first real alternative to proprietary enterprise software. The company's web-based Enterprise Resource Planning (ERP) and Point of Sale (PoS) solutions, the most popular in their market, have been downloaded more than 1.5 million times and are used in over 50 countries.
Openbravo ERP is a web-based business management system developed to help organizations streamline their daily operations and optimize back-office processes. The latest release, Openbravo ERP 2.50 Professional Subscription, introduced the concept of modularity, simplifying customization and the creation of third party add-ons. This makes it even easier for organizations to tailor their ERP system to their exact needs, while maintaining upgradability.
Openbravo ERP is now included in the Ubuntu partner repository, allowing Ubuntu users to add the software quickly and easily to their Ubuntu server. The newly created Openbravo ERP Professional Subscription for Ubuntu provides expert support and business continuity for the entire open source software stack, which includes the ERP software, operating system, application server and database.

What is ERP?
ERP (Enterprise Resource planning) covers the technique and concepts employed for the integrated management of business as a whole, from the viewpoint of the effectiveness use of management resources, to improve the efficiency of an enterprise. ERP packages are integrated software packages that support the above ERP concepts.
An Enterprise Resource Planning system (ERP) is a collection of modules/components integrated together while utilizing one database typically used primarily by medium to large manufacturing organizations with multiple sites located worldwide. Connecting to one database allows users from all departments of the organization located anywhere in the world to attain the necessary information to carry out their responsibilities. This integration approach offers improved operational processes and streamlined information to the fingertips of anyone with the security rights to access it. Paper documents are reduced or eliminated as online documents travel throughout the system to the appropriate department for updating and forwarding. Transactions pass through the system automatically updating several modules/components in real-time to provide timely and accurate data for users to access and share from any location in the world.

Phases of ERP Implementation Life Cycle

1. Pre-evaluation Screening
Once the company has decided to go for the ERP system, the search for the package must start as there are hundreds of packages it is always better to do a through and detailed evaluation of a small number of packages, than doing analysis of dozens of packages. This stage will be useful in eliminating those packages that are not suitable for the business process.

2. Package Evaluation
This stage is considered an important phases of the ERP implementation, as the package that one selects will decide the success or failure of the project. Implementation of an ERP involves huge investments and it is not easy to switch between different packages, so the right thing is ‘do it right the first time’. Once the packages to be evaluated are identified, the company needs to develop selection criteria that permit the evaluation of all the available packages on the same scale.

3. Project Planning
This is the phase that designs the implementation process. It is in this phase that the details of how to go about the implementation are decided. Time schedules deadlines, etc for the project are arrived at. The plan is developed, roles are identified and responsibilities are assigned. It will also decide when to begin the project, how to do it and it completion. A committee by the team leaders of each implementation group usually does such a planning.

4. Gap analysis
This is considered the most crucial phase for the success of ERP implementation. This is the process through which the companies create a complete model of where they are now, and in which direction will they opt in the future. It has been estimated that even the best packages will only meet 80% of the company’s requirements. The remaining 20% presents problematic issues for the company’s reengineering.

5. Reengineering
It is in this phase that human factors are taken into consideration. While every implementation is going to involve a significant change in number of employees and their job responsibilities, as the process becomes more automated and efficient, it is best to treat ERP as an investment as well as cost cutting measure.

6. Team training
Training is also an important phase in the implementation, which takes place along with the process of implementation. This is the phase where the company trains its employees to implement and later, run the system. Thus, it is vital for the company to choose the right employee who has the right attitude- people who are willing to change, learn new things and are not afraid of technology and a good functional knowledge.

7. Customization
This is the main functional area of ERP implementation. There is a bit of mystique around the customization process and for good reason: the Holy Grail of ERP implementation is synchronizing existing company practices with the package. In order to do so, business processes have to be understood and mapped in such a way that the arrived-at solutions match up with the overall goals of the company. But, companies cannot just shut down their operations while the mapping processes take place. Hence the prototype-a simulation of the actual business processes of the company-will be used. The prototype allows for through testing of the “to be” model in a controlled environment. As the ERP consultants configure and test the prototype, they attempt to solve any logistical problems inherent in the BPR before the actual go-live implementation.

8. Testing
This is the phase where one tries to break the system. One has reached a point where the company is testing the real case scenarios. The system is configured and now you must come up with extreme cases like system overloads, multiple users logging on at the same time, users entering invalid data, hackers trying to access restricted areas and so on. This phase is performed to find the weak link so that it can be rectified before its implementation.

9. Going Live
This is the phase where ERP is made available to the entire organization. On the technical side the work is almost complete: data conversion is done, databases are up and running and on the functional side, the prototype is fully configured and tested and ready to go operational. The system is officially proclaimed operational even though the implementation team must have been testing it and running it successfully for some time. But once the system is ‘live’ the old system is removed and the new system is used for doing business.

10. End-user Training
This is the phase where the actual users of the system will be given training on how to use the system. This phase starts much before the system goes live. The employees who are going to use the new system are identified. Their current skills are noted and they are divided into groups based on the current skill levels. Then each group is given training on the new system. This training is very important as the success of the ERP system is in the hands of the end-user. So, these training sessions should give the participants an overall view of the systems and how each person’s actions affect the entire system.

11. Post implementation
Once the implementation is over, the vendor and the hired consultants will go. To reap the fruit of the implementation it is very important that the system has wide acceptance. There should be enough employees who are trained to handle problems those crops up time to time. The system must be updated with the change in technology. The post implementation will need a different set of roles and skills than those with less integrated kind of systems. At a minimum, everyone who uses these systems needs to be trained on how they work, how they relate to business process and how a transaction ripples through the entire company whenever they press a key.
However, an organization can get the maximum value of these inputs if it successfully adopts and effectively uses the system.
-----------------------------------------------
System development life cycle. SDLC is the process of developing information systems through investigation, analysis, design, implementation and maintenance. SDLC is also known as information systems development or application development. SDLC is a systems approach to problem solving and is made up of several phases, each comprised of multiple steps:

• The software concept - identifies and defines a need for the new system

• A requirements analysis - analyzes the information needs of the end users

• The architectural design - creates a blueprint for the design with the necessary specifications for the hardware, software, people and data resources

• Coding and debugging - creates and programs the final system

• System testing - evaluates the system's actual functionality in relation to expected or intended functionality.

software development life cycle (SDLC) and also synonymous with software process as well as software engineering, it is a structured methodology used in the development of software products and packages. This methodology is used from the conception phase through to the delivery and end of life of a final software product. See under software engineering.


REFERENCE:
http://docs.google.com/viewer?a=v&q=cache:l5xlR5Ocv3sJ:www.ubuntu.com/system/files/Openbravo%2520Professional%2520Suscription%2520for%2520Ubuntu%25205%2520Aug%252009.pdf+organization+that+is+installing+an+ERP+package&hl=tl&gl=ph&pid=bl&srcid=ADGEESihjSMgxh6OsM6iF8qNeA820kBNhY7WNeJJGpdNavzHvTXQvMu7J9XL9cBVtNRrgTFpB8hZKXroM_VK7Y18iwVjhg9rdvQ6VtG8ZVGeZyy_8TimXEgc5wFY48m-kp2bfE7osbeF&sig=AHIEtbSHJvXdmj2SPENg7g9PfILdlaN0lg
http://www.docstoc.com/docs/5410205/ERP-Implementation
http://www.webopedia.com/TERM/S/SDLC.html
http://www.openbravo.com/about-us/

Characteristics examines when choosing or defining deployment environment

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.


One of the primary considerations in developing a new information system is the application deployment environment. The application deployment environment is the configuration of computer hardware, system software, and networks in which the new application software will operate. 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
Analysts consider the configuration of computer equipment, operating systems, and networks that will exist when the new application system is deployed.


Determine the constraints
The analyst must determine the constraints that are imposed on the system development alternatives.

Define Environment
The analyst must define an environment, or multiple environmental choices, that match 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 sum, application deployment environment choices, particularly the operating system, DBMS, and distributed software standard, tend to limit development tool choices. Thus, an analyst should consider the deployment and development environments together when determining their fit to a particular application.


REFERENCE:
http://books.google.com.ph/books?id=-ot62DeCKO4C&pg=PA309&lpg=PA309&dq=characteristics+that+an+anlayst+examines+when+choosing+or+defining+deployment+environment&source=bl&ots=V0x_RrJEXy&sig=ps0TRNmjo8XOHg7SB59vcqAN7Ng&hl=tl&ei=VTSOS9S2O4SQtgPk4qnZCA&sa=X&oi=book_result&ct=result&resnum=2&ved=0CA0Q6AEwAQ#v=onepage&q=&f=false

what characteristics does an analyst(you) examine when evalauating DFD quality?

With reference to assignments 8 and 9, what characteristics does an analyst(you) examine when evaluating DFD quality?


An analyst must know how to define every process on a Data flow diagram. He/ she must know how to keep braking down Data flow diagram to more detailed one. He/ she must understand the algorithm to be able to describe the process. He/ she must know how to decide. He/ she must identify the decision variable. He/ she must need to consider the number of locations of users, the processing and data access requirement, volume and timing of processing and access. He/ she must be able to translate the process into a diagram. He/ she must describe complex interactions and also alternative approaches. And also the systems-analyst author knows when he or she has reached the end.

But before I give details to the characteristics I examine when evaluating Data flow diagram, I would like to give some details what a Data flow diagram is. This is according to www.about-knowledge.com. Data flow diagram is a geographical tool that shows, process, flows, stores and external entities in a system. Data flow diagram shows the transformation of data into a system. Data flow diagram has got the following symbols. In Process flow diagrams, process symbol has got the following entities, process number (tells the number of the process), locality (where activity is happening) and a process name. Data flow datagram process symbol rules 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. 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 data flow diagram. Data flow symbol may appear in different shape and they signify the movement of data. They do not signify the movement of people, and goods. Doubles arrows signifies that activities occur at the same time which is wrong. Data flow in is never equal to data flow out. In 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. There are Dos and Don’ts in 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. There are two main types of analysis. The structured analysis and the object oriented analysis. The main phases of Structured Analysis are as follows: Requirements determination, structured modeling, Data modeling, and Alternative solution generation. The main phases of Object Oriented Analysis are as follows: Requirements determination, Object oriented modeling, Data modeling, and Alternative solution generation. The main sources from which the analyst can gather requirements are books, journals, people, current system documentation, websites, and articles. Break the business rules. For example, there is a rule that an organization can only use standalone system for all of its branches because of security reasons and an analyst can convince them to use online system having Internet securities.


According to Conrad Weisert, Information Disciplines, Inc., Chicago.
The elements of a Data flow datagram
A Data flow datagram contains four kinds of symbol:

1. Processes -- The only active elements. Processes cause something to happen. They have embedded descriptions, often in verb-object form. (Sometimes informally called "bubbles" because of their shape in an early version of SA.)
2. Terminators -- Represent users or other systems, i.e. entities outside the boundary of the system being described.
3. Data flows -- Composite data items (or objects) that pass either

From any element to a process (input dataflow) or from a process to any element (output dataflow)

4. Data stores -- Holding places for data flows; often implemented by databases.

Systems analysts apply this checklist to look for errors in their Data flow datagrams:

1. Every process must have at least one input dataflow (Violators are called "magic" processes, since they claim to do something based on no input, not even a trigger.)
2. Every process must have at least one output dataflow (Violators are called "black hole" processes, since their inputs are swallowed up for no reason.)
3. Every dataflow must connect two elements. One of them must be a process; the other can be a terminator, a data store or another process.
4. Each dataflow diagram should contain no more than six or seven processes and no more than six or seven data stores, and all the processes should be conceptually at the same level of detail. If a part of the system is too big or too complicated to describe in an easily grasped diagram, break it down into two or three lower-level diagrams. (We sometimes see hanging on an office wall a huge tour de force DFD that tries to describe an entire large system at a low level of detail with several dozen processes and convoluted intersecting dataflow arrows. That's not something to be proud of. It doesn't communicate to any audience.)
5. For every process, one of the following must eventually be true:
1. The description label is so simple and unambiguous that every reader will understand it in exactly the same way.
2. It is expanded or decomposed into a separate lower-level dataflow diagram that preserves exactly the same net inputs and outputs, but shows internal detail, such as data stores and internal processes.
3. It is rigorously described by a separate process specification (business rule, decision rule, function definition, algorithm, etc.).

The starting point: Context (level-0) diagram

The systems analyst begins by preparing the top-level DFD. This "context diagram" shows the entire system as a single process. Interactions with users and other external entities are shown as data flows.

The context diagram, although often almost trivially simple, serves two essential purposes:

* It clarifies to the user audience the analyst's understanding of the scope of the proposed system, the kinds of users the system will have, and the data coming out from and going into the system. A surprising number of misunderstandings are exposed at this early stage.
* It motivates and establishes a framework for the more complicated next level (below).

The system diagram (level-1 DFD)

After everyone agrees that the context diagram is correct and complete, the systems analyst examines the first-level breakdown of major functions. Most systems can be decomposed into between two and seven major areas.

The result is called the "system diagram&quot. It gives a clear overview of the system and serves as a base for further decomposition.

The end
The dataflow diagrams are complete when:

* Every process on every DFD complies with rule number 5 above.
* Every dataflow shown on every DFD is defined in the data dictionary.

There's more to come, but the remaining components of the system specification (or detailed user requirements documentation) have little or no effect on the functionality of the proposed system. Note that the information contained in these documents is essential not only as a foundation for building a custom application but also as a basis for evaluating and choosing a packaged application software product.


Analyst is the most responsible person for the new system project management and therefore he should possess and behaves the following characteristics. The analyst should: Question about every aspect of current and new system. Assume that every thing is possible and do not accept such sort of statements, "This is a routine operation to perform such type of job in our organization". Pay intension to each and every single answer because each answer could generate many important questions related to problems of current system. Restructure his mind before the development of each new system and do not correlate with previously developed systems. Have excellent communication skills. Identify and translate the problem of current system. Generate the maximum solution of the problem. Explain the logic of his solutions. Learn from mistakes. Not be bias to the customer or the software house for which he/she is working. In developing a physical data flow diagram, an analyst must explore the process for more details. Maintain consistency between the processes. Follow meaningful leveling convention. Ensure that data flow diagram clarifies what is happening in the system. Always remember data flow diagram audience. Evaluate data flow diagram for correctness. The system analyst must be able to communicate in writing and orally. The analyst must easily get along with people. The analyst must be a good listener and be able to react to what people say. The analyst must be knowledgeable of technology. The analyst is not expected to know the intricacies of programming, but a decent general knowledge of concepts and terms is essential. The analyst must be knowledgeable of business. The analyst is not expected to be an expert in business but a decent understanding of the client's world is required.



References:

http://www.docstoc.com/docs/16829052/ITEC-2010-Chapter-6---Data-Flow-Diagrams
http://www.about-knowledge.com/software-project-analysis-and-characteristics-of-an-analyst-and-types-of-analysis/
http://hubpages.com/hub/What-is-a-data-flow-diagram
http://www.idinews.com/life-cycle/dataflow.html
http://www.idinews.com/life-cycle/dataflow.html

Create at least 3 different types of Data flow diagram of USEP's pre-enrollment system

-------------------------------------------------------------------------------------------


---------------------------------------------------------------------------------------------

develop an activity diagram

This use case initiates when the applicant get an application form. The applicant fill up the form and that form will be check by the UGTO officer. When the form is accepted, the cashier will assess the applicant's liabilities. The applicant then pay the liabilities and receive a receipt and the schedule of the examination. When the examination day come, the exam applicant will have the examination, then the examination officer will check the examination papers. When the applicant pass the examination, the applicant will will have the medical examination. After that the applicant will proceed at the interview process. the interviewer will assess the applicants performance and submit the applicants' final assessment to the Dean. The Dean then finalize the List of Accepted Applicants.

develop a use case diagram and write a brief use case description.

dialogue between a systems professional

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?

These two workers have different views; John Juan believe that the way to go about the analysis is to first examine the old system while Peter Pedro believes the way to go about the analysis is to first started with a list of our requirements. I sympathized more with John Juan. I also believe that in starting analysis phase it must start on analysis strategy then have an analysis plan 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 analyze the old system then determine exactly what you want the system to do.

The analysis phase describes the requirements of the system; it describes all 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 answers the questions that start with what, that is connected with the system. 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.

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 factors 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.
The Use 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 a 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.

To summarize all, 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 analyze the old system then determine exactly what you want the system 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. I propose that they will use any of the following that fits the requirements; Use case model – a collection of models to capture system requirements. Use case diagram – identify actors and their roles and how the actor roles utilize the system. Activity diagram – a type of workflow diagram that describes the user activities and their sequential flow. Systems sequence diagrams (SSDs) – define inputs and outputs and sequence of interactions between user and system for a use case