OOSE Module 2 Complete Solutions
OOSE Module 2 Complete Solutions
PART-A
Syed Ikram
Functional Requirements: These are the requirements that the end user
specifically demands as basic facilities that the system should offer. All
these functionalities need to be necessarily incorporated into the system as
a part of the contract. They are basically the requirements stated by the
user which one can see directly in the final product, unlike the non-
functional requirements.
\
The requirements for the automated teller machine are organized in the
following way: General requirements, requirements for authorization,
requirements for a transaction.
Functional requirements
DFD (Data Flow Diagram) is used to describe this spell checking and
correcting function in the word processor. It is usually explained with the
help of different levels of DFD i.e., Level 0 DFD and Level 1 DFD. The
working at these levels is shown below:
Level 0 DFD –
At this level, the submitted document from the user is checked and if found
any error then it’s corrected. The corrected document is ended back to the
user.
Functional
We will understand about designing the use case diagram for the ATM
system. Some scenarios of the system are as follows.
Step-1:
The user is authenticated when enters the plastic ATM card in a Bank ATM.
Then enters the user name and PIN (Personal Identification Number). For
every ATM transaction, a Customer Authentication use case is required and
essential. So, it is shown as a relationship.
Example of use case diagram for Customer Authentication is shown below:
Step-2:
User checks the bank balance as well as also demands the mini statement
about the bank balance if they want. Then the user withdraws the money as
per their need. If they want to deposit some money, they can do it. After
complete action, the user closes the session.
Example of the use case diagram for Bank ATM system is shown below:
Along with this Feasibility study helps in identifying risk factors involved in
developing and deploying system and planning for risk analysis also
narrows the business alternatives and enhance success rate analyzing
different parameters associated with proposed project development.
1. Known risks: Those risks that can be uncovered after careful assessment
of the project program, the business and technical environment in which the
plan is being developed, and more reliable data sources (e.g., unrealistic
delivery date)
2. Predictable risks: Those risks that are hypothesized from previous
project experience (e.g., past turnover)
3. Unpredictable risks: Those risks that can and do occur, but are extremely
tough to identify in advance.
Principle of Risk Management
Global Perspective: In this, we review the bigger system description,
design, and implementation. We look at the chance and the impact the risk
is going to have.
Take a forward-looking view: Consider the threat which may appear in the
future and create future plans for directing the next events.
Open Communication: This is to allow the free flow of communications
between the client and the team members so that they have certainty about
the risks.
Integrated management: In this method risk management is made an
integral part of project management.
Continuous process: In this phase, the risks are tracked continuously
throughout the risk management paradigm.
8 Compare and contrast between reactive risks and proactive risks with
suitable examples. Discuss the need for risk identification.
importance
● The users and the client get a brief idea about the software while in
the initial stages.
● The purposes and the intentions as well as the expected results are
properly defined. It hence lays the outline for software design.
● The desired goals are defined thereby easing off the efforts of the
developers in terms of time and cost.
● It forms a basis for the agreement between the client and the
developer.
● It becomes easier while transferring and using the solution elsewhere
or with new customers as the basis of functioning of the software is
mentioned.
● It acts as a material for reference at a later stage.
● It acts as the basis for reviews.
Since the SRS is an important document and is required right from the initial
stages of the agreement till the final verification and cross checking of the
end product is done, this should be prepared with utmost care after having
a proper understanding of the product to be developed.
Abhiram
2A) Throwaway prototypes are developed from the initial requirements but
they are not used for the final product and not an alternative for written
specification of the requirements. It enables quick prototyping and commits
to throwing the prototype away. If the users can get quick feedback on their
requirements, they may be able to refine the requirements early in the
development of the software. Then changes can be done early in the
development life cycle.
Throwaway prototype has a short project timeline and is easier and faster
to develop the interface. This type of prototyping can be used at any time in
a project by any of the project’s personnel. Throwaway prototypes actually
do nothing, it’s just presentation only for a limited purpose. Soon it will be
starting to become a thing of the past. This type of prototyping is not
getting used as much now.
3A) 3 Explain about Evolutionary Software Prototyping
and if any special skills are needed to accomplish the project tasks
and subcontracting
9A) Estimation: The process approximating a value that can be used even if
the data may be incomplete or unstable is referred to as estimation.
● Estimating FP or LOC.
● Apply average labor rates, compute the total cost and compare the
estimates.
Estimation determines how much money, effort, resources, and time it will
take to build a specific system or product. Estimation is based on −
● Available Documents/Knowledge
● Assumptions
● Identified Risks
A)
TOOL BASED X
1. During the planning stage, one needs to choose how many engineers
are required for the project and to develop a schedule.
2. In monitoring the project's progress, one needs to access whether the
project is progressing according to the procedure and takes
corrective action, if necessary.
Static, Multivariable Models: These models are based on method (1), they
depend on several variables describing various aspects of the software
development environment. In some models, several variables are needed to
describe the software development process, and selected equations
combine these variables to give the estimate of time & cost. These models
are called multivariable models.
A)
14 List and explain the steps in Risk Management Proces
A)
15 What are the Eight Reasons for Late Software Delivery? Discus
15A)
8)Coding errors.
16 List out the principles of Project Scheduling and discuss about it in brief
16A)
17 Write short notes on requirement specification with an example
18A)
● Inconsistent software.
● Time and cost overrun to fix the software which was prepared without
1. Scalability
2. Reliability
3. Regulatory
4. Maintainability
5. Serviceability
6. Utility
7. Security
8. Manageability
9. Data integrity
10.Capacity
11. Availability
12.Usability
13.Interoperability
14.Environmental
● They ensure the software system follows legal and adherence rules.
software subsystem.
19A)
● How they interact with one another, and with their social and cultural
environment
their world
Ethnography is a common approach in various social science fields, not just
anthropology. It is used not only to study distant or unfamiliar cultures, but
also to study specific communities within the researcher's own society.
20A)
21,22,23,24) REPEATED