UNIT I

Introduction: Evolution, Software development projects, Exploratory style of software

developments, Emergence of software engineering, Notable changes in software development
practices, Computer system engineering.
Software Life Cycle Models: Basic concepts, Waterfall model and its extensions, Rapid
application development, Agile development model, Spiral model.
…………………………………………………………………………………………………………
………………….
1. Introduction
The computer has mainly two major components:
1. Hardware
2. Software

What is Computer Hardware?

Computer hardware is a physical device of computers that we can see and touch. For e.g.
Monitor, Central Processing Unit, Mouse, Joystick, etc. Using these devices, we can control
computer operations like input and output.
Example: Input Devices, Output Devices, Storage Devices, Internal Components

Computers cannot do anything on its own. It is the user who instructs computer; what to do,
how to do and when to do. In order to perform any task, you have to give a set of instructions
in a particular sequence to the computer. These sets of instructions are called Programs.
Software refers to a set of programs that makes the hardware perform a particular set of
tasks in particular order.
What is software engineering?
Software engineering discusses systematic and cost-effective techniques for software
development. These techniques help develop software using an engineering approach.
The Evaluation of Software Engineering:
a) Initial Stage: Started as an art form where development relied on individual intuition
and ad-hoc practices.
b) Progression: Evolved into a craft with shared techniques and, later, a discipline
structured around theoretical and empirical principles.
c) Current State: Now considered an engineering discipline, akin to civil or mechanical
engineering, emphasizing structured and scientific approaches.
The process framework activities

A process framework establishes the foundation for a complete software engineering process
by identifying a small number of framework activities that are applicable to all software
projects, regardless of their size or complexity.
 Communication – Communicate with stakeholders and customers to obtain objectives
of the system and requirements for the software.
 Planning – Software project plan has details of resources needed, tasks and risk factors
likely to occur, schedule.
 Modelling – Architectural models and design to better understand the problem and for
work towards the best solution.
 Construction – Generation of code and testing of the system to rectify errors and
ensuring all specified requirements are met.
 Deployment – Entire software product or partially completed product is delivered to the
customer for evaluation and feedback.
The above process framework can be developed different ways as
follows Linear process flow
Linear process flow executes each activity in sequence.

Iterative process flow

Iterative process flow repeats one or more activities before starting next.
Evolutionary process flow
Evolutionary process flow carries out activities in a circular way.

Parallel process flow

Parallel process flow executes one or more activities in parallel with each other.

Is software engineering a science or an art?

Software engineering is debated as being either a science or an art. However, it is argued that
software engineering has more similarities with other engineering disciplines than with art or
pure science. Here are the distinctions highlighted:
1. Similarity to Engineering Disciplines:
o Like other engineering fields, software engineering heavily relies on accumulated
knowledge and experiences of numerous practitioners.
o These experiences are systematically organized, and empirical observations are
sometimes given theoretical backing. In cases where theoretical justification is
unavailable, practical rules of thumb are adopted.
o Engineering disciplines, including software engineering, often deal with
conflicting goals and trade-offs, such as cost, maintainability, and usability,
necessitating iterative solutions and backtracking. This differs from science,
which aims for unique, provable solutions.
2. Contrast with Science:
o Science involves constructing solutions strictly through provable principles.
 o In contrast, software engineering often uses well-understood principles
without complete scientific rigor.
3. Contrast with Art:
o Art typically involves subjective judgment based on qualitative attributes
and poorly understood principles.
o Software engineering, in contrast, relies on well-documented and understood
methods to achieve its goals.
Software engineering is neither purely a science nor an art but shares characteristics of an
engineering discipline, blending empirical practices and systematic methodologies. It
emphasizes practicality, trade-offs, and iterative problem-solving over artistic intuition or
purely theoretical precision.
Q) EVOLUTION—FROM AN ART FORM TO AN ENGINEERING DISCIPLINE
a) Initial Phase: Art
Form

 In the early stages of software development, programming was seen as an art.

 Developers relied heavily on intuition, personal experience, and ad hoc practices to
create software.
 This informal style, called exploratory programming or build-and-fix, lacked formal
rules, plans, or methodologies.
b) Transition to Craft
 As the field matured, programming began to resemble a craft.
 Knowledge was shared among programmers, leading to improved practices and better
results.
 Lessons learned from past projects were increasingly documented and shared.
