software eng

1. Software Engineering
Software Engineering, A Practitioner’s Approach, Roger S,
Pressman.(2014).
An Integrated Approach to Software Engineering, Pankaj
Jalote, Narosa,3rd edition.
Software Testing - Concepts & Practices, K. Mustafa, R. A.
Khan, Narosa,Reprint 2009.

2. What is Software?
• Software is a set of programs performs a
specific task.
• Software, when made for a specific
requirement is called software product.

3. What is Engineering
• Engineering is all about developing products,
using well-defined, scientific principles and
methods.

4. What is Software Engineering?
• Software engineering is an engineering
branch associated with development of
software product using well-defined scientific
principles, methods and procedures.
• The outcome of software engineering is an
efficient(max productivity with min. wasted
efforts) and reliable(good quality of s/w)
software product.

5. Why Software Engineering is
important?
• It enables us to build complex system in a
timely manner.
• It ensures high quality of software.

6. What is work Product?
• It means result/outcome of software.
• 1. Software Engineer:
• The work product of s/w eng. is set of
programs, the content along with
documentation that is a part of s/w.
• 2. User/Customers:
• The functionality delivered by the s/w that
improves user experience.

7. Software Engineering Focuses on?
• 1. Quality:
• A) Functional: Degree to which correct software
is produced.
• B)Non-functional(Structured):
robustness,efficient,reliable.
• 2. Maintainability:
• After the s/w has been developed and delivered.
• Should be easily enhanced and adapt to change
requirements whenever required.

8. Types of Software.
• 1. System Software: The software that provides a platform
for other software to run.
• Eg. Operating system etc.
• 2. Application Software: They serve a particular purpose.
• Eg. Payroll , online shopping, Ms office etc.
• 3. Engineering/Scientific software:
• Solves complex numerical problems.
• Eg. Genetic Analysis, Astronomical etc.
• 4. Embedded S/w:
• Provides limlited features and functionality.
• Eg. Washing Machines, Micro wave ovens etc.
• 5. AI S/w:
• Induce human like intelligence in machines.
• Eg. Robotic, game playing s/w.

9. • 6. Legacy software:
• Very old and traditional software.
• Changed from time to time.
• Do not have good quality.
• 7. web/ Mobile application:
• Those s/w that run on browser or mobile.
• Eg candy crush etc.
• 8. Real world s/w:
• Control,monitor,analyse real world events in real time.
• Eg. Weather forecasting etc.

10. Software engineering - Layered
technology
• Software engineering is a fully layered
technology.
• To develop a software, we need to go from
one layer to another.
• All these layers are related to each other and
each layer demands the fulfillment of the
previous layer.

11. • Software eng. Comprises of a process, aset of
methods for managing and developing the s/w
and a collection of tools,
• The main layer of software eng. Is Quality.
• 1. Quality:
• A. Functional: Degree to which correct software
is developed.
• B)Non-functional(Structured):
• Robustness, maintainability.
• Eg. Six sigma

12. 2. Process:
• A framework that must be estabilished for
effective delivery of s/w.
• Timely development of software.
• Management and control of software projects.
3. Methods:
• Provide technical “how to” for building a
software.
• Each method consis of multiple tasks.
• Eg. Requirement analysis,testing,support etc.
4. Tools:
• Provides automated/semi automated support for
process and methods.
• Eg. CAD.

13. Software Development Life Cycle,
SDLC
• Software Development Life Cycle, is a well-
defined, structured sequence of stages in
software engineering to develop the intended
software product.

14. SDLC Activities
• SDLC provides a series of steps to be followed
to design and develop a software product
efficiently. SDLC framework includes the
following steps:

15. • Communication
• This is the first step where the user initiates the request for a desired software
product.
• He contacts the service provider and tries to negotiate the terms.
• He submits his request to the service providing organization in writing.
• Requirement Gathering
• This step onwards the software development team works to carry on the project.
• The team holds discussions with various stakeholders from problem domain and
tries to bring out as much information as possible on their requirements.
• The requirements are contemplated and segregated into user requirements,
system requirements and functional requirements.
• The requirements are collected using a number of practices as given –
– studying the existing system and software,
– conducting interviews of users and developers,
– referring to the database or
– collecting answers from the questionnaires.

