PFE .NET CRM

République Tunisienne
Ministère de l’Enseignement Supérieur et de la
Recherche Scientifique
Direction Générale des Etudes Technologiques
ISET de Rades
Département Technologies de l’Informatique
‫التونسية‬ ‫الجمهورية‬
‫العالي‬ ‫التعليم‬ ‫وزارة‬‫العلمي‬ ‫والبحث‬
‫للدراسات‬ ‫العامة‬ ‫اإلدارة‬‫التكنولوجية‬
‫ب‬ ‫التكنولوجية‬ ‫للدراسات‬ ‫العالي‬ ‫المعهد‬‫رادس‬
‫قســم‬‫تكنولوجيات‬‫اإلعالمية‬
Adresse : Rue El Quods, BP 172 - 2098 - Radès
Téléphone : 71 460 100 Fax : 71 442 322
Site Web : www.isetr.rnu.tn
:‫العنوان‬‫نهج‬‫القدس‬‫ص.ب‬ ،-172-2098-‫رادس‬
:‫الهاتف‬71 460 100:‫الفاكس‬71 442 322
www.isetr.rnu.tn :‫الواب‬ ‫موقع‬
Rapport de Projet de Fin d'Etudes
LICENCE APPLIQUEE EN TECHNOLOGIES DE L'INFORMATIQUE
PARCOURS: DEVELOPPEMENT DES SYSTEMES D’INFORMATIONS (DSI)
Entreprise:
SINORFI
Plateforme WEB pour la Gestion de la Relation Client
Code PFE : DSI-18-17 Année universitaire : 2017/2018
Encadré par:
Encadreur(s) entreprise: M. Mohamed
Tawfik WERFELLI
Encadreur(s) ISET: M. Riadh GHLALA
Réalisé par:
Rym DAKHLI

Tunisian republic
Ministry of Higher Education and Scientific
Research
General Directorate of Technological Studies
ISET of Rades
Department of Computer Technologies
‫التونسية‬ ‫الجمهورية‬
‫العالي‬ ‫التعليم‬ ‫وزارة‬‫العلمي‬ ‫والبحث‬
‫التكنولوجية‬ ‫للدراسات‬ ‫العامة‬ ‫اإلدارة‬
‫ب‬ ‫التكنولوجية‬ ‫للدراسات‬ ‫العالي‬ ‫المعهد‬‫رادس‬
‫قســم‬‫تكنولوجيات‬‫اإلعالمية‬
Address: El Quods Street, BP 172 - 2098 - Radès
Telephone: 71 460 100 Fax: 71 442 322
Website: www.isetr.rnu.tn
:‫العنوان‬‫نهج‬‫القدس‬‫ص.ب‬ ،-172-2098-‫رادس‬
:‫الهاتف‬71 460 100:‫الفاكس‬71 442 322
www.isetr.rnu.tn :‫الواب‬ ‫موقع‬
Graduation Project’s Report
Applied license in computer technologies
Branch: DEVELOPMENT OF INFORMATION SYSTEMS (DSI)
Host Organization:
SINORFI
WEB Platform of Customer Relationship Management
Supervised By:
SINORFI’s Supervisor: Mr. Mohamed
Tawfik WERFELLI
ISET’s Supervisor: Mr. Riadh GHLALA
PFE Code: DSI-18-17 Academic Year: 2017/2018
Realized By:
Rym DAKHLI

DEDICATION
It is with great pleasure that I dedicate this work.
To my mother and my father, for their support, the encouragement they
have always given me and especially the sacrifices they made so that I could
succeed in my studies.
To my siblings, for their affection and their love. I wish you joy, and success.
To my friends, for all those enjoyable moments we shared together.
Rym DAKHLI

ACKNOWLEDGEMENT
At the end of this work, we would like to thank everyone who without them
this project would never be completed.
Our thanks are especially to:
Mr. Ahmed JOUINI, owner of SINORFI, for giving us the honor to work within
his team.
Mr. Mohamed Tawfik WEFELLI, who did lead me throughout my internship. His
modesty and his kindness is matched only by his great professional qualities.
I also particularly thank Mr. Riadh GHLALA for accepting to supervise my
work throughout this project. His availability and his valuable advices have
greatly helped me to complete this project.
I express my sincere thanks to all the team of SINORFI.
Our most distinguished expressions, for all those who have contributed near
or far to the accomplishment of this project.

LIST OF CONTENTS
Contents
General Introduction...............................................................................................................................1
1.Project's Frame ....................................................................................................................................2
1.1. Introduction .................................................................................................................................2
1.2. SINORFI and its services...............................................................................................................2
1.2.1. SINORFI's services .................................................................................................................2
1.2.2. SINORFI's products................................................................................................................2
1.3. Purpose behind the Project .........................................................................................................3
1.4. State of the art.............................................................................................................................3
1.4.1. Customer Relationship Management (CRM)........................................................................3
1.4.2. Cloud Computing ..................................................................................................................4
1.4.2.1. Features .........................................................................................................................4
1.4.2.2. Types..............................................................................................................................5
1.5. Project’s adopted Methodology:.................................................................................................6
1.5.1. Agile methods .......................................................................................................................6
1.5.2. Agile methodologies comparison .........................................................................................6
1.5.3. The choice of Scrum methodology .......................................................................................7
1.5.3.1. Scrum roles: ...................................................................................................................7
1.5.3.2. Scrum artifacts:..............................................................................................................7
1.5.3.3. Scrum formal inspection:...............................................................................................7
1.5.3.5. The paradox in scrum: Sprint zero philosophy: .............................................................8
1.5.4. Scrum roles ...........................................................................................................................8
1.6. Conclusion....................................................................................................................................8
2. Sprint zero:..........................................................................................................................................9
2.1. Introduction .................................................................................................................................9
2.2. SRS: software requirements specification (IEEE830 standard)....................................................9
2.2.1. Introduction ..........................................................................................................................9
2.2.1.1. Purpose ..........................................................................................................................9
2.2.1.2. Scope..............................................................................................................................9
2.2.2. Acronyms, definitions and references..................................................................................9
2.2.2.1. Acronyms .......................................................................................................................9
2.2.2.2. Definitions....................................................................................................................10
2.2.2.3. References ...................................................................................................................10
2.2.3. General description.............................................................................................................10

2.2.3.1. System functionalities..................................................................................................10
2.2.3.2. Actors identification.....................................................................................................11
2.2.3.3. Constraints...................................................................................................................11
2.2.3.4. Hypotheses ..................................................................................................................11
2.2.4. Minimal design up front......................................................................................................11
2.2.4.1. Functional View............................................................................................................13
2.2.4.2. Structural View.............................................................................................................15
2.3. Product Backlog .........................................................................................................................19
2.4. Technical choice.........................................................................................................................20
2.5. Conclusion..................................................................................................................................20
4. Sprint1: Accounts management........................................................................................................21
3.1. Sprint Planning...........................................................................................................................21
3.1.1. Sprint backlog......................................................................................................................22
3.2. Daily Scrum ................................................................................................................................23
3.2.1. Analysis ...............................................................................................................................23
3.2.1.1. Use Case.......................................................................................................................23
3.2.1.2. Use case briefs .............................................................................................................23
3.2.2. Design..................................................................................................................................24
3.2.2.1. Class Diagram: Accounts management........................................................................24
3.2.2.2. Authentication sequence Diagram ..............................................................................25
3.2.2.3. Account creation sequence diagram ...........................................................................26
3.2.3. Implementation ..................................................................................................................27
3.2.4. Test......................................................................................................................................27
3.3. Sprint review..............................................................................................................................28
3.4. Sprint retrospective ...................................................................................................................28
5. Sprint2: Ticketing System..................................................................................................................29
4.1. Sprint Planning...........................................................................................................................29
4.1.1. Sprint backlog......................................................................................................................29
4.2. Daily Scrum ................................................................................................................................31
4.2.1. Analysis ...............................................................................................................................31
4.2.1.1 Use Case........................................................................................................................31
4.2.1.2 Use Case briefs..............................................................................................................32
4.2.2. Design..................................................................................................................................32
4.2.2.1. Class Diagram: Ticketing system..................................................................................32
4.2.2.2. delete trouble ticket sequence diagram......................................................................33
4.3. Sprint Review .............................................................................................................................35

