2013 Issue

53 ment Beyond testing | continued on page 54 will consume a significant amount of development resources should have a business case presented along with the proposal explaining why the concept wouldbenefit the eventual software end-users, and how those benefits would translate into benefits to the organiza- tion. When multiple ideas are being considered, the company is in a better position to choose the most pertinent selection between multiple competing project proposals. Many companies have an internal IT Governance committee that meets together regularly to filter competing proposals and prioritize the presented proposals against availableandupcoming resources. Typically estimatedReturn 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, 90 or 180 days after release for example, 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 prac- tices. They may even discover 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 requirements problems. Requirement problems typically come in the form of omissions, ambiguity, and inaccuracies. Unfortunately these mishaps are expensive and are caused by many factors in- cluding 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 then 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 is comprised 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 and waste, so a user ac- ceptance approval before serious coding begins is an important risk-mitigation step during design. Architectural quality control should be conducted similarly to the requirements review. Ideally, some architectural standards should exist in a development environment. Common architectural stan- dards are based on security, scalability, performance, re-usability, and maintainability. For example, an organization building inter- nal enterprise software may have a design standard for a Service Oriented Architecture (SOA). In a SOA environment, every public component must have an interface, a process, a location, and a description of what is does and how it should be accessed. A design checklist should be created and evaluated for each com- ponent and for the overall design. Example checklist items could be at all non-database files are stored in XML format.