eXtreme Programming Principles
For each of the twelve eXtreme Programming (XP) principles (the book calls them facets), decide if the principle can and should be applied to your CS 371 team project, and if so, how it might need to be adapted to fit your team project. Be sure to explain why a principle should or should not be applied to your team project. We discussed these principles in class, and the textbook discusses them in Section 2.2.
eXtreme Programming Principles
Extreme Programming is method of software development that is intended to improve software quality which based on simplicity. XP have twelve important principles that may help the project members to organize and develop a clear plan before the start of their project. This essay will discuss each of XP principles if it should or should not be applied on the project, reasons, and the way to apply each principle.
The planning game principle should be applied to our team project because it will organize the team time and give our team a deadline which will motivate the team members to give their maximum in each phase to finish it on time. Our team would use planning poker method to adopt this principle.
Small release principle can be very effective and good to the project. It will help the team to make sure that the project is on the right track. This principle help determining what requirement can we put in the project and then create a release schedule
Our team should use metaphor principle in the project. This principle will be efficient and helpful in our project, to determine a clear vision for all members of the team and to clarify the mechanism of action without getting into differences. This will facilitate the understanding of member of the project and helps to solve problems easily
Simple design is a principle that should be used in our project. The simple design will be useful for the project in several ways. It is simply faster and saves a lot of time given to our
project. Also, it is cheaper and less complex and easier to replace in the event of an error or problem in the code.
It is important to apply a testing principle on our project. Putting the project under some tests will be an effective factor and catalyst for this project. In the event of an error in the code, they could know it and repaired it immediately without continuing on the error. This will save a lot of time and effort and cost given this project. Also, the work of several tests during the lifetime of the project would alert the team members and they will avoid a change of the entire project for a mistake that could have been avoided before
Refactoring principle is very helpful for our team project, and we need to apply this principle on our project because it would improve the structure and performance for our program. After each stage in our project, our team should restructure that part of code if it is necessary to improve it.
Our team project should apply pair programming principle on our project because it has a positive impact on the code quality. Our team will contain two groups, and each group will contain two members. The members in each group should meet several times a week to work on the project
Trust is very important factor for any team to be successful; therefore, our team should apply collective ownership principle on our project. Furthermore, this principle will allow any member in our team to fix the bugs which could be in any part of our project code, and this will be reflected positively on our project.
Continuous Integration means that the team should integrate between all copies of developers working several times a day. This principle is very important for the project to make sure each part of the project complies with other parts to prevent integration problems.
Sustainable pace principle means that each member in our team should not work over 40 hours a week on the project. If we work on the project for long periods of time, this could affect
negatively our study. Also, each member in our group has his private concerns, so our team should adopt this principle. In fact, each member in our team should work in our project between 15 to 25 hours a week.
On-site customer principle aims to let a customer participate in the project; therefore, our team could get feedback from the customer, and develop the project to be commensurate with customer needs. In fact, our project does not target any group of customers, at least in its first version, so our team will not adopt this XP principle. However, we could adopt this point in the future in case when we want to develop our project and make it commercially.
Coding standards principle is very important, and it should be applied to our team project because it would to help each member in our team to understand the code. Therefore, each member in our team could edit other’s member work easily. Also, this principle will help our team to do other practices such as testing. However, to apply this principle, we should agree on one coding style, and each member should follow this coding style when he program his section.
In conclusion, extreme programming principles are very important, and these principles should applied on our team project, exclude the on-site customer principle which is not needed in this version of our project.
Section 3.4 discusses risk management in a project, and Sidebar 3.4 lists Boehm’s “top 10” list of risk items (Boehm is the one who created the spiral process model). The risk item is given in italics, and then the possible management actions or techniques are listed afterwards in plain font. For each risk item, discuss how it may apply to a CS 371 project, and what actions or techniques might be used to control the risk.
Boehm’s Top Ten Risk Items
Risk management is the process of analyzing, identifying and prioritizing potential risks and problems that may occur in the future of the project. When the risk is determined the team project could find the solutions and strategies to reduce and minimize the problem or avoid the problem before it happens. Boehm identify ten risks item and its potential solutions. This essay will discuss Boehm ten risks that could impact on the CS371 projects and the techniques that may help to avoid these risks.
Personnel shortfall: each member in a project team has different skills, and this skills could be in low level which could affect negatively on the project team because this member will not be as effective as other member in the team. For example, a team project works on project which need to be programmed by python language, so if any member in this has not the sufficient skills in python language will be a burden on the team. Therefore, the team need to select their members carefully when they start building their team to avoid this personnel shortfall risk. Also, the team could avoid this personnel shortfall risk by training their team members.
Unrealistic schedules and budgets: this risk item is commonly happen in software project because sometimes the team project finds that they need more time and money to finish their project. Therefore, to deal with this risk the team management has to detailed multi-source estimation for their project, so they can make best estimations for schedules and budget and for that project. As a result, the team project could avoid the risk which is associated with unrealistic schedules and budgets.
Developing the wrong functions: sometimes the team project develops the wrong functions for their projects. For instance, a team tried to create a chess game, but at the end of their project the team found that the game functionalities did not work well. Therefore, that team has had to analysis the mission to understand all parts about their project; indeed, the team has had to create prototype of their project to be certain about their game functionalities.
Developing the wrong user interface: Designing inappropriate user interface is a possible risk in any software project. For example, the team project could develop a user interface for their project which is not easy to use. Hence, this user interface will have negative impact on the project. Prototyping and analyzing the user interface could help the team to avoid this risk of developing unfriendly user interface.
Gold-plating: Designing a software project with extra unnecessary features considers a risk for that project because this extra features could increase the cost of that project and increase the time which is needed to finish the project. Hence, to control this risk item, the team project has to analyse the cost-benefit of this extra features to determine the effects of adding these features.
Continuing stream of requirements changes: the continuous changes in any software project requirements’ could introduce the risk to that project. However, using the incremental development to defer the changes to later increments could help to reduce the risk which is associated with the changes in the project requirements.
Shortfalls in externally-furnished Components: There are several external components which could be source for the risk on software project. For example, the customer-furnished components which could not comply with the project requirements represent a risk on that project. Hence, the project team has to do compatibility analysis to stay away from this risk.
Real-time performance shortfalls: some software programming must process information and produce a response in a fixed time. However, some software developers neglect the fact that their project need to real-time performance requirement; as a result of this negligence, they will put their project in risk. Therefore, the project team has to prototype their project and test their project to avoid this risk.
Straining computer science capabilities: Establishing unfamiliar technology or unstable in the project with put the project in risk because of that the team members will need a lot of work and time to understand the mechanism of this technology. Indeed, this technology could cost more money for that project. Therefore, the team project has to do both technical analysis and cost-benefit analysis to avoid this risk.
In conclusion, this essay discussed the Boehm’s ten risk item and the possible techniques which could help to manage the risk of these items.
