IT Evolution

Alternatives of Systems Life Cycle

2011-04-14T11:39:00.003+08:00

There are two different alternatives to the system life cycle learned during our last lecture: prototyping and RAD (rapid applications development).

However, after searching information in the internet, I found there is not only prototyping and RAD but also consists of Build-and-fix, Extreme programming, Spiral and also Iterative.

Build-and-Fix Model

The build-and-fix model was adopted from an earlier and simpler age of hardware product development. Those of us who bought early Volkswagen automobiles in the 1950s and ’60s remember it well. As new models were brought out and old models updated, the cars were sold apparently without benefit of testing, only to be tested by the customer. This always works best in a monopolistic or semimonopolistic environment, in which the customer has limited access to alternative vendors.

Build-and-Fix Software Development Model

Waterfall Model

The classic waterfall model was introduced in the 1970s by Win Royce at Lockheed. It is so named because it can be represented or graphically modeled as a cascade from establishing requirements, to design creation, to program implementation, to system test, to release to customer. It was a great step forward in software development as an engineering discipline.

Waterfall Model for Software Development

Rapid Prototyping Model

Rapid prototyping has long been used in the development of one-off programs, based on the familiar model of the chemical engineer’s pilot plant. A throwaway prototype approach is often used if the goal is to test the implementation method, language, or end-user acceptability. If this technology is completely viable, the prototype may become the basis of the final product development, but normally it is merely a vehicle to arrive at a completely secure functional specification. From that point on the process is very similar to the waterfall model. The major difference between this and the waterfall model is not just the creation of the operational prototype or functional subset; the essence is that it be done very quickly—hence the term rapid prototyping.

Rapid Prototyping Model

Incremental Model

The incremental model recognizes that software development steps are not discrete. These builds are not the versions released to the public but are merely staged compilations of the developing system at a new level of functionality or completeness. The incremental model is a variant of the waterfall and rapid prototyping models. It is intended to deliver an operational-quality system at each build stage, but it does not yet complete the functional specification.

Incremental Model

Extreme Programming

Extreme Programming (XP) is a rather recent development of the incremental model that puts the client in the driver’s seat. Each feature or feature set of the final product envisioned by the client and the development team is individually scoped for cost and development time. The client then selects features that will be included in the next build (again, a build is an operational system at some level of functionally) based on a cost-benefit analysis. This development model is distinguished by its flexibility because it can work in the face of a high degree of specification ambiguity on the user’s part.

Extreme Programming Model
Sources: http://www.extremeprogramming.org.

Spiral Model

The spiral model, developed by Dr. Barry Boehm, is an enhancement of the waterfall/rapid prototype model, with risk analysis preceding each phase of the cascade. This model has been successfully used for the internal development of large systems and is especially useful when software reuse is a goal and when specific quality objectives can be incorporated. It does depend on being able to accurately assess risks during development. This depends on controlling all factors and eliminating or at least minimizing exogenous influences. Like the other extensions of and improvements to the waterfall model, it adds feedback to earlier stages. This model has seen service in the development of major programming projects over a number of years, and is well documented in publications by Boehm and others.

Spiral Model

Object-Oriented Programming

Object-Oriented Programming (OOP) technology is not a software development model. It is a new way of designing, writing, and documenting programs that came about after the development of early OOP languages such as C++ and Smalltalk. However, OOP does enhance the effectiveness of earlier software development models intended for procedural programming languages, because it allows the development of applications by slices rather than by layers. The central ideas of OOP are encapsulation and polymorphism, which dramatically reduce complexity and increase program reusability.

Round-Tripping Model

Iterative Development or Evolutionary Model

The iterative development model is the most realistic of the traditional software development models. Rather than being open-loop like build-and-fix or the original waterfall models, it has continuous feedback between each stage and the prior one. Occasionally it has feedback across several stages in well-developed versions. In its most effective applications, this model is used in an incremental iterative way. That is, applying feedback from the last stage back to the first stage results in each iteration’s producing a useable executable release of the software product. A lower feedback arrow indicates this feature, but the combined incremental iterative method schema is often drawn as a circle. It has been applied to both procedural and object-oriented program development.

