― Edsger W. Dijkstra
388 total views, 1 views today
388 total views, 1 views today
In most developing countries the software development discipline is emerging. Several private and government entities are in the process of automating different business activities. Just like the software discipline itself, the information technology professional are still gaining expertise in specification and verification of software solutions.Where the clients know what they want, they are not in position to explain it to the developers. And equally less experienced developers find it a challenge to understand the needs of the client.
To overcome this problem, some entities hire a consultant to help manage and supervise the implementation process. That is, there are two different consulting firms involved in the project – one to do the actual implementation and the other to supervise the implementation. They all work for the client, but the supervising firm ensures quality is delivered.
This approach of a supervisor and the contractor is well tested in civil engineering works. Where you will find, the main contractor, the supervisor as independent contractors.
For this work, the discipline has to be mature such that the approaches and documentation are well understood by the different parties in the project. In some projects, this has improved the quality of the project because each contractor has a specific responsibility.
I have seen this approach work in software development with amazing results. Usually the supervising contractor requires domain knowledge to ensure that the engineering product serves the desired purpose. The presence of supervising contractor implies the need for proper specification, documentation and reports because these are part of the main inputs for the supervising contractor. The mandatory need for these documents guarantees a level of a streamlined the software development process.
995 total views, no views today
Like any incurable disease it (software) attracts more quarks, magicians and fortune tellers – -E.W. Dijkstra
In the past five years, I have come to think that it is valuable for the general public to know the distinction between a good computer system and a bad one, especially that the consequences affect even the innocent. Perhaps you have been to the bank and a teller casually announces that you can not withdraw or deposit money because the system is ‘down’, or you can not access your academic transcript because the system is ‘unavailable’. Maybe you have ever missed salary because of the computer system! Failure to withdraw your money may mean the landlord evicts you from the house or your son misses school. Failure to get the transcript may mean a missed life-time opportunity.
Such systems lead to wastage of millions of money, put lives at stake and businesses on the mercy of quarks. For government, the security of nation can be put at stake. The more computer systems fail, the more it becomes incurable because the general public has come to believe that it normal for systems to usually fail
A comparison with civil works
A comparison between the engineering of computer systems and civil engineering is informative. Unlike civil works, where the effects of a rudimentary engineering or lack of it are there to see through collapsing buildings, eroded fences and roadworks that are often fatal and lead to deaths, the effects of a rudimentary computer system are not readily visible. Mechanical engineers can get away with approximations for unknown or incalculable effects, substandard materials, and other surprises by building in safety margins. However, in software systems a single bit error can have disastrous consequences. Despite the the invisible nature of immeidate impacts of ill designed computer systems, the consequences go beyond what most can predict and can be as fatal as a collapsing building with occupants.
Unlike civil works that may be faced with fake construction materials (such as cemment in Uganda), the key players in the construction of software systems are the programmers and those that buy the software. So the quality of the software is enitely in the hands of programmers.
Now warrant not guarantee -“as is”
Interestingly, computer scientists mastered in advance, the art of hiding their incompetencies. They use fancy terms such as bugs to describe what ordinary means a malfunction. That is, a system that can not correctly do what it was intended to do. They do not even want to take responsibility of their own actions. Most software systems provide no guarantee or warrant for even the very mission the system is supposed to achieve.
The public has also accepted this situation and with not regret, it is not is common to hear with a smile that the computer system is not working, or the computer system is unavailable. Such lame explanations that have made system failure synonymous with the computing discipline are hurting. Such systems should not be casually accepted and need to be questioned for evidence of rigorous software engineering in the design and construction.
Good software is supposed to be reliable
Like any tool, a good software system is supposed to be reliable, that is safe to use by virtue of the fact that, when used, it acts as intended, or, more precisely, it reacts upon our inputs as intended. Even before subjecting a software system to a rigorous check for suitability of purpose, some indicator of incomplete and poor workmanship are usually there for even the computer illiterate to see. The first systems to be dismissed with contempt are those that fail due to any user inputs or limit existing good manual practices. That is, start by entering any data and good system should continue to behave normally. Bad systems will fail. Such systems are a clear manifestation of inept software engineering where the system is erected prematurely.
The buyer at fault
Executives, procurement officers should be aware that any programmer of some intelligence can cook up a computer system, the properties of which are utterly unattractive and unrelated to anything else. They need to be aware that the construction of computer systems is not a chaotic process with out systematic means to evaluate and sort them.
The executive managers with no formal training in software engineering approve these systems on the basis of their computer literacy normally in typing skills and email forwarding. Simple clicks and intelligent animations are usually enough to append their signatures on products that are an art of ingenious and intelligent computer quarks.
Software production is a systematic process and quality can be assured
The most important aspect of a software-based system lie in the modeling and analysis of its interactions with external factors and overall mission assurance. Before purchasing or accepting to use a software system, it must be checked for for system-level information assurance issues. It must be checked for Possible fail-stop mechanisms and procedures, fallback, contingency solutions for both direct and secondary effects of failure modes. And Usage scenarios are frequently not a priori limited.
The regular failure and unavailability of computer systems has convinced the general public that it is normal for computer systems to fail. The proliferation of poor systems is a making of buyers who are easilty decieved by self made computer experts. As Edgar Dijkstra put it, Like any incurable disease it (software) attracts more quarks, magicians and fortune tellers
2,442 total views, no views today
The goal of problem analysis is to gain better understanding of the problem being solved before development begins. It is import to know why the problem is occurring, when and how often. Try to understand the first cause of the problem. Root cause analysis is a systematic way of uncovering the root, or underlying first cause of an identified problem or a symptom to the problem. Tools such as fishbone diagram or pareto chart can help visualize the problem.
Identify stakeholders – understand needs of users or other stakeholders. A stakeholder is anybody affected by the implementation of a new system or application. Probing questions include
Define a solution boundary- the solution boundary divides the world into two parts, your system and the rest of the things that interact with your system. The system boundary defines the border between the solution and the real world that surrounds the solution. A boundary is an interface between the system and the environment or other system. All interactions with the system occur via interfaces between the system and the external world.
Understand what is involved in solving the problem. This is involves a identifying what is information is needed and what information is available.
Identify constraints to be imposed on the system – a constraint is a restriction to the degrees of freedom we have in providing a solution. Constraints may be political, economical, environmental, technological, materials and resources as described below
Schedule and Resources
3,449 total views, 1 views today
“Until the problem is well defined and articulated it is impossible to arrive at a solution”
The first step to solving any software engineering problem is to define the problem. Articulate the problem and eliminate all unnecessary terminologies and jargons. Start by reading the problem completely at least twice. Read and establish the context of each key word. If time allows, research about the problem.
Ensure that there is agreement on the problem to be solved. Try to restate the problem in you own understanding. Find out from the person who posed the problem whether the restated problem is the same as the original problem. Identify instances of the problem and see it is possible to solve an instance or example problem A solution to the example problem may lead to insights about how to solve the general problem or bring about any remaining misunderstanding.
Look at the problem from multiple perspectives. Each perspective may reveal additional information about the problem. The problem should be distinguished from its symptoms such that the root cause properly identified and stated.
The output of this step is a well-defined and articulated problem that focuses on what is required for its solution.
1,552 total views, 1 views today
Programming is the process of planning a sequence of steps called instructions for the computer to follow. The fact that you are reading this post you already know that computers lack common sense and cannot make any judgment. So the computer will do as instructed by the programmer through the computer program. Programming is more about problem solving than coding.
A problem is the difference between things as perceived and things as desired. A solution will move the situation from the things as perceived to the things as desired.
Programmers are problem solvers and need to improve the art and science of problem solving. On one hand problem solving involves an element of art in that experience, judgment and common sense can help deliver smart solutions. On the other hand problems solving is a science involving scientific means of arriving at solutions. Overall, there are several steps to be taken to solve problems
in the next post, more details on each step shall be discussed
1,393 total views, no views today