1.
Syed Saqib Raza Rizvi

2.
What is Engineering?
What is Software?
What is software engineering?
What is a software process?
Different types of process models?
Different Models with Strengths and Weaknesses
Agile Software Development

3.
Engineering is the application of scientific
and practical knowledge in order to invent,
design, build, maintain, and improve
systems, processes, etc.

4.
The software is collection of Integrated programs
Software consists of carefully-organized instructions and
code written by programmers in any of various special
computer languages.
Computer programs and associated documentation such
as requirements, design models and user manuals.

5.
Software engineering is an engineering discipline that is
concerned with all aspects of software production.
According to IEEE's definition software engineering can
be defined as the application of a systematic, disciplined,
quantifiable approach to the development, operation, and
maintenance of software, and the study of these
approaches; that is, the application of engineering to
software.

6.
 A framework that describes the activities performed at each stage of
a software development project.
 A set of activities whose goal is the development or evolution of
software.
 Generic activities in all software processes are:
 Specification - what the system should do and its development
constraints
 Development - production of the software system
 Validation - checking that the software is what the customer
wants
 Evolution - changing the software in response to changing
demands.

7.
Waterfall Model
Incremental Model
RAD Model
Spiral Model
Scrum Model
Lean Development Methodology
Extreme Programming
Etc

8.
 .

9.
Easy to understand, easy to use
Provides structure to inexperienced staff
Milestones are well understood
Good for management control (plan, staff, track)
Works well when quality is more important than cost or
schedule

10.
All requirements must be known upfront
Deliverables created for each phase are considered frozen
inhibits flexibility
Can give a false impression of progress
Does not reflect problem-solving nature of software
development – iterations of phases
Integration is one big bang at the end
Little opportunity for customer to preview the system
(until it may be too late)

11.
Requirements are very well known
Product definition is stable
Technology is understood
New version of an existing product
Porting an existing product to a new platform.
High risk for new systems because of specification
and design problems

12.
Whole requirement is divided into various builds
Multiple development cycles take place here, making the
life cycle a “multi-waterfall” cycle.
Cycles are divided up into smaller, more easily managed
modules.
Each module passes through the requirements, design,
implementation and testing phases.
A working version of software is produced during the first
module, so you have working software early on during the
software life cycle.

13.
Generates working software quickly and early during the
software life cycle.
More flexible – less costly to change scope and
requirements.
Easier to test and debug during a smaller iteration.
Customer can respond to each built.
Lowers initial delivery cost.

14.
Needs good planning and design.
Needs a clear and complete definition of the whole system
before it can be broken down and built incrementally.
Total cost is higher than waterfall.

15.
Requirements of the complete system are clearly defined
and understood.
Major requirements must be defined; however, some
details can evolve with time.
There is a need to get a product to the market early.
A new technology is being used
Resources with needed skill set are not available

16.
Rapid Application Development model
type of incremental model
In RAD model the components or functions are developed
in parallel as if they were mini projects.
The developments are time boxed, delivered and then
assembled into a working prototype.
This can quickly give the customer something to see and
use and to provide feedback regarding the delivery and
their requirements.

17.
Reduced development time.
Increases reusability of components
Quick initial reviews occur
Encourages customer feedback

18.
Depends on strong team and individual performances for
identifying business requirements.
Only system that can be modularized can be built using
RAD
Requires highly skilled developers/designers.
High dependency on modeling skills
Inapplicable to cheaper projects as cost of modeling and
automated code generation is very high.

19.
RAD should be used when there is a need to create a
system that can be modularized in 2-3 months of time.
It should be used if there’s high availability of designers
for modeling and the budget is high enough to afford their
cost along with the cost of automated code generating
tools.
RAD SDLC model should be chosen only if resources with
high business knowledge are available and there is a need
to produce the system in a short span of time (2-3 months).

20.
The spiral model is similar to the incremental model, with
more emphasis placed on risk analysis.
The spiral model has four phases: Planning, Risk Analysis,
Engineering and Evaluation.
A software project repeatedly passes through these phases
in iterations (called Spirals in this model).
The baseline spiral, starting in the planning phase,
requirements are gathered and risk is assessed.

21.
High amount of risk analysis hence, avoidance of Risk is
enhanced.
Good for large and mission-critical projects.
Strong approval and documentation control.
Additional Functionality can be added at a later date.

