V Model Software Development Methodology

Widely known, the essence of the V model is that the development consists in pairs of „definition” and „verification” steps (the descending and the ascending line of the V), with the implementation cycle in the middle. Usually it starts with requirement analysis and the creation of the Requirement Specification, followed by the Functional Specification and finally the detailed Design Specification. After implementation, we assist the first-level unit tests, integration tests and finally the system verification and validation. Each step is followed by a peer review, thus ensuring that the development goes on the right direction. Sometimes there is referred the extended V model, where the very first step is to create a concept about what has to be made, and the very last step is an user support and maintenance. The model shows early the conception gaps and ensures that the offered solution will meet the needs as expected. Furthermore, this model allows good estimates helping partners to negotiate fixed-price agreements.

Codespring’s QM system suits well with the V model, although other development models are also fit. We believe that on the well-defined projects the V model can minimize the project risks, can guarantee quality, and can reduce the costs on the project life. However, there where the requirements are not well defined and are frequently changing, the use of the V model can bring too much overhead.

Agile Software Development Methodology

Agile methodology is a project management approach, used in software development. Agile methods are used as a response to unpredictability, where the requirements are not clear, or they change very often. The main advantages to this approach, is that all the work is divided into small iterations, usually two weeks, when the team re-evaluates the requirements, and can change direction at the right time, if needed.

Here at Codespring we usually work in two week iterations, in a homogeneous team, consisting of developers, testers, QA engineers, always ready to respond positively to change requests, determined by the market or the product owner. All the work is divided in user stories, which are estimated in ideal points often using the planning poker method. We try to keep a close relation with the product owner, including them as much as possible in the user stories estimation. After establishing the team velocity, we can easily create a schedule, and decide the milestones for every iteration.

Xtreme Programming Software Development Methodology

Xtreme Programming or XP is an Agile programming and software developing methodology, improving software quality and facilitating quick responses to the fast-changing needs and requirements of the customers. This is a convenient approach as Xtreme Programming processes involve frequent releases of the product and allows customers to specify new feature requests. Releases are made in short iterations as opposed to other development methodologies. XP involves a lot of communication between the customers and developers in order to better understand the implications of the problems that are to be solved, in both directions.

Codespring embraces this methodology because we have projects incorporating a lot of innovation, and the beneficial aspects of traditional programming be taken to the extremes. This approach is justified by the concept that if some is good, more can only be better. Despite the fact that release dates have to be met more frequently than in other methodologies, Codespring is capable of providing very well planned schedules and deadlines, working at a constant pace. We are able to meet rapid changes and a rich flow of ideas from the customer side, and provide quality feedback on how customer requirements can be translated into programming specifications.