HACIA LA CONSTRUCCIÓN DE UNA LEY DE DESARROLLO RURAL

Phases Description

Inception Inception is significant for new development efforts; business and

requirement risks must be addressed before the project can proceed. For projects focused on enhancements to an existing system, the Inception phase is shorter, but is still focused on ensuring that the project is both worth doing and possible. During Inception, the business case for building the software is made. The Vision, a key intermediary artefact produced during Inception, is a high-level description of the system. It tells everyone what the system is, and may tell who will use it, why it will be used, what features must be present, and what constraints exist. Often the Vision contains the critical features the software must provide to the customer. This is often expressed in so-called use-cases that capture functional requirements. Use-cases allow description of sequences of events that, taken together, lead to a system doing something useful. An initial use- case model is typically drawn up with the use of diagrams that adhere to a modelling language such as the unified modelling language (UML).

Elaboration The goal of the Elaboration phase is to baseline the architecture of the

system to provide a stable basis for the bulk of the design and implementation effort in the Construction phase. The Vision is refined. Design activities focus on the notion of software architecture. The architecture evolves out of a consideration of the most significant requirements (those that have a great impact on the architecture of the system) and an assessment of risk. The stability of the architecture is evaluated through one or more architectural prototypes. Key intermediary artefacts during this stage are the software architecture document (SAD) and the iteration plan for the construction phase.

Construction The goal of Construction is to complete the development of the system.

The construction phase is, in some sense, a manufacturing process, where you emphasise managing resources and controlling operations to optimise costs, schedules and quality. In this sense, the management mindset undergoes a transition from the development of intellectual property during Inception and Elaboration, to the development of

deployable products during Construction and Transition. The Construction phase is where you produce code. It is typically the most substantial step in the process, with the bulk of person-hours used in this stage. It is typically divided into iterations that correspond to one component. Each component is built to satisfy one or more use-case(s) and other

functionality for the iteration.

Transition The focus of Transition is to ensure that software is available for its end-

users. The Transition phase includes testing the product in preparation for release and making minor adjustments based on user feedback. At this point in the lifecycle, user feedback needs to focus mainly on fine-tuning the product, configuring, installing and usability issues.

innovation than the ‘old’ notion of core competency is. He notes that core competences are unlikely to become wholly obsolete, but he shows that open business model firms are more aware of the danger that core competences can become ‘core rigidities’ (2006: 59).

The key insight provided by the literature is that the move beyond the core competence business model is a gradual process with no clear breakpoint. Even though some elements of the innovation process are organisationally de-linked from the firm, this does not mean that the disintegration process is no longer selective. The key empirical task is therefore not only to examine whether buyer firms adopt elements of the open business model, but also the degreeto which they do so and

the wayin which they do it (i.e. which element they use). The indicators defined

above are therefore only the starting point. The further analysis entails a deeper examination of the types of innovation activities that are outsourced and the degree to which these are ‘core’. The problem is, however, that this analysis easily falls into the trap of ex postrationalisation: ‘if the activity is kept in-house it must be core and

strategic’. The key is therefore to investigate firm trajectories of software outsourcing and to interpret these against the backdrop of a software innovation and

development framework. The next section develops such a framework.

3.1.2 Software development, innovation and outsourcing

In order to initiate the discussion of how one can classify ‘outsourcing’ and ‘innovative activities’ in software, it is useful to discuss the various activities in software development and provide some guide with regard to which of these are likely to constitute the loci of innovation. The section discusses the issue of software development activities in some detail because subsequent classifications pertaining to types of capabilities and types of outsourcing draw heavily on this conceptual basis.

‘Software’ is a general term used to describe a collection of computer programs, procedures and documentation that perform some tasks on a computer system. Software development is an iterative process, with various phases involving technical as well as non-technical tasks. Feedback loops are unavoidable and several activities can occur simultaneously. Planning and estimation of software development therefore revolve around phases that combine various tasks. Table 3.2 describes the four key phases in a software development project, including typical activities during each phase. One advantage of this ‘phase approach’ is that it highlights the connection between different activities at different points in time. Table 3.2 shows how multiple activities occur in each phase. The inception phase is central to the discussion of innovation in the software development process. It is necessary to place the software development process firmly in the context of its use – whether this software is for new product

development (NPD) or business process improvements (BPI). This is important because software feeds into larger human or non-human systems:

A software system is often a component of a much larger system. The software engineering activity is therefore part of a much larger systems design activity in which the requirement of the software is balanced against the requirements of other parts of the system being designed... Dealing with

18 It is sometimes said that the term ‘production’ is a misnomer in the services context. However, the term ‘production’ is often used in the software industry itself to denote relatively non-innovative processes. These are mainly implementation activities comprising coding and testing. However, implementation activities are not entirely ‘non-creative’. On the contrary, it has been suggested that they involve as much technical brilliance and creativity as requirement definition does (Brooks 1995). It is important to acknowledge that creative activities occur in both steps of the value chain, but for the purposes of this study, it is feasible to focus on knowledge creation in the requirement stage.

such a system requires the software engineer to participate in the development of requirements for the whole system. It requires that the software engineer attempt to understand the application area before starting to think of what abstract interfaces the software must meet.

(Ghezzi et al.2003: 3)

In other words, the software value chain connects with and is dependent on a larger value chain. Product development services feed into hardware systems (e.g. software in a phone), as opposed to business process software, which may underpin human systems and routines (e.g. a customer relationship management (CRM) system). Hence, the inception phase is dependent on radically different types of domain knowledge.

This domain knowledge influences the phase of software requirement definition and high-level design. This is the so-called software requirement chain. According to Arora et al.(2008), software innovationoccurs in this ‘requirement chain’ which

connects user needs to software functionality. This stage defines what a new or modified software system should do as well as its architecture. These authors contrast this with the ‘implementation chain’ in which a software artefact is actually constructed (coded in a given programming language), tested and released. They refer to this as software production.18_{Figure 3.1 shows the requirement and}

implementation chains in the standard waterfall model of the software

development lifecycle. These are the definitions of innovation and production activities in the software context. However, the next section adds further

conceptual depth to the concept of innovation and the next chapter discusses the importance of analysing innovativeness in the context of business lines.

In this way, one can think of software production and innovation as occurring in two different parts of the development lifecycle, involving different types of software activities. However, it is important to keep in mind the interfacebetween

production and innovation activities in the software development process, which

Figure 3.1

Software activities in the waterfall model – production and