22.
Can be a costly model to use.
Risk analysis requires highly specific expertise.
Project’s success is highly dependent on the risk analysis
phase.
Doesn’t work well for smaller projects.

23.
When costs and risk evaluation is important
For medium to high-risk projects
Users are unsure of their needs
Requirements are complex
New product line
Significant changes are expected (research and
exploration)

24.
Traditional approach to managing software development
projects was failing far too often, and there had to be a
better way
Agile development is a different way of managing IT
development teams and projects
Came up with the agile manifesto, which describes 4
important values that are as relevant today

25.
 Individuals and interactions over processes and tools
 Working software over comprehensive documentation
 Customer collaboration over contract negotiation
 Responding to change over following a plan

26.
1. Active user involvement is imperative
2. The team must be empowered to make decisions
3. Requirements evolve but the timescale is fixed
4. Capture requirements at a high level
5. Develop small, incremental releases and iterate

27.
6. Focus on frequent delivery of products
7. Complete each feature before moving on to the next
8. Apply the 80/20 rule
9. Testing is integrated throughout the project lifecycle – test
early and often
10. A collaborative & cooperative approach between all
stakeholders is essential

28.
 Is also an agile development method, which concentrates
particularly on how to manage tasks within a team-based
development environment.
Scrum is the most popular and widely adopted agile
method
Relatively simple to implement and addresses many of the
management issues that have plagued IT development
teams for decades

29.
•A product owner creates a prioritized wish list called a product backlog.
•During sprint planning, the team pulls a small chunk from the top of that
wish list, a sprint backlog, and decides how to implement those pieces.
•The team has a certain amount of time — a sprint (usually two to four
weeks) — to complete its work, but it meets each day to assess its progress
(daily Scrum).
•Along the way, the Scrum Master keeps the team focused on its goal.
•At the end of the sprint, the work should be potentially shippable: ready
to hand to a customer, put on a store shelf, or show to a stakeholder.
•The sprint ends with a sprint review.
•As the next sprint begins, the team chooses another chunk of the product
backlog and begins working again-

30.
XP (Extreme Programming) is a more radical agile
methodology,
Focusing more on the software engineering process
 Addressing the analysis, development and test phases
with novel approaches that make a substantial difference
to the quality of the end product.

31.
1. You need to improve communication.
2. You need to seek simplicity.
3. You need to get feedback on how well you are doing.
4. You need to always proceed with courage.

32.
In XP these four basic activities are implemented by using
practices which are traditional software engineering
practices but elevated to embody and encourage XP
values.
Although practices of Extreme Programing they can be
compacted into twelve simple rules

33.
1. User stories (planning): User stories can be viewed as a smaller version of use case. In this way, the
customer define as briefly as possible the specification of the new application (features, value, priority).
These stories will be the base for the project team to do cost estimation and management of the project.
2. Small releases (building blocks): XP emphasizes on small, simple but frequent versions updates of the
application. Each newly added requirement will instantly incorporated and the system is re-released.
3. Metaphor (standardized naming schemes): Developers and programmers must adhere to standards on
names, class names and methods.
4. Collective ownership: In XP methodology, all code is considered to be owned by the whole team and not
an individual property. Hence, all code is reviewed and updated by everyone.
5. Coding standard: Styles and formats of coding must be the same in order to enable compatibility
between team members. This approach results in more rapid collaboration.
6. Simple design: Always look for system implementation that is as easy as possible implementation of
the system yet meets all required functionality.

34.
7. Refactoring: The application should be continually adjusted and improved by all team
members. This requires extremely good communication between members to avoid work
duplication.
8. Testing: Every small release (called building block) must pass tests before being released.
XP’s uniqueness in this aspect is that tests are created first and then application code is
developed to meet and pass the challenges of those pre-written tests.
9. Pair programming: XP programmers work in pairs. All code is developed by two
programmers who work together at a single machine. The expectation is that pair programming
produces higher quality code at the same or less cost.
10. Continuous integration: Software builds are completed several times a day. In this way all
developers can avoid work fragmentations because they continuously releasing and integrating
code together.
11. 40-hour workweek: Keep mental and physical conditions to be up and running by not
working more than what the bodies can handle.
12. On-site customer: The customer must be viewed as an integral part of the project. The
customer must be arranged to be available at all times in order to ensure that the project is in the
right track.