We deliver a wide range of services at Oasis Digital – training, mentoring, development, and plenty in between. Occasionally we do an “analysis project”, in which we thoroughly review a project’s code and related assets, then prepare a written report and discussion of recommendations. Customers typically request such an analysis for the usual business reasons:
- Acquisition or investment diligence
- Budget has gone awry
- New opportunity drives a decision of whether to update or replace a software system
- As part of a technology “bake-off”
- Etc.
Although we work across a wide range of technologies, our project analysis work is focused on the technologies that we use most often, such as Angular, React, TypeScript, and Node, and many related technologies. The projects we analyze often have portions which span other technologies, and if they stray too far from areas where we have the greatest expertise, we caution customers that our analysis of those portions will be less deep.
Typical Analysis Project Scope of Work
The scope of work on an analysis project typically looks something like this:
- Meet with customer project managers and product owners to understand the business purposes for a project.
- Meet with customer developers to understand the technical background and status of the project.
- Study source code, documentation and other materials provided by customer.
- If there are multiple candidate sets of source code, use comparison tools and try to determine which is the most complete or up-to-date.
- To the extent possible, set up a development/test environment to execute the project. For some projects this is straightforward, rarely it proves impossible, usually it is somewhere in between.
- Assess use of third-party tools (open-source and commercial).
- Prepare a written report of our assessment and recommendations for the project.
- Prepare a screen video code review of some critical portions of the source code, if appropriate.
- One or more meetings with customer stakeholders (developers, product owners, etc.) to discuss the results.
Deliverables are:
- the written report
- optional screen video code review
- discussion meetings
The scope and deliverables for an analysis project do not include features, bug fixes, or other development work. We do many projects which deliver those things – but those are not analysis projects,.
Typical analysis project report outline
An analysis report will typically include sections like so:
- Introduction and summary of customer situation
- Summary of analysis work performed
- Analysis of how data is stored and managed in the software as it executes
- Analysis of how data is persisted long-term, i.e. how data is stored to a database/files/backend/etc
- Listing of third-party code libraries used
- Assessment of the currency and future prospects of such libraries
- Analysis of coding techniques used in the software, relative to popular or best practices
- Commentary on any potential security issues we notice (although as a company we do not specialize in security analysis)
- Assessment of the user interface
- Assessment of the overall amount of functionality relative to the quantity of source code
- Overall assessment of the maintainability and future prospects of the code
Of course the specific outline varies from one analysis to another, and we often have special requests from a customer to look in particular depth at one area or another.
Schedule and Cost
Depending on the size of a project, the duration can vary from days to weeks, and the cost can also vary widely. We generally can quote a price, once we know some statistics about a project, and discuss the project with someone who is familiar with the code.
For example, on a project that uses AngularJS, we would inquire about:
- How many Javascript files?
- How many total lines of JavaScript code? Ideally the tool used to count this would skip blank lines and comment lines. For both this line count in the file counts, it is best to count only project code – sometimes these numbers can get artificially inflated by third-party code you are merely using which happens to sit in a library directory in your project.
- How many template files?
- How many total lines of template?
- How many angular directives?
- How many angular components?
- How many angular services?
- How many different third-party JavaScript “widgets” are used?
- Mention any major add-on libraries that the application uses extensively; for example Lodash.
- Subjectively, how many distinct screens/pages are there in the sites/applications? Is there a large amount of code driving a small number of complex pages?
Sounds good, how do I buy this?
This is just a blog post, but if you contact us we can discuss your particular project in need of analysis, get a sense of its size, and prepare a service agreement to begin.