16. • Feasibility Study
• After requirement gathering, the team comes up with a rough plan of software
process.
• At this step the team analyzes if a software can be made to fulfill all requirements
of the user and if there is any possibility of software being no more useful.
• It is found out, if the project is financially, practically and technologically feasible
for the organization to take up.
• There are many algorithms available, which help the developers to conclude the
feasibility of a software project.
• System Analysis
• At this step the developers decide a roadmap of their plan and try to bring up the
best software model suitable for the project.
• System analysis includes Understanding of software product limitations, learning
system related problems or changes to be done in existing systems beforehand,
identifying and addressing the impact of project on organization and personnel
etc.
• The project team analyzes the scope of the project and plans the schedule and
resources accordingly.

17. • Software Design
• Next step is to bring down whole knowledge of requirements and
analysis on the desk and design the software product.
• The inputs from users and information gathered in requirement
gathering phase are the inputs of this step.
• The output of this step comes in the form of two designs; logical
design and physical design.
• Engineers produce data-flow diagrams and in some cases pseudo
codes.
• Coding
• This step is also known as programming phase.
• The implementation of software design starts in terms of writing
program code in the suitable programming language and
developing error-free executable programs efficiently.

18. • Testing
• Software testing is done while coding by the developers
and thorough testing is conducted by testing experts at
various levels of code such as module testing, program
testing, product testing, in-house testing and testing the
product at user’s end.
• Early discovery of errors and their remedy is the key to
reliable software.
• Integration
• Software may need to be integrated with the libraries,
databases and other program(s).
• This stage of SDLC is involved in the integration of software
with outer world entities.

19. • Implementation
• This means installing the software on user machines.
• At times, software needs post-installation configurations at user
end.
• Software is tested for portability and adaptability and integration
related issues are solved during implementation.
• Operation and Maintenance
• If required, the users are trained on, or aided with the
documentation on how to operate the software and how to keep
the software operational.
• The software is maintained timely by updating the code according
to the changes taking place in user end environment or technology.
• This phase may face challenges from hidden bugs and real-world
unidentified problems.

20. • Disposition
• As time elapses, the software may decline on the
performance front.
• It may go completely obsolete or may need
intense upgradation.
• This phase includes archiving data and required
software components, closing down the system,
planning disposition activity and terminating
system at appropriate end-of-system time.

21. Software LifeCycle Models
• The process followed in the development of
the software depends upon the Life cycle
model chosen for development.
• Types of Life Cycle Model.
• (A) Prescriptive Models
• 1. Waterfall Model.
• 2. Incremental process model.
– Iterative model.
– Rapid application model.

22. • 3. Evolutionary Models.
– Prototyping model.
– Spiral Model
(B) Specialized Process Models.
1. Agile Model.
2. Rational Unified process model.

23. Waterfall Model
Design
Coding and unit testing
Integration & system
Testing
Requirement Gathering
Implementation
Operation and Maintenance

24. Waterfall Model.
• The waterfall model is also called as 'Linear
sequential model' or 'Classic life cycle model'.
• It says that all the phases of SDLC will function
one after another in linear manner.
• That is, when the first phase is finished then
only the second phase will start and so on.
• This model does not work smoothly if there
are some issues left at the previous step.
• The sequential nature of model does not allow
us go back and undo or redo our actions.

25. Requirement Gathering
Purpose:To understand customer requirements
and document them Properly.
Work product: SRS(Software requirement
specification)
Use: Used as a contract between developer and
customer.

26. Design
• Purpose: Transforms requirements into a
structure suitable for implementation in some
programming language.
• Software architecture is specified in detail.
• Work Product: SDD(Software Design
Document)
• Use: Useful for start coding.

27. • Coding: SDD is used for coding.
• Testing:
1. Unit Testing: Each module is tested
independently of other module.
• Integration & System Testing:
• Integration: Bring all the modules together,
combine it to form a complete software & test
it.
• System Testing:The whole software is tested
by considering environment,hardware etc.
• Actual software is deployed at customer place
and tested.

