Discussion :

[débutant_en_C]

bonjour,
quelqu'un peut m'expliquer c'est quoi les specs d'un projet?


merci

[homeostasie]

Cahier des charges où tu définis les points, les objectifs auquels tu te dois de tenir et de répondre dans les délais donnés.

Ca peut être des contraintes de temps (temps de réponse) si tu bosses dans le temps réel.

Il peut y avoir aussi une notion de cout lié aux composants qu'il faut choisir pour réaliser l'application, le système attendu.

En gros, ca consiste à définir et prévoir au mieux avant même de commencer du hardware ou du software.

[Gruik]

Les specs découlent du cahier des charges et definissent ce que doit faire le programme de façon plus formelle que le cahier des charges (qui lui est en langage naturel, donc totalement informel)

Comme moyen tres formel d'écrire les specs, il ya les headers .h, mais ça c'est plus qd on travaille en equipe et qu'on doit faire un module

[Emmanuel Delahaye]

bonjour,
quelqu'un peut m'expliquer c'est quoi les specs d'un projet?

http://emmanuel-delahaye.developpez....nformatique-c/

[Foobar1329]

Hello,

bonjour,
quelqu'un peut m'expliquer c'est quoi les specs d'un projet?


merci

Les spécifications ...

Plus sérieusement, pour des besoins exprimés par un client (ou contracteur), il s'agit de formaliser un ensemble d'exigences qui va conditionner la suite de la réalisation. Ce n'est pas propre à l'informatique.
Dans le domaine de l'informatique, tu a diverses exigences à respecter pour la réalisation, comme par exemple des contraintes de sécurité (confidentialité de données par exemple), de fiabilité/disponibilité (si tu entend parler de MTBF un jour, ca en fait partie, je te laisse chercher ce que c'est), de performances temporelles (ou plutôt de temps de réponse), de déterminisme, des exigences sur l'interface utiisateur si il y en a une, etc..etc.. Il y en a un paquet d'autres, cela dépend du type d'application attendu par le client.
Les specs consistent à recenser et à formaliser (exprimer techniquement les besoins du client) toutes les exigences. Celles-ci sont ensuite tracées souvent à l'aide d'une matrice pour vérifier qu'on les respecte bien tout au long de la réalisation.

Dans le domaine du développement informatique militaire, cette phase de spécifications est elle même formalisée par des standards qui fournissent un support pour l'ensemble du cycle de développement logiciel. Il y a par exemple le très connu DoD-STD-2167A (US).
http://www2.umassd.edu/SWPI/DOD/MIL-.../DOD2167A.html
Les documents correspondants aux specs sont la SRS et l'IRS. En France tu as aussi GAM T17.

Même si ça vaut le coup de regarder ce qu'est une SRS pour se faire une idée de ce qu'est une spec pour un logiciel, c'est du lourd et ça fait partie d'une méthodologie qui n'est pas facile à mettre en place (n'existe vraiment que dans les grandes entreprises, genre Thales).

Faire ses propres documents de spécifications est un bon exercice.

A+

[homeostasie]

Pour le logiciel, il y a la spec nommé STBL, qui signifie spécification technique des besoins logiciels dans laquille on peut présenter ces différents points:

1. Documentation de référence
2. Terminologies et sigles utilisées
3. Exigences

• Présentation des objectifs du logiciel
• Exigences fonctionnelles (Description des différentes fonctions à réalisées)
• Exigences opérationnelles (Environnement, mise en oeuvre)
• Interfaces (matériel, homme-machine, BDD...)
• Exigences concernant la conception et la réalisation (sécurité, programmation, outil de développment, facteur de qualité...)
• Tracabilité des exigences

