Module1 - Introduction to Software Engineering.pdf

Module 1: Introduction to Software Engineeering
Software Engineering
Computer Science
Academic Year 2023/2024
Gerard Albà Soler
1

Contents
1. What’s Software Engineering
2. Software Quality
3. The Software Process (Software Development Life Cycle)
4. Modeling techniques and Programming paradigms
5. Software Requirements

• Motivation
• Software Engineering definitions
• What will we learn
• References Module 1

1. What’s software engineering

Sundar Pichai
The Future: AI is reworking software engineering

• More and more, individuals and the society rely on advanced software
Systems. We need to be able to produce reliable and trustworthy systems,
economically and quickly.
• Use software engineering methods and techniques for software systems,
rather than just write the programs as if it was a personal programming
project.
Importance of software

• Software crisis was a term used in the early days of computer science. It was
was coined by some attendees at the first NATO Software Engineering
Conference in 1968 in Germany.
- Projects running over-budget
- Projects running over-time
- Software was very inefficient
- Software was of low quality
- Software often did not meet requirements
- Projects were unmanageable and code difficult to maintain
Software crisis and the begining of Software Engineering

E. Dijkstra in 1972’s Turing award lecture:
“The major cause of the software crisis is that the
machines have become several orders of magnitude
more powerful! To put it quite bluntly: as long as
there were no machines, programming was no
problem at all; when we had a few weak computers,
programming became a mild problem, and now we
have gigantic computers, programming has become
an equally gigantic problem.”

Question Answer
What is software? Computer programs and associated documentation.
Software products may be developed for a particular
customer or may be developed for a general market.
What are the attributes of good software? Good software should deliver the required functionality and
performance to the user and should be maintainable,
dependable and usable.
What is software engineering? Software engineering is an engineering discipline that is
concerned with all aspects of software production.
What are the fundamental software
engineering activities?
Software specification, software development, software
validation and software evolution.
What is the difference between software
engineering and computer science?
Computer science focuses on theory and fundamentals;
software engineering is concerned with the practicalities of
developing and delivering useful software.

• Software engineering is an engineering discipline that is concerned with all
aspects of software production from the early stages of System specification
through to maintaining the System after it has gone into use.
• Engineering discipline
ü Using appropiate theories and methods to solve problems bearing in mind
organizational and financial constraints.
• All aspects of software production
ü Not just technical process of development. Also project management and
the development of tools, methods...to suport software production.
ü Includes many aspects, some of them will not be covered in this
introductory course: user interface, usability, database design, security...

What will we learn?
OOA/D
UML notation
Iterative
development,
agile and UP
Principles,
guidelines,
patterns
Requirement
analysis

• Analyse and Design before coding
• Define the users and use cases for
the System
• Define a contract diagram that
specificies the name, data assets,
funcions and rules of execution
• Use a finite state machine UML
diagram
• Design smart contracts in OP
Solidity
Case Study: Micropayment Dapp in Blockchain Web3

Class diagram Sequence diagram

https://youtu.be/kYCZPXSVvOQ?si=eAR4RaUxUraeueEV

• Book References
ü Software Engineering. A Practitioner’s approach. R. Pressman et al. Ed
McGrawHill
ü Software Engineering. I. Sommerville. Ed Addison-Wesley
ü Applying UML and Patterns. An Introduction to Object-Oriented Analysis
and Design and Iterative Development. C. Larman. Ed Prentice Hall
ü Software Engineering at Google. T. Winter. Ed O’Reilly

Contents
2. Software Quality
3. The Software Process

2. Software Quality
• Software crisis. Process, methods and tools
• McCall’s Quality model
• Quality Assurance

2. Software Quality
• Software engineering is a set of processes, methods and tools used for obtaining reliable,
reusable and efficient software that accomplishes specific goals.
• By following established software engineering principles and techniques, the software can
be developed with improved quality: fewer bugs and higher reliability.
• Through this course, we will focus on the foundational (the processes) and technical (the
methods) layers, but software engineering must always rest on an organizational
commitment to quality.

