0% found this document useful (0 votes)
54 views98 pages

SE Unit 1

Uploaded by

harshadsamrut3
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
54 views98 pages

SE Unit 1

Uploaded by

harshadsamrut3
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 98

SOFTWARE

ENGINEERING
SUBJECT CODE: 210253
SE COMPUTER
SEMESTER: SECOND
2019 PATTERN

TEACHING SCHEME: 3 HRS/WEEK

MID SEM (TH): 30 MARKS


END SEM (TH): 70 MARKS
COURSE OBJECTIVES

• To learn & understand the principles of software engineering.

• To be acquainted with methods of capturing, specifying, visualizing

and analyzing software requirements.

• To apply design & testing principles to software project development .

• To understand project management through life cycle of the project.


COURSE OUTCOMES

• CO1: Analyze s/w req. & formulate solution(design) for a s/w.


• CO2: Design solutions that are applicable in one or more domains
& integrate ethical, Social, legal & economic concerns.
• CO3: Apply s/w models, techniques & technologies to get
innovative & novelistic solutions that promote growth of society.
• CO4: Model & design user interface & components.
• CO5: Identify & handle risk mgt & s/w config. Mgt.
• CO6: Utilize knowledge of s/w testing, verification & validation
approaches.
• CO7: Construct high quality s/w. (which is reliable, easy to
understand & maintain)
COURSE CONTENTS

• Unit 1: Introduction to s/w engineering and s/w process models


• Unit 2: s/w requirements engineering and analysis
• Unit 3: Estimation and scheduling
• Unit 4: Design engineering
• Unit 5: Risk and configuration mgt
• Unit 6: Software testing
BOOKS TO REFER

• Roger pressman, “software engineering: a practitioner's


approach”, McGraw hill
• Ian Sommerville, “software engineering”, Addison & Wesley
UNIT 1
WHAT IS SOFTWARE ENGINEERING?

• The term software engineering is the


product of two words, software,
and engineering.

• The software is a collection of integrated


programs.

• Engineering is the application of scientific


and practical knowledge to invent,
design, build, maintain, and improve
frameworks, processes, etc.
WHAT IS SOFTWARE ENGINEERING?

• Software Engineering is a systematic and disciplined approach to


designing, developing, testing, deploying, and maintaining software. It applies
engineering principles to software development, ensuring that software is
reliable, efficient, scalable, and meets the needs of users and stakeholders.
Key Aspects of Software Engineering
1.Systematic Approach
Software engineering involves a structured process to design and build
software, ensuring quality and consistency.
2.Problem-Solving
It focuses on solving complex real-world problems using software solutions.
3.Scalability and Maintenance
Software is designed to accommodate future growth and is maintainable over
time.
4.Team Collaboration
Software engineering is typically done in teams, with clear roles and
responsibilities for developers, testers, project managers, and others.
Key Aspects of Software Engineering
1.Systematic Approach
Software engineering involves a structured process to design and build
software, ensuring quality and consistency.
2.Problem-Solving
It focuses on solving complex real-world problems using software solutions.
3.Scalability and Maintenance
Software is designed to accommodate future growth and is maintainable
over time.
4.Team Collaboration
Software engineering is typically done in teams, with clear roles and
responsibilities for developers, testers, project managers, and others.
Core Activities in Software Engineering
1.Requirements Analysis
1. Understanding what the user needs.
2. Documenting functional and non-functional requirements.
2.System Design
1. Creating a blueprint of the software's architecture, components, and
interfaces.
3.Implementation (Coding)
1. Writing and integrating the software code based on the design.
4.Testing
1. Verifying that the software works as intended and meets user
requirements.
2. Types of testing: Unit, Integration, System, and Acceptance Testing.
5.Deployment
1. Releasing the software to the production environment.
Software Engineering Principles
1. Modularity
Dividing software into smaller, manageable, and reusable modules.
2. Abstraction
Hiding implementation details to focus on essential features.
3. Scalability
Designing software to handle growing user demands.
4. Quality Assurance
Ensuring software reliability, performance, and usability.
5. User-Centric Design
Building software that meets user expectations and is easy to use.
WHY IS SOFTWARE ENGINEERING
REQUIRED?

• to manage Large software

• For more Scalability

• Cost Management

• To manage the dynamic nature of software

• For better quality Management


CHARACTERISTICS OF A GOOD
SOFTWARE ENGINEER

• Exposure to systematic methods, i.e., familiarity with software engineering


principles.

• Good technical knowledge of the project range (Domain knowledge).

