PRACTICAL 1

AIM: Identify the project scope and objective of given problem

COLLEGE AUTOMATION SYSTEM

College Automation System is a software that helps both the students and the management
authorities of the college. Our College Automation System is capable of storing the details of
the students and the teachers and also maintain their details in a dynamic order. This software
can help us explore all the activities happening inside the college which we as students do not
have any knowledge about. It can handle the details of students, teachers and head of the
departments.In this system the HOD can maintain every detail of a particular student in his
department. He can also post any notice corresponding to his department. He can also grant a
student his attendance and allowance to appear for the examination. There is also a question
and answer portal in our project in where anybody is able to post a question and anybody is
able to answer that question. In case of a student the name and the department of the student
will also be displayed in the question bar. This system provides detailed structure of the
departments of the college and the facilities of the college

Objective:

 The main objective of the system is to reduce the consumption of time during
maintenance of record of the
 Simple easy database maintained.
 To manage the tasks related to the students and authorities.
 User interface are user friendly.

Scope:

 Provides the searching facilities based on various factors. Such as Faculties,

Registration, Students, Courses
 College Management System also sells the employees details online for students’
details, employees’ details, courses.
 It tracks all the information of Branches, Login, Students etc.
 Manage the information of Branches
 Shows the information and description of the Faculties, Registration? To increase
efficiency of managing the Faculties, Branches
  It deals with monitoring the information and transactions of Students.
 Manage the information of Faculties

BANK MANAGEMENT SYSTEM

Banking and Automation- the two terms are synonymous to each other in the same way bread
is to butter – always clubbed together. We live in a digital age and hence, no institution of the
global economy can be immune from automation and the advent of digital means of
operations. In fact, banks and financial institutions were among the first adopters of
automation considering the humongous benefits that they get from embracing IT. The reason
why banks and financial institutions rapidly embraced IT is that their operations when done
manually take up a lot of time and effort from their staff as well- making them do routine
activities and searches over and over again, and in the process, missing the chance to move
up the value chain. Automation enables a standardized audit trail, making sure the right
people have access to the right systems and guaranteeing that financial institutions adhere to
industry standards, while reducing the need for cost involved in keeping legacy IT systems
running.
 PRACTICAL 2

AIM: Develop software requirement specification for college automation

system and bank management system

COLLEGE AUTOMATION:

The system should support management of academic, administrative, and other activities in
our institute. These activities are divided into four sections as follows

Academic activities include:

 Academic Programmed: Applications and Admissions, enrolling new students,

Course registration (enrollment for desired courses) and Fee payment, Evaluation
and Grading, Viewing, and printing grade cards, Teacher evaluation.
 Student Information: Student records management.
 Training and Placement: Displaying schedules of Campus interviews, putting up
shortlists and declaring results.

Administrative activities consist of:

 Employee Information: Maintaining Employee records, accessing data and

Generating reports as required.
 Legal matters: Access to Case reports and Legal suits of the Institute.
 Human Resources Management: Faculty and Staff Recruitment Process
 General Administration: File movement Tracking (across
departments/administration), Facility to raise an issue / ticket and track it, Meeting
Management, Managing Institute Advertisements.

Accounting and Finance includes:

 Student account management covering fees, teaching assistantship, scholarships,

fines, and other charges
 Employee Accounts Management: Salaries, Leave management, Income Tax
management, Pension management, TA/DA and PDA.
  Visibility and transparency of various funds across departments, projects, interest
groups, Deans, Registrar, and the Director; Compilation of accounts to enable
furnishing details of expenditure to the funding agencies.
 Internal Audit.

Facilities include:

 Stores and Purchases: Indenting and approval, Billing and sales, Inventory
management and stock verification, Common Access System to Library, Stores etc
through Smart Card, Interface to check stock register and status of purchase etc.
 Infrastructure Facilities and Transportation: Student hostel/room allocation, Hostel
management, Guesthouse management, Apartment/Quarter allocation and
management, Managing the booking of Seminar Halls / Conference Rooms,
Transportation management, Civil Maintenance works, Water / Electricity Bills,
Electrical Maintenance.

BANK MANAGEMENT SYSTEM:

Following are the requirement focused on this project:

a) Customer Login: Each Customer will have its account Id and password. This page will
require both attributes for them to access their account.
b) Bank Features: It isn’t sure that each visitor of the Bank’s website will be a customer.
He/she would be a normal visitor interested in reading the features bank provides.
The website’s main page should provide him the basic features and benefits of the
bank to these types of users.
c) Order for an Account: A new visitor the Bank’s website would be interested in
opening a new account in the Bank. So, he must be provided an easy path to create a
new account in the bank.
d) Fill the Form: Newcomer should have to fill the form to register him/herself with the
bank. After filling the form, If the values inputted by the user were logical correct, his
contact details will be sent to the administration block else he will be asked to input
the values again.
e) Welcome Page: After a user will be login, he will provide an interface offering
different tasks (Here this interface will provide many of the functionalities, which the
customer needs in the software). He must choose a task to carry on his work.
f) Staff Login: On the Website main page, A staff login link will also be provided. Bank
staff will use to input their ID’s and passwords to access their account. Here the type
of staff will also be recognized, if he will be of administration block, he will be sent to
the administration module else he will be sent to the record management module.
g) Check the balance: After logging in, if the user wants to check his balance, he will
have to click the balance check link. It will tell him his current balance of the account
through which he is logged in.
h) Transfer Balance: If user wants to transfer his money to some other account, then
this module will provide him this opportunity. He will input the account details of the
receiver. After this process, server will check the balance of the user and if the
transfer balance will be less than the account balance then transfer will take place
else, he will be alarmed that he has lo balance.
i) Account detail teller: If the user physically contacts the Bank branch, then he will
provide his account detail to the management staff who will inform him about his
account. User will be able to do every task at the branch that he can do online from
his home.
j) Order Cash Book: If user’s Cheque book has been finished, he will be able to order a
new cheque book from this module.
 PRACTICAL 3
AIM: Develop UML Use case model for a problem.
To model a system, the most important aspect is to capture the dynamic behavior.
Dynamic behavior means the behavior of the system when it is running/operating.
Only static behavior is not sufficient to model a system rather dynamic behavior is
more important than static behavior. In UML, there are five diagrams available to
model the dynamic nature and use case diagram is one of them. Now as we have to
discuss that the use case diagram is dynamic in nature, there should be some internal
or external factors for making the interaction.
These internal and external agents are known as actors. Use case diagrams consists
of actors, use cases and their relationships. The diagram is used to model the
system/subsystem of an application. A single use case diagram captures a particular
functionality of a system.
Hence to model the entire system, a number of use case diagrams are used.
Purpose of Use Case Diagrams
The purpose of use case diagram is to capture the dynamic aspect of a system.
However, this definition is too generic to describe the purpose, as other four
diagrams (activity, sequence, collaboration, and Statechart) also have the same
purpose. We will look into some specific purpose, which will distinguish it from
other four diagrams.
Use case diagrams are used to gather the requirements of a system including internal
and external influences. These requirements are mostly design requirements. Hence,
when a system is analyzed to gather its functionalities, use cases are prepared and
actors are identified.
When the initial task is complete, use case diagrams are modelled to present the
outside view.
In brief, the purposes of use case diagrams can be said to be as follows −
• Used to gather the requirements of a system.
• Used to get an outside view of a system.
• Identify the external and internal factors influencing the system.
• Show the interaction among the requirements are actors.

USE CASE OF COLLEGE AUTOMATION:

USE CASE OF BANK MANAGEMENT SYSTEM

 PRACTICAL 4
AIM: Develop Class diagrams.
Develop Class diagrams
Class diagram is a static diagram. It represents the static view of an application. Class
diagram is not only used for visualizing, describing, and documenting different aspects of a
system but also for constructing executable code of the software application.
Class diagram describes the attributes and operations of a class and also the constraints
imposed on the system. The class diagrams are widely used in the modeling of object-
oriented systems because they are the only UML diagrams, which can be mapped directly
with object-oriented languages.
Class diagram shows a collection of classes, interfaces, associations, collaborations, and
constraints. It is also known as a structural diagram.

Purpose of Class Diagrams

The purpose of class diagram is to model the static view of an application. Class diagrams are
the
only diagrams which can be directly mapped with object-oriented languages and thus widely
used
at the time of construction.
UML diagrams like activity diagram, sequence diagram can only give the sequence flow of
the
application, however class diagram is a bit different. It is the most popular UML diagram in
the
coder community.
The purpose of the class diagram can be summarized as −
• Analysis and design of the static view of an application.
• Describe responsibilities of a system.
• Base for component and deployment diagrams.
• Forward and reverse engineering.
Class diagram of college automation system:
 PRACTICAL 5
AIM: Represent project Scheduling of above-mentioned projects
 PRACTICAL 6
