2012 Issue

38 Software Concept Software ideas, like other good ideas, are abundant. The challenge every software delivering organization has is to be sure the idea being considered will be the best use of resources and in the best interest of the organization at that time. Software ideas that will consume a significant amount of development resources should have a business case presented along with the proposal explaining why the concept would benefit the eventual software end-users, and how those benefits would translate into benefits to the organi- zation. When multiple ideas are being considered, the company is in a better position to choose the best one. Many companies have an internal ITGovernance committee that meets together regularly to filter competing proposals and prioritize proposals against avail- able and upcoming resources. Typically, the estimated Return on Investment (ROI) is a leading prioritization factor. Few companies take this process one step further, and conduct post-release ROI validations. At some established future date, such as 90 or 180 days after release, an ROI evaluation should be done to assess the actual ROI and compare it to the original estimated ROI in the concept proposal. If wide variations exist, the organization can assess the root causes of the variance and learn more about their market trends, data sources, and estimation practices. They may even discover that if they tweak their software product slightly, they would enhance their ROI considerably for that same product. This extra step can be a helpful competitive advantage. Scope of Requirements The most expensive problems to correct in deployed software are requirement problems. Requirement problems typically come in the formof omissions, ambiguity, and inaccuracies. Unfortunately, these mishaps are expensive and are caused by many factors, including not identifying all of the target end-users, not receiving serious or adequate cooperation from stakeholders, or leaving requirement decisions to the programmers. Considerable research has been done demonstrating the impor- tance of good requirements skills. Dr. Barry Boehm’s COCOMO II data, published in his book Software Engineering Economics , con- cludes that requirements skills are more important than develop- ment skills to the overall success of a software project. Inmy travels, this is not a common observation. Most companies hire excellent programmers and invest in tools and training for their development teams, and the requirements people are left to figure it out as they go along. Companies that invest in the best requirement people, and in training their requirement analysts, enjoy higher software success rates than their competition. To improve quality in the requirements process, an organization should create a lessons-learned checklist. Based on past require- ment errors, a company should list problems encountered in the past and brainstormways to protect the process frommaking those same mistakes in the future. The results of these brainstorming sessions should be added to a requirements review checklist, and every project should be assessed against that checklist at the final stage of the requirements process, or during each iteration planning session if the team is developing software using an agile approach. Design The software design phase consists of three parts—User Interface (UI) design, architectural design, and database design. Be sure an end-user representative formally approves the UI design before the programmers build any significant amount of code for the UI. This is a common area of rework andwaste, so approval from a user before serious coding begins is an important risk-mitigation step during design. Architectural quality control should be conducted in a way that is similar to the requirements review. Ideally, some architectural standards should exist in a development environment. Com- mon architectural standards are based on security, scalability, performance, re-usability, and maintainability. For example, an organization building internal enterprise software may have a design standard for a Service Oriented Architecture (SOA). In a SOA environment, every public component must have an in- terface, a process, a location, and a description of what it does and how it should be accessed. A design checklist should be created and evaluated for each component and for the overall design. For example, one checklist item could be that all non-database files are stored in XML format. A database design checklist might contain items such as requiring that all table names must be singular, and all Boolean fields will be one-position CHAR datatypes with either “T” or “F” values. BEYOND TESTING | continued from page 37 Once your software has progressed this far, have an end-user confirm that the working screens and reports are ready and useful. Be sure to confirm which users performed each test, and what their role was.