Oose Unit 1

CCS356 OOSE Unit-I
Software engineering (Process manual to systematic)

Software
Software is more than just a program code, the programs and other operating information used by a
computer
Software is a set of instructions, data or programs used to operate computers and execute specific tasks.
3 types of software:
1. system software(Operating system-MAC os, Windows, Linux, Android)
2. utility software (Anti-virus, File management system, Disk management tools, Data mining tool, Disk
cleanup tool)
3. application software(MS Office, Internet browsers, Music software, Communication software[skype,
zoom, team])
Engineering
Engineering is the designing, testing and building of machines, structures and processes using maths and
science.
Software engineering
Software engineering is an engineering branch associated with development of software product using
well-defined scientific principles, methods and procedures. The outcome of software engineering is an efficient
and reliable software product.
Software engineering refer to the methods and techniques used to develop and maintain software.
OOSE(Object Oriented Software Engineering)
 Object-Oriented Software Engineering (OOSE) is a software design technique that is used in software design
in object-oriented programming.
 OOSE is developed by Ivar Jacobson in 1992. OOSE is the first object-oriented design methodology that
employs use cases in software design.
 OOSE is one of the precursors of the Unified Modeling Language (UML), such as Booch and OMT.
 It includes a requirements, an analysis, a design, an implementation and a testing model.
 Interaction diagrams are similar to UML's sequence diagrams. State transition diagrams are like UML
statechart diagrams.
1
Mrs.B.Rajalakshmi.MCA.,M.Phil.,
CCS356 OOSE Unit-I
Figure 1. Object-Oriented Software Engineering.
Figure 2. Jacobson’s Use Case diagram.
Below, we'll take a look at the biggest challenges for software developers in 2021 and what they can do to
overcome them.
1. Keeping Pace with Innovation. ... 2. Cultural Change. ... 3. Customer Experience. ...
4. Data Privacy. ... 5. Cybersecurity. ... 6. AI and Automation. ...
7. Data Literacy. ... 8. Cross-Platform Functionality. 9. Budgeting 10. .Talent
2
CCS356 OOSE Unit-I
SDLC
Software Development Life Cycle, SDLC for short, is a well-defined, structured sequence of stages
in software engineering to develop the intended software product.
SDLC Activities
 SDLC is the acronym of Software Development Life Cycle.

 It is also called as Software Development Process.
 SDLC is a framework defining tasks performed at each step in the software development process.
 ISO/IEC 12207 is an international standard for software life-cycle processes. It aims to be the standard
that defines all the tasks required for developing and maintaining software.
SDLC provides a series of steps to be followed to design and develop a software product efficiently. SDLC
framework includes the following steps:
3
CCS356 OOSE Unit-I
Communication
This is the first step where the user initiates the request for a desired software product. He contacts the service
provider and tries to negotiate the terms. He submits his request to the service providing organization in writing.
Requirement Gathering
This step onwards the software development team works to carry on the project. The team holds discussions with
various stakeholders from problem domain and tries to bring out as much information as possible on their
requirements. The requirements are contemplated and segregated into user requirements, system requirements
and functional requirements. The requirements are collected using a number of practices as given -
 studying the existing or obsolete system and software,

 conducting interviews of users and developers,
 referring to the database or
 Collecting answers from the questionnaires.
Feasibility Study
After requirement gathering, the team comes up with a rough plan of software process. At this step the team
analyzes if a software can be made to fulfill all requirements of the user and if there is any possibility of software
being no more useful. It is found out, if the project is financially, practically and technologically feasible for the
organization to take up. There are many algorithms available, which help the developers to conclude the
feasibility of a software project.
System Analysis
At this step the developers decide a roadmap of their plan and try to bring up the best software model suitable for
the project. System analysis includes Understanding of software product limitations, learning system related
problems or changes to be done in existing systems beforehand, identifying and addressing the impact of project
on organization and personnel etc. The project team analyzes the scope of the project and plans the schedule and
resources accordingly.
Software Design
Next step is to bring down whole knowledge of requirements and analysis on the desk and design the software
product. The inputs from users and information gathered in requirement gathering phase are the inputs of this
step. The output of this step comes in the form of two designs; logical design and physical design. Engineers
produce meta-data and data dictionaries, logical diagrams, data-flow diagrams and in some cases pseudo codes.
Coding
This step is also known as programming phase. The implementation of software design starts in terms of writing
program code in the suitable programming language and developing error-free executable programs efficiently.
4
CCS356 OOSE Unit-I
Testing
An estimate says that 50% of whole software development process should be tested. Errors may ruin the
software from critical level to its own removal. Software testing is done while coding by the developers and
thorough testing is conducted by testing experts at various levels of code such as module testing, program
testing, product testing, in-house testing and testing the product at user’s end. Early discovery of errors and their
remedy is the key to reliable software.
Integration
Software may need to be integrated with the libraries, databases and other program(s). This stage of SDLC is
involved in the integration of software with outer world entities.
Implementation
This means installing the software on user machines. At times, software needs post-installation configurations at
user end. Software is tested for portability and adaptability and integration related issues are solved during
implementation.
Operation and Maintenance
This phase confirms the software operation in terms of more efficiency and less errors. If required, the users are
trained on, or aided with the documentation on how to operate the software and how to keep the software
operational. The software is maintained timely by updating the code according to the changes taking place in
user end environment or technology. This phase may face challenges from hidden bugs and real-world
unidentified problems.
Disposition
As time elapses, the software may decline on the performance front. It may go completely obsolete or may need
intense upgradation. Hence a pressing need to eliminate a major portion of the system arises. This phase includes
archiving data and required software components, closing down the system, planning disposition activity and
terminating system at appropriate end-of-system time.
Software process
Software processes in software engineering refer to the methods and techniques used to develop and
maintain software. Software processes provides a framework for building high quality software.
The process that deals with the technical and management issues of software development is called a
software process.
5
CCS356 OOSE Unit-I
There are 4 software process activities

1. Specification – defining what the system should do;
2. Design and implementation – defining the organization of the system and implementing the
system;
3. Validation – checking that it does what the customer wants;
4. Evolution – changing the system in response to changing customer needs.
SOFTWARE DEVELOPMENT PROCESS STEPS

The software development process consists of four major steps. Each of these steps is detailed below.
 Step 1: Planning
 Step 2: Implementing
 Step 3: Testing
 Step 4: Deployment and Maintenance
Step #1: Planning

 An important task in creating a software program is Requirements Analysis.
 Customers typically have an abstract idea of what they want as an end result, but not what software should do.
 Skilled and experienced software engineers recognize incomplete, ambiguous, or even contradictory
requirements at this point.
 Frequently demonstrating live code may help reduce the risk that the requirements are incorrect.
 Once the general requirements are gathered from the client, an analysis of the scope of the development
should be determined and clearly stated.
 This is often called a Statement of Objectives (SOO).
Step #2: Implementation

 Implementation is the part of the process where software engineers actually program the code for the project.
6
CCS356 OOSE Unit-I
Step #3: Testing

 Software testing is an integral and important phase of the software development process.
 This part of the process ensures that defects are recognized as soon as possible.
 It can also provide an objective, independent view of the software to allow users to appreciate and understand
the risks of software deployment.
 Software testing can be stated as the process of validating and verifying that a software
program/application/product:
Step #4: Deployment and Maintenance

 Deployment starts after the code is appropriately tested, approved for release, and sold or otherwise
distributed into a production environment.
 This may involve installation, customization, testing, and possibly an extended period of evaluation.
 Software training and support are important, as the software is only effective if it is used correctly.
 Maintaining and enhancing software to cope with newly discovered faults or requirements can take substantial
