Integration Development

Project
Specialization: Software Engineering"

"Modular Web Application for

Construction Project Management"

Prepared by :
Hela Nefla
Rahma Jebali
Eya Maamouri
Zayneb Akermi
Youssef Oueslati
Dawsser Ghzel
Mentored by:
Mohammed ali bellili
Table of Contents
• General Introduction ……………………………………………………………………..…………… 3
Chapter 1: General Framework of the Project ………………………………………………………….…… 5

o 1.1 Problem Statement ……………………………………………………………………………6

o 1.2 Strengths and Weaknesses of Existing Solutions …………………………………… 6
o 1.3 Proposed Solution ……………………………………………………………………….…… 6
o 1.4 Methodology Adopted …………………………………………………………………….… 8
▪ 1.4.1 Introduction to SCRUM ………………………………………………………… 8
▪ 1.4.2 Roles in SCRUM …………………………………………………………………… 9
▪ 1.4.3 SCRUM Development Cycle …………………………………………………… 9
• Chapter 2: Sprint 0 - Analysis and Specification of Needs …………………………..……… 10
o 2.1 Needs Analysis ………………………………………………………………………………… 13
▪ 2.1.1 Identification of Stakeholders ………………………………………………… 13
▪ 2.1.2 Functional Requirements ……………………………………………………… 13
▪ 2.1.3 Non-Functional Requirements ……………………………..………………… 14
o 2.2 Requirements Specification ………………………………………………………..……… 14
▪ 2.2.1 Global Use Case Diagram ……………………………………………………… 14
▪ 2.2.2 Product Backlog …………………………………………………………………… 15
o 2.3 Architectural Specification …………………………………………………………..……… 17
▪ 2.3.1 Microservices Architecture ………………………………………………..…… 17
▪ 2.3.1.1 Characteristics of the Microservices Architecture ………….………… 17
▪ 2.3.1.2 Motivation for Using Microservices …………………………………………17
o 2.4 Design Patterns …………………………………………………………………………….…… 19
o 2.5 Working Environment …………………………………………………………………….……20
• Conclusion …………………………………………………………………………………………………… 22
General Conclusion ………………………………………………………………………………………………… 23

1
General Introduction
In the construction sector, project management holds paramount importance in ensuring
the smooth execution of operations, adherence to deadlines, budgets, and quality
standards. These projects, often characterized by their complexity and the involvement of
numerous stakeholder project managers, engineers, architects, suppliers, and workers
require meticulous coordination and structured organization. However, traditional
management methods, which rely on static or centralized tools, quickly reach their limits
in the face of the growing challenges within this sector.

To address these challenges, a modern and modular approach is essential. Microservices

architecture emerges as a particularly suitable solution for designing efficient and flexible
tools. This architecture allows the application to be divided into several independent
services, each dedicated to a specific functionality, such as managing deliverables,
schedules, or dashboards. These microservices communicate seamlessly while
maintaining independence in their development, deployment, and maintenance.

The adoption of microservices not only ensures enhanced modularity but also provides
greater scalability. Each service can be improved or replaced without impacting the rest
of the system, allowing for rapid adaptation to the evolving needs of users and projects.
Moreover, this architecture promotes efficient task distribution within development teams,
where each member can focus on a specific part of the system while working
autonomously.

This report presents the development of a construction project management application

based on this architecture. By leveraging the modularity offered by microservices, the
application aims to simplify collaboration among stakeholders, optimize task tracking, and
provide tools tailored to the growing complexity of construction projects. Through an in-
depth analysis of functional and non-functional requirements, explanatory diagrams, and
detailed design steps, this document highlights how microservices architecture can
transform project management and offer innovative solutions to the challenges of the
construction sector.

The present report, which describes the project's progression in detail, is structured into
two main chapters:

• The first chapter provides a brief overview of the general framework of the project.
It concludes with the project management methodology applied to ensure the
efficient execution of our work.

2
 • The second chapter outlines our initial sprint. It begins with a detailed analysis of
the application's overall functional and non-functional requirements, followed by the
general use case and the specification of various sprints. The chapter also delves
into the application's architecture detailing both its physical and logical design.
Finally, it specifies the design patterns used and the working environment, along
with the technological choices enabling the realization of our solution.

