Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

If you were tasked with performing due diligence for a software product/IP you/your company was considering buying. What would be your steps to make sure the purchase was acceptable from a technical risk level? The scenario is one company has a product you or your company is interested in buying in it's entirety (IP and code) so that your company can now sell that product or it's services. The upfront assumption is the product has some value, but you want to assess the technical foundation of the product to ensure it's not a complete hack and nightmare to support.

Examples of this might include

  • Compile/Build and install the software on a clean computer to verify the build and deploy cycle.
  • Run a code profiling tool against the code base to get an idea of overall code quality.

What else? Are there any resources/checklists on the web which might help?

share|improve this question
1  
Is this a tool you will be using to generate software, is it software that you will be integrating into your delivered product, or is it software that you will be integrating into the software that runs your business? –  Jay Elston Jun 14 '11 at 20:44
    
Given the answers the wording of my question is apparently not very good, because folks are answering a different question than what I am intending to ask (or maybe they're not reading the content and only the title). Maybe it works better as an example. Say my company wanted to buy gmail from google. Now my company owns and operates gmail. What is the technical due diligence you would perform to make sure gmail is a good product to buy? –  Stimy Jun 15 '11 at 15:10
    
As another note, there is a ton of information on the web about due diligence for buying a company, but I can't find much for just buying one piece (product) of the company. Maybe this is just a bad question for this site, though I think technical folks would be put in this situation. –  Stimy Jun 15 '11 at 15:20
add comment

3 Answers

I'd add actually looking at the code to see if it makes you want to vomit.

How's the documentation?

Build without errors/warnings?

Have access to their bug database? What's that look like?

Never done it before though. Most I've done is evaluate the use of 3rd party libs in our own development efforts. For that I basically want to know:

  • Is the company stable?
  • Do they provide real support?
  • How's the documentation? Can I easily learn how to use this?
  • How's the design? Would I fire the developers?
  • How quick are they to respond to bug reports?
  • Do they give a crap about backward compatibility?

Things like that.

share|improve this answer
    
Also, What are the users saying about the product? How long will they continue to provide support? What are the licensing terms, do they fit my needs, and does the company have the right to change the terms later in a way that will make trouble for me? –  rlb.usa Sep 8 '11 at 18:03
add comment

BEFORE you buy anything make sure you have gathered and written down all of the requirements for the software you are purchasing. Then, itemize all of the high level requirments and prioritize them, rank, and rate them regarding their importance for the system you are looking into purchasing.

For example, let's say that (for the sake of example) you have four requirments, then rank them and give them a rating:

  • Requirement 1 - priority 1, 35%
  • Requirement 2 - priority 1, 35%
  • Requirement 3 - priority 2, 15%
  • Requirement 4 - priority 2, 15%

Then, while doing your evaluation of your different solution, test each one of them and ask questions of the vendor to see how well, or even if, they satisfy your requirements. Then, you put a rating of 1-10 for each of these requirements which determines how well (in your eyes) the system meets your requirements.

Multiply each rating by the percentage factor and add them up. This way, you can have a quantifyable way of making your decision and something that management can understand (especially if it is in an Excel spreadsheet).

Also, make sure include functional AND non-functional requirments (e.g. cost, ease of install, etc.)

I've done this multiple times successfully over the last few years.

share|improve this answer
    
That's a solid approach to any kind of evaluation exercise, provided you get the weights and requirements right, but perhaps the OP is really asking what the requirements and their relative importance actually are. Is there anything you'd like to multiply, er, I mean add? –  rakslice Dec 11 '13 at 23:58
add comment
up vote 3 down vote accepted

Since I didn't get a true answer to my question I though I'd follow up with what I did.

I ended up putting together a combination of a Due Diligence Checklist and a Software Quality Assessment in a combined document along with a list of questions and answers received from the various communications with the company we were buying the product from.

For the Software Quality Assessment I used a variant of the ISO/IEC 9126 standard tailoring it to our internal needs and weightings. This covers key aspects of software including maintainability, evolvability, portability and descriptiveness.

The due diligence checklist had a list of activities along with whether they had been completed and comments on how the activity was done. Activities included the following:

Software Architecture

  • High level Software Architecture Overview Presented
  • Software Architecture Documentation Provided
  • Code Quality Analysis Performed

Hardware Architecture

  • High level Hardware/Infrastructure Overview Presented
  • Hardware/Infrastructure Architecture Documentation Provided

Support

  • High Level Support Overview Presented
  • Support and troubleshooting documentation provided
  • High level onboarding walkthrough
  • Onboarding documentation delivered

Build and Deploy

  • Build and Deploy Documentation Delivered
  • Clean Machine Build and Deploy executed

Cost Estimates

  • Estimate ongoing Support costs for onboarding and keeping the product running
  • Estimate initial hardware and resource costs for bringing the solution “in house”
  • Estimate initial software and resource costs for bringing the solution “in house”
share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.