幻想-东邪黄药师: VISUAL BASIC

A system is an organized set of related components established to accomplish a certain task. There are natural systems, such as the cardiovascular system, but many systems have been planned and deliberately put into place by people. For example, a fast-food franchise has a system for serving a customer, including taking an order, assembling the food, and collecting the amount due. A computer system is a system that has a computer as one of its components.

Systems analysis is the process of studying an existing system to determine how it works and how it meets user needs. Systems analysis lays the groundwork for improvements to the system. The analysis involves an investigation, which in turn usually involves establishing a relationship with the client for whom the analysis is being done and with the users of the system. The client is the person or organization contracting to have the work done. The users are people who will have contact with the system, usually employees and customers. For instance, in a fast-food system, the client is probably the franchise owner or manager, and the users are both the franchise employees and the customers.

Systems design is the process of developing a plan for an improved system, based on the results of the systems analysis. For instance, an analysis of a fast-food franchise may reveal that customers stand in unacceptably long lines waiting to order. A new system design might involve plans to have employees press buttons that match ordered items, causing a display on an overhead screen that can be seen by other employees who can quickly assemble the order.

The systems analyst normally performs both analysis and design. (The term systems designer is used in some places.) In some computer installations a person who is mostly a programmer may also do some systems analysis and thus have the title programmer/analyst. Traditionally, most people who have become systems analysts started out as programmers.

A systems analysis and design project does not spring out of thin air. There must be an impetus—motivation—for change and related authority for the change. The impetus for change may be the result of an internal force, such as the organization's management deciding that a computer could be useful in warehousing and inventory, or an external force, such as government reporting requirements or customer complaints about. Authority for the change, of course, comes from higher management.
The systems analyst fills the role of change agents the catalyst or persuader who overcomes the natural reluctance to change within an organization. The key to success is to involve the people of the client organization in the development of the new system. The common industry phrase is user involvement, and nothing could be more important to the success of the system. Some analysts like to think in terms of who "owns" the system. If efforts toward user involvement are successful, the user begins to think of the system as my system, rather than their system. Once that happens, the analyst's job becomes much easier.
Before one can understand what kind of person might make a good systems analyst, it is necessary to look at the kinds of things an analyst does. The systems analyst has three principal functions:

Coordination. An analyst must coordinate schedules and system-related tasks with a number of people: the analyst's own manager; the programmers working with the system; the system's users, from clerks to top management; the vendors selling the computer equipment; and a host of others, such as mail-room employees handling mailings and carpenters doing installation.

Communication, both oral and written. The analyst may be called upon to make oral presentations to clients, users, and others involved with the system. The analyst provides written reports—documentation—on the results of the analysis and the goals and means of the design. These documents may range from a few pages long to a few inches thick.

Planning and design. The systems analyst, with the participation of members of the client organization, plans and designs the new system. This function involves all the activities from the beginning of the project until the final implementation of the system.

In light of these principal functions, the kinds of personal qualities that are desirable in a systems analyst become apparent: an analytical mind and good communication skills. Perhaps not so obvious, however, are qualities such as self-discipline and self-direction, since a systems analyst often works without close supervision. An analyst must have good organizational skills to be able to keep track of all the facts about the system. An analyst also needs creativity to envision the new system. Finally, an analyst needs the ability to work without tangible results. There can be long dry spells when the analyst moves numbly from meeting to meeting and it can seem that little is being accomplished. System Development Life Cycle or SDLC is a methodology developed to ensure that systems are developed in a methodical, logical and step by step approach. SDLC was developed because many system projects were developed that did not satisfy user requirements and the projects that did satisfy user requirements were being developed over budget or over time. People need blueprints or maps. Having a blueprint of some kind makes program becomes easier. Base on this blueprint we can develop many programs with a little alteration.In class, the professor gives out a well-defined requirements statement, but in the real world, programmers need to develop these themselves. The requirement statement forms the basis of application that the system analyst developed throughout the rest of their project.
Whether you are investigating how to improve a bank's customer relations, how to track inventory for a jeans warehouse, how to manage egg production on a chicken ranch, or any other task, you will proceed by using the systems development life cycle (SDLC). The systems development life cycle can be described in six phases:

