UNIT 1

SOFTWARE

 Computer software is a product or program

code developed by software engineers.
 The applications of computer software are:
Telecommunication, military, medical
sciences, online shopping, office products, IT
industry etc.
 A Software consists of data and the related
documents.
 The software is the key element in all
computer based systems and products.
 Software is a program or set of programs
containing instructions which provide
desired functionality .
 Software is more than just a program code.
 A program is an executable code, which
serves some computational purpose.
 Software is considered to be a collection of
executable programming code, associated
libraries and documentations.
 Software, when made for a specific
requirement is called software product.
 NATURE/PROPERTIES OF SOFTWARE
 Software is intangible: Unable to be touched; not
having physical presence. Hard to understand
development effort
 Software is easy to reproduce : Cost is in its
development − in other engineering products,
manufacturing is the costly stage.
 The industry is labor-intensive : Labor intensity is the
relative proportion of labor used in a process. Hard to
automate.
 Software is easy to modify : People make changes
without fully understanding it.
 Software does not ‘wear out’ : It deteriorates by having
its design changed: − erroneously, or − in ways that were
not anticipated, thus making it complex
 Complexity: The complexity of software arises from the
large number of unique interacting parts in
a software system. Software parts have several
different kinds of interactions, including serial and
concurrent invocations, state transitions, data couplings,
and interfaces to databases and external systems.
 Conformity: Software, unlike a physical product, has
no underlying natural principles which it must
conform to, such as Newton’s laws of motion. However,
software must conform to exacting specifications in
the representation of each of its parts, in the interfaces to
other internal parts, and in the connections to the
environment in which it operates.
 Changeability: Because software is the most malleable
(easily changed) element in a software-intensive system,
it is the most frequently changed element. This is
particularly true during the late stages of a
development project and during system sustainment.
 CLASSES/TYPES OF SOFTWARE
 System Software: System Software is necessary to
manage the computer resources and support the
execution of application programs. Software like
operating systems, compilers etc.
 Networking and Web Applications Software:
Networking Software provides the required support
necessary for computers to interact with each
other and with data storage facilities. Eg: security
and encryption software.
 Embedded Software: This type of software is
embedded into the hardware normally in the Read
Only Memory (ROM) as a part of a large system and is
used to support certain functionality under the control
conditions. Eg: washing machines.
 Reservation Software: A Reservation system is
primarily used to store and retrieve information and
perform transactions related to travel, car rental,
hotels, or other activities.
 Business Software : This category of software is used to
support the business applications and is the most
widely used category of software. Eg: banking.
 Entertainment Software: Education and entertainment
software provides a powerful tool for educational
agencies, especially those that deal with educating young
children. Eg: games
 Artificial Intelligence Software :Software like expert
systems, decision support systems, pattern recognition
software, artificial neural networks, etc. come under this
category.
 Scientific Software: satisfies the needs of a scientific
or engineering user to perform enterprise specific
 Utilities Software : The programs coming under this
category perform specific tasks and are different
from other software in terms of size, cost and
complexity. Examples are anti-virus software, voice
recognition software, compression programs, etc.
 Document Management Software :A Document
Management Software is used to track, manage and
store documents in order to reduce the paperwork.
 Types of Software (On the basis of copyright) :
 Commercial : In this case, when a user buys a
software, they acquire a license key to use it. Users
are not allowed to make the copies of the software
 Shareware :Shareware is software that is distributed
free on a trial basis with the understanding that the
user may need or want to pay for it later.
 Freeware : Freeware is software that is available for
use at no monetary cost. In other words,
while freeware may be used without payment it is most
often proprietary software, and usually modification, re-
distribution or reverse-engineering without the
author's permission is prohibited.
 Public-domain software: is software that has been
placed in the public domain: in other words, there is
absolutely no ownership such as copyright, trademark, or
patent.
NEED/IMPORTANCE OF SOFTWARE
 Reduce time
 Reduce manpower
 Increased profits
 Better maintenance
 Less error
 Promptness
 Easy to change
 Convenient
 Makes complex things easy to handle
 Better security
 Easy report generetions
 PROGRAM VS SOFTWARE PRODUCT:
 Program is a set of instruction related each other where as
Software Product is a collection of program designed for
specific task.
 Programs are usually small in size where as Software
Products are usually large in size.
 Programs are developed by individuals that means single
user where as Software Product are developed teams.
 In program, there is no documentation or lack in proper
documentation.In Software Product, Proper
documentation and well documented and user manual
prepared.
 Development of program is Unplanned, not Systematic etc
but Development of Software Product is well Systematic,
organised, planned approach.
 Programs provide Limited functionality and less features
where as Software Products provides more functionality
as they are big in size (lines of codes) more options and
features.
WHAT ARE CHARACTERISTICS OF GOOD SOFTWARE?
 Operational: The operational characteristic provides information
about the working of the software. The working of the software is
measured on the basis of -
 Budget
 Usability
 Efficiency
 Correctness
 Functionality
 Dependability
 Security
 Safety
 Transitional: The transitional characteristics are essential for
moving the software from one platform to another.
 Portability
 Interoperability
 Reusability
 Adaptability
 Maintenance: The software need to be capable enough to maintain
and sustain the ever-changing environment. The aspects of
maintenance are -
 Modularitys
 Maintainability
 Flexibility
 Scalability
 SOFTWARE ENGINEERING
 Engineering, is all about developing products, using
well-defined, scientific principles and methods.
 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 and
reliable software product.
SOFTWARE ENGINEERING DEFINITIONS

 The establishment and use of sound

engineering principles in order to obtain
economical software that is reliable and
works efficiently on real machines.
 Software engineering is a systematic and
disciplined approach towards the
development of the software operation and
maintenance.
 Software engineering is an engineering branch
associated with the development of software
product using well-defined scientific
principles, methods and procedures.
NEED/OBJECTIVES OF SOFTWARE ENGINEERING
 Maintainability : It should be feasible for the software to
evolve to meet changing requirements.
 Correctness : A software product is correct, if the different
requirements as specified in the SRS document have been
correctly implemented.
 Reusability : A software product has good reusability, if the
different modules of the product can easily be reused to
develop new products.
 Testability : Here software facilitates both the
establishment of test criteria and the evaluation of the
software with respect to those criteria.
 Reliability : It is an attribute of software quality. The extent
to which a program can be expected to perform its desired
function, over an arbitrary time period.
 Portability : In this case, software can be transferred from
one computer system or environment to another.
 Adaptability : In this case, software allows differing
system constraints and user needs to be satisfied by making
changes to the software.
 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.
 1. Quality focus: Correctness of the functions required to be
performed by the software. Maintainability of the software.
Integrity i.e. providing security so that the unauthorized user
cannot access information or data. Usability i.e. the efforts
required to use or operate the software.
 2. Process: It is the base layer or foundation layer for the
software engineering. The software process is the key to keep
all levels together. It defines a framework that includes
different activities and tasks. In short, it covers
all activities, actions and tasks required to be carried
out for software development.
 3. Methods: The method provides the answers of all 'how-to'
that are asked during the process. It provides the
technical way to implement the software. It includes
collection of tasks starting from communication, requirement
analysis, analysis and design modeling, program construction,
testing and support.
 4. Tools: The software engineering tool is an automated
support for the software development. The tools are
integrated i.e. the information created by one tool can be used
by the other tool.
SOFTWARE PROCESS
 A software process (also knows as software methodology)
is a set of related activities that leads to the
production of the software.
 These activities may involve the development of the
software from the scratch, or, modifying an
existing system.
 Any software process must include the following four
activities:
 Software specification
 Software design and implementation
 Software verification and validation
 Software evolution
 Software specification (or requirements engineering):
Define the main functionalities of the software and the
constrains around them.
 Software design and implementation: The software is
to be designed and programmed.
 Software verification and validation: The software
must conforms to it’s specification and meets the customer
needs.
 Software evolution (software maintenance): The
software is being modified to meet customer and market
requirements changes.
 A process also includes the process
description, which includes:
 Products: The outcomes of the an activity.
For example, the outcome of architectural design
maybe a model for the software architecture.
 Roles: The responsibilities of the people
involved in the process. For example, the
project manager, programmer, etc.
 Pre and post conditions: The conditions that
must be true before and after an activity.
 THE GENERIC PROCESS MODEL
 There are five generic process framework
activities:

1. Communication:
The software development starts with the
communication between customer and developer
to gather requirements.

2. Planning:
It consists of complete estimation, scheduling for
project development and tracking.

3. Modeling: Modeling consists of complete requirement

analysis and the design of the project like algorithm,
flowchart etc. The algorithm is the step-by-step
solution of the problem and the flow chart shows a
complete flow diagram of a program.
 4. Construction: Construction consists of code
generation and the testing part. Coding part
implements the design details using an appropriate
programming language. Testing is to check whether
the flow of coding is correct or not. Testing also
check that the program provides desired output.
 5. Deployment: Deployment step consists of
delivering the product to the customer and take
feedback from them. If the customer wants some
corrections or demands for the additional
capabilities, then the change is required for
improvement in the quality of the software.
SOFTWARE DEVELOPMENT LIFE CYCLE
 SDLC is a process followed for a software project,
within a software organization.
 It consists of a detailed plan describing how to
develop, maintain, replace and alter or enhance
specific software
 Stage 1: Planning and Requirement Analysis
 Requirement analysis is the most important stage in
SDLC.
 It is performed by the senior members of the team
with inputs from the stakeholders like customer, the
sales department etc.
 This information is then used to plan the basic project
approach and to conduct product feasibility study
in the economical, operational and technical areas.
 Planning for the quality assurance requirements
and identification of the risks associated with the
project is also done in the planning stage.
 The outcome of the technical feasibility study is to
define the various technical approaches that can be
followed to implement the project successfully with
minimum risks.
 Stage 2: Defining Requirements
 Once the requirement analysis is done the next step is to
clearly define and document the product
requirements and get them approved from the
customer or the market analysts.
 This is done through an SRS (Software Requirement
Specification) document which consists of all the product
requirements to be designed and developed during the
project life cycle.
 Stage 3: Designing the Product Architecture
 Based on the requirements specified in SRS, usually