28. Operation and Maintenance:
• Purpose: After the delivery and deployment of
the software to the customer, maintanance
can be done like error correction, Improve
software .

29. Problems with waterfall model.
• Expects complete and accurate requirements
early in s/w development process.
• Working s/w is not available till very late in the
s/w development cycle.(delay in error
discovery)
• Change- not suitable for accomodating
changing during development.
• Sequential Nature-not realistic in todays
world and this model is not suitable for large
projects

30. When to use waterfall model.
• When the requirements are very clearly
understood and they will not change during
SDLC.
• Can be used by an organization:
– That has an experience in developing a particular
kind of software.
– When it wants to build a new software based on
an existing software.

31. Incremental Model.

32. Incremental Process Model.
• Aim: Deliver limited functionality quickly.
• Requirements: defined clearly.
• No confusion about requirements.
• Delivery of Functionality: is done in multiple
phases depending upon the priorities of the
requirements.
• Every Cycle: deliveres a semi-completed product
with limited functionality.
• Last Cycle: Complete s/w.

33. Iterative Enhancement Model.
• Phase Same phases as waterfall model
• They are implemented with less restriction.(No need to
follow sequential manner)
• Occurs in same order but in several cycles.
• Requirement Major requirements are specified by the
customer at beginning and SRS is prepared.
• Priorities- decided for different requi. by customer and
developer.
• Implementation of these requirement is done based
on priorities.

35. Waterfall vs Incremental
• Waterfall
• One final product at the end of SDLC with all the
functionalities.
• Long wait for the software.
• Incremental.
• Complete s/w is divided into releases.
• Limited functionality is released in every cycle.
• First release is available within a weeks/months.

36. RAD(Rapid Application Development) Model.
• Developed by IBM.
• In RAD user participation is very important.
• RAD model is Rapid Application Development
model. It is a 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.
Requirement
Planning
User
Description
Construction Cut Over

37. 1. Requirement Planning:
• Using group elicitation techniques like brain
stroming.
• User communication required for good
understanding of requirements..
• To gather and finalize the requirement by using
following prototype.
• As long as requirements is finalized the process
continues.
Feedback
User Evaluation
Build Rapid
prototype
Prototype
refined

38. 2. User Description:A joint team of customers
and developers understands and reviews the
gathered requirements.
• Automated tools may also be used.
3. Construction:Designcoding testing
• Product is released.
• For quick development we use automated
code,screen generator.
4. Cut over:All development is over.
• Install the software+Acceptance
testing+Training of the user.

39. Major Features.
• Rapid Prototype: Quick initial views about
product.
• Powerful development tools: Development
time goes down.
• User involvement: Acceptability of the
product increase.

40. Not useful when
• User cannot be involved continuously.
• Tools & resuable components cannot be used.
• Highly skilled & specialized developers.

41. SDLC Evolutionary Model
• SDLC Evolutionary model builds the required product
in several successive versions.
• It is also known as incremental model.
• Important points on SDLC Evolutionary model
• Requirement is broken down into different functional
units/Modules.
• These modules can be incrementally built and
delivered.
• Here at the beginning the core module of the software
product is developed.
• New functionality is built, added to existing one and
released as new version.
• Each successive version is capable of performing more
functions in comparision to its previous versions.

44. Useful when
• It is also suitable for large products where
requirements can be divided into modules.
• Every version will get built and delivered to
customer who can then use it instead of
waiting for the complete system.

45. Difference between Evolutionarly vs
Iterative.
• Iteravtive:A usable product is delivered at end
of each cycle.
• Requirements implemented priority wise.
• Evolutionary: No usable product at end of
each cycle.
• Requirements implemented category wise.

46. • For example, in a simple database application, one cycle might implement
the graphical user interface (GUI); another file manipulation; another
queries; and other updates.
- All four cycles must complete before there is working product available.
- GUI allows the users to interact with the system; file manipulation allows
data to be saved and retrieved; queries allow users to get data out of the
system; and updates allow users to put data into the system.
- With any one of those parts missing, the system will be unusable.
- In contrast, an iterative enhancement model would start by developing a
very simplistic, but usable database.
- On the completion of each cycle, the system would become more
sophisticated.
- It would provide all the critical functionality by the end of the first cycle.
- Evolutionary development and iterative enhancement are somewhat
interchangable.

