General information


Subject type: Mandatory

Coordinator: Alfonso Palacios González

Trimester: First term

Credits: 4

Teaching staff: 

Esteve Genovard Ferriol
Josep Roure Alcobé 
Eugeni Fernández González 

Skills


Basic skills
  • B2_That students know how to apply their knowledge to their job or vocation in a professional way and have the skills they demonstrate by developing and defending arguments and solving problems within their area of ​​study

  • B5_That students have developed those learning skills necessary to undertake further studies with a high degree of autonomy

Specific skills
  • EFB4_Basic knowledge of the use and programming of computers, operating systems, databases and computer programs with application in engineering

  • EIS1_Ability to develop, maintain and evaluate software services and systems that meet all user requirements and that behave reliably and efficiently, are affordable to develop and maintain and comply with quality standards, applying theories, principles, methods and software engineering practices

  • EIS4_Ability to identify and analyze problems and design, develop, implement, verify and document software solutions based on adequate knowledge of current theories, models and techniques

Transversal competences
  • T1_That students know a third language, which will be preferably English, with an adequate level of oral and written form, according to the needs of the graduates in each degree

  • T2_That students have the ability to work as members of an interdisciplinary team either as one more member, or performing management tasks in order to contribute to developing projects with pragmatism and a sense of responsibility, making commitments taking into account the available resources

Description


The subject d'Software Engineering 1 of the first term of the second year, is the first of three subjects called Software Engineering. Its teaching is designed to dedicate 3 ECTS to the theory part and 1 ECTS to practice the concepts exposed to theory.

This subject will introduce the concept of Software Engineering, emphasizing the ability of engineers to:

1.- Understand the requirements that reality presents to us.

2 .- "Divide the complexity" that express the requirements captured.

3.- Analyze and correctly model the target system

4.- Start with the first notions of design to implement source code.

 

Learning outcomes


  • Appropriately use theories, procedures and tools in the professional development of computer engineering in all its areas (specification, design, implementation, deployment -implantation- and product evaluation) so as to demonstrate an understanding of the commitments made in design decisions.
  • Demonstrate knowledge of the ethical dimension in the company: social and corporate responsibility in general and, in particular, the civil and professional responsibilities of IT engineers.
  • Use the tools of a software development environment to create and develop applications.
  • Demonstrate knowledge and know how to apply the appropriate techniques to model and analyze the different types of decisions.
  • Quality control and design testing in software production.
  • Define and manage the requirements of a software system.

      At a more specific level, at the end of the course students must be able to:

  • LO1 - Understand the stages required to build software based on the observation of reality (this includes what the user asks for)
  • LO2 - Understand perfectly why it is necessary to divide the complexity to tackle any software engineering project.
  • LO3 - Understand the requirements of a software system.
  • LO4 - Recognize the desirable properties of specifications.
  • LO5 - Analyze the system correctly.
  • LO6 - Model the system with UML notation.
  • LO7 - Create a model of the behavior of a system in UML notation.
  • LO8 - Transform the analysis model into a design model in UML notation.
  • LO9 - Apply basic design patterns (GRASP).

Working methodology


All the theoretical concepts of the subject will be treated in the theory classes (large groups) of the subject. In these classes the basic concepts of the analysis and design of the software are introduced showing their application with exercises solved by the teacher. It is recommended that students read the material published on the virtual platform before each session. In the classes the participation of the students will be asked individually or in group, to solve different problems proposed with or without anticipation. These activities, which due to their optional nature and brevity are not reflected in this document, will serve the student as a tool for self-assessment of the achievement of the contents of the subject and may be used by the teacher to make decisions. on the final grade of the student but never to the detriment of the numerical grade calculated according to the grading system indicated above.

The more practical concepts will be worked in small groups (laboratory) where works of medium complexity are presented, which require the application of the knowledge acquired in the most theoretical classes. These sessions will provide the appropriate tools to solve the scheduled activities but it is expected that these will be extended from a temporal point of view, beyond the laboratory hours and that, consequently, students will have to complete them during autonomous learning time.

 

Rules for carrying out the activities

For each activity, teachers will report on the particular rules and conditions that govern them.

One-on-one activities presuppose the student's commitment to carry them out individually. All activities in which the student does not comply with this commitment will be considered suspended, regardless of their role (origin or destination).

