0% found this document useful (0 votes)
16 views

Face Detection Project

this can help you recognise your ugly faces...
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
16 views

Face Detection Project

this can help you recognise your ugly faces...
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 20

face detection

project
Practical No :1

advantages :- the advantages of face


detection include better security, easy
integration, and automated identification

disadvantages :- the disadvantages


include huge storage requirements,
vulnerable detection, and potential privacy
issues
Future Scope :-
Different applications utilize facial
acknowledgment to ensure your information.
Indeed, even a safe secret key can’t shield
your records and data from talented
programmers, so individuals have gone to
facial acknowledgment. These applications
require your face to open your cell phone or
access private information.

Problem formulation :-
Facial Recognition technology doesn’t always
work as well as it should. Facial Recognition
systems can be impacted by poor lighting or
low image quality. The data may not match up
with the person’s nodal points because of
camera angles being obscured; this creates an
error when matching faceprints cannot be
verified in the database.
Result:-
Face detection, also called facial detection, is
an artificial intelligence (AI)-based computer
technology used to find and identify human
faces in digital images and video. Face
detection technology is often used for
surveillance and tracking of people in real
time. It is used in various fields including
security, biometrics, law enforcement,
entertainment and social media.
Practical No : 2
• Explain Waterfall model
The Waterfall Model is a linear
application development model that uses
rigid phases: When one phase ends, the
next begins. Steps occur in sequence, and,
if unmodified, the model does not allow
developers to go back to previous steps
(hence “waterfall”: Once water falls down,
it cannot go back up).

The Waterfall model is one of the most


common and classic of life cycle models,
also referred to as a linear-sequential life
cycle model. It is based on the factory
assembly-line process. It follows a
structured sequential path from
Requirements to Maintenance, setting out
milestones at each stage which must be
accomplished before the next stage can

begin (Fig. 9.5).

• Explain the freamwork


activity
image or document file, to create a package
unique to a project. Even after an application
is complete, coders can revise the framework
of an application to add new features or edit
existing components.
Benefits of a framework
Frameworks are helpful tools for programmers
and developers to use during the creation of
websites and other applications. Here are some
of the benefits a framework can offer:
Saving software developers time and energy
Providing a basic outline for coders to follow
Allowing coders to focus on tasks more
specific to their project
Creating clean and adaptable code
Reducing costs by shortening the amount of
time a developer spends programming the
application

6 types of frameworks
There are several types of frameworks.
Developers define each by either the
framework's function or the main coding
language they add to it. Here are some of the
most popular types of frameworks:

1. Web app framework


Developers use web app frameworks
when designing a website. A web app
framework allows a software engineer's
creations to function well on the internet, and
they usually have a higher rate of usability,
making them inclusive to users. Websites
require frequent updates and changes and
developers and coders benefit from using web
app frameworks, as they're easy to adjust.

2. Mobile app framework


A mobile app framework provides a
general structure for developers to add onto to
create an application for mobile devices, such
as smartphones. These frameworks are often
open-source, and developers can use a variety
of coding languages to create them. While the
mobile app framework is often similar to a
web app framework, this framework allows
software developers to format the application
specifically for easy use on a smartphone or
tablet.
3. Technology framework
Software engineers generally use
technology frameworks for business purposes.
This framework allows them to establish
information technology (IT) systems within a
company's database. Uses for a technology
framework can include security measures for
discrete data, management tools and common
applications.

4. Enterprise architecture
framework
An enterprise architecture framework
provides a blueprint for complex IT systems
within a company. There are four major types
of enterprise architecture frameworks, which
developers choose based on the framework's
fit for their specific project. These framework
subtypes include the Zachman,
Federal, Gartman and the Open Group
enterprise framework (TOGAF). Developers
most commonly use the latter.

5. Database framework
Software developers use database
frameworks to manage a variety of database
engines. They also help developers perform
database management tasks quickly and
without spending time and effort on additional
programming.
Developers use the database framework to
help analyze, sort and find data within a
certain collection. Database frameworks can
also act as a starting structure for software
developers to create functions and commands
that other people can use to perform the same
database management tasks without coding
knowledge.