General Conclusion and perspectives...................................................................................................36
Bibliography and Netography...............................................................................................................37
Appendix A: Scrum................................................................................................................................38
Appendix B: Academic meeting (procès-verbal PV) .............................................................................43
Appendix C: Sprint1 planning................................................................................................................44
Appendix D: Daily Scum meeting..........................................................................................................47
Appendix E: Sprint 1 Review .................................................................................................................48
Appendix F: Prioritize Your Agile Stories...............................................................................................49

LIST OF FIGURES
Figure 1: CRM types [3]...........................................................................................................................3
Figure 2: Cloud Computing system [4]....................................................................................................4
Figure 3: Cloud computing types [6].......................................................................................................5
Figure 4: The Scrum flow representation [11]........................................................................................8
Figure 5: Context diagram.....................................................................................................................13
Figure 6: Global use case diagram ........................................................................................................14
Figure 7: Global class Diagram..............................................................................................................15
Figure 8: Global Component Diagram ..................................................................................................16
Figure 9: Deployment diagram .............................................................................................................18
Figure 10: Product backlog screenshot VSTS........................................................................................20
Figure 11: Use Case Sprint1 ..................................................................................................................23
Figure 12: Class Diagram sprint1...........................................................................................................24
Figure 13: Authentication Sequence Diagram......................................................................................25
Figure 14: Account creation sequence diagram ...................................................................................26
Figure 15: Admin Interface code Screenshot........................................................................................27
Figure 16: test Registration interface ...................................................................................................27
Figure 17: Use Case sprint2: Ticketing system......................................................................................31
Figure 18: class diagram sprint2 ...........................................................................................................33
Figure 19: delete trouble ticket sequence diagram..............................................................................34

LIST OF TABLES
Table 1: Agile methodologies comparison..............................................................................................6
Table 2: Scrum roles................................................................................................................................8
Table 3: Table of acronyms.....................................................................................................................9
Table 4: Table of definitions..................................................................................................................10
Table 5: Groups of diagrams in UML.....................................................................................................12
Table 6: Product backlog.......................................................................................................................19
Table 7: Sprint Backlog..........................................................................................................................22
Table 8: Use Case Briefs, Sprint1: Update Profile.................................................................................23
Table 9: Sprint2 backlog: ticketing system ...........................................................................................30
Table 10: Use Case Briefs, Sprint2: Delete non-processed ticket.........................................................32
Table 11: Use Case Briefs, Sprint2: Process ticket ................................................................................32

1
General Introduction
During the Middle Ages, traders and craftsmen, have tried to take care of their customers. Thus, a
blacksmith or a baker had to offer the best service to his client to make sure to enhance the image of
its business also to keep it as a loyal client.
More recently, during the 50's or 60's, the customer could wait for months or even years for a product
ordered! In fact, companies generally had a "monopoly" in their sector of activity and exercised a
game of domination over their customers.
During the 1990s, the situation changed with the opening of trade to "competition" and the customer
became king. Therefore, Companies understand that taking care of their customers is essential to the
risk of a reduction in sales and getting a tarnished image.
Therefore, the customer has the choice. It should not be considered as passive, subjected to the
pressure of suppliers anymore, but as an actor who chooses knowingly.
The balance of power customer - supplier seems to rebalance to his advantage, and for the company,
there are no more customers acquired for life.
So, to insure its progress and positive income, companies today opted to new solutions so they can
better manage their relationship with their customers and partners such as the example of Customer
Relationship Management (CRM). CRMs were created to facilitate the communication between a
client and the company that provides him with several services.
Hence, this is what my graduation project looks into. We will start working on the most important
modules and carrying on until it covers the needs, this report will take you in a discovery of the
modules that I have realized since my internship began, it won't be so typical so that I'm not
implementing a classical process.
These modules are: an operational CRM module and analytical CRM module. They will be developed
within Microsoft .Net technology using several other technologies such as the Bootstrap framework.
To do this, we conduct a theoretical study to better understand the context of our project.
Our report will be divided into project's frame where we introduce the host organization, the subject
of our project and the project's adopted methodology, passing to the details of every sprint.

1.Project's Frame
2
1.Project's Frame
1.1. Introduction
In this chapter, we will present the general frame of our project, namely the host company which
proposed and accommodated this project, it's purpose, then a preliminary study is in order ,that will
help understand the project's status on the market and we will end up by detailing the work
methodology adopted to accomplish a better results.
1.2. SINORFI and its services
SINORFI stands for (Société d'INgénierie d'ORganisation Financiere et Industrie), or Financial and
industry engineering company.
SINORFI covers all the management consulting services, from the definition of the strategy to the
complete implementation of the solutions.
SINORFI and its professionals work closely with their customers to make them jump in competitiveness
and be at the service of their performance.
SINORFI is specialized in consulting, integration of solutions and information systems.
SINORFI creates value for its customers by mobilizing its teams around the major transformations of
companies. Performance improvement, change management and the integration of new technologies
represent so many projects for which SINORFI brings the best solutions to the challenges of its
customers. [1]
1.2.1. SINORFI's services
[1]
Customer Relationship Management (CRM)
Improving operating performance
Assets and services management
Enterprise Resource Planning (ERP)
Energy management
1.2.2. SINORFI's products
[1]
IBM Tivoli
IBM Maximo
Sage
Oracle
Siemens SIMATIC
Siemens Maintegrity

1.Project's Frame
3
1.3. Purpose behind the Project
As part of its business, the SINORFI deals basically with handling the incidents of the various
customers, the management products and the loyalty of their customers.
To do so, it does receive phones calls and even huge flow of e-mails, it engenders the risk of ignoring
some important incidents, or a customer loss, also that makes the work difficult and exhaustive.
SINORFI for that needs an application that solves these problems and to better understand the
principle of the relationship management points, it is necessary to define some basic concepts that
we present in the following section.
1.4. State of the art
1.4.1. Customer Relationship Management (CRM)
Customer Relationship Management is a set of practices, strategies and technologies used by
businesses to manage and analyze customer interactions and data, and a marketing approach to
building close relationships with customers and prospects to encourage them to focus on a strong
share of their purchase and incidents.
Currently: Buy or develop? [2]
The question that most companies ask is; which CRM software should I choose? In fact, there are so
many CRMs; The following table briefly explains the particularities of the dominant CRMs in the
market:
Software feature
Salesforce Sales Cloud Focused on innovation (social CRM and big data)
Sugar CRM Open Source and customizable
Microsoft Dynamics CRM Integrated to the Office Suite
Oracle Siebel CRM Very complete with a sales prediction tool
Each one of them is great, but each is missing something that you certainly need, the question that
must arise is why we need CRM?
So you better consider the context of your company’s business while highlighting Dominant
characteristics of CRM that you need.
Figure 1: CRM types [3]

