PFE .NET CRM

R

Information technology End of study project.

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
4.4. Sprint retrospective ...................................................................................................................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
4. Sprint1: Accounts management
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.4. Sprint retrospective ...................................................................................................................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.
4. Sprint1: Accounts management
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
2 as an administrator I want to
be able to block accounts
4 Conceive and implement
the method to block
account
3 12
3 as an administrator I want to
be able to reactive accounts
5 Implement the method to
reactive blocked accounts
3 12
6 test block and reactive
accounts
3 5
4 as an administrator I want to
be able to read all the accounts
7 Conceive the interface
to display accounts
3 12
8 Implement the method to
display
3 12
9 Test the functionality 2 12
5 as a customer I want to be able
to update my profile
10 Conceive the interface
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 update my profile
13 Conceive the interface
to display profile
3 5
14 Implement the method
and interface to display
the users profile
4 5
15 Test 2 5
7 as a manager I want to be able
to update my profile
16 Conceive the interface
to display profile
3 5
17 Implement the method
and interface to display
the users profile
4 5
18 Test 2 5
4. Sprint1: Accounts management
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
4. Sprint1: Accounts management
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
4. Sprint1: Accounts management
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
4. Sprint1: Accounts management
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
4. Sprint1: Accounts management
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
4. Sprint1: Accounts management
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
5. Sprint2: Ticketing System
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.4. Sprint retrospective ...................................................................................................................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.
5. Sprint2: Ticketing System
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
2 Conceive the interface
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
9 As a customer I want to
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
10 As a customer I want to
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
13 Code the display method
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
18 Code the display method
for the tickets
3 12
19 Code the display method
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
5. Sprint2: Ticketing System
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
5. 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.
5. Sprint2: Ticketing System
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.
5. Sprint2: Ticketing System
34
Figure 19: delete trouble ticket sequence diagram
5. Sprint2: Ticketing System
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
Appendix C: Sprint1 planning
MEETING INFORMATION’S:
Meeting Location SINORFI local Meeting Date 28/03/2018
Meeting Time 2.00-5.00pm
Meeting Notes prepared by Rym DAKHLI Meeting Notes
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
Appendix C: Sprint1 planning
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.
Appendix C: Sprint1 planning
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
2 as an administrator I want to be able
to block accounts
31 Conceive and implement
the method
3 as an administrator I want to be able
to reactive accounts
41 Implement the method to
reactive blocked accounts
2
51 test block and reactive
accounts
1
4 as an administrator I want to be able
to read all the accounts
61 Conceive the display
interface
1
71 Implement the method to
display
81 Test the functionality 1
8 as a customer I want to be able to
update my profile
91 Conceive the display
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
121 Conceive the display
interface
2
131 Implement the method and
interface to display the
users profile
3
141 Test 1
19 as a manager I want to be able to
update my profile
151 Conceive the display
interface
2
161 Implement the method and
interface to display the
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
Meeting Notes prepared by Rym DAKHLI Meeting Notes
Date
10/04/2018
Purpose of Meeting Formal Scrum inspection for Sprint1 Daily meeting
Attendees
Scrum Master: Mohamed Tawfik WERFELLI
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
Meeting Notes prepared by Rym DAKHLI Meeting Notes
Date
10/04/2018
Purpose of Meeting Formal Scrum inspection for Sprint1 Daily meeting
Attendees
Product owner: Ahmed JOUINI
Scrum Master: Mohamed Tawfik WERFELLI
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

Recommandé

CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE... par
CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...
CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...Madjid Meddah
11K vues77 diapositives
Rapport PFE : Réalisation d'une application web back-office de gestion pédago... par
Rapport PFE : Réalisation d'une application web back-office de gestion pédago...Rapport PFE : Réalisation d'une application web back-office de gestion pédago...
Rapport PFE : Réalisation d'une application web back-office de gestion pédago...Anas Riahi
11.7K vues55 diapositives
Rapport de projet de fin d'étude licence informatique et multimédia par
Rapport de projet de fin d'étude licence informatique et multimédiaRapport de projet de fin d'étude licence informatique et multimédia
Rapport de projet de fin d'étude licence informatique et multimédiaNazih Heni
181.3K vues91 diapositives
Rapport pfe par
Rapport pfeRapport pfe
Rapport pfeAhmed rebai
21.7K vues97 diapositives
Rapport du projet fin d'etudes par
Rapport du projet fin d'etudesRapport du projet fin d'etudes
Rapport du projet fin d'etudesTahani RIAHI
8.9K vues80 diapositives
Projet Fin D'étude Application Mobile par
Projet Fin D'étude Application MobileProjet Fin D'étude Application Mobile
Projet Fin D'étude Application MobileRim ENNOUR
13.1K vues67 diapositives

