Talk:Second Life Grid Glossary

• The title needs changing to something less specific, like "Glossary", because Viewer is certainly not a component of a grid. --Morgaine Dinova 09:29, 25 September 2007 (PDT)

• Added Services and Utilities to the list -- Zha Ewry 9/26/2007

• I didn't want to define these since they reference the Linden "implementation" but it would be good to define what is meant by "Central Utilities" and Identity, location, and currency.--Burhop Piccard 17:55, 3 October 2007 (PDT)

• I've added a couple of words that have taken hold in our discussions about defining requirements through the means of Viewpoint Advocacy Groups/Tasks/etc. This fits in nicely with the spirit of IEEE-1471 which seeks to be advisary and not prescriptive. --Morgaine Dinova 01:24, 12 October 2007 (PDT)

References

• Added section with 3 external links to IEEE-1471 resources.
• This stemmed from today's AWGroupies discussion which highlighted the misunderstandings that exist between developers (SLdev was mentioned) when discussing their somewhat different ideas using inconsistent terminology. The end result isn't helpful, causes friction, and ultimately is just a waste of time. IEEE-1471 can be quite helpful even if used only conversationally. --Morgaine Dinova

• As an example, the client/server divide often causes communication difficulties:

Client guy: "I want X in the server."

Server guy: "That's actually a client issue, I'm not interested."

IEEE-1471 acts against this communication breakdown. It tells the Server guy to answer:

Server guy: "The system needs to satisfy multiple stakeholders, please detail the viewpoint that you need satisfied."

However, this is *NOT* a copout or brushoff by the Server guy, because he is then obligated to deliver a view that shows the design to be conformant with the expressed viewpoint, with 1:1 traceability. If he cannot show early conformance within such a view, he cannot claim to be engaged in satisfying the requirements of that stakeholder. Then his brushoff is in the open.

This is designed to keep stakeholders happy while at the same time giving designers (who are also stakeholders) a relatively stable and consistent set of goals, and to deliver an appropriate system, not just some random thing that popped out of the designer's head. :-) --Morgaine Dinova 06:04, 10 October 2007 (PDT)

• It's worth pointing out that this has nothing at all to do with development methodologies. It applies just as much to traditional methodologies as it does in eXtreme Programming, or indeed even when there is just a single developer. The only thing that it assumes is that the developer(s) wish to satisfy the concerns of the parties affected. It helps to assure that and to provide a purpose and a lightweight structure for architectural documentation. --Morgaine Dinova 10:04, 10 October 2007 (PDT)

• Section renamed from Helping system designers speak a common language. --Morgaine Dinova

• Page renaming

As has been discussed on various occasions in AWGroupies and elsewhere, the parent page Components and Roles has evolved, and as a result it is no longer named appropriately. I would change it to one of the names that have been suggested (eg. AWG_Glossary) if I knew how to migrate its namespace tree as a unit, ie. including Talk, history etc, but I don't know how to do that. Anyone? --Morgaine Dinova 02:32, 12 October 2007 (PDT)