The report concludes with a general summary of the work completed and offers some
perspectives on future developments.

3
 Chapter 1

General Framework of the Project

Plan

1.1 Problem Statement ........................................................................................... 5

1.2 Criticism of the existing solution ............................................................ 5

1.3 Proposed Solution ............................................................................................ 5

1.4 Methodology adopted ...................................................................................... 7

1.4.1 Introduction to SCRUM ........................................................................... 7

1.4.2 Roles in SCRUM .......................................................................................... 8

1.4.3 SCRUM Development Cycle .................................................................... 9

4
Introduction
In the following, we will introduce the host organization that proposed the topic, its
services, and its products. Then, we will present an alternative solution. Finally, we will
conclude this chapter with a presentation of the adapted project management
methodology.

1.1 Problem Statement

Construction project management often suffers from a lack of organization and

appropriate tools. Traditional methods, relying on spreadsheets or disconnected tools,
limit collaboration and make centralizing information difficult. The main challenges include:

• Coordination of different teams involved in a project.

• Real-time tracking of deliverables, schedules, and timesheets.

• Management of large volumes of data with distributed teams.

The main objective of this project is to provide a centralized and modular solution capable
of addressing these needs while ensuring greater flexibility and scalability.

1.2 Criticism of the existing solution

Strengths of Existing Solutions

• Centralized Management: Tracks inspections and defect management.

• Mobility: Mobile apps for on-site inspections.
• Collaboration: Integration of stakeholders in the project.
• API Integrations: Connects with other business software (ERP, BIM).
Limitations of Existing Solutions

• High Cost: Most solutions are paid and require costly subscriptions.
• Limited Customization: Some solutions do not allow adapting workflows to
specific business needs.
• Security & Digital Signatures: Few tools offer advanced digital signature
management for reports.
• Limited Modular Management: Few platforms use a microservices architecture,
which allows better flexibility and scalability.

1.3 Proposed Solution

5
A company operating in the construction project management sector must focus on
improving its processes to ensure deadlines, budgets, and quality standards are met. It is
essential to have modern and efficient tools to coordinate teams, track task progress, and
ensure effective communication between stakeholders. After a thorough analysis of the
limitations of current solutions, particularly monolithic tools, and in order to address the
growing needs for flexibility, scalability, and performance, the development team has
decided to migrate the application to microservice architecture.
This choice will enhance the application's performance, modularity, and maintainability,
while ensuring better collaboration among teams. By separating key functionalities such
as user management, deliverable tracking, schedule management, dashboards, and
timesheet recording, we will be able to ensure more efficient management and more
accurate project tracking. Each service will be designed to operate independently, allowing
for easier updates, version management, and continuous deployment.

In this context, our project involves developing a construction project management

application based on microservices architecture using modern technologies.

6
Differentiation and Added value of our Project :

1.4 Methodology adopted

To complete the project within the timeframe established by the internship agreement, it
was necessary to define the key steps and estimate the time required for each. To achieve
this, we adopted an agile development process. The goal of a development process is to
produce high-quality software that meets user needs within predictable timeframes and
costs.

The methodology we chose for this project is the Agile SCRUM method. SCRUM is the
most widely used of all agile methodologies. It has proven to be highly effective in project
development environments characterized by rapid changes and evolving requirements.

Figure 1.1: Percentages of Agile Methods Used

1.4.1 Introduction to SCRUM
SCRUM is an agile framework designed to address complex and changing problems
7
while delivering the highest possible value products in an iterative and productive
manner. It is an empirical process based on real-world experience and is supported by
three pillars: transparency, inspection, and adaptation. The principle of the SCRUM
methodology is to develop software incrementally, maintaining a completely transparent
list of requests for changes or corrections to be implemented. With frequent deliveries,
the client receives functional software at each iteration. As the project progresses, the
software becomes more complete and is equipped with increasingly advanced features.
1.4.2 Roles in SCRUM

SCRUM methodology defines three main roles:

• Product Owner:
In most projects, the Product Owner is the project client representative. They
define and prioritize the product's feature list and determine the date and content
of each sprint based on the workload values communicated by the team.
This role is typically held by a domain expert who specifies functional
requirements and establishes the priority of features to be developed.