Iterative Model of Software Development

Comparison of Various Life-Cycle Models

Table 1.1 Comparison of Traditional Software Development Models

Model	Pros	Cons
Build-and-fix	OK for small one-off programs	Useless for large programs
Waterfall	Disciplined, document-driven	Result may not satisfy client
Rapid prototyping	Guarantees client satisfaction	May not work for large applications
Extreme programming	Early return on software development	Has not yet been widely used
Spiral	Ultimate waterfall model	Large system in-house development only
Incremental	Promotes maintainability	Can degenerate to build-and-fix
OOP	Supported by IDE tools	May lack discipline
Iterative	Can be used by OOP	May allow overiteration

Implementation of New System and Maintenance

2011-04-14T11:01:00.012+08:00

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)

2011-04-13T19:42:00.000+08:00

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

2011-04-10T14:11:00.000+08:00

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

GENERATION OF PROGRAMMING LANGUAGE

2011-04-10T13:54:00.019+08:00

First – generation Language When computers were no longer being rewired but rather programmed using some form of input, computer programming took the form of numbers and numbers alone. This exclusive use of numbers to command or instruct computers in their operations was called first -generation language. It is a low - level language. A first – generation language (1GL) is a machine language, that is, programs are coded in 0s and 1s. The main benefit of 1GL is that code written by a user can run very fast and efficiently due to the fact that the Central Processor Unit (CPU) executes the instructions directly. However, there were many drawback to 1GL. In the first place, portability is a problem because of various architectural considerations, for example, if two CPU’s differ in their architecture, the program has to be rewritten completely. It is also very difficult to code and even more difficult to debug.

Second – generation Language Second – generation language (2GL) refers to some form of assembly language but the code, unlike 1GL, can be fairly easily written or read by a programmer. It must be converted into machine-readable form before running it on a computer. This means converting the assembly language into binary machine language. This low – level language has major speed advantages but requires a great deal of programming effort and is difficult to use effectively in large applications.

Third – generation Language A third – generation language (3GL) is a high – level programming language designed to be easier to understand for the user and includes named variables and structured programming. 3GL uses a compiler to convert the statements or instructions of a specific language into machine language. A 3GL language requires a great deal of programming language.

Fourth – generation Language A fourth – generation language (4GL) is designed to be closer to natural language than a 3GL language. 4GL programs were developed with a specific purpose in mind, such as the development of commercial business software. Most 4GL languages are used to access databases and are typically non – procedural. They are designed to be used by end users and to develop applications quickly.

Fifth – generation Language A fifth – generation language (5GL) is a programming language based on solving problems using constraints given to the problem, rather than using algorithm written by a programmer. An algorithm is like a recipe used to bake a cake. In 4GL the programming adds all the ingredients together to bake the cake, but a fifth – generation language is itself a master cook that uses the given ingredients to bake a cake. The different between 4GL and 5GL is that the programmer only needs to worry about which problem to solve and which conditions to meet. Today fifth – generation languages have lost part of their initial appeal and are mostly used in academic circles

Computer technology and our success in the future

2011-04-10T08:53:00.005+08:00

As we know, computer is now becoming one of the necessity in our lives. We need it to communicating with the person who at another part of the world, organize and storing our important data and making possible to the existence of e-commerce, and many others. Hence, we could not imagine the consequences if we losing it.

As a student, computer really helped me in many ways. I used it to work out on my assignments, organizing the presentations, surfing internet to search for informations, storing my datas, and assessing to e-learning of my university. Leaving aside of the useful of computer in making me keep in touch with my family, entertaining me by watching movie and listen to the musics. The focus here is how to use computer technology to achieve our goals in the future. But one thing that is certain that is computer need to be utilized by the technology of Internet.