Ensuite il y a le DAL( Document d'Architecture Logiciel) qui devient plus technique et explique la conception du logiciel bien lpus en détail.

[moon93]

merci, pour toutes ces explications. Vous avez pas des exemples concrets de specs pour des logiciels simple


merci

[Emmanuel Delahaye]

Vous avez pas des exemples concrets de specs pour des logiciels simple

Ben non. Tu n'as donc aucune imagination ? Ton cerveau est liquéfié ou quoi ? On est obligé de te macher tout le travail ? Tu ne fais jamais rien par toi même ?

[kate60]

quelles sont les spécifications matérielles et logicielles

[Emmanuel Delahaye]

quelles sont les spécifications matérielles et logicielles

Euh, tu parles de quoi ? A qui ?

[lepinekong]

bonjour,
quelqu'un peut m'expliquer c'est quoi les specs d'un projet?


merci

Le cahier des charges (le Quoi) étant donné par le client ou maîtrise d'ouvrage, les spécifications sont la réponse de la maîtrise d'oeuvre au premier c'est à dire le comment.

[Tommy31]

Le cahier des charges (le Quoi) étant donné par le client ou maîtrise d'ouvrage, les spécifications sont la réponse de la maîtrise d'oeuvre au premier c'est à dire le comment.

Non, c'est toujours du quoi, mais structuré et formalisé (et éventuellement selon un processus ou une méthodologie). Le comment vient après comme déjà dis plus haut.

[souviron34]

Le cahier des charges (le Quoi) étant donné par le client ou maîtrise d'ouvrage, les spécifications sont la réponse de la maîtrise d'oeuvre au premier c'est à dire le comment.

non, ceci est faux quand tu es dans une entreprise éditeur de logiciel ou de produit contenant un logiciel...




Dans ces cas-là, le Cahier des Charges est établi soit par le service Marketing soit par une étude approfondie par le CP..

[lepinekong]

Non, c'est toujours du quoi, mais structuré et formalisé (et éventuellement selon un processus ou une méthodologie). Le comment vient après comme déjà dis plus haut.

Je suis chef de projet depuis 15 ans et pratiqué aussi bien des standards internationaux que des méthodos maisons de grandes sociétés, ça tourne toujours autour des Requirements Specifications (Cahier des Charges en Français) et des Functional Specifications (Spécifications Fonctionnelles Détaillées).

Dans les grandes organisations, les services sont comme des centres de profit, l'un donne l'ordre, l'autre propose une solution comme si c'était un prestataire externe, cette solution c'est les spécifs fonctionnelles. Le service donneur d'ordre ne passera pas commande les yeux fermés, il veut savoir comment avant de signer. On ne parle pas évidemment de conception technique détaillée à ce stade (c'est du comment technique mais le client n'en a cure).

[Franck SORIANO]

non, ceci est faux quand tu es dans une entreprise éditeur de logiciel ou de produit contenant un logiciel...



Dans ces cas-là, le Cahier des Charges est établi soit par le service Marketing soit par une étude approfondie par le CP..

C'est jouer sur les mots. J'ai fait pratiquement toute ma carrière chez des éditeurs de logiciels.

Tu reçois un cahier des charges (ou une expression de besoins chacun l'appelle comme il veut) issu d'un chef de produit, d'un service marketing, de demandes d'évolutions formulées directement par tes clients, de remontés terrain des commerciaux, des techniciens, d'un délire du patron...

Bref tu as une demande issue d'un donneur d'ordres : la maitrise d'ouvrage. Cette demande est formulée dans un langage d'utilisateurs, avec de nombreuses imprécisions, contradictions, voeux pieux et demandes impossibles.

Côté R&D, tu analyses cette demande et tu rédiges les spécifications : C'est à dire la description précise, détaillée et exhaustive (du moins c'est la théorie ) de la solution que tu proposes de réaliser pour répondre aux besoins exprimés. Et tu l'as soumet à ton donneur d'ordres pour validation.

Après, appeler ça du "quoi" ou du "comment" je n'en vois pas trop l'intérêt. C'est du comment dans la mesure où tu décris "comment" tu vas répondre aux besoins.
Et c'est du "quoi" dans la mesure où tu décris ce que tu vas réaliser.

PS: Chez nous, le marketing est considéré comme le Client et les devs font l'objet de facturation interne auprès du service qui les demande.

[souviron34]

Et tu l'as soumet à ton donneur d'ordres pour validation.

je suis d'accord avec toi sauf sur ce point...



J'ai par exemple été CP il y a bien longtemps dans une entreprise qui fabriquait une machine d'IRM..

Le Cahier des Charges, c'est moi-même qui l'ai établi en parcourant les docs des concurrents, en allant voir des salles de radio dans des hôpitaux, en fouillant et en cherchant tout ce qu'il y avait de disponible comme docs (à l'époque il n'y a avait pas d'Internet).. et en me forçant justement à garde r un langage "d'utilisateur" et des contraintes "utilisateur" (exemple : faire un zoom panormaique à la vitesse de la souris")..

J'en ai ensuite tiré des specs systèmes, puis on fabrique le soft. On l'installe dans la machine. On teste avec un ou 2 utilisateurs, et en expérience in-vivo dans un hôpital..

Mais la "validation" se fait dans un salon intenrational, si les clients potntels sont intéressés, accrochés, etc etc..

Dans ces cas-là, tu n'as aucun "donneur d'ordre", et même le service Marketing ne valide pas grand'chose.. C'est uniquement les "clients" et le service après-vente qui valide et te demande (ou non) des modifs...




Ce que tu décriis correspond à un modèle "Watefall" d'une structure "logicielle" qui, bien que répandue, est justement une des raisons des échecs répétés d'un certain nombre de projets : le "donneur d'ordre", quand il existe, est rarement en mesure de valider ou non un logiciel..

Ce ne sera que les utilisateurs qui peuvent valider, et encore pas du tout comme s'y attendent les équipes logicielles "normales" :

aucune validation d'architecture, de BDD, etc et..


La seule validation possible (et souhaitable) est celle concernant la fonctionalité et "l'ergonomie" au sens large, c'est à dire le flux des informations et la suite des opérations...

Le reste est purement de la responsabilité informatique (avec des "input" marketing, par exemple sur le coût de telle ou telle solution)...

Mais en aucun cas (à mon avis) un "donneur d'ordre" ne doit "valider" de choses contenant des termes ou des définitions informatiques, sauf si c'est un autre service informatique...




Ce qui me choque relativement (et c'est pour ça que j'avais réagi au post de lepinekong) c'est que la notion de "client" ayant été étendue aux services internes, a contrario on oublie trop facilement que ce n'est pas un vrai client en général...

Et que donc ses "validations" ou "cahier des charges" sont à prendre avec des pincettes...

Dans le jargon des dernières années, on oublie trop souvent ceci, et c'est à mon avis une raison de la stagnation du nombre de succès (juste un petit tiers) des projets...



Mais cette discussion est un peu HS...

[lepinekong]

je suis d'accord avec toi sauf sur ce point...

J'ai par exemple été CP il y a bien longtemps dans une entreprise qui fabriquait une machine d'IRM..

Le Cahier des Charges, c'est moi-même qui l'ai établi en parcourant les docs des concurrents, en allant voir des salles de radio dans des hôpitaux, en fouillant et en cherchant tout ce qu'il y avait de disponible comme docs (à l'époque il n'y a avait pas d'Internet).. et en me forçant justement à garde r un langage "d'utilisateur" et des contraintes "utilisateur" (exemple : faire un zoom panormaique à la vitesse de la souris")..

Effectivement on ne parle pas du même contexte, je travaille essentiellement dans celui des Multinationales qui suivent des process normalisés.

Maintenant quand tu dis "le cahier des charges c'est toi-même qui l'a établi" c'est parce que tu es dans une trop petite organisation pour avoir un département marketing qui vont faire une étude de marché, faire l'étude de la concurrence etc., mais sur le principe t'essayes d'avoir de connaître ce que les clients veulent en étudiant les concurrents.

Mais la "validation" se fait dans un salon intenrational, si les clients potntels sont intéressés, accrochés, etc etc..

Dans ces cas-là, tu n'as aucun "donneur d'ordre", et même le service Marketing ne valide pas grand'chose.. C'est uniquement les "clients" et le service après-vente qui valide et te demande (ou non) des modifs...

Ce que tu décriis correspond à un modèle "Watefall" d'une structure "logicielle" qui, bien que répandue, est justement une des raisons des échecs répétés d'un certain nombre de projets : le "donneur d'ordre", quand il existe, est rarement en mesure de valider ou non un logiciel..

Ce ne sera que les utilisateurs qui peuvent valider, et encore pas du tout comme s'y attendent les équipes logicielles "normales" :

aucune validation d'architecture, de BDD, etc et..


La seule validation possible (et souhaitable) est celle concernant la fonctionalité et "l'ergonomie" au sens large, c'est à dire le flux des informations et la suite des opérations...

Le reste est purement de la responsabilité informatique (avec des "input" marketing, par exemple sur le coût de telle ou telle solution)...

Mais en aucun cas (à mon avis) un "donneur d'ordre" ne doit "valider" de choses contenant des termes ou des définitions informatiques, sauf si c'est un autre service informatique...

C'est pas moi que tu vas convaincre du contraire concernant Waterfall regardes ma signature. Mais c'est pas parce qu'on est en mode Agile que le donneur d'ordre ne donne pas son avis. Encore une fois je raisonne dans le contexte de grandes organisations.

Ce qui me choque relativement (et c'est pour ça que j'avais réagi au post de lepinekong) c'est que la notion de "client" ayant été étendue aux services internes, a contrario on oublie trop facilement que ce n'est pas un vrai client en général...

Et que donc ses "validations" ou "cahier des charges" sont à prendre avec des pincettes...

Dans le jargon des dernières années, on oublie trop souvent ceci, et c'est à mon avis une raison de la stagnation du nombre de succès (juste un petit tiers) des projets...

Je suis de l'Ecole de Deming (le gars qui a enseigné la Qualité aux Japonais, eh oui un américain envoyé par Mac Arthur peu de gens le savent) qui dit qu'il faut mettre en avant l'humain avant le produit ou l'argent pour que les équipes soient performantes, mais si les têtes en haut d'une grande organisation ne comprend pas ça, c'est pas le bas de la pyramide qui peut la soulever.

Donc ce n'est ni toi ni moi qui décidons Ce ne sont même plus les opérationnels qui ont leur mot final à dire dans les grosses sociétés, c'est la Finance. Rien n'empêche de les impliquer mais ceux qui ont l'expérience de grands comptes savent très bien que le moteur des décisions c'est la politique au nom bien sûr du bien être des utilisateurs. Se lamenter et le déplorer c'est une chose, changer les réalités en est une autre.

[Franck SORIANO]

je suis d'accord avec toi sauf sur ce point...

Je comprends bien ce que tu veux dire. Mais c'est qu'en même une première validation. Si tu as un trop grand gap entre ce que te demande ton donneur d'ordres et ce que tu réalises, tu te feras tapper sur les doigts avant même d'avoir pû soumettre ton travail aux véritables clients.

Et que donc ses "validations" ou "cahier des charges" sont à prendre avec des pincettes...

C'est sûr que c'est simplement un Go pour pouvoir lancer le dev... bien souvent ils te laissent faire mais ne veulent surtout pas s'engager sur quoi que ce soit (histoire de pouvoir te demander de tout refaire à la dernière minute sans que tu puisses dire quoi que ce soit).

Ce qui me choque relativement (et c'est pour ça que j'avais réagi au post de lepinekong) c'est que la notion de "client" ayant été étendue aux services internes, a contrario on oublie trop facilement que ce n'est pas un vrai client en général...

Là encore, je suis bien d'accord avec toi. J'avais l'habitude de travailler dans des PME où la R&D travaillait de concert avec tous les autres services pour satisfaire au mieu les clients.
Maintenant qu'on a été racheté, le marketing se substitue au client, et le dev devient : "le seul client qui existe pour la R&D c'est le marketing, donc tous ce qui compte c'est de faire plaisir au marketing". Ils veullent cette fonctionnalité, on le fait et tant pis si ça divise les perfs par deux et que finallement ça n'intéresse que le mec du marketing qui a pondu son délire.

Donc ce n'est ni toi ni moi qui décidons Ce ne sont même plus les opérationnels qui ont leur mot final à dire dans les grosses sociétés, c'est la Finance.

Ca c'est un peu caricatural. Maintenant je suis moi aussi dans une grosse multinationnal (il parait qu'on réalise un CA mondial qui est le double de celui d'Oracle).
Les financiers jouent un rôle très important, mais ils se contentent d'accorder les budgets que tu demandes.
De plus, lorsque le produit passe en maintenance, tu as un budget récurrent que tu dépenses plus ou moins comme tu veux pour faire vivre le produit et respecter les objectifs de vente.
Les financiers ne viendront mettre leur grain de sel que si tu réclames un budget supplémentaire pour un développement exceptionnel (ou si tu ne tiens pas tes objectifs...).

Un petit exemple : cette année on nous a fixé un gros objectif de migration. On doit migrer un grand nombre de clients qui utilisaient un ancien produit vers un nouveau.
Cet objectif nous ammène à une contrainte : Chaque technicien doit pouvoir réaliser trois migrations par jours.
A partir de là, j'ai décidé qu'il fallait refaire le programme d'installation, développer un utilitaire de migration de données... J'ai définit mes propres specs, je les ai faites valider par les techniciens qui allaient faire les installations (bon d'accord, j'ai fait le dev et je leur ait demandé ce qu'ils voulaient que j'adapte )
Le tout en total autonomie. La direction et les financiers ne regardent qu'une seule chose : Est-ce qu'on va pouvoir tenir l'objectif, est-ce que les opérationnels sont satisafaits des outils fournis par la R&D et peuvent faire leur travail en toute sérénité.

[souviron34]

Ce ne sont même plus les opérationnels qui ont leur mot final à dire dans les grosses sociétés, c'est la Finance.

C'est pour ça que ça fait maintenant 21 ans que j'ai quiité les grosses sociétés, et que j'ai toujours refusé les postes qu'on m'y proposait..

Je n'ai jamais compris comme argument de vente "nous sommes un des plus gros leaders du secteur (+ XX milliers d'employés)"...

Pour moi c'est plus une indication de ne pas candidater que d'y aspirer...

Mais faut dire que j'ai eu de la chance : ma première boîte privée était une gigantesque multinationale française (+300 000 salariés), et quand j'y ai vu que le Directeur d'une des Diviisions (+ 8500 salariés sous ses ordres, 55 usines dans le monde) était averti d'un changement profond dans SA division par le journal télé , ça m'a dépucelé.. J'avais 29 ans, et j'ai compris....

Rien n'empêche de les impliquer mais ceux qui ont l'expérience de grands comptes

ça ça m'énerve en France : "les grands comptes", "les institutionnels"...


C'est parce que c'est le domaine réservé des gros.. En France...

Au Canada, tout seul, en auto-entrepreneur, j'ai eu accès à "un grand compte" : le Gouvernement Fédéral... Et seul responsable/fournisseur d'un logiciel pour un Ministère Fédéral... sans assurances particulières, sans être en SARL, etc etc....


(rien contre toi, hein .. C'est l'expression qui m'énerve)