Partie 1: Introduction

Partie 1: Introduction


Pourquoi cette série?

Cette série d’articles a été créé pour démontrer que tout ce qui est fait dans SharePoint (toutes versions confondues) doit être issu d’un travail de réflexion sur un besoin à combler en connaissance des concepts et contraintes de la plateforme. Trois constats inter-reliés ont motivé sa rédaction:

  • Premièrement, les nouvelles fonctionnalités de SharePoint 2013 placent la recherche au centre de l’accès à l’information. Cette nouvelle stratégie fait réagir et mérite d’être expliquée.
  • Ensuite, sur bon nombre de projets, l’étape d’analyse, de conception et d’architecture d’information (lorsque présente) est souvent négligée au profit d’une implémentation précipitée.
  • Enfin, dans le cadre de chaque solution SharePoint, il est primordial d’être en mesure de comprendre pourquoi certaines fonctionnalités sont privilégiées par rapport à d’autres.

Au terme de la lecture de ce guide, vous devriez être en mesure de comprendre la réflexion logique adoptée pour choisir telle ou telle solution en connaissance des possibilités de l’outil. Par exemple, vous serez en mesure de répondre à la question suivante :

« Pourquoi ce WebPart de requête de contenu a été utilisé dans une page donnée plutôt qu’un autre composant ou même qu’un développement personnalisé ? »

Nous avons trois réponses possibles:

  • A  J’ai lu sur un forum ou un blog que ce composant offrait plein de possibilités, je vais donc l’essayer.
  • B  J’ai compris les mécanismes et concepts en jeu dans SharePoint et suis certain que ce composant est la solution la plus adaptée à mon besoin.
  • C  Je suis une fougère (vous pouvez arrêter de lire ici dans le cas présent).

Il y a fort à parier que la réponse la plus appropriée sera « B » ! Ce guide vous accompagnera vers cette conclusion. Ma vision du métier:

Concevoir une application sous SharePoint (intranet, extranet, …) équivaut ni plus ni moins à faire de l’ingénierie logicielle classique, mais dans un cadre d’outil existant auquel il faut s’adapter.

C’est cette façon de voir le métier que je vous exposerai dans ce guide.

 Ce que vous y trouverez

  • Un schéma de réflexion logique pour concevoir vos applications, du besoin jusqu’à l’implémentation, en connaissance des possibilités et limitations de SharePoint (selon les versions).
  • L’explication de ces différentes solutions dans l’outil lors de la conception d’une solution.
  • Des exemples concrets.
 Ce que vous n’y trouverez pas

  • Des solutions toutes faites.
  • Comment configurer dans le détail une fonctionnalité ou un composant en particulier. Le Web regorge d’articles sur le sujet! (Cependant, vous trouverez à la fin du document des annexes techniques appuyant ou complétant certains points de méthodologie).
 À noter  Les versions de SharePoint abordées dans ce guide sont de 2007 à 2013, en passant par Office 365. Vous verrez que l’approche demeure fondamentalement la même dans tous les cas, seules les possibilités changent entre les versions.

A qui s’adresse-t-elle?

Elle s’adresse à toute personne qui possède des notions de base sur SharePoint (peu importe la version) et qui souhaite comprendre les étapes de conception  d’un projet liées à cette technologie et les contraintes inhérentes à celles-ci. Ce guide s’adresse principalement aux profils suivants :

  • Les analystes fonctionnelsarchitectes d’informations et développeurs qui mettent en place un projet SharePoint. Ce guide leur permettra :
    • D’adopter une démarche cadrée d’analyse fonctionnelle et de conception logicielle adaptée à SharePoint en se posant les bonnes questions.
    • De comprendre les mécanismes de SharePoint et d’identifier les solutions optimales disponibles dans l’outil en réponse à des situations connues (pour la plupart)
  • Les décideurs en informatique, qui désirent conjuguer des concepts « métier », compréhensibles par tous à des solutions technologiques dans SharePoint. Ils pourront :
    • Identifier clairement les besoins avant d’embarquer dans SharePoint.
    • Comprendre les étapes de conception d’un projet SharePoint et les contraintes associées à celui-ci.

