WCS Home Qualifications About WCS Consulting Benefits Services Engagements Links IT Resources Portland Site Map

TYPES OF SERVICES Wright Consulting Services, Inc., specializes in Development and Implementation of database information systems services for a variety of private, non-profit, and government clients. Available services in these areas, as well as Systems Analysis and Design, are listed below. Please be aware that some of these tasks may be combined or skipped for smaller organizations or for smaller systems. Systems Analysis: Reviewing and analyzing an organization's existing information systems, including both manual and computerized systems. Includes documenting how information is processed, what tasks are performed, and how information is organized. Systems Design: Designing and/or redesigning an organization's systems to more effectively meet their needs. Systems design is generally based on the results of systems analysis, and may include redesigning the organization and processing of data, developing prototypes of the new system, capacity planning, and evaluation and selection of hardware, software, and communications components. Systems Development and Implementation: Implementation of newly designed systems. May include acquisition and/or customization of selected components, development of custom software, data conversion, technical documentation, and user documentation and training. Wright Consulting Services, Inc. most often uses Oracle Developer (Forms and Reports) and PL/SQL for development. Each of these categories of services is described in more detail below. Systems Analysis The purpose of systems analysis is to gain an understanding of an organization's existing information systems. Although for most people the term "information systems" brings to mind existing computerized systems, most organizations still store much, if not most, of their information in paper form. In addition to existing automated systems, a comprehensive systems analysis project may include the review of manual filing systems as well as manual processes and procedures that use information. The scope of systems analysis may vary depending on the client's needs. It may involve a comprehensive review of all the manual and automated systems in use. In other cases it can be limited to a very particular aspect of the client's operations. For smaller organizations whose requirements are fairly straightforward, the result may be a brief outline and a handful of simple diagrams. In almost all cases, however, the preliminary results of this report are generally presented to the client for discussion and feedback before they are finalized. Systems analysis activities may include: Information Gathering: Systems analysis begins by gathering information about existing systems. This may include demonstrations of the existing manual and automated systems and processes by staff members, reviewing system and user documentation, and interviewing staff and management. Interviews may include discussions of situations in which these systems are used, how well various aspects of the systems support staff members' and management's work, and the overall events and processes that require the use of information. Physical Process Modeling: The goal of physical process modeling is to document how information is currently processed. The result is a collection of Physical Data Flow Diagrams (DFDs) documenting the processes which collect, store, manipulate, analyze, and report data. They can be used to identify all of the data used by a particular process, or conversely to determine all the processes which use a particular piece of data and track the flow of data through these processes. Logical Data Modeling: This purpose of logical data modeling is to document the data that is used by an organization. The result is a collection of Entity-Relationship Diagrams (ERDs) identifying the various entities of data (such as customers, orders, and invoices), the elements of data contained in these in these entities (customer number, name, and address; order date and amount; and so forth), and the relationships between the entities (a customer may place many orders; each order is accompanied by one or more invoices). Logical Process Modeling: Unlike physical process modeling, logical process modeling documents what processing takes place without regard to how that processing is conducted. The reason is that in many cases many tasks are performed the way they are because of the technology available at the time they were developed. By identifying the information processing needed by an organization independent of the technology currently used, the Logical Data Flow Diagrams (DFDs) produced by this task can be used to design systems that more effectively meet an organization's needs. Return to Top of Page Systems Design Often, once existing data and processes have been analyzed and documented, an organization will wish to redesign their systems to more effectively match their requirements. This may include the automation of previously manual systems, the redesign of manual systems to better integrate with automated systems, and the redesign of automated systems to better meet business requirements. Both processes and data may be redesigned. Before the final systems design is approved, it is discussed and reviewed with the client to ensure that there is a clear understanding of the changes that will take place and the client agrees with those changes. Often, several system design tasks may take place concurrently, including the following: Physical Data Modeling: Using the logical data model created under system analysis, a physical model for the data is created. Changes may be made from the logical model to fit available technology. Some entities may be put in a database and others may remain in non-electronic form. The model may be optimized, with some entities rearranged somewhat to provide for better performance when the database is implemented in the real world. In general, however, the changes made in the physical data model are generally relatively few, and the physical model often looks quite similar to the logical model. Physical Process Modeling: Physical process modeling, often a large task, involves describing how information will be processed by the new systems. In addition to physical data flow diagrams, the designer(s) will produce technical specifications and illustrations of the visual elements of the new systems, including screens and reports, as well as interfaces to external systems. Also included are descriptions of the computing equipment, networking, and underlying operating systems to be used. Rapid Prototyping: In recent years, it has become common for many organizations to use a technique known as Rapid Prototyping, Rapid Application Development (RAD), or Joint Application Development (JAD) to accomplish much of their application design. Under this method, a partially functional prototype of the new system is created in a very short time, so that users can then see exactly what the application will look like, get some kind of idea how it functions, and provide immediate feedback. Because the application is not fully functional (it is to a completed application as the false building fronts on Hollywood sets are to real buildings), the designer(s) can quickly go back to their rapid prototyping tool, make changes, and present them to the users again, sometimes the same day. This technique allows an application's users to be more comfortable with the design, and often results in an application which better meets their needs. Capacity Planning: Based upon the design of the databases as well as the processing to be implemented, a determination is made of the hardware, operating software, and communication capacity needed to effectively support the systems. Based upon the resources needed, changes may be made to the physical data and process models to fit these requirements to budgetary constraints. Evaluation and Selection: In this task, a review takes place of the hardware, operating and support software, and communications products currently on the market and how well they support the new systems. In addition, there may also be a review of available prepackaged software that may meet some of the organization's processing requirements, and the relative merits of purchasing such software versus developing it. If the decision is made to use prepackaged software, revisions may then be made to the physical data and/or process models to reflect the capabilities of the software selected. Return to Top of Page Systems Development and Implementation Once systems design has taken place, implementation can begin. Because of the large amount of effort and complexity involved, this often requires more labor and time than any of the previous tasks. Often implementation of larger systems is broken down into phases to make things more manageable. The activities involved vary a great deal from one project to the next, but may include any of the following: Acquisition and/or Customization of selected hardware, operating and support software, and communications technologies. In many cases, a great deal of customization may take place to prepackaged software after its purchase and installation. Development of custom software. Larger projects may require the effort of a number of developers for larger projects. A tremendous variety of software tools exist for systems development; Wright Consulting Services, Inc. most often uses Oracle Developer (Forms and Reports) and PL/SQL for development. Testing of acquired, customized, and/or developed software. This may take the form of unit testing by developers of individual program modules, alpha testing of systems overall by developers, beta testing of systems by end users, and/or acceptance testing after final system delivery. Data Conversion: Since most software projects involve making improvements to existing manual or automated systems, existing data often must be entered from paper sources and/or converted from electronic sources. Technical Documentation for reference by developers in maintaining and making changes to the application in the future. User Documentation for use by the systems' end users. It is usually preferable for a team of users (or a professional technical writer) to develop the user documentation themselves in their own words, with the assistance of developers. User Training in the use of the new system. For larger systems, a professional trainer or a team of application users may be trained by the developers, and they in turn train the rest of the users. Return to Top of Page WCS: Home | Qualifications | About WCS Consulting: Benefits | Services | Engagements Links: IT Resources | Portland | Site Map

Designed, created, maintained, and © Wright Consulting Services, Inc., 1996-2003. Last updated 3/23/2003.
Domain name and virtual server hosting services provided by Global Hosting Internet Services.