So, since i will be graduate in one year period, i would also like to discuss about this topic. First, i think computer competencies can greatly influence our opportunities of getting jobs. This is because, nowadays, many organizations is willing to pay high salary to those computer experts. So in order to grasp the opportunity, we need to be advanced in computer technology.

Then, once we get the jobs, we also need to keep ourselves update with the changes of computer technology. The growth of computer technology is very speedy and changing every days. Therefore, it is not sustanable if we only stay with the current technology without looking for new things.

Furthermore, don't forget, we also need to concern about the ethics in using computer technologies. Sometimes, organizations loses because they was threaten by information theft. Most of the time, they are the employees inside the organizations. They steal the important informations and sell it to another competitors.

Lastly, in order to ensure the achievement of our goals, we need to think open-minded, accept the new technologies evoked, learnt how they functions and at the same time aggressively keep update with the relovution of technologies. Reluctance or resistance is only making left behind.

INTRODUCTION OF PROGRAMING

2011-04-09T21:52:00.006+08:00

It is the intent of this manual to provide an introduction to computer programming, and to the programming language, BASIC (Beginners All-Purpose Symbolic Instruction Code). BASIC is a popular programming language, especially for new programmers and casual computer users. Its conversational nature makes communicating with computers natural, simple, and straightforward. Its use of near English words and mathematical expressions gives the coding a familiar appearance. Also, its original design, to teach the casual user how to program, makes it a good language to learn first. For those of you with computer operations experience, this course is intended to provide a transition from operations into programming. It will intro-duce concepts of programming that apply to other languages as well as BASIC. For those of you with programming experience, it will provide a review of programming concepts and introduce the capabilities of BASIC and its syntax. For those not in data processing, who have a computer available, it will pro-vide an introduction to a programming language available on most computers. When you complete the course, you should understand the capabilities and syntax of the BASIC language and be able to write a program.

OVERVIEW OF PROGRAMMING
Before learning to program in the language, BASIC, it is helpful to establish some context for the productive part of the entire programming effort. This context comprises the understanding and agreement that there are four funda-mental and discrete steps involved in solving a problem on a computer. The four steps are:

1. State, analyze, and define the problem.

2. Develop the program logic and prepare a program flowchart or decision table.

3. Code the program, prepare the code in machine readable form, prepare test data, and perform debug and test runs.

4. Complete the documentation and prepare operator procedures for implementation and production.

Programming can be complicated, and advance preparation is required before you can actually start to write or code the program. The first two steps, problem understanding/definition and flowcharting, fall into the advance planning phase of programming. It is important at this point to develop

Figure 1-1.—Evolution of a Program.

correct habits and procedures, since this will prevent later difficulties in pro-gram preparation.

Whether you are working with a systems analyst, a customer, or solving a problem of your own, it is extremely important that you have a thorough understanding of the problem.

Every aspect of the problem must be defined:

. What is the problem?

What information (or data) is needed?

. Where and how will the information be obtained?

. What is the desired output?

Starting with only a portion of the information, or an incomplete definition, will result in having to constantly alter what has been done to accommodate the additional facts as they become available. It is easier and more efficient to begin programming after all of the necessary information is understood.

Java Script: The World's Most Misunderstood Programming Language

2011-04-09T15:33:00.006+08:00

Java Script is the world's most popular programming languages. Nowadays, every personal computer sure has installed with Java Script. This is because it is quite common and active used. Java Script becoming popular because of its role as the scripting language of the WWW. Actually, JavaScript is somehow related to Java, that it is a subset or less capable version of Java. It seems that the name was intentionally selected to create confusion, and from confusion comes misunderstanding. JavaScript is not interpreted Java. Java is interpreted Java. JavaScript is a different language. JavaScript has a syntactic similarity to Java, much as Java has to C. But it is no more a subset of Java than Java is a subset of C. It is better than Java in the applications that Java (fka Oak) was originally intended for. JavaScript was designed to run in Netscape Navigator. Its success there led to it becoming standard equipment in virtually all web browsers.

The first versions of JavaScript were quite weak. They lacked exception handling, inner functions, and inheritance. In its present form, it is now a complete object-oriented programming language. But many opinions of the language are based on its immature forms.