6. Testing framework
Software developers use testing
frameworks as guidelines for creating test
cases. This helps supply developers with tools
and practices that allow them to complete
quality assurance tasks. Testing frameworks
remind developers what to test for and how to
complete tests, and they ensure accuracy and
efficiency in quality assurance practices.

Question :
 Gather and write application specific
requirements for your any micro project

 Step 1: Assign roles


The first step in requirements gathering is to assign roles in your project.
This is when you identify your
A stakeholder is anyone invested in the project, whether they’re internal or external
partners. For example, a customer is an external stakeholder, while a department
manager or board member is an internal stakeholder. Identifying these roles first will
help you determine who should analyze your later on.
Other roles include the , designers, product testers, and developers. These people
can help you identify the requirements and resources you need in order to hit your
project goals.
While you may feel tempted to jump headfirst into your project and start listing all the
things you know you’ll need, this can be a mistake. Slow down and stick to the
process and you’ll have a better chance of preventing
 Step 2: Meet with stakeholders
Once you’ve identified your project stakeholders, meet with them to get an
idea of what they’re hoping to get out of the project. Understanding what
stakeholders want matters because they’re ultimately the ones you’re creating your
deliverables for.
Some questions you can ask include:
 What is your goal for this project?
 What do you think would make this project successful?
 What are your concerns about this project?
 What do you wish this product or service would do that it doesn’t already?
 What changes would you recommend about this project?
The stakeholders are the people you’re ultimately developing the project for, so you
should ask them questions that can help you create your list of requirements.

 Step 3: Gather and document


Step three in the process happens at the same time as step two. You’ll
gather information as you ask your stakeholders questions. The goal is to document
everything you can, so have all of the answers you need to start your project.
Use a project management tool to collect and document this information. That way,
you can keep your project plan, project requirements, and project communication all
in one place. Some examples of what you might document include:
 Stakeholder answers to interview questions
 Stakeholder questions
 Stakeholder requests
 Stakeholder comments
 Questions and comments that arise during interviews
You don’t have to use every answer you receive, but having everything documented
can help you see all of your stakeholders’ perspectives, which will help you with
 Step 4: List assumptions and requirements
Now that you’ve completed the intake process, create yo
based on the information you’ve gathered.
Consider the questions you initially set out to answer during the requirements
gathering process. Then, use them to create your requirements goals, including:
 Length of project schedule: You can map out your project timeline using a Gantt
chart and use it to visualize any project requirements that depend on project
milestones. Some requirements will apply for the full duration of the project,
whereas others may only apply during distinct project phases. For example,
you’ll need a specific budget for team member salaries throughout the entire
project, but you may only need specific material during the last stage of your
project timeline.
 People involved in the project: Identify exactly which team members will be
involved in your project, including how many designers, developers, or managers
you’ll need to execute every step. People are part of your project requirements
because if you don’t have the team members you need, you won’t be able to
complete the project on time.
 Project risks: Understanding your project risks is an important part of
identifying project requirements. Use a risk register to determine which risks are
of highest priority, such as stakeholder feedback, timeline delays, and lack of
budget. Then, schedule a brainstorming session with your team to figure out how
to prevent these risks.

 Step 5: Get approval


Once you formalize your project requirements, you’ll need approval from
stakeholders to ensure you’re meeting user needs. Encouraging clear can also
prevent scope creep by ensuring your stakeholders know the limits of the project from
the beginning. You can then proceed with your which may include acquiring
resources and assembling a team.
 Step 6: Monitor progress
The last part of the process and other requirements as you move
through project execution. The benefit of project management software is that you
can see changes to your project in real-time and take immediate action when things
go awry.

 What is requirement elicitation write in


detail

 Requirements elicitation is perhaps the most difficult, most error


and most communication-intensive software development.

1. It can be successful only through an effective customer-developer


