DEPARTMENT OF MANAGEMENT (LSM)

SUBJECT: SOFTWARE ENGNEERING

TOPIC: ASSIGNMENT-1

SUBMITTED TO : SUBMITTED BY :
MS. SHAINA SHUJA QAMMER
REG NO: 10904442
ROLL NO: 03
SECTION: S1906
MBA (I.T)
Q1. “Spiral model is an evolutionary as well as an iterative development”. Justify your
answer by discussion about different aspects of spiral model.

Ans. Spiral Model is said is an evolutionary as well as an I development model base. It

possesses both the properties of evolutionary nature of the sequential model and iterative
nature of prototyping. The development is organized in the form of a spiral which includes
as many cycles as required for the development of any of the processes

The Spiral Model is divided into some activities known as task ,it can varied from the value
of four to six as per the model requirement..
No of cycle that has been showed in this spiral model, the fact is that each single cycle is a
kind of complete process cycle in itself as each cycle contained following no. Of tasks

1. Customer communication

2. Planning

3. Risk analysis

4. Engineering

5. Construction and release

6. Customer evaluation...

.The main feature by its risk-driven nature which helps it to follow is prototyping
feature. That is why it is considered as most suited model for projects having high
risks factors.
The steps in the spiral model can be generalized as follows:

The new system requirements are defined in as much detail as possible. This usually
involves interviewing a number of users representing all the external or internal users
and other aspects of the existing system.

1. A preliminary design is created for the new system.

2. A first prototype of the new system is constructed from the preliminary design. This is
usually a scaled-down system, and represents an approximation of the characteristics
of the final product.
3. A second prototype is evolved by a fourfold procedure: (1) evaluating the first
prototype in terms of its strengths, weaknesses, and risks; (2) defining the
requirements of the second prototype; (3) planning and designing the second
prototype; (4) constructing and testing the second prototype.
4. At the customer's option, the entire project can be aborted if the risk is deemed too
great. Risk factors might involve development cost overruns, operating-cost
miscalculation, or any other factor that could, in the customer's judgment, result in a
less-than-satisfactory final product.
5. The existing prototype is evaluated in the same manner as was the previous prototype,
and, if necessary, another prototype is developed from it according to the fourfold
procedure outlined above.
6. The preceding steps are iterated until the customer is satisfied that the refined
prototype represents the final product desired.
7. The final system is constructed, based on the refined prototype.
8. The final system is thoroughly evaluated and tested. Routine maintenance is carried
out on a continuing basis to prevent large-scale failures and to minimize downtime.
Q2. “Deep Dive Analysis of business processes of an organization is necessary before
implementing them in software”. Justify with a suitable example?

Ans. The study understanding of several needs of the client and the users so that the software
can be built in a way that all the needs shall be known as analysis. The analyst, who is
responsible for the specifications of the software, must be totally aware of the business
processes of the organisation.

This is a important factor because if the analyst has the knowledge about the business
processes only then he can change them into the specified requirements or we can say the
required features of the software and the designers can get the same in the software

The analyst is supposed to have knowledge about the questions the clients has and users to
know about how the business processes are going in the organization

Q3. Evaluate the efficiency of RAD model over basic Waterfall model used for software
development.

Ans. Out of many options available, the Rapid Application Development and Waterfall
Model are used predominantly. One method can be proved helpful to the other one. In the
following points we discuss.

1...prototype need is different in both the processes tool in RAD we have regular iteration as
in waterfall it is not so required..

2.flexibilty:- as in the waterfall tool process we have less of the flexibility as the alteration are
lesser times required as the other tool as RAD requires more of the flexibility

3. User involvement:-as RAD needs regular iterations so it require more of the user
involvement role is quite important as compare to the other one..

4. Usage: - as for the smaller process we have RAD at the better size as compared to the
waterfall for the heavy projects.

Q4. Discuss in detail about SRS. Also prepare a sample SRS document taking some
sample requirements.

