SV Group Services Application development

Application development

SV Group recommendations for application development are based on the Rational Unified Process (RUP).

The RUP processes and recommendations do not provide ready-to-use solutions for the development of application projects; instead, they should be adjusted and further elaborated to suit the specific features of a particular application project. The text below lists only the most important elements that may be produced by processes and recommendations for application development. Depending on the specific features of a project, it may not be necessary to generate all the elements of the application development process mentioned further on in the text.

The basic principles of application development based on the Rational Unified Process include:

  • Clear Vision – A clear vision of the targeted application system is defined at the beginning of the project within the document „Project Requirement“.
  • Iterativity – Work on the project should result in an early functional version of the application which the users can use and evaluate. Additional functionalities are added at regular intervals or iterations.
  • Risk Management – The principle of risk reduction should be applied when distributing activities into iterations; the most risky parts of the application should be treated first.
  • Visual Design – To develop an application by means of object-oriented languages (Java, C++ …), the UML should be used to describe objects, their attributes, relationships between the objects, etc.
  • Architecture based on components and services (SOA – Service Oriented Architecture) – The future application solution should be generated by means of reusable components, which requires the use of SOA architecture.
  • Regular Project Status – Project status and results should be regularly checked in order to undertake suitable actions related to problems in project management, technical problems or project risks.
  • Change Management – Requirements for changes in an application are inevitable; they should be collected exclusively through formalized procedures defined beforehand.
  • User Support – End users must have the opportunity to influence the development of a project, as this is one of the prerequisites of its successful completion.

The process of application development can be presented graphically in two dimensions.

  • The horizontal axis represents time and shows a dynamic aspect of the application development process. It shows Phases and Iterations of the application development process.
  • The vertical axis represents a static aspect of the project. It represents Activities (Disciplines) undertaken during the application development process.

The basic activities of the application development process include:

  • Business Modelling
  • Requirements
  • Analysis
  • Design
  • Implementation
  • Testing
  • Deployment
  • Maintenance

The accompanying activities of the application development process include:

  • Project Management
  • Configuration and Change Mgmt
  • Environment

Business Modelling

One of the main problems encountered in the process of application system development is how to establish mutual understanding between the two parties: business and IT.  Business modelling results in the following documents (not necessarily all of them):

  • Business Use Case Model
  • Business Analytical Model
  • Business Rules
  • Business Vocabulary

Requirements Specification

Requirements specification is an activity in the application development process intended to collect, specify, and document information which is vital for the development of a targeted application. The basic object of this activity is to describe what the targeted application system should accomplish. Requirements specification generates the following documents:

  • Project Requirements
  • Software Requirements Specifications
  • Use Case Model


Analysis is an activity dealing with analyzing data and information collected during the Requirements Specification and Business Modelling phases. Its goal is to generate the following documents:

  • Analytical Model
  • User Experience Model
  • Software Architecture Document (SAD)


Design is an activity that uses the results of Analysis to produce detailed specification which can be efficiently implemented and tested.

The primary input documents in the design process include Use Case Model, Analytical Model, Software Requirements Specification, Software Architecture Document, User Experience Model and optionally, test results.


The goal of implementation is to produce a targeted application system in accordance with previously adopted documents.

The primary input documents in the implementation process include Design Model, Data Model, Software Architecture Document, User Experience Model and optionally, Test Results.

The results of Implementation are:

  • Application Version (source and executable code)
  • Application Code Documentation


Testing is the activity of planning, defining and testing the application system. The purpose is to ensure that all project requirements (functional and non-functional) are successfully implemented.


Deployment is an activity which incorporates deployment (delivery) of an application system (final solution or one of the iterations) into the test, simulation or production environment.


Maintenance includes all changes in the application system after its deployment in the production environment for the purpose of correcting mistakes and improving system performance. It also enables adjustments to changes occurring in business, organisational or system environments.

Although maintenance is not a part of development, we should always take account of the fact that the system will be subject to changes and that it should be maintained during the entire project. Some specific maintenance-related activities are:

  • Managing the transition from a project development process to a project maintenance process implies the transfer of knowledge from the development team to the maintenance team, since they need not be the same persons.
  • Defining Service Level Agreement (SLA) once the system is deployed in the production environment. SLA documents define types and priorities of changes, as well as time and other frames within which changes should be made.

Develop long-term and stable relationships with our users, partners, employees, the owner and the social community.


By continuing to browse or by clicking “Accept All Cookies,” you agree to the storing of first- and third-party cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts. Read our.
Cookie Policy | Privacy Policy

Privacy Preference Center