1.Project's Frame
4
While CRMs in the previous products is collaborative (social), analytical or/and operational that deals
with automations and smart scripts, SINORFI only needs:
•Operational CRM that focuses on customer service and after sales service.
•Analytical CRM that focuses on analyzing customer-related data for strategic or tactical purposes.
SINORFI can't afford the expenses of buying one of the previous CRM products and it doesn’t choose
an open source one that it doesn't want to handle any updates problems.
And since it is a company in the process of development it chooses to develop a CRM from scratch
that will grow with its needs.
1.4.2. Cloud Computing
While Cloud computing is a paradigm that enables real time access to shared and configurable system
resources and higher-level services that can be rapidly provisioned with minimal management effort,
often over the Internet. SINORFI chooses to deploy it's CRM product on Microsoft Azure Cloud service.
Figure 2: Cloud Computing system [4]
1.4.2.1. Features
The National Institute of Standards and Technology (NIST) provide a very precise definition of the
different elements that characterize the cloud: "This model promotes availability and includes five
main features: [5]
• Free on-demand service.
• Extended access to the network.
• Pooling of resources.
• Elasticity / scaling fast.
• Pay by use.

1.Project's Frame
5
1.4.2.2. Types
The three model layers of IT-as-a-Service were introduced by NIST standards; [5]
1. SaaS: Software as a Service, the provider maintains the applications used by the client in a
completely transparent way. Example we could find Google applications (doc, reader, Gmail„
etc.) also Salesforce CRM, etc.
2. PaaS: Platform as a Service, the client only maintains its applications while the supplier
maintains the servers and the software infrastructure (Databases, application’s behavior in
the client side, security, and storage). It provides computational resources via a platform upon
which applications and services can be developed and hosted. example: Google App Engine,
Microsoft Azure Cloud, OpenShift (Redhat).
3. IaaS: Infrastructure as a Service. It provides resources are composed of virtualized
infrastructure which is mostly located in a remote Datacenters. Examples: SQL Azure.
Everyone loves Pizza, right! So the best way to understand this is to compare it to the famous
Pizza-As-a-Service.
Figure 3: Cloud computing types [6]
SINORFI focuses on the specific form of cloud: PaaS. Since it will have only access to the application and its
data (database, etc..), PaaS is the suitable form of implementation that it will be handling the presentation
and the data layers of the application once it is deployed to the cloud.

1.Project's Frame
6
1.5. Project’s adopted Methodology:
The adoption of a development methodology is a must to ensure an acceptable level of quality and to
avoid missing deadlines.
1.5.1. Agile methods
An agile method is an iterative and incremental approach to software development, which produce,
within a constrained time, high quality software aims to meet the changing needs of users. The goal
of an agile method is to maximize the added value. The development is carried out by successive
iterations, it is possible, at the end of each iteration, to change priorities by ensuring that the elements
bringing the most value are realized first.
The principles of the Agile Manifesto are: [7]
• Satisfy the customer by delivering early and regularly useful software.
• Accept changes even late in development.
• Frequently deliver an application that works.
• Collaborate daily between customers and developers.
1.5.2. Agile methodologies comparison
In this section, we will try to identify the differences between some of the best known agile
development methods. The following table briefly compares agile methods, including: [8]
• Extreme Programming (XP).
• Rational Unified Process (RUP). [9]
• Scrum.
• Feature-Driven Development (FDD).
Table 1: Agile methodologies comparison
method Advantage Disadvantages
XP • Customer-driven development
• Reduced teams, focused on
developers in pairs.
• Built daily, continuous
improvement, adaptive to changes.
• Emphasize individual development the cost
of the general direction practices or
formalization.
• Risk of lack of control and structure,
leaving developers free to drift away from
the functions of the application.
RUP • The whole process helped with
tools.
• Well defined roles.
• Heavy, widely spread, it can be
difficult to implement in a specific way.
• Suitable for large projects that generate
a lot of documentation.
Scrum •mixed teams.
•30-day Iterations.
• Daily meetings.
• Implementation of the development
is not specified, taking considerations of
human resources management.
FDD •Well-defined and simple
process and very short
iterations
• Only focused on development.

1.Project's Frame
7
1.5.3. The choice of Scrum methodology
Scrum uses an iterative and incremental approach that aims to maximize predictability. [10]
1.5.3.1. Scrum roles:
The Scrum team has three roles: [10]
1. The Product Owner is the one that has the idea that is going to be turning to a project.
2. The SCRUM Master acts as the team's leader in helping the team and the organization make
the best use of Scrum.
3. The Development Team is made up of professionals who work to make the product
incrementally with a series of short periods of time called Sprints.
1.5.3.2. Scrum artifacts:
Scrum proposes the creation of three essential artifacts: [10]
1. The Product Backlog is an ordered list of ideas for the product, which is maintained in the
expected production order.
2. The Sprint Backlog is the detailed development plan for the next Sprint.
3. The Burndown chart.
1.5.3.3. Scrum formal inspection:
Scrum prescribes four formal inspection and adaptation opportunities: [10]
1. Sprint Planning is a boxed meeting that triggers each sprint. During this meeting, the Scrum
team collaborates to select and understand the work to be done in the upcoming Sprint.
2. The Daily Scrum is a meeting that takes place at the same places and at the same time every
day. It is used by the development team to ensure that it is appropriate for the situation to
achieve the Sprint goal.
3. The Sprint Review (Sprint Review) is an hour-long boxing meeting where the Scrum team and
stakeholders review the Sprint result.
4. The Sprint Retrospective is a meeting that closes every sprint to examine how things went
about the process, relationships between people, and tools.
The following schema is a recap of the Scrum flow highlighting its roles, artifacts and inspections.

1.Project's Frame
8
Figure 4: The Scrum flow representation [11]
1.5.3.5. The paradox in scrum: Sprint zero philosophy:
In the lifecycle of every project we need an inception or a starting point to include everything we need
to work on it, from the people to the processes. And it is a much smoother step to getting started than
to get lost in further steps.
For this previous reason, and to make scrum more practical, a special sprint set up, called Sprint zero,
and we also call it iteration zero or inception sprint.
What inception sprint should be?
Sprint Zero should be used to create the basic skeleton for the project so that future sprints can truly
add incremental value in an efficient way; It is used to prepare the necessary documents or delimiting
teams and their roles also for installing an appropriate environment for work.
In our case; specify the software requirements, prepare the product backlog then plan for the
upcoming typical sprints. [12]
1.5.4. Scrum roles
As we mentioned at first that we are going to adopt scrum methodology, we should first make sure
that the roles are well distributed until we can start working.
Table 2: Scrum roles
Scrum role FirstName & Last Name role
Product owner Ahmed JOUINI Define the functionalities to be build
Scrum Master Mohamed Tawfik WERFELLI Does anything possible to help the
team perform at their highest level
Development team Rym DAKHLI Requirements, design, development
1.6. Conclusion
In this chapter, we present our project and the motivations that drive us to develop a CRM from
scratch while introducing the host organization SINORFI.
After discussing new technologies and choosing Scrum framework, which will manipulate the life-
cycle of the Software product, we will run into sprints.