• Good programming abilities.

• Good communication skills. These skills comprise of oral, written, and


interpersonal skills.

• High motivation.

• Sound knowledge of fundamentals of computer science.

• Intelligence.

• Ability to work in a team

• Discipline, etc.
Importance of Software Engineering
1. Reduces Costs
A systematic approach minimizes errors and rework, saving time
and money.
2. Improves Quality
Adherence to engineering principles ensures the delivery of reliable
software.
3. Handles Complexity
Software engineering helps manage the complexity of modern
systems.
4. Supports Scalability
Software can grow and adapt to meet evolving user needs.
5. Ensures Security
IMPORTANCE OF SOFTWARE
ENGINEERING
• Reduces complexity: Big software is always complicated and challenging to
progress. Software engineering divides big problems into various small issues. And
then start solving each small issue one by one. All these small problems are solved
independently to each other & finally combined.
• To minimize software cost: Software needs a lot of hard work and software
engineers are highly paid experts. A lot of manpower is required to develop software
with a large number of codes. But in software engineering, programmers project
everything and decrease all those things that are not needed. In turn, the cost for
software productions becomes less as compared to any software that does not use
software engineering method.
• To decrease time: Anything that is not made according to the project always wastes
time. And if you are making great software, then you may need to run many codes to
get the definitive running code. This is a very time-consuming procedure, and if it is
not well handled, then this can take a lot of time. So if you are making your software
according to the software engineering method, then it will decrease a lot of time.
• Handling big projects: Big projects are not done in a couple of days, and they need
lots of patience, planning, and management. And to invest six and seven months of
any company, it requires heaps of planning, direction, testing, and maintenance. No
one can say that he has given four months of a company to the task, and the project
is still in its first stage. Because the company has provided many resources to the plan
and it should be completed. So to handle a big project without any problem, the
company has to go for a software engineering method.
• Reliable software: Software should be secure, means if you have delivered the
software, then it should work for at least its given time or subscription. And if any
bugs come in the software, the company is responsible for solving all these bugs.
Because in software engineering, testing and maintenance are given, so there is no
worry of its reliability.
• Effectiveness: Effectiveness comes if anything has made according to the standards.
Software standards are the big target of companies to make it more effective. So
Software becomes more effective in the act with the help of software engineering.
NATURE OF SOFTWARE

• Software acts as a product as well as a vehicle to deliver a


product.
1. Software as a Product
In this context, software itself is the final deliverable that users or
customers consume.
•Examples:
• Standalone Software Products: Applications like Microsoft Office,
Photoshop, or games like Fortnite.
• Web Applications: Platforms like Gmail, Netflix, or social media
apps like Instagram.
• Mobile Apps: WhatsApp, Uber, or weather apps.
•Characteristics:
• Developed to meet specific user needs or solve problems.
• It is sold, licensed, or distributed to end users.
• Frequently updated to include new features, fix bugs, or improve
performance.
•User Interaction: The customer interacts directly with the software, and
2. Software as a Vehicle to Deliver a Product
In this case, software is the medium through which a product or service is delivered to the
end user.
•Examples:
• E-Commerce Platforms: Websites like Amazon or Flipkart, where software is used
to deliver the service of buying and selling products.
• Streaming Services: Platforms like YouTube, Spotify, or Netflix, where software
delivers video or audio content.
• Cloud Services: Services like Google Drive or Dropbox deliver data storage and
sharing capabilities via software.
• IoT Devices: Software embedded in devices (like smartwatches, Alexa, or
autonomous cars) delivers services such as fitness tracking, voice assistance, or
navigation.
•Characteristics:
• Acts as a conduit to enable access to the core product or service.
• The focus is on delivering seamless access, reliability, and integration with other
The nature of software refers to its inherent characteristics, qualities, and
behavior that make it distinct from physical products. Understanding the nature of
software helps us appreciate its development, maintenance, and evolution. Below
are the key aspects of the nature of software:
1. Intangible
• Software has no physical form; it cannot be touched or seen like
hardware.
• It exists as code, logic, and data stored in electronic devices.
• Challenges:
• Difficult to visualize or measure directly.
• Quality is judged through functionality, usability, and performance.

2. Engineered, Not Manufactured


• Unlike physical goods, software is not "manufactured"; it is designed
and engineered.
• Once developed, it can be replicated at virtually no cost (e.g.,
downloading an app).
3. Subject to Change
• Software is constantly evolving due to:
• Changing user requirements.
• New technologies or platforms.
• Fixes for bugs and performance improvements.
• Unlike physical products, software must update to stay relevant