2. Software Quality
PROCESS METHODS TOOLS
• The way we organise
the activities for
creating, using and
maintaining software
• It defines a framework
• It guides the engineer
through the necessary
tasks to build software
• Assist the engineer in
modelling the software
design: here we can use
different diagrams,
notations…
• Principles and
guidelines for a broad
array of tasks that
include communication,
requirements analysis,
design modeling,
program construction,
testing, and support.
• Traditional Computer-
Aided Software
Egineering (CASE) tools
provide support for
processes and methods.
• Currently, many
integrated development
environments (IDEs)
provide comprehensive
facilities for software
development (ex UML
from code)

2. Software Quality
• Traditionally, a high-quality product is outlined in terms of its fitness of
purpose. That is, a high-quality product will specifically be what the end-
users need.
• For code products (software), fitness of purpose isn’t a completely
satisfactory definition of quality. In the most general sense, software quality
can be defined as:
An effective software process applied in a manner
that creates a useful product that provides measurable value for those who
produce it and those who use it.

2. Software Quality
• Software quality factors of this model focus on three software product
aspects: its operation characteristics, its ability to undergo change, and its
adaptability to new environments.
Mc Call’s Quality model

2. Software Quality
Quality factor High-quality software includes several quality factors like the following
Correctness Software is correct if completely different needs are properly enforced.
Usability A software has smart usability if completely different users (i.e. knowledgeable and
novice users) will simply invoke the functions of the product.
Portability A software is claimed to be transportable, if it works in several package
environments, in several machines, with other programs, etc.
Maintainability A software is reparable, if errors may be simply corrected as and once they show
up, new functions may be simply added, and therefore the functionalities may be
easily changed, etc.
Efficiency The more efficient software is, the less it uses of CPU-time, memory, disk space,
network bandwidth, and other resources.
Reliability Software is more reliable if it has fewer failures.
Reusability A software has smart reusability if different modules can be smoothly reused to
develop new versions.

2. Software Quality
• There are several software quality models (qualitative and quantitative) and standards (like
ISO 9001).
• But a Quality Management System is one of the the main methods used by organizations.
Quality systems have increasingly evolved over time:
• Initially, the function was to inspect the finished products to remove defective ones.
• Then, the first product inspection task led to quality control. Thus, quality control aims
at correcting the reasons for bugs and not just rejecting the products.
• The next breakthrough was the development of quality assurance. If an organization's
processes are proper and are followed rigorously, then the products will be of good
quality.
• Total quality management (TQM) advocates that the procedure followed by an
organization must be continuously improved through process measurements. TQM
aims at frequently process improvement.

2. Software Quality
• Evolution: from product inspection to process assurance
• Reference book: Software Engineering at Google, Ed O’Reilly

2. Software Quality
https://youtu.be/xtQpNdGK6WI?si=ZsW_KHks5TyU_fel

• Software Development Life Cycle
• Predictive and Adaptative methodologies
• Waterfall
• Prototype
• Agile
• Scrum
• Unified Process (UP)

• The Software Process, sometimes also called the Software Development
Life Cycle is a framework for the activities, actions, and tasks required to
build high-quality software.
• A generic process framework:
1. Software specification: the functionality of the software and
constraints on its operation must be defined.
2. Software design and implementation: the software to meet the
specification must be produced.
3. Software validation: the software must be validated to ensure that it
does what the customer wants.
4. Software evolution: must evolve to meet changing customer needs.

• Short-term programming differ from producing code with a much longer
expected life span
• Imagine Google Search being stuck on a version of the initial OS from the
1990s..!!

• Software development phases
Planning
Analysis
Design
Development
Testing
Deployment
Maintenance

• Additionally, those phases can follow a process flow, that describes how the framework
activities and the actions and tasks that occur within each framework activity are
organized with respect to sequence and time. We will discuss it later in more detail
Linear
Iterative
Evolutionary
Paral.lel

• Plan-driven processes are processes where all of the process activities are
planned in advance and progress is measured against this plan.
• In agile processes, planning is incremental and it is easier to change the
process to reflect changing customer requirements.
• In practice, most practical processes include elements of both plan-driven
and agile approaches.
• There are no right or wrong software processes.
Plan-driven vs Agile

