Olivier Ridoux

The Art of Picopoly

The various forms of handouts in university studies cover a large spectrum from complete reference texts to cheat-sheets. We present our experiences in very compact handouts, "pico" handouts, that we call "picopoly" in French. We have been using them consistently in various learning formats, from full semester modules to conferences, and in very different domains, from epistemology to algorithmics. The initial aim was to clarify for the students the expected inputs, i.e. prerequisites and context knowledge, and outputs, i.e. learning outcomes. Very compact, they only give an overview of these inputs and outputs, but they are intended as maps of territories that will be explored during the learning experience.

Introduction

The forms of handouts in university studies go from complete reference texts to cheat-sheets, including exercise sheets, practical work instructions, or printed copies of slideshows, etc. Each form assumes a different role for the handout, but our experience is that very often the form is not really chosen on purpose but simply out of local traditions and personal feelings. For instance, an institution or a student association may assume that a copy of a slideshow is a mandatory part of the handout package. Note that even assuming that a slideshow exists is another cliché since the actual relevance of a slideshow is highly dependent on domains and personal approaches. Among personal feelings is the fear that too complete handouts will favor absenteeism. This often leads to handout strategies where copies of slideshows are distributed after the corresponding lecture. We believe that nobody should be incriminated in particular, because all parties, the teachers, the students, and the institutions, are equally driven by parasitic feelings. Students want to be reassured by a lot of documentation, teachers want to be reassured that students are not dissatisfied, and the institutions are happy that everybody is happy. Several articles describe these ambiguities and conflicting views on handouts [START_REF] Nelson-Wong | Influence of presentation handout completeness on student learning in a physical therapy curriculum[END_REF][START_REF] Mclennan | The role of handouts, note-taking and overhead transparencies in veterinary science lectures[END_REF]. Some even conclude that there is no evidence that the mode of distribution of handouts, and even their very existence, has a measurable effect [START_REF] Babu | The role of structured handouts in improving the teaching learning process of final year MBBS students[END_REF][START_REF] Marsh | Access to handouts of presentation slides during lecture: Consequences for learning[END_REF]. They often describe these phenomena from the point of view of one teaching discipline or one teaching level, but we believe these observations can be generalized to most disciplines and levels.

Altogether, we consider that even if the only effect of handouts is to make everybody happy, it is a useful effect. However, what we want to do is to go further than using handouts as a reassuring balm, but rather to use them in a global strategy.

The day-to-day teaching experience shows that this tradition-laden approach to university teaching causes severe anomalies. We focus on two of them, namely the lack of agreement on prerequisites and context knowledge, and the lack of agreement on learning outcomes. This leads to contentious situations in which all the unsaid assumptions make surface.

The lack of agreement on prerequisites and context knowledge leads to situations where teachers complain that the education level is decreasing (eg. measured by results of teaching interactions or by the results of homeworks), or students complain that the course is too difficult, too abstract, too ... The standard institutional answer to this is to make explicit the dependencies between courses, e.g. CS101 is a prerequisite to CS205. However, this does not work very well because it ignores the fact that most students pass final exams with gaps in their acquisitions, and that all the outcomes of the first course are not used as prerequisites to the second course. This also ignores the fact that mobility students may have studied a different first course, or even a really different cursus that has been validated as a whole as roughly equivalent to the CS1 cursus. This shows that the institutional communication on course dependencies is not precise enough. However, we believe that institutions do their part fine. It is not the institutions that should make there documentation more precise, because it would not be the proper level of detail for their purpose. It is the course teacher in her 1 own documentation who should be more explicit.

The lack of agreement on the learning outcomes leads to situations where teachers complain that the education level is decreasing (eg. measured as the results of the final exam), or students complain that the exams was unfair. A crude manifestation of this is when a fellow teacher is worried by her next exam subject, and suddenly is very happy to have found a bright idea, a "very interesting" subject. It is in fact "Chronicle of a Death Foretold" [START_REF] García | Crónica de una muerte anunciada[END_REF]! An exam should not be "interesting" to the teacher, but it must be fair with the students. To be fair is to be faithful with some explicit contract.

Our answer to these two anomalies is to develop a compact format of handouts that presents on one side the prerequisites, and on the other side an overview of the outcomes. We have called this format a "picopoly" from the SI2 prefix "pico" (itself derived from Italian "piccolo", small, and Spanish "pico", sharp), and the French diminutive for "polycopié", a handout. We then build a global strategy in which the picopoly is used during teaching, including preparation of evaluation.

The folding

The structure of a picopoly is made of a single sheet of paper folded as shown in Figure 1 and2.

Figure 1 shows the structure of a picopoly before folding it. Fold lines (mountain folds as red dotted lines, and valley folds as grey dotted lines) mark the borders of 8 pages. The numbers in the figure show the pagination and the orientation of pages. The solid red segment marks a slot that must be opened in the paper sheet.

Figure 2 shows the folding itself. Again, numbers represent pages. This folding belongs to folklore, sometimes called "hotdog" booklet, and it is used as a routine in many primary schools to initiate children to the joy of in-folio composition. It is also often called "origami" booklet, though it would be preferable to call it "kirigami" booklet, because of the cut in the paper.

It is readily apparent that once folded a face of the paper sheet is hidden. We call it the verso side. The visible face is the recto side. In usual instances of the hotdog booklet folding, the verso side is simply wasted. Instead of a flaw we make of this accessibility difference a feature. The verso face is used to present the prerequisites or context knowledge, and the recto face is used for the learning outcomes. The inputs become what is readily accessible before folding, and the output is what is accessible after folding. Thus, folding is kind of a metaphor for preparing the course.

Next two sections explain how we have chosen to inhabit the physical constraints of the hotdog booklet format. It constitutes our design rules for picopolies.

The recto side -8 pages

The recto face is paginated, and we chose to use that as a strict guide to redaction. Page 1 is the front page, with a title, authorship, and introduction/motivations. Page 8 is the back page, with a conclusion and bibliography. Remains 6 pages for an overview of the subject. This is the first of the main two difficulties in composing a picopoly. Indeed, we prefer to align the structure of the overview on the 6 pages, which leads to 6 sub-subjects, which might not be so natural at first sight. So a large part of the reflection required to prepare a picopoly is how to align the subject on 6 equally-sized pages. This can be relaxed by accepting that two facing pages treat a same subject, or that one page treats 2 small sub-subjects.

Picopolies are printed in A3 3 , 29.7 cm × 42.0 cm. Texts are composed in 8 pt, using a sans-serif police. That sounds small but experience shows it can be read comfortably, especially because pages are small. Pages are 14.8 cm high and 10.5 cm wide (equivalent to A6: A3 area divided by 8). Left, right and top margins are about 0.5 cm. Bottom margin is 1.0 cm to allow for page numbers.

Since folding lines are marked on the paginated face, it is important that they fall in their exact due position. However, their is a technical difficulty with many printers. They add a margin, called technical margin, and they reduce the document to fit in what remains of the physical size of the sheet of paper minus the technical margin. This process slightly changes the proportions of the printed document. The mid-width fold and the mid-length fold will be correct if the technical margin is the same along each border. However, the quarter-length folds (e.g. between pages 6 and 7) will be off-position. A solution is to anticipate the technical margin, but it is a never-ending story because technical margins depend too much on the printer. Another solution is to find a printer that do not add any technical margin, or a printer pilot that format the document to the physical dimensions of the paper sheet. In the latter case, a technical margin may still exist, but it is taken from the document instead of being taken from the sheet of paper. It is the solution we have chosen, calibrating the picopoly margins so that it corresponds to the technical margin.

As a basis, we decided that texts can be highlighted in one of two colors:

• a faded blue, mainly for definitions and highlighted terms;

• a faded red, mainly for examples, and opposition with other highlighted terms (e.g. this and not that).

More colors could be used, but we try to limit to two. All highlighted text is composed in bold to compensate for the faded shades of colors, and for accessibility to colour-blind people.

Underlining or boldface are never used as such in paragraphs. Page titles are composed in 10 pt bold.

Most of our experience with picopolies is for courses in computer science curriculae. As is usual in this discipline, we also use courier police for programlike texts (texts that are meant to be presented as it to a computer system), and italics for specification texts.

Page limits are marked grey or red, according to how they should be folded: red for mountain folds, and grey for valley folds. At the point where pages 1, 2, 3 and 8 meet, a red dot is printed, as well as at the point where pages 4, 5, 6 and 7 meet. They delimit the slot that must be cut between pages 8-7 and 3-4.

The verso side -a mosaic of text items

On the opposite, the verso page is not paginated, and we chose to compose it as a mosaic of small items (tiles). We think it is in accordance with the role of this page which addresses a reader whom we do not know precisely the actual background. Composing this page is the second difficulty. It forces to lay down what are the precise prerequisites or useful context knowledge. Tiles from different themes are filled in with different colors. Tiles from a given theme have the same color, and they are numbered to help finding one's way in the mosaic. Reading and folding instructions are written on top of the page, including the key for background colors.

Tile texts are composed using the same rules as page texts, except for the dimensions of the tiles. In effect, tiles are often rectangular, in a landscape orientation, but not always. Some tiles are even not rectangular. Some tiles are large, other very small. They are not meant to be read in a strict order, but they are partially numbered to help the reader who wants to read the whole text. A secondary difficulty is to design the tiles so that they pave the page as exactly as possible. A difficulty in the difficulty is to try to ensure that the slot cut in the page does not go through text.

Usage

The student

The role attributed to the reader is twice. First, she must read the verso page, the prerequisites or context knowledge, before folding, and acknowledge whether she already knows the recalled notions. If she acknowledges she does, all is right, but the reader is warned that these notions are important to start the course. She is also warned of the actual notations/definitions that will be in use during the course. If the reader acknowledges she does not know/remember a notion, she is invited to search by herself some help to acquire the notion. The help could be a book, a tutorial, a video, a friend, etc. To give the substance of all prerequisites is not the goal of the verso page. It is only a kind of autotest.

After folding the picopoly, the second role of the reader is to browse the course overview. She must read it as a tourist reads a map, or as an aviator contemplates a bird view of a territory. It is normal to not understand everything at first sight, but as the course progresses the reader should understand more and more. So, the overview part is also a kind of autotest. The contract is that though not everything is given in full details in the overview, it must be faithful to the actual content of the course.

The teacher

