Quality System and Achievement of Objectives

The foundation for the success of any automation project or service delivery initiative is the adoption of an appropriate quality system capable of ensuring, at every stage of the process, that the results achieved comply with the expected outcomes.

The following provides a brief description of the methodology adopted by GESINF with regard to its internal quality system and the methodologies applied during the design, development, and maintenance phases of software, as well as in the management of services, implemented according to the company’s various areas of activity.

The basic elements of the company quality system are the processes used throughout the Software Life Cycle and the methodology and organization adopted within the production areas for the creation of internal and external documentation relating to the production process and associated activities, with the aim of verifying their quality.

The GESINF quality system is UNI EN ISO 9001 certified for software design, development, maintenance, support, and the provision of cloud and SaaS services.

The software life cycle is based on a methodology comparable to the so-called "waterfall" methodology, integrated with verification and review activities of the phases designed to reduce the risks associated with the incomplete execution of one of the phases.

According to the "waterfall" model, the application life cycle passes through a sequence of cascaded phases, and in each phase, it receives inputs from the previous phase and produces outputs for the following phase.

The graphical representation of this model illustrates a progression of phases such that one proceeds from one phase to the next, which does not provide, in the purely theoretical model, techniques for managing feedback loops to previous phases, and which can therefore become highly disruptive elements.

The model currently adopted by GESINF includes the phases described below, highlighting the activities that compose each phase. As will be explained later, the phases described must be understood as an abstract reference framework on which the quality system of the production area is based. Indeed, the succession of phases should not be understood rigidly, since, in the real world, there is a need to return to the previous phase, modify the sequence, or eliminate one or more phases, depending on project characteristics, imposed priorities, and practical problems encountered in the field.

STRATEGIC PLAN

It is the initial study of a project as a whole, meaning the preliminary assessment of its feasibility and, if applicable, the costs and benefits of the entire application. It includes the evaluation of possible alternatives, reference human and technological resources, and the rough timeline.

ANALYSIS AND SPECIFICATION OF REQUIREMENTS

In this phase, a complete analysis of the user's problems and application reality is carried out to specify the functional and quality characteristics that the application must satisfy.

This phase highlights above all the functional requirements, i.e., what the application must offer in terms of functionality and the qualities of correctness, reliability, and robustness of the system. The approach in this phase emphasizes what the system must do, and not how it must do it, meaning without anticipating the design choices that must be made later, focusing efforts on the user's external level of interest.

The requirement analysis represents a fundamental phase in the software life cycle, although the level of detail can vary depending on many factors, first and foremost the presence or absence of pre-established standards for managing widespread and consolidated issues. In such circumstances, the formalization of details that represent essential and commonly accepted elements within the scope of the problem in question can be omitted in favor of parts that require effective deepening.

DESIGN

In this phase, through successive stages of detail, it is defined how the requirements specified in the DSR can be achieved through a suitable hardware and software architecture, and through an appropriate decomposition of the system into sub-systems, sub-systems into modules, and modules into functions. There are generally two levels of detail:

An additional project documentation is Modeling: this term indicates the detailed specification activity of all classes and instances composing the project or part of it (currently converged into the methodology called UML - Unified Modeling Language). The purpose is to define exactly and without ambiguity, at different levels of abstraction, all information related to the application and functional classes and objects that will be part of the project (properties, methods, relationships, inheritance, etc.).

The high-level design phase is always present; for the design of system extensions (with none or few variations to the logical model), detailed design can be reduced to the bare essentials.

MODULE DEVELOPMENT AND UNIT TESTING

This corresponds to the actual implementation activity, the programming phase, carried out by the development staff in compliance with project specifications. Alongside this activity, in parallel, is the verification of the functioning of individual modules by the development personnel themselves and, upon module completion, by dedicated personnel (depending on project complexity).

This phase is assigned the task of providing any prototypes of one or more modules component the system, should the project require it. The functional characteristics of the prototypes were defined, if applicable, in the design phase.

In this phase, specific internal documentation is produced for the correct verification of compliance with deadlines and the quality of finished products. This documentation is updated by the developers themselves or, if a separate test unit is present, in collaboration with the latter.

INTEGRATION AND SYSTEM TESTING

This phase is activated after the completion of all or part of the modules composing the system, to allow its verification and subsequent operational launch. It is important, in many respects, that system tests are performed by personnel not directly involved in the previous development phase.

In this phase, specific internal documentation is produced for the correct verification of compliance with deadlines and the quality of finished products. This documentation, represented by the worksheets, is updated by the developers themselves and in collaboration with the separate test unit.

DOCUMENTATION

This phase is represented by the activity of gathering information related to the project, analysis, and project documents, on the basis of which the documentation for the client is drafted.

The temporal execution of this activity varies depending on the size and materials required.

STARTUP, GO-LIVE SUPPORT, AND MAINTENANCE

This phase includes all services provided for the system's operational launch, and subsequent maintenance activities. The activities of customer service and support include:

• Provision of technical services or specialist consultancy related to bringing a system into operation.
• Personnel training.
• System startup or go-live support activities.
• Support for system use, meant as direct or remote assistance.
• Intervention activities in case of system malfunctions or interruptions, upon notification by the client or based on information in the company's possession.
• Collection, cataloging, and evaluation of requests for system variations or extensions by the Client.
• Installation of updates, patches, implementations of new functionalities.
• The mentioned activities, to which any specific services may be added, are dealt with in the specific section.