Preliminary investigation—determining the problem

Analysis—understanding the existing system

Design—planning the new system

Development—doing the work to bring the new system into being

Implementation—converting to the new system

Audit and Maintenance

PHASE 1 - Preliminary investigation

PHASE 2 - Detailed analysis of the project

PHASE 3 - Design a program

PHASE 4 - Development

PHASE 5 - Implementation

PHASE 6 - Audit and Maintenance

PHASE 1

Preliminary investigation is to verify a problem or deficiencies really exist or to pass judgment on the new requirement. Typically three things are to be considered before we can start a program:
i. Technical

The project cannot be completed with the current technology currently in existence. 100 years ago building a helicopter is an impossible mission. Technology constraints made it impossible to build something that is not achievable in those days.

ii. Time

　　 The project can be completed but not in time to satisfy the user's requirement. This is a frequent reason for the abandonment of the project after preliminary investigation.

iii. Budgetary

It is not possible to finish the project due to budget limitation even though the technology at that time allows it to happen and it can be finished on time.
The preliminary investigation, often called the feasibility study or system survey, is the initial investigation, a brief study of the problem to determine whether the systems project should be pursued. You, as the systems analyst, need to determine what the problem is and what to do about it. The net result will be a rough plan for how—and whether—to proceed with the project.
Before you can decide whether to proceed, you must be able to describe the problem. To do this, you will work with the users. One of your tools will be an organization chart, which is a hierarchical drawing showing the organization's management by name and title. Many organizations already have such a chart and can give you a copy. If the chart does not exist, you must ask some questions and then make it yourself. Constructing such a chart is not an idle task. If you are to work effectively within the organization, you need to understand the lines of authority through the formal communication channels.
Your initial aim is to define the problem. You and the users must come to an agreement on these points: You must agree on the nature of the problem and then designate a limited scope. In the process you will also determine what the objectives of the project are.

Nature of the Problem -Begin by determining the true nature of the problem. Sometimes what appears to be the problem turns out to be, on a closer look, only a symptom. For example, suppose that you are examining customer complaints of late deliveries. Your brief study may reveal that the problem is not in the shipping department, as you first thought, but in the original ordering process.

Scope- Establishing the scope of the problem is critical because problems tend to expand if no firm boundaries are established. Limitations are also necessary to stay within the eventual budget and schedule. So in the beginning the analyst and user must agree on the scope of the project: what the new or revised system is supposed to do—and not do.

Objectives- You will soon come to understand what the user needs—that is, what the user thinks the system should be able to do. You will want to express these needs as objectives. Examine the objectives for the Swift inventory process. The people who run the existing inventory system already know what such a system must do. It remains for you and them to work out how this can be achieved on a computer system. In the next phase, the systems analysis phase, you will produce a more specific list of system requirements based on these objectives.
The preliminary investigation, which is necessarily brief, should result in some sort of report, perhaps only a few pages long, telling management what you have found and listing your recommendations. Furthermore, money is always a factor in go/no-go decisions: Is the project financially feasible? At this point management has three choices: They can (1) drop the matter; (2) fix the problem immediately if it is simple; or (3) authorize you to go on to the next phase for a closer look.

PHASE 2

