Software Enginyering

Code: 106561
ECTS Credits: 6 2024/2025

Degree Type Year

2504392 Intel·ligència Artificial / Artificial Intelligence O 3 and 4

Contact
Name: Marc Castelló Torrellas
E-mail: [email protected]

Teacher: Marc Castelló Torrellas

Teaching groups languages: You can view this information at the end of this document
Prerequisites

Since the course is an introduction to software engineering, it will be assumed that no prior knowledge of the
subject is possessed. It is the responsibility of the course itself to provide students with a means to acquire the
knowledge described in the course content section (section 6 of this guide). However, it is recommended to
have passed the first-year course on Fundamentals of Programming.

Objectives and Contextualisation

This course serves as an introduction to the software engineering process. The general objective is to provide
a comprehensive and structured overview of the software development process, which goes beyond
programming (as programming is just one phase within the entire software engineering process). The course
will introduce the fundamental activities that make up the development process (requirements analysis, design,
implementation, testing, and maintenance), particularly those related to Artificial Intelligence.

The aim, therefore, is for students to acquire a general understanding of what a software development process
entails, how software is modeled, which tools are used, how quality is managed, and how a project is
administered. More specifically, the objectives are:
• To provide a general overview of the software development process, its paradigms, activities, and the
objectives of each activity.
• To understand what software modeling is, as well as the importance and challenges of requirements
specification and design in their different perspectives.
• To learn the basic concepts of UML for practical work in software modeling.
• To introduce students to the principles, concepts, and techniques used to manage and control software
quality.
• To familiarize students with the management techniques required to plan, organize, monitor, and control
software projects.
• To become acquainted with the SCRUM model as the most relevant paradigm for evolutionary
development.

Learning Outcomes

1. Analyze application performance, identify bottlenecks, and apply possible optimizations.

2. Analyze, design, distribute, and maintain applications, ensuring their quality and maintainability, while
incorporating AI techniques into these processes.
3. Critically evaluate the work performed.
4. Describe a software system and transform it into a design model.
5. Plan and manage time and available resources.
6. Ensure that students demonstrate an understanding and knowledge in a field of study that builds upon
general secondary education and is typically found at a level that, while based on advanced textbooks,
also cludes some aspects involving knowledge from the forefront of that field of study.
Content
BLOCK 1. SOFTWARE AND SOFTWARE ENGINEERING
Topic 1. Principles of Software Engineering
• Definition and Objectives of SE: Definition of software. Characteristics of software. Software
applications. Definition of Software Engineering. Objectives of Software Engineering.
• Evolution of Software: Stages. Software crisis: problems and causes.
• Process, Method, and Tool: Definitions. Activities in the software development process.
• Software Development Paradigms: Linear sequential model (classic lifecycle). Prototyping model.
Evolutionary model. Spiral model.

BLOCK 2. MANAGEMENT AND DEVELOPMENT OF SOFTWARE PROJECTS

Topic 2. SCRUM
• Introduction: Agile project management methodology.
• SCRUM: Characteristics. History.
• Components of SCRUM: Roles. Artifacts. Processes. Scalability. Scrum of Scrums.
• Software Tools: Tools for implementing SCRUM.
• Other Agile Models: Lean. Extreme Programming (XP). Kanban.
• A Case Study: Presentation of a case study to be followed throughout the course.

BLOCK 3. SOFTWARE MODELING

Topic 3. Software Requirements Analysis
• Introduction: Types of requirements. Tasks to be performed.
• Understanding the Problem: Communication techniques. Associated problems. Principles of analysis.
• Requirements Specification: Desired properties of a requirements specification. Software engineering
standards. Review and validation of the specification.

Topic 4. Software Design

• Introduction: Design process. Data design, architectural design, interface design, procedural design.
Principles (objectives) of design.
• Design Concepts: Abstraction. Modularity. Refinement.
• Effective Modular Design: Functional independence. Cohesion. Coupling. Heuristics for effective
modular design.
• User Interface Design.

