SE Unit-1
SE Unit-1
SE Unit-1
Design
Implementation
• 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.
Operation and Maintenance:
• Purpose: After the delivery and deployment of
the software to the customer, maintanance
can be done like error correction, Improve
software .
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
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.
Incremental Model.
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.
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.
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.
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 User
Construction Cut Over
Planning Description
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.
Build Rapid Prototype
User Evaluation Feedback
prototype refined
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.
Major Features.
• Rapid Prototype: Quick initial views about
product.
• Powerful development tools: Development
time goes down.
• User involvement: Acceptability of the
product increase.
Not useful when
• User cannot be involved continuously.
• Tools & resuable components cannot be used.
• Highly skilled & specialized developers.
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.
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.
Prototype Model
Requirements
Quick Design
Feedback &
Implement
Refinement
Not Accepted by
Customer Evaluation Customer
Accepted by
Customer
Design
Implemantation &
unit Testing
Intergration &
System Testing
Operation and
maintenance
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.
Drawbacks
• Limited Functionality.
• Not very good quality.
• Not good performance.
• Advantages:
• Refine requirements.
• Prepare final SRS documents.
• Is prototype our final product?
• Benefits of developing a prototype?
• Does prototype development incur extra cost?
Spiral Model
• 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.
• 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.
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.
• 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
Software Requirements 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
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.
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
incosistencies,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.
Software Requirement
Elicitation(Requi. Gathering)
• Requi elicitation is an activity that helps us to
undesrtand 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)
Reason for Conflits
• 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)
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.
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.
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.
Types of Requirements
1. Functional and non-functional requi.
2. User and system requi.(language difference)
3. Interface specification.
• 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.
• 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.
• 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.
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.
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.
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.
Agile Model
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
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.
• 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
project schedule in traditional software
development.
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.
The iteration cycle of an Agile project
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.
Phases of Unified Process Model.
• Inception: initial concept(requirement
gathering)
• Elaboration: exploring requirements
• Construction: building the software
• Transition: final packaging
• 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.
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.
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.
Roles of SCRUM
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.
Extreme Programming(XP)
• Extreme Programming (XP) is an agile software
development framework that aims to produce higher
quality software.
• Extreme programming (XP) is one of the most
important software development framework of Agile
models.
• It is used to improve software quality and responsive
to customer requirements.
• The extreme programming model recommends taking
the best practices that have worked well in the past in
program development projects to extreme levels.
Values of XP/Best Practices
• The five values of XP are:
• Communication
• 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.
• 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.
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:
1. Project planning
2. Project monitoring and control
I. 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:
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.
II. 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.
knowledge areas of Project
Management:
• Project Integration Management to identify,
define, combine, unify, and coordinate the
various processes and project management
activities within the Project Management
Process Groups.
• Project Scope Management : only the work
required, to complete the project successfully.
• Project Time Management : to manage the timely
completion of the project.
• Project Cost Management : planning, estimating,
budgeting, financing, funding, managing, and
controlling costs so that the project can be
completed within the approved budget.
• Project Quality Management : organization
performing to determine quality policies,
objectives, and responsibilities so that the project
will satisfy the needs for which it was undertaken.
• Project Human Resource Management : the
processes that organize, manage, and lead the
project team.
• Project Communications Management : 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 : conducting risk
management planning, identification, analysis,
response planning, and controlling risk on a
project.
• Project Procurement Management : necessary to
purchase or acquire products, services, or results
needed from outside the project team
• Project Stakeholders Management : 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.