Let us suppose that management has decided to continue. Remember that the purpose of systems analysis is to understand the existing system. A related goal is to establish the system requirements. The best way to understand a system is to gather all the data you can about it; this data must then be organized and analyzed. During the systems analysis phase you will be concerned with (1) data gathering and (2) data analysis. Keep in mind that the system being analyzed may or may not already be a computerized system.
Phase 2 is detailed analysis of the project also called as Data Gathering Phase. We study the problem, deficiency or new requirement in detail. Depend on the size of the project; it could take few days or even months. You cannot get much information if you spend a little time with the user. You need to gather as much information as you can about the project from the owner.
Data Gathering- Data gathering is expensive and requires a lot of legwork and time. There is no standard procedure for gathering data because each system is unique. But there are certain sources that are commonly used: written documents, interviews, questionnaires, observation, and sampling. Sometimes you will use all of these sources, but in most cases it will be appropriate to use some and not others.
Written Documents- These include procedures manuals, reports, forms, and any other kind of material bearing on the problem that you find in the organization. Take time to get a copy of each form an organization uses.
Interviews- A key advantage of interviews is their flexibility; as the interviewer, you can change the direction of your questions if you discover a productive area of investigation. Another bonus is that you can probe with open-ended questions that people would balk at answering on paper. You can also observe the respondent's voice inflection and body motions, which may tell you more than words alone. Finally, of course, there is the bonus of getting to know clients better and establishing a rapport with them, an important factor in promoting user involvement in the system from the beginning. Interviews have certain drawbacks: They are time-consuming and therefore expensive. If you need to find out about procedures from 40 mail clerks, you are better off using a questionnaire.
There are two types of interviews, structured and unstructured. A structured interview includes only questions that have been planned and written out in advance. A structured interview is useful when it is desirable—or required by law—to ask identical questions of several people. However, the unstructured interview is often more productive, since the interviewer may stray from the line of questioning.
Questionnaires- Unlike interviews, questionnaires can be used to get information from large groups. Also, because of the large number of respondents, sometimes a trend or problem pattern emerges that would not be evident from a small number of interviews. Questionnaires allow people to respond anonymously and, presumably, more truthfully. Questionnaires do have disadvantages, however, including the problem of getting them returned and the possibility of biased answers.
Observation- As an analyst and observer, you go into the organization and watch who interrelates with whom. In particular, you observe how data flows: from desk to desk, fax to fax, or computer to computer. Note how data comes into and leaves the organization. Initially, you make arrangements with a group supervisor and make everyone aware of the purpose of your visit. Be sure to return on more than one occasion so that the people under observation become used to your presence. One form of observation is participant observation; in this form the analyst temporarily joins the activities of the group.
Sampling- You may need to collect data about quantities, costs, period of time, and other factors relevant to the system. For example, how many phone orders can be taken by an order entry clerk in an hour? If you are dealing with a major mail-order organization, this type of question may be best answered through a procedure called sampling: Instead of observing all 125 clerks filling orders for an hour, you pick a sample of 3 or 4 clerks. Or, in a case involving a high volume of paper output, such as customer bills, you could collect a random sample of a few dozen bills. Although actual sampling methods are beyond the scope of this book, it should be mentioned that there are statistical techniques that can determine exactly what sample size will yield accurate results.
Data Analysis- Your data-gathering processes will probably produce an alarming amount of paper and a strong need to get organized. It is now time to turn your attention to the second activity of this phase, data analysis. A variety of tools—charts and diagrams—are used to analyze data, not all of them appropriate for every system. You should become familiar with the techniques favored by your organization and then use the tools that suit you at the time. Two typical tools are data flow diagrams and decision tables. Data analysis shows how the current system works and helps determine the system requirements. In addition, data analysis materials will serve as the basis for documentation of the system.
Data Flow Diagrams- A data flow diagram (DFD) is a sort of road map that graphically shows the flow of data through a system. It is a valuable tool for depicting present procedures and data flow. Although data flow diagrams can be used in the design process, they are particularly useful for facilitating communication between you and the users during the analysis phase. Suppose, for example, you spend a couple of hours with a McDonald's franchise manager, talking about the paperwork that keeps the burgers and the customers flowing. You would probably make copious notes about what goes on where. But that is only the data gathering function; now you must somehow analyze your findings. You could come back on another day with pages of narrative for the manager to review or, instead, with an easy-to-follow picture. Most users would prefer the picture. There are a variety of notations for data flow diagrams. The notation used here has been chosen because it is informal and easy to draw and read. The elements of a data flow diagram are processes, files, sources and sinks, and vectors.
Decision Tables- A decision table, also called a decision logic table, is a standard table of the logical decisions that must be made regarding potential conditions in a given system. Decision tables are useful in cases that involve a series of interrelated decisions; their use helps to ensure that no alternatives are overlooked. Programmers can code portions of a program right from a decision table.
System Requirements- As noted earlier, the purpose of gathering and analyzing data is twofold: to understand the system and, as a by-product of that understanding, to establish the system requirements, a detailed list of the things the system must be able to do. You need to determine and document specific user needs. A system that a bank teller uses, for example, needs to be able to retrieve a customer record and display it on a screen within five seconds. The importance of accurate requirements cannot be overemphasized, because the design of the new system will be based on the system requirements. Furthermore, the analyst and management must come to clear agreement on the system requirements, since a misunderstanding can result in a poor evaluation of the new system and even cause a delay in project completion.
Report To Management- When you have finished the systems analysis phase, you present a report to management. This report summarizes the problems you found in the current system, describes the requirements for the new system, includes a cost analysis, and makes recommendations on what course to take next. If the project is significant, you may also make a formal presentation, including visual displays. If management decides to pursue the project, you move on to phase 3.