time and effort, as missed requirements may force a redesign of the software.
=>Software Development Plan (SDP)

 The Software Development Plan (SDP) describes a developer’s plans for conducting a software development
effort.
 The SDP provides the acquirer insight and a tool for monitoring the processes to be followed for
software development. It also details methods to be used and the approach to be followed for each activity,
organization, and resource.
 The software development process should be detailed in the SDP.
Types of Software Process Model

1. Waterfall model.
2. V model.
3. Incremental model.
4. Iterative model.
5. Unified Process Model.
6. RAD model(Rapid Application Develope).
7. Spiral Model
8. Big-Bang model.
9. Prototype Model.
10. Agile model.
7
CCS356 OOSE Unit-I
1. Waterfall Model (Also called Classical life cycle model or Linear Sequential Model)
The waterfall model is a breakdown of project activities into linear sequential phases, where each phase
depends on the deliverables of the previous one and corresponds to a specialization of tasks. The approach is
typical for certain areas of engineering design.
The sequential phases in Waterfall model are:
 Requirement Gathering and analysis:

All possible requirements of the system to be developed are captured in this phase and
documented in a requirement specification document.
 System Design:
The requirement specifications from first phase are studied in this phase and the system design is
prepared. This system design helps in specifying hardware and system requirements and helps in defining
the overall system architecture.
 Implementation:
With inputs from the 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. Post integration the entire system is tested for any faults and failures.
 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:
8
CCS356 OOSE Unit-I
There are some issues which come up in the client environment. To fix those issues, patches are
released. Also to enhance the product some better versions are released. Maintenance is done to deliver
these changes in the customer environment.
All these phases are cascaded to each other in which progress is seen as flowing steadily downwards (like
a waterfall) through the phases. The next phase is started only after the defined set of goals are achieved for
previous phase and it is signed off, so the name "Waterfall Model". In this model, phases do not overlap.
(Waterfall model is most appropriate are −
 Requirements are very well documented, clear and fixed.

 Product definition is stable.
 Technology is understood and is not dynamic.
 There are no ambiguous requirements.
 Ample resources with required expertise are available to support the product.
 The project is short.)
Waterfall Model - Advantages
The advantages of waterfall development are 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.
Development moves from concept, through design, implementation, testing, installation, troubleshooting,
and ends up at operation and maintenance. Each phase of development proceeds in strict order.
Some of the major advantages of the Waterfall Model are as follows −
 Simple and easy to understand and use(Efficiently, like Easy to use)

 Easy to manage due to the rigidity of the model. Each phase has specific deliverables and a review
process.
 Phases are processed and completed one at a time.
 Works well for smaller projects where requirements are very well understood.
 Clearly defined stages.
 Well understood milestones.
 Easy to arrange tasks.
 Process and results are well documented.
 For smaller projects, waterfall model works well and yield the appropriate results.
 Since the phases are rigid and precise, one phase is done one at a time, it is easy to maintain
 The entry and exit criteria are well defined, so it easy and systematic to proceed with quality
Waterfall Model - Disadvantages
The disadvantage of waterfall development is that it does not allow much reflection or revision. Once
an application is in the testing stage, it is very difficult to go back and change something that was not well-
documented or thought upon in the concept stage.
9
CCS356 OOSE Unit-I
The major disadvantages of the Waterfall Model are as follows −
 No working software is produced until late during the life cycle.

 High amounts of risk and uncertainty.
 Not a good model for complex and object-oriented projects.
 Poor model for long and ongoing projects.
 Not suitable for the projects where requirements are at a moderate to high risk of changing. So, risk and
uncertainty is high with this process model.
 It is difficult to measure progress within stages.
 Cannot accommodate changing requirements.
 Adjusting scope during the life cycle can end a project.
 Integration is done as a "big-bang. at the very end, which doesn't allow identifying any technological or
business bottleneck or challenges early.
 Cannot adopt the changes in requirements
 It becomes very difficult to move back to the phase. For example, if the application has now moved to the
testing stage and there is a change in requirement, It becomes difficult to go back and change it.
 Delivery of the final product is late as there is no prototype which is demonstrated intermediately.
 For bigger and complex projects, this model is not good as a risk factor is higher.
 Not suitable for the projects where requirements are changed frequently.
 Does not work for long and ongoing projects.
 Since the testing is done at a later stage, it does not allow identifying the challenges and risks in the
earlier phase so the risk mitigation strategy is difficult to prepare
2.V Model
The V-model represents a development process that may be considered an extension of the waterfall
model and is an example of the more general V-model. Instead of moving down in a linear way, the process
steps are bent upwards after the coding phase, to form the typical V shape.
The V-Model demonstrates the relationships between each phase of the development life cycle and its
associated phase of testing. The horizontal and vertical axes represent time or project completeness (left-to-
right) and level of abstraction (coarsest-grain abstraction uppermost), respectively.
The V-model is an SDLC model where execution of processes happens in a sequential manner in a V-
shape. It is also known as Verification and Validation model.
10
CCS356 OOSE Unit-I
(know diff between verification & validation)
The V-Model is an extension of the waterfall model and is based on the association of a testing phase
for each corresponding development stage. This means that for every single phase in the development cycle,
there is a directly associated testing phase.
This is a highly-disciplined model and the next phase starts only after completion of the previous phase.
V-Model - Design
Under the V-Model, the corresponding testing phase of the development phase is planned in parallel. So,
there are Verification phases on one side of the ‘V’ and Validation phases on the other side. The Coding Phase
joins the two sides of the V-Model.
The following illustration depicts the different phases in a V-Model of the SDLC.
11
CCS356 OOSE Unit-I
V-Model - Verification Phases
There are several Verification phases in the V-Model, each of these are explained in detail below.
 Business Requirement Analysis

This is the first phase in the development cycle where the product requirements are understood from the
customer’s perspective. This phase involves detailed communication with the customer to understand his
expectations and exact requirement. This is a very important activity and needs to be managed well, as most of
the customers are not sure about what exactly they need. The acceptance test design planning is done at this
stage as business requirements can be used as an input for acceptance testing.
 System Design
Once you have the clear and detailed product requirements, it is time to design the complete system. The
system design will have the understanding and detailing the complete hardware and communication setup for the
product under development. The system test plan is developed based on the system design. Doing this at an
earlier stage leaves more time for the actual test execution later.
 Architectural Design
Architectural specifications are understood and designed in this phase. Usually more than one technical
approach is proposed and based on the technical and financial feasibility the final decision is taken. The system
design is broken down further into modules taking up different functionality. This is also referred to as High
Level Design (HLD).
The data transfer and communication between the internal modules and with the outside world (other
systems) is clearly understood and defined in this stage. With this information, integration tests can be designed
and documented during this stage.
12
CCS356 OOSE Unit-I
 Module Design
In this phase, the detailed internal design for all the system modules is specified, referred to as Low Level
Design (LLD). It is important that the design is compatible with the other modules in the system architecture and
the other external systems. The unit tests are an essential part of any development process and helps eliminate
the maximum faults and errors at a very early stage. These unit tests can be designed at this stage based on the
internal module designs.
Coding Phase
The actual coding of the system modules designed in the design phase is taken up in the Coding phase. The best
suitable programming language is decided based on the system and architectural requirements.
The coding is performed based on the coding guidelines and standards. The code goes through numerous code
reviews and is optimized for best performance before the final build is checked into the repository.
Validation Phases
The different Validation Phases in a V-Model are explained in detail below.
 Unit Testing
Unit tests designed in the module design phase are executed on the code during this validation phase.
Unit testing is the testing at code level and helps eliminate bugs at an early stage, though all defects cannot be
uncovered by unit testing.
 Integration Testing
Integration testing is associated with the architectural design phase. Integration tests are performed to test
the coexistence and communication of the internal modules within the system.
 System Testing
System testing is directly associated with the system design phase. System tests check the entire system
functionality and the communication of the system under development with external systems. Most of the
software and hardware compatibility issues can be uncovered during this system test execution.
 Acceptance Testing
Acceptance testing is associated with the business requirement analysis phase and involves testing the
product in user environment. Acceptance tests uncover the compatibility issues with the other systems available
in the user environment. It also discovers the non-functional issues such as load and performance defects in the
actual user environment.
13
CCS356 OOSE Unit-I
V- Model ─ Application
V- Model application is almost the same as the waterfall model, as both the models are of sequential type.
Requirements have to be very clear before the project starts, because it is usually expensive to go back and make
changes. This model is used in the medical development field, as it is strictly a disciplined domain.
The following pointers are some of the most suitable scenarios to use the V-Model application.
 Requirements are well defined, clearly documented and fixed.

 Product definition is stable.
 Technology is not dynamic and is well understood by the project team.
 There are no ambiguous or undefined requirements.
 The project is short.
The advantage of the V-Model method is that it is very easy to understand and apply. The simplicity of this
model also makes it easier to manage.
The disadvantage is that the model is not flexible to changes and just in case there is a requirement
change, which is very common in today’s dynamic world, it becomes very expensive to make the change.
The advantages of the V-Model method are as follows −
 This is a highly-disciplined model and Phases are completed one at a time.

 Works well for smaller projects where requirements are very well understood.
 Simple and easy to understand and use.
 Easy to manage due to the rigidity of the model. Each phase has specific deliverables and a review
process.
The disadvantages of the V-Model method are as follows −
 High risk and uncertainty.

 Not suitable for the projects where requirements are at a moderate to high risk of changing.
 Once an application is in the testing stage, it is difficult to go back and change a functionality.
 No working software is produced until late during the life cycle.
3. Incremental model
The incremental build model is a method of software development where the model is designed,
implemented and tested incrementally (a little more is added each time) until the product is finished. It
involves both development and maintenance. The product is defined as finished when it satisfies all of its
requirements. Each iteration passes through the requirements, design, coding and testing phases. And each
14
CCS356 OOSE Unit-I
subsequent release of the system adds function to the previous release until all designed functionally has been
implemented. This model combines the elements of the waterfall model with the iterative philosophy of
prototyping.
4.Iterative Model
An iterative life cycle model does not attempt to start with a full specification of requirements by first
focusing on an initial, simplified set user features, which then progressively gains more complexity and a
broader set of features until the targeted system is complete.
When adopting the iterative approach, the philosophy of incremental development will also often be
used liberally and interchangeably.
In other words, the iterative approach begins by specifying and implementing just part of the software,
which can then be reviewed and prioritized in order to identify further requirements.
This iterative process is then repeated by delivering a new version of the software for each iteration. In
a light-weight iterative project the code may represent the major source of documentation of the system;
however, in a critical iterative project a formal software specification may also be required.
15
CCS356 OOSE Unit-I
In the Iterative model, iterative process starts with a simple implementation of a small set of the software
requirements and iteratively enhances the evolving versions until the complete system is implemented and ready
to be deployed.
An iterative life cycle model does not attempt to start with a full specification of requirements. Instead,
development begins by specifying and implementing just part of the software, which is then reviewed to identify
further requirements.
This process is then repeated, producing a new version of the software at the end of each iteration of the
model.
Iterative Model - Design
Iterative process starts with a simple implementation of a subset of the software requirements and
iteratively enhances the evolving versions until the full system is implemented. At each iteration, design
modifications are made and new functional capabilities are added.
The basic idea behind this method is to develop a system through repeated cycles (iterative) and in
smaller portions at a time (incremental).
The following illustration is a representation of the Iterative and Incremental model −
Iterative and Incremental development is a combination of both iterative design or iterative method and
incremental build model for development. "During software development, more than one iteration of the
software development cycle may be in progress at the same time." This process may be described as an
"evolutionary acquisition" or "incremental build" approach."
In this incremental model, the whole requirement is divided into various builds. During each iteration, the
development module goes through the requirements, design, implementation and testing phases.
Each subsequent release of the module adds function to the previous release. The process continues till
the complete system is ready as per the requirement.
16
CCS356 OOSE Unit-I
The key to a successful use of an iterative software development lifecycle is rigorous validation of requirements,
and verification & testing of each version of the software against those requirements within each cycle of the
model.
As the software evolves through successive cycles, tests must be repeated and extended to verify each
version of the software.
Iterative Model - Application
Like other SDLC models, Iterative and incremental development has some specific applications in the
software industry. This model is most often used in the following scenarios −
 Requirements of the complete system are clearly defined and understood.

 Major requirements must be defined; however, some functionalities or requested enhancements may
evolve with time.
 There is a time to the market constraint.
 A new technology is being used and is being learnt by the development team while working on the
project.
 Resources with needed skill sets are not available and are planned to be used on contract basis for
specific iterations.
 There are some high-risk features and goals which may change in the future.
The advantage of this model is that there is a working model of the system at a very early stage of
development, which makes it easier to find functional or design flaws. Finding issues at an early stage of
development enables to take corrective measures in a limited budget.
The disadvantage with this SDLC model is that it is applicable only to large and bulky software
development projects. This is because it is hard to break a small software system into further small serviceable
increments/modules.
The advantages of the Iterative and Incremental
 Some working functionality can be developed quickly and early in the life cycle.
 Results are obtained early and periodically.
 Parallel development can be planned.
 Progress can be measured.
 Less costly to change the scope/requirements.
 Testing and debugging during smaller iteration is easy.
 Risks are identified and resolved during iteration; and each iteration is an easily managed milestone.
 Easier to manage risk - High risk part is done first.
 With every increment, operational product is delivered.
 Issues, challenges and risks identified from each increment can be utilized/applied to the next increment.
 Risk analysis is better.
 It supports changing requirements.
 Initial Operating time is less.
 Better suited for large and mission-critical projects.
17
CCS356 OOSE Unit-I
 During the life cycle, software is produced early which facilitates customer evaluation and feedback.
The disadvantages of the Iterative and Incremental
 More resources may be required.

 Although cost of change is lesser, but it is not very suitable for changing requirements.
 More management attention is required.
 System architecture or design issues may arise because not all requirements are gathered in the beginning
of the entire life cycle.
 Defining increments may require definition of the complete system.
 Not suitable for smaller projects.
 Management complexity is more.
 End of project may not be known which a risk is.
 Highly skilled resources are required for risk analysis.
 Projects progress is highly dependent upon the risk analysis phase.
5. UNIFIED PROCESS MODEL

The Unified Process (UP) is a software development framework used for object-oriented modeling. The
framework is also known as Rational Unified Process (RUP) and the Open Unified Process (Open UP).
It defines the order of phases.

It is component-based, meaning a software system is built as a set of software components. There must
be well-defined interfaces between the components for smooth communication.
It follows an iterative, incremental, architecture-centric, and use-case driven approach
Phases of Unified Process Model

We can represent a unified process model as a series of cycles. Each cycle ends with the release of a new
system version for the customers.
We have four phases in every cycle:
 Inception
 Elaboration
18
CCS356 OOSE Unit-I
 Construction
 Transition
Inception
The main goal of this phase involves delimiting the project scope. This is where we define why we
are making this product in the first place. It should have the following:
 What are the key features? How does this benefit the customers?
 Which methodology will we follow?
 What are the risks involved in executing the project?
 Schedule and cost estimates.
Elaboration
We build the system given the requirements, cost, and time constraints and all the risks involved. It
should include the following:
 Develop with the majority of the functional requirements implemented.
 Finalize the methodology to be used.
 Deal with the significant risks involved.
Construction
This phase is where the development, integration, and testing take place. We build the complete
architecture in this phase and hand the final documentation to the client.
Transition
This phase involves the deployment, multiple iterations, beta releases, and improvements of the
software. The users will test the software, which may raise potential issues. The development team will
then fix those errors.
Conclusion
This method allows us to deal with the changing requirements throughout the development period.
The unified process model has various applications which also makes it complex in nature.
6.RAD model
Rapid application development was a response to plan-driven waterfall processes, developed in the
1970s and 1980s, such as the Structured Systems Analysis and Design Method (SSADM). Rapid
application development (RAD) is often referred as the adaptive software development. RAD is an
19
CCS356 OOSE Unit-I
incremental prototyping approach to software development that end users can produce better feedback when
examining a live system, as opposed to working strictly with documentation. It puts less emphasis on planning
and more emphasis on an adaptive process.
RAD may resulted in a lower level of rejection when the application is placed into production, but this
success most often comes at the expense of a dramatic overruns in project costs and schedule. RAD approach
is especially well suited for developing software that is driven by user interface requirements. Thus, some GUI
builders are often called rapid application development tools.
The RAD (Rapid Application Development) model is based on prototyping and iterative
development with no specific planning involved. The process of writing the software itself involves the
planning required for developing the product.
Rapid Application Development focuses on gathering customer requirements through workshops or

focus groups, early testing of the prototypes by the customer using iterative concept, reuse of the existing
prototypes (components), continuous integration and rapid delivery.
(What is RAD?
Rapid application development is a software development methodology that uses minimal planning in
favor of rapid prototyping. A prototype is a working model that is functionally equivalent to a component of the
product.)
In the RAD model, the functional modules are developed in parallel as prototypes and are integrated to
make the complete product for faster product delivery. Since there is no detailed preplanning, it makes it easier
to incorporate the changes within the development process.
RAD projects follow iterative and incremental model and have small teams comprising of developers,
domain experts, customer representatives and other IT resources working progressively on their component or
prototype.
The most important aspect for this model to be successful is to make sure that the prototypes developed
are reusable.
RAD Model Design

20
CCS356 OOSE Unit-I
RAD model distributes the analysis, design, build and test phases into a series of short, iterative
development cycles.
Following are the various phases of the RAD Model −
i.Business Modelling
The business model for the product under development is designed in terms of flow of information and the
distribution of information between various business channels. A complete business analysis is performed to find
the vital information for business, how it can be obtained, how and when is the information processed and what
are the factors driving successful flow of information.
ii.Data Modelling
The information gathered in the Business Modelling phase is reviewed and analyzed to form sets of data objects
vital for the business. The attributes of all data sets is identified and defined. The relation between these data
objects are established and defined in detail in relevance to the business model.
iii.Process Modelling
The data object sets defined in the Data Modelling phase are converted to establish the business information flow
needed to achieve specific business objectives as per the business model. The process model for any changes or
enhancements to the data object sets is defined in this phase. Process descriptions for adding, deleting, retrieving
or modifying a data object are given.
21
CCS356 OOSE Unit-I
iv.Application Generation
The actual system is built and coding is done by using automation tools to convert process and data models into
actual prototypes.
v.Testing and Turnover
The overall testing time is reduced in the RAD model as the prototypes are independently tested during every
iteration. However, the data flow and the interfaces between all the components need to be thoroughly tested
with complete test coverage. Since most of the programming components have already been tested, it reduces the
risk of any major issues.
The following illustration describes the RAD Model in detail.
(RAD Model Vs Traditional SDLC
The traditional SDLC follows a rigid process models with high emphasis on requirement analysis and gathering
before the coding starts. It puts pressure on the customer to sign off the requirements before the project starts
and the customer doesn’t get the feel of the product as there is no working build available for a long time.
The customer may need some changes after he gets to see the software. However, the change process is quite
rigid and it may not be feasible to incorporate major changes in the product in the traditional SDLC.
The RAD model focuses on iterative and incremental delivery of working models to the customer. This results in
rapid delivery to the customer and customer involvement during the complete development cycle of product
reducing the risk of non-conformance with the actual user requirements.)
RAD Model - Application
RAD model can be applied successfully to the projects in which clear modularization is possible. If the
project cannot be broken into modules, RAD may fail.
The following pointers describe the typical scenarios where RAD can be used −
 RAD should be used only when a system can be modularized to be delivered in an incremental manner.
 It should be used if there is a high availability of designers for Modelling.
 It should be used only if the budget permits use of automated code generating tools.
 RAD SDLC model should be chosen only if domain experts are available with relevant business
knowledge.
 Should be used where the requirements change during the project and working prototypes are to be
presented to customer in small iterations of 2-3 months.
RAD model enables rapid delivery as it reduces the overall development time due to the reusability of the
components and parallel development. RAD works well only if high skilled engineers are available and the
22
CCS356 OOSE Unit-I
customer is also committed to achieve the targeted prototype in the given time frame. If there is commitment
lacking on either side the model may fail.
The advantages of the RAD Model are as follows −
 Changing requirements can be accommodated.

 Progress can be measured.
 Iteration time can be short with use of powerful RAD tools.
 Productivity with fewer people in a short time.
 Reduced development time.
 Increases reusability of components.
 Quick initial reviews occur.
 Encourages customer feedback.
 Integration from very beginning solves a lot of integration issues.
The disadvantages of the RAD Model are as follows −
 Dependency on technically strong team members for identifying business requirements.

 Only system that can be modularized can be built using RAD.
 Requires highly skilled developers/designers.
 High dependency on modelling skills.
 Inapplicable to cheaper projects as cost of Modelling and automated code generation is very high.
 Management complexity is more.
 Suitable for systems that are component based and scalable.
 Requires user involvement throughout the life cycle.
 Suitable for project requiring shorter development times.
7.Spiral model
The spiral model, first described by Barry Boehm in 1986, is a risk-driven software development
process model which was introduced for dealing with the shortcomings in the traditional waterfall model. A
spiral model looks like a spiral with many loops.
The exact number of loops of the spiral is unknown and can vary from project to project. This model
supports risk handling, and the project is delivered in loops. Each loop of the spiral is called a Phase of the
software development process.
The initial phase of the spiral model in the early stages of Waterfall Life Cycle that is needed to
develop a software product. The exact number of phases needed to develop the product can be varied by the
project manager depending upon the project risks. As the project manager dynamically determines the number
of phases, so the project manager has an important role to develop a product using a spiral model.
23
CCS356 OOSE Unit-I
The spiral model combines the idea of iterative development with the systematic, controlled aspects of
the waterfall model. This Spiral model is a combination of iterative development process model and sequential
linear development model i.e. the waterfall model with a very high emphasis on risk analysis. It allows
incremental releases of the product or incremental refinement through each iteration around the spiral.
Spiral Model - Design
The spiral model has four phases. A software project repeatedly passes through these phases in iterations called
Spirals.
1. Identification
2. Design
3. Construct or Build
4. Evaluation and Risk Analysis
i)Identification
This phase starts with gathering the business requirements in the baseline spiral. In the subsequent spirals as the
product matures, identification of system requirements, subsystem requirements and unit requirements are all
done in this phase.
This phase also includes understanding the system requirements by continuous communication between the
customer and the system analyst. At the end of the spiral, the product is deployed in the identified market.
24
CCS356 OOSE Unit-I
ii)Design
The Design phase starts with the conceptual design in the baseline spiral and involves architectural design,
logical design of modules, physical product design and the final design in the subsequent spirals.
iii)Construct or Build
The Construct phase refers to production of the actual software product at every spiral. In the baseline spiral,
when the product is just thought of and the design is being developed a POC (Proof of Concept) is developed in
this phase to get customer feedback.
Then in the subsequent spirals with higher clarity on requirements and design details a working model of the
software called build is produced with a version number. These builds are sent to the customer for feedback.
iv)Evaluation and Risk Analysis
Risk Analysis includes identifying, estimating and monitoring the technical feasibility and management
risks, such as schedule slippage and cost overrun. After testing the build, at the end of first iteration, the
customer evaluates the software and provides feedback.
Spiral Model Application
The Spiral Model is widely used in the software industry as it is in sync with the natural development process of
any product, i.e. learning with maturity which involves minimum risk for the customer as well as the
development firms.
The following pointers explain the typical uses of a Spiral Model −
 When there is a budget constraint and risk evaluation is important.

 For medium to high-risk projects.
 Long-term project commitment because of potential changes to economic priorities as the requirements
change with time.
 Customer is not sure of their requirements which is usually the case.
 Requirements are complex and need evaluation to get clarity.
 New product line which should be released in phases to get enough customer feedback.
 Significant changes are expected in the product during the development cycle.
The advantage of spiral lifecycle model is that it allows elements of the product to be added in, when they
become available or known. This assures that there is no conflict with previous requirements and design.
This method is consistent with approaches that have multiple software builds and releases which allows
making an orderly transition to a maintenance activity.
Another positive aspect of this method is that the spiral model forces an early user involvement in the system
development effort.
25
CCS356 OOSE Unit-I
On the other side, it takes a very strict management to complete such products and there is a risk of running
the spiral in an indefinite loop. So, the discipline of change and the extent of taking change requests is very
important to develop and deploy the product successfully.
The advantages of the Spiral Model are:
 Changing requirements can be accommodated.

 Allows extensive use of prototypes.
 Requirements can be captured more accurately.
 Users see the system early.
 Development can be divided into smaller parts and the risky parts can be developed earlier which helps in
better risk management.
The disadvantages of the Spiral Model are:
 Management is more complex.

 End of the project may not be known early.
 Not suitable for small or low risk projects and could be expensive for small projects.
 Process is complex
 Spiral may go on indefinitely.
 Large number of intermediate stages requires excessive documentation.

8.BIG-BANG MODEL
The Big Bang model is an SDLC model where we do not follow any specific process. The development
just starts with the required money and efforts as the input, and the output is the software developed which may
or may not be as per customer requirement.
This Big Bang Model does not follow a process/procedure and there is a very little planning required.
Even the customer is not sure about what exactly he wants and the requirements are implemented on the fly
without much analysis.
Usually this model is followed for small projects where the development teams are very small.
26
CCS356 OOSE Unit-I
Big Bang Model ─ Design and Application
The Big Bang Model comprises of focusing all the possible resources in the software development and
coding, with very little or no planning. The requirements are understood and implemented as they come. Any
changes required may or may not need to revamp the complete software.
This model is ideal for small projects with one or two developers working together and is also useful for
academic or practice projects. It is an ideal model for the product where requirements are not well understood
and the final release date is not given.
The advantage of this Big Bang Model is that it is very simple and requires very little or no planning. Easy to
manage and no formal procedure are required.
However, the Big Bang Model is a very high risk model and changes in the requirements or misunderstood
requirements may even lead to complete reversal or scraping of the project. It is ideal for repetitive or small
projects with minimum risks.
The advantages of the Big Bang Model are as follows −
 This is a very simple model

 Little or no planning required
 Easy to manage
 Very few resources required
 Gives flexibility to developers
 It is a good learning aid for new comers or students.
The disadvantages of the Big Bang Model are as follows −
 Very High risk and uncertainty.

 Can turn out to be very expensive if requirements are misunderstood.
27
CCS356 OOSE Unit-I
9.Prototype Model
The prototype model requires that before carrying out the development of actual software, a working
prototype of the system should be built.
A prototype is a toy implementation of the system. A prototype usually turns out to be a very crude
version of the actual system, possible exhibiting limited functional capabilities, low reliability, and inefficient
performance as compared to actual software.
In many instances, the client only has a general view of what is expected from the software product. In
such a scenario where there is an absence of detailed information regarding the input to the system, the
processing needs, and the output requirement, the prototyping model may be employed.
Steps of Prototype Model
28
CCS356 OOSE Unit-I
1. Requirement Gathering and Analyst
2. Quick Decision
3. Build a Prototype
4. Assessment or User Evaluation
5. Prototype Refinement
6. Engineer Product
Advantage of Prototype Model
1. Reduce the risk of incorrect user requirement

2. Good where requirement are changing/uncommitted
3. Regular visible process aids management
4. Support early product marketing
5. Reduce Maintenance cost.
6. Errors can be detected much earlier as the system is made side by side.
Disadvantage of Prototype Model
1. An unstable/badly implemented prototype often becomes the final product.