• Scrum Master:
The Scrum Master acts as a project facilitator, ensuring that everyone works at
their full potential by removing obstacles and shielding the team from external
disturbances.
The Scrum Master ensures adherence to SCRUM principles, facilitates
communication within the team, and aims to improve productivity and the team's
skills.

• Development Team:
This is composed of professionals responsible for incrementally building the
product over a series of short time periods called sprints.

1.4.3 SCRUM Development Cycle

In this methodology, the project begins with Sprint 0, dedicated to all preparatory tasks
such as design and architecture, development environments, and tracking and integration
tools.
The requested features are listed and described as "User Stories" and added to the
Product Backlog.

• Sprint Planning:
This meeting marks the start of each sprint. The team gathers to determine which
user stories will be developed. These selected user stories form the Sprint
Backlog, and the sprint's objectives are set.

8
 • Daily Scrum:
Throughout the sprint, daily meetings (or Daily Scrums) are held, usually in the
morning, involving the whole team. These meetings last approximately 15
minutes to synchronize the team, ensuring everyone has the same level of
information.
At the end of the meeting, the team, along with the Scrum Master, confirms the
feasibility of meeting deadlines and completing the entire Sprint Backlog.
• Sprint Demonstration:
At the end of the sprint, the current state of the application is demonstrated to the
client. The client can interact with the application and ensure the developments
meet expectations. Comments and requests for modifications can be made,
which may or may not be included in the next sprint.

• Sprint Review:
On the last day of the sprint, a Sprint Review meeting is held. The team recalls
the objectives set, reviews the functionalities developed and delivered, and
discusses the sprint outcomes.

• Sprint Retrospective:
Finally, the project team meets for a Sprint Retrospective, where they list what
went well during the sprint and identify areas for improvement. An improvement
plan is established, and the next sprint begins immediately after.

The figure below illustrates the SCRUM lifecycle.

Figure 1.2: SCRUM Lifecycle

9
 Chapter 2

Sprint 0: Analysis and specification of needs

2.1 Needs Analysis ..............................................................................................

2.1.1 Identification of Stakeholders .........................................................

2.1.2 Functional Requirements ................................................................

2.1.3 Non-Functional Requirements .............................................................

2.2 Requirements Specification .....................................................................

2.2.1 Global Use Case Diagram .......................................................................

2.2.2 Product Backlog .........................................................................................

2.3 Architectural Specification ..........................................................................

2.3.1 Microservices Architecture ....................................................................

2.3.1.1 Characteristics of the Microservices Architecture.........................

2.3.1.2 Motivation for Using Microservices..................................................

2.3.1.3 Benefits of Microservices Architecture.....................................

2.3.2 Software Architecture....................................................................

2.3.2.1 Front-End Architecture....................................................................

2.3.2.2 Back-End Architecture ...............................................................

2.3.3 Physical Architecture....................................................................

2.4 Design Patterns ....................................................................

2.4.1 DAO: Data Access Object.....................................................................

2.4.2 DTO: Data Transfer Object ....................................................................

2.4.3 IOC: Inversion of Control........................................................................

2.5 Work Environment ..........................................................................................

2.5.1 Software Development Environments...................................................

3. onclusion.............................................................................................................

10
Introduction
This chapter represents our initial sprint, during which we will specify the requirements of
the various users. A study of both functional and non-functional requirements is necessary.
Next, we will present our product backlog and the planning of our sprints. Finally, we will
explain the proposed microservices architecture and the working environment.

2.1 Needs Analysis

2.1.1 Identification of Stakeholders

The stakeholders involved in the project include:

1. End Users: These are the primary users who will interact with the application, such
as project managers, team members, and clients.
2. Admin Users: Individuals responsible for managing the system, such as system
administrators or technical support teams.

3. External Systems: Systems that will interact with the application, like databases,
third-party APIs, or other enterprise software.

4. Project Managers: Those responsible for overseeing the project and ensuring that
timelines, budgets, and quality standards are met.

5. Developers and Designers: The technical team responsible for building,

maintaining, and enhancing the system.

2.1.2 Functional Requirements

1. User Management

o Manage user accounts, roles, and permissions.

o Secure authentication and profile management.

2. Financial Management

o Track budgets, invoices, and expenses.

o Generate financial reports and integrate with accounting systems.