4. Complexity
• Software systems can be incredibly complex, involving millions of lines of
code.
• Complexity grows as features are added, making it harder to manage and
maintain.
•5. Customizable
Errors and
are inevitable Flexible
due to this complexity.
• Software can be tailored to meet specific user or business needs.
• It allows for dynamic behavior, unlike hardware, which has fixed
functionality.
6. Non-Wearable but Degrades
• Software doesn’t physically wear out like hardware, but it "degrades" over
time:
• Outdated technology or design.
• Accumulation of technical debt.
• Compatibility issues with new systems.

7. Invisible and Abstract


• Software is inherently abstract and invisible.
• Its structure and functionality must be visualized through tools like:
• Flowcharts.
• UML diagrams.
• Wireframes or mockups.
8. Quality is Hard to Define
• Software quality depends on:
• Functionality: Does it meet user needs?
• Reliability: Does it work without errors?
• Usability: Is it easy to use?
• Performance: Is it fast and efficient?
• Maintainability: Can it be easily updated?
• Unlike hardware, these metrics are not always objective or
straightforward to measure.
9. Lifecycle-Oriented 10. Dependent on the Environment
• Software follows a lifecycle that
includes: • Software operates within a specific
• Requirements Analysis. environment (e.g., hardware, operating
• Design.
• Development. system).
• Testing. • Changes in the environment, such as
• Deployment.
• Maintenance. hardware upgrades or OS updates, may
• Maintenance often consumes the require software modifications.
largest share of resources (up to 60%).
11. Reusable
• Components or modules of software can be reused across
multiple projects, saving time and effort.
• Example: Libraries, APIs, frameworks like React or Angular.

12. Human-Centric
• Software is created to meet human needs, solve
problems, or improve processes.
• It requires input from various stakeholders:
• Users. Conclusion
The nature of software makes it unique compared
• Developers.
to traditional physical products. Its intangible,
• Designers. dynamic, and abstract qualities require careful
planning, continuous adaptation, and efficient
• Testers.
engineering practices to ensure its success and
sustainability in the ever-evolving digital world.
HOW S/W DIFFERS FROM H/W

1. s/w is developed or engineered. (not manufactured.)


2. Software doesn’t wear out.
3. Software continues to be custom built.

Figure depicts failure rate as a


function of time for h/w.
(bathtub curve)

It shows that h/w has high


failure rate in its early life,
then it drops to a steady state
level for some time &then
failure rate rises again.
DEFINING A SOFTWARE

1. instructions (computer programs) that when executed, provide

desired features, functions and performance.

2. data structures that enable programs to adequately manipulate

info.

3. descriptive info in both soft & hard copy that describes the

operations & use of the programs.


Defining Software
Software is a collection of instructions, data, and programs used to
operate computers and execute specific tasks. It is intangible and serves as
the bridge between the user and the computer's hardware, enabling the
system to perform a wide variety of functions.

Detailed Definition
Software can be defined as:
•"A set of computer programs, procedures, algorithms, and
associated documentation designed to perform a specific task or
solve a problem."
Key Components of Software
1. Programs (Code):
1. The core instructions written in programming languages (e.g., Python,
Java, C++).
2. Directs hardware to perform specific actions.
2. Data:
1. Information that programs use or process (e.g., input from users,
configuration files).
3. Documentation:
1. Manuals, guides, and technical references to help users and
developers understand and use the software.
Characteristics of Software

• Intangible: Cannot be physically touched or seen.

• Automated: Executes tasks automatically when properly configured.

• Reusable: Components or modules can be reused across

applications.

• Customizable: Can be tailored to meet specific user needs.

• Dynamic: Evolves over time with updates and new features.


Types of Software
1. System Software:
1. Software that manages hardware and system resources.
2. Examples: Operating systems (Windows, Linux), device drivers.
2. Application Software:
1. Software designed for end-users to perform specific tasks.
2. Examples: MS Office, web browsers, mobile apps.
3. Middleware:
1. Software that acts as a bridge between other software applications or
systems.
2. Examples: Database middleware, message queues.
4. Embedded Software:
1. Software embedded in devices to control their operations.
2. Examples: Software in washing machines, IoT devices, automotive systems.
S/W APPLICATION DOMAINS

1. System s/w: collection of programs written to service other programs. Ex:


compilers, editors, drivers, file mgt utilities etc.
2. Application s/w: stand alone programs that solve specific needs. Ex:
calculator, oven, automatic climate control in cars etc.
3. Engineering/scientific s/w: specifically designed for engineering/ scientific
needs. Ex: astronomy, volcanology, automotive stress analysis, ventilator etc.
4. Embedded s/w: resides within a product & controls the features and functions
as per the users choices. Ex: calculator, oven etc.
5. Product line s/w: designed to provide specific capability for use of many
different customers. Ex: word processing, spreadsheets, database mgt etc
6. Web applications: (web apps)
7. Artificial intelligence s/w: used to solve complex problems (robotics, neural
networks)
Importance of Software
• Automation: Reduces manual effort and increases efficiency.
• Problem-Solving: Provides solutions to complex real-world problems.
• Communication: Enables collaboration and communication through
applications like email, messaging, and social media.
• Business Operations: Essential for modern-day business processes like
inventory management, customer relations, and data analysis.

Conclusion
Software is the driving force behind modern technology, enabling computers
and other devices to function effectively. It is an essential part of every digital
system, and its versatility makes it a cornerstone of innovation in nearly
every industry.
S/W ENGINEERING

s/w engineering
layers
S/W ENGINEERING PRACTICE

• Software Engineering Practices

• Software Engineering Practices refer to a set of principles, methodologies,

and techniques followed to design, develop, test, and maintain high-quality

software systematically and efficiently. These practices aim to ensure that

the software meets user requirements, is reliable, scalable, and

maintainable, and is delivered on time and within budget.


KEY SOFTWARE ENGINEERING
PRACTICES

1. Requirements Engineering
2. Design Practices
3. Coding Practices
4. Testing Practices
5. Deployment Practices
6. Maintenance Practices
1. Requirements Engineering
•Objective: Understand what the client/user wants.

•Key Activities:

•Requirement elicitation (interviews, surveys, brainstorming)


(Elicitation in software engineering is the process of identifying and
documenting the requirements for a system from users, customers, and
other stakeholders:)

•Requirement analysis (identifying feasibility and conflicts)

•Requirement documentation (SRS - Software Requirement Specification)

•Requirement validation (ensuring completeness and correctness)


2. Design Practices

•Objective: Create a blueprint of the software system.


•Key Techniques:
•Architectural Design: High-level structure of the system.
•Detailed Design: Module-level details, algorithms, data structures.
•Design Principles: Modularity, scalability, reusability, cohesion, and low coupling.
•Use of UML diagrams like class diagrams, sequence diagrams, etc.

Cohesion refers to the degree to which Low coupling refers to a relationship in


elements within a module work which one module interacts with another
together to fulfill a single, well-defined module through a simple and stable
purpose
interface and does not need to be
concerned with the other module's
internal implementation
3. Coding Practices

•Objective: Translate the design into executable code.


•Best Practices:
•Follow coding standards (e.g., indentation, naming conventions).
•Write clean, readable, and maintainable code.
•Adhere to SOLID principles and DRY (Don’t Repeat Yourself).
•Use version control systems (e.g., Git) for collaboration and
versioning. Version Control Systems (VCS) like Git are essential tools for
modern software development. They help teams manage code
changes, collaborate effectively, and maintain a history of the
project’s evolution.
Why Use Git?
1.Collaboration: Multiple developers can work on the same
project simultaneously without overwriting each other’s work.
2.Versioning: Tracks every change made to the codebase,
allowing you to revert to previous versions if needed.
Indentation refers to the 3.Branching and Merging: Supports isolated feature
development through branches, which can be merged back into the
spaces at the beginning of a main codebase.
4.History Tracking: Maintains a complete history of who made

code line. changes, what they changed, and why (via commit messages).
5.Backup: Code is stored in remote repositories (e.g., GitHub,
GitLab, Bitbucket), providing a backup mechanism.
4. Testing Practices

• Objective: Identify and fix defects before deployment.

• Types of Testing:

• Unit Testing: Testing individual components.

• Integration Testing: Ensuring modules work together.

• System Testing: Validating the complete system.

• Regression Testing: Ensuring changes haven’t broken existing

functionality.

• Automation Testing: Using tools like Selenium or JUnit.


5. Deployment Practices
• Objective: Deliver the software to production efficiently.
• Best Practices:
• Use Continuous Integration/Continuous Deployment (CI/CD)
pipelines.
• Automate deployment processes (e.g., using Docker or
Kubernetes).
• Monitor and rollback in case of deployment issues.
6. Maintenance Practices
•Objective: Ensure the software remains
functional and up-to-date.
•Activities:
• Bug fixing.
• Feature enhancements.
• Code refactoring for better performance or
readability.
• Adapting software to new environments
(adaptive maintenance).
S/W ENGINEERING PRACTICE

1. Understand the problem (communication & analysis)

2. Plan a solution (modelling & design)

3. Carry out the plan (code generation)

4. Examine result for accuracy (testing & quality assurance)


1. UNDERSTAND THE PROBLEM

• Who are the stakeholders?

• What are the unknowns?

• Can the problem be compartmentalized? (divide the problem


into smaller ones to understand them easily)

• Can the problem be represented graphically?


2. PLAN THE SOLUTION

After understanding the problem properly, a design must be


made before actually coding for the problem.

• Have you seen similar problems before?


• Has a similar problem been solved? If so, then previous
solution can be used?
• Can subproblems be defined?
• Can you represent a solution that leads to effective
implementation?
3. CARRY OUT THE PLAN

Design created in previous step acts as a roadmap for the


system to be built.

• Does the solution confirm to the plan? (corelates with design


model?)
• Has the code and design been reviewed?
4. EXAMINE THE RESULT

We can never be sure that the solution is perfect. But we can


design sufficient amount of tests to minimize errors as much as
possible.

• Is it possible to test each component part of the solution?


• Does the solution produce results that confirm to requirements
of customer?
• Software Development Methodologies

• Agile: Iterative and incremental, emphasizes collaboration and flexibility.

• Waterfall: Linear and sequential, suitable for well-defined projects.

• Scrum: Framework under Agile with sprints and defined roles (e.g., Product Owner).

• DevOps: Combines development and operations for faster delivery and reliability.
• Best Practices for Modern Software Engineering

1.Adopt Agile and DevOps for speed and collaboration.

2.Focus on Quality Assurance (QA) throughout the

development lifecycle.

3.Leverage Automation in testing, builds, and deployment.

4.Ensure Continuous Feedback from stakeholders and users.

5.Use Metrics and Monitoring for performance and error

tracking.
SOFTWARE MYTHS

• We already have a book full of standards & procedures to build the s/w.

• If we get behind the schedule, we can add more programmers & catch
up.

• If I outsource project to a third party, I can relax & let them build it.

• s/w requirements continually change, but changes can be easily


accommodated as s/w is flexible.

• Once we write the program & get it to work, our job is done.

• Until I get the program running, there's no way to assess its quality.
S/W PROCESS

• A process is a collection of activities, actions and tasks.


• A process defines who is doing what when and how to reach a certain goal.

FIVE activities:
1. Communication: communicate/collaborate with customer/stakeholders
2. Planning: create a road map (s/w project plan) for that will guide the work
team.
3. Modelling: create a “sketch” to understand the big picture.
4. Construction: code generation & testing for errors.
5. Deployment: s/w is delivered to customer who then evaluates & provides
feedback.
• Software Process

• A software process is a structured set of activities involved in

developing a software system. It provides a framework for planning,

designing, developing, testing, and maintaining software.

Understanding the components and models of software processes is

essential to ensure high-quality software delivery.


A GENERIC PROCESS MODEL

• A generic software process model outlines the fundamental


activities that are common across all software development
projects. These activities provide a baseline that can be tailored
to fit specific project needs.
• Core Framework Activities:

1.Communication: Establishing collaboration and understanding between stakeholders and


developers (e.g., requirements gathering, meetings).

2.Planning: Defining objectives, timelines, resources, and tasks.

3.Modeling: Designing the system’s architecture, data structures, and user interface.

4.Construction: Writing code and testing the system.

5.Deployment: Delivering the software to the customer and gathering feedback.


1. Communication:
•Objective: Understand project objectives and gather requirements.
•Example: Meetings, brainstorming, and customer collaboration.

2. Planning:
•Objective: Create a roadmap for the project, define timelines, resources, and tasks.
•Example: Preparing schedules, identifying risks.

3. Modeling:
•Objective: Translate requirements into system designs and architecture.
•Example: Creating UML diagrams, data flow diagrams.

4. Construction:
•Objective: Write code and test the software.
•Example: Development, unit testing, integration testing.

5. Deployment:
•Objective: Deliver the software to users and gather feedback.
•Example: Installation, maintenance, updates.
A GENERIC PROCESS MODEL

• Supporting Activities:
• Configuration management.
• Quality assurance.
• Documentation.
• Risk management.
A GENERIC
PROCESS MODEL

