SEMD U_I Introduction to SE.pptx

Software Engineering, Modeling & Design
Sanjivani Rural Education Society’s
Sanjivani College of Engineering, Kopargaon-423603
(An Autonomous Institute Affiliated to Savitribai Phule Pune University, Pune)
NAAC ‘A’ Grade Accredited, ISO 9001:2015 Certified
Department of Information Technology
(NBA Accredited)
Mr. N. L. Shelake
Assistant Professor

Software Engineering Modeling and Design
Unit – I Introduction To Software Engineering Mr. N. L. Shelake Department of Information Technology
Unit - I
Introduction To Software Engineering

Software : -
Software is
instructions (computer programs) that when executed provide
desired features, function, and performance
data structures that enable the programs to adequately
manipulate information
descriptive information in both hard copy and virtual forms that
describes the operation and use of the programs

Software : -
Software is developed or engineered; it is not manufactured in the
classical sense.
 Although some similarities exist between software development and
hardware manufacturing, the two activities are fundamentally different
Software doesn’t “wear out.”
 hardware has relatively high failure rates early in its life
Although the industry is moving toward component-based
construction, most software continues to be custom built.

Software Engineering : -
Software engineering encompasses a process, methods for
managing and engineering software, and tools.
The application of a systematic, disciplined, quantifiable
approach to the development, operation, and maintenance
of software; that is, the application of engineering to
software.

Software Application Domains / Nature of Software
 System software - a collection of programs written to service other
programs.
 Application software - stand-alone programs that solve a specific business
need.
 Engineering/scientific software - Applications range from astronomy, from
automotive stress analysis to space shuttle orbital dynamics, conventional
numerical algorithms. Computer-aided design, system simulation
 Embedded software - resides within a product or system and is used to
implement and control features and functions for the end user and for the
system itself.

Software Application Domains / Nature of Software
 Product-line software - designed to provide a specific capability for use by
many different customers.
 Web applications - called “WebApps,” this network-centric software
category spans a wide array of applications
 Artificial intelligence software - makes use of non numerical algorithms to
solve complex problems that are not amenable to computation or straight
forward analysis

Software Development Life Cycle

Software Myths: -
 Erroneous beliefs about software and the process that is used to build it.
 Myths have a number of attributes that make them insidious.
 misleading attitudes that have caused serious problems for managers and
practitioners.
 Three types of myth are associated with software: -
 Management myth
 Customer myth
 Practitioner’s myth

Management myths:-
 Managers with software responsibility, like managers in most disciplines, are
often under pressure to maintain budgets, keep schedules from slipping, and
improve quality.
 Myth: If we get behind schedule, we can add more programmers and catch up
 Reality: Software development is not a mechanistic process like manufacturing.
In the words of Brooks: “adding people to a late software project makes it later.”
However, as new people are added, people who were working must spend time
educating the newcomers, thereby reducing the amount of time spent on
productive development effort. People can be added but only in a planned and
well coordinated manner.

Management myths:-
 Myth: If I decide to outsource the software project to a third party, I can just
relax and let that firm build it.
 Reality: If an organization does not understand how to manage and control
software projects internally, it will invariably struggle when it outsources software
projects
 Myth: We already have a book that’s full of standards and procedures for
building software. Won’t that provide my people with everything they need to
know.
 Reality: The book of standards may very well exist, but is it used?

Customer myths:-
 Customer myths. A customer who requests computer software may be a person
at the next desk, a technical group down the hall, the marketing/sales
department, or an outside company that has requested software under contract.
 Myths lead to false expectations (by the customer) and, ultimately, dissatisfaction
with the developer.

Customer myths:-
 Myth: A general statement of objectives is sufficient to begin writing
programs—we can fill in the details later.
 Reality: Although a comprehensive and stable statement of requirements is not
always possible, an ambiguous “statement of objectives” is a recipe for disaster.
Unambiguous requirements (usually derived iteratively) are developed only
through effective and continuous communication between customer and
developer

Customer myths:-
 Myth: Software requirements continually change, but change can be easily