AIM: Use any model for estimating the effort, schedule and cost of software
project
 PRACTICAL 7
AIM: Develop DFD model (level-0, level-1 DFD and Data dictionary) of the
project
DFD: Data Flow Diagram (DFD) of a system represents how input data is converted to
output data graphically. Level 0 also called context level represents most fundamental and
abstract view of the system. Subsequently other lower levels can be decomposed from it.
DFD model of a system contains multiple DFDs but there is a single data dictionary for entire
DFD model. Data dictionary comprises definitions of data items used in DFD.

DFD rules
● Each process should have at least one input and an output.
● Each data store should have at least one data flow in and one data flow out.
● Data stored in a system must go through a process.
● All processes in a DFD go to another process or a data store.

DFD Levels:
A data flow diagram can dive into progressively more detail by using levels and
layers, zeroing in on a particular piece. DFD levels are numbered 0, 1 or 2, and
occasionally go to even Level 3 or beyond.

1. DFD Level 0 is also called a Context Diagram. It’s a basic overview of the whole
system or process being analyzed or modeled. It’s designed to be an at-a-glance view,
showing the system as a single high-level process, with its relationship to external
entities
 Level 0

2. DFD Level 1 provides a more detailed breakout of pieces of the Context Level
Diagram. You will highlight the main functions carried out by the system, as you
break down the high-level process of the Context Diagram into its subprocesses.

Level 1

Physical and Logical:

DFDs There are two types of data flow diagrams, namely physical data flow diagrams and
logical dataflow diagrams and it is important to distinguish clearly between the two:

Physical Data Flow Diagrams:

An implementation-dependent view of the current system, showing what tasks are carriedout
and how they are performed. Physical characteristics can include:
Names of people
Form and document names or numbers
Master and transaction files
Equipment and devices used
Logical Data Flow Diagrams
An implementation-independent view of the a system, focusing on the flow of data
betweenprocesses without regard for the specific devices, storage locations or people in the
system. Thephysical characteristics listed above for physical data flow diagrams will not be
specified.

A typical DFD

Importance of DFDs in a good software design

The main reason why the DFD technique is so popular is probably because of the fact that
DFD is a very simple formalism – it is simple to understand and use. Starting with a set of
high-level functions that a system performs, a DFD model hierarchically represents various
subfunctions. In fact, any hierarchical model is simple to understand. Human mind is such
that it caneasily understand any hierarchical model of a system – because in a hierarchical
model, startingORDERS CUSTOMERS INVOICES with a very simple and abstract model
of a system, different details of the systemare slowlyintroduced through different hierarchies.
The data flow diagramming technique also follows avery simple set of intuitive concepts and
rules. DFD is an elegant modeling technique that turns out to be useful not only to represent
the results of structured analysis of a software problem, but also for several other applications
such as showing the flow of documents or items inanorganization.

Data dictionary
A data dictionary lists all data items appearing in the DFD model of a system. The dataitems
listed include all data flows and the contents of all data stores appearing ontheDFDs in the
DFD model of a system. A data dictionary lists the purpose of all data itemsand the definition
of all composite data items in terms of their component data items. For example, a data
dictionary entry may represent that the data grossPay consists of thecomponents regularPay
and overtimePay.

Balancing a DFD
The data that flow into or out of a bubble must match the data flow at the next level of DFD.
This is known as balancing a DFD. The concept of balancing a DFDhas beenillustrated in fig.
5.3. In the level 1 of the DFD, data items d1 and d3 flow out of the bubble 0.1 and the data
item d2 flows into the bubble 0.1. In the next level, bubble 0.1isdecomposed. The
decomposition is balanced, as d1 and d3 flow out of the level 2diagram and d2 flows in
 PRACTICAL 8
AIM: Develop sequence diagram.
A sequence diagram is used primarily to show the interactions between objects that
arerepresented as lifelines in a sequential order.

Step 1:- Right click Sequence diagram on Diagram Navigator and select New Sequence Diagram
fromthepop-up menu to create a sequence diagram.

Step 2:- mEnter name for the newly created sequence diagram in the text field of pop-up box
on the top left corner .Page 23 of 49 Creating actor To create actor, click Actor on the
diagram toolbar and then

Creating lifeline
To create lifeline, you can click LifeLine on the diagram toolbar and then click on the
diagram. Alternatively, a much quicker and more efficient way is to use the resource-centric
interface. Clickonthe Message -> LifeLine resource beside an actor/lifeline and drag.
step 3:- Move the mouse to empty space of the diagram and then release the mouse button.
A newlifeline will becreated and connected to the actor/lifeline with a

