Week 2

1. Describe the major elements and issues with waterfall development.

Waterfall Development follows the phases of the life cycle in sequence (Planning, Analysis, Design, and
Implementation). Each phase is thoroughly documented and approval is required before proceeding to the
subsequent phase. It is difficult, though not impossible, to go backwards in the SDLC under Waterfall
Development.

Waterfall Development requires that the system requirements be precisely specified prior to implementation and
also often "freezes" those requirements during development. The high degree of effort devoted to specifying user
requirements is a strength of Waterfall Development but specifying those requirements on paper is laborious and
may lead to errors and omissions. "Freezing" the requirements during development helps assure that the system is
developed according to specifications, but in a dynamic business environment, the system that is ultimately
developed may bear little resemblance to what is actually needed at the time the project is completed. Therefore,
extensive maintenance may be needed after implementation to revise the system to meet current conditions.

The two key advantages of the structured design waterfall approach are that:
 It identifies system requirements long before programming begins
 It minimizes changes to the requirements as the project proceeds.

The two key disadvantages are that:

a. The design must be completely specified before programming begins.
b. A long time elapses between the completion of the system proposal in the analysis phase and the delivery
of the system.

2. Why is it important for an OOSAD approach to be architecture centric?

A development methodology is said to be architecture centric if the architecture is the main artifact upon which
the design and implementation of the system is built. In other words, first the developers decide upon a framework
and then the system is built around and upon it. The architecture becomes both an enabler and a constraint on how
the system is developed.

It is important of an OOSAD approach to be architecture centric because this approach allows the development
team to iterate repeatedly without undermining the stability of the system’s core. If the architecture were to be
revisited and modified over time, then there would be a very good chance that support to some (or most) system
components would eventually be compromised.

3. Compare and contrast extreme programming and throwaway prototyping.

Extreme programming (XP): Extreme Programming is founded on four core values which provide a foundation on
which XP developers use to create any system. The four core values are Communication, Simplicity, Feedback
and Courage.
Throwaway Prototyping: Throwaway prototyping-based methodologies balance the benefits of well thought out
analysis and design phases with the advantages of using prototypes to refine key issues before a system is built.
Each of these issues is examined by analyzing, designing, and building a design prototype.
4. What is the Unified Modeling Language?
The Unified Modeling Language (UML) is a standard set of diagramming techniques. The objective of UML is to
provide a common vocabulary of object-oriented terms and diagramming techniques rich enough to model any
systems development project from analysis through implementation.

Week 3
1. What are the three types of interview questions? Define and identify why an analyst would use each type of
question. Include an example of each question type.
The three types of interview questions are closed-ended, open-ended, and probing. Closed-ended questions are
questions that require a specific answer. Analysts use closed-ended question when they are looking for specific,
precise information. An example of a closed-ended question is “How many telephone orders are received per
day?”

Open-ended questions are questions that leave room for the interviewee to elaborate. Analysts use open-ended
questions to gather rich information and to give the interviewee more control over the information that is revealed
during the interview. An example of an open-ended question is “What do you think about the current system?”

Probing questions follow up on what has just been discussed in order for the analyst to learn more and are often
used when the interviewer is unclear about what the interviewee’s answer. Probing questions encourage the
interviewee to expand or confirm information from a previous response and they are a signal that the interviewer
is listening and is interested in the topic. An example of a probing question is “Why?”

2. What is the difference between an as-is system and a to-be system?

An as is system is an existing or a current state of system or process. The As-Is system is the combination of
people, processes, data, and technology that currently perform the tasks and functions of the system under study.
The As-Is system may or may not incorporate computers.
A to be system is the one which is developed on the basis of the analysis done on the current system which needs
to be changed. The To-Be system is the combination of people, processes, data, and technology that will perform
the required tasks and functions of the system under study.

3. Describe the five major steps in conducting interviews.

The five major steps to conducting interviews are:
a) Selecting interviewees - determine who should be interviewed, why they should be interviewed (what
contribution will they make to the project?), and develop a schedule for conducting the interviews.
b) Design the interview questions - depending on who is being interviewed and the type of information
desired, the analyst needs to design the interview session with the appropriate structure and question type.
c) Prepare for the interview - review related material; review interview plan; review interview questions and
plan for any anticipated problem areas; inform interviewee about interview agenda.
d) Conduct the interview - establish rapport with the interviewee; explain purpose of interview; ask interview
questions; record information from interviewee.
e) Prepare post-interview report - summarize the interview in an interview report.
 4. How can you differentiate between facts and opinions? Why can both be useful?
