• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

oops question

 
Ranch Hand
Posts: 80
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
When using OOAD artifacts to organize and assign team responsibilities on a project, it is BEST to:

a) evenly distribute use cases among team members and have them work as independently as possible in order to minimize code dependencies

b) designate one team for implementing interaction diagrams related to the "common code path" and another team for implementing interaction diagrams related to "code path variations" (for example ? conditional or error paths)

c) divide teams according to package diagram dependencies and utilize use cases to schedule the work for the individual team members

d) divide teams according to the layers in the software architecture and have them work as independently as possible in order to minimize dependencies between the layers}

 
Ranch Hand
Posts: 93
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Use cases are typically arranged by priority, and are used to plan iterations. Therefore you would never distribute them evenly among team members. So A is wrong.
The same goes for B. Your teams should be focused on iterations which are driven by use cases. So you would not have one team implement a common code path. In fact, in a distributed system I'm not really sure what they mean by a common code path. Having other teams implement the error paths is ludicrous.
C is interesting, because you should actually use use cases to schedule the work. Having teams organized according to package dependencies also makes sense.
While D is often what happens in a project because of the skills or interests of the developers, it is probably not as good an answer as C. Here again is the statement, "work as independently as possible in order to minimize dependencies". Well, dependencies exist no matter what.
dan'l
 
reply
    Bookmark Topic Watch Topic
  • New Topic