Software

Engineering
Software is a program or set of programs containing instructions that provide the desired functionality.

Engineering is the process of designing and building something that serves a particular purpose and finds a
cost-effective solution to problems.

Software Engineering is the process of designing, developing, testing, and maintaining software. It is a
systematic and disciplined approach to software development that aims to create high-quality, reliable, and
maintainable software.

There are four main Attributes of Software Engineering.

1. Efficiency: It provides a measure of the resource requirement of a software product efficiently.

2. Reliability: It assures that the product will deliver the same results when used in similar working environment.

3. Reusability: This attribute makes sure that the module can be used in multiple applications.

4. Maintainability: It is the ability of the software to be modified, repaired, or enhanced easily with changing
requirements.

Objectives of Software Engineering

1. Efficiency: The software should not make wasteful use of computing devices such as memory, processor cycles, etc.
2. Reusability: A software product has good reusability if the different modules of the product can easily
be reused to develop new products.
3. Testability: Here software facilitates both the establishment of test criteria and the evaluation of the software
concerning those criteria.
4. Reliability: It is an attribute of software quality. The extent to which a program can be expected to perform
its desired function, over an arbitrary time period.
5. Portability: In this case, the software can be transferred from one computer system or

Components of Software

There are three main components of the software:

1. Program: A computer program is a list of instructions that tell a computer what to do.

2. Documentation: Source information about the product contained in design documents, detailed code comments,
etc.

3. Operating Procedures: Set of step-by-step instructions compiled by an organization to help workers

carry out complex routine operations.

Software Crisis

The term “software crisis” refers to a set of problems that were faced by the software industry in the 1960s and 1970s, such
as:

1. Size and Cost: Day to day growing complexity and expectation out of software. Software are more expensive and
more complex.

2. Quality: Software products must have good quality.

3. Delayed Delivery: Software takes longer than the estimated time to develop, which in turn leads to cost shooting
up.
 4. High costs and long development times: software projects were taking much longer and costing much more than
expected.

5. Low quality: software was often delivered late, with bugs and other defects that made it difficult to use.

6. Lack of standardization: there were no established best practices or standards for software
development, making it difficult to compare and improve different approaches.

7. Lack of tools and methodologies: there were few tools and methodologies available to help with
software development, making it a difficult and time-consuming process.

These problems led to a growing realization that the traditional approaches to software development were not
effective and needed to be improved. This led to the development of new software development methodologies,
such as the Waterfall and Agile methodologies, as well as the creation of new tools and technologies to support
software development.

Software engg process- The software engineering process consists of activities for managing the creation of
software, including requirement collection, analysis, design, coding, testing, and maintenance. Software
engineering methods are just different ways of approaching software development and delivery.

Difference Between Software Engineering Process and Conventional Engineering Process

Aspect Software Engineering Process Conventional Engineering Process

Software Engineering Process is a process that The conventional Engineering Process is a

majorly involves computer science, information process that majorly involves science,
technology, and discrete mathematics. mathematics, and empirical knowledge.
Process

It is mainly related to computers, programming,

It is about building cars, machines, hardware,
and writing codes for building applications.
Focus Area buildings, etc.

In Software Engineering Process construction In Conventional Engineering Process

and development costs are low. construction and development cost is high.
Cost

It can involve the application of new and untested It usually applies only known and tested
Application elements in software projects. principles to meet product requirements.
 In the Software Engineering Process, most In Conventional Engineering Process, most
Development
development effort goes into building new designs development efforts are required to change old
Effort
and features. designs.

It majorly emphasizes quality. It majorly emphasizes mass production.

Emphasis

Product development develops intangible productsProduct development develops tangible products

Product Nature (software). (e.g. bridges, buildings).

Design Design requirements may change throughout theDesign Requirements are typically well-defined
Requirement development process. upfront.

Testing is an integral part of the developmentTesting occurs mainly after product completion.
Testing process.

Prototyping is common and helps to refinePrototyping is less common due to cost and time.
Prototyping requirements.

Maintenance and updates are necessary to keepMaintenance is typically scheduled or reactive.

Maintenance software relevant.

Software development often involves complex logicConventional engineering may have more complex
Complexity and algorithms. physical properties to deal with.

Software development often follows established Conventional engineering may have well-
Framework standards and frameworks. established regulations and standards.

Software development is typically less expensive to Conventional engineering may be more expensive
start, but costs may increase with maintenance andto start due to materials and construction but may
Cost Dynamics updates. have lower maintenance costs.

Similarities Between Software Engineering Process and Conventional Engineering Process

• Both Software Engineering and Conventional Engineering Processes become automated after some time.

• Both these processes are making our day-to-day place better.

• Both these processes have a fixed working time.

• Both processes must consist of deeper knowledge.

Software quality attributes

1. Portability: A software is claimed to be transportable, if it may be simply created to figure in several
package environments, in several machines, with alternative code merchandise, etc.
2. Usability: A software has smart usability if completely different classes of users (i.e. knowledgeable and
novice users) will simply invoke the functions of the merchandise.
3. Reusability: A software has smart reusability if completely different modules of the merchandise will
simply be reused to develop new merchandise.
4. Maintainability: A software is reparable, if errors may be simply corrected as and once they show up, new
functions may be simply added to the merchandise, and therefore the functionalities of the merchandise may
be simply changed, etc
5. Reliability: Software is more reliable if it has fewer failures. Since software engineers do not deliberately
plan for their software to fail, reliability depends on the number and type of mistakes they make. Designers
can improve reliability by ensuring the software is easy to implement and change, by testing it thoroughly,
and also by ensuring that if failures occur, the system can handle them or can recover easily.
6. Efficiency. The more efficient software is, the less it uses of CPU-time, memory, disk space, network
bandwidth, and other resources. This is important to customers in order to reduce their costs of running the
software, although with today’s powerful computers, CPU time, memory and disk usage are less of a
concern than in years gone by.

Software Development Life Cycle (SDLC)

Software development life cycle (SDLC) is a structured process that is used to design, develop, and test good-
quality software. SDLC, or software development life cycle, is a methodology that defines the entire procedure
of software development step-by-step.

The goal of the SDLC life cycle model is to deliver high-quality, maintainable software that meets the user’s
requirements. SDLC in software engineering models outlines the plan for each stage so that each stage of the
software development model can perform its task efficiently to deliver the software at a low cost within a given
time frame that meets users’ requirements.