c) Emergence of Engineering Discipline
 Over time, the accumulation of best practices, empirical findings, and theoretical
foundations allowed software development to become a formal engineering discipline.
 The adoption of systematic approaches, like design methodologies, planning,
estimation, and testing, marked this transition.
FIGURE 1.1: Evolution of technology with time
d) Comparison with Other Engineering Disciplines
 The evolution of software engineering mirrors the progression of other engineering
disciplines, such as iron-making or building construction:
o Initial stages were dominated by secretive and artisanal practices.
o Gradually, these practices transitioned into standardized, scientific, and
engineering-based methods.
e) Current State
 Software engineering now employs structured techniques and principles that are widely
accepted in the industry.
 Despite occasional criticism for lacking complete scientific rigor, the discipline has
proven indispensable for managing the complexity and scale of modern software
development.

FIGURE 1.2: Relative changes of hardware and software costs over time
As can be seen in the figure 1.2, organisations are spending increasingly larger portions of
their budget on software as compared to that on hardware. Among all the symptoms of the
present software crisis, the trend of increasing software costs is probably the most vexing.
Q) SOFTWARE DEVELOPMENT PROJECTS
2.1 Programs versus Products
 Toy Software:
o Developed by individuals (e.g., students or hobbyists) for personal use or
classroom assignments.
o Characteristics:
 Small size and limited functionality.
 Poor user interface, documentation, maintainability, efficiency, and
reliability.
 Solely used and maintained by the developer.
 Referred to as "programs" due to their simplicity and lack of supporting
documentation.
  Professional Software:
o Designed for multiple users and includes proper documentation (user
manuals, design documents, test documents, etc.).
o Characteristics:
 Developed by teams using systematic methodologies.
 Good user interface and thorough testing.
 Built with long-term maintainability and scalability in mind.
 Includes a set of supporting documents alongside the code.
2.2 Types of Software Development Projects
Software projects are broadly classified into two categories:
1. Software Product Development Projects
o Focused on creating software products, either:
 Generic Products: Target a broad spectrum of customers (e.g., Windows,
Oracle).
 Domain-Specific Products: Tailored for specific industries or market
segments (e.g., banking or healthcare).
2. Software Services Projects
o Encompass customization, maintenance, outsourcing, testing, and consultancy.
o Characteristics:
 Rapidly growing segment due to the availability of a large codebase for
reuse.
 Heavy reliance on modifying or customizing existing software for specific
needs.
 Project durations are typically shorter (a few months or weeks).

FIGURE 1.3: A classification of software projects.

2.3 Software Projects Undertaken by Indian Companies
 Indian companies excel in executing software services projects (e.g., customization and
maintenance).
 Recent trends show an increased focus on product development despite its higher
business risks.
 Differences between products and services:
o Generic Products: Require substantial upfront investment and carry risks of market
acceptance.
o Services Projects: Less risky and provide one-time revenues.
Q) EXPLORATORY STYLE OF SOFTWARE DEVELOPMENT
The exploratory style refers to an informal development approach where the programmer relies
on intuition rather than systematic methodologies.
Developers enjoy complete freedom to choose the sequence of activities while building
software. Process
1. Initial Briefing:
o The customer provides a general idea of the requirements.
2. Coding:
o The developer starts coding based on the customer's description without a detailed
plan.
3. Testing and Bug Fixing:
o The software undergoes a cycle of testing and fixing bugs until it meets the
customer's expectations.
Schematic Representation
 Figure 1.4 illustrates the exploratory development style:
o Start: Customer briefing.
o Development: Coding without formal plans.
o Testing: Continuous cycle of fixing bugs until customer satisfaction is achieved.

FIGURE 1.4: Exploratory program development

Suitability
 The exploratory style is suitable for small programs or projects developed by individual
programmers (e.g., students or hobbyists).
 It is not viable for professional or large-scale software projects.
Problems with the Exploratory Style
1. Unpredictable Effort and Time:
o Development time and effort increase exponentially with problem size (Figure
1.5).
o As software grows in complexity, this style becomes inefficient and unmanageable.
2. Poor Planning:
o There is no proper estimation or planning for resources, timelines, or deliverables.
3. Low Maintainability:
o The resulting code is often unstructured and difficult to maintain or enhance.
4. Inefficiency:
o The lack of systematic approaches leads to cost and time overruns, making it
uncompetitive for professional use.
Q) EMERGENCE OF SOFTWARE ENGINEERING
4.1 Early Computer Programming
 In the early days, programming was performed using low-level assembly languages.
 Programs were small and written by individuals, often using ad hoc and exploratory