Ans. As SRS stands for:- Software Requirement Specification is considered to be the basis
for the process of development of software. A Software Requirements Specification (SRS) is
a complete description of the behaviour of the system to be developed. It includes a set of use
cases that describe all the interactions the users will have with the software. Use cases are
also known as functional requirements. In addition to use cases, the SRS also contains non-
functional (or supplementary) requirements. Non-functional requirements are requirements
which impose constraints on the design or implementation (such as performance
engineering requirements, quality standards, or design constraints).
It sets the basis for software design, test, deployment, training etc. It also sets pre-requisite
for a good design though it is not enough.

. It consists of 6 modules:

1. Inception
2. Elicitation
3. Elaboration
4. Negotiation
5. Specification
6. Validation

Components of SRS

a) Functionality

b) Performance

c) Design constraints imposed on an implementation.

SRS for UMS (University Management System):

GENERAL DESCRIPTION – UMS is University Management System for managing the
records of the alumni’s of the university as well as staff, faculty and higher authorities.

Purpose – The purpose for developing this type of software or introducing this UMS is to
facilitate everyone who is concerned with the university.

Scope – The scope of UMS is global i.e. it should be able to be accessed from anywhere
through internet i.e. registered users must be able to login to their accounts by directly
accessing the university’s website and then signing in with their username and password
anytime and anywhere.

Abbreviation – UMS University Management System

Overview – As the ums is able to have a user interface. It should have a drop down boxes
and if we drag mouse on any control at our welcome screen information regarding that the
control should be displayed. Help menu should be there. As a teacher it should provide them
to upload the various assignments and the attendance of the students. As a developer it should
make a user interface which is user friendly. He should make the UMS as simple as he can.
Backup at the main server should be made.

OVERALL DESCRIPTION

1 Product Perspective – product i.e. UMS should be able to provide a basic and easy
interchange of information i.e. it should be able to remove the communication gaps between a
teacher and the student. It should have chat facilities for all the users that are online. It should
be compatible with all the operating systems.

2. Product Functions - The following are the product functions of the UMS:

 The UMS login box should on the official website of the university.
 The password field should be secured.
 After signing in all updates and new announcements for users should be displayed.
 By clicking on the dropdown box of the options the user should be able to view
progress reports, assignments, notes, attendance, placement services and results.
 User should be able to change the passwords.
 Web pages should support pdf, ppt, doc and similar supported formats so that they can
be easily downloadable and unloadable.

3. User Characteristics – A user can only have his/her registration number as username so if
he joins the university then only he can then only he can login. This prevents misuse,
unauthorized access and hacking of the product.

4. General Constraints – Server capacity is how many users can access or can be online at
once. More is the number of users more will be the network traffic and hence the server
comes in a down state. Personal firewall and updating is a tough task, it should be such that it
should not block the network traffic, making the system slower. Firewall of the UMS should
not collide with the firewall of the user system.

5. Assumptions and Dependencies – UMS should work even at when the network traffic is
high. Server should have a power backup as well as a database backup. The UMS should be
compatible with most of the operating systems i.e. previous and latest ones.

Q 5. “Validation of requirements is a mandatory practice while requirement

engineering”. Support this term with appropriate examples.

Requirements analysis in systems engineering and software engineering, encompasses

those tasks that go into determining the needs or conditions to meet for a new or altered
product, taking account of the possibly conflicting requirements of the various stakeholders,
such as beneficiaries or users.

Requirements analysis is critical to the success of a development project. Requirements must

be actionable, measurable, testable, related to identified business needs or opportunities, and
defined to a level of detail sufficient for system design. Requirements can
be functional and non-functional.

Conceptually, requirements analysis includes three types of activity:

 Eliciting requirements: the task of communicating with customers and users to

determine what their requirements are. This is sometimes also called requirements
gathering.
 Analyzing requirements: determining whether the stated requirements are unclear,
incomplete, ambiguous, or contradictory, and then resolving these issues.
 Recording requirements: Requirements might be documented in various forms, such
as natural-language documents, use cases, user stories, or process specifications.