Each framework activity has a set of s/w


engg. Actions.

Each s/w engg. action is defined by a


task set that identifies the work to be
done.
LINEAR PROCESS FLOW

• Linear process flow executes each framework activity in


sequence, starting with communication & ending with
deployment.
ITERATIVE PROCESS FLOW

• Iterative process flow repeats one or more activities before


proceeding to the next.
EVOLUTIONARY PROCESS FLOW

• Activities are executed in circular fashion.


• Each circuit through 5 activities leads to a more complete
version of s/w.
PARALLEL PROCESS FLOW

• One or more activities are executed in parallel with other


activities.
• Defining a Framework Activity

• Framework activities are high-level steps applicable to all


software processes. Each framework activity includes:

• Entry criteria: Conditions that must be met before starting


the activity.

• Tasks: Specific actions performed during the activity.

• Exit criteria: Conditions that must be met to consider the


activity complete.

• Deliverables: Outputs produced by the activity (e.g.,


requirements documents, test reports).
TASK SET

• A task set defines actual work to be done.


For ex: requirement gathering.

Task set for requirement gathering of a relatively small project will look
like this-
1. Make a list of stakeholders for the project
2. Invite all of them to an informal meeting
3. Ask each stakeholder to make a list of features & functions required.
4. Discuss those requirements & build a final list.
5. Decide priorities for those requirements.
6. Note areas of uncertainty.
• Identifying a Task Set

• A task set is a collection of specific actions required to achieve the


objectives of a framework activity. Task sets vary based on the:

• Project type: Small, medium, or large-scale.

• Project complexity: Simple, complex, or mission-critical.

• Team size: Number of people working on the project.

• Example:

• For the "Modeling" activity, a task set might include:

1.Creating system models (e.g., data flow diagrams, class diagrams).

2.Developing user scenarios.

3.Conducting design reviews.


PROCESS PATTERNS

• Every s/w team encounters a problem during s/w process.


• If solutions to these problems were readily available, then they can be
solved quickly.

• A process pattern
• describes process-related problems encountered during
work,
• identifies environment in which problem occurred &
• suggests one or more proven solutions for the problem.

i.e. the process pattern provides you with a template.


PROCESS PATTERNS

• A process pattern describes best practices, guidelines, or reusable solutions for


recurring issues during software development.

• Types of Process Patterns:

1. Stage Patterns: Define activities within a specific phase (e.g., coding, testing).

2. Task Patterns: Define tasks within an activity (e.g., code review).

3. Phase Patterns: Define the sequence of phases (e.g., requirements, design,


implementation).

• Example:

• Problem: Lack of clarity in requirements.

• Process Pattern: Conduct a structured requirements workshop.


TEMPLATE FOR PROCESS PATTERN
ACCORDING TO AMBLER [AMB98]

• Pattern name: a meaningful name that will describe the context.

• Forces: env. In which problem encountered.

• Type: type of the pattern

• Stage pattern: defines problem associated with framework activity

• Task pattern: defines problem associated with work task

• Phase pattern: defines sequence of framework activities that occur within the process

• Initial context: describes conditions under which pattern applies.


• Problem: the specific problem to be solved by the pattern.
• Solution: tells how to implement the pattern.
• Resulting context: tells the conditions which will result once the pattern is
applied.
• Related patterns: list of patterns related to this one.
• Known uses and examples: tells different aspects where pattern is applicable.
Ex:
PROCESS ASSESSMENT &
IMPROVEMENT

• Just because we’re building a s/w, doesn’t mean that it will be-
• delivered on time,
• will meet all of the customers needs or
• it will provide long term quality.
• There are different approaches to assess the software process &
improve it.

1) Standard CMMI assessment method for process improvement


This approach provides a 5 step process assessment model
having these phases- initializing, diagnosing, establishing,
acting, learning. CMMI: Capability Maturity Model Integration
2) CMM based appraisal for internal process improvement
Provides diagnostic technique
CMM was developed by the Software Engineering Institute (SEI) to
provide organizations with a model for improving their software processes.

3) SPICE
A standard that defines set of requirments for software process
assessment.

4) ISO 9001:2000
A generic standard that applies to any organization that wants to improve
overall quality for their products.
CMM (Capability Maturity Model) and SPICE
(Software Process Improvement and Capability
Determination, also known as ISO/IEC 15504)
2) CMM based appraisal for internal process improvement
Provides diagnostic technique
CMM was developed by the Software Engineering Institute (SEI) to provide organizations with a
model for improving their software processes.

