Are you one of those who is interacting with the software vendor in relation with changing the software that they developed? Are you the one who is told about the expensive change requests leading to ever increasing maintenance cost? Have you been thinking or wondering on how long would you pay the software maintenance cost and at what magnitude given the uncertain and ever changing business requirements?
If the answer to above is yes, you may want to get your software accessed by internal or external vendor for examining overall architecture and measuring the software code quality aspects such as maintainability. Additionally, ask the assessor to make recommendations on how to improve the system in terms of maturity model.
Lets see what can the application assessment look like.
Application Assessment – Software Quality
Following can be areas of application assessment:
- Quality in use
- Product quality
Quality in Use Assessment
This would cover the assessment of different areas related to primary users, i.e., end users who interact with the system. Following are areas of assessment:
- End user experience in terms of ease of usage/navigation
- End user experience in terms of efficiency of application; this would take into account, areas such as page loading performance, resource usage etc.
Product Quality Assessment
This would cover assessment of different areas related with secondary users such as developers who need to support the system. Following are areas of assessment:
- Application Maintainability: Under this category, we will assess the application agility in terms of ease of change. In other words, the assessment will be done to assess how easy & cost-effective is it to change some of the following:
- Presentation – User Interface (UI)
- Server side components (Business Logic)
- Data access handling
Some of the following characteristics which are key to application agility/maintainability will be evaluated:
- Modularity
- Testability
- Reusability
As part of the exercise, code smells will be identified across the applications and cost of change will be reflected. We shall also try and evaluate technical debt.
- Application Efficiency: Under this category, application efficiency will be assessed in form of following:
- Web page loading
- Resource utilization in terms of existing software & hardware
- Application Security: Under this category, application security will be assessed against OWASP standards owing to this being a web application. Following are some of the areas that will be assessed:
- SQL Injection
- Cross-Site Scripting
- Cross-Site Request Forgery
- Indirect Object Reference
- Application Reliability: Application reliability will be assessed primarily from the perspective of following:
- Whether applications fails gracefully
- Exception & error handling scenarios and best practices
- Application Usability: Under this category, following aspect of code will be assessed:
- Readability
- Understandability
Application Assessment – Gap Analysis
You may also want to get the gap analysis done to understand what are the gaps between as-is and to-be architecture. Some of the following tasks can be undertaken for performing gap analysis activities:
- Understanding TO-BE architecture
- Understanding AS-IS architecture
- Gaps analysis from following perspective:
- Assessing technology gaps (software design/code, data design)
- Assessing governance gaps (monitoring tools & frameworks, governance processes)
- Assessing people gaps (Skill with people to understand, develop, maintain, build & deploy the applications)
1.
Check out my latest book titled as First Principles Thinking: Building winning products using first principles thinking.
- Agentic Reasoning Design Patterns in AI: Examples - October 18, 2024
- LLMs for Adaptive Learning & Personalized Education - October 8, 2024
- Sparse Mixture of Experts (MoE) Models: Examples - October 6, 2024
I found it very helpful. However the differences are not too understandable for me