Software Engineering & Project

Management

21CS61
 Modules
M1: Software and Software Engineering & Process Models

M2: Understanding Requirements & Requirements Modeling Scenarios,

Information and Analysis classes

M3: Agile Development & Principles that guide practice

M4: Introduction to Project Management

M5: Software Quality

 Course Outcomes
CO 1. Understand the activities involved in software engineering and analyze the role of
various process models.

CO 2. Explain the basics of object-oriented concepts and build a suitable class model using
modelling techniques.

CO 3. Describe various software testing methods and to understand the importance of agile
methodology and DevOps.

CO 4. Illustrate the role of project planning and quality management in software

development.

CO 5. Understand the importance of activity planning and different planning models.s

 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: Defining a framework

activity, Prescriptive Process Models: The Waterfall Model, Incremental Process
Model, Evolutionary Process Model, The Unified Process, What is an Agile
Process? XP Process.
 Module 1 - Chapter 1

Software and Software Engineering

 Introduction to Software Engineering
What is Software Engineering?

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

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

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

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

build, maintain, and improve frameworks, processes, etc.
 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, information communication,
and creating other programs.

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
Software is:

• 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 developed or engineered, it is not manufactured in

the classical sense

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

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

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.
 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(sorting, searching).
Application within this area include robotics, pattern recognition, game
playing.

• Engineering and scientific software- 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 is supported integrated
with remote database and business applications.
 Software-New Categories

[Link]-World Computing: With wireless networks growing, software engineers

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

[Link]: The web is becoming a computing hub, so engineers must create

simple and useful apps for people worldwide.

[Link] 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 are essential to 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.
 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:
• Network-Intensive: WebApps are accessed over networks like the Internet or corporate
Intranets.
• Concurrency: Many users can use WebApps 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

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

in order to obtain economically 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:
• Correctness of the functions required to be performed by the
software.
• Integrity i.e. providing security so that the unauthorized user
cannot access information or data.
• Usability i.e. the efforts required to use or operate the
software.
 Software Engineering- Layered technology
The layered technology consists of:
2. Process
• It is the base layer or foundation layer for the software
engineering. It covers all activities, actions and tasks required
to be carried out for software development.
3. Methods
• It provides the technical way to implement the software. It
includes collection of tasks starting from communication,
requirement analysis, analysis and design modelling, program
 Software Engineering- Layered technology
The layered technology consists of:
4. Tools
• 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 methods, process, and quality focus.
 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 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 .
• A task focuses on a small, but well-defined objective that produces a
tangible outcome.
 The Software Process
• A generic process framework for software engineering encompasses five activities:
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.
Modeling
Build models to better understand software requirements and design solutions that meet
those requirements.
 The Software Process
• 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.
• 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
 The Software Process
• 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.
• Measurement
Collect process, project, and product metrics to help deliver software that meets
stakeholders' needs.
• Software Configuration Management
Manage changes throughout the software process to control their impact.
The Software Process

• 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:
• 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 Principles

• 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 Myth

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
• Customer Myth

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.

• Practitioner’s myths

Myth: Once we write the program and get it to work, our job is done.

Reality: Most of the effort (60-80%) occurs after the initial delivery due to maintenance

and updates.
 How it all starts

Every software project starts because of a business need, like fixing defects, adapting legacy
systems, enhancing existing applications, or creating new products or services. Initially, these
needs are often discussed informally. Here's a simple conversation illustrating this concept:
Scene: Meeting room at CPI Corporation
Participants:
Joe: Executive VP
Mal: Senior Manager, Product Development
Lisa: Marketing Manager
Lee: Engineering Manager
 How it all starts
Conversation:
Joe: What's this about a universal wireless box?
Lee: It's a small device that can connect to various sensors wirelessly. It could lead to a new
generation of products.
Mal: Sales are flat, so we need something new. Lisa and I have ideas for a big product line.
Lisa: We call them "SafeHome," a new generation of home management products like
security, surveillance, and appliance control.
Lee: The hardware is feasible, and the software is manageable.
Joe: How big is this opportunity?
Mal: With the right pricing, it could bring in $30-40 million in the second year.
Joe: Let's take it to the next level.
 Summary: Software
