Implementation of New System and Maintenance

In the last lecture, we have been introducing about the types of conversion. So, to let you all easier to understand about any different or actually how those this type of conversion work, I have found some diagram. I hope through the diagram provided, you will give an benefits to you.

First I would like to discuss with you what actually each conversion mean for.

The initial operation of a new e-business system can be a difficult task. Such an operation is usually a conversion process in which the personnel, procedures, equipment, input/output media, and databases of an old information system must be converted to the requirements of a new system. Four major forms of system conversion include:

• Parallel Conversion: - Both the old and the new system are operated until the project development team and end user management agrees to switch completely over to the new system. It is during this time that the operations and results of both systems are compared and evaluated. Errors can be identified and corrected, and the operating problems can be solved before the old system is abandoned.

• Phased Conversion: - Only parts of a new application or only a few departments, branch offices, or plant locations at a time are converted. A phased conversion allows a gradual implementation process to take place within an organization.

• Pilot Conversion: - Where one department or other work site serves as a test site. A new system can be tried out at this site until developers feel it can be implemented throughout the organization.

• Plunge/Direct Cutover: - Use the system immediately and totally abandons the old system.

After the new system has been installing, next step is to maintain the system. In my opinion, maintenance system is more important than develop a new system. No matter how good is the system if without the efficiency maintenance, is doesn’t make sense. This sentence I always listen from one of lecturer in this sem. He is satisfied with the facilities provided by the university but every time he come in the class the computer sure will bring problems for him. Some time, it take around 20 minutes to fix it. From this cases, I realize that, if the university provide a poor system but a good maintenance system is better than provide an advance system but poor maintenance system. Because a new system without the maintenance will always bring trouble for the users.

So, below is several tips for maintenance system:

Once a system is fully implemented and is being used in business operations, the maintenance function begins. System maintenance is the monitoring, evaluating, and modifying of operational e-business systems to make desirable or necessary improvements. The maintenance function includes:

• A post implementation review process to ensure that newly implemented systems meet the e-business objectives established for them.

• Correcting errors in the development or use of the system. This includes a periodic review or audit of a system to ensure that it is operating properly and meeting its objectives.
  

• Making modifications to an e-business system due to changes in the business organization or the business environment.

I sincerely hope that, my university also can do this maintenance to all the facilities provided also. By this it only can show how advances we are..hehe^^

Sources retrieved from:

http://www.scribd.com/doc/396849/Developing-BusinessIT-Solutions

How well do you know Rapid Application Development (RAD)

          RAD is a software development process that allows usable systems to be built in as little as 60-90 days, often with some compromises.

To RAD or not to RAD

The Rapid Application Development methodology was developed to respond to the need to deliver systems very fast. The RAD approach is not appropriate to all projects - an air traffic control system based on RAD would not instill much confidence. Project scope, size and circumstances all determine the success of a RAD approach. The following categorize indicates suitability for a RAD approach:

PROJECT SCOPE
Suitable for RAD - Focused scope where the business objectives are well defined and narrow.
Unsuitable for RAD - Broad scope where the business objectives are obscure or broad.

PROJECT DATA
Suitable for RAD - Data for the project already exists (completely or in part). The project largely comprises analysis or reporting of the data.
Unsuitable for RAD - Complex and voluminous data must be analyzed, designed and created within the scope of the project.

PROJECT DECISIONS
Suitable for RAD - Decisions can be made by a small number of people who are available and preferably co-located.
Unsuitable for RAD - Many people must be involved in the decisions on the project, the decision makers are not available on a timely basis or they are geographically dispersed.

PROJECT TEAM
Suitable for RAD - The project team is small (preferably six people or less).
Unsuitable for RAD - The project team is large or there are multiple teams whose work needs to be coordinated.

PROJECT TECHNICAL ARCHITECTURE
Suitable for RAD - The technical architecture is defined and clear and the key technology components are in place and tested.
Unsuitable for RAD - The technical architecture is unclear and much of the technology will be used for the first time within the project.