No programming language is perfect. JavaScript has its share of design errors, such as the overloading of + to mean both addition and concatenation with type coercion, and the error-prone with statement should be avoided. The reserved word policies are much too strict. Semicolon insertion was a huge mistake, as was the notation for literal regular expressions. These mistakes have led to programming errors, and called the design of the language as a whole into question.

Is JavaScript object-oriented? It has objects which can contain data and methods that act upon that data. Objects can contain other objects. It does not have classes, but it does have constructors which do what classes do, including acting as containers for class variables and methods. It does not have class-oriented inheritance, but it does have prototype-oriented inheritance.

The two main ways of building up object systems are by inheritance (is-a) and by aggregation (has-a). JavaScript does both, but its dynamic nature allows it to excel at aggregation.

Some argue that JavaScript is not truly object oriented because it does not provide information hiding. That is, objects cannot have private variables and private methods: All members are public.

Information retrieved from author: Douglas Crockford

http://www.crockford.com/javascript/javascript.html

Internet in China Vs Malaysia

2011-04-09T14:36:00.006+08:00

During the last lecture in our class, we have a group present about the information system available in China by our foreigner classmate (from China). In the last of the presentation, Madam has asked a question concern about internet in China toward the presenter. And this has grasped my attention. Before that, I even think about the internet issues in our country and also compare it to others country. So, this time I would like to share with you with the internet issues in different country.

Before I proceed to the comparison, I would like to share with you about my bad experiences with our local internet services provider. I think you all are very familiar with “cool uni pack” right? You know I take how long to get this packages? Half and a year! Yes, I’m not written it wrong. Even take half an a year but it only work when I complained it to Pusat Khidmat Aduan Pengguna Nasional (NCCC). There is a lot of reasons this local internet provider want to reject my application and I don’t want too discuss too much about this. The main issue that I want to say here is about their services! If I rank it to: 1=very good, 10= very poor, I will rate them as 11! Wrong information, slow in conduct or solve the problem, attitude and many many many that I don’t like.

Ok, let’s continue with the comparison because if I still continue with my experience I’m sure I will become a volcano explosion. Today, China is one of the easiest country in the Asia to make internet accessible to businesses, homes, travellers and students. If you are a business traveller or tourist, you will be pleasantly surprised that almost all hotels, down to 3 stars hotels, even in more remote Chinese cities offer broadband internet access in their hotel rooms. Most rooms will have an ethernet port for you to hook up to the hotel's broadband. Access is mostly automatically DHCP with dynamic IPs but in certain Chinese hotels, you may need to call the reception to allow access from your room. Home users are well taken care of as well. Many new apartment also comes with broadband access or you can apply to the Chinese Telecoms directly. Charges for monthly sDSL broadband can be as low as US$12 @ RM 36.20 for 2Mbits of access speed or even better.

Internet Service Provider Directory: (I just list down the most popular provider)

Name:	Broadband:	Subscribers:
China Telecom 31,Jinrong Street Xicheng District, Bejing, China 100032 8610-5850-1688	DSL	19,170,000
China Netcom No. 1, Beihuan Donglu, Beijing Development Area Beijing, China 100176	DSL	8,000,000
Great Wall Broadband No. 2 Great Wall Technology Building Kefa Road, Nanshan District Shenzhen, China 518057 0755-2672-8686	DSL	4,000,000

Source retrieved from: http://www.birds-eye.net/directory/china.htm

CHINANET, the world's largest Internet network reaches more subscribers in Asia than any other IP network and provides direct connections to all major global ISPs, enabling global traffic routing. CHINANET has more than 10 million registered customers and provides daily access for more than 28 million people.

China Telecom IP network services are delivered over our international 40Gbps MPLS-enabled IP backbone, and are backed by industry-leading service level agreements (SLAs) and are competitively priced to ensure our customers receive superior performance, reliability and value.

As your IP activities grow, our high capacity, fully-managed network lets you easily add bandwidth to quickly and cost-effectively increase performance.