Auto extending activation

When create message between lifelines

/actors, activation will be automatically extended.

Step 4:- Using sweeper and magnet to manage sequence diagram Sweeper helps you to move
shapes aside to make room for new shapes or connectors. To use sweeper, click Sweeper on the
diagram toolbar
Step 5:- You can also use magnet to pull shapes together. To use magnet, click Magnet
onthediagram toolbar

Click on empty space of the diagram and drag towards top, right, bottom or left. Shapes
affectedwill bepulled to the direction you dragged. The picture below shows when drag the
magnet upwards, shapes below dragged position are pulledupwards.

Step 6:- Creating combined fragment for messages To create combined fragment to cover
messages, select the messages, right-click on the selectionandselect Create Combined
Fragment, and then select a combined fragment type (e.g. loop) fromthe popup menu.
Step 7:- A combined fragment of selected type will be created to cover the messages.

Step 8:- Adding/removing covered lifelines After you've created a combined fragment on
the messages, you can add or remove the covered lifelines.
1. Move the mouse over the combined fragment and select Add/Remove Covered Lifeline...
fromthe pop-up menu.

2. In the Add/Remove Covered Lifelines dialog box, check the lifeline(s) you want to cover
or uncheck the lifeline(s) you don't want to cover. Click OK button.
3. As a result, the area of covered lifelines is extended or narrowed down according toyour
selection.

Managing Operands
After you've created a combined fragment on the messages, you can also add or remove
operand(s). 1. Move the mouse over the combined fragment and select Operand > Manage
Operands.fromthe pop-up menu

Step 9:-
1. To remove an operand, select the target operand from Operands and click Remove
button. ClickOK button.
2. Otherwise, click Add button to add a new operand and then name it. Click
OKbutton. Developing sequence diagram with quick editor or keyboard shortcuts In
sequence diagram, an editor appears at the bottom of diagram by default, which
enables youtoconstruct sequence diagram with the buttons there. The shortcut keys
assigned to the buttons provideaway to construct diagram through keyboard. Besides
constructing diagram, you can also access diagram elements listing in the editor.

There are two panes, Lifelines and Messages. The Lifelines pane enables you to
create different kinds of actors and lifelines.
Step 10:- Buttons in Lifelines pane Editing messages The Messages pane enables
you to connect lifelines with various kinds of messages.

Buttons in Messages pane.

Expanding and collapsing the editor To hide the editor, click on the down arrow
button that appears at the bar on top of the quick editor. Toexpand, click on the up
arrow button.
Collapse the quick editor
Setting different ways of numbering sequence messages You are able to set the way of
numbering sequence messages either on diagram base or frame base.

Diagram-based sequence message

Right click on the diagram's background, select Sequence Number and then either Single
Levelor Nested Level from the pop-up menu.

Step 11:- If you choose Single Level, all sequence messages will be ordered with integers
on diagrambase. Ontheother hand, if you choose Nested Level, all sequence messages will be
ordered with decimal placeondiagram base.
Right click on the diagram's background, select Sequence Number and then either Frame-
basedSingleLevel or Frame-based Nested Level from the pop-up menu.

When you set the way of numbering sequence messages on frame base, the sequence
messages inframewill restart numbering sequence message since they are independent and
ignore the way of numberingsequence message outside the frame.
 PRACTICAL 9
AIM: Develop Structured design for the DFD model developed.
A DFD model of a system graphically depicts the transformation of the data input
tothesystem to the final result through a hierarchy of levels. A DFD starts with the most
abstract definition of the system (lowest level) and at each higher level DFD, more details are
successively introduced. To develop a higher-level DFD model, processes are decomposed
input data to these functions and the data output by these functions and represent them
appropriately in the diagram.
If a system has more than 7 high- level functional requirements, then some of the related
requirements have to be combined and represented in the form of a bubble in the level 1DFD.
Such a bubble can be split in the lower DFD levels. If a system has less than three high-level
functional requirements, then some of them need to be split into their subfunctions so that we
have roughly about 5 to 7 bubbles on the diagram.

Decomposition:-
Each bubble in the DFD represents a function performed by the system. The bubbles are
decomposed into sub-functions at the successive levels of the DFD. Decomposition of a
bubble is also known as factoring or exploding a bubble. Each bubble at any level of DFD is
usually decomposed to anything between 3 to 7 bubbles. Too few bubbles at any level make
that level superfluous. For example, if a bubble is decomposed to just one bubble or two
bubbles, then this decomposition becomes redundant. Also, too many bubbles, i.e. more than
7 bubbles at any level of a DFD makes the DFD model hard to understand. Decomposition of
a bubble should be carried on until a level is reached at which the function of the bubble can
be described using a simple algorithm.