2. Sprint zero:
9
2. Sprint zero:
2.1. Introduction
this chapter is an inception for our project it includes the requirements of our software, that goes with
IEEE 830 standard for software requirements specifications and the backlog of the product and a spike
clarification for the upcoming sprints. [13]
2.2. SRS: software requirements specification (IEEE830 standard)
The main idea of this specification standard is that it deals with agile methodology; it can be
modified all along the project in contrast with the older waterfall life cycles. So, it is an agile spec!
Placing this chapter here does not refer that it was done first, it was iteratively approached all along
the project!
2.2.1. Introduction
2.2.1.1. Purpose
This document fully describes the expected behavior of our software system; collect and analyze all
assorted ideas that have come up to define the system, its requirements with respect to consumers.
And provide a detailed overview of our software product, its parameters and goals all along the
project's life cycle.
It is intended for both the stakeholders and the developers of the system.
2.2.1.2. Scope
Our job is to develop a web and BI platform for customer relationship management to manage their
needs and provides the managers with a snapshot of company performance and the various functions
in one place. It is designed to reduce time-consuming tasks, increase sales and customer loyalty care.
More specifically, this system is designed to allow the users to better solve problems with a trouble ticket
module and a BI module that helps the manager with decision making.
It will be provided with a relational database and deployed on azure cloud service.
2.2.2. Acronyms, definitions and references
2.2.2.1. Acronyms
Table 3: Table of acronyms
Acronym Stands for
CRM Customer Relationship Management
ERP Enterprise Resource Planning
SINORFI Société d'INgénieurie d'ORganisation Financiere et Industrie
NIST National Institute of Standards and Technology
VSTS Visual Studio Team Services
UML Unified Modeling Language
HTTP HyperText Transfer Protocol
WCF Windows Communication Foundation
ODBC Open Database Connectivity

2. Sprint zero:
10
2.2.2.2. Definitions
Table 4: Table of definitions
Term definition
CRM is a term that refers to practices, strategies and technologies that
companies use to manage and analyze customer interactions and data
NIST is one of USA’s oldest physical science laboratories.
WCF framework for building service-oriented applications
ODBC standard application programming interface (API) for accessing
database management systems
HTTP is the underlying protocol used by the World Wide Web and this
protocol defines how messages are formatted and transmitted.
2.2.2.3. References
This document is officially declared at:
IEEE. IEEE Std 830-1998 IEEE Recommended Practice for Software Requirements Specifications. IEEE
Computer Society, 1998.
2.2.3. General description
2.2.3.1. System functionalities
The system can be divided into analytical and operational CRM;
o Operational CRM
Ticketing system
Sales management
o Analytical CRM
Dashboards and reporting
2.2.3.1.1. Functional requirements:
Our application must provide the features which are going to be specified in this section. The
processes to be implemented are:
• All Customers should be able to create a trouble ticket and keep informed by its status.
• Dashboards need to be useful, understandable and up-to-date as well as the reports.
• The Help desk and should be able to treat every single trouble ticket
• Customers should be able to modify their accounts.
• The manager should be able to manage the products.
• The customer should see the products
• The administrator should have access to all information around the system.
2.2.3.1.2. Non-Functional requirements:
This application must satisfy a series of non-functional requirements such as:
• Security: the system needs to control the users access and session (encrypted data).
• Performance: velocity of response time especially for data access.
• Maintainability: well commented source code.
• Data Integrity: Information should be provided by the CRM Platform on the Cloud.

2. Sprint zero:
11
2.2.3.2. Actors identification
Administrator
o manage all accounts
o auditing of the system
o feedback management
Helpdesk
o Treats the trouble tickets.
Manager:
o Treats the trouble tickets.
o Product management.
Customer:
o Create incident tickets
o Send feedback.
2.2.3.3. Constraints
We have no constraints.
2.2.3.4. Hypotheses
This system is supposed to work on Azure cloud server, user can connect after having their accounts
from administration, the back-office should be responsive to any user requirements and should be
executive from any machine that supports an internet browser.
2.2.4. Minimal design up front
For the modeling of the system we will adopt a set of Unified Modeling Language UML diagrams.
The current UML standards call for thirteen different types of diagrams: class, activity, object, use
case, sequence, package, state, component, communication, composite structure, interaction
overview, timing, and deployment.
These diagrams are organized into three distinct groups:
1. Structural diagrams
2. Behavioral diagrams
3. Functional diagrams
The following table 4 represents the interest of those three groups, the specifications and focus of
each group and its description, and the associated UML diagrams.

2. Sprint zero:
12
Table 5: Groups of diagrams in UML
Group Description Focus UML diagrams
Functional
View
The functionality of the software
as its roles in the business
process and its interaction with
the user and the environment.
How the system works
from the external
point of view.
Use case diagram
Activity diagram
Structural
View
The structure of the data that
supports the business process in
an organization and their
representation and process in the
software.
The logic organization
of data at technical
details such as how
the data are stored,
created or
manipulated in design
and implementation.
Object diagram
Class diagram
Package diagram
Deployment diagram
Component diagram
Behavioral
View
The internal dynamic aspects
that supports the business
processes in an organization.
The internal logic of
processes and how
the processes are
implemented
Sequence diagram
Communication
diagram
Behavioral diagram
State diagram
In the upcoming stage we will do as a first modeling iteration;
The context diagram and the system use case that will help understanding an external global view of
how our system is going to be as Functional view. The component diagram and the component
diagram to see better the physical and logical architecture of the system and facilitate the upcoming
work as Structural view.
We will be leaving a detailed use case as well as functional view.
Class diagram and sequence diagram Structural and behavioral respectively.

2. Sprint zero:
13
2.2.4.1. Functional View
2.2.4.1.1. System context diagram
This diagram is not mentioned with the thirteen official diagrams of UML, it considers the system as a
black box to highlight its external relationships, and the maximum number of instances of each actor
connected to the system at a given point in time. [14]
A system context diagram (SCD) is a diagram that defines the boundary between the system, or part
of a system, and its environment, showing the entities that interact with it. This diagram is a high-level
view of a system. It is similar to a block diagram.
This diagram is called a top-level use-case diagram, but as it’s very similar to a type of diagram that
predates UML; it often called: context diagram. This type of diagram, shown in Figure 6, displays the
system of interest and all its actors—but it hides the use cases themselves.
The SCD takes place right after actor’s identification and before the use cases.
Figure 5: Context diagram

2. Sprint zero:
14
2.2.4.1.2. Use Case Global view
The use case diagram is the primary form of system requirements for a new software program under
development. Use cases specify the expected behavior (what). It summarizes some of the
relationships between use cases and actors as represents the following Figure 7.
Figure 6: Global use case diagram

2. Sprint zero:
15
2.2.4.2. Structural View
The following Figure represents the global class diagram and shows the set of classes we’re needing
in the project and their interrelationships.
Figure 7: Global class Diagram
In this section, the architecture of the CRM System is described in more detail using UML 2,
Component diagram.
It will represent an overview of the structure of the system which introduces single parts, like
interfaces and connections between them to show the structure the single components beginning
with the topmost, namely the component CRM and going on with the inner, more detailed
components are beheld and respectively their instance number indicated on the upper left of each
component.
It is organized as a layered architecture these layers are web, Business Logic, Data access and the Data
store or database.

2. Sprint zero:
16
Figure 8: Global Component Diagram
The Figure 8 represents eventually the Global Component diagram that shows the dependencies and
interactions between software components. A component is the container of logical elements and
represents things that participate in the execution of a system.
For each instance of CRM exists only one instance of the component Database where all data is stored.
The component Data representing the data Access layer of a classical three-layer-architecture hides
details of the database and provides data access to the application layer represented by the
component Business Logic.
The communication between the components Data Store and Data Access is managed by ODBC as an
implementation of .NET Persistence API with the persistence framework Entity Framework.
Each of the components Data Access and Business Logic provides generic interfaces to communicate
with Business Logic and Web respectively;

