3. Agenda
Software Definition.
Attributes of good software.
Software Engineering :
• Software Engineering Definition.
• Software Development Life Cycle.
Waterfall Model.
V-Model.
Agile Scrum.
Introduction to software engineeringBy : Ahmed Elshahat Mohamed
4. What is software ?
Software is a set of instructions used to acquire inputs and to
manipulate them to produce the desired output in terms of
functions and performance as determined by the user of the
software.
software
Source
Code
Documents
System
Manuals
ProcessInputs Outputs
5. Types of software
Custom :
For a specific customer
Generic :
Specifications are produced by the marketing
department of the product company .They reflect
what they think
Embedded Software :
Software with principal role , specialized for
particular hardware that runs on and has time and
memory constraints .
6. Importance of software
It is embedded in all kinds of systems, such as
transportation, medical, telecommunications, military,
industrial processes, entertainment, office products, etc.
It is important as it affects nearly every aspect of our lives
and has become pervasive in our commerce, our culture,
and our everyday activities.
7.
8. Software quality attributes:
The software should deliver the required functionality and performance to user
and should be maintainable, reliable and acceptable.
9. Software quality attributes
• Reliability
Ability of Software to perform its intended functions and
operations in a system's environment, without experiencing
failure (system crash) always exist.
• Efficiency
Software should make the best use of the system resources.
And satisfy the required response time.
• Usability
Software must be usable by the users for which it was designed.
This means it must be understandable, usable and compatible
with other systems.
10. Software quality attributes
• Portability
Characteristics related to the ability to transfer the software from
one organization or hardware or software environment to another.
• Maintainability
Software must evolve to meet changing needs.
11. Software Cost
Software engineering is concerned with cost-efficient software
development.
The costs of software are often higher than the hardware cost.
Software costs more to be maintained than it does to be developed
For systems with long life,
maintenance cost may be several times
development cost.
About US$250 billions spent per year
in the US on application development.
Out of this, about US$140 billions wasted
due to the projects getting abandoned or reworked.
12. Software crisis
31% of projects get cancelled before they are completed .
53% over-run their cost estimates by an average 189% .
For every 100 projects , there are 94 projects restart .
Why !
• Schedule and cost estimates are often grossly inaccurate.
• Lack in productivity of software people .
• The quality of software sometimes less than expected .
• Communication between customer and developer is often poor.
• Software maintenance tasks devour the majority of funds.
13. Software crisis
The launched rocket by the European Space Agency , 1996 .
Software crisis led to software Engineering
15. What is software Engineering?
It is a systematic approach to
analysis, design, implementation,
test, maintenance
and reengineering of software,
so that it is of higher quality,
more affordable, maintainable,
cost efficient and faster to build.
16. Software development life cycle
Also known as software process.
Software Development Life Cycle (or SDLC) is the process
which is followed to develop a software product. It is a
structured way of building software applications. Most
organizations have a process in place for developing software.
The software-development life-cycle is used to facilitate the
development of a large software product in a systematic, well-
defined, cost-effective and fast way.
A set of activities whose goal is the development or evolution
of software.
18. Requirements
What the system should do and its development constraints, This
phase is the main focus of the project managers and stake holders
.
Meetings with managers, stake holders and users are held in order
to determine the requirements like , Who is going to use the
system? How will they use the system ? What data should be input
into the system ? What data should be output by the system ?
These are general questions that get answered during a
requirements gathering phase.
19. • Functional Requirements: specify what actually the system
does.
•Non-functional Requirements: specify system limits and
constrains example: memory size, power consumption and
aspects concerning maintainability, portability, and usability.
Requirement types
Functional
Requirements
Non-functional
Requirements
20. Requirements analysis
The purpose of a requirements
analysis is to identify the qualities
required of the application,
in terms of functionality,
performance, ease of use,
portability, interfaces, security.
The requirements describe
the “what” of a system, not the “how” .
The o/p of this step is An SRS .
21.
22.
23.
24. Software Requirement Specification Document
An SRS document is generated as the output of requirements
analysis.
Requirements analysis involves obtaining a clear and thorough
understanding of the product to be developed. Thus, the SRS
should be a consistent, correct, unambiguous, and complete
document.
An SRS document must contain the following:
Detailed statement of problem.
Possible alternative solution to problem.
Functional requirements of the software system.
Constraints on the software system.
25. Software Requirement Specification Document
Requirements documentation is the description of what a particular
software does or shall do.
It is used throughout development to communicate how the
software functions or how it is intended to operate. It is also used
as an agreement or as the foundation for agreement on what the
software will do.
Requirements are produced and consumed by everyone involved
in the production of software: end users, customers, product
managers, project managers , designers , developers, and testers.
26. Requirement Traceability
The ability to describe and trace the life of a requirement
, is it covered by coding team and testing team (create test
cases) .
Requirement traceability matrix is documented table to
trace the progress in the project
28. Software Design
Software design is the blueprint of the system, which once
completed can be provided to developers for code
development. Based on the components in design, they are
translated into software modules/functions/libraries, etc…
and these pieces together form a software system.
30. Software Design
High Level Design (HLD) : is the overall system design , It
describes the relation between various modules and functions of
the system.
Low Level Design (LLD) : is like detailing the HLD. It defines the
actual logic for each and every component of the system.
31. Flow chart
Flow chart is a type of diagram that describe the path of data , or
process step by step, showing the steps as boxes of various kinds
and their order by connecting with arrows.
Flow charts are used in designing processes or programs to
make them simple to understand.
The biggest advantage of a flow chart is that it gives an overall
view of the process at a single glance , to understand it better
32. Commonly used shapes in flow charts
Flow Line
An arrow coming from one symbol
and ending at another symbol
represents that control passes to
the symbol the arrow points to.
Terminal
Represented as circles. They usually
contain the word "Start" or "End", or
another phrase signaling the start or
end of a process.
Process
Represented as rectangles. This
shape is used to show that
something is performed. Examples:
"Add 1 to X .
Decision
Represented as a diamond showing
where a decision is necessary,
commonly a Yes/No question or
True/False test.
Generally , flowcharts flow from top to bottom and left to right.
34. Pseudo-code
using pseudo-code , the designer describes system
characteristics using short , concise English language
phrases that are structured by keywords , such as if-
Then-Else, while-do , and End.
Its written in structured manner .
36. Software Architecture
Why SW Layers ?
Isolate Application from HW changes as
upper layers don’t affect by lower ones
(Portability).
Reusability of the SW driver among different
applications.
Easier in Testing.
Simplifies isolation of software bugs
(detection and correction).
Easier Software updates and upgrades
(Software maintainability).
37. Development(Coding)
On receiving system design documents,
the work is divided in modules/units and actual coding is
started.
Since, in this phase the code is produced so it is the main
focus for the developer.
The output of this phase
is an implemented
and tested collection of modules.
38. Testing
After the code is developed it is tested against the requirements to
make sure that the product is actually solving the needs addressed
and gathered during the requirements phase.
40. 1.Unit testing : Test the software for defects and bugs .
2.Component testing :Test functionality of each module alone.
3.Integration testing : Test the interfaces and interactions between
integrated modules .
4.System testing : Checking the whole system in the intention of
finding defects and anomalies from both the design & the
requirements.
5.User Acceptance Testing : The acceptance test phase is the
phase used by the customer to determine whether to accept the
system or not. When the software passes those tests it has been
accepted by the client as meeting the requirements .
43. Maintenance
It is an important part of the SDLC .it may consume
time more than that taken for development and cost
that range from 50% to 80% of the total development
cost .
45. Types of maintenance
1. Corrective maintenance : it is repairing processing
or performance failures or making changes because
of previously uncorrected problems .
2. Adaptive maintenance : changing the program
function . This is done to adapt to the external
environment change .
3. Perfective maintenance : enhancing the
performance or modifying the programs to respond to
the user’s additional or changing needs.
4. Preventive maintenance : it is the process by which
we prevent our system from being obsolete. It
involves the concept of re-engineering an old system
with an old technology using new technology
47. Software Development Methodology
Plan driven:
Plan driven processes where all the process activities
are planed in advance .
In this way, we can measure the progress of the
process against this plan.
Agile:
In Agile processes planning is incremental and it is
easier to change the plan and the software to reflect
changing customer requirements .
As activities can be changed, so the progress of
development process is not measured exactly.
49. Waterfall model
The waterfall model is a very common software development
process model.
The waterfall model was popularized in the 1970s and
permeates most current software-engineering textbooks and
standard industrial practices.
As the figure shows, the process is structured as a cascade of
phases, where the output of one phase constitutes the input to
the next one. Each phase, in turn, is structured as a set of
activities that might be executed by different people concurrently.
Because of the cascade from one phase to another, this model is
known as the waterfall model.
50. Waterfall model
Advantages of Waterfall Model
1.it is a simple one. Easy to understand, easy to use.
2.Easy to manage due to the rigidity of the model –each phase has
specific deliverables and a review process.
3.Phases are processed and completed one at a time.
4.Works well for smaller projects where requirements are very well
understood.
51. Waterfall model
Disadvantages of Waterfall Model
1.This model is not suitable for accommodating any change. So this
model is Not suitable for the projects where requirements are at a
moderate to high risk of changing.
2.We can not go backward in the SDLC. Once an application is in
the testing stage, it is very difficult to go back and change
something that was not well-thought out in the concept stage
3.It does not scale up well to large and complex projects.
4.Poor model for long and ongoing projects.
5.No working software is produced until late during the life cycle.
52. Waterfall model
When to use the waterfall model
1.Requirements are very well known, clear and fixed.
2.Product definition is stable.
4.There are no ambiguous requirements
5.The project is short
53. Developers life cycle V-Model Tester life cycle
Requirements
specification
High level Design
Low level Design
coding
Software code
Unit testing
Component testing
Integration Testing
System testing
54. V-model
The V-model represents a software development , which may be
considered an extension of the waterfall model. Instead of moving
down in a linear way, the process steps are bent upwards after the
coding phase, to form the typical V shape. The V-Model
demonstrates the relationships between each phase of the
development life cycle and its associated phase of testing.
Requirements like SRS document begin the life cycle model just
like the waterfall model. But, in this model before development is
started, a system test plan is created. The test plan focuses on
meeting the functionality specified in the requirements gathering.
55. V-model
The high-level design (HLD) or Architecture Design phase
focuses on system architecture and design. It provide overview of
solution, platform, system, product and service/process. An
integration test plan is created in this phase as well in order to
test the pieces of the software systems ability to work together.
The low-level design(LLD) or Detailed Design Phase or
Module Design Phase is where the actual software components
are designed. It defines the actual logic for each and every
component(Module) of the system. Component tests or Module
Tests are created in this phase as well.
56. V-model
The implementation(Coding) phase is where all coding takes
place. Unit Testing is created in this phase in order to test the
software for defects and bugs . Then is performed on the code
once coding is complete . The path of execution continues up the
right side of the V where the test plans developed earlier are now
put to use. This is at the bottom of the V-Shape model. Module
design is converted into code by developers.
57. V-model
Advantages of V-model
1.Simple and easy to use.
2.Testing is a full life-cycle activity ,this saves a lot of time. Hence
higher chance of success over the waterfall model.
3.Proactive defect tracking –that is defects are found at early stage.
58. V-model
Disadvantages of V-model
1.Software is developed during the implementation phase, so no
early prototypes of the software are produced.
2.If any changes happen in midway, then the test documents along
with requirement documents has to be updated.
3.Heavy weight documentation.
4.It needs lot of resources . It can be implemented by only some big
companies
59. Waterfall Limitations
Waterfall
limitations
Sequential in nature,
complete a stage before
moving to next stage
No working version of the
system until late in the
process
Any changes customer mentions
in between may cause a lot of
rework
Doesn't account for the
fact that requirements
constantly change
60. Agile Scrum
Many projects fail to deliver value in either a timely fashion or at all
For both technical and non-technical reasons. So agile allows us to
focus on delivering the highest business value in the shortest time.
For progress in project , software is developed and delivered in
small iterations (Sprints).
It helps the business to see the work , or want to receive product
benefit earlier or help in later changes .
61. Agile principles
Our highest priority is to satisfy the customer through early and
continuous delivery of valuable software .
Welcome changing requirements , even late in development.
Deliver working software (customer value ) with a preference to
the shorter time scale.
Simplicity .
62. Agile Scrum
The Agile Scrum life cycle :
Every sprint :
Project endSprint 3Sprint 2Sprint 1
Project
start
Detailed
requirements
Design
develop
test
63. Characteristics of Agile Scrum
Scrum projects make progress in a series of “sprints”.
Typical duration is 2–4 weeks or a calendar month at most.
Product feature is designed, coded, and tested during the sprint.
Teams are co-located , or simulate being together.
Face to face communication is preferred over documentation
66. Product owner
■ Define the features of the product (responsible for the
backlog and story) .
■ Decide on release date and content .
■ Prioritize features according to market value .
■ Accept or reject work results .
■ Helps define ‘done’ .
67. The Scrum Master
• Process facilitator .
• Represents management to the project .
• Helps builds self organizing teams .
• Removes impediments
• Ensure that the team is fully functional and productive .
• Enable close cooperation across all roles and functions .
• Shield the team from external interferences .
68. The team
• Typically 5-9 people
• Cross-functional
• Programmers, testers, designers, analyst , etc.
• Teams are self-organizing
• Accountable for delivery of result that meet the customer’s needs
and software quality
• Membership should change only between sprints
70. Product backlog
• The requirements
• A list of all desired work on the project
• Ideally expressed such that each item has value to the users or
customers of the product
• Prioritized by the product owner
• Reprioritized at the start of each sprint
This is the
product backlog
71. Sprint Backlog
Team selects items from the product backlog they can
commit to completing.
Sprint backlog is created
Tasks are identified and each is estimated (1-16
hours)
Collaboratively, not done alone by the Scrum
Master
75. Sprint planning meeting
Sprint prioritization
• Analyze and evaluate product
backlog
• Select sprint goal
Sprint planning
• Decide how to achieve sprint
goal (design)
• Create sprint backlog (tasks)
from product backlog items
(user stories / features)
• Estimate sprint backlog in hours
Sprint
goal
Sprint
backlog
Business
conditions
Team
capacity
Product
backlog
Technology
Current
product
Sprint planning
76. The daily scrum
• Parameters
• Daily
• 15-minutes
• Stand-up
• Not for problem solving
• Whole world is invited
• Only team members, Scrum Master, product
owner, can talk
• Helps avoid other unnecessary meetings
77. Everyone answers 3 questions
What did you do yesterday?
1
What will you do today?
2
Is anything in your way?
3
78. The sprint review
• Team presents what it accomplished during the sprint
• Typically takes the form of a demo of new features Informal
• 2-hour prep time rule
• Whole team participates
• Invite the world
79. Sprint retrospective
■ Periodically take a look at what is and is not
working
■ Typically 15–30 minutes
■ Done after every sprint
■ Whole team participates
– Scrum Master
– Product owner
– Team
– Possibly customers
80.
81.
82.
83.
84. Parameters Agile Model Non-Agile Models
Approach of this methodology This methodology is very flexible and
adjustable and can adapt to the
project needs.
This methodology is not as flexible as
Agile model and it’s tough to
accommodate changes in the project.
Measurement of Success The success of the project in Agile
model is measured by the Business
value delivered.
In this methodology the success of
the project is measured by the
Conformation to plan.
Size of the Project The Project size is usually small in
Agile model. However larger projects
can also be handled using the Scaled
Agile Framework (SAFe).
The project size is Large in non- Agile
models.
Ability to adapt to change In Agile model the changes are
accepted and adapted as per the
project needs.
But in non-Agile models the changes
are not accepted easily in the later
stages of the development.
Difference between Agile model and Non-Agile models
85. Documentation required Less documentation is required in
Agile.
More documentation is required in
non-Agile models.
Importance of In Agile model more emphasis is given
to the people that means it’s People-
Oriented.
In non-Agile models the more
importance is given to the process
hence it’s Process- Oreinted.
Planning in Advance There is minimal upfront planning in
Agile methodology.
In Non-Agile models the planning
should be complete before the
development starts.
Revenue In Agile method the return on
investment is early in the project cycle.
In non-Agile methods the return on
investment is at the end of the project.
Size of the team The size of the team in Agile
methodology is usually small and
creative.
But in Non-Agile models the team size
is large.