partnership. It is needed to know what the users require.
2. Requirements elicitation involves the identification, collection, analysis,
and refinement of the requirements for a software system.
3. It is a critical part of the software development life cycle and is typically
performed at the beginning of the project.
4. Requirements elicitation involves stakeholders from different areas of the
organization, including business owners, end-users, and technical experts.
5. The output of the requirements elicitation process is a set of clear, concise,
and well-defined requirements that serve as the basis for the design and
development of the software system.
Importance of Requirements Elicitation
1. Compliance with Business Objectives: The process of elicitation
guarantees that the software development endeavours are in harmony with
the wider company aims and objectives. Comprehending the business
context facilitates the development of a solution that adds value for the
company.
2. User Satisfaction: It is easier to create software that fulfils end
users needs and expectations when they are involved in the requirements
elicitation process. Higher user pleasure and acceptance of the finished
product are the results of this.
3. Time and Money Savings: Having precise and well-defined
specifications aids in preventing miscommunication and rework during the
development phase. As a result, there will be cost savings and the project
will be completed on time.
4. Compliance and Regulation Requirements: Requirements elicitation is
crucial for projects in regulated industries to guarantee that the software
conforms with applicable laws and norms. In industries like healthcare,
finance, and aerospace, this is crucial.
5. Traceability and Documentation: Throughout the software development
process, traceability is based on requirements that are well-documented.
Traceability helps with testing, validation, and maintenance by ensuring
that every part of the software can be linked to a particular requirement.
Requirements Elicitation Activities:
Requirements elicitation includes the subsequent activities. A few
of them are listed below:
1. Knowledge of the overall area where the systems are applied.
2. The details of the precise customer problem where the system is going to
be applied must be understood.
3. Interaction of system with external requirements.
4. Detailed investigation of user needs.
5. Define the constraints for system development.

 Requirements Elicitation Methods:


There are a number of requirements elicitation methods. Few
of them are listed below:

1. Interviews
Objective of conducting an interview is to understand the customer’s
expectations from the software.
It is impossible to interview every stakeholder hence representatives from groups are
selected based on their expertise and credibility. Interviews maybe be open-ended or
structured.
1. In open-ended interviews there is no pre-set agenda. Context free
questions may be asked to understand the problem.
2. In a structured interview, an agenda of fairly open questions is prepared.
Sometimes a proper questionnaire is designed for the interview.
2. Brainstorming Sessions
 It is a group technique
 It is intended to generate lots of new ideas hence providing a platform to
share views
 A highly trained facilitator is required to handle group bias and group
conflicts.
 Every idea is documented so that everyone can see it.
 Finally, a document is prepared which consists of the list of requirements
and their priority if possible.

3. Facilitated Application Specification


Technique
Its objective is to bridge the expectation gap – the difference between
what the developers think they are supposed to build and what customers think they
are going to get. A team-oriented approach is developed for requirements
gathering. Each attendee is asked to make a list of objects that are:
1. Part of the environment that surrounds the system.
2. Produced by the system.
3. Used by the system.
Each participant prepares his/her list, different lists are then combined, redundant
entries are eliminated, team is divided into smaller sub-teams to develop mini-
specifications and finally a draft of specifications is written down using all the inputs
from the meeting.

4. Quality Function Deployment


In this technique customer satisfaction is of prime concern, hence it
emphasizes on the requirements which are valuable to the customer.
3 types of requirements are identified:
 Normal requirements: In this the objective and goals of the proposed
software are discussed with the customer. Example – normal requirements
for a result management system may be entry of marks, calculation of
results, etc.
 Expected requirements: These requirements are so obvious that the
customer need not explicitly state them. Example – protection from
unauthorized access.
 Exciting requirements: It includes features that are beyond customer’s
expectations and prove to be very satisfying when present. Example –
when unauthorized access is detected, it should backup and shutdown all
processes.
5. Use Case Approach
This technique combines text and pictures to provide a better understanding of the
requirements.
The use cases describe the ‘what’, of a system and not ‘how’. Hence, they only give
a functional view of the system.
The components of the use case design include three major things – Actor, use cases,
use case diagram.
1. Actor: It is the external agent that lies outside the system but interacts
with it in some way. An actor maybe a person, machine etc. It is
represented as a stick figure. Actors can be primary actors or secondary
actors.
 Primary actors: It requires assistance from the system to
