Precautions when outsourcing software development
- 1. Precautions when outsourcing software development work
- 2. Software development and outsourcing of development work
- 3. Contract contract, quasi-delegation contract and dispatch contract
- 4. Choose a trusted contractor
- 5. Business scope and responsibility decomposition point
- 6. Let’s write the requirement specifications firmly
- 7. Let’s decide the development management method first
- 8. Acceptance conditions are as important as the required specifications
- 9. There are various points to be aware of when outsourcing software development work.
Precautions when outsourcing software development work
There are various items that you need to be aware of when outsourcing software development to another company, but what should you be careful about? Good contractors choose, to entrust clarify the business to, the way of management is determined in advance, and acceptance conditions is determined in advance, and post-release what to do with the maintenance , such as keep thinking, there are a variety of considerations. Here, I will introduce what kind of points Gutara’s father has been careful about when outsourcing software development.
Software development and outsourcing of development work
Software development work can be broadly divided into planning, design, implementation, testing, and maintenance. It is also common in the field of software development to outsource all or part of these operations to other companies . It would be good if the outsourced part fulfills the functions and quality that were originally planned and is delivered on time , but in many cases it does not go as planned. So, can I note what that when you entrust the business do you? Here, I would like to introduce what my father Gutara was careful about when outsourcing.
Contract contract, quasi-delegation contract and dispatch contract
When outsourcing a business, we conclude a contract with the outsourced company, but the outsourcing of software development uses either a contract contract, a quasi-delegation contract, or a dispatch contract . Here, I will talk only about outsourcing by contract contract, which is often used in the field of software development. There are other quasi-delegation contracts and dispatch contracts for outsourcing, but these will be introduced at another time.
The contract contract is a contract for the purpose of completing the work, and the contractor has the authority to proceed with the work and who will do the work. In addition, the contractor does not have the command and command authority over the contractor’s workers . In short, it’s a contract that you take responsibility for the results you have achieved, because you will take care of everything, including how you work . Therefore, assuming that the outsourced work is, for example, design and implementation, the software design and implementation process will proceed according to the rules of the outsourcee. What should I be aware of in such a contract?
Choose a trusted contractor
First of all, it is most important to choose a good contractor . Unlike the production of mass-produced products, software development does not require special equipment or environment (clean water, etc.), and it is okay if there is a good engineer . To put it the other way around, if you don’t have a good engineer, no matter how good your office is, it would be great to outsource your work there.
It’s easy to say, but it 's actually very difficult to tell whether it’s a good contractor or not . Of course, you can get some information such as the scale of the company, the technical field that you are good at, and the development results so far from the information published on the net.
However, unfortunately, software development depends entirely on the competence of the engineers in charge . No matter how much the company has a track record of making good software, it would be just as wonderful if an engineer with little experience and skill was in charge of the work, not the engineer who made those achievements. You can’t expect results.
So what to do is … experience and intuition! !! Well, in short, when choosing a destination to outsource software development, ask the software leader who will be in charge of the outsourced work , and talk about the development experience, development management and technology so far. I will let you know. So, if the answer seems solid, it 's probably okay to outsource the development work to a development team led by that person . Of course, it is quite difficult to correctly judge the technical ability and development manager of the other party in a short time, but if you meet in person and have a conversation for about 1 to 2 hours, you will somehow understand the ability of that person.
If you want to the selection of a bit more subcontractors, the software development audit and so there is also a means to say, if you are interested, please also look at there of classification.
Business scope and responsibility decomposition point
Software development work flows from upstream to planning, software design, software implementation, test design, test execution, and maintenance. It is necessary to clarify which part of this work will be outsourced . At the same time, it is necessary to clarify the division of responsibilities between the outsourced work and the unoutsourced work, that is, whether it is done in-house or outsourced to another company . In other words, it can be said to clarify the entrance and exit of outsourcing .
For example, let’s say that planning is done in-house and the work from software design to test implementation is outsourced. In this case, the entrance to the outsourcing is the design work , and the demarcation point of responsibility is the requirement specification that is the input to the design work . The content written in this requirement specification is the responsibility decomposition point of the entrance of the business that the company of the other party who has been entrusted with the business under the contract contract is responsible.
The demarcation point of responsibility at the other exit is the test result report . The result of confirming by testing that the completed software meets the contents described in the required specifications is the responsibility decomposition point on the exit side of this outsourced work.
In this way, it is important to clarify the scope of the outsourced work and the demarcation points of responsibility at the entrance and exit, and proceed with the outsourcing of the work. If this is not clarified, it is possible that part of the development work will be duplicated or omitted, and the final software will not be completed.
Let’s write the requirement specifications firmly
When outsourcing some or all of the software’s function development work, it is often the case that the same company is outsourced from design to test implementation. In such a case, it is important to write the requirement specifications firmly because it is the requirement decomposition point on the entrance side that becomes important, but it is actually quite difficult to write the requirements specifications firmly.
Since it is software development, it is relatively easy to come up with the functions and performance to be realized, and it is relatively easy to write specific requirements. Such a function is necessary, it is started by such an operation, the processing is completed in such a response time, etc. If you write it concretely as much as possible, the chapter of the requirement specification will be filled. I will continue.
What is difficult to write is what is called a non-functional requirement. Stability that keeps operating stably even if you use it for a long time, robustness that handles it properly as an error and keeps moving even if you enter the wrong operation or input, it functions smoothly when adding new functions after half a year Scalability that allows you to add, maintainability to take countermeasures and collect information for cause investigation when something goes wrong, and easily switch to new hardware when hardware becomes obsolete and performance is insufficient It is such portability , and so on.
In fact, there are various non-functional requirements that need to be built into the software in addition to its functions and performance in order to make it good software that users can use for a long time even after it is released . .. And, in order to come up with these non-functional requirements, we often do not realize that we must be able to imagine how the software will be used in the market after it is completed. Why don’t you pay attention to whether the requirement specifications are written from such a viewpoint?