2. Require extensive customer collaboration
o Costs customer money
o Needs committed customer
o Difficult to finish if customer withdraw
o May be too customer specific, no broad market
3. Difficult to know how long the project will last.
4. Easy to fall back into the code and fix without proper requirement analysis, design, customer evaluation,
and feedback.
5. Prototyping tools are expensive.
6. Special tools & techniques are required to build a prototype.
7. It is a time-consuming process.
29
CCS356 OOSE Unit-I
10.Agile model
The meaning of Agile is swift or versatile."Agile process model" refers to a software development
approach based on iterative development. Agile methods break tasks into smaller iterations, or parts do not
directly involve long term planning. The project scope and requirements are laid down at the beginning of the
development process. Plans regarding the number of iterations, the duration and the scope of each iteration are
clearly defined in advance.
Each iteration is considered as a short time "frame" in the Agile process model, which typically lasts
from one to four weeks. The division of the entire project into smaller parts helps to minimize the project risk
and to reduce the overall project delivery time requirements. Each iteration involves a team working through a
full software development life cycle including planning, requirements analysis, design, coding, and testing
before a working product is demonstrated to the client.
1. Requirements gathering:
In this phase, you must define the requirements. You should explain business
opportunities and plan the time and effort needed to build the project. Based on this information, you can evaluate
technical and economic feasibility.
2. Design the requirements:
When you have identified the project, work with stakeholders to define requirements. You
can use the user flow diagram or the high-level UML diagram to show the work of new features and
show how it will apply to your existing system.
3. Construction/ iteration:
When the team defines the requirements, the work begins. Designers and developers start
working on their project, which aims to deploy a working product. The product will undergo various
stages of improvement, so it includes simple, minimal functionality.
30
CCS356 OOSE Unit-I
4. Testing:
In this phase, the Quality Assurance team examines the product's performance and looks for the
bug.
5. Deployment:
In this phase, the team issues a product for the user's work environment.
6. Feedback: After releasing the product, the last step is feedback. In this, the team receives feedback about
the product and works through the feedback.
Or [The Agile model is a software development process that is based on the iterative development of software
products. The Agile model is a type of incremental model where software is developed in a rapid incremental
cycle.
The stages involved in the Agile model are as follows:
1. Gather requirements This is the stage where important requirements of the project are defined. This
stage explains the important features and plans the time and effort ahead of the project.
2. Design requirements This stage illustrates the previously defined requirements with a user flow
diagram or UML diagrams.
3. Iteration After defining and designing the requirements, developers start working on the projects to
develop a working product. All of this is done within an iteration or sprint.
4. Testing This stage examines the product’s functionality and ensures the product does what it is
designed for.
5. Deployment This stage releases a product to the user.
6. Client feedback This last step gathers feedback from the client after releasing the product. The team
receives the feedback and implements changes if necessary.]
Advantage(Pros) of Agile Method:
1. Frequent Delivery
2. Face-to-Face Communication with clients.
3. Efficient design and fulfils the business requirement.
4. Anytime changes are acceptable.
5. It reduces total development time.
Disadvantages(Cons) of Agile Model:
31
CCS356 OOSE Unit-I
1. Due to the shortage of formal documents, it creates confusion and crucial decisions taken throughout
various phases can be misinterpreted at any time by different team members.
2. Due to the lack of proper documentation, once the project completes and the developers allotted to
another project, maintenance of the finished project can become a difficulty.
What is Agility?
Agility implies speed, although something that is fast is not necessarily agile. Developers and customers
alike appreciate speed, though being “first to market” and in terms of responsiveness.
Members if the agile alliance have expensed the following preferences and values:
1) Individuals and interactions over processes and tools
2) Working software over comprehensive documentation
3) Customer collaboration over contract negotiation
4) Responding to change over following a plan
Agility is defined as “the quality or state of being agile: MIMBLENESS, DEXTERITY (played with
increasing agility)”
Attributes of agility
1) Speed: Quick, fast
2) Nimble: Able to improvise, and use patterns creativity to construct new solutions on the fly, flexible.
3) Adaptable: Responsive (sense and respond), dynamic and interactive in response to a customer, or to
changing circumstances.
4) Resourceful: Thoughtful or exhibiting some discipline. This however is not the same as a traditional
“command and control” approach with defined, formal procedures.
Basic properties of a successful agile software development process
1) The first issue is the ability to adapt the development of the software as the clients problem changes.
32
CCS356 OOSE Unit-I
2) The second issue derives form the need to allow for the future evolution of any delivered solution.
3) The third issue is that of software quality- How do we know that the software always does what it is supposed to
do?
4) The fourth issue is the amount of unnecessary documentation and other bureaucracy that is required to sustain and
manage the development process.
5) The fifth issue is the human one, which relates both to the experience of the developers in the development process
and to the way in which the human resources are managed.
Coupled with these is a need to have a clear business focus for any software development project and application.
Principles of Agile for Achieving Agility
1) Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2) Welcome changing requirements, even late in development. Agile processes harness change for the customer’s
competitive advantage.
3) Deliver working software frequently, form a couple of weeks to a couple of months, with a preference to the
shorter timescale.
4) Business people and developers must work together daily throughout the project.
5) Build projects around motivated individuals. Give them the environment and support they need, and trust them to
get the job done.
6) The most efficient and effective method of conveying information to and within a development team is face-to-face
conversation.
7) Working software is the primary measure of progress.
8) Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain
a constant pace indefinitely.
9) Continuous attention to technical excellence and good design enhances agility.
10) Simplicity-the art of maximizing the amount of work not done – is essential.
11) The best architectures, requirements, and designs emerge from self-organizing teams.
12) At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior
accordingly.
Agile Process
i) Agile Methods are Adaptive rather than Predictive: Engineering methods tend to try to plan-out a large part
of the software process in great detail for a long span of time. This works well until things do not change. So
their nature is to resist change. The agile methods, however, welcome change. They try to be processes that
adapt and thrive on change, even to the point of changing themselves.
ii) Agile Methods are People-Oriented rather than Process-Oriented: The goal of engineering methods is to
define a process that will work well, whoever happens to be using it. Agile methods assert that no process will
ever make-up he skill of the development team, so the role of a process is to support the development team in
their work.
iii) Iterative Development with Incremental Delivery: The basic idea in this approach is to develop the
software in small parts, having a well-defined small functionally and then deliver. Then take the next
functionally and proceed further. The process is iterative and each incremental delivery along with earlier one
is complete usable software.
33
CCS356 OOSE Unit-I
Agile Methods:
Agile is an umbrella term for a set of methods and practices based on the values and principles
expressed in the Agile Manifesto that is a way of thinking that enables teams and businesses to innovate,
quickly respond to changing demand, while mitigating risk. Organizations can be agile using many of the
available frameworks available such as Scrum, Kanban, Lean, Extreme Programming (XP) and etc.
1. Scrum
2. Crystal
3. Dynamic Software Development Method(DSDM)
4. Feature Driven Development(FDD)
5. Lean Software Development
6. eXtreme Programming(XP)
1.Scrum
SCRUM is an agile development process focused primarily on ways to manage tasks in team-based
development conditions.
There are three roles in it, and their responsibilities are:
o Scrum Master: The scrum can set up the master team, arrange the meeting and remove obstacles for the
process
o Product owner: The product owner makes the product backlog, prioritizes the delay and is responsible
for the distribution of functionality on each repetition.
o Scrum Team: The team manages its work and organizes the work to complete the sprint or cycle.
34
CCS356 OOSE Unit-I
2.Crystal:
There are three concepts of this method-
1. Chartering: Multi activities are involved in this phase such as making a development team, performing feasibility
analysis, developing plans, etc.
2. Cyclic delivery: under this, two more cycles consist, these are:
A. Team updates the release plan.
B. Integrated product delivers to the users.
3. Wrap up: According to the user environment, this phase performs deployment, post-deployment.
3.Dynamic Software Development Method(DSDM):

DSDM is a rapid application development strategy for software development and gives an agile project
distribution structure. The essential features of DSDM are that users must be actively connected, and teams have
been given the right to make decisions. The techniques used in DSDM are:
 Time Boxing
 MoSCoW Rules
 Prototyping
The DSDM project contains seven stages:
 Pre-project
 Feasibility Study
 Business Study
 Functional Model Iteration
 Design and build Iteration
 Implementation
 Post-project
4. Feature Driven Development (FDD):

This method focuses on "Designing and Building" features. In contrast to other smart methods, FDD
describes the small steps of the work that should be obtained separately per function.
35
CCS356 OOSE Unit-I
5. Lean Software Development:
Lean software development methodology follows the principle "just in time production." The lean method
indicates the increasing speed of software development and reducing costs. Lean development can be
summarized in seven phases.
1. Eliminating Waste
2. Amplifying learning
3. Defer commitment (deciding as late as possible)
4. Early delivery
5. Empowering the team
6. Building Integrity
7. Optimize the whole
6. eXtreme Programming(XP)
This type of methodology is used when customers are constantly changing demands or requirements, or
when they are not sure about the system's performance.
When to use the Agile Model?

o When frequent changes are required.
o When a highly qualified and experienced team is available.
o When a customer is ready to have a meeting with a software team all the time.
o When project size is small.
Iteration
A short period that lasts from one to four weeks in the Agile process model is referred to as an iteration.
Each iteration results in small incremental releases, with each release building on previous functionality.
This individual release is thoroughly tested to ensure maintenance of the software quality.
36
CCS356 OOSE Unit-I
With Agile, the entire project is divided into smaller parts or sprints to help reduce the overall project
delivery time and minimize risks in the project.
Advantages of the Agile model
 Frequently encourages the delivery of working software.
 Adapts to changes in circumstances during the project.
 Reduces the total time spent in development.
 Constant interactions between clients, developers, and testers.
 Pays diligent attention to good design and technical excellence.
Disadvantages of the Agile model
 There may be confusion and misinterpretation at any time by different team members due to the
shortage or lack of formal documents.
 It can be difficult to maintain the final project due to the lack of proper documentation.
 It is difficult to assess the effort required to produce deliverables at the beginning of the software
development process
Stages of the Agile model