Si vous ne connaissez pas du tout SharePoint, je vous recommande de vous familiariser avec cet outil par le biais de formations, de publications ou de programmes de mentorat. La lecture de ce guide vous paraîtra plus facile lorsque vous aurez acquis quelques notions de base.

Une règle simple : Gardez ça simple

Peut-être avez-vous déjà constaté que la plupart des projets SharePoint se ressemblent très fortement dans le principe (si ce n’est pas le cas, je vous expliquerai par la suite). Par conséquent, il est important de garder en tête les besoins réels des utilisateurs et de ne pas se laisser emballer par les nombreuses possibilités techniques de l’outil lors de la phase de conception. C’est un peu le piège SharePoint qui fait passer la phase d’analyse au second plan, favorisant une méthode empirique.

« Dites-moi ce que SharePoint peut faire et je vous dirais ce dont vous avez besoin… »

Lorsqu’on débute un projet SharePoint, il est important de se poser les bonnes questions et d’appliquer un cheminement logique de réflexion sur la base de questions fonctionnelles simples, intervenant dans le cadre du processus de conception du projet. En parallèle, il est nécessaire de comprendre certains mécanismes propres à SharePoint. Vous serez ainsi en mesure d’ajuster cette architecture, car n’oublions pas que nous devons nous adapter à l’outil dans tous les cas. Cette série d’articles propose en quelque sorte un amalgame entre ce que SharePoint peut faire, l’expression des besoins et la capacité à les modéliser et ce, de manière simple et concise.

SharePoint au cœur du processus agile

Une bonne façon de rester le plus simple possible est d’adopter une gestion de projet en mode agile, comme cela sera le cas dans ce guide. Appliquez cette réflexion sur l’histoire utilisateur sur laquelle vous travaillez, vous gagnerez en efficacité plutôt qu’en vous attaquant à la globalité. N’oubliez pas qu’un projet SharePoint est aussi un projet d’ingénierie logicielle à laquelle les méthodes agiles se prêtent très bien (attention, je ne parle ici que de la partie applicative).

Note importante

La présente série propose une approche personnelle de conception d’applications SharePoint basée sur l’expérience. Loin de prétendre être l’unique référence, ni même être totalement exhaustive, elle se concentre sur des points essentiels. Vous êtes bien sûr libres de les suivre en tout ou en partie.

Votre mémo sur la méthodologie

La méthodologie complète se présente de la manière suivante. Tout au long du document je m’appuierais sur un besoin concert pour illustrer les différents concepts à chaque étape. Il est intéressant de noter que toutes les étapes ne sont pas obligatoires. Voici donc votre mémo sur la méthodologie d’analyse fonctionnelle faite sur une fonctionnalité seule :

Définir le besoin

 Quel était votre besoin? Exemple: « Rechercher un projet »

Visualiser le besoin

 À quoi ressemble-t-il visuellement? 

Décrire l’information

 Quels sont les types d’informations s’y rattachant? 

Définir les relations entre les informations

 Quelles sont les relations entre ces types? 

Répartir l’information

 Comment sont-ils répartis logiquement dans la structure SharePoint? 

Déterminer le sens de circulation de l’information

 Quel est le sens de circulation des informations dans cette structure? Était-ce plutôt un flux de lecture, d’écriture ou les deux? 

Définir les points d’accès

 Où se trouvent les points d’accès à ces informations dans cette structure? 


Parmi tous ces points d’accès


Déterminer les critères de requête sur les informations

 Quelles sont les conditions de récupération de ces informations? Devaient-elles correspondre à la réalité à l’instant « t » dans SharePoint? Doivent-elles être triées? Possèdent-t-elles des contraintes de récupération hiérarchiques? Impliquent-t-elles des relations entre les types d’informations? Impliquent-t-elles une récupération supportant le multilinguisme? Les requêtes doivent-elles être réutilisables? 

Déterminer les comportements relationnels

 Quelles sont les contraintes relationnelles et les connexions entre ces informations? 

Définir l’affichage

 Quelles sont les informations à afficher aux utilisateurs? Devaient-elles être affichées de manière groupée ou unique? Si de manière groupée, devait-on les dissocier visuellement lors de l’affichage? 

Implémentation


+ There are no comments

Add yours