47. Prototype Model
Requirements
Quick Design
Implement
Customer Evaluation
Design
Implemantation &
unit Testing
Intergration &
System Testing
Operation and
maintenance
Feedback &
Refinement
Not Accepted by
Customer
Accepted by
Customer

48. Prototyping Model.
• Prototype is a working model of software with some
limited functionality.
• The prototype does not always hold the exact logic
used in the actual software application and is an extra
effort to be considered under effort estimation.
• Prototyping is used to allow the users evaluate
developer proposals and try them out before
implementation.
• It also helps understand the requirements which are
user specific and may not have been considered by the
developer during product design.
• Continuous customer support in requirement phase.

49. Drawbacks
• Limited Functionality.
• Not very good quality.
• Not good performance.
• Advantages:
• Refine requirements.
• Prepare final SRS documents.

50. • Is prototype our final product?
• Benefits of developing a prototype?
• Does prototype development incur extra cost?

51. Spiral Model

52. • Developed by Barry Boehm.
• Main feature: Handling uncertainity/Risk.
• Phase: Mulitiple phases having 4 Activities.
• 1. Planning: Determine objectivies,alternatives.
• Imposes constraints.
• 2. Risk: Identify & resolve risk, classify into levels
• Tries to find alternatives and plan ahead.
• 3. Development and testing
• 4. Assessment: Customer Evaluation.

53. • Phase1: PlanningAnalyse
RiskPrototypebuiltCustomer Evaluation &
feedback.
• Phase2:prototype is refinedReqirements are
documented & validated by
customersfinalprototype.
• Phase3:Risks are knownuse traditional
approach for development.

54. Focus Area.
• Identify problemclassify into different risk
levelseliminate them before they affect
software.
• Continuous validation(review) by concerned
people(designers/developers) to check the
work product quality.

55. • Advantages:
• Accommodate good features of other SDLC
models.
• Software quality maintained during development
– By continuous risk analysis.
– Reviews conducted.
Disadvantages:
Experties required in risk handling to carry out spiral
model

56. Software Requirements Engineering.
• The process to gather the software requirements
from client, analyze and document them is
known as requirement engineering.
• Understanding the requirements of the
customers, then document the requirements.
• Document the Requirement Specification what to
do, & does not tell us How to do.
• Work Product: It Produces one large document
written in Natural language containing a
description of WHAT system will do without
describing HOW it will do it.
• SRS

57. Importance of Requirements Eng.
• Without well written document:
• The developers will not know what to do.
• Customers may not be consistent about
requirements.
• It becomes difficult to validate/accept the
software.

58. 4 steps in Requirement Engineering
• 1. Requirement Elicitation: Gathering of requi, requi
are identified with the help of customers(Existing
system)
• 2.Requi. Analysis: Requi are analysed to find
inconsistencies , defects, omittions , priorities.
• 3. Requi. Documentation: end product of first 2 steps.
• Leads to prepration of SRS.
• It becomes foundation for design of s/w.
• 4. Requi. Review or verification: To improve the
quality of SRS.

59. Software Requirement
Elicitation(Requi. Gathering)
• Requi elicitation is an activity that helps us to
understand what problem has to be solved and wat
customers expect from the software.
• Foundation: Effective communication between
customer and the developer.
• Method: Developer questions customers.
• Customer responds, based on response cross questions
carry outs.
• Hurdles: Misunderstanding/conflict(customer &
developers are not understanding each others point of
view)
• Communication gap.(unanswered questions)

60. Reason for Conflicts
• Developers is efficient in the knowledge of his
own development domain while customer is
efficient only in his domain(not suitable to
implement some functionality)
• Lack of proper communication skills(not
understanding technical terms)

61. Requi Elicitation Methods.
1. Interviews: Understanding each other.
• Requi engineers act as mediators between customer
and development team.
• Open minded, co-operative,understanding,flexible.
• Types of interviews:
• 1. open-ended:No pre-set agenga.
• No pre-defined list of questions are prepared.
• 2. Structure: There is a set agenda.
• pre-defined list of questions are prepared.
• In both interviews questions should be short,simple &
clear.
• Both parties should be open for discussion in any
direction.

