![[spacer]](/schemes/blue/line.gif){kind=small}
Summarized by AndrewRizwan'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:
References: 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 ProgrammingPair 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.
References:
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:
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. References:
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. Summary: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. |