PHASE 3

The systems design phase is the phase in which you actually plan the new system. This phase is divided into two sub-phases: preliminary design, in which the analyst establishes the new system concept, followed by detail design, in which the analyst determines exact design specifications. The reason this phase is divided into two parts is that an analyst wants to make sure management approves the overall plan before spending time and money on the details of the new system.The design in the SDLC encompasses many different elements. Input → File → Processing → Output. Jumping immediately into coding is a huge mistake. Never start building a house without a blueprint. The biggest mistake that any programmer would do is spending too little time on the design phase and more eager to start doing programming. It can take months to complete a house and making a mistake in building the house could be devastating. While writing a Visual Basic program can take hours if not minutes.
The first task of preliminary design is to review the system requirements and then consider some of the major aspects of a system. Should the system be centralized or distributed? Should the system be online? Can the system be run on the users' personal computers? How will input data be captured? What kind of reports will be needed? The questions can go on and on.
A key question that should be answered early on is whether packaged software should be purchased, as opposed to having programmers write custom software. That is, instead of designing, developing, and implementing a new system from scratch, you may be able to obtain an existing system—acquisition by purchase—that meets your client's requirements. This may be tricky because clients often think that their problems are unique. However, if the new system falls into one of several major categories, such as accounting or inventory control, you will find that many software vendors offer packaged solutions. A packaged solution should meet at least 75 percent of client requirements. For the remaining 25 percent, the client can adjust ways of doing business to match the package software or, more expensively, the packaged software can be customized, or altered, to meet the client's special needs.
Another possibility is outsourcing, which means turning the system over to an outside agency to develop. Large organizations that employ their own computer professionals may outsource certain projects, especially if the subject matter is one in which a reputable outsourcing firm specializes. The outsourcing company then turns the completed system over to the client. Some organizations outsource most or all of their computer projects, preferring to avoid bearing the costs of keeping their own staff.
If you proceed with an in-house design, then, together with key personel from the client organization, you determine an overall plan. In fact, it is common to offer alternative plans, called candidates. Each candidate meets the client's requirements but with variations in features and costs. The chosen candidate is usually the one that best meets the client's current needs and is flexible enough to meet future needs.
At this stage it is wise to make a formal presentation of the selected plan, or possibly of all the alternatives. The point is that you do not want to commit time and energy to—nor does the client want to pay for—a detailed design until you and the client agree on the basic design.
Building a prototype—a sort of guinea-pig model of the system—has become a standard approach in many organizations. Considered from a systems viewpoint, a prototype is a limited working system, or a subset of a system, that is developed quickly, sometimes in just a few days. Some organizations use prototyping very loosely, so that it has no true functionality but can produce output that looks like output of the finished system, enabling users to see and evaluate it. The idea is that users can get an idea of what the system might be like before it is fully developed. Many organizations develop a prototype as a working model, one that can be tinkered with and fine-tuned. No one expects users to be completely satisfied with a prototype, so requirements can be revised before a lot has been invested in developing the new system.

Could you adopt this approach to systems development? It seems at odds with this systems development life cycle, which promotes doing steps in the proper order. And yet many analysts in the computer industry are making good use of prototypes. The prototype approach exploits advances in computer technology and uses powerful, high-level software tools. These software packages allow analysts to build systems quickly in response to user needs. The systems produced can then be refined as they are used until the fit between user and system is acceptable.
Detail Design- Let us say that the users have accepted your design proposal and you are on your way. You must now develop detailed design specifications, or a detail design. This is a time-consuming part of the project, but it is relatively straightforward.

