Custom software

Individual software (also individual solution ) is a term in information technology , which means an individual, i. H. Application software made for a specific user . It is characterized by the fact that it is tailor-made according to the requirements of a single client - in contrast to standard software , which is developed for a larger number of (potential, partly still unknown) users.

Individual software is either created by the software developers of a company or an institution, possibly also by private users, or is commissioned from an external service provider for software development. A hybrid of both is when external service providers are commissioned for the project for special tasks ("specialists") or to compensate for a lack of development capacities . Typical users of individual software are institutions that have specific requirements for their software, for which there are no exactly suitable commercially available software products.

Creation and maintenance of individual solutions, possibly also the operation and other IT services, are often outsourced to external IT companies, the details of which are specified in corresponding contracts. The clients are then customers of these service providers, but remain the owners of the software. Depending on the scope of the externally outsourced activities, the outsourcing can be legally carried out via a work contract (in the case of largely autonomous external creation) or via a service contract .

Reasons for the decision for an individual solution

If a company decides to create individual software, this can have different, non-exclusive reasons:

There is no known, suitable standard software.
The costs of individual software are estimated to be lower than those of standard software.
You don't want to be tied to a software provider ( lock-in effect ), but rather to ensure control over the future development of the software.
The company's own software should give the company a competitive edge over competitors (functionality, flexibility, stability).
Although there are standard products for the intended purpose, you want to develop a more suitable solution (e.g. take organizational and technical peculiarities / requirements of the company into account).

For further arguments / reasons see also and.

Procedure and technologies used

The only concept-forming criterion for the term "individual software " (ISW) is that it was developed individually - for use by a specific user (in the sense of the client / owner). With regard to the procedure for software development ( process models, development methods used, tools and architectures), it does not have to differ fundamentally and inevitably from the procedure for standard software (SSW). However, the different properties of SSW and ISW (see e.g. in), which differ in more or less details, also make other procedures necessary or possible. Examples:

Project trigger

A project for ISW is usually initiated when requirements arise that are not met by the existing SSW and when the expansion of the previous solution (regardless of whether ISW or SSW) is not practical.

Specifications and specifications

The software requirements are formulated from the point of view of a single client. They therefore refer to conditions (only) there; comprehensive adaptability to conditions of different users is not required. At SSW, desired subsequent adaptation measures must run through a possibly lengthy approval process, while at ISW their implementation is easier, but must be carried out or commissioned by the user.

Technical environmental conditions

As a rule, ISW is generated for a defined technical system environment (such as JEE or .NET etc.). Flexibility with regard to possible functional adaptations does not have to be, but can be provided, for example through parameterization .

Quality of the solution

ISW can be tailored exactly to the requirements and habits of the user. Their user interfaces are often more widely accepted by users than an unfamiliar and possibly functionally oversized SSW. The developers of an SSW manufacturer often have more experience. Errors, e.g. B. were discovered at one user can be corrected and the SSW can be made available to all others in the form of an update.

documentation

Since a SSW must be documented in such a way that its content is understood by many users, it is in most cases more comprehensive and systematic structured (according to page 9 in: “Volume and quality of the manual” ) than documentation that follows generated by the rules and habits of a single company.

Technical introduction

The installation programs customary at SSW are often not available at ISW or only in a simple form because no or only a few customizing functions are required, and because the software can be installed with the given procedures in the target environment.

costs

If one compares individual software with the purchase of standard software, at ISW the costs for development, maintenance and servicing usually have to be paid by just one client. This effort is offset by the license costs to be paid periodically for SSW, whereby the possibly significantly higher development effort can be passed on to many users.

As a mixed form, techniques such as aspect-oriented programming or feature-oriented programming can be used to put together individual software from finished standard components as well as individual special components.

Cost-reducing factors

There are cost factors that do not arise or only to a lesser extent in the development and operation of custom software. These can be:

The software may only have to be used for a limited number of users / workstations; Standard solutions might therefore be oversized and require higher operational resources.

Therefore, the costs for auxiliary and support services (" support ") can be lower compared to the large number of users with standard software for individual software. Users often have quicker and easier access to support providers.
The costs for user documentation can be lower - if one can assume that the users were / are involved in the development process and therefore know the functionality and have often also influenced the design of the user interface.

The degree of standardization and flexibility of the software need to be less pronounced. This means that the software only has to offer the functionality required by the individual. In terms of system load, it often only has to cope with a smaller number of use cases and does not have to be capable of running on different system environments .
In the case of custom software, the processes for error handling and the subsequent software distribution are often much simpler: error messages, troubleshooting and provision of a new version can all take place more quickly.
Installation software can often be dispensed with. In the case of standard software, on the other hand, a mechanism, usually an installation program, is part of the sales apparatus that enables error-free and automatic installation on the target systems by laypeople, as a rule. This mechanism has to cope with a large number of unknown states on the target systems, and a clean uninstallation mechanism must also be made available to remove the software again. This can cause considerable costs and is also very extensive in terms of testing, troubleshooting and support.
There are usually no costs for advertising and distribution.
If software is to be used on several computers, the license costs for standard software are higher because a corresponding number of licenses must be purchased. Individual programming can be cheaper here, since the development only has to be paid for once.
By billing according to expenditure, costs can also be saved in individual projects if the client and contractor work together in a partnership, professional and open manner.

Factors increasing costs

On the other hand, in practice the costs are often enormously underestimated. This may be due to the fact that the user or client erroneously deduces the costs of individual software from the low costs for purchasing standard software.

Further factors for high costs with custom software (most of these points can also occur with standard software, but experience shows that they eliminate themselves from the project over time):

The often short development time (compared to standard software) and the associated “time pressure to succeed” lead to all sorts of wrong decisions or hasty decisions or development processes. Often not enough time is taken to consider the development environments, modules or partial solutions available on the market.
The client would like to see partial results early because he has also made partial payments, for example. Often, however, no visible successes can be demonstrated in software development over long periods of time, at least not towards the client, if the client is a software-technical layman. Therefore, certain important development steps are often neglected prematurely in order to quickly achieve presentable results. This later avenges itself through the high expenditure of time, which is necessary to iron out any errors that have arisen. A large part of the development effort consists in planning, in preparatory development, the development of modules or partial programs, the preparation of environments, the testing and adaptation of subsystems, the documentation of the source texts and system development and the like.
The choice of wrong or inappropriate development tools or environments.
The client intervenes in the development process with inappropriate instructions that lead to cost increases, or he has certain irrelevant specifications (e.g. using outdated software or hardware, cooperation with employees or companies or systems proposed by him).
Assignment or involvement of unqualified companies or persons by the developers.
The client decides during the development process about the scope and type of the task
During the development process, the developers make decisions about the type of development systems and tools used.
Lack of competitive pressure. In the market for standard software, there is a certain competitive pressure that the end product has to compete with similar products on the market.

Individual evidence

↑ ^a ^b The Marki standard software versus individual software [1]

↑ ^a ^b ^c ^d ^e ^f ^g Uni Hannover archive link ( Memento of the original from March 4, 2016 in the Internet Archive ) Info: The archive link was inserted automatically and has not yet been checked. Please check the original and archive link according to the instructions and then remove this notice. Potentials and risks of standard and individual software @1@ 2
↑ See also advantages of billing according to expenditure ( memento of July 24, 2010 in the Internet Archive ).

[Marki-1] The Marki standard software versus individual software [1]