Software Engineering & Project Management

BCS501

Sem V - AIML

Faculty Incharge: Dr. Manjula Ramannavar

 Modules
M1: Software and Software Engineering ; Process Models

M2: Understanding Requirements ; Requirements Modeling Scenarios,

Information and Analysis classes ; Requirement Modeling Strategies

M3: Agile Development ; Principles that guide practice

M4: Introduction to Project Management ; Project Evaluation

M5: Software Quality ; Software Project Estimation

 Module 1

Software and Software Engineering and

Process Model
 Contents
Chapter 1: Software and Software Engineering: The Nature of Software, The
Unique Nature of Web Apps, Software Engineering, Software Process, Software
Engineering Practice, Software Myths.

Chapter 2: Process Models: A Generic Process Model, Process assessment and

improvement, Prescriptive Process Models: The Waterfall Model, Incremental
Process Models, Evolutionary Process Models, Concurrent models, Specialized
Process Models, The Unified Process, Personal and Team Process Models
 Module 1 - Chapter 1

Software and Software Engineering

 Introduction to Software Engineering
What is Software Engineering?

The term software engineering is the combination of two words, software and
engineering.

The software is a collection of integrated programs. It consists of carefully-organized

instructions and code written by developers using any of the various particular
computer languages.

Engineering is the application of scientific and practical knowledge to invent, design,

 The Evolving Role Of Software
Dual Role of Software:
• As a Product: Delivers computing potential through computer hardware or
networks.
• Transforms, manages, acquires, modifies, displays, and transmits information.
• As a Delivery Vehicle: Basis for computer control (OS), information
communication (N/w), and creating other programs (S/w tools, f/ws, envs).

Information Transformer:
• Software transforms personal data, manages business information, and provides
access to global networks like the Internet.
 The Evolving Role Of Software

Evolution of Software:
• Significant changes in computer software over the past 50 years:
• Hardware improvements and new computing architectures.
• Increased memory/storage and innovative input/output options.
• Shift from solo programmers to specialized teams for complex applications.
 Nature Of Software
Software is:

(1) instructions (computer programs) that when executed provide

desired features, function, and performance;

(2) data structures that enable the programs to adequately manipulate

information, and

(3) document that describes the operation and use of the programs.
 Nature Of Software
Characteristics of software

1) Software is developed or engineered, it is not manufactured in

the classical sense

- Both h/w & s/w – high quality  good design

- Manufacturing h/w  quality pbms --- non-existent (easily corrected) for s/w

It is not a Traditional manufacturing approach, It’s a Creative Process,

Involves designing, coding, and refining a product based on user needs.
 Nature Of Software
Characteristics of software

2) Software does not wear out. However, it weakens due to change.

Changes in software occur due to bug fixes, feature updates, and adaptations to new
requirements. These modifications can introduce new errors, which degrade the
software's performance or functionality.

Unlike physical products (e.g., machinery), software does not deteriorate over
time due to usage
 Nature Of Software

Hardware follows a "bathtub curve," showing high initial stable operation, and wear-out
over time.

Software doesn’t wear out but fails due to changes (bug fixes, updates), which can
introduce new errors, increasing the failure rate over time.
 Nature Of Software
Hardware:

• Hardware has Relatively high failure rates early in its life.

• Defects are corrected then failure rate drops to a steady-state level for some
period of time.

• As time passes, the failure rate rises again as hardware components suffer from
the cumulative effects of dust, vibration, abuse,

• The hardware begins to wear out(performance degradation start to occur, making

hardware prone to failure over time).
 Nature Of Software
• Software isn't affected by environmental issues like heat or humidity that wear
out hardware.

• Ideally, software failure rates should follow an "idealized curve," where defects
cause high failure rates early on, and then the rates decrease as bugs are fixed.

• Unlike hardware, software doesn't wear out physically, but it can still fail due to
undiscovered defects.

• Software will inevitably change and evolve throughout its life to meet new
requirements or fix issues.
 Nature Of Software
Characteristics of software

➢Software is custom built rather than assembling existing

components.

Software is designed and developed to meet specific requirements or solve

particular problems of a user or organization.

Involves writing new code, crafting unique architectures, and creating new
features.
 Software Applications
Seven Broad Categories of software are challenges for software engineers

• System software- System software is a collection of programs written to service

other programs. System software: such as compilers, editors, file management
utilities.

• Application software- stand-alone programs for specific needs. This software

are used to controls business needs. Ex: Transaction processing.
 Software Applications
• Artificial intelligence software- Artificial intelligence (AI) software makes
use of nonnumeric algorithms to solve complex problems. Application within
this area include robotics, pattern recognition, game playing.

• Engineering and scientific software- “number crunching” enables engineers

and scientists to efficiently analyze, model, and solve complex problems,
making it a crucial aspect of their work in various fields.
 Software Applications
• Embedded software resides within a product or system. (key pad control of
a microwave oven, digital function of dashboard display in a car).

• Product-line software focus on a limited marketplace to address mass

consumer market. (word processing, graphics, database management).

• WebApps (Web applications) network centric software. As web 2.0

emerges, more sophisticated computing environments are supported; integrated
with remote database and business applications.
 Software-New Categories

1.Open-World Computing: With wireless networks growing, software engineers

need to build systems that let mobile devices, PCs, and servers communicate
easily.

2.Netsourcing: The web is becoming a computing engine as well as content

provider, so engineers must create simple and useful apps for people worldwide.

3.Open Source: More source code is shared freely, so engineers must write clear
code and track changes for everyone to understand.
 Legacy Software
