Current Version: Elaboration Iteration 1, Completed 11/14/2002
Inception, Completed 9/5/2002
Risk List
This is the risk list for the StickSync project. General a risk list includes the columns in the table below plus two additional columns. For this project we chose to eliminate the Monitor and Responsibility columns, since it is clear that Gary and Curt must monitor all the risks and are responsible for seeing that the risks are discharged.
| Description | Priority | Impact | Contingency |
|---|---|---|---|
| Synchronizing between computers when one has a case-sensitive file system and the others is case-insensitive may result in loss of data. | High | inability to sync, loss of confidence in system, loss of data | System prevents adding files to synchronization set if an existing file in the same location has the same name when ignoring case. |
| Although command-line tools exist for merging two sets of changes to a single file (e.g., GNU merge), it is not clear how to perform such merging from a Java program. | High | Since the algorithms for merging exist in open source software, it is clear that we could implement them. The impact is therefore on the project schedule. | System stores both versions of the file on a single computer so that User can use command-line tools for merging them. |
| What does it mean for two files to be identical? | Medium | User's might want system to translate line endings between platforms, which might entail rewriting our file comparison and transfer logic. | Provide this as an option??? Or retain the capability for plugging in comparison and transfer rules as a sustainability requirement? |
| A file name may be so long on one computer, that the operating system on another computer does not support it. Thus one would not be able to use the same file name on the other computer. | Low | This case seems unlikely to occur in practice, as the limits on file name length are fairly long. | Store the file with the truncated file name, which will look like a new file. |
| Users will want to transport files that are much larger than the PMSD can handle, even with compression. | Low | Users will want slicing of files. | Suggest that users use WinZip or some other tool that slices files for them in the interim, or ignore this. |
| Users will want to synchronize several computers, not pairs of computers. | Medium | This impacts fundamental assumptions about the software model. | Deal with this in early iterations by getting user feedback? |
| Different OSs may set the timestamps for directories differently. | Medium | Our timestamp based model for detecting the order of changes may not be able to differentiate the order of directory creation or deletion. | Always merge added directories. Require additional User interaction when propagating directory deletions. |
Last modified Tuesday, September 16, 2003.
This web page is for the StickSync project, developed as an example for Com S 362 at Iowa State University. Please direct any comments or questions about this project to Gary T. Leavens at leavens@cs-DOT-iastate-DOT-edu or Curtis Clifton at cclifton@cs-DOT-iastate-DOT-edu (after replacing -DOT- with `.').