Module 14: Customizing Leap

Objectives:	The objectives of this module are: To explore the use of Leap in an alternative development context.
Tasks:	So far in this course, you have been using a "shrinkwrapped" version of Leap, in which we have provided you with document, defect, size, phase set, and project definitions. In addition, we have provided you with a set of specifications for each project you've carried out. This is a good way to begin learning about reflective software engineering and the Leap toolkit, but finesses a critical requirement for adoption of reflective software engineering: the ability to define your own approach to development and reflect upon different kinds of work products and work environments. In this module, we want you to "spread your wings", as it were, and investigate the use of the toolkit in some new context. The only limitations on the domain of application is that (a) the activity results in the generation of a work product (or set of related work products) (b) at least 5 hours of effort are required to generate the work product(s), and (c) at least two projects can be defined in the domain. Once you have chosen a domain of application, then you customize Leap to that domain by defining an appropriate document type, a set of defect types, a size type, a phase set, and of course a project definition (including GQM data). For example, suppose you are also enrolled in a writing class, and you are required to turn in a paper every two weeks. You know that you spend well over 5 hours working on each paper, so this domain would be appropriate for this module. The document type could be "English paper". The defect types could include "010: misspelling", "020: passive voice", "030: run-on", etc. The size type could be "words", and have only one level. The phase set could include "initial draft", "review", and "revision". If you are working, you could use this opportunity to apply Leap to your workplace. Once again, you need to identify a kind of work product that you will create at least two instances of during the next several weeks, and the appropriate definitions. There are three stages to this module: Identifying the domain, and obtaining instructor approval. You need to first figure out what you want to record using Leap. Then, you need to send an email message to me briefly describing what you plan to record and what your work products are. I will reply immediately to approve or disapprove this choice of domain. Once your domain is approved, you define the Leap definitions in whatever way you see fit, and begin collecting the data as you work on the project. Once you have collected the data on the two projects, you must write a brief postmortem on the experience. Your postmortem should consist of answers to the following: Analysis of my Leap data gave me the following insights into my development activities in this domain: The most useful aspects of Leap for these activities were: I would make the following changes the next time I apply Leap to a new development context:
Assessment:	This module is due during the first week of December, 1999. It can be turned in sooner if the module requirements have been met. Your grade for this module will be based upon your personal interview with Philip on the contents of this module. You must turn in a diskette containing the Leap data file for these projects. (The data file can be the same one as the one you are using for the 613 projects, or a separate file.) Some of the issues to be covered in the assessment include: Your data should include appropriate definitions for the various Leap data items of importance to this domain. The Leap data should be complete and accurate. Your GQM definitions should be tied to the Leap data. Your answers to the postmortem questions should be thoughtful, reflective, and insightful. They should also be grammatically correct and clearly written.