[Cs5500] Urgent SCG Court Maintenance task

[Karl Lieberherr]

Hi Madhu:

The Claim class:

Claim =  <instanceSetWrapper> RWrap(InstanceSetI) <protocolWrapper>
RWrap(ProtocolI) <quality> double *s <confidence> double.

does not store information about which claim it is (ClaimId)
nor information about the proposer of the claim.
When we print two repeated claims in the game history,
they will look the same. A claimId will make them distinguishable.

Once we make the welfare set opposable, we will need to know
for each claim who proposed it.

The proposal is to extend Claim with two new fields:

Claim =  <instanceSetWrapper> RWrap(InstanceSetI) <protocolWrapper>
RWrap(ProtocolI) <quality> double *s <confidence> double <claimId>
ClaimId
<proposer> ScholarId.

We need both fields because it is possible that the same player
repeats the same claim and we have a protocol interpreter object
for each simultaneously.

Are those good changes to the structure?

-- Karl


On Wed, Oct 19, 2011 at 12:20 PM, Madhuvanthi Balasubramanian
<balasubramanian.m at husky.neu.edu> wrote:
> Professor,
>          Here is the analysis document for this change request.
>          Please let us know what you think.
>
> On Wed, Oct 19, 2011 at 10:19 AM, Karl Lieberherr <lieber at ccs.neu.edu>
> wrote:
>>
>> Hi Madhu:
>>
>> thank you for proposing this process. It looks good to me: it is like
>> a mini-waterfall process adapted to a maintenance task of SCG Court
>> and to your way of working on the fourth floor.
>> And it encourages everybody to develop their estimation skills.
>>
>> I recommend that you apply this process. Call me in when you need advice.
>>
>> -- Karl
>>
>> On Wed, Oct 19, 2011 at 9:58 AM, Madhuvanthi Balasubramanian
>> <balasubramanian.m at husky.neu.edu> wrote:
>> > Hello everyone,
>> >            Here is what I propose, for our maintenance task. Since we
>> > are
>> > already in the maintenance phase, this process aims to keep it simple,
>> > while
>> > making sure we don't miss out on the important tasks :
>> > Requirement Analysis:
>> > Impact Analysis ( Analyze what happens when ProposedClaimMustBeNew to
>> > false)
>> > Documentation of results
>> > Feasibility Study (Is it possible to implement this change, without
>> > significant change of behavior in the system? )
>> > Change Proposal (what you think must be changed, in order for the system
>> > to
>> > work as expected? )
>> > Include design team in your meetings
>> > Design:
>> > Details of classes(if any) that need to be changed
>> > The new configuration file
>> > Meet with development team and discuss if these changes are feasible
>> > Development:
>> > Propose estimated time of completion (how long you would take to make
>> > this
>> > change)
>> > Make changes in the required classes
>> > Include detailed documentation in classes
>> > Report back to design team if you encounter issues
>> > Testing:
>> > Propose estimated time of completion ( how long you would take to test)
>> > Perform regression testing
>> > Run a series of tournaments, in both MMG and HSR to make sure the system
>> > behaves as expected.
>> > I had looked into this issue in little detail last week. So I'm ready to
>> > do
>> > the requirement analysis with teamNavi and share the impact &
>> > feasibility
>> > analysis results with the rest of the teams.
>> > Please let me know if there are any issues with this process, or if this
>> > can
>> > be done better.
>> > On Wed, Oct 19, 2011 at 5:11 AM, Karl Lieberherr <lieber at ccs.neu.edu>
>> > wrote:
>> >>
>> >> We have an urgent task: we need to allow repetition in MMG and BFS.
>> >> Otherwise, those playgrounds don't work well.
>> >> This task is overdue, because MMG and BFS were due on Monday Oct. 17.
>> >> Please can the managers (Sandeep with Madhu, the outgoing SCG Court
>> >> manager ) assign responsibilities to the teams to get this done asap.
>> >> Madhu has been thinking about a simple process that we should
>> >> follow for such maintenance tasks. Please can she share it with the
>> >> class.
>> >>
>> >> Reasons/Rationale for maintenance are here:
>> >>
>> >>
>> >> http://www.ccs.neu.edu/home/lieber/courses/se-courses/cs5500/f11/maintenance/game-repair/repeating-claims
>> >>
>> >> -- Karl
>> >>
>> >> _______________________________________________
>> >> Cs5500 mailing list
>> >> Cs5500 at lists.ccs.neu.edu
>> >> https://lists.ccs.neu.edu/bin/listinfo/cs5500
>> >
>> >
>> >
>> > --
>> >  Thanks
>> > - Madhu
>> >
>
>
>
> --
>  Thanks
> - Madhu
>