An opinion is a statement about an issue or situation that may or may not be support by fact. If it is stated "Most
of our collections are on-time," this is an opinion that can be confirmed or denied by doing an actual measurement
of on-time collections. This information is factual, and may provide the basis for the opinion expressed.
Alternatively, the opinion may be a misstatement of actual fact, and may suggest an area where there is
misunderstanding of the true situation.

5. What are the key aspects of using observation in the information-gathering process?
Observation is very helpful in enabling the analysts to understand the As-Is system. It is often much easier to
grasp a process by observing it rather than having it explain verbally. Observation helps validate information
learned from other techniques. As an observer, one must always bear in mind that people's behavior may change
because they are being observed. Therefore, the results of observation may be questionable. The behavior that is
observed is not necessarily the true behavior.

Week 4
5. How do you create use cases?
a) Write each step in the SVDPI form
b) Make clear the initiator and receiver of action in each step
c) Write the step from the perspective of an independent observer
d) Write all steps at the same level of abstraction
e) Ensure that each use case represents a sensible set of actions
f) Keep all steps as simple as possible
g) Repeat all actions as necessary.

6. How do you create use case diagrams?

a) Start by drawing the system boundary
b) Draw the use cases on the diagram
c) Place the actors on the diagram
d) Draw the lines connecting the actors to the use cases with which they interact.

7. Explain the following terms: actor, use case, system boundary, and relationship. Use layperson’s language,
as though you were describing them to a user.
a) Actor: The actor is someone (or occasionally some thing) outside the system that provides information or
things (inputs) that the system needs, receives some or all of the things or information (outputs) that the
system creates, or the actor can both supply and receive things or information from the system.

b) Use case: A use case is a description of what the system does from the perspective of the user. Since systems
can often do many things, the use case often includes a central activity of the system but also shows the many
variations that can occur under different circumstances or when varied users interact with it in different ways.
 c) System boundary: The system boundary is the dividing point between those items that are included in the
system and those that are not. In terms of information technology, the boundary separates the parts of a job
that are done by the application from those that are done by humans. In terms of the entire information system
that includes both the humans and applications working together to solve business problems, the boundary can
be fuzzier. For the efficient development of new systems, however, the boundary shows what the
programmers must include and what they should not include in the framework of the project.

d) Relationship: Use cases are not independent and stand alone items in most examples. Pairs (or more) of use
cases can be related can be associated -- for example there can be communication between an actor and a use
case. Use cases can be extended such that a normal flow of events can be extended to another use case
showing an alternate or exceptional flow. An include relationship shows that one or more use case is a part of
another more encompassing use case. Finally, a generalization relationship shows that a use case is a
specialized example of a more general case

Week 5
1. Describe the terms action, activity and object nodes that are found in an activity diagram.
Action is a simple non-decomposable piece of the overall behavior that is being modeled. On the other hand,
an activity is used to represent a set of actions. An activity can further be decomposed into other activities or
actions. Actions and activities can represent either computerized or manual behavior. They are depicted using
rounded rectangles. Object nodes model objects in the activity diagram. They are represented using rectangles.
Object nodes represent the flow of information from one activity to another activity.

2. Distinguish between control flows and object flows in an activity diagram.

Control flows model the paths of execution through a business process. Control flows can only be attached to
actions or activities, and are depicted using a solid line with an arrowhead depicting the direction of flow.
Object flows model the flow of objects through the business process. Since activities or actions modify or
transform objects, object flows are necessary to show the actual objects that are used by and modified by these
actions and activities. Object flows are depicted using dashed lines with arrows, and must have an activity at
one end and an object at the other end.

Week 6
8. Explain how a detail use case differ from an overview use case? When are each used?
The overview use case provides a high level version of the system. It shows the basic information and is created
early in the information requirements determination process. In contrast, the detail level use case shows all of the
aspects of the use case needed to document the system.

9. How does an essential use case differ from a real use case?
The essential use case uses only the minimal essential issues necessary to understand specific functionality. In
contrast, the real use case adds in the specifics of how the system implements the request. This seems analogous to
the logical versus the physical views of the system.
10. What are the major elements of an overview use case?
The major elements are its name, ID number, primary actor, type, and a brief description.

11. What are the major elements of a detail use case?

The major elements consist of all of the overview use case elements plus a listing of stakeholders and interests;
trigger and trigger type; relationships; normal flow of events; listing of sub-flows and alternate/exceptional
flows.

Week 7
1. Describe to a businessperson the multiplicity of a relationship between two classes.
When a relationship exists between classes, the multiplicity documents how many objects may or must be
associated between these classes in the form of minimum and maximum numbers. In general, multiplicity reflects
business rules regarding the nature of these relationships among classes.

2. Give two examples of aggregation, generalization, and association relationships. How is each type of
association depicted on a class diagram?
Aggregation: The spark plug is part of the engine; the engine is part of the car
Generalization: The graduate student is a student; the rock music CD is a CD
Association: customer orders book; UPS/FedEx/Post Office delivers book

