This week's book giveaway is in the Agile and Other Processes forum.
We're giving away four copies of The Little Book of Impediments (e-book only) and have Tom Perry on-line!
See this thread for details.
Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Assignment Question

 
Sean Walker
Ranch Hand
Posts: 64
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The 'Change Itinerary' use case ends saying that it continues with the 'Prepare Itinerary' use case. How could this be? The Prepare Itinerary use case begins with search criteria for a destination/return location dates.

The only way I can interpret this is that it means the prepare Itinerary use case is rerun but constrained to apply only to the deleted segement's locations and date/times. IMHO, this appears to me to be a bad use case definition!
Could someone advise me whether I should feel comfortable making this assumption or not?
 
patrick jiang
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As I know, after the customer delete his flight. He may want to buy another flight. So, he go to the Prepare Itinerary use case.
 
Sean Walker
Ranch Hand
Posts: 64
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, sort of. The user can delete a segment, not a flight. But when you delete one segment of an overall itinerary, you still may have many others right? So I believe there is now a constraint which exists that is not present in the Prepare Itinerary use case. And yet, as documented, you are supposed to continue with the Prepare Itinerary use case.
Could someone please clarify this?
-----------
As an aside. I don't believe that part of the role of an architect is supposed to be creatively 'interpreting' a set of requirements. Pretty much every modern SDLC methology strictly emphasizes that requirements should be articulated and elaborated by the customer. SO forgive my evident frustration when I ask - what the hell was Sun thinking when they came up with this vague set of requirements for the SCEA assignemnt? IMHO I really don't think they thaoght this through very well. What's more, I'm feeling a little like some animal jumping through hoops in order to get my professional bone (ie the certifcation).
I shouldn't be surprised I guess. I recently passed the PMP exam and it was pretty much the same thing. Although, the SCEA-I exam wasn't like this at all - go figure...
 
Sridhar Raman
Ranch Hand
Posts: 142
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Sean,
I agree that some of the requirements are vague and appear to be wrong at places. I had the same question about change itinerary sending control to the Prepare Itinerary Use Case. ( I haven't resolved it yet ). If you think that there should be some additional processing done prior to sending control to the Prepare Itinerary use case, I don't see why you can't incorporate such a flow in your architecture model and document your design decision.
Yes, I agree that Sun MS could have done a better job of specifying the requirements. Having said this, I feel that there would always exist some sort of a confusion about the requirements even when specified in a detailed manner and this is an inherent limitation of such examinations. That is why Sun MS expects us make assumptions, not because it is meant to be a reflection of the real-world scenario. Besides, the certification guidelines say that unless a requirement is explicitly stated, the architecture is not awarded points for what it realizes but how it realizes the given set of requirements.

Regards
Sridhar
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic