What Software Delivery Guidelines are appropriate when outsourcing?

Question

I started working at a very small company that regularly (not too often) has to outsource some software developments. The external suppliers than have to deliver something. As I now have seen is that the suppliers deliver a very varying quality of the deliverables - this covers sometimes only being the binary executable (no source), missing documentation, no interface description, ...
As I'm not a software expert now, still I want to baseline this and I'm looking for some kind of standards / generic best practices that could be used for contracts etc - containing what the delivery should contain like:

• the executable
• the source code
• toolchain description (reference of how to build the code)
• documentation
• interface description
• generic coding standards (maybe something that is not as specific as MISAR XY)

.. and what is so the minimum for that (on the mentioned points) - and what is missing. Are there any IEEE/RFC/ITF standards available for that kind of Software Delivery Guidelines?
In my last company, there have been experts working on that topic that have been creating this kind of document (list of required documents/deliverables) per contract/supplier.

Answer 1

I am not aware of any such standards.

Ultimately, a subcontractor should deliver whatever they are contracted to deliver. If you want documentation, it should say so in the contract. The same goes for source code, designs or anything else.

So if you're not happy with what's delivered, have a good look at what you contracted them to deliver and (as a company) ask yourselves whether your subcontracting process is sufficiently robust.

It's not in the subcontractor's interests to deliver anything more than a binary and a few release notes. If they give you everything, then you can make updates yourself, rather than paying them for improvements.

Answer 2

To my knowledge, there is no standard for this, though you should most certainly support a baseline for software for the needs of your company.

A good idea would be to establish a basic project structure as well, to better organize the project and how it will be used, something like:

project root 
  \_ source
       \_ build.sh / build.bat
  \_ bin
      \_ project executable
      \_ resources
  \_ doc

Where launching the build.sh or build.bat should produce project.exe in bin folder, and the executable would be named accordingly. Other executables can be present as well as needed. The source folder can be organized in whichever way is most convenient for the development team. Likewise, the bin folder can be organized in whichever way is most convenient for the development team, executable withstanding.

The resources folder is meant to provide whatever additional libraries or reference files needed for the executable to work.

The doc folder would be for providing basic usage and how to call. Additional technical documentation can added as well, but the basic call usage must exist (and it must reflect the current version of the build). If there is an interface to implement, then there should be complete documentation of said interface and how it will be used. One such document for each api interface (for ease of access).

You're free to change this up a bit, but something like this would be a good foundation and would be flexible for the developer.

A few tips for you, I would necessarily require the source code to be present each and every time. If your company is paying for software to be made, the software code will allow you to recreate it entirely from scratch and it is your right to ask for it.

On a more discrete note, if you don't trust this third party, you should also insist that no executable is initially present and that it is built each and every time. This takes longer, and they may argue that it is less convenient for you, but it is a guarantee that the program corresponds to the source code being built.