Definition: Legacy software refers to older computer programs that have been modified over
time to meet new business requirements.
Challenges: These systems often have poor design, outdated documentation, and convoluted
code, making them costly to maintain and risky to update.
Importance: Despite their issues, legacy systems maintain business operations and support core
functions.
Handling Legacy Systems:
1. If the system works well and meets user needs, it's best to leave it as is.
2. Changes may be necessary to adapt to new technology, meet business requirements, or
enable integration with modern systems.
3. Adapted / enhanced / extended /re-architected to meet the changing requirements
 The Unique Nature of Web Apps

• Web applications (WebApps) are a unique type of software that blend elements
of print publishing, software development, marketing, computing,
communications, and art.

• Web Technology are capable of empowering new web applications with

sophisticated functionalities such as data interconnection, adaptable data
formats, and external Application Programming Interfaces (APIs), expanding the
realm of what is achievable in the digital landscape.
 The Unique Nature of Web Apps

Key Features / Attributes:

• Network Intensiveness: A WebApp is on a network  diverse community of clients.
Worldwide access – Internet / limited access -- Intranet
• Concurrency: Many users can use the WebApp simultaneously.
• Unpredictable Load: The number of users can vary widely from day to day.
• Performance: Users expect fast loading; delays can cause them to leave.
• Availability: WebApps should be accessible 24/7, though 100% uptime isn't always
possible.
The Unique Nature of Web Apps

• Data-Driven: They often present multimedia content and access external databases.
• Content-Sensitive: Quality content and visuals are crucial for user satisfaction.
• Continuous Evolution: WebApps evolve quickly without strict release schedules.
• Immediacy: Quick time-to-market, often within days or weeks.
• Security: Network access makes it challenging to protect sensitive information.
• Aesthetics: A good design is vital, especially for marketing or sales purposes.
 Software Engineering

Why s/w must be engineered?

To build s/w  challenges of today, you must recognize the following realities:
• Understand the problem before you build the solution – S/w is everywhere; many
users, all requirements to be taken into account
• Design is a pivotal s/w engg activity – IT requirements vary – Complex
computing environment – interaction of all system elements is important
• Both quality and maintainability are an outgrowth of good design – heavy
reliance on s/w for day-to-day operations – high quality
• As an app value grows – user base and its longevity grow – demands grow – s/w
should be maintainable
Software Engineering

• Software engineering is the establishment and use of sound engineering principles

in order to obtain economically viable software that is reliable and works
efficiently on real machines.
Or
• The IEEE definition: Software Engineering: (1) The application of a systematic,
disciplined, quantifiable approach to the development, operation, and maintenance of
software; that is, the application of engineering to software.
 Software Engineering- Layered technology

Software engineering is a fully layered technology.

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

The layered technology consists of:

1. Quality focus – Bedrock that supports SE
• Total quality management, Six Sigma, etc.
• Correctness of the functions required to be performed by the
software.
• Integrity – reliable and secure so that the unauthorized user
cannot
access information or data.
• Usability – the efforts required to use or operate the
 Software Engineering- Layered technology
2. Process
• It is the base layer or foundation layer for the software
engineering.
• It holds the technology layers together and ensures timely
s/w development
• It covers all activities, actions and tasks required to be
carried out for software development.

3. Methods
 Software Engineering- Layered technology
• Methods encompass broad array of tasks including
communication, requirement analysis, design modelling,
program construction, testing and support

4. Tools
• S/w engg tools provide automated / semi-automated support for
the process and the methods.
• Software products that aid software engineers in developing,
managing, and maintaining software projects efficiently. These
tools are at the top layer, building on the foundational layers of
 The Software Process

• A process is a collection of activities, actions, and tasks that are performed

when some work product is to be created.
• An activity (ex – communication with stakeholders) strives to achieve a
broad objective with which software engineering is to be applied.
• An action encompasses a set of tasks that produce a major work (ex –
architectural design model).
• A task focuses on a small, but well-defined objective that produces a
tangible outcome (ex – unit testing).
 The Software Process Framework

Comprises of: --- Generic process framework

--- Umbrella Activities

A generic process framework for software engineering encompasses five activities that are
applied repeatedly through a number of project iterations:
Communication
Engage with customers and stakeholders to understand objectives and gather requirements
for software features and functions.
Planning
Create a project plan to outline tasks, risks, resources, and the schedule needed to complete
the software engineering work.
 The Software Process

• Modeling
Build models to better understand software requirements and design solutions that meet
those requirements.
• Construction
Generate code (manually or automatically) and conduct testing to identify and correct
errors in the code.
• Deployment
Deliver the software to the customer, who provides feedback after evaluating the product.
 The Software Process

SE process framework activities are complemented by Umbrella Activities:

• Software Project Tracking and Control
Monitor project progress and adjust to maintain the schedule according to the plan.
• Risk Management
Identify and evaluate risks that could impact the project's outcome or product quality
• Software Quality Assurance
Define and execute activities to ensure the quality of the software product.
• Technical Reviews
Evaluate engineering work products to detect and remove errors before progressing to the
next activity.
 The Software Process

• Measurement
defines and collects process, project and product measures to deliver s/w that meets
stakeholders’ needs
• Software Configuration Management
Manage changes throughout the software process to control their impact.
• Reusability Management
Set criteria for reusing components and establish mechanisms to promote reuse.
• Work Product Preparation and Production
Prepare and produce work products like models, documents, logs, forms, and lists.
Software Engineering Practices

The Essence of Practice

1. Understand the problem (communication and

analysis).

2. Plan a solution (modeling and software design).

3. Carry out the plan (code generation).

