Re: [osera-isp-dev] bricks use case descriptions
Brought to you by:
reddyenugu,
ryen
Menu
▾
▴
Re: [osera-isp-dev] bricks use case descriptions
|
From: Irene P. <ir...@to...> - 2008-05-14 03:34:17
|
<Would you be able to talk some tomorrow about what we mean when we say one policy supersedes another> I can talk about my understanding of it. I understand superseding as an act of a decision about a use of technology at GSA becoming outdated. Let's say IE 6.0 was an approved standard, then a new decision was made that IE 6.0 is in containment starting this month and IE 7.0 is now an approved standard. These are 3 policy decisions. "IE 6.0 is an approved standard" is being superseded or becomes outdated. The notion of one policy superseding another one is not as clear to me. For example, we could say that 2 policies (IE 6.0 is in containment starting this month and IE 7.0 is an approved standard) now replace the original one (IE 6.0 is an approved standard) or we could say that only one of them replaces the original one. Often, there would be a change of status - something that was approved becomes in containment, something that was a tactical strategy becomes approved, something that was in containment becomes retired, etc. I believe the view use case diagrams may have took was that a policy decision gets superseded by another decision about the same product, so in this example "IE 6.0 is an approved standard" is superseded by " 6.0 is in containment starting this month". On the other hand, it is possible for a policy decision to become outdated without us creating another decision about the product in question. For example, product X was listed as a strategic direction, then we decided that it was no longer the case. There are no new decisions about product X, it just got deleted and is no longer mentioned any place. When we do this, we could, at the same time, add another product as a strategic direction. Would this mean that a decision about giving another product the same status as the status of product X, supersedes the policy about product X? If so, does it mean that potentially one or 2 policies (or may be even more) could supersede a previously existing policy and therefore, "IE 6.0 is in containment starting this month" and "IE 7.0 is an approved standard" superseded "IE 6.0 is an approved standard"? The only constraint is that a superseding policy has to be either about the same product or have to give another product the same status. Finally, we could have just removed product X and done nothing else, so a decision can be superseded without putting in place a new one. I do not believe we teased it out to the extent I am doing it here and I don't believe there is currently a model supporting the concept of superseding, although may be Cory has done something in the shared concepts I am not aware of as part of his work on the effectivity. It is also possible that Cory have a design in mind where a decision gets superseded by a negating statement, so "IE 6.0 is an approved standard" gets superceded by "IE 6.0 is NOT an approved standard" Irene Polikoff Executive Partner, TopQuadrant tel: 914-777-0888/ cell: 914-329-8576 www.topquadrant.com <http://www.topquadrant.com/> _____ From: ric...@gs... [mailto:ric...@gs...] Sent: Tuesday, May 13, 2008 11:01 PM To: ir...@to... Cc: ose...@li...; ed...@mo...; 'Walt Melo'; cli...@gs... Subject: RE: [osera-isp-dev] bricks use case descriptions Sounds good with me, how about you Ed ? BTW - Would you be able to talk some tomorrow about what we mean when we say one policy supercedes another ? Best wishes, Rick office: 202-501-9199 cell: 202-557-1604 -----"Irene Polikoff" <ir...@to...> wrote: ----- To: ric...@gs..., ose...@li..., ed...@mo... From: "Irene Polikoff" <ir...@to...> Date: 05/13/2008 10:53PM cc: "'Walt Melo'" <wa...@mo...>, cli...@gs... Subject: RE: [osera-isp-dev] bricks use case descriptions I asked Jim about this in the past. He said he originally wanted to have this use case, but then decided it was not needed (or it was too premature to define one). I think deleting it is the right thing to do. Irene Polikoff Executive Partner, TopQuadrant tel: 914-777-0888/ cell: 914-329-8576 www.topquadrant.com <http://www.topquadrant.com/> _____ From: ric...@gs... [mailto:ric...@gs...] Sent: Tuesday, May 13, 2008 10:39 PM To: ose...@li...; ed...@mo... Cc: Walt Melo; cli...@gs... Subject: Re: [osera-isp-dev] bricks use case descriptions Ed, I think you may not have the right understanding of my request. Someone, I'm guessing Jim, partially defined a use case called ValidateTechnologyPolicy and put it in the model. There's an empty use case and a blank diagram. I never asked anyone to put this use case in the model in the first place. But what I don't think anyone wants is a model that creates the impression we're sloppy. Maybe the smart thing is to have me take it out for you. I'll do that for free ! Lemme' know ... Best wishes, Rick office: 202-501-9199 cell: 202-557-1604 -----"Ed Harrington" <ed...@mo...> wrote: ----- To: ric...@gs..., ose...@li... From: "Ed Harrington" <ed...@mo...> Date: 05/13/2008 10:22PM cc: "Walt Melo" <wa...@mo...>, cli...@gs... Subject: RE: [osera-isp-dev] bricks use case descriptions Rick: A very simple reminder: we were only required to develop "Add" and "Update" use case descriptions and use case models. Anything beyond that - and we have delivered a lot more - is gravy. "Validate Technology Policy" IMHO appears to be outside the scope of our capabilities or capacity. I would think that a validated Technical Policy would need to be in place and would be reflected in the choices that were made in the process. Also, I thought that we had discussed, early on in our discussions, that we were NOT to build an application (based on use cases) that would be part of the decision process.our Bricks application, as reflected in our understanding of the SOW and as we submitted our (accepted) proposal, was to only reflect decisions that had been already made. I submit that your request is out of scope for the current requirements. We will be happy to consider it, but it will require additional funding. If appropriate, I'll submit this to the CO. Regards, Ed Harrington Mobile: +1.757.342.4552 email: <mailto:ed...@mo...> ed...@mo... <http://www.modeldriven.com> www.modeldriven.com Disclaimer: Privileged or Confidential information may be contained in this message or with any files transferred with it. If you are not the intended recipient, kindly destroy this message and notify the sender by return mail. Opinions, conclusions and other information included in this message that do not relate to the official business of Model Driven Solutions are neither given nor endorsed by it. From: ose...@li... [mailto:ose...@li...] On Behalf Of ric...@gs... Sent: Tuesday, May 13, 2008 9:35 PM To: ose...@li... Cc: Walt Melo Subject: [osera-isp-dev] bricks use case descriptions Jim, Irene, Rob or Reddy: I have entered the use case descriptions in MagicDraw. Just two things: 1. The Bricks PIM in subversion is missing the ValidateTechnologyPolicy use case including the model and the diagram. Also, there's no description in the use case document. Jim, would you mind updating the model and diagram ? Irene, I assume you're writing the descriptions. Just a heads up, I have checked out the BricksPIM from subversion, so we'll have to synchronize. 2. Rob: Would you mind setting me ( rmurphy ) up with write permissions so I can commit. Jim, I'll let you know when I get my commit permissions. If I get them early tomorrow, I may be able to execute my commit before you make any mods. Sorry for the short notice, but I'll be presenting the bricks use cases to the ITAPC Thursday, so we'll come off better if we're done by then. Best wishes, Rick office: 202-501-9199 cell: 202-557-1604 |