Contenu connexe

Tendances

Rapport PFE Ahmed BEN JEMIA par
Rapport PFE Ahmed BEN JEMIARapport PFE Ahmed BEN JEMIA
Rapport PFE Ahmed BEN JEMIAAhmed BEN JEMIA
3.7K vues115 diapositives
Rapport PFE : Développement D'une application de gestion des cartes de fidéli... par
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...Riadh K.
91.6K vues29 diapositives
Rapport de stage du fin d'étude par
Rapport de stage du fin d'étudeRapport de stage du fin d'étude
Rapport de stage du fin d'étudeYahyaoui Mohamed Yosri
73.6K vues72 diapositives
Conception et Réalisation Application Web Laravel PFE BTS par
Conception et Réalisation Application Web Laravel PFE BTSConception et Réalisation Application Web Laravel PFE BTS
Conception et Réalisation Application Web Laravel PFE BTSFaissoilMkavavo
4.7K vues51 diapositives
Pfe conception et réalisation d'une application de gestion des processus d'ac... par
Pfe conception et réalisation d'une application de gestion des processus d'ac...Pfe conception et réalisation d'une application de gestion des processus d'ac...
Pfe conception et réalisation d'une application de gestion des processus d'ac...Ahmed Makni
19.3K vues67 diapositives
Rapport pfe-ayoub mkharbach par
Rapport pfe-ayoub mkharbachRapport pfe-ayoub mkharbach
Rapport pfe-ayoub mkharbachAyoub Mkharbach
7.4K vues87 diapositives

Tendances(20)