accommodated because software is flexible.
 Reality: It is true that software requirements change, but the impact of change
varies with the time at which it is introduced. When requirements changes are
requested early (before design or code has been started), the cost impact is
relatively small

Practitioner myths:-
 Practitioner’s myths. Myths that are still believed by software practitioners have
been fostered by over 50 years of programming culture. During the early days,
programming was viewed as an art form. Old ways and attitudes die hard.
 Myth: Once we write the program and get it to work, our job is done.
 Reality: Someone once said that “the sooner you begin ‘writing code,’ the longer
it’ll take you to get done.” Industry data indicate that between 60 and 80 percent
of all effort expended on software will be expended after it is delivered to the
customer for the first time

Practitioner myths:-
 Myth: Software engineering will make us create voluminous and unnecessary
documentation and will invariably slow us down.
 Reality: Software engineering is not about creating documents. It is about
creating a quality product. Better quality leads to reduced rework. And reduced
rework results in faster delivery times

Product ?
Process ?

Product
Product includes any software manufactured based on the
customer’s request/requirements.
This can be a problem solving software or computer based system
Product is the final outcome of the software development process
Product focuses on final result
It may be tends to short term
Product is successful completion of the job

Process
Process is a set of sequence steps that have to be followed to
create a project
Purpose of a process is to improve the quality of the project
Whereas the process is focused on completing each steps being
developed
The process directs the development of the product
Process makes the progressive changes in requirements of the
product. It includes the various stages of SDLC, such as
planning, analysis, design, implementation, testing, and
deployment.

A product is the artefact produced in the life of the project, for
example, models, source code, documentation and so on. In contrast,
the process is a series of the stages includes operations, constraints
and resource produce a specific output.
Product Vs Process

Difference between Hardware and Software

Generic Process Model :-
A generic process framework for software
engineering defines five framework activities—
communication, planning, modeling,
construction and deployment

Process Flow :-

Software Engineering Practices :-
The Essence of Practice
Understand the problem
Plan a Solution
Carry out the plan
Examine the result for accuracy

Software Engineering Practices :-
The Essence of Practice
Understand the problem (Communication and Analysis)
Plan a Solution (Modeling and S/W Design)
Carry out the plan (Code Generation)
Examine the result for accuracy (Testing and Quality Assurance)

Predictive Vs Adaptive

How do you put these different pieces together
to create a work flow or a process that a team
can use to build software?
Why do you need so many models?

Prescriptive Process Model :-
 These traditional models have brought a certain amount of useful structure to software
engineering work and have provided a reasonably effective road map for software teams.
 Populates a process framework with explicit task sets for software engineering actions.
 To meet the development goals
 Prescriptive - Prescribe a sets of process elements framework activities, software
engineering actions, tasks, work products, quality assurances and change control
mechanism for project.
 Workflow – the manner in which the process elements are interrelated to one another

Waterfall Model

Waterfall Model :-
 The waterfall model, sometimes called the classic life cycle, suggests a
systematic, sequential approach to software development that begins
with customer specification of requirements and progresses through
planning, modeling, construction, and deployment
 Work flows from communication through deployment in a reasonably
linear fashion.
 This situation is sometimes encountered when well-defined adaptations
or enhancements to an existing system must be made.
 Requirements are well defined and reasonably stable.

V-Model :-
 A variation in the representation of the waterfall
model
 Depicts the relationship of quality assurance actions
to the actions associated with communication,
Modeling and early construction activities.
 Requirements are refined into progressively more
detailed and technical representations of the
problem and its solution.
 There is no fundamental difference between the
classic life cycle and the V-mode
 A way of visualizing how verification and validation
actions are applied to earlier engineering work

Incremental Model :-
 Prescriptive Process Model
 Combines Elements of Waterfall Model applied
in an iterative fashion.
 Linear sequence produces deliverable increments
 Module by module
 Customer interaction maximum
 Early release product demand
 Flexible to change
 First increment often a core product
 Specially for large project

Incremental Model :-
Advantages
 Work with small team (less manpower)
 Initial product delivery is fast
 Can accommodate changes
 Customer response is consider