62. Types of stakeholders to interview.
• 1. Entry level personnel: They don’t have much
domain knowledge.
• They have new ideas,opinions.general ideas(not
technical)
• 2. Mid level: Experience people with good
domain knowledge they know the criticality of
the project. Eg. Project Managers
• 3. Mangers and higher managements: Useful
insights about the project.
• 4. Users of S/W: They will be using the software
max no. of time.

63. 2. BrainStroming Session.
• Group Discussion techniques.
• Promotes creative thinking & new ideas.
• Platform to express and share your views, expectations &
difficulties in implementation.
• Facilitators: Ego clashes/conflicts(to avoid them)
• Encourage people to participate as much as possible.
• Work Product:all ideas are Documented and displayed on
projector , so that all participant can see.
• Detailed report containing each idea in simple language is
prepared and reviewed by facilitator.
• At end a document is prepared with list of requirements
and their priority.

64. Types of Requirements
1. Functional and non-functional requi.
2. User and system requi.(language difference)
3. Interface specification.

65. • Functional Requi: (Product Features)
- Describes what the system has to do.
- What are expectations from the software.
- What the system should not do.
• Non-Function Requi.:
- Highlight how well the software programs its function.
- Eg: for user: High performance.goog interface,usability.
- For developers: maintainability,testability,portability.

66. • User Requi.: Written for users who are not experts of
software field
- Highlight the overview of the system without design
description.
- Specifies:
- functional+non functional requi.
- Constraints.
- Quality.
- External behaviour(user interaction like interfaces)
- What to avoid?
- Complex lang.
- Technical terms.

67. • System requi.: (expanded form of user requi.)
• Used as input to designers so that they can
prepared SDD.
• Both user and system requi are a part of SRS.
• Interface specification:
• API(Application programming interfaces) are
specified in SRS.
• What kind of interfaces customer desires.

68. SRS (software requirements
specification)
• A software requirements specification (SRS) is
a document that captures complete
description about what the system is expected
to perform.
• It is usually signed off at the end of
requirements engineering phase.

69. Characteristics of good SRS.
1. Consistency:No conflict between the requirements.
- Every requi must be specified using standard
terminiology.
- Eg. Module A should take 3 inputs but later the same
module A should take 2 inputs
2. Correct: What is stated is exactly what is desired.
- Expected functionality matches the requi present in
SRS.
3. Unambiguos: Every stated requi has only 1 unique
meaning.
- Words with multiple meaning(these words should be
specified with meaning)
- SRS lang is used.
- Advantage: lang processors exist which tell diff kinds
of errors.

70. 4. Complete: include all functional+non functional
requi+constraints.
- Specifies expected output from all kinds(valid/invalid)
inputs from the user.
5. Traceable: each requi should be clear.
- Important is because future referencing may be
required for development/maintenance.(ask
concerned people)
6. verifiable:Each requi is verifiable.
7. modifiable: easy to make changes in SRS retaining its
structure.

71. Agile Model

72. What is Agile Model?(ability to move quickly
and easily)
• Agile model, the requirements are decomposed into many small parts
that can be incrementally developed.
• The Agile model adopts Iterative development.
• Each iteration is intended to be easily manageable and that can be
completed within a couple of weeks only.
• At a time one iteration is planned, developed and deployed to the
customers.
• Long-term plans are not made.
• Agile model is the combination of iterative and incremental process
models.
• Steps involve in agile SDLC models are:
• Requirement gathering
• Requirement Analysis
• Design
• Coding
• Unit testing
• Acceptance testing

73. Agile Vs Traditional SDLC Models
• Agile is based on the adaptive software development
methods, whereas the traditional SDLC models like the
waterfall model is based on a predictive approach.
• Predictive teams in the traditional SDLC models
usually work with detailed planning and have a
complete forecast of the exact tasks and features to be
delivered in the next few months or during the product
life cycle.
• Predictive methods entirely depend on
the requirement analysis and planning done in the
beginning of cycle.
• Any changes to be incorporated go through a strict
change control management and prioritization.