achieve a goal.
 Secondary actor: It is an actor from which the system needs
assistance.
2. Use cases: They describe the sequence of interactions between actors and
the system. They capture who(actors) do what(interaction) with the
system. A complete set of use cases specifies all possible ways to use the
system.
3. Use case diagram: A use case diagram graphically represents what
happens when an actor interacts with a system. It captures the functional
aspect of the system.
 A stick figure is used to represent an actor.
 An oval is used to represent a use case.
 A line is used to represent a relationship between an actor and a
use case.
The success of an elicitation technique used depends on the maturity of the analyst,
developers, users, and the customer involved.
Steps Of Requirements Elicitation:
1. Identify all the stakeholders, e.g., Users, developers, customers etc.
2. List out all requirements from customer.
3. A value indicating degree of importance is assigned to each requirement.
4. In the end the final list of requirements is categorized as:
 It is possible to achieve.
 It should be deferred and the reason for it.
 It is impossible to achieve and should be dropped off.
 Features of Requirements Elicitation:
1. Stakeholder engagement: Requirements elicitation involves
engaging with stakeholders such as customers, end-users, project
sponsors, and subject-matter experts to understand their needs and
requirements.
2. Gathering information: Requirements elicitation involves gathering
information about the system to be developed, the business processes it
will support, and the end-users who will be using it.
3. Requirement prioritization: Requirements elicitation involves
prioritizing requirements based on their importance to the project’s
success.
4. Requirements documentation: Requirements elicitation involves
documenting the requirements in a clear and concise manner so that they
can be easily understood and communicated to the development team.
5. Validation and verification: Requirements elicitation involves validating
and verifying the requirements with the stakeholders to ensure that they
accurately represent their needs and requirements.
6. Iterative process: Requirements elicitation is an iterative process
that involves continuously refining and updating the requirements based
on feedback from stakeholders.
7. Communication and collaboration: Requirements elicitation
involves effective communication and collaboration with stakeholders,
project team members, and other relevant parties to ensure that the
requirements are clearly understood and implemented.
8. Flexibility: Requirements elicitation requires flexibility to adapt to
changing requirements, stakeholder needs, and project constraints.

 Advantages of Requirements Elicitation:


1. Clear requirements: Helps to clarify and refine customer requirements.
2. Improves communication: Improves communication and collaboration
between stakeholders.
3. Results in good quality software: Increases the chances of developing a
software system that meets customer needs.
4. Avoids misunderstandings: Avoids misunderstandings and helps to
manage expectations.
5. Supports the identification of potential risks: Supports the
identification of potential risks and problems early in the development
cycle.
6. Facilitates development of accurate plan: Facilitates the development of
a comprehensive and accurate project plan.
7. Increases user confidence: Increases user and stakeholder confidence in
the software development process.
8. Supports identification of new business opportunities: Supports the
identification of new business opportunities and revenue streams.

 Disadvantages of Requirements Elicitation:

1. Time consuming: Can be time-consuming and expensive.


2. Skills required: Requires specialized skills and expertise.
3. Impacted by changing requirements: May be impacted by changing
business needs and requirements.
4. Impacted by other factors: Can be impacted by political and
organizational factors.
5. Lack of commitment from stakeholders: Can result in a lack of buy-in
and commitment from stakeholders.
6. Impacted by conflicting priorities: Can be impacted by conflicting
priorities and competing interests.
7. Sometimes inaccurate requirements: May result in incomplete or
inaccurate requirements if not properly managed.
8. Increased development cost: Can lead to increased development costs
and decreased efficiency if requirements are not well-defined.

Usecase Diagram
Practical no:- 12

use time line chart/ gantt chart of of


fingerprint based ATM system

You might also like