more than one design approach for the product
architecture is proposed and documented in a DDS -
Design Document Specification.
 This DDS is reviewed by all the important
stakeholders and based on various parameters as
risk assessment, product robustness, design modularity,
budget and time constraints, the best design approach
is selected for the product.
 A design approach clearly defines all the architectural
modules of the product along with its communication
and data flow representation with the external and
third party modules (if any).
 Stage 4: Building or Developing the Product
 In this stage of SDLC the actual development starts
and the product is built.
 The programming code is generated as per DDS
during this stage.
 If the design is performed in a detailed and organized
manner, code generation can be accomplished
without much hassle.
 Developers must follow the coding guidelines defined
by their organization .
 The programming language is chosen with respect
to the type of software being developed.
 Stage 5: Testing the Product
 This stage is usually a subset of all the stages as in the
modern SDLC models, the testing activities are mostly
involved in all the stages of SDLC.
 However, this stage refers to the testing only stage of
the product where product defects are reported,
tracked, fixed and retested, until the product reaches
the quality standards defined in the SRS.
 Stage 6: Deployment in the Market and Maintenance
 Once the product is tested and ready to be deployed it
is released formally in the appropriate market.
 Sometimes product deployment happens in stages as
per the business strategy of that organization.
 Then based on the feedback, the product may be
released as it is or with suggested enhancements in the
targeting market segment.
 After the product is released in the market, its
maintenance is done for the existing customer base.
WATERFALL MODEL
 In “The Waterfall” approach, the whole process
of software development is divided into separate
phases.
 The outcome of one phase acts as the input for the
next phase sequentially.
 This means that any phase in the development process
begins only if the previous phase is complete.
 The waterfall model is a sequential design process in
which progress is seen as flowing steadily downwards
(like a waterfall) through the phases of Conception,
Initiation, Analysis, Design, Construction, Testing,
Production/Implementation and Maintenance.
 It is also referred to as a Linear-Sequential Life Cycle
Model.
 Sequential Phases in Waterfall Model
 Requirements: The first phase involves understanding
what need to be design and what is its function,
purpose etc. Here, the specifications of the input and
output or the final product are studied and marked.
 System Design: The requirement specifications from
first phase are studied in this phase and system design
is prepared. System Design helps in specifying
hardware and system requirements and also helps in
defining overall system architecture. The software code
to be written in the next stage is created now.
 Implementation: With inputs from system design, the
system is first developed in small programs called
units, which are integrated in the next phase. Each
unit is developed and tested for its functionality
which is referred to as Unit Testing.
 Integration and Testing: All the units developed in
the implementation phase are integrated into a system
after testing of each unit. The software designed, needs
to go through constant software testing to find out if
there are any flaw or errors. Testing is done so that the
client does not face any problem during the installation of
the software.
 Deployment of System: Once the functional and non-
functional testing is done, the product is deployed in
the customer environment or released into the market.
 Maintenance: This step occurs after installation, and
involves making modifications to the system or an
individual component to alter attributes or improve
performance. These modifications arise either due to change
requests initiated by the customer, or defects uncovered
during live use of the system. Client is provided with
regular maintenance and support for the developed
software.
 Advantages of Waterfall Model
 The advantage of waterfall development is that it allows
for departmentalization and control. A schedule can be
set with deadlines for each stage of development and a
product can proceed through the development process model
phases one by one.
 The waterfall model progresses through easily
understandable and explainable phases and thus it is
easy to use.
 It is easy to manage due to the rigidity of the model – each
phase has specific deliverables and a review process.
 In this model, phases are processed and completed one
at a time and they do not overlap. Waterfall model
works well for smaller projects where requirements
are very well understood.
 Disadvantages of Waterfall Model
 It is difficult to estimate time and cost for each phase
of the development process.
 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.
 Not a good model for complex and object-oriented
projects.
 Not suitable for the projects where requirements are
at a moderate to high risk of changing.
 INCREMENTAL MODEL
 Incremental Model is a process of software development
where requirements are broken down into multiple
standalone modules of software development cycle.
 Incremental development is done in steps from
analysis design, implementation,
testing/verification, maintenance.
 Each iteration passes through the requirements,
design, coding and testing phases.
 And each subsequent release of the system adds
function to the previous release until all designed
functionality has been implemented.
 The system is put into production when the first
increment is delivered.
 The first increment is often a core product where the
basic requirements are addressed, and supplementary
features are added in the next increments.
 Once the core product is analyzed by the client, there
is plan development for the next increment.
 Characteristics of an Incremental module includes
 System development is broken down into many mini
development projects
 Partial systems are successively built to produce a
final total system
 Highest priority requirement is tackled first

 Once the incremented portion id developed,

requirements for that increment are frozen
EVOLUTIONARY PROCESS MODELS

 Evolutionary models are iterative type models.

 They allow to develop more complete versions
of the software.
 Following are the evolutionary process models.

1. The prototyping model

2. The spiral model
3. Concurrent development model
 THE PROTOTYPING MODEL
 Prototype is defined as first or preliminary form
using which other forms are copied or derived.
 It does not identify the requirements like detailed
input, output.
 In this model, working programs are quickly
produced.

 The different phases of Prototyping model are:

1. Communication
In this phase, developer and customer meet and
discuss the overall objectives of the software.
 2. Quick design:
 Quick design is implemented when requirements are
known.
 It includes only the important aspects like input and
output format of the software.
 It focuses on those aspects which are visible to the
user rather than the detailed plan.
 It helps to construct a prototype.
 3. Modeling quick design:
 This phase gives the clear idea about the development of
software because the software is now built.
 It allows the developer to better understand the
exact requirements.
 4. Construction of prototype:
The prototype is evaluated by the customer itself.
 5. Deployment, delivery, feedback:
 If the user is not satisfied with current prototype then it
refines according to the requirements of the user.
 The process of refining the prototype is repeated until
all the requirements of users are met.
 When the users are satisfied with the developed
prototype then the system is developed on the basis of
final prototype.
 Advantages of Prototyping Model
 Prototype model need not know the detailed input, output,
processes, adaptability of operating system and full machine
interaction.
 In the development process of this model users are actively
involved.
 The development process is the best platform to understand
the system by the user.
 Errors are detected much earlier.
 Gives quick user feedback for better solutions.
 Disadvantages of Prototyping Model:
 The client involvement is more and it is not always
considered by the developer.
 It is a slow process because it takes more time for
development.
 Many changes can disturb the rhythm of the development
team.
 It is a thrown away prototype when the users are confused
with it.
THE SPIRAL MODEL

 Spiral model is a risk driven process model.

 It is used for generating the software projects.

 In spiral model, an alternate solution is provided

if the risk is found in the risk analysis, then
alternate solutions are suggested and
implemented.
 It is a combination of prototype and sequential
model or waterfall model.
 In one iteration all activities are done, for large
project's the output is small.
 Quadrant 1 - Determine objectives, alternatives and
constraints
 Objectives − Functionality, performance, hardware/software
interface, critical success factors, etc.
 Alternatives − Build, reuse, buy, sub-contract, etc.
 Constraints − Cost, schedule, interface, etc.

 Quadrant 2 - Evaluate alternatives, identify and resolve

risks
 Study alternatives relative to the objectives and
constraints that are determined.
 Identify risks such as lack of experience, new technology,
tight schedules, etc.
 Resolve the identified risks evaluating their impact on the
project, identifying the needed mitigation and contingency
plans and implementing them.
 Quadrant 3 - Develop next-level product
 Typical activities include −
 Create a design
 Review design
 Develop code
 Inspect code
 Test product
 Quadrant 4 - Plan next phase
 Typical activities include −
 Develop project plan
 Develop configuration management plan
 Develop a test plan
 Develop an installation plan
 Advantages of Spiral Model
 It reduces high amount of risk.

 It is good for large and critical projects.

 It gives strong approval and documentation control.

 In spiral model, the software is produced early in the

life cycle process.
 Disadvantages of Spiral Model

 It can be costly to develop a software model.

 It is not used for small projects.

THE CONCURRENT DEVELOPMENT MODEL

 The communication activity has completed in the

first iteration and exits in the awaiting changes
state.
 The modeling activity completed its initial
communication and then go to the
underdevelopment state.
 If the customer specifies the change in the
requirement, then the modeling activity moves from
the under development state into the awaiting
change state.
 The concurrent process model activities moving from
one state to another state.
 Advantages of the concurrent development model:
 This model is applicable to all types of software
development processes.
 It is easy for understanding and use.

 It gives immediate feedback from testing.

 It provides an accurate picture of the current state of

a project.
 Disadvantages of the concurrent development
model:
 It needs better communication between the team
members. This may not be achieved all the time.
 It requires to remember the status of the different
activities.
COMPONENT-BASED DEVELOPMENT
 Component-based development (CBD) is a procedure
that design and development of computer-based
systems with the help of reusable software
components.
 Component-based development techniques involve
procedures for developing software systems by
choosing ideal off-the-shelf components and then
assembling them using a well-defined software
architecture.
 CBD intends to deliver better quality and output.
 Component-based system development process
 Requirements Phase:
 The requirements specification will also consider the
availability of existing components;
 The requirements specification is not only input to the
further development, but also a result of the design and
implementation decisions.
 Analysis & Design Phase:
 It starts with a system analysis and a conceptual design
providing the system overall architecture and continues
with the detailed design.
 Again, as in the requirements process, a tradeoff between
desired design and a possible design using the existing
components must be analyzed.
 Implementation Phase:
 The main emphasis is put on component selection and
investigation before its integration into the system.
 First the selection process should ensure that appropriate
components have been selected.
 Investigation requires that components integrated in
assemblies are tested before they are integrated into the
system.
 Integration Phase:
 The phase is however very important as it is the “moment of
truth”;
 Problems become visible due to architectural mismatches of
the incoming components, or due to unwanted behaviour of
different extra-functional properties on the system level.
 That is why the integration phase is tightly connected to the
system test phase .
 Test Phase
 The component test is actually performed at many
different times: though individual assessment, when
integrated in an assembly or subsystem, and when
deployed (integrated) into the systems
 Release Phase

 The release phase includes packaging of the software

in forms suitable for delivery and installation.
 Maintenance Phase

 This step occurs after installation, and involves

making modifications to the system or an individual
component to alter attributes or improve performance.
 The key goals/Advantages of CBD:
 Save time and money when building large and complex
systems.
 Enhance the software quality.

 Detect defects within the systems

 Improved efficiency

 Minimized expenditures
 THE UNIFIED PROCESS PHASES
 The Unified Process is not simply a process, but rather an
extensible framework which should be customized
for specific organizations or projects.
 Unified Process characteristics
 Iterative and incremental: Each iteration results in
an increment, which is a release of the system that contains
added or improved functionality compared with the
previous release.
 Architecture-centric: The Unified Process insists that
architecture sit at the heart of the project team's efforts to
shape the system.
 Risk-focused: The Unified Process requires the project team
to focus on addressing the most critical risks early in the
project life cycle.
 Project lifecycle (Phases of Unified Process)

 The Unified Process divides the project into four phases:

 Inception
 Elaboration (milestone)
 Construction (release)
 Transition (final production release)
 Inception phase
 Inception is the smallest phase in the project, and
ideally it should be quite short.
 If the Inception Phase is long then it may be an
indication of excessive up-front specification, which is
contrary to the spirit of the Unified Process.
 The following are typical goals for the Inception phase:
 Establish
 Prepare a preliminary project schedule and cost estimate
 Feasibility
 Buy or develop it

 The Lifecycle Objective Milestone marks the end of

the Inception phase.
 Elaboration phase
 During the Elaboration phase, the project team is
expected to capture a healthy majority of the system
requirements.
 However, the primary goals of Elaboration are to
address known risk factors and to establish and
validate the system architecture.
 By the end of the Elaboration phase, the system
architecture must have stabilized.
 The final Elaboration phase deliverable is a plan
(including cost and schedule estimates) for the
Construction phase.
 Construction phase
 Construction is the largest phase of the project.

 In this phase, the remainder of the system is built on

the foundation laid in Elaboration.
 System features are implemented in a series of short,
time-boxed iterations.
 Each iteration results in an executable release of
the software.
 The final Construction phase deliverable is
software ready to be deployed in the Transition
phase.
 Transition phase
 The final project phase is Transition.

 In this phase the system is deployed to the target

users.
 Feedback received from an initial release (or initial
releases) may result in further refinements to be
incorporated over the course of several Transition phase
iterations.
 The Transition phase also includes system
conversions and user training.
 AGILE MODEL/PROCESS/METHOD
 The ability to create and respond to change in order
to succeed in an uncertain and turbulent
environment is called Agile.
 Agile model believes that every project needs to be
handled differently and the existing methods need to
be tailored to best suit the project requirements.
 In Agile, the tasks are divided to time boxes (small
time frames) to deliver specific features for a release.
 Iterative approach is taken and working software
build is delivered after each iteration.
 Each build is incremental in terms of features; the
final build holds all the features required by the
customer.
Note: write description for
each step
 Development in Agile:
 In Agile development, Design and Implementation are
considered to be the central activities in the software
process.
 Design and Implementation phase also incorporate
other activities such as requirements elicitation
and testing into it.
 In an agile approach, iteration occurs across
activities. Therefore, the requirements and the
design are developed together, rather than
separately.
 The allocation of requirements and the design planning
and development as executed in a series of
increments.
 An agile process focuses more on code development
rather than documentation.
AGILE PRINCIPLES
 Highest priority is to satisfy the customer through
early and continuous delivery of valuable software.
 It welcomes changing requirements, even late in
development.
 Deliver working software frequently, from a couple
of weeks to a couple of months, with a preference to
the shortest timescale.
 Build projects around motivated individuals. Give
them the environment and the support they need, and
trust them to get the job done.
 Working software is the primary measure of progress.
 Simplicity the art of maximizing the amount of work
not done is essential.
 The most efficient and effective method of conveying
information to and within a development team is face-
to-face conversation.
 ADVANTAGES OF AGILE
 Very realistic approach to software development.
 Promotes teamwork and cross training.
 Functionality can be developed rapidly and
demonstrated.
 Resource requirements are minimum.
 Suitable for fixed or changing requirements
 Delivers early partial working solutions.
 Good model for environments that change steadily.
 Minimal rules, documentation easily employed.
 Enables concurrent development and delivery within an
overall planned context.
 Little or no planning required.
 Easy to manage.
 Gives flexibility to developers.
 DISADVANTAGES OF AGILE
 Not suitable for handling complex dependencies.
 More risk of sustainability, maintainability and
extensibility.
 An overall plan, an agile leader and agile PM
practice is a must without which it will not work.
 Strict delivery management dictates the scope,
functionality to be delivered, and adjustments to meet the
deadlines.
 Depends heavily on customer interaction, so if
customer is not clear, team can be driven in the wrong
direction.
 There is a very high individual dependency, since
there is minimum documentation generated.
 Transfer of technology to new team members may be
quite challenging due to lack of documentation.
 The most popular Agile methods include:
 Rational Unified Process (1994),
 Scrum (1995),
 Crystal Clear,
 Extreme Programming (1996),
 Adaptive Software Development,
 Feature Driven Development, and
 Dynamic Systems Development Method (DSDM)
(1995).
 These are now collectively referred to as Agile
Methodologies
SCRUM
 SCRUM is an agile development method which
concentrates specifically on how to manage
tasks within a team-based development
environment.
 Basically, Scrum is derived from activity that
occurs during a rugby match.
 Scrum believes in empowering the
development team and advocates working
in small teams (say- 7 to 9 members).
 It consists of three roles, and their
responsibilities are explained as follows:
 Scrum Master: Master is responsible for setting up
the team, sprint meeting and removes obstacles to
progress
 Product owner: The Product Owner creates product
backlog(epository where requirements are tracked with
details on the no of requirements to be completed for each
release), prioritizes the backlog and is responsible
for the delivery of the functionality at each iteration
 Scrum Team: Team manages its own work and
organizes the work to complete the sprint or cycle.
SCRUM PRACTICES
 Process flow of Scrum Methodologies:
 Each iteration of a scrum is known as Sprint

 Product backlog is a list where all details are

entered to get end product
 During each Sprint, top items of Product
backlog are selected and turned into Sprint
backlog
 Team works on the defined sprint backlog

 Team checks for the daily work

 At the end of the sprint, team delivers

product functionality
EXTREME PROGRAMMING (XP)

 Extreme Programming technique is very helpful

when there is constantly changing demands
or requirements from the customers or when they
are not sure about the functionality of the
system.
 It advocates frequent "releases" of the product
in short development cycles, which inherently
improves the productivity of the system and
also introduces a checkpoint where any
customer requirements can be easily
implemented
 Phases of eXtreme programming:
 Planning
 Identification of stakeholders and sponsors
 Infrastructure Requirements
 Security related information and gathering
 Service Level Agreements and its conditions

 Analysis
 Capturing of Stories in Parking lot
 Prioritize stories in Parking lot
 Scrubbing of stories for estimation
 Define Iteration SPAN(Time)
 Resource planning for both Development and QA teams
 Design
 Break down of tasks
 Test Scenario preparation for each task
 Regression Automation Framework
 Execution
 Coding
 Unit Testing
 Execution of Manual test scenarios
 Defect Report generation
 Conversion of Manual to Automation regression test cases
 Mid Iteration review
 End of Iteration review
 Wrapping
 Small Releases
 Regression Testing
 Demos and reviews
 Develop new stories based on the need
 Process Improvements based on end of iteration review comments
 Closure
 Pilot Launch
 Training
 Production Launch
 SLA Guarantee assurance
 Review SOA strategy
 Production Support
 There are two storyboards available to track the work on
a daily basis:
 Story Cardboard
 This is a traditional way of collecting all the stories in a
board in the form of stick notes to track daily XP activities.
As this manual activity involves more effort and time, it is
better to switch to an online form.
 Online Storyboard
 Online tool Storyboard can be used to store the
stories. Several teams can use it for different purposes.
Agile Model
•Agile method proposes incremental
and iterative approach to software
design
•The agile process is broken into
individual models that designers
work on
•The customer has early and
frequent opportunities to look at
the product and make decision and
changes to the project
•Agile model is considered
unstructured compared to the
waterfall model
•Small projects can be
implemented very quickly. For
large projects, it is difficult to
estimate the development time.
Traditional/Waterfall Model
•Development of the software flows
sequentially from start point to end
point.
•The design process is not broken
into an individual models
•The customer can only see the
product at the end of the project
•Waterfall model are more secure
because they are so plan oriented
•d can be estimated and completed.
 SOFTWARE REQUIREMENTS & CATEGORIES
 The software requirements are description of
features and functionalities of the target system.
 A software requirement can be of 3 types:

 Functional requirements

 Non-functional requirements

 Domain requirements
 Functional Requirements
 Requirements, which are related to functional aspect of
software fall into this category. They define functions and
functionality within and from the software system.
 These are represented or stated in the form of input to be
given to the system, the operation performed and the
output expected.
 They are basically the requirements stated by the user
which one can see directly in the final product, unlike the
non-functional requirements.
 EXAMPLES -
 Search option given to user to search from various invoices.
 User should be able to mail any report to management.
 Users can be divided into groups and groups can be given
separate rights.
 Should comply business rules and administrative
functions.
 Software is developed keeping downward compatibility
intact.
 Non-Functional Requirements
 Requirements, which are not related to functional aspect of
software, fall into this category.
 They are implicit or expected characteristics of software,
which users make assumption of.
 These are basically the quality constraints that the system
must satisfy according to the project contract.
 The priority or extent to which these factors are implemented
varies from one project to other.
 They are also called non-behavioral requirements.
 Non-functional requirements include -
 Security
 Logging
 Storage etc
 Reliability
 Scalability
 Performance
 Reusability
 Flexibility
 Product requirements – Requirements which specify
that the delivered product must behave in a
particular way.
 Efficiency requirements: Describe the extent to which the
software makes optimal use of resources
 Reliability requirements: Describe the acceptable failure
rate of the software
 Portability requirements: Describe the ease with which the
software can be transferred from one platform to another.
 Usability requirements: Describe the ease with which users
are able to operate the software
 Organizational requirements – Requirements which
are a consequence of organizational policies.
 Delivery requirements: Specify when the software and its
documentation are to be delivered to the user.
 Implementation requirements: Describe requirements
such as programming language and design method.
 Standards requirements: Describe the process
standards to be used during software development
 External requirements – Requirements which arise
from factors which are external to the system and
its development process.
 Interoperability requirements: Define the way in which
different computer based systems will interact with each
other in one or more organizations.
 Ethical requirements: Specify the rules and regulations
of the software so that they are acceptable to users.
 Legislative requirements: Ensure that the software
operates within the legal jurisdiction.
 Domain requirements:
 Domain requirements are the requirements which are
characteristic of a particular category or domain of
projects.
 The basic functions that a system of a specific domain
must necessarily exhibit come under this category.
 For instance, in an academic software that maintains
records of a school or college, the functionality of being able
to access the list of faculty and list of students of each grade
is a domain requirement.
 These requirements are therefore identified from that
domain model and are not user specific
 REQUIREMENTS ENGINEERING
 Requirements convey the expectations of users from
the software product.
 The requirements can be obvious or hidden, known or
unknown, expected or unexpected from client’s point
of view.
 Requirement Engineering is the process of
defining, documenting and maintaining the
requirements.
 It is a process of gathering and defining service
provided by the system.
 Requirements Engineering Process consists of the
following main activities:
 Feasibility study
 Requirements elicitation
 Requirements specification
 Requirements verification and validation
 Requirements management

 Feasibility study
 analysts does a detailed study about whether the
desired system and its functionality are feasible to
develop.(Economical, Technical etc)
 Requirements Elicitation/Gathering:
 It is related to the various ways used to gain knowledge
about the project domain and requirements.
 The various sources of domain knowledge include
customers, business manuals, the existing software
of same type, standards and other stakeholders of the
project.
 The techniques used for requirements elicitation
include interviews, brainstorming, task analysis,
Delphi technique, prototyping, etc.
 Elicitation does not produce formal models of the
requirements understood.
 Instead, it widens the knowledge domain of the
analyst and thus helps in providing input to the next
stage.
 Requirement Elicitation/Gathering Process

 Requirements gathering - The developers discuss with the

client and end users and know their expectations from the
software.
 Organizing Requirements - The developers prioritize and
arrange the requirements in order of importance,
urgency and convenience.
 Negotiation & discussion - If requirements are
ambiguous or there are some conflicts in requirements of
various stakeholders, if they are, it is then negotiated and
discussed with stakeholders. Requirements may then be
prioritized and reasonably compromised.
 Documentation - All formal & informal, functional and non-
functional requirements are documented and made available
for next phase processing.
 Requirement Elicitation/Gathering Techniques
 Interviews
 Interviews are strong medium to collect requirements.
Organization may conduct several types of interviews such
as:
 Structured (closed) interviews, where every single
information to gather is decided in advance, they follow
pattern and matter of discussion firmly.
 Non-structured (open) interviews, where information to

gather is not decided in advance, more flexible and less

biased.
 Oral interviews

 Written interviews

 One-to-one interviews which are held between two persons

across the table.

 Group interviews which are held between groups of
participants. They help to uncover any missing requirement as
numerous people are involved.
 Requirement Elicitation/gathering Techniques
 Surveys
 Organization may conduct surveys among various
stakeholders by querying about their expectation and
requirements from the upcoming system.
 Questionnaires
 A document with pre-defined set of objective questions and
respective options is handed over to all stakeholders to
answer, which are collected and compiled.
 A shortcoming of this technique is, if an option for some issue
is not mentioned in the questionnaire, the issue might be
left unattended.
 Task analysis
 Team of engineers and developers may analyze the operation
for which the new system is required. If the client already
has some software to perform certain operation, it is studied
and requirements of proposed system are collected.
 Domain Analysis
 Every software falls into some domain category. The expert
people in the domain can be a great help to analyze
general and specific requirements.
 Requirement Elicitation Techniques
 Brainstorming
 An informal debate is held among various stakeholders and
all their inputs are recorded for further requirements
analysis.
 Prototyping
 Prototyping is building user interface without adding
detail functionality for user to interpret the features of
intended software product. It helps giving better idea of
requirements. The prototype is shown to the client and the
feedback is noted. The client feedback serves as an input
for requirement gathering.
 Observation
 Team of experts visit the client’s organization or workplace.
They observe the actual working of the existing installed
systems. They observe the workflow at client’s end and how
execution problems are dealt. The team itself draws some
conclusions which aid to form requirements expected from the
software.
 Requirements specification:
This activity is used to produce formal software
requirement models.
 All the requirements including the functional as well
as the non-functional requirements and the
constraints are specified by these models in totality.
 During specification, more knowledge about the
problem may be required which can again trigger the
elicitation process.
The models used at this stage include ER diagrams, data
flow diagrams(DFDs), function decomposition
diagrams(FDDs), data dictionaries, etc.
 SRS is prepared at this stage.
 Requirements verification and validation:
 Verification: It refers to the set of tasks that ensure
that software correctly implements a specific
function.
 Validation: It refers to a different set of tasks that
ensure that the software that has been built is
traceable to customer requirements.

 The main steps for this process include:

 The requirements should be consistent with all the
other requirements i.e no two requirements should
conflict with each other.
 The requirements should be complete in every sense.

 The requirements should be practically achievable.

 Reviews, buddy checks, making test cases, etc. are

some of the methods used for this.
 Requirements management:
Requirement management is the process of analyzing,
documenting, tracking, prioritizing and agreeing
on the requirement and controlling the communication to
relevant stakeholders.
 This stage takes care of the changing nature of
requirements.
 It should be ensured that the SRS is as modifiable as
possible so as to incorporate changes in requirements
specified by the end users at later stages too.
 Being able to modify the software as per
requirements in a systematic and controlled
manner in an extremely important part of the
requirements engineering process.
SOFTWARE REQUIREMENT SPECIFICATION
 A software requirements specification (SRS) is a
document that captures complete description
about how the system is expected to perform.
 It is usually signed off at the end of requirements
engineering phase.

 COMPONENTS OF THE SRS

 Functional requirements(refer to last slides)
 Performance requirements
 Design constraints
 External interface requirements
 Performance Requirements (Speed Requirements)
 This part of an SRS specifies the performance
constraints on the software system.
 All the requirements related to the performance
characteristics of the system must be clearly specified.
 Performance requirements are typically expressed as
processed transaction s per second or response
time from the system for a user event or screen refresh
time or a combination of these.
 It is a good idea to pin down performance
requirements for the most used or critical
transactions, user events and screens.
 Design Constraints
 The client environment may restrict the designer to
include some design constraints that must be followed.
 Standard Compliance: It specifies the requirements for the
standard the system must follow. The standards may include the
report format and according procedures.
 Hardware Limitations: The software needs some existing or
predetermined hardware to operate, thus imposing restrictions on the
design. Hardware limitations can includes the types of machines to
be used operating system availability memory space etc.
 Fault Tolerance: Fault tolerance requirements can place a major
constraint on how the system is to be designed. Fault tolerance
requirements often make the system more complex and expensive, so
they should be minimized.
 Security: Currently security requirements have become essential and
major for all types of systems. Security requirements place
restriction s on the use of certain commands control access to
database, provide different kinds of access, requirements for
different people, require the use of passwords and cryptography
techniques, and maintain a log of activities in the system.
 External Interface Requirements
 For each external interface requirements:

 1. All the possible interactions of the software with

people hardware and other software should be
clearly specified,
 2. The characteristics of each user interface of the
software product should be specified and
 3. The SRS should specify the logical characteristics
of each interface between the software product and
the hardware components for hardware interfacing.
CHARACTERISTICS / QUALITIES OF GOOD SRS
 Correctness:
User review is used to ensure the correctness of
requirements stated in the SRS. SRS is said to be
correct if it covers all the requirements that are
actually expected from the system.
 Completeness:
Completeness of SRS indicates every sense of
completion including the numbering of all the pages,
resolving the to be determined parts to as much extent
as possible as well as covering all the functional and
non-functional requirements properly.
 Consistency:
Requirements in SRS are said to be consistent if there are
no conflicts between any set of requirements.
Examples of conflict include differences in terminologies
used at separate places, logical conflicts like time period
of report generation, etc.
 Unambiguousness:
An SRS is said to be unambiguous if all the
requirements stated have only 1 interpretation.
Some of the ways to prevent unambiguousness include the
use of modelling techniques like ER diagrams, proper
reviews and buddy checks, etc.
 Ranking for importance and stability:
There should a criterion to classify the requirements
as less or more important or more specifically as
desirable or essential. An identifier mark can be used
with every requirement to indicate its rank or stability.
 Modifiability:
SRS should be made as modifiable as possible and should
be capable of easily accepting changes to the system
to some extent. Modifications should be properly indexed
and cross-referenced.
 Verifiability:
An SRS is verifiable if there exists a specific technique to
quantifiably measure the extent to which every
requirement is met by the system. For example, a
requirement stating that the system must be user-
friendly is not verifiable and listing such requirements
should be avoided.
 Traceability:
One should be able to trace a requirement to a design
component and then to a code segment in the
program, to the corresponding test cases.
 Design Independence:
There should be an option to choose from multiple
design alternatives for the final system. More
specifically, the SRS should not include any
implementation details.
 Testability:
An SRS should be written in such a way that it is easy to
generate test cases and test plans from the document.
 Understandable by the customer:
An end user maybe an expert in his/her specific domain
but might not be an expert in computer science.
Hence, the use of formal notations and symbols
should be avoided to as much extent as possible. The
language should be kept easy and clear.
 Right level of abstraction:
If the SRS is written for the requirements phase, the
details should be explained explicitly. Whereas, for a
feasibility study, fewer details can be used. Hence, the
level of abstraction varies according to the purpose of the
SRS.
TYPES OF REQUIREMENTS COVERED BY SRS
ADVANTAGES OF SRS
 Covers all requirements to be developed.
 Any requirement conflicts are resolved.

 Adaptive to changes.

 Prioritize requirements.

 Helps in devising test cases.

 HOW TO WRITE A GOOD SRS/CONTENTS OF AN
EFFECTIVE SRS DOCUMENT

 There is no single precise template for writing good

Software Requirement Specifications.
 The contents of an SRS document depends on the
software product being developed and also on the
expertise of the people doing the requirement
elicitation.
 Still a good Software Requirement Specification (SRS)
usually contains project scope section, functional
requirements, requirement analysis models,
external interface requirements and non functional
requirements.
 Scope of the project/ Product vision
 One of the most important items in the requirements
specification is the precise scope definition of the
project.
 Accuracy of this is important since SRS is also used
for estimation and costing.
 This section should include a brief overview of the
project and should also indicate the goals of the
project including its benefits.
 If the project is for the development of a product, product
vision defines the scope and the target user base of the
product.
 Functional Requirements
 Functional requirements specify the business
requirements of the project in detail.
 Usually business requirements are specified in terms of
the actions that user performs on the software
system. This is known as the use case model.
 Functional requirements should contain a combination
of use cases and plain textual description of system
features.
 Requirement Analysis Models
 Once the overall use cases in the system are identified
in requirements elicitation, requirement analysis
models can be developed to drill down to specifics of
each requirement.
 Requirement Analysis models act as the bridge
between functional requirements and the detailed
design of the software system.

 Entity Relationship Diagrams

 Entity relationship model diagram (ERD) is a
conceptual representation of the data in a software
system.
 During detail design this model is mapped in to the
physical database model.
 Data Dictionary
 Data dictionary in a requirements document is an
extension of the entity relationship diagrams.
 Which ER diagrams specify system entities and their
relationships, a data dictionary lists all the
attributes pertaining to each of those entities.

 External Interface Requirements

 It is very rare that we have a standalone software
system. Usually a software system interacts with a
number of external applications for data input and
output.
 All the external interface requirements are detailed
in this section.
 Non Functional Requirements
 Non functional or technical requirements specify how
the software system should operate.
 In contrast functional requirements specify what a
software system should do.
 Some of the non functional requirements are derived
from the functional requirements.
 Contents of SRS Template
 OBJECT ORIENTED DESIGN USING UML
 UML stands for Unified Modeling Language.
 UML is a pictorial language used to make software
blueprints.
 UML is a standard language for specifying,
visualizing, constructing, and documenting the
artifacts of software systems.
 UML is not a programming language but tools can be
used to generate code in various languages using
UML diagrams.
 Goals/Advantages of UML
 Provide users with a ready-to-use, expressive visual
modeling language so they can develop and exchange
meaningful models.
 Provide extensibility and specialization
mechanisms to extend the core concepts.
 Be independent of particular programming
languages and development processes.
 Provide a formal basis for understanding the
modeling language.
 Encourage the growth of the OO tools market.

 Support higher-level development concepts such as

collaborations, frameworks, patterns and components.
 Integrate best practices.
 Features of UML
 UML helps to organize, plan and visualize a program.
 UML is used in a variety of purposes and its readability and
re-usability make it an ideal choice for programmers.
 A UML diagram is a visual representation of the
relationships between classes and entities in a computer
program.
 A UML diagram is beneficial in that it is very readable. The
diagram is meant to be understood by any type of
programmer and helps to explain relationships in a
program in a straightforward manner.
 UML is used as a standard, it is widely understood and well
known. This makes it easy for a new programmer to step
into a project and be productive from day one.
 UML helps to plan a program before the programming
takes place. In some tools used to model UML, the tool will
generate code based on the classes set up in the model.
 OBJECT-ORIENTED CONCEPTS
 UML can be described as the successor of object-oriented
(OO) analysis and design.
 UML is powerful enough to represent all the concepts
that exist in object-oriented analysis and design.
 Fundamental concepts of the object-oriented world −
 Objects − Objects represent an entity and the basic building
block.
 Class − Class is the blue print of an object.
 Abstraction − Abstraction represents the behavior of an real
world entity.
 Encapsulation − Encapsulation is the mechanism of binding
the data together and hiding them from the outside world.
 Inheritance − Inheritance is the mechanism of making new
classes from existing ones.
 Polymorphism − It defines the mechanism to exists in
different forms.
 OO ANALYSIS AND DESIGN
 OO can be defined as an investigation and to be more
specific, it is the investigation of objects.
 The most important purpose of OO analysis is to
identify objects of a system to be designed.
 After identifying the objects, their relationships are
identified and finally the design is produced.
 The purpose of OO analysis and design can
described as:
 Identifying the objects of a system.
 Identifying their relationships.
 Making a design, which can be converted to executables
using OO languages.
 There are three basic steps where the OO concepts are
applied and implemented. The steps can be defined as
 OO Analysis → OO Design → OO implementation
using OO languages
 TYPES OF UML DIAGRAM
 The current UML standards call for 13 different types of
diagrams.
 These diagrams are organized into two distinct groups:
 Structural UML diagrams
 Class diagram
 Package diagram
 Object diagram
 Component diagram
 Composite structure diagram
 Deployment diagram
 Behavioral UML diagrams
 Activity diagram
 Sequence diagram
 Use case diagram
 State diagram
 Communication diagram
 Interaction overview diagram
 Timing diagram
 MODEL/ UML MODEL
 Model is a description of any particular perspective or
entire system, constructed to understand the system
before actually building the system.
 There are two kinds of object models: dynamic and static.

 Dynamic models, such as UML interaction

diagrams (sequence diagrams or communication
diagrams), help design the logic, the behavior of the
code or the method bodies. They tend to be the more
interesting, difficult, important diagrams to create.

 Static models, such as UML class diagrams, help design

the definition of packages, class names, attributes,
and method signatures (but not method bodies).
BENEFITS OF MODEL
 Model is a simplification of reality.
 Blueprint of the actual system.
 Specify the structural and behavior of the
system.
 Templates for designing the system.
 Helps document the system.
 Provides standard for software development.
 Reducing of costs to develop diagrams of UML
using supporting tools.
 Development time is reduced.
 The past faced issues by the developers are no longer
exists.
 Has large visual elements to construct
USE CASE DIAGRAM
 Only static behavior is not sufficient to model a
system rather dynamic behavior is more
important than static behavior.
 Use case diagram is dynamic in nature, there
should be some internal or external factors for
making the interaction.
 Use case diagrams consists of actors, use cases
and their relationships.
 The diagram is used to model the system/subsystem
of an application. A single use case diagram
captures a particular functionality of a system.
 Hence to model the entire system, a number of
use case diagrams are used.
 PURPOSES/NEED/USES/ADVANTAGES OF USE
CASE DIAGRAMS

 Used to gather the requirements of a system.

 Used to get an outside view of a system.

 Identify the external and internal factors influencing

the system.
 Show the interaction among the requirements are
actors.
 Captures dynamic nature of the system.

 Use case diagrams can be used for −

 Requirement analysis and high level design.
 Model the context of a system.
 Reverse engineering.
 Forward engineering.
ELEMENTS/COMPONENTS OF USE CASE
DIAGRAM

 Use case
 Actor

 Association

 System boundary
 Use Case
 A Use Case represents a discrete unit of interaction
between a user (human or machine) and the system.
 This interaction is a single unit of meaningful work, such
as Create Account or View Account Details.
 Each Use Case describes the functionality to be built in
the proposed system, which can include another Use
Case's functionality or extend another Use Case with its
own behavior.
 Depicted using ellipse.
 A Use Case description will generally includes:
 General comments and notes describing the use case.
 Requirements - functional requirements to be provided to the end
user, such as <ability to update order>.
 Constraints - The formal rules and limitations a Use Case operates
under, defining what can and cannot be done. These include: Pre/Post
conditions
 Scenarios – Formal, sequential descriptions of the steps taken to
carry out the use case, or the flow of events that occur during a Use
Case instance.
 Additional attributes, such as implementation phase, version
number, complexity rating, stereotype and status.
 Actor
 Use Cases are typically related to 'actors', which are
human or machine entities that use or interact with
the system to perform a piece of meaningful work
that helps them to achieve a goal.
 The set of Use Cases an actor has access to defines
their overall role in the system and the scope of their
action.
 An actor is shown as a stick figure in a use case diagram
depicted "outside" the system boundary
 Association
 It is an interaction between the actor and the use
case.
 It is depicted as a solid line.

 Arrow heads are optionally used to show the

direction of the communication between the actor
and the use case.
 System Boundary
 System boundary defines the scope of what a system
will be.
 A system cannot have infinite functionality.

 So, it follows that use cases also need to have definitive

limits defined.
 A system boundary of a use case diagram defines the
limits of the system.
 The system boundary is shown as a rectangle spanning
all the use cases in the system.

System Boundary
 RELATIONSHIPS IN USE CASES
 A relationship between two use cases is basically a
dependency between the two use cases.
 Defining a relationship between two use cases is
the decision of the modeler of the use case diagram.
 This reuse of an existing use case using different
types of relationships reduces the overall effort
required in defining use cases in a system.
 Use case relationships can be one of the following:
 Include
 Exclude
 Generalization
 Include:
 When a use case is depicted as using the
functionality of another use case as a part of its
business process flow, this relationship between the
use cases is named as an include relationship.
 An include relationship is depicted with a directed
arrow having a dotted shaft.
 The tip of the arrowhead points to the child use case
and the parent use case is connected at the base of
the arrow.
 The stereotype "<<include>>" identifies the
relationship as an include relationship.
 Extend
 In an extend relationship between two use cases, the
child use case adds to the existing functionality and
characteristics of the parent use case.
 An extend relationship is depicted with a directed
arrow having a dotted shaft, similar to the include
relationship.
 The tip of the arrowhead points to the parent use
case and the child use case is connected at the base
of the arrow.
 The stereotype "<<extend>>" identifies the relationship
as an extend relationship
 Generalizations
 A generalization relationship is also a parent-child
relationship between use cases.
 The child use case in the generalization relationship has
the underlying business process meaning, but is an
enhancement of the parent use case.
 In a use case diagram, generalization is shown as a
directed arrow with a triangle arrowhead.
 The child use case is connected at the base of the
arrow.
 The tip of the arrow is connected to the parent use
case.
HOW TO CREATE USE CASE DIAGRAM
 Step 1 - Identify the actors
 Step 2 - Identify the use case

 Step 3 - Link the actor and use case

 Step 4 - Identify relations between use cases.

CLASS DIAGRAM
 Class diagrams describe the static structure
of a system.
 The focus of the class diagram is to describe
how a system is structured rather than how
it behaves.
 Class diagrams are probably the most versatile
of the UML diagrams.
 Data models, software components, software
classes, and business objects are modeled
using the class diagram, each in its own
diagram.
PURPOSE/USES/BENEFITS/ADV OF THE
CLASS DIAGRAM
 Analysis and design of the static view of an
application.
 Describe responsibilities of a system.
 Base for component and deployment diagrams.
 Forward and reverse engineering.
 Showing the collaboration among the elements of
the static view.
 Construction of software applications using object
oriented languages.
 It provides an overview of how the application is
structured before studying the actual code. This can
easily reduce the maintenance time
 It helps for better understanding of general
schematics of an application.
COMPONENTS/ ELEMENTS OF CLASS
DIAGRAM

 Essential elements of UML class diagram are:

 Class

 Relationship
 CLASSES
 Essential elements of class :
 Class Name
 Attributes
 Operations

 The class is rendered as a rectangle, including its name,

attributes, and operations in separate compartments.

 Class name: The name of the class is only needed in the

graphical representation of the class. It appears in the
topmost compartment. A class is the blueprint of an
object which can share the same relationships, attributes,
operations, & semantics
 Attributes:
 An attribute is named property of a class which
describes the object being modeled.
 In the class diagram, this component is placed just
below the name-compartment.
 A derived attribute is computed from other
attributes.
 For example, an age of the student can be easily
computed from his/her birth date.
 Operations:
 Methods or functions that the class will perform.

 It depicts the functionality of the class.

 Included in the 3rd compartment just after attributes.

 Active Classes
 Active classes initiate and control the flow of
activity, while passive classes store data and serve
other classes.
 Illustrate active classes with a thicker border.
 Visibility
 Use visibility markers to signify who can access the
information contained within a class.
 Private visibility, denoted with a - sign, hides
information from anything outside the class
partition.
 Public visibility, denoted with a + sign, allows all
other classes to view the marked information.
 Protected visibility, denoted with a # sign, allows
child classes to access information they inherited
from a parent class.
RELATIONSHIPS

 There are mainly three kinds of relationships in

UML:
 Dependencies
 Generalizations
 Associations
 Aggregation
 Composition
 Dependency
 A dependency means the relation between two or more
classes in which a change in one may force changes
in the other.
 However, it will always create a weaker relationship.

 Dependency indicates that one class depends on

another.
 In the following example, Student has a dependency on
College
 Generalization
 A generalization helps to connect a subclass to its
superclass.
 A sub-class is inherited from its superclass.

 Generalization relationship can't be used to model

interface implementation.
 Class diagram allows inheriting from multiple super
classes.
 In this example, the class Student is generalized from
Person Class.
 ASSOCIATIONS
 Associations represent static relationships between
classes.
 Place association names above, on, or below the
association line.
 Use a filled arrow to indicate the direction of the
relationship.
 Place roles near the end of an association.

 Roles represent the way the two classes see each

other.
 Multiplicity (Cardinality)
 Place multiplicity notations near the ends of an
association.
 These symbols indicate the number of instances of one
class linked to one instance of the other class.
 For example, one company will have one or more
employees, but each employee works for just one
company.
 Constraint
 Any rule.

 Place constraints inside curly braces {}.

 Aggregation
 Aggregation is a special type of association that
models a whole- part relationship between
aggregate and its parts.
 For example, the class college is made up of one or
more student.
 In aggregation, the contained classes are never totally
dependent on the lifecycle of the container.
 Here, the college class will remain even if the
student is not available.
 Composition:
 The composition is a special type of aggregation which
denotes strong ownership between two classes when
one class is a part of another class.
 For example, if college is composed of classes student.

 The college could contain many students, while each

student belongs to only one college.
 So, if college is not functioning all the students also
removed.
Aggregation
Aggregation indicates a
relationship where the child can
exist separately from their
parent class. Example:
Automobile (Parent) and Car
(Child). So, If you delete the
Automobile, the child Car still
exist.
Composition
Composition display relationship
where the child will never
exist independent of the
parent. Example: House (parent)
and Room (child). Rooms will
never separate into a House.
HOW TO CREATE CLASS DIAGRAM
 Step 1 - Identify the classes
 Step 2 - Identify the association, dependency,
generalization, composition and aggregation
PACKAGE DIAGRAM
 Package diagram is UML structure
diagram which shows packages and
dependencies between the packages.
 Package diagram shows the arrangement
and organization of model elements in
middle to large scale project that can be used to
show both structure and dependencies
between sub-systems or modules.
USES/ADVANTAGES/BENEFITS/PURPOSE
 To group elements
 To provide a namespace for the grouped
elements
 A package may contain other packages, thus
providing for a hierarchical organization of
packages.
 UML elements can be grouped into
packages.
 To create an overview of a large set of model
elements
 To organize a large model
ELEMENTS/COMPONENTS PACKAGE DIAGRAM
 Package
 Dependency
 Package:
 Package is a namespace used to group together
elements that are semantically related and might
change together.
 It is a general purpose mechanism to organize
elements into groups to provide better structure for
system model.
 A package is rendered as a tabbed folder - a rectangle
with a small tab attached to the left side of the top of the
rectangle.
 If the members of the package are not shown inside
the package rectangle, then the name of the package
should be placed inside.
 The members of the package may be shown within
the boundaries of the package.
 In this case the name of the package should be
placed on the tab.

 Nested and Hierarchical Packages

 A package can be represented as a hierarchical
structure with nested packages
 The name of packages should be unique within a
system.
 However, it is allowed for classes inside different
packages to have same name. For Example,
Package::Product & Shipping::Product are allowed.
 Package Containment

 Packages are shown in static diagrams

 Two equivalent ways to show containment:

 Dependency
 There are two sub-types involved in dependency.

 They are <<access>> & <<import>>.

 Though there are two stereotypes users can use their own
stereotype to represent the type of dependency between
two packages.
 <<import>> - one package imports the functionality
of other package
 <<access>> - one package requires help from
functions of other package
HOW TO CREATE PACKAGE DIAGRAM
 Step 1 - Identify the packages present in the
system
 Step 2 - Identify the dependencies
OBJECT DIAGRAM
 Object diagrams are derived from class
diagrams so object diagrams are dependent
upon class diagrams.
 Object diagrams also represent the static view
of a system but this static view is a snapshot of
the system at a particular moment.
 Object diagrams are used to render a set of
objects and their relationships as an
instance.
PURPOSE OF OBJECT DIAGRAMS

 Forward and reverse engineering.

 Object relationships of a system
 Static view of an interaction.
 Understand object behavior and their
relationship from practical perspective
 Examining a specific iteration of a general
system.
 Getting a high-level overview of the system you
will develop.
 Testing a class diagram
 Discover facts and dependencies between
specific instances and depicting specific examples
of classifiers.
ELEMENTS/COMPONENTS OF OBJECT
DIAGRAM

Links: dependency, association, aggregation, composition & generalization

Object diagram for company structure
SEQUENCE DIAGRAM

 A sequence diagram is the most commonly

used interaction diagram, used to show
the interactive behavior of a system.
 A sequence diagram simply depicts interaction
between objects in a sequential order i.e. the
order in which these interactions take place.
 Sequence diagrams describe how and in what
order the objects in a system function.
 These diagrams are widely used by businessmen
and software developers to document and
understand requirements for new and
existing systems.
PURPOSE

 Used to model and visualise the logic behind

a sophisticated function, operation or
procedure.
 They are also used to show details of UML use
case diagrams.
 Used to understand the detailed
functionality of current or future systems.
 Visualise how messages and tasks move
between objects or components in a system.
 See how objects and components interact
with each other to complete a process.
COMPONENTS / ELEMENTS/ NOTATION
 Messages
Messages are arrows that represent communication
between objects.
 Types of Messages in Sequence Diagrams
 Synchronous Message
A synchronous message requires a response before the
interaction can continue. It's usually drawn using a line
with a solid arrowhead pointing from one object to
another.

 Asynchronous Message
Asynchronous messages don't need a reply for interaction
to continue. Like synchronous messages, they are drawn
with an arrow connecting two lifelines; however, the
arrowhead is usually open and there's no return message
depicted.
 Reply or Return Message
A reply message is drawn with a dotted line and an open
arrowhead pointing back to the original lifeline.

 Self Message
A message an object sends to itself, usually shown as a U
shaped arrow pointing back to itself.

 Create Message
This is a message that creates a new object. Similar
to a return message, it's depicted with a dashed line
and an open arrowhead that points to the rectangle
representing the object created.
 Delete Message
This is a message that destroys an object. It can be shown
by an arrow with an x at the end.

 Found Message
A message sent from an unknown recipient, shown by an
arrow from an endpoint to a lifeline.

 Lost Message
A message sent to an unknown recipient. It's shown by an
arrow going from a lifeline to an endpoint, a filled circle or
an x.
 Duration Message: A message defines a particular
communication between Lifelines of an Interaction.
Duration message shows the distance between two
time instants for a message invocation.

 Note:
 A note (comment) gives the ability to attach various
remarks to elements. A comment carries no semantic
force, but may contain information that is useful to a
modeler.
 Sequence Fragments
 A sequence fragment is represented as a box, called a
combined fragment, which encloses a portion of the
interactions within a sequence diagram
 The fragment operator (in the top left cornet)
indicates the type of fragment
 Fragment types: ref, assert, loop, break, alt, opt, neg
 Operator Fragment Type
Alternative multiple fragments: only the one whose condition
alt
is true will execute.

Optional: the fragment executes only if the supplied condition

opt
is true. Equivalent to an alt only with one trace.

par Parallel: each fragment is run in parallel.

Loop: the fragment may execute multiple times, and the guard
loop
indicates the basis of iteration.

Critical region: the fragment can have only one thread

region
executing it at once.

neg Negative: the fragment shows an invalid interaction.

Reference: refers to an interaction defined on another

ref diagram. The frame is drawn to cover the lifelines involved in
the interaction. You can define parameters and a return value.

Sequence diagram: used to surround an entire sequence

sd
diagram.
 Combined fragment : It is possible to combine frames
in order to capture, e.g., loops or branches.
ACTIVITY DIAGRAM
 An activity diagram visually presents a series of
actions or flow of control in a system similar to
a flowchart or a data flow diagram.
 Activity diagrams are often used in business process
modeling.
 They can also describe the steps in a use case
diagram.
 Activities modeled can be sequential and concurrent.

 In both cases an activity diagram will have a

beginning (an initial state) and an end (a final
state).
BENEFITS OF ACTIVITY DIAGRAMS

 Demonstrate the logic of an algorithm.

 Describe the steps performed in a UML use
case.
 Illustrate a business process or workflow
between users and the system.
 Simplify and improve any process by
clarifying complicated use cases.
 Model software architecture elements, such
as method, function, and operation.
NOTATION
 Initial State or Start Point
 A small filled circle followed by an arrow
represents the initial action state or the start point
for any activity diagram.

 Activity or Action State

 An action state represents the non-interruptible
action of objects. You can draw an action using a
rectangle with rounded corners.
 Action Flow
 Action flows, also called edges and paths, illustrate the
transitions from one action state to another. They are
usually drawn with an arrowed line.

 Object Flow
 Object flow refers to the creation and modification of
objects by activities. An object flow arrow from an
action to an object means that the action creates or
influences the object.
 Decisions and Branching
 A diamond represents a decision with alternate paths.
When an activity requires a decision prior to moving
on to the next activity, add a diamond between the two
activities. The outgoing alternates should be labeled
with a condition or guard expression. You can also
label one of the paths "else.“
 Guards

 In UML, guards are a statement written next to a

decision diamond that must be true before moving
next to the next activity. These are not essential, but
are useful when a specific answer, such as "Yes, three
labels are printed," is needed before moving forward.

 Synchronization
 A fork node is used to split a single incoming flow
into multiple concurrent flows. It is represented as a
straight, slightly thicker line in an activity diagram.
 A join node joins multiple concurrent flows back
into a single outgoing flow.
 A fork and join mode used together are often referred
to as synchronization.
 Note symbol: Allows the diagram creators or
collaborators to communicate additional messages
that don't fit within the diagram itself.

 Send signal symbol : Indicates that a signal is being

sent to a receiving activity.

 Receive signal symbol: Demonstrates the acceptance

of an event.
 Shallow history pseudostate symbol: Represents a
transition that invokes the last active state.

 Option loop symbol: Allows the creator to model a

repetitive sequence within the option loop symbol.

 Flow final symbol: Represents the end of a specific

process flow. This symbol shouldn’t represent the end
of all flows in an activity.

 Condition text: Placed next to a decision marker to let you

know under what condition an activity flow should split off
in that direction.
 End symbol: Marks the end state of an activity and
represents the completion of all flows of a process.

 Swim lanes: Swim lanes group related activities into

one column. Horizontal Swimlane or Vertical
Swimlane
STATE CHART DIAGRAM
 A State chart diagram describes a state
machine.
 State machine can be defined as a machine
which defines different states of an object
and these states are controlled by external
or internal events.
 It’s a behavioral diagram and it represents
the behavior using finite state transitions.
PURPOSE

 To model the dynamic aspect of a system.

 To model the life time of a reactive system.

 To describe different states of an object

during its life time.
 Define a state machine to model the states of
an object.
 We use it to state the events responsible for
change in state.
 To understand the reaction of
objects/classes to internal or external stimuli.
ELEMENTS

 Initial state – We use a black filled circle

represent the initial state of a System or a
class.

 State – We use a rounded rectangle to

represent a state. A state represents the
conditions or circumstances of an object of a
class at an instant of time.

State
 Transition – We use a solid arrow to represent the
transition or change of control from one state to another.
The arrow is labelled with the event which causes
the change in state.

 Fork – We use a rounded solid rectangular bar to

represent a Fork notation with incoming arrow from
the parent state and outgoing arrows towards the
newly created states. We use the fork notation to
represent a state splitting into two or more
concurrent states.
 Join – We use a rounded solid rectangular bar to
represent a Join notation with incoming arrows from
the joining states and outgoing arrow towards the
common goal state. We use the join notation when two
or more states concurrently converge into one on
the occurrence of an event or events.

 Self transition – We use a solid arrow pointing back

to the state itself to represent a self transition.
 Composite state – We use a rounded rectangle to
represent a composite state also.We represent a state
with internal activities using a composite state.

 Final state – We use a filled circle within a circle

notation to represent the final state in a state
machine diagram.
COLLABORATION DIAGRAM
 Collaboration diagrams allow you to see both the
dynamic aspects and static relationships of
business objects in a single diagram.
 A collaboration diagram resembles
a flowchartthat portrays the roles, functionality
and behavior of individual objects as well as the
overall operation of the system in real time.

PURPOSE

 Model the logic of a sophisticated procedure,

function, or operation.
 Identify how commands are sent and
received between objects or components of a
process.
 Visualize the consequences of specific
interactions between various components in
a process.
 Plan and understand the detailed
functionality of an existing or future
scenario.
ELEMENTS

 Collaboration Diagram Elements

 There are three primary elements of a
collaboration diagram:
 Objects
 Links
 Messages
 Objects
 Objects participating in a collaboration come in two
flavors?supplier and client.
 Supplier objects are the objects that supply the
method that is being called, and therefore receive
the message.
 Client objects call methods on supplier objects, and
therefore send messages.
 Depicted as a rectangle.

 Global (the object is visible as a global variable)

 Local (the object is visible as a local variable)

 Parameters (the object is visible as a parameter)

 Self (represents the ability of an object to send a message

to itself)
 Links
 The connecting lines drawn between objects in a
collaboration diagram are links.
 These links are what set collaboration diagrams
apart from sequence diagrams.
 They enable you to see the relationships between
objects.
 Each link represents a relationship between
objects and symbolizes the ability of objects to
send messages to each other.
 A single link can support one or more messages sent
between objects.
 This is different from sequence diagrams, where the
lines drawn between objects represent messages
sent from one object to another.
 However, you can also specify the following
adornments for links to indicate how objects are
associated:
 Global (the object is visible as a global variable)

 Local (the object is visible as a local variable)

 Parameters (the object is visible as a parameter)

 Self (represents the ability of an object to send a

message to itself)
 Messages:
 Messages in collaboration diagrams are shown as
arrows pointing from the Client object to the
Supplier object.
 Typically, messages represent a client invoking an
operation on a supplier object.
 Messages are composed of message text prefixed by
a sequence number.
 This sequence number indicates the time-ordering
of the message.
IMPLEMENTATION DIAGRAM
 These are used in implementation phase of
the software life cycle.
 It is used to depict, physical and logical
structure of the system.
 Two types:
 Component
 Deployment
COMPONENT DIAGRAM
 Component diagrams are used to model the
physical aspects of a system.
 Physical aspects are the elements such as
executables, libraries, files, documents, etc.
which reside in a node.
 Component diagrams are used to visualize the
organization and relationships among
components in a system.
PURPOSE

 Visualize the components of a system.

 Construct executables by using forward and
reverse engineering.
 Describe the organization and relationships
of the components.
 Model the components of a system.

 Model the database schema.

 Model the executables of an application.

 Model the system's source code.

 Imagine the system’s physical structure.

ELEMENTS/ NOTATIONS/ COMPONENTS
 Component symbol: An entity required to
execute a stereotype function. A component
provides and consumes behavior through
interfaces, as well as through other
components.
 Node symbol: Represents hardware or software
objects, which are of a higher level than components.

 Interface symbol: Shows input or materials that a

component either receives or provides. Interfaces can
be represented with textual notes or symbols.

 Port symbol: Specifies a separate interaction point

between the component and the environment. Ports
are symbolized with a small square.
 Package symbol: Groups together multiple elements
of the system and is represented by file folders.

 Note symbol: Allows developers to affix a meta-

analysis to the component diagram.

 Dependency symbol: Shows that one part of your

system depends on another. Dependencies are
represented by dashed lines linking one component (or
element) to another.
DEPLOYMENT DIAGRAM
 Deployment diagrams are used to visualize the
topology of the physical components of a
system, where the software components are
deployed.
 Deployment diagrams are used to describe the
static deployment view of a system.
 Deployment diagrams consist of nodes and
their relationships.
PURPOSE

 Visualize the hardware topology of a system.

 Describe the hardware components used to
deploy software components.
 Describe the runtime processing nodes.

 Show which software elements are deployed

by which hardware elements.
 Illustrate the runtime processing for
hardware.
ELEMENTS
 Artifact: A product developed by the software,
symbolized by a rectangle with the name and the
word “artifact” enclosed by double arrows.

 Association: A line that indicates a message or

other type of communication between nodes.

 Component: A rectangle with two tabs that

indicates a software element.

 Dependency: A dashed line that ends in an arrow,

which indicates that one node or component is
dependent on another.
 Node: A hardware or software object, shown by a
three-dimensional box.

 Stereotype: A device contained within the node,

presented at the top of the node, with the name
bracketed by double arrows.<<NAME>>

 Node as container: A node that contains another

node inside of it—such as in the example below, where
the nodes contain components.

 Database: Databases represent any data stored by the

deployed system
LEFT OUT CONTENT
FEASIBILITY STUDY
 Feasibility is defined as the practical extent
to which a project can be performed
successfully.
 To evaluate feasibility, a feasibility study is
performed, which determines whether the
solution considered to accomplish the
requirements is practical and workable in
the software.
 Information such as resource availability,
cost estimation for software development,
benefits of the software to the organization after
it is developed and cost to be incurred on its
maintenance are considered during the
feasibility study.
 Need/ Benefits of feasibility study:
 To analyze whether the software will meet
organizational requirements
 To determine whether the software can be
implemented using the current technology and
within the specified budget and schedule
 To determine whether the software can be integrated
with other existing software.
 Establish the reasons for developing the software
that is acceptable to users, adaptable to change and
conformable to established standards.
 Types of feasibility study:
RATIONAL UNIFIED PROCESS(RUP)
 It is a Unified Process method.
 This methodology divides the development
process into four distinct phases that each
involves business modeling, analysis and
design, implementation, testing, and
deployment.
 This is an object-oriented and web-enabled
program development methodology.
 This model also helps software developer for
providing them guidelines, templates, and
examples for all aspects and stages of
software development.
 ADVANTAGES AND DISADVANTAGES
 Advantages:
 This methodology emphasizes on accurate documentation
 It is proactively able to resolve the project risks that are
associated with the clients evolving requirements for careful
changes and request management
 Very less need for integration as the process of
integration goes on throughout the development process

 Disadvantages:
 The software developer needs to be expert in their work
to develop software under this methodology.
 The development process in this methodology is very
complex and not exactly organized.
 Integration throughout the process of software development
adds the confusion that causes more issues during the
stages of testing.
 This process is too complex therefore it is very hard to
understand.
 THE 6 RUP BEST PRACTICES
 1.0 Develop Iteratively: The (SRS) keeps on evolving throughout the
development process and loops are created to add them without
affecting the cost of development.
 2.0 Manage Requirements: The business requirements
documentation and project management requirements need to be
gathered properly from the user in order to reach the targeted goal.
 3.0 Use Components: The components of large project which are
already tested and are in use can be conveniently used in other
projects.
 4.0 Model Visually: Use of Unified modeling language (UML)
facilitates the analysis and design of various components.
Diagrams and models are used to represent various components and their
interactions.
 5.0 Verify Quality: Testing and implementing effective project quality
management should be a major part of each and every phase of the
project from initiation to delivery (aka the project management life
cycle).
 6.0 Control Changes: Synchronization of various parts of the
system becomes all the more challenging when the parts are being
developed by various teams working from different geographic
locations on different development platforms. Hence special care
should be taken in this direction so that the changes can be
controlled.
 THE RUP PHASES
 The four phases are:
 Inception - The idea for the project is stated. The
development team determines if the project is worth
pursuing and what resources will be needed.
 Elaboration - The project's architecture and
required resources are further evaluated. Developers
consider possible applications of the software and costs
associated with the development.
 Construction - The project is developed and
completed. The software is designed, written, and tested.
 Transition - The software is released to the public.
Final adjustments or updates are made based on
feedback from end users.
 THE RUP 9 PRINCIPLES OR DISCIPLINES
 The Business Modeling Discipline: The goal is to
understand the business of the organization, usually
confined to the scope of the business that is relevant to
the system being developed.

 The Requirements Discipline: The goal is to elicit,

document, and agree upon the scope of what is and
what is not to be built. This information is used by
analysts, designers, and programmers to build the system,
by testers to verify the system, and by the project manager
to plan and manage the project.

 The Analysis and Design Discipline: The goal is to

analyze the requirements for the system and to
design a solution to be implemented, taking into
consideration the requirements, constraints and all
applicable standards and guidelines.
 The Implementation Discipline: The goal is to
transform the design into executable code and to
perform a basic level of testing, in particular unit
testing.

 The Test Discipline: The goal is to perform an

objective evaluation to ensure quality. This includes
finding defects, validating that system works as designed,
and verifying that the requirements are met.

 The Deployment Discipline: The goal is to plan for

the delivery of the system and to execute the plan to
make the system available to end users.

 The Configuration and Change Management

Discipline: The goal is to manage access to the
project’s work products. This includes not only
tracking versions over time but also controlling and
managing changes to them.
 The Project Management Discipline: The goal is to
direct the activities that take place on the project.
This includes managing risks, directing people
(assigning tasks, tracking progress, etc.), and
coordinating with people and systems outside the scope of
the project to be sure that it is delivered on time and
within budget.

 The Environment Discipline: The goal is to support

the rest of the effort in terms in ensuring that the
proper process, guidance (standards and guidelines),
and tools (hardware, software, etc.) are available for the
team as needed.
RAD

 RAD or Rapid Application Development

process is an adoption of the waterfall
model; it targets at developing software in a
short span of time.
 RAD follow the iterative.

 SDLC RAD model has following phases

 Business Modeling
 Data Modeling
 Process Modeling
 Application Generation
 Testing and Turnover
Phases of Activities performed in RAD Model
RAD model

Business •On basis of the flow of information and distribution

Modeling between various business channels, the product is designed

Data •The information collected from business modeling is refined

Modeling into a set of data objects that are significant for the business

Process •The data object that is declared in the data modeling phase
Modeling is transformed to achieve the information flow necessary to
implement a business function

Application •Automated tools are used for the construction of the

Generation software, to convert process and data models into prototypes

Testing and •As prototypes are individually tested during every

Turnover iteration, the overall testing time is reduced in RAD.
Advantages
•Flexible and adaptable to changes
•It is useful when you have to reduce the
overall project risk
•It is adaptable and flexible to changes
•It is easier to transfer deliverables as
scripts, high-level abstractions and
intermediate codes are used
•Due to code generators and code reuse,
there is a reduction of manual coding
•Due to prototyping in nature, there is a
possibility of lesser defects
•Each phase in RAD delivers highest
priority functionality to client
•With less people, productivity can be
increased in short time
Disadvantages
•It can't be used for smaller projects
•Not all application is compatible with RAD
•When technical risk is high, it is not
suitable
•If developers are not committed to
delivering software on time, RAD projects
can fail
•Reduced features due to time boxing,
where features are pushed to a later
version to finish a release in short period
•Reduced scalability occurs because a RAD
developed application begins as a prototype
and evolves into a finished application
•Progress and problems accustomed are
hard to track as such there is no
documentation to demonstrate what has
been done
•Requires highly skilled designers or
developers
 TEST DRIVEN/FIRST DEVELOPMENT
 It is a software development process that relies on the
repetition of a very short development cycle: first
the developer writes an (initially failing) automated
test case that defines a desired improvement or new
function, then produces the minimum amount of
code to pass that test, and finally refactors the new
code to acceptable standards.
 The following sequence of steps is generally followed:
 Add a test
 Run all tests and see if the new one fails
 Write some code
 Run tests
 Refactor code
 Repeat
QUALITY FUNCTION DEPLOYMENT
 Quality function deployment (QFD) is the
translation of user requirements and requests
into product designs.
 The goal of QFD is to build a product that does
exactly what the customer wants instead of
delivering a product that emphasizes expertise
the builder already has.
 QFD identifies three types of requirements:
 Normal requirements: These requirements reflect
objectives and goals stated for a product or system
during meetings with the customer.
 Expected requirements: These requirements are
implicit to the product or system and may be so
fundamental that the customer does not explicitly state
them.
 Exciting requirements: These requirements reflect
features that go beyond the customer’s expectations
and prove to be very satisfying when present.
 Benefits of QFD
 TYPES OF STAKEHOLDERS
 Stakeholders are individuals or groups of persons
who have some interest or stake in the business
and generally work for the success of the organization or
business.

 Owners:
 The owners of any business are the first set of
stakeholders. They contribute capital or equity and
have a say in the running of the business.

 Employees:
 The next group of stakeholders in any business is its
employees. These employees may be of any cadre and
may carry out managerial, supervisory or other
functions.
 Customers:
 Business exists for the sake of its customers. It is the
customers who keep the business going. Customers
obtain their products and services from the
business establishments.

 Community:
 The community within which a business operates
can be considered as another set of stakeholders. Good
organizations and sound businesses are considered an
asset to any community.

 Government:
 Every business, in some way or the other, comes within
the ambit of government agencies. These government
agencies may be national or central, provincial or
state, or even local in nature.
 Trade Organizations:
 Every business generally has certain affiliations or
memberships with a trade organization or an association.
It may be functional or geographical in nature.

 Competitors:
 There may be various players who operate in the market.
There are often occasions for them to communicate
with each other.

 Press and Media:

 Businesses also often face the need for
communicating or interacting with press, television
and other media.
ISSUES IN REQUIREMENT GATHERING/
ELICITATION

 1. Success criteria is not defined clearly

 It is normal for stakeholders to know that they
have a problem or an opportunity to explore, but
not know exactly what they want. The key to
addressing this issue is to break the project
into smaller pieces, and start from a section
that the client is clearer about.

 2. Stakeholders change their minds

 This happens time and again. Whether the
requirements were not clearly understood or
communicated initially or they
 3. Stakeholders are not willing to speak up or they
are being too expressive
 This issue is often rooted in political issues within the
organization. In some cases, people might be afraid of
being pinned down for expressing their ideas. In
other cases, the project might be politically important
and everyone may want to be associated with it and
have a say in how it should work.

 4. Stakeholders imply or insist on a particular

technical solution
 This issue often arises when stakeholders have limited
knowledge in certain technical areas, have had a
specific technology work well for them in some past
project, or simply are just not able to clearly
articulate the actual need they are trying to
address.
 5. Stakeholders have Conflicting priorities
 When a new system is created, it must adhere to the
needs of several groups of stakeholders, such as end users
and senior management. It is possible for these
various groups to have conflicting views and
priorities.
 INTERVIEW PROCESS
 Prepare
 Identify stakeholders
 Make a list of questions
 Set time and venue
 Inform selected stakeholders

 Conduct
 Actually conduct
 List out issues, errors, unanswered questions

 Follow up
 Review the notes
 Identify the areas of further clarification