Feasibility Study and Project Plan



School of Computing and Information Sciences - FIUFall10Feasibility Study and Project Plan08FallQuota SystemGroup 7Eduardo PenaVanessa RamirezEduardo TibauCIS 4911 Senior Project Coordinator: Prof. Peter J. ClarkeMentor: Dr. Masoud SadjadiSeptember 14, 2010AbstractAs technology advances, new IT courses and learning methodologies arise. In Spring 2009 the IT Automation course was introduced to FIU. Sponsored by Kaseya and lectured by Dr. Masoud Sadjadi, the purpose of this course is to get students familiar with IT automation. To achieve this goal, students have access to certain online resources. These online resources are of limited capacity making it necessary to use an appointment system for their use. At the beginning the appointments were taken care by hand, this turned out to be time consuming and a hard task to maintain. Later on a scheduling system was developed to allow students to make these reservations online through Moodle. This scheduling system provides a better user experience, but it is difficult to control a fair distribution of these resources among users. With this problem in hand, our goal is to develop a system that will interact with the current scheduler, and allow the administrator to define usage policies. In this document we have analyzed the current system, and defined the user requirements at a high level. Also, we propose three alternative solutions to the problem, along with a feasibility study of these solutions. Finally, a project plan is presented including tasks, milestones, and deliverables.Table of Contents TOC \o "1-3" \h \z \u 1.Introduction PAGEREF _Toc145842044 \h 41.1.Problem definition PAGEREF _Toc145842045 \h 41.2.Background PAGEREF _Toc145842046 \h 41.3.Definitions, Acronyms, and Abbreviations PAGEREF _Toc145842047 \h 51.4.Overview of document PAGEREF _Toc145842048 \h 62.Feasibility Study PAGEREF _Toc145842049 \h 72.1.Description of Current System PAGEREF _Toc145842050 \h 72.2.Purpose of New System PAGEREF _Toc145842051 \h 72.3.High-level Definition of User Requirements PAGEREF _Toc145842052 \h 82.4.Alternative Solutions PAGEREF _Toc145842053 \h 82.4.1.Description of Alternatives PAGEREF _Toc145842054 \h 82.4.2.Selection Criteria PAGEREF _Toc145842055 \h 102.4.3.Analysis of Alternatives PAGEREF _Toc145842056 \h 112.5.Recommendations PAGEREF _Toc145842057 \h 123.Project Plan PAGEREF _Toc145842058 \h 143.1.Project Organization PAGEREF _Toc145842059 \h 143.1.1.Project Personnel Organization PAGEREF _Toc145842060 \h 143.1.2.Hardware and Software Resources PAGEREF _Toc145842061 \h 153.2.Identification of Tasks, Milestones and Deliverables PAGEREF _Toc145842062 \h 164.Appendix PAGEREF _Toc145842063 \h 184.1.Appendix A - Project schedule PAGEREF _Toc145842064 \h 184.2.Appendix B - Diary of Meetings PAGEREF _Toc145842065 \h 204.3.Appendix C – Feasibility Matrix PAGEREF _Toc145842066 \h 224.4.Appendix D – Cost Matrix PAGEREF _Toc145842067 \h 245.References PAGEREF _Toc145842068 \h 26IntroductionThis chapter provides an introduction to the document. First, on section 1.1 a clear definition of the problem is presented. Then, on section 1.2 an overview of the background information to allow the reader to understand more about the problem. Finally, section 1.3 defines certain words to be used in the document, and section 1.4 provides an overview of the different chapters of the document.Problem definitionIn the IT Automation class at?FIU, students are expected to develop scripts and procedures in a lab setting. A limited number of resources are available for this course, which primarily include mentors and virtual labs. The latter refers to different virtual environment configurations designed for students to solve a particular IT problem. At the moment, a system is being developed to allow students to schedule these resources. However, the system does not provide an efficient way to manage these resources so that all the students have a fair share.The scheduling system gives students the freedom to reserve resources for the labs at the time that better fits with their schedule as long as they are available. However, this freedom results in misuse of resources as seen in previous prototypes. For instance, some students do not use the system on a regular basis and wait until deadlines to complete the required hours for the course. An excessive demand of requests puts a lot of pressure on the system, which cannot provide enough resources. Another case is when students schedule resources along the semester but do not use them all. The waste of resources is also an issue that needs to be addressed since it is an unfair practice that affects other students.Background The IT Automation course was first offered in Spring 2009 at?FIU CITATION Mas10 \l 1033 (Sadjadi). Sponsored by Kaseya and lectured by Dr. Masoud Sadjadi, this course has the objective of preparing students in the IT management and automation field. Students are expected to learn the necessary skills to master different IT automation tools in a lab setting.?Dr. Sadjadi has been working with?graduate and undergraduate students to develop a system that would facilitate the management of resources for the IT Automation course. The prototypes that have been developed so far are based on Web Services. Moreover, a familiar interface is provided through Moodle CITATION Moo \l 1033 (Moodle Community), which is commonly used by IT students at FIU. The first prototype allowed students to schedule virtual labs only. The last prototype allowed students to schedule the different resources available for the course. It also gives the administrator the capability to configure settings through the same interface. The prototype is still in development but the expected release is on Spring 2011. Definitions, Acronyms, and AbbreviationsIT: Information Technology.Kaseya: Company that offers IT Systems Management Software and Network Management Software for IT Departments and Managed Service Providers.Resources: In this particular context, this term refers only to virtual labs, mentoring, and certificate exams.Virtual Lab: Different virtual environment configurations designed for students to solve a particular IT problem.Mentoring: Time used by teacher assistants to help students.Certificate Exams: Virtual environments specifically for graded exam sessions.CMS: Course Management System also known as a Learning Management System (LMS) or a Virtual Learning Environment (VLE).Moodle CITATION Moo \l 1033 (Moodle Community): An open source CMS that educators can use to create effective online learning sites.JavaScript: A scripting programming language most commonly used to add interactive features to web pages.phpScheduleIt CITATION Nic10 \l 1033 (Korbel): A web application written in PHP developed by Nick Korbel for resource reservation and management.PHP: (Hypertext Preprocessor) is a popular general-purpose server side scripting language that can be embedded into HTML to create web applications.Web Service: A standardized way of integrating web-based applications that share business logic, data, and processes through a programmatic interface across a network.FullCalendar CITATION Ada10 \l 1033 (Shaw, 2010): A jQuery plugin developed by Adam Shaw, which provides a full-sized, drag & drop calendar that uses AJAX to fetch events on-the-fly for each month and is easily configured to use your own feed format.jQuery: JavaScript Library that simplifies HTML document traversing, event handling, animating, and Ajax interactions for rapid web development.Quota: Limited time the students will have in the new system to allocate resources. Overview of documentChapter one provides an introduction to this document and begins with a detailed definition of the problem. After this, background information on the problem previously described is provided. Finally, a list of definitions, acronyms, and abbreviations used across the document is given followed by an overview of each chapter's contents.Chapter two contains the feasibility study conducted to determine whether a feasible solution exists for the given problem. This chapter begins with a complete description of the current system and its deficiencies. Next, the purpose for the new system is explained in detail, followed by a list of the requirements given by the user as part of the possible solution. After this, a list of alternative solutions is provided along with a brief description for each of these solutions. Then, the criteria used to evaluate the possible solutions are explained followed by the summary of the analysis of each solution according to the mentioned criteria. To conclude this chapter, a recommendation is given explaining why one of these solutions is more feasible than the others.Chapter three explains how the team plans to develop the chosen solution. It explains how personnel are organized and what role will each team member play during the development process. After this, a list of the resources needed to develop the solution is provided. Finally a detailed table of tasks, milestones and deliverables shows exactly what each team member will be doing on each phase.Finally, chapter four contains the appendices that were used to create this document. These appendices include a project schedule, the diary of meetings, and the feasibility matrix.Feasibility StudyThe following chapter will analyze the different possible solutions to the problem in question. First, section 2.1 describes the current scheduling system along with its limitations and constraints. Then, section 2.2 provides an overview of the new system and its main goals. Next, section 2.3 defines the user requirements at a high level. Finally, section 2.4 will talk about three possible solutions to the problem, followed by recommendations on section 2.5.Description of Current System Dr. Sadjadi and his research team developed the current scheduling system. This scheduling system provides an interface through Moodle that allows students to reserve different types of resources. The resources available at the moment include virtual labs, mentoring and certificate exams.The main interface of the scheduler is a JavaScript calendar, based on FullCalendar jQuery plugin CITATION Ada10 \l 1033 (Shaw, 2010), with all the desired scheduling functionality added to it. Students can select for which resource they want to reserve time and schedule it on the calendar. The calendar will show the users not only their appointments but also the availability of resources to make the scheduling process easier.At the moment the system doesn’t have any type of policy towards the use of resources. Students can reserve an unlimited amount of resources, leaving other students without available time slots. This is an unfair distribution of resources that inevitably leads to wasted resource usage time. Furthermore, administrators don’t have access to any kind of report about usage. Since this is the case, there is no way to prevent or penalize students with unused allocated resources.Purpose of New SystemThe purpose of the new system is to allow a fairer distribution of resources between students. Also, the new system should give the administrator more control over the resources and their use. The way to control these resources will be through different reports and usage policies. Ultimately, the administrator will make sure that the students are using the resources in a fair and efficient manner.Consequently, since it will be easier to find available resources, students will have a better experience throughout the course. They will waste less time trying to allocate the resources they need, and will optimally have more resources available for their use. High-level Definition of User RequirementsThe high-level user requirements are the following:The system shall allow the administrator to define policies about usage time, availability, cost, and other fixed factors about each resource in a user-friendly manner.The system shall provide a way to modify these policies without affecting previously reserved time slots.The system shall allow students to allocate and release resources.The system shall provide students with reports about their usage of resources.The system shall display the number of hours of a resource that the student can reserve.The system shall allow students to request additional time on a resource (outside of their normal quota) upon approval.The system shall provide an interface with the scheduling system to check the available quota, and the request’s compliance with the applicable policies.Alternative SolutionsThis section presents different alternative solutions for the problem stated above. Sub-section 2.4.1 contains a description of each solution and how it should be implemented. Next, sub-section 2.4.2 presents the selection criteria on which the analysis of each of these alternatives was based. A summary of this analysis is shown in sub-section 2.4.3.Description of AlternativesAlternative 1: PhpScheduleIt adaptationPhpScheduleIt is a web application written in PHP developed by Nick Korbel for reservations and resource management CITATION Nic10 \l 1033 (Korbel). The system includes a full user log in and registration system, user profile management, a scheduling and reservation system, and numerous administration tools. On the administrative side phpScheduleIt supports a fixed group of policies that can be defined for each resource. The system administrator can also decide what resources are available for each user. In order to use phpScheduleIt as a solution for the given problem, the system will be wrapped inside a Moodle module so it can interact with the existing system's modules. The source code will be modified to fit user requirements and discard unwanted functionality.Alternative 2: Fair scheduling algorithmModify the existing scheduling system to allow a fairer distribution of resources. The new scheduler will handle a priority-based system, where a determined number of minimum resources for each student will be considered high priority resources. Additional resources acquired by students will have lower priorities. This way every student will have a chance to use their high priority resources over the additional lower priority resources of other students. Additionally there will be scheduling periods where students will choose when to use their resources before the schedule is locked. During this period other student’s high priority resources may replace some student’s lower priority resources. The students whose resources were removed will have a chance to reschedule their lower priority resources before the scheduling period ends. Once the scheduling period is over students may only choose open time slots to spend their resources until the next scheduling period begins.Alternative 3: Quota SystemA new custom-made module that will interact with existing modules of the current system. This module will work with quota or credit types instead of handling resources directly. Each type of resource will have a value in a given type of credit. As it most important feature, the new module will allow the creation of user designed policies to determine whether resources should be assigned to a student. These policies can be applied to students individually or as a group. Additionally, system administrators will be able to give students access to additional resources should the student need them.Selection Criteria This sub-section describes the criteria used to evaluate each of the solutions proposed in the previous sub-section. The following types of feasibility were considered for this analysis: operational, technical, schedule, economic.Operational FeasibilityPerformanceIs the solution’s throughput and response time adequate?InformationDo end users and administrators get timely, pertinent, accurate and usefully formatted information?ControlAre there effective controls to protect against fraud and to guarantee information accuracy and security?ServicesAre current services reliable? Are they flexible and expandable?User FriendlinessIs the solution easy to use?Requirement ComplianceDoes the solution satisfy all user requirements?Technical FeasibilityExpertiseDoes the team possess the expertise required to develop the solution?TechnologyDoes the team possess the tools required to develop the solution?Schedule FeasibilityPreparationHow long does it take the team to learn the base system's technology?Design and ImplementationHow long does it take to design and implement the solution?Economic FeasibilityMaintenanceHow much does it cost to maintain the system after development is complete?Analysis of AlternativesThis sub-section contains a summary of the pros and cons involved with implementing each of the proposed solutions based on the feasibility matrix. (Appendix C) The score associated with each alternative is based on the sum of the score given to the alternative for each individual criterion. This score given corresponds to a one to ten grading scale.Table SEQ Table \* ARABIC 1 phpScheduleIt adaptation score summaryAlternative 1: phpScheduleIt adaptationScoreProsCons5.57- Working system with useful functionality.- Useful statistical information displayed.- Fixed policies- Hard to scale and maintain.- Hard to modify.- Must understand complex code.arTable SEQ Table \* ARABIC 2 Fair scheduling algorithm score summaryAlternative 2: Fair scheduling algorithmScoreProsCons7.49- System designed to solve problem.- Moodle based application.- Fixed policies.- Not very scalable- Must learn about current system.Table SEQ Table \* ARABIC 3 Quota system web service score summaryAlternative 3: Quota systemScoreProsCons8.65- System designed to solve problem.- Flexible policies.Flexibility in scheduling.- Moodle based application.- Very scalable.- More than one web service required.- Minor changes in existing module.Not optimal utilization of resources.RecommendationsThe primary goal of the new system is to ensure fair distribution of existing resources among students. Even though all proposed solutions achieve this primary goal, some are more flexible in specific aspects than others.The quota system web service solution provides the user with the most flexibility regarding policy implementation for resource management compared to the other two alternatives, which only allow the user to change parameters from a fixed set of policies. The quota system also adapts to the current system without having to modify any of the existing code, while in order to implement the other solutions existing code must be understood and altered. Keeping the current system unchanged translates into students not having to learn how to use a brand new system; instead, students will face the same familiar user interface with minor additions.The team recommends the implementation of the new quota system web service, since it satisfies all user requirements with a simple, scalable module, while maintaining a familiar user interface, and providing the most flexible resource control solution.Project PlanThis chapter describes the work plan for this project, hardware and software resources, tasks and milestones for each deliverable. Section 3.1 described the project organization. In section 3.1.1 the team roles are defined for each member and deliverable. Section 3.1.2 describes the software and hardware resources available to the team to develop this project. In section 3.2 a breakdown of the project is detailed with every task and milestone for each deliverable. Project OrganizationThis section will describe the roles and responsibilities of team members, and the resources available for this project.Project Personnel OrganizationIn this section the team roles are shown for each deliverable of the project. Table SEQ Table \* ARABIC 4 DeliverablesIDDeliverableFS-PPFeasibility Study and Project PlanRDRequirements Document DDDesign Document FDFinal DeliverableTable SEQ Table \* ARABIC 5 Team RolesTeam MemberFS-PPRDDDFDEduardo Pena?Requirement Analyst?Technical Writer?Requirement Analyst?Technical Writer?Minute Taker?System Analyst Designer?Technical Writer?Developer?Technical Writer?Minute TakerVanessa Ramirez?Project Manager?Technical Writer?Project Manager?Requirement Analyst?Project Manager?System Analyst Designer?Project Manager?Lead Tester?DeveloperEduardo TibauRequirement AnalystMinute TakerRequirement AnalystDevelopment Team ManagerDevelopment Team ManagerMinute TakerHardware and Software Resources This section describes the hardware and software minimum requirements for development.Personal computers: Hardware SpecificationThree portable computers with the following minimum specifications:RAM Memory: 2GBHard disk space: 100GBProcessor: Intel Core 2 DuoNetwork: 10/100 Mb/sSoftware SpecificationAny operating systemEclipse IDEMS Office SuiteAXIS2ApachePHP 5Java Development Kit (JDK) 1.6MySQLPostgreSQLServer:Hardware SpecificationRAM Memory: 1GBHard disk space: 40GBProcessor: Intel Core 2 DuoNetwork: 10/100 Mb/sSoftware SpecificationAny operating systemAXIS2ApachePHP 5Java Development Kit (JDK) 1.6PostgreSQLIdentification of Tasks, Milestones and DeliverablesThis section describes in detail the work plan for the project including the tasks and milestones that compose the deliverables shown in table 1. A Gantt chart was built as well to show the project schedule (Appendix A).Table SEQ Table \* ARABIC 6 MilestonesIDMilestonesDeliverableM1Problem statement and descriptionFS-PPM2Feasibility study and Project PlanFS-PPM3Final documentFS-PPM4Scope of the system, Current System problems and limitations and Project planRDM5Proposed system requirementsRDM6Final DocumentRDM7System methodology and design.DDM8Detailed designDDM9Final documentDDM10Final version of FS-PP, RD and DDFDM11Implementation of web serviceFDM12Implementation of interfaceFDM13System ValidationFDM14Final document and productFDTable SEQ Table \* ARABIC 7 TasksIDTaskMilestoneT1Problem statement M1T2BackgroundM1T3Feasibility studyM2T4Project planM2T5Terminology and overviewM3T6Integration and revision of final document M3T7Scope of the systemM4T8Current System problems and limitationsM4T9Project planM4T10Functional requirementsM5T11Analysis of system requirementsM5T12Terminology and overviewM6T13Integration and revision of final documentM6T14Design methodologyM7T15System designM7T16Static and Dynamic modelM8T17Code SpecificationM8T18Terminology and overviewM9T19Integration and revision of final documentM9T20Final version of FS-PP documentM10T21Final version of RD documentM10T22Final version of DD documentM10T23Credit Manager web serviceM11T24Policy Manager web serviceM11T25Credit Manager Moodle moduleM12T26Policy Manager Moodle moduleM12T27Policy Manager integration test M13T28Credit Manager integration testM13T29System integration testM13T30User guideM14T31Integration and revision of final documentM14Figure SEQ Figure \* ARABIC 1 Project schedule400050742950Appendix Appendix A - Project schedule Appendix B - Diary of Meetings Date08/24/2010Time16:30 – 17:30LocationDr. Sadjadi’s officeAttendeesAll members and Dr. SadjadiAbsenteesDiscussionBrief introduction of Eduardo P. and Eduardo T. to Dr. Sadjadi.Description of the current issues with the scheduler, and what we need to do to improve it.Talked about taking the project from a software engineering path.DecisionHave a meeting to further discuss the problem statement on 8/26/2010.Vanessa has to make a draft of the problem statement since she is the one with more knowledge of the current system and its problems.Open issuesNoneDate08/25/2010Time20:00 – 21:00LocationEduardo’s houseAttendeesAll membersAbsenteesDiscussionPrepared the problem statement for 8/26 meeting, uploaded it to basecampDecisionNoneOpen issuesNoneDate08/26/2010Time17:00 – 18:00LocationDr. Sadjadi’s officeAttendeesAll members and Dr. SadjadiAbsenteesDiscussionContinued the talk about the project, specifically about high-level user requirement.Presented the problem statement to Dr. Sadjadi.Agreed to work 10 hours per week. On-campus meetings with Dr. Sadjadi Tuesdays 17:00-18:00, and Wednesdays 14:30-17:00DecisionDivide the first deliverable, and start working on it.Vanessa needs to work on defining the milestones for the project.Everyone needs to start looking for possible solutions to the problem.Open issuesNoneDate08/31/2010Time14:00 – 17:00LocationECS 212AttendeesAll membersAbsenteesDiscussionSearching for alternative solutions. Found phpScheduleItComing up with two solutions to the problem. Option one, priority reservation system, needs to modify the existing modules in order to integrate it. Option two, quota web service system that handles credits and talks to the shopping cart, scheduler and its own administrative interface with reports.DecisionOpen issuesTry to explain our own solutions to Dr. Sadjadi to get some feedback from him. Date08/31/2010Time17:00 – 17:45LocationDr. Sadjadi’s officeAttendeesAll members and Dr. SadjadiAbsenteesDiscussionFurther talk about the problem.Revision of the problem statement. It turned out to be fine.Presentation date.DecisionKeep looking for alternatives. Select from the pool of other alternatives one which we think is the best.Choose a presentation date on next class and notify Dr. Sadjadi about it.Open issuesTry to explain our own solutions to Dr. Sadjadi to get some feedback from him.Date09/6/2010Time15:00 – 22:30LocationEduardo’s houseAttendeesAll membersAbsenteesDiscussionEach member worked on the respective part of deliverable 1.Decided to make phpScheduleIt one of the alternative solutions along with our two options.DecisionIntegrate the various parts of the document into one single file to present it.Make the presentation for deliverable 1Overview of document and terminology by Eduardo P. Due 9/10Ask about cost matrix, if there won’t be any costs associated with any of the 3 alternativesOpen issuesTry to explain our own solutions to Dr. Sadjadi to get some feedback from him.Appendix C – Feasibility MatrixTable SEQ Table \* ARABIC 8 Feasibility MatrixFeasibility TypeType Wt.CriteriaCriteria Wt.Alternative 1Alternative 2Alternative 3ObservationsScoreObservationsScoreObservationsScoreOperational50%Performance10%No web service calls involved.System has one database.10System contained within the same web service.System has one database.9System must call other web services.More than one database.7Information10%Users and Administrators are informed about resource use.Graphs and other visual aids to view information.10GUI designed specifically for this purpose.10GUI designed specifically for this purpose.10Control10%System manages its own database.9Information contained within existing system.One web service.10Information contained within existing system.More than one web service.8Services10%System is fully developed.Hard to scale.2Complex large system.Hard to scale.6Simple separated modules.Very scalable.10User Friendliness20%Too many options.Overkill of user rmation saturated views.7GUI designed to present relevant data only.Easy access to all required functionalities.10GUI designed to present relevant data only.Easy access to all required functionalities.10Requirement Compliance40%Fixed, limited policies.6Fixed, limited policies.6Flexible policy system.Custom made to meet user requirements.10Type Score6.97.99.5Technical20%Expertise70%No knowledge about PEAR databases.6Medium knowledge of Moodle based web applications.8Medium knowledge of Moodle based web applications.8Technology30%No PEAR database manager.8All required tools installed.10All required tools installed.10Type Score6.68.68.6Schedule20%Preparation40%Complete implemented system unknown.2Current scheduling system code unknown.Time required to learn Moodle development.5Time required to learn Moodle development.8Design and Development60%Complete implemented system unknown.2Rework current plex algorithm design.6Start design from the beginning.7Type Score25.67.4Economic10%Maintenance100%Person in charge must know in extent system code.4Person in charge must know Moodle.7Person in charge must know Moodle.7Type Score477Total Score5.577.498.65Appendix D – Cost MatrixTable SEQ Table \* ARABIC 9 Personnel CostsAlternativesProject Duration Weeks (10 h/w)PersonnelTotal HoursTotal Cost ($15 per hour)phpScheduleIt203200$9000Fair Scheduling Algorithm253250$11250Quota System153150$6750Table SEQ Table \* ARABIC 10 Risks CostsRisk ItemProbabilityphpScheduleItFair Scheduling AlgorithmQuota SystemRecovery CostRisk ValueRecovery CostRisk ValueRecovery CostRisk ValueRisk 1: Personnel could work fewer hours than estimated due to sickness or personal issues.0.3$450$135$612.5$183.75$350$105Risk 2: Requirements could change drastically which could change the system design.0.2$4500$900$6250$1250$3200$640Risk 3: Time estimations for deliverables could not match the time necessary to complete the project.0.25$5500$1350$7000$1750$4000$1000Total$2385$3183.75$1745Table SEQ Table \* ARABIC 11 Software and Hardware Costs (All alternative have the same costs)ItemCostComputers$6,490 Developer Tools (Open Source)$0 Project Management Tools (Microsoft Office 2007, MS Project)$1,100 Total$7,590 Table SEQ Table \* ARABIC 12 Project CostsAlternativesPersonnel CostsHardware and SoftwareRisk MitigationTotalphpScheduleIt$9000$7,590$2385$18.975Fair Scheduling Algorithm$11250$7,590$3183.75$22023.75Quota System$6750$7,590$1745$15780References BIBLIOGRAPHY Korbel, N. (n.d.). Introduction to phpScheduleIt. Retrieved 08 28, 2010, from phpScheduleIt: Community. (n.d.). About. Retrieved 08 28, 2010, from Moodle: , M. (n.d.). it Automation Home Page. Retrieved 08 24, 2010, from S. Masoud Sadjadi's Home Page: , A. (2010). FullCalendar. Retrieved from ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download