Likewise, the activities to be carried out in groups presuppose the commitment on the part of the students who make it up to carry them out within the group. All activities in which the group has not respected this commitment regardless of its role (origin or destination) will be considered suspended.

In group activities, the teacher can, based on the information available, customize the grade for each member of the group.

Any undelivered activity will be considered scored with zero points.

It is optional for teachers to accept or not deliveries outside the deadlines indicated. In the event that these late deliveries are accepted, it is up to the teacher to decide whether to apply a penalty and the amount thereof.

Contents


1. Introduction to Software Engineering

1.1 What is software engineering?

1.2 Particular features of the software.

1.3 Why do you need to make models?

1.4 Different software processes

1.5 Iterative Software Process.

1.6 UML-based Software Engineering

1.7 UML modeling tools

2. Software specification and requirements

2.1 Application specification and scope.

2.2 Definition, qualities and types of requirements.

2.3 Division of complexity.

2.4 A method for capturing requirements.

2.5 Use cases as an analysis tool

2.6 Study of use cases.

3. Domain model

3.1 The domain model

3.2 Use cases as part of the domain model.

3.3 Diagram of conceptual structures.

3.4 Classes, associations and attributes.

3.5 Aggregation and composition.

3.6 Associative class.

3.7 Class hierarchy.

3.8 Modeling guides.

 4. Design model

4.1 From the domain model to the design model.

4.2 Behavior model: interaction diagrams.

4.3 Behavior model: sequence diagrams

4.4 Design class diagrams.

4.5 Responsibility Assignment Patterns (GRASP)

 

5. Implementation Model

5.1 From design to implementation.

5.2 Coding of classes from the design class diagram.

5.3 Source code quality measures (cyclomatic complexity)

5.4 Deduction of methods from interaction diagrams.

5.5 Container classes

5.6 Order of implementation.

Learning activities


GENERAL EVALUATION CRITERIA

In order to pass the assessment activities proposed below, students must demonstrate

  • That they have acquired the theoretical knowledge related to the contents of the subject and that their understanding allows them to put them into practice.  [MECES-2 point a, point c] 
  • That have the ability to collect and interpret the requirements of a system on which to develop the necessary models [MECES-2 point c]
  • They can develop solutions to problems that, while similar to others seen above, have aspects that are new. [MECES-2 point f]

WEIGHTING

The practices as a whole represent 40% of the final mark, but the evaluation of them is based on the final level achieved by the student.

WORK EXPERIENCE

Practice 1

  • Each group is assigned a video explaining a set of very basic requirements.
  • Students must be able to understand the "limits" of what is being asked and the "context" that surrounds what is being asked.

Specific objectives: At the end of the activity, students must be able to write a document that explains the following:

  • That is asked.
  • That it must "be working" in order to be able to do what is requested.
  • An estimate of time in hours of what the job will bring (with no idea how to estimate).

Practice 1 will give evidence of the learning outcomes: RA1, RA3, RA4

Practice 2   

It is about analyzing the same statement from practice 1 but this time the result of the analysis must be more accurate.

Specific objectives: At the end of the activity students must be able to:

  • Specify the scope of the application.
  • State "all" requirements that will need to be implemented.
  • State "all" requirements that, although not to be implemented, are necessary. 
  • Draw the use case required by the practice document 1.

Practice 2 will give evidence of the learning outcomes: RA2, RA3, RA4, RA5

Practice 3   

It is about evolving the project that has been started with practice 2 to bring it to the design model of what is to be programmed.

Specific objectives: At the end of the activity students must be able to:

  • Provide a diagram with the main conceptual structures of the system.
  • List the main classes to be implemented in the system.
  • Make the basic class diagram of the system.
  • Make one of the necessary interaction diagram.
  • Make one of the necessary sequence diagrams.

Practice 3 will give evidence of the learning outcomes: RA6, RA7, RA8

Practice 4   

It is about evolving the project that was started with practice 2 to bring it to the point of coding.

Specific objectives: At the end of the activity students must be able to:

  • Class diagram reflecting the GRASP patterns that will be applied to the design created by the practice 3.
  • Implementation of the classes presented in the diagram of the previous point.
  • Calculation of the cyclomatic complexity of the longest method of all those that have been implemented.

Practice 4 will give evidence of the learning outcomes: RA6, RA7, RA8, RA9