74. • Agile uses an adaptive approach where there is no
detailed planning and there is clarity on future tasks
only in respect of what features need to be developed.
• There is feature driven development and the team
adapts to the changing product requirements
dynamically.
• The product is tested very frequently, through the
release iterations, minimizing the risk of any major
failures in future.
• Customer Interaction is the backbone of this Agile
methodology, and open communication with minimum
documentation are the typical features of Agile
development environment.
• The agile teams work in close collaboration with each
other and are most often located in the same
geographical location.

75. Use of Agile Model
• In earlier days Iterative Waterfall model was very
popular to complete a project.
• But nowadays developers face various problems while
using it to develop a software.
• The main difficulties included
- handling change requests from customers during
project development
- the high cost and time required to incorporate these
changes.
- To overcome these drawbacks , in the mid-1990s the
Agile Software Development model was proposed.

76. Why agility is Required?
• The Agile model was primarily designed to
help a project to adapt to change requests
quickly.
• So, the main aim of the Agile model is to
facilitate quick project completion.
• Agility is achieved by removing activities that
may not be essential for a specific project.
Also, anything that is wastage of time and
effort is avoided.

77. Agile SDLC models
• Crystal
• Atern
• Feature-driven development
• Scrum
• Extreme programming (XP)
• Lean development
• Unified process
• These are now collectively referred to as Agile
Methodologies, after the Agile Manifesto was
published in 2001.

78. Following are the Agile Manifesto
principles −
• Individuals and interactions − In Agile development, self-
organization and motivation are important, as are
interactions like co-location and pair programming.
• Working software − Demo working software is considered
the best means of communication with the customers to
understand their requirements, instead of just depending
on documentation.
• Customer collaboration − As the requirements cannot be
gathered completely in the beginning of the project due to
various factors, continuous customer interaction is very
important to get proper product requirements.
• Responding to change − Agile Development is focused on
quick responses to change and continuous development.

79. Software Delivery.
• The time to complete an iteration is known as a Time
Box.
• Time-box refers to the maximum amount of time
needed to deliver an iteration to customers.
• So, the end date for an iteration does not change.
• The development team can decide to reduce the
delivered functionality during a Time-box if necessary
to deliver it on time.
• The principle of the Agile model is the delivery of an
increment to the customer after each Time-box.

80. Advantages of Agile model:
• Customer satisfaction by rapid, continuous delivery of
useful software.
• Customers, developers and testers constantly interact
with each other.
• Working software is delivered frequently (weeks rather
than months).
• Face-to-face conversation is the best form of
communication.
• Daily cooperation between business people and
developers.
• Continuous attention to technical excellence and good
design.
• Regular adaptation to changing circumstances.
• Even late changes in requirements are welcomed.

81. Disadvantages of Agile model:
• In case of some software deliverables, especially the
large ones, it is difficult to assess the effort required at
the beginning of the software development life cycle.
• There is lack of emphasis on necessary designing and
documentation.
• The project can easily get taken off track if the
customer representative is not clear what final
outcome that they want.
• Only senior programmers are capable of taking the
kind of decisions required during the development
process. Hence it has no place for new programmers,
unless combined with experienced resources.

82. Example of Agile software
development
• Example: Google is working on project to
come up with a competing product for MS
Word, that provides all the features provided
by MS Word and any other features requested
by the marketing team. The final product
needs to be ready in 10 months of time. Let us
see how this project is executed in traditional
and Agile methodologies.

83. In traditional Waterfall model –
• At a high level, the project teams would spend 15% of
their time on gathering requirements and analysis (1.5
months)
• 20% of their time on design (2 months)
• 40% on coding (4 months) and unit testing
• 20% on System and Integration testing (2 months).
• At the end of this cycle, the project may also have 2
weeks of User Acceptance testing by marketing teams.
• In this approach, the customer does not get to see the
end product until the end of the project, when it
becomes too late to make significant changes.

84. project schedule in traditional software
development.