4. Examine the result for accuracy (testing and quality

 Software Engineering Practices

The Essence of Practice

1. Understand the problem:
• Who has a stake in the solution to the problem? That is, who are the stakeholders?
• What are the unknowns?
• What data, functions, and features are required to properly solve the problem?
• Can the problem be compartmentalized? Is it possible to represent smaller problems that
may be easier to understand?
• Can the problem be represented graphically? Can an analysis model be created?
 Software Engineering Practices

The Essence of Practice

2. Plan a solution
• Have you seen similar problems before?
• Are there patterns that are recognizable in a potential solution?
• Is there existing software that implements the data, functions, and features that are
required?
• Has a similar problem been solved? If so, are elements of the solution reusable?
• Can subproblems be defined?
 Software Engineering Practices

The Essence of Practice

3. Carry out the plan
• Does the solution conform to the plan? Is source code traceable to the design
model?
• Is each component part of the solution provably correct?
• Have the design and code been reviewed, or better, have correctness proofs
been applied to the algorithm?
 Software Engineering Practices

The Essence of Practice

4. Examine the result for accuracy
• Is it possible to test each component part of the solution? Has a reasonable
testing strategy been implemented?
• Does the solution produce results that conform to the data, functions, and
features that are required?
• Has the software been validated against all stakeholder requirements?
 Software Engineering General Principles

• The First Principle: The Reason It All Exists

A software system exists to provide value to its users; every decision should be

made to ensure this value.

• The Second Principle: KISS (Keep It Simple, Stupid!)

Design should prioritize simplicity without sacrificing essential features.

• The Third Principle: Maintain the Vision

A clear vision is crucial for the successful execution of a software project

 Software Engineering Principles
• The Fourth Principle: What You Produce, Others Will Consume
Design and implement software with the understanding that others will need to comprehend
and use it.
• The Fifth Principle: Be Open to the Future
Build adaptable systems that can accommodate future changes and have a long lifetime.
• The Sixth Principle: Plan Ahead for Reuse
Reuse code and designs to save time and effort, leveraging the benefits of object-oriented
technologies.
• The Seventh Principle: Think!
Prioritize thoughtful planning before action to improve outcomes and learn how to do it
right.
 Software Myths
Software myths— erroneous beliefs about software and the process that is used to build
it—can be traced to the earliest days of computing.
 Management Myths
 Customer Myths
 Practitioner’s Myths

• Management Myths

Myth: "We have a standards book for software development, so my team has all they need."

Reality: The book might exist, but often it's outdated, unused, incomplete, and not adapted to

modern practices or fast delivery while ensuring quality.

 Software Myths
Management Myths
Myth: If we get behind schedule, we can add more programmers and catch up (sometimes
called the “Mongolian horde” concept).
Reality: Software development is not a mechanistic process like manufacturing. In the words
of Brooks [Bro95]: “adding people to a late software project makes it later.”

Myth: If I decide to outsource the software project to a third party, I can just relax and let
that firm build it.
Reality: If an organization does not understand how to manage and control software projects
internally, it will invariably struggle when it outsources software projects.
 Software Myths

• Customer Myths

Myth: A general statement of objectives is enough to start coding; details can be added
later.
Reality: Vague objectives lead to disaster; clear requirements require ongoing
communication between customer and developer.

Myth: Software requirements continually change, but change can be easily accommodated
because software is flexible.
Reality: It is true that software requirements change, but the impact of change varies with
the time at which it is introduced. When requirements changes are requested early (before
design or code has been started), the cost impact is relatively small. However, as time
passes, the cost impact grows rapidly—resources have been committed, a design framework
has been established, and change can cause upheaval that requires additional resources and
major design modification.
 Software Myths

Practitioner’s Myths
Myth: Once we write the program and get it to work, our job is done.
Reality: Someone once said that “the sooner you begin ‘writing code,’ the
longer it’ll take you to get done.” Industry data indicate that between 60 and 80
percent of all effort expended on software will be expended after it is delivered
to the customer for the first time.

Myth: Until I get the program “running” I have no way of assessing its quality.
Reality: One of the most effective software quality assurance mechanisms can
be applied from the inception of a project—the technical review. Software
reviews are a “quality filter” that have been found to be more effective than
testing for finding certain classes of software defects
 Software Myths

Practitioner’s Myths
Myth: The only deliverable work product for a successful project is the
working program.
Reality: A working program is only one part of a software configuration
that includes many elements. A variety of work products (e.g., models,
documents, plans) provide a foundation for successful engineering and,
more important, guidance for software support.

Myth: Software engineering will make us create voluminous and

unnecessary documentation and will invariably slow us down.
Reality: Software engineering is not about creating documents. It is
about creating a quality product. Better quality leads to reduced rework.
And reduced rework results in faster delivery times.
Module 1 - Chapter 2

Process Models
A Generic Process Model
• Software Process Framework

• Process flow

• Defining a Framework Activity

• Identifying a Task Set

• Process Patterns
A Generic Process Model
• A generic process framework for software engineering defines five
framework activities—communication, planning, modeling, construction,
and deployment.
• In addition, a set of umbrella activities—project tracking and control, risk
management, quality assurance, configuration management, technical
reviews, and others—are applied throughout the process.
• Process flow—describes how the framework activities and the actions and
tasks that occur within each framework activity are organized with respect
to sequence and time.
A Generic Process Model

The software process is represented

schematically in following figure.
A Generic Process Model – Process flow
 A Generic Process Model – Process flow
• A linear process flow executes each of the five framework activities in sequence,
beginning with communication and culminating with deployment (Figure 2.2a).
• An iterative process flow repeats one or more of the activities before proceeding to
the next (Figure 2.2b).
• An evolutionary process flow executes the activities in a “circular” manner. (Figure
2.2c). Each circuit through the five activities leads to a more complete version of the
software.
• A parallel process flow (Figure 2.2d) executes one or more activities in parallel with
other activities (e.g., modeling for one aspect of the software might be executed in
parallel with construction of another aspect of the software)
A Generic Process Model
Defining a Framework Activity
What actions are appropriate for a framework activity, given the nature of the problem to be
solved, the characteristics of the people doing the work, and the stakeholders who are
sponsoring the project?

For a small software project, the communication activity  phone call with the appropriate
stakeholder. Therefore, the only necessary action is phone conversation, and the work tasks
(the task set) that this action encompasses are:
1. Make contact with stakeholder via telephone.
2. Discuss requirements and take notes.
3. Organize notes into a brief written statement of requirements.
4. E-mail to stakeholder for review and approval.

For a large project: inception, elicitation, elaboration, negotiation, specification, and

validation. Each of these software engineering actions would have many work tasks and a
number of distinct work products
 A Generic Process Model
• Identifying a Task Set: Choose a task set that best accommodates the needs of the project
and the characteristics of your team.
• A task set defines the actual work to be done to accomplish the objectives of a software
engineering action. Exs – work tasks, work products, quality assurance points, and project
milestones
For a small, relatively simple project, the task set for requirements gathering:
1. Make a list of stakeholders for the project.
2. Invite all stakeholders to an informal meeting.
3. Ask each stakeholder to make a list of features and functions required.
4. Discuss requirements and build a final list.
5. Prioritize requirements.
6. Note areas of uncertainty.
A Generic Process Model
• Process Pattern A process pattern describes a process-related problem that is
encountered during software engineering work, identifies the environment in which the
problem has been encountered, and suggests one or more proven solutions to the
problem.
• Patterns can be defined at any level of abstraction – Pbm & Sol for Process Model /
Framework activity / Action / Task
• Template for describing a Process pattern:
• Pattern Name - Ex- TechnicalReview
• Forces – environment in which the pattern is encountered; issues
• Pattern Type
A Generic Process Model

• Process pattern types-

 Stage patterns — defines a problem associated with a framework activity for the
process; stage pattern incorporates multiple task patterns.
Ex – EstablishingCommunication  RequirementsGathering
& others
 Task patterns — defines a problem associated with a software engineering action

or work task and relevant to successful software engineering practice.

Ex - RequirementsGathering
 Phase patterns — define the sequence of framework activities that occur with
Initial context. Describes the conditions under which the pattern
applies prior to the initiation of the pattern. Ex: Planning phase pattern
requires that Communication phase pattern is completed

Problem. The specific problem to be solved by the pattern.

Solution. Describes how to implement the pattern successfully.

Describes how initial process state is modified due to the pattern.

Resulting Context. Describes the conditions that will result once the
pattern has been successfully implemented.

Related Patterns. Provide a list of all process patterns that are directly
related to this one. This may be represented as a hierarchy or in some
other diagrammatic form.
Process Assessment And Improvement
• Existence of a s/w process  no guarantee that it will be delivered on time and
meets the needs
• Process itself needs to be assessed

Approaches:
• Standard CMMI Assessment Method for Process Improvement (SCAMPI)
• CMM-Based Appraisal for Internal Process Improvement (CBA IPI)
• SPICE—The SPICE (ISO/IEC15504) standard
• ISO 9001:2000 for Software
Process Assessment And Improvement
 Process Assessment And Improvement
• A number of different approaches to software process assessment and improvement have

been proposed over the past few decades:

 Standard CMMI Assessment Method for Process Improvement (SCAMPI) — provides a

five step process assessment model that incorporates five phases: initiating, diagnosing,

establishing, acting and learning. uses the SEI CMM as the basis for the assessment.

 CMM-Based Appraisal for Internal Process Improvement (CBA IPI)—provides a

diagnostic technique for assessing the relative maturity of a software organization; uses the

SEI CMM as the basis for the assessment.

Process Assessment And Improvement

 SPICE—The SPICE (ISO/IEC15504) standard defines a set of requirements for software

process assessment. The intent of the standard is to assist organizations in developing an

objective evaluation of the efficacy of any defined software process.

 ISO 9001:2000 for Software—a generic standard that applies to any organization that wants

to improve the overall quality of the products, systems, or services that it provides. Therefore,

the standard is directly applicable to software organizations and companies

Prescriptive Process Models
• Prescriptive process models define a prescribed set of process elements

and work flow for each project.

• Process elements – F/w activities, SE actions, tasks, work products, SQA

points

• Each process model also prescribes a process flow (work flow)  how

process elements are interrelated to one another.

Prescriptive Process Models

 The Waterfall Model

 Incremental Process Models

 Evolutionary Process Models

 Concurrent Models

 A final word on Evolutionary Processes

The Waterfall Model / Classic Life Cycle
 Requirements are well-understood. Work flows from Communication through
deployment in a linear fashion. 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.
 A variation in the representation of the waterfall model is called the V-model.

Fig: Waterfall Model

The Waterfall Model
Fig: V model
The Waterfall Model
 As a software team moves down the left side of the V, basic problem requirements are
refined into progressively more detailed and technical representations of the problem
and its solution.
 Once code has been generated, the team moves up the right side of the V, essentially
performing a series of tests (quality assurance actions) that validate each of the models
created as the team moved down the left side.
 In reality, there is no fundamental difference between the classic life cycle and the V-
model. The V-model provides a way of visualizing how verification and validation
actions are applied to earlier engineering work
The Waterfall Model
Advantages of waterfall model
• This model works for small projects because the requirements are understood very well.
• The waterfall model is simple and easy to understand, implement, and use.
• All the requirements are known at the beginning of the project, hence it is easy to manage.

Disadvantages of the waterfall model

• Real projects rarely follow the sequential flow that the model proposes.
• It is often difficult for the customer to state all requirements explicitly.
• The customer must have patience. A working version of the program(s) will not be available until late in the
project time span. The problems with this model are uncovered, until the software testing.
• This model is not good for complex and object oriented projects.
• “blocking states” – team members must wait for other team members to complete dependent tasks.
Incremental Process Models
• The incremental model combines elements of linear and parallel process flows; it
applies linear sequences in a staggered fashion as calendar time progresses.
• Tasks are divided into small, manageable segments. These segments are then completed
in a step-by-step manner, with each segment starting after the previous one has
progressed, continuing this pattern over time.
• Each linear sequence produces deliverable “increments” of the software.
• When an incremental model is used, the first increment is often a core product. That is,
basic requirements are addressed but many supplementary features remain undelivered.
The core product is used by the customer for detailed evaluation.
Incremental Process Models
• As a result of use and/or evaluation, a plan is developed for the next increment.

• The plan addresses the modification of the core product to better meet the needs of the

customer and the delivery of additional features and functionality.

• This process is repeated following the delivery of each increment, until the complete

product is produced.

• The incremental process model focuses on the delivery of an operational product with each

increment. Early increments are stripped-down versions of the final product, but they do

provide capability that serves the user and also provide a platform for evaluation by the user
Incremental Process Models

Fig: Incremental Process model

Incremental Process Models

For example, word-processing software:

first increment – basic file management, editing, and document production functions

second increment – more sophisticated editing and document production capabilities

third increment – spelling and grammar checking

fourth increment – advanced page layout capability

Incremental Process Models
Advantages of incremental model
 This model is flexible because the cost of development is low and initial product delivery is faster.
 It is easier to test and debug during the smaller iteration.
 The working software generates quickly and early during the software life cycle.
 The customers can respond to its functionalities after every increment.
 Useful when staffing is unavailable for a complete implementation by the business deadline
Disadvantages of the incremental model
 The cost of the final product may cross the cost estimated initially.
 This model requires a very clear and complete planning before the whole system is broken into small
increments.
 The demands of customer for the additional functionalities after every increment causes problem
during the system architecture.
Evolutionary Process Models
Evolutionary models are iterative. They are characterized in a manner that enables you to
develop increasingly more complete versions of the s/w.
For example, in a simple database application,
 one cycle might implement the graphical user Interface (GUI),
 another cycle might implement the file manipulation,
 next cycle might implement the queries and
 last cycle may implement updates required.
Following are the evolutionary process models.
1. The prototyping model
2. The spiral model
3. Concurrent development model
Evolutionary Process Models
1. The Prototyping model
• A customer  general objectives but not identify detailed requirements
• In other cases, the developer concerns  unsure of the efficiency of an algorithm, the
adaptability of an OS, or the form that human-machine interaction should take.  a
prototyping paradigm may offer the best approach.
Although prototyping  stand-alone process model, it is more commonly used as a
technique that can be implemented within the context of any one of the process models
• 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.
Evolutionary Process Models
The Prototyping model
• The goal of the Prototyping model in software development is to have a basic outline or
plan (not detailed specifications) of what the software needs to do. It won't have all the
features or capabilities of the final product but serves as a starting point.
• Instead of getting into all the nitty-gritty details (like specific inputs and outputs), the
Prototyping model looks at the overall goals and functions that the software should
achieve.
• Developers create working programs rapidly to demonstrate key functions or
features. This helps in getting quick feedback and making improvements early on.
Evolutionary Process Models

The Prototyping model

The different phases of Prototyping model are:

1) Communication: In this phase, developer and customer meet and discuss the overall
objectives of the software.
2) Quick Plan : A prototyping iteration is planned quickly
Evolutionary Process Models
The Prototyping model