2. Sprint zero:
17
IPersistance boundary includes each of the interfaces:
• IUserRepository
• ITicketRepository
• IProductRepository
IBusiness boundary includes each of the interfaces:
• IUserService
• ITicketService
• IProductService
While the Component diagram deals with layered architecture, down below Deployment diagram will
highlight the physical tiers architecture.
The following Figure 9 represents the Structural deployment diagram that shows the architecture of
the system as distribution of software artifacts to deployment targets.
Deployment target is usually represented by a node which is either hardware device or some software
execution environment (web browser, web server and data server).
Nodes could be connected through communication paths to create networked systems of arbitrary
complexity (HTTP and ODBC).

2. Sprint zero:
18
Figure 9: Deployment diagram

2. Sprint zero:
19
2.3. Product Backlog
The agile product backlog in Scrum is a prioritized features list containing short descriptions of all
functionalities desired in the product. When applying Scrum, it is not necessary to start the project
with a completed documentation of all requirements. The Scrum product backlog is then allowed to
grow and change as more is learned about the product and its customers.
Table 6: Product backlog
Sprint Sprints
Priorities
ID
User Story
User Stories
Priorities
Account
s
manage
ment
25 1 as an administrator I want to be able to create
accounts and roles
25
2 as an administrator I want to be able to block
accounts
5
3 as an administrator I want to be able to
reactive accounts
5
4 as an administrator I want to be able to read all
the accounts
12
5 as a customer I want to be able to update my
profile
5
6 as a helpdesk I want to be able to update my
profile
5
7 as a manager I want to be able to update my
profile
5
Ticketin
g system
25 8 as a customer I want to be able to create tickets 25
9 as a customer I want to be able to read the
state of the tickets that I created
25
10 as a customer I want to be able to delete my
ticket not yet treated
12
11 as a helpdesk I want to be able to read all
tickets and owner profiles
20
12 as a helpdesk I want to be able to update
tickets
25
13 as a manager I want to be able to read all the
tickets and the profile of the owners
12
14 as a manager I want to be able to update tickets 12
Product
manage
ment
12 15 as a customer I want to be able to read
products
20
16 as a manager I want to be able to create
products
25
17 as a manager I want to be able to update a
product
20
18 as a manager I want to be able to delete a
product
5
Analytic
al
manage
ment
- 19
as a customer I want to be able to send a
feedback of satisfaction
-
PS: descending priority order.

2. Sprint zero:
20
The project management tool used to organize the work and especially share it, is
VisualStudioTeamService.
Figure 10: Product backlog screenshot VSTS
2.4. Technical choice
• Visual Studio: Integrated Development Environment
• SQL Server: Relational database server
• Visual Studio Team Service: Git and project management tool
• ASP.NET MVC5(.NET framework): It is a runtime execution environment it contains the
Common Language Runtime (CLR), the base class libraries and other managed libraries.
[15]
• C#: Object Oriented programming language chosen to code the .NET application. [15]
• ASP.NET identity: Framework that includes authentication, works with Open Web Interface
for .NET (OWIN), and included with the ASP.NET. [15]
• Entity Framework: is an object-relational mapper that enables .NET developers to work
with relational data using domain-specific objects. It eliminates the need for most of
the data-access code that developers usually need to write. [15]
• Bootstrap Framework: Bootstrap is the most popular HTML, CSS, and JavaScript
framework for developing responsive, mobile-first websites. Bootstrap is completely
free to download and use. [16]
2.5. Conclusion
This was the sprint zero that handled the Software Requirements Specifications document that will
have iterations and incrementations all along the project, the First Scrum artifact; product backlog,
scrum roles and a global view about the system and the sprints.
The upcoming parts will be Sprints containing its artifacts ceremonies and other disciplines.

4. Sprint1: Accounts management
21
Plan
4. Sprint1: Accounts management........................................................................................................21
3.1. Sprint Planning...........................................................................................................................21
3.1.1. Sprint backlog......................................................................................................................22
3.2. Daily Scrum ................................................................................................................................23
3.2.1. Analysis ...............................................................................................................................23
3.2.1.1. Use Case.......................................................................................................................23
3.2.1.2. Use case briefs .............................................................................................................23
3.2.2. Design..................................................................................................................................24
3.2.2.1. Class Diagram: Accounts management........................................................................24
3.2.2.2. Authentication sequence Diagram ..............................................................................25
3.2.2.3. Account creation sequence diagram ...........................................................................26
3.2.3. Implementation ..................................................................................................................27
3.2.4. Test......................................................................................................................................27
3.3. Sprint review..............................................................................................................................28
3.1. Sprint Planning
As far as we already have our product backlog, this inspection had place in 28/03/2018 and lasted for
two hours, and where we decided to complete a set of product backlog items.
This agreement has defined the sprint backlog based on the team’s velocity or capacity and the length
of the sprint.

22
3.1.1. Sprint backlog
During the Sprint Planning inspection, we selected few items from the product backlog, delimited the
user stories and necessary tasks to accomplish each of them. Down below the table representing
Sprint backlog tasks and estimation in days of each task.
Table 7: Sprint Backlog
Id User Story Id task Tasks Estimation Priority
1 as an administrator I want to
be able to create accounts and
roles
1 Integrate interfaces 3 12
2 Implement create user
method
4 25
3 Implement method
to assign role
3 20
be able to block accounts
4 Conceive and implement
the method to block
account
3 12
be able to reactive accounts
5 Implement the method to
reactive blocked accounts
3 12
6 test block and reactive
accounts
3 5
be able to read all the accounts
7 Conceive the interface
to display accounts
3 12
display
3 12
9 Test the functionality 2 12
5 as a customer I want to be able
to update my profile
to display profile
3 5
11 Implement the method
and interface to display
the users profile
4 5
12 Test 2 5
6 as a helpdesk I want to be able
to display profile
3 5
the users profile
4 5
15 Test 2 5
7 as a manager I want to be able
to display profile
3 5
the users profile
4 5
18 Test 2 5

23
3.2. Daily Scrum
All along the Sprint an everyday inspection takes place where we deal about the work done, the
upcoming steps and the problems we had during the work. Yet in this sprint we had to make several
iterations between analysis, design, code and test.
3.2.1. Analysis
3.2.1.1. Use Case
Figure 11: Use Case Sprint1
3.2.1.2. Use case briefs
Table 8: Use Case Briefs, Sprint1: Update Profile
Name Update Profile
description The user can update personal information through his profile section like
his phone number, birthday...
actors Customer, helpdesk, Manager
preconditions Accounts created and active
Basic flow Read account and update information
Alternative flow Account blocked, leaving the page without validating the changed
information
Exceptional flow
Postcondition Validate the updated information

24
3.2.2. Design
3.2.2.1. Class Diagram: Accounts management
This Part and the following figure represents the class diagram of the very first sprint (Accounts
management), its importance is that it makes the connection between, the use cases, the business
layer models and the interface with the user.
Figure 12: Class Diagram sprint1

25
3.2.2.2. Authentication sequence Diagram
In this diagram, we first highlight the parts that participate in the realization of the scenario
"Authentication".
The following Figure illustrates the different interactions between any type of user and the system at
the phase of connection.
Figure 13: Authentication Sequence Diagram

26
3.2.2.3. Account creation sequence diagram
In this diagram, we highlight the parts that participate in the realization of the scenario "Account
Creation".
In the following Figure we’ll be presenting the different interactions between administrator and
system after authentication.
Figure 14: Account creation sequence diagram

27
3.2.3. Implementation
Down below a screenshot of some code we have made.
Figure 15: Admin Interface code Screenshot
3.2.4. Test
Software testing is a process of executing a program or application with the intent of finding
the software bugs. It can also be stated as the process of validating and verifying that
a software program or application or product: Meets the business and technical requirements that
guided its design and development.
In the figure 21 down below we screenshotted the administrator interface after logging In to register
a new user.
Figure 16: test Registration interface