85. With Agile development methodology–
• In the Agile methodology, each project is broken up into several
‘Iterations’.
• All Iterations should be of the same time duration (between 2 to 8 weeks).
• At the end of each iteration, a working product should be delivered.
• In simple terms, in the Agile approach the project will be broken up into
10 releases (assuming each iteration is set to last 4 weeks).
• Rather than spending 1.5 months on requirements gathering, in Agile
software development, the team will decide the basic core features that
are required in the product and decide which of these features can be
developed in the first iteration.
• Any remaining features that cannot be delivered in the first iteration will
be taken up in the next iteration or subsequent iterations, based on
priority.
• At the end of the first iterations, the team will deliver a working software
with the features that were finalized for that iteration.
• There will be 10 iterations and at the end of each iteration the customer is
delivered a working software that is incrementally enhanced and updated
with the features that were shortlisted for that iteration.

86. The iteration cycle of an Agile project

88. Unified Model
• The Unified Process Model (UPM) is an iterative,
incremental, architecture-centric and use-case driven
approach to software development.
• Use-case driven approach
• The list of requirements specified by a customer are
converted to functional requirements by a business analyst
and generally referred to as use cases.
• For example, the online cake shop can be specified in terms
of use cases such as 'Add cake to cart', 'Change the quantity
of added cakes in cart', 'Cake Order Checkout' and so on.
• Architecture-centric approach
• creating a blueprint of the organization of the software
system.
• It would include taking into account the different
technologies, programming languages, operating systems,
development and release environments, for developing the
software.

89. Phases of Unified Process Model.
• Inception: initial concept(requirement
gathering)
• Elaboration: exploring requirements
• Construction: building the software
• Transition: final packaging

90. • Inception : The inception phase is similar to the 'Requirements
Collection and Analysis' stage of the Waterfall Model of software
development.
• In this phase, you'd collect requirements from the customer,
analyse the project's feasibility, it's cost, risks and profits.
• Elaboration : In this phase, you'd be expanding upon the activities
undertaken in the inception phase.
• The major goals of this phase include creating fully functional
requirements (use cases) and creating a detailed architecture for
fulfillment of the requirements.
• You'd also prepare a business case document for the customer.
• Construction : In this phase, you'd be writing actual code and
implementing the features for each iteration.
• You'd be rolling out the first iteration of the software depending on
the key use cases that make up the core functionalities of the
software system.
• Transition : In this phase, you'd be rolling out the next iterations to
the customer and fixing bugs for previous releases.
• You would also deploy 'builds' of the software to the customer.

91. Advantages of UP
• Rapid feedback from users and developers
– Then adapt to changes in the next iteration
(adaptive development)
• Visible progress.
• Manage complexity by dividing the problem
into smaller ones.

92. Scrum
• Scrum is a project management framework
that is applicable to any project with
aggressive deadlines, complex requirements.
• In Scrum, projects move forward via a series of
iterations called sprints.
• Each sprint is typically two to four weeks long.

94. Roles of SCRUM

97. Scrum Best Practices
• Define requirements just in time to keep product
features as relevant as possible.
• Test and incorporate product owner feedback
daily.
• Sprint reviews with stakeholders need to be
regular.
• The scrum team needs to use the sprint
retrospectives to improve how they work.
• Conduct face-to-face conversations to reduce
miscommunications.
• Trust the teams to do the best job possible.
• Don’t burn out the team members. Respect the
balance between their personal and professional
lives to ease stress.

98. Extreme Programming(XP)
• Extreme Programming (XP) is an agile
software development framework that aims
to produce higher quality software, and higher
quality of life for the development team.

99. Values of XP
• The five values of XP are:
• Communication
• communication to transfer knowledge from one team member to
everyone else on the team.
• XP of communication - face to face discussion with the aid of a white
board or other drawing mechanism.
• Simplicity
• Simplicity means “what is the simplest thing that will work?” The purpose
of this is to avoid waste and do only absolutely necessary things such as
keep the design of the system as simple as possible so that it is easier to
maintain, support, and revise.
• Simplicity also means address only the requirements that you know
about; don’t try to predict the future.
• Feedback
• Through constant feedback about their previous efforts, teams can
identify areas for improvement and revise their practices.
• Feedback also supports simple design. Your team builds something,
gathers feedback on your design and implementation, and then adjust
your product going forward.

