What techniques exist for homologation of systems?
What technique can I use to homologate software?
Is there any kind of form, pattern, technique or procedure for us to validate if a system meets the requirements?
Is there a standard document to formalize this approval?
2 answers
homologation , in the common sense used in companies, means only to obtain a confirmation from the user, an "accepted", that the software meets what it needs.
There is no standard rule or process here, though you'll probably find some templates out there.
There are some process frameworks like RUP or ITIL that talk something about homologation, sometimes using terms like acceptance tests or others. See this article , for example.
However, although they suggest good practices, they do not prescribe all actions and practices, it is up to you to understand what the method proposes and apply it according to your needs.
To perform homologation testing, you follow general principles of system testing, but there is no specific rule and it varies depending on the type of system.
To document you use the tool you have at hand. It can be an internal system like Bugzilla or Jira, a text document or even a spreadsheet. Test-related documents may also appear in checklist format, requiring you to check certain items specifically.
If you buy a consultancy for some process they will provide templates and help to customize according to your needs.
However, by making a counterpoint to the other answer, it is very important that you differentiate legal aspects from the pragmatic aspects that involve the customer satisfaction, regarding the problem that involves delivering something that may contain hidden defects.
About legal aspects, look for a specialized lawyer, ask for emails, signatures, etc.
Now, think of the other side. When you require the customer to sign a statement that the system "works", in practice, you are waiving the responsibility to test it properly and provide warranty. What is the purpose of throwing in the face of the client a signed document when does he find obvious errors in the system?
The first step towards a reasonable approval process is to have the requirements and objectives of the system very clear.
The second thing is to establish communication with the customer that allows some flexibility in changing requirements within the same budget and make clear the cost for larger changes.
In addition, it is important to differentiate non - compliance with the requirements (for example, using simple interest when the requirement says that it should be composed) of implementation errors (for example, the calculation of interest returns incorrect values in certain cases).
The system guarantee in general applies to errors only and you should make this clear.
The homologation, from the customer's point of view, should be a general check that the system is doing what it actually asked for, but it is not an attestation that there are no errors.
Who writes the software is primarily responsible by performing the tests and also training the users and demonstrating the system to them. The client is not the expert.
Think of an automobile. Ever thought if the manufacturer asked you to sign a document that there is no problem in the vehicle after a test drive? Perhaps you will argue that a car is an expensive item. Well, software that isn't worth the cost of its own quality and maintenance maybe shouldn't even have been made.
Look, I think your question is for teaching purposes, and I wanted to apply all the knowledge that the faculty gave me to answer with pleasure this question. But honestly, I think it's better to answer this question by sharing some experiences, than a theoretical text on system homologation, documentation, which does not make so much sense seeing in practice. I hope for a better answer to your question, but I really wanted to see more experiences of other users shared here too.
Text messages, call and email do not count as homologation... it's obvious!
The first system I made (at the time I was rebellious and did not listen to what I saw in college), was a commercial system adapted to a small company, I decided not to make homologation documentation. Soon, I worked for a couple of months (after the effective delivery of the system without homologation), making small adaptations, why as the turnover of the staff at the company were great, and each new one that there were "hints" to get in the system, I was very attentive, answered them, I wanted to ask you all to send their improvements, and sometimes it fixes it by e-mail, because I thought, "I will have all of this at the e-mail address, I will be able to charge you later," and, well, if I'd thought of that, you will receive an e-mail saying, ,"honey, does your the control functions, but it is a button over there in the corner?' or "it's working , but I I wanted you to open an exception, it can be", "Computer Boy, it's beautiful, a wonder, Works until when my computer is turned off, come here have a coffee" and I skeptical that I would print all these e-mails and prove that the system is operational (soon this in my head meant that it was already homologated) and still charge for the extra service. Well, I lost to gain for my service in those eight months of "improvement correction" there, "correction of the correction of an exception opening here" , then I learned that this would not be a good form of homologation, since in the head of the owner of the company, all I was doing after the delivery of the system, was correction or improvement of something already ordered by them.
Homologating everything in form does not solve 100% and gives poop
In the second system, I learned the lesson (which I cited above and was no longer rebellious in college, so I welcomed the teachings) and I I started making forms (on paper even) throughout the development of the system. The form was simple, it was a field around "tested and is sure that xzy functionality is working: () Yes () No" reflecting the initial scope of the project and so on, well described functionality by functionality. Well, there came a point that I was doing homologation on top of homologation form of another homologation already made one or more times by myself or by the other team members. Soon I realized, that the analysis that I and my team did a few months, had no weight at the time of homologation, why, the owner of the company describing a functionality is one thing, user describing and asking for a functionality is another thing, user testing/using it seems that it goes to another dimension that is inverse the dimension that the owner of the company was when he described/requested the features.
Now I homologo system making the user make a written statement, with witnesses and with notarized recognition (including I wanted to have videos, photos, audio recordings and biometric reading at that moment rsrs)
For starters, it's serious. Every step of the development, I bring the user to exhaustion forcing to complete the process, declaring for the proper purposes... that performed the system test, on a certain date, in a certain place, with the presence of witnesses, certifying that the functionality is as expected, that there were no errors during the process, and that improvements and suggestions should be sent after the delivery of the system is effective(as it should and always should be). I do this not because I want to, but it is because I do not want the company I work, to lose money and so little that the customer I serve is dissatisfied. Personally, I would prefer to do everything the user asks for, receiving it or not, it is a pleasure to do things but this is a disgrace to the company that pays my salary.
But, a homologation in fact is like this and it has to be like this always
Dear , let the whole system work, alone! Leave the room, go have a coffee bouncing around the company, make a beautiful form, fill a lot of sausage in it, a no, thousands... At the end of the homologation process, take a photo with the V of the victory of you and who was in this process, posted on face, thumblr, twitter with the hashtags #homologacaoTop #funfouTudo #semMaisHelloWorld, leave the room, go through the hallway doing Highfive with everyone, dance with the cleaning aunt, open a smile of those, the customer will see your countenance of happiness and you will infect everyone, and that harmony.... ah that harmony, that happiness that will take care of the department, that yes is a baita of a well-made homologation, the process in the end that is worth this !
Jokes aside, I wish you good luck when I get to that point.