technical audit of the IT project

technical audit of the IT project

35 questions for a quick assessment of the quality of an IT project.

I’m doing the audit

Hello Habre! There are situations in life when it is necessary to assess the quality of the project at once by all articles. You can order an external audit, or you can check everything yourself using the following guide.

I have a bachelor’s degree in Applied Computer Science (Enterprise Information Systems) and 6 years of experience in web development, so I’ve put together this checklist (which you’ll find at the end) with a 100-point system that will give you a good idea of ​​the quality of the project. The material is more suitable for fresh projects, although it can also be useful for stale ones.

I divided the article into subsections of the check with a brief description of the criteria. Perhaps you will find insights in them and delve deeper into a topic.

  1. Requirements and obligations

First of all, we study the requirements from the customer – the main deadlines for submitting/rolling out features. We check obligations to organizations, if there is accreditation (conditions for obtaining/supporting). We write out all control dates.

Here we check the requirements documentation – a description of the system processes. Ideally BPMN/Activity/IDEF0. Why? The graphic way of presenting information is the fastest to understand, and the popular notations are understandable to everyone and unambiguous in interpretation.

  1. Development methodology

It is important to check the presence of the development methodology: its presence indicates the organization of the process. Lack of methodology in large teams predicts problems, although small projects can get by with close communication. There are many methodologies that suit everyone’s desire. Examples of popular methodologies:

Methodology

Description

What to check

Agile

Iterative and highly flexible methodology. Aimed at adapting to changes.

In the processes – sprints, daily, planning, retrospectives are possible.

Scrum

Agile implementation option, the most popular methodology. The same principles, a little more structured

In Scrum, important roles (Scrum Master, Product Owner, Team), artifacts (Product Backlog, Sprint Backlog) and Events (Sprint Planning, Daily Scrum, Sprint Review, Retrospective)

Lean

Talk less and work more.

There should be a focus on customer value, feedback should influence development as soon as possible

Waterfall

Suitable if there are VERY clear end requirements. At the beginning, a development plan with deadlines is built.

There should be clear adherence to the plan, there should be a plan in general, clear documentation

Prototype

A product prototype is quickly created and then refined until an acceptable result is obtained.

Must be a product version, well user tested and quick to adapt.

  1. Project management system

A project management system is required, preferably Jira/Redmine/Trello/Asana/Microsoft Project.

Agile needs a task board of the current sprint with testing, Waterfall needs a Gantt chart. A backlog of tasks is important. In Agile/Scrum, tasks should be structured (Epic > Story > Tasks + Test execution).

A clear description and title of the task, indication of testing and attachment of commits for integration with the repository are important.

Here we check the terms from point 1. Perhaps the plans will be in another system, this is not a problem. Check the compatibility of plans and risks. Obviously, if there is a discrepancy, something needs to be changed.

  1. Repository

We look at the branches in the project, behind them the git flow will be clear. It is bad if there are few branches – only master and develop, for example. Features should be developed in separate branches, they should be.

Next, we go to Merge requests. There should be:

  • Normal description

  • The task number must be specified in the commits, without this the code will turn into hell in a couple of years, you will not find the ends

  • There should be discussions, at least in large MRs, Approves – otherwise arbitrariness

  • Pipeline – must be. In the tests – assembly, linter, tests (+ deployment result, static analysis if desired)

  1. The composition of the team

There are many options, but a good basic one is this:

  • front end

  • backend

  • designer

  • the product

  • the project

  • the tester

  • devops

If the team is incomplete, something will sag. If there is no separate frontend and backend, the code may be of low quality. Without a designer, it will look like a collective farm. Without a product – there is no development plan (if it is a waterfall with a ready-made plan). Without a project, there will be chaos in development. Without testers – there will be bugs, without devops – the system will be unstable.

  1. Releases and environment

Regardless of the stage of the project, there must be a plan. The biggest standard for environments – dev, prod, stage. Releases should have a plan – Git flow, Continuous Deployment.

There should also be a plan for managing hotfixes and emergency releases to ensure stability and business continuity in the production environment.

  1. Deployment

If you do have devops, you should first look at the deployment diagrams. Here it is worth evaluating whether docker or other containerization tools are needed, as well as applications for orchestrating containerized applications (k8s, etc.). It is especially relevant for several environments, if you want automatic deployment (for example, to avoid errors when deploying the next environment) and in general for large applications, microservice architectures.

  1. Testing

Here we are talking about testing separately from development. In my experience, the most important thing here is exploratory testing. Because the developer himself can check the tasks after completion with the help of his developer friends, but you cannot check the intervals between the tasks. Some things just need to be pushed by hand sometimes. And this, in my opinion, is the most important thing. Of course, the best option is when there is both manual and automated testing, but even when it is only manual, it is already good.

Load testing will also be a plus.

  1. Code

First of all, modern technologies should be chosen. In order not to offend anyone, let’s say this: the versions of frameworks, libraries, interpreters/compilers should not be old, they should correspond to modern trends. Example (February 2024):

PHP 8 is the norm, PHP 7 is obsolete.

Node 16 is normal, Node 13 is obsolete.

If there is an examination – you can check whether the architecture is in the application and whether it is modern.

There must be tests.

Check any file – how readable it is, whether there are comments. If there is expertise, you can look deeper (SOLID, design principles).

Are there linters?

If the frontend must be indexed, SSR is highly desirable.

Documentation – how the program is arranged. I prefer class diagrams (in general, I like all UML diagrams), but other popular ways of presenting information will also work.

  1. Technical compliance

Technical compliance: here, ensure compliance with data storage requirements, use of cookies with warning and user consent, fulfillment of requirements of partner companies (for example, such as mandatory logging of transactions).

Security: Vulnerability testing and code scanning for potential threats (you can make a report directly in Gitlab or use other tools).

Logging: Having a monitoring and logging tool would be very useful. For example, Sentry. This will be very useful when the product is released to users and incomprehensible errors are thrown.

Performance: Load speed and system response tests, especially important for the frontend.

Compatibility with browsers and devices: a cursory check of display and functionality on different devices and browsers.

Accessibility and SEO: Make sure the product is accessible to users with disabilities, do SEO checks or check the report

  1. Summary table

Criterion

Mark

Check

There is documentation of processes

2

There is a development methodology

4

The methodology corresponds to the description

4

There is a project management system

5

The project management system corresponds to the methodology

5

Features are structured by epics and stories

4

The description of tasks is complete and clear, with the scope of testing

5

There is integration with the repository

4

The plans for the SUP meet the requirements

3

Repository – there are features of branches

4

MR – full description

4

MR – the task number is indicated in the commits

4

MR – there are discussions and approvals

4

MR – there is a pipeline

4

MR – the pipeline has assembly, linter, tests

3

The composition of the team is complete

2

There is a release plan

2

There is a Continuous Deployment plan

2

There is a plan for managing hotfixes and emergency releases

2

There are deployment charts

1

The deployment corresponds to the complexity of the project

2

There is manual testing

3

There is a self-test

2

There is load testing

1

Code – new technologies

4

Code is architecture

2

The code is readable and complies with design principles

3

Code – there are linters

2

Code – there is documentation

3

Technical compliance – fulfilled legal obligations (logging, warnings, security requirements)

2

There is an error logging system

2

Security – a minimum of potential threats

2

Performance – fast loading and response

2

Works in the right browsers

1

Accessibility and SEO

1

Conclusions

Thanks to everyone who read to the end! I hope this material was useful to you. Share your project review criteria!

Related posts