In this phase every facet of the system is considered in detail. Here is a list of some detail design activities: designing output forms and screens, plan input data forms and procedures, drawing system flowcharts, planning file access methods and record formats, planning database interfaces, planning data communications interfaces, designing system security controls, and considering human factors. This list is not comprehensive, nor will all activities listed be used for all systems. Some analysts choose to plan the overall logic at this stage, preparing program structure charts, pseudo-code, and the like.

Normally, in the detail design phase, parts of the system are considered in this order: output requirements, input requirements, files and databases, systems processing, and systems controls and backup.
Output Requirements- Before you can do anything, you must know exactly what the client wants the system to produce—the output. As an analyst, you must also consider the medium of the output—paper, computer screen, and so on. In addition, you must determine the type of reports needed (summary, exception, and so on) and the contents of the output—what data is needed for the reports. The forms that the output will be printed on are also a consideration; they may need to be custom-printed if they go outside the organization to customers or stockholders.
Input Requirements- Once your desired output is determined, you must consider what kind of input is required to produce it. First you must consider the input medium: Will you try to capture data at the source via pointof-sale (POS) terminals? Must the input be keyed from a source document?

Next you must consider content again—what fields are needed, the order in which they appear, and the like. This in turn may involve designing forms that will organize data before it is entered. You need to plan some kind of input validation process, a check that data is reasonable as well as accurate; you would not expect a six-figure salary, for example, for someone who works in the mail room. Finally, you need to consider input volume, particularly the volume at peak periods. Can the system handle it? A mail-order house, for instance, may have to be ready for higher sales of expensive toys during the December holiday season than at other times of the year.
Files and Databases- You need to consider how the files in your computer system will be organized: sequentially, directly, or by some other method. You also need to decide how the files should be accessed, as well as the format of records making up the data files. If the system has one or more databases or accesses databases used in other systems, you will have to coordinate your design efforts with the database administrator, the person responsible for controlling and updating databases.
Systems Processing- Just as you drew a data flow diagram to describe the old system, now you need to show the flow of data in the new system. One method is to use standard ANSI flowchart symbols to illustrate what will be done and what files will be used. A systems flowchart is not the same as the logic flowchart used in programming. The systems flowchart describes only the big picture; a logic flowchart represents the flow of logic within a single program.
Systems Controls and Backup- To make sure that data is input and process correctly, and to prevent fraud and tampering with the computer system, you will need to institute appropriate controls. In a batch system, in which data for the system is processed in groups, begin with the source documents, such as time cards or sales orders. Each document should be serially numbered so that the system can keep track of it. Documents are time stamped when received and then grouped in hatches. Each hatch is labeled with the number of documents per batch; these counts are balanced against totals of the processed data. The input is controlled to make sure that the data is accurately converted from source documents to machine process able form. Data input to online systems is backed up by system journals, files that record every transaction processed at each terminal, such as an account withdrawal through a hank teller. Processing controls include the data validation procedures mentioned in the section on input requirements.

It is also important to plan for the backup of system files; copies of transaction and master files should be made on a regular basis. These file copies should then be stored temporarily in case the originals are inadvertently lost or damaged. Often the backup copies are stored off site for added security.

As before, the results of this phase are documented. The resulting report, usually referred to as the detail design specifications, is an outgrowth of the preliminary design document. The report is probably large and detailed. A presentation often accompanies the completion of this stage.

PHASE 4

Finally, the system is actually going to be developed. As a systems analyst you prepare a schedule to monitor the principal activities in systems development—programming and testing.

