Commencez. C'est gratuit
ou s'inscrire avec votre adresse courriel
Rocket clouds
PDS M2 ISIDIS par Mind Map: PDS M2 ISIDIS

1. Fonctionnalités

1.1. Rescencement des clients actuels ou potentiels ( professionnels de santé), connaitre leurs relations et leurs environnements

1.1.1. Les informations saisies doivent être fiabilisées

1.2. Intégrer un agenda

1.2.1. Gestion des évenements

1.2.2. Calcul des disponibilités

1.3. Saisie d'un compte rendu du commercial

1.3.1. Qualité de la relation du client

1.3.2. Montant des ventes

1.4. Gestion de la concurrence (analyse de données relatives au secteur)

1.4.1. Statistique empirique

1.4.2. Etude de la concurrence

1.5. Détecter les clients potentiels

1.6. Gérer les appels d'offres

2. Acteurs : qui ?

2.1. Professionel de santé Privé

2.2. Professionel de santé Public

2.3. Distributeurs

2.4. Fabricants

3. Dispositif médicaux

3.1. Fournitures

3.1.1. Bandes

3.1.2. Pansements

3.1.3. Gants

3.1.4. Seringues

3.2. Instruments légers

3.2.1. Pinces

3.2.2. Ciseaux

3.2.3. Scalpel

3.3. Outils diagnostic

3.3.1. Stéthoscopes

3.3.2. Thermomètres

3.4. Mobilier

3.4.1. Table d'examen

3.5. Equipements

3.5.1. Léger

3.5.2. Lourd

4. Objectif du projet

4.1. Cocnevoir un CRM

4.1.1. Catalogue de produit

4.1.1.1. Bonus

4.1.1.1.1. Boutique en ligne

4.1.2. Définir des besoins génériques (pour tous les distributeurs)

4.2. Etude de l'existant

4.2.1. Etude du domaine de métier

5. UC provisoires

5.1. Gestion des portefeuilles client

5.2. Gestion de la concurrence

6. Contraintes

6.1. Supporting requirements avec des estimations réalistes

6.1.1. Volumétrie

6.1.2. Nombre de clients

6.2. Agenda

6.2.1. Ne pas implémenter un agenda (API)

6.2.2. Synchroniser avec agenda android

6.3. Acces au crm sans connexion internet(localt)

6.4. Découplage des traitements longs

6.5. Traitement transactionnel

6.6. Client asynchrone

6.7. Load balancing, fault telerance, horizontal scalability

6.8. Modèle d'architecture cloud

6.9. Notification protocole bi-directionnel

6.10. Réplication BDD

6.10.1. Doit être en haute disponibilité

6.10.2. Scalabilité verticale et horizontale

6.11. Mocker des données

6.12. Architecture logicielle téléphonie informatique préconisée

6.13. Gestion du cache doit être optimale

6.14. ISIN

6.14.1. A faire par les ISIN

6.14.1.1. Convergence téléphonie et informatique

6.14.1.2. Passer du nomade au sédentaire

6.14.1.3. Agenda android

6.14.2. Partenariat avec ISIN fortement valorisé

6.14.3. Se synchroniser avec ISIN : contrat

6.14.4. Indentifier interconnexions des implémentations

6.15. Implémentation API

6.15.1. Documenter l'api

6.15.2. Doit répondre à n'importe quelle demande

6.16. Système de fichier doit être répliqué

6.17. Outil de supervision et administration

6.17.1. JMX

6.18. Langages

6.18.1. Client lourd

6.18.1.1. Java et/ou C# et/ou C++ (recommandé)

6.18.2. Client léger

6.18.2.1. PHP, JAVA, ASPX, PYTHON et JavaScript (recommandé)

6.19. Revue de code

6.19.1. Une classe dev = une classe de test

7. Questions

7.1. Que fait chaque spécialité?

7.1.1. partie fonctionnelle pareil

7.1.2. Ihm sensiblemement pareil

7.1.3. tout le monde fait tout

7.2. Quels sont les protocoles bi-directionnel

7.3. Que veut dire "le couplage doit être le plus faible possible?"

7.3.1. Il faut découpler au maximum(api, composant réutilisable etc...)

7.3.1.1. (

7.4. Précision couplage téléphonie informatique

7.4.1. comment dialoguer avec la partie téléphonie?

7.5. Qui choisir pour définir les choses à faire avec les ISIN

7.6. Précision sur le prototype d'architecture logicielle générale

8. Next step

8.1. Demander à tout le monde son niveau de compétence pour chaque technologie

9. TACLE

9.1. DEMONSTRATION ECLIPSE = -10

9.2. DELAI DE REVUE DU CODE

9.3. DEPASSEMENT DU NOMBRE DE PAGE