Chapter Four

Software Development
Methodologies and Paradigms
 Contents
• Software Engineering Practice

• Essence of Practice

• Core Principles of Software Engineering

• Types of Practice

• Software Engineering Methodologies

• Software Development Paradigm

 Introduction
• Software engineering (SE) is concerned with developing and maintaining
software systems that behave reliably and efficiently, are affordable to
develop and maintain, and satisfy all the requirements that customers have
defined for them.
• Software engineering principles use important techniques to reduce problem
complexity:
• Abstraction: Simplifying problems by omitting irrelevant details.
• Decomposition (analysis): Dividing complex problems into several smaller
problems (understandable pieces) and solving smaller problems one by
one.
• Synthesis: building (composing) the software from smaller building blocks.
 Software Engineering: Solving Problem
• The analysis process
• The synthesis process
 Software Engineering Practice
• Consists of a collection of concepts, principles, methods, and
tools that a software engineer calls upon on a daily basis

• Equips managers to manage software projects and software

engineers to build computer programs

• Provides necessary technical and management knowledge

how to getting the job done
 Essence of Practice
1. Understand the problem (communication and analysis)
• Who has a stake in the solution to the problem?
• What are the unknowns? and what (data, function, behavior) are required
to properly solve the Problem?
• Is it possible to represent smaller problems that may be easier to
understand?
• Can the problem be represented graphically? Can analysis model be
created?
 Cont’d
2. Plan a solution (planning, modeling and software design)
• Have you seen similar problems like this before?
• Has a similar problem been solved? If so, are the elements of the
solution reusable?
• Can sub problems be defined and are solutions available for the
sub problems?
 Cont’d

3. Carry out the plan (construction; code generation)

• Does the solution conform to the plan? Is the source code
traceable back to the design?
• Is each component of the solution correct? Has the design and
code been reviewed?
 Cont’d
4. Examine the results for accuracy (testing and quality
assurance)
• Is it possible to test each component of the solution? Has a
reasonable testing strategy been implemented?
• Does the solution produce results that conform to the data, function,
and behavior that are required?
• Has the Software been validated against all stakeholders
requirement?
 Core Principles of Software Engineering
1. Remember the reason that the software exists
• The software should provide value to its users and satisfy the requirements

2. Keep it simple
• All design and implementation should be as simple as possible

3. Maintain the vision of the project

• A clear vision is essential to the project’s success

4. Others will consume what you produce

• Always specify, design, and implement knowing that someone else will later have to
understand and modify what you did
 Cont’d
5. Be open to the future
• Never design yourself into a corner; build software that can be easily changed and
adapted.

6. Plan ahead for software reuse

• Reuse of software reduces the long-term cost and increases the value of the program
and the reusable components.

7. Think, then act

• Placing clear, complete thought before action will almost always produce better
results
 Types of Practices
• Communication Practice

• Planning Practice

• Modeling Practice

• Construction Practice

• Testing Practice

• Deployment Practice
 Communication Practice
1. Listen to the speaker and concentrate on what is being said

2. Prepare before you meet by researching and understanding the

problem

3. Someone should facilitate the meeting and have an agenda

4. Face-to-face communication is best, but also have a document or

presentation to focus the discussion

5. Take notes and document decisions

 Cont’d
6. Strive for collaboration and consensus

7. Stay focused on a topic; modularize your discussion

8. If something is unclear, draw a picture

9. Move on to the next topic

a) after you agree to something,

b) if you cannot agree to something, or

c) if a feature or function is unclear and cannot be clarified at the moment

10. Negotiation is not a contest or a game; it works best when both parties win
 Planning Practice
1. Understand the scope of the project

2. Involve the customer in the planning activity

3. Recognize that planning is iterative; things will change

4. Estimate based on only what you know

5. Consider risk as you define the plan

 Cont’d
6. Be realistic on how much can be done each day by each person and
how well

7. Adjust granularity as you define the plan

8. Define how you intend to ensure quality

9. Describe how you intend to accommodate change

[Link] the plan frequently and make adjustments as required

 Modeling Practice (Analysis)
1. The information domain of a problem (the data that flows in and out of a system) must
be represented and understood

2. The functions that the software performs must be defined

3. The behavior of the software (as a consequence of external events) must be

represented

4. The models that depict information, function, and behavior must be partitioned in a
manner that uncovers detail in a layered (or hierarchical) fashion

5. The analysis task should move from essential information toward implementation
detail
 Modeling Practice (Design)
1. The design should be traceable to the analysis model

2. Always consider the software architecture of the system to be built

3. Design of data is as important as design of processing functions