An iteration requires a team to work through a full software development cycle, where planning, analysis,
design, coding, and testing are carried out to produce a working product for a demonstration to the client.
The Agile movement proposes alternatives to traditional project management. Agile approaches are typically
used in software development to help businesses respond to unpredictability which refer to a group of software
development methodologies based on iterative development, where requirements and solutions evolve through
collaboration between self-organizing cross-functional teams.
The primary goal of being Agile is empowered the development team the ability to create and respond to
change in order to succeed in an uncertain and turbulent environment. Agile software development approach is
typically operated in rapid and small cycles. This results in more frequent incremental releases with each
release building on previous functionality. Thorough testing is done to ensure that software quality is
maintained.
37
CCS356 OOSE Unit-I
Agile SDLC model is a combination of iterative and incremental process models with focus on process
adaptability and customer satisfaction by rapid delivery of working software product. Agile Methods break the
product into small incremental builds. These builds are provided in iterations. Each iteration typically lasts from
about one to three weeks. Every iteration involves cross functional teams working simultaneously on various
areas like −
 Planning
 Requirements Analysis
 Design
 Coding
 Unit Testing and
 Acceptance Testing.
At the end of the iteration, a working product is displayed to the customer and important stakeholders.
What is 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.
Here is a graphical illustration of the Agile Model −
38
CCS356 OOSE Unit-I
The Agile thought process had started early in the software development and started becoming popular
with time due to its flexibility and adaptability.
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,
after the Agile Manifesto was published in 2001.
Following are the Agile Manifesto principles −
 Individuals and interactions − In Agile development, self-organization and motivation are important, as
are interactions like co-location and pair programming.
 Working software − Demo working software is considered the best means of communication with the
customers to understand their requirements, instead of just depending on documentation.
 Customer collaboration − As the requirements cannot be gathered completely in the beginning of the
project due to various factors, continuous customer interaction is very important to get proper product
requirements.
 Responding to change − Agile Development is focused on quick responses to change and continuous
development.
Agile Vs Traditional SDLC Models

39
CCS356 OOSE Unit-I
Agile is based on the adaptive software development methods, whereas the traditional SDLC models
like the waterfall model is based on a predictive approach. Predictive teams in the traditional SDLC models
usually work with detailed planning and have a complete forecast of the exact tasks and features to be delivered
in the next few months or during the product life cycle.
Predictive methods entirely depend on the requirement analysis and planning done in the beginning of
cycle. Any changes to be incorporated go through a strict change control management and prioritization.
Agile uses an adaptive approach where there is no detailed planning and there is clarity on future tasks
only in respect of what features need to be developed. There is feature driven development and the team adapts
to the changing product requirements dynamically. The product is tested very frequently, through the release
iterations, minimizing the risk of any major failures in future.
Customer Interaction is the backbone of this Agile methodology, and open communication with
minimum documentation are the typical features of Agile development environment. The agile teams work in
close collaboration with each other and are most often located in the same geographical location.
Agile methods are being widely accepted in the software world recently. However, this method may not
always be suitable for all products. Here are some pros and cons of the Agile model.
The advantages of the Agile Model are as follows −
 Is a 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.
The disadvantages of the Agile Model are as follows −
 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.
40
CCS356 OOSE Unit-I
Agile Manifesto
1) Customer satisfaction by rapid delivery of useful software
2) Welcome changing requirements, even late in development
3) Working software is delivered frequently
4) Working software is the principal measure of progress
5) Sustainable development, able to maintain a constant pace
6) Close, daily cooperation between businesspeople and developers
7) Face-to-face conversation is the best form of communication
8) Projects are built around motivated individuals, who should be trusted
9) Continuous attention to technical excellence and good design
10) Simplicity
11) Self-organizing teams
12) Regular adaptation to changing circumstances
Extreme Programming (XP)

Extreme programming (XP) is one of the most important software development frameworks of
Agile models.
It is used to improve software quality and responsiveness to customer requirements. The
extreme programming model recommends taking the best practices that have worked well in the past
in program development projects to extreme levels.
Good practices need to be practiced in extreme programming: Some of the good practices that
have been recognized in the extreme programming model and suggested to maximize their use are
given below:
 Code Review: Code review detects and corrects errors efficiently. It suggests pair programming as
coding and reviewing of written code carried out by a pair of programmers who switch their work
between them every hour.
 Testing: Testing code helps to remove errors and improves its reliability. XP suggests test-driven
development (TDD) to continually write and execute test cases. In the TDD approach, test cases
are written even before any code is written.
 Incremental development: Incremental development is very good because customer feedback is
gained and based on this development team comes up with new increments every few days after
each iteration.
 Simplicity: Simplicity makes it easier to develop good-quality code as well as to test and debug it.
 Design: Good quality design is important to develop good quality software. So, everybody should
design daily.
 Integration testing: It helps to identify bugs at the interfaces of different functionalities.
Extreme programming suggests that the developers should achieve continuous integration by
building and performing integration testing several times a day.
Basic principles of Extreme programming:
41
CCS356 OOSE Unit-I
XP is based on the frequent iteration through which the developers implement User Stories. User
stories are simple and informal statements of the customer about the functionalities needed. A User
Story is a conventional description by the user of a feature of the required system.
It does not mention finer details such as the different scenarios that can occur. Based on User
stories, the project team proposes Metaphors. Metaphors are a common vision of how the system
would work. The development team may decide to build a Spike for some features.
A Spike is a very simple program that is constructed to explore the suitability of a solution being
proposed. It can be considered similar to a prototype. Some of the basic activities that are followed
during software development by using the XP model are given below:
 Coding: The concept of coding which is used in the XP model is slightly different from traditional
coding. Here, the coding activity includes drawing diagrams (modeling) that will be transformed
into code, scripting a web-based system, and choosing among several alternative solutions.
 Testing: The XP model gives high importance to testing and considers it to be the primary factor
in developing fault-free software.
 Listening: The developers need to carefully listen to the customers if they have to develop good
quality software. Sometimes programmers may not have the depth knowledge of the system to be
developed. So, the programmers should understand properly the functionality of the system and
they have to listen to the customers.
 Designing: Without a proper design, a system implementation becomes too complex, and very
difficult to understand the solution, thus making maintenance expensive. A good design results
elimination of complex dependencies within a system. So, effective use of suitable design is
emphasized.
 Feedback: One of the most important aspects of the XP model is to gain feedback to understand
the exact customer needs. Frequent contact with the customer makes the development effective.
 Simplicity: The main principle of the XP model is to develop a simple system that will work
efficiently in the present time, rather than trying to build something that would take time and may
never be used. It focuses on some specific features that are immediately needed, rather than
engaging time and effort on speculations of future requirements.
 Pair Programming: XP encourages pair programming where two developers work together at the
same workstation. This approach helps in knowledge sharing, reduces errors, and improves code
quality.
 Continuous Integration: In XP, developers integrate their code into a shared repository several
times a day. This helps to detect and resolve integration issues early on in the development
process.
 Refactoring: XP encourages refactoring, which is the process of restructuring existing code to
make it more efficient and maintainable. Refactoring helps to keep the codebase clean,
organized, and easy to understand.
 Collective Code Ownership: In XP, there is no individual ownership of code. Instead, the
entire team is responsible for the codebase. This approach ensures that all team members have a
sense of ownership and responsibility towards the code.
 Planning Game: XP follows a planning game, where the customer and the development team
collaborate to prioritize and plan development tasks. This approach helps to ensure that the
team is working on the most important features and delivers value to the customer.
42
CCS356 OOSE Unit-I
 On-site Customer: XP requires an on-site customer who works closely with the development