Software Importance:
[Link] is crucial to the evolution of computer systems and products,
becoming one of the most significant global technologies.
[Link] the past 50 years, software has evolved from a specialized problem-
solving tool to a standalone industry.
Challenges:
Despite advancements, delivering high-quality software on time and within
budget remains a challenge.
 Summary: Software
Legacy Software Issues:
Legacy software continues to pose significant challenges to those who
maintain it.
Changing Nature of Software:
[Link]-based systems and applications have evolved.
[Link] applications face new challenges as they adapt to various platforms.
[Link] computing is transforming how software is delivered and operated.
[Link] line software provides potential efficiencies in how software is
built.
Module 1 - Chapter 2

Process Models
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.
• This aspect—called 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
• 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.
• A list of the task to be accomplished.
• A list of the work products to be produced.
• A list of the quality assurance filters to be applied.
 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.
• Process pattern types-
 Stage patterns — defines a problem associated with a framework activity for the
process.
 Task patterns — defines a problem associated with a software engineering action or
work task and relevant to successful software engineering practice
 Phase patterns — define the sequence of framework activities that occur with the
process, even when the overall flow of activities is iterative in nature..
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.

 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 a

predictable process workflow.

• Prescriptive software models are those which prescribe the components which

make up a software model, including the activities, the inputs and outputs of the

activities, how quality assurance is performed, how change is managed.

Prescriptive Process Models

 The Waterfall Model

 Incremental Process Models

 Evolutionary Process Models

 Concurrent Models

 Specialized process models.

The Waterfall Model
 The waterfall model is a breakdown of project activities into linear sequential phases, where

each phase depends on the deliverables of the previous one and corresponds to a

specialization of tasks. The approach is typical for certain areas of engineering design.

 A variation in the representation of the waterfall model is called the V-mode.

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.

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

• The problems with this model are uncovered, until the software testing.

• The amount of risk is high.

• This model is not good for complex and object oriented projects.
 Incremental Process Models
• The incremental model combines elements of linear flows(waterfall) applied in iterative fashion.

• In incremental model 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
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.
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.
 The planning of design is required 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 process model resembles the iterative enhancement model. The
same phases are defined for the waterfall model occurs here in a cyclical
fashion.

• This model differs from the iterative enhancement model in the sense that this
does not require a useful product at the end of each cycle.

• In evolutionary development, requirements are implemented by category

rather than by priority.
Evolutionary Process Models
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
• 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.

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

• 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.
Evolutionary Process Models
The Prototyping model

• The prototype itself is a simple, working version of the software. It won't

have all the features or capabilities of the final product but serves as a

starting point.

• 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
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 design: Quick design is implemented when requirements are known. It includes only
the important aspects like input and output format of the software. It helps to construct a
prototype.
Evolutionary Process Models
The Prototyping model
3. Modeling quick design: This phase gives the clear idea about the development of software
because the software is now built. It allows the developer to better understand the exact
requirements.

4. Construction of prototype: The prototype is evaluated by the customer itself.

5. Deployment, delivery, feedback: If the user isn't happy with the current prototype, it's
refined based on their needs. This refining process is repeated until all user requirements are
met. Once users approve the developed prototype, the system is then built based on this final
version.
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.
• The development process is the best platform to understand the system by the
user.
• Errors are detected much earlier.
• Gives quick user feedback for better solutions.
• It identifies the missing functionality easily. It also identifies the confusing or
Evolutionary Process Models
The Prototyping model- Disadvantages

• The client involvement is more and it is not always considered by the

developer.
• It is a slow process because it takes more time for development.
• Many changes can disturb the rhythm of the development team.
• It is a thrown away prototype when the users are confused with it.
Evolutionary Process Models

2. The Spiral model

• The Spiral model is iterative in nature so, the model allows for risk assessment and
management in each cycle.
• In contrast, the Waterfall model does not have built-in mechanisms for risk management
once a phase is completed.
• It helps in creating software step by step.
• If risks are identified during analysis, the model suggests and implements alternative
solutions.
• This model combines elements of prototyping and sequential (or waterfall) models.
Evolutionary Process Models

2. The Spiral model

The spiral model has four phases:
• Objective setting:This includes identifying the key objectives, determining the project
requirements, and understanding the constraints and priorities.