• First stage where the project is initiated
• The team examines key aspects of the project to see if it’s doable or not
• In this stage, it’s important to consider:
ü Communication: make contact with stakeholder and discuss high-level requirements
ü Business: the business value of the project. Why this project? Why this way?
ü Economic: What’s the budget? Is it reasonable?
ü Schedule: How many time can we work on it? It’s reasonable?
ü Technical: Can we build it? It’s possible?
ü Resources: What do we need? (tools, technology, people…)
• At the end of this phase we may have deliverables (depending on the paradigm): cost plan,
working plan, risk assessment plan, etc
Planning

• First Requirement gathering: relevant information is collected from the client, in order to
know exactly what it needs to be done and start thinking how.
• We are defining all the needs that the project will have to solve and what do we need to do
it. Critical step due to the implications if there is a misunderstanding with the customer.
• We can find two levels of definition here:
• User requirements [close to the client]: “we want the user to buy in a secure manner”
• Specification/Functional requirements [close to the tech team]: “activate login session
once the customer pushes enter after introducing mail and password. If the session
remains inactive for 60 seconds, delete the session”
• The documentation after this phase will depend on the paradigm. For Use Cases driven
development use cases textual definition is an additional deliverable.
Analysis

• How the system will achieve what is needed?
• Requirements are translated into: “how will it be implemented?”
• We produce plenty of design documents:
ü Physical design: UI, UX, Data Design, etc
ü Logical design: abstract representation of the system via modelling
• This documents are usually submitted to be approved by the whole team or higher
stakeholders of the project
Design

• In this phase, we also take decisions about code architecture. Software architecture is about
breaking large systems into sub-systems:
ü That are Independent with some business logic
ü That can be integrated with other components
ü That can be created separately
• At the end of this phase, design system requirements are transformed into a detailed,
software ready description
ü Graphical mock-ups or wireframes
ü Formal descriptions including UML diagrams
• During design, we must avoid technology-specific specifications
Design

• This is the longest phase (and way more longer if previous steps are not well defined).
• The team uses the design documents and diagrams to build the project correctly.
• In addition to the working software deliverables, for this phase we generate:
ü Unit tests for each one of the implemented modules
ü Build scripts to compile and link software into executable components
ü Code documentation inside the code
ü Test cases or testing flow for the application
Development

• Testing is intended to show that a program does what it is intended to do and to discover
program defects before it is put into use. When you test software, you execute a program
using artificial data. You check the results of the test run for errors, anomalies, or
information about the program’s non-functional attributes.
• Two distinct goals:
1. Validation: To demonstrate to the developer and the customer that the software meets its
requirements. “Are we building the right product?”
2. Verification: or defect testing. To discover situations in which the behavior of the software
is incorrect, undesirable, or does not conform to its specification. These are a consequence
of software defects. “Are we building the product right?”
Testing

• Traditional testing process, as used in plan-driven development. Test cases are specifications
of the inputs to the test and the expected output from the system (the test results), plus a
statement of what is being tested.
Testing

• Typically, a software system has to go through three stages of testing:
1. Development testing, where the system is tested during development to discover bugs
and defects. System designers and programmers are likely to be involved
in the testing process.
2. Release testing, where a separate testing team tests a complete version of the
system before it is released to users. The aim of release testing is to check that
the system meets the requirements of system stakeholders.
3. User testing, where users or potential users of a system test the system in their own
environment. Acceptance testing is one type of user testing where the customer formally
tests a system to decide if it should be accepted from the system supplier or if further
development is required.
Testing

• Development testing is primarily a defect testing process, where the aim of testing
is to discover bugs in the software.
• During development, testing may be carried out at three levels of granularity:
1. Unit testing, where individual program units or object classes are tested. Should focus
on testing the functionality of objects or methods.
2. Component testing, where several individual units are integrated to create composite
components. Should focus on testing component interfaces.
3. System testing, where some or all of the components in a system are integrated
and the system is tested as a whole. Should focus on testing component interactions.
Testing

