McHolmes Corps provides full life-cycle software engineering, applications development, and IT management to federal and commercial clients. We develop cutting-edge software products using flexible, agile methodologies, combined with rigorous development processes, to ensure our solutions exceed customers' expectations and provide exceptional value. McHolmes Corps has specialized experience in developing geospatially enabled mapping and planning solutions utilizing a variety of technologies, built on leading vendor toolsets including those from ESRI and Autodesk. McHolmes Corps also provides fully-supported, commercially available process management and automation software for the manufacturing industry; and sensor integration, data visualization, and decision support applications for commercial security information management systems.
The strategy for software integration provides a road map that describes the steps to be conducted as part of the implementation of software to start integration activities. When a strategy is planned, then resources are required. This strategy should be flexible and promote an approach that could show change. Sometimes, planning by senior, program and project managers need to track program and project progress and require the following characteristics:
Conduct effective technical reviews
Show different integration techniques and software approaches
Software designers are required to be involved from the start to the finish
The software integration strategy provides an en example of higher level integrations in Figure 1.
Figure 1. Software Integration Strategy
Approach to Software Integration
The approach to software integration activities are planned in advance and the first start for effective software integration. This approach accommodates lower-level integration to verify software code development that has not been implemented correctly and validate major system functional expectations by customers.
The approach of effective planning for software integration provides guidance software design, development and test teams to reach milestones expectations by senior, program and project managers. The steps for effective software integration occur numerous times when deadlines rise and measurements problems are resolved early in schedules.
Software Integration Testing
What is Software Integration Testing? The concept for testing software is to uncover errors, troubleshoot, and fix problems that occur during test. Test plans and procedures are developed to test systems and if required, rerun integration tests that are to being witnessed by quality or customers.
The software test plans and procedures developed by program and project managers and along with testing experts ensure that testing strategies are not a waste time during integration. Errors can appear went undetected. That is the purpose of having plans and procedures released and in place. Test specifications are also defined and documented to provide testing steps that test conductors and experts can implement.
Performing a review of test specifications prior to software integration testing is a strong attribute assessment before tests are complete. An effective approach to utilize a test plan or procedure for software, do lead to the order and discovery of errors at each stage in the test integration process.
The techniques for developing and the construction of the software architecture goals take unit-tested components and build program structures established by design. The "Bam Theory" approach is to attempt non-scheduled software integration and testing. This approach is performed in the following four steps:
Planning and schedules are in place
Software test plans, procedures, or internal work instructions are ready to support integration
Software Integration is ready for testing to be conducted and performed by all notified team members
Stay in control between multiple tests running at the same time. Out of control can cause chaos.
The Big Picture
Software processes are viewed as a spiral concept in Figure 2 for software integration to ensure testing is the development of software.
Figure 2. The Spiral Content
Early in the software design and development phases for military and aerospace programs and projects, a Development Facility (DF) is normally established for software integration activities. This facility is used for preparation of software prior to delivery to a S/SIF. Many statements or comments are made about these facilities, and if they have an effective way to test traffic loads on specific work products. In discussions with technicians and test teams for hours I have tried to explain that we need traffic load tests in these development facilities.
An overview of developer facilities include geographic locations in which software integration is performed, facilities used, and secure areas along with other features. Customer furnished equipment, software, services, documentation, data, and facilities are required contractual efforts along with a schedule detailing when these items needed are included. Other required resources, include plans for obtaining the resources, dates needed, and availability of each resource item.
The engineering design and development teams are primarily located in a designated software development geographic location.
Adaptation that is intrinsic to the software operations. Examples of this include parameter-based initialization data and settings selected or entered by a software designer and developer and test teams during operations of the software and systems retained for other test integration purposes.
The requirements for a software design and development environment must be understood when a schedule calls for software development and integration activities to be performed. Software integration plans ensures that each element of an environment performs to intended functions in support of the software design and development activities. The plans also provide requirements for test environments to perform software testing, including integration, trouble shooting, and checkout to ensure that each element of the test environment performs intended functions.
Software applications and tools used for designing, building, or integration testing the work product could be deliverable. Any non-deliverable software, upon which the operation depends on, after delivery, can be identified and provisions made to ensure program and project sponsors and stakeholders obtain the same software and work product.
Software tools used for integration and hardware units installed are placed under configuration control. When software upgrades or new versions become available, program and projects evaluate and recommend whether the updates should be incorporated. Upgrades are installed as soon as is reasonable for the design and development and integration activities are agreed to by all affected organizations. The criteria for evaluating an upgrade include considering integration problems detected, problems solved, and impacts on software integration efforts.
All software configuration identifications documented in accordance with the program and project software plans are effective ways to ensure configuration control. The configured baselines identify the development life-cycle, namely functional and allocated work product baselines. Unique software documentation and media define software configuration baselines.
Software Integration Setup
The software integration setup method is planning with program and project managers to coordinate with the facility operations manager. Allocated resources such as computers (i.e., work stations), and hardware units are provided to the software design, developer, and test teams to conduct informal integration testing. The software engineering builds and loading into hardware units are performed by selected build engineers.
Inside programs and project integration facilities, system integration tests are conducted and performed. Verification steps are to insure tests provide a checkout of software and hardware unit’s capabilities. The software integration test is to be repeated numerous times and ensure all integration test problems are resolved and performance is accomplished early in the defined system and also working to software requirements.
Installation Plans and Procedures
The installation plan and procedures developed, define systems specification requirements. A plan and procedure for the software integration tests cover the testing of requirements and verification methods conducted and performed in the DF. Specific integration test plans and procedures consist of checkout activities to ensure system utilization. The integration testing environment provide necessary steps to be followed, data collected, and analysis solutions are used or implemented to produce test reports during the end of testing activities. The installation test plans and procedures are to be peer reviewed and approved for release by program and project managers to prepare for the start of software integration testing.
Integration and Checkout
Early integration and checkouts focus on software components applied to tests uncover errors. Once the components are tested, an informal system is constructed. Tests are executed to fix software bugs and errors. The recommendation of processing "draft only" test plans and procedures provide loading instructions, execution, and the capabilities for uncovering problems early during integration testing. The software design and test engineers need to troubleshoot at long as possible before going into a formal test environment.
Software Integration Log
The purpose of a software integration log provides day to day operations for the design and test teams to use hardware units for integration and checkout. Facility operations managers these logs to support operational setup activities. There are no formal released plans or procedures required during this informal phase of integration. Quality personnel are not required to support integration and checkouts performed by the software design and test teams. This is an effective method to use for conducting informal software testing in preparing for such activities in a facility for software and systems integration. Allow software design teams the freedom to fix and debug problems and also work with test teams to ensure released plans and procedures will be ready for release to support formal test phases.
This software integration log is an effective method for the software design and test team to troubleshoot problems discovered during this informal test phase. Once the software is loaded into hardware units, the software does not impact and take hardware out of configuration. Hardware quality and quality software teams butt heads concerning this issue. The quality team for software is right on and provides the correct answer. No formal software plans such as step by step operational paperwork or tools in the manufacturing environment is not required.
Software Test Completion
The term "Acceptance Testing" is a discussed topic all throughout software integration program and projects. There are always questions each time when this topic is mentioned or discussed. When will the software integration testing be completed? There is never an accurate answer and that frustrates program and project managers to no end. The burden is always blamed on software engineering. Remember that the importance for quality is first and not second in any software program and projects. The pressure in on when integration testing keeps going on and on and is not completed in time to deliver the S/SIL and the customer.
The metrics collected or testing models make it possible to develop guidelines for many answers to; "When will software integration and testing will is completed?" Software Integration is the first phase before any stage of systems integration. Now understand that metrics do come into play in the early stage of software integration and testing. All program and project managers need to implement and use metrics instead of solving problems with no data to support and make key decisions.
Integration Verification and Validation
One of the important software processes for integration is the element that is often referred to a process model; "Verification and Validation". The verification aspect is a set of tasks that ensure correct implementations techniques are in place to verify that the right work product is being integrated correctly. The validation concept ensures that the correct work product is the right product to validate. The quality team roles are to perform:
Configuration Management audits
Monitor progression during software integration
Plans, procedures and documentation reviews
Qualification and Acceptance testing
Witness implemented plans and procedures during integration and test.
Quality during software integration throughout the life-cycle shows that proper methods and tools are being utilized. The real motive for quality can be applied for very large and small scale systems.