Innovationweb

Software Development

Innovationweb develops software with an engineering approach, following all project phases from requirements gathering to deployment.

Innovationweb differentiates itself from other software houses as it aims to create solutions that integrate not only on a software level but also in terms of services and network infrastructure.

Some of our products that we have decided to bring to the market include: MakeBooking Hotel CRS, MakeWeb Hotel CMS, MakeWeb PRO CMS, and MakeWeb PA CMS.

Feasibility Study

In this phase, the feasibility of the project is analyzed in terms of costs, implementation time, and resources to be allocated, including infrastructure and human resources. Often, there are existing solutions in the market related to the problem under study. In such cases, it is necessary to evaluate whether it is more cost-effective to buy or develop the project.

Requirements Gathering and Analysis

The requirements gathering and analysis phase involves analyzing the application domain and determining the system requirements. A proper understanding of the application domain, which includes the problem and the context in which the website will operate, is essential to deliver a high-quality product.

This phase requires a certain level of user interaction and a careful analysis of the existing system to gather all the necessary information to produce the requirements analysis and specification document, also known as the ASR document.

To obtain a comprehensive ASR document, the "5 W" rule should be applied: Who?, Why?, What?, Where?, When?.

The first "W", "Who will use the system?", seeks to identify the different users of the website. The second "W" asks: "Why develop the system and why should users use it?".
In the case of HOTEL, the need to manage and publish real-time information about rooms, conference halls, stay or wellness package promotions, news, as well as having an online booking system, is the answer to why develop the system. The users are potential customers who wish to make a reservation or take advantage of a promotion.

The third "W", "What will it provide?", defines the services and functionalities that the website will offer. In the case of a hotel, the services provided to customers include browsing the website and making room or meeting hall reservations.

The last two W, "where will it be used and what architecture will be used?" and "when and for how long will it be used?", ask the designer about the location and timing of website usage. It becomes evident that there is a need for an efficient and secure system for managing the website, accessible and searchable via the Internet, capable of storing, maintaining, and updating relevant information.

Design

The design phase defines the overall architecture of the website. Although there are various design strategies, in general, the approach is to break down the overall architecture into subsystems, eventually identifying the individual modules that compose the system. The approach of dividing the system into modules is typical of software engineering. Each module realizes a self-contained functionality within the overall logic of the application.

It is this modular logic that allows the MakeWeb suite to be both a generic CMS and a specific CMS, proving to be an excellent solution for both hotels and public administration.

Coding and Unit Testing

In this phase, we focus on implementing the module using the chosen programming language: each part is implemented and tested separately, with particular attention given to producing appropriate documentation on the implemented module and the testing activities. This approach creates self-contained modules that will be integrated to produce the overall architecture of the website.
Subsequently, we will proceed to system testing, which is divided into alpha testing (performed by the development team) and beta testing (performed by individuals external to the development team).

Verification and Validation

It is an essential phase that serves to determine whether the website or product being constructed corresponds to the provided specifications, while validation tells us if we are building the right product according to user expectations. At this point, it is natural to ask what needs to be verified. Certainly, the final product. However, the final product is dependent on requirements and design. Expressing this concept in a formula, we could say:

where FP is the final product to be subjected to verification, S is the specification, and D is the design or project. Therefore, since the final product depends on S, D, these intermediate activities should also be verified. Furthermore, the verification activity itself should be verified because if it is conducted with incorrect criteria or improper methods, the desired results would not be achieved. Finally, it should be noted that the final product must also undergo acceptance testing by the client; in other words, the client assesses whether what has been developed is the actual solution to their problem or if modifications need to be made to the implemented product.