https://engineering.fb.com/2018/05/02/developer-tools/sapienz-intelligent-automated-software-testing-at-scale/
Testing
• Meta (Facebook) AI testing system

https://youtu.be/v3Qxf1PG0fo?si=sZ2QYBiXkJiVB3xz
Testing
Quality Assurance

• The SDLC deployment phase involves customer acceptance and releasing the software
• Deployment and recovery plan must be ready before starting
• Deployment plan must consider :
ü Hardware and environment
ü Database related activities
ü Documentation for new software
ü Training activities
ü Third party software's
Deployment

• The Documentation is key in this phase, to support users and administrators
ü Manual explaining how to use features and functions
ü Installation manual or quick start guides
• Development team leads with most knowledge about the system will remain involved to:
ü Troubleshoot issues found in early deployment
ü Assist in training and documentation
ü Help transition to the new support team
Maintenance

• How to manage all this phases of the software development process, will depend on the
methodology, and the chosen one is often related with the enterprise culture, way of
working and project needs and goals. We have two big groups:
• Predictive methodologies:
• Customer has clear requirements
• Once approved the requirements do not change
• Development always follows the process: design —> develop —> test
• Software is build in only one shot at the end
• Adaptative methodologies:
• Customer has an idea of what he wants to build
• Development team builds the software by small chunks
• We talk about iterations, and at the end of each one we receive customer feedback
• The final product may not be the first idea, but it’s what the customer really wants
Process methodologies (also called models or paradigms)

Predictive Adaptative
The predictive method is a Waterfall methodology Adaptive method is an Agile methodology
This is a traditional approach to developing This is an iterative process of development
Changes can not be made easily throughout the
development of the project
The process allows for easy changes during any
stage of the process
Testing can only be done at the implementation
stage
Testing can be done at any stage
Clients are involved only during selected stages such
as requirement, scope change, and implementation
Clients are involved throughout different
development stages
Suitable for projects that are fully understood are
less complex
Suitable for less certain and complex projects
The methodology is process-oriented The methodology is people-oriented
The Predictive method can be implemented as an
individual by a team
The Adaptive method requires partnership or
collaboration by all stakeholders

Waterfall (Predictive methodologies)

• There are separate identified phases in the waterfall model:
ü Requirements analysis and definition
ü System and software design
ü Implementation and unit testing
ü Integration and system testing
ü Operation and maintenance
• The main drawback is the difficulty of accommodating change after the process is underway.
A phase has to be complete before moving onto the next.
• Inflexible partitioning into distinct stages makes it difficult to respond to changing customer
requirements. This model is only appropriate when the requirements are well-understood
and changes will be fairly limited. But few business systems have stable requirements.
• The waterfall model is mostly used for large systems engineering projects where a system is
developed at several sites. The plan-driven nature of the waterfall model helps coordinate.
Waterfall (Predictive methodologies)

https://youtu.be/5RocT_OdQcA?si=87ucYP0RKUDdXeG2

• In the waterfall model:
• Feedback not obtained until testing phase .
• That implies thinking that no errors were made while producing all design documents.
• This increases dramatically the risk of project failure.
• To overcome this issues, the prototype methodology was proposed.
• The application will be build based on approved prototype.
• A prototype it’s a fast build software that will allow the user to validate and establish
requirements for the final system. A prototype is a working software that only contains the
key features we want to try at a certain moment.
Prototype (Adaptative methodologies)

• Although problems can occur, prototyping can
be an effective paradigm.
• The key is to define the rules of the game at
the beginning; that is, all stakeholders should
agree that the prototype is built in part to
serve as a mechanism for defining
requirements.
• It is often desirable to design a prototype so it
can be evolved into the final product. The
reality is developers may need to discard (at
least in part) a prototype to better meet the
evolving needs.
Prototype (Adaptative methodologies)

Incremental or Evolutionary (Adaptative methodologies)
• 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.

• Rapid development and delivery is now often the most important
requirement for software systems
ü Businesses operate in a fast –changing requirement and it is
practically impossible to produce a set of stable software
requirements.
ü Software has to evolve quickly to reflect changing business needs.
• Rapid software development
ü Specification, design and implementation are inter-leaved.
ü System is developed as a series of versions with stakeholders
involved in version evaluation.
Agile (Adaptative methodologies)