As for the teacher side, picopolies are not meant to replace all other handouts. They are more like a vademecum to accompany the other documents. We use them alongside copies of slideshows, exercise sheets, instructions for practical works, etc. However, while all other handouts are sequence, or even event, oriented, the picopoly gives the broad picture of the entire course. To be consistent with this role we use it at a reference frame to mark the progress of the course or the important use of some prerequisite. Hence, we use the picopoly as a map: "here we are", "now, we are entering this area", etc. Note that in our usage, the picopolies are the only paper printed handouts; all other documents are available in electronic form right from the beginning of the course.

There is a debate on whether distributing handouts arms note-taking and memorization abilities. The debate may focus on the very existence of handouts, their completeness, or the moment they are distributed (before or after the lectures). We believe that if note-taking and memorization are considered a desired ability (as we do), the best is to incorporate them in the teaching and evaluation process. We refuse to consider that such operational ability is a prerequisite, because it would be avoiding the issue and charging our predecessor level colleagues of all responsibilities. As a general rule, we believe it is never too late to acquire these kinds of operational abilities, including spelling and argumentation.

So, we first explain the articulation between handouts, lectures, and notetaking, and between all documents and a memory aid or cheat-sheet. In particular, we explain that the picopoly is definitely not a good memory aid because of its bird view position. The global picture should be remembered by the students, but we agree that some technical details may need a memory aid. We do not like the cheat part of cheat-sheet as it seems to imply an immoral stance, but we insist on the aid part of memory aid as it implies an auxiliary role to an existing memory. Second, we organize exams on the closed-book mode with personal hand-written memory aids allowed. A study [START_REF] De | Student created cheat-sheets in examinations: impact on student outcomes[END_REF] shows it is an effective compromise between closed-and open-book modes.

We do not evaluate the memory aids per se, because we think it is a very personal affair with the student and herself, but being in a continuous assessment framework, we comment after each control on the memory aids we have seen. For instance, we observe that first memory aids are often dense unstructured texts. After having commented on the possibility to use more visual tools like tables, diagrams, mind-maps, etc., we observe that the students adopt progressively a mixed approach, sometimes very creative, that combines different tools for what they are the most useful to. In doing so, we believe we helped students in developing their note-taking and memorizing ability.

Very often, students observe themselves that they did not need use their memory aid during the exam. It is the paradox of hand-writing a memory aid. The very effort and concentration needed for writing it helps in memorizing [START_REF] Bui | Note-taking with computers: Exploring alternative strategies for improved recall[END_REF][START_REF] Mueller | The pen is mightier than the keyboard: Advantages of longhand over laptop note taking[END_REF]. Some authors even show that it stimulates specific brain activities [START_REF] James | The effects of handwriting experience on functional brain development in pre-literate children[END_REF].

Though the initial motivation for picopolies was to clarify the prerequisites and outcomes of an entire course, we departed slightly from this initial role by designing picopolies for parts of courses, or even picopolies for specific prerequisites. In the later case, the verso will be devoted to context knowledge, and the recto will present the great lines of the prerequisites. We also often distribute to mobility students the picopolies of the courses they did not follow but are prerequisites to courses that they will follow.

We noticed an interest about the picopoly format from the students. This cannot come from the content since it is plain academic content in a rather terse form! We believe it comes from the form itself that intrigues the reader. We also noticed that many students are puzzled by the folding. In fact, we believe it transgresses a tacit line that separates intellectual skills from manual skills. It is something we already observed when instructing students to design tangible models (e.g. made of building blocks, or of cans and straws) of abstract concepts (e.g. a file system, or a Turing machine). We think this transgression is a positive by-product. Finally, we observed that most students used to picopolies expect the next course will also handout picopolies. Some students with the sense of collection even bind together the whole set of picopolies.

Two examples

We present two examples of picopolies. Their two sides are included as illustration only to give a concrete perception of their organization. They are not Prérequis : lire, comprendre, apprendre, puis procéder au pliage. Pliage : autre face dessus, traits gris rentrants, traits rouges saillants. Découper selon le trait rouge entre les deux , puis achever le pliage.

N'oubliez jamais !

