IDS 405Home
IDS 405
The purpose of the analysis phase is to figure out what the business needs. The purpose of the design phase is to decide how to build it. At the end of the design phase, the project team creates the final deliverable for the phase called the system specification. The system specification contains:
A workaround is a custom-built add-on program that interfaces with a packaged application to handle special needs. It is a way to create needed functionality that does not exist in the software package.
System integration refers to the process of building new systems by combining packaged software, existing legacy systems, and new software written to integrate these.
Outsourcing: Hiring an external vendor, developer, or service provider to create a system.
Two important points about outsourcing:
There are three primary types of contracts that can be drawn to control an outsourcing deal:
Is the business need for the system common and do technical solutions already exist? Packaged systems are good alternatives for common business needs; a custom alternative should be explored when the business need is unique or has special requirements; and outsourcing is the best choice if the business need is not critical to the company.
Does in-house experience exist for all the functional and technical needs of the system? It will be easier to build a custom application is these skills exist than if they do not. A packaged system may be a better alternative for companies that do not have the technical skills to build the desired system. Outsourcing is a good way to bring in outside experience that is missing in-house so that skilled people are in charge of building the system.
The skills that are applied during projects are either technical (e.g. Java, SQL) or functional (e.g. e-commerce), and different desgin alternatives are more viable depending on how important the skills are to the company's strategy. If, for instance, certain technical and functional expertise is important to the organization, then the organization should probably develop the system in-house, using company employees so that the relevant skills can be developed and improved. On the other hand, some skills may be beyond the technical expertise of employers or not of interest to the company's strategists (for example, operational issues that needs to be handled). In this cases, packaged systems or outsourcing should be considered so internal employees can focus on other business-critical applications and skills.
When time is a factor, the project team should probably start looking for a system that is already built and tested. (Of course, this assumes that the package can be installed as-is and does not need many workarounds to integrate it into the existing business processes and technical environment.
An aternative matrix can be used to organize the pros and cons of the design alternatives do that the best solution will be chosen in the end. It is a grid that contrains the technical, budget, and organization feasibilities for each system candidate, pros and cons associated with adopting each solution, and other information that is helpful when making comparisons. Sometimes weights are provided for different parts of the matrix to show when some criteria are more important to final decision.
The matrix is created using the same steps as the feasibility analysis (Ch2)--the only difference being that the alternative matrix combines several feasibility analyses into one matrix so that the alternatives can be easily compared.
If a company is considering implementing a packaged financial system, but does not have enough in-house experise to create a thorough alternative matrix , one helpful tool is the request for proposal (RFP), a document that solicits proposals to provide the alternative solutions from a vendor, developer, or service provider. At the minimum, the RFP should include:
(A less effort-intensive tool is the request for information (RFI).)
When the system is being designed, logical DFDs and ERDs are converted into physical process models and data models to show the implementation details and to explain how the final system will work. After the physical models are created, analysts can use a technique called the CRUD matrix to depict exactly how data is (to be) used by the processes in the system
The CRUD matrix--which stands for create read update delete--is drawn to make sure that the data stores are associated with the right processes in the correct way.
We discuss the physical DFD, physical ERD, and end with a description of the CRUD matrix in the next sections.
The physical DFD contains the same components as the logical DFD (e.g. data stores, data flows), and the same rules apply (e.g. balancing, decomposition). The basic difference is that the physical DFD contains additional details that describe how the system will be built. There are five steps to perform to make the transition to the physical DFD.
That is, we add references to ways in which the data stores, data flows and processes will be implemented. Data stores on physical DFDs will refer to files and are database tables; processes to programs or human actions; and data flow, to the physical medium for the data, such as a paper report, bar code scanning, input screens, or computer reports. By definition, external entities on the DFD are outside the scope of the system and therefore remain unchanged in the physical diagram.
Physical DFDs are different from their logical counterparts because they differentiate human and computer interactions useing a human-machine boundary, which is a line drawn on the model to seperate human action from automated processes. The project team will need to weigh the following criteria when drawing the human-machine boundary: cost, efficiency, and integrity.
That is, we add data stores, data flows, and processes that are specific to the implementation of the system and have little (or nothing) to do with the business process itself. These additions can be due to technical limitations or to the need for audits, controls, or exception handling.
The physical DFD might contain sytem-related data elements, for reasons similar to those presented in previous step. Examples of system-related data elements include last_update (when was the last change made?), and updated_by (who made the change). Another physical data element is a system-generated number used to uniquely identify each record in a database.
During step 4, the physical data elements are added to the metadata descriptions of the data flows in the CASE repository.
That is, ensure that the infomration about the DFD components in the CASE repository is updated with implemetation-specific information.
Charles E. Oyibo
IDS :: CBA
:: UIC