28
3.3. Sprint review
As the Scrum principles are, this inspection took place in 20/04/2018, lasted for an hour with the
product owner to discuss whether he is satisfied. We discussed the imperfections of this first sprint
and came out with some (would have) functionalities that we decided to leave them up to another
sprint after getting the (should have) ones done.
3.4. Sprint retrospective
This inspection was a great way to the team to reflect on the sprint, the work that was done, the goals
achieved, and set our course for the next sprint.
The tool used was oral conversation! It was simpler than whiteboards and sticky notes. However, we
had a paper and a pen to write down important ideas.
As most important things we have deal about are the KSS; what to keep, what to start and what to
stop; We will keep a better team communication during the work, start working on a best commented
code quality and stop doing anything that wastes time.

5. Sprint2: Ticketing System
29
Plan
5. Sprint2: Ticketing System..................................................................................................................29
4.1. Sprint Planning...........................................................................................................................29
4.1.1. Sprint backlog......................................................................................................................29
4.2. Daily Scrum ................................................................................................................................31
4.2.1. Analysis ...............................................................................................................................31
4.2.1.1 Use Case........................................................................................................................31
4.2.1.2 Use Case briefs..............................................................................................................32
4.2.2. Design..................................................................................................................................32
4.2.2.1. Class Diagram: Ticketing system..................................................................................32
4.2.2.2. delete trouble ticket sequence diagram......................................................................33
4.3. Sprint Review .............................................................................................................................35
4.1. Sprint Planning
For the host organization’s benefit, the product owner decides that this is for now the most important
sprint regarding to its functionalities, in this inspection we discussed for more than three hours dating
24/04/2018, since this sprint has deeply larger tasks to realize, we decided to set a goal of basic
ticketing system that respond to the basic requirements. And therefore, realizing the following sprint
backlog.
4.1.1. Sprint backlog
Those few items selected from the product backlog, representing a basic functionality of a ticketing
system desired. The below table (Sprint backlog) englobes user stories broken down into more specific
tasks and estimated days to accomplish each of them.

30
Table 9: Sprint2 backlog: ticketing system
Id User Story Id task Tasks Estimation Priority
8 As a customer I want to
be able to create tickets
1 Implement the class
diagram and Entity
Framework mapping
3 25
responsible to add the
ticket
3 25
3 Implement the add ticket
method to the customers
interface
3 25
4 Test the creation of the
ticket
2 20
be able to read the state
of a ticket that I created
5 Implement the read
method with the
customer’s interface
4 12
6 Test the method 2 12
be able to delete my
ticket that is not yet
treated
7 Plan the algorithm of
testing if the ticket could
be deleted
2 12
8 Implement the method 3 12
11 9 Test it 2 12
As a help desk I want to
be able to read all tickets
and their owners profile
10 Conceive the display
interface
3 25
11 Code the interface 3 12
12 Code the display method
for the tickets
3 20
for the owner of each
ticket
4 12
14 Test every task as a help
desk
2 12
12 As a help desk I want to
be able to update tickets
15 Code the method to
update tickets
4 20
16 Test the update as a help
desk
2 12
13 As a manager I want to be
able to read all tickets and
their owners profile
17 Conceive and code the
interface
4 12
for the tickets
3 12
for the owner of each
ticket
3 5
20 Test every task as a
manager
2 12
14 As a help desk I want to
be able to update tickets
21 Code the method to
update tickets
3 12
22 Test the update as a help
desk
2 12

31
4.2. Daily Scrum
Typically, every single day we had to make a daily scrum meeting, setting the context of the previous
and upcoming days of work.
That we detailed in the below parts of this sprint the artifacts and the theoretical facts we could
document in this report.
4.2.1. Analysis
4.2.1.1 Use Case
Figure 17: Use Case sprint2: Ticketing system

32
4.2.1.2 Use Case briefs
Table 10: Use Case Briefs, Sprint2: Delete non-processed ticket
Name Delete non- processed ticket
description The customer can delete the ticket created by mistake or if the problem
is solved after a while he created the ticket.
actors Customer
preconditions Authentication
Being the owner of the ticket
The ticket is not opened and its process started
Basic flow Create ticket
Open ticket and delete it
Alternative flow the ticket is starting process or solved,
then deleting it is impossible
Exceptional flow
Postcondition A confirmation delete message
Table 11: Use Case Briefs, Sprint2: Process ticket
Name Process ticket
description The user can update personal information in his profile like his phone
number, birthday...
actors Customer, helpdesk, Manager
preconditions Accounts created and active
Basic flow Read account and update information
Alternative flow Account blocked, leaving the page without validating the changed
information
Exceptional flow
Postcondition Validate the updated information
4.2.2. Design
4.2.2.1. Class Diagram: Ticketing system
In this Part we represent the class diagram of the second sprint (Ticketing system), highlighting the
most needed classes for this sprint.

33
Figure 18: class diagram sprint2
4.2.2.2. delete trouble ticket sequence diagram
In this diagram, we highlight the parts that participate in the realization of the scenario "Delete trouble
ticket".
In the following Figure we’ll be presenting the different interactions between customer and system
after authentication while managing his tickets.

34
Figure 19: delete trouble ticket sequence diagram

35
4.3. Sprint Review
this inspection took place in 18/05/2018, lasted for an hour when the product owner was present. We
discuss the product’s state, we came out with some other requirements that will be present in the
upcoming sprint backlog.
4.4. Sprint retrospective
As well as the previous sprint the team discussed the work done, the goals achieved and non-
achieved, and our communication with each other.
The inspection lasted for an hour and we created a plan for improvements to be enacted during the
next Sprint.

General Conclusion and perspectives
36
General Conclusion and perspectives
In this project, we created our CRM from scratch by learning and exploring a well propelled we
technology, which allows easy and perfect communication between the Client-side, fully developed in
HTML5 and Razor pages, and the .NET Server-side.
This report is the summary of our graduation project from the higher institute of technological studies
of Rades (ISETR) (in French “institut supérieur des études technologiques de radès (ISETR)”) at the
host company SINORFI. It summarizes the work done to develop this application.
This work provides the most important services to SINORFI primarily: the ticketing system.
It is supposed to be hosted on Azure Cloud service but this task is delayed by a decision from the
responsible of SINORFI.
The realization of this report is divided into three big axes; the first one deals with the general frame
of the project (presenting the host organization its problems and the solution proposed), and the
methodology adopted.
The second is the sprint zero; which is something a little special with Scrum, since we are not familiar
with this methodology before that it was a must to have a sprint zero that contains the hole work
done before starting the typical known sprints(Dividing roles, technical choices and tools used),
therefore we had the software requirements specifications ‘document, the first most important
artifact; the product backlog and we planned a little about the upcoming sprints and an overview
about their repartition.
Afterwards, the third part id obviously the sprints iterations, each sprint deals with several
functionalities.
This internship was a fabulous experience to me with its ups and downs, that I learned from scratch
Scrum practically and .net technology as well. Discovered for the first time the work within a Digital
Service Company, it was equally a chance to discover CRM s and think about my own startup project.