Rapport PFE : Développement D'une application de gestion des cartes de fidéli... par Riadh K.
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
Riadh K.91.6K vues
Conception et Réalisation Application Web Laravel PFE BTS par FaissoilMkavavo
Conception et Réalisation Application Web Laravel PFE BTSConception et Réalisation Application Web Laravel PFE BTS
Conception et Réalisation Application Web Laravel PFE BTS
FaissoilMkavavo4.7K vues
Pfe conception et réalisation d'une application de gestion des processus d'ac... par Ahmed Makni
Pfe conception et réalisation d'une application de gestion des processus d'ac...Pfe conception et réalisation d'une application de gestion des processus d'ac...
Pfe conception et réalisation d'une application de gestion des processus d'ac...
Ahmed Makni19.3K vues
Rapport PFE Application Web Mobiles belwafi bilel par Belwafi Bilel
Rapport PFE Application Web Mobiles belwafi bilelRapport PFE Application Web Mobiles belwafi bilel
Rapport PFE Application Web Mobiles belwafi bilel
Belwafi Bilel17.2K vues
Rapport stage pfe par rimeh moussi
Rapport stage  pfe Rapport stage  pfe
Rapport stage pfe
rimeh moussi33.5K vues
Rapport Projet ERP - Plateforme Odoo 12 (PFE Licence) par Yasmine Tounsi
Rapport Projet ERP - Plateforme Odoo 12 (PFE Licence)Rapport Projet ERP - Plateforme Odoo 12 (PFE Licence)
Rapport Projet ERP - Plateforme Odoo 12 (PFE Licence)
Yasmine Tounsi4.8K vues
Rapport pfe Conceptionet Developpement d'une Application web et Mobile par Raoua Bennasr
Rapport pfe Conceptionet Developpement d'une Application web et  Mobile Rapport pfe Conceptionet Developpement d'une Application web et  Mobile
Rapport pfe Conceptionet Developpement d'une Application web et Mobile
Raoua Bennasr17.1K vues
Rapport du Projet de Fin d'année Génie informatique par ayoub daoudi
Rapport du Projet de Fin d'année Génie informatique Rapport du Projet de Fin d'année Génie informatique
Rapport du Projet de Fin d'année Génie informatique
ayoub daoudi7.6K vues
Conception et developpement d'un site web pour la suggestion et notification ... par Mohamed Boubaya
Conception et developpement d'un site web pour la suggestion et notification ...Conception et developpement d'un site web pour la suggestion et notification ...
Conception et developpement d'un site web pour la suggestion et notification ...
Mohamed Boubaya12.7K vues
Rapport PFE Développent d'une application bancaire mobile par Nader Somrani
Rapport PFE Développent d'une application bancaire mobileRapport PFE Développent d'une application bancaire mobile
Rapport PFE Développent d'une application bancaire mobile
Nader Somrani42.7K vues
Présentation PFE par Hedi Riahi
Présentation PFEPrésentation PFE
Présentation PFE
Hedi Riahi4.5K vues
rapport PFE ingénieur génie logiciel INSAT par Siwar GUEMRI
rapport PFE ingénieur génie logiciel INSATrapport PFE ingénieur génie logiciel INSAT
rapport PFE ingénieur génie logiciel INSAT
Siwar GUEMRI24.7K vues
Rapport pfe talan_2018_donia_hammami par Donia Hammami
Rapport pfe talan_2018_donia_hammamiRapport pfe talan_2018_donia_hammami
Rapport pfe talan_2018_donia_hammami
Donia Hammami33.6K vues
Rapport- Conception et réalisation d'une plateforme social learning par Rouâa Ben Hammouda
Rapport- Conception et réalisation d'une plateforme social learningRapport- Conception et réalisation d'une plateforme social learning
Rapport- Conception et réalisation d'une plateforme social learning
Rouâa Ben Hammouda39.4K vues
Rapport PFE "Conception et développement d'un Portail web pour le Smart Met... par Hajer Dahech
Rapport  PFE  "Conception et développement d'un Portail web pour le Smart Met...Rapport  PFE  "Conception et développement d'un Portail web pour le Smart Met...
Rapport PFE "Conception et développement d'un Portail web pour le Smart Met...
Hajer Dahech17.8K vues
Conception et réalisation d'une application de gestion intégrée au sein de la... par Addi Ait-Mlouk
Conception et réalisation d'une application de gestion intégrée au sein de la...Conception et réalisation d'une application de gestion intégrée au sein de la...
Conception et réalisation d'une application de gestion intégrée au sein de la...
Addi Ait-Mlouk128.2K vues
Projet de fin étude ( LFIG : Conception et Développement d'une application W... par Ramzi Noumairi
Projet de fin étude  ( LFIG : Conception et Développement d'une application W...Projet de fin étude  ( LFIG : Conception et Développement d'une application W...
Projet de fin étude ( LFIG : Conception et Développement d'une application W...
Ramzi Noumairi20.4K vues

Similaire à PFE .NET CRM

Rapport Stage PFE Bureau D'étude Electricité : ÉTUDE DE L’INSTALLATION ÉLECTR... par
Rapport Stage PFE Bureau D'étude Electricité : ÉTUDE DE L’INSTALLATION ÉLECTR...Rapport Stage PFE Bureau D'étude Electricité : ÉTUDE DE L’INSTALLATION ÉLECTR...
Rapport Stage PFE Bureau D'étude Electricité : ÉTUDE DE L’INSTALLATION ÉLECTR...SadokZgolli
12.4K vues148 diapositives
Industrial attachment of micro fibre ltd par
Industrial attachment of micro fibre ltdIndustrial attachment of micro fibre ltd
Industrial attachment of micro fibre ltdMd. Mazadul Hasan Shishir
2.7K vues157 diapositives
Iset portal with o365 and SP online par
Iset portal with o365 and SP onlineIset portal with o365 and SP online
Iset portal with o365 and SP onlineKhouloud Ben Cheikh
693 vues84 diapositives
CV-Mohamed Ahmed Sayed cv par
CV-Mohamed Ahmed Sayed cvCV-Mohamed Ahmed Sayed cv
CV-Mohamed Ahmed Sayed cvMohamed Ahmed
348 vues4 diapositives
Report on Industrial Attachment at Abanti Colour Tex Limited par
Report on Industrial Attachment at Abanti Colour Tex LimitedReport on Industrial Attachment at Abanti Colour Tex Limited
Report on Industrial Attachment at Abanti Colour Tex LimitedAbu Hasnat Md. Shakik Prodhan
1.5K vues119 diapositives
Industrial attachment of interstoff Apparels Ltd. par
Industrial attachment of interstoff Apparels Ltd.Industrial attachment of interstoff Apparels Ltd.
Industrial attachment of interstoff Apparels Ltd.National Institute of Textile Engineering and Research
694 vues104 diapositives

Similaire à PFE .NET CRM(20)

Rapport Stage PFE Bureau D'étude Electricité : ÉTUDE DE L’INSTALLATION ÉLECTR... par SadokZgolli
Rapport Stage PFE Bureau D'étude Electricité : ÉTUDE DE L’INSTALLATION ÉLECTR...Rapport Stage PFE Bureau D'étude Electricité : ÉTUDE DE L’INSTALLATION ÉLECTR...
Rapport Stage PFE Bureau D'étude Electricité : ÉTUDE DE L’INSTALLATION ÉLECTR...
SadokZgolli12.4K vues
Final Internship Report par Minhas Kamal
Final Internship ReportFinal Internship Report
Final Internship Report
Minhas Kamal20.8K vues
Internship report wvu updated final par MwesigwaJovan
Internship report wvu updated finalInternship report wvu updated final
Internship report wvu updated final
MwesigwaJovan151 vues
Réalisation d’un plan topographique de la ville de El-Brij,Sidi Bouzid par Firas Mejri
Réalisation d’un plan topographique  de la ville de El-Brij,Sidi BouzidRéalisation d’un plan topographique  de la ville de El-Brij,Sidi Bouzid
Réalisation d’un plan topographique de la ville de El-Brij,Sidi Bouzid
Firas Mejri944 vues
Rewrite a message exchange system and set up its testing environment par Emmanuel Padjinou
Rewrite a message exchange system and set up its testing environmentRewrite a message exchange system and set up its testing environment
Rewrite a message exchange system and set up its testing environment
Computer science/ IT Fianl attachment report par Paullaster Okoth
Computer science/ IT Fianl attachment reportComputer science/ IT Fianl attachment report
Computer science/ IT Fianl attachment report
Paullaster Okoth20.6K vues
Student Industrial Workshop Experience Scheme (SIWES) Report par OkpehHarrison
Student Industrial Workshop Experience Scheme (SIWES) ReportStudent Industrial Workshop Experience Scheme (SIWES) Report
Student Industrial Workshop Experience Scheme (SIWES) Report
OkpehHarrison4.3K vues
WIRELESS SENSOR NETWORK FOR REAL TIME AIR QUALITY MONITORING par nuru kessy
WIRELESS SENSOR NETWORK FOR REAL TIME AIR QUALITY MONITORINGWIRELESS SENSOR NETWORK FOR REAL TIME AIR QUALITY MONITORING
WIRELESS SENSOR NETWORK FOR REAL TIME AIR QUALITY MONITORING
nuru kessy74 vues

Dernier

Kyo - Functional Scala 2023.pdf par
Kyo - Functional Scala 2023.pdfKyo - Functional Scala 2023.pdf
Kyo - Functional Scala 2023.pdfFlavio W. Brasil
298 vues92 diapositives
iSAQB Software Architecture Gathering 2023: How Process Orchestration Increas... par
iSAQB Software Architecture Gathering 2023: How Process Orchestration Increas...iSAQB Software Architecture Gathering 2023: How Process Orchestration Increas...
iSAQB Software Architecture Gathering 2023: How Process Orchestration Increas...Bernd Ruecker
33 vues69 diapositives
Five Things You SHOULD Know About Postman par
Five Things You SHOULD Know About PostmanFive Things You SHOULD Know About Postman
Five Things You SHOULD Know About PostmanPostman
30 vues43 diapositives
Perth MeetUp November 2023 par
Perth MeetUp November 2023 Perth MeetUp November 2023
Perth MeetUp November 2023 Michael Price
19 vues44 diapositives
STPI OctaNE CoE Brochure.pdf par
STPI OctaNE CoE Brochure.pdfSTPI OctaNE CoE Brochure.pdf
STPI OctaNE CoE Brochure.pdfmadhurjyapb
13 vues1 diapositive
Attacking IoT Devices from a Web Perspective - Linux Day par
Attacking IoT Devices from a Web Perspective - Linux Day Attacking IoT Devices from a Web Perspective - Linux Day
Attacking IoT Devices from a Web Perspective - Linux Day Simone Onofri
15 vues68 diapositives

Dernier(20)

iSAQB Software Architecture Gathering 2023: How Process Orchestration Increas... par Bernd Ruecker
iSAQB Software Architecture Gathering 2023: How Process Orchestration Increas...iSAQB Software Architecture Gathering 2023: How Process Orchestration Increas...
iSAQB Software Architecture Gathering 2023: How Process Orchestration Increas...
Bernd Ruecker33 vues
Five Things You SHOULD Know About Postman par Postman
Five Things You SHOULD Know About PostmanFive Things You SHOULD Know About Postman
Five Things You SHOULD Know About Postman
Postman30 vues
STPI OctaNE CoE Brochure.pdf par madhurjyapb
STPI OctaNE CoE Brochure.pdfSTPI OctaNE CoE Brochure.pdf
STPI OctaNE CoE Brochure.pdf
madhurjyapb13 vues
Attacking IoT Devices from a Web Perspective - Linux Day par Simone Onofri
Attacking IoT Devices from a Web Perspective - Linux Day Attacking IoT Devices from a Web Perspective - Linux Day
Attacking IoT Devices from a Web Perspective - Linux Day
Simone Onofri15 vues
Business Analyst Series 2023 - Week 3 Session 5 par DianaGray10
Business Analyst Series 2023 -  Week 3 Session 5Business Analyst Series 2023 -  Week 3 Session 5
Business Analyst Series 2023 - Week 3 Session 5
DianaGray10237 vues
handbook for web 3 adoption.pdf par Liveplex
handbook for web 3 adoption.pdfhandbook for web 3 adoption.pdf
handbook for web 3 adoption.pdf
Liveplex22 vues
Spesifikasi Lengkap ASUS Vivobook Go 14 par Dot Semarang
Spesifikasi Lengkap ASUS Vivobook Go 14Spesifikasi Lengkap ASUS Vivobook Go 14
Spesifikasi Lengkap ASUS Vivobook Go 14
Dot Semarang37 vues
GDG Cloud Southlake 28 Brad Taylor and Shawn Augenstein Old Problems in the N... par James Anderson
GDG Cloud Southlake 28 Brad Taylor and Shawn Augenstein Old Problems in the N...GDG Cloud Southlake 28 Brad Taylor and Shawn Augenstein Old Problems in the N...
GDG Cloud Southlake 28 Brad Taylor and Shawn Augenstein Old Problems in the N...
James Anderson66 vues
TouchLog: Finger Micro Gesture Recognition Using Photo-Reflective Sensors par sugiuralab
TouchLog: Finger Micro Gesture Recognition  Using Photo-Reflective SensorsTouchLog: Finger Micro Gesture Recognition  Using Photo-Reflective Sensors
TouchLog: Finger Micro Gesture Recognition Using Photo-Reflective Sensors
sugiuralab19 vues
Case Study Copenhagen Energy and Business Central.pdf par Aitana
Case Study Copenhagen Energy and Business Central.pdfCase Study Copenhagen Energy and Business Central.pdf
Case Study Copenhagen Energy and Business Central.pdf
Aitana16 vues
Piloting & Scaling Successfully With Microsoft Viva par Richard Harbridge
Piloting & Scaling Successfully With Microsoft VivaPiloting & Scaling Successfully With Microsoft Viva
Piloting & Scaling Successfully With Microsoft Viva
From chaos to control: Managing migrations and Microsoft 365 with ShareGate! par sammart93
From chaos to control: Managing migrations and Microsoft 365 with ShareGate!From chaos to control: Managing migrations and Microsoft 365 with ShareGate!
From chaos to control: Managing migrations and Microsoft 365 with ShareGate!
sammart939 vues
Unit 1_Lecture 2_Physical Design of IoT.pdf par StephenTec
Unit 1_Lecture 2_Physical Design of IoT.pdfUnit 1_Lecture 2_Physical Design of IoT.pdf
Unit 1_Lecture 2_Physical Design of IoT.pdf
StephenTec12 vues

PFE .NET CRM

  • 1. 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
  • 2. 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
  • 3. 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
  • 4. 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.
  • 5. 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
  • 6. 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
  • 7. 4.4. Sprint retrospective ...................................................................................................................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
  • 8. 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
  • 9. 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
  • 10. 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.
  • 11. 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
  • 12. 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]
  • 13. 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.
  • 14. 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.
  • 15. 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.
  • 16. 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.
  • 17. 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.
  • 18. 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
  • 19. 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.
  • 20. 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.
  • 21. 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.
  • 22. 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
  • 23. 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
  • 24. 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.
  • 25. 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;
  • 26. 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).
  • 27. 2. Sprint zero: 18 Figure 9: Deployment diagram
  • 28. 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.
  • 29. 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.
  • 30. 4. Sprint1: Accounts management 21 4. Sprint1: Accounts management 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.4. Sprint retrospective ...................................................................................................................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.
  • 31. 4. Sprint1: Accounts management 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 2 as an administrator I want to be able to block accounts 4 Conceive and implement the method to block account 3 12 3 as an administrator I want to be able to reactive accounts 5 Implement the method to reactive blocked accounts 3 12 6 test block and reactive accounts 3 5 4 as an administrator I want to be able to read all the accounts 7 Conceive the interface to display accounts 3 12 8 Implement the method to display 3 12 9 Test the functionality 2 12 5 as a customer I want to be able to update my profile 10 Conceive the interface 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 update my profile 13 Conceive the interface to display profile 3 5 14 Implement the method and interface to display the users profile 4 5 15 Test 2 5 7 as a manager I want to be able to update my profile 16 Conceive the interface to display profile 3 5 17 Implement the method and interface to display the users profile 4 5 18 Test 2 5
  • 32. 4. Sprint1: Accounts management 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
  • 33. 4. Sprint1: Accounts management 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
  • 34. 4. Sprint1: Accounts management 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
  • 35. 4. Sprint1: Accounts management 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
  • 36. 4. Sprint1: Accounts management 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
  • 37. 4. Sprint1: Accounts management 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.
  • 38. 5. Sprint2: Ticketing System 29 5. Sprint2: Ticketing System 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.4. Sprint retrospective ...................................................................................................................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.
  • 39. 5. Sprint2: Ticketing System 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 2 Conceive the interface 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 9 As a customer I want to 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 10 As a customer I want to 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 13 Code the display method 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 18 Code the display method for the tickets 3 12 19 Code the display method 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
  • 40. 5. Sprint2: Ticketing System 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
  • 41. 5. 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.
  • 42. 5. Sprint2: Ticketing System 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.
  • 43. 5. Sprint2: Ticketing System 34 Figure 19: delete trouble ticket sequence diagram
  • 44. 5. Sprint2: Ticketing System 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.
  • 45. 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.
  • 46. 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.
  • 47. 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.
  • 48. 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
  • 49. 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.
  • 50. 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.
  • 51. 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.
  • 52. 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.
  • 53. Appendix C: Sprint1 planning 44 Appendix C: Sprint1 planning MEETING INFORMATION’S: Meeting Location SINORFI local Meeting Date 28/03/2018 Meeting Time 2.00-5.00pm Meeting Notes prepared by Rym DAKHLI Meeting Notes 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
  • 54. Appendix C: Sprint1 planning 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.
  • 55. Appendix C: Sprint1 planning 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 2 as an administrator I want to be able to block accounts 31 Conceive and implement the method 3 as an administrator I want to be able to reactive accounts 41 Implement the method to reactive blocked accounts 2 51 test block and reactive accounts 1 4 as an administrator I want to be able to read all the accounts 61 Conceive the display interface 1 71 Implement the method to display 81 Test the functionality 1 8 as a customer I want to be able to update my profile 91 Conceive the display 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 121 Conceive the display interface 2 131 Implement the method and interface to display the users profile 3 141 Test 1 19 as a manager I want to be able to update my profile 151 Conceive the display interface 2 161 Implement the method and interface to display the users profile 3 171 Test 1
  • 56. 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 Meeting Notes prepared by Rym DAKHLI Meeting Notes Date 10/04/2018 Purpose of Meeting Formal Scrum inspection for Sprint1 Daily meeting Attendees Scrum Master: Mohamed Tawfik WERFELLI 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.
  • 57. 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 Meeting Notes prepared by Rym DAKHLI Meeting Notes Date 10/04/2018 Purpose of Meeting Formal Scrum inspection for Sprint1 Daily meeting Attendees Product owner: Ahmed JOUINI Scrum Master: Mohamed Tawfik WERFELLI 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.
  • 58. 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