Differences

This shows you the differences between two versions of the page.

--- teaching:reverse:2017:start [2017/12/17 13:42]
blay [Références]
+++ teaching:reverse:2017:start [2018/12/16 20:24] (current)
blay old revision restored (2018/11/23 07:26)
@@ Line 43: / Line 43: @@
 ====== Planning ======
   - mar.19 déc. 2017
-     * //08:00 – 10:00// : Cours - Introduction  // (MBF)//
+     * //08:00 – 10:00// : {{:teaching:reverse:2017:introcoursmaintenance.pdf|Cours - Introduction}}  // (MBF)//
      *  //10:00 - 11h00 // : Autonomie
      * //11:15 – 12:15// : TD - Choix et caractérisation du sujet d'étude  //(MBF,SM,PC)//
-     *  lundi 8 janv. 2018	 à 15h au plus tard  <badge> Livrable L.1 </badge>
+     *  lundi 8 janv. 2018	 à 15h au plus tard  <badge> [[teaching:reverse:2017:evaluation|Livrable L.1]] </badge>
   - mar.9 janv. 2018
      * //8:00 – 9:00//  : TD - Compléments sur le sujet en mode "coaching" //(MBF,SM,PC)//
@@ Line 52: / Line 52: @@
      * //10:00 – 12:15// : Autonomie
   - mar.16 janv. 2018
-     * //08:00 – 09:30// : Cours - Comprendre un logiciel en regardant son histoire //Xavier Blanc(XB)//
+     * //08:00 – 09:30// : Cours - Comprendre un logiciel en regardant son histoire //Xavier Blanc(XB)// (https://promyze.com/)
      * //09:45 – 12:15// : TD - Validations Métrics/KPI //(MBF,XB)//
   - mar.23 janv. 2018
-     * //08:00 – 11:00// : Oral (10mn exposé + 10mn questions) (MBF,PC) <badge> Exposé E.1</badge>
+     * //08:00 – 11:00// : Oral (10mn exposé + 10mn questions) (MBF,PC) <badge> [[teaching:reverse:2017:evaluation|Exposé E.1]]</badge>
   - mar.30 janv. 2018
-     * Remise des articles à avoir lu pour l'examen
+     * //09:45 – 12:15// : Autonomie
-     * //09:45 – 12:15// : Autonomie   <badge> Livrable L.3 </badge>
   - mar.6 févr. 2018
-     * //08:00 – 10:00// : TD - Travail sur les choix d'articles, démarche & Métrics/KPI //(SM,PC)//
+     * //08:00 – 10:00// : TD - Travail sur les articles sélectionnés par les étudiants, démarche & Métrics/KPI //(SM,PC)//
-     *  //09:45 – 12:15// : Autonomie <badge> Livrable L.2 & L.4 </badge>
+     *  //09:45 – 12:15// : Autonomie
+     * lundi 12 février 18h  <badge> [[teaching:reverse:2017:evaluation|Livrable L.2]] </badge>
   - mar.13 févr. 2018
      * //08:00 – 9:00// : Intervention d'un industriel
   - mar.20 févr. 2018
+     * Annonce de la sélection des articles utilisés pour l'examen
      * //08:00 – 11:00// : Autonomie
   - mar.27 févr. 2018
-     * //08:00 – 11:00// : Examen<badge> Livrable L.5 & Livrable 6</badge>
+     * //08:00 – 11:00// : Examen<badge> Livrable L.3 & Livrable 4</badge>
@@ Line 82: / Line 83: @@
 </callout>
