Course Documents
     Main Page
     Contact Information
     Course Announcement
     Schedule and Syllabus
     Course Participants
     Discussion Forum
     Swiki Chat Area
     Lecture Material
     Independent Research
     Previous Course
Swiki Features:
  View this Page
  Edit this Page
  Printer Friendly View
  Lock this Page
  References to this Page
  Uploads to this Page
  History of this Page
  Top of the Swiki
  Recent Changes
  Search the Swiki
  Help Guide
Related Links:
     Atlas Program
     Center for LifeLong Learning and Design
     Computer Science Department
     Institute of Cognitive Science
     College of Architecture and Planning
     University of Colorado at Boulder
Summarized by Andrew

Rizwan's progress:

Software development processes involve a significant amount of risk in various forms such as schedule slips, business changes, increasing cost of change etc. Extreme programming attempts to minimize these risks for projects of a certain nature. I would be looking into the strategies for various phases of an extreme programming project, namely:

  • Planning strategy: I have so far looked into the principles of planning. In XP, the aim is to plan such that there will be little inertia when a change is to be made later on. I am finding ways in which the XP paradigm of planning is more flexible than a traditional process.

  • Management strategy: Both centralized and decentralized models of management (and responsibility) have their own pros and cons. My aim is to research how the basic principles of XP guide in finding the balance point on the spectrum of centralized/decentralized styles. In addition, I have also tried to get myself acquainted with the issues that guide the economics of software development.

  • Design strategy: I have read case studies of some projects that were done using the XP methodology. From this study, I can conclude that simplicity and continuous refinement are the cornerstones of any design strategy in an XP project. I am trying to find out how this strategy works and where it fails. In particular, I will read more literature and research how the design strategy affects the costs of any future changes in design.

  • Development strategy: Pair programming, continuous integration and collective ownership are the techniques through which a development episode proceeds to completion. I am reading literature to understand the details of each of these techniques in order to get the bigger picture of XP development phase.

  • Testing strategy: In XP, the testing of modules proceeds side-by-side with the development phase. Test cases are written before coding starts and in conjunction with the customer. My study of the testing strategy so far has focused on the seamless integration of testing with development. I will delve further into this theme.


1. Extreme Programming Examined, Giancarlo Succi and Michele Marchesi

2. Agile Software Development: Principles, Patterns and Practices, Robert C. Martin

3. Extreme Programming Explained, Kent Beck

4. Comparative evaluation of software development strategies based on Net Present Value, Hakan Erdogmus

Randell's progress:

Pair Programming

Pair Programming occurs when two programmers work side-by-side at one computer collaborating on the same design, algorithm, code or test. This practice helps to achieve higher quality products that are produced faster. Yet most that have not tried and tested pair programming reject the idea immediately as an overtly redundant, wasteful use of programming resources. One important result is that those who are involved in Pair Programming have an enjoyable experience in problem-solving and are more confident in their solutions. I have several papers that ranger from the anecdotal to the experiment set that proof the previous statement.
Pair Programming has been used for a long time, yet its popularity came out when Extreme Programming (XP) software development methodology started evolving in 1996 by Kent Beck, Ward Cunningham and Ron Jeffries. They credit that much of XP success is due to the heavy use of Pair Programming by all their programmers, experts and novice alike.

How it works?

One partner is the "driver" and has control of the pencil/mouse/keyboard and is writing the design or code. The other person continuously and actively observes the work of the driver: watching for defects, thinking of alternatives, looking up resources, and considering strategic implications of the work at hand. The roles of driver and observer are deliberately switched between the pair periodically. Both are equal, active participants in the process at all times and wholly share the ownership of the work products whether they be a morning’s effort or an entire project.

  • Pair Development: At times a pair must split; experienced pair programmers prioritize which parts of the development cycle are most important to work together, which can be done separately, and what to do with the independently developed work when reuniting.
  • Pair-analysis and Pair-design are critical for the pair success. It is important for the pair to collectively agree on the development direction and strategy outlined during these stages. Even more, doing such stages in pairs significantly decreases the probability of proceeding with a bad design. The pair that is observing when doing pair-analysis or pair-design can be thinking more strategically about the implications of the design and can perform continuous design reviews, hence preventing and removing defects as soon as they hit the paper.
  • Pair-implementation occurs when the pair starts writing the code. Again, the driver is in charge of using the keyboard, while the other is actively observing. This allows for performing a continuous code review and considering strategic implications of the implementation. Hence there is an efficient form of defect removal right from the start of coding.
  • Pair-testing, although is not heavily used, it helps as long as the pair develops the test cases together. They can later split to perform the test cases and reunite to analyze their results.


  • "Exploring the efficacy of distributed pair programming" by Prashant Baheti, Dr Edward Gehringer and Dr David Stotts
  • "All I Really Need to Know about Pair Programming I Learned In Kindergarten" by Laurie A. Williams and Robert R. Kessler
  • "Strengthening the Case for Pair-Programming" by Laurie Williams, Robert R. Kessler, Ward Cunningham and Ron Jeffries
  • XTreme Programming website