Disadvantages
 Actual cost may exceed the estimate cost
 System broken into small increments

RAD Model :-
 Prescriptive Process Model
 Rapid Application Model
 Emphasizes a short development cycle.
 “High speed” adaptation of the waterfall model
 Component based construction approach
 “Fully functional system” (60 to 90 days)

RAD Model :-

RAD Model :-
Advantages
 Faster implementation of Project
 Parallel implementation
 Increases re usability of components
 Encourages customer feedback
 Projects divided into small teams results into
better implementation

RAD Model :-
Disadvantages
 Limited Time for system implementation results into inadequate analysis
of project.
 Less time for testing.
 If user is unclear with the system project may fail.
 If developers and customers are not committed to the rapid model, the
RAD project fails.
 RAD has to be modularized in a proper way otherwise creates a lots of
confusions and problems.
 In case of high performance requirement, RAD cannot be ideal model.

Evolutionary Model :-
 A combination of Iterative and Incremental model of software
development life cycle.
 Prototyping Model
 Spiral Model
 Concurrent Model

Prototyping Model :-
Prototyping is defined as the process of
developing a working replication of a
product or system that has to be
engineered.
It offers a small scale end product and is
used for obtaining customer feedback

 The customers do not know the exact project
requirements
 A prototype of the end product is first developed,
tested and refined as per customer feedback
repeatedly till a final acceptable prototype is
achieved which forms the basis for developing the
final product.
 Customers an opportunity to see the product early

 Implementation of high level paper model
 used to build the initial prototype supporting only the basic functionality as desired by the
customer
 The customer figures out the problems, the prototype is further refined to eliminate them
 The process continues until the user approves the prototype and finds the working model to be
satisfactory

 Rapid Throwaway Prototyping - Customer feedback helps in preventing unnecessary design
faults
 Evolutionary Prototyping - incrementally refined on the basis of customer feedback till it finally
gets accepted
 Incremental Prototyping - expected product is broken into different small pieces of prototypes
 Extreme Prototyping - mainly used for web development
 basic prototype, Functional , services are implemented and associated

Advantages :-
 The customers get to see the partial product early in the life cycle. This ensures a greater level of
customer satisfaction and comfort.
 New requirements can be easily accommodated as there is scope for refinement.
 Missing functionalities can be easily figured out.

Disadvantages :-
 Costly w.r.t time as well as money.
 Poor Documentation due to continuously changing customer requirements
 Too much variation in requirements each time the prototype is evaluated by the customer.

Spiral Model :-
The spiral model is a risk-driven software development process model
Its diagrammatic representation, contains a spiral with many loops.
The spiral is unknown and can vary from project to project
Phase of the software development process
The project manager dynamically determines the number of phase/spiral

Spiral Model :-
Objectives determination and identify alternative solutions
Identify and resolve Risks
Develop next version of the Product
Review and plan for the next Phase

Advantages :-
 Risk Handling
 Good for large projects
 Customer Satisfaction
 Flexibility in Requirements

Disadvantages :-
 much more complex than other SDLC models
 not suitable for small projects as it is expensive
 project is very much dependent on Risk Analysis
 time estimation is very difficult

Concurrent Process Model :-
 Concurrent Process model is an evolutionary process model
 The term concurrent mean “done at the same time”.

Concurrent
Process
Model :-

Specialized Process Model :-
 when a narrowly defined software engineering approach
 Better characterized as a collection of techniques or a methodology for accomplishing a
specific software development goal
 Component-Based Development
 Formal Methods Model
 Aspect-Oriented Software Development

Component-Based Development
Commercial off-the-shelf (COTS) software components
Provide targeted functionality with well-defined interfaces
Incorporates many of the characteristics of the spiral model
The model composes applications from prepackaged s/w components
Modeling and construction activities begin with the identification of candidate
components

Component-Based Development
The CBD model incorporates the following steps:
Available component based product are researched and evaluated for the
application domain in question
Component integration issues are considered
A s/w architecture is designed to accommodate the components
Components are integrated into the architecture
Comprehensive testing is conducted to ensure proper functionality