During the Development phase, computer hardware is purchased and the software is developed. In another words coding process starts.During the Development phase, we’d constantly examine and reexamine the requirement statements to ensure that we were following the customer needs.
Developers use the Development stage to demo the application to the customer as another check that the final software solution answers the problem posed. When they are given the okay sign from the customer, the final version code is written into this shell to complete the phase.
Scheduling- A Gantt chart is a bar chart commonly used to depict schedule deadlines and milestones. The chart might shows the work to be accomplished over a given period. It does not, however, show the number of work hours required. If you were the supervisor, it would be common practice for you to ask others on the development team to produce individual Gantt charts of their own activities. Organizations that want further control may use project management software, which offers additional features, such as allocating people and resources to each task, monitoring schedules, and producing status reports.
Programming- Until this point there has been no programming, unless, that is, some prototyping was done. So usually, before programming begins, you need to prepare program design specifications. Program development tools must be considered. Some of this work may already have been done as part of the design phase, but usually programmers participate in refining the design at this point. Program design specifications can be developed through detailed logic flowcharts and pseudo-code, among other tools.
Testing- Would you write a program and then simply turn it over to the client without checking it over first? Of course not. Thus programmers perform unit testing, meaning that they individually test their own program pieces (units), using test data. Programmers even try bad data so that they can be confident that their program can handle it appropriately. This is followed by system testing, which determines whether all the program units work together satisfactorily. During this process the development team uses test data to test every part of the programs. Finally, volume testing uses real data in large amounts. Volume testing sometimes reveals errors that do not show up with test data, especially errors in storage or memory usage. In particular, volume testing of online systems will reveal problems that are likely to occur only under heavy use.As in every phase of the project, documentation is required. In this phase documentation describes the program logic and detailed data formats.

PHASE 5

After the Development phase of the SDLC is complete, we begin to implement the system.
Even though implementation is the final phase, a good deal of effort is still required, including the following activities: training, equipment conversion, file conversion, system conversion, auditing, evaluation, and maintenance.
Software which we designed in Phase 3 and programmed in Phase 4, will be installed in the computer.
During Implementation phase, both hardware and software are tested. The hardware usually will be prepared with the hardware. However the software testing will be done by the developer who involved with the project.
When the software was installed on the PC, the program should be bug free. The user will uncover problems developer has been unable to generate. These types of problem will be handled in more detail in the section on error handling.
Training- Often systems analysts do not give training the attention it deserves, because they are so concerned about the computer system itself. But a system can be no better than the people using it. A good time to start training—for at least a few of the users—is at some point during the testing, so that people can begin to learn how to use the system even as the development team is checking it out. Do not be concerned that these users will see a not-yet-perfect system; users actually gain confidence in a budding system as errors get fixed and the system improves every day. .
An important training tool is the user's manual, a document prepared to aid users not familiar with the computer system. Some organizations employ technical writers to create the user's manual while the system is being developed. But documentation for the user is just the beginning. Any teacher knows that students learn best by doing. Besides, users are as likely to read a thick manual as they are to read a dictionary. The message is clear: Users must receive hands-on training to learn to use the system. The trainer must prepare exercises that simulate the tasks users will be required to do. For example, a hotel clerk learning a new online reservation system is given typical requests to fulfill—a family of four for three nights—and uses a terminal to practice. The user's manual is used as a reference guide. Setting all this up is not a trivial task. The trainer must consider class space, equipment, data, and the users' schedules.
Equipment Conversion- Equipment conversion can vary from almost none to installing a mainframe computer and all its peripheral equipment. If you are implementing a small-or medium-size system on established equipment in a major information systems department, your equipment considerations may simply involve negotiating scheduled run time and disk space. If you are purchasing a moderate amount of equipment, such as terminals or personal computers, you will be concerned primarily with delivery schedules, networking, and compatibility.

A major equipment purchase demands a large amount of time and attention. The planning for such a purchase, of course, must begin long before the implementation phase. For a major equipment purchase you will need site preparation advice from vendors and other equipment experts.

Personal computer systems are less demanding, but they too require site planning in terms of the availability of space, accessibility, and cleanliness. And, as the analyst, you may be the one who does the actual installation.
File Conversion- File conversion may be very tricky if the existing files are being handled in a manual manner. The data must be prepared in such a way that it is accessible to computer systems. All of the contents of the file drawers in the personnel department, for instance, must be keyed, or possibly scanned, to be stored on disk. Some scheme must be used to input the data files and keep them updated. You may need to employ temporary help. The big headache during this process is keeping all file records up to date when some are still processed manually and some have been keyed in preparation for the new system.