3) Modeling (“quick design”): A quick design focuses on a representation of

those aspects of the software that will be visible to end users (e.g., human interface
layout or output display formats).
4) The quick design leads to the construction of a prototype.
5) The prototype is deployed and evaluated by stakeholders, who provide
feedback that is used to further refine requirements. Iteration occurs as the
prototype is tuned to satisfy the needs of various stakeholders, while at the same
time enabling you to better understand what needs to be done.
Evolutionary Process Models
The Prototyping model- Advantages
• Prototype model need not know the detailed input, output, processes,
adaptability of operating system and full machine interaction.
• In the development process of this model users are actively involved.
• Errors are detected much earlier.
• Gives quick user feedback for better solutions.
• It identifies the missing functionality easily. It also identifies the confusing or
difficult functions.
Evolutionary Process Models
The Prototyping model- Disadvantages
• Stakeholders see what appears to be a working version of the software,
unaware that  the prototype is held together haphazardly, in the rush to get it
working  overall software quality or long-term maintainability.
• As a software engineer, you often make implementation compromises in
order to get a prototype working quickly. The less-than-ideal choice has now
become an integral part of the system.
• The client involvement is more and it is not always considered by the developer.
• It is a slow process because it takes more time for development.
Evolutionary Process Models

2. The Spiral model