• Dissatisfaction with the overheads involved in software design methods (of
the 1980s and 1990s) led to the creation of agile methods.
• These methods:
ü Focus on the code rather than the design.
ü Are based on an iterative approach.
ü Are intended to deliver working software quickly and evolve to meet
changing requirements.
• The aim of agile methods is to reduce overheads in the software process
(e.g. by limiting documentation) and to be able to respond quickly to
changing requirements without excessive rework.

https://agilemanifesto.org/

• Dissatisfaction
Principle Description
Customer involvement Customers should be closely involved throughout the development process.
Their role is provide and prioritize new system requirements and to evaluate
the iterations of the system.
Incremental delivery The software is developed in increments with the customer specifying the
requirements to be included in each increment.
People not process The skills of the development team should be recognized and exploited. Team
members should be left to develop their own ways of working without
prescriptive processes.
Embrace change Expect the system requirements to change and so design the system to
accommodate these changes.
Maintain simplicity Focus on simplicity in both the software being developed and in the
development process. Wherever possible, actively work to eliminate
complexity from the system.

• Product development where a software company is developing a small or
medium-sized product for sale.
• Custom system development within an organization, where there is a clear
commitment from the customer to become involved in the development
process and where there are not a lot of external rules and regulations that
affect the software.
• Because of their focus on small, tightly-integrated teams, there are
problems in scaling agile methods to large systems.

• Scrum it’s an agile methodology that iterates over sprints.
• This sprints have a fixed duration, between 1 and 4 weeks.
• The tasks for the project are created and added into a list called backlog.
• In this backlog we can find big tasks, that needs to be more defined (epic
stories) and smaller tasks ready to develop.
• This backlog is permanently reviewed and prioritised by the Product Owner
and estimated by the team.
Scrum (Agile)

https://youtu.be/9TycLR0TqFA?si=SPpKezU13yz8egYS

• We can find different roles:
• Product Owner: responsible for defining the product backlog, communicating the
product vision, and making decisions about which features should be developed next
to ensure the satisfaction of stakeholders and the success of the project.
• Team: delivering incremental, usable increments of the product, through self-
organization and collaboration, within the constraints of each sprint. In fact, the team
decides what they will be working on on each sprint and they commit to it.
• Scrum Master: helping the development team, removing obstacles to progress, and
ensuring that the Scrum framework and Agile Principles are understood and
followed.
Scrum (Agile)

• And meetings:
• Sprint planning: the entire team gather around and start estimating tasks from the
backlog, and selecting the ones that the team will work on during the sprint. After this
meeting, all the team commits to the sprint backlog.
• Daily meeting: each day, before starting work, the team meets, in a daily standup
meeting, where each one of them answers three questions: what i’ve been working on?
what i’ll be working on? is there any blocking point for me? The maximum duration is 15
minutes, and often a clock is used to not overpass this time.
• Sprint review: the development team demonstrates the completed product increments
to stakeholders, discusses the progress and lessons learned, and collaborates to plan
future improvements and work for the next sprint.
• Sprint retrospective: the development team thinks about the past sprint, identifies
areas for improvement, and collaboratively agrees on actions to make those
improvements, in order to continuously increase effectiveness and efficiency.

• Extreme programming (XP) is a well-known agile method that integrates a
range of good programming practices such as frequent releases of the
software, continuous software improvement and customer participation in
the development team.
• Extreme Programming takes an ‘extreme’ approach to iterative
development.
ü New versions may be built several times per day.
ü Increments are delivered to customers every 2 weeks.
ü All tests must be run for every build and the build is only accepted if
tests run successfully.
Extreme programming XP (Agile)

• Incremental development is supported
through small, frequent system releases.
• Customer involvement means full-time
customer engagement with the team.
• People not process through pair
programming, collective ownership and a
process that avoids long working hours.
• Change supported through regular system
releases.
• Maintaining simplicity through constant
refactoring of code.
Extreme programming XP (Agile)