3. Human Resources Management

o Manage leave requests, employee records, and time sheets.

o Assign tasks and handle performance reviews and employee claims.

4. Logistics Management
o Manage supplier orders, inventory, and procurement.

11
 o Track goods receipt and set stock alerts.

5. Inspection Management

o Schedule and track inspections.

o Generate reports and handle corrective actions.

6. Task Scheduling and Planning

o Create, assign, and track tasks.

o Use visual tools (Gantt charts, Kanban boards) for task management.
o Track time, allocate resources, and manage dependencies.

7. Reporting and Analytics: The system should generate reports on project

progress, budgets, and other key metrics.
2.1.3 Non-Functional Requirements

Non-functional requirements describe the system's quality attributes. These include:

1. Performance: The system should handle a large number of concurrent users and
process high volumes of data without performance degradation.

2. Scalability: The system should be able to scale up or down based on user load,
ensuring that additional resources can be allocated as needed.

3. Security: The system should implement strong authentication and authorization

mechanisms, as well as encryption for sensitive data.

2.2 Requirements Specification

2.2.1 Global Use Case Diagram

Use case diagrams are used to provide an overall view of the functional behavior
of a software system. They help collect, analyze, and organize requirements, as well as
identify the major functionalities of a system. This is the first UML step in system analysis.
It represents the interaction between a user (actor) and the system (use case) without
detailing how the system will execute the described functionalities. The global use case
diagram, shown in Figure 2.1, models the overall features provided by our application. We
will detail the implemented use cases in the following chapters.

12
 Figure 2.1: Overall use case diagram

2.2.2 Product Backlog

The “Product Backlog” is the central point of any Scrum project. It is an ordered
list of everything that could be required in the product and is the single source of
requirements for all changes to be made to the product.

In this section, we describe the product backlog of our project, illustrated by Table
2.1 below

13
14
2.3 Architectural Specification

2.3.1 Microservices Architecture

2.3.1.1 Characteristics of the Microservices Architecture

The microservices architecture divides the application into small, independent

services that can be developed, deployed, and maintained separately. Each
microservice focuses on a specific business function, such as user management,
logistics, Billing and Payment Management, recruitment, invoicing, HR, project
operations, mission management, quality control... These services communicate with
each other through APIs.

2.3.1.2 Motivation for Using Microservices

The main motivation for adopting microservices is to enhance scalability, flexibility, and
maintainability of the system. Each service can be independently scaled and updated,
improving development speed and reducing the risk of system-wide failures. Additionally,
microservices allow teams to work independently on different services, enabling faster
development cycles.

2.3.1.3 Benefits of Microservices Architecture

The benefits of microservices include:

• Scalability: Independent scaling of services based on demand.

• Resilience: A failure in one service does not affect the entire system.
• Flexibility: New features can be added without disrupting other services.
15
 • Faster Development: Smaller services can be developed, tested, and deployed
independently.
• Technology Agnostic: Different technologies can be used for different services.
• High Availability: Services can be replicated and distributed to ensure
uninterrupted access, even during partial failures.

2.3.2 Software Architecture

The software architecture is designed using the microservices pattern, where each
business function is a separate service. These services interact via RESTful APIs or
message queues for asynchronous communication. This allows for easy updates and
modifications to individual services.

2.3.2.1 Front-End Architecture

The front-end architecture is based on a modern web framework such as Angular,

which is integrated with a microservices-based back-end. It communicates with the
back-end via RESTful APIs, delivering a seamless user experience. The front-end
interacts with various independent microservices, handling the presentation of data and
user interaction for all modules, such as user login, task management, and quality
control.

2.3.2.2 Back-End Architecture

The back-end architecture is composed of various microservices deployed

independently. Each service manages a specific business domain, such as user
authentication, recruitment, or invoicing... The back-end communicates with a
centralized database, but each service can have its own storage, allowing for better data
management and security.

16
2.3.3 Physical Architecture

The physical architecture follows a 3-tier design, focusing on scalability and resilience.
The services are deployed in containers, which are managed using orchestration tools
like Kubernetes. The system is deployed on a cloud infrastructure, ensuring high
availability, fault tolerance, and separation of concerns across the presentation, business
logic, and data layers.

2.4 Design Patterns