styles.
 The lack of standard practices or formal methodologies made software development
inefficient and error-prone.
4.2 High-level Language Programming
 The introduction of high-level programming languages like FORTRAN and COBOL
marked a significant advancement.
 These languages improved productivity and allowed programmers to focus on problem-
solving rather than hardware details.
 However, challenges such as poor design practices and lack of documentation persisted.

4.3 Control Flow-based Design

 Control flow-based design emerged as the first step toward structured programming.
 Programs were designed using a logical flow of control, including loops, conditionals, and
sequences.
 While this was an improvement, it did not adequately address the complexity of large
systems.
4.4 Data Structure-oriented Design
 The next evolution focused on data structures as the central element of program design.
 Programs were organized around key data structures and operations, improving
modularity and reducing redundancy.
4.5 Data Flow-oriented Design
 Data flow-oriented design introduced the concept of information flow within a system.
 This approach emphasized how data moves between components and how inputs are
transformed into outputs.
 It improved clarity and system-level understanding of software.

4.6 Object-oriented Design

 The introduction of object-oriented programming (OOP) revolutionized software
engineering.
 Key principles:
1. Encapsulation: Bundling data and methods within objects.
2. Inheritance: Reusing and extending existing code.
 3. Polymorphism: Allowing objects to be used interchangeably.
 Object-oriented design facilitated modularity, reusability, and scalability, making it
suitable for large, complex systems.
Q) NOTABLE CHANGES IN SOFTWARE DEVELOPMENT PRACTICES
Key Changes in Software Development Practices
1. Increased Complexity of Software Systems
o Early programs were simple and often written by individual developers.
o Modern software systems are far more complex, requiring teams of developers
and systematic development practices.
2. Shift to Team-based Development
o Collaboration among teams is now essential due to the scale and complexity
of modern software.
o Systematic methods, tools, and documentation are required for effective teamwork.
3. Emphasis on Maintainability
o Early development practices often ignored the need for maintainable code.
o Modern practices prioritize writing modular, readable, and maintainable code
to facilitate updates and enhancements.
4. Focus on Testing and Quality Assurance
o Testing was once considered optional or performed late in the development
process.
o Today, testing is an integral part of the development lifecycle, with practices like
unit testing, integration testing, and automated testing.
5. Adoption of Iterative and Agile Development Models
o Traditional models, like the waterfall model, have given way to iterative
approaches.
o Agile methodologies focus on adaptability, customer collaboration, and
incremental delivery.
6. Automation and Tools
o The rise of tools for version control, continuous integration, and deployment (e.g.,
Git, Jenkins) has transformed development practices.
o Integrated Development Environments (IDEs) and debugging tools improve
productivity.
7. Rise of Open Source
o Open-source software development has gained popularity, enabling collaboration
across global developer communities.
8. Globalization and Outsourcing
o Software development has become a global activity, with companies outsourcing
to leverage cost benefits and expertise from different regions.
9. Security Awareness
o With the increasing prevalence of cyber threats, security has become a key
focus during development.
 o Practices like secure coding and vulnerability assessments are now standard.
10.Shift Towards Cloud Computing
o Many software systems are now developed for cloud environments, leveraging
scalability, cost- effectiveness, and accessibility.
Q) COMPUTER SYSTEMS ENGINEERING
Computer systems engineering is an interdisciplinary approach that emphasizes the design,
development, and integration of both hardware and software components to build robust
systems.
It considers not only the functional aspects but also factors like reliability, maintainability,
usability, and performance.
Scope of Computer Systems Engineering
1. System-level Perspective
o Focuses on designing the entire system rather than isolated components.
o Includes a wide array of concerns such as hardware-software co-design, system
integration, and real-time operations.
2. Hardware and Software Integration
o Ensures that hardware
and software
components work
seamlessly together.
o Requires knowledge of
hardware
specifications, low-
level programming,
and high-level
application
requirements.
3. Lifecycle Management
o Addresses all phases of
the system lifecycle,
including design,
implementation,
testing, deployment,
and maintenance.
4. Trade-offs
o Balances competing goals such as cost, performance, reliability, and power
consumption. Role in Software Engineering
 Computer systems engineering is foundational for projects that demand close