It is evident that, in order to produce the expected results, the reference software life cycle should ideally be applied in a strictly waterfall manner, i.e. avoiding returns to already completed phases. However, since this favorable circumstance occurs very rarely in the real world, the actual software life cycle generally consists of multiple cycles of analysis-development-evaluation, giving rise to what is generally defined as the spiral life cycle. This methodology, the most widely adopted in practice, can be applied both to the development of an entire management procedure and to that of a single module, and allows the final result (for example, the definitive version of a given software product) to be achieved through successive phases of integration, improvement, and extension of functions.
The advantages of this approach are essentially the following:
The initial analysis and design focus on the main aspects of the software, namely its fundamental structure and the necessary functions, postponing to a later stage (a subsequent cycle) the definition of functional details which, although improving or extending its usefulness, do not represent essential factors. This approach leads to greater attention being paid to the determining aspects (integrity and consistency of the project), facilitates discussion with the potential client, and makes it possible to reduce development times.
Decisions regarding the improvement/increase of functions can be made on the basis of an application (or a module) that is already partially (or even fully) operational, and can therefore be assessed according to the actual benefits they provide. It is not uncommon for one or more functions initially planned, if the initial analysis has been carried out with excessive detail, to have been completely changed before the end of the project, resulting in a greater time impact than would have been required if their implementation had been scheduled as the final phase.
It is possible to release a preliminary working version (e.g. beta) which, while complying with the basic functional requirements, can be subject to refinement and improvement, also based on the client's requests, and allows an effective compliance test to be performed.
It is possible to preliminarily evaluate the impact, in terms of performance, of new functions, whenever execution times represent an important factor.
The spiral life cycle is implemented either through the execution of several complete successive cycles, i.e. through new complete sessions of analysis-design-development-testing, or through the addition of further requirements and information to the various phases of a single session. The latter approach is generally adopted for cyclical development activities up to the release of a subsequent version of the applications to the client.

As already explained, the life cycle is of the “waterfall” type. In this context, the provision of post-installation services represents both the final phase of the software life cycle, which includes returning to previous phases with the appropriate information regarding operational issues, and a continuous activity throughout the period following the final delivery of the project, which does not necessarily influence again, or at least not in a decisive manner, the production phases.
The term Services & Customer Support therefore refers to the entire set of activities that characterize the official and operational relationships between the company and the client, beginning at the time of the final delivery of the project and continuing throughout the entire validity period of the warranty and/or any contractual agreements that may have been established.

The following activities are part of customer service and support:

• The provision of technical services or specialist consulting services related to bringing a system into operation.
• Personnel training.
• System start-up or user support activities.
• Support in the use of the system, intended as direct or remote assistance.
• Intervention activities in the event of malfunctions or system interruptions, following a report from the client or based on information available to the company.
• Collection, classification, and evaluation of requests for system changes or extensions from the client.
• Installation of updates, patches, and implementation of new functionalities.

The activities described above, together with any specific services that cannot be classified within one of the mentioned categories, share the need to be carried out in compliance with a specific official or operational procedure, established over time, which requires the involvement of both the company and the client. For this type of activity, the determining factors regarding quality can be summarized as follows:

• Clarify the objective and nature of the required or due service, in all its aspects, including the definition of the resources involved and the execution methods.
• Plan the service over time, establishing execution dates and schedules.
• Verify and assess the actual execution of the service and the achievement of the predefined objectives.
• Collect, classify, and forward to the relevant areas the information gathered during service execution, which may require the activation of other services or software production/revision processes.
• Evaluate the nature and extent of the requested activity (in terms of costs, times, and procedures).
• Distribute the planned activities among production units, defining their characteristics (execution times and methods).
• Verify the progress status of the assigned activities.
• Coordinate testing and delivery activities.
• Convey preliminary and final information to commercial and management units.

It is evident that the described factors involve a considerable amount of information, and that management complexity increases when considering the need to coordinate multiple resources for solving different contingent issues. Due to this complexity, the set of information relating to the provision of the above-mentioned services is managed through a centralized information collection system, based on software specifically designed by GESINF. This system is called SSC (Software for Customer Service & Support) and represents the reference tool for all personnel employed by the company, including production, commercial, administrative, and management units.
Through this tool, all information relating to requested services and their execution is managed within a single corporate database, allowing easy identification and management of the factors described above.

The result is the creation of an integrated and fully automated structure for managing the following aspects:

• Collection of reports originating externally (Customers) and internally (test units). This includes requests for information, interventions, anomaly reports, implementation requests, and so on.
• Planning of interventions at customer sites (appointments) or internal evaluation sessions (meetings).
• Reports on intervention activities carried out at customer sites, from both a formal perspective (duration and methods) and an operational perspective (subsequent activities).
• Distribution of planned activities based on reports and interventions, among production units, at area level (analysis, development, testing, and installation) down to the level of individual staff members.
• Final reports on production, testing, and support activities.
• Management of the commercial cycle of activities, integrated with the functions described above (requests for quotations, quotations, orders, delivery).

The overall structure of the tool is designed to allow each employee to enter and consult the information within their area of responsibility, operating from their own terminal and following a series of standardized operations based on their specific area of belonging. In this way, an infrastructure is created capable of ensuring:

• The systematic collection of all information in a standardized format.
• The sharing of information among all company resources.
• The distribution of activities by production unit and by employee.
• The possibility of analyzing planned activities, delivery methods, and achieved results.

With regard to applications in 2G technology, the support service is enhanced by a functionality that automatically sends reports to the customer service department, also capable of automatically transferring a wide range of information regarding the system configuration and the context in which the problem occurred.