Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2007/wiki2 4 2q

2019-08-23T03:08:37Z

Mkhan8: removed video link

'''A Guide to Use Cases on the WEB'''

''Topic :Use cases. There are even more pages on the Web on use cases than on [https://www.codecademy.com/articles/mvc MVC]. If someone wants to learn about them, what should (s)he do? Look at the first few hits in Google? I expect we can do better than that. Write a review of the use-case sites on the Web. Which are best for learning about the concept? Which have the most instructive examples? Which teach advanced concepts that are not apparent in perusing most use-case sites? Read at least several dozen pages before deciding how to organize your overview.''

=Introduction=

This page tries to review the use-case sites on the Web which can be useful to best understand the concept. Also a few instructive examples are covered paying attention to the basic use case as well as advanced concepts that are not apparent in perusing most use-case sites.

=What is a Use Case?=

==Definition==
<blockquote> "'''''Use case''' is a methodology used in software and systems engineering to understand and identify the functional requirements of a system. Use cases describe the interaction between a primary actor, the initiator of the interaction and the system itself, represented as a sequence of simple steps.''"[1][2]</blockquote>

An actor who can more generally be described as the user of the system, is the external entity and can be a person or another system itself. A use case can be best described as what happens when the actor is using the system to achieve some goal. This goal is nothing but the end result which follows the sequence of events as described in the use cases.

Every use case gives a complete list of events which occur from the time the actor starts interacting with the system till the time the final goal is achieved. A use case also records all the possible scenarios that may occur while trying to reach the desired goal. We can think of it as existence of a main course of events that will occur in normal circumstances, to which the exceptional cases are added. Anything that is not relevant to the actor/user is not a part of the use case.

Listed below are a few links to external websites which further illustrate this concept.

* [https://www.ibm.com/developerworks/library/ws-using-oo/ OO design process: Use cases, an introduction]
* [http://www.cs.uno.edu/~jaime/Courses/4210/useCaseFundamentals.html Use Case Fundamentals]

==UML Diagrams and Use cases==
<blockquote> "''The Use case diagram is used to identify the primary elements and processes that form the system. The primary elements are termed as 'actors' and the processes are called "use cases." The Use case diagram shows which actors interact with each use case."''[3]</blockquote>

They are useful in providing a pictorial view of the interactions between the users (actors) and sets of events (use cases) associated with the system.They also evolve as the projects or system change with time. The standard elements of a use case diagram makes comprehension easy for anyone trying to understand the use case.

Listed below are useful links in understanding how to draw typical use case diagrams.

* [https://www.smartdraw.com/uml-diagram/ An introduction to UML diagrams & Tutorial]
* [http://www.developer.com/design/article.php/2109801 Elements of a Use Case Diagram]
* [https://www.andrew.cmu.edu/course/90-754/umlucdfaq.html Tips and FAQ]

=Examples using Use Cases=
In this section, a few instructive examples have been outlined along with their references which illustrate different ways in which use cases can be written. The first example is a basic use-case template.

===Basic use case template===
Described below are some the characteristics of a typical use case.
'''CHARACTERISTIC INFORMATION'''
* ''Goal in Context'': Buyer issues request directly to our company, expects goods shipped and to be billed.
* ''Scope'': Company
* ''Preconditions'': We know Buyer, their address, etc.
* ''Success End Condition'': Buyer has goods, we have money for the goods.
* ''Failed End Condition'': We have not sent the goods, Buyer has not spent the money.
* ''Primary Actor'': Buyer, any agent (or computer) acting for the customer
* ''Trigger'': purchase request comes in.

'''MAIN SUCCESS SCENARIO'''
1. Buyer calls in with a purchase request.
2. Company captures buyer’s name, address, requested goods, etc.
3. Company gives buyer information on goods, prices, delivery dates, etc.
4. Buyer signs for order.
5. Company creates order, ships order to buyer.
6. Company ships invoice to buyer.
7. Buyers pays invoice.

'''EXTENSIONS'''
3a. Company is out of one of the ordered items:
3a1. Renegotiate order.
4a. Buyer pays directly with credit card:
4a1. Take payment by credit card (use case 44)
7a. Buyer returns goods:
7a. Handle returned goods (use case 105)
The basic steps that can be followed so as to ensure writing an effective use case has been described well in [https://www.wikihow.com/Write-a-Use-Case How to Write a use case].[4]

===Restaurant===
This example provides one use case but distinctly provides a step by step analysis of the events that constitute a Use Case. It mentions the actors, pre-conditions, Exceptions and Alternative scenarios.

* [http://www.uml-diagrams.org/restaurant-uml-use-case-diagram-example.html Restaurant]

===Purchase order===
This example provides a typical use case specification by listing the Activity, Result, Constraints and Extensions involved with a purchase order from a Finance web page.

* [https://creately.com/diagram/example/ifq4uulr/Purchase%20Order Purchase order System]

===ATM system===
This example is a little more involved in that it provides a number of use cases associated with using an ATM system including cash withdrawal,
transfers, deposits, balance inquiry, etc.

* [http://www.cs.fsu.edu/~baker/swe1/restricted/templates/rr631gv1_stuwrk_withdraw_cash_use-case_spec.pdf ATM System]

===A shopping website order Process===
This is a very good example that describes the scenarios and extensions involved in writing a use case for a online shopping order. It also describes the UML diagram.

* [http://www.uml-diagrams.org/examples/online-shopping-use-case-diagram-example.html?context=uc-examples Shopping website order]

===Self Service Machine===
This example provides the typical Use Cases in a self service machine. Some of the aspects of using a self service machine are: buying a product, re-stocking the machine, collecting the money etc. The following link expands on how to do this and also provides the UML diagrams which depict the interaction between the users and system through the use case

* [http://www.cloudbus.org/~raj/254/Lectures/RajUML2.pdf Self-Service Machine (page-3)]

=How to Write a Use Case?=

==Writing Effective Use Cases==

One of the most difficult problem in software development is capturing precisely what you want to build. Inaccurate requirement will end-up with significant delay, rework or even abandonment of the project. Effective applying use case technique helps your team capturing requirements in user point of view which can be easily understood by both the end-user and your team. Use case driven development support subsequent development activities such as analysis and design and testing.

Listed below are useful links in understanding how to write effective use cases.
* [https://www.visual-paradigm.com/tutorials/writingeffectiveusecase.jsp Writing Effective Use Cases]
* [https://www.wikihow.com/Write-a-Use-Case How to Write a use case]
* [http://www.utm.mx/~caff/doc/OpenUPWeb/openup/guidances/guidelines/detail_ucs_and_scenarios_6BC56BB7.html Writing Use Case]
=References=

* [1] Ivar Jacobson (1992). Object-Oriented Software Engineering. Addison Wesley Professional. ISBN 0-201-54435.
* [2] [http://en.wikipedia.org/wiki/Use_case Wikipidea Page] Basic definition of Use Case
* [3] [http://www.developer.com/design/article.php/2109801 Use Case Diagrams]
* [4] [https://www.wikihow.com/Write-a-Use-Case How to Write a use case]

=External Links=

* [http://www.cs.uno.edu/~jaime/Courses/4210/useCaseFundamentals.html Use Case Fundamentals]
* [http://www.developer.com/design/article.php/2109801 Elements of a Use Case Diagram]
* [https://www.visual-paradigm.com/tutorials/writingeffectiveusecase.jsp Writing effective Use Cases]
* [https://www.wikihow.com/Write-a-Use-Case How to Write a use case]
* [http://www.utm.mx/~caff/doc/OpenUPWeb/openup/guidances/guidelines/detail_ucs_and_scenarios_6BC56BB7.html Writing Use Case]
* [https://www.andrew.cmu.edu/course/90-754/umlucdfaq.html Tips and FAQ]
* [https://www.codecademy.com/articles/mvc MVC]

CSC/ECE 517 Fall 2007/wiki2 4 2q

2019-08-22T15:27:26Z

Mkhan8: update the links/added new external Links

'''A Guide to Use Cases on the WEB'''

''Topic :Use cases. There are even more pages on the Web on use cases than on MVC[https://www.youtube.com/watch?v=DUg2SWWK18I (model-view-controller)]. If someone wants to learn about them, what should (s)he do? Look at the first few hits in Google? I expect we can do better than that. Write a review of the use-case sites on the Web. Which are best for learning about the concept? Which have the most instructive examples? Which teach advanced concepts that are not apparent in perusing most use-case sites? Read at least several dozen pages before deciding how to organize your overview.''

=Introduction=

This page tries to review the use-case sites on the Web which can be useful to best understand the concept. Also a few instructive examples are covered paying attention to the basic use case as well as advanced concepts that are not apparent in perusing most use-case sites.

=What is a Use Case?=

==Definition==
<blockquote> "'''''Use case''' is a methodology used in software and systems engineering to understand and identify the functional requirements of a system. Use cases describe the interaction between a primary actor, the initiator of the interaction and the system itself, represented as a sequence of simple steps.''"[1][2]</blockquote>

An actor who can more generally be described as the user of the system, is the external entity and can be a person or another system itself. A use case can be best described as what happens when the actor is using the system to achieve some goal. This goal is nothing but the end result which follows the sequence of events as described in the use cases.

Every use case gives a complete list of events which occur from the time the actor starts interacting with the system till the time the final goal is achieved. A use case also records all the possible scenarios that may occur while trying to reach the desired goal. We can think of it as existence of a main course of events that will occur in normal circumstances, to which the exceptional cases are added. Anything that is not relevant to the actor/user is not a part of the use case.

Listed below are a few links to external websites which further illustrate this concept.

* [https://www.ibm.com/developerworks/library/ws-using-oo/ OO design process: Use cases, an introduction]
* [http://www.cs.uno.edu/~jaime/Courses/4210/useCaseFundamentals.html Use Case Fundamentals]

==UML Diagrams and Use cases==
<blockquote> "''The Use case diagram is used to identify the primary elements and processes that form the system. The primary elements are termed as 'actors' and the processes are called "use cases." The Use case diagram shows which actors interact with each use case."''[3]</blockquote>

They are useful in providing a pictorial view of the interactions between the users (actors) and sets of events (use cases) associated with the system.They also evolve as the projects or system change with time. The standard elements of a use case diagram makes comprehension easy for anyone trying to understand the use case.

Listed below are useful links in understanding how to draw typical use case diagrams.

* [https://www.smartdraw.com/uml-diagram/ An introduction to UML diagrams & Tutorial]
* [http://www.developer.com/design/article.php/2109801 Elements of a Use Case Diagram]
* [https://www.andrew.cmu.edu/course/90-754/umlucdfaq.html Tips and FAQ]

=Examples using Use Cases=
In this section, a few instructive examples have been outlined along with their references which illustrate different ways in which use cases can be written. The first example is a basic use-case template.

===Basic use case template===
Described below are some the characteristics of a typical use case.
'''CHARACTERISTIC INFORMATION'''
* ''Goal in Context'': Buyer issues request directly to our company, expects goods shipped and to be billed.
* ''Scope'': Company
* ''Preconditions'': We know Buyer, their address, etc.
* ''Success End Condition'': Buyer has goods, we have money for the goods.
* ''Failed End Condition'': We have not sent the goods, Buyer has not spent the money.
* ''Primary Actor'': Buyer, any agent (or computer) acting for the customer
* ''Trigger'': purchase request comes in.

'''MAIN SUCCESS SCENARIO'''
1. Buyer calls in with a purchase request.
2. Company captures buyer’s name, address, requested goods, etc.
3. Company gives buyer information on goods, prices, delivery dates, etc.
4. Buyer signs for order.
5. Company creates order, ships order to buyer.
6. Company ships invoice to buyer.
7. Buyers pays invoice.

'''EXTENSIONS'''
3a. Company is out of one of the ordered items:
3a1. Renegotiate order.
4a. Buyer pays directly with credit card:
4a1. Take payment by credit card (use case 44)
7a. Buyer returns goods:
7a. Handle returned goods (use case 105)
The basic steps that can be followed so as to ensure writing an effective use case has been described well in [https://www.wikihow.com/Write-a-Use-Case How to Write a use case].[4]

===Restaurant===
This example provides one use case but distinctly provides a step by step analysis of the events that constitute a Use Case. It mentions the actors, pre-conditions, Exceptions and Alternative scenarios.

* [http://www.uml-diagrams.org/restaurant-uml-use-case-diagram-example.html Restaurant]

===Purchase order===
This example provides a typical use case specification by listing the Activity, Result, Constraints and Extensions involved with a purchase order from a Finance web page.

* [https://creately.com/diagram/example/ifq4uulr/Purchase%20Order Purchase order System]

===ATM system===
This example is a little more involved in that it provides a number of use cases associated with using an ATM system including cash withdrawal,
transfers, deposits, balance inquiry, etc.

* [http://www.cs.fsu.edu/~baker/swe1/restricted/templates/rr631gv1_stuwrk_withdraw_cash_use-case_spec.pdf ATM System]

===A shopping website order Process===
This is a very good example that describes the scenarios and extensions involved in writing a use case for a online shopping order. It also describes the UML diagram.

* [http://www.uml-diagrams.org/examples/online-shopping-use-case-diagram-example.html?context=uc-examples Shopping website order]

===Self Service Machine===
This example provides the typical Use Cases in a self service machine. Some of the aspects of using a self service machine are: buying a product, re-stocking the machine, collecting the money etc. The following link expands on how to do this and also provides the UML diagrams which depict the interaction between the users and system through the use case

* [http://www.cloudbus.org/~raj/254/Lectures/RajUML2.pdf Self-Service Machine (page-3)]

=How to Write a Use Case?=

==Writing Effective Use Cases==

One of the most difficult problem in software development is capturing precisely what you want to build. Inaccurate requirement will end-up with significant delay, rework or even abandonment of the project. Effective applying use case technique helps your team capturing requirements in user point of view which can be easily understood by both the end-user and your team. Use case driven development support subsequent development activities such as analysis and design and testing.

Listed below are useful links in understanding how to write effective use cases.
* [https://www.visual-paradigm.com/tutorials/writingeffectiveusecase.jsp Writing Effective Use Cases]
* [https://www.wikihow.com/Write-a-Use-Case How to Write a use case]
* [http://www.utm.mx/~caff/doc/OpenUPWeb/openup/guidances/guidelines/detail_ucs_and_scenarios_6BC56BB7.html Writing Use Case]
=References=

* [1] Ivar Jacobson (1992). Object-Oriented Software Engineering. Addison Wesley Professional. ISBN 0-201-54435.
* [2] [http://en.wikipedia.org/wiki/Use_case Wikipidea Page] Basic definition of Use Case
* [3] [http://www.developer.com/design/article.php/2109801 Use Case Diagrams]
* [4] [https://www.wikihow.com/Write-a-Use-Case How to Write a use case]

=External Links=

* [http://www.cs.uno.edu/~jaime/Courses/4210/useCaseFundamentals.html Use Case Fundamentals]
* [http://www.developer.com/design/article.php/2109801 Elements of a Use Case Diagram]
* [https://www.visual-paradigm.com/tutorials/writingeffectiveusecase.jsp Writing effective Use Cases]
* [https://www.wikihow.com/Write-a-Use-Case How to Write a use case]
* [http://www.utm.mx/~caff/doc/OpenUPWeb/openup/guidances/guidelines/detail_ucs_and_scenarios_6BC56BB7.html Writing Use Case]
* [https://www.andrew.cmu.edu/course/90-754/umlucdfaq.html Tips and FAQ]

CSC/ECE 517 Fall 2007/wiki2 4 2q

2019-08-22T14:38:17Z

Mkhan8:

'''A Guide to Use Cases on the WEB'''

''Topic :Use cases. There are even more pages on the Web on use cases than on MVC[https://www.youtube.com/watch?v=DUg2SWWK18I (model-view-controller)]. If someone wants to learn about them, what should (s)he do? Look at the first few hits in Google? I expect we can do better than that. Write a review of the use-case sites on the Web. Which are best for learning about the concept? Which have the most instructive examples? Which teach advanced concepts that are not apparent in perusing most use-case sites? Read at least several dozen pages before deciding how to organize your overview.''

=Introduction=

This page tries to review the use-case sites on the Web which can be useful to best understand the concept. Also a few instructive examples are covered paying attention to the basic use case as well as advanced concepts that are not apparent in perusing most use-case sites.

=What is a Use Case?=

==Definition==
<blockquote> "'''''Use case''' is a methodology used in software and systems engineering to understand and identify the functional requirements of a system. Use cases describe the interaction between a primary actor, the initiator of the interaction and the system itself, represented as a sequence of simple steps.''"[1][2]</blockquote>

An actor who can more generally be described as the user of the system, is the external entity and can be a person or another system itself. A use case can be best described as what happens when the actor is using the system to achieve some goal. This goal is nothing but the end result which follows the sequence of events as described in the use cases.

Every use case gives a complete list of events which occur from the time the actor starts interacting with the system till the time the final goal is achieved. A use case also records all the possible scenarios that may occur while trying to reach the desired goal. We can think of it as existence of a main course of events that will occur in normal circumstances, to which the exceptional cases are added. Anything that is not relevant to the actor/user is not a part of the use case.

Listed below are a few links to external websites which further illustrate this concept.

* [https://www.ibm.com/developerworks/library/ws-using-oo/ OO design process: Use cases, an introduction]
* [http://www.cs.uno.edu/~jaime/Courses/4210/useCaseFundamentals.html Use Case Fundamentals]

==UML Diagrams and Use cases==
<blockquote> "''The Use case diagram is used to identify the primary elements and processes that form the system. The primary elements are termed as 'actors' and the processes are called "use cases." The Use case diagram shows which actors interact with each use case."''[3]</blockquote>

They are useful in providing a pictorial view of the interactions between the users (actors) and sets of events (use cases) associated with the system.They also evolve as the projects or system change with time. The standard elements of a use case diagram makes comprehension easy for anyone trying to understand the use case.

Listed below are useful links in understanding how to draw typical use case diagrams.

* [https://www.smartdraw.com/uml-diagram/ An introduction to UML diagrams & Tutorial]
* [http://www.developer.com/design/article.php/2109801 Elements of a Use Case Diagram]

=Examples using Use Cases=
In this section, a few instructive examples have been outlined along with their references which illustrate different ways in which use cases can be written. The first example is a basic use-case template.

===Basic use case template===
Described below are some the characteristics of a typical use case.
'''CHARACTERISTIC INFORMATION'''
* ''Goal in Context'': Buyer issues request directly to our company, expects goods shipped and to be billed.
* ''Scope'': Company
* ''Preconditions'': We know Buyer, their address, etc.
* ''Success End Condition'': Buyer has goods, we have money for the goods.
* ''Failed End Condition'': We have not sent the goods, Buyer has not spent the money.
* ''Primary Actor'': Buyer, any agent (or computer) acting for the customer
* ''Trigger'': purchase request comes in.

'''MAIN SUCCESS SCENARIO'''
1. Buyer calls in with a purchase request.
2. Company captures buyer’s name, address, requested goods, etc.
3. Company gives buyer information on goods, prices, delivery dates, etc.
4. Buyer signs for order.
5. Company creates order, ships order to buyer.
6. Company ships invoice to buyer.
7. Buyers pays invoice.

'''EXTENSIONS'''
3a. Company is out of one of the ordered items:
3a1. Renegotiate order.
4a. Buyer pays directly with credit card:
4a1. Take payment by credit card (use case 44)
7a. Buyer returns goods:
7a. Handle returned goods (use case 105)
The basic steps that can be followed so as to ensure writing an effective use case has been described well in [http://www.gatherspace.com/static/use_case_example.html Writing Effective Use Cases].[4]

===Restaurant===
This example provides one use case but distinctly provides a step by step analysis of the events that constitute a Use Case. It mentions the actors, pre-conditions, Exceptions and Alternative scenarios.

* [http://www.uml-diagrams.org/restaurant-uml-use-case-diagram-example.html Restaurant]

===Purchase order===
This example provides a typical use case specification by listing the Activity, Result, Constraints and Extensions involved with a purchase order from a Finance web page.

* [https://creately.com/diagram/example/ifq4uulr/Purchase%20Order Purchase order System]

===ATM system===
This example is a little more involved in that it provides a number of use cases associated with using an ATM system including cash withdrawal,
transfers, deposits, balance inquiry, etc.

* [http://www.cs.fsu.edu/~baker/swe1/restricted/templates/rr631gv1_stuwrk_withdraw_cash_use-case_spec.pdf ATM System]

===A shopping website order Process===
This is a very good example that describes the scenarios and extensions involved in writing a use case for a online shopping order. It also describes the UML diagram.

* [http://www.uml-diagrams.org/examples/online-shopping-use-case-diagram-example.html?context=uc-examples Shopping website order]

===Self Service Machine===
This example provides the typical Use Cases in a self service machine. Some of the aspects of using a self service machine are: buying a product, re-stocking the machine, collecting the money etc. The following link expands on how to do this and also provides the UML diagrams which depict the interaction between the users and system through the use case

* [http://www.cloudbus.org/~raj/254/Lectures/RajUML2.pdf Self-Service Machine (page-3)]

=How to Write a Use Case?=

==Writing Effective Use Cases==

One of the most difficult problem in software development is capturing precisely what you want to build. Inaccurate requirement will end-up with significant delay, rework or even abandonment of the project. Effective applying use case technique helps your team capturing requirements in user point of view which can be easily understood by both the end-user and your team. Use case driven development support subsequent development activities such as analysis and design and testing.

Listed below are useful links in understanding how to write effective use cases.
* [https://www.visual-paradigm.com/tutorials/writingeffectiveusecase.jsp Writing Effective Use Cases]
* [https://www.wikihow.com/Write-a-Use-Case How to Write a use case]

=References=

* [1] Ivar Jacobson (1992). Object-Oriented Software Engineering. Addison Wesley Professional. ISBN 0-201-54435.
* [2] [http://en.wikipedia.org/wiki/Use_case Wikipidea Page] Basic definition of Use Case
* [3] [http://www.developer.com/design/article.php/2109801 Use Case Diagrams]
* [4] [http://www.gatherspace.com/static/use_case_example.html#1 Writing Effective Use Cases]
* [5] [https://www.wikihow.com/Write-a-Use-Case How to Write a use case]

=External Links=

* [http://www.cs.uno.edu/~jaime/Courses/4210/useCaseFundamentals.html Use Case Fundamentals]
* [http://www.developer.com/design/article.php/2109801 Elements of a Use Case Diagram]
* [https://www.visual-paradigm.com/tutorials/writingeffectiveusecase.jsp Writing effective Use Cases]
* [https://www.wikihow.com/Write-a-Use-Case How to Write a use case]

CSC/ECE 517 Fall 2007/wiki2 4 2q

2019-08-22T13:49:53Z

Mkhan8:

'''A Guide to Use Cases on the WEB'''

''Topic :Use cases. There are even more pages on the Web on use cases than on MVC(model-view-controller). If someone wants to learn about them, what should (s)he do? Look at the first few hits in Google? I expect we can do better than that. Write a review of the use-case sites on the Web. Which are best for learning about the concept? Which have the most instructive examples? Which teach advanced concepts that are not apparent in perusing most use-case sites? Read at least several dozen pages before deciding how to organize your overview.''

=Introduction=

This page tries to review the use-case sites on the Web which can be useful to best understand the concept. Also a few instructive examples are covered paying attention to the basic use case as well as advanced concepts that are not apparent in perusing most use-case sites.

=What is a Use Case?=

==Definition==
<blockquote> "'''''Use case''' is a methodology used in software and systems engineering to understand and identify the functional requirements of a system. Use cases describe the interaction between a primary actor, the initiator of the interaction and the system itself, represented as a sequence of simple steps.''"[1][2]</blockquote>

An actor who can more generally be described as the user of the system, is the external entity and can be a person or another system itself. A use case can be best described as what happens when the actor is using the system to achieve some goal. This goal is nothing but the end result which follows the sequence of events as described in the use cases.

Every use case gives a complete list of events which occur from the time the actor starts interacting with the system till the time the final goal is achieved. A use case also records all the possible scenarios that may occur while trying to reach the desired goal. We can think of it as existence of a main course of events that will occur in normal circumstances, to which the exceptional cases are added. Anything that is not relevant to the actor/user is not a part of the use case.

Listed below are a few links to external websites which further illustrate this concept.

* [https://www.ibm.com/developerworks/library/ws-using-oo/ OO design process: Use cases, an introduction]
* [http://www.cs.uno.edu/~jaime/Courses/4210/useCaseFundamentals.html Use Case Fundamentals]

==UML Diagrams and Use cases==
<blockquote> "''The Use case diagram is used to identify the primary elements and processes that form the system. The primary elements are termed as 'actors' and the processes are called "use cases." The Use case diagram shows which actors interact with each use case."''[3]</blockquote>

They are useful in providing a pictorial view of the interactions between the users (actors) and sets of events (use cases) associated with the system.They also evolve as the projects or system change with time. The standard elements of a use case diagram makes comprehension easy for anyone trying to understand the use case.

Listed below are useful links in understanding how to draw typical use case diagrams.

* [https://www.smartdraw.com/uml-diagram/ An introduction to UML diagrams & Tutorial]
* [http://www.developer.com/design/article.php/2109801 Elements of a Use Case Diagram]

=Examples using Use Cases=
In this section, a few instructive examples have been outlined along with their references which illustrate different ways in which use cases can be written. The first example is a basic use-case template.

===Basic use case template===
Described below are some the characteristics of a typical use case.
'''CHARACTERISTIC INFORMATION'''
* ''Goal in Context'': Buyer issues request directly to our company, expects goods shipped and to be billed.
* ''Scope'': Company
* ''Preconditions'': We know Buyer, their address, etc.
* ''Success End Condition'': Buyer has goods, we have money for the goods.
* ''Failed End Condition'': We have not sent the goods, Buyer has not spent the money.
* ''Primary Actor'': Buyer, any agent (or computer) acting for the customer
* ''Trigger'': purchase request comes in.

'''MAIN SUCCESS SCENARIO'''
1. Buyer calls in with a purchase request.
2. Company captures buyer’s name, address, requested goods, etc.
3. Company gives buyer information on goods, prices, delivery dates, etc.
4. Buyer signs for order.
5. Company creates order, ships order to buyer.
6. Company ships invoice to buyer.
7. Buyers pays invoice.

'''EXTENSIONS'''
3a. Company is out of one of the ordered items:
3a1. Renegotiate order.
4a. Buyer pays directly with credit card:
4a1. Take payment by credit card (use case 44)
7a. Buyer returns goods:
7a. Handle returned goods (use case 105)
The basic steps that can be followed so as to ensure writing an effective use case has been described well in [http://www.gatherspace.com/static/use_case_example.html Writing Effective Use Cases].[4]

===Restaurant===
This example provides one use case but distinctly provides a step by step analysis of the events that constitute a Use Case. It mentions the actors, pre-conditions, Exceptions and Alternative scenarios.

* [http://www.uml-diagrams.org/restaurant-uml-use-case-diagram-example.html Restaurant]

===Purchase order===
This example provides a typical use case specification by listing the Activity, Result, Constraints and Extensions involved with a purchase order from a Finance web page.

* [https://creately.com/diagram/example/ifq4uulr/Purchase%20Order Purchase order System]

===ATM system===
This example is a little more involved in that it provides a number of use cases associated with using an ATM system including cash withdrawal,
transfers, deposits, balance inquiry, etc.

* [http://www.cs.fsu.edu/~baker/swe1/restricted/templates/rr631gv1_stuwrk_withdraw_cash_use-case_spec.pdf ATM System]

===A shopping website order Process===
This is a very good example that describes the scenarios and extensions involved in writing a use case for a online shopping order. It also describes the UML diagram.

* [http://www.uml-diagrams.org/examples/online-shopping-use-case-diagram-example.html?context=uc-examples Shopping website order]

===Self Service Machine===
This example provides the typical Use Cases in a self service machine. Some of the aspects of using a self service machine are: buying a product, re-stocking the machine, collecting the money etc. The following link expands on how to do this and also provides the UML diagrams which depict the interaction between the users and system through the use case

* [http://www.cloudbus.org/~raj/254/Lectures/RajUML2.pdf Self-Service Machine (page-3)]

=How to Write a Use Case?=

==Writing Effective Use Cases==

One of the most difficult problem in software development is capturing precisely what you want to build. Inaccurate requirement will end-up with significant delay, rework or even abandonment of the project. Effective applying use case technique helps your team capturing requirements in user point of view which can be easily understood by both the end-user and your team. Use case driven development support subsequent development activities such as analysis and design and testing.

Listed below are useful links in understanding how to write effective use cases.
* [https://www.visual-paradigm.com/tutorials/writingeffectiveusecase.jsp Writing Effective Use Cases]

=References=

* [1] Ivar Jacobson (1992). Object-Oriented Software Engineering. Addison Wesley Professional. ISBN 0-201-54435.
* [2] [http://en.wikipedia.org/wiki/Use_case Wikipidea Page] Basic definition of Use Case
* [3] [http://www.developer.com/design/article.php/2109801 Use Case Diagrams]
* [4] [http://www.gatherspace.com/static/use_case_example.html#1 Writing Effective Use Cases]

=External Links=

* [http://www.cs.uno.edu/~jaime/Courses/4210/useCaseFundamentals.html Use Case Fundamentals]
* [http://www.developer.com/design/article.php/2109801 Elements of a Use Case Diagram]
* [https://www.visual-paradigm.com/tutorials/writingeffectiveusecase.jsp Writing effective Use Cases]

File:E1860 ISSUE1.PNG

2018-11-20T21:50:17Z

Mkhan8: uploaded a new version of "File:E1860 ISSUE1.PNG"

File:1860 UI MOCK Issue3.PNG

2018-11-20T21:48:01Z

Mkhan8: uploaded a new version of "File:1860 UI MOCK Issue3.PNG"

File:1860 UI MOCK Issue3.PNG

2018-11-20T21:47:40Z

Mkhan8: uploaded a new version of "File:1860 UI MOCK Issue3.PNG"

CSC/ECE 517 Fall 2018/E1860 Improvements to staggered deadline

2018-11-20T21:46:05Z

Mkhan8: /* Add Colors to the Graded Reviews */

== Introduction ==
'''Staggered Deadline Assignment''' is an assignment which can have different topics listed under it and each of these topics have their independent submission and review deadline. Topic's deadline can be the same as parent assignment or independent to it . Such assignments are useful when the class material is more sequential and instructor wants students to complete assignment as and when a topic gets covered in the class. For example it wouldn't make sense to write a paper on a topic from Chapter 4, until the class had covered Chapter 4.

== Problem Statement ==

==== Staggered-deadline topic available for selection past its deadline====

This issue occurs when a '''Topic''' is created with multiple slots. If the topic is not selected for the first round of topics(assignment) or all the slots did not get filled up, It is still available for selection in the subsequent rounds. If a team selects the topic in a later round, they are not able to submit their work as the submission deadline is already over.
If the topic had only one slot which remained unselected, instructor can change the deadline for that topic to match the new deadlines, but for topics with multiple slots, if the deadline is extended, the teams who worked on this topic in the previous round can submit/review the topic again. This should not happen

====Manual submission and review deadline entry required for all topics====

When creating a topic an instructor is required to enter review and submission deadlines for all the topics. To reduce the manual we want to allow the instructor to apply one deadline entry to a set of topics and also let the system calculate subsequent dates for subsequent project phases like review and re-submission, based on an initial deadline entry. Instructor should also have the ability to edit each of those deadlines independently incase he wants to change a particular deadline of a topic.

====New submissions not identifiable among pool of already graded entries====

There is no way to identify new submissions or reviews are new since grading was last done. The '''Submissions''' and '''Reviews''' should appear in different color before and after they are graded. The color scheme should be compatible with the one used for review report. ie '''Red''' indicates incomplete Reviews, '''Blue''' indicates reviews that have not been graded and '''Brown''' for reviews that have grade assigned to them

== Proposed Design ==

===Issue 1===
==== Solution :Prevent Students from Signing up for topics past deadline====

Students can be prevented from signing up for a topic whose submission deadline has passed. Currently this is happening, but only in case of assignments/topics which do not have staggered deadlines.

'''sign_up_sheet_controller.rb'''

<pre>
unless assignment.due_dates.find_by_deadline_type_id(1).nil?
if !assignment.staggered_deadline? and assignment.due_dates.find_by_deadline_type_id(1).due_at < Time.now
@show_actions = false
</pre>

A Similar logic can be implemented for topic where we fetch the deadline for a '''topic''' by implementing a function and then determine whether to display that topic or not. The same function could also be modified to achieve the desired results.

[[File:E1860_ISSUE1.PNG]]

'''MOCK UI'''

[[File:E1860_UI_MOCK_ISSUE1.PNG]]

===Issue 2===
==== Add a new setting for Staggered Assignments ====

This can be achieved by adding a new setting to the staggered deadline assignments so that while creating the assignment an instructor can specify how much gap(days) is needed between the different rounds of submission and review.

Data will be stored in a new table and only staggered assignments will have this setting. Rationale behind not storing this data in the current '''Assignments''' is to avoid usage of space and prevent any error to the existing setup. Once we have this data, we can calculate all the deadlines for a topic once the instructor has entered the starting deadline. This will reduce a lot of manual work and this setting can be changed any time by the instructor/TA.

==== Add Dropdowns for Relative Dates ====

Changes will have to be made to the due_dates_table in the _due_dates.html.erb file. Changes have to be made to the datetime_picker_roundtype_roundnumber id. We could provide the user with a drop down menu listing a possible set of relative dates to chose from, in addition to the ability to manually enter a custom date. This could be done on the view side by modifying the date fields and adding the necessary JavaScript so that appropriate date responses are filled into the corresponding date fields when an option is chose from the dropdown menu.

[[File:Screen_Shot_2018-11-16_at_10.06.55_AM.png]]

MOCK UI- Issue 2:

[[File:Issue2_UI.png]]

=== Issue 3===
==== Add Colors to the Graded Reviews ====

Below color coding will be used to indicate the current stage of the reviews :

Red - Incomplete Review

Blue - Grade Unassigned to the Review

Brown - Review Complete/ Grade Assigned

This will be achieved by passing the colors of the reviews to _review_report.html.erb.

'''UI MOCK'''

[[File:1860_UI_MOCK_Issue3.PNG]]

== Test Plan ==

<big>'''''Issue 1: # Don’t allow students to sign up for topics that has past due dates.'''''</big>

; Pre-steps:

: 1. Login as an instructor.
: 2. Edit any assignment under the General tab, mark it as staggered deadline assignment.
: 3. Provide deadlines for few topics in the past.
: 4. Impersonate a student.
:5. In the Assignments section, Click on Sign-up sheet.
:6. verify topics available for sign-up.

;Data and Database Integrity Testing: None
;Functional Testing:
:Expectations:
:1. The modified topics should not be available for signup.
:2. The unmodified topics with deadlines in future should be available for signup.
;User Interface Testing:
:Expectation:
:1. A green tick mark should be available under ‘Actions’ tab for topics with deadlines in the future.
:2. Actions’ tab should be empty for topics with deadlines in the past.
;Performance Testing: None

<big>'''''Issue 2: # Provide default deadline options for assignments with staggered deadlines.'''''</big>

; Pre-steps:

: 1. Login as an instructor.
: 2. Go to assignments and either create a new one or edit a pre-existing one.
: 3. Change assignment type to staggered deadline.
: 4. Type in a submission deadline for Round 1-Submission.
:5. Verify that other due dates are auto populated.

;'''Case 1: Instructor wants to assign default deadlines to a staggered assignment:'''
; Steps:

: 1. Click save.
;Data and Database Integrity Testing:
:Expectations:
:1. Verify all deadlines are updated in due_at field in due_dates tables for corresponding deadline types after saving the populated values.

;Functional Testing:
:Expectations:
:1. Deadlines auto-populated for other Round N should be in correspondence with default offset days between rounds.
:2. The auto populated deadline should reflect in student assignment section.
;User Interface Testing:
:Expectation:
:1. The auto-population triggered on to corresponding fields by JavaScript should be correct.
:2. The format of date auto populated should be as per current system.
;Performance Testing:
:Expectation:
:1. The response time to auto populate the dates to other rounds should be within 5 second latency.

;'''Case 2: Instructor wants to enter a custom deadline only for a particular round:'''
; Steps:

: 1. Choose offset value from initial vale from dropdown option available against each deadline type.
;Data and Database Integrity Testing:
:Expectations:
:1. Verify all deadlines are updated in due_at field in due_dates tables for corresponding deadline types after saving the populated values.

;Functional Testing:
:Expectations:
:1. The auto populated deadline values are changed as per selected offset days from drop-down.
:2. Same should reflect in student assignment section.
;User Interface Testing:
:Expectation:
:1. The triggered change on to corresponding fields by JavaScript should be correct..
:2. The format of date auto populated should be as per current system.
;Performance Testing:
:Expectation:
:1. The response time to change the dates to other rounds should be within 5 second latency.

;'''Case 3: Entering an incorrect date when manually entering a deadline for a particular round for a staggered deadline. When the user decides to enter a deadline manually rather than choosing the relative deadlines from the dropdown, care must be taken to ensure that the date is in the correct form:'''
; Pre-steps:

: 1. Impersonate a student.
: 2. Go to assignments and click on others work.
: 3. Request multiple reviews.
: 4. Submit one review.
:5. Do not start another review and have another review incomplete.
:6. Impersonate Instructor.
:7. Go assignments page and view review report for this assignment for the impersonate student in step1.
:8. verify the results.

;User Interface Testing:
:Expectation:
:1. Incomplete reviews are marked Red.
:2. Ungraded reviews are marked Blue.
:3. Graded reviews are marked Brown.

File:1860 UI MOCK Issue3.PNG

2018-11-20T21:44:47Z

Mkhan8:

File:E1860 UI MOCK ISSUE1.PNG

2018-11-20T20:53:46Z

Mkhan8: uploaded a new version of "File:E1860 UI MOCK ISSUE1.PNG"

File:E1860 UI MOCK ISSUE1.PNG

2018-11-20T20:53:02Z

Mkhan8: uploaded a new version of "File:E1860 UI MOCK ISSUE1.PNG"

File:E1860 UI MOCK ISSUE1.PNG

2018-11-20T20:52:11Z

Mkhan8: uploaded a new version of "File:E1860 UI MOCK ISSUE1.PNG"

CSC/ECE 517 Fall 2018/E1860 Improvements to staggered deadline

2018-11-20T20:51:32Z

Mkhan8: /* Solution :Prevent Students from Signing up for topics past deadline */

== Introduction ==
'''Staggered Deadline Assignment''' is an assignment which can have different topics listed under it and each of these topics have their independent submission and review deadline. Topic's deadline can be the same as parent assignment or independent to it . Such assignments are useful when the class material is more sequential and instructor wants students to complete assignment as and when a topic gets covered in the class. For example it wouldn't make sense to write a paper on a topic from Chapter 4, until the class had covered Chapter 4.

== Problem Statement ==

==== Staggered-deadline topic available for selection past its deadline====

This issue occurs when a '''Topic''' is created with multiple slots. If the topic is not selected for the first round of topics(assignment) or all the slots did not get filled up, It is still available for selection in the subsequent rounds. If a team selects the topic in a later round, they are not able to submit their work as the submission deadline is already over.
If the topic had only one slot which remained unselected, instructor can change the deadline for that topic to match the new deadlines, but for topics with multiple slots, if the deadline is extended, the teams who worked on this topic in the previous round can submit/review the topic again. This should not happen

====Manual submission and review deadline entry required for all topics====

When creating a topic an instructor is required to enter review and submission deadlines for all the topics. To reduce the manual we want to allow the instructor to apply one deadline entry to a set of topics and also let the system calculate subsequent dates for subsequent project phases like review and re-submission, based on an initial deadline entry. Instructor should also have the ability to edit each of those deadlines independently incase he wants to change a particular deadline of a topic.

====New submissions not identifiable among pool of already graded entries====

There is no way to identify new submissions or reviews are new since grading was last done. The '''Submissions''' and '''Reviews''' should appear in different color before and after they are graded. The color scheme should be compatible with the one used for review report. ie '''Red''' indicates incomplete Reviews, '''Blue''' indicates reviews that have not been graded and '''Brown''' for reviews that have grade assigned to them

== Proposed Design ==

===Issue 1===
==== Solution :Prevent Students from Signing up for topics past deadline====

Students can be prevented from signing up for a topic whose submission deadline has passed. Currently this is happening, but only in case of assignments/topics which do not have staggered deadlines.

'''sign_up_sheet_controller.rb'''

<pre>
unless assignment.due_dates.find_by_deadline_type_id(1).nil?
if !assignment.staggered_deadline? and assignment.due_dates.find_by_deadline_type_id(1).due_at < Time.now
@show_actions = false
</pre>

A Similar logic can be implemented for topic where we fetch the deadline for a '''topic''' by implementing a function and then determine whether to display that topic or not. The same function could also be modified to achieve the desired results.

[[File:E1860_ISSUE1.PNG]]

'''MOCK UI'''

[[File:E1860_UI_MOCK_ISSUE1.PNG]]

===Issue 2===
==== Add a new setting for Staggered Assignments ====

This can be achieved by adding a new setting to the staggered deadline assignments so that while creating the assignment an instructor can specify how much gap(days) is needed between the different rounds of submission and review.

Data will be stored in a new table and only staggered assignments will have this setting. Rationale behind not storing this data in the current '''Assignments''' is to avoid usage of space and prevent any error to the existing setup. Once we have this data, we can calculate all the deadlines for a topic once the instructor has entered the starting deadline. This will reduce a lot of manual work and this setting can be changed any time by the instructor/TA.

==== Add Dropdowns for Relative Dates ====

Changes will have to be made to the due_dates_table in the _due_dates.html.erb file. Changes have to be made to the datetime_picker_roundtype_roundnumber id. We could provide the user with a drop down menu listing a possible set of relative dates to chose from, in addition to the ability to manually enter a custom date. This could be done on the view side by modifying the date fields and adding the necessary JavaScript so that appropriate date responses are filled into the corresponding date fields when an option is chose from the dropdown menu.

[[File:Screen_Shot_2018-11-16_at_10.06.55_AM.png]]

=== Issue 3===
==== Add Colors to the Graded Reviews ====

Below color coding will be used to indicate the current stage of the reviews :

Red - Incomplete Review

Blue - Grade Unassigned to the Review

Brown - Review Complete/ Grade Assigned

This will be achieved by passing the colors of the reviews to _review_report.html.erb.

== Test Plan ==

<big>'''''Issue 1: # Don’t allow students to sign up for topics that has past due dates.'''''</big>

; Pre-steps:

: 1. Login as an instructor.
: 2. Edit any assignment under the General tab, mark it as staggered deadline assignment.
: 3. Provide deadlines for few topics in the past.
: 4. Impersonate a student.
:5. In the Assignments section, Click on Sign-up sheet.
:6. verify topics available for sign-up.

;Data and Database Integrity Testing: None
;Functional Testing:
:Expectations:
:1. The modified topics should not be available for signup.
:2. The unmodified topics with deadlines in future should be available for signup.
;User Interface Testing:
:Expectation:
:1. A green tick mark should be available under ‘Actions’ tab for topics with deadlines in the future.
:2. Actions’ tab should be empty for topics with deadlines in the past.
;Performance Testing: None

<big>'''''Issue 2: # Provide default deadline options for assignments with staggered deadlines.'''''</big>

; Pre-steps:

: 1. Login as an instructor.
: 2. Go to assignments and either create a new one or edit a pre-existing one.
: 3. Change assignment type to staggered deadline.
: 4. Type in a submission deadline for Round 1-Submission.
:5. Verify that other due dates are auto populated.

;'''Case 1: Instructor wants to assign default deadlines to a staggered assignment:'''
; Steps:

: 1. Click save.
;Data and Database Integrity Testing:
:Expectations:
:1. Verify all deadlines are updated in due_at field in due_dates tables for corresponding deadline types after saving the populated values.

;Functional Testing:
:Expectations:
:1. Deadlines auto-populated for other Round N should be in correspondence with default offset days between rounds.
:2. The auto populated deadline should reflect in student assignment section.
;User Interface Testing:
:Expectation:
:1. The auto-population triggered on to corresponding fields by JavaScript should be correct.
:2. The format of date auto populated should be as per current system.
;Performance Testing:
:Expectation:
:1. The response time to auto populate the dates to other rounds should be within 5 second latency.

;'''Case 2: Instructor wants to enter a custom deadline only for a particular round:'''
; Steps:

: 1. Choose offset value from initial vale from dropdown option available against each deadline type.
;Data and Database Integrity Testing:
:Expectations:
:1. Verify all deadlines are updated in due_at field in due_dates tables for corresponding deadline types after saving the populated values.

;Functional Testing:
:Expectations:
:1. The auto populated deadline values are changed as per selected offset days from drop-down.
:2. Same should reflect in student assignment section.
;User Interface Testing:
:Expectation:
:1. The triggered change on to corresponding fields by JavaScript should be correct..
:2. The format of date auto populated should be as per current system.
;Performance Testing:
:Expectation:
:1. The response time to change the dates to other rounds should be within 5 second latency.

;'''Case 3: Entering an incorrect date when manually entering a deadline for a particular round for a staggered deadline. When the user decides to enter a deadline manually rather than choosing the relative deadlines from the dropdown, care must be taken to ensure that the date is in the correct form:'''
; Pre-steps:

: 1. Impersonate a student.
: 2. Go to assignments and click on others work.
: 3. Request multiple reviews.
: 4. Submit one review.
:5. Do not start another review and have another review incomplete.
:6. Impersonate Instructor.
:7. Go assignments page and view review report for this assignment for the impersonate student in step1.
:8. verify the results.

;User Interface Testing:
:Expectation:
:1. Incomplete reviews are marked Red.
:2. Ungraded reviews are marked Blue.
:3. Graded reviews are marked Brown.

File:E1860 UI MOCK ISSUE1.PNG

2018-11-20T20:51:00Z

Mkhan8:

CSC/ECE 517 Fall 2018/E1860 Improvements to staggered deadline

2018-11-20T20:50:41Z

Mkhan8: /* Solution :Prevent Students from Signing up for topics past deadline */

== Introduction ==
'''Staggered Deadline Assignment''' is an assignment which can have different topics listed under it and each of these topics have their independent submission and review deadline. Topic's deadline can be the same as parent assignment or independent to it . Such assignments are useful when the class material is more sequential and instructor wants students to complete assignment as and when a topic gets covered in the class. For example it wouldn't make sense to write a paper on a topic from Chapter 4, until the class had covered Chapter 4.

== Problem Statement ==

==== Staggered-deadline topic available for selection past its deadline====

This issue occurs when a '''Topic''' is created with multiple slots. If the topic is not selected for the first round of topics(assignment) or all the slots did not get filled up, It is still available for selection in the subsequent rounds. If a team selects the topic in a later round, they are not able to submit their work as the submission deadline is already over.
If the topic had only one slot which remained unselected, instructor can change the deadline for that topic to match the new deadlines, but for topics with multiple slots, if the deadline is extended, the teams who worked on this topic in the previous round can submit/review the topic again. This should not happen

====Manual submission and review deadline entry required for all topics====

When creating a topic an instructor is required to enter review and submission deadlines for all the topics. To reduce the manual we want to allow the instructor to apply one deadline entry to a set of topics and also let the system calculate subsequent dates for subsequent project phases like review and re-submission, based on an initial deadline entry. Instructor should also have the ability to edit each of those deadlines independently incase he wants to change a particular deadline of a topic.

====New submissions not identifiable among pool of already graded entries====

There is no way to identify new submissions or reviews are new since grading was last done. The '''Submissions''' and '''Reviews''' should appear in different color before and after they are graded. The color scheme should be compatible with the one used for review report. ie '''Red''' indicates incomplete Reviews, '''Blue''' indicates reviews that have not been graded and '''Brown''' for reviews that have grade assigned to them

== Proposed Design ==

===Issue 1===
==== Solution :Prevent Students from Signing up for topics past deadline====

Students can be prevented from signing up for a topic whose submission deadline has passed. Currently this is happening, but only in case of assignments/topics which do not have staggered deadlines.

'''sign_up_sheet_controller.rb'''

<pre>
unless assignment.due_dates.find_by_deadline_type_id(1).nil?
if !assignment.staggered_deadline? and assignment.due_dates.find_by_deadline_type_id(1).due_at < Time.now
@show_actions = false
</pre>

A Similar logic can be implemented for topic where we fetch the deadline for a '''topic''' by implementing a function and then determine whether to display that topic or not. The same function could also be modified to achieve the desired results.

[[File:E1860_ISSUE1.PNG]]

'''MOCK UI'''

[[File:Example.jpg]]

===Issue 2===
==== Add a new setting for Staggered Assignments ====

This can be achieved by adding a new setting to the staggered deadline assignments so that while creating the assignment an instructor can specify how much gap(days) is needed between the different rounds of submission and review.

Data will be stored in a new table and only staggered assignments will have this setting. Rationale behind not storing this data in the current '''Assignments''' is to avoid usage of space and prevent any error to the existing setup. Once we have this data, we can calculate all the deadlines for a topic once the instructor has entered the starting deadline. This will reduce a lot of manual work and this setting can be changed any time by the instructor/TA.

==== Add Dropdowns for Relative Dates ====

Changes will have to be made to the due_dates_table in the _due_dates.html.erb file. Changes have to be made to the datetime_picker_roundtype_roundnumber id. We could provide the user with a drop down menu listing a possible set of relative dates to chose from, in addition to the ability to manually enter a custom date. This could be done on the view side by modifying the date fields and adding the necessary JavaScript so that appropriate date responses are filled into the corresponding date fields when an option is chose from the dropdown menu.

[[File:Screen_Shot_2018-11-16_at_10.06.55_AM.png]]

=== Issue 3===
==== Add Colors to the Graded Reviews ====

Below color coding will be used to indicate the current stage of the reviews :

Red - Incomplete Review

Blue - Grade Unassigned to the Review

Brown - Review Complete/ Grade Assigned

This will be achieved by passing the colors of the reviews to _review_report.html.erb.

== Test Plan ==

<big>'''''Issue 1: # Don’t allow students to sign up for topics that has past due dates.'''''</big>

; Pre-steps:

: 1. Login as an instructor.
: 2. Edit any assignment under the General tab, mark it as staggered deadline assignment.
: 3. Provide deadlines for few topics in the past.
: 4. Impersonate a student.
:5. In the Assignments section, Click on Sign-up sheet.
:6. verify topics available for sign-up.

;Data and Database Integrity Testing: None
;Functional Testing:
:Expectations:
:1. The modified topics should not be available for signup.
:2. The unmodified topics with deadlines in future should be available for signup.
;User Interface Testing:
:Expectation:
:1. A green tick mark should be available under ‘Actions’ tab for topics with deadlines in the future.
:2. Actions’ tab should be empty for topics with deadlines in the past.
;Performance Testing: None

<big>'''''Issue 2: # Provide default deadline options for assignments with staggered deadlines.'''''</big>

; Pre-steps:

: 1. Login as an instructor.
: 2. Go to assignments and either create a new one or edit a pre-existing one.
: 3. Change assignment type to staggered deadline.
: 4. Type in a submission deadline for Round 1-Submission.
:5. Verify that other due dates are auto populated.

;'''Case 1: Instructor wants to assign default deadlines to a staggered assignment:'''
; Steps:

: 1. Click save.
;Data and Database Integrity Testing:
:Expectations:
:1. Verify all deadlines are updated in due_at field in due_dates tables for corresponding deadline types after saving the populated values.

;Functional Testing:
:Expectations:
:1. Deadlines auto-populated for other Round N should be in correspondence with default offset days between rounds.
:2. The auto populated deadline should reflect in student assignment section.
;User Interface Testing:
:Expectation:
:1. The auto-population triggered on to corresponding fields by JavaScript should be correct.
:2. The format of date auto populated should be as per current system.
;Performance Testing:
:Expectation:
:1. The response time to auto populate the dates to other rounds should be within 5 second latency.

;'''Case 2: Instructor wants to enter a custom deadline only for a particular round:'''
; Steps:

: 1. Choose offset value from initial vale from dropdown option available against each deadline type.
;Data and Database Integrity Testing:
:Expectations:
:1. Verify all deadlines are updated in due_at field in due_dates tables for corresponding deadline types after saving the populated values.

;Functional Testing:
:Expectations:
:1. The auto populated deadline values are changed as per selected offset days from drop-down.
:2. Same should reflect in student assignment section.
;User Interface Testing:
:Expectation:
:1. The triggered change on to corresponding fields by JavaScript should be correct..
:2. The format of date auto populated should be as per current system.
;Performance Testing:
:Expectation:
:1. The response time to change the dates to other rounds should be within 5 second latency.

CSC/ECE 517 Fall 2018/E1860 Improvements to staggered deadline

2018-11-20T20:23:09Z

Mkhan8: /* Solution :Prevent Students from Signing up for topics past deadline */

== Introduction ==
'''Staggered Deadline Assignment''' is an assignment which can have different topics listed under it and each of these topics have their independent submission and review deadline. Topic's deadline can be the same as parent assignment or independent to it . Such assignments are useful when the class material is more sequential and instructor wants students to complete assignment as and when a topic gets covered in the class. For example it wouldn't make sense to write a paper on a topic from Chapter 4, until the class had covered Chapter 4.

== Problem Statement ==

==== Staggered-deadline topic available for selection past its deadline====

This issue occurs when a '''Topic''' is created with multiple slots. If the topic is not selected for the first round of topics(assignment) or all the slots did not get filled up, It is still available for selection in the subsequent rounds. If a team selects the topic in a later round, they are not able to submit their work as the submission deadline is already over.
If the topic had only one slot which remained unselected, instructor can change the deadline for that topic to match the new deadlines, but for topics with multiple slots, if the deadline is extended, the teams who worked on this topic in the previous round can submit/review the topic again. This should not happen

====Manual submission and review deadline entry required for all topics====

When creating a topic an instructor is required to enter review and submission deadlines for all the topics. To reduce the manual we want to allow the instructor to apply one deadline entry to a set of topics and also let the system calculate subsequent dates for subsequent project phases like review and re-submission, based on an initial deadline entry. Instructor should also have the ability to edit each of those deadlines independently incase he wants to change a particular deadline of a topic.

====New submissions not identifiable among pool of already graded entries====

There is no way to identify new submissions or reviews are new since grading was last done. The '''Submissions''' and '''Reviews''' should appear in different color before and after they are graded. The color scheme should be compatible with the one used for review report. ie '''Red''' indicates incomplete Reviews, '''Blue''' indicates reviews that have not been graded and '''Brown''' for reviews that have grade assigned to them

== Proposed Design ==

===Issue 1===
==== Solution :Prevent Students from Signing up for topics past deadline====

Students can be prevented from signing up for a topic whose submission deadline has passed. Currently this is happening, but only in case of assignments/topics which do not have staggered deadlines.

'''sign_up_sheet_controller.rb'''

<pre>
unless assignment.due_dates.find_by_deadline_type_id(1).nil?
if !assignment.staggered_deadline? and assignment.due_dates.find_by_deadline_type_id(1).due_at < Time.now
@show_actions = false
</pre>

A Similar logic can be implemented for topic where we fetch the deadline for a '''topic''' by implementing a function and then determine whether to display that topic or not. The same function could also be modified to achieve the desired results.

[[File:E1860_ISSUE1.PNG]]

===Issue 2===
==== Add a new setting for Staggered Assignments ====

This can be achieved by adding a new setting to the staggered deadline assignments so that while creating the assignment an instructor can specify how much gap(days) is needed between the different rounds of submission and review.

Data will be stored in a new table and only staggered assignments will have this setting. Rationale behind not storing this data in the current '''Assignments''' is to avoid usage of space and prevent any error to the existing setup. Once we have this data, we can calculate all the deadlines for a topic once the instructor has entered the starting deadline. This will reduce a lot of manual work and this setting can be changed any time by the instructor/TA.

==== Add Dropdowns for Relative Dates ====

Changes will have to be made to the due_dates_table in the _due_dates.html.erb file. Changes have to be made to the datetime_picker_roundtype_roundnumber id. We could provide the user with a drop down menu listing a possible set of relative dates to chose from, in addition to the ability to manually enter a custom date. This could be done on the view side by modifying the date fields and adding the necessary JavaScript so that appropriate date responses are filled into the corresponding date fields when an option is chose from the dropdown menu.

[[File:Screen_Shot_2018-11-16_at_10.06.55_AM.png]]

=== Issue 3===
==== Add Colors to the Graded Reviews ====

Below color coding will be used to indicate the current stage of the reviews :

Red - Incomplete Review

Blue - Grade Unassigned to the Review

Brown - Review Complete/ Grade Assigned

This will be achieved by passing the colors of the reviews to _review_report.html.erb.

== Test Plan ==

<big>'''''Issue 1: # Don’t allow students to sign up for topics that has past due dates.'''''</big>

; Pre-steps:

: 1. Login as an instructor.
: 2. Edit any assignment under the General tab, mark it as staggered deadline assignment.
: 3. Provide deadlines for few topics in the past.
: 4. Impersonate a student.
:5. In the Assignments section, Click on Sign-up sheet.
:6. verify topics available for sign-up.

;Data and Database Integrity Testing: None
;Functional Testing:
:Expectations:
:1. The modified topics should not be available for signup.
:2. The unmodified topics with deadlines in future should be available for signup.
;User Interface Testing:
:Expectation:
:1. A green tick mark should be available under ‘Actions’ tab for topics with deadlines in the future.
:2. Actions’ tab should be empty for topics with deadlines in the past.
;Performance Testing: None

<big>'''''Issue 2: # Provide default deadline options for assignments with staggered deadlines.'''''</big>

; Pre-steps:

: 1. Login as an instructor.
: 2. Go to assignments and either create a new one or edit a pre-existing one.
: 3. Change assignment type to staggered deadline.
: 4. Type in a submission deadline for Round 1-Submission.
:5. Verify that other due dates are auto populated.

;'''Case 1: Instructor wants to assign default deadlines to a staggered assignment:'''
; Steps:

: 1. Click save.
;Data and Database Integrity Testing:
:Expectations:
:1. Verify all deadlines are updated in due_at field in due_dates tables for corresponding deadline types after saving the populated values.

;Functional Testing:
:Expectations:
:1. Deadlines auto-populated for other Round N should be in correspondence with default offset days between rounds.
:2. The auto populated deadline should reflect in student assignment section.
;User Interface Testing:
:Expectation:
:1. The auto-population triggered on to corresponding fields by JavaScript should be correct.
:2. The format of date auto populated should be as per current system.
;Performance Testing:
:Expectation:
:1. The response time to auto populate the dates to other rounds should be within 5 second latency.

;'''Case 2: Instructor wants to enter a custom deadline only for a particular round:'''
; Steps:

: 1. Choose offset value from initial vale from dropdown option available against each deadline type.
;Data and Database Integrity Testing:
:Expectations:
:1. Verify all deadlines are updated in due_at field in due_dates tables for corresponding deadline types after saving the populated values.

;Functional Testing:
:Expectations:
:1. The auto populated deadline values are changed as per selected offset days from drop-down.
:2. Same should reflect in student assignment section.
;User Interface Testing:
:Expectation:
:1. The triggered change on to corresponding fields by JavaScript should be correct..
:2. The format of date auto populated should be as per current system.
;Performance Testing:
:Expectation:
:1. The response time to change the dates to other rounds should be within 5 second latency.

File:E1860 ISSUE1.PNG

2018-11-20T20:22:29Z

Mkhan8:

File:Issue1.png

2018-11-20T20:21:01Z

Mkhan8: uploaded a new version of "File:Issue1.png"

CSC/ECE 517 Fall 2018/E1860 Improvements to staggered deadline

2018-11-20T20:20:05Z

Mkhan8: /* Solution :Prevent Students from Signing up for topics past deadline */

== Introduction ==
'''Staggered Deadline Assignment''' is an assignment which can have different topics listed under it and each of these topics have their independent submission and review deadline. Topic's deadline can be the same as parent assignment or independent to it . Such assignments are useful when the class material is more sequential and instructor wants students to complete assignment as and when a topic gets covered in the class. For example it wouldn't make sense to write a paper on a topic from Chapter 4, until the class had covered Chapter 4.

== Problem Statement ==

==== Staggered-deadline topic available for selection past its deadline====

This issue occurs when a '''Topic''' is created with multiple slots. If the topic is not selected for the first round of topics(assignment) or all the slots did not get filled up, It is still available for selection in the subsequent rounds. If a team selects the topic in a later round, they are not able to submit their work as the submission deadline is already over.
If the topic had only one slot which remained unselected, instructor can change the deadline for that topic to match the new deadlines, but for topics with multiple slots, if the deadline is extended, the teams who worked on this topic in the previous round can submit/review the topic again. This should not happen

====Manual submission and review deadline entry required for all topics====

When creating a topic an instructor is required to enter review and submission deadlines for all the topics. To reduce the manual we want to allow the instructor to apply one deadline entry to a set of topics and also let the system calculate subsequent dates for subsequent project phases like review and re-submission, based on an initial deadline entry. Instructor should also have the ability to edit each of those deadlines independently incase he wants to change a particular deadline of a topic.

====New submissions not identifiable among pool of already graded entries====

There is no way to identify new submissions or reviews are new since grading was last done. The '''Submissions''' and '''Reviews''' should appear in different color before and after they are graded. The color scheme should be compatible with the one used for review report. ie '''Red''' indicates incomplete Reviews, '''Blue''' indicates reviews that have not been graded and '''Brown''' for reviews that have grade assigned to them

== Proposed Design ==

===Issue 1===
==== Solution :Prevent Students from Signing up for topics past deadline====

Students can be prevented from signing up for a topic whose submission deadline has passed. Currently this is happening, but only in case of assignments/topics which do not have staggered deadlines.

'''sign_up_sheet_controller.rb'''

<pre>
unless assignment.due_dates.find_by_deadline_type_id(1).nil?
if !assignment.staggered_deadline? and assignment.due_dates.find_by_deadline_type_id(1).due_at < Time.now
@show_actions = false
</pre>

A Similar logic can be implemented for topic where we fetch the deadline for a '''topic''' by implementing a function and then determine whether to display that topic or not. The same function could also be modified to achieve the desired results.

[[File: Issue1.png]]

===Issue 2===
==== Add a new setting for Staggered Assignments ====

This can be achieved by adding a new setting to the staggered deadline assignments so that while creating the assignment an instructor can specify how much gap(days) is needed between the different rounds of submission and review.

Data will be stored in a new table and only staggered assignments will have this setting. Rationale behind not storing this data in the current '''Assignments''' is to avoid usage of space and prevent any error to the existing setup. Once we have this data, we can calculate all the deadlines for a topic once the instructor has entered the starting deadline. This will reduce a lot of manual work and this setting can be changed any time by the instructor/TA.

==== Add Dropdowns for Relative Dates ====

Changes will have to be made to the due_dates_table in the _due_dates.html.erb file. Changes have to be made to the datetime_picker_roundtype_roundnumber id. We could provide the user with a drop down menu listing a possible set of relative dates to chose from, in addition to the ability to manually enter a custom date. This could be done on the view side by modifying the date fields and adding the necessary JavaScript so that appropriate date responses are filled into the corresponding date fields when an option is chose from the dropdown menu.

[[File:Screen_Shot_2018-11-16_at_10.06.55_AM.png]]

=== Issue 3===
==== Add Colors to the Graded Reviews ====

Below color coding will be used to indicate the current stage of the reviews :

Red - Incomplete Review

Blue - Grade Unassigned to the Review

Brown - Review Complete/ Grade Assigned

This will be achieved by passing the colors of the reviews to _review_report.html.erb.

== Test Plan ==

<big>'''''Issue 1: # Don’t allow students to sign up for topics that has past due dates.'''''</big>

; Pre-steps:

: 1. Login as an instructor.
: 2. Edit any assignment under the General tab, mark it as staggered deadline assignment.
: 3. Provide deadlines for few topics in the past.
: 4. Impersonate a student.
:5. In the Assignments section, Click on Sign-up sheet.
:6. verify topics available for sign-up.

;Data and Database Integrity Testing: None
;Functional Testing:
:Expectations:
:1. The modified topics should not be available for signup.
:2. The unmodified topics with deadlines in future should be available for signup.
;User Interface Testing:
:Expectation:
:1. A green tick mark should be available under ‘Actions’ tab for topics with deadlines in the future.
:2. Actions’ tab should be empty for topics with deadlines in the past.
;Performance Testing: None

<big>'''''Issue 2: # Provide default deadline options for assignments with staggered deadlines.'''''</big>

; Pre-steps:

: 1. Login as an instructor.
: 2. Go to assignments and either create a new one or edit a pre-existing one.
: 3. Change assignment type to staggered deadline.
: 4. Type in a submission deadline for Round 1-Submission.
:5. Verify that other due dates are auto populated.

;'''Case 1: Instructor wants to assign default deadlines to a staggered assignment:'''
; Steps:

: 1. Click save.
;Data and Database Integrity Testing:
:Expectations:
:1. Verify all deadlines are updated in due_at field in due_dates tables for corresponding deadline types after saving the populated values.

;Functional Testing:
:Expectations:
:1. Deadlines auto-populated for other Round N should be in correspondence with default offset days between rounds.
:2. The auto populated deadline should reflect in student assignment section.
;User Interface Testing:
:Expectation:
:1. The auto-population triggered on to corresponding fields by JavaScript should be correct.
:2. The format of date auto populated should be as per current system.
;Performance Testing:
:Expectation:
:1. The response time to auto populate the dates to other rounds should be within 5 second latency.

;'''Case 2: Instructor wants to enter a custom deadline only for a particular round:'''
; Steps:

: 1. Choose offset value from initial vale from dropdown option available against each deadline type.
;Data and Database Integrity Testing:
:Expectations:
:1. Verify all deadlines are updated in due_at field in due_dates tables for corresponding deadline types after saving the populated values.

;Functional Testing:
:Expectations:
:1. The auto populated deadline values are changed as per selected offset days from drop-down.
:2. Same should reflect in student assignment section.
;User Interface Testing:
:Expectation:
:1. The triggered change on to corresponding fields by JavaScript should be correct..
:2. The format of date auto populated should be as per current system.
;Performance Testing:
:Expectation:
:1. The response time to change the dates to other rounds should be within 5 second latency.

File:Issue1.png

2018-11-20T20:18:48Z

Mkhan8: uploaded a new version of "File:Issue1.png"

CSC/ECE 517 Fall 2018/E1860 Improvements to staggered deadline

2018-11-20T20:18:23Z

Mkhan8: /* Solution :Prevent Students from Signing up for topics past deadline */

== Introduction ==
'''Staggered Deadline Assignment''' is an assignment which can have different topics listed under it and each of these topics have their independent submission and review deadline. Topic's deadline can be the same as parent assignment or independent to it . Such assignments are useful when the class material is more sequential and instructor wants students to complete assignment as and when a topic gets covered in the class. For example it wouldn't make sense to write a paper on a topic from Chapter 4, until the class had covered Chapter 4.

== Problem Statement ==

==== Staggered-deadline topic available for selection past its deadline====

This issue occurs when a '''Topic''' is created with multiple slots. If the topic is not selected for the first round of topics(assignment) or all the slots did not get filled up, It is still available for selection in the subsequent rounds. If a team selects the topic in a later round, they are not able to submit their work as the submission deadline is already over.
If the topic had only one slot which remained unselected, instructor can change the deadline for that topic to match the new deadlines, but for topics with multiple slots, if the deadline is extended, the teams who worked on this topic in the previous round can submit/review the topic again. This should not happen

====Manual submission and review deadline entry required for all topics====

When creating a topic an instructor is required to enter review and submission deadlines for all the topics. To reduce the manual we want to allow the instructor to apply one deadline entry to a set of topics and also let the system calculate subsequent dates for subsequent project phases like review and re-submission, based on an initial deadline entry. Instructor should also have the ability to edit each of those deadlines independently incase he wants to change a particular deadline of a topic.

====New submissions not identifiable among pool of already graded entries====

There is no way to identify new submissions or reviews are new since grading was last done. The '''Submissions''' and '''Reviews''' should appear in different color before and after they are graded. The color scheme should be compatible with the one used for review report. ie '''Red''' indicates incomplete Reviews, '''Blue''' indicates reviews that have not been graded and '''Brown''' for reviews that have grade assigned to them

== Proposed Design ==

===Issue 1===
==== Solution :Prevent Students from Signing up for topics past deadline====

Students can be prevented from signing up for a topic whose submission deadline has passed. Currently this is happening, but only in case of assignments/topics which do not have staggered deadlines.

'''sign_up_sheet_controller.rb'''

<pre>
unless assignment.due_dates.find_by_deadline_type_id(1).nil?
if !assignment.staggered_deadline? and assignment.due_dates.find_by_deadline_type_id(1).due_at < Time.now
@show_actions = false
</pre>

A Similar logic can be implemented for topic where we fetch the deadline for a '''topic''' by implementing a function and then determine whether to display that topic or not. The same function could also be modified to achieve the desired results.

[[File:Issue1.png]]

===Issue 2===
==== Add a new setting for Staggered Assignments ====

This can be achieved by adding a new setting to the staggered deadline assignments so that while creating the assignment an instructor can specify how much gap(days) is needed between the different rounds of submission and review.

Data will be stored in a new table and only staggered assignments will have this setting. Rationale behind not storing this data in the current '''Assignments''' is to avoid usage of space and prevent any error to the existing setup. Once we have this data, we can calculate all the deadlines for a topic once the instructor has entered the starting deadline. This will reduce a lot of manual work and this setting can be changed any time by the instructor/TA.

==== Add Dropdowns for Relative Dates ====

Changes will have to be made to the due_dates_table in the _due_dates.html.erb file. Changes have to be made to the datetime_picker_roundtype_roundnumber id. We could provide the user with a drop down menu listing a possible set of relative dates to chose from, in addition to the ability to manually enter a custom date. This could be done on the view side by modifying the date fields and adding the necessary JavaScript so that appropriate date responses are filled into the corresponding date fields when an option is chose from the dropdown menu.

[[File:Screen_Shot_2018-11-16_at_10.06.55_AM.png]]

=== Issue 3===
==== Add Colors to the Graded Reviews ====

Below color coding will be used to indicate the current stage of the reviews :

Red - Incomplete Review

Blue - Grade Unassigned to the Review

Brown - Review Complete/ Grade Assigned

This will be achieved by passing the colors of the reviews to _review_report.html.erb.

== Test Plan ==

<big>'''''Issue 1: # Don’t allow students to sign up for topics that has past due dates.'''''</big>

; Pre-steps:

: 1. Login as an instructor.
: 2. Edit any assignment under the General tab, mark it as staggered deadline assignment.
: 3. Provide deadlines for few topics in the past.
: 4. Impersonate a student.
:5. In the Assignments section, Click on Sign-up sheet.
:6. verify topics available for sign-up.

;Data and Database Integrity Testing: None
;Functional Testing:
:Expectations:
:1. The modified topics should not be available for signup.
:2. The unmodified topics with deadlines in future should be available for signup.
;User Interface Testing:
:Expectation:
:1. A green tick mark should be available under ‘Actions’ tab for topics with deadlines in the future.
:2. Actions’ tab should be empty for topics with deadlines in the past.
;Performance Testing: None

<big>'''''Issue 2: # Provide default deadline options for assignments with staggered deadlines.'''''</big>

; Pre-steps:

: 1. Login as an instructor.
: 2. Go to assignments and either create a new one or edit a pre-existing one.
: 3. Change assignment type to staggered deadline.
: 4. Type in a submission deadline for Round 1-Submission.
:5. Verify that other due dates are auto populated.

;'''Case 1: Instructor wants to assign default deadlines to a staggered assignment:'''
; Steps:

: 1. Click save.
;Data and Database Integrity Testing:
:Expectations:
:1. Verify all deadlines are updated in due_at field in due_dates tables for corresponding deadline types after saving the populated values.

;Functional Testing:
:Expectations:
:1. Deadlines auto-populated for other Round N should be in correspondence with default offset days between rounds.
:2. The auto populated deadline should reflect in student assignment section.
;User Interface Testing:
:Expectation:
:1. The auto-population triggered on to corresponding fields by JavaScript should be correct.
:2. The format of date auto populated should be as per current system.
;Performance Testing:
:Expectation:
:1. The response time to auto populate the dates to other rounds should be within 5 second latency.

;'''Case 2: Instructor wants to enter a custom deadline only for a particular round:'''
; Steps:

: 1. Choose offset value from initial vale from dropdown option available against each deadline type.
;Data and Database Integrity Testing:
:Expectations:
:1. Verify all deadlines are updated in due_at field in due_dates tables for corresponding deadline types after saving the populated values.

;Functional Testing:
:Expectations:
:1. The auto populated deadline values are changed as per selected offset days from drop-down.
:2. Same should reflect in student assignment section.
;User Interface Testing:
:Expectation:
:1. The triggered change on to corresponding fields by JavaScript should be correct..
:2. The format of date auto populated should be as per current system.
;Performance Testing:
:Expectation:
:1. The response time to change the dates to other rounds should be within 5 second latency.

CSC/ECE 517 Fall 2018/E1860 Improvements to staggered deadline

2018-11-20T19:44:13Z

Mkhan8: /* Solution 1 - Prevent Students from Signing up for topics past deadline */

== Introduction ==
'''Staggered Deadline Assignment''' is an assignment which can have different topics listed under it and each of these topics have their independent submission and review deadline. Topic's deadline can be the same as parent assignment or independent to it . Such assignments are useful when the class material is more sequential and instructor wants students to complete assignment as and when a topic gets covered in the class. For example it wouldn't make sense to write a paper on a topic from Chapter 4, until the class had covered Chapter 4.

== Problem Statement ==

==== Staggered-deadline topic available for selection past its deadline====

This issue occurs when a '''Topic''' is created with multiple slots. If the topic is not selected for the first round of topics(assignment) or all the slots did not get filled up, It is still available for selection in the subsequent rounds. If a team selects the topic in a later round, they are not able to submit their work as the submission deadline is already over.
If the topic had only one slot which remained unselected, instructor can change the deadline for that topic to match the new deadlines, but for topics with multiple slots, if the deadline is extended, the teams who worked on this topic in the previous round can submit/review the topic again. This should not happen

====Manual submission and review deadline entry required for all topics====

When creating a topic an instructor is required to enter review and submission deadlines for all the topics. To reduce the manual we want to allow the instructor to apply one deadline entry to a set of topics and also let the system calculate subsequent dates for subsequent project phases like review and re-submission, based on an initial deadline entry. Instructor should also have the ability to edit each of those deadlines independently incase he wants to change a particular deadline of a topic.

====New submissions not identifiable among pool of already graded entries====

There is no way to identify new submissions or reviews are new since grading was last done. The '''Submissions''' and '''Reviews''' should appear in different color before and after they are graded. The color scheme should be compatible with the one used for review report. ie '''Red''' indicates incomplete Reviews, '''Blue''' indicates reviews that have not been graded and '''Brown''' for reviews that have grade assigned to them

== Proposed Design ==

===Issue 1===
==== Solution :Prevent Students from Signing up for topics past deadline====

Students can be prevented from signing up for a topic whose submission deadline has passed. Currently this is happening, but only in case of assignments/topics which do not have staggered deadlines.

'''sign_up_sheet_controller.rb'''

<pre>
unless assignment.due_dates.find_by_deadline_type_id(1).nil?
if !assignment.staggered_deadline? and assignment.due_dates.find_by_deadline_type_id(1).due_at < Time.now
@show_actions = false
</pre>

A Similar logic can be implemented for topic where we fetch the deadline for a '''topic''' by implementing a function and then determine whether to display that topic or not. The same function could also be modified to achieve the desired results.

[[File:Issue1.jpeg]]

===Issue 2===
==== Add a new setting for Staggered Assignments ====

This can be achieved by adding a new setting to the staggered deadline assignments so that while creating the assignment an instructor can specify how much gap(days) is needed between the different rounds of submission and review.

Data will be stored in a new table and only staggered assignments will have this setting. Rationale behind not storing this data in the current '''Assignments''' is to avoid usage of space and prevent any error to the existing setup. Once we have this data, we can calculate all the deadlines for a topic once the instructor has entered the starting deadline. This will reduce a lot of manual work and this setting can be changed any time by the instructor/TA.

==== Add Dropdowns for Relative Dates ====

Changes will have to be made to the due_dates_table in the _due_dates.html.erb file. Changes have to be made to the datetime_picker_roundtype_roundnumber id. We could provide the user with a drop down menu listing a possible set of relative dates to chose from, in addition to the ability to manually enter a custom date. This could be done on the view side by modifying the date fields and adding the necessary JavaScript so that appropriate date responses are filled into the corresponding date fields when an option is chose from the dropdown menu.

[[File:Screen_Shot_2018-11-16_at_10.06.55_AM.png]]

=== Issue 3===
==== Add Colors to the Graded Reviews ====

Below color coding will be used to indicate the current stage of the reviews :

Red - Incomplete Review

Blue - Grade Unassigned to the Review

Brown - Review Complete/ Grade Assigned

This will be achieved by passing the colors of the reviews to _review_report.html.erb.

== Test Plan ==

<big>'''''Issue 1: # Don’t allow students to sign up for topics that has past due dates.'''''</big>

; Pre-steps:

: 1. Login as an instructor.
: 2. Edit any assignment under the General tab, mark it as staggered deadline assignment.
: 3. Provide deadlines for few topics in the past.
: 4. Impersonate a student.
:5. In the Assignments section, Click on Sign-up sheet.
:6. verify topics available for sign-up.

;Data and Database Integrity Testing: None
;Functional Testing:
:Expectations:
:1. The modified topics should not be available for signup.
:2. The unmodified topics with deadlines in future should be available for signup.
;User Interface Testing:
:Expectation:
:1. A green tick mark should be available under ‘Actions’ tab for topics with deadlines in the future.
:2. Actions’ tab should be empty for topics with deadlines in the past.
;Performance Testing: None

<big>'''''Issue 2: # Provide default deadline options for assignments with staggered deadlines.'''''</big>

; Pre-steps:

: 1. Login as an instructor.
: 2. Go to assignments and either create a new one or edit a pre-existing one.
: 3. Change assignment type to staggered deadline.
: 4. Type in a submission deadline for Round 1-Submission.
:5. Verify that other due dates are auto populated.

;'''Case 1: Instructor wants to assign default deadlines to a staggered assignment:'''
; Steps:

: 1. Click save.
;Data and Database Integrity Testing:
:Expectations:
:1. Verify all deadlines are updated in due_at field in due_dates tables for corresponding deadline types after saving the populated values.

;Functional Testing:
:Expectations:
:1. Deadlines auto-populated for other Round N should be in correspondence with default offset days between rounds.
:2. The auto populated deadline should reflect in student assignment section.
;User Interface Testing:
:Expectation:
:1. The auto-population triggered on to corresponding fields by JavaScript should be correct.
:2. The format of date auto populated should be as per current system.
;Performance Testing:
:Expectation:
:1. The response time to auto populate the dates to other rounds should be within 5 second latency.

;'''Case 2: Instructor wants to enter a custom deadline only for a particular round:'''
; Steps:

: 1. Choose offset value from initial vale from dropdown option available against each deadline type.
;Data and Database Integrity Testing:
:Expectations:
:1. Verify all deadlines are updated in due_at field in due_dates tables for corresponding deadline types after saving the populated values.

;Functional Testing:
:Expectations:
:1. The auto populated deadline values are changed as per selected offset days from drop-down.
:2. Same should reflect in student assignment section.
;User Interface Testing:
:Expectation:
:1. The triggered change on to corresponding fields by JavaScript should be correct..
:2. The format of date auto populated should be as per current system.
;Performance Testing:
:Expectation:
:1. The response time to change the dates to other rounds should be within 5 second latency.

CSC/ECE 517 Fall 2018/E1860 Improvements to staggered deadline

2018-11-16T04:35:41Z

Mkhan8: /* Test Plan */

== Introduction ==
'''Staggered Deadline Assignment''' is an assignment which can have different topics listed under it and each of these topics have their independent submission and review deadline. Topic's deadline can be the same as parent assignment or independent to it . Such assignments are useful when the class material is more sequential and instructor wants students to complete assignment as and when a topic gets covered in the class. For example it wouldn't make sense to write a paper on a topic from Chapter 4, until the class had covered Chapter 4.

== Problem Statement ==

==== Staggered-deadline topic available for selection past its deadline====

This issue occurs when a '''Topic''' is created with multiple slots. If the topic is not selected for the first round of topics(assignment) or all the slots did not get filled up, It is still available for selection in the subsequent rounds. If a team selects the topic in a later round, they are not able to submit their work as the submission deadline is already over.
If the topic had only one slot which remained unselected, instructor can change the deadline for that topic to match the new deadlines, but for topics with multiple slots, if the deadline is extended, the teams who worked on this topic in the previous round can submit/review the topic again. This should not happen

====Manual submission and review deadline entry required for all topics====

When creating a topic an instructor is required to enter review and submission deadlines for all the topics. To reduce the manual we want to allow the instructor to apply one deadline entry to a set of topics and also let the system calculate subsequent dates for subsequent project phases like review and re-submission, based on an initial deadline entry. Instructor should also have the ability to edit each of those deadlines independently incase he wants to change a particular deadline of a topic.

====New submissions not identifiable among pool of already graded entries====

There is no way to identify new submissions or reviews are new since grading was last done. The '''Submissions''' and '''Reviews''' should appear in different color before and after they are graded. The color scheme should be compatible with the one used for review report. ie '''Red''' indicates incomplete Reviews, '''Blue''' indicates reviews that have not been graded and '''Brown''' for reviews that have grade assigned to them

== Proposed Design ==

===Issue 1===
==== Solution 1 - Prevent Students from Signing up for topics past deadline====

Students can be prevented from signing up for a topic whose submission deadline has passed. Currently this is happening, but only in case of assignments/topics which do not have staggered deadlines.

'''sign_up_sheet_controller.rb'''

<pre>
unless assignment.due_dates.find_by_deadline_type_id(1).nil?
if !assignment.staggered_deadline? and assignment.due_dates.find_by_deadline_type_id(1).due_at < Time.now
@show_actions = false
</pre>

A Similar logic can be implemented for topic where we fetch the deadline for a '''topic''' by implementing a function and then determine whether to display that topic or not. The same function could also be modified to achieve the desired results.

[[File:Issue1.jpeg]]

==== Solution 2 - Assign chronologically nearest round's deadline to the team ====

This can be achieved in the following steps:

1. Add a column in "signed_up_teams" with the name "deadline_round" to store which round of deadline applies to the team signing up and also maintain a new deadline data in the due dates db with the type as "topic" and round as "earlier round+1".

2. Add logic in sign_up_sheet_controller.rb to assign the chronologically nearest round's deadline set to the team when signing up.

This Implementation might end up being complex because of how the data is currently being stored in the DB, but is a correct solution and needs more design discussion with the professor.

[[File:Issue2.jpg]]

===Issue 2===
==== Add a new setting for Staggered Assignments ====

This can be achieved by adding a new setting to the staggered deadline assignments so that while creating the assignment an instructor can specify how much gap(days) is needed between the different rounds of submission and review.

Data will be stored in a new table and only staggered assignments will have this setting. Rationale behind not storing this data in the current '''Assignments''' is to avoid usage of space and prevent any error to the existing setup. Once we have this data, we can calculate all the deadlines for a topic once the instructor has entered the starting deadline. This will reduce a lot of manual work and this setting can be changed any time by the instructor/TA.

==== Add Dropdowns for Relative Dates ====

Changes will have to be made to the due_dates_table in the _due_dates.html.erb file. Changes have to be made to the datetime_picker_roundtype_roundnumber id. We could provide the user with a drop down menu listing a possible set of relative dates to chose from, in addition to the ability to manually enter a custom date. This could be done on the view side by modifying the date fields and adding the necessary JavaScript so that appropriate date responses are filled into the corresponding date fields when an option is chose from the dropdown menu.

=== Issue 3===
==== Add Colors to the Graded Reviews ====

Below color coding will be used to indicate the current stage of the reviews :

Red - Incomplete Review

Blue - Grade Unassigned to the Review

Brown - Review Complete/ Grade Assigned

This will be achieved by passing the colors of the reviews to _review_report.html.erb.

== Test Plan ==

'''Issue 1:'''

When a team tries to sign up for a topic that is still open but the deadline is already passed , an error should be displayed stating that the topic could not be picked as the deadlines are already passed.

'''Issue 2:'''

When the user creates/changes the deadlines of an assignment / topic, all the other dates should be automatically adjusted based on the settings of the assignment.

'''Issue 3:'''

When the Instructor/TA visits assignments page , submission/reviews which are currently active/in-process should be displayed in Red , submission/reviews which are completed but grades are not assigned should be displayed in Blue and submission/reviews which are already graded should be displayed in Brown.

CSC/ECE 517 Fall 2018/E1860 Improvements to staggered deadline

2018-11-16T04:31:35Z

Mkhan8: /* Add Colors to the Graded Reviews */

== Introduction ==
'''Staggered Deadline Assignment''' is an assignment which can have different topics listed under it and each of these topics have their independent submission and review deadline. Topic's deadline can be the same as parent assignment or independent to it . Such assignments are useful when the class material is more sequential and instructor wants students to complete assignment as and when a topic gets covered in the class. For example it wouldn't make sense to write a paper on a topic from Chapter 4, until the class had covered Chapter 4.

== Problem Statement ==

==== Staggered-deadline topic available for selection past its deadline====

This issue occurs when a '''Topic''' is created with multiple slots. If the topic is not selected for the first round of topics(assignment) or all the slots did not get filled up, It is still available for selection in the subsequent rounds. If a team selects the topic in a later round, they are not able to submit their work as the submission deadline is already over.
If the topic had only one slot which remained unselected, instructor can change the deadline for that topic to match the new deadlines, but for topics with multiple slots, if the deadline is extended, the teams who worked on this topic in the previous round can submit/review the topic again. This should not happen

====Manual submission and review deadline entry required for all topics====

When creating a topic an instructor is required to enter review and submission deadlines for all the topics. To reduce the manual we want to allow the instructor to apply one deadline entry to a set of topics and also let the system calculate subsequent dates for subsequent project phases like review and re-submission, based on an initial deadline entry. Instructor should also have the ability to edit each of those deadlines independently incase he wants to change a particular deadline of a topic.

====New submissions not identifiable among pool of already graded entries====

There is no way to identify new submissions or reviews are new since grading was last done. The '''Submissions''' and '''Reviews''' should appear in different color before and after they are graded. The color scheme should be compatible with the one used for review report. ie '''Red''' indicates incomplete Reviews, '''Blue''' indicates reviews that have not been graded and '''Brown''' for reviews that have grade assigned to them

== Proposed Design ==

===Issue 1===
==== Solution 1 - Prevent Students from Signing up for topics past deadline====

Students can be prevented from signing up for a topic whose submission deadline has passed. Currently this is happening, but only in case of assignments/topics which do not have staggered deadlines.

'''sign_up_sheet_controller.rb'''

<pre>
unless assignment.due_dates.find_by_deadline_type_id(1).nil?
if !assignment.staggered_deadline? and assignment.due_dates.find_by_deadline_type_id(1).due_at < Time.now
@show_actions = false
</pre>

A Similar logic can be implemented for topic where we fetch the deadline for a '''topic''' by implementing a function and then determine whether to display that topic or not. The same function could also be modified to achieve the desired results.

[[File:Issue1.jpeg]]

==== Solution 2 - Assign chronologically nearest round's deadline to the team ====

This can be achieved in the following steps:

1. Add a column in "signed_up_teams" with the name "deadline_round" to store which round of deadline applies to the team signing up and also maintain a new deadline data in the due dates db with the type as "topic" and round as "earlier round+1".

2. Add logic in sign_up_sheet_controller.rb to assign the chronologically nearest round's deadline set to the team when signing up.

This Implementation might end up being complex because of how the data is currently being stored in the DB, but is a correct solution and needs more design discussion with the professor.

[[File:Issue2.jpg]]

===Issue 2===
==== Add a new setting for Staggered Assignments ====

This can be achieved by adding a new setting to the staggered deadline assignments so that while creating the assignment an instructor can specify how much gap(days) is needed between the different rounds of submission and review.

Data will be stored in a new table and only staggered assignments will have this setting. Rationale behind not storing this data in the current '''Assignments''' is to avoid usage of space and prevent any error to the existing setup. Once we have this data, we can calculate all the deadlines for a topic once the instructor has entered the starting deadline. This will reduce a lot of manual work and this setting can be changed any time by the instructor/TA.

==== Add Dropdowns for Relative Dates ====

Changes will have to be made to the due_dates_table in the _due_dates.html.erb file. Changes have to be made to the datetime_picker_roundtype_roundnumber id. We could provide the user with a drop down menu listing a possible set of relative dates to chose from, in addition to the ability to manually enter a custom date. This could be done on the view side by modifying the date fields and adding the necessary JavaScript so that appropriate date responses are filled into the corresponding date fields when an option is chose from the dropdown menu.

=== Issue 3===
==== Add Colors to the Graded Reviews ====

Below color coding will be used to indicate the current stage of the reviews :

Red - Incomplete Review

Blue - Grade Unassigned to the Review

Brown - Review Complete/ Grade Assigned

This will be achieved by passing the colors of the reviews to _review_report.html.erb.

== Test Plan ==

Testing for modification of dates in staggered deadlines.

'''Issue 1:'''

When a team tries to sign up for a topic that is still open but the deadline is already passed , an error should be displayed stating that the topic could not be picked as the deadlines are already passed.

'''Issue 2:'''

When the user creates/changes the deadlines of an assignment / topic, all the other dates should be automatically adjusted based on the settings of the assignment.

'''Issue 3:'''

When the Instructor/TA visits assignments page , submission/reviews which are currently active/in-process should be displayed in Red , submission/reviews which are completed but grades are not assigned should be displayed in Blue and submission/reviews which are already graded should be displayed in Brown.

CSC/ECE 517 Fall 2018/E1860 Improvements to staggered deadline

2018-11-16T04:30:06Z

Mkhan8: /* Add a new setting for Staggered Assignments */

== Introduction ==
'''Staggered Deadline Assignment''' is an assignment which can have different topics listed under it and each of these topics have their independent submission and review deadline. Topic's deadline can be the same as parent assignment or independent to it . Such assignments are useful when the class material is more sequential and instructor wants students to complete assignment as and when a topic gets covered in the class. For example it wouldn't make sense to write a paper on a topic from Chapter 4, until the class had covered Chapter 4.

== Problem Statement ==

==== Staggered-deadline topic available for selection past its deadline====

This issue occurs when a '''Topic''' is created with multiple slots. If the topic is not selected for the first round of topics(assignment) or all the slots did not get filled up, It is still available for selection in the subsequent rounds. If a team selects the topic in a later round, they are not able to submit their work as the submission deadline is already over.
If the topic had only one slot which remained unselected, instructor can change the deadline for that topic to match the new deadlines, but for topics with multiple slots, if the deadline is extended, the teams who worked on this topic in the previous round can submit/review the topic again. This should not happen

====Manual submission and review deadline entry required for all topics====

When creating a topic an instructor is required to enter review and submission deadlines for all the topics. To reduce the manual we want to allow the instructor to apply one deadline entry to a set of topics and also let the system calculate subsequent dates for subsequent project phases like review and re-submission, based on an initial deadline entry. Instructor should also have the ability to edit each of those deadlines independently incase he wants to change a particular deadline of a topic.

====New submissions not identifiable among pool of already graded entries====

There is no way to identify new submissions or reviews are new since grading was last done. The '''Submissions''' and '''Reviews''' should appear in different color before and after they are graded. The color scheme should be compatible with the one used for review report. ie '''Red''' indicates incomplete Reviews, '''Blue''' indicates reviews that have not been graded and '''Brown''' for reviews that have grade assigned to them

== Proposed Design ==

===Issue 1===
==== Solution 1 - Prevent Students from Signing up for topics past deadline====

Students can be prevented from signing up for a topic whose submission deadline has passed. Currently this is happening, but only in case of assignments/topics which do not have staggered deadlines.

'''sign_up_sheet_controller.rb'''

<pre>
unless assignment.due_dates.find_by_deadline_type_id(1).nil?
if !assignment.staggered_deadline? and assignment.due_dates.find_by_deadline_type_id(1).due_at < Time.now
@show_actions = false
</pre>

A Similar logic can be implemented for topic where we fetch the deadline for a '''topic''' by implementing a function and then determine whether to display that topic or not. The same function could also be modified to achieve the desired results.

[[File:Issue1.jpeg]]

==== Solution 2 - Assign chronologically nearest round's deadline to the team ====

This can be achieved in the following steps:

1. Add a column in "signed_up_teams" with the name "deadline_round" to store which round of deadline applies to the team signing up and also maintain a new deadline data in the due dates db with the type as "topic" and round as "earlier round+1".

2. Add logic in sign_up_sheet_controller.rb to assign the chronologically nearest round's deadline set to the team when signing up.

This Implementation might end up being complex because of how the data is currently being stored in the DB, but is a correct solution and needs more design discussion with the professor.

[[File:Issue2.jpg]]

===Issue 2===
==== Add a new setting for Staggered Assignments ====

This can be achieved by adding a new setting to the staggered deadline assignments so that while creating the assignment an instructor can specify how much gap(days) is needed between the different rounds of submission and review.

Data will be stored in a new table and only staggered assignments will have this setting. Rationale behind not storing this data in the current '''Assignments''' is to avoid usage of space and prevent any error to the existing setup. Once we have this data, we can calculate all the deadlines for a topic once the instructor has entered the starting deadline. This will reduce a lot of manual work and this setting can be changed any time by the instructor/TA.

==== Add Dropdowns for Relative Dates ====

Changes will have to be made to the due_dates_table in the _due_dates.html.erb file. Changes have to be made to the datetime_picker_roundtype_roundnumber id. We could provide the user with a drop down menu listing a possible set of relative dates to chose from, in addition to the ability to manually enter a custom date. This could be done on the view side by modifying the date fields and adding the necessary JavaScript so that appropriate date responses are filled into the corresponding date fields when an option is chose from the dropdown menu.

=== Issue 3===
==== Add Colors to the Graded Reviews ====

Below color coding will be used to indicate the current stage of the reviews :

Red - Incomplete Review
Blue - Grade Unassigned to the Review
Brown - Review Complete/ Grade Assigned

This will be achieved by passing the colors of the reviews to _review_report.html.erb.

== Test Plan ==

Testing for modification of dates in staggered deadlines.

'''Issue 1:'''

When a team tries to sign up for a topic that is still open but the deadline is already passed , an error should be displayed stating that the topic could not be picked as the deadlines are already passed.

'''Issue 2:'''

When the user creates/changes the deadlines of an assignment / topic, all the other dates should be automatically adjusted based on the settings of the assignment.

'''Issue 3:'''

When the Instructor/TA visits assignments page , submission/reviews which are currently active/in-process should be displayed in Red , submission/reviews which are completed but grades are not assigned should be displayed in Blue and submission/reviews which are already graded should be displayed in Brown.

CSC/ECE 517 Fall 2018/E1860 Improvements to staggered deadline

2018-11-16T04:28:38Z

Mkhan8: /* Test Plan */

== Introduction ==
'''Staggered Deadline Assignment''' is an assignment which can have different topics listed under it and each of these topics have their independent submission and review deadline. Topic's deadline can be the same as parent assignment or independent to it . Such assignments are useful when the class material is more sequential and instructor wants students to complete assignment as and when a topic gets covered in the class. For example it wouldn't make sense to write a paper on a topic from Chapter 4, until the class had covered Chapter 4.

== Problem Statement ==

==== Staggered-deadline topic available for selection past its deadline====

This issue occurs when a '''Topic''' is created with multiple slots. If the topic is not selected for the first round of topics(assignment) or all the slots did not get filled up, It is still available for selection in the subsequent rounds. If a team selects the topic in a later round, they are not able to submit their work as the submission deadline is already over.
If the topic had only one slot which remained unselected, instructor can change the deadline for that topic to match the new deadlines, but for topics with multiple slots, if the deadline is extended, the teams who worked on this topic in the previous round can submit/review the topic again. This should not happen

====Manual submission and review deadline entry required for all topics====

When creating a topic an instructor is required to enter review and submission deadlines for all the topics. To reduce the manual we want to allow the instructor to apply one deadline entry to a set of topics and also let the system calculate subsequent dates for subsequent project phases like review and re-submission, based on an initial deadline entry. Instructor should also have the ability to edit each of those deadlines independently incase he wants to change a particular deadline of a topic.

====New submissions not identifiable among pool of already graded entries====

There is no way to identify new submissions or reviews are new since grading was last done. The '''Submissions''' and '''Reviews''' should appear in different color before and after they are graded. The color scheme should be compatible with the one used for review report. ie '''Red''' indicates incomplete Reviews, '''Blue''' indicates reviews that have not been graded and '''Brown''' for reviews that have grade assigned to them

== Proposed Design ==

===Issue 1===
==== Solution 1 - Prevent Students from Signing up for topics past deadline====

Students can be prevented from signing up for a topic whose submission deadline has passed. Currently this is happening, but only in case of assignments/topics which do not have staggered deadlines.

'''sign_up_sheet_controller.rb'''

<pre>
unless assignment.due_dates.find_by_deadline_type_id(1).nil?
if !assignment.staggered_deadline? and assignment.due_dates.find_by_deadline_type_id(1).due_at < Time.now
@show_actions = false
</pre>

A Similar logic can be implemented for topic where we fetch the deadline for a '''topic''' by implementing a function and then determine whether to display that topic or not. The same function could also be modified to achieve the desired results.

[[File:Issue1.jpeg]]

==== Solution 2 - Assign chronologically nearest round's deadline to the team ====

This can be achieved in the following steps:

1. Add a column in "signed_up_teams" with the name "deadline_round" to store which round of deadline applies to the team signing up and also maintain a new deadline data in the due dates db with the type as "topic" and round as "earlier round+1".

2. Add logic in sign_up_sheet_controller.rb to assign the chronologically nearest round's deadline set to the team when signing up.

This Implementation might end up being complex because of how the data is currently being stored in the DB, but is a correct solution and needs more design discussion with the professor.

[[File:Issue2.jpg]]

===Issue 2===
==== Add a new setting for Staggered Assignments ====

This can be achieved by adding a new setting to the staggered deadline assingments so that while creating the assignment an instructor can specify how much gap(days) is needed between the different rounds of submission and review.
Data will be stored in a new table and only staggered assingments will have this setting. Rationale behind not storing this data in the current '''Assignments''' is to avoid usage of space and prevent any error to the existing setup. Once we have this data, we can calculate all the deadlines for a topic once the instructor has entered the starting deadline. This is reduce a lot of manual work and this setting can be changed any time by the instructor.

==== Add Dropdowns for Relative Dates ====

Changes will have to be made to the due_dates_table in the _due_dates.html.erb file. Changes have to be made to the datetime_picker_roundtype_roundnumber id. We could provide the user with a drop down menu listing a possible set of relative dates to chose from, in addition to the ability to manually enter a custom date. This could be done on the view side by modifying the date fields and adding the necessary JavaScript so that appropriate date responses are filled into the corresponding date fields when an option is chose from the dropdown menu.

=== Issue 3===
==== Add Colors to the Graded Reviews ====

Below color coding will be used to indicate the current stage of the reviews :

Red - Incomplete Review
Blue - Grade Unassigned to the Review
Brown - Review Complete/ Grade Assigned

This will be achieved by passing the colors of the reviews to _review_report.html.erb.

== Test Plan ==

Testing for modification of dates in staggered deadlines.

'''Issue 1:'''

When a team tries to sign up for a topic that is still open but the deadline is already passed , an error should be displayed stating that the topic could not be picked as the deadlines are already passed.

'''Issue 2:'''

When the user creates/changes the deadlines of an assignment / topic, all the other dates should be automatically adjusted based on the settings of the assignment.

'''Issue 3:'''

When the Instructor/TA visits assignments page , submission/reviews which are currently active/in-process should be displayed in Red , submission/reviews which are completed but grades are not assigned should be displayed in Blue and submission/reviews which are already graded should be displayed in Brown.

CSC/ECE 517 Fall 2018/E1860 Improvements to staggered deadline

2018-11-16T04:28:12Z

Mkhan8: /* Test Plan */

== Introduction ==
'''Staggered Deadline Assignment''' is an assignment which can have different topics listed under it and each of these topics have their independent submission and review deadline. Topic's deadline can be the same as parent assignment or independent to it . Such assignments are useful when the class material is more sequential and instructor wants students to complete assignment as and when a topic gets covered in the class. For example it wouldn't make sense to write a paper on a topic from Chapter 4, until the class had covered Chapter 4.

== Problem Statement ==

==== Staggered-deadline topic available for selection past its deadline====

This issue occurs when a '''Topic''' is created with multiple slots. If the topic is not selected for the first round of topics(assignment) or all the slots did not get filled up, It is still available for selection in the subsequent rounds. If a team selects the topic in a later round, they are not able to submit their work as the submission deadline is already over.
If the topic had only one slot which remained unselected, instructor can change the deadline for that topic to match the new deadlines, but for topics with multiple slots, if the deadline is extended, the teams who worked on this topic in the previous round can submit/review the topic again. This should not happen

====Manual submission and review deadline entry required for all topics====

When creating a topic an instructor is required to enter review and submission deadlines for all the topics. To reduce the manual we want to allow the instructor to apply one deadline entry to a set of topics and also let the system calculate subsequent dates for subsequent project phases like review and re-submission, based on an initial deadline entry. Instructor should also have the ability to edit each of those deadlines independently incase he wants to change a particular deadline of a topic.

====New submissions not identifiable among pool of already graded entries====

There is no way to identify new submissions or reviews are new since grading was last done. The '''Submissions''' and '''Reviews''' should appear in different color before and after they are graded. The color scheme should be compatible with the one used for review report. ie '''Red''' indicates incomplete Reviews, '''Blue''' indicates reviews that have not been graded and '''Brown''' for reviews that have grade assigned to them

== Proposed Design ==

===Issue 1===
==== Solution 1 - Prevent Students from Signing up for topics past deadline====

Students can be prevented from signing up for a topic whose submission deadline has passed. Currently this is happening, but only in case of assignments/topics which do not have staggered deadlines.

'''sign_up_sheet_controller.rb'''

<pre>
unless assignment.due_dates.find_by_deadline_type_id(1).nil?
if !assignment.staggered_deadline? and assignment.due_dates.find_by_deadline_type_id(1).due_at < Time.now
@show_actions = false
</pre>

A Similar logic can be implemented for topic where we fetch the deadline for a '''topic''' by implementing a function and then determine whether to display that topic or not. The same function could also be modified to achieve the desired results.

[[File:Issue1.jpeg]]

==== Solution 2 - Assign chronologically nearest round's deadline to the team ====

This can be achieved in the following steps:

1. Add a column in "signed_up_teams" with the name "deadline_round" to store which round of deadline applies to the team signing up and also maintain a new deadline data in the due dates db with the type as "topic" and round as "earlier round+1".

2. Add logic in sign_up_sheet_controller.rb to assign the chronologically nearest round's deadline set to the team when signing up.

This Implementation might end up being complex because of how the data is currently being stored in the DB, but is a correct solution and needs more design discussion with the professor.

[[File:Issue2.jpg]]

===Issue 2===
==== Add a new setting for Staggered Assignments ====

This can be achieved by adding a new setting to the staggered deadline assingments so that while creating the assignment an instructor can specify how much gap(days) is needed between the different rounds of submission and review.
Data will be stored in a new table and only staggered assingments will have this setting. Rationale behind not storing this data in the current '''Assignments''' is to avoid usage of space and prevent any error to the existing setup. Once we have this data, we can calculate all the deadlines for a topic once the instructor has entered the starting deadline. This is reduce a lot of manual work and this setting can be changed any time by the instructor.

==== Add Dropdowns for Relative Dates ====

Changes will have to be made to the due_dates_table in the _due_dates.html.erb file. Changes have to be made to the datetime_picker_roundtype_roundnumber id. We could provide the user with a drop down menu listing a possible set of relative dates to chose from, in addition to the ability to manually enter a custom date. This could be done on the view side by modifying the date fields and adding the necessary JavaScript so that appropriate date responses are filled into the corresponding date fields when an option is chose from the dropdown menu.

=== Issue 3===
==== Add Colors to the Graded Reviews ====

Below color coding will be used to indicate the current stage of the reviews :

Red - Incomplete Review
Blue - Grade Unassigned to the Review
Brown - Review Complete/ Grade Assigned

This will be achieved by passing the colors of the reviews to _review_report.html.erb.

== Test Plan ==

Testing for modification of dates in staggered deadlines.

Issue 1:

When a team tries to sign up for a topic that is still open but the deadline is already passed , an error should be displayed stating that the topic could not be picked as the deadlines are already passed.

Issue 2: When the user craetes/changes the deadlines of an assignment / topic, all the other dates should be automatically adjusted based on the settings of the assignment.

Issue 3: When the Instructor/TA visits assignments page , submission/reviews which are currently active/in-process should be displayed in Red , submission/reviews which are completed but grades are not assigned should be displayed in Blue and submission/reviews which are already graded should be displayed in Brown.

CSC/ECE 517 Fall 2018/E1860 Improvements to staggered deadline

2018-11-16T04:19:29Z

Mkhan8: /* issue 3 */

CSC/ECE 517 Fall 2018/E1860 Improvements to staggered deadline

2018-11-16T04:17:41Z

Mkhan8:

File:Issue2.jpg

2018-11-16T04:16:10Z

Mkhan8: uploaded a new version of "File:Issue2.jpg"

File:Issue2.jpg

2018-11-16T04:15:24Z

Mkhan8: uploaded a new version of "File:Issue2.jpg"

CSC/ECE 517 Fall 2018/E1860 Improvements to staggered deadline

2018-11-16T04:14:15Z

Mkhan8: /* Solution 2 - Assign chronologically nearest round's deadline to the team */

File:Issue2.jpg

2018-11-16T04:14:01Z

Mkhan8:

File:Issue1.jpeg

2018-11-16T04:02:38Z

Mkhan8:

CSC/ECE 517 Fall 2018/E1860 Improvements to staggered deadline

2018-11-16T04:02:02Z

Mkhan8: /* Solution 1 - Prevent Students from Signing up for topics past deadline */

File:Issue1.jpg

2018-11-16T04:01:33Z

Mkhan8:

File:Issue10.PNG

2018-11-16T03:58:33Z

Mkhan8:

File:Issue1.png

2018-11-16T03:56:48Z

Mkhan8:

CSC/ECE 517 Fall 2018/E1860 Improvements to staggered deadline

2018-11-16T03:56:33Z

Mkhan8: /* Solution 1 - Prevent Students from Signing up for topics past deadline */

File:Issue 1860 1.PNG

2018-11-16T03:54:59Z

Mkhan8:

File:Issue1.PNG

2018-11-16T03:52:58Z

Mkhan8: uploaded a new version of "File:Issue1.PNG"

File:Issue1.PNG

2018-11-16T03:52:32Z

Mkhan8: uploaded a new version of "File:Issue1.PNG"

File:Issue1.PNG

2018-11-16T03:52:01Z

Mkhan8:

CSC/ECE 517 Fall 2018/E1860 Improvements to staggered deadline

2018-11-16T03:51:38Z

Mkhan8: /* Solution 1 - Prevent Students from Signing up for topics past deadline */

CSC/ECE 517 Fall 2018/E1860 Improvements to staggered deadline

2018-11-16T03:45:19Z

Mkhan8: /* Solution 1 - Prevent Students from Signing up for topics past deadline */