Bibliography and Netography
37
Bibliography and Netography
[1] [Online]. Available: http://www.sinorfi.com/. [Accessed 03 2018].
[2] [Online]. Available: https://www.youtube.com/watch?v=Mmm-7o4gVrk. [Accessed 02 2018].
[3] [Online]. Available: http://techonestop.com/what-does-crm-stand-for-what-is-crm. [Accessed
03 2018].
[4] [Online]. Available: https://www.researchgate.net/figure/Non-Exhaustive-View-on-the-Main-
Aspects-Forming-a-Cloud-System-13_fig3_49592729. [Accessed 04 2018].
[5] [Online]. Available: https://www.nist.gov/. [Accessed 04 2018].
[6] [Online]. Available: https://kvaes.wordpress.com/2017/02/21/opinion-hybrid-cloud-hybrid-
cloud-and-how-does-private-cloud-link-to-that/. [Accessed 04 2018].
[7] [Online]. Available: https://www.agilealliance.org/agile101/12-principles-behind-the-agile-
manifesto/. [Accessed 03 2018].
[8] [Online]. Available: https://www.versionone.com/agile-101/agile-methodologies/. [Accessed
03 2018].
[9] [Online]. Available: http://sce.uhcl.edu/helm/rationalunifiedprocess/. [Accessed 03 2018].
[10] [Online]. Available: https://www.scrum.org/resources/what-is-scrum. [Accessed 03 2018].
[11] [Online]. Available: https://www.c-sharpcorner.com/UploadFile/d9c992/the-agile-scrum-
framework/. [Accessed 03 2018].
[12] [Online]. Available: https://www.frontrowagile.com/blog/posts/125-sprint-zero-for-product-
owners. [Accessed 04 2018].
[13] [Online]. Available:
http://www.trempet.it/Enseignement/Cours/inf5151/Hiver2008/NotesdeCours/PP-
IEEE%20830-%201998.pdf. [Accessed 03-04 2018].
[14] 04 2018. [Online]. Available: https://flylib.com/books/en/2.100.1.64/1/.
[15] [Online]. Available: https://docs.microsoft.com/en-us/aspnet/.
[16] [Online]. Available: https://www.w3schools.com/bootstrap/. [Accessed 04 2018].
[17] 05 2018. [Online]. Available: https://michaellant.com/2010/05/21/how-to-easily-prioritize-
your-agile-stories/.
[18] [Online]. Available: https://www.scrum.org/resources/blog/5-scrum-values-take-center-stage.
[Accessed 03 2018].
[19] 05 2018. [Online]. Available: https://www.agilebusiness.org/content/moscow-prioritisation-0.

Appendix A: Scrum
38
Appendix A: Scrum
INTRODUCTION
SCRUM is a loose set of guidelines that govern the development process of a product, from its design
stages to its completion. It aims to cure some common failures of the typical development process,
such as:
• Chaos due to changing requirements - the real or perceived requirements of a project usually
changes drastically from the time the product is designed to when it is released. Under most product
development methods, all design is done at the beginning of the project, and then no changes are
allowed for or made when the requirements change.
• Unrealistic estimates of time, cost, and quality of the product - the project management and the
developers tend to underestimate how much time and resources a project will take, and how much
functionality can be produced within those constraints. This usually cannot be accurately predicted at
the beginning of the development cycle.
• Developers are forced to lie about how the project is progressing - When management
underestimates the time and cost needed to reach a certain level of quality, the developers must
either lie about how much progress has been made on the product, or face the indignation of the
management.
SCRUM has been successfully employed by hundreds of different companies in many different fields,
with outstanding results.
SCRUM VALUES
The SCRUM values are derived from the Agile values of software development.
• Individuals and interactions over processes and tools - processes and tools are helpful, but they will
do you no good if the team does not communicate and collaborate in a constructive fashion.
• Working software over comprehensive documentation - documentation is important, but what’s
most important is to have working software.
• Customer collaboration over contract negotiation - you are not just looking to get a contract and get
money that way - you are solving the customer’s problem.
• Responding to change over following a plan - if the requirements or perceived requirements
changed, so should the plans and design.

Appendix A: Scrum
39
THE SCRUM PROCESS
The scrum process has 3 main phases:
FIG 1: The Scrum process
PLANNING
In this phase, the project is planned and high-level design decisions are made.
SPRINT CYCLE
FIG 2: the scrum cycle

Appendix A: Scrum
40
The sprint cycle is an iterative cycle of about 3-4 weeks, in which the actual development of the
product is done. It starts out with a Sprint Planning Meeting to decide what will be done in the current
sprint. Then the development is done. A sprint is closed with a Sprint Review Meeting where the
progress made in the last sprint is demonstrated, the sprint is reviewed, and adjustments are made to
the project as necessary. The sprint cycle is repeated until the product’s development is complete.
The product is complete when the variables of time, quality, competition, and cost are at a balance.
• Develop the product further - implement, test, and document.
• Wrap up the work - get it ready to be evaluated and integrated.
• Review the work done in this sprint.
• Adjust for any changes in requirements or plans.
CLOSURE
In this phase, the product’s development is brought to a close, and the product is released.
THE SCRUM TEAM
The SCRUM team consists of 2 groups
- the interested team, which consists of people who are interested, but who will not be doing the
work, and the working team;
- people who are interested, and will be doing the work on the project.
A team typically has no more than 6-9 working members, although Scrum has been successfully used
with more members. If there are more members than manageable, the project should be broken into
multiple sub-projects, each focusing on one, self-contained area of work (one for QA, one for
documentation, etc.). There should be people to act as bridges - that is, to attend the meetings of
more than one SCRUM team, and act as a communication bridge between the teams. Members of
teams that are closely related/involved with each other should sit in on the other teams’ Scrum
meetings.
THE LEADER (SCRUM MASTER)
The team’s leader is called the Scrum Master. He should be one of the members of the working team
- that is, he should be one of the people who is actually doing the work on the project. The Scrum
Master measures progress, removes impediments, and leads the team meetings.

Appendix A: Scrum
41
COMMONLY USED TERMS
SPRINT
The product is developed in a series of 1-to-4-week iterations, or sprints. Before a sprint is begun, a
Sprint Planning Meeting is held to determine what features are to be implemented in that sprint. The
sprint has 4 major steps:
• Develop the product further - implement, test, and document.
• Wrap up the work - get it ready to be evaluated and integrated.
• Review the work done in this sprint.
• Adjust for any changes in requirements or plans.
PRODUCT BACKLOG
A prioritized list of all the desired changes to the product being developed, put together by the product
owner. See Figure 2.
SPRINT BACKLOG
A list with items that will be completed in the current sprint, taken from the product backlog. See
Figure 2.
DAILY SCRUM MEETING
A 15-minute SCRUM meeting is held every day. The SCRUM Master asks the three questions, and all
members of the team and interested parties take part and give feedback. The meeting should be held
at the same place every time, so that people know where to go.
UNIT TESTING
A unit test is an automated test that ensures that the functionality required for a certain area of a
project is implemented, and that there are no breaking changes that have not been taken into
consideration.
IMPEDIMENT
Impediments are things that get in the way of the progress of the project. The SCRUM Master is
responsible to look for and remove these obstacles so that they do not slow down or impair the
project.

Appendix A: Scrum
42
3 QUESTIONS
The Scrum Master asks the developers 3 important questions at every SCRUM meeting:
1. What have you accomplished since the last meeting?
2. Are there any obstacles in the way of meeting your goal?
3. What will you accomplish before the next meeting?
PRODUCT OWNER
The person who commissions the project, and defines the requirements and priorities for the product.
SPRINT PLANNING MEETING
A meeting at the beginning of a sprint where the sprint is planned. Items from the Product Backlog
are selected to be completed in the sprint, based on the priorities set by the Product Owner.
SPRINT REVIEW MEETING
A sprint is closed with a Sprint Review Meeting where the progress made in the last sprint is
demonstrated, the sprint is reviewed, and adjustments are made to the project as necessary.
KEY PLAYERS/AUTHORS:
• Jeff Sutherland is one of the originators of SCRUM, and was one of the first people to apply SCRUM
to a real-life project.
• Ken Schwaber is one of the originators of SCRUM.
• Mike Beedle has successfully used SCRUM in numerous large-scale projects, and, together with Ken
Schwaber, wrote the book Agile Software Development with SCRUM.