Topic 5. UML (Unified Modeling Language)

• Evolution and History of UML.
• UML Views: Use case view, logical view, component view, deployment view.

BLOCK 4. SOFTWARE QUALITY MANAGEMENT

Topic 6. Software Quality
• Introduction: Quality concepts.
• Software Testing: Testing strategies, testing of conventional applications, testing of web applications.
• Software Configuration Management: Overview and practices.
Activities and Methodology
Title Hours ECTS Learning Outcomes

Type: Directed
30 1,2 4, 6
Theory Classes
Preparation and Study 30 1,2 3, 5, 6
Seminars/Problems 15 0,6 1, 2, 4, 3
Type: Supervised
Interviews/Tutorials for 15 0,6 1, 2, 4, 3, 5
Case Study
Tutoring 15 0,6 3, 5
Type: Autonomous
Practical Work 38 1,52 1, 2, 4, 3, 5, 6

The Software Engineering course has a strong applied component, but it also requires a theoretical part,
based on experience, from which practical decisions are implemented. Therefore, the course will not be purely
PBL (Problem-Based Learning) but a mix of PBL and traditional methods. Students will be presented with a
practical case (a generic problem) of real-world size, around which the problem sessions and practical work
will be structured. The student must acquire the role of an analyst/architect to make the appropriate decisions
that lead to the construction of a design proposal for the proposed system. The professor will act as a tutor
and, in specific situations, as a client, encouraging developer-client dialogue simulations.

The course consists of 4 weekly hours in person. There is no distinction between theory, problem-solving, and
laboratory practice hours. During the in-person hours, theory classes, problems, or practical sessions will
alternate according to the schedule provided on the course planning day. In general, the explanation of the
fundamental theoretical content will be concentrated during the first sessions of the course (approximately the
first 6 weeks), but some problem-solving and case study sessions will be gradually interspersed. Once the
theoretical content has been covered, the remaining sessions will be dedicated to problem-based work,
identifying mandatory attendance sessions where practical work will be done (in teams of n people, where the
number n will be specified at the beginning of the course) or problems to be submitted at the end of the
session.

THEORY
The theory consists of lectures with multimedia material available on the UAB Virtual Campus. The main
objective of these classes is to introduce basic notions about the processes, methods, and tools related to the
software lifecycle from an engineering perspective. The principles and paradigms of Software Engineering, the
different activities, and the tasks to be carried out in each activity will be presented. The theory classes should
allow students to gain a real understanding of the rigor, planning, and systematic approach required for the
professional development of software.

SEMINARS/PROBLEMS
The seminars are participatory classes where students actively engage. They have a dual function, linking the
lecture classes with practical sessions focused on solving problems in teams. On one hand, the seminars will
complement the technological content presented in the lectures, enhancing students’ understanding. On the
other hand, they will serve as the framework for discussing, establishing the foundations, and developing the
guiding problem. Students will be provided with the necessary knowledge to advance in the practical work or
will be directed to resources where they can obtain it.The seminars primarily promote analytical and synthetic
skills, critical reasoning, and decision-making in relation to solving the guiding problem. Since this is a highly
practical course and the theoretical content is of low complexity, practical work is often reinforced through
problem-solving or participatory activities. The seminar content will be coordinated with the stages to be
addressed in the practical work.
PRACTICAL WORK FOLLOW-UP

There will be no in-person laboratory sessions. Students will solve the guiding problem autonomously in small
groups, and follow-up will occur during regular class hours. The practice sessions (12 hours during the course)
will consist of two parts. First, each practice team will present their progress to the rest of the class (the person
responsible for the presentation will be the scrum master for that iteration). In the second part of the session,
the practice tutor will have an individual interview with each team for follow-up and evaluation. The
development will follow a SCRUM-based approach, where each increment, called a sprint, corresponds to one
session.