• The spiral model is an evolutionary software process model that couples the iterative
nature of prototyping with the controlled and systematic aspects of the waterfall
model. It provides the potential for rapid development of increasingly more complete
versions of the software.
• Using the spiral model, software is developed in a series of evolutionary releases.
During early iterations, the release  model or prototype.
During later iterations  increasingly more complete versions of the engineered system
Evolutionary Process Models
The Spiral model
Evolutionary Process Models – The Spiral Model
• A spiral model is divided into a set of framework activities; Each of the framework activities
represent one segment of the spiral path.
• Activities are performed around the spiral in a clockwise direction, beginning at the center.
• Anchor point milestones—a combination of work products and conditions that are attained along
the path of the spiral.
• First circuit  development of a product specification;
• Subsequent passes  prototype development and then progressively more sophisticated versions
of the software.
• Each pass through the planning region results in adjustments to the project plan. Cost and
schedule are adjusted based on feedback derived from the customer after delivery. In addition, the
project manager adjusts the planned number of iterations required to complete the software.
Evolutionary Process Models
The Spiral model

Advantages
 It reduces high amount of risk.
 It is good for large and critical projects because of its iterative nature.
 It gives strong approval and documentation control.
 In spiral model, the software is produced early in the life cycle process.
Early iterations result in prototypes or initial versions of the software that can
be tested, validated, and demonstrated to stakeholders.
Evolutionary Process Models
The Spiral model
Disadvantages
 It can be costly to develop a software model.
 Complexity and Management Challenges.
 It is not used for small projects.
 Requires Highly Skilled Teams.
 Documentation Overhead.
 Inconsistent Risk Management Practices: If risk assessment is not conducted