Principle XP Description
Incremental planning Requirements are recorded on story cards and the stories to be included in a
release are determined by the time available and their relative priority. The
developers break these stories into development ‘Tasks’.
Small releases The minimal useful set of functionality that provides business value is developed
first. Releases of the system are frequent and incrementally add.
Simple design Enough design is carried out to meet the current requirements and no more.
Test-first development An automated unit test framework is used to write tests for a new piece of
functionality before that functionality itself is implemented.
Refactoring All developers are expected to refactor the code continuously as soon as possible
code improvements are found. This keeps the code simple and maintainable.

Principle XP Description
Pair programming Developers work in pairs, checking each other’s work and providing the
support to always do a good job.
Collective ownership The pairs of developers work on all areas of the system, so that no islands of
expertise develop and all the developers take responsibility for all of the
code. Anyone can change anything.
Continuous integration As soon as the work on a task is complete, it is integrated into the whole
system. After any such integration, all the unit tests in the system must pass.
Sustainable pace Large amounts of overtime are not considered acceptable as the net effect
is often to reduce code quality and medium term productivity.
On-site customer A representative of the end-user of the system (the customer) should be
available full time for the use of the XP team. In an extreme programming
process, the customer is a member of the development team.

UP (Adaptative methodologies)
• The Unified Process (UP) is a process model that
represents the development of the software as a four-
phase iterative activity: inception, elaboration,
construction, transition and production
ü Inception establishes a business case for the system
ü Elaboration defines the architecture
ü Construction implements the system
ü Transition deploys the system
ü Production ongoing use of the software is
monitored
• Book Reference: “Applying UML and Patterns. An
Introduction to Object-Oriented Analysis and Design and
Iterative Development”. C Larman, Ed Prentice Hall

• In some ways the Unified Process (UP) is 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.
• The Unified Process recognizes the importance of customer communication and
streamlined methods for describing the customer’s view of a system (the use case).
• It emphasizes the important role of software architecture and helps the architect focus
on the right goals, such as understandability, reliance to future changes, and reuse.
• It suggests a process flow that is iterative and incremental, providing the evolutionary
feel that is essential in modern software development.

• The UML, the unified modeling language, was developed to support the
UP process implementation.
• UML contains a robust notation for the modeling and development of
object-oriented systems and has became a de facto industry standard for
modeling software of all types (see for example the Case Study: UML for
Blockchain).
• UML is used throughout this course to represent both requirements and
design models.

• The inception phase of the UP is where customer communication and planning takes
place. Fundamental business requirements are described through a set of preliminary use
cases that describe which features and functions each major class of users desires.
Planning identifies resources, assesses major risks, and defines a preliminary schedule for
the software increments.
• The elaboration phase encompasses the planning and modeling activities of the generic
process model. Elaboration refines and expands the preliminary use cases and creates an
architectural baseline that includes five different views of the software—the use case
model, the analysis model, the design model, the implementation model, and the
deployment model.
UP (Unified Process)

• The construction phase of the UP is the construction activity defined for the generic
software process. All necessary and required features and functions for the software
increment (i.e., the release) 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.
• The transition phase of the UP encompasses the latter stages of the generic construction
activity and the first part of the generic deployment (delivery and feedback) activity.
Software and supporting documentation is given to end users for beta testing, and user
feedback reports both defects and necessary changes. At the conclusion of the transition
phase, the software increment becomes a usable software release.
UP (Unified Process)

• The UP describes:
ü Disciplines: a set of
activities in one subject
area (such as requirement
analysis, design,
deployment, etc)
ü Artifacts: a general term for
any work product:
diagrams, models, code,
web, database schema, text
documents, etc
• In this course, we will mainly focus on these three disciplines: Business modeling (the Domain
model artifact), Requirements (the Use-Case model and Supplementary Specification) and
Design (design artifacts to design software objects)

4. Modeling techniques and Paradigms
• Unified Modelling Language (UML)
• Programming Paradigms: Imperative and Declarative
• Procedural
• Object-Oriented Programming
• Functional