SDLC is a process followed for software building within a software organization. SDLC consists of a
precise plan that describes how to develop, maintain, replace, and enhance specific software. The life cycle
defines a method for improving the quality of software and the all- around development process.

Stages of the Software Development Life Cycle

SDLC specifies the task(s) to be performed at various stages by a software engineer or developer. It ensures that
the end product is able to meet the customer’s expectations and fits within the overall budget. Hence, it’s vital
for a software developer to have prior knowledge of this software development process. SDLC is a collection of
these six stages, and the stages of SDLC are as follows:

Different SDLC models are:

1. Waterfall Model
Waterfall model is a famous and good version of SDLC(System Development Life Cycle) for software
engineering. The waterfall model is a linear and sequential model, which means that a development phase cannot
begin until the previous phase is completed. We cannot overlap phases in waterfall model, once one phase of
development is completed then we move to the next phase but cannot go back to the previous phase. In the
waterfall model, the output of one phase serves as the input for the other phase.

Phases of Waterfall model

1. Requirement phase:- Requirement phase is the first phase of the waterfall model. In this phase the
requirements of the system are collected and documented. This phase is very crucial because the next
phases are based on this phase.

2. Design phase:- Design phase is based on the fact how the software will be built. The main objective of
the design phase is to prepare the blueprint of the software system so that no problems are faced in the
coming phases and solutions to all the requirements in the requirement phase are found.

3. Implementation phase:- In this phase, hardware, software and application programs are installed and
the database design is implemented. Before the database design can be implemented, the software has
to go through a testing, coding, and debugging process. This is the longest lasting phase in waterfall.

4. Verification phase:- In this phase the software is verified and it is evaluated that we have created the
right product. In this phase, various types of testing are done and every area of the software is checked.
It is believed that if we do not verify the software properly and there is any defect in it then no one will
use it, hence verification is very important. One advantage of verification is that it reduces the risk of
software failure.

5. Maintenance phase:- This is the last phase of waterfall. When the system is ready and users start
using it, then the problems that arise have to be solved time-to-time. Taking care of the finished
software and maintaining it as per time is called maintenance.

Advantages of Waterfall Model

• This model is simple and easy to understand.

• This is very useful for small projects.

• This model is easy to manage.

• The end goal is determined early.

• Each phase of this model is well explained.

• It provides a structured way to do things.

Disadvantages of Waterfall Model

• In this model, complete and accurate requirements are expected at the beginning of the development process.

• Working software is not available for very long during the development life cycle.

• We cannot go back to the previous phase due to which it is very difficult to change the requirements.

• Risk is not assessed in this, hence there is high risk and uncertainty in this model.

• In this the testing period comes very late.

 • Due to its sequential nature this model is not realistic in today’s world.

• This is not a good model for large and complex projects.

Prototype model
Prototype model is an activity in which prototypes of software applications are created. First a prototype is
created and then the final product is manufactured based on that prototype.

• The prototype model was developed to overcome the shortcomings of the waterfall model.

• This model is created when we do not know the requirements well.

• The specialty of this model is that this model can be used with other models as well as alone.

One problem in this model is that if the end users are not satisfied with the prototype model, then a new prototype
model is created again, due to which this model consumes a lot of money and time.

The prototype model has the following phases

• Requirement gathering: The first step of prototype model is to collect the requirements, although the
customer does not know much about the requirements but the major requirements are defined in detail.

• Build the initial prototype: In this phase the initial prototype is built. In this some basic requirements
are displayed and user interface is made available.

• Review the prototype: When the construction of the prototype is completed, it is presented to the end
users or customer and feedback is taken from them about this prototype. This feedback is used to
further improve the system and possible changes are made to the prototype.

• Revise and improve the prototype: When feedback is taken from end users and customers, the
prototype is improved on the basis of feedback. If the customer is not satisfied with the prototype, a
new prototype is created and this process continues until the customer gets the prototype as per his
desire.

Advantages of Prototype model

• Prototype Model is suggested to create applications whose prototype is very easy and which always
includes human machine interaction within it.

• When we know only the general objective of creating software, but we do not know anything in detail
about input, processing and output. Then in such a situation we make it a Prototype Model.
• When a software developer is not very sure about the capability of an algorithm or its adaptability to an
operating system, then in this situation, using a prototype model can be a better option.

Disadvantages of Prototype model

• When the first version of the prototype model is ready, the customer himself often wants small fixes
and changes in it rather than rebuilding the system. Whereas if the system is redesigned then more
quality will be maintained in it.
 • Many compromises can be seen in the first version of the Prototype Model.

• Sometimes a software developer may make compromises in his implementation, just to get the
prototype model up and running quickly, and after some time he may become comfortable with making
such compromises and may forget that it is completely inappropriate to do so.

Spiral Model
Spiral model is a software development process model. This model has characteristics of both iterative and
waterfall models. This model is used in projects which are large and complex. This model was named spiral
because if we look at its figure, it looks like a spiral, in which a long curved line starts from the center point and
makes many loops around it.

A software project goes through these loops again and again in iterations. After each iteration a more and more
complete version of the software is developed. The most special thing about this model is that risks are identified
in each phase and they are resolved through prototyping. This feature is also called Risk Handling.

Since it also includes the approaches of other SDLC models, it is also called Meta Model. It was first developed by Barry
Boehm in 1986.

In Spiral Model the entire process of software development is described in four phases which are repeated until the project
is completed.

Those phases are as follows:-

• Determining objectives and alternate solutions: In the first phase, whatever requirements the customer
has related to the software are collected. On the basis of which objectives are identified and analysed
and various alternative solutions are proposed.

• Identifying and resolving risks: In this phase, all the proposed solutions are assessed and the best
solution is selected. Now that solution is analyzed and the risks related to it are identified. Now the
identified risks are resolved through some best strategy.

• Develop and test: Now the development of software is started. In this phase various features are
implemented, that is, their coding is done. Then those features are verified through testing.

• Review and plan for the next phase: In this phase the developed version of the software is given to the
customer and he evaluates it. Gives his feedback and tells new requirements. Finally planning for the
next phase (next spiral) is started.

Advantages of Spiral Model

• If we have to add additional functionality or make any changes to the software, then through this model
we can do so in the later stages also.

• Spiral model is suitable for large and complex projects.

• It is easy to estimate how much the project will cost.

 • Risk analysis is done in each phase of this model.