rigorously at each iteration, the model’s benefits can be undermined.
Evolutionary Process Models
Aspect Prototype
Prototype Model Model VS SpiralSpiral
model Model

Eemphasizes risk management and iterative

Quickly create a working, simplified
development to address uncertainties, manage
Main Goal version of the software to gather user
risks, and progressively refine the software
feedback and validate requirements.
based on evolving requirements and feedback.

Focuses on creating prototypes to Combines iterative development with

Approach to
understand user requirements and refine systematic risk analysis and management at
Development
design through user feedback. each phase (spiral).
Less emphasis on comprehensive
Strong emphasis on documentation and
documentation, more on visual and
Documentation review at each iteration to ensure clear
functional prototypes to communicate
communication, traceability, and approval.
ideas.
Can be quicker and less costly in the Can be more time-consuming and expensive
Time and Cost early stages as it focuses on developing due to the detailed risk management and
simplified prototypes. iterative planning required.
The Concurrent Development Model
 The Concurrent Development Model
• The concurrent development model, sometimes called concurrent engineering, allows a s/w
team to represent iterative and concurrent elements of any of the process models.
Ex: modeling activity  s/w engineering actions: prototyping, analysis, and design.
• In the figure, the Modeling activity may be in any one of the states at any given time.
Similarly, other activities, actions, or tasks (e.g., communication or construction) can be
represented in an analogous manner. All software engineering activities exist concurrently
but reside in different states.
• Ex - The communication activity has completed its first iteration (not shown in the fig) and
exists in the awaiting changes state. The modeling activity (which existed in the inactive
state while initial communication was completed, now makes a transition into the under
development state.
• If the customer specifies the change in the requirement, then the modeling activity moves
from the under-development state into the awaiting changes state.
The Concurrent
• The concurrent Development
modeling Model
defines a series of events that will trigger transitions from state
to
state for each of the software engineering activities, actions, or tasks.
For example, during design (a major software engineering action that occurs during the
modeling activity), if an inconsistency in the requirements model is uncovered  generates

the event analysis model correction. This will trigger the requirements analysis action from
the done state into the awaiting changes state.
• Concurrent modeling is applicable to all types of software development and provides an
accurate picture of the current state of a project.
• Rather than confining software engineering activities, actions, and tasks to a sequence of
events, it defines a process network.
• Each activity, action, or task on the network exists simultaneously with other activities,
actions, or tasks.
• Events generated at one point in the process network trigger transitions among the states.
The concurrent development model
Advantages of the concurrent development model
 This model is applicable to all types of software development processes.
 It is easy for understanding and use.
 It gives immediate feedback from testing.
 It provides an accurate picture of the current state of a project.
Disadvantages of the concurrent development model
 It needs better communication between the team members. This may not be achieved all
the time.
 It requires to remember the status of the different activities.
 A Final Word on Evolutionary Processes
Computer software  continual change, tight time lines, customer–user satisfaction.
Evolutionary process models  these issues; they too have weaknesses:
• The first concern is that prototyping [and other more sophisticated evolutionary processes] poses a
problem to project planning because of the uncertain number of cycles required to construct the
product. Most project management and estimation techniques are based on linear layouts of
activities, so they do not fit completely.
• Second, evolutionary software processes do not establish the maximum speed of the evolution.
If the evolutions occur too fast  process will fall into chaos. If the speed is too low 
productivity is affected.
• Third, software processes should be focused on flexibility and extensibility rather than on high
quality. We should prioritize the speed of the development over zero defects. Extending the
development in order to reach high quality could result in a late delivery of the product, when the
opportunity niche has disappeared.
The intent of evolutionary models is to develop high-quality software in an iterative or incremental
manner. However, it is possible to use an evolutionary process to emphasize flexibility, extensibility,
and speed of development. The challenge for software teams and their managers is to establish a
proper balance between these critical project and product parameters and customer satisfaction.
Specialized Process Models
• Specialized process models are tailored versions of traditional software
development models designed to address specific types of projects,
particular project requirements, or unique development environments.

Types in Specialized process models:

1. Component based development (Promotes reusable components)
2. The formal methods model (Mathematical formal methods are backbone
here)
3. Aspect oriented software development (Uses crosscutting technology) .
Specialized Process Models
Component-Based Development:

• What is a Component?

• A component is like a building block of a software application. It's a piece of

software that does a specific job, like handling user input or managing data.

• A component is a modular, portable, replaceable, and reusable set of well-

defined functionality that encapsulates its implementation and exporting it as a

higher-level interface.
Specialized Process Models
Component-Based Development:
• Commercial off-the-shelf (COTS) software components, developed by vendors who offer
them as products, provide targeted functionality with well-defined interfaces that enable
the component to be integrated into the software that is to be built.
• The component-based development model incorporates many of the characteristics of
the spiral model and it is evolutionary in nature requiring Iterative Development
• The component-based development model constructs applications from prepackaged
software components.
• In Component-Based Development (CBD), the modeling and construction activities focus
on identifying and designing components that serve as the building blocks of the
software system.
Specialized Process Models
Component-Based Development:

Regardless of the technology that is used to create the components, the

component-based development model incorporates the following steps

1. Available component-based products are researched and evaluated for the

application domain in question.

2. Component integration issues are considered.

Specialized Process Models
Component-Based Development:

3. A software architecture is designed to accommodate the components.

4. Components are integrated into the architecture.

5. Comprehensive testing is conducted to ensure proper functionality.

The component-based development model leads to software reuse, and

reusability provides software engineers with several measurable benefits.

Specialized Process Models
Component-Based Development: E-commerce Application

1. Component Identification
•User Management Component: Handles user registration, authentication, and profile
management.
•Product Catalog Component: Manages product listings, categories, and search functionality.
•Order Processing Component: Handles order creation, payment processing, and order
tracking.
•Inventory Management Component: Manages stock levels, inventory updates, and supplier
interactions.
•Payment Gateway Component: Processes payments and handles different payment methods.
Specialized Process Models
Component-Based Development: E-commerce Application

2. Component Specification: By defining clear interfaces for each component, we establish

contracts that specify how other components or systems can interact with them. This clarity
reduces ambiguity and promotes seamless integration.

3. Component Testing and Verification: Component interfaces serve as the basis for testing
and verification. Unit tests can be written to validate the behavior of each component based on
its interface, ensuring that it meets the specified requirements.
Specialized Process Models
The Formal Methods Model

• The formal methods model encompasses a set of activities that leads to

formal mathematical specification of computer software.

• Formal methods enable you to specify, develop, and verify a computer-

based system by applying a rigorous, mathematical notation.

Specialized Process Models
The Formal Methods Model

• A variation on this approach  clean room software engineering.

• When formal methods are used during development, they provide a

mechanism for eliminating many of the problems that are difficult to

overcome using other software engineering paradigms.

• Ambiguity, incompleteness, and inconsistency can be discovered and

corrected more easily, but through the application of mathematical analysis.

Specialized Process Models
The Formal Methods Model

• When formal methods are used during design, they serve as a basis for

program verification and therefore enable you to discover and correct

errors that might otherwise go undetected.

• Although not a mainstream approach, the formal methods model offers the

promise of defect-free software.

Specialized Process Models
The Formal Methods Model : Example

Imagine a turnstile gate at a subway station that controls access based on two actions:
inserting a coin and pushing the turnstile.
States:
1.Locked: The turnstile is locked and requires a coin to unlock.
2.Unlocked: The turnstile is unlocked and can be pushed to allow entry.

Inputs:
3.Insert Coin: An action that transitions the turnstile from Locked to Unlocked.
4.Push: An action that transitions the turnstile from Unlocked to Locked.
Specialized Process Models
The Formal Methods Model : Example

FSM for the turnstile: Finite State Machine (FSM) is a mathematical model used to
represent systems with a finite number of states.
FSM Representation:
1.States: Locked, Unlocked
2.Inputs: Coin, Push
3.Initial State: Locked
4.Transitions:
1. From Locked to Unlocked on Coin 2.From Unlocked to Locked on Push
Specialized Process Models
The Formal Methods Model : Example

Benefits of Using FSM:

1.Clarity: FSM provides a clear and precise way to describe the behavior of a system with
a finite number of states.
2.Simplicity: FSMs are relatively simple to understand and implement.
3.Predictability: The behavior of the system is predictable and can be easily analyzed.
Specialized Process Models
The Formal Methods Model
Draw Backs:

• The development of formal models is currently quite time consuming and

expensive.
• Because few software developers have the necessary background to apply
formal methods, extensive training is required.
• It is difficult to use the models as a communication mechanism for
Technically unsophisticated customers.
Specialized Process Models
Specialized Process Models
Aspect-Oriented Software Development (AOSD) or Aspect-Oriented Programming (AOP)

• AOSD defines “aspects” that express customer concerns that cut across multiple system

functions, features, and information  crosscutting concerns.

• Aspectual requirements define those crosscutting concerns that have an impact across the

software architecture.

• Aspect-oriented software development (AOSD), / Aspect-Oriented Programming

(AOP), is a relatively new software engineering paradigm that provides a process and

methodological approach for defining, specifying, designing, and constructing “aspects.”

Specialized Process Models
Aspect-Oriented Component Engineering (AOCE) – Grundy discusses AOCE:
• AOCE uses a concept of horizontal slices through vertically-decomposed software
components  called “aspects,” to characterize cross-cutting functional and non-functional
properties of components.
• Common, systemic aspects include user interfaces, collaborative work, distribution,
persistency, memory management, transaction processing, security, integrity and so on.
• Components may provide or require one or more “aspect details” relating to a particular
aspect, such as a viewing mechanism, extensible affordance and interface kind (user
interface aspects); event generation, transport and receiving (distribution aspects); data
store/retrieve and indexing (persistency aspects); authentication, encoding and access rights
(security aspects); transaction atomicity, concurrency control and logging strategy
(transaction aspects); and so on.
• Each aspect detail has a number of properties, relating to functional and/or non-functional
characteristics of the aspect detail.
 Specialized Process Models
Aspect-Oriented Software Development : E-Commerce System :Example

Components (Vertical Slices):

Order Processing Component: Manages orders, from creation to fulfillment.
Inventory Management Component: Keeps track of stock levels and updates inventory.
Customer Management Component: Manages customer information and interactions.

Aspects (Horizontal Slices):

Logging Aspect: Records information about method calls and system events for auditing and
debugging.
Security Aspect: Ensures that only authorized users can perform certain actions.
Transaction Management Aspect: Manages database transactions to ensure consistency and integrity.
 The Unified Process Phases
An attempt to draw on the best features
and characteristics of traditional software
process models, but characterize them in
a way that implements many of the best
principles of agile software development.

UML—a unified modeling language that

contains a robust notation for the
modeling and development of object-
oriented systems.

Unified Process - a framework for object-

oriented software engineering using
UML.
 The Unified Process Phases
1) Inception phase – This encompasses both customer communication and planning activities.
Communication - collaborating with stakeholders  business requirements for the s/w; a rough
architecture for the system; plan for the iterative, incremental nature of the ensuing project
Fundamental business requirements  set of preliminary use cases that describe which features and
functions each major class of users desires.
Planning  identifies resources, assesses major risks, defines a schedule, and establishes a basis for the
phases that are to be applied as the software increment is developed.