Numbering of Bubbles:-
It is necessary to number the different bubbles occurring in the DFD. These numbers help in
uniquely identifying any bubble in the DFD by its bubble number. The bubble at the context
level is usually assigned the number 0 to indicate that it is the 0 level DFD. Bubbles at level 1
are numbered, 0.1, 0.2, 0.3, etc. When a bubble numbered x is decomposed, its children
bubble are numbered x.1, x.2, x.3, etc. In this numbering scheme, by looking at the number of
a bubble we can unambiguously determine its level, its ancestors, and its successors.

Example:-
A supermarket needs to develop the following software to encourage regular customers. For
this, the customer needs to supply his/her residence address, telephone number, and the
driving license number. Each customer who registers for this scheme is assigned a unique
customer number (CN) by the computer. A customer can present his CN to the check out
staff when he makes any purchase. In this case, the value of his purchase is credited against
his CN. At the end of each year, the supermarket intends to award surprise gifts to 10
customers who make the highest total purchase over the year. Also, it intends to award a 22
caret gold coin to every customer whose purchase exceededRs.10,000. The entries against the
CN are the reset on the day of every year after the prize winners’ lists are generated .
 PRACTICAL 10
AIM: Develop the waterfall model, prototype model and spiral model of the
product.
Waterfall Model design
In "The Waterfall" approach, the entire process of software development is separated into
separate phases. In Waterfall model, typically, the outcome of one phase acts as the input for
the next phase sequentially. Following is a diagrammatic representation of different phases of
waterfall model.

Waterfall Model
The sequential phases in Waterfall model are:
 Requirement Gathering and analysis: All possible requirements of the system to be
developed are captured in this phase and documented in a requirement specification doc
known as RSR document.
 System Design: The requirement specifications from first phase are studied in this phase
and system design is prepared which can be unit or in various phases. Here we develop the
overall system architecture while specifying hardware and system requirements of the
system.
 Implementation: With inputs from system design, the system is first developed in small
programs called units, which are integrated in the next phase. Each unit is developed and
tested for its functionality which is referred to as Unit Testing.
 Integration and Testing: All the units developed in the implementation phase are integrated
into a system after testing of each unit. Post integration the entire system is tested for any
faults and failures.
 Deployment of system: Once the functional and non functional testing is done, the product
is deployed in the customer setting or released into the market.
  Maintenance: There are some issues which come up in the client environment. To fix those
issues patches are released.
Also to enhance the product some better versions are released. Maintenance is done to
deliver these changes in the customer environment. All these phases are cascaded to each
other in which progress is seen as flowing steadily downwards (like a waterfall) through the
phases. The next phase is started only after the defined set of goals are achieved for previous
phase and it is signed off, so the name "Waterfall Model". In this model phases do not
overlap.

Waterfall Model Application

Every software developed is different and requires a suitable SDLC approach to be followed
based on the internal and external factors. Some situations where the use of Waterfall model
is most appropriate are:
 Requirements are very well documented, clear and fixed.
 Product definition is stable.
 Technology is understood and is not dynamic.
 There are no ambiguous requirements.
 Ample resources with required expertise are available to support the product.
 The project is short.

Prototyping Model
Prototyping approach, also known as evolutionary approach, came to picture because of failures
that occurred in the final version of the software application developed using the waterfall
approach. The failure generally occurs because of the changes in the requirement of the proposed
system or because of the gap in understanding the user requirement by the development team.

A gap in the first version of the developed application, unavoidably leads to the need for redoing
the application. To overcome these limitations, the concept of prototyping was introduced.

Prototyping Approach
A prototype is the sample implementation of the system that shows limited and main functional
capabilities of the proposed system. After a prototype is built, it is delivered to the user for the
evaluation. The prototype helps the user determine how the feature will function in the final
software. The customer provides suggestion and improvements on the prototype.
 Prototype model
The development team implements the suggestion in the new prototype, which is again
evaluated by the user. The process continues until the user and the development team
understands the exact requirement of the proposed system .
When the final prototype is developed, the requirement is considered to be frozen. The
prototyping approach is used in the requirement gathering and in the analysis phase to capture
the exact requirement of the proposed system. After the requirements are frozen, the
remaining phases of the development process needs to be executed to complete the
development of the software system.

Need for a prototype in software development

There are several uses of a prototype. An important purpose is to illustrate the input data
formats, messages, reports, and the interactive dialogues to the customer. This is a valuable
mechanism for gaining better understanding of the customer’s needs:
• How the screens might look like
• How the user interface would behave
• How the system would produce outputs
This is something similar to what the architectural designers of a building do; they show a
prototype of the building to their customer. The customer can evaluate whether he likes it or
not and the changes that he would need in the actual product. A similar thing happens in the
case of a software product and its prototyping model. Another reason for developing a
prototype is that it is impossible to get the perfect product in the first attempt. Many
researchers and engineers advocate that if you want to develop a good product you must plan
to throw away the first version. The experience gained in developing the prototype can be
used to develop the final product.

Real time Application: Prototype model is like a making of an E-

COMMERCE WEBSITE where all the above specified phase is same like
1. An e-commerce website, such as shopping site is an example where you can implement the
prototyping approach.
 2. You can develop the prototype of the various web pages of the shopping site such as
catalogue page, product order page etc., and present it to the customer for approval.
3. If the customer approves the prototype of the site, requirements are states again and the
design of the web site is initiated.
4. If the customer does not approve the web site, the development team revisits the prototype
and resubmits it to the customer for approval.
5. This process continues until the prototype.

Spiral model
The spiral model is called a meta model since it encompasses all other life cycle models. Risk
handling is inherently built into this model. The Spiral model appears like a spiral with many
loops. The exact number of loops in the spiral is not fixed. Each loop of the spiral represents
a phase of the software process. Spiral Model includes the iterative nature of the prototyping
model and the linear nature of the waterfall model. This approach is ideal for developing
software that is revealed in various version[5] [6]s.In each iteration of the spiral approach,
software development process follows the phase-wise linear approach. At the end of first
iteration, the customer evaluates the software and provides the feedback. Based on the
feedback, software development process enters into the next iteration and subsequently
follows the linear approach to implement the feedback suggested by the customer. The
process of iteration continues throughout the life of the software.

Spiral Approach Phases

1. Customer Communication: Includes understanding the system requirements by continuous
communication between the customer and the system analyst.
2. Planning: Includes estimating Schedule, cost, and resource for the iteration.
3. Risk Analysis: includes identifying, estimating, and monitoring technical and management
risks, such as schedule slippage and cost overrun.
4. Engineering: Includes requirement gathering and design of the software system.
5. Construction and release: Includes coding, testing and deploying software at the customer
site and providing user-support documents.
6. Customer Evaluation: Includes evaluation of software by the customer and implementing
feedback in the next iteration of the software development.

a)First quadrant (Objective Setting)

• During the first quadrant, it is needed to identify the objectives of the phase.

• Examine the risks associated with these objectives.

b) Second Quadrant (Risk Assessment and Reduction)

• A detailed analysis is carried out for each identified project risk.
• Steps are taken to reduce the risks. For example, if there is a risk that the requirements are
inappropriate, a prototype system may be developed.

Spiral Model
c) Third Quadrant (Development and Validation)
• Develop and validate the next level of the product after resolving the identified risks.

d) Fourth Quadrant (Review and Planning)

• Review the results achieved so far with the customer and plan the next iteration around the
spiral.
• Progressively more complete version of the software gets built with each iteration around
the spiral.

Real time Application of spiral model :

Working on the missiles or satellites is the real time example of a spiral model. The risk
associated and cumulative costs both are the very important aspect of the missiles.
1. Understanding the basic requirements, need and goal is the first step of the spiral model.
2. Estimate the schedule, time, cost and the various resources to make the components or the
part of a missile is comes under the category of planning which is the second iteration of
spiral model .
3. Identifying, estimating, and monitoring various risks associated covered under risk
association.
4. Developing the final model based upon the approved requirements is the developing
iteration of the spiral model which is called Engineering which Includes requirement
gathering and design of the software system.
5. Includes coding and testing and launch of a missile is the most crucial iteration of spiral
model which is called Construction and release.
Last iteration is the Evaluation, feedback or the limitation or the success story of launching of
missile.
 PRACTICAL 11
AIM: Explain with reason which model is best suited for the product.
 PRACTICAL 12
AIM: Develop a working protocol of any of two problem
 PRACTICAL 13
AIM: Use LOC, FP and Cyclomatic Complexity Metric of above-
mentioned problem.