Step 2 Comprehensive Software Assessment Process
This posting is the second in a series on Software Assessment. In the previous post, we looked at Change Definition and outlined a broad activity in which we seek to envision every aspect of a proposed change and how it will affect our environment.
In the Identify Key Differences step, we take a deep dive into the software, hardware, people, process and environment of our systems and anticipate what will be different after the change. The goal here is to compare before and after images of our infrastructure and operations to articulate what will be different and what those differences will be.
Software and Software Artifacts
In traceability analysis, the relationships between system requirements and software specifications are captured and documented. If a requirement or specification changes, the analyst can use the baseline traceability relationships to identify other requirements or specifications that may change or need to be changed as a result.
Not surprisingly, the quality of a software change analysis is highly reliant on the quality of the available data. Any gaps or errors in the baseline documentation will propagate through the analysis to produce errors in the assessment of key differences.
Good data for analysis can be hard to come by. Manual documentation for large complex software architectures is extremely difficult and expensive to maintain, and documentation is often not given a high priority in today’s rapid development, continuous deployment environments.
Fortunately, our enterprise solution, Crosscode Panoptics, fully automates the application discovery and code-level dependency mapping process. This automation enables your organization to complete analyses with a fraction of the time and expense seen in manual efforts, while at the same time driving up the quality and completeness of your baseline data.
Panoptics also provides powerful Software Assessment functionality to complete this assessment step by letting you see and document how any proposed software change will ripple through your architecture and what other elements may need to be changed.
Along with the software itself, several standard software development artifacts may be impacted by the change. Examples of such artifacts include user manuals, online help, and training materials, as well as the baseline architecture documentation itself describing requirements, specifications, and dependencies.
Software change projects frequently involve changes in the associated hardware requirements. Software changes can result in greater server storage needs, higher network throughput requirements, or the need for end-users to have a more capable minimum configuration.
As with software changes, in the Identify Key Differences step we will seek to define the current hardware baseline as accurately as possible and then identify all the elements of that baseline that would be different after the change project.
Certain new hardware requirements may be difficult to accurately determine during a Software Assessment. The need for some changes might not become apparent until upgraded software can be tested and bench marked. However, there are important steps you can take to anticipate potential new demands on hardware. A software change, for example, may provide new services to users, which in turn may imply greater network demands.
Significantly, many new hardware requirements can be traced to third-party tools and components. Many times, organizations do not have complete, up-to-date information on the third-party and open source components in their systems. Again, Panoptics’ automated discovery and mapping capabilities can help here, providing an easy mechanism to scan your infrastructure and ensure you have a baseline understanding of all potential contributors to your baseline hardware requirements.
People and Process
Evaluating the follow-on differences to an organization’s staffing and policies for a proposed software change is generally a team activity. Subject matter experts from human resources and other business operations functions are in the best position to help establish a definition for the current state and make informed predictions as to what the key organizational differences will be.
As a preliminary step, all relevant documentation should be gathered and distributed to the team. Depending on the nature of the change project, this documentation could include organization charts, job descriptions, workflows, policies, and procedures. After the team has reviewed the documentation, a facilitated work session can provide a venue for the team to collaborate and determine all the likely organizational changes that would be needed.
The Panoptics Difference
Crosscode Panoptics’ industry-leading discovery and code-level dependency mapping capabilities will significantly improve your ability to establish an architectural baseline and define the key differences change projects will bring to that architecture. Our unique algorithms dig deeper into your infrastructure than any other solution to reveal dependencies and applications that others will miss - including critical third party and open source components.
Panoptics’ application discovery and dependency mapping features are fully automatic, saving months of labor compiling the data for Software Assessment. In upcoming posts in this series, we will continue to explore the Software Assessment process and the many ways in which Crosscode Panoptics can save you time and money while driving down risk and improving your estimates.
If your responsibilities include conducting Software Assessments for complex software and infrastructure change projects, contact us today for a personalized demonstration and let us show you the difference Panoptics can make.