• Models are abstraction that help us to communicate what is important on
the system and help to deal with complexity.
• Modelling techniques are used to represent and visualise different aspects
of software system: requirements, architecture, behaviour and data.
• The goal of modelling is to help understand and communicate the system’s
design and requirements, to facilitate its development and maintenance.
• Techniques used for modeling will also depend on the programming
paradigm. In this course, we will apply those techniques mainly to OOA/D.
• The Unified Modelling Language (UML) is the most popular and
successfull standard for modelling software products.

• As we will see in the next Modules, some modelling techniques include:
ü Use case: for functional requirements, interactions between actors and the system
ü Class modelling: structure and relationships between classes and objects .
ü State machine: to represent the behaviour of a system in response to events and inputs.
ü Data modelling: to represent data structures, relationships and constraints of a system.
ü Architecture: high level structure and relationships between components in a system.
• In the phases of Analysis and Design in OOA/D, models will be build from different perspectives:
ü Domain modelling: identify key concepts for a specific domain to solve a specific problem.
ü Specification modelling: elements that compose the solution and high-level description of
the services provided.
ü Design modelling: describes the software itself, its behaviour to external events and the
different responsibilities for each element of the system .

• A programming paradigm is a
style to write computer
programs that defines the
structure, organisation and
nature of the code.
• Sometimes, it is also used as a
classification of programming
languages based on their
features. But most popular
languages support multiple
paradigms (C++, Python etc).
Programming paradigms

• In the Imperative style, the programmers instruct the machine How to
perform a task by writing step-by-step instructions including variables,
conditions, loops etc.).
• Algorithms as a sequence of steps .
• Often used synonymously: procedural programming (emphasizing the
concept of using procedure calls(functions) to structure the programing
modular fashion).
• Object-Oriented Programming (OOP) is usually considered a subcategory.
Imperative

• Example: you want to search for an element in an array of numbers, you
write all the instructions to perform the search such as taking input, iterating
the array, checking if the element is found or not, returning the results, etc.
Imperative

• The imperative paradigm is further classified into two types: Procedural and
Object Oriented.
• Procedural oriented: procedural language breaks down a task into a
collection of procedures (subroutines, functions) to perform a task. It
maintains global variables to manage the state of the system. C, BASIC, etc.
• Object-oriented (OOP) breaks down a task into objects that expose
behaviour (method) and data (member or attribute), objects communicate
with each other through message-passing techniques to accomplish a given
task. C++, Java, C#, Kotlin etc belong to the object-oriented paradigm.
Imperative

Procedural
• Example: linear
search in C

Object-Oriented
• Example: linear
search in Java

• The declarative paradigm is classified into two types: Functional and Logical.
• Functional: Functional programming contains only functions without mutating the state or
data. It means that there are no global data/variables. Composing and applying function is
the main driving force in this paradigm. A function can take another as an argument and
return a new function. The first high-level functional programming language, developed in
the 1950s, was LISP. This language laid the foundation for modern functional languages.
• Logical: has its foundations in mathematical logic in which program statements express facts
and rules. Rules are written as logical clauses. The engine infers the answer to the user’s
query by using unification and backtracking techniques. The set of facts and rules forms a
knowledge base, allowing the system to reason. Prolog, Datalog etc are examples of logical
programming. Logical programming helps in major areas such as Natural language
processing, Database management, Pattern matching, and Predictive analysis.
Declarative

Functional
• Example: factorial
program using
LISP

Logical
• Example: Prolog program to
infer relationship match of
two people from their food
interest knowledge base.
• LP can be made available
with libraries, e.g. For
Python: Pyke (inspired by
Prolog), pyDatalog (inspired
by Datalog)

• Functional and Non-funcional
• Software Requirements Specification

• Software Requirements: the process of establishing the services that the
customer requires from a system and the constraints under which it operates
and is developed.
• The requirements themselves are the descriptions of the system services
and constraints that are generated during the requirements engineering
process.
• It may range from a high-level abstract statement of a service or of a system
constraint to a detailed mathematical functional specification.