team throughout the project. This approach helps to ensure that the customer’s needs are
understood and met, and also facilitates communication and feedback.
Applications of Extreme Programming (XP):

Some of the projects that are suitable to develop using the XP model are given below:
 Small projects: The XP model is very useful in small projects consisting of small teams as face-
to-face meeting is easier to achieve.
 Projects involving new technology or Research projects: This type of project faces changing
requirements rapidly and technical problems. So XP model is used to complete this type of project.
 Web development projects: The XP model is well-suited for web development projects as the
development process is iterative and requires frequent testing to ensure the system meets the
requirements.
 Collaborative projects: The XP model is useful for collaborative projects that require close
collaboration between the development team and the customer.
 Projects with tight deadlines: The XP model can be used in projects that have a tight deadline, as
it emphasizes simplicity and iterative development.
 Projects with rapidly changing requirements: The XP model is designed to handle rapidly
changing requirements, making it suitable for projects where requirements may change frequently.
 Projects where quality is a high priority: The bureaucracy-basedXP model places a strong
emphasis on testing and quality assurance, making it a suitable approach for projects where quality
is a high priority.
Extreme Programming (XP) is that focuses on delivering high-quality software through frequent
and continuous feedback, collaboration, and adaptation. XP emphasizes a close working relationship
between the development team, the customer, and stakeholders, with an emphasis on rapid, iterative
development and deployment.
Agile development approaches evolved in the 1990s as a reaction to documentation and
bureaucracy-based processes, particularly the waterfall approach. Agile approaches are based on some
common principles, some of which are:
1. Working software is the key measure of progress in a project.

2. For progress in a project, therefore software should be developed and delivered rapidly in small
increments.
3. Even late changes in the requirements should be entertained.
4. Face-to-face communication is preferred over documentation.
5. Continuous feedback and involvement of customers is necessary for developing good-quality
software.
6. A simple design which involves and improves with time is a better approach than doing an
elaborate design up front for handling all possible scenarios.
7. The delivery dates are decided by empowered teams of talented individuals.
43
CCS356 OOSE Unit-I
Extreme programming is one of the most popular and well-known approaches in the family of
agile methods. An XP project starts with user stories which are short descriptions of what scenarios
the customers and users would like the system to support. Each story is written on a separate card, so
they can be flexibly grouped.
XP, and other agile methods, are suitable for situations where the volume and space of
requirements change are high and where requirement risks are considerable.
XP includes the following practices:

1. Continuous Integration: Code is integrated and tested frequently, with all changes reviewed by the
development team.
2. Test-Driven Development: Tests are written before code is written, and the code is developed to
pass those tests.
3. Pair Programming: Developers work together in pairs to write code and review each other’s work.
4. Continuous Feedback: Feedback is obtained from customers and stakeholders through frequent
demonstrations of working software.
5. Simplicity: XP prioritizes simplicity in design and implementation, to reduce complexity and
improve maintainability.
6. Collective Ownership: All team members are responsible for the code, and anyone can make
changes to any part of the codebase.
7. Coding Standards: Coding standards are established and followed to ensure consistency and
maintainability of the code.
8. Sustainable Pace: The pace of work is maintained at a sustainable level, with regular breaks and
opportunities for rest and rejuvenation.
9. XP is well-suited to projects with rapidly changing requirements, as it emphasizes flexibility and
adaptability. It is also well-suited to projects with tight timelines, as it emphasizes rapid
development and deployment.
10. Refactoring: Code is regularly refactored to improve its design and maintainability, without
changing its functionality.
11. Small Releases: Software is released in small increments, allowing for frequent feedback and
adjustments based on that feedback.
12. Customer Involvement: Customers are actively involved in the development process, providing
feedback and clarifying requirements.
13. On-Site Customer: A representative from the customer’s organization is present with the
development team to provide continuous feedback and answer questions.
14. Short Iterations: Work is broken down into short iterations, usually one to two weeks in length, to
allow for rapid development and frequent feedback.
15. Planning Game: The team and customer work together to plan and prioritize the work for each
iteration, to deliver the most valuable features first.
16. Metaphor: A shared metaphor is used to guide the design and implementation of the system.
17. Coding Standards: Coding standards are established and followed to ensure consistency and
maintainability of the code.
Advantages of Extreme Programming (XP):

44
CCS356 OOSE Unit-I
 Slipped schedules − Timely delivery is ensured through slipping timetables and doable
development cycles.
 Misunderstanding the business and/or domain − Constant contact and explanations are ensured
by including the client on the team.
 Canceled projects − Focusing on ongoing customer engagement guarantees open communication
with the consumer and prompt problem-solving.
 Staff turnover − Teamwork that is focused on cooperation provides excitement and goodwill.
Team spirit is fostered by multidisciplinary cohesion.
 Costs incurred in changes − Extensive and continuing testing ensures that the modifications do
not impair the functioning of the system. A functioning system always guarantees that there is
enough time to accommodate changes without impairing ongoing operations.
 Business changes − Changes are accepted at any moment since they are seen to be inevitable.
 Production and post-delivery defects: Emphasis is on − the unit tests to find and repair bugs as
soon as possible.
45

Oose Unit 1

Uploaded by

Copyright:

Available Formats

Oose Unit 1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Oose Unit 1

Uploaded by

Copyright:

Available Formats

CCS356 OOSE Unit-I

Software engineering (Process manual to systematic)

Figure 1. Object-Oriented Software Engineering.

Figure 2. Jacobson’s Use Case diagram.

 SDLC is the acronym of Software Development Life Cycle.

 studying the existing or obsolete system and software,

Operation and Maintenance

There are 4 software process activities

SOFTWARE DEVELOPMENT PROCESS STEPS

Step #1: Planning

Step #2: Implementation

Step #3: Testing

Step #4: Deployment and Maintenance

=>Software Development Plan (SDP)

Types of Software Process Model

The sequential phases in Waterfall model are:

 Requirement Gathering and analysis:

(Waterfall model is most appropriate are −

 Requirements are very well documented, clear and fixed.

Waterfall Model - Advantages

Some of the major advantages of the Waterfall Model are as follows −

 Simple and easy to understand and use(Efficiently, like Easy to use)

Waterfall Model - Disadvantages

 No working software is produced until late during the life cycle.

(know diff between verification & validation)

V-Model - Verification Phases

 Business Requirement Analysis

The different Validation Phases in a V-Model are explained in detail below.

 Requirements are well defined, clearly documented and fixed.

The advantages of the V-Model method are as follows −

 This is a highly-disciplined model and Phases are completed one at a time.

The disadvantages of the V-Model method are as follows −

 High risk and uncertainty.

Iterative Model - Design

The following illustration is a representation of the Iterative and Incremental model −

Iterative Model - Application

 Requirements of the complete system are clearly defined and understood.

The advantages of the Iterative and Incremental

The disadvantages of the Iterative and Incremental

 More resources may be required.

5. UNIFIED PROCESS MODEL

It defines the order of phases.

Phases of Unified Process Model

Rapid Application Development focuses on gathering customer requirements through workshops or

RAD Model Design

Following are the various phases of the RAD Model −

v.Testing and Turnover

The following illustration describes the RAD Model in detail.

(RAD Model Vs Traditional SDLC

RAD Model - Application

The advantages of the RAD Model are as follows −

 Changing requirements can be accommodated.

The disadvantages of the RAD Model are as follows −

 Dependency on technically strong team members for identifying business requirements.

Spiral Model - Design

iv)Evaluation and Risk Analysis

Spiral Model Application

The following pointers explain the typical uses of a Spiral Model −

 When there is a budget constraint and risk evaluation is important.