Benefits

Accessibility : Customers access our IP network by using their choice of access technologies, including IP, private line, ATM and Frame Relay.
International : Our Dedicated International Access service is currently available in the U.S., China, Hong Kong and the world. Our global peering enables us to connect you to the world. We use owned undersea cable capacity, to connect our networks in both China and the U.S. We offer the leading international SLAs to and from China: 99.99 percent availability, packet loss of less than 3 percent, and round trip latency of less than 180ms between the U.S. and China.
Flexible Bandwidth Options : China Telecom Dedicated Internet Access can be provisioned at speeds of DS-1, OC-3, OC-12, OC-48, all Ethernet speeds, and Gigabyte Ethernet speeds. Our IP backbone is highly scalable and expandable to provide a range of capacity, allowing customers to choose the bandwidth they need.

Features

Scalable port speeds (Nx64, T1, DS-3, OC-3, Fast Ethernet, and Gigabit Ethernet)
Single global AS number in the U.S. and China
Private and public peering
Flexible billing options (flat fee or usage based)
IP addresses
BGP4-enabled
Real-time traffic reports

Source: www.chinatelecomusa.com

How much does the Internet access cost?

China Telecom are providing broadband access service for Internet users without pay for start-up fees. Broadband access service has divided in to: 512 Mbps and I Gbps. The fees for 512 Mbps is around RMB.90-100/month (unlimited access), and for 1 Gbps is around RMB.120-130/month @ RM 55.39 to RM 60.16 (unlimited access).

Control of the internet

China is one of the countries with strict internet laws. Having said that, internet usage in China is very, very common and popular for both business and personal use and not tightly controlled as may be often portrayed by Western media. Because personal computers are still relatively expensive by China's income standard, most people access the internet from cybercafes or from offices.

All websites hosted in China need to be a approved by a government unit. One of the first thing you will notice in China is that domestic sites are blazingly fast but foreign hosted sites tend to be very slow. This is due to foreign sites having to go through a proxy(for Chinese censorship purposes) as well as a bottleneck on China's limited conduit out to the international internet pipes. It is better to host your website within China if you intend your main audience to be in China.

Many foreign sites such as CNN, Falungong, Playboy and other sites deem sensitive to China's society are blocked.

Quick interesting video clip that show the increasing of the population in China and comparison internet users in China and U.S..
Source retrieved from http://www.youtube.com/watch?v=hzqr5x8dPV0

PROCESSING INFORMATION

2011-04-04T09:22:00.005+08:00

Processing is the act of doing something (e.g. organising and manipulating) with data to produce output. Processing is at the centre of our model of an information system :

There are two distinct methods of processing data : and real-time processing. In a computerised information system most of the processing is carried out by a hardware device known as a microprocessor

Batch Processing
Using batch processing input data is grouped together into batches. No data is processed until a complete batch has been put together. Then all the data in a batch is processed in one go. There may be a long time delay between data being input into the system and the data being processed.
In this type of system the important data that the computer stores all the time is kept in a file called the master file. The data in the master file is sorted into order using one of the fields in the records in the file, known as the primary key field. The primary key field must uniquely identify each record in the file.

example of batch processing:

Transaction Processing (Real Time Processing)
For some applications the master file needs to be kept up to date all of the time. For example in a travel agents whenever a seat is booked on a flight the number of seats that remain available on the flight must be reduced by one immediately. If this update was not done until the end of a day (as might happen in a batch processing system) then the flight could become overbooked.
Transaction processing systems are used whenever the master file must be kept up to date. A transaction processing system operates like this :
• When a transaction is entered it is placed in a queue of transactions waiting to be made. The transactions are processed in the order that they are placed into the queue. If there are many people using the system at the same time then there could be lots of transactions being made from different computer terminals.
• The computer system will process one transaction at a time. Once the system starts processing a transaction it will not process any other transactions until the current transaction is finished. When a transaction is processed the master file is updated immediately. Therefore the master file is always kept up to date.

