PRESENTATION | TECHNOLOGIES ET PROJETS | OFFRE | OFFRE WEB | OPTEAMIST | DOCUMENTS
 
Grands comptes et PME

Exemples de réalisations en offshore programming pour des grands comptes
  • Développement de toute une base clients sous Lotus Notes, avec reprise d'un existant sous Access
  • Développement d'un agenda pour toutes les agences régionales d'une grande société française; l'agenda doit être accessible par client Lotus Notes et par navigateur Internet.
  • Réalisation d'une interface entre les agences locales d'une grande société française et le système central des dossiers clients.
  • Développement de bases de données.
  • "traduction" de logiciels en Java.
  • Interfaces, migrations de bases.
  • Redéveloppement en architecture trois tiers.
  • Logiciels RH.

Exemples de réalisations pour des PME
  • Développement de divers sites Web de commerce électronique.
  • Développement du site Web d'une société de transport permettant aux clients de l'entreprise le suivi de leurs transports.
  • Refonte de sites Internet (php-->asp; php --> jsp; SQLServer --> Oracle; Lotus --> SQLServer, etc..)
  • Réalisation de back office de sites permettant la gestion des clients, des produits, des appels d'offres, des commandes, des stocks, des demandes, etc..
  • Implémentation de caddies, d'historiques clients, de "têtes de gondoles", de processus de suivi des commandes pour le client, etc..
  • diverses places de marché

Proposition de plan d'un Cdc pour un petit projet (50/150 jours) dans la perspective d'un développement en offshore programming
  1. Objectifs du Cdc
    Précisez notamment le NIVEAU D'OBJECTIF. Est-ce un objectif de niveau " stratégique " nécessitant encore de la réflexion ou un objectif à court terme donc nécessitant rapidité d'exécution. Ceci vous aidera à apprécier le degré de détails nécessaires, qui n'est pas forcément élevé en offshore programming.

  2. Limites et nature du système décrit
    Ne négligez pas cette partie qui peut changer notablement la complexité et la réalisation de votre projet. S'agit-il de créer un logiciel, une interface, un back-office, un extranet, un intranet ? Cette question n'est souvent pas anodine au moins tant que les différents intervenants n'auront pas les mêmes définitions de ces termes.
    Autre type d'erreur dans la nature du système décrit : avez-vous décrit le fonctionnement et les processus de l'entreprise elle-même (processus et fonctionnements qui doivent être informatisés) ou du système d'information que vous souhaitez en ayant déjà enlevé ce qui ne le concerne pas ?
    La question des limites du système est-elle aussi cruciale. N'hésitez pas à créer 2 colonnes dans le projet/hors du projet pour bien en identifier les limites. Petits exemples standards de problème à ce niveau : La gestion de l'impression de certains document est-elle gérée ou pas par le système ? La vérification des connectés au système est-elle gérée ou pas par le système ? La sécurité des transactions est elle à prendre en compte ?
    En offshore programming, ne cherchez pas tant à décrire une boite blanche qu'une boite noire.

  3. Lecteurs et intervenants
    Préciser qui sont les lecteurs vous aidera (et réciproquement) à définir les objectifs du Cdc et à déterminer le style et le niveau de détails de celui-ci, notamment en offshore programming.
    Les " intervenants " sont en plus des " acteurs " du système, ceux qui auront une action dans sa création (qui sont lecteurs aussi a priori) mais aussi dans son installation (attention, informer par exemple au tout dernier moment un administrateur réseau d'une réalisation peut provoquer des surprises au niveau de ce qui est permis ou pas )

  4. Terminologie employée (important en offshore programming)
    Certains termes ou abréviations doivent être définis ici pour :
    · parler de la même chose quand les lecteurs poseront des questions (par exemple des mots comme " e-learning " ou " asp " ont des définitions différentes pour différentes personnes).
    · éviter d'avoir à écrire plusieurs mots quand une abréviation suffit.

  5. Exigences techniques
    1. Avec quels systèmes, ce système s'interfacera-t-il et dans quelles conditions ?
    2. Quelles sont les technologies préconisées ?
    3. Quelles sont les performances attendues ?
    4. Quelles sont les contraintes techniques ?
    5. Dans le cadre d'un développement en offshore prgramming, bien mentionnner les versions du logiciel (souvent les développeurs d'une plate forme d'offshore programming utilisent la version internationalle du software de développement).

  6. Cas d'utilisations
    1. Acteurs principaux du système
    2. Scénario général
    3. Cas d'utilisations
      1. C1
      2. C2
      3. C3
      4. ...

  7. Quelle documentation doit être fournie ?
    Ce point est important car la documentation prend un temps non négligeable dans un développement. Un code très documenté prend jusqu'à 20% en plus de temps de développement. Des documents annexes comme les très bons modèles de " Software Development Plan " ou " Architecture Development Plan " de Rational sont très utiles à un dépôt de brevet, de propriété ou pour des investisseurs mais prennent aussi du temps à être réalisés. Ces documents sont pourtant très utiles et pratiques (surtout depuis l'arrivée d'UML) si vous voulez faire ensuite reprendre la maintenance par un autre prestataire.

  8. Quelles questions non résolues sont reportées à plus tard et quand
    Cette partie est nécessaire, mais il est préférable de ne pas y mettre trop d'éléments.

  9. Questions humaines
    Ce paragraphe est vital pour un développement réussi, surtout au forfait. Les problèmes de délais, de dépassement et autres arrivent parce qu'à la base la communication ou la compréhension des différents intervenants du projet est mauvaise. Soit entre les utilisateurs finaux et le rédacteur du Cdc, soit entre le donneur d'ordre et le prestataire, soit à l'intérieur du prestataire, soit à l'intérieur du donneur d'ordres. Combien, par exemple, de projets traînent en longueur car le prestataire n'a pas de " répondeur " aux questions identifiées chez le donneur d'ordre?
    1. Qui sont les contacts pour le projet ?
    2. Qui seront les utilisateurs du système ?
    3. Y a-t-il un besoin de formation ?

  10. La réalisation du système a-t-elle des risques ou impacts ou nécessités juridiques ?
  11. Délais souhaitables
    Il est souhaitable d'indiquer au prestataire les délais souhaités car le délai n'est malheureusement pas en développement une fonction linéaire du nombre de personnes qui travaillent sur le projet.
    De plus, indiquer ceci dans le cdc permettra d'avoir sur la même longueur d'onde tous les lecteurs du document.
Copyright © Tubbydev Offshore Programming 2000 - 2010 Contact | English version