• The customer can see the look of his software only in the early stages of the development process.

• Since continuous feedback is taken from the customer during the development process, the chances
of customer satisfaction increases.

Disadvantage of Spiral Model

• This is the most complex model of SDLC, due to which it is quite difficult to manage.

• This model is not suitable for small projects.

• The cost of this model is quite high.

• It requires more documentation than other models.

• Experienced experts are required to evaluate and review the project from time to time.

• Using this model, the success of the project depends greatly on the risk analysis phase.

Evolutionary Model – Software Engineering

The Evolutionary development model divides the development cycle into smaller, incremental waterfall models
in which users can get access to the product at the end of each cycle.

1. Feedback is provided by the users on the product for the planning stage of the next cycle and the
development team responds, often by changing the product, plan, or process.

2. Therefore, the software product evolves with time.

3. All the models have the disadvantage that the duration of time from the start of the project to the
delivery time of a solution is very high.

4. The evolutionary model solves this problem with a different approach.

5. The evolutionary model suggests breaking down work into smaller chunks, prioritizing them, and then
delivering those chunks to the customer one by one.

6. The number of chunks is huge and is the number of deliveries made to the customer.

7. The main advantage is that the customer’s confidence increases as he constantly gets quantifiable
goods or services from the beginning of the project to verify and validate his requirements.

8. The model allows for changing requirements as well as all work is broken down into maintainable work chunks.

Application of Evolutionary Model

1. It is used in large projects where you can easily find modules for incremental implementation.
Evolutionary model is commonly used when the customer wants to start using the core features instead
of waiting for the full software.
 2. Evolutionary model is also used in object oriented software development because the system can be
easily portioned into units in terms of objects.

Necessary Conditions for Implementing this Model

1. Customer needs are clear and been explained in deep to the developer team.

2. There might be small changes required in separate parts but not a major change.

3. As it requires time, so there must be some time left for the market constraints.

4. Risk is high and continuous targets to achieve and report to customer repeatedly.

5. It is used when working on a technology is new and requires time to learn.

Advantages Evolutionary Model

1. Adaptability to Changing Requirements: Evolutionary models work effectively in projects when the
requirements are ambiguous or change often. They support adjustments and flexibility along the course
of development.

2. Early and Gradual Distribution: Functional components or prototypes can be delivered early thanks to
incremental development. Faster user satisfaction and feedback may result from this.

3. User Commentary and Involvement: Evolutionary models place a strong emphasis on ongoing user
input and participation. This guarantees that the software offered closely matches the needs and
expectations of the user.

4. Improved Handling of Difficult Projects: Big, complex tasks can be effectively managed with the
help of evolutionary models. The development process is made simpler by segmenting the project into
smaller, easier-to-manage portions.

Disadvantages Evolutionary Model

1. Communication Difficulties: Evolutionary models require constant cooperation and communication.

The strategy may be less effective if there are gaps in communication or if team members are spread
out geographically.

2. Dependence on an Expert Group: A knowledgeable and experienced group that can quickly adjust
to changes is needed for evolutionary models. Teams lacking experience may find it difficult to handle
these model’s dynamic nature.
3. Increasing Management Complexity: Complexity can be introduced by organizing and managing
several increments or iterations, particularly in large projects. In order to guarantee integration and
synchronization, good project management is needed.

4. Greater Initial Expenditure: As evolutionary models necessitate continual testing, user feedback and
prototyping, they may come with a greater starting cost. This may be a problem for projects that have
limited funding.

Iterative Model
In Iterative model we start developing the software with some requirements and when it is developed, it is
reviewed. If there are requirements for changes in it, then we develop a new version of the software based on
those requirements. This process repeats itself many times until we get our final product.

• So, in Iterative model a software is developed by following several iterations. Iteration means that we are
repeating the development process again and again. For example, we develop the first version of the
software following the SDLC process with some software requirements.

• After the first version is developed, if there is a need to change the software , then a new version is
developed with the second iteration. Now again we will see if the new version is enough, if not then we
will make changes in it with the third iteration. The iteration will be repeated until the complete
 software is ready.

• The basic concept of Iterative model is that the software should be developed through repeated cycles or
what we also call iteration and only a small part of it should be developed at a time. This model was
developed to overcome the drawbacks of the classical waterfall model.

Through this diagram you can understand the Interactive model.

Phases of iterative model

1. Requirement gathering & analysis: In this phase, all the software requirements of the customer are
collected and it is analyzed whether those requirements can be meet or not. Besides, it is also checked
whether this project will not go beyond our budget.

2. Design: In this phase the design of software is prepared. For this, various diagrams like Data Flow
diagram, class diagram, activity diagram, state transition diagram, etc. are used.

3. Implementation: Now the design of software is implemented in coding through various programming
languages. We also call this coding phase.

4. Testing: After the coding of the software is done, it is now tested so that the bugs and errors present in
it can be identified. To do this, various testing techniques like performance testing, security testing,
requirement testing, stress testing, etc. are done.

5. Deployment: Finally the software is given to the customer. After this the customer starts using that
software in his work environment.

6. Review: After the software is deployed in its work environment, it is reviewed. If any error/bug is found
or any new requirements come in front of developer, then again these phases are repeated with new
iteration and a new version is developed.

7. Maintenance: In this phase we look at customer feedback, solve problems, fix errors, update software, etc.

Advantage of Iterative model

• In iterative models, bugs and errors can be identified quickly.

• Under this model, software is prepared quickly with some specifications.

• Testing and debugging the software becomes easier during each iteration.

• We get reliable feedback from users along with blueprints.

• This model is easily adaptable to constantly changing needs.

• During the software development process, additional time is devoted to development and limited time to
documentation.

• Risks are identified and resolved during iteration.

Disadvantage of Iterative model

• Iterative model is not suitable for small projects.

• Since we have to repeat iterations many times in the software development process due to which we require more
resources.
 • Since the requirements are constantly changing, we have to make frequent changes in the software.

• Due to constantly changing requirements, the budget of the project also increases and it takes more time to
complete it.

• In this model, it is complicated to control the entire process of software development.

• It is very difficult to tell by what date the complete software will be ready.

Agile Model
Agile model is a combination of iterative and incremental models, that is, it is made up of iterative and incremental models.

• In Agile model, focus is given to process adaptability and customer satisfaction.

• In earlier times, iterative waterfall model was used to create software. But in today’s time developers
have to face many problems. The biggest problem is that in the middle of software development, the
customer asks to make changes in the software. It takes a lot of time and money to make these changes.