100. • Courage
• You need courage to raise organizational issues that
reduce your team’s effectiveness.
• courage to stop doing something that doesn’t work
and try something else.
• courage to accept and act on feedback, even when it’s
difficult to accept.
• Respect
• The members of your team need to respect each other
in order to communicate with each other, provide and
accept feedback that honors your relationship, and to
work together to identify simple designs and solutions.

101. Project Manager.
• A software project manager is the most important
person inside a team who takes the overall
responsibilities to manage the software projects and
play an important role in the successful completion of
the projects.
• A project manager has to face many difficult situations
to accomplish activities like building up team moral.
• Most of the managers take responsibility for writing
the project proposal, project cost estimation,
scheduling, project staffing, project monitoring and
control, software configuration management, risk
management and interfacing with clients.
• The task of a project manager are classified into two
major types:
• Project planning
• Project monitoring and control

102. Project Planning
• Project planning is undertaken immediately after the feasibility
study phase and before the starting of the requirement analysis
phase.
• Once a project has been found to be feasible, Software project
managers started project planning.
• Project planning is completed before any development phase
starts.
• Project planning involves estimating several characteristics of a
project and then plan the project activities based on these
estimations.
• Project planning is done with most care and attention.
• A wrong estimation can result in :
• Schedule delay can cause customer dissatisfaction, which may lead
to a project failure.
• For effective project planning, in addition to a very good knowledge
of various estimation techniques, past experience is also very
important. During the project planning the project manager
performs the following activities:

103. During the project planning the project
manager performs the following
activities:
• Project Estimation: Project Size Estimation is the most important
parameter based on which all other estimations like cost, duration and
effort are made.
– Cost Estimation: Total expenses to develop the software product is estimated.
– Time Estimation: The total time required to complete the project.
– Effort Estimation: The effort needed to complete the project is estimated.
• The effectiveness of all later planning activities is dependent on the
accuracy of these three estimations.
• Scheduling: After completion of estimation of all the project parameters,
scheduling for manpower and other resources are done.
• Staffing: Team structure and staffing plans are made.
• Risk Management: The project manager should identify the unanticipated
risks that may occur during project development risk, analysis the damage
might cause these risks and take risk reduction plan to cope up with these
risks.
• Miscellaneous plans: This includes making several other plans such as
quality assurance plan, configuration management plan, etc.

104. Project monitoring and control
• Project monitoring and control activities are
undertaken once the development activities start.
• The main focus of project monitoring and control
activities is to ensure that the software
development proceeds as per plan.
• This includes checking whether the project is
going on as per plan or not if any problem
created then the project manager must take
necessary action to solve the problem.

105. knowledge areas of Project
Management:
• Project Integration Management : Project Integration Management
includes the processes and activities needed to identify, define,
combine, unify, and coordinate the various processes and project
management activities within the Project Management Process
Groups.
• Project Scope Management : Project Scope Management includes
the processes required to ensure that the project includes all the
work required, and only the work required, to complete the project
successfully.
• Project Time Management : Project Time Management includes the
processes required to manage the timely completion of the project.
• Project Cost Management : Project Cost Management includes the
processes involved in planning, estimating, budgeting, financing,
funding, managing, and controlling costs so that the project can be
completed within the approved budget.
• Project Quality Management : Project Quality Management
includes the processes and activities of the performing organization
that determine quality policies, objectives, and responsibilities so
that the project will satisfy the needs for which it was undertaken.

106. • Project Human Resource Management : Project Human Resource
Management includes the processes that organize, manage, and lead the
project team.
• Project Communications Management : Project Communications
Management includes the processes that are required to ensure timely
and appropriate planning, collection, creation, distribution, storage,
retrieval, management, control, monitoring, and the ultimate disposition
of project information.
• Project Risk Management : Project Risk Management includes the
processes of conducting risk management planning, identification,
analysis, response planning, and controlling risk on a project.
• Project Procurement Management : Project Procurement Management
includes the processes necessary to purchase or acquire products,
services, or results needed from outside the project team
• Project Stakeholders Management : Project Stakeholder Management
includes the processes required to identify all people or organizations
impacted by the project, analyzing stakeholder expectations and impact
on the project, and developing appropriate management strategies for
effectively engaging stakeholders in project decisions and execution.