Information Technology provides for a new channel in the dissemination of marketing and investor information, product distribution, and service delivery as well as provides tools for rapid decision support, just-in time inventory, and a repertoire of various benefits that leverage on the immediate availability of information. To be competitive, it is of primary importance that our company invests in an IT infrastructure to tap this new product, service, or information delivery channel as well as leverage on the huge potentials of quick information for robust opportunities in terms of greater savings, new businesses, or more efficient operations. While our CEO recognizes the importance of IT and is committed to developing an in-house information systems development staff, let me present the various stages, methods, techniques, tools and strategies in the development of software, as well as point out the various pitfalls and traps in this undertaking. Information systems development may have its benefits but it can also come up with various risks that can be potentially damaging to our company if poorly managed. Except for the recommendations, the ideas and issues that follow have been generally derived from Roger S.
Pressman’s (2005) book entitled: Software Engineering: A Practitioner’s Approach.Here is the first issue. The systems development lifecycle (SDLC) pertains to many choices, and each choice corresponds to a set of steps or stages that are significantly different from each model or methodology. Some models and methodologies are as follows: (1) waterfall; (2) fountain; (3) spiral; (4) build and fix; (5) rapid prototyping; (6) incremental; and (7) synchronize and stabilize. The most successful software developer in the world, Microsoft, has an additional set of approaches in its portfolio of models and methodologies: (1) it buys the entire company that develops the software it cannot successfully develop; and/ or (2) pirate entire teams of software architects, software engineers, test engineers, analysts, programmers, etc.
who have successfully developed a desirable software application. Each model or methodology can have its distinct advantages and pitfalls. However, the greatest pitfall of all models and methodologies, except for the additional approaches of Microsoft as described here, is the incubation period or the software configuration and management (SCM) phase. SCM is necessary to establish stability. In short, no matter how speedy the model’s or methodologies’ name implies, software development takes time. And by the time a software is finally developed, new software or hardware would have had made the software application obsolete compared to a newer alternative.Here is the second issue. Aside from models and methodologies, systems development usually comes with tools such as the approach of the programming language in the form of object-oriented programming for instance versus procedural programming.
Two programmers that each specialize in one form would have difficulty understanding the other. Hence, a unified modeling language (UML) that can be universally understood by different programmers who may have different skill sets and specializations have been developed. Thus, although one may be proficient in one software development lifecycle model or programming language, UML provides the way for one to be understood by another proficient in a different discipline. UML is like English, the international language of business, while programming approaches are like the different ways people of different races build houses.
When a new programming approach dominates, the old approach needs to be totally flushed out of a programmer’s mindset, who may be used to the old way of doing things. Otherwise, he/she would be creating software using new technology but coding it according to old ways. This is like using an assault rifle as a club to bash the head of a target rather than pulling the trigger to smash it. Other tools would include computer-assisted software engineering (CASE), which is self-explanatory as the acronym implies.Software architects basically design software according to a structured discipline that minimizes the risk of instability while software engineers execute such designs. This structured discipline is commonly known as structured systems analysis and design.
In most cases, software development usually goes beyond the projected timeframe and budget. But this is not the entire fault of the software architect or the poor skills of the software engineer. In most cases, many variable factors affect software development. One factor is changing user requirements. Users generally do not know what features they need or want until they see one, hence the participatory design approach has been modeled together with rapid prototyping to ensure the greater participation of users in an iterative design process, which can take forever. Another factor is the quality of data.
Data exceptions usually pressure programmers to cut the feet to fit the shoe. When designs (the shoe) have already been made and a data exception (a different set of feet) occurs, the general reaction is for programmers to update the database table. This circumvents the validations that have been coded to ensure data quality and integrity. Some would create new sets of shoes to fit different feet, but most often this reaction leads to unmanageable complexity that eventually makes the software unusable due to unexplained system crashes and menacing instability.Hence, in software development, the opportunities are many but the pitfalls are even greater. To develop a competitive and highly skilled IS development staff with minimum risks, I recommend the following steps: (1) Let us buy ready-made software that are already tested in the areas these applications are supposed to serve, these are cheaper in the long run; (2) Let us only develop software for areas that require customization especially for those that are not yet covered by commercial-off-the-shelf software, our staff would have had baselines on features and user needs that can be gleaned from ready-made software already in use; and (3) Let us be ready to train and develop staff on a technology that could become immediately obsolete and forget about it so we can jump to the next best technology, if we cannot do this fast enough, it would be best to outsource our customized software requirement with adequate provisions for penalties in case our sub-contractor fails to deliver. One thing is for sure: we are not in the business of software development but we can effectively develop our own with minimal risks through these three steps.