[Kuml-cvs] CVS: kuml/docs/old_ftp/people/keith/docs riskAnalysis.txt,NONE,1.1

[Gerard F. <ger...@us...>]

Update of /cvsroot/kuml/kuml/docs/old_ftp/people/keith/docs
In directory usw-pr-cvs1:/tmp/cvs-serv24442/people/keith/docs

Added Files:
	riskAnalysis.txt 
Log Message:
Checkin of files from project FTP site.




--- NEW FILE ---
		Project risk analysis draft
		---------------------------

	Why bother?
	----------
To find out the risks associated with the project. And to take steps to limit those that
are under our control. It is not intended that this be distracting. But in the long term 
I believe that having measures to control risks will be needed.


	What is risk?
	------------
Risk is the possiblity of a negative/undesirable outcome. The higher the possibility of
that negative outcome and the more dramatic the impact on the project, the higher the risk.


	How are risks identified?
	-------------------------

By looking at the 
	.development team
	.project complexity
	.development time 
	.user requirement and their stability


	What are my percieved risks?
	----------------------------

Development team
----------------
	risk : working this for fun - may not contiue to be the case

	problem
		.team member leave project
		.team members put in lower than expected(agreed) hours 
	impact
		.project is delayed 

	risk level
		.low to medium - we wouldn't be here unless we were commmited 

	risk control
		.double up - two member work on an area at once 
				(this may not be practical but is desireable)

Technical risks
---------------
	risk: leading edge software

	problems  
		.unfamiliar with development tools and software technologies
		.uncertain that requirement can be achieved

	Impact
		.incomplete/missing/reworked requirements - project not complete or delayed

	risk level
		.xml and support libraries: High risk
		.application graphic interface : medium

	risk control
		.choose a software development lifecycle to reduce risk. 
		.allow time for frequent check of progress.
		.modulize project - already being done

Requirements
------------
	risk: requirements not fixed

	problem
		.requirements change frequently
		.disagreement about requirements
		.poor change control

	impact 
		.rework requirments - project delayed 
				     - in the extreeme case project not completable or
					the project is abandoned
	risk level
		.xml and support libraries: medium
		.application graphic interface : medium		
 
	risk control
		.agree on requirments by consensus - already being done



	Recommendation 
	-------------
1) Someone else have a look at risks at project to clarify/confirm/rebut analysis. 
2) Consider how risks may be controled.
3) Consider the high risk support libraries be spun off into a separate open enviroment
	project and that kUML team works very closely with it.