How to outsource a software development process?

We are having a good idea for a software product. Since its complexity surpasses the capacities for a one man army or perhaps of a small software team, it will be necessary to outsource software production.

We want to write a complete specification on how software should be. Think about it as a complete blueprint that should has the following characteristics:

• It let us to establish a complete contract with a software factory.
• It can be "registered" as a business idea (like a patent). I do not know the mechanisms because I'm not a lawyer, but the idea is to impede other parties to take advantage on the idea without being responsible for stealing it.
• It specifically has to include something like time production estimates in order to know how much will it cost.

We know that there are artifacts like a Requirements Analysis Document and Use cases besides other modeling tools like UML. We do not know the following:

1. Is there an industrial standard about what should be given to a software factory outsource in order to start a development process?
2. Do you know which kind of maturity process certification has to have a software factory to guarantee its efficacy? (i.e. CMMi, but there should be more..)
3. Which artifacts usually compose a software process for a commercial product?
4. How to ask to a software factory about which artifacts do they require to write a software?

Juan, there are no set standards in the software industry and there are many different methodologies. Varying from a waterfall development methodology where everything is specified and defined in much detail on the entire projects before developing anything. To, agile development methodologies where you have a high level view of the entire game plan, but you only plan in small iterations (usually 2 weeks) but you deliver something usable on each deliverable. Continue to use that process to build out future features and incorporate information.

At a minimum you will want:

• Wireframes: Your idea of what you think you need. Paper and pencil mockups of your screens, what is to be collected, how each behaves, what happens when you click on each document.
• Specs / requirements: A document that explains in plain language the overall project and what is going on on each page.

There is much more that you can produce, but I would say that is the minimum. You could do use cases, workflow charts, UML / database diagrams - but are you a developer / database guy?

I also wouldn't judge a company by their CMM level. All that really means is they have a process they follow each and every time. They analyze the process, improve it, refine it but they have a repeatable 'process.'

It doesn't mean that they are building award winning and awesome projects. It means that they will approach the projects and deliver them in a similar way.

Also, your blueprint that you write should not include time estimates as you mentioned above. That is up to the development team to determine.

Usually you can choose 2 of these 3. Cost, Timeline, Features. and the other company tells you the 3rd.

Examples: You want to pay $50,000 and want it in 6 months. Then they get to say, fine... but you are only getting these features.

You want to pay $50,000 and want these 100 features. They can say fine, but we are working on it in our spare time and it will take 2 years.

You can say we want these 100 features, and in 2 months, they can say no problem $100,000.

After you refine your wireframes & specifications with your development company you will want to go through a pretty detailed user experience process. You should have a professional designer / UX professional understand your application and do a beautiful and usable design for it. The developers will then use these assets and ideas when building your app.

This is so it doesn't come out looking terrible and being a horrible experience to use. AND is critical! If an app looks great, feels great even if it is not awesome it will still give the user a great feeling. If it has all the features in the world but is ugly and not a good experience, you lose every time.

After that you may need to revisit, refine your milestones and schedule.

You will want to work with your development company to determine the right technologies to be used. You may even run that by a couple 3rd parties to get their feedback.

Most importantly when CHOOSING a company to work with, they must be able to show you similar enough software applications that they created that give you confidence they can build your application. If you have a sophisticated web app you want created and they keep showing you Wordpress / marketing websites ... that's an issue. If they can show you applications along the same lines that you want, then you call those companies and check up on them :]

Good luck with your project. It's good to do as much as possible before getting in touch with prospective developers, but make sure you find someone who can take your IDEAS and do what is right with them.

You don't want to tell them to do something and they do it without question. They should know more about software, usability, and the entire process then you. And you should trust their expertise, or you have the wrong partner.

• The patent aspect is best learned by reading tons of patents. Check out Yahoo's, Microsoft's, Yahoo's for good examples. However, I am in general against software patents.

In my experience in building the technology for http://www.Staff.com you're going to find that as you start building the software your requirements will likely change. It is very difficult to know the exact specifications.

When you said "Since its complexity surpasses the capacities for a one man army or perhaps of a small software team, it will be necessary to outsource software production." I would say that this approach is highly unlikely to succeed. Outsourcing complex software to a third party is a recipe for disaster. If you have the funding it's better to hire that capability in house. Hire one person who has built similar software before to lead the team, and then build the rest of the team from there.

It might be worth investing a little bit of time and money on a mock-ups tool (like Balsamiq) and sketching out how you expect the main parts of the application to work. This will help a lot with documenting what you need and also allow you to "play with it" to see how it all hangs together. When you select a company to build it, this mock-up will be something they can work from.

You can do something similar in Visio (I used to use it for that), but Balsamiq is trivial cost ($79) and designed for this exact job.

At some point, this will all get a lot easier, as various startups are working on ways to allow anyone to create complex applications, without the need to hire developers, etc. Turns out, most people can build what they need and start using it right away, quicker than they can document it.