2.4.1 DAO: Data Access Object

The Data Access Object pattern is used to separate the data access logic from the
business logic. It provides a clear interface for interacting with the database, improving
maintainability and flexibility.

2.4.2 DTO: Data Transfer Object

The Data Transfer Object pattern is used to transfer data between layers or systems.
DTOs are simple objects without business logic, designed to transport data efficiently.

2.4.3 IOC: Inversion of Control

Inversion of Control (IoC) is used to decouple the service layer from its dependencies,
making it easier to manage and test the system. IoC allows services to be injected with
their dependencies instead of creating them internally.

17
2.5 Work Environment

Throughout the development of our project, we have used specific hardware and
software, which we will present in the following sections.

2.5.1 Software Development Environments

The software tools we used to develop our application are as follows:

Spring Boot: Spring Boot is an open-source Java-based framework used to create
stand-alone, production-grade Spring applications. It simplifies the setup of Spring
applications by providing pre-configured templates for various features like web
development, security, and data access. Spring Boot aims to reduce the development
time and improve the deployment of applications.

Angular: Angular is a popular open-source web application framework developed by

Google. It is written in TypeScript and helps developers build dynamic, single-page
applications (SPAs) with a rich user interface. Angular provides tools for handling
routing, forms, HTTP client, and more, allowing developers to create modern,
maintainable web apps.

18
MySQL: MySQL is an open-source relational database management system (RDBMS)
based on Structured Query Language (SQL). It is widely used for storing, managing, and
retrieving structured data in various applications, ranging from small-scale projects to
large enterprise systems.

Git: Git is a distributed version control system that allows developers to track changes in
their codebase and collaborate efficiently. It helps manage multiple versions of a project,
enabling teams to work on different branches, merge changes, and revert to previous
versions when necessary. Git is widely used in software development to maintain code
integrity and enable seamless collaboration.

GitHub: GitHub is a web-based platform for version control and collaborative software
development. It uses Git, a distributed version control system, to track changes in code
and enables multiple developers to work together on a project. GitHub allows users to
store repositories, which can contain all the project files and history, collaborate via pull
requests, manage issues, and create branches for experimentation without affecting the
main codebase. It is widely used for open-source projects and personal software
development due to its powerful tools for collaboration, project management, and
integration with other development tools.

Docker: Docker is a platform used to automate the deployment, scaling, and

management of applications inside containers. A container is a lightweight, standalone,
and executable package that includes everything needed to run a piece of software,
such as the code, runtime, system tools, libraries, and settings. Docker allows
developers to build, ship, and run applications consistently across any environment,
whether it's on a local machine, a testing server, or a production system. It is particularly

19
useful for creating microservices-based architectures, as it simplifies the process of
deploying and managing these services independently in isolated environments.

3. Conclusion

The adoption of a microservices architecture offers scalability, flexibility, and resilience to

the project. The separation of concerns into smaller, manageable services enables
faster development cycles and independent service deployment. With modern
frameworks and technologies, the system is designed for high availability and ease of
maintenance, ensuring that the project can scale with future needs.

20
General Conclusion

In conclusion, this report has outlined the development process of a construction project
management application based on microservices architecture. By addressing the
growing complexity and demands of the construction sector, our approach focuses on
providing a modular and flexible solution that enhances collaboration, improves task
management, and ensures effective tracking of project progress. The application
leverages microservices to break down key functionalities into independent, scalable
services that can be easily updated or replaced without affecting the entire system.

The methodology adopted, particularly the Agile SCRUM process, facilitated an iterative
development approach that allowed for continuous improvements and real-time
stakeholder feedback. The implementation of both functional and non-functional
requirements ensured that the system can handle the challenges posed by large-scale
construction projects, such as data management, task scheduling, and team
coordination.

Overall, the adoption of microservices architecture offers significant advantages,

including improved modularity, scalability, and maintainability. These features contribute
to a more efficient and adaptable project management tool that can evolve alongside the
ever-changing needs of the construction industry. Moving forward, the application’s
capabilities can be expanded further, allowing it to accommodate future requirements,
integrate with new technologies, and provide even more value to its users. This report
demonstrates how a modern, microservices-based approach can transform construction
project management and overcome the limitations of traditional tools.

21