Andrew's progress:

Extreme programming is one reaction to the challenge of modern software programming. The difficulties of collaboration in software development have been observed by many, from Fred Brooks to a variety of authors today. Recipes like Extreme programming can be very effective, but do not work for all environments. To understand collaboration in the software development process, one must understand the factors at work. To improve collaboration in software development, one should apply a sensible subset of available techniques to the particular situation. I am comparing core practices of extreme programming, such as:

  • Planning Techniques
  • Release cycle
  • Design Techniques
  • Collective ownership
  • Pair programming
  • 40 hour week
  • Coding standards

to other viewpoints present in the marketplace of ideas. The idea here is to avoid wholesale consumption of rule of thumb, or recipe type practices, and carefully analyze techniques for their viability in a live and changing development environemnt.

  • Rapid Development by Steve McConnell
  • Agile Software Development with Scrum by Schwaber and Beedle
  • Peopleware by Tom DeMarco and Timothy Lister
  • extreme Programming explained by Kent Beck
  • Software for your Head by McCarthy and McCarthy
  • After the Gold Rush - Creating a True Profession of Software Engineering by Steve McConnell (library book)

Nilo's progress:

Collaboration in Software Development Process: Project Management for Rapid Application Development Progress Report Nilo Tsung

When you build a product, it is important to go through a series of predictable steps � a road map that helps you create a timely, high-quality result. The road map that you follow is called a �process.� From the point of view of a software engineer, the products of software development process are the programs, documents, and data produced as a consequence of software engineering activities defined by the process. Software metrics refers to a broad range of measurements for computer software. Measurement can be applied to the software process with the intent of improving it on a continuous basis. Within the context of software project management, we are concerned primarily with productivity and quality metrics.

Rapid application development (RAD) is an incremental software development process model that emphasizes an extremely short development cycle. The RAD model is a �high-speed� adaptation of the linear sequential model in which rapid development is achieved by using component-based construction. If requirement are well understood and project scope is constrained, the RAD process enables a development team to create a �fully function system� within very short time periods (e.g. 60 to 90 days). Used primarily for information systems applications, the RAD approach encompasses 5 phases, (1) business modeling, (2) data modeling, (3) process modeling, (4) application generation, and (5) testing and turnover. Several smaller teams can simultaneously develop a project, if the amount of programming work is large and dividable. It becomes extremely crucial to the RAD project to have good collaboration among its teams. This research focuses on how to apply an emerging project management technique� virtual design team (VDT) - to model collaboration among teams in the RAD process.

The VDT framework, which explicitly models information dependency and failure propagation between concurrent activities, has been proven in the construction industry to be far more accurate, and to incorporate a wider range of parameters, than CPM/PERT process models for the fast-paced development projects. I have finished reading the relevant information listed in the references. I have sent an email to Stanford University�s Professor Raymond Levitt, one of the original developers of the VDT system, requesting for a copy of the system. Hopefully, I can get one for free, so that I can use the VDT system to model, at least, one of RAD paradigms covered by my research teammates.

References 1. Kunz, J. C., Levitt, R. E., and Jin, Y. (1998), �The Virtual Design Team: A Computational Simulation Model of Project Organizations,� Communications of the Association for Computing Machinery (CACM), 41(11), November, 1998, pp. 84-91.

2. Pressman, R. S. (2001), Software Engineering: A Practitioner�s Approach, McGraw Hill Co., Boston.


Although our progress reports for this independent research are separate, we are working toward a comprehensive assessment of collaboration in the software development process, with a focus on the extreme programming methodology. Rizwan is examining overall strategies of extreme programming, and how these strategies can assist collaboration in this process. Randell is looking in detail at a specific technique of extreme programming, pair programming. This examination will uncover useful insight into collaboration "in the small" between software developers. I (Andrew) am examining alternative approaches to solving software collaboration issues, to help people involved in software collaboration understand better how various techniques will fare in their own environment. I am also examining alternatives to some of the elements of extreme programming that may not be compatible with certain collaboration environments. Nilo is putting these conjectures to the test by applying project simulation software to analyze these different approaches. Bringing all of our work together, we hope to provide class members with an understanding of rapid development processes and their interaction with software development collaboration.

View this PageEdit this PagePrinter Friendly ViewLock this PageReferences to this PageUploads to this PageHistory of this PageTop of the SwikiRecent ChangesSearch the SwikiHelp Guide