Transaction processing systems need to use direct access files. In a direct access file any record in the file can be updated directly, without having to read through all of the records that come before it in the file. Serial access media such as magnetic tape can not be used. The time required to find the record in the master file that a transaction related to would make processing incredibly slow.
Transaction processing is interactive, i.e. processing takes place as a "conversation" between the user and the computer : The computer responds to the user’s input by outputting some data before the user can input any more data.

example of real time processing:

Seven Deadly Sins of Database Design

2011-04-03T23:17:00.004+08:00

Several factors can lead to a poor database design -- lack of experience, a shortage of the necessary skills, tight timelines and insufficient resources can all contribute. In turn, poor database design leads to many problems down the line, such as sub-par performance, the inability to make changes to accommodate new features, and low-quality data that can cost both time and money as the application evolves.

Sin #1: Poor or missing documentation for database(s) in production

Documentation for databases usually falls into three categories: incomplete, inaccurate, or none at all. To make matters worse, it is almost never centralized in one place. Without proper, centralized documentation, understanding the impact of a change is difficult at best, impossible at worst. This causes developers, DBAs, architects, and business analysts to scramble to get on the same page. They are left up to their own imagination to interpret the meaning and usage of the data.

Sin #2: Little or no normalization

There are times to denormalize a database structure to achieve optimized performance, but sacrificing flexibility is terrible. Despite the long-held belief by developers, one table to store everything is not always optimal. The “one table” approach may make data access easier, but invariably there will be many NULLs for columns that do not apply to a record, and special application code will be needed to handle it. Another common mistake is repeating values stored in a table. This can greatly decrease flexibility and increase difficulty when updating the data.

Sin #3: Not treating the data model like a living, breathing organism

The sin arises when changes creep into the database due to critical production issues. Inevitably, the model is then left languishing on the side if there is not a process to update the model along with the database. As more changes occur in the database, the model becomes useless.
Undocumented data can also lead to security and compliance risks, poor understanding of future changes and the inability to adapt to future needs of the business. Although the design-then-build practice may be a utopia that is never reached, the changes need to find their way back to the model.
Sin #4: Improper storage of reference data

Two main problems with reference data. It is either stored in many places or, even worse, embedded in the application code. It is almost never captured in the data model with the rest of the documentation. This causes huge problems when a reference value needs to change. Reference values provide valuable documentation which should be communicated. Your best chance is often via the model. It may not be practical to store reference values in the data model if you have large volumes, but there is no excuse not to point to them from the model. The key is to have it defined in one place and used in other places.

Sin #5: Not using foreign keys or check constraints

Customers always complain all the time about the lack of referential integrity (RI) or validation checks defined in the database when reverse engineering databases. For older database systems, it was thought that foreign keys and check constraints slowed performance, thus, the RI and checks should be done via the application. This might have been the case in the past, but DBMSs have come a long way.

Sin #6: Not using domains and naming standards
Domains and naming standards are probably two of the most important things you can incorporate into your modeling practices. Domains allow you to create reusable attributes so that the same attributes are not created in different places with different properties. It is extremely important to have a common set that everyone can use across all models. Naming standards allow us to clearly identify those attributes consistently.
Having a set of standards also ensures consistency across systems and promotes readability of models and code. You don’t want short, cryptic names that users need to interpret. Given the advanced nature of the latest vendor releases, the days of limited column length name are over when building new databases. Always have a common set of classwords to identify key types of data and use modifiers as needed.
Sin #7: Not choosing primary keys properly
The simplest principle to remember when picking a primary key is SUM: Static, Unique, Minimal. It is not necessary to delve into the whole natural vs. surrogate key debate; however, it is important to know that although surrogate keys may uniquely indentify therecord, they do not always unique identify the data. There is a time and a place for both, and you can always create an alternate key for natural keys if a surrogate is used as the primary key.
Author, Jason Tiret
Information retrieved from
http://esj.com/Articles/2010/02/16/Database-Design-Sins.aspx?Page=3