4. Interfaces (both internal and external) must be designed with care

5. User interface design should be tuned to the needs of the end-user

and should stress ease of use
 Cont’d
6. Component-level design should be functionally independent (high
cohesion)

7. Components should be loosely coupled to one another and to the

external environment

8. Design representations (models) should be easily understandable

9. The design should be developed iteratively; with each iteration, the

designer should strive for greater simplicity
 Construction Practices (Before Coding)
1. Understand the problem you are trying to solve

2. Understand basic design principles and concepts

3. Pick a programming language that meets the needs of the software to be

built and the environment in which it will operate

4. Select a programming environment that provides tools that will make your
work easier

5. Create a set of unit tests that will be applied once the component you code
is completed
Construction Practices (When Coding Begin)
1. Constrain your algorithms by following structured programming
practices
2. Select data structures that will meet the needs of the design
3. Understand the software architecture and create interfaces that are
consistent with it
4. Keep conditional logic as simple as possible
5. Create nested loops in a way that makes them easily testable
6. Select meaningful variable names and follow other local coding
standards
7. Write code that is self-documenting
8. Create a visual layout (e.g., indentation and blank lines) that aids code
understanding
 Construction Practices (When Coding End)
1. Conduct a code walkthrough

2. Perform unit tests (black-box and white-box) and correct errors you
have uncovered

3. Refactor the code

 Testing Practice
1. All tests should be traceable to the software requirements

2. Tests should be planned long before testing begins

3. The Pareto principle applies to software testing

• 80% of the uncovered errors are in 20% of the code

4. Testing should begin “in the small” and progress toward testing “in the large”
• Unit testing --> integration testing --> validation testing --> system testing

5. Exhaustive testing is not possible

 Deployment Practice
1. Customer expectations for the software must be managed
• Be careful not to promise too much or to mislead the user

2. A complete delivery package should be assembled and tested

3. A support system must be established before the software is

delivered

4. Appropriate instructional materials must be provided to end users

5. Buggy software should be fixed first, delivered later

Software Engineering
Methodologies
 Software Engineering Methodologies
• SE methods provide an organized and systematic approach to
develop software for a target computer.
• There are numerous methods from which to choose, and it is
important for the software engineer to choose an
appropriate method or methods.
• The choice can have a dramatic effect on the success of the
software project.
 Software Engineering Methodologies
• Some of the selected SE methods are:
• Heuristic Methods,
• Prototyping Methods, and
• Agile Methods.
 Heuristic Methods
• Are those experience-based SE methods that have been and are fairly
widely practiced in the software industry.

• Heuristic methods rely on experience, applying The following

techniques
i. Structured analysis and design methods,

ii. Data modeling methods,

iii. Object oriented analysis and design methods.

 Heuristic Methods-cont’d

Structured analysis and design methods:

• A traditional approach that uses diagrams to describe and understand systems.
• It uses boxes and arrows to represent entities, activities, and relationships.
• The Structured Systems Analysis and Design Method (SSADM) was developed in the 1980s for the
British government.

• Starting from a high-level view of the software (including data and control elements) and then
progressively decomposing or refining the model components through increasingly detailed designs.

• The detailed design eventually converges to very specific details or specifications of the software
that must be coded (by hand, automatically generated, or both), built, tested, and verified.
 Heuristic Methods-cont’d

Data Modeling Methods:

• A process that creates visual representations of data to communicate connections

between data points and structures.

• Some types of data modeling techniques include hierarchical, network, relational,

object-oriented, entity-relationship, dimensional, and graph

• Used primarily for defining and analyzing data requirements supporting database
designs or data repositories typically found in business software, where data is
actively managed as a business systems resource or asset.
 Heuristic Methods-cont’d

Object-Oriented Analysis and Design Methods:

• A popular approach that uses object-oriented concepts to design and implement
software systems.
• It involves techniques and practices such as object-oriented programming, design
patterns, UML diagrams, and use cases.
• It is represented as a collection of objects that encapsulate data and relationships
and interact with other objects through methods.
• Objects may be real-world items or virtual items
• The software model is constructed using diagrams to constitute selected views of
the software.
• Progressive refinement of the software models leads to a detailed design.
• The detailed design is then either evolved through successive iteration or
transformed (using some mechanism) into the implementation view of the model.
 Prototyping Methods
• Software prototyping is an activity that generally creates incomplete or minimally
functional versions of a software application
• An iterative development approach that involves building a simplified version of
the software to gather feedback and identify requirements.
• Usually the method used for trying out specific new features, soliciting feedback
on software requirements or user interfaces, further exploring software
requirements, software design, and other cases.
• The software engineer selects a prototyping method to understand the least
understood aspects or components of the software first;
• The prototyping approach is in contrast with other software engineering methods
that usually begin development with the most understood portions first.
• Prototyped product does not become the final software product without
extensive development rework or refactoring.
 Prototyping Methods-cont’d