If you are modifying an existing computer system and thus have files already in computer-accessible form, you may need to have a program written to convert the old files to the format needed for the new system. This is a much speedier process than having to key in data from scratch. Nevertheless, it is not unusual for file conversion to take a long time.
System Conversion- During the system conversion stage, you actually "pull the plug" on the old system and begin using the new one. There are four ways of handling the conversion.

Direct conversion means that the user simply stops using the old system and starts using the new one—a somewhat risky method, since there is no other system to fall back on if anything goes wrong. This procedure is best followed only if the old system is very small or in unusable condition. A phased conversion is one in which the organization eases into^. the new system one step at a time so that all the users are working with some of the system. In contrast, in a pilot conversion the entire system is used by a designated set of users and is extended to all users once it has proved successful. This works best when a company has several branch offices or separate divisions. In a parallel conversion, the most prolonged and expensive method, the old and new systems are operated simultaneously for some time, until users are satisfied that the new system performs to their standards.

System conversion is often a time of stress and confusion for all concerned. As the analyst, your credibility is on the line. During this time users are often doing double duty, trying to perform their regular jobs and simultaneously cope with a new computer system. Problems seem to appear in all areas, from input to output. Clearly, this is a period when your patience is needed.

PHASE 6

Auditing- Security violations, whether deliberate or unintentional, can be difficult to detect. Data begins from some source, perhaps a written source document or a transaction, for which there must be a record log. Eventually, the data is part of the system on some medium, probably disk. Once the data is on disk, it is possible for an unauthorized person to alter it in some illicit way. How would anyone know that the disk files had been changed and, in fact, no longer match the original source documents from which the data came? To guard against this situation, the systems analyst designs an audit trail to trace output back to the source data. In real-time systems, security violations can be particularly elusive unless all transactions are recorded on disk for later reference by auditors. Modern auditors no longer shuffle mountains of paper; instead, they have computer programs of their own to monitor applications programs and data.Change takes place in order to meet the satisfaction of the customer, governmental regulations and alteration in the business rules of the customer.
Evaluation- Is the system working? How well is it meeting the original requirements, benefits, and budgets? Out of such evaluation will come adjustments that will improve the system. Approaches to evaluation vary. Sometimes the systems analyst and someone from the client organization evaluate the system against preset criteria directly related to the requirements that were determined during the systems analysis phase. Some organizations prefer to bring in an independent evaluating team, on the assumption that independent members will be free from bias and expectations.The client or a third party such as an auditor studies the implemented system to ensure it actually fulfils the requirement statement. Next the maintenance portion of this phase deals with any changes that need to make to this system.
Maintenance- Many consider maintenance to be a separate phase, one that begins only when the initial system effort is implemented and complete. In any case maintenance is an ongoing activity, one that lasts the lifetime of the system. Monitoring must take place and necessary adjustments must be made if the computer is to continue to produce the expected results. Maintenance tasks also include making revisions and additions to the computer system.

The maintenance task poses interesting problems for programmers. New programmers, fresh from school, may have written only new programs to submit for academic credit. Others have also written programs for their own purposes. But on the first job they are likely to discover that their task is to make changes to programs written by others: maintenance. Some programmers like maintenance; in fact, sometimes a key programmer on development stays on the project to do maintenance, for both familiarity and job security reasons. Programmers who do not like maintenance must extricate themselves from each project as it nears completion and find a way to get on the next new project. The systems analyst, by the way, has long since left.

The preceding discussion may leave the impression that, by simply following a formula, one can develop a system. In fact, novice analysts often believe this to be true. Each system is unique, however, so no one formula can fit every project. It would be more correct to say that there are merely guidelines.
Windows Registry is a database that the Windows operating system uses to store and track information necessary for the operation of your computer. Types of information that we can record in the Registry includes small pieces of information that must be maintained from one session of the program to another. Some programs such as Visual Basic use the Registry to record windows, their size locations are open when the program is exited.