Practices 1,2,3 and 4 1 and 2 have to do with the following common and specific competences (in brackets the most relevant aspects of each competence to which the subject contributes)

  • T2 (have the ability to work as a member of a team)
  • B5 (Develop your degree of autonomy)
  • CIN3 (Understand the importance of effective work habits)
  • B2 (Apply knowledge to their work)
  • CIN13 (Knowledge and application of tools)

PROVES

Test 1 Blocks 1, 2 and 3

Individual test of the theoretical concepts and practical procedures of the first three blocks of the subject.

This test represents 30% of the final grade of the subject.

Specific objectives: The aim of this activity is to assess whether the student:

  • Understands the concepts of Software Engineering.
  • You can explain "what is" a software process
  • He understands perfectly why it should be modeled as the basis of Software Engineering.
  • He knows how to divide the complexity of a small problem that is posed to him.
  • Understand that it is the domain model.
  • Understand the basic relationships between classes.

Test 1 will give evidence of the learning outcomes: RA1, RA2, RA3, RA4, RA5
 

Test 2 of blocks 4 and 5                                                                                    

Individual test of the theoretical concepts and practical procedures of blocks 4 and 5 of the subject.

This test represents 30% of the final grade of the subject.

Specific objectives: The aim of this activity is to assess whether the student:

  • He knows how to transform a specification model in UML into a design model.
  • Can create a class diagram.
  • Knows how to create a class interaction diagram.
  • Can create a class sequence diagram.
  • Knows how to apply basic GRASP patterns.
  • Can encode a class based on a class diagram.

Test 2 will give evidence of the learning outcomes: RA5, RA6, RA7, RA8, RA9

Tests 1 and 2 have to do with the following common and specific competences (in brackets the most relevant aspects of each competence to which the subject contributes)

  • CIN2 (Plan and conceive projects)
  • CIN4 (Prepare a technical specifications)
  • CIN5 (Knowledge of computer applications)
  • CIN8 (Ability to analyze and design applications robustly)
  • CIN16 (Knowledge and application of methodologies)
  • EIS1 (Develop software systems that meet user requirements)
  • EIS4
    • (PART1: Identify and analyze problems)
    • (PART2: design, develop, implement and verify software solutions)
  • EFB4 (Basic knowledge of the use and programming of computers)
  • C1N (Design and develop applications)
  • EFB4 (Basic knowledge of the use and programming of computers)
  • T1 (know a third language)


Reading and Comprehension (autonomous learning)

Reading and comprehension of chapters chosen by the teacher from the books of the bibliography and class material.

Support material: Books (available in the library) and course material.

The reading questionnaire will need to be answered.

Specific objectives: Understand and apply complex software engineering concepts from the reading and study of the material proposed by the teacher.

Evaluation system


The final grade will be calculated with the grades of the weighted activities as follows:

· Test 1: 30%

· Test 2: 30%

· Practices from 1 to 4: 40% (The final grade will be evaluated according to the level reached at the end of the learning process.)

With the above weights, laboratory practices weigh 40% and tests 60%.

Tests 1 and 2 can only be retaken in a single test of the whole subject (lpractices cannot be recovered). 60% of the final mark of the subject will be the highest between the recovery test and the one obtained in tests 1 and 2.

In order to take the recovery test, the student must meet the following three conditions:

. The grade of the subject is less than five.

. You have at least a three of the tests.

. You have at least a three internship.

In order to pass the subject, the mark of the practices must be 5 or higher, the mark of each of the exams must be 5 or higher. It is useless to have a 10 in one part of the subject and a 0 in the other because it is not averaged if the minimum has not been reached in all parts of the subject.

REFERENCES


Basic

Coad, Peter / Yourdon Edward. Object Oriented Analysis. 2nd. Yourdon Press, 1991. ISBN0-13-629981-4

Larman, Craig. UML and patterns: an introduction to analysis and object oriented design and the unified process. 2nd Prentice Hall, 2003. ISBN9788420534381.

Pressman, Roger S .. Software Engineering: a practical approach. 7. McGraw-Hill, 2010. ISBN 9786071503145.

Booch, Grady. Object Oriented Analysis and Design: with applications. 2nd. Addison Wesley / Diaz de Santos, 1996. ISBN0-201-60122-2.

Complementary

Farley, D. “Modern Software Engineering”. Addison-Wesley Professional, 2021. ISBN 978-0137314911