Attendance at follow-up interviews will be MANDATORY for all students. Absence will negatively affect the
evaluation of the practical work, resulting in failure if the number of absences exceeds 15% of the sessions. In
case of justified absence, the professor will consider compensatory mechanisms. The size of the practice
teams will be determined at the beginning of the course, with teams of around 5 people being a guideline.
Since attendance at follow-up sessions is mandatory, and they occur during in-person hours, it is important that
all members of a practice team are enrolled and attend the same group.

PRACTICAL WORK

At the beginning of the course, students will be given a guiding problem. This problem will serve two purposes.
First, it will be used as an example in the seminar classes, with parts of the problem being solved according to
the content of each moment. Second, it can be understood as the statement of a practice that will be solved in
stages throughout the course. Students will organize themselves into work teams and will solve the problem
autonomously, with the weekly follow-up described earlier.

Evaluation
Title Weighting Hours ECTS Learning Outcomes

Practical Evaluation 60 4 0,16 1, 2, 4, 3, 5, 6

Theoretical Evaluation 40 3 0,12 4, 6

INDICATORS AND EVALUATION

This course does not use a single assessment system. The evaluation will be based on the practical work
developed by the student and included in their portfolio (final resolution of the guiding problem, material
generated in seminar activities), the level of involvement in the seminars, and the technological knowledge
acquired in the subject. The following evaluation instruments will be considered:

• Theoretical Evaluation (TE). Written in-person exam to assess the level of knowledge acquired by the
student on an individual basis. There will be two partial exams during the course, which will allow
students to be exempt from certain content, provided the score obtained is equal to or higher than 4.
The score for each partial exam will contribute 50% to the final grade of the theoretical evaluation.

• Practical Evaluation (PE). Assessment of the collective performance of the different work groups in
solving the guiding problem (project) and the various activities presented in the seminars (problems). It
consists of two instruments:
Project Grade. Documentation submitted by the students for their practical work. The technical
resolution of the guiding problem will be evaluated. This includes the defense of the work by the
students during the submissions, the monitoring of the work's evolution, and active participation
in the seminars.

Assessment through Interviews and Problem Solving. The evaluation will be based on interviews
with the professor, short written tests, submissions, or presentations of problems and cases
addressed in the activities. Although this instrument is for collective assessment, at the
discretion of the tutor, it may be corrected individually in cases where a student's participation
stands out (either positively or negatively) compared to their group.

Problems Grade. Throughout the course, the professor will ask students to solve certain
problems independently, apart from those solved collectively during the problem-solving
sessions. These submissions will be individual.
The final grade will be determined according to the following table:
Minimum Minimum
Grade Average Grade Average Grade
Grade Grade
Partial_1 4
TE=0.5 Partial_1+0.5 Partial_2 5
Partial_2 4
FG = 0.4 TE + 0.6 PE
Problems 5
PE=0.5 Problems+0.5 Project 5
Project 5

At the time of publishing each evaluation, a period will be given for students to review their grades. The grade
review periods will be strictly respected, meaning that no grade will be reviewed outside of these established
periods.

The course will be evaluated as Not Evaluated only if the student has not attended any of the evaluation tests
or has not fully or partially submitted the required assignments.

If the student does not pass the course because any evaluation activity does not meet the minimum required
grade, the final grade recorded in the transcript will be the weighted average of the grades. However, the
exceptions are:

The grade "Not Evaluated" will be assigned to students who did not participate in any evaluation activities.

The numerical grade in the transcript will be zero (0) if the student has committed any irregularities during an
evaluation (and thus cannot pass by compensation). Honors will be awarded within the limits set by UAB
regulations (depending on the number of students enrolled) to those who achieve the highest grades of 9 or
above. For each evaluation activity, a location, date, and time for review will be specified, during which
students can review the activity with the professor. In this context, students can appeal their grade, and such
appeals will be evaluated by the professor in charge of the course. If the student does not attend this review,
the activity will not be reviewed at a later time.

See the "PLAGIARISM" section for measures in cases of irregularities due to plagiarism in evaluation
activities.