Appendix B: Academic meeting (procès-verbal PV)
43
Appendix B: Academic meeting (procès-verbal PV)
MEETING INFORMATION’S:
Meeting Location ISET Rades Meeting Date 08/05/2018
Meeting Time 3.15-4.30pm
Meeting Notes prepared by Rym DAKHLI Meeting Notes
Date
09/05/2018
Purpose of Meeting Formal inspection for Sprint1 Planning
Attendees
Riadh GHLALA
Rym DAKHLI
Not attended
DISCUSSIONS SYNTHESIS:
Entry Product:
earlier version of this report
Goals of the meeting:
The goals of the meeting were two:
1. Revise the report
2. Test the code
Revise the report
Mr. Riadh had provided us with such important information about how a report should be.
Test the code
Revising weather the code is depending from the specifications.

Appendix C: Sprint1 planning
44
MEETING INFORMATION’S:
Meeting Location SINORFI local Meeting Date 28/03/2018
Meeting Time 2.00-5.00pm
Date
10/04/2018
Purpose of Meeting Formal inspection for Sprint1 Planning
Attendees
Product owner: Ahmed JOUINI
Scrum Master: Mohamed Tawfik WERFELLI
Team: Rym DAKHLI
Not attended
DISCUSSIONS SYNTHESIS:
Entry Product: Product backlog
tab 1: product backlog
Sprint ID User Story
1 1 as an administrator I want to be able to create accounts
1 2 as an administrator I want to be able to block accounts
1 3 as an administrator I want to be able to reactive accounts
1 4 as an administrator I want to be able to read all the accounts
1 8 as a customer I want to be able to update my profile
1 15 as a helpdesk I want to be able to update my profile
1 19 as a manager I want to be able to update my profile
2 9 as a customer I want to be able to create tickets
2 10 as a customer I want to be able to read the state of the tickets that I created
2 11 as a customer I want to be able to delete my ticket not yet treated
2 16 as a helpdesk I want to be able to read all tickets and owner profiles
2 17 as a helpdesk I want to be able to update tickets
2 20 as a manager I want to be able to read all the tickets and the profile of the owners
2 21 as a manager I want to be able to update tickets
3 12 as a customer I want to be able to read products
3 22 as a manager I want to be able to create products
3 23 as a manager I want to be able to update a product
3 24 as a manager I want to be able to delete a product
4 13 as a customer I want to be able to send a feedback of satisfaction

45
Goals of the meeting
The goals of the meeting were to:
1. Set the goal of the sprint
2. Identify tasks from selected items
3. Estimation of tasks
4. Assignement of tasks
5. The commitment of the team
6. Output Product: backlog sprint 1
1. Set the goal of the sprint
There are three main focuses:
▪ Implementing the interface
▪ Make the design
▪ Creating users and roles
▪ authentication
2. IDENTIFY TASKS FROM SELECTED ITEMS
Integrate interfaces.
Implement class diagram.
Map code with database.
Conceive and implement methods to create accounts, block and reactive them.
Implement the methods to allow the user to update his own profile.
Test the functionalities.
3. Estimation of tasks
After we set all the technical aspects. The estimation was made with the product owner about 3
weeks of work.
4. Assignment of tasks
Once the sprint activities have been defined and the product owner describes the priorities, the
team members usually volunteer to own certain tasks and then activities can be performed by
one or more people depending on their availability, but in this specific project the only member
is ‘Rym DAKHLI' who will perform all the required tasks.
5. The commitment of the team
Ideally the team commits collectively to the sprint backlog and its elements. As much as they can
do in the sprint timing and on the list of tasks.

46
Output Product: backlog sprint 1
The team provided a sprint backlog 1 in an easily visible and accessible form.
tab 2: sprint1 backlog
Id User Story Id task Tasks Estimation
1 as an administrator I want to be able
to create accounts and roles
01 Integrate interfaces 2
11 Implement class diagram 1
21 Map code with database 2
to block accounts
31 Conceive and implement
the method
to reactive accounts
reactive blocked accounts
2
51 test block and reactive
accounts
1
to read all the accounts
interface
1
display
81 Test the functionality 1
8 as a customer I want to be able to
update my profile
interface
2
101 Implement the method and
interface to display the
users profile
3
111 Test 1
15 as a helpdesk I want to be able to
update my profile
interface
2
users profile
3
141 Test 1
19 as a manager I want to be able to
update my profile
interface
2
users profile
3
171 Test 1

Appendix D: Daily Scum meeting
47
Appendix D: Daily Scum meeting
Meeting Location Skype Meeting Date 05/04/2018
Meeting Time 9.00-9.20am
Date
10/04/2018
Purpose of Meeting Formal Scrum inspection for Sprint1 Daily meeting
Attendees
Team: Rym DAKHLI
Not attended
Meeting agenda:
1. Tasks done.
2. Tasks in progress.
3. Problems preventing progress.
1. Tasks done:
Id user story 1
2. Tasks in progress
• creating roles
3. Problems preventing progress
Team not familiar with the technology.

Appendix E: Sprint 1 Review
48
Appendix E: Sprint 1 Review
Meeting Location Skype Meeting Date 20/04/2018
Meeting Time 9.00-10.00am
Date
10/04/2018
Purpose of Meeting Formal Scrum inspection for Sprint1 Daily meeting
Attendees
Product owner: Ahmed JOUINI
Team: Rym DAKHLI
Not attended
Input product:
Our potentially deliverable product that we have developed at the end of sprint 1.
Steps:
• Preparation of a demonstration highlighting a syllabus management scenario considering all the
stakeholders of our application.
• Recall the purpose of the “to create an authentication system”
• We performed the demonstration according to the scenario prepared before the beginning of the
meeting.
• The plan of the setting on line: the product owners decided that the setting on line had to be at
closing the project by assembling all other deliverables.

Appendix F: Prioritize Your Agile Stories
49
Appendix F: Prioritize Your Agile Stories
Scott Ambler says that 85% of all features built into software products are either rarely used, or never
used at all. So as much as some stakeholders might think that a particular product feature is essential,
it is highly likely it will end up being one of the 85% that go unused. One of the fundamental reasons
for using an Agile methodology is to focus on the things that bring the greatest value, so how do you
actually determine which stories provide the greatest value and are thus scheduled first? To be
effective and obtain consistent, repeatable results requires a system or process that is quick, easy to
use and consistently applied. [17]
The quick answer is to rank all of the cards on a scale of 1 to 10, or 1 to 100 if you need finer
differentiation, and then sort them in order from highest to lowest priority. This is a pretty common
approach, but it is challenging to apply a single numerical value to what is usually a multidimensional
question.
 Time is the first vector because time is almost inevitably the fundamental constraint on all
projects and it is the one finite resource. This vector is up to the stakeholders.
 Business Value is the second, it could thus mean the amount of revenue that might be
generated or lost, effect on brand or reputation, performance issues, security concerns…
It is up to the team to decide in each case what the Business Value guidelines should be, and how
to classify each item.
These two by themselves does not mean much, but if we put them together and match with our
backlog we can assess the priority o fa user story or a task.
FIG 3: Priority Range

PFE .NET CRM

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to PFE .NET CRM

Similar to PFE .NET CRM (20)

Recently uploaded

Recently uploaded (20)

PFE .NET CRM