Requirements analysis can be a long and arduous process during which many delicate
psychological skills are involved. New systems change the environment and relationships
between people, so it is important to identify all the stakeholders, take into account all their
needs and ensure they understand the implications of the new systems. Analysts can employ
several techniques to elicit the requirements from the customer. Historically, this has included
such things as holding interviews, or holding focus groups (more aptly named in this context
as requirements workshops) and creating requirements lists. More modern techniques
include prototyping, and use cases. Where necessary, the analyst will employ a combination
of these methods to establish the exact requirements of the stakeholders, so that a system that
meets the business needs is produced.

Systematic requirements analysis is also known as requirements engineering. It is sometimes

referred to loosely by names such as requirements gathering, requirements capture,
orrequirements specification. The term requirements analysis can also be applied specifically
to the analysis proper, as opposed to elicitation or documentation of the requirements, for
instance.

Requirement engineering according to Laplante (2007) is "a subdiscipline of systems

engineering and software engineering that is concerned with determining the goals, functions,
and constraints of hardware and software systems." In some life cycle models, the
requirement engineering process begins with a feasibility study activity, which leads to a
feasibility report. If the feasibility study suggest that the product should be developed, then
requirement analysis can begin. If requirement analysis precedes feasibility studies, which
may foster outside the box thinking, then feasibility should be determined before
requirements are finalized.

Q6. Discuss in detail about the DFD and ER Diagrams. Also put some light on different
aspects of both which make them suitable for the development process of Software.

Ans. Data Flow Diagrams: It is the basic tool for development of any process Data Flow
Diagram represents the flow of data in a system. We know that every system has inputs
which are processed to result into the desired outputs, so DFD is mainly focussed to show
those processes and information flow. Also, while

Components of DFD:

1. :-

Figures represent processes. These circles are labelled according to the process they represent
in the DFD.

2.
Shows data storage.

3.

Shows the flow of data

A DFD provides no information about the timing or ordering of processes, or about whether
processes will operate in sequence or in parallel. It is therefore quite different from
a flowchart, which shows the flow of control through an algorithm, allowing a reader to
determine what operations will be performed, in what order, and under what circumstances,
but not what kinds of data will be input to and output from the system, nor where the data
will come from and go to, nor where the data will be stored (all of which are shown on a
DFD).

Entity Relationship Diagrams:

An entity relationship diagram (ERD) is a graphical tool which is used to depict the
conceptual and abstract data and relationships between different entities in a database. ER
diagrams often use symbols to represent three different types of information. Boxes are
commonly used to represent entities. Diamonds are normally used to represent relationships
and ovals are used to represent attributes.

Also Known As: ER Diagram, E-R Diagram, entity-relationship model

Consider the example of a database that contains information on the residents of a city. The
ER digram shown in the image above contains two entities -- people and cities. There is a
single "Lives In" relationship. In our example, due to space constraints, there is only one
attribute associated with each entity. People have names and cities have populations. In a
real-world example, each one of these would likely have many different attributes.
In software engineering, an entity-relationship model (ERM) is an abstract and conceptual
representation of data. Entity-relationship modeling is a database modeling method, used to
produce a type of conceptual schema or semantic data model of a system, often a relational
database, and its requirements in a top-down fashion. Diagrams created by this process are
calledentity-relationship diagrams, ER diagrams, or ERDs.

The first stage of information system design uses these models during the requirements
analysis to describe information needs or the type of information that is to be stored in
a database. The data modeling technique can be used to describe any ontology (i.e. an
overview and classifications of used terms and their relationships) for a certain area of
interest. In the case of the design of an information system that is based on a database,
the conceptual data model is, at a later stage (usually called logical design), mapped to
a logical data model, such as therelational model; this in turn is mapped to a physical model
during physical design. Note that sometimes, both of these phases are referred to as "physical
design".

There are a number of conventions for entity-relationship diagrams (ERDs). The classical
notation mainly relates to conceptual modeling. There are a range of notations employed in
logical and physical database design, such as IDEF1X.
Refrences

1.Pearsons Software Engineering

2- www. Software-req/334-acfe/html

3. www.wiki.soft/org

4. www.google.com