RECOVERY:
• Theoretical Evaluation (TE): Two partial exams will be held during class hours. Students who do not
pass one or both exams will have the opportunity to take a recovery exam during the final assessment
date scheduled by the program.

• Practical Evaluation (PE): The practical work is assessed through continuous evaluation during the
follow-up sessions. Therefore, there will be no recovery activity at the end of the course. However,
regarding the resolution of the project, failing to submit on time or not

ASSESSMENT DATES:

The dates for continuous assessment and submission of assignments will be published on the virtual campus
and may be subject to schedule changes due to adaptation to possible incidents. Any changes will be
communicated on the virtual campus, as it is understood to be the usual channel for information exchange
between professors and students.

REPEATING STUDENTS:

Partial grades (theory or practice) are not carried over from one course to another. However, at the professor's
discretion and based on evaluations from previous courses, compensations may be established.

PLAGIARISM:

Without prejudice to other disciplinary measures deemed appropriate, and in accordance with the current
academic regulations, any irregularities committed by a student that may lead to a change in the grade will be
graded with a zero (0). For example, plagiarizing, copying, allowing copying, etc., in an assessment activity will
result in the failure of that assessment activity with a zero (0). Activities assessed in this way and through this
procedure will not be recoverable. If it is necessary to pass any of these assessment activities in order to pass
the course, the student will automatically fail the course with a zero (0), with no opportunity to recover it in the
same term. These irregularities include, but are not limited to:

• Total or partial copying of a practice, report, or any other assessment activity.

• Allowing someone to copy.
• Presenting a group work not entirely completed by the members of the group.
• Presenting materials produced by a third party as your own, even if they are translations or adaptations,
and in general, works containing non-original elements that are not exclusive to the student.
• Unauthorized use of AI (e.g., Copilot, ChatGPT, or equivalents) to solve exercises, practices, or any
other assessable activity.
• Having communication devices (such as mobile phones, smart watches, etc.) accessible during
individual theoretical-practical assessment tests (exams).

A student who has committed irregularities in an assessment act will not have any of the assessment activities
validated. In summary: copying, allowing copying, or plagiarizing (or attempting to) in any assessment activity
results in a FAIL, with a zero (0) that cannot be compensated and no validation of parts of the subject in
subsequent courses.

FINAL CLARIFICATION:

For any doubts or discrepancies, the most up-to-date information communicated on the day of the course
presentation and published on the virtual campus will prevail.

Bibliography
• G. Booch, J. Rumbaugh, I. Jacobson. El lenguaje unificado de modelado. Addison-Wesley, 2001.
• I. Jacobson, G. Booch, J. Rumbaugh. El proceso unificado de desarrollo de software. Addison-Wesley,
2000.
• J. Rumbaugh , I. Jacobson, G. Booch. El lenguaje unificado de modelado: manual de referencia.
Addison-Wesley, 2007.
• T. Quatrani. Visual Modeling with Rational Rose 2000 and UML. Addison-Wesley, 2000.
• P. Krutchen. The Rational Unified Process. An Introduction. Addison-Wesley, 2000.
• Roger S. Pressman, Ingeniería del software, un enfoque práctico. Mc Grah-Hill, 7a. edició , 2010.
• A. Álvarez García, R. de las Heras del Dedo, C. Lasa Gómez, Métodos Ágiles y Scrum. Anaya
Multimedia, 2012.
• K. Pohl, C. Rupp. Requeriments Engineering Fundamentals. Rocky Nook Inc. 2011.

Since many materials are now online and more up-to-date than traditional bibliographic sources, links to freely
available documentation, video lectures, etc., will be provided throughout the course.

Software
ArgoUML (http://argouml.tigris.org/)
Eclipse (https://www.eclipse.org/ide/)

Language list

Name Group Language Semester Turn

(PAUL) Classroom practices English Second semester afternoon
(TE) Theory English Second semester afternoon