-<accordion  collapsed="true">
-<panel  title="Livrables du module">
-  * <alert type="info"> Livrable  L.1.: "Voici mon sujet" </alert>
-                                             *  //Objectifs de ce livrable : Vérifier que vous avez identifié votre sujet  et les questions associées.//
-                                             * Il comprend sous la forme qui vous convient :
-                                                    - <todo> la question générale  &  pourquoi vous la trouvez intéressante</todo>
-                                                              - <todo> la décomposition en sous-questions et les métriques/KPI/outils **envisagés** pour y répondre </todo>
-                                                              - <todo> la démarche prévue </todo>
-                                                              - <todo> les 2 articles au moins sur lesquels vous pensez vous baser pour répondre à la question. Un doit se trouver dans la rubrique généralité, un autre dans la rubrique études. Vous pouvez avoir vous-même suggéré des articles dans ces 2 rubriques. Dans ce cas, ils doivent être validés par les enseignants.</todo>
-                                                               * Il ne faut hésiter à évoquer plusieurs pistes si les choix ne sont pas faits.
-                                                     - <todo> Chaque groupe a créé un chapitre dans le livre précisant les auteurs, et chaque auteur est bien "associé" au livre </todo>
-                                             * **date limite : 8/01 à 15h**.  Le rendu se fait sur Slack.
-   *  <alert type="info">  Exposé E.1 : Présentation du projet </alert>
-             *  //Objectifs de ce livrable : Evaluer l'avancement des projets et préparer la phase en autonomie//
-                     -  10mn d'exposé, 10mn de questions par groupe : 20mn par groupe.
-                     -  ** Date : 23 janvier de 8h à 12h00 **
-                     - Utilisation de Slack pour partager les questions du groupe aux différents sous-projets
-/*
-  * <alert type="info"> Livrable L.2. : Retour d'expériences sur les outils,</alert>
-                                            *  //Objectifs de ce livrable : Vérifiez que votre démarche est cohérente et que vous savez utiliser des outils.//
-                                            *   date limite : **6/2 à 23h59**  @todo<forme à expliciter>
-                                            * Le rendu explicite  :
-                                                    - <todo> les questions  auxquelles vous voulez répondre et votre utilisation des outils en cours et prévue,</todo> POurquoi c'est cette question? Quels éléments je vais expoliter? Comment je vais le démontrer? Protocole d'expériemntation? Les rsiqes et limites du protocole.
-                                                    - <todo> en quoi les expérimentations doivent répondre aux questions posées, vos attentes en terme de validation </todo>
-                                                    - <todo>  les premiers résultats obtenus</todo>
-                                                    - <todo>  les difficultés rencontrées s'il y en a </todo>
-  * <alert type="info"> Livrable L.4. : Evaluation des retours d'expériences sur les outils,</alert>
-                                            *  //Objectifs de ce livrable : Apprendre des travaux des camarades et montrer vos capacités critiques.//
-                                            *   date limite : **12/2 à 23h59**  @todo<Lieu à expliciter>
-                                            * Le rendu explicite  :
-                                                    - <todo> @todo une critique par étudiant/ 4 differentes par groupes/ Distributions faites avant par binding? </todo>
-                                                    - <todo> Vous avez compris, vous adhérez à l'approche proposée, vous avez identifié des hypothèses, erreurs, non identifiées par les auteurs, vous avez appris (rien, un peu , ..) </todo>
-                                                    - @todo mettre en place une form
-  * <alert type="info"> Livrable L.3. : Synthèse d'articles scientifiques</alert>
-                                            *  //Objectifs de ce livrable : Montrer que vous savez faire une synthèse d'articles scientifiques et utiliser les résultats dans vos travaux//
-                                            *   date limite : ** 4/02 à 23h59 **  @todo<Lieu à expliciter>
-                                            * Le rendu explicite  :
-                                                    - <todo> @todo nbre de pages </todo>
-                                            * qui ou comment  <todo> @todo</todo> une partie chacun dans le groupe et une synthese globale...
-  *  <alert type="info">  Exposé E.2 : Bilan de compétences.</alert>
-                     - Ouvert à un pannel d'experts précisés ultérieurement
-                     -  10mn d'exposé, 10mn de questions par groupe : 20mn par groupe.
-                     -  ** Date : 20 février de 8h à 12h00 **
- */
-  *  <alert type="info">  Rendu L.5 :  Contenu du livre </alert>
+**[[teaching:reverse:2017:Evaluation|Livrables du module : détails]]**
-              * @todo a revoir
-              * Evaluation par  plusieurs relecteurs extérieurs
-              * Critères d'évaluation :
-                     * Méthode suivie et argumentaire
-                     * Rédaction
-                     * Résultats
-                      * Recul et Pertinence des remarques
-                      *** Date limite : 27 février à 23h59**
-  *  <alert type="info">  Rendu L.6 :  Codes/Resultats Brutes/</alert>
-                         * Livrable en fonction des artefacts utilisés, l'objectif est de rendre l'expérimentation reproductible.
-                         *** Date limite : 27 février à 23h59**
-  *  <alert type="info">  Examen </alert>
-                         *** Date : 27 février ** @todo forme à préiciser
-</panel>
-</accordion>
@@ Line 205: / Line 143: @@
 Vous pouvez proposer d'autres articles, mais dans ce cas, les faire valider par les enseignants.
