Risks

     There are many potential risks involved in proposing, designing, and implementing a software project.  There is the risk that something will not get done in time.  This risk has a low probability because the team has well defined deadlines and members of the team communicate with each other frequently.  Therefore if there is a problem the team will know about it and help.  The impact of this risk depends on the assignment.  If the assignment is a major deliverable it will have great impact, if it is a small sub-assignment impact will not be so great.  The risk is of highest concern to the team.  There are many deliverables that will be due through the development process.  Getting behind in the work will lead to failure in the end so if we keep focused on getting the assignments done on time the project will work out fine.

     Another potential risk is that the software solution will not meet all of the requirements.  The probability of this risk happening is a little higher than the risk above.  The client does not want all of the functionality of the traffic controllers right away.  We can first get key functionality done and then add other functionality later.  If there is a problem with communication we might leave out functionality that client thinks is essential.  If the problem is not recognized early on the impact of it will be great because there might not be enough time to get the functionality in to the project.  This concern involved with this risk is second highest.  The way the team plans to avoid this risk by keeping the client informed in out progress.  The client will see the requirements we plan to put in the project and if something is missing the client will let us know.

     The client wanting functionality that is not feasible to complete is a potential risk.  The probability of this risk happening is low because the team has already looked at the requirements and nothing appears to be unfeasible.  The impact this risk will have on the project varies depending on how necessary to the system the unfeasible functionality is.  If it is an important requirement it will have a great impact.  This risk is of least concern because the team does not believe that any requirement will be unfeasible.  There will be a whole deliverable dedicated to feasibility study and this will allow us to realized and manage any unfeasible requirements.

     We have to understand how the traffic controllers work in order to simulate them through software and there is a risk that we will not understand the logic behind them.  We believe the probability of this risk coming to pass is low.  We have access to the traffic lab and as long as we experiment with the traffic controllers we should be able to understand how their logic works.  The impact of this risk is low because even if we do not know exactly how the logic works we can just make the functionality work the same.  This risk is the third lowest in concern because we just do not think it will happen.  We will avoid this risk by just working with the machine and asking our client about their functionality if there is something we do not understand.