PROJECT TECHNICAL REQUIREMENTS
Suitable for RAD - Technical requirements (response times, throughput, database sizes, etc.) are reasonable and well within the capabilities of the technology being used. In fact targeted performance should be less than 70% of the published limits of the technologies.
Unsuitable for RAD - Technical requirements are tight for the equipment to be used.

PRINCIPLES BEHIND THE DEFINITION
A. In certain situations, a usable 80% solution can be produced in 20% of the time that would have been required to produce a total solution.
B. In certain situations, the business requirements for a system can be fully satisfied even if some of its operational requirements are not satisfied.
C. In certain situations, the acceptability of a system can be assessed against the agreed minimum useful set of requirements rather than all requirements.

PROBLEMS ADDRESSED BY RAD
A. With conventional methods, there is a long delay before the customer gets to see any results.
B. With conventional methods, development can take so long that the customer's business has fundamentally changed by the time the system is ready for use.
C. With conventional methods, there is nothing until 100% of the process is finished, then 100% of the software is delivered.

WHY USE RAD?
A. BAD REASONS FOR USING RAD
1. to prevent cost overruns (RAD needs a team already disciplined in cost management)
2. to prevent runaway schedules (RAD needs a team already disciplined in time management)

B. GOOD REASONS FOR USING RAD
1. to converge early toward a design acceptable to the customer and feasible for the developers
2. to limit a project's exposure to the forces of change
3. to save development time, possibly at the expense of economy or product quality

WHEN RAD WORKS AND WHEN IT DOESN'T
A. RAD TENDS TO WORK WHEN
1. The application will be run standalone.
2. Major use can be made of preexisting class libraries (APIs).
3. Performance is not critical.
4. Product distribution will be narrow (in-house or vertical market).
5. Project scope (macro-schedule) is constrained.
6. Reliability is not critical.
7. System can be split into several independent modules.
8. The product is aimed at a highly specialized IS (information systems) market.
9. The project has strong micro-schedule constraints (timeboxes).
10. The required technology is more than a year old.

B. RAD TENDS TO FAIL WHEN ...
1. Application must interoperate with existing programs.
2. Few plug-in components are available.
3. Optimal performance is required.
4. Product development can't take advantage of high-end IS tools (e.g., 4GLs).
5. Product distribution will be wide (horizontal or mass market).
6. RAD becomes QADAD (Quick And Dirty Application Development).
7. RAD methods are used to build operating systems (reliability target too high for RAD), computer games (performance target too high for RAD).
8. Technical risks are high due to use of "bleeding" edge technology.
9. The product is mission- or life-critical.
10. The system cannot be modularized (defeats parallelism).

EVALUATION OF RAD
A. ADVANTAGES OF RAD
1. Buying may save money compared to building
2. Deliverables sometimes easier to port (because they make greater use of high-level abstractions, scripts, intermediate code)
3. Development conducted at a higher level of abstraction (because RAD tools operate at that level)
4. Early visibility (because of prototyping)
5. Greater flexibility (because developers can redesign almost at will)
6. Greatly reduced manual coding (because of wizards, code generators, code reuse)
7. Increased user involvement (because they are represented on the team at all times)
8. Possibly fewer defects (because CASE tools may generate much of the code)
9. Possibly reduced cost (because time is money, also because of reuse)
10. Shorter development cycles (because development tilts toward schedule and away from economy and quality)
11. Standardized look and feel (because APIs and other reusable components give a consistent appearance)

B. DISADVANTAGES
1. Buying may not save money compared to building
2. Cost of integrated toolset and hardware to run it
3. Harder to gauge progress (because there are no classic milestones)
4. Less efficient (because code isn't hand crafted)
5. Loss of scientific precision (because no formal methods are used)
6. May accidentally empower a return to the uncontrolled practices of the early days of software development
7. More defects (because of the "code-like-hell" syndrome)
8. Prototype may not scale up, a B-I-G problem
9. Reduced features (because of timeboxing, software reuse)
10. Reliance on third-party components may ...
a. sacrifice needed functionality
b. add unneeded functionality
c. create legal problems
11. Requirements may not converge (because the interests of customers and developers may diverge from one iteration to the next)
12. Standardized look and feel (undistinguished, lackluster appearance)
13. Successful efforts difficult to repeat (no two projects evolve the same way)
14. Unwanted features (through reuse of existing components)

Reference:
http://www.gantthead.com/content/processes/11306.cfm
http://csweb.cs.bgsu.edu/maner/domains/RAD.htm#4
http://software-document.blogspot.com/2010/11/rapid-application-development-quick.html

Debugging

Identify the Bug

     Debugging means removing bugs from programs. A bug is unexpected and undesirable behavior by a program.
     Occasionally there is a formal specification that the program is required to follow, in which case a bug is a failure to follow the spec. More frequently the program specification is informal, in which case people may disagree as to whether a particular program behavior is in fact a bug or not.
     As one of the people writing a program, you should be a source of bug reports. Don't simply rely on testers or users. If you notice something odd while running a program, it can be tempting to disregard it and hope that it will go away. This is especially true if you are working on something else at the time. Resist the temptation. Record the bug. If you have data files or logs, save them. If you have time later, return to the issue; otherwise, pass it on to somebody else. As one of the people most familiar with how the program is supposed to work, you are in the best possible position for detecting unexpected behavior.
     Once you have a bug report, the first step in removing the bug is identifying it. This is of particular importance when working with a bug report produced by somebody else, such as the testing team or a user. Some bugs are relatively obvious, as when the program crashes unexpectedly. Others are obscure, as when the program generates output which is slightly incorrect.
Many bug reports received from users are of the form "I did such and such, and something went wrong." Before doing anything else, you must find out what went wrong--that is, you must identify the bug by determining the program behavior which was unexpected and undesirable. Any attempt to fix the bug before understanding what went wrong is generally wasted time.
     Identifying a bug reported by a user typically requires getting the answer to two questions: "What did the program do?" and "What did you expect the program to do?" The goal is to determine precisely the behavior of the program which was unexpected and undesirable.
     Once the bug has been identified, the easiest and fastest way to fix it is to determine that it is not a bug at all. If there is a formal specification for the program, you may have to modify the specification. In other cases, you may have to modify the expectations of the user. This rapid fix is often known as declaring the behavior to be an "undocumented feature." Despite the obvious potential for abuse, this is in fact sometimes the correct way to handle the problem.
     Unfortunately, most bugs are real bugs, and require further work.

Replicate the Bug
     The first step in fixing a bug is to replicate it. This means to recreate the undesirable behavior under controlled conditions. The goal is to find a precisely specified set of steps which demonstrate the bug.
In many cases this is straightforward. You run the program on a particular input, or you press a particular button on a particular dialog, and the bug occurs. In other cases, replication can be very difficult. It may require a lengthy series of steps, or, in an interactive program such as a game, it may require precise timing. In the worst cases, replication may be nearly impossible.

Understand the Bug
     Once you are able to replicate the bug, you must figure out what causes it. This is generally the most time-consuming step.

Understand the program
     In order to understand a bug in a program, you must have some understanding of the program.
If you wrote the program, then you presumably understand it. If not, then you have more serious problems.
If you didn't write the program, you need to grasp its general structure. Most programs are organized in a fairly sensible fashion, once you know the general approach. If you are lucky, the general approach is documented, or you can ask the original designer.
     More commonly, you need to pull the structure out of the source code. The best approach is to start looking at the source code from the start of the program (e.g., the main function in a C program). Skim through the program, stepping down through functions, until you find the main center of action--in most programs, some sort of loop. This can normally be done fairly quickly. The nature of this center of action should tell you where to look in the source code for any particular activity. It should also tell you the general way in which the program acts.
     The worst cases are large programs written over many years by many different people. These often become a hodge-podge of different ideas with little consistency. The situation is depressingly common. You must simply do the best you can. At least try to avoid making the mess worse.
     A debugger can also be helpful when trying to understand a program. By running the program under the debugger and setting breakpoints, you may be able to see the dynamic behavior of the program. When you reach a breakpoint, look at the call stack to see how you got there, and look at key variables. Or if you don't reach a breakpoint you expected to reach, you've also learned something.

Locate the bug
The next step is to locate the bug in the program source code.
     There are two source code locations which you need to consider: the code which causes the visible incorrect behavior, and the code which is actually incorrect. It's fairly common for these to be the same pieces of code. However, it's also fairly common for these to be in different parts of the program. A typical example of this is when an error in one part of the program causes memory corruption which leads to visible bad behavior in a completely different part of the program. Do not let your eagerness to fix the bug mislead you into thinking that the code which directly causes the bad behavior is actually incorrect.
     Ordinarily you must first find the code which causes the incorrect behavior. Knowing the incorrect behavior, and knowing how the source code is arranged, will often lead you quickly to the part of the program which is at fault. Sometimes a quick scan of the source code is enough to identify the problematic code.
     Otherwise, narrowing down the bad behavior to a particular piece of code is where a debugger can be very useful. If you are lucky enough to have a core dump, a debugger can immediately identify the line which fails. Otherwise, judiciously setting breakpoints while replicating the bug can quickly hone in on the code you are after.
     Another useful approach is to add check routines to the code to verify that data structures are in a valid state. Such routines can help narrow down where data corruption occurs. If the check routines are fast, you may want to always enable them. Otherwise, leave them in the code, and provide some sort of mechanism to turn them on when you need them.
     In the specific case of a memory corruption bug, you may be able to replace the standard memory allocation routines with ones that perform various checks. For example, on GNU/Linux systems, read the malloc documentation to see how the environment variable MALLOC_CHECK_ can be used to do this.
     The final fallback for locating the source of the bad behavior is simple source code inspection. This is the only option if you can't replicate the problem. A clear understanding of the overall program source code is an absolute requirement for this to work. Unfortunately, a complex problem is nearly impossible to isolate by simply reading the source code. You will have to guess at likely possibilities, and try to trace through the code carefully to see if they are really problems.
     If you are very unlucky, the bug may not be in the program source code at all. It may be in a library routine, or in the operating system, or in the compiler. These cases are rare, and it is a mark of an inexperienced programmer to suspect a compiler bug too quickly. However, they do happen, so when all else fails, consider these possibilities. Verify a bug in a library routine or the OS by writing a check program, and verify a bug in the compiler by examining the machine code directly.

Locate the error
     Now that you have found the code which causes the bad behavior, you need to identify the actual coding error. Often they are the same code--that is, the coding error directly causes the bad behavior. However, you should always consider the possibility that the actual error is elsewhere.
     For example, the routine which causes the bad behavior may be behaving correctly, but be called with bad input, or at the wrong time. A coding error elsewhere may cause a data structure to hold unreasonable values. Another possibility is bad user input.
     The fix in such cases may be two-fold. You should, of course, fix the code which called the routine incorrectly or otherwise created the bad input data. In the case of bad user input, you should validate the input. In addition, however, you may want to add checks to the code which used the values. It should check for unreasonable input, and report an error or otherwise handle the error without causing invalid behavior.

Fix the bug
     The final step in the debugging process is, of course, to fix the bug. I won't discuss this step in detail, as fixing a bug is where you leave the debugging phase and return to programming. I'll just mention a couple of points.
     If you want a program which can be maintained in the future, then make sure you fix the bug in the right way. This means making a fix which fits in with the rest of the program, and which fixes all aspects of the problem, without introducing any new problems. Don't forget to update any relevant documentation.
     In some cases you may need a quick patch to fix an immediate problem. There is nothing wrong with doing that, as long as you take the time afterward to go back and make the right fix.
     Obviously, always test any fix you make by ensuring that you can no longer replicate the bad behavior. Don't forget to make sure that the program continues to pass its test suites. Consider extending the test suites to detect the case which you just fixed, to make sure it doesn't reappear.

Reference:
http://www.airs.com/ian/essays/debug/debug.html
http://www.leonmeijer.nl/archive/2007/06/05/45.aspx