Successful In Budget On Time Met Requirements User Involved

1. The services provided through Aspiron’s Independent Verification and Validation (IV&V) range from the establishment of enterprise-level capability within an organization to the execution of assessments that support organizational system development efforts. Software “Chaos” How software projects generally fair …. • Challenged • Over Budget • Late • Missing Capabilities • Successful • In Budget • On Time • Met Requirements • User Involved Cancelled • IV&V works with the Project • Goal is project success • IV&V is an engineering discipline • IV&V processes are defined and tailored to the specific program • Mission, operations and systems knowledge is used to perform engineering analyses of system components Code Requirements & Design • IV&V is most effective when started early • 70% of errors found in testing are traceable to problems in the requirements and design • IV&V works problems at the lowest possible level • Primarily work via established organization interfaces (e.g. working groups, Integrated Process Teams, etc.) • Elevate issues only when necessary Installation Defect Densities Where do all those defects come from?

2. The support of system development efforts* encompass any SDLC and contain assessment tasks within four categories: • Verification and Validation Planning • Requirements and Design Assurance • Quality Assurance • Test Execution and Reports • * To be most effective, Aspiron’s IV&V team members should have intimate, unbiased participation in requirements definition, design reviews, code inspections, and configuration change board decisions. Verification and Validation Planning: IV&V Planning and Effort Estimates - Like other plans, IV&V planning should be generated early, initially as part of the Software Development and Quality Plans, and later as a standalone document. Planning for change and its impact to the test strategy is essential as system requirements and architecture will likely change during development activities. Conversely the IV&V strategy for regulatory compliance may change which in turn can impact system requirements and architecture tradeoffs. The IV&V effort can be a significant portion of the projects resources and therefore deserves to be estimated and tracked like other development activities. This is especially true for regulated industries where the effort may consume up to half the cost. Test Objectives - Test objectives should be developed early to help remove ambiguity from the system requirements. It is not uncommon for a project to release too early or become mired in testing because there are no clear objectives established to determine completion criteria. Usage goals for the project such as performance, reliability, and usability must be considered in addition to functional testing. The Software Development Plan should clearly state whether the business uses testing to access project and release risks, or simply as a debugging exercise. Software Maintenance and Upgrades - A good Quality Plan will anticipate the special needs of the Maintenance life-cycle. Modifications to existing products are often underestimated because they tend to appear smaller and more limited than a full development activity. All the processes followed for the initial development project should also be executed in some form for maintenance and upgrades. This ensures all of the good quality work put into the initial product continues as the product is changed and enhanced. Requirements and Design Assurance: Requirements and Design Reviews - Historically, 65 % of the project defects originate in the requirements phase; it is very important that the verification and validation efforts mature these elements quickly before development resources are wasted in the wrong direction. A diverse group of participants, modeling, and formal inspections can be a valuable part of these reviews to ensure system requirements and designs are correct, complete, traceable, and testable. Development Infrastructure Control and Certification - Tools that the team members will use to perform analysis and development tasks should be validated and configuration controlled. These tools include requirements management, configuration management, change control, issue tracking, quality analysis, checklists, templates, forms, compilers, integrated development environments, schematic capture and layout, computer aided design, authoring, testing, monitoring, and any other project specific tools which support the development activities. Standard Operating Procedures – Standard operating procedures and documented guidelines establish the roadmap and framework for the project; they ensure the development process is sound, repeatable, and managed. Aspiron maintains a full quality systems program that includes a library of procedures, policies, and guidelines to quickly train team members on all the processes they will utilize. Team ownership in these processes is encouraged through training and tailoring to address any inadequate or incomplete procedures. Team Training – Team members typically come from varied backgrounds and environments; this is a great advantage during activities requiring diversity of perspective. However, if not on the same foundation, team members could be at odds with each other. Team Training is very important to effectively make progress and implement the established quality-based processes; it is often overlooked or too limited in scope.

3. Test Execution and Reports: Test Case Development - Test cases validate each of the requirements (are we building what the customer wants) and verify each of the design elements (did we build the product right). Traceability of test cases to requirements and design are crucial to ensuring appropriate test coverage. Test procedures establish the testing processes, steps, methods, and pass/fail evaluation criteria before the test is executed. Test Execution and Report Generation - Test cases are executed following best practices to establish evidence of the results of the execution. A report of the results (both details and summary) is made to document the testing effort, and provide a baseline for future regression testing. The test report is formal, unbiased, and separate from any release decisions, which are made by the project and business leaders. Defect Tracking and System Change Requests - All defects are not created equal and all system change requests have a cost. Each must be evaluated on its own merits to the project in both the current phase and future commitments. Some must be implemented immediately while others may be deferred for later consideration or may be even counterproductive to the goals of the project. The Configuration Control Board (CCB), a qualified group of team members with diverse backgrounds and perspectives, has the responsibility to manage these decisions effectively. Requirements creep is an inevitable condition affecting all software projects. Its most dangerous results can be attributed to failure to manage change or defect resolution, creating indefinite delays in product launch or feature upgrades. A well defined change management process implemented through an effective CCB can manage requirements creep and thereby protect the project’s scope, schedule, and budget from erosion. Simulation Environments - Simulations assist in both development and integrated verification activities. Simulation is used to take the place of physical components that are not yet available; test objectives and procedures may be evaluated before the product is available using simulated components. Simulation can also be used to control or establish a known test environment for regression testing purposes and automated testing. Early and informed selection of simulation environments can result in reuse in product development, debugging, testing, and manufacturing. Quality Assurance: Dedicated Specialists – These are people who are not directly responsible for the development of the code, but will ensure that the defined processes are followed and quality expectations are met. Each Aspiron professional possesses many years of hands-on experience as a developer, systems engineer, configuration manager, software tester, database administrator, business intelligence engineer, and project manager. Their comprehensive experiences provide a uniquely empathetic and non-confrontational approach to the multi-faceted world of software quality. Capability Maturity Model Integration – CMMI is a process improvement approach used by business to establish the maturity and reliability of their current process and also identify areas for improvement. A goal for projects is to reduce risks while improving predictability and reliability without substantially increasing overhead costs. Aspiron’s continuous or staged quality systems program is designed for any project to operate at CMMI Level 3. The program can be tailored as necessary for the size and purpose of the development effort. Internal Audits – Internal Audits are “self checks” performed by a resource independent from the project in order to assess compliance to the established project plans and the overall corporate-wide quality goals. Audits are invaluable during the development activities and for purposes of showing compliance to standards. For instance, an audit of deliverables required to exit a project phase is very timely and important to preventing a project from skipping ahead before it is ready. Risk assessments and audits of computer systems, software, and processes are important for both certification and business operation efficiency. Metrics and Static Analysis Reports - Metrics are valuable for more than just long term trend analysis. There are several special purpose static analysis tools typically used during software and hardware development to assess the qualities of those deliverables. Reports generated by these tools should be available to everyone on the project to encourage uniformity and immediate improvement opportunities. For example, software developers should be able to generate qualitative reports on their code before code check-in and inspections. Minimum acceptance levels are established as phase exit and entry criteria.