3rd weekly Report

Here we are with our 3rd weekly report, which includes the Risk analysis and a complete view of Time cards. The complete risk analysis has been done keeping in mind the efforts and hard work put in by all the members of our group. It should also be taken into consideration that different members were assigned different works and thus a type of parallel processing was achieved in the group. Although, it was new experiment in our group but we have found this experiment to be a very contributive activity and a success. In fact it will be very good idea if in future also we should proceed with this parallel processing system.

INITIAL RISK ANALYSIS FOR THE PROJECT.

HOTEL INVENTORY SYSTEM.

Here we have tried to understand some of the factors that may cause harm to our project and we may end up loosing precious time and resources in the end. But if we are prepared then the chances of damage control are very high, which will minimize the looses…

We shall first of all try to find out :

a) What are the risks,

b) What are the methods to avoid them,

c) Risk detection/identification and in the end

d) Risk handling.

1) Business impact risks :

a) Reasonableness of the delivery deadline ?

Although this risk is a very genuine risk, it is beyond our control, as the deadlines have been decided by the university , and therefor can not be monitored at our end . And as such this is one risk that can not be avoided. The only way to handle this is to meet the dead line.

b) Dependency on other systems that our project must interact to successfully deliver the result.

As this is a small project, which monitors only the stores department,

our project has to interact with various other systems to perform well,

therefor we have to ensure that our project has compatibility with all

the systems in the hotel. This risk can be identified during the dry run in

real life situation. In case there is any discrepancy then we can

immediately identify the problem and modify the project accordingly.

c) As our project result depends a lot on the end user we have to take

their Level of sophistication into account.

Our system depends heavily on the sophistication level of our end user.

This can be immediately identified during the practice run and can be

rectified by providing suitable training to the end users . this training can

be imparted by either the in house training system or by the software

making company.

2) Customer related risks :

a) Is my customer clear about his ideas and requirements?

As we are ourselves the customers, it is very important that we should be very clear about our ideas and requirements, otherwise our user stories may be wrong and this will jeopardize the entire project, to avoid this we can at times look for a real life customer and take his view’s.

b) Does the stories given by him, are free of any ambiguity?

Are we sure that all the stories provided to us by the customer are accurate and without any ambiguity? To avoid this risk, we should try to verify the stories again and again from the customer.

c) Is there any contradiction in the stories ?

This again will create problems in coding, as any contradiction will create only confusion. This can be cross-checked from the user as well as by going through all the stories to see that no two story is similar or overlaps each other.

d) Has the customer written down all his requirements?

It is very imperative that the customer clearly writes down all the stories, as this will help in dispelling all the ambiguity and any uncertainty

3) Size of the group :

a) Is the group size an optimum size for doing the project?

Are we sufficient in number to handle this project? Or the number of members is more then required? Although it is difficult to identify this risk, but we must know if the group size is optimum for the project or not. In case of too many members we stand to loose important man-hours, and in case of under participation we again use too many man-hours, which is not required.

b) Are all the people of the group well aware of the XP process?

XP is a very innovative method of writing a programme ,and therefor it is imperative that all the members should be well aware of the process

c) Do we all have some programming background to know exactly what’s going on?

This group is a heterogeneous mix of members who have different background, in case that any of us is not aware with the language used for the programming of the system, which in turn will hamper the group harmony.

d) Are we all using our various skills to the maximum utility?

This is the most unique risk according to me. If any member is not getting the chance to make full use of his capabilities then he will feel dissatisfied with his work and therefore wont be able to put in his best efforts .

4) Process definition :

a) Are we all aware of the path we have to take?

This is a very major risk as we all must be very sure of the procedure or the path that is being followed to develop the system. If any member is not aware of this then there are high chances that he will commit errors in his assignment.

b) Are we documenting all our efforts?

A very major task of the entire process is to document each and every work methodically or else it will be a tremendous effort latter on to track any particular segment of the work done by the team.

c) Are the test codes being followed and being documented , do we have

something planned for any contingency?

The most important part of the XP process is to have the test code for

each Iteration, or rather for each piece of the code generated, this helps

the developer in knowing his problems and helps a lot in debugging.

In our 3^rd weekly report we have come up with the new concept of Track of Time Cards that we were maintaining right from the beginning if the 1^st iteration. This Time card concept is just the brief sketch of what we have achieved yet. This Time Card concept also provides the tasks performed by our team members. The Time Card is a short preview that summarizes the efforts put in the project by team members. We have followed XP programming rules this is clearly stated by the % of pair programming which has come out to be 81% which is good enough to indicate that we are following the XP strictly. This is what is needed for the Software Engineering Project to reach to its peak. In the Time Card Track overview it is very clear that every member of the team is not kept restricted to particular task but is handling all the tasks need for the project to be succeeded. This is what XP teaches that every member of team should be competent enough to handle any task that is being performed in the group. Each member of team has been assigned the list of tasks he/she has to perform in the cyclic manner so that in full complete iteration he/she must come in contact to all the activities happening in the group so to familiarize what is all happening during the iteration.

Our weekly report is going to give a brief idea of what we are going do in our next forthcoming iteration. This is what XP says that for the next iteration to move smoothly and a systematic fashion we have to plan what we have to deal in next iteration. Ours is XP project so moving according to regulations. Our weekly report also highlights the new improved idea about how to increase the scope of our project. Although they may seem to be minor achievements but they are a big step towards the achievement of our goal i.e. the successful completion of Software Engineering Project.

So here are we with our next iteration planning: