1 / 16

Applying Pantomime and Reverse Engineering Techniques in Software Engineering Education

Applying Pantomime and Reverse Engineering Techniques in Software Engineering Education. Vladimir L Pavlov, Nikita Boyko, Alexander Babich, Oleksii Kuchaiev, Stanislav Busygin. Agenda. Students’ Practical Experience. Small Projects Easy to implement in university environment

josette
Télécharger la présentation

Applying Pantomime and Reverse Engineering Techniques in Software Engineering Education

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Applying Pantomime andReverse Engineering Techniquesin Software Engineering Education Vladimir L Pavlov, Nikita Boyko, Alexander Babich, Oleksii Kuchaiev, Stanislav Busygin http://www.intspei.com

  2. Agenda http://www.intspei.com

  3. Students’ Practical Experience • Small Projects • Easy to implement in university environment • Students learn: • Software Engineering methods create additional overhead – without them it would be more easy to complete the project • If you want to finish your project faster, you code and then create (fake) all the documentation to meet “official” requirements • Negative learning experience • Large Projects • Hard to implement in university environment • Students learn: • Software Engineering methods create value – without them it would be more difficult to complete the project • If you follow your SDLC, you finish your project faster and with less bugs • Positive learning experience http://www.intspei.com

  4. “Dirty Tricks to Train Software Engineers” • Give an inadequate specification • Make sure all assumptions are wrong • Have conflicting requirements and pressures • Give additional tasks to disrupt the schedule • Change the deadlines • Crash the hardware • . . . Ray Dawson “Twenty Dirty Tricks to Train Software Engineers”, Proceedings of the 22nd International Conference on Software Engineering, 2000, pp 209-218. http://www.intspei.com

  5. SE2004 • Curriculum designers must strike an appropriate balance between coverage of material, and flexibility to allow for innovation. • The underlying and enduring principles of software engineering should be emphasized, rather than details of the latest or specific tools. • In order to ensure that students embrace certain important ideas, care must be taken to motivate students by using interesting, concrete and convincing examples. • Software engineering education in the 21st century needs to move beyond the lecture format: It is therefore important to encourage consideration of a variety of teaching and learning approaches. • Important efficiencies and synergies can be achieved by designing curricula so that several types of knowledge are learned at the same time. http://www.intspei.com

  6. Evolution of P-Modeling • 2001: Speechless modeling – will it work? • 2003: Are “normal” teams performing better, than “speechless”? • 2005: Can we use reverse engineering as a quality-control tool? • 200X: ?-?-?-?-?-?-?-? http://www.intspei.com

  7. P-Modeling Session http://www.intspei.com

  8. Current Experience of Using P-Modeling Sessions in Universities • Four universities in Ukraine/Russia • Never a required part of curriculum • always an option for students to choose an alternative activity • usually 30%-50% of students choose to participate in a P-Modeling Session • Around 200 participants so far • undergraduates in their third, fourth or fifth year of studying Software Engineering or Computer Science http://www.intspei.com

  9. Feedback From Students 100% would want to participate in such events again and/or to organize such events in their professional practice in the future 100% would recommend attending such sessions to others 100% assess Reverse Semantic Traceability as an extremely powerful tool to validate software design and want to use it in their practical work in the future 93% of all participants consider Speechless Modeling a powerful tool for learning Object-Oriented Analysis and Design with UML 90% mentioned improving of their team working skills 71% of participants think that such sessions can help new team members to understand the domain area more quickly than traditional approach 52% said that Speechless sessions taught them to create more precise models more quickly http://www.intspei.com

  10. Sample Assignment and Outcome of P-Modeling Session …. … are Available in the Article (see Conference Proceedings) http://www.intspei.com

  11. Submit Your UML Jokeand Win a Brand-New Laptop! • How powerful is UML to express humor? • The project is aimed to • research semantic capabilities of the UML • attract the community’s attention to it • A chance to win a brand-new laptop, PDA or another exciting prize • www.umljokes.com http://www.intspei.com

  12. Summary http://www.intspei.com

  13. Backup Slides http://www.intspei.com

  14. Cost to Correct Maintenance Requirements Construction Architecture DetailedDesign Detailed Design Architecture Construction Requirements Phase That a Defect is Created Phase That a Defect is Corrected INTSPEI P-Modeling Framework • The most important decisions (and most expensive mistakes) are done at the beginning of the project • The initial amount of quality control is minimal and then grows as development moves forward. • This results in a costly rework (often hidden) on the late stages of the project • INTSPEI P-Modeling Framework addresses this problem. It enables to reduce delays between bug insertions and bug fixes • Engineers start discovering and fixing critical mistakes virtually immediately - when introduced - not at the late phases where they are the most expensive to resolve Cost to correct a defect greatly depends on how early it was introduced and revealed http://www.intspei.com

  15. Iterative Development

  16. Traceability Management

More Related