• Functional: expresses the relation between input and output of the system
and its processes
• We answer this questions: what does the software need to do? What’s the
problem we need to solve? What’s the necessary features and capabilities?
• Non functional: defines the quality or restriction that we impose to a system
to realise its function:
ü Performance: how many users should the app support simultaneously?
ü Law: what do we need to do in terms of data protection?
ü Support: how the app should perform when there is an issue?
ü Security, budget…

• First, perform a previous analysis or problem comprehension: understand user needs and
understand the associated problematic. How?
ü Ask users: meetings, surveys…
ü Compare to other existing systems and select the equal parts
ü Prototype building
ü Brainstorming
• And thereater, do an analysis or requirements specification: define what the client wants
and generate a document (Software Requirement Specification or SRS) :
https://www.utdallas.edu/~chung/RE/Presentations07S/Team_1_Doc/Documents/SRS4.0.doc
• The software requirements document is the official statement of what is required of the
system developers. Should include both a definition of user requirements and a
specification of the system requirements. It is not a design document. As far as possible, it
should set of What the system should do rather than How it should do it.

• In order to correctly do the SRS, it must be:
ü Correct: the requirement are the ones the software must do (not “nice to have” features).
ü Unambiguous: every statement has only one interpretation, and leaves no room to other.
ü Complete: contain all significant requirements relating to functionality, performance,
design constraints, attributes and external interfaces.
ü Modifiable: structure and style may allow any changes done easily and completely while
retaining the structure and style.
ü Consistent: the document must agree with all other documentation, specially the higher-
level one, usually made before.
ü Verifiable: all statements must be verifiable by third persons and the team.
ü Traceable: the origin of each requirement must be clear and facilitates the referencing of
each requirement.

• We can classify requirements according to:
ü Functionality: features of the system.
ü Usability: everything that will affect the final user (easy to use,
intuitive…).
ü Reliability: availability, failure rate, predictability (downtime
accepted, for example).
ü Performance: speed, efficiency, scalability, resource consumption…
ü Support: testability, configurability, extensibility…

• Many agile methods argue that producing a requirements document is a
waste of time as requirements change so quickly. The document is
therefore always out of date.
• Methods such as XP use incremental requirements engineering and
express requirements as ‘user stories’ (discussed in Chapter 3).
• This is practical for business systems but problematic for systems that
require a lot of pre-delivery analysis (e.g. critical systems) or systems
developed by several teams.

SRS Chapter (1/2) Description
Preface This should define the expected readership of the document and describe
its version history, including a rationale for the creation of a new version and
a summary of the changes made in each version.
Introduction This should describe the need for the system. It should briefly describe the
system’s functions and explain how it will work with other systems. It should
also describe how the system fits into the overall business or strategic
objectives of the organization commissioning the software.
Glossary This should define the technical terms used. You should not make
assumptions about the experience or expertise of the reader.
User requirements
definition
Here, you describe the services provided for the user. The nonfunctional
system requirements should also be described in this section. This
description may use natural language, diagrams, or other notations that are
understandable to customers. Product and process standards that must be
followed should be specified.
System architecture A high-level overview of the anticipated system architecture, showing the
distribution of functions across system modules.

SRS Chapter (2/2) Description
System requirements
specification
Describe the functional and nonfunctional requirements in more detail.
Further detail may also be added to the nonfunctional requirements.
Interfaces to other systems may be defined.
System models This might include graphical system models showing the relationships
between the system components and the system and its environment.
Examples of possible models are object models, data-flow models, or
semantic data models.
System evolution This should describe the fundamental assumptions on which the system is
based, and any anticipated changes due to hardware evolution, changing
user needs, and so on. This section is useful for system designers as it may
help them avoid design decisions that would constrain likely future changes
to the system.
Appendices These should provide detailed, specific information that is related to the
application being developed; for example, hardware and database
descriptions.

Module1 - Introduction to Software Engineering.pdf

Recommended

Recommended

More Related Content

Similar to Module1 - Introduction to Software Engineering.pdf

Similar to Module1 - Introduction to Software Engineering.pdf (20)

More from Gerard Alba

More from Gerard Alba (20)

Recently uploaded

Recently uploaded (20)

Module1 - Introduction to Software Engineering.pdf