Generalization shows that one class (subclass) inherits from another class (superclass), meaning that the properties
and operations of the superclass are also valid for objects of the subclass. The generalization path is shown with a
solid line from the subclass to the superclass and a hollow arrow pointing at the superclass. Generalization
relationship occurs when you need to use words such as “is a-kind-of” to describe the relationship.

Aggregation is used when classes actually comprise other classes. For example, think about a doctor’s office that
has decided to create health care teams that include doctors, nurses, and administrative personnel. As patients
enter the office, they are assigned to a health care team that cares for their needs during their visits. Typically, you
can identify these kinds of associations when you need to use words like “is a part of” or “is made up of” to
describe the relationship.

Week 8
1. Give three examples of derived attributes that may exist on a class diagram. How would they be denoted on
the class diagram?
Derived attributes, which are attributes that can be calculated or derived; these special attributes are denoted by
placing a slash (/) before the attribute’s name. For example:

a) -/ age (derived from the difference between birth date and current date.
b) -/ line-item cost (derived from multiplying product price by quantity)
c) -/ grade point average (derived from the dividend of total grade points by total units)
2. What are the different types of visibility? How would they be denoted on a class diagram?
Visibility relates to the level of information hiding to be enforced for the attribute. The visibility of an attribute
can be public (+), protected (#), or private (-).

Week 9
1. What is meant by class cohesion? What are the characteristics of ideal class cohesion?
Class cohesion is the level of cohesion among the attributes and methods of a class (i.e., how single-minded a
class is). A class should represent only one thing, such as an employee, a department, or an order. Cohesive class
should have these attributes:

1. It should contain multiple methods that are visible outside the class.
2. Each visible method performs only a single function.
3. All methods reference only attributes or other methods defined within the class or one of its superclasses.
2. What are the three primary hardware components of any physical architecture?
The three primary hardware components of any physical architecture are:

1. Servers
2. Client computers
3. Network

3. Compare and contrast server-based architectures, client-based architectures and client-server- based
architectures.
Although there are numerous ways in which the software components can be placed on the hardware components,
there are three principal application architectures in use today: server-based architectures, client-based
architectures and client–server architectures. The most common architecture is the client–server architecture.

Server-based architecture: Being one of the very first computing architectures, this had the server performing all
the four application functions.
Advantages:
 Simple architecture works well
 Single point of control cause all messages flow through server
 Application software is developed and stored on one computer and all the data are on the same computer.
Disadvantages:
 Server must process all messages
 Increase in applications results in slower response rate
 Server upgrades come in large increments and are expensive.

Client-based architecture: Clients generally are personal computers on a local area network and the server
computer is on the same network.
Advantages:
 Simple architecture and works well
 Disadvantages:
 All data on the server must travel to the client for processing, resulting in network overload and high
power requirement on client computers.

Client-Server architecture: Most organizations today are moving to client–server architectures, which attempt to
balance the processing between the client and the server by having both do some of the application functions. In
these architectures, the client is responsible for the presentation logic while the server is responsible for the data
access logic and data storage. The application logic may reside on either the client, the server, or be split between
both.
Advantages:
 They are scalable
 They are able to support different types of clients and servers.
 For thin client server architectures that use Internet standards, it is simple to clearly separate the
presentation logic, the application logic, and the data access logic and design each to be somewhat
independent.
 Network stability
Disadvantages:
 Writing software is more complicated because client-server computing requires two applications: one on the
client and the other on the server.
 Updating the network with a new version of the software is more complicated, too.
 Software updating is to be done in all servers and clients.

Week 10
1. How can different parts of the interface be consistent?
The navigation controls can be consistent, using the same icon or command to trigger an action throughout the
system. Terminology can be consistent throughout the interface. The content portion of the screen that
contains forms and reports should also present consistently designed reports and forms. Messages and
information in the status area should be specified consistently throughout the system.

2. What are use scenarios and why are they important?

Use scenarios describe commonly used patterns of actions that users will perform. Use cases describe how
users will interact with the system. Use cases are developed for the most common ways of working through
the system. These use cases will be valuable in ensuring that the interface permits the users to enact these use
cases quickly and smoothly.

3. What is a WND and why is it used?

A window navigation diagram defines the basic structure of the interface. These diagrams show all the
screens, forms, and reports in the system, how they are connected, and how the user moves from one to
another. The diagram helps depict the basic components of the interface and how they work together to
provide users the needed functionality. The structure of the interface depicted in the WND can be examined
using the use cases to see how well the use cases can be performed. This is an important early step in
developing simple paths through the most common activities performed in the system.