Un modèle est toujours imparfait, parfois utile, et c'est tout ce qu'on peut lui demander (d'après George Box 1978, voir aussi a contrario les cartes à l'échelle 1/1 de Jorge Luis Borges 1946 et Lewis Carroll 1893, si parfaites qu'elles sont inutiles).

L'informatique ne travaille que sur la représentation des choses. Il faut toujours se demander ce qui a du sens par rapport à ce qui est représenté.

1⃣ ⃣ Théorie naïve des ensembles

Un ensemble est une collection d'objets où le rang et la multiplicité ne comptent pas. On appelle éléments les objets de la collection, et on dit qu'un élément appartient à un ensemble. Cela se note e ∈ ∈ E pour « e appartient à E », et e, e' ∈ ∈ E pour « e eteé appartiennent à E ».

On note une collection entre accolades ({…}). Ex. {a, b, c} est une collection, et puisque le rang ne compte pas, la collection {b, c, a} dénote le même ensemble, et puisque la multiplicité ne compte pas non plus, la collection {a, b, a, c} dénote encore le même ensemble.

Dans la théorie naïve des ensembles on ne considère que des objets qu'il est toujours possible de distinguer les uns des autres, mais à part cela n'importe quoi peut être un objet, y compris un ensemble.

Une collection vide, {}, constitue un ensemble particulier qu'on appelle l'ensemble vide, et qu'on note ∅ ∅ ou {}. Il n'y a qu'un ensemble vide. On appelle singleton un ensemble qui n'a qu'un élément. L'ensemble {∅ ∅} est donc un singleton. Ne pas confondre l'élément a et le singleton {a}. Les confondre revient à commettre une erreur de type en programmation. Ne pas confondre non plus ∅ ∅ et {∅ ∅}.

La collection des éléments d'un ensemble s'appelle l'extension de l'ensemble. On peut aussi spécifier les éléments d'un ensemble par une propriété qui les distingue de ceux qui n'appartiennent pas à l'ensemble. Cette propriété s'appelle l'intension de l'ensemble (l'intenSion n'a rien à voir avec l'intenTion, ou dessein). On exprime une intension soit par une phrase en prenant le risque d'être imprécis ou ambigu, soit par une formule logique en prenant le risque d'être fastidieux. N'importe quelle formule logique fausse (contradictoire ou absurde) est l'intension de ∅ ∅.

Ex. « les lettres communes aux mots ``bancal'' et ``tabac'' » est une intension possible pour l'ensemble constitué de la collection {a, b, c}. Les « 3 premières lettres de l'alphabet » est une intension équivalente. Un ensemble peut avoir de nombreuses intensions, certaines même difficiles à comparer.

Si tous les éléments d'un ensemble E1 appartiennent à un ensemble E2, on dit que E1 est inclus dans E2, et on note E1 ⊂ ⊂ E2. On dit aussi que E1 est un sous-ensemble ou une partie de E2. On note E1 ⊊ ⊊ E2 pour signifier l'inclusion sans égalité possible (on parle alors de sous-ensemble strict), et E1 ⊆ ⊆ E2 pour insister sur l'égalité possible.

2⃣ ⃣ Algèbre des ensembles

2⃣ ⃣ Idiomes logiques

En pratique, on n'utilise pas n'importe quelle formule de la logique des prédicats. On a tendance à utiliser des expressions idiomatiques qu'il convient de reconnaître et interpréter correctement au premier coup d'oeil.

Quantifications dans un domaine : Très souvent, on écrit des formules comme ∀ ∀x ∈ ∈ E . f f(x) ou ∀ ∀x tq y y(x) . f f(x). C'est une façon de dire dans quel domaine doit être évaluée la quantification. Ces formules doivent être lues

∀ ∀x . [x ∈ ∈ E ⟹ ⟹ f f(x)] et ∀ ∀x . [y y(x) ⟹ ⟹ f f(x)]
. Une conséquence directe est qu'une quantification universelle sur un domaine vide est trivialement vraie. Cela paraît une situation étrange, mais c'est banal en informatique, spécialement quand on considère les cas d'initialisation : ex. Tous les utilisateurs sont … lorsqu'il n'y a pas d'utilisateurs. De la même façon, on écrit des formules comme ∃ ∃x ∈ ∈ E . f f(x) ou ∃ ∃x tq y y(x) . f f(x). Ces formules doivent être lues

∃ ∃x . [x ∈ ∈ E ∧ ∧ f f(x)] et ∃ ∃x . [y y(x) ∧ ∧ f f(x)].
On voit alors qu'une quantification existentielle sur un domaine vide est trivialement fausse.

Cascades d'implications :

On écrit parfois des formules comme f f1 ⇒ ⇒ f f2 ⇒ ⇒ f f3, qui pourrait être lue soit (f f1 ⇒ ⇒ f f2) ⇒ ⇒ f f3 soit f f1 ⇒ ⇒ (f f2 ⇒ ⇒ f f3). Dans le premier cas, on exprime que f f1 ⇒ ⇒ f f2 est un théorème qui pourrait servir à démontrer f f3. Dans le second cas, la formule est équivalente à

(f f1 ∧ ∧ f f2) ⇒ ⇒ f f3, donc (f f2 ∧ ∧ f f1) ⇒ ⇒ f f3, et donc f f2 ⇒ ⇒ (f f1 ⇒ ⇒ f f3
• ¬ ¬ ( (f f1 ∧ ∧ f f2) est équivalent à ¬ ¬ f f1 ∨ ∨ ¬ ¬ f f2 et ¬ ¬ ( (f f1 ∨ ∨ f f2) est équivalent à ¬ ¬ f f1 ∧ ∧ ¬ ¬ f f2 . • ¬ ¬ ( (f f1 ⇒ ⇒ f f2 ) est équivalent à f f1 ∧ ∧ ¬ ¬ f f2 . • ¬ ¬¬ ¬ f f est équivalent à f f.
Pose beaucoup plus de difficultés que la taille de l'identité ne le laisse penser, mais est vrai pour la logique usuelle. Se rappeler combien nous humains sommes peu doués pour les doubles négations.

• ¬ ¬ ∀ ∀ x . f f(x) est équivalent à ∃ ∃ x . ¬ ¬ f f (x) et ¬ ¬ ∃ ∃ x . f f (x) est équivalent à ∀ ∀ x . ¬ ¬ f f(x) .
Cascades de quantifications : On imbrique souvent les quantifications. Certaines imbrications doivent faire réfléchir, et d'autres moins.

• ∃ ∃x . ∃ ∃y . f f (x, y) est équivalent à ∃ ∃y . ∃ ∃x . f f (x, y) et on note souvent ∃ ∃x, y . f f (x, y). • ∀ ∀x . ∀ ∀y . f f (x, y) est équivalent à ∀ ∀y . ∀ ∀x . f f (x, y) et on note souvent ∀ ∀x, y . f f (x, y).
• ∀ ∀x . ∃ ∃y . f f (x, y) exprime que pour chaque x il y a un y, qui peut dépendre de x, qui a la propriété désirée. Ex. dans ∀ ∀x . ∃ ∃y . x × × y = 0, le même y convient pour tous les x, mais dans ∀ ∀x . ∃ ∃y . x × × y = 1, à tout x correspond un y différent. Un y existentiel est donc implicitement une fonction de tous les x universels qui le précèdent.

• ∃ ∃x . ∀ ∀y . f f (x, y) exprime qu'un x unique a la propriété désirée pour tous les y. Ex. ∃ ∃x . ∀ ∀y . x × × y = 0 est vrai, mais pas ∃ ∃x . ∀ ∀y . x × × y = 1.

• ∃ ∃x . [y y ⩙ ⩙ f f(x)] est équivalent à y y ⩙ ⩙ ∃ ∃x . f f(x) et ∀ ∀x . [y y ⩙ ⩙ f f(x)] est équivalent à y y ⩙ ⩙ ∀ ∀x . f f(x) si x n'apparaît pas dans y y, et ⩙ ⩙ représente ∧ ∧ ou ∨ ∨.

1⃣ ⃣ Logique des prédicats

Dans sa définition la plus naïve la logique des prédicats est la formalisation de la logique employée tous les jours dans les activités un peu scientifiques. Elle permet d'exprimer des jugements sous forme de formules, et de décider formellement si elles sont vraies ou fausses. Les formules de la logique des prédicats sont définies de la façon suivante :

Prédicats atomiques (ou atomes) : Ce sont des formules élémentaires qui expriment des jugements sur des objets. Nous ne nous prononçons pas sur la notation à employer dans les atomes ; cela n'a pas vraiment d'importance. Par exemple,

• Rennes est une capitale, où Rennes est l'objet du jugement et être une capitale en est le prédicat.

• Rennes est la capitale de la France, où Rennes et la France sont des objets et être la capitale de est le prédicat.

• x > y, où x et y sont les objets, et où > (être plus grand que) est le prédicat du jugement.

• 1273 + 556 est un nombre premier, où 1273 + 556 est l'objet et être un nombre premier est le prédicat.

• Le Grand théorème de Fermat est vrai, où le Grand théorème de Fermat est l'objet et être vrai est le prédicat.

• P P ≠ ≠ N NP P, où P P et N NP P sont les objets et ≠ ≠ (être différent) le prédicat. On peut attribuer une valeur de vérité, Vrai ou Faux, à un atome, en se référant à une réalité de terrain, comme pour Rennes, à des théories et des calculs, comme pour la primalité de 1273 + 556, ou à des preuves externes, comme celle du grand théorème de Fermat. Parfois on ne peut pas, par manque d'information, comme pour x > y, ou parce qu'on ne sait vraiment pas, comme pour P P ≠ ≠ N NP P.

Formules propositionnelles : Ce sont des formules, élémentaires ou non, qui sont reliées par des connecteurs logiques, généralement ∧ ∧, ∨ ∨, ¬ ¬, ou ⇒ ⇒.

• conjonction, f f1 ∧ ∧ f f2 : relie deux formules pour en former une troisième qui est vraie ssi les deux premières le sont. Le connecteur ∧ ∧ est commutatif, associatif, et a pour élément neutre la valeur de vérité Vrai. Cela permet la notation de conjonction étendue comme ⋀i

∈ ∈ [1,n] f fi. Si on convenait que Faux < Vrai, f f1 ∧ ∧ f f2 serait le minimum de f f1 et f f2 . Si on convenait que Faux = 0 et Vrai = 1, f f1 ∧ ∧ f f2 serait f f1 × × f f2.
• disjonction, f f1 ∨ ∨ f f2 : relie deux formules pour en former une troisième qui est vraie ssi au moins une des deux premières l'est. Le connecteur ∨ ∨ est commutatif, associatif, et a pour élément neutre la valeur de vérité Faux. Cela permet la notation de disjonction étendue comme ⋁i

∈ ∈ [1,n] f fi. Si on convenait que Faux < Vrai, f f1 ∨ ∨ f f2 serait le maximum de f f1 et f f2. Si on convenait que Faux = 0 et Vrai = 1, f f1 ∨ ∨ f f2 serait 1 -(1-f f1) × × (1-f f2).
• implication, f f1 ⇒ ⇒ f f2 : relie deux formules pour en former une troisième qui est fausse ssi f f1 est vraie alors que f f2 est fausse. Le connecteur

⇒ ⇒ n'est ni commutatif ni associatif. Si on convenait que Faux < Vrai, f f1 ⇒ ⇒ f f2 serait Vrai ssi f f1 ≤ f f2 . • négation, ¬ ¬ f f : constitue une formule qui est fausse ssi f f est vraie. Si on convenait que Faux = 0 et Vrai=1, ¬ ¬ f f serait 1 --f f .
Formules quantifiées : Ce sont des formules, élémentaires ou non, dont la valeur de vérité s'évalue par rapport à un ensemble d'objets, plutôt que par rapport à des objets pris individuellement.

• quantification universelle, ∀ ∀x . f f(x) : constitue une formule qui est vraie ssi f f est vraie de tous les éléments du domaine. Si le domaine est fini, la quantification universelle est équivalente à une conjonction des applications de f f à tous les éléments du domaine :

∀ ∀x ∈ ∈ {e1, e2, …, en}. f f(x) ssi ⋀i ∈ ∈ [1,n] f f(ei) .
• quantification existentielle, ∃ ∃x . f f (x) : constitue une formule qui est vraie ssi f f est vraie d'au moins un élément du domaine. Si le domaine est fini, la quantification existentielle est équivalente à une disjonction des applications de f f à tous les éléments du domaine:

∃ ∃x ∈ ∈ {e1, e2, …, en}. f f(x) ssi ⋁i ∈ ∈ [1,n] f f(ei) .
Parenthèses et priorité des opérateurs : Il est courant d'assigner des priorités d'opérateurs aux différents connecteurs et quantificateurs afin de spécifier comment se lisent les formules complexes en l'absence de parenthèses. Nous pensons que c'est utile mais absolument pas fondamental car ces conventions dépendent trop des outils, et même quand ce n'est pas le cas, il n'est jamais très prudent de se reposer trop lourdement sur les priorités des opérateurs quand le coût de quelques parenthèses est si faible devant le coût d'une grosse erreur. Ce genre d'expertise est à réserver aux experts. Il vaut mieux ne pas être avare de parenthèses, et nous proposons d'utiliser les parenthèses rondes ((…)) pour structurer les connecteurs, et les parenthèses carrées (ou crochets, […]) pour les quantificateurs.

3⃣ ⃣ Cardinalité des ensembles finis

Le nombre d'éléments d'un ensemble fini est appelé la cardinalité de l'ensemble. La cardinalité d'un ensemble E est notée card(E) ou ∥E∥. La cardinalité des ensembles suit les lois suivantes : Produit cartésien : ∥A × × B∥ = ∥A∥ × × ∥B∥. Noter la surcharge du signe × × qui opère tantôt sur des ensembles (le produit cartésien) et tantôt sur des entiers (le produit arithmétique).

Ensemble des parties : ∥P P(E)∥ = 2card(E), ce qui explique un peu la notation 2E pour l'ensemble des parties de E. Union : max{∥A∥, ∥B∥} ≤ ∥A ∪ ∪ B∥ ≤ ∥A∥ + ∥B∥ car des éléments peuvent appartenir aux deux ensembles, mais ne doivent être comptés qu'une fois.

Intersection : 0 ≤ ∥A ∩ ∩ B∥ ≤ min{∥A∥, ∥B∥}. Plus précisément, ∥A ∪ ∪ B∥ = ∥A∥ + ∥B∥ -∥A ∩ ∩ B∥. Complémentation : ∥∁ ∁A B∥ = ∥A∥ -∥A ∩ ∩ B∥.
Étant donné un univers U U d'objets de références, on peut former une structure algébrique sur les sous-ensembles de U U avec les opérations suivantes : The first picopoly is representative of the initial motivation, to clarify prerequisites and outcomes. It is related to a course on relational databases, introductory level, where the prerequisites are formal logic and set theory, and the outcomes are relational algebra, SQL, modelling and normalization, and a few system-level aspects like the so-called ACID properties. The prerequisite side (see Figure 3) is composed as a mosaic, with logic related tiles with a beige filling, and set theory tiles filled in light blue. The overview side (see Figure 4) is paginated as follows:

Produit cartésien (noté × ×) : A × × B est l'
1. Title and motivation: databases are everywhere, they are used for many purposes by many different role-persons, the relational paradigm is the classical one;

2. Historical context: first presented in 1970, the relational paradigm took about 20 years to be fully developed, it is now challenged by new paradigms related to new web-oriented application styles; Plusieurs sortes de redondances ont été analysées théoriquement, et sont éliminées de cette façon dans des formes normales de forces croissantes.

Normaliser n'est pas une fin en soi. Si une BDD subit très peu de mises à jour, on peut même choisir de la dénormaliser exprès pour des raisons d'efficacité.

Rôles

La théorie des BDD distingue plusieurs rôles d'agents. Les mots nom, habite et adresse y sont correctement interprétés grâce à la déclara-tion de schéma qui a précédé. Et la requête SELECT nom FROM habite, etat_voirie WHERE etat_voirie.voie = habite.adresse AND etat = "en chantier" retourne la liste des noms de tous les habitants d'une rue en chantier, soit p pnom(s setat_voirie.voie = habite.adresse ∧ ∧ etat = en chantier(habite× ×etat_voirie)).

Ici, on a croisé les informations de deux tables ; on appelle cela une jointure. Une BDD contient explicitement les informations stockées dans ses tables, et implicite-ment celles qui peuvent s'en déduire. Une requête SELECT construit donc une table aussi bien qu'une requête CREATE On peut répondre à cela en interdisant d'entrelacer deux requêtes à la même BDD. Mais deux requêtes à la même BDD peuvent aussi ne pas du tout interférer l'une avec l'autre. Il serait alors inefficace de les interpréter l'une après l'autre. On va donc se donner pour objectif de limiter les entrelacements à ceux qui garantissent que le résultat sera le même que si les requêtes avaient été interprétées l'une après l'autre. On dit que les requêtes qui permettent cela sont sérialisables. 4. The SQL query language: the concrete programming language that allows to configure, populate, and query databases;

5. Database design and entity-association diagrams: even with the same content, all database organizations are not equally good, there is formal reasons for that, and methods for avoiding bad organizations;

6. Database normalization: ...and methods for repairing bad organizations also exist;

7. Concurrent accesses and ACID properties: many databases are vastly multiusers, very often users are concurrent (e.g. an hotel reservation system), this must be tackled for;

Conclusion and bibliography.

This picopoly is handed out at the beginning of the course on databases, and at the beginning of other courses to mobility students who did not follow the database course, but should be in sync with their comrades.

The second example is representative of variations on the theme. It is about agile methods for software development. It is used as a vademecum in a course where agility is the recommended approach for the practical works but about half the students are mobility students. The prerequisite mosaic (see Figure 5) evolves into a context mosaic, on software development cycles (filled in green), software development risk analysis (filled in red), and on software maturity (filled in blue). The overview side (see Figure 6) is paginated as follows:

1. Title and motivation: developing software is difficult, exposed to many risks, agility is a way for coping for these risks;

2. Historical context: first variants of agility date from the 90's, an Agile Manifesto reconciled different approaches at the beginning of 2000, a few approaches became de facto standard;

3. The Agile Manifesto: exposes values and principles that govern agile methods;

4 and 5. Concepts from SCRUM: one of the de facto standard approaches (an example of a large subject treated on 2 facing pages);

6. Concepts from Extreme programming: one of the pioneer approaches, remains as traces in modern approaches; Agility and time management: how agility helps managing time, especially as one comes close to deadlines (an example of 2 small subjects treated on the same page);

7. Agility and practical works: how to be agile in student works;

Conclusion and bibliography.

Other subjects that have been treated as picopolies are:

• algorithmic (primarily as a companion to a full course in an engineering school program, secondarily as a prerequisite for many other courses), used 5 for about 8 years and 100 students per year;

• Turing machine (companion to a short course from a continuous education program for secondary school teachers, and prerequisite to many others), first edition in 2019 and 100 students per year;

• λ-calculus (companion to a short course from a continuous education program for secondary school teachers, and prerequisite to many others), first edition in 2020 and about 100 students per year;

• formal language theory (full course in an engineering school program and prerequisite in others), used for about 10 years and 50 students per year;

• compilation (full course in an engineering school program and prerequisite in others), used for about 10 years and 50 students per year;

• green IT (full course in an engineering school program and a bachelor-level program), used for about 10 years and more than 200 students per year;

Compléments de lecture : maturité, cycles de vie et risques. Pliage : verso de cette page au-dessus, traits gris rentrants, traits rouges saillants. Découper selon le trait rouge entre les deux , puis achever le pliage.

2⃣ ⃣ La prise en compte des risques

Une fois les risques identifiés, et sans chercher à les éliminer, on peut réfléchir à comment en réduire l'impact.

• Les échéances : le chiffrage des coûts, et particulièrement du temps nécessaire à un développement logiciel, est une des problématiques la plus difficile qui soit. Il faut faire en sorte que même si on s'est trompé, un développement qui s'interrompt à l'échéance due ait produit quelque chose de pertinent du point de vue du client, ne serait-ce que pour être en meilleure position pour négocier une prolongation.

• L'analyse : ne jamais prétendre qu'on a compris la demande, ne même pas en faire un objectif, et soumettre sa compréhension régulièrement au demandeur, donc toujours présenter au demandeur une réalisation de bout en bout, même très incomplète. Rappel : le demandeur n'est pas forcément informaticien, et on doit lui parler dans son langage pour le convaincre.

• Le codage : toujours suspecter qu'un programme est faux et le vérifier/valider en continu, donc l'intégrer/déployer en continu. Ne pas croire que bien réfléchir a priori dispense de vérifier a posteriori.

• La sous-traitance : inverser les rôles du demandeur et du développeur.

• La technologie : commencer par ce qui est le moins maîtrisé, faire des maquettes purement techniques juste pour se former à la technologie.

• Les ressources humaines : se méfier du mode copain, qui rend aveugle, inclure la formation dans le cycle de vie, veiller à la durabilité de l'effort, ménager des moments de détente et de satisfaction. Les ambitions de chaque niveau peuvent sembler très modestes, mais en fait elles sont très difficiles à satisfaire car elles portent sur tous les aspects de l'organisation : ses processus techniques, mais aussi les ressources humaines, le management, etc. Très peu d'entreprises sont certifiées CMM à un niveau élevé, c-à-d. au-delà de 3. Ce qui est évalué est en fait l'alignement de tous ces processus.

Évidemment, n'être certifié qu'à un niveau n'interdit pas de mettre en oeuvre partiellement les exigences d'un niveau supérieur. La variante continue de CMMI permet d'en rendre compte.

1⃣ ⃣ Cycles de vie de développement

En première approximation, le développement d'un logiciel demande une part :

• B : d'expression d'un besoin par un demandeur,

• A : d'analyse pour comprendre le problème posé et imaginer une réponse,

• C : de codage pour produire le logiciel proprement dit, éventuellement constitué de plusieurs parties,

• ID : d'intégration/déploiement pour assembler les différentes parties du logiciel, et l'installer dans son contexte d'utilisation,

• VV : et de vérification/validation pour s'assurer que le logiciel réalise bien les consignes spécifiées à l'avance, et qu'il peut être utilisé dans le contexte où il doit l'être.

On appelle cycle de vie de développement la façon dont on enchaîne ces actions. Si on admet que la vérification/validation peut échouer, le cycle de vie réel ne peut qu'itérer A, C, ID et VV. Si en plus même le besoin du client peut évoluer, il faudra aussi itérer sur B. Cependant, au cours de l'histoire du génie logiciel la façon de décrire le cycle de vie a beaucoup évolué, donnant lieu à de nombreux styles de modélisation.

Les modèles de cycles de vie présentés ici le sont d'une façon extrêmement simplifiée avec 2 objectifs : permettre d'utiliser une symbolique homogène et simple, et mettre en valeur les traits saillants de chaque modèle, au risque d'être accusé de caricature.

1⃣ ⃣ Le rôle occulte des documents logiciels

Le génie logiciel est une ingénierie très documentaire. Il ne faut pas en sous-estimer la richesse des documents manipulés. Concernant les documents de programmation et de test, et à leur commentaires, on peut faire les observations suivantes :

• Programme : permet de dire à un humain ce qu'on demande à une machine. Ne pas négliger ce rôle. Un programme doit être lisible par un humain.

• Test : permet de préciser formellement et de façon vérifiable des éléments de spécification. Ne pas hésiter à compléter une spécification par des cas de test. Toujours se demander à quel élément de spécification correspond un test.

• Commentaire : partout où il est permis d'en mettre, permet de prendre note de difficultés rencontrées et des réponses apportées, permet de lier des éléments logiciels entre eux. Sont de plus en plus formalisés pour entrer dans des traitements automatiques.

1⃣ ⃣ Risques génie logiciel

Il est intéressant de considérer la gestion de projet, génie logiciel ou pas, non pas comme un ensemble de méthodes qui orientées vers le but à atteindre, mais plutôt comme un ensemble de méthodes qui aident à anticiper les risques.

Anticiper n'est pas éviter, mais plutôt chercher à réduire l'impact du risque qui se réalise.

La plupart des risques qui menacent un projet de développement logiciel sont génériques et peuvent aussi menacer un projet d'une autre nature. Seuls les détails les distinguent. Dans tous les cas, la grande question est comment se rendre compte au plus tôt de la réalisation d'un risque, et quelle réponse adopter. Quels sont ces risques ?

• Les échéances : ne pas pouvoir les tenir.

• L'analyse : ne pas comprendre la demande du client. Pire, penser qu'on l'a comprise, alors que ce n'est pas le cas.

• Le codage : même si l'analyse a été correcte, se tromper dans sa mise en oeuvre. Pour un projet logiciel on distinguera souvent une facette fonctionnelle qui concerne plutôt les données et les résultats, et une facette non-fonctionnelle qui concerne plutôt les performances, ex. vitesse, capacité de traitement, ou sécurité.

• La sous-traitance : quand un sous-projet est confié à un tiers qui sera lui-même exposé aux mêmes risques.

• La technologie : ne pas savoir la maîtriser.

• Les ressources humaines : ne pas savoir gérer les différences d'aptitudes ou de motivations, les fluctuations dans les effectifs, les besoins de formation, se contenter de constater que c'est difficile, croire que c'est plus important de connaître les threads de Java.

• L'environnement : des événements de nature sociale, économique ou politique qui affectent le projet, voire son existence même. Changement de direction ou de réglementation, crise, etc.

Dans un cadre d'apprentissage, ces risques prennent un tour particulier. Les échéances sont beaucoup plus fermes qu'on ne l'imagine car après le semestre ce n'est plus le semestre. L'analyse, le codage, la technologie sont souvent le sujet d'étude et constituent un risque calculé. La sous-traitance et les effets de l'environnement sont rares, sauf à faire exprès de sensibiliser à ces risques. Et le risque dominant est le risque ressources humaines car il est constamment masqué par le mode copain. C'est pourquoi il faut savoir s'affranchir des affinités pour former des groupes de projet.

2⃣ ⃣ Cycle de vie en cascade

Une des premières tentatives de modélisation du cycle de vie de développement est celle de la cascade.

Dans ce modèle, on imagine qu'un problème est décrit de façon plus ou moins formelle, que cette description est passée à des analystes qui vont tenter de la comprendre et proposer une solution logicielle, décrite elle aussi de façon plus ou moins formelle, que cette solution est passée à des programmeurs qui vont la coder sous forme de programmes, qui vont devoir être intégrés et déployés pour pouvoir exécuter le logiciel et le vérifier/valider.

La représentation traditionnelle de la cascade semble être bidimensionnelle, mais il n'en est rien. Elle représente juste le temps qui s'écoule le long des flèches. Certaines présentations montrent des flèches bidirectionnelles, ce qui éloigne encore un peu plus l'intuition temporelle, mais évoque plutôt la capacité de communiquer entre boîtes successives.

Cela a l'air très raisonnable, mais cette modélisation ne dit rien de ce qu'on doit faire quand la vérification/validation échoue. En effet, en cas d'échec il faut en chercher la cause dans toutes les étapes qui ont précédé : analyse, codage ou intégration, voire vérification/validation elle-même. On peut bien-sûr raffiner le modèle en remontant une partie de la vérification juste après le codage, mais ça ne change pas l'idée générale. Une autre difficulté réside dans l'enseignement de l'agilité. Ici, le risque est de ne considérer l'agilité que comme une pratique sociale et de la confiner aux enseignements de management ou de communication (réellement observé aussi). À nouveau, cela revient à réduire l'agilité à un rite en oubliant son rôle de guider des décisions techniques qu'on ne peut comprendre qu'en comprenant le pourquoi de l'agilité. Nous pensons qu'un bon point de vue sur ce pourquoi est dans l'anticipation des risques, et c'est ce que nous proposons ici.

Analyse

Cependant, la mise en oeuvre raisonnée de l'agilité est complexe. C'est pourquoi on doit profiter de tous les exercices de programmation qui s'offrent aux étudiants, même les plus simples, pour pratiquer l'agilité. Plus généralement, le génie logiciel, dont l'agilité, ne doit pas être enseigné uniquement quand la programmation devient difficile, mais comme le seul exercice raisonnable de la programmation. On a d'abord cru que ces approches étaient réservées aux petits projets démar-rant ex nihilo, et dans des relations contractuelles pas trop contraignantes. Cela excluait les gros projets des SSII/ESN (sociétés de services en ingénierie informa-tique/entreprises de services du numérique), souvent en mode de maintenance. D'autres pratiques de ces entreprises, comme la délocalisation de sous-projets semblaient aussi s'opposer aux aspects les plus sociaux des approches agiles.

Cependant, l'approche agile s'est diffusée lentement jusqu'à être appliquée aujourd'hui de façon très généralisée dans toutes sortes de cadres de développe-ment logiciel. Elle n'est pas toujours appliquée dans tous ses aspects, mais elle fait désormais partie du vocabulaire standard du développement logiciel.

On en est même au stade où l'agilité est devenue un buzzword, ses pratiques des stéréotypes, et son vocabulaire une sorte de latin de médecins de Molière. Il est donc important de rendre à l'agilité sa fraicheur première. Dans ce cadre, les risques sont principalement :

Agilité et anticipation des

• Celui des échéances, et l'agilité permet de s'assurer de rendre quelque chose dans les délais, éventuellement incomplet, mais intéressant pour le product owner.

• Celui de la technologie, et l'agilité permet de prévoir des sprints purement technologiques pour l'apprivoiser, même en réalisant des fonctionnalités qui n'ont rien à voir avec le sujet apparent du TP ; ne pas s'en priver.

• Celui des fonctionnalités, et ici encore l'agilité commande de réaliser des applications partielles que le product owner enseignant pourra valider. Souvent, la consigne s'analyse selon deux axes, fonctionnalités couches technologiques, ex. plusieurs fonctionnalités et des couches interfaces, services, et base de données. Ici, l'agilité commande de commencer par ne développer qu'une fonctionnalité embryonnaire, mais en traversant toutes les couches technologiques. Faire le contraire serait anti-agile, et expose à développer une grande quantité de code qui, si le TP n'arrive pas à bonne fin, ne servira à rien. C'est le syndrome du TP où rien ne marche malgré la quantité de travail. Le product owner enseignant ne peut que donner la note de 0, alors que les étudiants qui ont travaillé s'attendent à plus même sans résultat tangible.

DevOps

La notion de product owner risque de cacher la réalité parfois compliquée de l'exploitation d'un logiciel, avec évidemment ses utilisateurs finaux, parfois dans plusieurs rôles bien distincts comme dans les bases de données, mais aussi tous les agents opérationnels qui installent et exploitent le logiciel. • history of innovation theories (full course from an innovation program in an engineering school and context information in an epistemology program), used for about 6 years and about 30 students per year;

• revolution and disruption in science and innovation (full curse from an innovation program in an engineering school and context information in an epistemology program), used for about 6 years and about 30 students per year;

• the art of the demo (prerequisite and context information in an engineering school program and others), used for about 5 years and about 20 students per year;

• principles of computer systems (full course in a computer science bachelor program), first edition in 2021 and about 250 students per year;

• the curriculum of our Computer Science 2nd year.

Note that the "Turing machine" picopoly contains in itself a tangible Turing machine. So, not only the picopoly format allows to carry in one's pocket all the courses of a semester, but it allows to take with them a universal calculator!

Conclusion

We presented a compact format of handouts, which we call picopoly, as a way to clarify prerequisites and learning outcomes of university courses. This role progressively evolved into summarizing prerequisites or summarizing outcomes. We started developing this approach in 2010, and published 10 picopolies that are used either in courses they were designed for, or in courses where they happen to be useful as a compact reference, including in courses where the teacher is not the author of the picopoly.

Though we made picopolies the cornerstone of our handout strategy, we do not advocate generalizing all the details to every situations. What we advocate is that the picopoly format is an adequate support for making prerequisites and learning outcomes explicit, and that the constraints it imposes on redaction are interesting for themselves. We observes that picopolies are welcomed by students, and that it actually helps to clarify didactic situations. Maybe their unusual form is enough to create a surprise effect that captures the interest of the students and helps them remember what they should remember.

Figure 1 :Figure 2 :

 12 Figure 1: A picopoly as a flat sheet

  ensemble formé de tous les couples (a, b) où a ∈ ∈ A et b ∈ ∈ B. Bien noter que l'ordre compte et que (a, b) ≠ ≠ (b, a) sauf si a= =b. Noter aussi que A × × ∅ ∅ = = ∅ ∅. Ensemble des parties (noté P P(E) ou 2E) : P P(E) est l'ensemble formé de toutes les parties de E, donc un ensemble d'ensembles. Noter que P P(∅ ∅) = {∅ ∅} et P P({a}) = {∅ ∅, {a}}. Union (notée ⋃ ⋃) : A ∪ ∪ B est l'ensemble formé des éléments de A et de ceux de B. Comme la multiplicité ne compte pas, il est indifférent qu'un élément appartienne aux deux ensembles ou seulement à l'un d'entre eux. Par exemple, {a, b} ∪ ∪ {c, b} = {a} ∪ ∪ {b, c} = {a, b, c}. L'union est commutative, associative, idempotente, et a ∅ ∅ pour élément neutre. Cela autorise la notation d'union étendue comme ⋃i ∈ ∈ [1,n] Ei. L'intension d'une union d'ensembles est la disjonction des intensions de ces ensembles. Noter que A ⊆ ⊆ B ssi A ∪ ∪ B = B, et que ⋃i ∈ ∈ ∅ ∅ Ei = ∅ ∅. Intersection (notée ⋂ ⋂) : A ∩ ∩ B est l'ensemble formé des éléments de A qui appartiennent aussi à B. Par exemple, {a, b} ∩ ∩ {c, b} = {b}. L'intersection est commutative, associative, idempotente, et a U U pour élément neutre. Cela autorise la notation d'intersection étendue comme ⋂i ∈ ∈ [1,n] Ei. L'intension d'une intersection d'ensembles est la conjonction des intensions de ces ensembles. Noter que A ⊆ ⊆ B ssi A ∩ ∩ B = A , et que ⋂i ∈ ∈ ∅ ∅ Ei = U U . Complémentation (notée ∁ ∁) : ∁ ∁A B est l'ensemble formé de la collection des éléments de A qui n'appartiennent pas à B ; le complémentaire de B dans A. On note parfois A\B ou même A-B. Il n'est pas nécessaire que B soit inclus dans A ! Quand l'ensemble de référence est U U on peut se dispenser de le noter : ∁ ∁ B = ∁ ∁U U B. Noter que ∁ ∁ ∁ ∁ B = B. L'intension du complémentaire d'un ensemble est la conjonction de l'intension de l'ensemble de référence et de la négation de l'intension de l'ensemble. L'intersection et l'union sont distributives l'une par rapport à l'autre : pour tout triplet d'ensembles A, B et C, A ∪ ∪ (B∩ ∩C) = (A∪ ∪B) ∩ ∩ (A∪ ∪C) et A ∩ ∩ (B∪ ∪C) = (A∩ ∩B) ∪ ∪ (A∩ ∩C). La complémentation est une sorte de négation, et suit les lois de De Morgan : ∁ ∁A(B∪ ∪C) = ∁ ∁AB ∩ ∩ ∁ ∁AC et ∁ ∁A(B∩ ∩C) = ∁ ∁AB ∪ ∪ ∁ ∁AC. Même si l'une fait penser à l'addition et l'autre à la soustraction, l'union et la complémentation ne sont pas les opposées l'une de l'autre ; pour certaines paires d'ensembles A et B, on a (A\B) ∪ ∪ B ≠ ≠ A ou (A∪ ∪B) \ B ≠ ≠ A. Ex. ({a}\{b}) ∪ ∪ {b} = = {a, b} et ({a, b} ∪ ∪ {b})\{b} = = {a}.

Figure 3 :

 3 Figure 3: On databases: verso

3 .

 3 Relational algebra: based on basic set theory and formal logic, it is the formal model of relational databases; Bases de données Le modèle relationnel Olivier Ridoux -2020 Motivations Les bases de données (BDD) sont des systèmes informatiques qui permettent de stocker, calculer, et restituer des données. On entend par données des valeurs comme 12, en chantier, rue Morgue, Mme L'Espanaye. Elles peuvent être associées pour former des informations comme la rue Morgue est en chantier ou Mme L'Espanaye habite rue Morgue, ou la liste des rues en chantier. C'est en tant qu'outil de gestion de l'information que les BDD sont essentielles. On peut imaginer des BDD utilisées par une seule personne pour un unique service, comme pour gérer les livres d'un bibliophile, et pour cela presque n'importe quelle solution pourrait convenir. Cependant, on considère le plus souvent qu'une BDD doit pouvoir être utilisée par plusieurs agents indépendants et même à des fins différentes. Ex. les stocks d'une entreprise de e-commerce doivent être consultés par son service des achats, et sous une forme simplifiée par ses clients. Pour que le développement d'applications qui utilisent des BDD puisse devenir un métier il convient qu'elles proposent des façons de faire conventionnelles. Il existe plusieurs façons de faire, mais sans doute la plus répandue aujourd'hui s'appelle le modèle relationnel. Ce modèle est disponible au travers de nombreux outils, qui sont pré-installés dans des systèmes variés (hébergement internet, ordinateurs, smartphones, boxes internet, etc.). L'objectif d'un enseignement de BDD relationnelle est de fournir des éléments méthodologiques suffisants pour être autonome dans la conception d'applications comme on en trouve dans tous les domaines des technologies de l'information. Les BDD relationnelles ont aussi une théorie, et même une théorie qui marche ! C'est-à-dire une théorie suffisamment puissante pour permettre de prouver des choses et d'automatiser des traitements fastidieux. Un module d'enseignement de BDD relationnelles entrelace donc des éléments théoriques et des éléments plus opérationnels. 1 Normalisation : soit un schéma, ex. musicien(nomMus, instrument, nomOrch, nomChef, contrat) et l'énoncé de dépendances fonctionnelles (DF) entre ses attributs. Une DF A A ⟶ ⟶ B B exprime que les valeurs des attributs A A déterminent les valeurs des attributs B B. Ex. si le nom d'un musicien détermine son orchestre et l'instrument qu'il y joue, on note nomMus ⟶ ⟶ nomOrch, instrument, et de façon similaire nomOrch ⟶ ⟶ nomChef et nomChef ⟶ ⟶ contrat. On voit alors que la relation musicien est redondante car le nom et le contrat du chef d'un orchestre seront notés dans toutes les lignes des musiciens de l'orchestre. Cela se détecte sans attendre de peupler la BDD car nomMus détermine tous les attributs, nomOrch détermine une partie d'entre eux, et nomChef une souspartie. Les DF servent alors de guides pour décomposer la relation en sous-relations sans redondance telles que la relation de départ peut être reconstituée. Ici on produirait musicien(nomMus, instrument, nomOrch), orchestre(nomOrch, nomChef) et chef(nomChef).

L 6 Conception 5 3 2 SQL-

 6532 'administrateur de BDD : gère un système de gestion de BDD, ex. l'utilisation des ressources par le système et à l'attribution des droits d'accès au système. Il peut définir un schéma général des données, une politique de sécurité, etc. L'administrateur d'application : gère l'accès aux données en vue d'une application. Il définit des schémas spécifiques à l'application qui vont masquer le schéma général aux yeux des programmeurs d'application et des utilisateurs. Le programmeur d'application : développe les applications qui utilisent la BDD. Il ne voit que les schémas qu'a préparés l'administrateur d'application.: ne voit que l'interface homme-machine de l'application ; il ne voit pas la BDD, même si celle-ci est sollicitée par l'application. Ces rôles sont transposables dans la plupart des métiers de l'informatique. Une BDD contient de l'information explicite dans ses tables et implicite via ses déductions. Une mise à jour peut donc avoir des effets indirects désastreux, ex. perte d'une information implicite. Pour prévenir ce risque, on peut concevoir des schémas reconnus plus sûrs, exprimer des contraintes d'intégrité (ex. âge < 200 ans), ou spécifier des règles de propagation des mises à jour. Une difficulté de la mise à jour vient de la redondance de donnée ; c-à-d. quand une même information est représentée plusieurs fois. Dans une telle situation, il est très difficile de s'assurer qu'une mise à jour laisse la BDD dans un état cohé-rent. Ex. on aurait pu décider de noter l'état de la voirie dans la relation habite (ex. habite(Mme L'Espanaye, rue Morgue, en chantier)), mais cela entraîne que l'état d'une rue est noté pour chacun de ses habitants, et que lorsqu'il change il faut le mettre à jour partout. Cela entraîne aussi que l'état d'une rue disparaît de la BDD quand son dernier habitant disparaît ! On a le choix entre adopter une modélisation qui ne crée pas ces situations ou les supprimer par normalisation. Modélisation : on analyse une situation du monde réel en y identifiant des classes d'entités (correspondant ± à des noms communs), leurs attributs (± des adjectifs) et des classes d'associations (± des verbes). On relie entre elles les classes d'entités, toujours via une association que l'on quantifie à l'aide de cardi-nalités pour exprimer à combien d'entités d'une autre classe peut être associée une entité d'une classe. Ex. on pourra dire que chaque personne ne vit qu'à une adresse, mais qu'à une adresse peuvent vivre plusieurs personnes. On peut alors traduire ces entités et associations en relations, pour obtenir un ensemble de relations de bonne qualité face au risque d'incohérence lors d'une mise à jour. Le modèle relationnel Les données du modèle relationnel sont organisées en tables, ou relations. Visuel-lement, une relation est un tableau avec des colonnes ayant chacune un titre, qu'on appelle attribut. L'ensemble des attributs d'une relation constitue son schéma. Chaque ligne d'une table est une valuation pour chacun de ses attributs. Formellement, une relation est un ensemble de lignes. Chaque ligne peut être lue comme un axiome, ex. Mme L'Espanaye habite rue Morgue, et chaque relation comme la conjonction de tous ses axiomes. On peut déduire de ces axiomes des propriétés comme ∃ ∃ r. Mme L'Espanaye habite r, mais aussi en croisant plusieurs tables ∃ ∃ r. [Mme L'Espanaye habite r ∧ ∧ r est en chantier]. On peut ainsi raisonner sur les relations et les formules, prouver des équivalences, et faire des déductions. On peut aussi adopter un point de vue algébrique où les déductions sont représen-tées par des opérations algébriques. Connaissant la sémantique de ces opérations on peut prouver des identités remarquables et les appliquer pour transformer des requêtes comme on le fait en mathématiques pour simplifier/factoriser/développer des formules. On appelle cette algèbre l'algèbre relationnelle. Les principales opé-rations de cette algèbre sont les suivantes : Restriction : s spropriété(relation) = { ligne | ligne ∈ ∈ relation ∧ ∧ propriété(ligne) } La restriction sélectionne des lignes d'une relation sur la base de leur contenu indi-viduel. Le résultat est une relation de même schéma, plus petite, qui est la conjonc-tion d'une propriété en extension (relation) et d'une propriété en intension (pro-priété). Sélectionner des lignes sur la base d'une propriété collective, ex. les rues dont les habitants dépassent 60 ans en moyenne, demande d'autres moyens. Produit : relation1 × × relation2 = { (ligne1, ligne2) | ligne1 ∈ ∈ relation1 ∧ ∧ ligne2 ∈ ∈ relation2 } Le produit calcule toutes les combinaisons possibles des lignes de deux relations. Le résultat est une relation qui a tous les attributs de relation1 et relation2, et ∥relation1∥ × × ∥relation2∥ lignes. Projection : p pattributs(relation) = { ligne | ∃ ∃ x... dans colonnes autres attributs.(ligne, x...) ∈ ∈ relation) } La projection sélectionne des colonnes d'une relation sur la base de leur nom. Le résultat est une relation de schéma plus petit, et avec possiblement moins de lignes.Opérations ensemblistes : ∪ ∪, ∩ ∩ et \ s'appliquent à des relations de même schéma.L'idiome p pattributs(s spropriété(relation1× ×relation2× ×relation3× ×…)) recouvre à lui seul une grande part des déductions qu'on peut vouloir faire (ex. page 4).Bases de données, etc.Le terme « base de données » désigne tantôt un modèle de logiciel de gestion de bases de données (ex. la BDD MySQL), tantôt une installation de ce logiciel (ex. la BDD de mon smartphone), tantôt un des contenus de cette installation (ex. la BDD clients). On parlera respectivement d'un « logiciel de gestion » de BDD, d'un « système de gestion » de BDD et d'une « base de données ».Les BDD sont le plus souvent couplées à un dispositif de stockage persistant, ex. un ou plusieurs disques durs. Elles sont souvent installées sur un serveur de BDD comportant un interpréteur de requêtes capable de lire des requêtes prove-nant de plusieurs utilisateurs et d'y répondre, donnant à chaque utilisateur l'im-pression d'avoir la BDD pour lui seul.HistoriqueLe modèle des BDD relationnelles a été proposé par Edgar Franck Codd en 1970. Il proposait de remplacer le point de vue physique sur le stockage des données qui prévalait à l'époque par un point de vue formel fondé sur la logique des prédicats. L'essor des BDD relationnelles a ensuite été très long, en partie parce qu'il a fallu apprendre à les mettre en oeuvre efficacement. C'est encore un exem-ple où un nouveau paradigme n'est pas strictement meilleur que ses alternatives au moment de son introduction, il est seulement plus prometteur. Le modèle relationnel a mis une vingtaine d'années à dominer le marché avec de très grands fournisseurs, comme Oracle, et de nombreux fournisseurs alternatifs, comme SQLite ou MySQL (racheté par Oracle), tous partageant les mêmes concepts résumés dans l'appellation BDD SQL (Structured Query Language). Des alternatives comme Access privilégient une interface graphique à l'interface lin-guistique de SQL. De nombreuses variantes existent, en particuliers pour le traite-ment de données spécifiques, ex. données temporelles ou géolocalisées. D'autres modèles comme les BDD orientées objets ont tenté d'émerger, mais sans grand succès. Plus récemment, le mouvement NoSQL (not only SQL) et celui du web sémantique proposent des alternatives destinées le plus souvent à mieux prendre en compte le volume, l'hétérogénéité, la volatilité et l'éparpillement des données de certaines applications web. Structured Query Language SQL permet l'exploitation des BDD relationnelles. Il comporte 4 sous-langages : Langage de définition des données : il permet de décrire leur organisation (les schémas). Par exemple, la requête CREATE TABLE habite (nom TEXT, adresse TEXT) déclare le schéma d'une nouvelle table habite qui aura un attribut nom et un attribut adresse, tous deux textuels. La table est créée vide. Langage de manipulation de données : il permet de déposer des données, de les mettre à jour et de les rechercher. Par exemple, la requête INSERT INTO habite(nom, adresse) ("Mme L'Espanaye", "rue Morgue") ajoute la ligne (Mme L'Espanaye, rue Morgue) à la table habite. La requête SELECT nom FROM habite WHERE adresse = "rue Morgue" retourne la liste des noms de tous les habitants de la rue Morgue, soit p pnom(s sadresse = rue Morgue(habite)).

4

 4 Accès concurrentsL'exécution d'une requête consiste à enchaîner des opérations élémentaires qui mobilisent tantôt l'unité centrale tantôt le disque dur pour lire ou mettre à jour les tables. Il est alors tentant de permettre à l'interpréteur d'entrelacer les opérations de plusieurs requêtes pour augmenter les performances. Cependant, deux requêtes différentes peuvent accéder aux mêmes données, voire leur apporter des changements contradictoires (ex. retrait/dépôt sur un compte bancaire).

7

 7 On convient que l'interpréteur de requêtes doit garantir les propriétés d'atomicité, de cohérence, d'isolation et de durabilité, qu'on appelle collectivement propriétés ACID. Des requêtes qui respectent ces propriétés sont appelées des transactions. Atomicité : une requête est interprétée en entier ou pas du tout. Si elle doit être interrompue, toutes les mises à jour qu'elle avait commencé à faire sont annulées (commande ROLLBACK du langage de contrôle des transactions). Sinon elles sont confirmées (commande COMMIT). On enregistre pour cela les mises à jour faites depuis le début de l'interprétation de la requête dans un journal. Cohérence : l'exécution d'une requête laisse la BDD conforme à ses contraintes d'intégrité. Isolation : l'avancement d'une requête est invisible depuis d'autres requêtes. Si elle doit faire une mise à jour en plusieurs fois, il est impossible d'observer les situations intermédiaires. On utilise pour cela des verrous qui garantissent un accès protégé à la donnée mise à jour. Durabilité : l'effet d'une requête de mise à jour est définitif. Ex. le versement d'un salaire ne doit pas disparaître, même en cas de panne du système ! On obtient cet effet par des sauvegardes qui enregistrent des copies de la BDD, et par un journal qui enregistre les mises à jour depuis la dernière sauvegarde. Les propriétés ACID sont coûteuses à mettre en oeuvre. Des bases de données très volatiles et volumineuses comme celles des réseaux sociaux tendent à s'en affranchir en adoptant des modèles NoSQL. Conclusion et perspectives Les BDD sont un composant essentiel de la plupart des systèmes d'information. Dans leur variante relationnelle, le langage d'exploitation SQL domine, et est même imité dans d'autres modèles de BDD, comme SPARQL pour le web sémantique. Il est souvent étendu par des capacités à gérer des données temporelles ou spatiales, comme dans les systèmes d'information géographiques (SIG). La plupart des éléments des BDD relationnelles (sémantique, requêtage, optimisation, normalisation, accès concurrent, etc.) sont susceptibles d'un traitement formel car les BDD relationnelles s'appuient sur une théorie qui marche. Plus simples que l'architecture client-serveur conventionnelle on peut trouver des BDD minimalistes, mais sémantiquement complètes, dans la plupart des dispositifs portables ou des équipements d'informatique domestique. Mais on fait aussi plus complexe avec des BDD réparties sur plusieurs sites ou dupliquées sur des sites miroirs, pour des raisons d'efficacité ou de tolérance aux pannes, ou qui gèrent des données en flux si intenses que le modèle SQL ACID n'est plus opérationnel. L'accès aux données peut aussi être plus sophistiqué que le simple requêtage. Par exemple, la fouille de données, ou l'informatique décisionnelle, permet d'extraire des informations qui ne sont ni représentées explicitement, ni déductibles relationnellement, mais plutôt déductibles tendanciellement, ex. une corrélation. Bibliographie • « A Relational Model of Data for Large Shared Data Banks » par Codd (Communications of the ACM, 1970), pour le texte fondateur. • « Foundations of Databases » par Abiteboul, Hull et Vianu (Addison-Wesley, 1995), pour une somme théorique. • « Des bases de données à l'Internet » par Mathieu (Vuibert, 2000), pour un cours d'introduction. • « Les bases de données » par Comyn-Wattiau et Akoka (PUF, Que-sais-je ? 2003), pour un survol peu onéreux. • « The Manga Guide to Databases » par Takahashi et Azuma (Ohmsha & No Starch Press, 2009), pour les BDD en BD. • « Beginning Database Design » et « Beginning SQL Queries » par Churcher (APress, 2012), pour une étude pragmatique. • « Double assassinat dans la rue Morgue » par Poe (1841), pour les exemples.

  chef dirige 0 ou n orchestres, mais un orchestre n'a qu'un chef. Un musicien joue dans 0 ou 1 orchestres, mais un orchestre a 1 ou n musiciens. Le musicien joue d'un instrument pour son orchestre, mais pourrait jouer d'un autre ailleurs. Le tout se traduit dans les relations chef(nomChef, contrat), musicien(nomMus), joue_dans(nomMus, instrument, nomOrch), et orchestre(nomOrch, nomChef).Noter comment l'association dirige a été absorbée dans la relation orchestre.

Figure 4 :

 4 Figure 4: On databases: recto (oriented as in Figure 1; page 1 bottom right, and other pages counter-clockwise)

Figure 5 :

 5 Figure 5: On agile software development: verso

1 3 Historique

 3 Pendant le déroulement d'un sprint, l'équipe note sa progression sur un tableau spécial, le scrum board. Il peut prendre la forme emblématique d'un tableau mu-ral couvert de Post It ® mais il en existe aussi des versions numériques. Tous les jours l'équipe tient un daily meeting durant lequel chacun explique où il en est, ses difficultés, et ses objectifs pour la journée. Chacun peut proposer son aide, on peut redistribuer les tâches, toujours dans le but de faire progresser le sprint. Ces pratiques se sont généralisées, même en cas de délocalisation lointaine.À la fin du sprint, le PO valide ou non les user stories selon les critères convenus au départ du sprint. Noter que la fin d'un sprint n'est pas déterminée par l'épuise-ment de son objectif, mais simplement par l'épuisement de la durée prévues (time boxing). En cas d'inadéquation entre la durée du sprint et son objectif, on ne prolonge pas la durée du sprint, mais on reconnaît que l'objectif n'a pas été atteint. L'adéquation entre la time box, le planning et les capacités de l'équipes est un indicateur de qualité qu'il faut suivre.Le cumul des points d'effort des user stories validées à la fin d'un sprint constitue la vélocité de l'équipe pendant ce sprint. Comme pour les points d'effort, il ne s'agit pas d'une mesure absolue qui permettrait de comparer des équipes, mais d'une aide à la décision pour les futurs sprint plannings de la même équipe. Alors qu'estimer les coûts est une des choses les plus difficiles qui soit, on s'attend à ce qu'en procédant ainsi l'équipe fasse des estimations toujours plus précises.La fin du sprint donne lieu à un cérémonial contenant entre autre une rétrospec-tive (Aurait-on pu faire mieux ? Et comment ?) et éventuellement une célébration de fin de sprint, ex. un repas pris en commun. Ces rituels intègrent explicitement dans la démarche la dimension humaine des risques à anticiper, y compris via des détails comme de recommander que le daily meeting se tienne debout.5Manifeste AgileLe Manifeste Agile met en avant 4 valeurs et 12 principes. 4 valeurs [les parties entre crochets sont nos commentaires] : V1 : S'appuyer sur les individus et leurs interactions et pas seulement sur les proces-sus et les outils. V2 : Valoriser le logiciel démontrable et pas seulement sa documentation. V3 : Collaborer avec le client [pendant tout le projet] et pas seulement négocier un contrat avec lui [avant de lancer le projet]. V4 : S'adapter au changement, et pas seulement suivre un plan préétabli. Dans l'original anglais les valeurs sont rédigées en suivant le schéma X over Y et un commentaire spécifie qu'il ne faut pas lire X plutôt que Y, mais plutôt Y ne suffit pas et X est nécessaire. Il n'est pas non plus exprimé que X plus Y est suffisant. 12 principes [les parties entre crochets sont nos commentaires] : • Le meilleur moyen de contenter le client [au sens large, utilisateurs, donneurs d'ordre, ..., et pas seulement celui qui paye] est de lui fournir des fonctionnalités à grande valeur ajoutée [c'est le client qui décide de la valeur ; V2, V3]. • Le client peut exprimer des changements de besoins à tout moment [ça peut être une valeur ajoutée pour lui ; V3, V4]. • Le client doit recevoir des versions opérationnelles du logiciel [qu'il puisse utiliser dans son rôle de client ; V2, V3, V4], selon une périodicité la plus courte possible. • Le client et l'équipe collaborent quotidiennement [V1, V3] . • On fournira à l'équipe un environnement motivant et on lui fera confiance [V1]. • On privilégiera le face à face [V1]. • On mesure l'avancement en fonctionnalités délivrées [et pas en lignes de code au autres métriques, « The proof of the pudding is in the eating » ; V2]. • L'effort de développement sera soutenable. Les parties prenantes doivent pouvoir maintenir un effort constant [sans « coups de bourre » ; V1, V3] aussi longtemps que nécessaire. • On vise toujours l'excellence technique [voir la charte de l'ingénieur IESF ; V1]. • On évitera tout travail inutile [qui ne contribue pas à la valeur ajoutée démon-trable ; V2]. • On laisse l'équipe s'auto-organiser pour analyser les besoins du client et trouver la meilleure façon d'y répondre [V1]. • L'équipe s'introspecte régulièrement en quête d'amélioration continue [V1, V4]. Les années 1990 ont vu fleurir des propositions de modèle de cycle de vie de développement logiciel qui privilégiaient la réactivité par rapport à la planifica-tion, qui mettaient le test et la fonctionnalité en bonne place, et qui introdui-saient des considérations psycho-sociologiques pour voir le programmeur comme une personne plutôt que comme un exécutant. Ces approches s'appelaient RAD (Rapid Application Development), Extreme Programming, Scrum, etc. Assez vite, les porteurs de ces propositions se sont rendu compte qu'elles avaient beaucoup en commun, et ils l'ont formalisé dans un manifeste, le Manifeste agile (Manifesto for Agile Software Development en anglais). Aujourd'hui, l'approche Scrum sert souvent de référence. Elle a stabilisé et fait connaître un vocabulaire qui est utilisé même en dehors d'une application stricte de l'approche.

2 4 L

 24 risques L'anticipation des risques suggère une posture de doute, de vérification continue, d'expérimentation et de remise en cause. L'intérêt de l'agilité est qu'elle permet cette posture. En fait, l'agilité est rarement présentée sous cet angle, mais plutôt comme un moyen de maximiser la valeur du logiciel produit pour le client. Cepen-dant, les deux objectifs sont compatibles, et penser anticipation des risques permet d'intégrer des étapes qui ne sont pas immédiatement productives pour le client, mais qui sont nécessaires pour avancer. Le vocabulaire de la méthode Scrum La méthode Scrum identifie des rôles et des pratiques qui sont entrés dans le voca-bulaire commun. Dans la suite, ces termes sont présentés en anglais et sans effort de traduction, car c'est ainsi qu'ils sont utilisés. Le product owner (PO) est le client, ou son représentant. Dans d'autres contextes, on aurait pu l'appeler le maître d'ouvrage ou l'assistant à la maîtrise d'ouvrage. En mode cascade ou V, le client est supposé formuler ses exigences en début de cycle et sans ambiguïté. En mode agile, il est supposé collaborer intimement avec l'équi-pe de développement. Le PO définit les fonctionnalités attendues sous la forme de user stories. L'ensemble des user stories non traitées constitue le backlog. Le PO peut modifier le backlog comme il le veut. C'est un élément important de l'agilité qui permet au client de faire évoluer ses besoins, et aux développeurs de s'y adap-ter sereinement. L'équipe de développement est représentée auprès du client par le scrum master (SM). Il organise le travail de l'équipe en sprints de durée fixée, ex. 1 mois. Un sprint se donne pour objectif de réaliser une sélection de user stories du backlog qui ont été choisies d'un commun accord avec le PO et l'équipe de développement. Pour y parvenir l'équipe estime la charge de travail (exprimée en points d'effort) représentée par chaque user story et le PO leur attribue une priorité. Les deux peuvent être exprimés par des nombres mais sans soucis de fidélité métrique. Ex. 4 est plus prioritaire que 2, mais pas 2 fois plus prioritaire. Pour éviter cette tentation on peut utiliser des échelles non linéaires, ex. la suite de Fibonacci (1, 2, 3, 5, 8, ...). L'estimation des points d'effort est bien sûr difficile. Elle pourra utiliser des techni-ques de brainstorming comme le poker planning, qui permet aux membres de l'équipe de s'exprimer tout en évitant certains artefacts de la communication de groupe. La planification d'un sprint (sprint planning) devra chercher à maximiser le service rendu au PO, tout en respectant la capacité de travail de l'équipe. Le PO et le scrum master doivent aussi s'accorder sur la validation des user stories. À l'extrême, une user story peut être entièrement définie par des cas de test, dans le style test driven development (TDD). On a vu que le PO pouvait modifier le backlog à sa convenance, mais il ne peut pas intervenir sur la planification d'un sprint en cours, et c'est même une mission du scrum master que de l'en empêcher. Le client ne peut pas non plus « dévalider » une user story qu'il aurait validée ; il peut y renoncer, en définir d'autres, mais ne peut pas renier un travail fait et validé. 'agilité en enseignement -le cas du TP L'agilité peut aussi être utile en situation d'enseignement. On ne parle pas ici du TP énigme à résoudre dans une séance de 2 heures, mais plutôt du TP problème ouvert s'étalant sur plusieurs séances. Dans cette situation, l'enseignant de TP est le product owner, et ce qui l'intéresse c'est l'usage fait par les étudiants de la technologie illustrée par le TP, via la réalisation d'une fonctionnalité qui sert de prétexte au déploiement de cette technologie.

7 ConclusionFigure 6 :

 76 Figure 6: On agile software development: recto (oriented as in Figure 1; page 1 bottom right, and other pages counter-clockwise)

Formules de De Morgan (

  ). Ce qui n'a rien à voir avec la première lecture. Conclusion, faire des économies de bouts de parenthèses avec discernement ! Augustus De Morgan, 1806-1871) : La négation a à voir avec le complémentaire d'une situation, mais le complémentaire d'une situation compliquée est souvent encore plus compliqué que la situation. Les formules de De Morgan (qui ne sont pas toutes dues à De Morgan) peuvent être mises à profit pour pousser les négations vers l'intérieur des formules où elles s'appliqueront à des formules plus petites.

SELECT nom FROM habite, (SELECT voie FROM etat_voirie WHERE etat = "en chantier") AS voie_en_chantier WHERE voie_en_chantier.voie = habite.adresse

  TABLE. SQL permet d'en profiter comme suit

	de calcul et dont la sémantique est donnée par l'algèbre relationnelle.
	SQL est donc une sorte de langage de programmation pour qui la table est l'unité
	Langage de contrôle des transactions : voir page 7.
	donne à l'utilisateur Poe tous les droits sur la table habite.
	GRANT ALL ON habite TO poe@localhost
	exemple, la requête
	Langage de contrôle des données : il permet de dire qui a accès aux données. Par
	soit p pnom(s svoie_en_chantier.rue=habite.adresse( habite× × p pvoie(s setat=en chantier(etat_voirie)) as voie_en_chantier)).

  • L'environnement : rester souple, ne pas se sentir propriétaire du projet, faire une veille technologique/réglementaire/économique/etc. Les démarches agiles ont dès leur origine proposé une vision globale incluant les aspects techniques et les aspects psycho-sociaux. C'est une dimension que l'on perd quand on s'en tient à la lettre du protocole d'une démarche agile particulière sans en comprendre l'esprit.

N'oubliez jamais !

Contrairement à une idée trop répandue, un programme n'est pas que le moyen pour un humain de spécifier à une machine ce qu'elle doit faire, mais c'est surtout le moyen d'expliquer à un autre humain ce qu'on spécifie à une machine. En effet, un logiciel (pas un programme jetable genre TP) se construit dans l'espace, c-à-d. les multiples intervenants qui collaborent à sa production, et dans le temps, c-à-d. les multiples étapes du développement de ce logiciel, possiblement prises en charge par des développeurs qui ne se connaissent pas. Même le cas extrême d'un développeur unique se ramène au cas général quand on considère la difficulté qu'éprouve un programmeur à se relire.

2 2⃣ ⃣ CMM ou évaluer la maturité d'une organisation

Dans les années 90, le Software Engineering Institute de l'Université de Carnegie-Mellon propose un modèle pour l'évaluation du niveau de maturité des organisations. Le premier modèle était spécialisé pour le développement logiciel, mais d'autres domaines ont été traités dans les années 2000 sous le nom générique de CMMI. Ces modèles s'appellent des Capability Maturity Models (CMM, + I pour Integration). Les modèles CMM distinguent 5 niveaux de maturité : 1. Initial ou héroïque : l'issue d'un projet ne dépend que des qualités individuelles des participants, et de la chance. Aucune maturité. 2. Discipliné ou reproductible : c'est le premier niveau qui témoigne d'un effort de gestion de projet. Un important apport de ce niveau est que le processus soit reproductible et accumule l'expérience. Ce qui a marché remarchera, ce qui n'a pas marché… Comparer avec la situation du TP qui marche un jour, mais ne marche plus le jour de le rendre. 3. Ajusté ou défini : les savoir-faire sont documentés, il est prévu de la formation pour les maintenir. Comparer avec la situation du TP qui marche pour un binôme, mais pas pour un autre.

4. Géré quantitativement ou maîtrisé : les objectifs sont documentés et la qualité des résultats évaluée par rapport aux objectifs. Comparer avec la situation du TP qui passe les tests des élèves, mais pas ceux du professeur.

5.

Optimisé : un processus qualité vise à l'amélioration continue des performances en recherchant l'alignement des valeurs techniques et des valeurs business.

Cycle de vie en spirale

  Plus avancé que le modèle en cascade le modèle du cycle de vie en V modélise les étapes du développement de façon à mettre en correspondance les échecs de vérification/validation et leurs causes probables. Il est aligné sur un modèle général d'ingénierie des systèmes qui s'est développé dans les années 80.Dans ce modèle, l'analyse est organisée en niveaux de détail croissants, et la vérification/validation l'est en niveaux d'intégration croissants. L'idée est de mettre en vis-à-vis les niveaux d'analyse les plus détaillés avec les niveaux de vérification/validation les moins intégrés. De façon duale, les niveaux d'analyse les moins détaillés seront mis en vis-àvis des niveaux de vérification/validation les plus intégrés. De cette façon un échec à un niveau donné désigne le niveau d'analyse qui lui correspond comme cause probable. Ce modèle crée un effet de tunnel où une erreur commise très tôt, donc à l'entrée du tunnel, ne pourra être détectée que très tard, à la sortie du tunnel. Ces erreurs seront donc extrêmement coûteuses.On doit reconnaître cependant que dans les premières présentations de ce modèle de nombreuses autres formes d'itération étaient prévues, ex. dans la branche de gauche. Afin de répondre au reproche fait au modèle en V, on propose un modèle en spirale où on itère les A, C, ID et VV pas seulement pour répondre aux échecs de vérification/validation, mais d'abord dans une prise en compte progressive des exigences de l'application visée. De cette façon, on enchaîne des « tours » de spirale assez rapides, ce qui évite l'effet de tunnel propre au modèle en V.Le cycle de vie en spirale est la base de l'agilité quand on ajoute l'exigence supplémentaire que ce est produit chaque tour ait du sens dans le monde du client. Ex. si un système logiciel comporte plusieurs couches, il n'est pas question de réaliser la 1ère couche dans une 1ère itération, puis la 2nde dans une 2nde itération, …, car ces couches n'ont pas de sens pour le client. Elles sont juste le Comment imaginé par les développeurs pour la réalisation d'un Pourquoi seul compris par le client. Au contraire, il faut produire à chaque itération une réponse partielle au Pourquoi du client qui passe par des fragments de toutes les couches du système.

				Besoin
				?
				Codage
				Intégration
				Déploiement
				Vérification
				Validation
	3 3⃣ ⃣ Cycle de vie en V
				4 4⃣ ⃣
	Besoin			Validation (recette)
	Analyse	Vérification 2
	fonctionnelle	(test d'intégration)
	Le principal reproche modèle est qu'il éloigne	Analyse détaillée	Vérification 1 (test unitaire)	qu'on adresse à ce l'analyse de plus haut
	niveau de la validation correspondante, alors d'analyse qui comporte le plus de risque	qu'on reconnaît que c'est justement ce niveau d'erreur. Codage

Her stands for her/his, and similarly she stands for she/he.

International system of units -Système international d'unités ; ISO 80000-1:2009

ISO 216

It is not our objective, and three material reasons oppose to readability: (1) their subject is plain computer science, (2) they are written in French, and (3) they are reduced by a linear factor

(i.e. area reduction by 25) to fit in the page as figures.

including a yearly revision