interaction between hardware and software, such as:
o Embedded systems.
o Real-time systems.
o IoT devices.
 It complements software engineering by addressing hardware constraints and ensuring
the software is optimized for the underlying hardware platform.
 CHAPTER-II
Software Life Cycle Models
Basic concepts, Waterfall model and its extensions, Rapid application development, Agile
development model, Spiral model.
…………………………………………………………………………………………………………
………………….
1.A FEW BASIC CONCEPTS
The following are the a few basic concepts concerning life cycle models
a) Software life cycle
The life cycle of a software represents the series of identifiable stages through which it evolves
during its life time.
 The software life cycle is a biological process involving stages from initial customer
request to full development and finally disposal.
 The inception stage is the initial stage where customers express a need for the software.
 The software evolves through a series of phases based on development activities
until it is fully developed and released to customers.
 The operation phase, or maintenance phase, begins when users start using the
software and suggest improvements and modifications.
 The operation phase is the longest and constitutes the useful life of a software.
 The software is retired when users no longer find it useful due to changes in
business scenarios, availability of new software, or changing computing platforms.
 The software life cycle model is crucial in professional software development
environments.

b) Software development life cycle (SDLC) model

Software Development Life Cycle (SDLC) is a process used by the software industry to design,
develop and test high quality softwares. The SDLC aims to produce a high-quality software that
meets or exceeds customer expectations, reaches completion within times and cost estimates.

 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.

What is SDLC?

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. The life cycle defines a methodology for improving the quality of software and the
overall development process.

The following figure is a graphical representation of the various stages of a typical SDLC.
A typical Software Development Life Cycle consists of the following stages −

Stage 1: Planning and Requirement Analysis

Requirement analysis is the most important and fundamental stage in SDLC. It is performed by
the senior members of the team with inputs from the customer, the sales department, market
surveys and domain experts in the industry. 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

SRS is the reference for product architects to come out with the best architecture for the product
to be developed. 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).
The internal design of all the modules of the proposed architecture should be clearly defined
with the minutest of the details in DDS.
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 and programming
tools like compilers, interpreters, debuggers, etc. are used to generate the code. Different high
level programming languages such as C, C++, Pascal, Java and PHP are used for coding. 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. The product may first be released in a limited segment and tested in the real
business environment (UAT- User acceptance testing).

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

The Waterfall Model was the first Process Model to be introduced. It is also referred to as
a linear-sequential life cycle model. It is very simple to understand and use. In a waterfall model,
each phase must be completed before the next phase can begin and there is no overlapping in
the phases.

The Waterfall model is the earliest SDLC approach that was used for software development.

The waterfall Model illustrates the software development process in a linear sequential flow. This
means that any phase in the development process begins only if the previous phase is complete.
In this waterfall model, the phases do not overlap.

Waterfall Model - Design

Waterfall approach was first SDLC Model to be used widely in Software Engineering to ensure
success of the project. In "The Waterfall" approach, the whole process of software development
is divided into separate phases. In this Waterfall model, typically, the outcome of one phase acts
as the input for the next phase sequentially.

The following illustration is a representation of the different phases of the Waterfall Model.
 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 − 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 - Application

Every software developed is different and requires a suitable SDLC approach to be followed
based on the internal and external factors. Some situations where the use of 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

 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.

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.

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.

RAD Model

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

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 −

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.

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.

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.

Application Generation

The actual system is built and coding is done by using automation tools to convert process and
data models into actual prototypes.

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.

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 - Pros and Cons

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 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.

Agile Model

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 −

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

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 Model - Pros and Cons

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.

Spiral Model

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.

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.

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.

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.

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.

The following illustration is a representation of the Spiral Model, listing the activities in each
phase.
 Based on the customer evaluation, the software development process enters the next iteration
and subsequently follows the linear approach to implement the feedback suggested by the
customer. The process of iterations along the spiral continues throughout the life of the software.

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.

Spiral Model - Pros and Cons

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.

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 SDLC Model are as follows −

 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 SDLC Model are as follows −

 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.

