Shuja Assignment on Software Engeneering

8/9/2019 Shuja Assignment on Software Engeneering

1/11

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)


2/11

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 includesas 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.


3/11

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-costmiscalculation, 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.
http://www.onestoptesting.com/sdlc-models/spiral-model.asphttp://www.onestoptesting.com/sdlc-models/spiral-model.asp


4/11

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 toknow 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 ofuse

casesthat 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
http://en.wikipedia.org/wiki/Use_casehttp://en.wikipedia.org/wiki/Use_casehttp://en.wikipedia.org/wiki/Use_casehttp://en.wikipedia.org/wiki/Functional_requirementshttp://en.wikipedia.org/wiki/Functional_requirementshttp://en.wikipedia.org/wiki/Non-functional_requirementshttp://en.wikipedia.org/wiki/Use_casehttp://en.wikipedia.org/wiki/Use_casehttp://en.wikipedia.org/wiki/Functional_requirementshttp://en.wikipedia.org/wiki/Non-functional_requirements


5/11

which impose constraints on the design or implementation (such asperformance

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 alumnis 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 universitys 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 themto upload the various assignments and the attendance of the students. As a developer it should
http://en.wikipedia.org/wiki/Performance_engineeringhttp://en.wikipedia.org/wiki/Performance_engineeringhttp://en.wikipedia.org/wiki/Quality_(business)http://en.wikipedia.org/wiki/Performance_engineeringhttp://en.wikipedia.org/wiki/Performance_engineeringhttp://en.wikipedia.org/wiki/Quality_(business)


6/11

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 engineeringand software engineering, encompasses

those tasks that go into determining the needs or conditions to meet for a new or altered
http://en.wikipedia.org/wiki/Systems_engineeringhttp://en.wikipedia.org/wiki/Systems_engineeringhttp://en.wikipedia.org/wiki/Software_engineeringhttp://en.wikipedia.org/wiki/Systems_engineeringhttp://en.wikipedia.org/wiki/Software_engineering


7/11

product, taking account of the possibly conflictingrequirementsof 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, anddefined to a level of detail sufficient for system design. Requirements can

befunctional andnon-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

includeprototyping, 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 ofsystems

engineering and software engineering that is concerned with determining the goals, functions,

and constraints of hardware and software systems." In some life cyclemodels, 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
http://en.wikipedia.org/wiki/Requirementshttp://en.wikipedia.org/wiki/Requirementshttp://en.wikipedia.org/wiki/Requirementshttp://en.wikipedia.org/wiki/Stakeholder_(corporate)http://en.wikipedia.org/wiki/Stakeholder_(corporate)http://en.wikipedia.org/wiki/Requirementhttp://en.wikipedia.org/wiki/Functional_requirementshttp://en.wikipedia.org/wiki/Functional_requirementshttp://en.wikipedia.org/wiki/Non-functional_requirementshttp://en.wikipedia.org/wiki/Non-functional_requirementshttp://en.wikipedia.org/wiki/Requirements_elicitationhttp://en.wikipedia.org/wiki/Use_casehttp://en.wikipedia.org/wiki/Use_casehttp://en.wikipedia.org/wiki/User_storyhttp://en.wikipedia.org/wiki/User_storyhttp://en.wikipedia.org/wiki/Interviewhttp://en.wikipedia.org/wiki/Focus_grouphttp://en.wikipedia.org/wiki/Focus_grouphttp://en.wikipedia.org/wiki/Prototypinghttp://en.wikipedia.org/wiki/Prototypinghttp://en.wikipedia.org/wiki/Use_Casehttp://en.wikipedia.org/wiki/Requirements_specificationhttp://en.wikipedia.org/wiki/Systems_engineeringhttp://en.wikipedia.org/wiki/Systems_engineeringhttp://en.wikipedia.org/wiki/Software_engineeringhttp://en.wikipedia.org/wiki/Software_development_life_cyclehttp://en.wikipedia.org/wiki/Software_development_life_cyclehttp://en.wikipedia.org/wiki/Requirementshttp://en.wikipedia.org/wiki/Stakeholder_(corporate)http://en.wikipedia.org/wiki/Requirementhttp://en.wikipedia.org/wiki/Functional_requirementshttp://en.wikipedia.org/wiki/Non-functional_requirementshttp://en.wikipedia.org/wiki/Requirements_elicitationhttp://en.wikipedia.org/wiki/Use_casehttp://en.wikipedia.org/wiki/User_storyhttp://en.wikipedia.org/wiki/Interviewhttp://en.wikipedia.org/wiki/Focus_grouphttp://en.wikipedia.org/wiki/Prototypinghttp://en.wikipedia.org/wiki/Use_Casehttp://en.wikipedia.org/wiki/Requirements_specificationhttp://en.wikipedia.org/wiki/Systems_engineeringhttp://en.wikipedia.org/wiki/Systems_engineeringhttp://en.wikipedia.org/wiki/Software_engineeringhttp://en.wikipedia.org/wiki/Software_development_life_cycle


8/11

may fosteroutside the boxthinking, then feasibility should be determined before

requirements are finalized.

Q6. Discuss in detail about the DFD and ER Diagrams. Also put some light on differentaspects 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.
http://en.wikipedia.org/wiki/Outside_the_boxhttp://en.wikipedia.org/wiki/Outside_the_boxhttp://en.wikipedia.org/wiki/File:SE_Process.jpghttp://en.wikipedia.org/wiki/Outside_the_box


9/11

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
http://en.wikipedia.org/wiki/Flowcharthttp://en.wikipedia.org/wiki/Flowchart


10/11

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 ofdata. Entity-relationship modeling is a database modeling method, used to

produce a type ofconceptual schema orsemantic 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, orERDs.

The first stage ofinformation system design uses these models during the requirements

analysis to describe information needs or the type ofinformation 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.
http://en.wikipedia.org/wiki/Software_engineeringhttp://en.wikipedia.org/wiki/Datahttp://en.wikipedia.org/wiki/Database_modelhttp://en.wikipedia.org/wiki/Conceptual_schemahttp://en.wikipedia.org/wiki/Semantic_data_modelhttp://en.wikipedia.org/wiki/Relational_databasehttp://en.wikipedia.org/wiki/Relational_databasehttp://en.wikipedia.org/wiki/Top-downhttp://en.wikipedia.org/wiki/Information_systemhttp://en.wikipedia.org/wiki/Requirements_analysishttp://en.wikipedia.org/wiki/Requirements_analysishttp://en.wikipedia.org/wiki/Informationhttp://en.wikipedia.org/wiki/Databasehttp://en.wikipedia.org/wiki/Data_modelinghttp://en.wikipedia.org/wiki/Ontology_(computer_science)http://en.wikipedia.org/wiki/Universe_of_discoursehttp://en.wikipedia.org/wiki/Universe_of_discoursehttp://en.wikipedia.org/wiki/Conceptual_data_modelhttp://en.wikipedia.org/wiki/Logical_data_modelhttp://en.wikipedia.org/wiki/Relational_modelhttp://en.wikipedia.org/wiki/Conceptual_data_modelhttp://en.wikipedia.org/wiki/Database_designhttp://en.wikipedia.org/wiki/IDEF1Xhttp://en.wikipedia.org/wiki/Software_engineeringhttp://en.wikipedia.org/wiki/Datahttp://en.wikipedia.org/wiki/Database_modelhttp://en.wikipedia.org/wiki/Conceptual_schemahttp://en.wikipedia.org/wiki/Semantic_data_modelhttp://en.wikipedia.org/wiki/Relational_databasehttp://en.wikipedia.org/wiki/Relational_databasehttp://en.wikipedia.org/wiki/Top-downhttp://en.wikipedia.org/wiki/Information_systemhttp://en.wikipedia.org/wiki/Requirements_analysishttp://en.wikipedia.org/wiki/Requirements_analysishttp://en.wikipedia.org/wiki/Informationhttp://en.wikipedia.org/wiki/Databasehttp://en.wikipedia.org/wiki/Data_modelinghttp://en.wikipedia.org/wiki/Ontology_(computer_science)http://en.wikipedia.org/wiki/Universe_of_discoursehttp://en.wikipedia.org/wiki/Universe_of_discoursehttp://en.wikipedia.org/wiki/Conceptual_data_modelhttp://en.wikipedia.org/wiki/Logical_data_modelhttp://en.wikipedia.org/wiki/Relational_modelhttp://en.wikipedia.org/wiki/Conceptual_data_modelhttp://en.wikipedia.org/wiki/Database_designhttp://en.wikipedia.org/wiki/IDEF1X


11/11

Refrences

1.Pearsons Software Engineering

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

3. www.wiki.soft/org

4. www.google.com
http://www.wiki.soft/orghttp://www.wiki.soft/org

Documents

Shuja Assignment on Software Engeneering