Prototyping Style: This addresses the various approaches to develop prototypes.

• The style chosen is based on the type of results the project needs, the quality of
the results needed, and the urgency of the results.

Prototyping Target: The target of the prototype activity is the specific product being
served by the prototyping effort.

• Examples of prototyping targets include a requirements specification, an

architectural design element or component, an algorithm etc.
 Prototyping Methods-cont’d
Prototyping Evaluation Techniques: A prototype may be used or evaluated in a
number of ways by the software engineer or other project stakeholders.

• Primarily by the underlying reasons that led to prototype development in the first
place.

• Prototypes may be evaluated or tested against the actual implemented software

or against a target set of requirements (for example, a requirements prototype)

• The prototype may also serve as a model for a future software development
effort (for example, as in a user interface specification).
 Agile Methods
Considered lightweight methods in that they are characterized by
• Short,
• Iterative development cycles,
• Self-organizing teams,
• Simpler designs,
• Code refactoring
• Test-driven development,
• Frequent customer involvement, and
• An emphasis on creating a demonstrable working product with each
development cycle.
 Agile Methods – Cont’d
Some of the more popular approaches of Agile Methods are
• Rapid Application Development (RAD),

• eXtreme Programming (XP), and

• Scrum
 Agile Methods – Cont’d
RAD:
• Rapid software development methods are used primarily in data-intensive,
business systems application development.

• The RAD method is enabled with special-purpose database development tools

used by software engineers to quickly develop, test, and deploy new or modified
business applications.
 Agile Methods – Cont’d
XP:
• This approach uses stories or scenarios for requirements, develops
tests first, has direct customer involvement on the team (typically
defining acceptance tests), uses pair programming, and provides for
continuous code refactoring and integration.
• Each increment of software is tested with automated and manual
tests
• An increment may be released frequently, such as every couple of
weeks or so.
 Agile Methods – Cont’d
Scrum:
• This agile approach is more project management-friendly than the
others.
• The scrum master manages the activities within the project increment;
each increment is called a sprint and lasts no more than 30 days.
• A Product Backlog Item (PBI) list is developed from which tasks are
identified, defined, prioritized, and estimated.
• A working version of the software is tested and released in each
increment.
• Daily scrum meetings ensure work is managed to plan.
Software Development
Paradigm
(Process Models)
 Software Development Paradigm
• Is a strategy to develop the software

• They are not mutually exclusive and are often used together
⮚ WATERFALL MODEL
⮚ ITERATIVE MODEL
⮚ PROTOTYPING MODEL

⮚ SPIRAL MODEL
 Waterfall Model
• The simplest process model

• All the phases of SDLC will function one after another in linear manner when
the first phase is finished then only the second phase will start

• Assumes that everything is carried out perfectly as planned in the previous

stage

• Does not allow us go back and undo or redo our actions.

• Documentation is produced at each phase this makes the process visible so

managers can monitor progress against the development plan.
 Iterative Model
• Cyclic manner repeating every step after every cycle of SDLC
process.
• The software is first developed on very small scale and then, on
every next iteration, more features and modules are designed,
coded, tested and added to the software.
• Every cycle produces software, which is complete in by itself
and has more features and capabilities than that of the
previous one
• Easier to manage the development process but it consumes
more resources.
 Prototyping Model
• Prototype: Implementation of system having limited functional capabilities,
low reliability, and inefficient performance compared to the actual software.

• Stepwise approach to design a software prototype

⮚ Basic Requirement Identification
⮚ Developing the initial Prototype

⮚ Review of the Prototype

⮚ Revise and enhance the Prototype

 Spiral Model
• It like a spiral with many loops

• Has four phases and the software project repeatedly passes through these
phases in iterations called Spirals
• Each loop of the spiral represents a phase of the software process

• Each phase in this model are (the four sectors / quadrants)

