Please turn in complete packages printed out on paper. You are also
required to put up the documents tomorrow and complete all document
preparation. Please do not hand in incomplete packages as we will not
accept partial work. Put up your LCO artifacts on the web by this evening.
The grading criteria for LCO packages and ARB has been posted on the class page. Team presentations would be graded 10 points. ARB presentations should be given to LaDonna Pierce in SAL 326 before the presentation, so that she can run copies.
Weekly Questionnaire due today.
You can use the WinWin tool to complete your negotiations and change some of the artifacts. In case you do that, you can get upto 10 extra credit points.
The guidelines would be updated at the end of the LCO reviews and it
is likely to affect the presentation of your documents slightly based on
the feedback obtained from students and the packages. Be prepared to rework
some of the documents
Q. > I had a question - in the sections like the project milestones
and also
> specifically, section 4.7 Status Monitoring and Control- what kind
of
> charts are u expecting at the LCO stage- is it OK to mention their
use
> later and include them for the LCA stage- do let me know
Status monitoring and control section describes how you are planning
to perform
it. That is usually in the form of status reports. Describe the form
of status
reports you are preparing in there. It does not require charts per
se. Milestone
charts are required in the LCO package as well as in the LCA package.
Right now
you can provide an overall schedule/milestone plan with entire life
cycle (577b
and beyond) coverage. The idea is to know how long is the life cycle
and what are
the major chunks.
Q. > Is is ok if we include a reference to our team website in an appendix.
> Specifically, I am looking to avoid including the entire results
of our
> WinWin negotiations at the end of my FRD document. Thanks,
That should be fine. In case you update your negotiations in the future,
then you would have to provide teh entire negotitaions again.
Q. > The Development Organization chart is supposed to show the realtionship
> team members only or also supposed to include the relation with the
> client- the university bookstore in our case. Thanks
The client should not be included as a customer in this chart. If the
project has
additional personnel from the book store who are going to be assigned
any
development responsibilities, then you can include them. I do not see
how anyone
from bookstore would fit there. Winsor Brown can be considered in your
development hierarchy.
Q. > I have some confusions regarding which Semester's Phase milestones
should
> be included in the section 2.2 of LCP. Should we write both semester's
> milestones?
Yes. Consider both semesters.
> Q. I had a question- is it important at this point of time to mention
> post-LCA milestones- given the scope of the document we are producing-
I'd
> think that is something that would be added to the LCP incrementally.
A. You have to consider the entire life cycle including construction
and
transition while doing the LCP. AT this time, you do not require details
for
the later phases, but an overall strategy has to be identified. If
there is no
info on whether support is needed in terms of capability expansion
or
maintenance, or data entry then the LCP would not be complete
Q. I'm not sure I can make the distinction between the stakeholder's
responsibilities' engineering stage and the development responsibilities.
A. Engineering stage stakeholders other than developers include the
client,
facilities and maintenance people. The development responsibilities
are for
the team members.
Q. I have been looking at the previous year's projects for the LCP.
Some of
them had given a detailed budget using COCOMO. For eg: ARIEL To Web
Document Delivery (project #17), World War I - Access Enhancement (Project
#13) etc. There were others who just gave a very brief account without
using any of the tools. For eg: Hispanic Digital Archive (project #5),
Asian Film Database (project #3) etc. And there were still others who
ignored this section saying that it would be covered during LCA.
I am not sure which approach has to be followed for the LCO (detailed
budget-using COCOMO or just a brief description). Could you please
guide
me through this?
A. The level of detail in your COCOMO estimate would directly depend
on the
current state of the architecture. If you have identified the programming
to
be done for the project, use the sizes to make an estimate. At any
cost, you
are required to provide COCOMO estimates, failing which points would
be
deducted.
Micorsoft Project can be used to create the Gantt charts and the Pert
charts.
If you are unable to use the tool from the SCF facilities, then you
would have
to create them using a simpler drawing tool.
Q. I studied the LCP document of the Hispanic Digital Archive
project. Under
the 2.1 Overall Life Cycle Strategy, you had described the construction
phase in great detail. And in 2.2 Phase Milestones and Schedules, you
had
also given a construction schedule for different functionalities to
be
developed in the project. Are we supposed to go in this much detail?
After
going through the guidelines for MBASE
project deliverables, I get a feeling that we need to give a broad
view of
the strategy as well as the milestones and schedules.
A. You are not expected to have a detailed breakdown of the construction
schedule
at this stage. You should however provide an overall life cycle strategy.
Q. > Secondly, I have a question on Evolution Requirements. Are
the Interface and
> Technology evolution requirements dependent upon the Capability evolution
> requriements?
>
> For example, one of the capability that can be implemented in the
system we
> are developing is storage of search results. Implementation
of this
> capability will have interface and technology requirements.
Do I have to
> discuss these requirements as well, under the Interface and Technology
> Evolution Requirements?
Interface and evolution requirements are tightly linked to each other.
Even
though you would not be implementing your evolution requirements, events
can
sometime force you to rethink plans. At such times it is useful to
have
documented the evolutionary requirements. They are also useful to other
developers who pick up where you leave.
Q. > My thoughts on this are that future capabilities are not guaranteed
to be
> implemented so they should have no influence over Interface and
> technology evolution requirements. But I just wanted to know
your thought
> on this issue.
In general, explain what are the tech evolutionary requirements rather
than
those specific to a particular capability.
Q. Do we need to have a use case diagram for all the system requirnments???
I have a requirnement - the system should be scalable ....in this case
it
would not be possible to draw a use case diagram.
Scalability is not a system requirement. It is a level of service requirement. Only system requirements are captured as use cases.
Q. In the SSRD document section 3.2.1.1 (Nominal Requirements) do we
need
to put in anything in the Mainstream Scenario, Proposed Activity and
Exception handling Scenario. According to the template this needs
to
be a reference to the OCD, but the new template of the OCD has no such
thing. What do we do in this case.
The Mainstream scenario should be linked to the Proposed interaction in OCD, the proposed activity to the relevant activity in OCD. Leave the Exception handling scenario empty for now.
Q. I've been using the SSRD template that was on the web that I found
in the
EPG. I guess it was for last year. I noticed that we got
dinged in the
SSAD for doing so. Is using this template the right thing to
do for the
SSRD? If not what should I be using? What sort of Rose
diagrams besides a
the block diagram should I be using. I've been using the HDA
as an
example. What sort of deviations from that must I follow?
A. Look at the presentation I gave for the SSRD in class. That identifies all the variations from the last year. You would require the same diagrams including use case diagrams, except that use UML everywhere possible. Do not use any other drawing tool.
As for the template, if you went to the EPG and looked under Artifacts -> SSRD, the right template is available there.
Q. In the behavior
model use case, can our proposed system be
represented by an actor, this seems to be the method followed last
year.
The context you have provided does not justify using an actor for the proposed system. That is what the use cases are for.
Q) In the Behavior Model, I have drawn a use-case diagram showing a
user deciding to e-mail, chat or send messages. I have shown that this
'deciding to e-mail...' use case <<include>> 'Log on to website'
which
in turn <<include>> 'Password validation'. The comment that you
have
written states "DO NOT SHOW SEQUENCES IN USE CASE DIAGRAM" for all
three use cases. Well... this does represent a sequence, but then it
best describes how the user interacts with the system as a whole.
He
wants to e-mail/chat. This process includes logging on and validating
a password. So did you mean renaming my usecases to "connect to
webiste" or something and then show logon and validate as sequences?
Or is there something else which is wrong?
USE CASES CAN BE COARSE GRAINED. SO CHAT IS A USE CASE, LOG ON IS ANOTHER, PASSWORD VALIDATION IS NOT DIFFERENT FROM THE LOGON CASE. SHOW A SEQUENCE DIAGRAM FOR THE DETAILS.
Q) I've drawn the Logical Component View as a Component Diagram for
the Initial Draft. But SSAD Guidance 2 states that the Logical
Component View must be a Class diagram. Nothing has been mentioned
in
the Initial Draft about this, so is it safe to assume that a Component
Diagram is acceptable? And if not, then what would be the difference
between the class diagram in the Logical Component View and the class
diagram in the Component Model (2.1)?
YES, USE A CLASS DIAGRAM FOR THE COMPONENT MODEL. THE DIFFERENCE IS THAT IN SSAD YOU CAN GROUP THE ENTITIES TO IDENTIFY LOGICALLY RELATED/GROUPABLE ENTITIES AS COMPONENTS.
Q) I've drawn the System Deployment View as a Deployment Diagram
rather than a Collaboration Diagram. Is this okay?
THAT'S FINE.