So to overcome all these shortcomings, the agile model was proposed in the 1990s.

The agile model was created mainly to make changes in the middle of software development so that the software
project can be completed quickly.

• In the agile model, the software product is divided into small incremental parts. In this, the smallest part
is developed first and then the larger one.

• And each incremental part is developed over iteration.

• Each iteration is kept small so that it can be easily managed. And it can be completed in two-three
weeks. Only one iteration is planned, developed and deployed at a time.

Principles of Agile model

• There is a customer representative in the development team to maintain contact with the customer during
software development and to understand the requirement. When an iteration is completed, stakeholders
and customer representatives review it and re-evaluate the requirements.

• Demo of working software is given to understand the customer’s requirements. That is, it does not depend only on
documentation.

• Incremental versions of the software have to be delivered to the customer representative after a few weeks.
• In this model it is advised that the size of the development team should be small (5 to 9 people) so that
the team members can communicate face to face.
• Agile model focuses on the fact that whenever any changes have to be made in the software, it should be
completed quickly.

• In agile development, two programmers work together. One programmer does the coding and the other
reviews that code. Both the programmers keep changing their tasks, that is, sometimes one does coding
and sometimes someone reviews.
Agile has the following models

1. Scrum

2. Crystal methods

3. DSDM

4. Feature driven development (FDD

5. Lean software development

6. Extreme programming (xp)

Advantages of Agile Model

• In this, two programmers work together due to which the code is error free and there are very few mistakes in it.

• In this the software project is completed in a very short time.

• In this the customer representative has an idea of each iteration so that he can easily change the requirement.

• This is a very realistic approach to software development.

• In this, focus is given on teamwork.

• There are very few rules in this and documentation is also negligible.

• There is no need for planning in this.

• It can be managed easily.

• It provides flexibility to developers.

Disadvantages of Agile Model

• It cannot handle complex dependencies.

• Due to lack of formal documentation in this, there is confusion in development.

• It mostly depends on the customer representative, if the customer representative gives any wrong
information then the software can become wrong.

• Only experienced programmers can take any decision in this. New programmers cannot take any decision.

• In the beginning of software development, it is not known how much effort and time will be required to create the
software.

UNIT - 2
Requirements Engineering
A systematic and strict approach to the definition, creation, and verification of requirements for a software system is
known as requirements engineering. To guarantee the effective creation of a software product, the requirements
engineering process entails several tasks that help in understanding, recording, and managing the demands of
stakeholders.
Requirements Engineering Process
 Requirements Engineering Process
1. Feasibility Study
2. Requirements elicitation
3. Requirements specification
4. Requirements for verification and validation
5. Requirements management

1. Feasibility Study
The feasibility study mainly concentrates on below five mentioned areas below. Among these Economic Feasibility Study
is the most important part of the feasibility analysis and the Legal Feasibility Study is less considered feasibility analysis.
i. Technical Feasibility: In Technical Feasibility current resources both hardware software along required
technology are analyzed/assessed to develop the project.
ii. Operational Feasibility: In Operational Feasibility degree of providing service to requirements is analyzed along
with how easy the product will be to operate and maintain after deployment.
iii. Economic Feasibility: In the Economic Feasibility study cost and benefit of the project are analyzed. This means
under this feasibility study a detailed analysis is carried out will be cost of the project for development which
includes all required costs for final development hardware and software resources required, design and
development costs operational costs, and so on. After that, it is analysed whether the project will be beneficial in
terms of finance for the organization or not.
iv. Legal Feasibility: In legal feasibility, the project is ensured to comply with all relevant laws, regulations, and
standards. It identifies any legal constraints that could impact the project and reviews existing contracts and
agreements to assess their effect on the project’s execution. Additionally, legal feasibility considers issues related
to intellectual property, such as patents and copyrights, to safeguard the project’s innovation and originality.
v. Schedule Feasibility: In schedule feasibility, the project timeline is evaluated to determine if it is realistic and
achievable, deadlines are established to track progress effectively. Resource availability is assessed to ensure that
the necessary resources are accessible to meet the project schedule. Furthermore, any time constraints that might
affect project delivery are considered to ensure timely completion. This focus on schedule feasibility is crucial for
the successful planning and execution of a project.

2. Requirements Elicitation
Requirements elicitation is the process of gathering information about the needs and expectations of stakeholders for a
software system. This is the first step in the requirements engineering process and it is critical to the success of the software
development project. The goal of this step is to understand the problem that the software system is intended to solve and the
needs and expectations of the stakeholders who will use the system.
3. Requirements Specification
Requirements specification is the process of documenting the requirements identified in the analysis step in a clear,
consistent, and unambiguous manner. The goal of this step is to create a clear and comprehensive document that describes
the requirements for the software system. This document should be understandable by both the development team and the
stakeholders.
4. Requirements Verification and Validation
Requirements verification and validation (V&V) is the process of checking that the requirements for a software system are
complete, consistent, and accurate and that they meet the needs and expectations of the stakeholders. The goal of V&V is to
ensure that the software system being developed meets the requirements and that it is developed on time, within budget, and
to the required quality.
5. Requirements Management
Requirements management is the process of managing the requirements throughout the software development life cycle,
including tracking and controlling changes, and ensuring that the requirements are still valid and relevant. The goal of
requirements management is to ensure that the software system being developed meets the needs and expectations of the
stakeholders and that it is developed on time, within budget, and to the required quality.
Advantages of Requirements Engineering Process

• Helps ensure that the software being developed meets the needs and expectations of the stakeholders

• Can help identify potential issues or problems early in the development process, allowing for adjustments to be
made before significant

• Helps ensure that the software is developed in a cost-effective and efficient manner

• Can improve communication and collaboration between the development team and stakeholders

• Helps to ensure that the software system meets the needs of all stakeholders.

• Provides an unambiguous description of the requirements, which helps to reduce misunderstandings and errors.

• Helps to identify potential conflicts and contradictions in the requirements, which can be resolved before the
software development process begins.

• Helps to ensure that the software system is delivered on time, within budget, and to the required quality standards.

• Provides a solid foundation for the development process, which helps to reduce the risk of failure.
Disadvantages of Requirements Engineering Process

• Can be time-consuming and costly, particularly if the requirements-gathering process is not well-managed

• Can be difficult to ensure that all stakeholders’ needs and expectations are taken into account

• It Can be challenging to ensure that the requirements are clear, consistent, and complete

• Changes in requirements can lead to delays and increased costs in the development process.

• As a best practice, Requirements engineering should be flexible, adaptable, and should be aligned with the overall
project goals.

• It can be time-consuming and expensive, especially if the requirements are complex.

• It can be difficult to elicit requirements from stakeholders who have different needs and priorities.

• Requirements may change over time, which can result in delays and additional costs.

• There may be conflicts between stakeholders, which can be difficult to resolve.

• It may be challenging to ensure that all stakeholders understand and agree on the requirements.

Feasibility Study
In software engineering, a feasibility study entails planning and evaluating every facet of a project before moving forward.
The procedure entails gathering information and assessing various project components in light of predetermined financial
and schedule limitations standards. After evaluating all project-related factors, participants will come to a consensus on
whether or not it is possible to finish this project within the allocated time frame and budget constraints. Participants will
plan how to finish the project after deciding whether it is feasible. This will involve creating documentation for each
process step using modeling techniques for software system design, dynamic flow mapping for computer application flow
design, and other techniques.
Feasibility studies can be carried out to determine the proposed project's future scope to validate this idea. Since it is
universal, it applies to all industries, and in particular, it provides a more promising future for the software engineering and
development sectors.
A feasibility study determines whether a software project will be viable. Whether a project is feasible depends largely on
how it will function in the market, what will work, what competitors have produced, and how long this product will last.

DFD(Data Flow Diagram)

Data Flow Diagram (DFD) represents the flow of data within information systems. Data Flow Diagrams (DFD) provide a
graphical representation of the data flow of a system that can be understood by both technical and non-technical users. The
models enable software engineers, customers, and users to work together effectively during the analysis and specification of
requirements.
It also gives insight into the inputs and outputs of each entity and the process itself. Data Flow Diagram (DFD) does not
have a control flow and no loops or decision rules are present. Specific operations, depending on the type of data, can be
explained by a flowchart. It is a graphical tool, useful for communicating with users, managers and other personnel. it is
useful for analyzing existing as well as proposed systems.
Characteristics of Data Flow Diagram (DFD)

• Graphical Representation: Data Flow Diagram (DFD) use different symbols and notation to represent data flow
within system. That simplify the complex model.

• Problem Analysis: Data Flow Diagram (DFDs) are very useful in understanding a system and can be effectively
used during analysis. Data Flow Diagram (DFDs) are quite general and are not limited to problem analysis for
software requirements specification.

• Abstraction: Data Flow Diagram (DFD) provides a abstraction to complex model i.e. DFD hides unnecessary
implementation details and show only the flow of data and processes within information system.

• Hierarchy: Data Flow Diagram (DFD) provides a hierarchy of a system. High- level diagram i.e. 0-level diagram
provides an overview of entire system while lower-level diagram like 1-level DFD and beyond provides a detailed
data flow of individual process.

• Data Flow: The primary objective of Data Flow Diagram (DFD) is to visualize the data flow between external
entity, processes and data store. Data Flow is represented by an arrow Symbol.

• Ease of Understanding: Data Flow Diagram (DFD) can be easily understand by both technical and non-technical
stakeholders.

• Modularity: Modularity can be achieved using Data Flow Diagram (DFD) as it breaks the complex system into
smaller module or processes. This provides easily analysis and design of a system.
Types of Data Flow Diagram (DFD)
There are two types of Data Flow Diagram (DFD)
1. Logical Data Flow Diagram
2. Physical Data Flow Diagram
Logical Data Flow Diagram (DFD)
Logical data flow diagram mainly focuses on the system process. It illustrates how data flows in the system. Logical Data
Flow Diagram (DFD) mainly focuses on high level processes and data flow without diving deep into technical
implementation details. Logical DFD is used in various organizations for the smooth running of system. Like in a Banking
software system, it is used to describe how data is moved from one entity to another.
Physical Data Flow Diagram
Physical data flow diagram shows how the data flow is actually implemented in the system. In the Physical Data Flow
Diagram (DFD), we include additional details such as data storage, data transmission, and specific technology or system
components. Physical DFD is more specific and closer to implementation.
Components of Data Flow Diagrams (DFD)
The Data Flow Diagram has 4 components:

• Process: Input to output transformation in a system takes place because of process function. The symbols of a
process are rectangular with rounded corners, oval, rectangle or a circle. The process is named a short sentence, in
one word or a phrase to express its essence

• Data Flow: Data flow describes the information transferring between different parts of the systems. The arrow
symbol is the symbol of data flow. A relatable name should be given to the flow to determine the information
which is being moved. Data flow also represents material along with information that is being moved. Material
shifts are modeled in systems that are not merely informative. A given flow should only transfer a single type of
information. The direction of flow is represented by the arrow which can also be bi-directional.

• Warehouse (Data Store) : The data is stored in the warehouse for later use. Two horizontal lines represent the
symbol of the store. The warehouse is simply not restricted to being a data file rather it can be anything like a
folder with documents, an optical disc, a filing cabinet. The data warehouse can be viewed independent of its
implementation. When the data flow from the warehouse it is considered as data reading and when data flows to
the warehouse it is called data entry or data updating.

• Terminator (External Entity): The Terminator is an external entity that stands outside of the system and
communicates with the system. It can be, for example, organizations like banks, groups of people like customers or
different departments of the same organization, which is not a part of the model system and is an external entity.
Modelled systems also communicate with terminator.

Levels in Data Flow Diagram (DFD)

DFDs can be divided into different levels, which provide varying degrees of detail about the system. The following are the
four levels of DFDs:
1. Level 0 DFD
2. Level 1 DFD
3. Level 2 DFD
4. Level 3 DFD
The choice of DFD level depends on the complexity of the system and the level of detail required to understand the system.
Higher levels of DFD provide a broad overview of the system, while lower levels provide more detail about the system’s
processes, data flows, and data stores. A combination of different levels of DFD can provide a complete understanding of
the system.
Level 0 Data Flow Diagram (DFD)
Level 0 is the highest-level Data Flow Diagram (DFD), which provides an overview of the entire system. It shows the
major processes, data flows, and data stores in the system, without providing any details about the internal workings of
these processes.
It is also known as a context diagram. It’s designed to be an abstraction view, showing the system as a single process with
its relationship to external entities. It represents the entire system as a single bubble with input and output data indicated by
incoming/outgoing arrows.

1-Level Data Flow Diagram (DFD)

1-Level provides a more detailed view of the system by breaking down the major processes identified in the level 0 Data
Flow Diagram (DFD) into sub-processes. Each sub-process is depicted as a separate process on the level 1 Data Flow
Diagram (DFD). The data flows and data stores associated with each sub-process are also shown.
In 1-level Data Flow Diagram (DFD), the context diagram is decomposed into multiple bubbles/processes. In this level, we
highlight the main functions of the system and breakdown the high-level process of 0-level Data Flow Diagram (DFD) into
subprocesses.

2-Level Data Flow Diagram (DFD)

2-Level provides an even more detailed view of the system by breaking down the sub-processes identified in the level 1
Data Flow Diagram (DFD) into further sub-processes. Each sub-process is depicted as a separate process on the level 2
DFD. The data flows and data stores associated with each sub-process are also shown.
2-Level Data Flow Diagram (DFD) goes one step deeper into parts of 1-level DFD. It can be used to plan or record the
specific/necessary detail about the system’s functioning.

3-Level Data Flow Diagram (DFD)

3-Level is the most detailed level of Data Flow Diagram (DFDs), which provides a detailed view of the processes, data
flows, and data stores in the system. This level is typically used for complex systems, where a high level of detail is
required to understand the system. Each process on the level 3 DFD is depicted with a detailed description of its input,
processing, and output. The data flows and data stores associated with each process are also shown.
Advantages of using Data Flow Diagrams (DFD)
Following are the Advantage of Data Flow Diagram (DFD) :
1. Easy to understand: DFDs are graphical representations that are easy to understand and communicate, making
them useful for non-technical stakeholders and team members.
2. Improves system analysis: DFDs are useful for analyzing a system’s processes and data flow, which can help
identify inefficiencies, redundancies, and other problems that may exist in the system.
3. Supports system design: DFDs can be used to design a system’s architecture and structure, which can help ensure
that the system is designed to meet the requirements of the stakeholders.
4. Enables testing and verification: DFDs can be used to identify the inputs and outputs of a system, which can
help in the testing and verification of the system’s functionality.
5. Facilitates documentation: DFDs provide a visual representation of a system, making it easier to document and
maintain the system over time.
Disadvantages of using Data Flow Diagram (DFD)
Following are the Disadvantage of Data Flow Diagram (DFD) :
1. Can be time-consuming: Creating DFDs can be a time-consuming process, especially for complex systems.
2. Limited focus: DFDs focus primarily on the flow of data in a system, and may not capture other important aspects
of the system, such as user interface design, system security, or system performance.
3. Can be difficult to keep up-to-date: DFDs may become out-of-date over time as the system evolves and changes.
4. Requires technical expertise: While DFDs are easy to understand, creating them requires a certain level of
technical expertise and familiarity with the system being analyzed.

Flow Chart
A Flowchart is a diagrammatic representation of an algorithm. Sometimes programmers use it as a program planning tool to
solve a problem. It makes use of symbols that are connected among them to indicate the flow of information and
processing. It is a convenient technique to represent a program’s control flow.

Flowchart is a graphical representation of an algorithm. Programmers often use it as a program-planning tool to solve a
problem. It makes use of symbols which are connected among them to indicate the flow of information and processing.
The process of drawing a flowchart for an algorithm is known as “flowcharting”.
Basic Symbols used in Flowchart Designs
1. Terminal: The oval symbol indicates Start, Stop and Halt in a program’s logic flow. A pause/halt is generally
used in a program logic under some error conditions. Terminal is the first and last symbols in the flowchart.

2. Input/Output: A parallelogram denotes any function of input/output type. Program instructions that take input
from input devices and display output on output devices are indicated with parallelogram in a flowchart.
 3. Processing: A box represents arithmetic instructions. All arithmetic processes such as adding, subtracting,
multiplication and division are indicated by action or process symbol.

4. Decision Diamond symbol represents a decision point. Decision based operations such as yes/no question or
true/false are indicated by diamond in flowchart.

5. Connectors: Whenever flowchart becomes complex or it spreads over more than one page, it is useful to use
connectors to avoid any confusions. It is represented by a circle.

6. Flow lines: Flow lines indicate the exact sequence in which instructions are executed. Arrows represent the
direction of flow of control and relationship among different symbols of flowchart.

Rules For Creating Flowchart :

A flowchart is a graphical representation of an [Link] should follow some rules while creating a flowchart
Rule 1: Flowchart opening statement must be ‘start’ keyword.
Rule 2: Flowchart ending statement must be ‘end’ keyword.
Rule 3: All symbols in the flowchart must be connected with an arrow line.
Rule 4: The decision symbol in the flowchart is associated with the arrow line.

Advantages of Flowchart:

• Flowcharts are a better way of communicating the logic of the system.

• Flowcharts act as a guide for blueprint during program designed.

• Flowcharts help in debugging process.

• With the help of flowcharts programs can be easily analyzed.

• It provides better documentation.

• Flowcharts serve as a good proper documentation.

• Easy to trace errors in the software.

• Easy to understand.

• The flowchart can be reused for inconvenience in the future.

• It helps to provide correct logic.

Disadvantages of Flowchart:
• It is difficult to draw flowcharts for large and complex programs.

• There is no standard to determine the amount of detail.

• Difficult to reproduce the flowcharts.

• It is very difficult to modify the Flowchart.

• Making a flowchart is costly.

• Some developer thinks that it is waste of time.

• It makes software processes low.

• If changes are done in software, then the flowchart must be redrawn

Difference Between Flowchart and Data Flow Diagram

Flow Chart Data Flow Diagram (DFD)

The main objective is to represent the flow of control in The main objective is to represent the processes and
the program. data flow between them.

It has only a single type of arrow is used to show the It defines the flow and process of data input, data
control flow in the flow chart. output, and storing data.

It is the view of the system at a lower level. It is the view of the system at a high level.

Three symbols represent a Flowchart. Five symbols represent a DFD

It deals with the physical aspect of the action. It deals with the logical aspect of the action.

It shows how to make the system function. It defines the functionality of the system.

It is not very suitable for a complex system. It is used for complex systems.

Entity-Relationship Diagrams
ER-modeling is a data modeling method used in software engineering to produce a conceptual data model of an information
system. Diagrams created using this ER-modeling method are called Entity-Relationship Diagrams or ER diagrams or
ERDs.
Purpose of ERD
o The database analyst gains a better understanding of the data to be contained in the database through the step of
constructing the ERD.
o The ERD serves as a documentation tool.
o Finally, the ERD is used to connect the logical structure of the database to users. In particular, the ERD effectively
communicates the logic of the database to users
Symbols Used in ER Model

Components of ER Diagram
ER Model consists of Entities, Attributes, and Relationships among Entities:

Software Requirement Specification (SRS):

A software requirements specification (SRS) is a detailed description of a software system to be developed with its
functional and non-functional requirements. The SRS is developed based the agreement between customer and contractors.
It may include the use cases of how user is going to interact with software system. The software requirement specification
document consistent of all necessary requirements required for project development. To develop the software system we
should have clear understanding of Software system. To achieve this we need to continuous communication with customers
to gather all requirements. A good SRS defines the how Software System will interact with all internal modules, hardware,
communication with other programs and human user interactions with wide range of real life scenarios. Using the Software
requirements specification (SRS) document on QA lead, managers creates test plan. It is very important that testers must be
cleared with every detail specified in this document in order to avoid faults in test cases and its expected results. It is highly
recommended to review or test SRS documents before start writing test cases and making any plan for testing. Let’s see
how to test SRS and the important point to keep in mind while testing it.
Characteristics of good SRS
1. Correctness:
User review is used to ensure the correctness of requirements stated in the SRS. SRS is said to be correct if it
covers all the requirements that are actually expected from the system.
2. Completeness:
Completeness of SRS indicates every sense of completion including the numbering of all the pages, resolving the
to be determined parts to as much extent as possible as well as covering all the functional and non-functional
requirements properly.
3. Consistency:
Requirements in SRS are said to be consistent if there are no conflicts between any set of requirements. Examples
of conflict include differences in terminologies used at separate places, logical conflicts like time period of report
generation, etc.
4. Unambiguous:
A SRS is said to be unambiguous if all the requirements stated have only 1 interpretation. Some of the ways to
prevent unambiguousness include the use of modelling techniques like ER diagrams, proper reviews and buddy
checks, etc.
5. Ranking for importance and stability:
There should a criterion to classify the requirements as less or more important or more specifically as desirable or
essential. An identifier mark can be used with every requirement to indicate its rank or stability.
 6. Modifiability:
SRS should be made as modifiable as possible and should be capable of easily accepting changes to the system to
some extent. Modifications should be properly indexed and cross-referenced.
7. Verifiability:
A SRS is verifiable if there exists a specific technique to quantifiably measure the extent to which every
requirement is met by the system. For example, a requirement starting that the system must be user-friendly is not
verifiable and listing such requirements should be avoided.
8. Traceability:
One should be able to trace a requirement to design component and then to code segment in the program.
Similarly, one should be able to trace a requirement to the corresponding test cases.
9. Design Independence:
There should be an option to choose from multiple design alternatives for the final system. More specifically, the
SRS should not include any implementation details.
10. Testability:
A SRS should be written in such a way that it is easy to generate test cases and test plans from the document.
11. Understandable by the customer:
An end user maybe an expert in his/her specific domain but might not be an expert in computer science. Hence, the
use of formal notations and symbols should be avoided to as much extent as possible. The language should be kept
easy and clear.
12. Right level of abstraction:
If the SRS is written for the requirements phase, the details should be explained explicitly. Whereas, for a
feasibility study, fewer details can be used. Hence, the level of abstraction varies according to the purpose of the
SRS.

Advantages of having a good Software Requirements Specification (SRS) document include:

1. Improved communication and understanding between stakeholders and developers, as the SRS clearly defines the
requirements for the software system
2. Increased efficiency in the software development process, as a well-written SRS can help to reduce the need for
rework and change requests
3. Improved quality of the final software system, as a well-written SRS helps to ensure that all requirements are met
4. Increased stakeholder satisfaction, as a well-written SRS helps to ensure that the software system meets the needs
of the business and its users
5. Improved traceability and verifiability, as a well-written SRS can be traced to other documents and artifacts and its
requirements can be tested and validated.
6. Clarity and Completeness: A good SRS document provides clear and complete specifications for the software
project, which ensures that all stakeholders have a common understanding of the requirements and objectives.

7. Traceability: A good SRS document includes detailed requirements and specifications, which enables traceability
throughout the software development process.
8. Testability: A good SRS document can serve as a basis for test cases and verification, which can ensure that the
software meets the requirements and specifications.
9. Improved Communication: A good SRS document can serve as a communication tool between different
stakeholders, such as project managers, developers, testers, and customers.
10. Reduced Rework: A good SRS document can help to identify and resolve issues early in the development process,
which can reduce the need for rework and improve the overall quality of the software.
Disadvantages of having a poorly written SRS include:
1. Confusion and misunderstandings between stakeholders and developers, as the requirements are not clearly
defined or are vague increased rework and change requests, as the SRS does not accurately capture the
requirements of the software system
 2. Reduced quality of the final software system, as a poorly written SRS can result in requirements being missed or
not fully met
3. Reduced stakeholder satisfaction, as a poorly written SRS does not accurately capture the needs of the business
and its users
4. Reduced traceability and verifiability, as a poorly written SRS can’t be traced to other documents and artifacts and
its requirements can’t be tested and validated.
5. It is important to note that, regardless of the quality of the SRS, gathering and validating requirements is an
iterative process, that should be continuously reviewed and updated throughout the software development process.
6. Time-consuming: Creating a good SRS document can be a time-consuming process, especially for complex
software projects, which can delay the development process.
7. Changes and Updates: Changes or updates to the SRS document can cause delays in the software development
process and can be difficult to manage.
8. Lack of Flexibility: A detailed SRS document can restrict the flexibility of the development process, which can be
challenging for projects that require agile development methodologies.
9. Limited Stakeholder Involvement: The process of creating an SRS document can limit the involvement of
stakeholders in the software development process, which can lead to a lack of collaboration and input from
different perspectives.
10. Ambiguity: A poorly written SRS document can lead to ambiguity and misunderstandings, which can cause issues
throughout the software development process.

The IEEE standard for requirements documents

The most widely known requirements document standard is (IEEE, 1998). This IEEE standard suggests the following
structure for requirements documents:
1. Introduction
1.1 Purpose of the requirements document
1.2 Scope of the product
1.3 Definitions, acronyms and abbreviations
1.4 References
1.5 Overview of the remainder of the document
2. General description
2.1 Product perspective
2.2 Product functions
2.3 User characteristics
2.4 General constraints
2.5 Assumptions and dependencies
3. Specific requirements, covering functional, non-functional and interface requirements. This is obviously the most
substantial part of the document but because of the wide variability in organisational practice, it is not appropriate to define
a standard structure for this section. The requirements may document external interfaces, describe system functionality and
performance, and specify logical database requirements, design constraints, emergent system properties and quality
characteristics.
[Link]
[Link]
Although the IEEE standard is not ideal, it contains a great deal of good advice on how to write requirements and how to
avoid problems. It is too general to be an organisational standard in its own right. It is a general framework that can be
tailored and adapted to define a standard geared to the needs of a particular organisation.
Verification and Validation
Verification and Validation is the process of investigating whether a software system satisfies specifications and standards
and fulfills the required purpose. Verification and Validation both play an important role in developing good software
development. Verification helps in examining whether the product is built right according to requirements, while validation
helps in examining whether the right product is built to meet user needs.

Differences between Verification and Validation

Verification Validation

Verification refers to the set of activities that Validation refers to the set of activities that ensure
ensure software correctly implements the that the software that has been built is traceable to
Definition specific function customer requirements.

It includes checking documents, designs, codes, It includes testing and validating the actual
Focus and programs. product.

Type of Testing Verification is the static testing. Validation is dynamic testing.

Execution It does not include the execution of the code. It includes the execution of the code.

Methods used in verification are Methods used in validation are Black Box
reviews, walkthroughs, inspections and desk- Testing, White Box Testing and non-functional
Methods Used checking. testing.

It checks whether the software meets the

It checks whether the software conforms to
requirements and expectations of a customer or
specifications or not.
Purpose not.

It can find the bugs in the early stage of the It can only find the bugs that could not be found by
Bug development. the verification process.

The goal of verification is application and

The goal of validation is an actual product.
Goal software architecture and specification.

Validation is executed on software code with the

Quality assurance team does verification.
Responsibility help of testing team.

Timing It comes before validation. It comes after verification.

Human or It consists of checking of documents/files and is It consists of execution of program and is

Computer performed by human. performed by computer.
 Verification Validation

After a valid and complete specification, the

Validation begins as soon as project starts.
Lifecycle verification starts.

Error Focus Verification is for prevention of errors. Validation is for detection of errors.

Verification is also termed as white box testing

Validation can be termed as black box testing or
Another or static testing as work product goes through
dynamic testing as work product is executed.
Terminology reviews.

Verification finds about 50 to 60% of the

Validation finds about 20 to 30% of the defects.
Performance defects.

Verification is based on the opinion of reviewer

Validation is based on the fact and is often stable.
Stability and may change from person to person.

Software Quality Assurance – Software Engineering

Software Quality Assurance (SQA) is simply a way to assure quality in the software. It is the set of activities that ensure
processes, procedures as well as standards are suitable for the project and implemented correctly.
Software Quality Assurance is a process that works parallel to Software Development. It focuses on improving the process
of development of software so that problems can be prevented before they become major issues.

Software Quality Assurance Plan in Software Development

A software quality assurance plan’s main goal is to guarantee that the market’s product or service is trouble- and bug-free.
Additionally, it must fulfill the specifications listed in the SRS (software requirement specification).

Software Quality Assurance Plan

A Quality Assurance Plan (QAP) is a document or set of documents that outlines the systematic processes, procedures, and
standards for ensuring the quality of a product or service. It is a key component of quality management and is used in
various industries to establish and maintain a consistent level of quality in deliverables. For a software product or service,
an SQA plan will be used in conjunction with the typical development, prototyping, design, production, and release cycle.
An SQA plan will include several components, such as purpose, references, configuration and management, tools, code
controls, testing methodology, problem reporting and remedial measures, and more, for easy documentation and
referencing.
Importance of Software Quality Assurance Plan

• Quality Standards and Guidelines: The SQA Plan lays out the requirements and guidelines to make sure the
programme satisfies predetermined standards for quality.

• Risk management: It is the process of recognizing, evaluating and controlling risks in order to reduce the
possibility of errors and other problems with quality.

• Standardization and Consistency: The strategy guarantees consistent methods, processes, and procedures,
fostering a unified and well-structured approach to quality assurance.

• Customer Satisfaction: The SQA Plan helps to ensure that the finished product satisfies customer needs, which in
turn increases overall customer satisfaction.

• Resource optimization: It is the process of defining roles, responsibilities, and procedures in order to maximize
resource utilization and minimize needless rework.
 • Early Issue Detection: SQA Plans help identify problems early on, which lowers the expense and work involved
in fixing them.

Software Quality Framework – Software Engineering

Software Quality Framework is a model for software quality that ensures quality by connecting and integrating the different
views of software quality. This article focuses on discussing the Software Quality Framework.
What is a Software Quality Framework?
Software Quality Framework connects the customer view with the developer’s view of software quality and it treats
software as a product.
1. The software product view describes the characteristics of a product that bear on its ability to satisfy stated and
implied needs.
2. This is a framework that describes all the different concepts relating to quality in a common way measured by a
qualitative scale that can be understood and interpreted commonly.
Therefore, the most influential factor for the developers is the customer perception. This framework connects the developer
with the customer to derive a common interpretation of quality.

Software Engineering Institute Capability Maturity Model (SEICMM)

The Capability Maturity Model (CMM) is a procedure used to develop and refine an organization's software development
process.
The model defines a five-level evolutionary stage of increasingly organized and consistently more mature processes.
CMM was developed and is promoted by the Software Engineering Institute (SEI), a research and development center
promote by the U.S. Department of Defense (DOD).
Capability Maturity Model is used as a benchmark to measure the maturity of an organization's software process.
Methods of SEICMM
There are two methods of SEICMM:

Capability Evaluation: Capability evaluation provides a way to assess the software process capability of an organization.
The results of capability evaluation indicate the likely contractor performance if the contractor is awarded a work.
Therefore, the results of the software process capability assessment can be used to select a contractor.
Software Process Assessment: Software process assessment is used by an organization to improve its process capability.
Thus, this type of evaluation is for purely internal use.
SEI CMM categorized software development industries into the following five maturity levels. The various levels of SEI
CMM have been designed so that it is easy for an organization to build its quality system starting from scratch slowly.