To determine what level of formality is appropriate for your project you can look at the customization factors in the follow-ing sections. The factors have been inspired by D.I.R. (2000), ISO 12207 (1995), and Euromethod (1996) and should be viewed as guidelines and not exact values on what level to choose. It is important to look at several factors and determine which are most important for your project before you decide upon a for-mality level.
3.2.1 Product characteristics
The product characteristics factors obviously stem from the char-acteristics of the software product to be acquired.
Requirements volatility
Since software development is a creative process, and it is diffi-cult to anticipate all technical problems beforehand, change of requirements occur more or less in all software development projects. However, due to the nature of the problem the soft-ware is to solve, the total set of requirements can be more or less change-prone.
Minimal proc-esses suffi-cient
Stable requirements. Highly unlikely that the overwhelming majority of the requirements will change.
Controlled processes recommended
A significant subset of the requirements is vola-tile.
Robust proc-esses rec-ommended
Volatile requirements. High degree of uncer-tainty on a large or important subset of the requirements.
Program size
The estimated program size indicates the effort that is needed to build the software. The values given in the table below are to be considered as suggestions since program size depends on what language is used and other factors.
Minimal proc-esses suffi-cient
Small. Less than 32 KLOC1.
3 Customization
Large. More than 128 KLOC.
Criticality
Criticality is the impact malfunctioning software will have on people’s safety and the magnitude of financial loss that can re-sult, according to Oskarsson and Glass (1996).
Minimal proc-esses suffi-cient
People’s safety is not at risk, nor will any signifi-cant amount of money be lost if the software mal-functions.
Controlled processes recommended
People’s safety is not at risk, but there is a risk of moderate financial losses due to software mal-functioning.
Robust proc-esses rec-ommended
The safety of people is at stake or huge amounts of money. A disaster occurs if the software
doesn’t function properly.
Innovation
Oskarsson and Glass (1996) define innovative projects as those in which the problem is new and different and hasn’t been solved with computer programs before. Less innovative pro-jects use mature and proven technology.
Minimal proc-esses suffi-cient
Mature technology. Many similar applications exist.
Controlled processes recommended
The technology has been proven to work and is expanding but few similar applications exist.
Robust proc-esses rec-ommended
Emerging unproven technology where the ques-tion is more on whether the problem can be solved. Unique application.
Transformational impact
Transformational impact is the depth of change that the deliv-ered software product will have on the user’s behavior and the user organization’s processes and products.
Minimal proc-esses suffi-cient
Minimal change for the user.
Controlled processes recommended
Moderate modifications or amendments to the user’s behavior or the internal work processes and products of the user organization.
Robust proc-esses rec-ommended
Fundamentally changes the behavior of the user and the work processes and products of the user organization.
3.2.2 Effort
The effort customization factors delivery time, total cost, and de-velopment team size are implied by the estimated effort to build the software. The estimate is based on the product characteris-tics. The larger the effort is the higher formality is required to avoid unnecessary chaos.
Delivery time
Delivery time is the estimated calendar time for delivery of the finished software product. With a longer project there is a higher likelihood that new people will join the development team and others leave. Change in the requirements is also more likely. The values given in the table below are to be considered as suggestions.
3 Customization
Total cost is the estimated total cost to acquire the software in order of magnitude. The value ranges of low, medium, and high in the table below are difficult to specify since these values may change over time and are only given as suggestions.
Minimal proc-esses suffi-cient
Low. Less than $50,000.
Controlled processes recommended
Medium. $50,000 – $1,000,000.
Robust proc-esses rec-ommended
High. More than $1,000,000.
Contractor development team size
The more people that are involved in the contractor’s develop-ment team the more communication is needed to coordinate the work, sort out misunderstandings, and resolve conflicts. The values in the table are not to be considered as absolute.
Minimal proc-esses suffi-cient
Less than 10 developers.
Controlled processes recommended
10 – 30 developers.
Robust proc-esses rec-ommended
More than 30 developers.
3.2.3 Contracting environment
The contracting environment customization factors are related to the contractor and the organizational environment that the ac-quisition takes place in.
Organizations involved
The more organizations, such as stakeholders, supporting con-tractors, consultants, independent testing organizations, etc. are involved, the more communication is needed to coordinate the work.
Minimal proc-esses suffi-cient
Two parties involved in a simple dyadic relation-ship; customer and contractor.
Controlled processes recommended
More than two parties are involved; either sev-eral customers co-sourcing, or sevsev-eral contractors collaborating, or subcontractors are used, and possibly supporting contractors. The organiza-tional structure is not (too) complex.
Robust proc-esses rec-ommended
Several organizations are involved in a complex organizational structure composed of some or all of the following: multiple customers, multiple contractors, multiple subcontractors, multiple supporting contractors, etc.
3 Customization
© Daniel Svennberg 2001 27
Contractor development team characteristics
The contractor’s development team characteristics are the ex-perience, constitution, and performance of the contractor’s de-velopment team.
Minimal proc-esses suffi-cient
Low staff turnover. Mostly experienced and well-trained personnel. Well functioning teamwork.
Efficient and appropriate working methods.
High performance.
Controlled processes recommended
Moderate staff turnover. Some inexperienced and untrained personnel. Teamwork could be func-tioning better. Working methods need some im-provement. Medium performance.
Robust proc-esses rec-ommended
High staff turnover. Lots of inexperienced and untrained personnel. Teamwork not functioning optimally. Inefficient and inappropriate working methods. Low performance.
Experience with contractor
The type and level of experience with the contractor(s).
Minimal proc-esses suffi-cient
The customer and contractor have worked to-gether on several previous occasions and have a good relationship built on trust. The customer knows how the contractor works and vice versa.
Controlled processes recommended
First time working with a contractor with good results working for other customers, or mixed experiences with a previously used contractor.
Robust proc-esses rec-ommended
First time working with a contractor that is not well known or has had bad results working for other customers, or bad experiences with a previ-ously used contractor.
Geographic dispersion
Management becomes more difficult with customer and con-tractor on different geographical sites.
Minimal proc-esses suffi-cient
The customer, contractor, and other involved parties work at the same site or can visit and work on each other’s site on a daily basis.
Controlled processes recommended
The customer, contractor, and other involved parties work at different sites, with their respec-tive teams located at the same site, and cannot meet on a daily basis.
Robust proc-esses rec-ommended
The customer, contractor, and other involved parties have several teams involved in the project dispersed on several different sites and they can-not meet on a daily basis.
3.2.4 Other factors
The factors stated above are only suggestions and you will probably have to look at more factors to be able to customize the project appropriately. Other factors include: standards re-quired, laws and regulations, other projects, cultural differ-ences, application domain, system complexity, etc.
29
4 Roles
“No matter how much you want it to be a technical problem, it’s a people problem.”
– Unknown
Having good people and good teamwork is key to the success of the project. This chapter presents the different types of roles that may be necessary for a successful software acquisition pro-ject. One person can be assigned several roles. The roles de-scriptions are assembled from and based upon the different frameworks stated in appendix A, Marciniak and Reifer (1990), Salwin (1998), and the interviews with Urmi (2000), Oskarsson (2000), and Ran (2000).