2.3 V-Model
A popular development process model, V-model is a variant of the waterfall model. As is the
case with the waterfall model, this model gets its name from its visual appearance (see Figure
2.5).
In this model verification and validation activities are carried out throughout the development
life cycle, and therefore the chances bugs in the work products considerably reduce. This
model is therefore generally considered to be suitable for use in projects concerned with
development of safety-critical software that are required to have high reliability.

As shown in Figure 2.5, there are two main phases—development and validation phases. The
left half of the model comprises the development phases and the right half comprises the
validation phases.

1). In each development phase, along with the development of a work product, test case
design and the plan for testing the work product are carried out, whereas the actual testing is
carried out in the validation phase. This validation plan created during the development
phases is carried out in the corresponding validation phase which have been shown by dotted
arcs in Figure 2.5.
2). In the validation phase, testing is carried out in three steps—unit, integration, and system
testing. The purpose of these three different steps of testing during the validation phase is to
detect defects that arise in the corresponding phases of software development— requirements
analysis and specification, design, and coding respectively.
 V-model versus waterfall model

 V-model is an extension of the waterfall model, with testing activities spread throughout
the lifecycle.
 During requirements specification, system test suite design occurs.
 In waterfall model where testing activities are confined to the testing phase only, in the
V-model testing activities are spread over the entire life cycle. Design phase involves
designing integration test cases. Unit test cases are designed during coding.
 Development and validation activities proceed hand in hand in
this model. Advantages of V-model
The important advantages of the V-model over the iterative waterfall model are as following:
 In the V-model, much of the testing activities (test case design, test planning, etc.) are
carried out in parallel with the development activities. Therefore, before testing phase
starts significant part of the testing activities, including test case design and test
planning, is already complete. Therefore, this model usually leads to a shorter testing
phase and an overall faster product development as compared to the iterative model.
 Since test cases are designed when the schedule pressure has not built up, the quality
of the test cases is usually better.
 The test team is reasonably kept occupied throughout the development cycle in contrast
to the waterfall model where the testers are active only during the testing phase. This
leads to more efficient manpower utilisation.
 In the V-model, the test team is associated with the project from the beginning.
Therefore, they build up a good understanding of the development artifacts, and this in
turn, helps them to carry out effective testing of the software. In contrast, in the
waterfall model often the test team comes on board late in the development cycle,
since no testing activities are carried out before the start of the implementation and
testing phase.
Disadvantages of V-model
Being a derivative of the classical waterfall model, this model inherits most of the weaknesses
of the waterfall model.
2 Marks Questions

1. What is the significance of software engineering in modern development

practices? Software engineering introduces systematic, disciplined, and
quantifiable approaches to the development, operation, and maintenance of
software.
2. What is exploratory software development?
Exploratory development is an informal approach where the focus is on rapidly building a
working version of the system without extensive upfront planning or formal
requirements.
3. Why did the emergence of software engineering become necessary?
The emergence was driven by the increasing complexity of software, the need for
reliability, and the demand for better software quality.
4. What are the key challenges in software development projects?
Key challenges include unclear requirements, tight schedules, resource constraints,
and ensuring software quality and scalability.
5. What are notable changes in software development practices over time?
Changes include the shift to iterative development, increased automation, use of version
control, and the adoption of agile and DevOps practices.
6. What is computer system engineering?
 Computer system engineering is the discipline of designing and managing computer
systems, encompassing both hardware and software components.
Software Life Cycle Models
1. What is a software life cycle model?
A software life cycle model is a conceptual framework that describes the stages involved
in software development, from inception to maintenance.
2. What are the primary stages in the waterfall model?
The primary stages are requirement analysis, system design, implementation, integration,
testing, deployment, and maintenance.
3. How does the rapid application development (RAD) model differ from the waterfall
model? RAD emphasizes quick development through iterative prototypes and user
feedback, whereas the waterfall model follows a sequential process.
4. What is the main goal of the agile development model?
The main goal of agile is to deliver small, incremental changes in working software with
continuous collaboration and flexibility.
5. What is the spiral model?
The spiral model combines iterative development with risk management, focusing on risk
analysis at each stage.
6. Name one extension of the waterfall model.
One extension of the waterfall model is the V-model (Verification and Validation model).
7. What are the key benefits of using the agile model?
Agile allows faster delivery, flexibility in responding to changes, and enhanced
collaboration between stakeholders.

8. What are the four main activities in the spiral model?