The Formal Methods Model
 Encompasses a set of activities that leads to formal mathematical specification of
computer software.
 Clean room software engineering
 Provide mechanism for eliminating many of problems that are difficult to
overcome using other s/w engg. paradigms – Ambiguity, incompleteness,
inconsistency.
 When formal methods are used during design, they serve as a basis for program
verfication

The Formal Methods Model
Its applicability in a business environment has been voiced:
 The development of formal models is currently quite time-consuming and
expensive
 s/w developers have the necessary background to apply formal methods, extensive
training is required.
 It is difficult to use the models as a communication mechanism for technically
unsophisticated customers

Aspect-Oriented Methods Model
 The builders of complex software invariably implement a set of localized features,
functions and information content
 These localized software characteristics are modeled as components
 As modern computer-based systems become more sophisticated, certain concerns
 Some concerns are high-level properties of a system
 When concerns cut across multiple system functions, features, and information,
they are often referred to as crosscutting concerns

Aspect-Oriented Methods Model
Aspectual requirements define those crosscutting concerns that have an impact across
the software architecture
Aspect-oriented software development (AOSD), often referred to as aspect-oriented
programming (AOP)
is a relatively new software engineering paradigm that provides a process and
methodological approach for defining, specifying, designing, and constructing

To prepare survey form
 To gather user/customer requirements
 Prepare Questionnaires
 Prepare google form etc

Which of the following categories best describes the type of
software developed for this project?
 Desktop
 Web-based (not Web services)
 2-Tier client/server / N-Tier client/server
 DatabaseWeb Services / Service Oriented Architecture(SOA)
 Mainframe
 Embedded
 Other

Which of the following application domains does/did this
project apply to?
 Education
 Medical Systems
 Imaging
 Utilities
 Finance/Banking/Insurance
 Retail, Distribution & Transport
 Government
 Telecommunications
 Defence
 Pharmaceuticals
 Other

What is/was the duration of the project (from inception to
delivery) ?
 less than 6 months
 6 months - < 12 months
 12 months - <24 months
 more than 60 months

What are the primary goals and objectives of the Library
Management System?
 Improved efficiency and productivity
 Better user experience for library members
 Better tracking and management of library resources
 Increased security and privacy

What are the primary functions that the Library
Management System should support?
 Check in/check out of books
 Inventory management
 Member registration and management
 Search and discovery of books and other materials
 Circulation and holds
 Reporting and analytics

What are the different types of users that will use the
system?
 Library staff
 Library members
 Library administrators

How should the system handle book and item check-in and
check-out?
 Should the system support self-check-in/check-out?
 How should the system handle fines and lost items?
 What information should be displayed when checking out an item?

What type of inventory management is required?
 How should the system track item information such as title, author, ISBN, etc.?
 How should the system handle multiple copies of the same item?
 How should the system handle items that are checked out, lost, or damaged??

How should the system handle member registration and
management?
 What information should be collected during registration?
 How should the system handle renewing memberships?
 How should the system track borrowing history for each member?

What type of reporting and analytics functionality is
required?
 What type of reports should the system generate (e.g., circulation reports, overdue
reports, etc.)?
 How should the system handle exporting reports to different file formats (e.g.,
PDF, Excel, etc.)?
 How should the system display data and trends in an easy-to-understand manner?

Non-functional requirements
Non-functional requirements are requirements that specify
how well a system should perform, as opposed to what it
should do.
These requirements can include aspects such as usability,
security, performance, scalability, and more.
The requirements are being presented in a manner that
highlights their importance and emphasizes the positive
impact they will have on the system.

Excited Non-functional requirements
The requirements are being presented in a manner that
highlights their importance and emphasizes the positive
impact they will have on the system.
This can help to build excitement and enthusiasm around the
project, and increase the likelihood that the requirements will
be met.

Thank You

SEMD U_I Introduction to SE.pptx

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a SEMD U_I Introduction to SE.pptx

Semelhante a SEMD U_I Introduction to SE.pptx (20)

Último

Último (20)

SEMD U_I Introduction to SE.pptx