3) SPICE
A standard that defines set of requirments for software process assessment.
SPICE is an international standard for process assessment. It focuses on evaluating the capability
of processes rather than the maturity of an organization.

4) ISO 9001:2000
A generic standard that applies to any organization that wants to improve overall quality for their
products.

CMM (Capability Maturity Model) and SPICE


(Software Process Improvement and Capability
Determination, also known as ISO/IEC 15504)
PRESCRIPTIVE PROCESS MODELS

• Prescriptive models provide structured approaches to software


development, defining clear stages, tasks, and deliverables.
• Types:
1.Waterfall Model
2.Incremental Process Models
3.Evolutionary Process Models
4.Concurrent Models
SDLC
MODELS
THE WATERFALL MODEL

The Waterfall Model is one of


the earliest and most
straightforward software
development methodologies. It is
a linear and sequential
approach where each phase
must be completed before the
next begins. This model is best
suited for projects with well-
defined requirements and
minimal expected changes.
PHASES OF THE WATERFALL MODEL

1. Requirements Analysis
2. System Design
3. Implementation
4. Testing
5. Deployment
6. Maintenance
THE WATERFALL MODEL

• Also called as a classic life cycle model


• Provides a systematic & sequential approach for software
development.
1. Requirements analysis and specification phase: aim of this
phase is to understand the exact requirements of the customer
and to document them properly.

Both the customer and the software developer work together


to document all the requirements of the software.

a large document called Software Requirement


Specification (SRS) is created which contains a detailed
description of what the system will do in the common
language.

2. Design Phase: This phase takes SRS from first phase and defines
the overall software architecture with high level and detailed
design.

All this work is documented as a Software Design Document


(SDD).
3. Implementation and unit testing:
• During this phase, design is implemented. If the SDD is complete, the
implementation or coding phase proceeds smoothly.
• During testing, the code is thoroughly examined and modified. Small
modules are tested in isolation initially.

4. Integration and System Testing:


• in this phase, the modules are tested for their interactions with each
other and with the system.

5. Operation and maintenance phase:


• delivery
• Support
• Feedback
• Key Characteristics
• Linear Process: Each phase flows sequentially into the next.
• No Overlap: Phases do not overlap, making it easy to
manage.
• Emphasis on Documentation: Every phase has specific
deliverables and documentation.
ADVANTAGES OF WATERFALL MODEL

• model is simple to implement & number of resources that are


required are minimal.
• The requirements are simple and explicitly declared; i.e. they remain
unchanged during the entire project development.
• The “start” and “end” points for each phase is fixed, which makes it
easy to cover progress.
• The release date for the complete product, as well as its final cost,
can be determined before development.
• Its easy to control and provides clarity for the customer due to a
strict reporting system.
DISADVANTAGES OF WATERFALL
MODEL

• In this model, the risk factor is higher, so this model is not suitable
for complex projects.
• This model cannot accept the changes in requirements during
development.
• It becomes tough to go back to the previous phase.
• Since the testing done at a later stage, it does not allow identifying
the challenges and risks in the earlier phase, so the risk reduction
strategy is difficult to prepare.
A variation in representation of
waterfall model is called v-model
which depicts relationship between
different stages and quality
assurance actions done in parallel.

V model tells us how verification


and validation actions are applied
to earlier engineering work.
Problems faced when using
waterfall model-

• Real projects rarely follow


sequential flow. Therefore can
cause confusion.

• It is often difficult for customer to


state all the requirements
explicitly. (which is required for
this model & can cause
uncertainty).

• Customer needs to have patience


Testing
as a of the device
major is planned
problem in parallel with a corresponding stage of development.
undetected
• When to use V-model?
• When the requirements are well defined and not ambiguous.
• When working on small to medium-sized projects where requirements are clearly defined and fixed.
• when sample technical resources are available with essential technical expertise.

• Advantages-
1. Easy to Understand.
2. Testing Methods like planning, test designing happens well before coding.
3. This saves a lot of time. Hence a higher chance of success over the waterfall model.
4. Avoids the downward flow of the defects.
5. Works well for small plans where requirements are easily understood.

• Disadvantages-
1. Very rigid and least flexible.
2. Not a good for a complex project.
3. Software is developed during the implementation stage, so no early prototypes of the software are
produced.
4. If any changes happen in the midway, then the test documents along with the required
documents, has to be updated.
INCREMENTAL PROCESS MODEL

