At Kynetia we define the development project to be used in initial stages of projects, at the same time as establishing the partnership framework with the client. Key to this process is the choice of the software product life cycle and quality assurance.

Process iteration. The need to accept change

Change is inevitable in all software projects above a certain size. This makes it necessary to employ iterative development processes, seeking to avoid the gaps that appear in evolutionary developments, which hinder project management and may have detrimental effects on architecture quality.

The sources of change lie both in the business process needs supported by the software under development and in technological advances, making it necessary to adjust both design and the implementation of solutions.

The first process models to apply iteration to processes were the incremental delivery model, spiral developments for more advanced models, such as the Agile methodologies centering on rapid product development, and the Rational Unified Process (RUP), which was created to ensure the successful completion of major projects and allows some room for adaptation in line with the needs of each project.

Development processes employed by Kynetia

• RUP (Rational Unified Process) – This is modern software development processes uses elements of all the process bases mentioned above, as well as a series of best practices to obtain a quality product.
• Scrum – More than a development methodology, Scrum defines a management framework for agile development projects. The main objective is that deliveries from each iteration should maximize value for the business for which the software is being built. It is based on the repetition of iterations every 15 to 30 days (typically four weeks), known as Sprints in the model jargon.
• Agile UP – This model is an adaptation of the agile UP (Unified Process) formalized by Scott Ambler. It is an iterative and incremental software development framework. Agile UP is often viewed as a highly ceremonial process, because it specifies numerous activities and artifacts involved in the performance of a software project. As a process framework, it is adaptable. The best-known such adaptation is RUP .

Choice of the software life cycle

Life cycle refers to each of the activities concerned in the project development process and the way in which they are carried out over time. There are numerous models, but none of them is the panacea for all projects. Rather, each of the various models has its own advantages and disadvantages depending on the type of project in question. For this reason, Kynetia employs a methodology that ensures the life cycle of each project provides the best fit with the software project developed.

Four main activity groups may be defined on the basis of the activities involved in any development process according to the literature:

• Requirements – The series of activities aimed at establishing the business requirements. This is the work of business analysts, and it falls in large part to our clients, who have the business know-how. Kynetia helps eliminate ambiguities and ensure that the requirements established are full and complete. Project managers and the officers concerned are responsible for describing functionalities and the business logic, the data stored, human/machine interfaces, etc.
• Analysis and Design – This is the phase where software architects do their main work to determine the best technical solution to adopt. The hardware and software architecture are determined at this phase, and sub-systems and their interrelationships are defined. The design of components requiring manufacture is produced and products that can be procured in the market are identified.
• Construction and Testing – This is the part where development and testing teams construct, integrate and test the specifications contained in the design documents obtained in the preceding phase.
• Maintenance and Operation – The final stage, which starts only after the product has been validated for operational running, consists of services to enhance the product in line with needs emerging from its use.

The characteristics of some projects will make it unnecessary to provide all of the life cycle activities as a serve. For example, Maintenance might be provided only during the operation of an existing system, or the project may end at with Construction and testing. Similarly, it might be necessary only to provide the architectural design of the solution.

The most appropriate life cycle is determined based on development characteristics (client needs, size, interaction with other teams, technology, scope of activities, etc.), varying the manner in which activities are performed. To explain this more clearly, let us look at some of the basic principles of life cycles in software processes.

Basic process principles

ascade development
This is a classic procedure. It is simple and easy to manage because each phase is independent of the last. It works well in small projects where requirements are clear.

The main drawbacks are the rigidity of the process and the associated risks. If a requirement changes, or if they are not well defined, the inflexibility of cascade development may cause the failure of the project. Also, the user only sees results at the end of the development cycle, and the longer this is the more likely it is that the outcome will stray from the client’s expectations.

Evolutionary development
The evolutionary development model stands in contrast to cascade development. The starting point in this case is that the development idea is unlikely to reflect the final solution. This is largely true in the case of long developments, because businesses are in permanent change and because the details and opportunities for improvements do not become apparent until an application is produced.

The idea is not to waste too much effort on specification, quickly producing prototypes that can be repeatedly refined through successive versions of the software, adapting the product to the project needs and interweaving new specifications with validation before each iteration.

This model works very well for small systems (up to 500,000 of code). It is more effective than the cascade process because any ill-defined requirements can be resolved in the course of development.

The main problem is that it may be difficult to gain an overview of the whole process due to the speed with which it goes ahead, and because of the tendency to relax the production of documentation, which hinders project management. Finally, the working method tends to degrade the initial architecture with the result that refactoring becomes necessary if the project grows beyond a certain size and complexity.

Components-based development
A greater or lesser degree of reutilization is a part of all developments, but components-based development takes it to the extreme that all elements consist of off-the-shelf components (COTs), allowing development using the Component Based Software Engineering (CBSE) discipline, in which the main effort is focused on the integration of systems.

Systems of this kind often entail the modification of requirements to ensure the fit with off-the-shelf components. The elements of the system for which no components can be found are developed and integrated with the rest to obtain the final application.