[Cs5500] Urgent SCG Court Maintenance task

[Madhuvanthi Balasubramanian]

Professor,

         Yes, this should work. As you say, the scholarID is also required,
to deal with repeatable welfare claims.  But at this point, I'm not sure how
big a change, adding a scholarID is . We may want to assign scholar ID's to
players as they sign up (does this mean every PlayerProxy class should also
have a scholarID field? ) , and claimID's to claims when they are proposed.

On Wed, Oct 19, 2011 at 10:57 PM, Karl Lieberherr <lieber at ccs.neu.edu>wrote:

> 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
> >
>



-- 
 Thanks
- Madhu
-------------- next part --------------
HTML attachment scrubbed and removed