Methodical approach
Our methods for your success
Our method combines different approaches and process models, resulting in a superb compromise of formalism and pragmatism. The primary aims are always improving communication, minimizing project risks, achieving all project goals, guaranteeing quality, and limiting total costs.
The ISB approach also offers additional value by using our existing document templates. These are adapted to our approach and help us to ensure that all results are in the needed form, the required level of detail, and desired quality.
Agile– quick and transparent
The agile software development process according to the classic SCRUM model is divided into several incremental iterations which we work through in two- to four-week sprints. The result of each sprint is a product increment in form of a ready and working application.
At the beginning of the project, we define the product backlog. It contains all services and tasks to be performed during the project in form of requirements that need to be implemented, the so-called user stories. These are – visible to all project members – assigned to the sprints and continuously advanced and refined throughout the project.
Every sprint starts with a joint sprint planning. Tasks are selected from the product backlog based on priority and urgency and a task schedule is generated. Here we also check that the specification is sufficient. One essential criterion is the “Definition of Done“. We decide together with you what the result needs to look like in order to guarantee a successful (partial) release after implementation and quality assurance are completed.
At the end of each sprint, there is a joint sprint review. We present the results of the sprint and check them against the previously defined release criteria (Definition of Done). Requirements that were not completely satisfied go back into the product backlog. Since all requirements are developed in small iterations and the “Definition of Done” was defined in advance for all requirements, quality assurance can be conducted as an agile process in close cooperation with the customer.
One advantage of this approach is the very close collaboration between the customer and our team. Initial modules are finished at a very early stage; the customer gets an initial impression of whether the development is progressing as desired.
SCRUM model
An agile approach according to the SCRUM model is expedient when some details are not yet defined before the start of the software development process or
- constant adaptation of the system environment is necessary,
- time-to-market pressure is extremely high,
- new technologies are used,
- cooperation and communication between customer and service provider is particularly important,
- early and constant insight into the status of the implementation is needed for continuous verification of the requirements, or
- detailed and comprehensive documentation of the process is not a top priority.
There are times when the V-model is still justified
The agile approach does not work for every project. In particular when requirements are already defined in detail, the customer does not wish to take an active part in the software development, and the requirement and budgetary framework is absolutely fixed, the V-model approach is usually preferable.
In this approach, the software development process is divided into several goal or result-oriented process phases according to the classic V-model. These phases are worked through sequentially, meaning the beginning of each phase is contingent on the conclusion of the previous phase.
Each specifying phase is juxtaposed by a test phase, which results in the characteristic imaginary “V” in the illustration. This juxtaposition leads to very high test coverage, because the specifications of the development phases are the basis for the tests (test cases) in the corresponding test phases. If inconsistencies occur, the process returns to the tested phase on the left of the diagram.
As a first step, we conduct the analysis to define the requirements of the system. The technical concept then describes the business processes the application needs to translate. We then use process models to analyze the content and goal of the individual process steps. The final result are detailed process descriptions with pre- and post-conditions in the form of use cases for all essential process steps.
After we have analyzed the “what” in the technical concept, the detailed data processing concept (design) now addresses the “how”. How do we technologically translate the business processes into IT processes? The following concepts and models are prepared as concrete templates for the subsequent implementation:
- Architecture concept
- Data model / objekt model
- Authorization concept
- Surface model
- Mask design (functional / look and feel)
- Interfaces conzept
During implementation, the specifications described in the data processing concept are consistently translated and the concepts are thus transferred into an IT system. This project phase is comprised of the segments system design and implementation.
The final system and integration tests, deployment of the system, and its subsequent roll-out are part of the hand-off.
Always knowing where you stand
Always knowing where you stand – that is what good project control is about. It requires consistent transparency regarding remaining effort, costs, dates, and possible risks. It is the only way to really achieve targeted project planning and control.
As a result of many years’ experience in managing some very extensive projects, we use established methods and instruments of professional and systematic project management. Using these tools guarantees efficiency and schedule dependability, and therefore successful projects.
Aside from personal experience in guiding complex project teams, ISB-specific control and steering instruments include e.g.
- risk analyses,
- estimates of remaining effort,
- milestone trend analyses or
- status reports.
They are common tools used by every ISB project manager. As experience in many successfully concluded projects has shown, our standards represent an ideal balance of the highest possible level of transparency and healthy pragmatism. They guarantee targeted project management with the necessary dose of common sense.
Our quality management ensures that the requirements defined for the system are completely satisfied for every project phase. The following three phases are essential:
Quality assurance
A team of QA representatives checks that our results are correct in terms of plans, concepts, documentation, surfaces, etc. The QA team also ensures that QA measures (e.g. tests) are carried out completely and correctly. These QA processes are clearly defined, supported by standardized documents, and conducted manually.
Test
System components are tested at various stages and under various quality aspects. These tests can be automated or carried out manually. Testing processes and standards are therefore defined separately or form complex independent processes as aspects of quality management. Test results and reports are integrated into the QA processes for formal testing.
For all of these aspects, we have developed a methodical approach to quality-controlled project management aligned with ISO 9001 provisions and PMI guidelines. With its modular structure, our quality system is highly flexible, so only those elements are used that actually provide a customer benefit and at the same time minimize costs. Projects “in quality, time & budget” are a logical consequence.