12

Our company is about to acquire a source code of a huge product.

What are thing to take into consideration when the handover starts, to make sure we have everything and be capable to maintain that product in the future?

Improve this question
3
  • 1
    If possible, request the acquisition for the some of the engineers working on the project. This will help with the resource continuity problem.
    – tehnyit
    Commented Feb 24, 2012 at 14:01
  • we are not lucky enough. we can't do that the maximum we can do is to make some engineer available for 3-4 weeks.
    – Ahmed Aswani
    Commented Feb 25, 2012 at 20:07
  • I've found a related answer I think It completes what most answers down here.
    – Ahmed Aswani
    Commented Feb 25, 2012 at 21:22

4 Answers 4

Reset to default
8

Firstly good luck.

Here are some of the things which you probably should ask for / be provided with.

  • List of known defects.
  • List of incident and problem records.
  • Details on the last two releases like; how long did they take to implement, was there a period of increased incidents following the release, etc.
  • Who are the key subject matter experts.
  • What are the hours of operation and primary support.
  • How long has the product been in existence and how stable is the code base.
  • What is the product roadmap.
  • What is the technology stack.
  • What are the integration points, and who supports the integrated systems.
  • Is there any DR components
  • Who is responsible for invoking DR
  • What are the application SLAs or service targets.
  • What is the expected growth of the file system / database / message queues.
  • When are system backups performed, who is responsible and what is the restoration strategy.
  • Who is responsible for managing the product backlog.
  • What vendor SLA and contact details are in place.
  • Are there any batch schedules or long running processes.
  • Is the system completely transactional and how is concurrency managed.
  • What is the major incident management process for the application.
  • What, when, who and how are the stakeholders notified of changes and outages.
  • What are the agreed outage periods / times.
  • Where is the source code kept.
  • How is the source code backed up, restored and change log managed.
  • Where, what and who owns the solution architecture.
  • What is the deployment target (DEV, ST, UAT, Pre PROD, PROD, DR).
  • When are the 3rd party licenses renewed.
  • Is there a RACI chart
  • How many users are there and where are they located.
  • What are the common troubleshooting problems or complaints.
  • Who is responsible for granting system access.
  • When are pent tests / security audits undertaken.
  • Where is the CI and automated build process.
  • Who is responsible for administering the source control and build server.
  • Where are the installation guides.
  • Is there documentation for the target infrastructure and network.
  • What are the types of severity and impact from recent incidents.
  • Are there developer workstation setup instructions.
    • What development aides and frameworks are used and are they licensed for your team.

That's about all I can think of at the moment.

Improve this answer
5
  • 8
    Please define "DR", "DEV, ST, UAT, Pre PROD, PROD, DR", and "RACI". Note that some of this is irrelevant for source code (i.e., RACI charts are organizational, not code related at all.)
    – S.Lott
    Commented Feb 24, 2012 at 12:38
  • I would awant access to the whoel source code repository not just the current versions of teh source code. The comments in this will often tellyou why code was changed a particular way. That is important to iknwo to maintaining it.
    – HLGEM
    Commented Feb 24, 2012 at 22:04
  • @HLGEM sorry my statement on the current versions of source code implied (well to me anyway) the full source code for all components.
    – Kane
    Commented Feb 24, 2012 at 22:33
  • @S.Lott DR is used to describe "disaster recovery". Dev is a common term for the "Development Environment", whatever that is comprised of for your environment. ST is an abbreviation for the System Testing Environment. I disagree that RACI is an organisational tool as it is used to describe who is responsible, accountable, informed and consulted. So when code is committed who is responsible for it? Who is consulted as part of a peer review? Who is informed that a build succeeded / failed? And so on
    – Kane
    Commented Feb 24, 2012 at 22:37
  • @kame: Please update the answer with the definitions. Please do not add yet more comments to the answer. Please update the answer.
    – S.Lott
    Commented Feb 25, 2012 at 12:13
6

What are thing to take into consideration when the handover starts, to make sure we have everything and be capable to maintain that product in the future?

The things you should make sure are :

  • you see them build the code successfully
  • you see them build unit tests and make all pass
  • you see them execute other tests successfully, and all pass (acceptance, integration, etc)
  • you get the database of open issues (easy to get if they use bugzilla, or similar)
  • the product runs (installation instructions).

Everything else is up to the current maintainer to hand over.

Improve this answer
4
  • 2
    I would suggest that these be modified to have the words "You must see them..." e.g., "You must see them build the code" and "You must see them run the unit tests", etc. Evidence is important here.
    – S.Lott
    Commented Feb 24, 2012 at 12:39
  • @S.Lott Whether they show, or write in a document, it shouldn't matter. Ahmed Aswani and his team are going to maintain the application, and should be able to do all the step above on their own. I modified the answer a bit, but I am not sure if that is what you suggested.
    – BЈовић
    Commented Feb 24, 2012 at 12:56
  • 1
    A claim that the code builds is not the same as actually seeing the code get built. Been there. Done that. The documentation can be vague, or confusing or incomplete. It's the old "Trust but Verify" principle. Until you see it, don't believe it.
    – S.Lott
    Commented Feb 24, 2012 at 12:57
  • 1
    @S.Lott Ok makes sense. Now that I think of it, I was in similar situation before, where they made us implement something on broken HW boards. We spent good 4 months before figuring out what is really wrong.
    – BЈовић
    Commented Feb 24, 2012 at 13:27
5

You need to make sure that the team hands over the code will provide support for a period of time. Make it a signed contract!

You will have questions later on that you didn't know you had to ask upfront, so they need to "stick around" to explain stuff to you not just give the code, docs and whatever they have on the project.

When you have a project handover you loose one important thing: the original team experience.

You sometimes also get something you didn't expect: their hostility.

Is the company doing the handover getting a good deal with the handover? If they loose business because they turn the project to you, the (proud) developers that created the code might resent the fact that their "baby" is given away. You might get responses like: "It's in the docs you got" ... even if it isn't.

Technical aspects are good to cover, but also take into consideration the human side of it.

YMMV!

Improve this answer
0

Does the code come with a test-suite? Do all the tests in the test-suite pass? How much coverage does the suite have?

I would recommend that, missing a test-suite, you make building the test-suite and related framework your first priority.

Improve this answer

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