-[[teaching:reverse:2017:references|Références]]
+**[[teaching:reverse:2017:references|Références]]**
-===== Généralités =====
-<accordion  collapsed="true">
-<panel  title="Articles généraux présentant les principes de RIMEL">
-        - {{:teaching:reverse:swebokv3_-_chap5_-_code_maintenance.pdf|SWEBOK, Chap 5 Maintenance}}
-              * Auteurs Alain Abran, James W Moore, Pierre Bourque, Robert Dupuis, Leonard L Tripp
-              * Date de publication 2004
-              * Guide to the software engineering body of knowledge: 2004 version SWEBOK (chapitre sofware Maintenance)
-       -  {{:teaching:reverse:10.1109_ieeestd.2006.235774.pdf|IEEE Std. 14764-2006 (a.k.a. ISO/IEC  14764:2006)}} Standard for Software  Engineering—Software Life Cycle  Processes—Maintenance, IEEE, 2006.
-       - [[http://www.cc.uah.es/drg/jif/2013HerraizRRG_CSUR.pdf|Herraiz I, Rodriguez D, Robles G, Gonzalez-Barahona JM (2013) The Evolution of the Laws of Software Evolution: A Discussion Based on a Systematic Literature Review. ACM Comput Surv 46:28:1--28:28.]]
-        - Demeyer S, Ducasse S, Nierstrasz O (2002) Object Oriented Reengineering Patterns. Morgan Kaufmann Publishers Inc., San Francisco, CA, USA
-</panel>
- </accordion>
-/*
-       - {{:teaching:reverse:en88-web.pdf||Evolving Sofware}} Vous pouvez vous baser uniquement sur certains articles, mais plus qu'un.
-        - {{:teaching:reverse:kitchenham2002.pdf|Preliminary Guidelines for Empirical Research in Software Engineering}}  Pour ceux qui se posent des questions sur la méthode d'analyse et si besoin {{:teaching:reverse:kitchenham2008.pdf|}}
-Old
-        -{{:teaching:reverse:mens2005iwpse-challenges.pdf| Challenges in Software Evolution}}
-*/
-===== Etudes =====
- <accordion  collapsed="true">
-<panel  title="Sélection d'articles présentant des études de rétro-ingénierie">
-  - [[https://users.uom.gr/~achat/papers/ECSA2017.pdf| The Evolution of Technical Debt in the Apache Ecosystem]]
-         * Authors : Georgios Digkas, Mircea Lungu, Alexander Chatzigeorgiou, Paris Avgeriou
-         * Publication date : 2017/9/11
-         * Conference European Conference on Software Architecture
-         * Pages 51-66
-         * Description :
-                   * Software systems must evolve over time or become increasingly irrelevant says one of Lehman's laws of software evolution. Many studies have been presented in the literature  that investigate the evolution of software systems but few have focused on the evolution of  technical debt. In this paper we study sixty-six Java open-source software projects from the  Apache ecosystem focusing on the evolution of technical debt. We analyze the evolution of these systems over the past five years at the temporal granularity level of weekly …
-   - [[https://pdfs.semanticscholar.org/c585/63d5b643fc7678a939618904d99af7da24e9.pdf|Evaluating an Architecture Conformance Monitoring Solution]]
-         * Authors :  Andrea Caracciolo, Mircea Lungu, Oskar Truffer, Kirill Levitin, Oscar Nierstrasz
-         * Publication date : 2016/3/13
-         * Conference Empirical Software Engineering in Practice (IWESEP), 2016 7th International Workshop on
-         * Pages 41-44
-         * Description
-                   * Architectural rules are often defined but rarely tested. Current tools offer limited functionality and often require significant effort to be configured, automated and integrated  within existing platforms. We propose a platform that is aimed at reducing the overall cost of setting up and maintaining an architectural conformance monitoring environment by decoupling the conceptual representation of a user-defined rule from its technical specification prescribed by the underlying analysis tools. The user is no longer expected …
-   - [[http://web.cs.ucdavis.edu/~filkov/papers/CI_adoption.pdf|The Impact of Continuous Integration on Other Software Development Practices: A Large-Scale Empirical Study]]
-         * Authors :  Yangyang Zhao, Alexander Serebrenik, Yuming Zhou, Vladimir Filkov, Bogdan Vasilescu
-         * Date de publication 2017
-         * Conférence ASE
-         * Description
-                             * Continuous Integration (CI) has become a disruptive innovation in software  development: with proper tool support and adoption, positive effects have been demonstrated for pull request throughput and scaling up of project sizes. As any other innovation, adopting CI implies adapting existing practices in order to take full advantage of its potential, and" best practices" to that end have been proposed. Here we study the adaptation and evolution of code writing and submission, issue and pull request closing …
-   - [[http://www0.cs.ucl.ac.uk/staff/j.krinke/publications/ase17.pdf|Are developers aware of the architectural impact of their changes?]]
-         * Auteurs : Matheus Paixao, Jens Krinke, DongGyun Han, Chaiyong Ragkhitwetsagul, Mark Harman
-         * Date de publication 2017/10/30
-         * Conférence Proceedings of the 32nd IEEE/ACM International Conference on Automated Software Engineering
-         * Pages 95-105
-         * Description :
-                            * Although considered one of the most important decisions in a software development lifecycle, empirical evidence on how developers perform and perceive architectural changes is still scarce. Given the large implications of architectural decisions, we do not know whether developers are aware of their changes' impact on the software's architecture, whether awareness leads to better changes, and whether automatically making developers aware would prevent degradation. Therefore, we use code review data of 4 …
-     - [[http://linyun.info/micode/micode.pdf|Mining Implicit Design Templates for Actionable Code Reuse]]
-         * Auteurs :  Yun Lin, Guozhu Meng, Yinxing Xue, Zhenchang Xing, Jun Sun, Xin Peng, Yang Liu, Wenyun Zhao, Jinsong Dong
-         * Date de publication :  2017/10
-         * Conférence The 32nd IEEE/ACM International Conference on Automated Software Engineering
-         * Pages 394--404
-         * Description
-                            * In this paper, we propose an approach to detecting project-specific recurring  designs in code base and abstracting them into design templates as reuse opportunities.  The mined templates allow programmers to make further customization for generating new  code. The generated code involves the code skeleton of recurring design as well as the semi-implemented code bodies annotated with comments to remind programmers of  necessary modification. We implemented our approach as an Eclipse plugin called …
-    - [[https://hal.inria.fr/hal-01344842/file/Test_Case_Selection_in_Industry-An_Analysis_of_Issues_related_to_Static_Approaches.pdf|Test case selection in industry: an analysis of issues related to static approaches]]
-            * Auteurs Vincent Blondeau, Anne Etien, Nicolas Anquetil, Sylvain Cresson, Pascal Croisy, Stéphane Ducasse
-            * Date de publication 2016
-            * Revue Software Quality Journal
-            * Pages 1-35
-            * Description :
-                    * Automatic testing constitutes an important part of everyday development practice.  Worldline, a major IT company, is creating more and more tests to ensure the good behavior  of its applications and gains in efficiency and quality. But running all these tests may take  hours. This is especially true for large systems involving, for example, the deployment of a web server or communication with a database. For this reason, tests are not launched as often as they should be and are mostly run at night. The company wishes to improve its …
-    -  {{:teaching:reverse:p173-hebig.pdf|The Quest for Open Source Projects That Use UML}}
-            *  Auteurs: Regina Hebig, Truong Ho Quang, Michel RV Chaudron, Gregorio Robles, Miguel Angel Fernandez
-            * Date de publication :  2016/10/2
-            * Conférence Proceedings of the ACM/IEEE 19th International Conference on Model Driven Engineering Languages and Systems
-            *  Pages 173-183
-            *  Description
-                    * Context: While industrial use of UML was studied intensely, little is known about  UML use in Free/Open Source Software (FOSS) projects. Goal: We aim at systematically mining GitHub projects to answer the question when models, if used, are created and updated throughout the whole project's life-span. Method: We present a semi-automated  approach to collect UML stored in images,. xmi, and. uml files and scanned ten percent of all  GitHub projects (1.24 million). Our focus was on number and role of contributors that …
-            * Et aussi :  [[http://dl.acm.org/citation.cfm?id=3104261|An extensive dataset of UML models in GitHub]]
-  -  [[https://arxiv.org/pdf/1703.02925.pdf|Assessing Code Authorship: The Case of the Linux Kernel.]]
-                     * Auteurs Guilherme Avelino, Leonardo Passos, Andre Hora, Marco Tulio Valente
-                     * Date de publication 2017/5/22
-                     * Conférence IFIP International Conference on Open Source Systems
-                     * Pages 151-163
-                     * Description
-                               * Code authorship is a key information in large-scale open-source systems. Among  others, it allows maintainers to assess division of work and identify key collaborators.  Interestingly, open-source communities lack guidelines on how to manage authorship. This could be mitigated by setting to build an empirical body of knowledge on how authorship-related measures evolve in successful open-source communities. Towards that direction, we perform a case study on the Linux kernel. Our results show that:(a) only a small portion of …
-       -  {{:teaching:reverse:ccs221-meneely.pdf|Secure Open Source Collaboration: An Empirical Study of Linus’ Law}}
-                  * Auteurs Andrew Meneely, Laurie Williams
-                  * Date de publication 2009/11/9
-                  * Conférence Proceedings of the 16th ACM conference on Computer and communications security
-                  * Pages 453-462
-                  * Description : Open source software is often considered to be secure. One factor in this  confidence in the security of open source software lies in leveraging large developer  communities to find vulnerabilities in the code. Eric Raymond declares Linus' Law" Given enough eyeballs, all bugs are shallow." Does Linus' Law hold up ad infinitum? Or, can the multitude of developers become" too many cooks in the kitchen", causing the system's security to suffer as a result? In this study, we examine the security of an open source …
-      -[[ https://hal.archives-ouvertes.fr/hal-01471294/document | Code Smells in iOS Apps: How do they compare to Android?]]
-              * Auteurs :  Sarra Habchi, Geoffrey Hecht, Romain Rouvoy, Naouel Moha
-              * Date de publication :  2017/5/20
-              * Conférence :  Proceedings of the 4th International Conference on Mobile Software Engineering and Systems
-              * Pages : 110-121
-              * Description
-                       * With billions of app downloads, the Apple App Store and Google Play Store  succeeded to conquer mobile devices. However, this success also challenges app  developers to publish high-quality apps to keep attracting and satisfying end-users. In particular, taming the ever-growing complexity of mobile apps to cope with maintenance and evolution tasks under such a pressure may lead to bad development choices. While these bad choices, aka code smells, are widely studied in object-oriented software, their study …
-       - **(Non disponible en ligne...)** Code review analysis of software system using machine learning techniques
-              * Auteurs Harsh Lal, Gaurav Pahwa
-              * Date de publication  2017/1/5
-              * Conférence Intelligent Systems and Control (ISCO), 2017 11th International Conference on
-              * Pages 8-13
-              * Description
-                          * Code review is systematic examination of a software system's source code. It is intended to find mistakes overlooked in the initial development phase, improving the overall  quality of software and reducing the risk of bugs among other benefits. Reviews are done in various forms such as pair programming, informal walk-through, and formal inspections.  Code review has been found to accelerate and streamline the process of software  development like very few other practices in software development can. In this paper we …
-     - Beaucoup d'articles proviennent de [[ http://ase2017.org/accepted_papers| ASE 2017]], d'autres peuvent être intéressants en fonction de vos sujets d'études.
-</panel>
- </accordion>
- /*
-    -  Keisuke Hotta, Yui Sasaki, Yukiko Sano, Yoshiki Higo, and Shinji Kusumoto, “[[http://downloads.hindawi.com/journals/ase/2012/938296.pdf|An Empirical Study on the Impact of Duplicate Code]],” Advances in Software Engineering, vol. 2012, Article ID 938296, 22 pages, 2012. doi:10.1155/2012/938296
-*/
-===== Autres études =====
-<accordion  collapsed="true">
-<panel  title="Autres articles">
-     - [[https://www.researchgate.net/profile/Mark_Hall6/publication/221900777_The_WEKA_data_mining_software_An_update/links/09e41507f01ad2a029000000.pdf |The WEKA Data Mining Software: An Update]]
-         * Date 2009
-        * Description :
-                      * More than twelve years have elapsed since the first public release of WEKA. In that time, the software has been rewritten entirely from scratch, evolved substantially and now accompanies a text on data mining [35]. These days, WEKA enjoys widespread acceptance  in both academia and business, has an active community, and has been downloaded more  than 1.4 million times since being placed on Source-Forge in April 2000. This paper provides an introduction to the WEKA workbench, reviews the history of the project, and …
-       - Martinez J, Ziadi T, Bissyandé T, Klein J, Le Traon Y (2015) [[https://www.researchgate.net/publication/282863985_Automating_the_Extraction_of_Model-based_Software_Product_Lines_from_Model_Variants|Automating the Extraction of Model-based Software Product Lines from Model Variants.]] 30th ACM/IEEE Int. Conf. Autom. Softw. Eng. - ASE. ACM/IEEE, Lincoln, Nebraska, United States
-       - Khatoon S, Li G, Mahmood A (2013) Comparison and Evaluation of Source Code Mining Tools and Techniques: A Qualitative Approach. Intell Data Anal 17:459–484. doi: 10.3233/IDA-130589
-     -   Ouni A, Kessentini M, Sahraoui H, Inoue K, Hamdi MS (2015) Improving Multi-objective Code-smells Correction Using Development History. J Syst Softw 105:18–39. doi: 10.1016/j.jss.2015.03.040 (63 pages)
-     - {{:teaching:reverse:bpm-15-01.pdf|Kalenkova AA, van der Aalst WMP, Lomazova IA, Rubin VA (2016) Process Mining Using BPMN: Relating Event Logs and Process Models. Proc. ACM/IEEE 19th Int. Conf. Model Driven Eng. Lang. Syst. ACM, New York, NY, USA, p 123}}
-     - Hassan AE (2009) [[https://www.researchgate.net/publication/221554415_Predicting_faults_using_the_complexity_of_code_changes|Predicting faults using the complexity of code changes]]. Proc. - Int. Conf. Softw. Eng. pp 78–88
-     - {{:teaching:reverse:10.1.1.142.4190.pdf|A survey and taxonomy of approaches for mining software repositories in the context of software evolution}}
-     - Nachiappan Nagappan, Thomas Ball, and Andreas Zeller. 2006. [[https://www.st.cs.uni-saarland.de/publications/files/nagappan-icse-2006.pdf|Mining metrics to predict component failures]]. In Proceedings of the 28th international conference on Software engineering (ICSE '06). ACM, New York, NY, USA, 452-461. DOI=http://dx.doi.org/10.1145/1134285.1134349
-     - [[http://research.cs.queensu.ca/home/ahmed/home/teaching/CISC880/F11/papers/DontTouchMyCode_FSE2011.pdf|Don't touch my code!: examining the effects of ownership on software quality]] C Bird, N Nagappan, B Murphy, H Gall, P Devanbu - Proceedings of the 19th ACM SIGSOFT symposium …, 2011
-   - Foucault M, Palyart M, Blanc X, Murphy GC, Falleri J-R (2015) [[http://www.cs.ubc.ca/~mpalyart/paper/2015_FSE_Impact_Turnover_Quality.pdf|Impact of Developer Turnover on Quality in Open-source Software.]] Proc. 2015 10th Jt. Meet. Found. Softw. Eng. ACM, New York, NY, USA, pp 829–841
-   - Hora A, Robbes R, Anquetil N, Etien A, Ducasse S, Valente MT (2015) [[https://hal.inria.fr/hal-01185736/document|How do developers react to API evolution? the Pharo ecosystem case.]] 2015 IEEE 31st Int. Conf. Softw. Maint. Evol. ICSME 2015 - Proc. Institute of Electrical and Electronics Engineers Inc., pp 251–260
-   -  Silva LL, Valente MT, Maia M, Anquetil N (2015) [[http://rmod.inria.fr/archives/papers/silv15bICSM-cochange-patterns.pdf|Developers’ Perception of Co-Change Patterns: An Empirical Study.]] Proc. 31st IEEE Int. Conf. Softw. Maint.
-    -  Hecht G, Benomar O, Rouvoy R, Moha N, Duchien L (2016) [[https://hal.inria.fr/hal-01178734/document|Tracking the software quality of android applications along their evolution]]. Proc. - 2015 30th IEEE/ACM Int. Conf. Autom. Softw. Eng. ASE 2015. Institute of Electrical and Electronics Engineers Inc., pp 236–247
-    - Karina Sokolova, Marc Lemercier, Ludovic Garcia,{{:teaching:reverse:patterns_2013_1_20_70039.pdf|Android Passive MVC: a novel architecture model for the Android application development}}, in The Fifth International Conferences on Pervasive Patterns and Applications (PATTERNS 2013), May 27 - June 1, 2013 - Valencia, Spain, vol. , pp. 7
-    - {{:teaching:reverse:koch2007.pdf|Software evolution in open source projects—a large-scale investigation|}}  (Evaluer les Lois de l'évolution)
-    - features{{:teaching:reverse:ngo2007.pdf|Empirical-based recovery and maintenance of input error-correction}}
-    -  Benomar O, Sahraoui H, Poulin P (2013) Visualizing software dynamicities with heat maps. Softw. Vis. (VISSOFT), 2013 First IEEE Work. Conf. pp 1–10
-    - [[https://papyrus.bib.umontreal.ca/xmlui/bitstream/handle/1866/11998/Benomar_Omar_2015_these.pdf?sequence=2&isAllowed=y|A Unified Framework for the Comprehension of Software’s Time Dimension]]
-=====  Autres =====
-     -  [[ https://applidium.com/en/news/unbundling_pokemon_go/|Unbundling Pokémon Go]] et la masse de documentations sur le reverse de Pokemon Go... A utiliser avec "responsabilité"
-</panel>
- </accordion>
@@ Line 364: / Line 163: @@
   -Vos IDE fournissent également des outils directement ou sous la forme de plugins, à vous de voir.
 /*  -http://colorbrewer2.org/ mais pas sur... */
+/*
 ====== Exemples de codes pouvant servir à l'analyse ======
@@ Line 378: / Line 179: @@
   -Sous Github ou autre (bitbucket, sourceForge.net) au choix.. en fonction du sujet
   -Voir aussi dans les questions Spoon, IntelliJ, ...
+*/
 ====== Hypothèses et Limites ======
@@ Line 397: / Line 198: @@
 ====== ARCHIVES ======
-[[https://mireilleblayfornarino.i3s.unice.fr/doku.php?id=teaching:reverse:2016|2016-2017]]
+  * [[https://mireilleblayfornarino.i3s.unice.fr/doku.php?id=teaching:reverse:2016|2016-2017]]
+  * [[teaching:reverse:2017:start|2017-2018]]
+  * Retours d'expérience sur le module lors des journées du GDR Génie de la Programmation et du Logiciel :
+         * {{:teaching:reverse:2017:articleciel2017.pdf|article}} et {{:teaching:reverse:2017:rimel-ciel.pdf|exposé}}

Mireille Blay-Fornarino

User Tools

Site Tools

Differences

Page Tools