⮚ First quadrant (Identification/ Objective Setting)
⮚ Second Quadrant (Design)
⮚ Third Quadrant (Construct or Build)
⮚ Fourth Quadrant (Evaluation and Risk Analysis)
Identification- Phase One
• starts with gathering the business requirements in the baseline spiral. In the
subsequent spirals as the product matures, identification of system
requirements, subsystem requirements and unit requirements are all done in
this phase.
• This also includes understanding the system requirements by continuous
communication between the customer and the system analyst.
Design – Phase Two
• Design phase starts with the conceptual design in the baseline spiral and
involves architectural design, logical design of modules, physical product
design and final design in the subsequent spirals.
Construct or Build- Phase Three
• Production of the actual software product at every spiral. In the baseline spiral when the
product is just thought of and the design is being developed a POC (Proof of Concept).
• Then in the subsequent spirals with higher clarity on requirements and design details a
working model of the software called build is produced with a version number.
• These builds are sent to customer for feedback.
Evaluation and Risk Analysis- Phase Four
• Risk Analysis includes identifying, estimating, and monitoring technical feasibility and
management risks, such as schedule slippage and cost overrun.

• After testing the build, at the end of first iteration, the customer evaluates the software
and provides feedback.
 Activity: Creating a Software Project Plan While Exploring SDLC Phases

Objective
● Understand the SDLC phases (Requirements Analysis, Design, Implementation, Testing,
Deployment, and Maintenance).
● Practice breaking down a project into smaller, actionable tasks aligned with each phase.

cenario
Project: Develop a basic To-Do List Application that allows users to:

1. Add tasks.
2. Mark tasks as complete.
3. Delete tasks.
 1. Requirements Analysis

Purpose
To understand what the software needs to do and document the requirements.
Tasks
1. Gather Requirements:
○ Identify what users want from the application (functional and non-functional).
○ Example questions:
■ What should the app do?
■ How should it look?
○ Deliverable: A list of user stories.
■ Example:
■ As a user, I want to add a task so that I can manage my tasks.
2. Prioritize Requirements:
○ Rank features in order of importance (e.g., adding tasks is more important than marking them
complete).
Deliverables:
3. Functional Requirements (e.g., Add, complete, and delete tasks).
4. Non-Functional Requirements (e.g., the app should load within 3 seconds).
 Design

Purpose

To create the blueprint of the system.

Tasks

1. System Architecture:
○ Diagram showing components: Front-end, Back-end, and Database.
○ Example tools: Lucidchart, [Link].
2. Database Design:
○ Plan the schema for the database.

Example schema for a "tasks" table:

| id (PK) | description | completed (boolean) |

3. User Interface Design:

○ Draw wireframes of the app:
■ Home page: List of tasks.
■ Add Task: Input box and "Add" button.
■ Action Buttons: "Complete" and "Delete."

Deliverables:

4. System architecture diagram.

5. Database schema.
6. UI wireframes.
Implementation
Purpose
To build the software based on the design.
Tasks
1. Assign Roles:
○ Divide tasks among team members:
■ Front-End: Build UI with HTML, CSS, and JavaScript.
■ Back-End: Write code to manage data (e.g., [Link] or Python Flask).
■ Database: Set up tables and implement CRUD operations.
2. Write Code:
○ Focus on one feature at a time.
○ Example pseudocode for "Add Task":
INPUT: Task description
PROCESS: Insert task into database
OUTPUT: Display updated task list on the screen
3. Collaborate:
○ Use version control (Git) to manage code.
Deliverables:
4. Basic app structure (front-end, back-end, and database).
5. Implemented features (e.g., adding tasks).
 Testing

Purpose
To ensure the software works as intended and is bug-free.
Tasks
1. Create Test Cases:
○ Example test for "Add Task":
■ Input: "Buy groceries."
■ Expected Output: "Buy groceries" appears on the task list.
2. Perform Testing:
○ Test each feature: Add, Complete, and Delete tasks.
○ Types of testing:
■ Unit Testing: Test individual features.
■ Integration Testing: Test how components work together.
Deliverables:
3. Test case document.
 Deployment

Purpose

To make the software available for use.

Tasks

1. Setup Deployment Environment:

○ Host the app locally (e.g., using XAMPP) or online (e.g., GitHub Pages for front-end or
Heroku for a full-stack app).
2. Deploy and Verify:
○ Ensure the app is functional in the deployment environment.

Deliverable:

● Deployed application link or a working local instance.

 Maintenance and Support

Purpose

To ensure the app continues to work smoothly after deployment.

Tasks

1. Identify Future Enhancements:

○ Example: Add a "due date" for tasks.
2. Plan Bug Fixes:
○ Address any issues reported by users.
3. Document Maintenance Plan:
○ Steps to update the app when necessary.

Deliverable:

● A maintenance plan document.

 Activity Wrap-Up

1. Present Deliverables:
○ Each team shares their project outputs (e.g., requirements document, design artifacts, test cases,
deployed app).
2. Reflect and Discuss:
○ What challenges did they face in each phase?
○ How do the phases of SDLC contribute to a successful project?
END OF CHAPTER FOUR