2) Elaboration phase - encompasses the planning and modeling activities of the generic process model.
Preliminary use cases  refined and expanded.
Architectural representation is expanded to include five different views of the software—the use case
model, the requirements model, the design model, the implementation model, and the deployment
model.
In some cases, elaboration creates an “executable architectural baseline” [Arl] that represents a
“first cut” executable system. The architectural baseline demonstrates the viability of the architecture
but does not provide all features and functions required to use the system. In addition, the plan is
carefully reviewed at the culmination of the elaboration phase to ensure that scope, risks, and delivery
dates remain reasonable. Modifications to the plan are often made at this time.
 The Unified Process Phases
3) Construction phase – identical to the construction activity defined for the generic software process.
Using the architectural model as input, the construction phase develops or acquires the software
components that will make each use case operational for end users. To accomplish this, requirements and
design models that were started during the elaboration phase are completed to reflect the final version of
the software increment. All necessary and required features and functions for the software increment are
then implemented in source code. As components are being implemented, unit tests are designed and
executed for each. In addition, integration activities (component assembly and integration testing) are
conducted. Use cases are used to derive a suite of acceptance tests that are executed prior to the initiation
of the next UP phase.

4) Transition phase – encompasses the latter stages of the generic construction activity and the first part
of the generic deployment (delivery and feedback) activity. Software is given to end users for beta testing
and user feedback reports both defects and necessary changes. In addition, the software team creates the
necessary support information (e.g., user manuals, troubleshooting guides, installation procedures) that is
required for the release. At the conclusion of the transition phase, the software increment becomes a usable
software release.
 The Unified Process Phases