• Risk Assessment and reduction: This phase focuses on identifying potential risks that
could affect the project's success. Once the risks are identified, strategies are developed
to mitigate or eliminate them.
Evolutionary Process Models

2. The Spiral model

The spiral model has four phases:
• Development and validation:During this phase, the actual development of the product
takes place based on the objectives and plans set in earlier phases.

• Planning:This includes refining the project plan, scheduling, and resource allocation for
the next iteration.
Evolutionary Process Models

2. The Spiral model

Evolutionary Process Models

The Spiral model

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

Emphasizes 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 communication activity has completed in the first iteration and exits
in the awaiting changes state.
• The modeling activity completed its initial communication and then go to
the underdevelopment state.
• If the customer specifies the change in the requirement, then the modeling
activity moves from the under-development state into the awaiting change
state.
• The concurrent process model activities moving from one state to another
state.
The concurrent development model
•From Under Development to Awaiting Changes:
An activity might move to this state if it has been initially completed but needs to be revisited
for modifications.
•From Awaiting Changes to Under Development:
If stakeholders provide feedback or new requirements, the activity can move back to the
underdevelopment state to implement these changes.
•From Under Development to Awaiting Change:
If, during development, it becomes clear that a change is needed based on new requirements
or issues identified, the activity can move to the awaiting change state.
• Baselined state:
The baselined state works as a controller in the concurrent development model.
The concurrent development model
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.
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.

• These models help optimize the development process, improve efficiency,

enhance quality, and ensure the successful delivery of software products.

Specialized Process Models
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

Specialized Process Models
Component-Based Development:

• The component-based development model incorporates many of the

characteristics of the spiral model and it is evolutionary in nature.

• Iterative Development Risk Management

• Prototyping Progressive Refinement

• Flexibility and Adaptation Stakeholder Involvement

• Testing
Specialized Process Models
Component-Based 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, called 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:
[Link]: The turnstile is locked and requires a coin to unlock.
[Link]: The turnstile is unlocked and can be pushed to allow entry.

Inputs:
[Link] Coin: An action that transitions the turnstile from Locked to Unlocked.
[Link]: 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:
[Link]: Locked, Unlocked
[Link]: Coin, Push
[Link] State: Locked
[Link]:
1. From Locked to Unlocked on Coin [Link] Unlocked to Locked on Push
Specialized Process Models
The Formal Methods Model : Example

FSM for the turnstile:

Benefits of Using FSM:

[Link]: FSM provides a clear and precise way to describe the behavior of a system with
a finite number of states.
[Link]: FSMs are relatively simple to understand and implement.
[Link]: 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 defines “aspects” that express customer concerns that cut across multiple system

functions, features, and information.

• When concerns cut across multiple system functions, features, and information, they are

often referred to as crosscutting concerns.

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

the software architecture.

Specialized Process Models
Aspect-Oriented Software Development : Example

Simple Account Management

Imagine we have a simple account management system where we want to log every time an
account is accessed.

•Core Business Logic: The Account class contains methods for depositing, withdrawing, and
checking the balance.
•Logging Aspect: The Logging Aspect uses AspectJ annotations to define a pointcut for all
methods of interest (deposit, withdraw, and getBalance) and a before advice to log a message
before these methods execute.
•Separation of Concerns: The logging logic is separated from the business logic, making the
code cleaner and easier to maintain.
Specialized Process Models
Aspect-Oriented Software Development : Example

Simple Account Management

Benefits
[Link] of Concerns: Logging is handled separately from business logic.
[Link]: The logging aspect can be easily modified or extended without changing the core
application code.
[Link]: The logging aspect can be reused across different applications or components.
Specialized Process Models
Aspect-Oriented Software Development
• Aspect-oriented software development (AOSD), often referred to as 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.”

• John Grundy explains more about something he calls aspect-oriented component

engineering (AOCE). In AOCE, software parts are divided vertically, and "aspects" are
like horizontal slices that go through these parts. These slices help identify both the
main functions and extra features of the components.
 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.
summary
•Generic Process Model: A software engineering process model includes
framework activities, actions, and tasks organized in a sequential flow.

•Variety of Models: Different process models describe different process flows,

organizing the same set of activities, actions, and tasks in various ways.

•Process Patterns: These are solutions to common problems encountered

during the software process, helping streamline the development process.
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).