• In Incremental Model,
the requirements are
divided into multiple
standalone modules.
• each module goes
through the
requirements, design,
implementation and
testing phases.
• Every subsequent
release of the module
adds function to the
previous release.
• This process continues
until the complete
system is achieved.
WHEN TO USE THE INCREMENTAL
MODEL?

• When the requirements are superior.

• A project has a lengthy development schedule.

• When Software team are not very well skilled or trained.

• When the customer demands a quick release of the product.

• You can develop prioritized requirements first.


Advantage of Incremental Model
• Errors are easy to be recognized.
• Easier to test and debug
• More flexible.
• Simple to manage risk because it handled during its iteration.
• The Client gets important functionality early.

Disadvantage of Incremental Model


• Need for good planning
• Total Cost is high.
• Well defined module interfaces are needed.
EVOLUTIONARY PROCESS MODELS

• Evolutionary models are iterative.


• They allow us to develop more complete versions of the software.

• Types-
• Prototyping model
• Spiral model
PROTOTYPING MODEL

• Prototype is defined as first or preliminary form


using which other forms are copied or derived.
• Prototype model is a set of general objectives for
software.
• It does not identify the requirements like detailed
input, output.
• It is software working model of limited
functionality.
• In this model, working programs are quickly
produced.
• Communication:
• developer and customer meet and discuss the overall objectives
of the software.
• Quick design:
• a Quick design is implemented when requirements are known.
• It includes only the important aspects like input and output
format of the software.
• It focuses on those aspects which are visible to the user rather
than the detailed plan.
• It helps to construct a prototype.
• Modeling quick design:
• This phase gives the clear idea about the development of
software because the software is now built.
• It allows the developer to better understand the exact
requirements.
• Construction of prototype
• The prototype is evaluated by the customer itself.

• Deployment, delivery, feedback:


• If the user is not satisfied with current prototype then it
refines according to the requirements of the user.
• The process of refining the prototype is repeated until all
the requirements of users are met.
• When the users are satisfied with the developed prototype
then the system is developed on the basis of final prototype.
ADVANTAGES OF PROTOTYPING
MODEL

• Its not necessary to know the detailed input, output, processes,


adaptability of operating system and full machine interaction.
• users are actively involved in the development process of this model.
• The development process is the best platform to understand the system
by the user.
• Errors are detected much earlier.
• Gives quick user feedback for better solutions.
• It identifies the missing functionality easily.
• It also identifies the confusing or difficult functions.
DISADVANTAGES OF
PROTOTYPING MODEL:

• The client involvement is more and it is not always considered by


the developer.
• It is a slow process because it takes more time for development.
• Many changes can disturb the rhythm of the development team.
• It is a thrown away prototype when the users are confused with it.
SPIRAL MODEL

• Spiral model is a risk driven process model.


• It is used for generating the software projects.
• In spiral model, an alternate solution is provided if the risk is
found in the risk analysis, then alternate solutions are suggested
and implemented.
• It is a combination of prototype and sequential model or
waterfall model.
• In one iteration all activities are done, for large project's the
output is small.
Advantages of Spiral Model
• It reduces high amount of risk.
• It is good for large and critical projects.
• It gives strong approval and
documentation control.
• In spiral model, the software is
produced early in the life cycle process.

Disadvantages of Spiral Model


• It can be costly to develop a software
model.
• It is not used for small projects.
CONCURRENT DEVELOPMENT MODEL

• in concurrent process model, activities move


from one state to another state.

Advantages
• This model is applicable to all types of software
development processes.
• It is easy to understanding and use.
• It gives immediate feedback from testing.
• It provides an accurate picture of the current
state of a project.

Disadvantages
• needs better communication between the team
members. This may not be achieved all the
time.
• It requires to remember the status of the
AGILE SOFTWARE DEVELOPMENT

• "Agile process model"


refers to a software
development approach
which is based on iterative
development.
• Agile methods break tasks
into smaller iterations or
parts.
• Each iteration is considered
as a short time "frame“.
• One frame typically lasts
from one to four weeks.
• The division of the entire
project into smaller parts
helps to minimize the
project risk.
• Each iteration involves a
team working through a
full software development
life cycle including
planning, requirements
analysis, design, coding,
and testing before a
working product is
demonstrated to the
client.
PHASES OF AGILE MODEL

1.Requirements gathering
2.Design the requirements
3.Construction/ iteration
4.Testing/ Quality assurance
5.Deployment
6.Feedback
HOMEWORK

• Unified process
• Agile methods
CASE STUDY

• Agile tools JIRA

You might also like