5) Production phase – coincides with the deployment activity of the generic process.
During this phase, the ongoing use of the software is monitored, support for the
operating environment (infrastructure) is provided, and defect reports and requests for
changes are submitted and evaluated.
It is likely that at the same time the construction, transition, and production phases are
being conducted, work may have already begun on the next software increment. This
means that the five UP phases do not occur in a sequence, but rather with staggered
concurrency. A software engineering workflow is distributed across all UP phases. In
the context of UP, a workflow is analogous to a task set. That is, a workflow identifies
the tasks required to accomplish an important software engineering action and the work
products that are produced as a consequence of successfully completing the tasks.
Personal and Team Process Models
If a software process model has been developed at a corporate or organizational
level  effective only if accepted by the project team

Alternatively, the team itself can create its own process, and at the same time meet
the narrower needs of individuals and the broader needs of the organization

• “Personal Software Process” (PSP)

• and/or a “Team Software Process.” (TSP}
Personal Software Process (PSP)
PSP emphasizes personal measurement of both the work product that is produced and the
resultant quality of the work product. Also PSP makes the practitioner responsible for project
planning (e.g., estimating and scheduling) and empowers the practitioner to control the quality
of all software work products that are developed. The PSP model defines five framework
activities:
• Planning. This activity isolates requirements and develops both size and resource estimates.
defect estimate; metrics are recorded on worksheets or templates; development tasks; project
schedule
• High-level design. External specifications; component design; Prototypes; issues recorded
and tracked
• High-level design review. Formal verification methods are applied; Metrics are maintained
• Development. The component-level design is refined and reviewed. Code is generated,
reviewed, compiled, and tested. Metrics are maintained for all important tasks and work
results.
• Postmortem. Using the measures and metrics collected, the effectiveness of the process is
determined. They provide guidance for modifying the process to improve its effectiveness.
 Team Software Process (TSP)
The goal of TSP is to build a “self directed” project team that organizes itself to produce
high-quality software.
Objectives for TSP:
• Build self-directed teams that plan and track their work, establish goals, and own
their processes and plans. These can be pure software teams or integrated product
teams (IPTs) of 3 to about 20 engineers.
• Show managers how to coach and motivate their teams and how to help them
sustain peak performance.
• Accelerate software process improvement by making *CMM Level 5 behaviour normal and
expected. *Capability Maturity Model (CMM), a measure of the effectiveness of a software process
• Provide improvement guidance to high-maturity organizations.
• Facilitate university teaching of industrial-grade team skills.
Team Software Process (TSP)

• TSP defines the following framework activities: project launch, high-level design,
implementation, integration and test, and postmortem.

• TSP makes use of scripts, forms, and standards. “Scripts” define specific process activities
(i.e., project launch, design, implementation, integration and system testing, postmortem) and
other more detailed work functions (e.g., development planning, requirements development,
software configuration management, unit test) that are part of the team process.

• TSP recognizes that the best software teams are self-directed. Team members set project
objectives, adapt the process to meet their needs, control the project schedule, and through
measurement and analysis of the metrics collected, work continually to improve the team’s
approach to software engineering.
Summary
•Prescriptive Models: Models like the waterfall and V models provide structured and
orderly approaches to software development, performing generic activities such as
communication, planning, modeling, construction, and deployment.

•Incremental and Evolutionary Models: Incremental models are iterative and produce

working versions rapidly. Evolutionary models, like prototyping and the spiral model,

accommodate change and produce incremental work products quickly, covering the full

range of software activities from concept to maintenance.

Summary
•Concurrent Models: The concurrent process model handles iterative and
concurrent elements.

•Specialized models: Include component-based (focus on reuse), formal

methods (mathematical approach), and aspect-oriented (addressing crosscutting
concerns).