Xerox Common Lisp Development Project: development process overview Ron Fischer XAIS Bldg 32-215 8*923-5749 This document sets out how I view the development process. Comments appreciated. First, we have the encompassing process of creating the Xerox Lyric Release with "Common Lisp". This involves all the sections of the business unit coordinating themselves to make cardboard boxes containing high quality books and bits, and then both teach courses and answer questions on the phone about them. Here in development our job is to create a reasonably reliable piece of software to turn over to alpha test by the week of July 15th. It has to be good enough to keep from causing coronaries in Pasadena (be nice, the water and air are not as good down there as they are up here). Between now and then we've a large system to implement. The best way to do this is work hard, keep track of issues you discover and keep in communication with me, your backup partner, and others who can help you. To make working hard a bit more pleasant we'll do things like bring in dinner when the going gets rough. What you should have If you're missing anything tell me and I'll get it for you. 0) This sheet 1) "The good book" (tm) or "Common Lisp: the Manifesto" by Guy PigIron 2) Corrections and interpretations lists from the CL mailing list 3) Your task outline and partner assignment (sure you can change partners but let me know) 4) Up to date project schedule charts will be posted on the wall near my office The overall process For every major piece of the CL system that you implement there's a simple process that hopefully occurs: 1) Design document - for an initial period of about a week you create the design document a) issues section - you examine the issues raised by the part of the system you have to implement. You write down in the design document what these issues are and how you plan to solve them. You describe generally the steps you'll take and how the software works if it has an interesting structure (like the grammar for a parser in pathname code). b) documentation section - It is important to mention any documentation issues that arise. These are any interpretations or extensions to what is stated in the Silver Book. These are needed because we'll be shipping the Silver Book and a set of implementation addenda. These notes should be entered as documentation ARs and the AR number mentioned in the design document. c) testing section - Two things here, a description of edge cases that could be poked at in future serious testing of this code and a file of broad but shallow test case forms. These should reside in a file with extension TEST in the same directory as the design document (this is an interim location chosen because its handy). The test cases should exercise basic functionality, on the order of "Are all the functions defined and do the most important of their argument combinations work?" You should not spent alot of time on this, not more than a few days at most. Suggestion: use test cases in the Silver book when possible. d) handoff - You announce your first complete draft of the design document on XCLispCore^.PA. This is important because I will then get copies off to documentation and testing, who then are enabled to perform tasks in parallel for us. Major later revisions to te design document should be announced as well. 2) Implementation Using your plan you forge ahead into coding. Because of the size of the project and interrelationship of its parts there's a strong temptation to go off on tangents or cross over into other tasks. Please don't work on anything else until you've completed all your tasks for Common Lisp. AIS is depending on each of us in a very real way. Keep from straying into another implementor's territory unless you've spoken to them. Be sure to mention to me if something comes up that you anticipate will have an impact on your abilty to complete or continue your work. No one should just wait if something blocks them. Figuratively speaking we can get or build jackhammers of all sizes... 3) First testing This entails allowing your test cases to traipse through your code. Ideally you should poke at the soft areas described by the edge caes a bit as well. You should reserve the last week or two of your development time to do this. With the schedule being as tight as it is there's alot of reason to try to make it on time with your parts of the software. 4) Final handoff Away it goes into the hands of first the other developers, and sometime on or before July 15th, to the testing group. ($$(( TIMESROMAN TIMESROMAN TIMESROMAN 'R7@<ňPjHM>g,° e v kzş