From b2d80610db6beda38573890ed169815e495bc663 Mon Sep 17 00:00:00 2001
From: Nguyễn Gia Phong <mcsinyx@disroot.org>
Date: Sun, 24 May 2020 16:34:31 +0700
Subject: [usth/ICT2.7] Engineer software

---
 .../1 - Introduction - lang_en.srt                 |   40 +
 .../10 - Software Development - lang_en.srt        |  108 ++
 .../11 - Software Process - lang_en.srt            |   96 ++
 .../12 - Preliminary Questions - lang_en.srt       |   32 +
 ... - Preliminary Questions Solution - lang_en.srt |   16 +
 .../14 - Preliminary Questions - lang_en.srt       |   24 +
 ... - Preliminary Questions Solution - lang_en.srt |   32 +
 .../16 - Software Phases - lang_en.srt             |  100 ++
 .../17 - Tools of the Trade - lang_en.srt          |  160 +++
 ...mportance of Software Engineering - lang_en.srt |  572 ++++++++++
 .../3 - Software Failure Quiz - lang_en.srt        |   32 +
 ... - Software Failure Quiz Solution - lang_en.srt |   48 +
 ...iscipline of Software Engineering - lang_en.srt |   80 ++
 .../6 - The Software Crisis - lang_en.srt          |  208 ++++
 .../7 - The Software Crisis Quiz - lang_en.srt     |   44 +
 ...The Software Crisis Quiz Solution - lang_en.srt |   52 +
 ...- Evidence of the Software Crisis - lang_en.srt |  116 +++
 ...Introduction with Barry Boehm - lang_en_vs7.srt |  163 +++
 ...re Process Model Introduction - lang_en_vs4.srt |   79 ++
 .../11 - Waterfall Process - lang_en_vs4.srt       |   95 ++
 .../12 - Spiral Process - lang_en_vs4.srt          |  191 ++++
 ...lutionary Prototyping Process - lang_en_vs4.srt |  167 +++
 ...lutionary Prototyping Process - lang_pt_vs2.srt |  167 +++
 ...14 - Rational Unified Process - lang_en_vs5.srt |  111 ++
 ...14 - Rational Unified Process - lang_pt_vs1.srt |  111 ++
 .../15 - Agile Process - lang_en_vs3.srt           |  123 +++
 .../15 - Agile Process - lang_pt_vs1.srt           |  123 +++
 .../16 - Choosing a Model - lang_en_vs4.srt        |  179 ++++
 .../17 - Choosing a Model Quiz - lang_en_vs4.srt   |   35 +
 ...hoosing a Model Quiz Solution - lang_en_vs5.srt |   47 +
 .../19 - Choosing a Model Quiz - lang_en_vs5.srt   |   11 +
 ...- Traditional Software Phases - lang_en_vs4.srt |   75 ++
 ...hoosing a Model Quiz Solution - lang_en_vs4.srt |   67 ++
 .../21 - Lifecycle Documents - lang_en_vs4.srt     |   67 ++
 ...22 - Classic Mistakes: People - lang_en_vs4.srt |  163 +++
 ...3 - Classic Mistakes: Process - lang_en_vs4.srt |   79 ++
 ...4 - Classic Mistakes: Product - lang_en_vs4.srt |   87 ++
 ... Classic Mistakes: Technology - lang_en_vs4.srt |   95 ++
 .../26 - Classic Mistakes Quiz - lang_en_vs4.srt   |   23 +
 ...lassic Mistakes Quiz Solution - lang_en_vs4.srt |   39 +
 .../3 - Requirements Engineering - lang_en_vs4.srt |  175 ++++
 .../4 - Design - lang_en_vs4.srt                   |  103 ++
 .../5 - Implementation - lang_en_vs5.srt           |  103 ++
 ...6 - Verification & Validation - lang_en_vs4.srt |  123 +++
 .../7 - Maintenance - lang_en_vs5.srt              |  167 +++
 .../8 - Software Phases Quiz - lang_en_vs4.srt     |   47 +
 ...Software Phases Quiz Solution - lang_en_vs4.srt |   15 +
 .../1 - Lesson Overview - lang_en_vs5.srt          |   39 +
 .../2 - Eclipse Introduction - lang_en_vs5.srt     |   91 ++
 .../3 - IDE Overview - lang_en_vs6.srt             |  143 +++
 .../4 - Plug-Ins - lang_en_vs5.srt                 |   99 ++
 ...pse Demo: Create Java Project - lang_en_vs5.srt |  323 ++++++
 ... Eclipse Demo: Create a Class - lang_en_vs6.srt |  135 +++
 ...lipse Demo: Run Configuration - lang_en_vs6.srt |  115 ++
 .../8 - Eclipse Demo: Debugging - lang_en_vs5.srt  |  275 +++++
 .../1 - Lesson Overview - lang_en_vs5.srt          |   43 +
 .../10 - Introduction to GIT - lang_en_vs6.srt     |   79 ++
 .../11 - Installing GIT - lang_en_vs5.srt          |   63 ++
 .../12 - GIT Workflow - lang_en_vs5.srt            |  507 +++++++++
 .../13 - GIT Demo: Intro to Git - lang_en_vs5.srt  | 1095 ++++++++++++++++++++
 .../14 - GIT Demo: Git + Eclipse - lang_en_vs5.srt |  307 ++++++
 .../15 - GIT Demo: Github - lang_en_vs3.srt        |  239 +++++
 .../16 - GIT Recap - lang_en_vs5.srt               |   35 +
 ...GIT Recap: Local Repositories - lang_en_vs5.srt |  163 +++
 ...IT Recap: Remote Repositories - lang_en_vs3.srt |   59 ++
 .../19 - GitHub Setup Assignment - lang_en_vs2.srt |   15 +
 .../19 - GitHub Setup Assignment - lang_pt_vs1.srt |   19 +
 ...- Interview with John Britton - lang_en_vs5.srt |  435 ++++++++
 ...n Control System Introduction - lang_en_vs5.srt |  207 ++++
 .../4 - VCS Quiz - lang_en_vs4.srt                 |   31 +
 .../5 - VCS Quiz Solution - lang_en_vs7.srt        |   11 +
 .../6 - Essential Actions - lang_en_vs5.srt        |   79 ++
 .../7 - Example Workflow - lang_en_vs5.srt         |  111 ++
 .../8 - \"Don'ts\" in VCS - lang_en_vs5.srt"       |  175 ++++
 .../9 - Two Main Types of VCS - lang_en_vs5.srt    |  163 +++
 .../1 - Gathering Requirements - lang_en_vs3.srt   |   63 ++
 .../2 - Choosing Good Questions - lang_en_vs3.srt  |   15 +
 ...osing Good Questions Solution - lang_en_vs3.srt |   55 +
 .../4 - Requirements Interview - lang_en_vs3.srt   |  323 ++++++
 ... Sentence Length Requirements - lang_en_vs3.srt |   83 ++
 .../1 - Lesson Overview - lang_en_vs4.srt          |   55 +
 .../10 - Completeness Quiz - lang_en_vs4.srt       |   15 +
 ... - Completeness Quiz Solution - lang_en_vs4.srt |   23 +
 ... Irrelevant Requirements Quiz - lang_en_vs4.srt |   43 +
 ...nt Requirements Quiz Solution - lang_en_vs5.srt |   63 ++
 .../14 - Best Practices - lang_en_vs5.srt          |   83 ++
 .../15 - RE Definition Breakdown - lang_en_vs4.srt |  207 ++++
 .../16 - Defining Requirements - lang_en_vs4.srt   |  219 ++++
 ... - Defining Requirements Quiz - lang_en_vs4.srt |   79 ++
 ...ng Requirements Quiz Solution - lang_en_vs5.srt |  103 ++
 ...nd Nonfunctional Requirements - lang_en_vs4.srt |  139 +++
 ...rview with Jane Cleland-Huang - lang_en_vs5.srt |  411 ++++++++
 ... User and System Requirements - lang_en_vs4.srt |  111 ++
 .../21 - Requirements Quiz - lang_en_vs4.srt       |   43 +
 ... - Requirements Quiz Solution - lang_en_vs4.srt |   63 ++
 .../23 - Requirement Origins - lang_en_vs4.srt     |   71 ++
 .../24 - Elicitation Problems - lang_en_vs4.srt    |  179 ++++
 .../25 - Traditional Techniques - lang_en_vs5.srt  |  207 ++++
 .../26 - Other Techniques - lang_en_vs5.srt        |   71 ++
 .../27 - Modeling Requirements - lang_en_vs4.srt   |  223 ++++
 .../28 - Analyzing Requirements - lang_en_vs4.srt  |  155 +++
 ...- Requirements Prioritization - lang_en_vs5.srt |   59 ++
 .../3 - General RE Definition - lang_en_vs4.srt    |  103 ++
 ...uirements Prioritization Quiz - lang_en_vs4.srt |   79 ++
 ... Prioritization Quiz Solution - lang_en_vs5.srt |  119 +++
 ...uirements Engineering Process - lang_en_vs4.srt |   99 ++
 .../33 - SRS - lang_en_vs5.srt                     |  183 ++++
 ... - Software Intensive Systems - lang_en_vs5.srt |  111 ++
 .../5 - Software Quality - lang_en_vs4.srt         |  111 ++
 .../6 - Identifying Purpose - lang_en_vs4.srt      |  107 ++
 ...- Completeness and Pertinence - lang_en_vs5.srt |  103 ++
 .../8 - Pertinence Quiz - lang_en_vs5.srt          |   35 +
 .../9 - Pertinence Quiz Solution - lang_en_vs4.srt |   75 ++
 .../1 - Lesson Overview - lang_en_vs4.srt          |   35 +
 ...odeling Classes Quiz Solution - lang_en_vs4.srt |   47 +
 ...- Running Example Explanation - lang_en_vs5.srt |  115 ++
 ...ural Diagrams:  Class Diagram - lang_en_vs4.srt |   47 +
 .../13 - Class Diagram: Class - lang_en_vs5.srt    |  259 +++++
 ...4 - Class Diagram: Attributes - lang_en_vs5.srt |  135 +++
 ...5 - Class Diagram: Operations - lang_en_vs5.srt |  111 ++
 ... Class Diagram: Relationships - lang_en_vs5.srt |  111 ++
 ...ss Diagram Relationships Quiz - lang_en_vs4.srt |   55 +
 ...m Relationships Quiz Solution - lang_en_vs5.srt |   23 +
 ...gram: Dependency Relationship - lang_en_vs4.srt |   71 ++
 ...ject Orientation Introduction - lang_en_vs5.srt |  187 ++++
 ...n & Aggregation Relationships - lang_en_vs5.srt |  219 ++++
 ...: Generalization Relationship - lang_en_vs5.srt |   75 ++
 ... Class Diagram: Creation Tips - lang_en_vs5.srt |  143 +++
 ...l Diagrams: Component Diagram - lang_en_vs5.srt |  235 +++++
 ...ructural Diagrams: Deployment - lang_en_vs4.srt |   95 ++
 ...Behavioral Diagrams: Use Case - lang_en_vs5.srt |  111 ++
 ...26 - Use Case Diagram: Actors - lang_en_vs5.srt |  167 +++
 ...- Building a Use Case Diagram - lang_en_vs5.srt |  203 ++++
 .../28 - Use Case Example - lang_en_vs5.srt        |  243 +++++
 .../29 - Role of Use Cases - lang_en_vs5.srt       |  151 +++
 .../3 - Objects and Classes - lang_en_vs5.srt      |   83 ++
 ...e Case Diagram: Creation Tips - lang_en_vs5.srt |  127 +++
 ...Behavioral Diagrams: Sequence - lang_en_vs5.srt |  227 ++++
 ...ams: State Transition Diagram - lang_en_vs5.srt |  175 ++++
 ...te Transition Diagram Example - lang_en_vs5.srt |  227 ++++
 .../34 - Recap Quiz - lang_en_vs4.srt              |   31 +
 .../35 - Recap Quiz Solution - lang_en_vs4.srt     |   47 +
 .../36 - Recap Quiz - lang_en_vs4.srt              |   15 +
 .../37 - Recap Quiz Solution - lang_en_vs4.srt     |   63 ++
 .../4 - Benefits of OO - lang_en_vs5.srt           |   51 +
 .../5 - OO Benefits Quiz - lang_en_vs4.srt         |   43 +
 ...6 - OO Benefits Quiz Solution - lang_en_vs4.srt |   71 ++
 .../7 - OO Analysis History - lang_en_vs4.srt      |  175 ++++
 .../8 - OO Analysis Overview - lang_en_vs4.srt     |  147 +++
 .../9 - Modeling Classes Quiz - lang_en_vs4.srt    |   35 +
 .../1 - Lesson Overview - lang_en_vs4.srt          |   47 +
 ...ctural Recovery Quiz Solution - lang_en_vs4.srt |   67 ++
 .../11 - Real World Example - lang_en_vs6.srt      |  183 ++++
 .../12 - More Examples - lang_en_vs6.srt           |  107 ++
 .../13 - Final Example - lang_en_vs4.srt           |  127 +++
 ...4 - Architectural Design Quiz - lang_en_vs4.srt |   31 +
 ...tectural Design Quiz Solution - lang_en_vs4.srt |  107 ++
 .../16 - Architectural Elements - lang_en_vs5.srt  |  115 ++
 ...onnectors, and Configurations - lang_en_vs5.srt |  111 ++
 .../18 - Configuration Example - lang_en_vs5.srt   |   75 ++
 ...ent Architectural Perspective - lang_en_vs5.srt |  103 ++
 ...terview with Nenad Medvidovic - lang_en_vs6.srt |  499 +++++++++
 .../20 - Architectural Styles - lang_en_vs5.srt    |  111 ++
 ...Types of Architectural Styles - lang_en_vs5.srt |  239 +++++
 ...2 - Architectural Styles Quiz - lang_en_vs4.srt |   27 +
 ...tectural Styles Quiz Solution - lang_en_vs5.srt |   79 ++
 .../24 - P2P Architectures - lang_en_vs5.srt       |   39 +
 .../25 - Napster Example - lang_en_vs4.srt         |  231 +++++
 .../26 - Skype Example - lang_en_vs5.srt           |  287 +++++
 .../27 - Takeaway Message - lang_en_vs5.srt        |  131 +++
 ...hat is Software Architecture? - lang_en_vs6.srt |  127 +++
 ...4 - General Definition of SWA - lang_en_vs6.srt |  131 +++
 ...e vs Descriptive Architecture - lang_en_vs5.srt |   51 +
 .../6 - Architectural Evolution - lang_en_vs5.srt  |  115 ++
 ...7 - Architectural Degradation - lang_en_vs6.srt |  131 +++
 .../8 - Architectural Recovery - lang_en_vs4.srt   |   67 ++
 ...- Architectural Recovery Quiz - lang_en_vs4.srt |   35 +
 .../1 - Introduction - lang_en.srt                 |   88 ++
 .../10 - Debriefing - lang_en.srt                  |  104 ++
 .../2 - Analyzing Requirements - lang_en.srt       |  579 +++++++++++
 ...- Refining Classes and Attributes - lang_en.srt |  535 ++++++++++
 .../4 - Adding Attributes - lang_en.srt            |  352 +++++++
 .../5 - Identifying Operations - lang_en.srt       |  304 ++++++
 .../6 - Adding Relationships - lang_en.srt         |  488 +++++++++
 .../7 - Refining Relationships - lang_en.srt       |  188 ++++
 .../8 - Refining the Class Diagram - lang_en.srt   |  328 ++++++
 .../9 - Final Considerations - lang_en.srt         |  196 ++++
 .../1 - Lesson Overview - lang_en_vs4.srt          |   31 +
 .../10 - Choosing a Pattern - lang_en_vs5.srt      |   95 ++
 .../11 - Choosing a Pattern Quiz - lang_en_vs4.srt |   31 +
 ...osing a Pattern Quiz Solution - lang_en_vs4.srt |   79 ++
 ...13 - Negative Design Patterns - lang_en_vs4.srt |   51 +
 ... - History of Design Patterns - lang_en_vs6.srt |  179 ++++
 .../3 - Patterns Catalogue - lang_en_vs4.srt       |   79 ++
 .../4 - Pattern Format - lang_en_vs5.srt           |   71 ++
 .../5 - Factory Method Pattern - lang_en_vs5.srt   |  179 ++++
 ...actory Method Pattern Example - lang_en_vs5.srt |  127 +++
 .../7 - Strategy Pattern - lang_en_vs5.srt         |  143 +++
 ...rategy Pattern Example & Demo - lang_en_vs5.srt |  511 +++++++++
 .../9 - Other Common Patterns - lang_en_vs5.srt    |  295 ++++++
 .../1 - Lesson Overview - lang_en_vs4.srt          |   31 +
 ...0 - Iterative and Incremental - lang_en_vs6.srt |  147 +++
 .../11 - Cycle Example - lang_en_vs6.srt           |  147 +++
 .../12 - Phases within a Cycle - lang_en_vs5.srt   |  199 ++++
 .../13 - Iterations - lang_en_vs5.srt              |   95 ++
 .../14 - Iterative Approach Quiz - lang_en_vs5.srt |   43 +
 ...rative Approach Quiz Solution - lang_en_vs5.srt |  179 ++++
 .../16 - Inception Phase - lang_en_vs4.srt         |  323 ++++++
 .../17 - Elaboration Phase - lang_en_vs5.srt       |  215 ++++
 .../18 - Construction Phase - lang_en_vs5.srt      |  247 +++++
 .../19 - Transition Phase - lang_en_vs5.srt        |  231 +++++
 .../2 - History of RUP - lang_en_vs6.srt           |  115 ++
 .../20 - Phases and Iterations - lang_en_vs4.srt   |  107 ++
 .../3 - Key Features of RUP - lang_en_vs6.srt      |  103 ++
 .../4 - UML Quiz - lang_en_vs5.srt                 |   47 +
 .../5 - UML Quiz Solution - lang_en_vs4.srt        |   15 +
 .../6 - UML Quiz - lang_en_vs6.srt                 |   39 +
 .../7 - UML Quiz Solution - lang_en_vs6.srt        |  143 +++
 .../8 - Use Case Driven - lang_en_vs5.srt          |   71 ++
 .../9 - Architecture Centric - lang_en_vs5.srt     |  131 +++
 .../1 - Lesson Overview - lang_en_vs5.srt          |   91 ++
 .../10 - Verification Approaches - lang_en_vs4.srt |  239 +++++
 ...- Pros and Cons of Approaches - lang_en_vs4.srt |  195 ++++
 ... Verification Approaches Quiz - lang_en_vs5.srt |   47 +
 ...tion Approaches Quiz Solution - lang_en_vs4.srt |   11 +
 .../14 - Testing Introduction - lang_en_vs4.srt    |  119 +++
 ... - Testing Granularity Levels - lang_en_vs4.srt |  275 +++++
 .../16 - Alpha and Beta Testing - lang_en_vs4.srt  |   95 ++
 ...hite Box Testing Introduction - lang_en_vs4.srt |  115 ++
 ...8 - Black Box Testing Example - lang_en_vs4.srt |  135 +++
 ...9 - White Box Testing Example - lang_en_vs4.srt |  143 +++
 .../2 - Introduction - lang_en_vs4.srt             |  103 ++
 ...3 - Failure, Fault, and Error - lang_en_vs4.srt |   79 ++
 ...ailure, Fault, and Error Quiz - lang_en_vs4.srt |   15 +
 ...ault, and Error Quiz Solution - lang_en_vs4.srt |   15 +
 ...ailure, Fault, and Error Quiz - lang_en_vs4.srt |   19 +
 ...ault, and Error Quiz Solution - lang_en_vs4.srt |   31 +
 ...ailure, Fault, and Error Quiz - lang_en_vs4.srt |   15 +
 ...ault, and Error Quiz Solution - lang_en_vs4.srt |   39 +
 .../1 - Lesson Overview - lang_en_vs4.srt          |   47 +
 ... Data Selection Quiz Solution - lang_en_vs4.srt |   79 ++
 .../11 - Why Not Random Testing? - lang_en_vs4.srt |  143 +++
 .../12 - Partition Testing - lang_en_vs4.srt       |   67 ++
 ...3 - Partition Testing Example - lang_en_vs4.srt |  167 +++
 .../14 - Boundary Values - lang_en_vs4.srt         |   55 +
 .../15 - Boundary Values Example - lang_en_vs4.srt |   99 ++
 ...ving Test Case Specifications - lang_en_vs4.srt |  199 ++++
 ...7 - Category Partition Method - lang_en_vs4.srt |   99 ++
 .../18 - Identify Categories - lang_en_vs4.srt     |  127 +++
 ...ition Categories into Choices - lang_en_vs4.srt |  151 +++
 .../2 - Overview - lang_en_vs4.srt                 |  103 ++
 ...ify Constraints Among Choices - lang_en_vs4.srt |  239 +++++
 ...uate Test Case Specifications - lang_en_vs4.srt |  111 ++
 ...from Test Case Specifications - lang_en_vs4.srt |   91 ++
 .../23 - Category Partition Demo - lang_en_vs4.srt |  867 ++++++++++++++++
 .../24 - Model Based Testing - lang_en_vs4.srt     |   83 ++
 .../25 - Finite State Machines - lang_en_vs4.srt   |  103 ++
 ...Finite State Machines Example - lang_en_vs4.srt |  251 +++++
 ...State Machines Considerations - lang_en_vs4.srt |   99 ++
 .../28 - Summary - lang_en_vs4.srt                 |   67 ++
 ...c Functional Testing Approach - lang_en_vs4.srt |  179 ++++
 .../4 - Overview Quiz - lang_en_vs4.srt            |   35 +
 .../5 - Overview Quiz Solution - lang_en_vs4.srt   |   15 +
 .../6 - Overview Quiz - lang_en_vs4.srt            |   19 +
 .../7 - Overview Quiz Solution - lang_en_vs4.srt   |   71 ++
 .../8 - Test Data Selection - lang_en_vs4.srt      |  103 ++
 .../9 - Test Data Selection Quiz - lang_en_vs4.srt |   31 +
 .../1 - Lesson Overview - lang_en_vs4.srt          |   47 +
 ...tement Coverage Quiz Solution - lang_en_vs7.srt |   31 +
 .../11 - Control Flow Graphs - lang_en_vs5.srt     |  167 +++
 .../12 - Branch Coverage - lang_en_vs3.srt         |  267 +++++
 .../13 - Condition Coverage - lang_en_vs4.srt      |  191 ++++
 .../14 - Subsumption Quiz - lang_en_vs4.srt        |   31 +
 ...5 - Subsumption Quiz Solution - lang_en_vs4.srt |    7 +
 ...Branch and Condition Coverage - lang_en_vs4.srt |  143 +++
 .../17 - Subsumption Quiz - lang_en_vs4.srt        |   15 +
 ...8 - Subsumption Quiz Solution - lang_en_vs4.srt |   19 +
 ...9 - Test Criteria Subsumption - lang_en_vs4.srt |   47 +
 .../2 - Overview - lang_en_vs4.srt                 |  167 +++
 .../20 - B&C Coverage Quiz - lang_en_vs4.srt       |   35 +
 ... - B&C Coverage Quiz Solution - lang_en_vs4.srt |   67 ++
 .../22 - MC DC Coverage - lang_en_vs4.srt          |  307 ++++++
 .../23 - Other Criteria - lang_en_vs4.srt          |  275 +++++
 .../24 - Review Quiz - lang_en_vs4.srt             |   63 ++
 .../25 - Review Quiz Solution - lang_en_vs4.srt    |    7 +
 .../26 - Review Quiz - lang_en_vs4.srt             |   15 +
 .../27 - Review Quiz Solution - lang_en_vs4.srt    |   55 +
 .../28 - Review Quiz - lang_en_vs4.srt             |   31 +
 .../29 - Review Quiz Solution - lang_en_vs4.srt    |  119 +++
 .../3 - Coverage Criteria Intro - lang_en_vs4.srt  |  171 +++
 .../30 - Summary - lang_en_vs4.srt                 |  127 +++
 ... Coverage Criteria Intro Quiz - lang_en_vs4.srt |   39 +
 ... Criteria Intro Quiz Solution - lang_en_vs4.srt |   47 +
 ... Coverage Criteria Intro Quiz - lang_en_vs3.srt |   63 ++
 ... Criteria Intro Quiz Solution - lang_en_vs4.srt |   87 ++
 .../8 - Statement Coverage - lang_en_vs4.srt       |  291 ++++++
 .../9 - Statement Coverage Quiz - lang_en_vs4.srt  |   15 +
 .../1 - Lesson Overview - lang_en_vs4.srt          |   75 ++
 .../10 - Refactoring - lang_en_vs4.srt             |  103 ++
 .../11 - Pair Programming - lang_en_vs4.srt        |   99 ++
 .../12 - Continuous Integration - lang_en_vs4.srt  |  111 ++
 .../13 - On Site Customer - lang_en_vs4.srt        |   55 +
 ...14 - Requirements Engineering - lang_en_vs4.srt |  139 +++
 .../15 - Testing Strategy - lang_en_vs4.srt        |  147 +++
 .../16 - Testing Strategy Quiz - lang_en_vs4.srt   |   47 +
 ...esting Strategy Quiz Solution - lang_en_vs4.srt |  127 +++
 .../18 - Scrum Intro - lang_en_vs4.srt             |   99 ++
 ...19 - High Level Scrum Process - lang_en_vs4.srt |  215 ++++
 .../2 - Cost of Change - lang_en_vs4.srt           |  207 ++++
 ... - Agile Software Development - lang_en_vs7.srt |  159 +++
 .../4 - Extreme Programming (XP) - lang_en_vs4.srt |  179 ++++
 ...es, Principles, and Practices - lang_en_vs4.srt |  151 +++
 .../6 - Incremental Planning - lang_en_vs4.srt     |   71 ++
 .../7 - Small Releases - lang_en_vs4.srt           |   95 ++
 .../8 - Simple Design - lang_en_vs4.srt            |   63 ++
 .../9 - Test First Development - lang_en_vs4.srt   |   59 ++
 .../1 - Lesson Overview - lang_en_vs4.srt          |   71 ++
 ...nditional Expression Solution - lang_en_vs3.srt |   55 +
 ...1 - Decompose Conditionals - lang_en-us_vs2.srt |  263 +++++
 .../11 - Decompose Conditionals - lang_en_vs8.srt  |  263 +++++
 .../12 - Extract Class - lang_en_vs4.srt           |   99 ++
 .../13 - Inline Class - lang_en_vs4.srt            |   75 ++
 .../14 - Extract Method - lang_en_vs4.srt          |  163 +++
 .../15 - Refactoring Demo - lang_en_vs4.srt        |  599 +++++++++++
 ...tract Method Refactoring Quiz - lang_en_vs5.srt |   31 +
 ...hod Refactoring Quiz Solution - lang_en_vs4.srt |   83 ++
 .../18 - Refactoring Risks - lang_en_vs4.srt       |  143 +++
 .../19 - Cost of Refactoring - lang_en_vs4.srt     |  127 +++
 .../2 - Introduction - lang_en_vs4.srt             |  127 +++
 .../20 - When Not To Refactor - lang_en_vs4.srt    |  103 ++
 .../21 - Bad Smells - lang_en_vs4.srt              |   99 ++
 .../22 - Bad Smell Examples - lang_en_vs4.srt      |  263 +++++
 .../23 - Bad Smell Quiz - lang_en_vs3.srt          |   31 +
 .../24 - Bad Smell Quiz Solution - lang_en_vs3.srt |   75 ++
 .../3 - Introduction - lang_en_vs4.srt             |   27 +
 .../4 - Introduction Solution - lang_en_vs4.srt    |   39 +
 .../5 - Reasons to Refactor - lang_en_vs4.srt      |  131 +++
 .../6 - History of Refactoring - lang_en_vs4.srt   |  171 +++
 .../7 - Types of Refactorings - lang_en_vs4.srt    |   43 +
 .../8 - Collapse Hierarchy - lang_en_vs4.srt       |   67 ++
 ...lidate Conditional Expression - lang_en_vs4.srt |  131 +++
 usth/ICT2.7/fuzzy-find                             |   26 +
 342 files changed, 43454 insertions(+)
 create mode 100644 usth/ICT2.7/P1L1 Introduction and Overview Subtitles/1 - Introduction - lang_en.srt
 create mode 100644 usth/ICT2.7/P1L1 Introduction and Overview Subtitles/10 - Software Development - lang_en.srt
 create mode 100644 usth/ICT2.7/P1L1 Introduction and Overview Subtitles/11 - Software Process - lang_en.srt
 create mode 100644 usth/ICT2.7/P1L1 Introduction and Overview Subtitles/12 - Preliminary Questions - lang_en.srt
 create mode 100644 usth/ICT2.7/P1L1 Introduction and Overview Subtitles/13 - Preliminary Questions Solution - lang_en.srt
 create mode 100644 usth/ICT2.7/P1L1 Introduction and Overview Subtitles/14 - Preliminary Questions - lang_en.srt
 create mode 100644 usth/ICT2.7/P1L1 Introduction and Overview Subtitles/15 - Preliminary Questions Solution - lang_en.srt
 create mode 100644 usth/ICT2.7/P1L1 Introduction and Overview Subtitles/16 - Software Phases - lang_en.srt
 create mode 100644 usth/ICT2.7/P1L1 Introduction and Overview Subtitles/17 - Tools of the Trade - lang_en.srt
 create mode 100644 usth/ICT2.7/P1L1 Introduction and Overview Subtitles/2 - Importance of Software Engineering - lang_en.srt
 create mode 100644 usth/ICT2.7/P1L1 Introduction and Overview Subtitles/3 - Software Failure Quiz - lang_en.srt
 create mode 100644 usth/ICT2.7/P1L1 Introduction and Overview Subtitles/4 - Software Failure Quiz Solution - lang_en.srt
 create mode 100644 usth/ICT2.7/P1L1 Introduction and Overview Subtitles/5 - Discipline of Software Engineering - lang_en.srt
 create mode 100644 usth/ICT2.7/P1L1 Introduction and Overview Subtitles/6 - The Software Crisis - lang_en.srt
 create mode 100644 usth/ICT2.7/P1L1 Introduction and Overview Subtitles/7 - The Software Crisis Quiz - lang_en.srt
 create mode 100644 usth/ICT2.7/P1L1 Introduction and Overview Subtitles/8 - The Software Crisis Quiz Solution - lang_en.srt
 create mode 100644 usth/ICT2.7/P1L1 Introduction and Overview Subtitles/9 - Evidence of the Software Crisis - lang_en.srt
 create mode 100644 usth/ICT2.7/P1L2 Life Cycle Models Subtitles/1 - Introduction with Barry Boehm - lang_en_vs7.srt
 create mode 100644 usth/ICT2.7/P1L2 Life Cycle Models Subtitles/10 - Software Process Model Introduction - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P1L2 Life Cycle Models Subtitles/11 - Waterfall Process - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P1L2 Life Cycle Models Subtitles/12 - Spiral Process - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P1L2 Life Cycle Models Subtitles/13 - Evolutionary Prototyping Process - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P1L2 Life Cycle Models Subtitles/13 - Evolutionary Prototyping Process - lang_pt_vs2.srt
 create mode 100644 usth/ICT2.7/P1L2 Life Cycle Models Subtitles/14 - Rational Unified Process - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P1L2 Life Cycle Models Subtitles/14 - Rational Unified Process - lang_pt_vs1.srt
 create mode 100644 usth/ICT2.7/P1L2 Life Cycle Models Subtitles/15 - Agile Process - lang_en_vs3.srt
 create mode 100644 usth/ICT2.7/P1L2 Life Cycle Models Subtitles/15 - Agile Process - lang_pt_vs1.srt
 create mode 100644 usth/ICT2.7/P1L2 Life Cycle Models Subtitles/16 - Choosing a Model - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P1L2 Life Cycle Models Subtitles/17 - Choosing a Model Quiz - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P1L2 Life Cycle Models Subtitles/18 - Choosing a Model Quiz Solution - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P1L2 Life Cycle Models Subtitles/19 - Choosing a Model Quiz - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P1L2 Life Cycle Models Subtitles/2 - Traditional Software Phases - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P1L2 Life Cycle Models Subtitles/20 - Choosing a Model Quiz Solution - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P1L2 Life Cycle Models Subtitles/21 - Lifecycle Documents - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P1L2 Life Cycle Models Subtitles/22 - Classic Mistakes: People - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P1L2 Life Cycle Models Subtitles/23 - Classic Mistakes: Process - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P1L2 Life Cycle Models Subtitles/24 - Classic Mistakes: Product - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P1L2 Life Cycle Models Subtitles/25 - Classic Mistakes: Technology - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P1L2 Life Cycle Models Subtitles/26 - Classic Mistakes Quiz - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P1L2 Life Cycle Models Subtitles/27 - Classic Mistakes Quiz Solution - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P1L2 Life Cycle Models Subtitles/3 - Requirements Engineering - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P1L2 Life Cycle Models Subtitles/4 - Design - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P1L2 Life Cycle Models Subtitles/5 - Implementation - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P1L2 Life Cycle Models Subtitles/6 - Verification & Validation - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P1L2 Life Cycle Models Subtitles/7 - Maintenance - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P1L2 Life Cycle Models Subtitles/8 - Software Phases Quiz - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P1L2 Life Cycle Models Subtitles/9 - Software Phases Quiz Solution - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P1L3 Integrated Development Environment Subtitles/1 - Lesson Overview - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P1L3 Integrated Development Environment Subtitles/2 - Eclipse Introduction - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P1L3 Integrated Development Environment Subtitles/3 - IDE Overview - lang_en_vs6.srt
 create mode 100644 usth/ICT2.7/P1L3 Integrated Development Environment Subtitles/4 - Plug-Ins - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P1L3 Integrated Development Environment Subtitles/5 - Eclipse Demo: Create Java Project - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P1L3 Integrated Development Environment Subtitles/6 - Eclipse Demo: Create a Class - lang_en_vs6.srt
 create mode 100644 usth/ICT2.7/P1L3 Integrated Development Environment Subtitles/7 - Eclipse Demo: Run Configuration - lang_en_vs6.srt
 create mode 100644 usth/ICT2.7/P1L3 Integrated Development Environment Subtitles/8 - Eclipse Demo: Debugging - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P1L4 Version Control Subtitles/1 - Lesson Overview - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P1L4 Version Control Subtitles/10 - Introduction to GIT - lang_en_vs6.srt
 create mode 100644 usth/ICT2.7/P1L4 Version Control Subtitles/11 - Installing GIT - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P1L4 Version Control Subtitles/12 - GIT Workflow - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P1L4 Version Control Subtitles/13 - GIT Demo: Intro to Git - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P1L4 Version Control Subtitles/14 - GIT Demo: Git + Eclipse - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P1L4 Version Control Subtitles/15 - GIT Demo: Github - lang_en_vs3.srt
 create mode 100644 usth/ICT2.7/P1L4 Version Control Subtitles/16 - GIT Recap - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P1L4 Version Control Subtitles/17 - GIT Recap: Local Repositories - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P1L4 Version Control Subtitles/18 - GIT Recap: Remote Repositories - lang_en_vs3.srt
 create mode 100644 usth/ICT2.7/P1L4 Version Control Subtitles/19 - GitHub Setup Assignment - lang_en_vs2.srt
 create mode 100644 usth/ICT2.7/P1L4 Version Control Subtitles/19 - GitHub Setup Assignment - lang_pt_vs1.srt
 create mode 100644 usth/ICT2.7/P1L4 Version Control Subtitles/2 - Interview with John Britton - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P1L4 Version Control Subtitles/3 - Version Control System Introduction - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P1L4 Version Control Subtitles/4 - VCS Quiz - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P1L4 Version Control Subtitles/5 - VCS Quiz Solution - lang_en_vs7.srt
 create mode 100644 usth/ICT2.7/P1L4 Version Control Subtitles/6 - Essential Actions - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P1L4 Version Control Subtitles/7 - Example Workflow - lang_en_vs5.srt
 create mode 100644 "usth/ICT2.7/P1L4 Version Control Subtitles/8 - \"Don'ts\" in VCS - lang_en_vs5.srt"
 create mode 100644 usth/ICT2.7/P1L4 Version Control Subtitles/9 - Two Main Types of VCS - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P1L5 Requirements Gathering Subtitles/1 - Gathering Requirements - lang_en_vs3.srt
 create mode 100644 usth/ICT2.7/P1L5 Requirements Gathering Subtitles/2 - Choosing Good Questions - lang_en_vs3.srt
 create mode 100644 usth/ICT2.7/P1L5 Requirements Gathering Subtitles/3 - Choosing Good Questions Solution - lang_en_vs3.srt
 create mode 100644 usth/ICT2.7/P1L5 Requirements Gathering Subtitles/4 - Requirements Interview - lang_en_vs3.srt
 create mode 100644 usth/ICT2.7/P1L5 Requirements Gathering Subtitles/5 - Average Sentence Length Requirements - lang_en_vs3.srt
 create mode 100644 usth/ICT2.7/P2L1 Requirements Engineering Subtitles/1 - Lesson Overview - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P2L1 Requirements Engineering Subtitles/10 - Completeness Quiz - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P2L1 Requirements Engineering Subtitles/11 - Completeness Quiz Solution - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P2L1 Requirements Engineering Subtitles/12 - Irrelevant Requirements Quiz - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P2L1 Requirements Engineering Subtitles/13 - Irrelevant Requirements Quiz Solution - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P2L1 Requirements Engineering Subtitles/14 - Best Practices - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P2L1 Requirements Engineering Subtitles/15 - RE Definition Breakdown - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P2L1 Requirements Engineering Subtitles/16 - Defining Requirements - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P2L1 Requirements Engineering Subtitles/17 - Defining Requirements Quiz - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P2L1 Requirements Engineering Subtitles/18 - Defining Requirements Quiz Solution - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P2L1 Requirements Engineering Subtitles/19 - Functional and Nonfunctional Requirements - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P2L1 Requirements Engineering Subtitles/2 - Interview with Jane Cleland-Huang - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P2L1 Requirements Engineering Subtitles/20 - User and System Requirements - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P2L1 Requirements Engineering Subtitles/21 - Requirements Quiz - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P2L1 Requirements Engineering Subtitles/22 - Requirements Quiz Solution - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P2L1 Requirements Engineering Subtitles/23 - Requirement Origins - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P2L1 Requirements Engineering Subtitles/24 - Elicitation Problems - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P2L1 Requirements Engineering Subtitles/25 - Traditional Techniques - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P2L1 Requirements Engineering Subtitles/26 - Other Techniques - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P2L1 Requirements Engineering Subtitles/27 - Modeling Requirements - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P2L1 Requirements Engineering Subtitles/28 - Analyzing Requirements - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P2L1 Requirements Engineering Subtitles/29 - Requirements Prioritization - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P2L1 Requirements Engineering Subtitles/3 - General RE Definition - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P2L1 Requirements Engineering Subtitles/30 - Requirements Prioritization Quiz - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P2L1 Requirements Engineering Subtitles/31 - Requirements Prioritization Quiz Solution - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P2L1 Requirements Engineering Subtitles/32 - Requirements Engineering Process - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P2L1 Requirements Engineering Subtitles/33 - SRS - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P2L1 Requirements Engineering Subtitles/4 - Software Intensive Systems - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P2L1 Requirements Engineering Subtitles/5 - Software Quality - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P2L1 Requirements Engineering Subtitles/6 - Identifying Purpose - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P2L1 Requirements Engineering Subtitles/7 - Completeness and Pertinence - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P2L1 Requirements Engineering Subtitles/8 - Pertinence Quiz - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P2L1 Requirements Engineering Subtitles/9 - Pertinence Quiz Solution - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/1 - Lesson Overview - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/10 - Modeling Classes Quiz Solution - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/11 - Running Example Explanation - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/12 - UML Structural Diagrams:  Class Diagram - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/13 - Class Diagram: Class - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/14 - Class Diagram: Attributes - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/15 - Class Diagram: Operations - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/16 - Class Diagram: Relationships - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/17 - Class Diagram Relationships Quiz - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/18 - Class Diagram Relationships Quiz Solution - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/19 - Class Diagram: Dependency Relationship - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/2 - Object Orientation Introduction - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/20 - Class Diagram: Association & Aggregation Relationships - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/21 - Class Diagram: Generalization Relationship - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/22 - Class Diagram: Creation Tips - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/23 - UML Structural Diagrams: Component Diagram - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/24 - UML Structural Diagrams: Deployment - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/25 - UML Behavioral Diagrams: Use Case - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/26 - Use Case Diagram: Actors - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/27 - Building a Use Case Diagram - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/28 - Use Case Example - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/29 - Role of Use Cases - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/3 - Objects and Classes - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/30 - Use Case Diagram: Creation Tips - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/31 - UML Behavioral Diagrams: Sequence - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/32 - UML Behavioral Diagrams: State Transition Diagram - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/33 - State Transition Diagram Example - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/34 - Recap Quiz - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/35 - Recap Quiz Solution - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/36 - Recap Quiz - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/37 - Recap Quiz Solution - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/4 - Benefits of OO - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/5 - OO Benefits Quiz - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/6 - OO Benefits Quiz Solution - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/7 - OO Analysis History - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/8 - OO Analysis Overview - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/9 - Modeling Classes Quiz - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/1 - Lesson Overview - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/10 - Architectural Recovery Quiz Solution - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/11 - Real World Example - lang_en_vs6.srt
 create mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/12 - More Examples - lang_en_vs6.srt
 create mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/13 - Final Example - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/14 - Architectural Design Quiz - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/15 - Architectural Design Quiz Solution - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/16 - Architectural Elements - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/17 - Components, Connectors, and Configurations - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/18 - Configuration Example - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/19 - Deployment Architectural Perspective - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/2 - Interview with Nenad Medvidovic - lang_en_vs6.srt
 create mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/20 - Architectural Styles - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/21 - Types of Architectural Styles - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/22 - Architectural Styles Quiz - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/23 - Architectural Styles Quiz Solution - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/24 - P2P Architectures - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/25 - Napster Example - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/26 - Skype Example - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/27 - Takeaway Message - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/3 - What is Software Architecture? - lang_en_vs6.srt
 create mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/4 - General Definition of SWA - lang_en_vs6.srt
 create mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/5 - Prescriptive vs Descriptive Architecture - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/6 - Architectural Evolution - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/7 - Architectural Degradation - lang_en_vs6.srt
 create mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/8 - Architectural Recovery - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/9 - Architectural Recovery Quiz - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/1 - Introduction - lang_en.srt
 create mode 100644 usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/10 - Debriefing - lang_en.srt
 create mode 100644 usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/2 - Analyzing Requirements - lang_en.srt
 create mode 100644 usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/3 - Refining Classes and Attributes - lang_en.srt
 create mode 100644 usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/4 - Adding Attributes - lang_en.srt
 create mode 100644 usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/5 - Identifying Operations - lang_en.srt
 create mode 100644 usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/6 - Adding Relationships - lang_en.srt
 create mode 100644 usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/7 - Refining Relationships - lang_en.srt
 create mode 100644 usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/8 - Refining the Class Diagram - lang_en.srt
 create mode 100644 usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/9 - Final Considerations - lang_en.srt
 create mode 100644 usth/ICT2.7/P3L3 Design Patterns Subtitles/1 - Lesson Overview - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P3L3 Design Patterns Subtitles/10 - Choosing a Pattern - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P3L3 Design Patterns Subtitles/11 - Choosing a Pattern Quiz - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P3L3 Design Patterns Subtitles/12 - Choosing a Pattern Quiz Solution - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P3L3 Design Patterns Subtitles/13 - Negative Design Patterns - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P3L3 Design Patterns Subtitles/2 - History of Design Patterns - lang_en_vs6.srt
 create mode 100644 usth/ICT2.7/P3L3 Design Patterns Subtitles/3 - Patterns Catalogue - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P3L3 Design Patterns Subtitles/4 - Pattern Format - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P3L3 Design Patterns Subtitles/5 - Factory Method Pattern - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P3L3 Design Patterns Subtitles/6 - Factory Method Pattern Example - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P3L3 Design Patterns Subtitles/7 - Strategy Pattern - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P3L3 Design Patterns Subtitles/8 - Strategy Pattern Example & Demo - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P3L3 Design Patterns Subtitles/9 - Other Common Patterns - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P3L4 Unified Software Process Subtitles/1 - Lesson Overview - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P3L4 Unified Software Process Subtitles/10 - Iterative and Incremental - lang_en_vs6.srt
 create mode 100644 usth/ICT2.7/P3L4 Unified Software Process Subtitles/11 - Cycle Example - lang_en_vs6.srt
 create mode 100644 usth/ICT2.7/P3L4 Unified Software Process Subtitles/12 - Phases within a Cycle - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P3L4 Unified Software Process Subtitles/13 - Iterations - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P3L4 Unified Software Process Subtitles/14 - Iterative Approach Quiz - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P3L4 Unified Software Process Subtitles/15 - Iterative Approach Quiz Solution - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P3L4 Unified Software Process Subtitles/16 - Inception Phase - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P3L4 Unified Software Process Subtitles/17 - Elaboration Phase - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P3L4 Unified Software Process Subtitles/18 - Construction Phase - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P3L4 Unified Software Process Subtitles/19 - Transition Phase - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P3L4 Unified Software Process Subtitles/2 - History of RUP - lang_en_vs6.srt
 create mode 100644 usth/ICT2.7/P3L4 Unified Software Process Subtitles/20 - Phases and Iterations - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P3L4 Unified Software Process Subtitles/3 - Key Features of RUP - lang_en_vs6.srt
 create mode 100644 usth/ICT2.7/P3L4 Unified Software Process Subtitles/4 - UML Quiz - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P3L4 Unified Software Process Subtitles/5 - UML Quiz Solution - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P3L4 Unified Software Process Subtitles/6 - UML Quiz - lang_en_vs6.srt
 create mode 100644 usth/ICT2.7/P3L4 Unified Software Process Subtitles/7 - UML Quiz Solution - lang_en_vs6.srt
 create mode 100644 usth/ICT2.7/P3L4 Unified Software Process Subtitles/8 - Use Case Driven - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P3L4 Unified Software Process Subtitles/9 - Architecture Centric - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P4L1 General Concepts Subtitles/1 - Lesson Overview - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P4L1 General Concepts Subtitles/10 - Verification Approaches - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L1 General Concepts Subtitles/11 - Pros and Cons of Approaches - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L1 General Concepts Subtitles/12 - Verification Approaches Quiz - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P4L1 General Concepts Subtitles/13 - Verification Approaches Quiz Solution - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L1 General Concepts Subtitles/14 - Testing Introduction - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L1 General Concepts Subtitles/15 - Testing Granularity Levels - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L1 General Concepts Subtitles/16 - Alpha and Beta Testing - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L1 General Concepts Subtitles/17 - Black and White Box Testing Introduction - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L1 General Concepts Subtitles/18 - Black Box Testing Example - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L1 General Concepts Subtitles/19 - White Box Testing Example - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L1 General Concepts Subtitles/2 - Introduction - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L1 General Concepts Subtitles/3 - Failure, Fault, and Error - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L1 General Concepts Subtitles/4 - Failure, Fault, and Error Quiz - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L1 General Concepts Subtitles/5 - Failure, Fault, and Error Quiz Solution - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L1 General Concepts Subtitles/6 - Failure, Fault, and Error Quiz - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L1 General Concepts Subtitles/7 - Failure, Fault, and Error Quiz Solution - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L1 General Concepts Subtitles/8 - Failure, Fault, and Error Quiz - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L1 General Concepts Subtitles/9 - Failure, Fault, and Error Quiz Solution - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L2 Black-Box Testing Subtitles/1 - Lesson Overview - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L2 Black-Box Testing Subtitles/10 - Test Data Selection Quiz Solution - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L2 Black-Box Testing Subtitles/11 - Why Not Random Testing? - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L2 Black-Box Testing Subtitles/12 - Partition Testing - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L2 Black-Box Testing Subtitles/13 - Partition Testing Example - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L2 Black-Box Testing Subtitles/14 - Boundary Values - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L2 Black-Box Testing Subtitles/15 - Boundary Values Example - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L2 Black-Box Testing Subtitles/16 - Deriving Test Case Specifications - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L2 Black-Box Testing Subtitles/17 - Category Partition Method - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L2 Black-Box Testing Subtitles/18 - Identify Categories - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L2 Black-Box Testing Subtitles/19 - Partition Categories into Choices - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L2 Black-Box Testing Subtitles/2 - Overview - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L2 Black-Box Testing Subtitles/20 - Identify Constraints Among Choices - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L2 Black-Box Testing Subtitles/21 - Produce and Evaluate Test Case Specifications - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L2 Black-Box Testing Subtitles/22 - Generate Test Cases from Test Case Specifications - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L2 Black-Box Testing Subtitles/23 - Category Partition Demo - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L2 Black-Box Testing Subtitles/24 - Model Based Testing - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L2 Black-Box Testing Subtitles/25 - Finite State Machines - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L2 Black-Box Testing Subtitles/26 - Finite State Machines Example - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L2 Black-Box Testing Subtitles/27 - Finite State Machines Considerations - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L2 Black-Box Testing Subtitles/28 - Summary - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L2 Black-Box Testing Subtitles/3 - Systematic Functional Testing Approach - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L2 Black-Box Testing Subtitles/4 - Overview Quiz - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L2 Black-Box Testing Subtitles/5 - Overview Quiz Solution - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L2 Black-Box Testing Subtitles/6 - Overview Quiz - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L2 Black-Box Testing Subtitles/7 - Overview Quiz Solution - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L2 Black-Box Testing Subtitles/8 - Test Data Selection - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L2 Black-Box Testing Subtitles/9 - Test Data Selection Quiz - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L3 White-Box Testing Subtitles/1 - Lesson Overview - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L3 White-Box Testing Subtitles/10 - Statement Coverage Quiz Solution - lang_en_vs7.srt
 create mode 100644 usth/ICT2.7/P4L3 White-Box Testing Subtitles/11 - Control Flow Graphs - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P4L3 White-Box Testing Subtitles/12 - Branch Coverage - lang_en_vs3.srt
 create mode 100644 usth/ICT2.7/P4L3 White-Box Testing Subtitles/13 - Condition Coverage - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L3 White-Box Testing Subtitles/14 - Subsumption Quiz - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L3 White-Box Testing Subtitles/15 - Subsumption Quiz Solution - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L3 White-Box Testing Subtitles/16 - Branch and Condition Coverage - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L3 White-Box Testing Subtitles/17 - Subsumption Quiz - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L3 White-Box Testing Subtitles/18 - Subsumption Quiz Solution - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L3 White-Box Testing Subtitles/19 - Test Criteria Subsumption - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L3 White-Box Testing Subtitles/2 - Overview - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L3 White-Box Testing Subtitles/20 - B&C Coverage Quiz - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L3 White-Box Testing Subtitles/21 - B&C Coverage Quiz Solution - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L3 White-Box Testing Subtitles/22 - MC DC Coverage - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L3 White-Box Testing Subtitles/23 - Other Criteria - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L3 White-Box Testing Subtitles/24 - Review Quiz - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L3 White-Box Testing Subtitles/25 - Review Quiz Solution - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L3 White-Box Testing Subtitles/26 - Review Quiz - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L3 White-Box Testing Subtitles/27 - Review Quiz Solution - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L3 White-Box Testing Subtitles/28 - Review Quiz - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L3 White-Box Testing Subtitles/29 - Review Quiz Solution - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L3 White-Box Testing Subtitles/3 - Coverage Criteria Intro - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L3 White-Box Testing Subtitles/30 - Summary - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L3 White-Box Testing Subtitles/4 - Coverage Criteria Intro Quiz - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L3 White-Box Testing Subtitles/5 - Coverage Criteria Intro Quiz Solution - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L3 White-Box Testing Subtitles/6 - Coverage Criteria Intro Quiz - lang_en_vs3.srt
 create mode 100644 usth/ICT2.7/P4L3 White-Box Testing Subtitles/7 - Coverage Criteria Intro Quiz Solution - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L3 White-Box Testing Subtitles/8 - Statement Coverage - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L3 White-Box Testing Subtitles/9 - Statement Coverage Quiz - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L4 Agile Development Methods Subtitles/1 - Lesson Overview - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L4 Agile Development Methods Subtitles/10 - Refactoring - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L4 Agile Development Methods Subtitles/11 - Pair Programming - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L4 Agile Development Methods Subtitles/12 - Continuous Integration - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L4 Agile Development Methods Subtitles/13 - On Site Customer - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L4 Agile Development Methods Subtitles/14 - Requirements Engineering - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L4 Agile Development Methods Subtitles/15 - Testing Strategy - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L4 Agile Development Methods Subtitles/16 - Testing Strategy Quiz - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L4 Agile Development Methods Subtitles/17 - Testing Strategy Quiz Solution - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L4 Agile Development Methods Subtitles/18 - Scrum Intro - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L4 Agile Development Methods Subtitles/19 - High Level Scrum Process - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L4 Agile Development Methods Subtitles/2 - Cost of Change - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L4 Agile Development Methods Subtitles/3 - Agile Software Development - lang_en_vs7.srt
 create mode 100644 usth/ICT2.7/P4L4 Agile Development Methods Subtitles/4 - Extreme Programming (XP) - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L4 Agile Development Methods Subtitles/5 - XP's Values, Principles, and Practices - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L4 Agile Development Methods Subtitles/6 - Incremental Planning - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L4 Agile Development Methods Subtitles/7 - Small Releases - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L4 Agile Development Methods Subtitles/8 - Simple Design - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L4 Agile Development Methods Subtitles/9 - Test First Development - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L5 Software Refactoring Subtitles/1 - Lesson Overview - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L5 Software Refactoring Subtitles/10 - Consolidate Conditional Expression Solution - lang_en_vs3.srt
 create mode 100644 usth/ICT2.7/P4L5 Software Refactoring Subtitles/11 - Decompose Conditionals - lang_en-us_vs2.srt
 create mode 100644 usth/ICT2.7/P4L5 Software Refactoring Subtitles/11 - Decompose Conditionals - lang_en_vs8.srt
 create mode 100644 usth/ICT2.7/P4L5 Software Refactoring Subtitles/12 - Extract Class - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L5 Software Refactoring Subtitles/13 - Inline Class - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L5 Software Refactoring Subtitles/14 - Extract Method - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L5 Software Refactoring Subtitles/15 - Refactoring Demo - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L5 Software Refactoring Subtitles/16 - Extract Method Refactoring Quiz - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P4L5 Software Refactoring Subtitles/17 - Extract Method Refactoring Quiz Solution - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L5 Software Refactoring Subtitles/18 - Refactoring Risks - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L5 Software Refactoring Subtitles/19 - Cost of Refactoring - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L5 Software Refactoring Subtitles/2 - Introduction - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L5 Software Refactoring Subtitles/20 - When Not To Refactor - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L5 Software Refactoring Subtitles/21 - Bad Smells - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L5 Software Refactoring Subtitles/22 - Bad Smell Examples - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L5 Software Refactoring Subtitles/23 - Bad Smell Quiz - lang_en_vs3.srt
 create mode 100644 usth/ICT2.7/P4L5 Software Refactoring Subtitles/24 - Bad Smell Quiz Solution - lang_en_vs3.srt
 create mode 100644 usth/ICT2.7/P4L5 Software Refactoring Subtitles/3 - Introduction - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L5 Software Refactoring Subtitles/4 - Introduction Solution - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L5 Software Refactoring Subtitles/5 - Reasons to Refactor - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L5 Software Refactoring Subtitles/6 - History of Refactoring - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L5 Software Refactoring Subtitles/7 - Types of Refactorings - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L5 Software Refactoring Subtitles/8 - Collapse Hierarchy - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P4L5 Software Refactoring Subtitles/9 - Consolidate Conditional Expression - lang_en_vs4.srt
 create mode 100755 usth/ICT2.7/fuzzy-find

(limited to 'usth')

diff --git a/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/1 - Introduction - lang_en.srt b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/1 - Introduction - lang_en.srt
new file mode 100644
index 0000000..aea69ae
--- /dev/null
+++ b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/1 - Introduction - lang_en.srt	
@@ -0,0 +1,40 @@
+1
+00:00:00,350 --> 00:00:03,570
+Hi, everybody, and welcome to the first lesson
+
+2
+00:00:03,570 --> 00:00:07,970
+of the Software Engineering Course. In this introductory lesson
+
+3
+00:00:07,970 --> 00:00:09,820
+I will first provide an overview of the
+
+4
+00:00:09,820 --> 00:00:13,100
+whole course and then try to answer two important
+
+5
+00:00:13,100 --> 00:00:16,630
+questions about software engineering, which are, what is
+
+6
+00:00:16,630 --> 00:00:20,310
+software engineering and why do we need it? And
+
+7
+00:00:20,310 --> 00:00:22,370
+to spice up the content a bit I
+
+8
+00:00:22,370 --> 00:00:25,480
+will also interview several experts in the software engineering
+
+9
+00:00:25,480 --> 00:00:30,080
+field from both academia and industry and ask them these
+
+10
+00:00:30,080 --> 00:00:34,410
+very questions. So without any further ado, let's begin the lesson.
+
diff --git a/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/10 - Software Development - lang_en.srt b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/10 - Software Development - lang_en.srt
new file mode 100644
index 0000000..b1f822e
--- /dev/null
+++ b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/10 - Software Development - lang_en.srt	
@@ -0,0 +1,108 @@
+1
+00:00:00,060 --> 00:00:01,970
+Now that we saw how software engineering was born and we
+
+2
+00:00:01,970 --> 00:00:04,580
+saw some of the problems that led to the birth of software
+
+3
+00:00:04,580 --> 00:00:07,020
+engineering. Let's see how we can do better. How can we
+
+4
+00:00:07,020 --> 00:00:10,580
+preform software development in a smarter, in a better way, a more
+
+5
+00:00:10,580 --> 00:00:13,150
+successful way? So what I'm going to show here is the
+
+6
+00:00:13,150 --> 00:00:14,730
+way I see software development. To
+
+7
+00:00:14,730 --> 00:00:17,080
+me software development is fundementally going
+
+8
+00:00:17,080 --> 00:00:21,150
+from an abstract idea in somebody's head, for example, the customer's head,
+
+9
+00:00:21,150 --> 00:00:25,300
+to a concrete system that actually implements that idea and hopefully it
+
+10
+00:00:25,300 --> 00:00:27,640
+does it in the right way. And this is a very
+
+11
+00:00:27,640 --> 00:00:31,290
+complex process. It can be overwhelming. So, unless we are talking about
+
+12
+00:00:31,290 --> 00:00:34,800
+the trivial system, it's very complex for us to keep in mind
+
+13
+00:00:34,800 --> 00:00:37,020
+all the different aspects of the systems, and to do all the
+
+14
+00:00:37,020 --> 00:00:40,270
+different steps required to build this system, automatically. So that's when
+
+15
+00:00:40,270 --> 00:00:43,630
+software processes come to the rescue. So what is a software process?
+
+16
+00:00:43,630 --> 00:00:46,380
+A software process is nothing else but a way of breaking down
+
+17
+00:00:46,380 --> 00:00:50,320
+this otherwise unmanageable task into smaller steps. In smaller steps that we
+
+18
+00:00:50,320 --> 00:00:53,270
+can handle. And that can be tackled individually. So having a
+
+19
+00:00:53,270 --> 00:00:56,580
+software process is of fundamental importance for several reasons. First of
+
+20
+00:00:56,580 --> 00:00:59,530
+all, for non-trivial systems, you can't just do it by getting
+
+21
+00:00:59,530 --> 00:01:01,680
+it, by just sitting down and developing. What you have to
+
+22
+00:01:01,680 --> 00:01:04,629
+do instead is to break down the complexity in a systematic
+
+23
+00:01:04,629 --> 00:01:08,250
+way. So software processes are normally systematic. And you need to
+
+24
+00:01:08,250 --> 00:01:11,370
+break down this complexity, in a more or less formal way.
+
+25
+00:01:11,370 --> 00:01:15,800
+So software processes are also a formal, or semiformal, way of
+
+26
+00:01:15,800 --> 00:01:19,120
+discussing, or describing, how software should be developed.
+
+27
+00:01:19,120 --> 00:01:21,370
+So what are the steps involved in developing software?
+
diff --git a/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/11 - Software Process - lang_en.srt b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/11 - Software Process - lang_en.srt
new file mode 100644
index 0000000..98592eb
--- /dev/null
+++ b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/11 - Software Process - lang_en.srt	
@@ -0,0 +1,96 @@
+1
+00:00:00,200 --> 00:00:02,580
+One thing you need to know right away about software processes
+
+2
+00:00:02,580 --> 00:00:05,750
+is that there's not just one single process, but there are multiple,
+
+3
+00:00:05,750 --> 00:00:08,840
+possible processes, depending on your context, depending on the kind of
+
+4
+00:00:08,840 --> 00:00:11,535
+applications that you are developing. In this course, we are going to try
+
+5
+00:00:11,535 --> 00:00:14,760
+to cover the spectrum of the possible processes, as much as
+
+6
+00:00:14,760 --> 00:00:18,900
+possible, by focusing on four main software processes. The first one is
+
+7
+00:00:18,900 --> 00:00:22,480
+what we call normally the waterfall process. And, we call it waterfall
+
+8
+00:00:22,480 --> 00:00:25,490
+because in the process we go from one phase to the other
+
+9
+00:00:25,490 --> 00:00:28,300
+in the same way in which water follows the flow
+
+10
+00:00:28,300 --> 00:00:30,910
+in a waterfall. The second process that we consider is what
+
+11
+00:00:30,910 --> 00:00:34,580
+we call evolutionary prototyping, and in this case, instead of
+
+12
+00:00:34,580 --> 00:00:37,790
+following this set of rigid steps, all we're trying to do
+
+13
+00:00:37,790 --> 00:00:40,930
+is to start with an initial prototype and evolve it
+
+14
+00:00:40,930 --> 00:00:43,670
+based on the feedback from the customer. We will then move
+
+15
+00:00:43,670 --> 00:00:47,150
+towards a slightly more formal process, which is the rational unified
+
+16
+00:00:47,150 --> 00:00:50,590
+process or the unified software process. And this is a kind
+
+17
+00:00:50,590 --> 00:00:53,040
+of project heavily based on the use of UML, so we
+
+18
+00:00:53,040 --> 00:00:56,263
+will also cover UML when discussing this kind of project. Finally,
+
+19
+00:00:56,263 --> 00:00:58,680
+the fourth kind of process we will consider is the family
+
+20
+00:00:58,680 --> 00:01:01,670
+of agile software processes. And these are processes in which we
+
+21
+00:01:01,670 --> 00:01:04,280
+sacrifice the discipline a little bi,t in order to be more
+
+22
+00:01:04,280 --> 00:01:07,380
+flexible and be more able to account for changes and in
+
+23
+00:01:07,380 --> 00:01:10,760
+particular for changes in requirements. We are going to cover each
+
+24
+00:01:10,760 --> 00:01:14,620
+one of these four processes extensively in the rest of the class.
+
diff --git a/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/12 - Preliminary Questions - lang_en.srt b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/12 - Preliminary Questions - lang_en.srt
new file mode 100644
index 0000000..20ef47f
--- /dev/null
+++ b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/12 - Preliminary Questions - lang_en.srt	
@@ -0,0 +1,32 @@
+1
+00:00:00,110 --> 00:00:01,450
+So, now before we actually jump to the
+
+2
+00:00:01,450 --> 00:00:03,410
+discussion of software processes I want to ask you
+
+3
+00:00:03,410 --> 00:00:05,770
+a couple of preliminary questions. The first one is,
+
+4
+00:00:05,770 --> 00:00:08,140
+what is the largest software system on which you
+
+5
+00:00:08,140 --> 00:00:10,860
+had worked? And you should enter here the size.
+
+6
+00:00:10,860 --> 00:00:12,850
+And the second question I'm going to ask is how
+
+7
+00:00:12,850 --> 00:00:15,070
+many LOC or how many lines of code per
+
+8
+00:00:15,070 --> 00:00:17,380
+day you were producing when working on this system?
+
diff --git a/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/13 - Preliminary Questions Solution - lang_en.srt b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/13 - Preliminary Questions Solution - lang_en.srt
new file mode 100644
index 0000000..fe239c6
--- /dev/null
+++ b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/13 - Preliminary Questions Solution - lang_en.srt	
@@ -0,0 +1,16 @@
+1
+00:00:00,110 --> 00:00:01,620
+We're going to go back to these two questions
+
+2
+00:00:01,620 --> 00:00:03,260
+and to your answers later. But I wanted to
+
+3
+00:00:03,260 --> 00:00:05,810
+gather this information beforehand, so that your answers are
+
+4
+00:00:05,810 --> 00:00:08,590
+not biased, they're not influenced by this subsequent discussion.
+
diff --git a/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/14 - Preliminary Questions - lang_en.srt b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/14 - Preliminary Questions - lang_en.srt
new file mode 100644
index 0000000..936b50d
--- /dev/null
+++ b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/14 - Preliminary Questions - lang_en.srt	
@@ -0,0 +1,24 @@
+1
+00:00:00,090 --> 00:00:03,200
+So now I want to ask you one additional question, which is how many lines
+
+2
+00:00:03,200 --> 00:00:05,030
+of code a day do you think professional
+
+3
+00:00:05,030 --> 00:00:07,370
+software engineers produce? Do you think they produce
+
+4
+00:00:07,370 --> 00:00:12,160
+25 lines of code? Between 25 and 50? Between 50 and 100? Between 100 and 1000?
+
+5
+00:00:12,160 --> 00:00:13,720
+Or more than 1000 a day? And remember
+
+6
+00:00:13,720 --> 00:00:16,379
+that here we're talking about professional software engineers.
+
diff --git a/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/15 - Preliminary Questions Solution - lang_en.srt b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/15 - Preliminary Questions Solution - lang_en.srt
new file mode 100644
index 0000000..1a040e2
--- /dev/null
+++ b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/15 - Preliminary Questions Solution - lang_en.srt	
@@ -0,0 +1,32 @@
+1
+00:00:00,180 --> 00:00:03,450
+Studies has shown that, on average, developers produce between
+
+2
+00:00:03,450 --> 00:00:07,030
+50 and 100 lines of code a day. And that
+
+3
+00:00:07,030 --> 00:00:09,530
+might not seem much. Why, why only 50 to
+
+4
+00:00:09,530 --> 00:00:11,580
+100 lines of code in a whole day? And the
+
+5
+00:00:11,580 --> 00:00:14,350
+answer is because coding is not everything. When you
+
+6
+00:00:14,350 --> 00:00:17,020
+develop a system writing code is not the only thing
+
+7
+00:00:17,020 --> 00:00:18,890
+you have to do. It's not the only activity that
+
+8
+00:00:18,890 --> 00:00:20,800
+you have to perform. And that's a very important point.
+
diff --git a/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/16 - Software Phases - lang_en.srt b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/16 - Software Phases - lang_en.srt
new file mode 100644
index 0000000..7fc30ef
--- /dev/null
+++ b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/16 - Software Phases - lang_en.srt	
@@ -0,0 +1,100 @@
+1
+00:00:00,110 --> 00:00:03,730
+In fact, software processes are normally characterized by several phases, what
+
+2
+00:00:03,730 --> 00:00:07,240
+we call the software phases, and only one of these phases is
+
+3
+00:00:07,240 --> 00:00:09,970
+mainly focused on coding. The other phases are meant to support
+
+4
+00:00:09,970 --> 00:00:13,440
+other parts of software development. The first of these phases is called
+
+5
+00:00:13,440 --> 00:00:16,110
+requirements engineering and that's the phase in which we talk to
+
+6
+00:00:16,110 --> 00:00:19,640
+the customer, to the stakeholders, whoever we are building the software for.
+
+7
+00:00:19,640 --> 00:00:22,120
+And we try to understand what kind of system we need
+
+8
+00:00:22,120 --> 00:00:25,650
+to build. Then we use this information to define our design and
+
+9
+00:00:25,650 --> 00:00:28,840
+the design is the high-level structure, that then can become more
+
+10
+00:00:28,840 --> 00:00:31,800
+and more detailed, of our software system. Once we've defined our
+
+11
+00:00:31,800 --> 00:00:34,180
+design we can actually move to the next phase, which is
+
+12
+00:00:34,180 --> 00:00:37,480
+the implementation, in which we write code that implements the design which
+
+13
+00:00:37,480 --> 00:00:40,630
+we just defined. After implementing the code, we need to verify
+
+14
+00:00:40,630 --> 00:00:43,510
+and validate the code. We need to make sure that the code
+
+15
+00:00:43,510 --> 00:00:46,930
+behaves as intended. And finally, we need to maintain the code.
+
+16
+00:00:46,930 --> 00:00:48,992
+And maintenance involves several activities like,
+
+17
+00:00:48,992 --> 00:00:50,980
+for example, adding new functionality or
+
+18
+00:00:50,980 --> 00:00:54,568
+eliminating bugs from the code or responding to problems that
+
+19
+00:00:54,568 --> 00:00:57,420
+were reported from the field after we released the software.
+
+20
+00:00:57,420 --> 00:00:59,020
+We will look at all of these activities and of
+
+21
+00:00:59,020 --> 00:01:01,670
+the software development process in detail, in the rest of the
+
+22
+00:01:01,670 --> 00:01:03,610
+class. And for each activity, we will look at the
+
+23
+00:01:03,610 --> 00:01:06,460
+fundamental principles and how it is done currently. And in
+
+24
+00:01:06,460 --> 00:01:08,780
+some cases, we will also look at some advance ways
+
+25
+00:01:08,780 --> 00:01:11,680
+to do it. For example, more research approaches for that activity.
+
diff --git a/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/17 - Tools of the Trade - lang_en.srt b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/17 - Tools of the Trade - lang_en.srt
new file mode 100644
index 0000000..077c0f8
--- /dev/null
+++ b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/17 - Tools of the Trade - lang_en.srt	
@@ -0,0 +1,160 @@
+1
+00:00:00,072 --> 00:00:02,960
+We will also look at how tools can improve software phases,
+
+2
+00:00:02,960 --> 00:00:06,660
+the software activities, and can support software development tasks in general.
+
+3
+00:00:06,660 --> 00:00:08,890
+And this is something that I will repeat over and over
+
+4
+00:00:08,890 --> 00:00:12,340
+in the class, tools and automation are fundamental, in software engineering.
+
+5
+00:00:12,340 --> 00:00:15,910
+And they're fundamental for improving productivity, not only efficiency but also
+
+6
+00:00:15,910 --> 00:00:19,820
+effectiveness of our activities in the software development process. So let
+
+7
+00:00:19,820 --> 00:00:22,110
+me go back to one of the diagrams that I showed
+
+8
+00:00:22,110 --> 00:00:25,170
+you before. If you remember we had this qualititive diagram in which
+
+9
+00:00:25,170 --> 00:00:27,170
+we were showing that one of the issues that led to the
+
+10
+00:00:27,170 --> 00:00:30,350
+software crisis was the fact that developers' productivity was not able to
+
+11
+00:00:30,350 --> 00:00:33,580
+keep up with the software size and complexity, with the growth in
+
+12
+00:00:33,580 --> 00:00:36,750
+the importance and the complexity of software. What tools can help us
+
+13
+00:00:36,750 --> 00:00:40,150
+to do is to change this and basically move this curve from
+
+14
+00:00:40,150 --> 00:00:43,950
+this original position up here. So that it gets closer and closer
+
+15
+00:00:43,950 --> 00:00:45,970
+to what we need to develop the software that we need to
+
+16
+00:00:45,970 --> 00:00:50,230
+build. So let me discuss examples on how tools can improve productivity.
+
+17
+00:00:50,230 --> 00:00:52,970
+For example, if we are talking about development, think about
+
+18
+00:00:52,970 --> 00:00:54,890
+what kind of improvement it was to go from punch
+
+19
+00:00:54,890 --> 00:00:58,440
+cards to modern IDEs. If we're talking about languages, think
+
+20
+00:00:58,440 --> 00:01:02,210
+about of how much more productive developers became when going from
+
+21
+00:01:02,210 --> 00:01:05,830
+writing machine code to writing code in high-level languages. And
+
+22
+00:01:05,830 --> 00:01:08,750
+finally, if we talk about debugging, which is a very important
+
+23
+00:01:08,750 --> 00:01:12,140
+and expensive activity, moving from the use of print lines
+
+24
+00:01:12,140 --> 00:01:16,060
+to the use of symbolic debuggers dramatically improve the effectiveness and
+
+25
+00:01:16,060 --> 00:01:18,810
+efficiency of development. And these are just some of the
+
+26
+00:01:18,810 --> 00:01:21,050
+tools that we will discuss in the rest of the class
+
+27
+00:01:21,050 --> 00:01:23,350
+and notice that we will also use the tools in practice.
+
+28
+00:01:23,350 --> 00:01:26,290
+So we will use the tools before projects and also during
+
+29
+00:01:26,290 --> 00:01:30,153
+the lessons and for assignments. In particular, we will use
+
+30
+00:01:30,153 --> 00:01:33,920
+three main kinds of tools. The first type is IDE's. And
+
+31
+00:01:33,920 --> 00:01:37,140
+I'm pretty sure you're familiar with IDE's. These are integrated development
+
+32
+00:01:37,140 --> 00:01:41,250
+environments. So, advanced editors in which you can write, compile, run,
+
+33
+00:01:41,250 --> 00:01:43,950
+and debug and even test your code. We'll also use a
+
+34
+00:01:43,950 --> 00:01:48,190
+version control system, systems that allow you to save, and restore, and
+
+35
+00:01:48,190 --> 00:01:51,750
+check the differences between different versions of the code, in particular
+
+36
+00:01:51,750 --> 00:01:53,950
+we will be working with git. We will also be looking at
+
+37
+00:01:53,950 --> 00:01:57,460
+other kinds of tools like coverage and verification tools. These are
+
+38
+00:01:57,460 --> 00:02:00,310
+tools that can help you during testing and I'm a big fan
+
+39
+00:02:00,310 --> 00:02:02,710
+of these tools, so I'm really going to stress the usefulness
+
+40
+00:02:02,710 --> 00:02:05,530
+of these tools and how you should use them in your development.
+
diff --git a/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/2 - Importance of Software Engineering - lang_en.srt b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/2 - Importance of Software Engineering - lang_en.srt
new file mode 100644
index 0000000..858a75a
--- /dev/null
+++ b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/2 - Importance of Software Engineering - lang_en.srt	
@@ -0,0 +1,572 @@
+1
+00:00:00,150 --> 00:00:02,106
+First, let me start by asking a couple of very
+
+2
+00:00:02,106 --> 00:00:04,820
+natural questions that you might have when considering whether to take
+
+3
+00:00:04,820 --> 00:00:07,800
+this course. The first one is what is software engineering.
+
+4
+00:00:07,800 --> 00:00:10,050
+And the second, very related one, is why do we need
+
+5
+00:00:10,050 --> 00:00:12,430
+it? So what I did was actually to go out
+
+6
+00:00:12,430 --> 00:00:15,430
+and ask some of the main experts in the field, both
+
+7
+00:00:15,430 --> 00:00:18,290
+in academia and industry, these very questions and let's see what
+
+8
+00:00:18,290 --> 00:00:22,160
+they said. What is software engineering and why is it important?
+
+9
+00:00:23,170 --> 00:00:25,150
+>> Okay, can I start with another question?
+
+10
+00:00:25,150 --> 00:00:26,020
+>> Of course.
+
+11
+00:00:26,020 --> 00:00:31,290
+>> Okay, first what is a computer? It's a programmable device. So the essence
+
+12
+00:00:31,290 --> 00:00:34,730
+of computing is programming. So program development
+
+13
+00:00:34,730 --> 00:00:37,240
+is basically the most essential use of the
+
+14
+00:00:37,240 --> 00:00:41,010
+computer. So software engineering is the discipline
+
+15
+00:00:41,010 --> 00:00:44,850
+that investigates program development. So, how can it
+
+16
+00:00:44,850 --> 00:00:47,390
+been done more efficiently? What's the best
+
+17
+00:00:47,390 --> 00:00:50,170
+way of doing program development? And how can
+
+18
+00:00:50,170 --> 00:00:53,140
+you develop reliable programs? So that's how I would define
+
+19
+00:00:53,140 --> 00:00:55,060
+it. But I consider any
+
+20
+00:00:55,060 --> 00:00:57,345
+software development activity software engineering activity
+
+21
+00:00:58,825 --> 00:01:04,239
+>> Software engineering is the systematic application of methods to build
+
+22
+00:01:04,239 --> 00:01:07,884
+software in a rigorous way. And I think one of the
+
+23
+00:01:07,884 --> 00:01:11,196
+aspects that I like to bring into the notion of software
+
+24
+00:01:11,196 --> 00:01:15,228
+engineering is that it's something that involves not only kind of
+
+25
+00:01:15,228 --> 00:01:18,612
+technically building the system but understanding the
+
+26
+00:01:18,612 --> 00:01:22,317
+requirements, working with stake holders. Trying to
+
+27
+00:01:22,317 --> 00:01:28,232
+find a solution that balances all of the stakeholder needs in order to deliver
+
+28
+00:01:28,232 --> 00:01:34,338
+the software thats tested and its rigorous to meet the needs of a stakeholder.
+
+29
+00:01:34,338 --> 00:01:37,656
+Well, software engineering is the whole process
+
+30
+00:01:37,656 --> 00:01:41,460
+of creation of software using engineering principles.
+
+31
+00:01:41,460 --> 00:01:42,886
+>> My view is kind of a holistic
+
+32
+00:01:42,886 --> 00:01:45,490
+view and I think about it from the perspective
+
+33
+00:01:45,490 --> 00:01:49,440
+of how is software engineering different from programming.
+
+34
+00:01:49,440 --> 00:01:52,940
+So, I think that research about programming is all
+
+35
+00:01:52,940 --> 00:01:57,550
+about the create part of software. And that
+
+36
+00:01:57,550 --> 00:02:00,270
+software engineering is about the entire life cycle. So,
+
+37
+00:02:00,270 --> 00:02:03,070
+that's one aspect. And the other aspect of the
+
+38
+00:02:03,070 --> 00:02:07,350
+definition is it's about quality, the quality of software.
+
+39
+00:02:07,350 --> 00:02:12,330
+Software engineering even considers things long after you ship which we all know
+
+40
+00:02:12,330 --> 00:02:18,310
+is one of the, it is the largest economic piece of software development.
+
+41
+00:02:18,310 --> 00:02:22,990
+>> So, improve, software engineering process
+
+42
+00:02:22,990 --> 00:02:26,440
+for better software productivity and quality.
+
+43
+00:02:26,440 --> 00:02:32,472
+>> The set of activities that one engages in when building software
+
+44
+00:02:32,472 --> 00:02:39,634
+systems or software products. It's fundamentally a venue-creating
+
+45
+00:02:39,634 --> 00:02:45,492
+activity. It involves social processes.
+
+46
+00:02:45,492 --> 00:02:47,247
+>> Software engineering is the act
+
+47
+00:02:47,247 --> 00:02:49,652
+of many people working together and putting
+
+48
+00:02:49,652 --> 00:02:52,057
+together many versions of large and complex
+
+49
+00:02:52,057 --> 00:02:57,110
+systems. And our world depends on software,
+
+50
+00:02:57,110 --> 00:02:58,910
+software is immensely complex and we need
+
+51
+00:02:58,910 --> 00:03:01,700
+many, many smart people to build these things.
+
+52
+00:03:01,700 --> 00:03:05,610
+>> Well, engineering I think is the activity of envisioning and
+
+53
+00:03:05,610 --> 00:03:10,180
+realizing valuable new functions with sufficient
+
+54
+00:03:10,180 --> 00:03:13,500
+and justifiable confidence that the resulting
+
+55
+00:03:13,500 --> 00:03:18,190
+system will have all of the critical quality attributes that are necessary
+
+56
+00:03:18,190 --> 00:03:22,140
+for the system to be a success. And software engineering is the
+
+57
+00:03:22,140 --> 00:03:24,790
+activity of doing this not only for
+
+58
+00:03:24,790 --> 00:03:27,550
+the software components of engineering systems but
+
+59
+00:03:28,830 --> 00:03:31,740
+for the system overall, given that it's
+
+60
+00:03:31,740 --> 00:03:35,500
+so heavily reliant on it's underlying software technologies.
+
+61
+00:03:35,500 --> 00:03:40,440
+>> So, I would say software engineering is the
+
+62
+00:03:40,440 --> 00:03:44,070
+kind of art and practice of building software systems.
+
+63
+00:03:44,070 --> 00:03:47,610
+>> Software engineering, in a nutshell, is a set of
+
+64
+00:03:47,610 --> 00:03:52,140
+methods and principles and techniques that we have developed to enable us to
+
+65
+00:03:53,220 --> 00:03:57,830
+engineer, or build, large software systems that
+
+66
+00:03:59,090 --> 00:04:03,960
+outstrip or outpace one engineer's or even a small
+
+67
+00:04:03,960 --> 00:04:08,900
+team of engineer's ability or abilities to understand
+
+68
+00:04:08,900 --> 00:04:13,330
+and construct and maintain
+
+69
+00:04:13,330 --> 00:04:17,339
+over time. So it requires a lot of people, it requires a long,
+
+70
+00:04:17,339 --> 00:04:21,820
+term investment by an organization or a number of organizations, and often times
+
+71
+00:04:21,820 --> 00:04:28,040
+it requires support for systems that that are intended for one purpose but end
+
+72
+00:04:28,040 --> 00:04:33,930
+up getting used for many additional purposes in addition to the original one.
+
+73
+00:04:33,930 --> 00:04:38,656
+>> Software engineering is about building and constructing very large-scale
+
+74
+00:04:38,656 --> 00:04:42,800
+high-quality systems, so the high quality is the big issue.
+
+75
+00:04:42,800 --> 00:04:46,268
+>> Software engineering is engineering discipline of developing
+
+76
+00:04:46,268 --> 00:04:52,800
+software-based systems, usually embedded into larger systems composed of
+
+77
+00:04:52,800 --> 00:04:58,544
+hardware and and humans [LAUGH] and business
+
+78
+00:04:58,544 --> 00:05:04,943
+processes and processes in general. And why is that important?
+
+79
+00:05:04,943 --> 00:05:06,971
+Well, because software is pervasive in all industry sectors
+
+80
+00:05:06,971 --> 00:05:09,001
+and therefore systems must be reliable, safe and secure.
+
+81
+00:05:09,001 --> 00:05:13,232
+>> Why can't we just get that by sitting down and writing software?
+
+82
+00:05:13,232 --> 00:05:16,697
+>> Well, you could if software was small and
+
+83
+00:05:16,697 --> 00:05:20,162
+simple enough to be developed by one or two
+
+84
+00:05:20,162 --> 00:05:25,360
+people together in a room. But software development now
+
+85
+00:05:25,360 --> 00:05:31,550
+is distributed, involves teams of people with different backgrounds
+
+86
+00:05:31,550 --> 00:05:37,450
+who have to communicate with each other. It also involves customers,
+
+87
+00:05:37,450 --> 00:05:42,512
+clients, users. Software engineers have to work with
+
+88
+00:05:42,512 --> 00:05:47,462
+hardware engineers, with domain experts and therefore,
+
+89
+00:05:47,462 --> 00:05:52,233
+well, no, we can't simply sit down and start coding.
+
+90
+00:05:52,233 --> 00:05:57,380
+>> Software engineering is mostly being able
+
+91
+00:05:57,380 --> 00:06:02,775
+to program. And you need to be able to put big
+
+92
+00:06:02,775 --> 00:06:06,920
+systems together so that they actually work. That's my simple definition.
+
+93
+00:06:06,920 --> 00:06:09,210
+>> And if you don't use software engineering practices,
+
+94
+00:06:09,210 --> 00:06:10,670
+you're not going to be able to put them together?
+
+95
+00:06:10,670 --> 00:06:13,290
+>> Well, you're not going to be able to reliably
+
+96
+00:06:13,290 --> 00:06:16,160
+put them together. So basically, you could maybe hack something up,
+
+97
+00:06:16,160 --> 00:06:18,750
+but it's not going to necessarily stand the test of time.
+
+98
+00:06:18,750 --> 00:06:21,221
+If somebody wants to change it it's probably going to break.
+
+99
+00:06:21,221 --> 00:06:24,140
+>> It's important
+
+100
+00:06:24,140 --> 00:06:29,700
+because if you don't think about how you're building this system and
+
+101
+00:06:29,700 --> 00:06:31,600
+how you're trading off different aspects,
+
+102
+00:06:31,600 --> 00:06:35,580
+like performance and scalability and reliability, then
+
+103
+00:06:35,580 --> 00:06:39,900
+it's going to end up breaking or not lasting very long or not,
+
+104
+00:06:39,900 --> 00:06:42,900
+not doing everything that you want it to do, or being really expensive.
+
+105
+00:06:43,960 --> 00:06:45,800
+>> If it's not done in a principled way it will
+
+106
+00:06:45,800 --> 00:06:49,220
+be bad and every user will suffer. That's why we need
+
+107
+00:06:49,220 --> 00:06:49,970
+software engineering.
+
+108
+00:06:49,970 --> 00:06:56,252
+>> Why is it important? Because, I mean these two goal, productivity, faster,
+
+109
+00:06:56,252 --> 00:06:59,480
+in developing software. And higher quality
+
+110
+00:06:59,480 --> 00:07:03,551
+would be apparently important. Software is everywhere.
+
+111
+00:07:03,551 --> 00:07:08,260
+>> It's important because we use software in everyday life. Everything's
+
+112
+00:07:08,260 --> 00:07:14,120
+built on software systems. And these are ubiquitous across our society.
+
+113
+00:07:14,120 --> 00:07:14,300
+>> It's
+
+114
+00:07:14,300 --> 00:07:20,820
+important because software is everywhere around us and the way we build it,
+
+115
+00:07:20,820 --> 00:07:26,910
+and the way we maintain it, is something that determines almost a basic
+
+116
+00:07:26,910 --> 00:07:33,940
+quality of life nowadays. And getting that software right can make a difference,
+
+117
+00:07:33,940 --> 00:07:39,590
+oftentimes, between a really fun product and one that you won't like to use
+
+118
+00:07:40,640 --> 00:07:45,750
+a reasonably successful company, or one that fails. And in
+
+119
+00:07:45,750 --> 00:07:49,690
+more extreme cases even the difference between life and death,
+
+120
+00:07:49,690 --> 00:07:51,510
+if you think about the software that runs in the
+
+121
+00:07:51,510 --> 00:07:56,380
+airplane on which many of you fly on a regular basis.
+
+122
+00:07:56,380 --> 00:08:00,790
+>> There are programs out there that if they screw up we are all screwed.
+
+123
+00:08:00,790 --> 00:08:02,440
+>> Software engineering is crucially
+
+124
+00:08:02,440 --> 00:08:06,460
+important because it's the engineering discipline
+
+125
+00:08:06,460 --> 00:08:10,250
+that is uniquely capable of carrying out
+
+126
+00:08:10,250 --> 00:08:13,848
+the engineering mission for software reliant systems.
+
+127
+00:08:13,848 --> 00:08:17,620
+>> In the U.S we've all seen an unfortunate example with
+
+128
+00:08:17,620 --> 00:08:23,032
+a system that went badly wrong in healthcare.gov and that system wasn't
+
+129
+00:08:23,032 --> 00:08:26,740
+engineered correctly. And I think if we look at the reasons for
+
+130
+00:08:26,740 --> 00:08:32,350
+that, they stem back to somewhere at the intersection between requirements and
+
+131
+00:08:32,350 --> 00:08:37,470
+architecture and politics and project management, and all of these things are
+
+132
+00:08:37,470 --> 00:08:43,270
+important concepts that have to go into the software engineering mix.
+
+133
+00:08:43,270 --> 00:08:45,570
+>> It would end up in lots and lots of chaos because people
+
+134
+00:08:45,570 --> 00:08:47,220
+wouldn't know how to organize themselves and
+
+135
+00:08:47,220 --> 00:08:49,400
+wouldn't know how to organize software. Many
+
+136
+00:08:49,400 --> 00:08:53,830
+of software engineering has very simple rules that you need to apply properly in
+
+137
+00:08:53,830 --> 00:08:57,280
+order to get things done. And people who look at these rules and think,
+
+138
+00:08:57,280 --> 00:09:01,050
+these rules are so super simple. This is totally obvious. But once
+
+139
+00:09:01,050 --> 00:09:05,495
+you try to apply them, you'll find out they're not obvious at all.
+
+140
+00:09:05,495 --> 00:09:07,670
+>> Now that we've heard these experts, let me show you an
+
+141
+00:09:07,670 --> 00:09:10,080
+example that illustrates what can happen
+
+142
+00:09:10,080 --> 00:09:12,410
+when software engineering practices are not suitably
+
+143
+00:09:15,310 --> 00:09:24,010
+applied. [NOISE].
+
diff --git a/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/3 - Software Failure Quiz - lang_en.srt b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/3 - Software Failure Quiz - lang_en.srt
new file mode 100644
index 0000000..f98f98f
--- /dev/null
+++ b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/3 - Software Failure Quiz - lang_en.srt	
@@ -0,0 +1,32 @@
+1
+00:00:00,110 --> 00:00:01,940
+Now that you watched this small video, I like
+
+2
+00:00:01,940 --> 00:00:03,660
+to ask you, what is this? Do you think
+
+3
+00:00:03,660 --> 00:00:06,330
+it's fireworks for the 4th of July celebration, or
+
+4
+00:00:06,330 --> 00:00:08,280
+maybe it was a flare gun in action, or
+
+5
+00:00:08,280 --> 00:00:10,240
+maybe again it was the explosion of the Ariane
+
+6
+00:00:10,240 --> 00:00:12,280
+five rocket due to a software error. What do
+
+7
+00:00:12,280 --> 00:00:14,190
+you think? And in case it helps, I'm also
+
+8
+00:00:14,190 --> 00:00:16,450
+going to show you an actual picture of this event.
+
diff --git a/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/4 - Software Failure Quiz Solution - lang_en.srt b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/4 - Software Failure Quiz Solution - lang_en.srt
new file mode 100644
index 0000000..db633e2
--- /dev/null
+++ b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/4 - Software Failure Quiz Solution - lang_en.srt	
@@ -0,0 +1,48 @@
+1
+00:00:00,100 --> 00:00:02,600
+As you probably guessed, these are not fireworks for the 4th of
+
+2
+00:00:02,600 --> 00:00:06,670
+July but, rather, the explosion of the Ariane 5, which happened 30 seconds
+
+3
+00:00:06,670 --> 00:00:09,250
+or so after takeoff due to a software error. And this is
+
+4
+00:00:09,250 --> 00:00:12,020
+just an example of what can go wrong when we don't build software
+
+5
+00:00:12,020 --> 00:00:15,600
+and we don't test and verify and perform quality assurance of software
+
+6
+00:00:15,600 --> 00:00:18,540
+in the right way, and quite an expensive one. In fact, to develop
+
+7
+00:00:18,540 --> 00:00:21,250
+and to build the Ariane 5 it took 10 years. The cost
+
+8
+00:00:21,250 --> 00:00:25,240
+was around $7 billion and there were $500 million of cargo on board.
+
+9
+00:00:25,240 --> 00:00:27,280
+Luckily, at least there were no humans on the
+
+10
+00:00:27,280 --> 00:00:29,400
+rocket. And you can find more details in case
+
+11
+00:00:29,400 --> 00:00:31,610
+you're interested about the Ariane 5 accident in the
+
+12
+00:00:31,610 --> 00:00:33,230
+lesson notes. I put a couple of links there.
+
diff --git a/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/5 - Discipline of Software Engineering - lang_en.srt b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/5 - Discipline of Software Engineering - lang_en.srt
new file mode 100644
index 0000000..6933222
--- /dev/null
+++ b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/5 - Discipline of Software Engineering - lang_en.srt	
@@ -0,0 +1,80 @@
+1
+00:00:00,140 --> 00:00:02,469
+And even if we don't go to these extreme examples, I'm
+
+2
+00:00:02,469 --> 00:00:04,380
+sure that you have all experienced
+
+3
+00:00:04,380 --> 00:00:06,540
+software problems, typically manifested in what
+
+4
+00:00:06,540 --> 00:00:09,630
+we call a crash. And that crash might happen while you're
+
+5
+00:00:09,630 --> 00:00:13,230
+finishing your homework or that three-page long email that you were preparing
+
+6
+00:00:13,230 --> 00:00:15,900
+for the last two hours. But why's it so difficult to
+
+7
+00:00:15,900 --> 00:00:20,220
+build software, or better, why's it so difficult to build good software?
+
+8
+00:00:20,220 --> 00:00:22,200
+And how can we do it? This is exactly the topic
+
+9
+00:00:22,200 --> 00:00:25,190
+of this class. And the reason why software engineering is a fundamental
+
+10
+00:00:25,190 --> 00:00:28,330
+discipline in computer science. To motivate that, in this class, we
+
+11
+00:00:28,330 --> 00:00:32,259
+will study a set of methodologies, techniques, and tools, that will help
+
+12
+00:00:32,259 --> 00:00:35,150
+us build high quality software that does what it's supposed to
+
+13
+00:00:35,150 --> 00:00:38,540
+do. And therefore, makes our customers happy. And that does it within
+
+14
+00:00:38,540 --> 00:00:42,375
+the given time and money constraints. So within the budget that
+
+15
+00:00:42,375 --> 00:00:44,300
+is allocated for the software. Before
+
+16
+00:00:44,300 --> 00:00:46,222
+jumping into today's software engineering techniques
+
+17
+00:00:46,222 --> 00:00:48,010
+though, let me take a step back and look at how
+
+18
+00:00:48,010 --> 00:00:50,240
+we got here, as I believe it is very important to have
+
+19
+00:00:50,240 --> 00:00:52,690
+some historical perspective on how this discipline was
+
+20
+00:00:52,690 --> 00:00:54,840
+born and how it was developed over the years.
+
diff --git a/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/6 - The Software Crisis - lang_en.srt b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/6 - The Software Crisis - lang_en.srt
new file mode 100644
index 0000000..41061a5
--- /dev/null
+++ b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/6 - The Software Crisis - lang_en.srt	
@@ -0,0 +1,208 @@
+1
+00:00:00,072 --> 00:00:02,190
+To do that we'll have to go back in time to
+
+2
+00:00:02,190 --> 00:00:05,280
+the late 60s. So what was happening in the 60s? Well for
+
+3
+00:00:05,280 --> 00:00:08,410
+example the first man landed on the moon. That was also
+
+4
+00:00:08,410 --> 00:00:11,720
+time when Woodstock took place and also the time when the first
+
+5
+00:00:11,720 --> 00:00:16,149
+60 second picture from Polaroid was created. Concurrently to these events,
+
+6
+00:00:16,149 --> 00:00:18,910
+which you probably didn't witness in first person, that was also the
+
+7
+00:00:18,910 --> 00:00:22,280
+time when people started to realize that they were not able
+
+8
+00:00:22,280 --> 00:00:25,610
+to build the software they needed. This happened for several reasons and
+
+9
+00:00:25,610 --> 00:00:29,220
+resulted in what we call the software crisis. So let's
+
+10
+00:00:29,220 --> 00:00:31,820
+look at some of the most important reasons behind this
+
+11
+00:00:31,820 --> 00:00:35,760
+crisis. The first cause was the rising demand for software.
+
+12
+00:00:35,760 --> 00:00:38,500
+Now you're used to see software everywhere: in your phone,
+
+13
+00:00:38,500 --> 00:00:41,530
+in your car, even your washing machine. Before the 60s,
+
+14
+00:00:41,530 --> 00:00:44,590
+however, the size and complexity of software was very limited
+
+15
+00:00:44,590 --> 00:00:47,580
+and hardware components were really dominating the scene. Then things
+
+16
+00:00:47,580 --> 00:00:51,490
+started to change and software started to be increasingly prevalent.
+
+17
+00:00:51,490 --> 00:00:53,940
+So we move from a situation where everything was mostly
+
+18
+00:00:53,940 --> 00:00:57,380
+hardware to a situation in which software became more and more
+
+19
+00:00:57,380 --> 00:01:00,660
+important. To give an example, I'm going to show you the growth
+
+20
+00:01:00,660 --> 00:01:04,080
+in the software demand at NASA along those years. And in
+
+21
+00:01:04,080 --> 00:01:07,610
+particular, from the 1950s to more or less 2000. And this
+
+22
+00:01:07,610 --> 00:01:10,350
+is just a qualitative plot but that's more or less the
+
+23
+00:01:10,350 --> 00:01:13,880
+ways things went. So the demand for software in NASA grow
+
+24
+00:01:13,880 --> 00:01:16,930
+exponentially. And the same happened in a lot of other companies.
+
+25
+00:01:16,930 --> 00:01:19,020
+For example, just to cite one, for Boeing. So the
+
+26
+00:01:19,020 --> 00:01:22,350
+amount of software on airplanes became larger and larger. The
+
+27
+00:01:22,350 --> 00:01:26,170
+second cause for the software crisis was the increasing amount
+
+28
+00:01:26,170 --> 00:01:30,210
+of development effort needed due to the increase of product complexity.
+
+29
+00:01:30,210 --> 00:01:34,260
+Unfortunately, software complexity does not increase linearly with size. It
+
+30
+00:01:34,260 --> 00:01:36,170
+is not the same thing to write software for a
+
+31
+00:01:36,170 --> 00:01:39,410
+class exercise or a small project, or a temp project,
+
+32
+00:01:39,410 --> 00:01:41,970
+than it is to build a software for a word processor,
+
+33
+00:01:41,970 --> 00:01:45,950
+an operating system, a distributed system, or even more complex and larger
+
+34
+00:01:45,950 --> 00:01:49,390
+system. And what I'm giving here is just an indicative size for
+
+35
+00:01:49,390 --> 00:01:52,643
+the software so the class exercise might be 100 lines of code,
+
+36
+00:01:52,643 --> 00:01:55,600
+the small project might be 1000 lines of code, in the other thousand
+
+37
+00:01:55,600 --> 00:01:58,328
+lines of code, and so on and so forth. For the former,
+
+38
+00:01:58,328 --> 00:02:01,510
+the heroic effort of an individual developer can get the job done.
+
+39
+00:02:01,510 --> 00:02:03,850
+So that's what we call a programming effort. If you're a good
+
+40
+00:02:03,850 --> 00:02:07,340
+programmer, you can go sit down and do it, right. For the latter,
+
+41
+00:02:07,340 --> 00:02:09,330
+this is not possible. This is what we called the
+
+42
+00:02:09,330 --> 00:02:13,810
+software engineering effort. In fact, no matter how much programming languages,
+
+43
+00:02:13,810 --> 00:02:17,280
+development environments, and software tools improve, developers could not keep
+
+44
+00:02:17,280 --> 00:02:20,220
+up with increasing software size and complexity. Which leads us to
+
+45
+00:02:20,220 --> 00:02:22,280
+the third problem that I want to mention and the
+
+46
+00:02:22,280 --> 00:02:25,020
+third reason for the software crisis. And this cause is the
+
+47
+00:02:25,020 --> 00:02:28,790
+slow developer's productivity growth. So let me show this again
+
+48
+00:02:28,790 --> 00:02:32,243
+with a qualitative diagram. And this is taken from the IEEE
+
+49
+00:02:32,243 --> 00:02:35,550
+Software Magazine. And what I'm showing here is the growth in
+
+50
+00:02:35,550 --> 00:02:39,930
+software size and complexity over time, and how the developers' productivity
+
+51
+00:02:39,930 --> 00:02:43,800
+really couldn't keep up with this additional software complexity, which resulted
+
+52
+00:02:43,800 --> 00:02:47,170
+in this gap between what was needed and what was actually available.
+
diff --git a/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/7 - The Software Crisis Quiz - lang_en.srt b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/7 - The Software Crisis Quiz - lang_en.srt
new file mode 100644
index 0000000..004a36c
--- /dev/null
+++ b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/7 - The Software Crisis Quiz - lang_en.srt	
@@ -0,0 +1,44 @@
+1
+00:00:00,078 --> 00:00:02,480
+So now let's take a quick break and have a recap
+
+2
+00:00:02,480 --> 00:00:05,300
+of what we just discussed. I want you to think about what
+
+3
+00:00:05,300 --> 00:00:07,850
+are the major causes of the software crisis. I'm going to provide you
+
+4
+00:00:07,850 --> 00:00:10,250
+a set of possibilities and I would like for you to mark
+
+5
+00:00:10,250 --> 00:00:14,160
+all that apply. Was that increasing costs of computers? Was it increasing
+
+6
+00:00:14,160 --> 00:00:17,990
+product complexity, or maybe the lack of programmers? Or was it, instead,
+
+7
+00:00:17,990 --> 00:00:20,000
+this slow programmers productivity growth? The
+
+8
+00:00:20,000 --> 00:00:21,540
+lack of funding for software engineering
+
+9
+00:00:21,540 --> 00:00:25,210
+research? The rise in demand for software? And finally, was it maybe
+
+10
+00:00:25,210 --> 00:00:26,500
+the lack of caffeine in software
+
+11
+00:00:26,500 --> 00:00:29,570
+development organizations? Again, mark all that apply.
+
diff --git a/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/8 - The Software Crisis Quiz Solution - lang_en.srt b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/8 - The Software Crisis Quiz Solution - lang_en.srt
new file mode 100644
index 0000000..33f5c6c
--- /dev/null
+++ b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/8 - The Software Crisis Quiz Solution - lang_en.srt	
@@ -0,0 +1,52 @@
+1
+00:00:00,090 --> 00:00:02,440
+So, if you think about what we just discussed. Definitely one
+
+2
+00:00:02,440 --> 00:00:06,210
+of the causes was the increasing product complexity. Products were becoming more
+
+3
+00:00:06,210 --> 00:00:09,510
+and more complex and software was replacing more and more, what
+
+4
+00:00:09,510 --> 00:00:11,860
+was before, provided by hardware components.
+
+5
+00:00:11,860 --> 00:00:14,160
+Slow productivity growth was another problem,
+
+6
+00:00:14,160 --> 00:00:17,350
+because programmers could not keep up with the additional complexity of
+
+7
+00:00:17,350 --> 00:00:19,720
+the software that they had to develop. I would like to say
+
+8
+00:00:19,720 --> 00:00:22,480
+there was lack of funding for software engineering research because I'm
+
+9
+00:00:22,480 --> 00:00:25,230
+a software engineering researcher, but that was not one of the reasons
+
+10
+00:00:25,230 --> 00:00:27,200
+for the software crisis. Instead, it was
+
+11
+00:00:27,200 --> 00:00:30,140
+the rising demand for software. Again, more
+
+12
+00:00:30,140 --> 00:00:32,060
+and more software was being required and
+
+13
+00:00:32,060 --> 00:00:33,850
+more and more software was replacing hardware.
+
diff --git a/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/9 - Evidence of the Software Crisis - lang_en.srt b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/9 - Evidence of the Software Crisis - lang_en.srt
new file mode 100644
index 0000000..0592078
--- /dev/null
+++ b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/9 - Evidence of the Software Crisis - lang_en.srt	
@@ -0,0 +1,116 @@
+1
+00:00:00,120 --> 00:00:03,220
+After recapping the three major issues that characterize a software crisis
+
+2
+00:00:03,220 --> 00:00:05,626
+let's see what was the evidence that there was indeed a
+
+3
+00:00:05,626 --> 00:00:07,900
+crisis. So what I want to discuss now is the result
+
+4
+00:00:07,900 --> 00:00:11,060
+of a study performed by Davis in 1990s. So in even
+
+5
+00:00:11,060 --> 00:00:13,670
+more recent times than the 60s and the 70s. And the
+
+6
+00:00:13,670 --> 00:00:17,280
+study was performed on nine software projects that were totaling a
+
+7
+00:00:17,280 --> 00:00:20,990
+cost around $7 million and I'm going to show you how this
+
+8
+00:00:20,990 --> 00:00:25,190
+projects went using this representation, this pi representation, in which I'm
+
+9
+00:00:25,190 --> 00:00:27,520
+going to discuss what each of the segment of the
+
+10
+00:00:27,520 --> 00:00:30,010
+pi represent. So let's start looking at the first one.
+
+11
+00:00:30,010 --> 00:00:32,920
+This is a software that was usable as delivered. Other
+
+12
+00:00:32,920 --> 00:00:36,590
+software was delivered, and usable, either after some changes or
+
+13
+00:00:36,590 --> 00:00:41,080
+after some major modifications, so within additional costs involved.
+
+14
+00:00:41,080 --> 00:00:43,530
+But the striking piece of information here is that the
+
+15
+00:00:43,530 --> 00:00:46,890
+vast majority of the software, so these two slices, were
+
+16
+00:00:46,890 --> 00:00:50,250
+software that was either delivered but never successfully used or
+
+17
+00:00:50,250 --> 00:00:53,730
+software that was not even delivered. And this corresponded
+
+18
+00:00:53,730 --> 00:00:57,500
+to five over the seven total million dollars for
+
+19
+00:00:57,500 --> 00:01:00,050
+all the projects. So clearly, this shows a pretty
+
+20
+00:01:00,050 --> 00:01:03,910
+grim picture for software development and its success. In short,
+
+21
+00:01:03,910 --> 00:01:06,410
+there was clear evidence the software was becoming to
+
+22
+00:01:06,410 --> 00:01:08,990
+difficult too build and that the software industry was facing
+
+23
+00:01:08,990 --> 00:01:11,190
+a crisis. And this is what led to the
+
+24
+00:01:11,190 --> 00:01:15,130
+NATO Software Engineering Conference that was held in January 1969,
+
+25
+00:01:15,130 --> 00:01:19,100
+which is what we can consider the birth of software engineering. And what
+
+26
+00:01:19,100 --> 00:01:23,080
+I'm showing here is a drawing of the proceedings for that conference. And if
+
+27
+00:01:23,080 --> 00:01:26,020
+you look at the class notes you can see a link to the actual
+
+28
+00:01:26,020 --> 00:01:27,640
+proceedings, in case you are interested in
+
+29
+00:01:27,640 --> 00:01:29,180
+looking at the issues that were discussed.
+
diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/1 - Introduction with Barry Boehm - lang_en_vs7.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/1 - Introduction with Barry Boehm - lang_en_vs7.srt
new file mode 100644
index 0000000..954db98
--- /dev/null
+++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/1 - Introduction with Barry Boehm - lang_en_vs7.srt	
@@ -0,0 +1,163 @@
+1
+00:00:00,430 --> 00:00:06,300
+Hi, in the last lesson we provided an overview of the course and motivated the
+
+2
+00:00:06,300 --> 00:00:09,570
+need for software engineering. In this lesson,
+
+3
+00:00:09,570 --> 00:00:13,090
+we will present and start discussing several traditional
+
+4
+00:00:13,090 --> 00:00:16,090
+software engineering life cycle models. We will
+
+5
+00:00:16,090 --> 00:00:18,790
+talk about their main advantages, and also about
+
+6
+00:00:18,790 --> 00:00:21,840
+their shortcomings. We will also talk about
+
+7
+00:00:21,840 --> 00:00:25,720
+classic mistakes in software engineering that is well
+
+8
+00:00:25,720 --> 00:00:29,530
+known ineffective development practices, that when
+
+9
+00:00:29,530 --> 00:00:32,590
+followed, tend to lead to better results. And
+
+10
+00:00:32,590 --> 00:00:35,120
+covering those, will hopefully help us to avoid
+
+11
+00:00:35,120 --> 00:00:38,350
+them in the future. And because in this
+
+12
+00:00:38,350 --> 00:00:41,290
+lesson, I will discuss some fundamental aspects of
+
+13
+00:00:41,290 --> 00:00:44,730
+software engineering, to suitably introduce these topics, I
+
+14
+00:00:44,730 --> 00:00:47,110
+went to the University of Southern California, to
+
+15
+00:00:47,110 --> 00:00:50,300
+interview one of the fathers of software engineering;
+
+16
+00:00:50,300 --> 00:00:53,070
+Professor Barry Boehm.
+
+17
+00:00:53,070 --> 00:00:59,060
+&gt;&gt; A well, a software life cycle is a sequence of, of decisions that you
+
+18
+00:00:59,060 --> 00:01:01,895
+make, and it's fundamentally those decisions are
+
+19
+00:01:01,895 --> 00:01:05,280
+going to be part of the history of the
+
+20
+00:01:05,280 --> 00:01:09,500
+software that. You are going to build that other people are going to use, and
+
+21
+00:01:09,500 --> 00:01:15,330
+the process model is basically answering the question of what do I do next and
+
+22
+00:01:15,330 --> 00:01:20,550
+how long shall I do it for. And again, because there are a lot of different ways
+
+23
+00:01:20,550 --> 00:01:24,220
+you can make that decision, you need to
+
+24
+00:01:24,220 --> 00:01:27,640
+figure out which models are good for which particular
+
+25
+00:01:27,640 --> 00:01:31,475
+situations. So, for example, we've, written a book
+
+26
+00:01:31,475 --> 00:01:34,846
+that's called Balancing Agility and Discipline. It says under
+
+27
+00:01:34,846 --> 00:01:37,835
+what conditions should you use agile methods, under
+
+28
+00:01:37,835 --> 00:01:40,824
+which conditions should you invest more time in analyzing
+
+29
+00:01:40,824 --> 00:01:44,826
+the situation and planning what you're going to do and the like. And so,
+
+30
+00:01:44,826 --> 00:01:49,866
+typically if the project is, is small where it's three to ten
+
+31
+00:01:49,866 --> 00:01:55,271
+people, agile works pretty well. If it's 300
+
+32
+00:01:55,271 --> 00:02:00,545
+people, then I think we don't want to go that way. If the affect of
+
+33
+00:02:00,545 --> 00:02:05,960
+the defect is loss of comfort or limited funds, then agile is fine,
+
+34
+00:02:05,960 --> 00:02:11,184
+but if it is a loss of life, then you don't. On the other hand if, if
+
+35
+00:02:11,184 --> 00:02:13,776
+you have a situation where you have lot
+
+36
+00:02:13,776 --> 00:02:17,745
+of unpredictable change, you really don't want to spend
+
+37
+00:02:17,745 --> 00:02:23,439
+a lot of time writing plans and lots of documents. In some cases you may have a
+
+38
+00:02:23,439 --> 00:02:26,907
+project where you want to do waterfall in
+
+39
+00:02:26,907 --> 00:02:31,140
+some parts and agile in others. So, these are
+
+40
+00:02:31,140 --> 00:02:36,180
+the kind of things that, that make the choice of life cycle process
+
+41
+00:02:36,180 --> 00:02:41,409
+model very important and very interesting as a subject of research.
diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/10 - Software Process Model Introduction - lang_en_vs4.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/10 - Software Process Model Introduction - lang_en_vs4.srt
new file mode 100644
index 0000000..39d418b
--- /dev/null
+++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/10 - Software Process Model Introduction - lang_en_vs4.srt	
@@ -0,0 +1,79 @@
+1
+00:00:00,240 --> 00:00:02,600
+At this point, you know the possible activities, the
+
+2
+00:00:02,600 --> 00:00:06,520
+possible phases performed during the software development process. But there
+
+3
+00:00:06,520 --> 00:00:08,710
+this something that we still haven't discussed, which is
+
+4
+00:00:08,710 --> 00:00:11,910
+very important. And that is how should we put these
+
+5
+00:00:11,910 --> 00:00:14,990
+activities together to develop software? And this all comes
+
+6
+00:00:14,990 --> 00:00:18,360
+down to the concept of software process model. Also called
+
+7
+00:00:18,360 --> 00:00:21,520
+software lifecycle model. And what this is, is a
+
+8
+00:00:21,520 --> 00:00:25,470
+prescriptive model of what should happen from the very beginning
+
+9
+00:00:25,470 --> 00:00:28,960
+to the very end. Of a software development process. The
+
+10
+00:00:28,960 --> 00:00:31,360
+main function of the life cycle model is to determine
+
+11
+00:00:31,360 --> 00:00:34,290
+the order of the different activities so that we know
+
+12
+00:00:34,290 --> 00:00:37,920
+which activities should come first and which ones should follow. Another
+
+13
+00:00:37,920 --> 00:00:40,910
+important function of the life cycle model is to determine
+
+14
+00:00:40,910 --> 00:00:45,290
+the transition criteria between activities. So, when we can go from
+
+15
+00:00:45,290 --> 00:00:48,000
+one phase to the subsequent one. In other words, what
+
+16
+00:00:48,000 --> 00:00:50,840
+the model should describe is what should we do next and
+
+17
+00:00:50,840 --> 00:00:53,450
+how long should we continue to do it for each activity
+
+18
+00:00:53,450 --> 00:00:56,290
+in the model. Now lets see a few traditional software process
+
+19
+00:00:56,290 --> 00:00:58,920
+models. I will discuss them here at the high level and
+
+20
+00:00:58,920 --> 00:01:02,000
+then revisit some of these models in the different mini courses.
diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/11 - Waterfall Process - lang_en_vs4.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/11 - Waterfall Process - lang_en_vs4.srt
new file mode 100644
index 0000000..b3d7c07
--- /dev/null
+++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/11 - Waterfall Process - lang_en_vs4.srt	
@@ -0,0 +1,95 @@
+1
+00:00:00,070 --> 00:00:02,830
+The first model we want to discuss is the grandfather of
+
+2
+00:00:02,830 --> 00:00:05,900
+all life cycle models. And it is the waterfall model. In
+
+3
+00:00:05,900 --> 00:00:08,890
+the waterfall model the project progresses to an orderly sequence of
+
+4
+00:00:08,890 --> 00:00:13,040
+steps. From the initial software concept, down until the final phase.
+
+5
+00:00:13,040 --> 00:00:16,110
+Which is system testing. And at the end of each phase
+
+6
+00:00:16,110 --> 00:00:18,510
+there will be a review to determine whether the project is
+
+7
+00:00:18,510 --> 00:00:22,120
+ready to advance to the next phase. The pure waterfall model
+
+8
+00:00:22,120 --> 00:00:25,340
+performs well for softer products in which there is a stable
+
+9
+00:00:25,340 --> 00:00:28,400
+product definition. The domain is well known and the technologies
+
+10
+00:00:28,400 --> 00:00:31,220
+involved are well understood. In these kind of domains, the
+
+11
+00:00:31,220 --> 00:00:34,350
+waterfall model helps you to find errors in the early,
+
+12
+00:00:34,350 --> 00:00:37,180
+local stages of the projects. If you remember what we discussed,
+
+13
+00:00:37,180 --> 00:00:39,950
+this is the place where we want to find errors,
+
+14
+00:00:39,950 --> 00:00:43,440
+not down here because finding them here will reduce the cost
+
+15
+00:00:43,440 --> 00:00:47,160
+of our overall software development. The main advantage of the
+
+16
+00:00:47,160 --> 00:00:50,930
+waterfall model is that it allows you to find errors early.
+
+17
+00:00:50,930 --> 00:00:53,910
+However, the main disadvantages of the waterfall model arise
+
+18
+00:00:53,910 --> 00:00:56,550
+from the fact that it is not flexible. Normally,
+
+19
+00:00:56,550 --> 00:00:59,520
+it is difficult to fully specify requirements at the
+
+20
+00:00:59,520 --> 00:01:02,470
+beginning of a project. And this lack of flexibility is
+
+21
+00:01:02,470 --> 00:01:04,800
+far from ideal when dealing with project in which
+
+22
+00:01:04,800 --> 00:01:07,310
+requirements change, the developers are not domain experts or
+
+23
+00:01:07,310 --> 00:01:11,130
+the technology used are new and evolving, that is
+
+24
+00:01:11,130 --> 00:01:14,440
+it is less than ideal for most real world projects.
diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/12 - Spiral Process - lang_en_vs4.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/12 - Spiral Process - lang_en_vs4.srt
new file mode 100644
index 0000000..2d0cdf9
--- /dev/null
+++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/12 - Spiral Process - lang_en_vs4.srt	
@@ -0,0 +1,191 @@
+1
+00:00:00,120 --> 00:00:02,600
+The next model that we will discuss is the spiral
+
+2
+00:00:02,600 --> 00:00:05,630
+model, which was first described by Barry Boehm, which is
+
+3
+00:00:05,630 --> 00:00:08,010
+the professor that we interviewed at the beginning of this
+
+4
+00:00:08,010 --> 00:00:12,240
+lesson. In his paper from 1986 that was entitled A Spiral
+
+5
+00:00:12,240 --> 00:00:15,730
+Model of Software Development and Enhancement. And one of the
+
+6
+00:00:15,730 --> 00:00:18,520
+main characteristics of that paper is that it was describing the
+
+7
+00:00:18,520 --> 00:00:21,670
+spiral model using a diagram, which is the one that
+
+8
+00:00:21,670 --> 00:00:25,130
+I'm showing you here, and this diagram has become very very
+
+9
+00:00:25,130 --> 00:00:27,950
+popular, and you probably saw it either in this
+
+10
+00:00:27,950 --> 00:00:30,400
+form or one of the many variations of the
+
+11
+00:00:30,400 --> 00:00:32,680
+diagram. So I'm not going to discuss all of
+
+12
+00:00:32,680 --> 00:00:34,770
+the details of the spiral model, but I just want to
+
+13
+00:00:34,770 --> 00:00:37,510
+give you an idea of its main characteristics. The
+
+14
+00:00:37,510 --> 00:00:41,580
+spiral model is an incremental risk-oriented lifecycle model that has
+
+15
+00:00:41,580 --> 00:00:46,330
+four main phases listed here: determine objectives, identify and
+
+16
+00:00:46,330 --> 00:00:51,180
+resolve risks, development and tests, and plan the next iteration.
+
+17
+00:00:51,180 --> 00:00:53,690
+A software project will go through these four phases in
+
+18
+00:00:53,690 --> 00:00:57,020
+an iterative way. In the first phase, the requirements will
+
+19
+00:00:57,020 --> 00:00:59,470
+be gathered. In the second phase, the risks and the
+
+20
+00:00:59,470 --> 00:01:04,010
+alternate solutions will be identified, and a prototype will be produced.
+
+21
+00:01:04,010 --> 00:01:06,190
+Software and tests for the software are produced in the
+
+22
+00:01:06,190 --> 00:01:09,210
+development and test phase, which is the third step of the
+
+23
+00:01:09,210 --> 00:01:12,830
+process. Finally, in the fourth phase, the output of the
+
+24
+00:01:12,830 --> 00:01:16,880
+project, so far, is evaluated, and the next iteration is planned.
+
+25
+00:01:16,880 --> 00:01:19,960
+So basically, what the spiral process prescribes is a
+
+26
+00:01:19,960 --> 00:01:23,262
+way of developing software by going through these phases in
+
+27
+00:01:23,262 --> 00:01:26,020
+an iterative way, in which we learn more and more
+
+28
+00:01:26,020 --> 00:01:29,420
+of the software, we identify more and more, and account
+
+29
+00:01:29,420 --> 00:01:32,250
+for, more and more risks and we go more
+
+30
+00:01:32,250 --> 00:01:36,000
+and more towards our final solution, our final release. There
+
+31
+00:01:36,000 --> 00:01:38,930
+are several advantages of using a spiral model. The first
+
+32
+00:01:38,930 --> 00:01:41,930
+one is that the extensive risk analysis does reduce the
+
+33
+00:01:41,930 --> 00:01:44,140
+chances of the project to fail. So there is a
+
+34
+00:01:44,140 --> 00:01:48,300
+risk reduction advantage. The second advantage is that functionality can be
+
+35
+00:01:48,300 --> 00:01:51,190
+added at a later phase because of the iterative nature of
+
+36
+00:01:51,190 --> 00:01:55,175
+the process. And finally, software is produced early in the software
+
+37
+00:01:55,175 --> 00:01:58,260
+lifecycle. So, at any iteration, we have something to show
+
+38
+00:01:58,260 --> 00:02:01,300
+for our development. We don't wait until the end before producing
+
+39
+00:02:01,300 --> 00:02:03,790
+something. And then of course there's also the advantage that we
+
+40
+00:02:03,790 --> 00:02:07,190
+can get early feedback from the customer about what we produced.
+
+41
+00:02:07,190 --> 00:02:09,000
+The main disadvantages on the other hand of
+
+42
+00:02:09,000 --> 00:02:11,870
+the spiral model, are that the risk analysis requires
+
+43
+00:02:11,870 --> 00:02:16,560
+a highly specific expertise. And unfortunately, the whole success
+
+44
+00:02:16,560 --> 00:02:19,260
+of the process is highly dependent on risk analysis.
+
+45
+00:02:19,260 --> 00:02:21,580
+So risk analysis has to be done right.
+
+46
+00:02:21,580 --> 00:02:24,510
+And finally the spiral model is way more complex
+
+47
+00:02:24,510 --> 00:02:27,180
+than other models, like for example, the water fall
+
+48
+00:02:27,180 --> 00:02:29,760
+model. And therefore it can be costly to implement.
diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/13 - Evolutionary Prototyping Process - lang_en_vs4.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/13 - Evolutionary Prototyping Process - lang_en_vs4.srt
new file mode 100644
index 0000000..cf068c0
--- /dev/null
+++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/13 - Evolutionary Prototyping Process - lang_en_vs4.srt	
@@ -0,0 +1,167 @@
+1
+00:00:00,080 --> 00:00:02,430
+The next process model I want to discuss is evolutionary
+
+2
+00:00:02,430 --> 00:00:05,786
+prototyping, which works in four main phases. We start
+
+3
+00:00:05,786 --> 00:00:08,393
+from an initial concept, then we design and implement
+
+4
+00:00:08,393 --> 00:00:11,509
+a prototype based on this initial concept, refine the prototype
+
+5
+00:00:11,509 --> 00:00:14,002
+until it is acceptable, and finally we complete and
+
+6
+00:00:14,002 --> 00:00:17,550
+release the prototype. Therefore, when developing a system using
+
+7
+00:00:17,550 --> 00:00:22,330
+evolutionary prototyping, the system is continually refined and rebuilt.
+
+8
+00:00:22,330 --> 00:00:25,340
+So it is an ideal process when not all requirements
+
+9
+00:00:25,340 --> 00:00:28,330
+are well understood. Which is a very common situation. So, looking
+
+10
+00:00:28,330 --> 00:00:30,370
+at this in a little more details, what happens is that
+
+11
+00:00:30,370 --> 00:00:33,760
+developers start by developing the parts of the system that they
+
+12
+00:00:33,760 --> 00:00:37,690
+understand, instead of working on developing a whole system, including parts
+
+13
+00:00:37,690 --> 00:00:40,520
+that might not be very clear at that stage. The partial
+
+14
+00:00:40,520 --> 00:00:43,900
+system is then shown to the customer and the customer feedback
+
+15
+00:00:43,900 --> 00:00:47,480
+is used to drive the next iteration, in which either changes
+
+16
+00:00:47,480 --> 00:00:50,340
+are made to the current features or new features are added.
+
+17
+00:00:50,340 --> 00:00:53,060
+So, either the current prototype is improved or the
+
+18
+00:00:53,060 --> 00:00:56,270
+prototype is extended. And finally, when the customer agrees that
+
+19
+00:00:56,270 --> 00:00:58,980
+the prototype is good enough, the developers will complete all
+
+20
+00:00:58,980 --> 00:01:01,410
+the remaining work on the system and release the prototype
+
+21
+00:01:01,410 --> 00:01:03,930
+as the final product. So let's discuss as we did
+
+22
+00:01:03,930 --> 00:01:06,780
+for the previous process models, what are the main advantages
+
+23
+00:01:06,780 --> 00:01:10,580
+and disadvantages of evolutionary prototyping. In this case, the main
+
+24
+00:01:10,580 --> 00:01:15,440
+advantage is the immediate feedback. Developers get feedback immediately as
+
+25
+00:01:15,440 --> 00:01:17,560
+soon as they produce a prototype and they show it to
+
+26
+00:01:17,560 --> 00:01:21,050
+the customer and therefore, the risk of implementing the wrong system is
+
+27
+00:01:21,050 --> 00:01:25,150
+minimized. The main negative is the fact that it's difficult to plan.
+
+28
+00:01:25,150 --> 00:01:29,070
+When using evolutionary prototype it is difficult to plan in advance how
+
+29
+00:01:29,070 --> 00:01:31,240
+long the development is going to take, because we don't know how
+
+30
+00:01:31,240 --> 00:01:34,550
+many iterations will be needed. And another drawback is that it can
+
+31
+00:01:34,550 --> 00:01:37,120
+easily become an excuse to do kind of do cut and fix
+
+32
+00:01:37,120 --> 00:01:40,530
+kind of approaches in which we hack something together, fix the main
+
+33
+00:01:40,530 --> 00:01:43,640
+issues when the customer gives us feedback, and then continue this
+
+34
+00:01:43,640 --> 00:01:46,780
+way, until the final product is something that is kind of
+
+35
+00:01:46,780 --> 00:01:49,830
+working, but it's not really a product of high quality. Something
+
+36
+00:01:49,830 --> 00:01:51,910
+else I want to point out before we move to the next
+
+37
+00:01:51,910 --> 00:01:54,490
+software process model is that there are many different kinds of
+
+38
+00:01:54,490 --> 00:01:56,700
+prototyping, so evolutionary prototyping is just
+
+39
+00:01:56,700 --> 00:01:58,010
+one of them. For example, throwaway
+
+40
+00:01:58,010 --> 00:02:02,100
+prototyping is another kind of prototyping in which the prototype is
+
+41
+00:02:02,100 --> 00:02:05,580
+just used to gather requirements, but is thrown away at the end
+
+42
+00:02:05,580 --> 00:02:08,710
+of the requirements gathering, instead of being evolved as it happens here.
diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/13 - Evolutionary Prototyping Process - lang_pt_vs2.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/13 - Evolutionary Prototyping Process - lang_pt_vs2.srt
new file mode 100644
index 0000000..a1fefdc
--- /dev/null
+++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/13 - Evolutionary Prototyping Process - lang_pt_vs2.srt	
@@ -0,0 +1,167 @@
+1
+00:00:00,080 --> 00:00:02,430
+O próximo modelo que eu quero discutir é prototipagem
+
+2
+00:00:02,430 --> 00:00:05,786
+evolutiva, que funciona em quatro fases principais. Nós começamos
+
+3
+00:00:05,786 --> 00:00:08,393
+por um conceito inicial, então nós desenhamos e criamos
+
+4
+00:00:08,393 --> 00:00:11,509
+um protótipo baseado neste conceito inicial, refinamos o protótipo
+
+5
+00:00:11,509 --> 00:00:14,002
+até que ele se torne aceitável e finalmente nós completamos e
+
+6
+00:00:14,002 --> 00:00:17,550
+liberamos o protótipo. Desta maneira, quando desenvolvemos um sistema usando
+
+7
+00:00:17,550 --> 00:00:22,330
+prototipagem evolutiva, o sistema é constantemente refinado e refeito.
+
+8
+00:00:22,330 --> 00:00:25,340
+Então este é o processo ideal quando nem todos os requisitos
+
+9
+00:00:25,340 --> 00:00:28,330
+estão bem compreendidos. O que é uma situação bastante usual. Então, olhando
+
+10
+00:00:28,330 --> 00:00:30,370
+para isso um pouco mais detalhadamente, o que ocorre é que
+
+11
+00:00:30,370 --> 00:00:33,760
+os desenvolvedores começam no desenvolvimento das partes do sistema que eles
+
+12
+00:00:33,760 --> 00:00:37,690
+compreendem, ao invés de trabalhar no desenvolvimento do sistema com um tido, incluindo as
+
+13
+00:00:37,690 --> 00:00:40,520
+parte que não estão ainda muito claras. O sistema
+
+14
+00:00:40,520 --> 00:00:43,900
+parcial é então mostrado ao cliente e a opinião do cliente
+
+15
+00:00:43,900 --> 00:00:47,480
+é usada para guiar a próxima iteração, na qual tanto modificações
+
+16
+00:00:47,480 --> 00:00:50,340
+são feitas nas atuais feições, como novas feições são adicionadas.
+
+17
+00:00:50,340 --> 00:00:53,060
+Assim, ou o protótipo atual é melhorado ou o
+
+18
+00:00:53,060 --> 00:00:56,270
+protótipo é aumentado. E finalmente, quando o cliente concorda de
+
+19
+00:00:56,270 --> 00:00:58,980
+que o protótipo está suficientemente bom, os desenvolvedores irão completar todo
+
+20
+00:00:58,980 --> 00:01:01,410
+o trabalho faltante no sistema e liberar o protótipo
+
+21
+00:01:01,410 --> 00:01:03,930
+como o produto final. Então vamos discutir como fizemos
+
+22
+00:01:03,930 --> 00:01:06,780
+para os modelos de processos anteriores, quais são as principais vantagens
+
+23
+00:01:06,780 --> 00:01:10,580
+e desvantagens de prototipagem evolutiva. Neste caso, a principal
+
+24
+00:01:10,580 --> 00:01:15,440
+vantagem é apreciação imediada. Os desenvolvedores recebem a opinião imediatamente,
+
+25
+00:01:15,440 --> 00:01:17,560
+tão logo eles produziram o protótipo e o mostraram para o
+
+26
+00:01:17,560 --> 00:01:21,050
+cliente e desta maneira, o risco de implementar erradamente o sistema é
+
+27
+00:01:21,050 --> 00:01:25,150
+minimizado. O principal ponto negativo é que isso é difícil de planejar.
+
+28
+00:01:25,150 --> 00:01:29,070
+Quando é usada a prototipagem evolutiva é difícil de antecipar por
+
+29
+00:01:29,070 --> 00:01:31,240
+quanto tempo o desenvolvimento irá levar, porquê nós não sabemos quantas
+
+30
+00:01:31,240 --> 00:01:34,550
+iterações serão necessárias. E outro inconveniente é que isso pode facilmente
+
+31
+00:01:34,550 --> 00:01:37,120
+se tornar uma desculpa para começar a fazer aquele tipo de abordagem de
+
+32
+00:01:37,120 --> 00:01:40,530
+"corte-e-correção" na qual nós começamos a enjambrar as coisas, corrigir os
+
+33
+00:01:40,530 --> 00:01:43,640
+principais defeitos quando o cliente nos dá sua opinião e então continuamos desta
+
+34
+00:01:43,640 --> 00:01:46,780
+maneira, até que o produto final se torne tipo algo que
+
+35
+00:01:46,780 --> 00:01:49,830
+funciona, mas que não é de fato um produto de alta qualidade. Outra coisa
+
+36
+00:01:49,830 --> 00:01:51,910
+que eu quero apontar antes de irmos ao próximo
+
+37
+00:01:51,910 --> 00:01:54,490
+modelo de criação de software é que existem diversas maneiras de
+
+38
+00:01:54,490 --> 00:01:56,700
+prototipagem, então a prototipagem evolutiva é apenas
+
+39
+00:01:56,700 --> 00:01:58,010
+uma delas. Por exemplo, prototipagem
+
+40
+00:01:58,010 --> 00:02:02,100
+descartável é outra maneira de prototipagem na qual o protótipo é
+
+41
+00:02:02,100 --> 00:02:05,580
+usado apenas para coletar requisitos, mas é descartado ao final
+
+42
+00:02:05,580 --> 00:02:08,710
+da coleta de requisitos, ao invés de ser evoluído, como ocorre aqui.
diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/14 - Rational Unified Process - lang_en_vs5.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/14 - Rational Unified Process - lang_en_vs5.srt
new file mode 100644
index 0000000..8bc6db8
--- /dev/null
+++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/14 - Rational Unified Process - lang_en_vs5.srt	
@@ -0,0 +1,111 @@
+1
+00:00:00,070 --> 00:00:02,969
+There are two more software process models that I want to cover, so
+
+2
+00:00:02,969 --> 00:00:06,120
+bear with me. The first one is the Rational Unified software Process
+
+3
+00:00:06,120 --> 00:00:09,500
+or IUP, which is s a very popular one based on UML.
+
+4
+00:00:09,500 --> 00:00:12,620
+RUP works in an iterative way, which means it that it performs different
+
+5
+00:00:12,620 --> 00:00:16,360
+iterations. And at each iteration, it performs four phases. So what I'm
+
+6
+00:00:16,360 --> 00:00:19,030
+showing you here, is a high level view of the process. And I
+
+7
+00:00:19,030 --> 00:00:21,630
+don't want you to focus on all the different details, because we
+
+8
+00:00:21,630 --> 00:00:25,170
+will discuss these details later on, in a lesson that is actually dedicated
+
+9
+00:00:25,170 --> 00:00:27,470
+to RUP. What I want to give you now, is just the
+
+10
+00:00:27,470 --> 00:00:31,020
+gist of how this works. So, in each one of these four
+
+11
+00:00:31,020 --> 00:00:34,680
+phases, which I'm going to describe in a second. We perform standard software
+
+12
+00:00:34,680 --> 00:00:38,060
+engineering activities, the ones that we just discussed. And we do them
+
+13
+00:00:38,060 --> 00:00:41,320
+to different extent, based on the phase in which we are.
+
+14
+00:00:41,320 --> 00:00:44,841
+In particular, in the inception phase the work is mostly to sculpt
+
+15
+00:00:44,841 --> 00:00:47,940
+the system. So basically figuring out what is the scope of the
+
+16
+00:00:47,940 --> 00:00:50,220
+work, what is the scope of the project, what is the domain.
+
+17
+00:00:50,220 --> 00:00:52,670
+So that we can be able to perform initial cost
+
+18
+00:00:52,670 --> 00:00:56,190
+and budget estimates. The operational phase is the phase in which
+
+19
+00:00:56,190 --> 00:00:59,910
+we focus on the domain analysis and define the basic architecture
+
+20
+00:00:59,910 --> 00:01:03,030
+for the system. So this is a phase in which analysis
+
+21
+00:01:03,030 --> 00:01:06,290
+and design are particularly paramount. Then there is a construction phase,
+
+22
+00:01:06,290 --> 00:01:09,250
+which is where the bulk of the development actually occurs. And
+
+23
+00:01:09,250 --> 00:01:11,640
+as you can see here, is where most of the implementation
+
+24
+00:01:11,640 --> 00:01:15,280
+happens. And finally, the transition phase is the phase in which
+
+25
+00:01:15,280 --> 00:01:18,090
+the system goes from development into production, so that
+
+26
+00:01:18,090 --> 00:01:20,380
+it becomes available to users. And of course, this is
+
+27
+00:01:20,380 --> 00:01:22,480
+the phase in which the other activities in software
+
+28
+00:01:22,480 --> 00:01:25,710
+development become less relevant and deployment becomes the main one.
diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/14 - Rational Unified Process - lang_pt_vs1.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/14 - Rational Unified Process - lang_pt_vs1.srt
new file mode 100644
index 0000000..cb089cb
--- /dev/null
+++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/14 - Rational Unified Process - lang_pt_vs1.srt	
@@ -0,0 +1,111 @@
+1
+00:00:00,070 --> 00:00:02,969
+Existem ainda dois outros processos de modelagem de software que eu gostaria de tratar, então
+
+2
+00:00:02,969 --> 00:00:06,120
+me acompanhem. O primeiro é o Processo Unificado Racional
+
+3
+00:00:06,120 --> 00:00:09,500
+ou RUP que é um dos mais populares baseados em UML.
+
+4
+00:00:09,500 --> 00:00:12,620
+RUP opera de uma maneira iterativa, o que significa que ocorrem diversas
+
+5
+00:00:12,620 --> 00:00:16,360
+iterações. E em cada iteração, são desenvolvidas quatro fases. Então o que eu
+
+6
+00:00:16,360 --> 00:00:19,030
+estou lhe mostrando aqui, é uma vista panorâmica do processo. E eu
+
+7
+00:00:19,030 --> 00:00:21,630
+não quero que você foque em todos os detalhes, porquê nós
+
+8
+00:00:21,630 --> 00:00:25,170
+iremos discutir estes detalhes mais tarde, numa lição que é de fato dedicada
+
+9
+00:00:25,170 --> 00:00:27,470
+ao RUP. O que eu quero lhe dar agora, é apenas a
+
+10
+00:00:27,470 --> 00:00:31,020
+essência de como isso funciona. Então, em cada um dessas quatro
+
+11
+00:00:31,020 --> 00:00:34,680
+fases, que eu irei descrever em breve... Nós desenvolvemos atividades
+
+12
+00:00:34,680 --> 00:00:38,060
+de engenharia de software padrões, as que nós já discutimos. E nós as fazemos
+
+13
+00:00:38,060 --> 00:00:41,320
+para diferentes amplitudes, baseadas na fase em que nos encontramos.
+
+14
+00:00:41,320 --> 00:00:44,841
+Em particular, na fase de Concepção (Iniciação) o trabalho será sobretudo de esculpir
+
+15
+00:00:44,841 --> 00:00:47,940
+o sistema. E basicamente ilustrando o escopo do
+
+16
+00:00:47,940 --> 00:00:50,220
+trabalho, qual será o escopo do projeto, qual é o domínio.
+
+17
+00:00:50,220 --> 00:00:52,670
+E então nós seremos capazes de saber o custo inicial
+
+18
+00:00:52,670 --> 00:00:56,190
+e fazer um orçamento. A fase de Elaboração é a fase na qual
+
+19
+00:00:56,190 --> 00:00:59,910
+nós focamos na análise de domínio e definimos a arquitetura de base
+
+20
+00:00:59,910 --> 00:01:03,030
+do sistema. Então esta é a fase na qual a análise
+
+21
+00:01:03,030 --> 00:01:06,290
+e o projeto se tornam proeminentes. E então ocorre a fase de Construção,
+
+22
+00:01:06,290 --> 00:01:09,250
+na qual o desenvolvimento massivo de fato ocorre. E
+
+23
+00:01:09,250 --> 00:01:11,640
+como você pode ver aqui, é onde a maior parte da implementação
+
+24
+00:01:11,640 --> 00:01:15,280
+ocorre. E finalmente, a fase de Transição é a fase na qual
+
+25
+00:01:15,280 --> 00:01:18,090
+o sistema passa do desenvolvimento para a produção, e então
+
+26
+00:01:18,090 --> 00:01:20,380
+ele se torna disponível aos usuários. E é claro, esta é
+
+27
+00:01:20,380 --> 00:01:22,480
+a fase na qual as outras atividades em desenvolvimento de
+
+28
+00:01:22,480 --> 00:01:25,710
+software se tornam menos relevantes e a entrega se torna a principal.
diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/15 - Agile Process - lang_en_vs3.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/15 - Agile Process - lang_en_vs3.srt
new file mode 100644
index 0000000..70ef200
--- /dev/null
+++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/15 - Agile Process - lang_en_vs3.srt	
@@ -0,0 +1,123 @@
+1
+00:00:00,150 --> 00:00:02,300
+The next type of software process models that I
+
+2
+00:00:02,300 --> 00:00:06,300
+want to discuss are Agile Software Development Processes. And this
+
+3
+00:00:06,300 --> 00:00:08,470
+is a group of software development methods that are
+
+4
+00:00:08,470 --> 00:00:12,620
+based on highly iterative and incremental development. And in particular,
+
+5
+00:00:12,620 --> 00:00:16,000
+I'm going to discuss Test Driven Development or TDD. The
+
+6
+00:00:16,000 --> 00:00:18,490
+space on the iteration of three main phases. In
+
+7
+00:00:18,490 --> 00:00:20,970
+the first one that we mark as red, we
+
+8
+00:00:20,970 --> 00:00:25,350
+write test cases that encode our requirements, and for which
+
+9
+00:00:25,350 --> 00:00:29,180
+we haven't written code yet. And therefore, they will fail, obviously.
+
+10
+00:00:29,180 --> 00:00:31,800
+So we're in this sort of red or fail phase. From
+
+11
+00:00:31,800 --> 00:00:34,830
+this phase, we move to this phase, in which after we
+
+12
+00:00:34,830 --> 00:00:37,970
+write the just enough code to make the test cases pass.
+
+13
+00:00:37,970 --> 00:00:40,670
+We have a set of test cases that are all passing.
+
+14
+00:00:40,670 --> 00:00:43,810
+And therefore, we can consider this as the green phase. We
+
+15
+00:00:43,810 --> 00:00:46,930
+had enough code to make the test cases pass because the
+
+16
+00:00:46,930 --> 00:00:50,520
+test cases encode our requirements. We have just written enough code to
+
+17
+00:00:50,520 --> 00:00:53,940
+satisfy our requirements. When we do this over time though,
+
+18
+00:00:53,940 --> 00:00:57,080
+what happens is that the structure of the code deteriorates, because
+
+19
+00:00:57,080 --> 00:00:59,100
+we keep adding pieces. So that's why we have the
+
+20
+00:00:59,100 --> 00:01:02,540
+first step, which is refactoring. In this step, we modify the
+
+21
+00:01:02,540 --> 00:01:05,724
+code, and we will talk about refactoring extensively. We'll devote
+
+22
+00:01:05,724 --> 00:01:08,190
+one lesson to it. We modify the code to make it
+
+23
+00:01:08,190 --> 00:01:12,650
+more readable, more maintainable. In general, we modify to improve the
+
+24
+00:01:12,650 --> 00:01:15,560
+design of the code. And after this phase, we will go
+
+25
+00:01:15,560 --> 00:01:17,670
+back to writing more test cases for
+
+26
+00:01:17,670 --> 00:01:19,730
+new requirements, write code that makes these
+
+27
+00:01:19,730 --> 00:01:24,870
+test cases pass, and so on. So we'll continue to iterate among these phases. And
+
+28
+00:01:24,870 --> 00:01:26,500
+also, in this case, we will talk
+
+29
+00:01:26,500 --> 00:01:29,390
+about Agile Software Processes. And in particular,
+
+30
+00:01:29,390 --> 00:01:32,250
+about extreme programming, or XP, and Scrum
+
+31
+00:01:32,250 --> 00:01:35,349
+in more details, in minor course number four.
diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/15 - Agile Process - lang_pt_vs1.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/15 - Agile Process - lang_pt_vs1.srt
new file mode 100644
index 0000000..b2224ea
--- /dev/null
+++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/15 - Agile Process - lang_pt_vs1.srt	
@@ -0,0 +1,123 @@
+1
+00:00:00,150 --> 00:00:02,300
+O próximo tipo de modelos de processo para software que eu
+
+2
+00:00:02,300 --> 00:00:06,300
+gostaria de discutir são os Processos Ágil de Desenvolvimento de Software. E este
+
+3
+00:00:06,300 --> 00:00:08,470
+é um grupo de métodos de desenvolvimento de software que são
+
+4
+00:00:08,470 --> 00:00:12,620
+baseados em desenvolvimento incremental e altamente iterativo. E em particular,
+
+5
+00:00:12,620 --> 00:00:16,000
+eu irei discutir é o Desenvolvimento Orientado a Testes, ou TDD. O
+
+6
+00:00:16,000 --> 00:00:18,490
+espaço na interação de três fases principais. Na
+
+7
+00:00:18,490 --> 00:00:20,970
+primeira delas que iremos marcar em vermelho, nós
+
+8
+00:00:20,970 --> 00:00:25,350
+escrevemos casos de teste que codificam nossos requisitos, e para os quais
+
+9
+00:00:25,350 --> 00:00:29,180
+nós ainda não escrevemos o código. E obviamente, em seguida eles irão falhar.
+
+10
+00:00:29,180 --> 00:00:31,800
+E então nós iremos cair neste tipo de fase vermelha, ou de falha. Desta
+
+11
+00:00:31,800 --> 00:00:34,830
+fase, nós passamos para esta outra fase, a qual ocorre depois de nós
+
+12
+00:00:34,830 --> 00:00:37,970
+escrevermos código suficiente para que os casos de teste aprovem.
+
+13
+00:00:37,970 --> 00:00:40,670
+Nós temos um conjunto de casos de testes em que todos aprovaram.
+
+14
+00:00:40,670 --> 00:00:43,810
+E em segunda, nós podemos considerar isso como a fase verde. Nós
+
+15
+00:00:43,810 --> 00:00:46,930
+temos código suficiente para fazer os casos de teste aprovarem porquê os
+
+16
+00:00:46,930 --> 00:00:50,520
+casos de teste codificam nossos requisitos. Nós escrevemos código suficiente para
+
+17
+00:00:50,520 --> 00:00:53,940
+satisfazer nossos requisitos. Quando nós seguimos com isso ao longo do tempo,
+
+18
+00:00:53,940 --> 00:00:57,080
+o que ocorre é que a estrutura do código deteriora, porquê
+
+19
+00:00:57,080 --> 00:00:59,100
+nós continuamos adicionando partes! E esta é a razão de nós termos o
+
+20
+00:00:59,100 --> 00:01:02,540
+primeiro passo, que é a Refatoração. Neste passo, nós modificamos o
+
+21
+00:01:02,540 --> 00:01:05,724
+código, e nós iremos falar extensamente sobre refatoração. Nós iremos dedicar
+
+22
+00:01:05,724 --> 00:01:08,190
+uma aula para isso. Nós modificamos o código para o tornar mais
+
+23
+00:01:08,190 --> 00:01:12,650
+legível, mais fácil de dar manutenção. Em geral, nós modificamos para aprimorar a
+
+24
+00:01:12,650 --> 00:01:15,560
+concepção do código. E depois desta fase, nós iremos tornar a
+
+25
+00:01:15,560 --> 00:01:17,670
+escrever mais casos de teste para
+
+26
+00:01:17,670 --> 00:01:19,730
+novos requisitos... escrever código que faz com que
+
+27
+00:01:19,730 --> 00:01:24,870
+esses casos de teste aprovem e assim em diante. E então nós iremos continuar a iterar ao entre essas fases. E
+
+28
+00:01:24,870 --> 00:01:26,500
+também, neste caso, nós iremos falar
+
+29
+00:01:26,500 --> 00:01:29,390
+sobre Processos Ágil de Desenvolvimento de Software. E em particular, em
+
+30
+00:01:29,390 --> 00:01:32,250
+Programação Extrema, ou XP e SCRUM
+
+31
+00:01:32,250 --> 00:01:35,349
+mais detalhadamente, no subcurso número quatro.
diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/16 - Choosing a Model - lang_en_vs4.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/16 - Choosing a Model - lang_en_vs4.srt
new file mode 100644
index 0000000..d898337
--- /dev/null
+++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/16 - Choosing a Model - lang_en_vs4.srt	
@@ -0,0 +1,179 @@
+1
+00:00:00,100 --> 00:00:02,860
+We just saw several software process models, and there
+
+2
+00:00:02,860 --> 00:00:06,330
+are many, many more. And because these process models define
+
+3
+00:00:06,330 --> 00:00:09,330
+the master plan for our project, the specific process
+
+4
+00:00:09,330 --> 00:00:12,220
+model that we choose has as much influence over a
+
+5
+00:00:12,220 --> 00:00:15,700
+project's success as any other major planning decision that
+
+6
+00:00:15,700 --> 00:00:18,610
+we make. Therefore, it is very important that we pick
+
+7
+00:00:18,610 --> 00:00:22,100
+the appropriate model for our development process. Picking an appropriate
+
+8
+00:00:22,100 --> 00:00:25,100
+model can ensure the success of a project. On the
+
+9
+00:00:25,100 --> 00:00:27,830
+contrary, if we choose the wrong model, that can be a
+
+10
+00:00:27,830 --> 00:00:31,010
+constant source of problems and ultimately, it can make the project
+
+11
+00:00:31,010 --> 00:00:33,830
+fail. So how can we choose the right model for a
+
+12
+00:00:33,830 --> 00:00:36,310
+project? To be able to do so, we have to take into
+
+13
+00:00:36,310 --> 00:00:40,490
+consideration many factors. In particular, we need to be aware of
+
+14
+00:00:40,490 --> 00:00:44,390
+what level of understanding we have of the requirements. Do we understand
+
+15
+00:00:44,390 --> 00:00:46,720
+all the requirements? Are we going to be able to collect all
+
+16
+00:00:46,720 --> 00:00:50,430
+the requirements in advance, or collecting requirements is going to be hard and
+
+17
+00:00:50,430 --> 00:00:53,460
+therefore, we might want to follow a process that is more flexible
+
+18
+00:00:53,460 --> 00:00:57,470
+with that respect. Another important point is the expected lifetime of the
+
+19
+00:00:57,470 --> 00:01:00,300
+project. Is this a quick project that we are putting together for
+
+20
+00:01:00,300 --> 00:01:03,100
+a specific purpose or something that's going to last for for a number
+
+21
+00:01:03,100 --> 00:01:05,910
+of years and that we're going to maintain over all those years?
+
+22
+00:01:05,910 --> 00:01:08,380
+That's going to make a difference in the way we decide to develop
+
+23
+00:01:08,380 --> 00:01:12,190
+that project. Also, what is the level of risk involved? Do we
+
+24
+00:01:12,190 --> 00:01:15,530
+know the domain very well? Do we know exactly the technologies involved?
+
+25
+00:01:15,530 --> 00:01:19,100
+Well, if so, we might go with a more traditional process. Otherwise,
+
+26
+00:01:19,100 --> 00:01:21,902
+we might want to be more agile, more flexible. It is also
+
+27
+00:01:21,902 --> 00:01:24,900
+very important to know the schedule constraints. How much time, how many
+
+28
+00:01:24,900 --> 00:01:28,640
+resources do we have for this project? What is the expected interaction
+
+29
+00:01:28,640 --> 00:01:31,870
+with the management and the customer? In particular for this ladder, there
+
+30
+00:01:31,870 --> 00:01:34,840
+are many processes that rely on the fact that there can be
+
+31
+00:01:34,840 --> 00:01:38,310
+a continuous interaction with the customer. If that interaction is not there,
+
+32
+00:01:38,310 --> 00:01:41,230
+there's no way we are going to be able to use these processes.
+
+33
+00:01:41,230 --> 00:01:44,580
+Conversely, there are processes that don't require the presence of the customer
+
+34
+00:01:44,580 --> 00:01:47,868
+at all, except for the initial phase and maybe some checking points and
+
+35
+00:01:47,868 --> 00:01:51,020
+so if the customer is very inaccessible, we might want to follow
+
+36
+00:01:51,020 --> 00:01:53,740
+one of those processes, instead of one of the more demanding ones in
+
+37
+00:01:53,740 --> 00:01:57,340
+terms of customer's time. Finally, it is important to take into account
+
+38
+00:01:57,340 --> 00:02:00,450
+the level of the expertise of the people involved. Do we have people
+
+39
+00:02:00,450 --> 00:02:02,730
+that know the technologies that we're using? Do we know people that
+
+40
+00:02:02,730 --> 00:02:04,590
+know a specific kind of process?
+
+41
+00:02:04,590 --> 00:02:06,930
+Some processes require some specific expertise and
+
+42
+00:02:06,930 --> 00:02:09,320
+we're not going to be able to follow that process if we don't
+
+43
+00:02:09,320 --> 00:02:12,410
+have the right expertise. So we need to take into account all of
+
+44
+00:02:12,410 --> 00:02:15,570
+these aspects, and sometimes more, in order to be able to make
+
+45
+00:02:15,570 --> 00:02:19,560
+the right decision and pick the right software process model for our project.
diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/17 - Choosing a Model Quiz - lang_en_vs4.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/17 - Choosing a Model Quiz - lang_en_vs4.srt
new file mode 100644
index 0000000..9f733ac
--- /dev/null
+++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/17 - Choosing a Model Quiz - lang_en_vs4.srt	
@@ -0,0 +1,35 @@
+1
+00:00:00,090 --> 00:00:02,080
+Now before we move to the last part of the lesson, let's
+
+2
+00:00:02,080 --> 00:00:04,939
+have a quick quiz on software process models to make sure that
+
+3
+00:00:04,939 --> 00:00:06,640
+we are all on the same page. So I am going to
+
+4
+00:00:06,640 --> 00:00:10,320
+ask you two questions. The first question is which of the following models
+
+5
+00:00:10,320 --> 00:00:14,330
+is most suitable to develop a software control system? And when you
+
+6
+00:00:14,330 --> 00:00:17,700
+think about the software control system, you can think about for example
+
+7
+00:00:17,700 --> 00:00:21,150
+the control system for the software in an airplane. Would you rather
+
+8
+00:00:21,150 --> 00:00:22,860
+use a pure waterfall model? Test
+
+9
+00:00:22,860 --> 00:00:25,840
+driven development? Or an evolutionary prototyping approach?
diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/18 - Choosing a Model Quiz Solution - lang_en_vs5.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/18 - Choosing a Model Quiz Solution - lang_en_vs5.srt
new file mode 100644
index 0000000..01a444c
--- /dev/null
+++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/18 - Choosing a Model Quiz Solution - lang_en_vs5.srt	
@@ -0,0 +1,47 @@
+1
+00:00:00,080 --> 00:00:02,980
+This is the context in which, typically, a pure
+
+2
+00:00:02,980 --> 00:00:06,310
+waterfall process will work well. Why? Well, because it's a
+
+3
+00:00:06,310 --> 00:00:10,160
+context in which requirements are usually well understood. The
+
+4
+00:00:10,160 --> 00:00:13,020
+domain is well understood, so that kind of system has
+
+5
+00:00:13,020 --> 00:00:15,900
+been built many times before. And also, it's a
+
+6
+00:00:15,900 --> 00:00:19,510
+system in which we don't expect requirements to change dramatically
+
+7
+00:00:19,510 --> 00:00:23,180
+over time. Therefore, a waterfall model, in which we collect
+
+8
+00:00:23,180 --> 00:00:25,140
+all the requirements at the beginning and then we move
+
+9
+00:00:25,140 --> 00:00:28,280
+to the subsequent phases might be the most appropriate one. Probably
+
+10
+00:00:28,280 --> 00:00:30,800
+we don't want to do evolutionary prototyping in the case of
+
+11
+00:00:30,800 --> 00:00:34,130
+the control system for an airplane. Same thing holds for TDD,
+
+12
+00:00:34,130 --> 00:00:36,460
+so we want to be a little more rigorous in those cases.
diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/19 - Choosing a Model Quiz - lang_en_vs5.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/19 - Choosing a Model Quiz - lang_en_vs5.srt
new file mode 100644
index 0000000..570d146
--- /dev/null
+++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/19 - Choosing a Model Quiz - lang_en_vs5.srt	
@@ -0,0 +1,11 @@
+1
+00:00:00,110 --> 00:00:03,580
+The second question I want to ask you is which model is the most suitable if you
+
+2
+00:00:03,580 --> 00:00:06,660
+expect mid-course corrections? Would you rather use a
+
+3
+00:00:06,660 --> 00:00:10,430
+pure waterfall model, a spiral model, or evolutionary prototyping?
diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/2 - Traditional Software Phases - lang_en_vs4.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/2 - Traditional Software Phases - lang_en_vs4.srt
new file mode 100644
index 0000000..cc522f0
--- /dev/null
+++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/2 - Traditional Software Phases - lang_en_vs4.srt	
@@ -0,0 +1,75 @@
+1
+00:00:00,160 --> 00:00:02,650
+As we just heard from Professor Bohem, software
+
+2
+00:00:02,650 --> 00:00:05,970
+engineering is an important and critical discipline, concerned
+
+3
+00:00:05,970 --> 00:00:09,100
+with cost effective software development. We also heard
+
+4
+00:00:09,100 --> 00:00:11,170
+that this is based on a systematic approach
+
+5
+00:00:11,170 --> 00:00:14,580
+that uses appropriate tools and techniques, operates under
+
+6
+00:00:14,580 --> 00:00:18,130
+specific development constraints. And most importantly, follows a
+
+7
+00:00:18,130 --> 00:00:20,890
+process. As we discussed in the previous lesson,
+
+8
+00:00:20,890 --> 00:00:25,770
+the software development process contains fundamental activities, or phases.
+
+9
+00:00:25,770 --> 00:00:28,480
+Since we will discuss several processes, I'm going to remind
+
+10
+00:00:28,480 --> 00:00:31,150
+you what these phases are. We start with requirements
+
+11
+00:00:31,150 --> 00:00:33,630
+engineering, followed by design,
+
+12
+00:00:33,630 --> 00:00:36,980
+implementation, verification and validation, and
+
+13
+00:00:36,980 --> 00:00:40,950
+finally maintenance. Note that we will revisit each of
+
+14
+00:00:40,950 --> 00:00:43,940
+these phases and devote an entire lesson or more
+
+15
+00:00:43,940 --> 00:00:46,160
+to each phase. So what I want to do next
+
+16
+00:00:46,160 --> 00:00:48,210
+is simply to give you a quick overview of
+
+17
+00:00:48,210 --> 00:00:51,020
+what these phases are. Note also that for now
+
+18
+00:00:51,020 --> 00:00:54,330
+I will follow a very traditional take on these topics. Later on in the
+
+19
+00:00:54,330 --> 00:00:58,260
+class we will see how things can change and did change over the years.
diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/20 - Choosing a Model Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/20 - Choosing a Model Quiz Solution - lang_en_vs4.srt
new file mode 100644
index 0000000..7ea0e4f
--- /dev/null
+++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/20 - Choosing a Model Quiz Solution - lang_en_vs4.srt	
@@ -0,0 +1,67 @@
+1
+00:00:00,150 --> 00:00:02,860
+In this case, I think about the spiral model,
+
+2
+00:00:02,860 --> 00:00:06,610
+and evolutionary prototyping model will work. Definitely you don't want to
+
+3
+00:00:06,610 --> 00:00:09,110
+have a pure water from water. Why? Well because it
+
+4
+00:00:09,110 --> 00:00:11,940
+is very expensive with a pure waterfall model to make
+
+5
+00:00:11,940 --> 00:00:15,460
+changes during the course of the project, especially changes
+
+6
+00:00:15,460 --> 00:00:17,860
+that involve requirements. Why? Because we saw that it can
+
+7
+00:00:17,860 --> 00:00:20,440
+be very expensive. Whereas with the spiral model, we saw
+
+8
+00:00:20,440 --> 00:00:25,220
+that being iterative, we can actually make correction throughout development.
+
+9
+00:00:25,220 --> 00:00:28,840
+Similarly, with evolutionary prototyping, we keep evolving our system
+
+10
+00:00:28,840 --> 00:00:32,170
+based on the customer feedback. And therefore, if something changes,
+
+11
+00:00:32,170 --> 00:00:33,810
+we will get feedback right away, and we will
+
+12
+00:00:33,810 --> 00:00:36,230
+be able to adapt. So the key thing here is
+
+13
+00:00:36,230 --> 00:00:39,060
+that anything that is iterative works better in the
+
+14
+00:00:39,060 --> 00:00:43,400
+case of changing environments. So, situations in which your requirements,
+
+15
+00:00:43,400 --> 00:00:46,720
+the situation, the project might change. Whereas waterfall is
+
+16
+00:00:46,720 --> 00:00:50,410
+more appropriate for situations in which the requirements are stable,
+
+17
+00:00:50,410 --> 00:00:53,760
+we know the domain, and possibly we also know the technologies involved.
diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/21 - Lifecycle Documents - lang_en_vs4.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/21 - Lifecycle Documents - lang_en_vs4.srt
new file mode 100644
index 0000000..20e1102
--- /dev/null
+++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/21 - Lifecycle Documents - lang_en_vs4.srt	
@@ -0,0 +1,67 @@
+1
+00:00:00,070 --> 00:00:02,650
+Now that we discussed softer process models, there is
+
+2
+00:00:02,650 --> 00:00:05,100
+another important point I want to cover, because it's going to
+
+3
+00:00:05,100 --> 00:00:08,970
+be useful for your projects. Documenting the activities carried out
+
+4
+00:00:08,970 --> 00:00:11,660
+during the different phases of the softer lifecycle, is a
+
+5
+00:00:11,660 --> 00:00:14,960
+very important task. The documents that we produce are used
+
+6
+00:00:14,960 --> 00:00:18,270
+for different purposes, such as communicative details of the software
+
+7
+00:00:18,270 --> 00:00:21,650
+systems. To difference the colors, ensure the correct implementation of
+
+8
+00:00:21,650 --> 00:00:25,630
+the system, facilitate maintenance, and so on. There are standardized
+
+9
+00:00:25,630 --> 00:00:29,230
+document that are provided by IEEE that you can use
+
+10
+00:00:29,230 --> 00:00:32,680
+for this purpose. However, they're kind of heavyweight. So for the
+
+11
+00:00:32,680 --> 00:00:35,090
+project in this class, when we will need them, I will
+
+12
+00:00:35,090 --> 00:00:38,760
+rather use this lightweight documents. That we created by modifying the
+
+13
+00:00:38,760 --> 00:00:41,730
+original ones, and make them a little simpler. In this,
+
+14
+00:00:41,730 --> 00:00:44,700
+our documents are actually used, while teaching this class in the
+
+15
+00:00:44,700 --> 00:00:47,600
+past. So they're well tested and work well for the kind
+
+16
+00:00:47,600 --> 00:00:50,730
+of projects that we will perform. I provide information on how
+
+17
+00:00:50,730 --> 00:00:52,880
+to access these documents in the class notes.
diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/22 - Classic Mistakes: People - lang_en_vs4.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/22 - Classic Mistakes: People - lang_en_vs4.srt
new file mode 100644
index 0000000..7edb042
--- /dev/null
+++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/22 - Classic Mistakes: People - lang_en_vs4.srt	
@@ -0,0 +1,163 @@
+1
+00:00:00,120 --> 00:00:02,000
+Now we get to the final part of the lesson.
+
+2
+00:00:02,000 --> 00:00:04,810
+And in this part I want to talk about well known,
+
+3
+00:00:04,810 --> 00:00:09,230
+ineffective development practices. These practices, when followed, tend to lead
+
+4
+00:00:09,230 --> 00:00:13,245
+to predictably bad results. So let's look at some examples of
+
+5
+00:00:13,245 --> 00:00:17,130
+these classic mistakes. And we're going to start with mistakes
+
+6
+00:00:17,130 --> 00:00:20,660
+involving people. And notice that there is a long list. So
+
+7
+00:00:20,660 --> 00:00:23,100
+I'm going to discuss just a few of those mistakes.
+
+8
+00:00:23,100 --> 00:00:25,215
+And I'm going to point you to more information on this
+
+9
+00:00:25,215 --> 00:00:27,550
+topic in the class notes. And some of these mistakes are
+
+10
+00:00:27,550 --> 00:00:30,020
+actually kind of entertaining. So I'll recommend that you look at
+
+11
+00:00:30,020 --> 00:00:33,210
+the class notes and go in more depth in this list.
+
+12
+00:00:33,210 --> 00:00:35,550
+So the first people mistake I want to mention is the
+
+13
+00:00:35,550 --> 00:00:38,945
+one that I define, heroics. And this refers to too much
+
+14
+00:00:38,945 --> 00:00:43,480
+emphasis on can do attitudes, so this idea that one person
+
+15
+00:00:43,480 --> 00:00:46,330
+by himself or by herself can do everything and can make
+
+16
+00:00:46,330 --> 00:00:50,422
+the difference in the whole project. And unfortunately, this encourages extreme
+
+17
+00:00:50,422 --> 00:00:53,950
+risk taking and discourages cooperation, which is plain bad for
+
+18
+00:00:53,950 --> 00:00:56,610
+the project. For example, it might force people not to
+
+19
+00:00:56,610 --> 00:00:59,600
+report schedule slips. It might force people to take on
+
+20
+00:00:59,600 --> 00:01:02,210
+on too much responsibility. And normally, and I saw it
+
+21
+00:01:02,210 --> 00:01:05,600
+happen many times, the final result is a failure. So
+
+22
+00:01:05,600 --> 00:01:08,410
+what you want when you're developing a larger project, is
+
+23
+00:01:08,410 --> 00:01:11,710
+actually to apply soft engineering principles. Have teams, have team
+
+24
+00:01:11,710 --> 00:01:15,580
+work, and have cooperation among the different team members, without pointing
+
+25
+00:01:15,580 --> 00:01:18,830
+too much on single individuals. Another classic mistake
+
+26
+00:01:18,830 --> 00:01:22,140
+is to not create the right working environment. We
+
+27
+00:01:22,140 --> 00:01:24,900
+all like to work in nice environments. And there
+
+28
+00:01:24,900 --> 00:01:27,790
+is strong evidence that the working environments can play
+
+29
+00:01:27,790 --> 00:01:30,670
+a big role in productivity. There is evidence
+
+30
+00:01:30,670 --> 00:01:34,280
+that productivity increases when the workplace is nice, quiet,
+
+31
+00:01:34,280 --> 00:01:37,950
+warm, and welcoming. Finally, some of the most important
+
+32
+00:01:37,950 --> 00:01:41,480
+people relating mistakes are due to poor people management.
+
+33
+00:01:41,480 --> 00:01:44,540
+For example, lack of leaderships, or leadership that is
+
+34
+00:01:44,540 --> 00:01:47,920
+exercised using the wrong means in the wrong way, which
+
+35
+00:01:47,920 --> 00:01:50,280
+can lead to very unhappy personnel and therefore, low
+
+36
+00:01:50,280 --> 00:01:54,190
+productivity, or even people leaving teams. Another classic example of
+
+37
+00:01:54,190 --> 00:01:57,370
+poor management is adding people to a project that
+
+38
+00:01:57,370 --> 00:02:01,600
+is behind schedule, which never works. Why it doesn't work?
+
+39
+00:02:01,600 --> 00:02:03,440
+Because these new people need to be brought up to
+
+40
+00:02:03,440 --> 00:02:06,520
+speed, and that causes further delays rather than improving the
+
+41
+00:02:06,520 --> 00:02:08,280
+situation with the project schedule.
diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/23 - Classic Mistakes: Process - lang_en_vs4.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/23 - Classic Mistakes: Process - lang_en_vs4.srt
new file mode 100644
index 0000000..83720a0
--- /dev/null
+++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/23 - Classic Mistakes: Process - lang_en_vs4.srt	
@@ -0,0 +1,79 @@
+1
+00:00:00,080 --> 00:00:03,770
+Another type of classic mistakes are process-related mistakes. And also
+
+2
+00:00:03,770 --> 00:00:05,850
+in this case, these kind of mistakes can be due
+
+3
+00:00:05,850 --> 00:00:08,970
+to many reasons. And they are of many types. One
+
+4
+00:00:08,970 --> 00:00:12,310
+typical example are scheduling issues, which are due to the fact
+
+5
+00:00:12,310 --> 00:00:15,180
+of being unable to come up with a realistic schedule.
+
+6
+00:00:15,180 --> 00:00:17,750
+So to have an overly optimistic schedule. And this can be
+
+7
+00:00:17,750 --> 00:00:21,230
+because we underestimate the effort involved in different parts of
+
+8
+00:00:21,230 --> 00:00:25,010
+the project. Because we overestimate the ability of the people involved.
+
+9
+00:00:25,010 --> 00:00:27,600
+Because we overestimate the importance, for example, of the use
+
+10
+00:00:27,600 --> 00:00:29,640
+of tools. But no matter what the reason is, the
+
+11
+00:00:29,640 --> 00:00:32,840
+result is typically that the projects end up being late,
+
+12
+00:00:32,840 --> 00:00:35,580
+which is a very common situation. So this is somehow
+
+13
+00:00:35,580 --> 00:00:39,020
+related to planning. And in general, planning is a fundamental
+
+14
+00:00:39,020 --> 00:00:42,720
+factor in software processes and in software development. Mistakes in
+
+15
+00:00:42,720 --> 00:00:46,120
+planning, such as insufficient planning or abandoning planning due to
+
+16
+00:00:46,120 --> 00:00:50,190
+pressure, usually lead inexorably to failure. And speaking of failures,
+
+17
+00:00:50,190 --> 00:00:53,040
+often there are unforeseen failures. Such as
+
+18
+00:00:53,040 --> 00:00:55,410
+failures on the constructor's end, for example,
+
+19
+00:00:55,410 --> 00:00:56,920
+that might lead to low quality or
+
+20
+00:00:56,920 --> 00:01:00,580
+late deliverables, which ultimately affects the downstream activities.
diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/24 - Classic Mistakes: Product - lang_en_vs4.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/24 - Classic Mistakes: Product - lang_en_vs4.srt
new file mode 100644
index 0000000..24972d9
--- /dev/null
+++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/24 - Classic Mistakes: Product - lang_en_vs4.srt	
@@ -0,0 +1,87 @@
+1
+00:00:00,090 --> 00:00:01,970
+The third category of mistakes that I want to
+
+2
+00:00:01,970 --> 00:00:04,970
+mention is product-related mistakes. A
+
+3
+00:00:04,970 --> 00:00:07,360
+typical example of product-related mistake
+
+4
+00:00:07,360 --> 00:00:11,010
+is gold plating of requirements. And what that means is
+
+5
+00:00:11,010 --> 00:00:13,710
+basically is that it's very common for projects to have
+
+6
+00:00:13,710 --> 00:00:17,230
+more requirements than they actually need. For example, marketing might
+
+7
+00:00:17,230 --> 00:00:19,090
+want to add more features than the ones that are
+
+8
+00:00:19,090 --> 00:00:21,460
+actually needed by the users. And of course having more
+
+9
+00:00:21,460 --> 00:00:25,720
+requirements lengthens the project's schedule in a totally unnecessary way.
+
+10
+00:00:25,720 --> 00:00:29,250
+Feature creep is another common mistake and consists in
+
+11
+00:00:29,250 --> 00:00:32,140
+adding more and more features to a product that were
+
+12
+00:00:32,140 --> 00:00:34,650
+not initially planned and are not really needed in most
+
+13
+00:00:34,650 --> 00:00:38,360
+cases. And here there is evidence that the average project
+
+14
+00:00:38,360 --> 00:00:41,180
+experiences about a 25% growth in the number of
+
+15
+00:00:41,180 --> 00:00:44,330
+features over its lifetime which can clearly highly effect The
+
+16
+00:00:44,330 --> 00:00:47,580
+project schedule. Finally, if you're working on a project that
+
+17
+00:00:47,580 --> 00:00:50,760
+strains the limits of computer science. For example, because you
+
+18
+00:00:50,760 --> 00:00:53,350
+need to develop new algorithms for the project, or you have
+
+19
+00:00:53,350 --> 00:00:56,670
+to use new techniques. Then that project might be more research than
+
+20
+00:00:56,670 --> 00:00:58,450
+actual development. And therefore, it
+
+21
+00:00:58,450 --> 00:01:00,600
+should be managed accordingly. For example,
+
+22
+00:01:00,600 --> 00:01:03,910
+by taking into account that you will have a highly unpredictable schedule.
diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/25 - Classic Mistakes: Technology - lang_en_vs4.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/25 - Classic Mistakes: Technology - lang_en_vs4.srt
new file mode 100644
index 0000000..16810ac
--- /dev/null
+++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/25 - Classic Mistakes: Technology - lang_en_vs4.srt	
@@ -0,0 +1,95 @@
+1
+00:00:00,080 --> 00:00:02,360
+The final type of classic mistakes that I want
+
+2
+00:00:02,360 --> 00:00:06,470
+to mention are technology related mistakes. One typical mistake
+
+3
+00:00:06,470 --> 00:00:09,990
+in this context is the silver-bullet syndrome. What does
+
+4
+00:00:09,990 --> 00:00:13,340
+that mean? Well, the silver-bullet syndrome refers to situations
+
+5
+00:00:13,340 --> 00:00:15,900
+in which there is too much reliance on the
+
+6
+00:00:15,900 --> 00:00:19,950
+advertised benefits of some previously unused technology. For example,
+
+7
+00:00:19,950 --> 00:00:21,980
+a new technology. And the problem here is that
+
+8
+00:00:21,980 --> 00:00:25,140
+we cannot expect technology alone to solve our software
+
+9
+00:00:25,140 --> 00:00:27,810
+development issues. So we should not rely too
+
+10
+00:00:27,810 --> 00:00:31,020
+much on technology alone. Another typical mistake is to
+
+11
+00:00:31,020 --> 00:00:33,700
+switch or add tools in the middle of
+
+12
+00:00:33,700 --> 00:00:36,010
+a project. And sometimes it can make sense to
+
+13
+00:00:36,010 --> 00:00:38,620
+upgrade a tool, but introducing new tools, which
+
+14
+00:00:38,620 --> 00:00:41,650
+can have a steep learning curve, has almost always
+
+15
+00:00:41,650 --> 00:00:46,290
+negative effects. Finally, a common unforgivable mistake is
+
+16
+00:00:46,290 --> 00:00:50,230
+the lack of an automated version control system for
+
+17
+00:00:50,230 --> 00:00:53,480
+your code and for your various artifacts. Manual and
+
+18
+00:00:53,480 --> 00:00:56,700
+ad hoc solutions are just not an option. It is
+
+19
+00:00:56,700 --> 00:00:59,270
+way too easy to make mistakes, use out of
+
+20
+00:00:59,270 --> 00:01:02,600
+date versions, be unable to find a previous working version,
+
+21
+00:01:02,600 --> 00:01:05,030
+and so on. I saw that happening many times,
+
+22
+00:01:05,030 --> 00:01:08,640
+and it always results in a disaster. So be warned,
+
+23
+00:01:08,640 --> 00:01:11,650
+use a version control system and an automated one. And
+
+24
+00:01:11,650 --> 00:01:14,750
+actually we will use version control systems in our projects.
diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/26 - Classic Mistakes Quiz - lang_en_vs4.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/26 - Classic Mistakes Quiz - lang_en_vs4.srt
new file mode 100644
index 0000000..2b4263f
--- /dev/null
+++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/26 - Classic Mistakes Quiz - lang_en_vs4.srt	
@@ -0,0 +1,23 @@
+1
+00:00:00,060 --> 00:00:01,650
+To conclude this lesson, I'm going to have a
+
+2
+00:00:01,650 --> 00:00:03,650
+simple quiz and what I'm going to ask you
+
+3
+00:00:03,650 --> 00:00:07,950
+is, which kind of mistake adding people to a late project is? And you can pick
+
+4
+00:00:07,950 --> 00:00:10,540
+between a people mistake, a product mistake, a
+
+5
+00:00:10,540 --> 00:00:12,830
+technology mistake, or maybe this is not a
+
+6
+00:00:12,830 --> 00:00:16,800
+mistake at all, it is actually okay to add people to a project that is late.
diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/27 - Classic Mistakes Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/27 - Classic Mistakes Quiz Solution - lang_en_vs4.srt
new file mode 100644
index 0000000..53c2485
--- /dev/null
+++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/27 - Classic Mistakes Quiz Solution - lang_en_vs4.srt	
@@ -0,0 +1,39 @@
+1
+00:00:00,060 --> 00:00:02,719
+You probably got this one right. The right answer is that
+
+2
+00:00:02,719 --> 00:00:05,330
+this is a people mistake. And despite the fact that this is
+
+3
+00:00:05,330 --> 00:00:07,550
+an easy answer, I just want to make sure to stress
+
+4
+00:00:07,550 --> 00:00:10,800
+once more. Because this is a very classic mistake. And one that
+
+5
+00:00:10,800 --> 00:00:14,070
+can have dire consequences. You should never add people, to a
+
+6
+00:00:14,070 --> 00:00:18,430
+late project. Because in 99.9% of the cases, that's only going to make
+
+7
+00:00:18,430 --> 00:00:21,390
+things worse. Why? Because these people have to be brought up to
+
+8
+00:00:21,390 --> 00:00:25,590
+speed, and also because having more also makes the communication more difficult,
+
+9
+00:00:25,590 --> 00:00:27,690
+the meetings more difficult and so on. So in
+
+10
+00:00:27,690 --> 00:00:29,980
+short, do not add people to a late project.
diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/3 - Requirements Engineering - lang_en_vs4.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/3 - Requirements Engineering - lang_en_vs4.srt
new file mode 100644
index 0000000..c541e70
--- /dev/null
+++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/3 - Requirements Engineering - lang_en_vs4.srt	
@@ -0,0 +1,175 @@
+1
+00:00:00,230 --> 00:00:03,200
+So, let's start with requirements engineering, which is the
+
+2
+00:00:03,200 --> 00:00:06,560
+field within software engineering that deals with establishing the
+
+3
+00:00:06,560 --> 00:00:09,400
+needs of stakeholders that are to be solved by
+
+4
+00:00:09,400 --> 00:00:13,480
+the software. So why is this phase so important?
+
+5
+00:00:13,480 --> 00:00:16,350
+In general, the cost of correcting an error depends
+
+6
+00:00:16,350 --> 00:00:19,060
+on the number of subsequent decisions that are based
+
+7
+00:00:19,060 --> 00:00:22,160
+on it. Therefore, errors made in understanding requirements have
+
+8
+00:00:22,160 --> 00:00:25,670
+the potential for greatest cost because many other design decisions
+
+9
+00:00:25,670 --> 00:00:29,020
+depend on them and many other follow up decisions depend on them.
+
+10
+00:00:29,020 --> 00:00:31,510
+In fact, if we look at this diagram, which is again a
+
+11
+00:00:31,510 --> 00:00:35,210
+qualitative diagram, where we have the cost of error correction over the
+
+12
+00:00:35,210 --> 00:00:38,780
+phase in which the error is discovered. We can see that if we
+
+13
+00:00:38,780 --> 00:00:42,420
+discover an error in requirements it's going to cost us one. If
+
+14
+00:00:42,420 --> 00:00:45,020
+we find it in in design it's going to cost us five and
+
+15
+00:00:45,020 --> 00:00:47,410
+so on and so forth. And the cost grows dramatically as we
+
+16
+00:00:47,410 --> 00:00:50,960
+go from the requirements phase to the maintenance phase. Why? Because of course
+
+17
+00:00:50,960 --> 00:00:53,092
+if we discover a problem here we're left to undo a
+
+18
+00:00:53,092 --> 00:00:55,536
+lot of the decision that we had made before to correct the
+
+19
+00:00:55,536 --> 00:00:58,019
+error. Whereas if we find an error here we can correct it
+
+20
+00:00:58,019 --> 00:01:01,380
+right away and we don't affect the subsequent phases. So how can
+
+21
+00:01:01,380 --> 00:01:03,540
+we collect the right requirements. Traditional
+
+22
+00:01:03,540 --> 00:01:05,310
+requirements in engineering does so through
+
+23
+00:01:05,310 --> 00:01:08,930
+a set of steps. The first step is elicitation which is the
+
+24
+00:01:08,930 --> 00:01:12,840
+collection of requirements from stake holders and other sources and can be
+
+25
+00:01:12,840 --> 00:01:15,890
+done in a variety of ways, we will discuss some of them.
+
+26
+00:01:15,890 --> 00:01:19,280
+The second is requirement analysis which involved the study and
+
+27
+00:01:19,280 --> 00:01:23,200
+deeper understanding of the collective requirements. The third step is this
+
+28
+00:01:23,200 --> 00:01:26,760
+specification of requirements, in which the collective requirements are suitably
+
+29
+00:01:26,760 --> 00:01:30,730
+represented, organized and save so that they can be shared. Also
+
+30
+00:01:30,730 --> 00:01:32,530
+in his case, there are many ways to do this,
+
+31
+00:01:32,530 --> 00:01:34,350
+and we will see some of this ways when we talk
+
+32
+00:01:34,350 --> 00:01:37,550
+about the requirements engineering in the dedicated lesson. Once the
+
+33
+00:01:37,550 --> 00:01:40,970
+requirements have been specified, they can be validated to make sure
+
+34
+00:01:40,970 --> 00:01:44,420
+that they're complete, consistent, no redundant and so on. So
+
+35
+00:01:44,420 --> 00:01:48,460
+that they've satisfied a set of importance properties, for requirements.
+
+36
+00:01:48,460 --> 00:01:52,410
+Finally, the fifth step is requirements management which accounts for
+
+37
+00:01:52,410 --> 00:01:56,100
+changes to requirements during the lifetime of the project. And here
+
+38
+00:01:56,100 --> 00:01:58,330
+I talked about steps, kind of giving the impression that
+
+39
+00:01:58,330 --> 00:02:01,310
+we're just going from the first step to the fifth one
+
+40
+00:02:01,310 --> 00:02:03,300
+and that this is sort of a linear process. In
+
+41
+00:02:03,300 --> 00:02:05,990
+reality, as we will see, this is more of an iterative
+
+42
+00:02:05,990 --> 00:02:09,690
+process in which will go and cover the different phases in an
+
+43
+00:02:09,690 --> 00:02:12,560
+iterative fashion. We will discuss extensively
+
+44
+00:02:12,560 --> 00:02:15,453
+requirements engineering in our second mini-course.
diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/4 - Design - lang_en_vs4.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/4 - Design - lang_en_vs4.srt
new file mode 100644
index 0000000..5ddb4d1
--- /dev/null
+++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/4 - Design - lang_en_vs4.srt	
@@ -0,0 +1,103 @@
+1
+00:00:00,290 --> 00:00:02,900
+Now let's discuss the next phase of software development,
+
+2
+00:00:02,900 --> 00:00:06,080
+which is software design. Software design is the phase
+
+3
+00:00:06,080 --> 00:00:09,030
+where software requirements are analyzed in order to produce
+
+4
+00:00:09,030 --> 00:00:11,500
+a description of the internal structure and organization of
+
+5
+00:00:11,500 --> 00:00:13,900
+the system. And this description will serve as the
+
+6
+00:00:13,900 --> 00:00:17,550
+basis for the construction of the actual system. Traditionally,
+
+7
+00:00:17,550 --> 00:00:20,020
+the software design phase consists of a series of
+
+8
+00:00:20,020 --> 00:00:25,360
+design activities. Which normally consists of the architectural design phase,
+
+9
+00:00:25,360 --> 00:00:27,880
+the abstract specification, interface design,
+
+10
+00:00:27,880 --> 00:00:30,010
+component design, data structure and
+
+11
+00:00:30,010 --> 00:00:33,230
+algorithm design. And notice that this is just a possible list
+
+12
+00:00:33,230 --> 00:00:35,820
+of activities. But you can also characterize design activities in
+
+13
+00:00:35,820 --> 00:00:38,550
+many different ways. And if you're looking at different books, and
+
+14
+00:00:38,550 --> 00:00:41,800
+different sources, you might find different activities described. But the
+
+15
+00:00:41,800 --> 00:00:44,500
+core idea, the important point is that we go from sort
+
+16
+00:00:44,500 --> 00:00:46,940
+of a high-level view of the system, which is the
+
+17
+00:00:46,940 --> 00:00:50,770
+architectural design, to a low-level view, which is the algorithm design.
+
+18
+00:00:50,770 --> 00:00:53,100
+And these activities result in a set of design
+
+19
+00:00:53,100 --> 00:00:56,810
+products, which describe various characteristics of the system. For
+
+20
+00:00:56,810 --> 00:00:59,770
+example, they describe the architecture of the system, so
+
+21
+00:00:59,770 --> 00:01:02,890
+how the system is decomposed and organized into components, the
+
+22
+00:01:02,890 --> 00:01:06,630
+interfaces between these components. They also describe these components
+
+23
+00:01:06,630 --> 00:01:09,030
+into a level of details that is suitable for
+
+24
+00:01:09,030 --> 00:01:12,470
+allowing their construction. We will discuss the details of
+
+25
+00:01:12,470 --> 00:01:16,130
+software design and talk extensively about these different actives and
+
+26
+00:01:16,130 --> 00:01:19,200
+these different products in the third mini course of this class.
diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/5 - Implementation - lang_en_vs5.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/5 - Implementation - lang_en_vs5.srt
new file mode 100644
index 0000000..465ae1b
--- /dev/null
+++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/5 - Implementation - lang_en_vs5.srt	
@@ -0,0 +1,103 @@
+1
+00:00:00,150 --> 00:00:02,719
+After we have designed our system we can implement
+
+2
+00:00:02,719 --> 00:00:05,900
+it. In the implementation phase what we do is basically
+
+3
+00:00:05,900 --> 00:00:08,410
+taking care of realizing the design of the system
+
+4
+00:00:08,410 --> 00:00:11,920
+that we just created and create an actual software system.
+
+5
+00:00:11,920 --> 00:00:15,530
+There are four fundamental principles, four pillars that can
+
+6
+00:00:15,530 --> 00:00:18,470
+affect the way in which software is constructed. The first
+
+7
+00:00:18,470 --> 00:00:21,900
+one is the reduction of complexity. This aims to build
+
+8
+00:00:21,900 --> 00:00:25,160
+software that is easier to understand and use. The second
+
+9
+00:00:25,160 --> 00:00:28,400
+pillar is the anticipation of diversity. Which takes into
+
+10
+00:00:28,400 --> 00:00:31,720
+account that software construction might change in various way over
+
+11
+00:00:31,720 --> 00:00:35,220
+time. That is that software evolves. In many cases,
+
+12
+00:00:35,220 --> 00:00:38,270
+it evolves in unexpected ways. And therefore, we have to
+
+13
+00:00:38,270 --> 00:00:41,680
+be able to anticipate some of these changes. The
+
+14
+00:00:41,680 --> 00:00:45,390
+third pillar is the structuring for validation. Also called design
+
+15
+00:00:45,390 --> 00:00:47,550
+for testability. And what this means is that we
+
+16
+00:00:47,550 --> 00:00:50,760
+want to build software so that it is easily testable
+
+17
+00:00:50,760 --> 00:00:54,890
+during the subsequent validation and verification activities. Finally, and
+
+18
+00:00:54,890 --> 00:00:58,040
+this is especially true within specific organizations and or
+
+19
+00:00:58,040 --> 00:01:00,770
+domains. It is important that the software conforms to
+
+20
+00:01:00,770 --> 00:01:04,330
+a set of internal or external standards. And some examples
+
+21
+00:01:04,330 --> 00:01:06,730
+of this might be, for example, for internal standards,
+
+22
+00:01:06,730 --> 00:01:10,680
+coding standards within an organization, or naming standards within an
+
+23
+00:01:10,680 --> 00:01:13,320
+organization. As for external standards, if for example you
+
+24
+00:01:13,320 --> 00:01:15,780
+are developing some medical software. There are some regulations and
+
+25
+00:01:15,780 --> 00:01:17,930
+some standards that you have to adhere to in
+
+26
+00:01:17,930 --> 00:01:20,060
+order for your software to be valid in that domain.
diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/6 - Verification & Validation - lang_en_vs4.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/6 - Verification & Validation - lang_en_vs4.srt
new file mode 100644
index 0000000..df504a2
--- /dev/null
+++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/6 - Verification & Validation - lang_en_vs4.srt	
@@ -0,0 +1,123 @@
+1
+00:00:00,120 --> 00:00:03,550
+After we have built our system, verification and validation
+
+2
+00:00:03,550 --> 00:00:05,970
+is that phase of software development that aims to
+
+3
+00:00:05,970 --> 00:00:09,000
+check that the software system meets its specification and
+
+4
+00:00:09,000 --> 00:00:12,800
+fulfills its intended purpose. More precisely, we can look
+
+5
+00:00:12,800 --> 00:00:16,250
+at verification and validation independently. And validation is the
+
+6
+00:00:16,250 --> 00:00:19,100
+activity that answers the question did we build the
+
+7
+00:00:19,100 --> 00:00:21,420
+right system. Did we build the system that the
+
+8
+00:00:21,420 --> 00:00:26,030
+customer wants? That will make the customer happy. Whereas verification
+
+9
+00:00:26,030 --> 00:00:28,730
+answers a different question which is did we build the system
+
+10
+00:00:28,730 --> 00:00:31,410
+right. So given a description of the system that is the one
+
+11
+00:00:31,410 --> 00:00:34,280
+that we derived from the customer through the collection of requirements
+
+12
+00:00:34,280 --> 00:00:37,130
+and then design and so on, did we build a system that
+
+13
+00:00:37,130 --> 00:00:41,150
+actually implements the specification that we defined? And when we look
+
+14
+00:00:41,150 --> 00:00:44,600
+at verification there's many, many ways of doing verification and in fact
+
+15
+00:00:44,600 --> 00:00:48,430
+in the mini course number four we will cover verification extensively. The
+
+16
+00:00:48,430 --> 00:00:51,100
+only thing I want to mention here is the fact that verification
+
+17
+00:00:51,100 --> 00:00:54,110
+can be performed at different levels. In particular, it can be
+
+18
+00:00:54,110 --> 00:00:57,810
+performed at the unit level in which we test that the individual
+
+19
+00:00:57,810 --> 00:01:01,520
+units work as a expected. Can be performed in the integration level
+
+20
+00:01:01,520 --> 00:01:05,525
+in which what we test is the interaction between the different units.
+
+21
+00:01:05,525 --> 00:01:07,630
+So we want to make sure that the different modules talk
+
+22
+00:01:07,630 --> 00:01:10,720
+to each other in the right way. And finally, there is system
+
+23
+00:01:10,720 --> 00:01:13,440
+testing in which we test the system as a whole and we
+
+24
+00:01:13,440 --> 00:01:16,170
+want to make sure that all the system, all the different pieces
+
+25
+00:01:16,170 --> 00:01:18,010
+of the system work together in the right
+
+26
+00:01:18,010 --> 00:01:20,160
+way. And this is also the level at which
+
+27
+00:01:20,160 --> 00:01:22,360
+then we will apply validation and some other
+
+28
+00:01:22,360 --> 00:01:25,770
+testing techniques like stress testing or robustness testing and
+
+29
+00:01:25,770 --> 00:01:29,890
+so on. And as I said I'm not going to say anything more on this topic because
+
+30
+00:01:29,890 --> 00:01:32,760
+we will cover verification, and validation, and testing in
+
+31
+00:01:32,760 --> 00:01:35,667
+particular in great details in mini course number four.
diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/7 - Maintenance - lang_en_vs5.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/7 - Maintenance - lang_en_vs5.srt
new file mode 100644
index 0000000..e3d95bf
--- /dev/null
+++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/7 - Maintenance - lang_en_vs5.srt	
@@ -0,0 +1,167 @@
+1
+00:00:00,012 --> 00:00:03,482
+As we discussed before software development efforts normally result
+
+2
+00:00:03,482 --> 00:00:06,127
+in the delivery of a software product that satisfies
+
+3
+00:00:06,127 --> 00:00:09,879
+the user requirements. So normally our software development organization
+
+4
+00:00:09,879 --> 00:00:13,127
+will release this application to its final users, however, once
+
+5
+00:00:13,127 --> 00:00:16,090
+the software is in operation many things can happen.
+
+6
+00:00:16,090 --> 00:00:18,950
+So, for example, the environment might change. There might be
+
+7
+00:00:18,950 --> 00:00:21,940
+new libraries. There might be new systems in which
+
+8
+00:00:21,940 --> 00:00:25,070
+our software has to operate. Or they may be future
+
+9
+00:00:25,070 --> 00:00:27,950
+requests, so the users may find out that, guess what,
+
+10
+00:00:27,950 --> 00:00:30,370
+they want to do something different with the problem that
+
+11
+00:00:30,370 --> 00:00:32,835
+we gave them. Or, again, and this is one of
+
+12
+00:00:32,835 --> 00:00:35,970
+the most common occurrences, users might find problems with the
+
+13
+00:00:35,970 --> 00:00:38,307
+software and may file bug reports and send the bug
+
+14
+00:00:38,307 --> 00:00:42,090
+reports back to the software developer. These are the reasons
+
+15
+00:00:42,090 --> 00:00:46,420
+why software maintenance is a necessary phase in software development.
+
+16
+00:00:46,420 --> 00:00:50,190
+Software maintenance is the activity that sustains the software product
+
+17
+00:00:50,190 --> 00:00:53,780
+as it evolves throughout its life cycle, specifically
+
+18
+00:00:53,780 --> 00:00:57,350
+in response to bug reports, feature requests and
+
+19
+00:00:57,350 --> 00:01:00,890
+environment changes. Development organisations perform three kinds of
+
+20
+00:01:00,890 --> 00:01:04,450
+maintenance activities: corrective maintenance to eliminate problems with the
+
+21
+00:01:04,450 --> 00:01:07,740
+code, perfective maintenance to accommodate feature request, and
+
+22
+00:01:07,740 --> 00:01:09,730
+in some cases just to improve the software, for
+
+23
+00:01:09,730 --> 00:01:12,230
+example, to make it more efficient, and finally,
+
+24
+00:01:12,230 --> 00:01:15,650
+adaptive maintenance, to take care of the environment changes.
+
+25
+00:01:15,650 --> 00:01:18,470
+And after this activities have been performed, the software developer
+
+26
+00:01:18,470 --> 00:01:21,540
+will produce a new version of the application, will release it
+
+27
+00:01:21,540 --> 00:01:24,150
+and the cycle will continue through out the lifetime of
+
+28
+00:01:24,150 --> 00:01:27,440
+the software. That's why maintenance is a fundamental activity and a
+
+29
+00:01:27,440 --> 00:01:30,420
+very expensive one. And one of the reasons why maintenance
+
+30
+00:01:30,420 --> 00:01:34,080
+is expensive, that I want to mention now, is regression testing.
+
+31
+00:01:34,080 --> 00:01:37,180
+During maintenance every time you modify your application you have
+
+32
+00:01:37,180 --> 00:01:41,120
+to regression test the application, where regression testing is the activity
+
+33
+00:01:41,120 --> 00:01:44,010
+of retesting software after it has been modified to make sure
+
+34
+00:01:44,010 --> 00:01:47,320
+that the changes you perform to the software work as expected,
+
+35
+00:01:47,320 --> 00:01:51,540
+and that your changes did not introduce any unforseen effect. I'm
+
+36
+00:01:51,540 --> 00:01:53,630
+pretty sure that you're familiar with the case of a new
+
+37
+00:01:53,630 --> 00:01:56,000
+version of the software being released and just a couple of
+
+38
+00:01:56,000 --> 00:01:59,260
+days later another version being released to fix some problems that
+
+39
+00:01:59,260 --> 00:02:02,000
+occor with the new version. These problems is what we call
+
+40
+00:02:02,000 --> 00:02:04,640
+regression errors and they're what regression
+
+41
+00:02:04,640 --> 00:02:06,560
+testing targets and tries to eliminate
+
+42
+00:02:06,560 --> 00:02:09,240
+before the new version of the software is released into the world.
diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/8 - Software Phases Quiz - lang_en_vs4.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/8 - Software Phases Quiz - lang_en_vs4.srt
new file mode 100644
index 0000000..e3fe74b
--- /dev/null
+++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/8 - Software Phases Quiz - lang_en_vs4.srt	
@@ -0,0 +1,47 @@
+1
+00:00:00,070 --> 00:00:02,590
+Okay. Now before we jump into the next
+
+2
+00:00:02,590 --> 00:00:04,780
+topic, I just want to take a very quick and
+
+3
+00:00:04,780 --> 00:00:06,630
+simple quiz just to make sure that you
+
+4
+00:00:06,630 --> 00:00:09,236
+guys paid attention to what I just discussed. So
+
+5
+00:00:09,236 --> 00:00:10,820
+I want to ask you what are the traditional
+
+6
+00:00:10,820 --> 00:00:13,200
+software phases. Requirements engineering,
+
+7
+00:00:13,200 --> 00:00:16,079
+design, abstraction, implementation, verification and
+
+8
+00:00:16,079 --> 00:00:18,020
+validation. Or maybe design,
+
+9
+00:00:18,020 --> 00:00:20,830
+optimization, implementation verification and validation
+
+10
+00:00:20,830 --> 00:00:22,448
+and maintenance. Or requirements
+
+11
+00:00:22,448 --> 00:00:24,892
+engineering, design, implementation, verification and
+
+12
+00:00:24,892 --> 00:00:26,290
+validation, and maintenance.
diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/9 - Software Phases Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/9 - Software Phases Quiz Solution - lang_en_vs4.srt
new file mode 100644
index 0000000..ecb7a35
--- /dev/null
+++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/9 - Software Phases Quiz Solution - lang_en_vs4.srt	
@@ -0,0 +1,15 @@
+1
+00:00:00,190 --> 00:00:04,000
+And the answer is the third one. The traditional software phases which are the
+
+2
+00:00:04,000 --> 00:00:05,960
+ones that we just discussed are requirements
+
+3
+00:00:05,960 --> 00:00:08,820
+engineering, design, implementation, verification
+
+4
+00:00:08,820 --> 00:00:10,630
+and validation, and maintenance.
diff --git a/usth/ICT2.7/P1L3 Integrated Development Environment Subtitles/1 - Lesson Overview - lang_en_vs5.srt b/usth/ICT2.7/P1L3 Integrated Development Environment Subtitles/1 - Lesson Overview - lang_en_vs5.srt
new file mode 100644
index 0000000..afc573d
--- /dev/null
+++ b/usth/ICT2.7/P1L3 Integrated Development Environment Subtitles/1 - Lesson Overview - lang_en_vs5.srt	
@@ -0,0 +1,39 @@
+1
+00:00:00,650 --> 00:00:07,470
+Hi, and welcome to the first of several lessons on tools of the trade. I'm
+
+2
+00:00:07,470 --> 00:00:12,200
+very excited about these lessons, because I believe that tools are a cornerstone
+
+3
+00:00:12,200 --> 00:00:14,390
+of the software engineering discipline, and it
+
+4
+00:00:14,390 --> 00:00:17,570
+is of paramount importance to know and
+
+5
+00:00:17,570 --> 00:00:20,330
+use them. In this lesson, we will
+
+6
+00:00:20,330 --> 00:00:25,530
+talk about integrated development environments, normally called IDEs.
+
+7
+00:00:25,530 --> 00:00:29,780
+And these are software applications that support developers in many of their
+
+8
+00:00:29,780 --> 00:00:36,870
+everyday tasks, such as writing, compiling, and debugging code. And to make the
+
+9
+00:00:36,870 --> 00:00:42,470
+discussion more concrete we will focus on a specific IDE, Eclipse. We will
+
+10
+00:00:42,470 --> 00:00:47,250
+first present Eclipse, and then get some hands-on experience through a demo.
diff --git a/usth/ICT2.7/P1L3 Integrated Development Environment Subtitles/2 - Eclipse Introduction - lang_en_vs5.srt b/usth/ICT2.7/P1L3 Integrated Development Environment Subtitles/2 - Eclipse Introduction - lang_en_vs5.srt
new file mode 100644
index 0000000..1d0ff56
--- /dev/null
+++ b/usth/ICT2.7/P1L3 Integrated Development Environment Subtitles/2 - Eclipse Introduction - lang_en_vs5.srt	
@@ -0,0 +1,91 @@
+1
+00:00:00,160 --> 00:00:02,750
+As I just told you, tools are fundamental in
+
+2
+00:00:02,750 --> 00:00:06,050
+software engineering. And I will stress this concept over and
+
+3
+00:00:06,050 --> 00:00:08,240
+over, throughout the class. And today we're going to talk
+
+4
+00:00:08,240 --> 00:00:11,310
+about a tool that is especially important, which is integrated
+
+5
+00:00:11,310 --> 00:00:15,060
+development environments, or IDEs. And you're probably familiar with
+
+6
+00:00:15,060 --> 00:00:18,060
+IDEs. So IDEs are environments that give you support for
+
+7
+00:00:18,060 --> 00:00:21,580
+your development activities. For example, for writing code, editing code,
+
+8
+00:00:21,580 --> 00:00:25,320
+compiling code, and so on. And we will focus specifically
+
+9
+00:00:25,320 --> 00:00:28,890
+on one particular IDE, which is called Eclipse. And
+
+10
+00:00:28,890 --> 00:00:31,450
+what I'm showing here is the two splash screens for
+
+11
+00:00:31,450 --> 00:00:35,350
+two versions of eclipse, Helios and Kepler. Eclipse is an
+
+12
+00:00:35,350 --> 00:00:39,200
+open, extensible development environment that was initially created by IBM
+
+13
+00:00:39,200 --> 00:00:41,510
+and is now managed by the Eclipse Foundation. And of
+
+14
+00:00:41,510 --> 00:00:43,840
+course, there are many other great IDEs such as for
+
+15
+00:00:43,840 --> 00:00:47,310
+example, Microsoft Visual Studio or Netbeans. We will be using
+
+16
+00:00:47,310 --> 00:00:50,830
+Eclipse because it is open and because it is multi-platform,
+
+17
+00:00:50,830 --> 00:00:52,390
+which means that you can use Eclipse
+
+18
+00:00:52,390 --> 00:00:55,140
+no matter what operating system we're using.
+
+19
+00:00:55,140 --> 00:00:59,030
+So if we consider the most commonly used operating system, such as Mac
+
+20
+00:00:59,030 --> 00:01:02,780
+OS, Windows, Linux, Eclipse runs on any
+
+21
+00:01:02,780 --> 00:01:04,769
+of these environments. Therefore, no matter what
+
+22
+00:01:04,769 --> 00:01:06,490
+you're using, you'll be able to install
+
+23
+00:01:06,490 --> 00:01:08,560
+Eclipse, run Eclipse, and follow the class.
diff --git a/usth/ICT2.7/P1L3 Integrated Development Environment Subtitles/3 - IDE Overview - lang_en_vs6.srt b/usth/ICT2.7/P1L3 Integrated Development Environment Subtitles/3 - IDE Overview - lang_en_vs6.srt
new file mode 100644
index 0000000..e2b63b3
--- /dev/null
+++ b/usth/ICT2.7/P1L3 Integrated Development Environment Subtitles/3 - IDE Overview - lang_en_vs6.srt	
@@ -0,0 +1,143 @@
+1
+00:00:00,130 --> 00:00:05,680
+So, now let's look in a little more detail to what is an IDE. An IDE is a
+
+2
+00:00:05,680 --> 00:00:09,790
+software application that supports software developers in many of
+
+3
+00:00:09,790 --> 00:00:13,840
+their everyday tasks. It has many useful features. Most IDEs
+
+4
+00:00:13,840 --> 00:00:16,790
+provide views that can be used to navigate, project
+
+5
+00:00:16,790 --> 00:00:20,140
+resources from different perspectives. For example, you might want to
+
+6
+00:00:20,140 --> 00:00:22,390
+look at your code differently when you're writing code,
+
+7
+00:00:22,390 --> 00:00:25,950
+and when you're debugging. They also normally provide an intelligent
+
+8
+00:00:25,950 --> 00:00:29,380
+source code editor. For example, an editor that will allow you
+
+9
+00:00:29,380 --> 00:00:32,110
+to browse the documentation when you're writing a code that
+
+10
+00:00:32,110 --> 00:00:35,780
+uses a specific method, or that will give you autocompletion when
+
+11
+00:00:35,780 --> 00:00:37,990
+you start writing the name of an object and you want to
+
+12
+00:00:37,990 --> 00:00:40,820
+get the methods for that object. And all of these things
+
+13
+00:00:40,820 --> 00:00:43,420
+can be very useful while you're developing and can save you a
+
+14
+00:00:43,420 --> 00:00:47,750
+lot of time. Modern IDE's will also normally give you support for
+
+15
+00:00:47,750 --> 00:00:49,540
+version control systems that then you
+
+16
+00:00:49,540 --> 00:00:52,490
+can use for softer configuration management.
+
+17
+00:00:52,490 --> 00:00:55,720
+And we're going to discuss in detail version control systems in
+
+18
+00:00:55,720 --> 00:00:58,380
+the next tools of the trade lesson, and we're also
+
+19
+00:00:58,380 --> 00:01:01,135
+going to see how it can be integrated within an IDE.
+
+20
+00:01:01,135 --> 00:01:04,730
+IDEs also give you builders so they give you build automation
+
+21
+00:01:04,730 --> 00:01:08,070
+tools, they give you runtime support. So that you can
+
+22
+00:01:08,070 --> 00:01:10,960
+run your projects from within the IDE and, for example,
+
+23
+00:01:10,960 --> 00:01:14,550
+observe some aspects of the execution. In addition to giving
+
+24
+00:01:14,550 --> 00:01:17,562
+you support for the runtime, they give you support for testing.
+
+25
+00:01:17,562 --> 00:01:21,267
+Many IDEs allow you to run tests from within
+
+26
+00:01:21,267 --> 00:01:23,520
+the IDE and to check the results of the tests
+
+27
+00:01:23,520 --> 00:01:26,300
+from within the IDE. Not only that. Normally, after you
+
+28
+00:01:26,300 --> 00:01:28,210
+run your tests, if there are some test cases that
+
+29
+00:01:28,210 --> 00:01:31,500
+fail, you can also use your IDEs to do debugging.
+
+30
+00:01:31,500 --> 00:01:35,620
+Many IDEs include graphical debuggers. Debuggers will allow you to
+
+31
+00:01:35,620 --> 00:01:39,400
+navigate through the code, set which points, stop and restart
+
+32
+00:01:39,400 --> 00:01:43,160
+the execution. Inspect variables, and do all of the activities
+
+33
+00:01:43,160 --> 00:01:46,320
+that help debugging. And, to help you be more efficient
+
+34
+00:01:46,320 --> 00:01:49,440
+and more effective when you do debugging. And into addition to
+
+35
+00:01:49,440 --> 00:01:52,760
+all these features that are listed here IDEs can normally provide
+
+36
+00:01:52,760 --> 00:01:56,650
+you even more features through a mechanishm that is called plugins.
diff --git a/usth/ICT2.7/P1L3 Integrated Development Environment Subtitles/4 - Plug-Ins - lang_en_vs5.srt b/usth/ICT2.7/P1L3 Integrated Development Environment Subtitles/4 - Plug-Ins - lang_en_vs5.srt
new file mode 100644
index 0000000..040293e
--- /dev/null
+++ b/usth/ICT2.7/P1L3 Integrated Development Environment Subtitles/4 - Plug-Ins - lang_en_vs5.srt	
@@ -0,0 +1,99 @@
+1
+00:00:00,110 --> 00:00:03,134
+In fact most IDEs are extensible through the use of
+
+2
+00:00:03,134 --> 00:00:06,158
+plug-ins. And by the way, note that plug-ins might be
+
+3
+00:00:06,158 --> 00:00:09,326
+called differently on different platforms. For example, if you're using
+
+4
+00:00:09,326 --> 00:00:12,970
+a Microsoft Visual Studio, plug-ins are normally called add-ins, but
+
+5
+00:00:12,970 --> 00:00:15,598
+the concept is more or less the same. So, what
+
+6
+00:00:15,598 --> 00:00:18,555
+is a plug-in? Well, let's imagine our IDE to be
+
+7
+00:00:18,555 --> 00:00:22,320
+this box. A plug-in is additional functionality that you can
+
+8
+00:00:22,320 --> 00:00:25,430
+actually plug into this box so that this box starts
+
+9
+00:00:25,430 --> 00:00:28,830
+offering more features to the user. For example, you
+
+10
+00:00:28,830 --> 00:00:32,850
+can add to Eclipse the Checkstyle plug-in. Which, paraphrasing the
+
+11
+00:00:32,850 --> 00:00:35,950
+Checkstyle website, helps you ensure that your Java code
+
+12
+00:00:35,950 --> 00:00:38,890
+complies with a set of coding standards by inspecting the
+
+13
+00:00:38,890 --> 00:00:41,690
+code and pointing out items that deviate from a
+
+14
+00:00:41,690 --> 00:00:44,870
+defined set of coding rules. Again, this is a functionality
+
+15
+00:00:44,870 --> 00:00:47,330
+the core of Eclipse doesn't have. You can add
+
+16
+00:00:47,330 --> 00:00:50,600
+the Checkstyle plug-in, and this functionality will become available in
+
+17
+00:00:50,600 --> 00:00:54,840
+the IDE. Another example of plug-in is the EGit plug-in which
+
+18
+00:00:54,840 --> 00:00:58,660
+adds support for the Git version control system in Eclipse. And
+
+19
+00:00:58,660 --> 00:01:01,290
+actually this is something that we'll cover in detail, we'll have
+
+20
+00:01:01,290 --> 00:01:04,150
+a demo, and we will actually use it throughout the class, so
+
+21
+00:01:04,150 --> 00:01:07,018
+I'm not going to say anything more about the EGit plug-in for
+
+22
+00:01:07,018 --> 00:01:09,300
+now. But again, what the plug-in will do is to add
+
+23
+00:01:09,300 --> 00:01:13,220
+the Git functionality to Eclipse. A functionality that is not in
+
+24
+00:01:13,220 --> 00:01:16,110
+the core of Eclipse and that is available to the user after
+
+25
+00:01:16,110 --> 00:01:17,181
+you add the plug-in.
diff --git a/usth/ICT2.7/P1L3 Integrated Development Environment Subtitles/5 - Eclipse Demo: Create Java Project - lang_en_vs5.srt b/usth/ICT2.7/P1L3 Integrated Development Environment Subtitles/5 - Eclipse Demo: Create Java Project - lang_en_vs5.srt
new file mode 100644
index 0000000..8788858
--- /dev/null
+++ b/usth/ICT2.7/P1L3 Integrated Development Environment Subtitles/5 - Eclipse Demo: Create Java Project - lang_en_vs5.srt	
@@ -0,0 +1,323 @@
+1
+00:00:00,070 --> 00:00:02,550
+In the rest of this lesson we're going to look at eclipse and
+
+2
+00:00:02,550 --> 00:00:05,290
+try to get more familiar with eclipse in a hands on manner
+
+3
+00:00:05,290 --> 00:00:07,550
+through a demo. In the demo we will cover some of the
+
+4
+00:00:07,550 --> 00:00:11,040
+basic aspects of eclipse like how to run eclipse, how to select
+
+5
+00:00:11,040 --> 00:00:14,400
+their workspace, how to create a project, how to create the class
+
+6
+00:00:14,400 --> 00:00:18,240
+within the project and so on. I'll also cover some more advanced
+
+7
+00:00:18,240 --> 00:00:21,610
+aspects, like how to create builders, run your project within Eclipse, and
+
+8
+00:00:21,610 --> 00:00:25,800
+how to use their Eclipse debugger. So let's get to the demo.
+
+9
+00:00:25,800 --> 00:00:28,220
+So let's start Eclipse. Eclipse is going to ask me
+
+10
+00:00:28,220 --> 00:00:31,600
+for the location of my workspace and in this
+
+11
+00:00:31,600 --> 00:00:34,530
+case, I selected a suitable directory and you can
+
+12
+00:00:34,530 --> 00:00:38,480
+also use that checkbox on the left to avoid Eclipse
+
+13
+00:00:38,480 --> 00:00:40,640
+for asking you again about where to put the
+
+14
+00:00:40,640 --> 00:00:43,860
+workspace. And the workspace is basically the place the
+
+15
+00:00:43,860 --> 00:00:48,310
+directory. Where, Eclipse will place all of your projects.
+
+16
+00:00:48,310 --> 00:00:50,830
+So, now when you start Eclipse, if it's the first
+
+17
+00:00:50,830 --> 00:00:53,480
+time you might get this Welcome screen. It's not going to happen
+
+18
+00:00:53,480 --> 00:00:57,500
+again on subsequent executions, but I just wanted to make sure
+
+19
+00:00:57,500 --> 00:01:00,210
+that I covered all the bases. And so, whatcha want to
+
+20
+00:01:00,210 --> 00:01:03,360
+do here is to basically go to the java perspective
+
+21
+00:01:03,360 --> 00:01:06,760
+which you can do by clicking over there or you can
+
+22
+00:01:06,760 --> 00:01:09,240
+also use the menus. So in this case we will have
+
+23
+00:01:09,240 --> 00:01:12,810
+to go to Window, open Perspective, and if the Perspective is
+
+24
+00:01:12,810 --> 00:01:15,660
+not here, you'll have to click on Other. And at this point,
+
+25
+00:01:15,660 --> 00:01:18,030
+that you can click on Java Perspective, then you
+
+26
+00:01:18,030 --> 00:01:21,680
+click okay. And the perspective is basically, the visual work
+
+27
+00:01:21,680 --> 00:01:24,810
+space where you will be operating. So, after we selected
+
+28
+00:01:24,810 --> 00:01:29,350
+perspective, we can actually close the welcome screen. And here,
+
+29
+00:01:29,350 --> 00:01:32,000
+you see that you have this different areas and on
+
+30
+00:01:32,000 --> 00:01:34,930
+the left You have the package explorer. This is the
+
+31
+00:01:34,930 --> 00:01:37,650
+area where your packages will be, you've got a task list,
+
+32
+00:01:37,650 --> 00:01:41,280
+and an outline on the right which we'll cover later.
+
+33
+00:01:41,280 --> 00:01:44,870
+And then you have underneath, the bottom, a problems, java
+
+34
+00:01:44,870 --> 00:01:48,330
+doc and declaration views and we will see some of
+
+35
+00:01:48,330 --> 00:01:51,320
+these views in actions later. And here in the center
+
+36
+00:01:51,320 --> 00:01:54,290
+you have the area. Which is called a code editor,
+
+37
+00:01:54,290 --> 00:01:58,360
+which is where you'll be writing, editing, and modifying, basically,
+
+38
+00:01:58,360 --> 00:02:00,440
+your code. This is where most of the action takes
+
+39
+00:02:00,440 --> 00:02:03,140
+place. So let's start by creating a Java project. And
+
+40
+00:02:03,140 --> 00:02:06,950
+to do that we can use either the context menu, or
+
+41
+00:02:06,950 --> 00:02:09,560
+you can just use the menu, select new Java project.
+
+42
+00:02:09,560 --> 00:02:12,390
+You'll be greeted by this, wizard, and. And at this
+
+43
+00:02:12,390 --> 00:02:15,500
+point in the wizard, you can select the name of
+
+44
+00:02:15,500 --> 00:02:19,100
+your project. I'm just going to call it a very simple way
+
+45
+00:02:19,100 --> 00:02:21,990
+my project. And I going to use the default location for
+
+46
+00:02:21,990 --> 00:02:24,070
+the project, as you can see it will be placed
+
+47
+00:02:24,070 --> 00:02:27,440
+in the work space that I selected before. I'm going to
+
+48
+00:02:27,440 --> 00:02:32,080
+also use the default. Java Runtime Environment, which is Java 1.7
+
+49
+00:02:32,080 --> 00:02:36,250
+in this case. I'm going to keep the selected default layout
+
+50
+00:02:36,250 --> 00:02:39,120
+and the, then I'm going to go to the next step. Here,
+
+51
+00:02:39,120 --> 00:02:42,380
+we're first presented with the location of the source code for
+
+52
+00:02:42,380 --> 00:02:46,840
+our project. The default is a directory SRC in my project
+
+53
+00:02:46,840 --> 00:02:49,320
+and for the output file, the directory bin. So repeat, we're now
+
+54
+00:02:49,320 --> 00:02:52,410
+going to change that. Here in case you need other projects to
+
+55
+00:02:52,410 --> 00:02:55,240
+build your own, then you can specify them here. Here we
+
+56
+00:02:55,240 --> 00:02:57,570
+are building a simple project, so there's no need for that.
+
+57
+00:02:57,570 --> 00:03:00,890
+And here we can specify which libraries our project requires. As
+
+58
+00:03:00,890 --> 00:03:03,880
+you can see, the Java library's already specified. And you can
+
+59
+00:03:03,880 --> 00:03:07,840
+also add other jars, which can even be External jars. And
+
+60
+00:03:07,840 --> 00:03:11,840
+finally this is the tab that allows you to specify which
+
+61
+00:03:11,840 --> 00:03:14,300
+part of you project. So how your project will be exported,
+
+62
+00:03:14,300 --> 00:03:16,760
+so lets not worry about that for now. Lets click finish.
+
+63
+00:03:16,760 --> 00:03:19,300
+And as you can see here on the package explorer, my
+
+64
+00:03:19,300 --> 00:03:22,920
+project appeared. So now we can open the project by clicking
+
+65
+00:03:22,920 --> 00:03:24,920
+on the triangle right next to it, and as you can
+
+66
+00:03:24,920 --> 00:03:28,250
+see there is the SRC directory, where my source code will go,
+
+67
+00:03:28,250 --> 00:03:31,760
+and there's also an indication that we're using the JRE, so that's
+
+68
+00:03:31,760 --> 00:03:35,800
+the Java system directory within our project. And this is just for people
+
+69
+00:03:35,800 --> 00:03:38,860
+who are interested in what happens you know, under the hood. So
+
+70
+00:03:38,860 --> 00:03:41,840
+if you don't care about that, you can just skip this part. So
+
+71
+00:03:41,840 --> 00:03:45,200
+basically here I'm showing you how we can go to the directory
+
+72
+00:03:45,200 --> 00:03:49,250
+where the project was created. We can see the bin and src directories.
+
+73
+00:03:49,250 --> 00:03:52,020
+And there's also some other files here that you can
+
+74
+00:03:52,020 --> 00:03:54,780
+see these 'dot' files that you will not normally, see. And
+
+75
+00:03:54,780 --> 00:03:57,870
+those are kind of bookkeeping files. So these are files that
+
+76
+00:03:57,870 --> 00:04:02,280
+contain information about your project and that are created automatically by
+
+77
+00:04:02,280 --> 00:04:05,860
+Eclipse. And, for example, will have various indication about the
+
+78
+00:04:05,860 --> 00:04:09,580
+configuration of the project, some settings and the class path for
+
+79
+00:04:09,580 --> 00:04:11,880
+the project. And, as I said, you don't have to worry
+
+80
+00:04:11,880 --> 00:04:14,490
+about this if you just want to go Eclipse as you're never
+
+81
+00:04:14,490 --> 00:04:16,551
+going to mess with the command line.
diff --git a/usth/ICT2.7/P1L3 Integrated Development Environment Subtitles/6 - Eclipse Demo: Create a Class - lang_en_vs6.srt b/usth/ICT2.7/P1L3 Integrated Development Environment Subtitles/6 - Eclipse Demo: Create a Class - lang_en_vs6.srt
new file mode 100644
index 0000000..3bd4f11
--- /dev/null
+++ b/usth/ICT2.7/P1L3 Integrated Development Environment Subtitles/6 - Eclipse Demo: Create a Class - lang_en_vs6.srt	
@@ -0,0 +1,135 @@
+1
+00:00:00,130 --> 00:00:02,420
+So now that we know, we saw what happens under
+
+2
+00:00:02,420 --> 00:00:04,570
+the hood, and as I said, don't worry about it if
+
+3
+00:00:04,570 --> 00:00:06,689
+you don't care about that part. Now we can go back
+
+4
+00:00:06,689 --> 00:00:09,850
+to Eclipse, and we can start creating a package. A package
+
+5
+00:00:09,850 --> 00:00:13,125
+is basically a way of organizing your classes into a
+
+6
+00:00:13,125 --> 00:00:17,015
+hierarchy. In this case, I'm going to specify the package name as
+
+7
+00:00:17,015 --> 00:00:21,350
+edu.gatech, which means that I'm creating really two packages, a package
+
+8
+00:00:21,350 --> 00:00:25,480
+gatech inside package edu. And I can start creating classes inside
+
+9
+00:00:25,480 --> 00:00:28,770
+my packages. So here, I can use the contextual menu, select
+
+10
+00:00:28,770 --> 00:00:32,055
+New&gt;Class, and I'll get another wizard that will allow me to
+
+11
+00:00:32,055 --> 00:00:35,160
+specify the name of the class. I'm not very creative here,
+
+12
+00:00:35,160 --> 00:00:38,250
+so I'm just going to call it Hello World. There's many other parameters
+
+13
+00:00:38,250 --> 00:00:41,710
+you can set, and in particular, you can define whether you
+
+14
+00:00:41,710 --> 00:00:45,450
+want a main method in your class. Where having a main
+
+15
+00:00:45,450 --> 00:00:48,460
+method means that your class can be the main class in
+
+16
+00:00:48,460 --> 00:00:50,850
+your project, can be the one that is run when you run
+
+17
+00:00:50,850 --> 00:00:54,340
+your project. After we click the button, the Finish button, we,
+
+18
+00:00:54,340 --> 00:00:56,859
+we get the class. So we also get template code for the
+
+19
+00:00:56,859 --> 00:00:59,604
+class, as you can see here, so we go to the editor
+
+20
+00:00:59,604 --> 00:01:02,120
+function, you can see that there is a to do. Where you
+
+21
+00:01:02,120 --> 00:01:05,019
+have to put your code, and here we are simply, basically printing,
+
+22
+00:01:05,019 --> 00:01:08,370
+you know, the typical first program. We just going to print Hello World
+
+23
+00:01:08,370 --> 00:01:11,180
+in Java. And something you can note is that as we are
+
+24
+00:01:11,180 --> 00:01:16,370
+typing, Eclipse gives us a auto complete suggestions, which is very helpful.
+
+25
+00:01:16,370 --> 00:01:19,650
+For example, in case you don't remember the exact syntax,
+
+26
+00:01:19,650 --> 00:01:22,190
+or the method, or you don't remember the parameters of the
+
+27
+00:01:22,190 --> 00:01:24,470
+method. Which is, you know, often the case especially where you
+
+28
+00:01:24,470 --> 00:01:27,590
+work with large libraries. So having that feature can really, really
+
+29
+00:01:27,590 --> 00:01:30,050
+help you. So now if we want to run our code
+
+30
+00:01:30,050 --> 00:01:33,380
+we can either click on the button up here, or we
+
+31
+00:01:33,380 --> 00:01:37,960
+can right-click in the Call window and select Run As Java
+
+32
+00:01:37,960 --> 00:01:41,370
+Application. And if we do that, Eclipse will run our tool,
+
+33
+00:01:41,370 --> 00:01:45,650
+and it will create, as you can see here, a console view that basically contains
+
+34
+00:01:45,650 --> 00:01:49,790
+the textual output of my program. And as expected, the output is Hello World.
diff --git a/usth/ICT2.7/P1L3 Integrated Development Environment Subtitles/7 - Eclipse Demo: Run Configuration - lang_en_vs6.srt b/usth/ICT2.7/P1L3 Integrated Development Environment Subtitles/7 - Eclipse Demo: Run Configuration - lang_en_vs6.srt
new file mode 100644
index 0000000..ad54f06
--- /dev/null
+++ b/usth/ICT2.7/P1L3 Integrated Development Environment Subtitles/7 - Eclipse Demo: Run Configuration - lang_en_vs6.srt	
@@ -0,0 +1,115 @@
+1
+00:00:00,140 --> 00:00:02,660
+So now that we have run our program, let's see what
+
+2
+00:00:02,660 --> 00:00:05,660
+happens exactly when you run a program within Eclipse. And to
+
+3
+00:00:05,660 --> 00:00:08,410
+do that I'm going to use the menu over here which is
+
+4
+00:00:08,410 --> 00:00:12,500
+the Run menu and I'm going to select Run Configurations, and this
+
+5
+00:00:12,500 --> 00:00:15,190
+brings up a window where you can change or run configurations.
+
+6
+00:00:15,190 --> 00:00:17,200
+Well first of all, you can see that here on the
+
+7
+00:00:17,200 --> 00:00:22,260
+left under Java application. Eclipse automatically created a Hello World run
+
+8
+00:00:22,260 --> 00:00:25,300
+configuration for our program. And this is where you can configure
+
+9
+00:00:25,300 --> 00:00:28,370
+the different parameters for your execution. For example,
+
+10
+00:00:28,370 --> 00:00:30,520
+you can select the main class. So here
+
+11
+00:00:30,520 --> 00:00:34,745
+it's, obviously, edu.gatech.HelloWorld. You can define different program
+
+12
+00:00:34,745 --> 00:00:36,920
+arguments. We don't have any for now. You can
+
+13
+00:00:36,920 --> 00:00:39,480
+also pass arguments to the virtual machine. You
+
+14
+00:00:39,480 --> 00:00:41,960
+can define which Java runtime environment you want to
+
+15
+00:00:41,960 --> 00:00:47,720
+use, Classpath and other environmental options. So let's
+
+16
+00:00:47,720 --> 00:00:50,650
+now try to pass some arguments to our program.
+
+17
+00:00:50,650 --> 00:00:54,390
+So for example here, I am just going to write George as
+
+18
+00:00:54,390 --> 00:00:58,450
+a possible parameter. I say Apply so that modify the configuration and
+
+19
+00:00:58,450 --> 00:01:01,510
+if i run the program of course, the output is not changing
+
+20
+00:01:01,510 --> 00:01:04,440
+because my program does not use the argument. But, let's see if
+
+21
+00:01:04,440 --> 00:01:07,060
+we do use the argument, what happens. So I'm going to slightly
+
+22
+00:01:07,060 --> 00:01:10,030
+modify the final program so that now, instead of printing hello
+
+23
+00:01:10,030 --> 00:01:13,420
+world, it will print hello followed by the first argument that I
+
+24
+00:01:13,420 --> 00:01:15,700
+will pass to the program. And if I do that, and I
+
+25
+00:01:15,700 --> 00:01:19,420
+go and I run the program, what I get is exactly what I
+
+26
+00:01:19,420 --> 00:01:23,420
+was expecting, which is Hello George. So this is the way in which you
+
+27
+00:01:23,420 --> 00:01:26,120
+can pass arguments to your execution, which
+
+28
+00:01:26,120 --> 00:01:27,640
+is something that might come in handy
+
+29
+00:01:27,640 --> 00:01:30,390
+for some other projects. When you need to run some code with an argument.
diff --git a/usth/ICT2.7/P1L3 Integrated Development Environment Subtitles/8 - Eclipse Demo: Debugging - lang_en_vs5.srt b/usth/ICT2.7/P1L3 Integrated Development Environment Subtitles/8 - Eclipse Demo: Debugging - lang_en_vs5.srt
new file mode 100644
index 0000000..025c2ba
--- /dev/null
+++ b/usth/ICT2.7/P1L3 Integrated Development Environment Subtitles/8 - Eclipse Demo: Debugging - lang_en_vs5.srt	
@@ -0,0 +1,275 @@
+1
+00:00:00,160 --> 00:00:03,090
+Now let's look at how we can do debugging within
+
+2
+00:00:03,090 --> 00:00:06,240
+Eclipse. I created a new file called AddNumbers which I'm
+
+3
+00:00:06,240 --> 00:00:10,770
+showing here. It takes two numbers, parses them into integers,
+
+4
+00:00:10,770 --> 00:00:14,870
+adds them and prints the sum, supposedly, of the two numbers.
+
+5
+00:00:14,870 --> 00:00:17,450
+Now we look at the run configuration for this program,
+
+6
+00:00:17,450 --> 00:00:19,670
+and here you can see that we're passing two arguments,
+
+7
+00:00:19,670 --> 00:00:22,060
+two and five, to the program. So now let's run
+
+8
+00:00:22,060 --> 00:00:25,468
+our program and see what happens. And the result says that
+
+9
+00:00:25,468 --> 00:00:28,150
+2 plus 5 is equal to 10, which is not
+
+10
+00:00:28,150 --> 00:00:31,030
+exactly correct. So we need to debug our program. We
+
+11
+00:00:31,030 --> 00:00:33,310
+need to figure out what's wrong with the program, why
+
+12
+00:00:33,310 --> 00:00:37,140
+the wrong result was, produced. So we're going to add a break
+
+13
+00:00:37,140 --> 00:00:40,260
+point here by double-clicking here on the side of the
+
+14
+00:00:40,260 --> 00:00:42,940
+code. And the break point is basically a place where I'm
+
+15
+00:00:42,940 --> 00:00:46,240
+telling my debugger to stop during the execution because I
+
+16
+00:00:46,240 --> 00:00:50,750
+want to inspect the state of the program. So to start
+
+17
+00:00:50,750 --> 00:00:54,690
+debugging, we select Debug as Java Application from the Context
+
+18
+00:00:54,690 --> 00:00:58,170
+menu, similar to what we were doing for running the program.
+
+19
+00:00:58,170 --> 00:01:00,190
+And as you can see, this asks us whether we want
+
+20
+00:01:00,190 --> 00:01:03,720
+to pass to the debug perspective, which is a, a perspective
+
+21
+00:01:03,720 --> 00:01:07,110
+specifically designed for debugging. We say yes. And as you
+
+22
+00:01:07,110 --> 00:01:10,750
+see here, it shows us, it's like a different, set of
+
+23
+00:01:10,750 --> 00:01:13,310
+views, so we can see the code down here with an
+
+24
+00:01:13,310 --> 00:01:16,100
+indication of where the execution is. And of course the execution
+
+25
+00:01:16,100 --> 00:01:18,610
+stopped at the break point, which is exactly where
+
+26
+00:01:18,610 --> 00:01:21,850
+we told the debugger to stop. So let's look at
+
+27
+00:01:21,850 --> 00:01:24,400
+some of the other views in this perspective. The view
+
+28
+00:01:24,400 --> 00:01:27,370
+here on the right-hand side, for example, shows the variables
+
+29
+00:01:27,370 --> 00:01:30,720
+in scope and the break points that are currently active
+
+30
+00:01:30,720 --> 00:01:33,240
+for the debugging session. This is where the editor is
+
+31
+00:01:33,240 --> 00:01:36,710
+at. The outline of the program and the console at
+
+32
+00:01:36,710 --> 00:01:41,520
+the bottom. So now let's execute one line by clicking
+
+33
+00:01:41,520 --> 00:01:45,400
+on the Step Over button here at the top, and this will
+
+34
+00:01:45,400 --> 00:01:49,150
+execute the line that is currently highlighted and therefore it will move to
+
+35
+00:01:49,150 --> 00:01:51,500
+the next line. And as you can see, one nice feature is that
+
+36
+00:01:51,500 --> 00:01:54,760
+if I move the mouse over a variable, I can see the value
+
+37
+00:01:54,760 --> 00:01:57,710
+of the variable. And the same thing I can do if I look
+
+38
+00:01:57,710 --> 00:02:00,690
+at the variables windows here on the right. If I click it, it
+
+39
+00:02:00,690 --> 00:02:03,960
+will tell me what is the value of the variable, and in case
+
+40
+00:02:03,960 --> 00:02:07,410
+of more complex variables you can even expand it and get more details.
+
+41
+00:02:07,410 --> 00:02:10,870
+So now let's step over another line by clicking again this button,
+
+42
+00:02:10,870 --> 00:02:13,180
+and as you can see now we get to the line that
+
+43
+00:02:13,180 --> 00:02:16,410
+is actually performing the sum, supposedly, so now let's do the same
+
+44
+00:02:16,410 --> 00:02:19,100
+thing that we did before, and let's mouse over b, and we can
+
+45
+00:02:19,100 --> 00:02:22,150
+see that the value of b is five, as expected. So now
+
+46
+00:02:22,150 --> 00:02:27,080
+let's step over this line as well, and execute the actual sum. And
+
+47
+00:02:27,080 --> 00:02:29,730
+doing the mouseover thing, we can see that the value of sum
+
+48
+00:02:29,730 --> 00:02:33,000
+is ten, which is not right, of course. In fact, if we check
+
+49
+00:02:33,000 --> 00:02:35,590
+a gain we can see that value of A is two. The
+
+50
+00:02:35,590 --> 00:02:39,130
+value of B is five and therefore it's clear that there's something
+
+51
+00:02:39,130 --> 00:02:41,780
+wrong going on here, and at this point we can notice that
+
+52
+00:02:41,780 --> 00:02:44,030
+here we are doing multiplication instead
+
+53
+00:02:44,030 --> 00:02:46,010
+of addition. And therefore that's what the
+
+54
+00:02:46,010 --> 00:02:49,260
+error is. And this is clearly a very simple case. Right? A
+
+55
+00:02:49,260 --> 00:02:51,440
+case in which probably you just needed to look at the code and
+
+56
+00:02:51,440 --> 00:02:54,150
+you didn't need the debugger. But you probably got the idea right?
+
+57
+00:02:54,150 --> 00:02:58,055
+So this can be extremely useful when you're debugging, when you're studying more
+
+58
+00:02:58,055 --> 00:03:01,533
+complex programs. If you want to stop the debugger because you're
+
+59
+00:03:01,533 --> 00:03:04,557
+done with your debugging session as in this case, you can
+
+60
+00:03:04,557 --> 00:03:07,518
+either click here on the Terminate button or you can also
+
+61
+00:03:07,518 --> 00:03:11,109
+just simply tell the debugger to continue the execution, to resume
+
+62
+00:03:11,109 --> 00:03:15,140
+the execution until the program terminates naturally. So, in this case,
+
+63
+00:03:15,140 --> 00:03:17,520
+we're going to click here just to show what happens. And what
+
+64
+00:03:17,520 --> 00:03:20,230
+happens is that, you know, the execution will just continue until
+
+65
+00:03:20,230 --> 00:03:23,690
+the program exits. So now let's say that we want to fix
+
+66
+00:03:23,690 --> 00:03:27,740
+this problem that we just discovered. So we replace the multiplication
+
+67
+00:03:27,740 --> 00:03:30,600
+with an addition, we save the program, and we execute the
+
+68
+00:03:30,600 --> 00:03:33,860
+program again by clicking on this button. And at this point,
+
+69
+00:03:33,860 --> 00:03:37,320
+unsurprisingly, we get the right result as shown in the console.
diff --git a/usth/ICT2.7/P1L4 Version Control Subtitles/1 - Lesson Overview - lang_en_vs5.srt b/usth/ICT2.7/P1L4 Version Control Subtitles/1 - Lesson Overview - lang_en_vs5.srt
new file mode 100644
index 0000000..936e3db
--- /dev/null
+++ b/usth/ICT2.7/P1L4 Version Control Subtitles/1 - Lesson Overview - lang_en_vs5.srt	
@@ -0,0 +1,43 @@
+1
+00:00:00,440 --> 00:00:06,190
+Hi and welcome to the second lesson on tools of the trade. In the
+
+2
+00:00:06,190 --> 00:00:09,710
+previous lesson we talked about IDEs. Integrated
+
+3
+00:00:09,710 --> 00:00:13,300
+Development Environments and in particular we discussed
+
+4
+00:00:13,300 --> 00:00:16,460
+the eclipse ID. Today we're going to
+
+5
+00:00:16,460 --> 00:00:19,780
+talk about another fundamental type of tools
+
+6
+00:00:19,780 --> 00:00:22,840
+in the software engineering arena. Version control
+
+7
+00:00:22,840 --> 00:00:26,140
+systems. And these are also called, revision
+
+8
+00:00:26,140 --> 00:00:30,620
+or source control systems. In particular, we will focus on a
+
+9
+00:00:30,620 --> 00:00:36,320
+specific version control system called git. And as we did for eclipse,
+
+10
+00:00:36,320 --> 00:00:40,510
+we will first present git from a conceptual standpoint. And then
+
+11
+00:00:40,510 --> 00:00:44,200
+we will do a demo. To get some hands-on experience with GIT.
diff --git a/usth/ICT2.7/P1L4 Version Control Subtitles/10 - Introduction to GIT - lang_en_vs6.srt b/usth/ICT2.7/P1L4 Version Control Subtitles/10 - Introduction to GIT - lang_en_vs6.srt
new file mode 100644
index 0000000..201c7a5
--- /dev/null
+++ b/usth/ICT2.7/P1L4 Version Control Subtitles/10 - Introduction to GIT - lang_en_vs6.srt	
@@ -0,0 +1,79 @@
+1
+00:00:00,240 --> 00:00:04,160
+One good representative of distributed version control systems, is
+
+2
+00:00:04,160 --> 00:00:08,320
+GIT. A distributed version control system that was initially designed
+
+3
+00:00:08,320 --> 00:00:11,297
+and developed by Linus Torvalds. I'm pretty sure you
+
+4
+00:00:11,297 --> 00:00:14,140
+know who Linus Torvalds is. He's basically this guy who
+
+5
+00:00:14,140 --> 00:00:17,070
+started and created the Linux operating system. And Linus
+
+6
+00:00:17,070 --> 00:00:20,140
+was unhappy with the existing version control systems, and wanted
+
+7
+00:00:20,140 --> 00:00:22,610
+a different one. He wanted to use it for maintaining
+
+8
+00:00:22,610 --> 00:00:25,330
+the Linux kernel. In particular, he wanted one with some
+
+9
+00:00:25,330 --> 00:00:28,550
+key characteristics. For example, the fact that it was distributed. He
+
+10
+00:00:28,550 --> 00:00:30,470
+wanted it to be fast. He wanted it to have a
+
+11
+00:00:30,470 --> 00:00:33,660
+simple design. And he wanted to have a strong support for
+
+12
+00:00:33,660 --> 00:00:37,370
+parallel branches, because many people were contributing to the kernel at the
+
+13
+00:00:37,370 --> 00:00:41,620
+same time. And therefore there many different branches of development. And
+
+14
+00:00:41,620 --> 00:00:45,120
+finally, he wanted for the virtual control system to be able to
+
+15
+00:00:45,120 --> 00:00:48,070
+handle large projects. As the Linux kernel is, and to do
+
+16
+00:00:48,070 --> 00:00:50,480
+it in an efficient way. So if you want to get an idea
+
+17
+00:00:50,480 --> 00:00:54,210
+of how popular GIT is today, there was a survey performed across the
+
+18
+00:00:54,210 --> 00:00:58,330
+Eclipse IDE users, and it showed that in 2013 GIT was used by
+
+19
+00:00:58,330 --> 00:01:02,950
+about 30% of the developers. So the, it had a 30% adoption rate.
+
+20
+00:01:02,950 --> 00:01:06,430
+So we will use a GIT as a version control system for the class.
diff --git a/usth/ICT2.7/P1L4 Version Control Subtitles/11 - Installing GIT - lang_en_vs5.srt b/usth/ICT2.7/P1L4 Version Control Subtitles/11 - Installing GIT - lang_en_vs5.srt
new file mode 100644
index 0000000..38eedc0
--- /dev/null
+++ b/usth/ICT2.7/P1L4 Version Control Subtitles/11 - Installing GIT - lang_en_vs5.srt	
@@ -0,0 +1,63 @@
+1
+00:00:00,120 --> 00:00:03,020
+As we did for Eclipse, and IDEs in general, we want
+
+2
+00:00:03,020 --> 00:00:05,133
+to start a GIT in a hands on way. So we're going
+
+3
+00:00:05,133 --> 00:00:08,425
+to start by seeing how to install GIT. And GIT is also
+
+4
+00:00:08,425 --> 00:00:12,440
+multiplatform, so you can install it no matter what operating system you
+
+5
+00:00:12,440 --> 00:00:15,980
+are using, unless of course you are using some arcane operating system.
+
+6
+00:00:15,980 --> 00:00:18,530
+But if you are using Linux, for instance, there should be a
+
+7
+00:00:18,530 --> 00:00:22,608
+package available that can install GIT for your specific distribution. If you're
+
+8
+00:00:22,608 --> 00:00:25,460
+using Mac OS, GIT is also available as part of XCode and
+
+9
+00:00:25,460 --> 00:00:29,270
+also as an independent package. Finally, if you're using Windows, GIT is
+
+10
+00:00:29,270 --> 00:00:33,090
+available as a package with an installer. In general, you can go
+
+11
+00:00:33,090 --> 00:00:37,290
+here to get information about how to get GIT, where to download
+
+12
+00:00:37,290 --> 00:00:39,975
+it, how to install it, and so on. So, now what I'd
+
+13
+00:00:39,975 --> 00:00:42,312
+like for you to do is to go, get GIT, install it,
+
+14
+00:00:42,312 --> 00:00:45,469
+in case you don't have it installed already on your machine. And
+
+15
+00:00:45,469 --> 00:00:48,253
+after that, you should be able to run GIT from the command
+
+16
+00:00:48,253 --> 00:00:51,120
+line. And, that's exactly what we're going to do through a demo.
diff --git a/usth/ICT2.7/P1L4 Version Control Subtitles/12 - GIT Workflow - lang_en_vs5.srt b/usth/ICT2.7/P1L4 Version Control Subtitles/12 - GIT Workflow - lang_en_vs5.srt
new file mode 100644
index 0000000..84f0f2e
--- /dev/null
+++ b/usth/ICT2.7/P1L4 Version Control Subtitles/12 - GIT Workflow - lang_en_vs5.srt	
@@ -0,0 +1,507 @@
+1
+00:00:00,070 --> 00:00:02,100
+But before jumping into the demo I would like
+
+2
+00:00:02,100 --> 00:00:05,370
+to give a high level overview of the GIT workflow,
+
+3
+00:00:05,370 --> 00:00:08,420
+which will help you better, following the demo. So let
+
+4
+00:00:08,420 --> 00:00:12,480
+me start by representing four fundamental elements in the GIT
+
+5
+00:00:12,480 --> 00:00:15,640
+workflow which are these four: the workspace which is your
+
+6
+00:00:15,640 --> 00:00:19,980
+local directory. The index, also called the stage, and we'll
+
+7
+00:00:19,980 --> 00:00:22,470
+see in a minute what the index is. Then, we
+
+8
+00:00:22,470 --> 00:00:25,380
+have the local repository. We'll also refer to this as
+
+9
+00:00:25,380 --> 00:00:27,910
+HEAD in the, when we explain the different commands
+
+10
+00:00:27,910 --> 00:00:31,340
+and then, the word flow. And finally, the remote repository.
+
+11
+00:00:31,340 --> 00:00:34,600
+If you consider a file in your work space it
+
+12
+00:00:34,600 --> 00:00:37,860
+can be in three possible states. It can be committed
+
+13
+00:00:37,860 --> 00:00:40,170
+which means that the data, the latest changes to the
+
+14
+00:00:40,170 --> 00:00:45,030
+file are safely stored here. It could be modified, which
+
+15
+00:00:45,030 --> 00:00:47,840
+is the case of the file being changed and no,
+
+16
+00:00:47,840 --> 00:00:50,710
+none of these changes being saved to the local repository
+
+17
+00:00:50,710 --> 00:00:54,440
+so locally modified or it can be staged. And
+
+18
+00:00:54,440 --> 00:00:58,270
+stage means that the file is basically part of this
+
+19
+00:00:58,270 --> 00:01:01,620
+index. And what that means, that it's been tagged
+
+20
+00:01:01,620 --> 00:01:04,890
+to be considered in the next commit. And I know
+
+21
+00:01:04,890 --> 00:01:08,070
+that this is not all 100% intuitive, so let's
+
+22
+00:01:08,070 --> 00:01:10,860
+look at that again by considering the actual workflow and
+
+23
+00:01:10,860 --> 00:01:12,680
+let's see what happens when you issue the different
+
+24
+00:01:12,680 --> 00:01:16,060
+commands in git. So the first command that you normally
+
+25
+00:01:16,060 --> 00:01:18,520
+run in case you, you're getting access to a remote
+
+26
+00:01:18,520 --> 00:01:21,940
+repository, is the git clone command. And the git clone,
+
+27
+00:01:21,940 --> 00:01:24,880
+followed by the url for that repository, will create a
+
+28
+00:01:24,880 --> 00:01:28,580
+local copy of the repository in your workspace. And of
+
+29
+00:01:28,580 --> 00:01:30,310
+course, you don't have to do this step if you're
+
+30
+00:01:30,310 --> 00:01:34,380
+creating the repository yourself. The next command that we already
+
+31
+00:01:34,380 --> 00:01:38,170
+saw is the command add. And what the command add
+
+32
+00:01:38,170 --> 00:01:41,130
+does is to add a file that is in the
+
+33
+00:01:41,130 --> 00:01:44,630
+workspace to this index. And we say that after that, the
+
+34
+00:01:44,630 --> 00:01:48,700
+file is staged. So it's marked to be committed, but not
+
+35
+00:01:48,700 --> 00:01:53,350
+yet committed. And here I'm just mentioning this minus u option.
+
+36
+00:01:53,350 --> 00:01:56,330
+If you specify the minus u option, you will also consider deleted
+
+37
+00:01:56,330 --> 00:01:58,820
+files File, but let's not get there for now, we'll talk
+
+38
+00:01:58,820 --> 00:02:01,240
+about that when we do the demo. As I said, if you
+
+39
+00:02:01,240 --> 00:02:03,720
+add the file, it just gets added to this index but
+
+40
+00:02:03,720 --> 00:02:06,430
+is not actually committed, so what you need to do, is to
+
+41
+00:02:06,430 --> 00:02:10,389
+commit the file, so when you execute git commit, all the
+
+42
+00:02:10,389 --> 00:02:13,970
+files that are staged, that are released it here, their changes
+
+43
+00:02:13,970 --> 00:02:17,080
+will be committed to the local repository. So your files, as
+
+44
+00:02:17,080 --> 00:02:18,970
+I was saying, they can be in three states. They will
+
+45
+00:02:18,970 --> 00:02:21,820
+go from the modified state to the stage state when you
+
+46
+00:02:21,820 --> 00:02:24,200
+execute the app. And then from the stage state to the
+
+47
+00:02:24,200 --> 00:02:27,510
+committed state when you perform a GIT Commit. Okay, so at
+
+48
+00:02:27,510 --> 00:02:31,780
+this point your changes are safely stored in the local repository.
+
+49
+00:02:31,780 --> 00:02:34,370
+Notice that you can also perform these two steps at
+
+50
+00:02:34,370 --> 00:02:38,150
+once by executing a Commit -a. So if you have
+
+51
+00:02:38,150 --> 00:02:40,920
+a set of modified files, and all these files are
+
+52
+00:02:40,920 --> 00:02:44,550
+already part of the repository, so they're already known to diversion
+
+53
+00:02:44,550 --> 00:02:47,540
+control system, you can simply execute a commit -a.
+
+54
+00:02:47,540 --> 00:02:50,040
+And what the commit -a command will do, it
+
+55
+00:02:50,040 --> 00:02:53,080
+will stage your file and then commit them. All at
+
+56
+00:02:53,080 --> 00:02:56,650
+once. So it's a convenient shortcut. Of course, as I said,
+
+57
+00:02:56,650 --> 00:02:58,710
+this will not work if the file is a new file.
+
+58
+00:02:58,710 --> 00:03:00,730
+So if a file is a new file, you have to manually add
+
+59
+00:03:00,730 --> 00:03:04,620
+it. Otherwise commit -a will just stage and commit at once.
+
+60
+00:03:04,620 --> 00:03:07,400
+As we discussed when we looked at the diffence between centralized
+
+61
+00:03:07,400 --> 00:03:10,520
+and decentralized version console system. We saw that in the case
+
+62
+00:03:10,520 --> 00:03:13,930
+of the decentralized, there is a local repository which is this one.
+
+63
+00:03:13,930 --> 00:03:17,190
+And then you have to explicitly push your changes to a remote
+
+64
+00:03:17,190 --> 00:03:21,850
+repository, and this is exactly what the git push command does. It pushes
+
+65
+00:03:21,850 --> 00:03:25,930
+your changes that are in the local repository to the remote repository
+
+66
+00:03:25,930 --> 00:03:28,160
+so at this point all of your changes will be
+
+67
+00:03:28,160 --> 00:03:31,680
+visible to anyone who has access to the remote repository.
+
+68
+00:03:31,680 --> 00:03:33,710
+Now, let's see the opposite flow so how does it
+
+69
+00:03:33,710 --> 00:03:36,640
+work when you're actually getting files from the repository instead
+
+70
+00:03:36,640 --> 00:03:39,650
+of committing files to the repository. So the first command
+
+71
+00:03:39,650 --> 00:03:43,280
+I want to mention is the get fetch command and
+
+72
+00:03:43,280 --> 00:03:46,900
+what the get fetch command does is to get files from
+
+73
+00:03:46,900 --> 00:03:50,680
+the remote repositories to your local repository, but not yet to
+
+74
+00:03:50,680 --> 00:03:53,890
+your working directory. And we will see what is the usefullness of
+
+75
+00:03:53,890 --> 00:03:56,900
+doing this operation. Of having the files all in the local respository,
+
+76
+00:03:56,900 --> 00:03:59,380
+but not in your local directory. So, what that means, just to
+
+77
+00:03:59,380 --> 00:04:01,360
+make sure that we're on the same page. Is that you
+
+78
+00:04:01,360 --> 00:04:05,620
+will not see these files when you workspace. You will still have
+
+79
+00:04:05,620 --> 00:04:09,030
+your local files here. So this is sort of a physical distinction.
+
+80
+00:04:09,030 --> 00:04:12,060
+In order to get your data files from the local repositories to
+
+81
+00:04:12,060 --> 00:04:14,470
+your workspace you have to issue another command. Which is
+
+82
+00:04:14,470 --> 00:04:18,250
+the command git merge. Git merge will take the changes in
+
+83
+00:04:18,250 --> 00:04:21,870
+local repository and get them to your local workspace. So at
+
+84
+00:04:21,870 --> 00:04:25,460
+this point your files will be updated. To what is in
+
+85
+00:04:25,460 --> 00:04:27,730
+the remote reposity. Or at least what was in the
+
+86
+00:04:27,730 --> 00:04:30,810
+remote reposity at the time of the fetch. SImilarly to what
+
+87
+00:04:30,810 --> 00:04:34,340
+happened for the add and commit. There's a shortcut which is
+
+88
+00:04:34,340 --> 00:04:37,230
+the command git pull. So in case you want to get
+
+89
+00:04:37,230 --> 00:04:40,590
+the changes directly. To your work space with a single
+
+90
+00:04:40,590 --> 00:04:44,120
+command, you can issue a git pull command and what will
+
+91
+00:04:44,120 --> 00:04:46,560
+happen, is that the changes will get collected from the
+
+92
+00:04:46,560 --> 00:04:49,810
+remote repository and they will go to your local repository and
+
+93
+00:04:49,810 --> 00:04:51,990
+to your work space, at once. So this has the
+
+94
+00:04:51,990 --> 00:04:55,820
+same affect as performing a git fetch and a git merge.
+
+95
+00:04:55,820 --> 00:04:59,160
+So if we can do everything in one command, why,
+
+96
+00:04:59,160 --> 00:05:03,290
+why we want to fetch and berch as two separate operations?
+
+97
+00:05:03,290 --> 00:05:05,920
+So one of the reason is because this allows us
+
+98
+00:05:05,920 --> 00:05:09,410
+to compare files before we actually get the latest version
+
+99
+00:05:09,410 --> 00:05:12,600
+of the files. In particular, I can run the command
+
+100
+00:05:12,600 --> 00:05:17,310
+git diff head to get the difference between my local files,
+
+101
+00:05:17,310 --> 00:05:20,330
+the files in my working directory, and the files in
+
+102
+00:05:20,330 --> 00:05:22,800
+my local repository. So what I can do, I can
+
+103
+00:05:22,800 --> 00:05:25,550
+fetch the files from the remote repository, and once I
+
+104
+00:05:25,550 --> 00:05:29,260
+fetch these files. I can run a git diff head and
+
+105
+00:05:29,260 --> 00:05:32,620
+check what the differences are. And based on the differences decide
+
+106
+00:05:32,620 --> 00:05:35,554
+whether I want to merge or not. So while we are talking about
+
+107
+00:05:35,554 --> 00:05:37,890
+git diff, there is something else that you can use with the
+
+108
+00:05:37,890 --> 00:05:41,060
+diff command. So what you can do, you can run git diff
+
+109
+00:05:41,060 --> 00:05:44,930
+without further specifying head. In this case, what the command tell you
+
+110
+00:05:44,930 --> 00:05:48,310
+is the difference between the files that you have in your work
+
+111
+00:05:48,310 --> 00:05:51,780
+space and the ones that are staged for a commit. So basically,
+
+112
+00:05:51,780 --> 00:05:54,630
+what it will be telling you, is that what you could still
+
+113
+00:05:54,630 --> 00:05:58,300
+add to the stage for the further commit, and that you
+
+114
+00:05:58,300 --> 00:06:01,230
+haven't already. So what local changes will not make it to the
+
+115
+00:06:01,230 --> 00:06:04,440
+next commit, basically. And this you can use, for example, as
+
+116
+00:06:04,440 --> 00:06:07,450
+a sanity check before doing a commit to make sure all the
+
+117
+00:06:07,450 --> 00:06:09,980
+local changes that you have, and that you want to commit,
+
+118
+00:06:09,980 --> 00:06:13,230
+are actually staged and therefore will be considered. So now we will
+
+119
+00:06:13,230 --> 00:06:16,930
+cover all of the commands that we saw here. In our practical
+
+120
+00:06:16,930 --> 00:06:20,560
+demo. But please feel free to refer back to this Git Workflow
+
+121
+00:06:20,560 --> 00:06:23,570
+to get a kind of a high level vision. Or maybe you want to keep it next to
+
+122
+00:06:23,570 --> 00:06:26,110
+you, because this really gives you the overall structure
+
+123
+00:06:26,110 --> 00:06:28,450
+and the overall view of what happens when you
+
+124
+00:06:28,450 --> 00:06:31,160
+run the different commands. And it also helps you
+
+125
+00:06:31,160 --> 00:06:34,840
+visualize The different elements that are relevant when you're
+
+126
+00:06:34,840 --> 00:06:37,970
+using GIT. So the workspace, once more, the index
+
+127
+00:06:37,970 --> 00:06:40,790
+or stage, the local repository, and the remote repository.
diff --git a/usth/ICT2.7/P1L4 Version Control Subtitles/13 - GIT Demo: Intro to Git - lang_en_vs5.srt b/usth/ICT2.7/P1L4 Version Control Subtitles/13 - GIT Demo: Intro to Git - lang_en_vs5.srt
new file mode 100644
index 0000000..d3b3a24
--- /dev/null
+++ b/usth/ICT2.7/P1L4 Version Control Subtitles/13 - GIT Demo: Intro to Git - lang_en_vs5.srt	
@@ -0,0 +1,1095 @@
+1
+00:00:00,120 --> 00:00:02,170
+In this first part of the git demo, we will
+
+2
+00:00:02,170 --> 00:00:05,080
+call it the basics of git. So for example, how to
+
+3
+00:00:05,080 --> 00:00:08,280
+introduce yourself to git, how to create a repository, how to
+
+4
+00:00:08,280 --> 00:00:12,450
+commit changes and get changes from the repository, and so on.
+
+5
+00:00:12,450 --> 00:00:15,140
+So after you installed git you should have the git tool
+
+6
+00:00:15,140 --> 00:00:18,150
+available on the command line, so you can run the command
+
+7
+00:00:18,150 --> 00:00:21,110
+git and, if you just execute git you will get the
+
+8
+00:00:21,110 --> 00:00:25,930
+usage information for git, with the most commonly used git commands.
+
+9
+00:00:25,930 --> 00:00:28,940
+And to find information on any command, you can simply
+
+10
+00:00:28,940 --> 00:00:32,310
+type git help and the name of the command. For
+
+11
+00:00:32,310 --> 00:00:35,240
+example, lets try to write git help init. And that
+
+12
+00:00:35,240 --> 00:00:38,960
+brings up the git manual page for git init, which describes
+
+13
+00:00:38,960 --> 00:00:41,590
+the command, the synopsis, and so on. Now, lets get
+
+14
+00:00:41,590 --> 00:00:45,970
+started with using git by introducing ourselves to git, which is
+
+15
+00:00:45,970 --> 00:00:47,830
+the first thing we need to do. To do that
+
+16
+00:00:47,830 --> 00:00:51,310
+we use the git config command, in particular we are going to
+
+17
+00:00:51,310 --> 00:00:54,170
+write to the git config minus, minus global
+
+18
+00:00:54,170 --> 00:00:56,440
+user dot name. Which means we are telling it
+
+19
+00:00:56,440 --> 00:00:59,900
+our user name. We'll specify our user name which
+
+20
+00:00:59,900 --> 00:01:02,970
+in this case is George P. Burdell. You could
+
+21
+00:01:02,970 --> 00:01:04,970
+also provide your email address in the same
+
+22
+00:01:04,970 --> 00:01:09,370
+way. So you still use the git config --global
+
+23
+00:01:09,370 --> 00:01:12,750
+command. But in this case you will write user.email
+
+24
+00:01:12,750 --> 00:01:16,580
+as the property. And then you'll specify a suitable
+
+25
+00:01:16,580 --> 00:01:19,670
+email address. In this case, the email address of George P.
+
+26
+00:01:19,670 --> 00:01:23,780
+Burdell. We will now look at some commonly used commands that to
+
+27
+00:01:23,780 --> 00:01:27,210
+create and maintain a local repository. Let's first create a
+
+28
+00:01:27,210 --> 00:01:30,510
+new project and call it my project. So, to do that we
+
+29
+00:01:30,510 --> 00:01:32,790
+are simply going to create a directory and then we're going
+
+30
+00:01:32,790 --> 00:01:35,520
+to move into that directory. Now, if we try to call the
+
+31
+00:01:35,520 --> 00:01:39,000
+git status command at this point to see what's the state of
+
+32
+00:01:39,000 --> 00:01:41,990
+my project, of course git doesn't know anything about this project, right?
+
+33
+00:01:41,990 --> 00:01:44,360
+So, you will get an error. It will tell you that, basically,
+
+34
+00:01:44,360 --> 00:01:47,080
+we're not in a git repository. So how do we create a git
+
+35
+00:01:47,080 --> 00:01:50,090
+repository? How do we make this? A Git repository, but we do it
+
+36
+00:01:50,090 --> 00:01:53,560
+by calling git init and the output will tell you that the
+
+37
+00:01:53,560 --> 00:01:56,580
+repository was initialized. If we check the status again, you will see
+
+38
+00:01:56,580 --> 00:01:59,790
+that now Git recognizes the repository and will tell you that there is
+
+39
+00:01:59,790 --> 00:02:01,160
+nothing to commit because, of course,
+
+40
+00:02:01,160 --> 00:02:03,190
+the repository is completely empty. So let's
+
+41
+00:02:03,190 --> 00:02:07,380
+just create a new, empty file. Which we're going to call REAME. So
+
+42
+00:02:07,380 --> 00:02:10,008
+now if you run git status, as you can see, git will
+
+43
+00:02:10,008 --> 00:02:13,250
+tell you there is a file that's called README, but it's untracked.
+
+44
+00:02:13,250 --> 00:02:15,600
+Now what that means is that the file not staged, if you
+
+45
+00:02:15,600 --> 00:02:18,710
+remember our lesson. So what we need to do, we first need
+
+46
+00:02:18,710 --> 00:02:22,040
+to tell git that, you know, this needs to be considered. And
+
+47
+00:02:22,040 --> 00:02:25,690
+the way we do that, is by calling the git at command
+
+48
+00:02:25,690 --> 00:02:28,880
+and then we specify README as the argument for the command. If
+
+49
+00:02:28,880 --> 00:02:33,090
+we call again, Git status. Now, as you can see, Git knows
+
+50
+00:02:33,090 --> 00:02:35,780
+that there is a new file called README, because the file
+
+51
+00:02:35,780 --> 00:02:38,390
+is staged. So Git is aware of the fact that this
+
+52
+00:02:38,390 --> 00:02:41,490
+file has to be committed. So, to commit a file,
+
+53
+00:02:41,490 --> 00:02:45,410
+we simply execute git commit, which will open a text editor, which
+
+54
+00:02:45,410 --> 00:02:48,500
+can be different, depending on what is your environment, and here
+
+55
+00:02:48,500 --> 00:02:50,980
+we need to add a comment to be added to the commit.
+
+56
+00:02:50,980 --> 00:02:54,760
+So here we simply write in Added README file, then we
+
+57
+00:02:54,760 --> 00:02:58,170
+can close and save And this will add the file to the
+
+58
+00:02:58,170 --> 00:03:01,310
+Git repository. The local Git repository of course. At this
+
+59
+00:03:01,310 --> 00:03:04,220
+point, if we ran Git status again to see where we are.
+
+60
+00:03:04,220 --> 00:03:06,400
+You can see that Git tells you that there is nothing
+
+61
+00:03:06,400 --> 00:03:08,660
+to commit. Because of course the only file that we have, is
+
+62
+00:03:08,660 --> 00:03:13,070
+committed to the repository. Now, let's make some changes to our
+
+63
+00:03:13,070 --> 00:03:17,270
+README file. I'm just going to add some text here. Once more, we
+
+64
+00:03:17,270 --> 00:03:20,050
+can run git status, and at this point, git knows about
+
+65
+00:03:20,050 --> 00:03:23,430
+this file. So, it will know that README file has been modified.
+
+66
+00:03:23,430 --> 00:03:25,280
+Remember that before, it was telling you that it was a new
+
+67
+00:03:25,280 --> 00:03:28,310
+file, now it knows that there was a different version in the
+
+68
+00:03:28,310 --> 00:03:31,430
+repository. So something we can do, at this point, for example, is
+
+69
+00:03:31,430 --> 00:03:34,820
+to check the differences. Between this file and the committed one by
+
+70
+00:03:34,820 --> 00:03:38,040
+executing get diff readme and if you look at the output of
+
+71
+00:03:38,040 --> 00:03:42,320
+the get diff command here, you can see that this line, readme
+
+72
+00:03:42,320 --> 00:03:45,170
+file content was added and you'll see that it was added because
+
+73
+00:03:45,170 --> 00:03:48,610
+there's a plus sign before that line. In case of deletion of lines,
+
+74
+00:03:48,610 --> 00:03:51,460
+you'll see a minusm sign there. So at this point, if we
+
+75
+00:03:51,460 --> 00:03:54,950
+want to commit our file, remember that we'll always have to tell git
+
+76
+00:03:54,950 --> 00:03:58,070
+that we want to stage the file before committing it. Otherwise, it
+
+77
+00:03:58,070 --> 00:04:01,420
+will be ignored by the commit operation. So to tell git, that the
+
+78
+00:04:01,420 --> 00:04:04,140
+file has to be staged, we will, can use the usual git
+
+79
+00:04:04,140 --> 00:04:07,140
+add command. But if you remember the lesson, we can also use a
+
+80
+00:04:07,140 --> 00:04:10,150
+shortcut. So you, we don't really have to do this in two steps.
+
+81
+00:04:10,150 --> 00:04:13,730
+We can simply say, git commit -a, and this will tell git to
+
+82
+00:04:13,730 --> 00:04:17,120
+commit all of the files that git knows about, which in this
+
+83
+00:04:17,120 --> 00:04:19,959
+case is only the written file of course. Something else that we can
+
+84
+00:04:19,959 --> 00:04:22,950
+do, is that we can also provide the right away message for
+
+85
+00:04:22,950 --> 00:04:26,140
+the commit, without having to open an editor. So, to do that we
+
+86
+00:04:26,140 --> 00:04:29,760
+can specify the -n option. And at this point a we can
+
+87
+00:04:29,760 --> 00:04:34,050
+just put a in double quotes our content we press enter and as
+
+88
+00:04:34,050 --> 00:04:36,690
+you can see it will notify us that one file was changed
+
+89
+00:04:36,690 --> 00:04:38,850
+and in particular it will also tell you that there was an a
+
+90
+00:04:38,850 --> 00:04:41,470
+insertion again if we run git status you will see that
+
+91
+00:04:41,470 --> 00:04:44,800
+there is nothing else to commit. So now lets imagine that
+
+92
+00:04:44,800 --> 00:04:48,390
+you want to see the version history for your repository. You
+
+93
+00:04:48,390 --> 00:04:51,760
+can do that by running the git log command. So if
+
+94
+00:04:51,760 --> 00:04:54,560
+you run that, it will show you all the different commits
+
+95
+00:04:54,560 --> 00:04:57,990
+For your repository. And each commit has got a commit ID, as
+
+96
+00:04:57,990 --> 00:05:01,010
+you can see here and the one down here is
+
+97
+00:05:01,010 --> 00:05:04,740
+the first commit, where as the one above is the second commit.
+
+98
+00:05:04,740 --> 00:05:07,670
+And as you can see, we'll also show you the comments associated
+
+99
+00:05:07,670 --> 00:05:11,070
+with each commit. And in case you wanted to see the changes introduced
+
+100
+00:05:11,070 --> 00:05:14,500
+by a commit. You can use that git show command, and you
+
+101
+00:05:14,500 --> 00:05:18,220
+can provide the commit ID for the commit that you're interested in.
+
+102
+00:05:18,220 --> 00:05:20,600
+And you don't really need to provide the whole ID, you can
+
+103
+00:05:20,600 --> 00:05:23,600
+provide the first four or more characters. So that's what we're going to
+
+104
+00:05:23,600 --> 00:05:26,540
+do here. So we're going to specify the second commit, and when we
+
+105
+00:05:26,540 --> 00:05:31,120
+execute the command it will show use the changes introduced by that commit.
+
+106
+00:05:31,120 --> 00:05:33,550
+To fetch a repository from a remote server, you can
+
+107
+00:05:33,550 --> 00:05:36,350
+use the git clone command. So you will write git clone
+
+108
+00:05:36,350 --> 00:05:39,140
+and then specify the URL. For the remote repository. Here
+
+109
+00:05:39,140 --> 00:05:44,260
+we are using the SSH protocal and there are different protocals
+
+110
+00:05:44,260 --> 00:05:46,680
+that can be used, so the remote repository can be
+
+111
+00:05:46,680 --> 00:05:49,800
+made available in different ways. As you can see, when you
+
+112
+00:05:49,800 --> 00:05:54,050
+clone the project, the project is cloned into the local directory.
+
+113
+00:05:54,050 --> 00:05:57,180
+If you wanted to import the project under a different name.
+
+114
+00:05:57,180 --> 00:05:59,790
+You could just specify the name that you want for the
+
+115
+00:05:59,790 --> 00:06:03,110
+Local Directory. For example, in this case, myproject2. And,
+
+116
+00:06:03,110 --> 00:06:06,630
+so here you'll get the project in my local work space
+
+117
+00:06:06,630 --> 00:06:09,530
+with the name that I specified. So, let's go inside one
+
+118
+00:06:09,530 --> 00:06:12,020
+of these two projects that have the same content because they're
+
+119
+00:06:12,020 --> 00:06:14,930
+coming from the repository. If you want to see the details
+
+120
+00:06:14,930 --> 00:06:18,550
+of the server you can use the remote command and specify
+
+121
+00:06:18,550 --> 00:06:22,230
+the flag -v. And here we'll show you what is the remote
+
+122
+00:06:22,230 --> 00:06:25,560
+repository now let's go ahead to make some changes to the project
+
+123
+00:06:25,560 --> 00:06:28,820
+for example let's add a file. So I'm just going to create this
+
+124
+00:06:28,820 --> 00:06:31,230
+empty file which I am going to call new file I'm going to
+
+125
+00:06:31,230 --> 00:06:34,890
+add it to my index so that it gets committed. Later on and
+
+126
+00:06:34,890 --> 00:06:37,650
+then I'm going to run git commit to actually commit it to the
+
+127
+00:06:37,650 --> 00:06:41,570
+local repository. And I'm going to specify the comment for the commit right
+
+128
+00:06:41,570 --> 00:06:44,120
+away here from the command line. So when we do that the
+
+129
+00:06:44,120 --> 00:06:47,680
+file gets added to my local repository. And if we want to double
+
+130
+00:06:47,680 --> 00:06:50,690
+check that, we can run git log. And if you look at
+
+131
+00:06:50,690 --> 00:06:53,360
+the last commit at the top, you can see that it's telling
+
+132
+00:06:53,360 --> 00:06:56,980
+me that the new file was added to the repository, showing the
+
+133
+00:06:56,980 --> 00:06:59,940
+comment that I added. But this is just for the local repository,
+
+134
+00:06:59,940 --> 00:07:03,100
+so I need to use the git push command to push it
+
+135
+00:07:03,100 --> 00:07:06,250
+to the remote repository. And at this point, when I run that,
+
+136
+00:07:06,250 --> 00:07:09,890
+my local changes will be committed. To the remote repository. So now
+
+137
+00:07:09,890 --> 00:07:13,110
+let's go to the other copy of the project that we created.
+
+138
+00:07:13,110 --> 00:07:16,660
+The one under directory myproject2. If you remember this project was
+
+139
+00:07:16,660 --> 00:07:19,610
+linked up to the same remote project. But of course, if we run
+
+140
+00:07:19,610 --> 00:07:22,720
+get log here, we don't see this latest change that we made, because
+
+141
+00:07:22,720 --> 00:07:25,970
+we didn't synchronize this local copy with the remote copy. And so we
+
+142
+00:07:25,970 --> 00:07:28,530
+just have these files, the README and ,Five that worked there before.
+
+143
+00:07:28,530 --> 00:07:30,720
+So what we need to do is that we need to pull the
+
+144
+00:07:30,720 --> 00:07:34,180
+changes from the remote repository using git pull, and when we do that,
+
+145
+00:07:34,180 --> 00:07:38,130
+that will actually pull these changes and therefore, create the new files that
+
+146
+00:07:38,130 --> 00:07:41,340
+we created in the other directory. And if we run git log now,
+
+147
+00:07:41,340 --> 00:07:43,790
+you can see that now we have the new entry. The comment at
+
+148
+00:07:43,790 --> 00:07:46,920
+the top, that says this new file was added and of course, this
+
+149
+00:07:46,920 --> 00:07:49,880
+is just an example, so we had two copies of the project on the
+
+150
+00:07:49,880 --> 00:07:52,990
+same machine and for the same user, so the normal users scenario for
+
+151
+00:07:52,990 --> 00:07:56,230
+this, it will be that, each user will have their local copy, but this
+
+152
+00:07:56,230 --> 00:07:59,220
+should have given you the idea of how, git allows you to work
+
+153
+00:07:59,220 --> 00:08:03,210
+on some local file. Commit them and push them to a remote repository and
+
+154
+00:08:03,210 --> 00:08:06,680
+other users to get your changes, do further changes push
+
+155
+00:08:06,680 --> 00:08:08,860
+them as well and then, you know, they will allow you
+
+156
+00:08:08,860 --> 00:08:10,890
+to get their changes, and so on and so forth. So
+
+157
+00:08:10,890 --> 00:08:15,540
+really allows this collaboration between different users and keeping track
+
+158
+00:08:15,540 --> 00:08:18,730
+of all the changes made by the different users. So now
+
+159
+00:08:18,730 --> 00:08:21,860
+let's look at some more advanced concept, which are the concept
+
+160
+00:08:21,860 --> 00:08:25,600
+of branching, and merging. So what branching means is basically is
+
+161
+00:08:25,600 --> 00:08:28,540
+to make a copy, to create a branch of the current
+
+162
+00:08:28,540 --> 00:08:32,070
+project so that we can work on that copy indpendently from the
+
+163
+00:08:32,070 --> 00:08:34,740
+other copy, from the other branch. And then we can decide whether
+
+164
+00:08:34,740 --> 00:08:37,190
+we want to keep, both branches, or we want to merge them at
+
+165
+00:08:37,190 --> 00:08:40,510
+some point. And you can of course have multiple branches, not just two.
+
+166
+00:08:40,510 --> 00:08:43,558
+And the reason why this is particularly useful is because in many
+
+167
+00:08:43,558 --> 00:08:46,790
+cases if you think, about the way we develop software in general,
+
+168
+00:08:46,790 --> 00:08:50,030
+we work with artifacts. We might have the need to create kind
+
+169
+00:08:50,030 --> 00:08:53,910
+of a separate copy of your work space. To do some experiments for example.
+
+170
+00:08:53,910 --> 00:08:54,940
+So you want to change something in
+
+171
+00:08:54,940 --> 00:08:56,250
+the code, you're not really sure it's going to
+
+172
+00:08:56,250 --> 00:08:57,650
+work and you don't want to touch
+
+173
+00:08:57,650 --> 00:08:59,500
+your main copy. So that's the perfect application
+
+174
+00:08:59,500 --> 00:09:00,830
+for branching. If you want to do
+
+175
+00:09:00,830 --> 00:09:02,710
+something like that...you want to experiment or do
+
+176
+00:09:02,710 --> 00:09:04,800
+some modifications that you're not sure about,
+
+177
+00:09:04,800 --> 00:09:06,820
+you will branch your code, you will do
+
+178
+00:09:06,820 --> 00:09:08,230
+the changes...and then if you're happy with
+
+179
+00:09:08,230 --> 00:09:09,890
+the changes, you will merge that branch
+
+180
+00:09:09,890 --> 00:09:13,250
+with the original one, or worse if you're not happy with the changes you will
+
+181
+00:09:13,250 --> 00:09:16,680
+just throw away that branch. So this is just one possible use of branch but
+
+182
+00:09:16,680 --> 00:09:18,950
+it's one of the main uses of that. So in all let's see how that
+
+183
+00:09:18,950 --> 00:09:21,070
+can be done with git. So first of all if you
+
+184
+00:09:21,070 --> 00:09:24,740
+want to see which branches are currently present in your project, you can
+
+185
+00:09:24,740 --> 00:09:28,260
+simply execute git branch, and in this case, you can see
+
+186
+00:09:28,260 --> 00:09:31,090
+that there's only one branch, which is called master, and the star
+
+187
+00:09:31,090 --> 00:09:33,940
+there indicates that this is our current branch. So how do
+
+188
+00:09:33,940 --> 00:09:37,210
+we create a new branch? So we simply run the command
+
+189
+00:09:37,210 --> 00:09:41,010
+git branch and specify a name for the new branch, for example we'll
+
+190
+00:09:41,010 --> 00:09:44,110
+call it newBranch, to make it very explicit. At this point,
+
+191
+00:09:44,110 --> 00:09:46,940
+if we run git branch of course, we will have
+
+192
+00:09:46,940 --> 00:09:50,410
+a new branch plus master will still be our current branch. So
+
+193
+00:09:50,410 --> 00:09:52,780
+if you want to switch to the new branch, we will use
+
+194
+00:09:52,780 --> 00:09:56,510
+the git checkout command and specify the name of the branch that
+
+195
+00:09:56,510 --> 00:10:00,220
+we want to become our current branch. So when we run that,
+
+196
+00:10:00,220 --> 00:10:02,780
+git will tell us that we switched to the new branch. And
+
+197
+00:10:02,780 --> 00:10:05,920
+if we run git branch you will see that now the star
+
+198
+00:10:05,920 --> 00:10:09,130
+is next to newBranch because that's our current branch. There is a
+
+199
+00:10:09,130 --> 00:10:12,834
+shortcut for these two commands. If you run the command git
+
+200
+00:10:12,834 --> 00:10:17,240
+checkout specify the -b flag and then the name of
+
+201
+00:10:17,240 --> 00:10:19,790
+the new branch it will do both things at the same
+
+202
+00:10:19,790 --> 00:10:22,910
+time. It will create the new branch called testing in this
+
+203
+00:10:22,910 --> 00:10:25,760
+case, and then it will switch to new branch and then
+
+204
+00:10:25,760 --> 00:10:28,860
+it will tell you after executing the command. So now if
+
+205
+00:10:28,860 --> 00:10:31,290
+we look at the git branch output, you can see that
+
+206
+00:10:31,290 --> 00:10:35,090
+there is three branches and we are currently on the testing branch.
+
+207
+00:10:35,090 --> 00:10:37,300
+So now let's create a new file and just call it test
+
+208
+00:10:37,300 --> 00:10:41,180
+file, put some content in there, save it, we edit and commit it.
+
+209
+00:10:47,380 --> 00:10:50,280
+And as you can see, now in this current branch, we have our
+
+210
+00:10:50,280 --> 00:10:53,430
+testFile. So now let's switch to a different branch. So let's go back
+
+211
+00:10:53,430 --> 00:10:57,550
+to the master branch using the usual git checkout command. So now if
+
+212
+00:10:57,550 --> 00:11:00,310
+we do an ls, if we check the content of the current directory,
+
+213
+00:11:00,310 --> 00:11:03,140
+we can see that the testFile is not there, because of course, it's
+
+214
+00:11:03,140 --> 00:11:06,070
+not in this branch. so now let's assume that we are happy with
+
+215
+00:11:06,070 --> 00:11:09,260
+the testFile that we created, with the modification that we made on the
+
+216
+00:11:09,260 --> 00:11:13,080
+branch. And so we want to merge that branch with our master branch.
+
+217
+00:11:13,080 --> 00:11:16,180
+To do that we can call the git merge command and
+
+218
+00:11:16,180 --> 00:11:19,260
+we'll specify the branch that we want to merge with the current
+
+219
+00:11:19,260 --> 00:11:23,030
+one. So we will specify testing in this case. That will merge
+
+220
+00:11:23,030 --> 00:11:26,260
+the testing branch with the current branch, which is the master. Which
+
+221
+00:11:26,260 --> 00:11:29,200
+means that now the testfile is in my current working directory,
+
+222
+00:11:29,200 --> 00:11:32,180
+is in my current, Current branch. And if I run the branch,
+
+223
+00:11:32,180 --> 00:11:35,590
+you'll see that the testing branch is obviously still there, so let's
+
+224
+00:11:35,590 --> 00:11:38,370
+assume that we want to delete the testing branch at this point
+
+225
+00:11:38,370 --> 00:11:41,220
+because we don't need it anymore. We could simply execute
+
+226
+00:11:41,220 --> 00:11:44,940
+the branch -d which stands for -delete, specify
+
+227
+00:11:44,940 --> 00:11:47,670
+the name of the branch and this will eliminate that
+
+228
+00:11:47,670 --> 00:11:51,670
+branch as confirmed by running the command git branch or the
+
+229
+00:11:51,670 --> 00:11:55,030
+testing branch no longer shows up. So, something that might
+
+230
+00:11:55,030 --> 00:11:57,200
+happen when you merge a branch is, is that you
+
+231
+00:11:57,200 --> 00:12:00,000
+might have conflicts For example, in case you change the,
+
+232
+00:12:00,000 --> 00:12:03,600
+the same file into different branches. So, let's see an example
+
+233
+00:12:03,600 --> 00:12:06,730
+of that. So, we're going to check which branches we have,
+
+234
+00:12:06,730 --> 00:12:09,260
+so we have two branches, in this case, master and newBranch
+
+235
+00:12:09,260 --> 00:12:14,040
+Our current branch is master. Let's open this file called new
+
+236
+00:12:14,040 --> 00:12:19,310
+file and, add some content there. So now let's commit
+
+237
+00:12:19,310 --> 00:12:21,890
+this changes to the get to the local repository. Now
+
+238
+00:12:21,890 --> 00:12:24,600
+let's switch to the other branch and if you remember we
+
+239
+00:12:24,600 --> 00:12:26,900
+do this by running git checkout and the name of the
+
+240
+00:12:26,900 --> 00:12:29,150
+branch. And at this point we do the same operation here.
+
+241
+00:12:29,150 --> 00:12:32,090
+So we take this file and we change it here to. In this
+
+242
+00:12:32,090 --> 00:12:34,740
+case we have content that reflects the fact that we are. In the
+
+243
+00:12:34,740 --> 00:12:38,790
+new branch just for convenience. At this point, we also can move the
+
+244
+00:12:38,790 --> 00:12:41,870
+file here. The comment here is, of course, that this is the new
+
+245
+00:12:41,870 --> 00:12:44,800
+file in the new branch. So, at this point, what we have here
+
+246
+00:12:44,800 --> 00:12:47,980
+is that we have this file called newfile that has been modified
+
+247
+00:12:47,980 --> 00:12:51,320
+independently both in the master branch and in the new branch. So we
+
+248
+00:12:51,320 --> 00:12:55,090
+have a conflict. Right? So, now, let's switch back to the master branch.
+
+249
+00:12:55,090 --> 00:12:57,720
+So now, let's say we want to merge the two branches. So
+
+250
+00:12:57,720 --> 00:13:00,490
+since we are in master, we want to say that when I
+
+251
+00:13:00,490 --> 00:13:03,970
+merge the new branch into the current one. And when we run
+
+252
+00:13:03,970 --> 00:13:07,540
+that, we get an auto merging conflict. So at this point what
+
+253
+00:13:07,540 --> 00:13:10,390
+we can do, is that we can manually fix the conflict by
+
+254
+00:13:10,390 --> 00:13:13,910
+opening the new file. So the file that was showing the conflict.
+
+255
+00:13:13,910 --> 00:13:16,860
+So here you can see the kind of of information that you get
+
+256
+00:13:16,860 --> 00:13:20,340
+in the conflicted file. So it's telling you basically that there is
+
+257
+00:13:20,340 --> 00:13:23,760
+in the head which is the, the master this conflict. Which is new
+
+258
+00:13:23,760 --> 00:13:26,830
+file in master. Which is the content that we added of course. And
+
+259
+00:13:26,830 --> 00:13:30,190
+then you know, under, you know, the separator you can see the content
+
+260
+00:13:30,190 --> 00:13:32,650
+that was added in the new branch. Which is the contents in new
+
+261
+00:13:32,650 --> 00:13:35,990
+file, in new branch. So basically, what this is showing you is the
+
+262
+00:13:35,990 --> 00:13:39,150
+parts of the file that are conflicting. In this case, we only have
+
+263
+00:13:39,150 --> 00:13:41,990
+one line, is basically the whole file into two versions and you can
+
+264
+00:13:41,990 --> 00:13:45,460
+decide which version you want to keep or how you want to merge in
+
+265
+00:13:45,460 --> 00:13:48,260
+general, the two pieces. So here, let's assume that we
+
+266
+00:13:48,260 --> 00:13:52,140
+want to keep the content from the master. So what we're
+
+267
+00:13:52,140 --> 00:13:54,510
+going to do is we're going to elimate the annotations
+
+268
+00:13:54,510 --> 00:13:57,500
+and we're going to eliminate the additional content. We save this
+
+269
+00:13:57,500 --> 00:13:59,680
+file. So at this point what we need to do
+
+270
+00:13:59,680 --> 00:14:04,040
+is simply to commit the modified file (the merge file) and we
+
+271
+00:14:04,040 --> 00:14:07,440
+do that in the normal way. We call git add, specifying
+
+272
+00:14:07,440 --> 00:14:11,180
+the file, so git add newfile. Then we run git commit
+
+273
+00:14:11,180 --> 00:14:15,630
+newfile, and we specify in the comment for clarity that this is the merged file,
+
+274
+00:14:15,630 --> 00:14:19,530
+so that we performed a merge. And at this point we are done with our merge.
diff --git a/usth/ICT2.7/P1L4 Version Control Subtitles/14 - GIT Demo: Git + Eclipse - lang_en_vs5.srt b/usth/ICT2.7/P1L4 Version Control Subtitles/14 - GIT Demo: Git + Eclipse - lang_en_vs5.srt
new file mode 100644
index 0000000..b95877b
--- /dev/null
+++ b/usth/ICT2.7/P1L4 Version Control Subtitles/14 - GIT Demo: Git + Eclipse - lang_en_vs5.srt	
@@ -0,0 +1,307 @@
+1
+00:00:00,140 --> 00:00:02,580
+Now that we saw some of the git basic
+
+2
+00:00:02,580 --> 00:00:05,689
+functionalities in practice, let's go a step further. If
+
+3
+00:00:05,689 --> 00:00:08,420
+you remember I mentioned before that many of these
+
+4
+00:00:08,420 --> 00:00:12,250
+version control systems are actually integrated into IDE's. So
+
+5
+00:00:12,250 --> 00:00:14,540
+what were going to look at next is what happens
+
+6
+00:00:14,540 --> 00:00:17,500
+if we put together git and eclipse. And the
+
+7
+00:00:17,500 --> 00:00:20,960
+result is egit, or EGit is a plug in
+
+8
+00:00:20,960 --> 00:00:25,520
+for the eclipse IDE that adds git functionality to eclipse.
+
+9
+00:00:25,520 --> 00:00:27,880
+So let's see how that works in practice. So
+
+10
+00:00:27,880 --> 00:00:31,400
+support for git is available in many IDE's including
+
+11
+00:00:31,400 --> 00:00:33,920
+Eclipse. And if you want to get github
+
+12
+00:00:33,920 --> 00:00:38,620
+for Eclipse, you should go to eclipse.github.com and you can
+
+13
+00:00:38,620 --> 00:00:41,445
+download the plugin. So this bring us to the
+
+14
+00:00:41,445 --> 00:00:44,530
+plugin page and you can use the provided URL
+
+15
+00:00:44,530 --> 00:00:47,060
+and directions to install the plugin. In this case
+
+16
+00:00:47,060 --> 00:00:49,945
+we're going to copy this address. So we're going to
+
+17
+00:00:49,945 --> 00:00:54,110
+Eclipse, Help, Install new software. We can click on Add
+
+18
+00:00:54,110 --> 00:00:56,810
+to add a new site from which to get software. We
+
+19
+00:00:56,810 --> 00:00:59,110
+paste the location that we just copied here. And we
+
+20
+00:00:59,110 --> 00:01:02,842
+can give it a descriptive name. In this case I'll just
+
+21
+00:01:02,842 --> 00:01:06,645
+call it Eclipse Git plugin. Then when I click okay,
+
+22
+00:01:06,645 --> 00:01:09,720
+Eclipse will go, and look for plugins. And as you can
+
+23
+00:01:09,720 --> 00:01:12,510
+see, there are two options. We can select both of them,
+
+24
+00:01:12,510 --> 00:01:15,180
+and click on next. You can see that the Eclipse identified
+
+25
+00:01:15,180 --> 00:01:18,330
+a few dependencies. You can click next and accept them. You can
+
+26
+00:01:18,330 --> 00:01:21,540
+accept the terms and conditions for the plug in, and then just
+
+27
+00:01:21,540 --> 00:01:25,730
+finish. And at this point, Eclipse will install the plugin, which might
+
+28
+00:01:25,730 --> 00:01:28,610
+take a little bit of time. So we're just going to speed it up.
+
+29
+00:01:28,610 --> 00:01:31,110
+And when Eclipse is done, you will get this prompt that will
+
+30
+00:01:31,110 --> 00:01:33,670
+tell you that you need to restart Eclipse for the plugin to
+
+31
+00:01:33,670 --> 00:01:36,990
+be actually installed. And at this point, you want to click yes. And
+
+32
+00:01:36,990 --> 00:01:40,550
+when Eclipse restarts. You'll have your plugin. We're going to go to the git
+
+33
+00:01:40,550 --> 00:01:44,030
+repository perspective that we can select here. And when we click
+
+34
+00:01:44,030 --> 00:01:47,160
+OK, you can see that our display will change. And since
+
+35
+00:01:47,160 --> 00:01:49,360
+we don't have any repository yet, we are provided with the
+
+36
+00:01:49,360 --> 00:01:53,620
+possibility of adding an existing local git repository, cloning a git repository
+
+37
+00:01:53,620 --> 00:01:56,330
+or creating a new local git repository. We're going to add an
+
+38
+00:01:56,330 --> 00:01:59,800
+existing local repository. This is the one that we created earlier,
+
+39
+00:01:59,800 --> 00:02:02,170
+so we'll select it and click finish, and you can see
+
+40
+00:02:02,170 --> 00:02:05,660
+that my project is now added to this set of git repositories.
+
+41
+00:02:05,660 --> 00:02:09,240
+Now let's check out the project from the repository by selecting import
+
+42
+00:02:09,240 --> 00:02:12,530
+project. And here you can import something as an existing project, you
+
+43
+00:02:12,530 --> 00:02:15,300
+can use a new project wizard, and in this case I chose
+
+44
+00:02:15,300 --> 00:02:18,680
+the option of importing as a general project. Then I click Next and
+
+45
+00:02:18,680 --> 00:02:20,870
+as you can see, I have the project name up there and
+
+46
+00:02:20,870 --> 00:02:24,630
+I can click Finish. So now, if I go to the resource perspective
+
+47
+00:02:24,630 --> 00:02:27,740
+by clicking here, I can see that the project has been added
+
+48
+00:02:27,740 --> 00:02:30,760
+to my set of projects. And I can see all the files within
+
+49
+00:02:30,760 --> 00:02:33,440
+the project, particularly, if I click on the README, you can see
+
+50
+00:02:33,440 --> 00:02:36,190
+that we have the Readme file that we created before. Same thing for
+
+51
+00:02:36,190 --> 00:02:38,930
+the test file. One thing I can do at this point, it
+
+52
+00:02:38,930 --> 00:02:41,070
+to execute different git commands, perform
+
+53
+00:02:41,070 --> 00:02:43,430
+different git operations by using the team
+
+54
+00:02:43,430 --> 00:02:47,010
+submenu in the contactual menu. And here there are several things
+
+55
+00:02:47,010 --> 00:02:50,650
+I can do including some advanced commands. And just to give it a
+
+56
+00:02:50,650 --> 00:02:53,200
+shot, I am going to try to click show local history, and this
+
+57
+00:02:53,200 --> 00:02:56,180
+shows the history of the file. For example it shows the author and
+
+58
+00:02:56,180 --> 00:02:59,200
+it shows when he was created, when he was authored. Lets make
+
+59
+00:02:59,200 --> 00:03:02,810
+some changes to this file by adding some new content. Okay. I saved
+
+60
+00:03:02,810 --> 00:03:05,160
+the file and now I can see that error that indicates that my
+
+61
+00:03:05,160 --> 00:03:08,620
+file was locally changed. So now if I go to the team menu,
+
+62
+00:03:08,620 --> 00:03:11,380
+you can see that I have the option to add to the index,
+
+63
+00:03:11,380 --> 00:03:14,686
+to stage the file. And now I got this new label that star
+
+64
+00:03:14,686 --> 00:03:17,980
+that shows the files added to the index. And now at this point,
+
+65
+00:03:17,980 --> 00:03:21,270
+I can go to the team menu again and I can actually commit
+
+66
+00:03:21,270 --> 00:03:25,480
+the file by selecting the corresponding entry. This allows me to enter
+
+67
+00:03:25,480 --> 00:03:28,390
+the commit message, exactly in the same way which I could do
+
+68
+00:03:28,390 --> 00:03:31,250
+that from the command line with the textual editor. And after I
+
+69
+00:03:31,250 --> 00:03:34,050
+put the comment there, I can actually commit. And now if we
+
+70
+00:03:34,050 --> 00:03:36,320
+look at the history view, we can see here that we have
+
+71
+00:03:36,320 --> 00:03:38,960
+a new version for the file that we just modified. And we
+
+72
+00:03:38,960 --> 00:03:42,250
+can also see the commit comment. And, at this point, if we
+
+73
+00:03:42,250 --> 00:03:46,450
+had remote repository we could push our changes to that remote repository
+
+74
+00:03:46,450 --> 00:03:49,330
+as well. Again, using the team submenu and
+
+75
+00:03:49,330 --> 00:03:52,170
+the contextual menu. And, speaking of remote repositories, what we
+
+76
+00:03:52,170 --> 00:03:55,230
+are going to see next is how to use GitHub
+
+77
+00:03:55,230 --> 00:03:58,640
+repositories which are remote repositories that are hosted on GitHub.
diff --git a/usth/ICT2.7/P1L4 Version Control Subtitles/15 - GIT Demo: Github - lang_en_vs3.srt b/usth/ICT2.7/P1L4 Version Control Subtitles/15 - GIT Demo: Github - lang_en_vs3.srt
new file mode 100644
index 0000000..5e842d7
--- /dev/null
+++ b/usth/ICT2.7/P1L4 Version Control Subtitles/15 - GIT Demo: Github - lang_en_vs3.srt	
@@ -0,0 +1,239 @@
+1
+00:00:00,120 --> 00:00:02,820
+In the interview that we did at the beginning of the class,
+
+2
+00:00:02,820 --> 00:00:08,430
+we talked with John about GitHub, where GitHub is a Git hosting website, and
+
+3
+00:00:08,430 --> 00:00:11,390
+John told you all about it. For this class, we will be
+
+4
+00:00:11,390 --> 00:00:16,350
+using GitHub as our Git hosting. Let's see how GitHub works in practice and
+
+5
+00:00:16,350 --> 00:00:19,450
+let's see some of the common features offered by GitHub.
+
+6
+00:00:19,450 --> 00:00:24,010
+This is what we'll do in the third part of this Git demo. What I'm showing here
+
+7
+00:00:24,010 --> 00:00:28,550
+is the GitHub website and as I said, GitHub is a Git hosting website and
+
+8
+00:00:28,550 --> 00:00:32,950
+you can create an account on GitHub by simply signing up on the website. And
+
+9
+00:00:32,950 --> 00:00:36,100
+because we already have an account that we're simply going to sign in
+
+10
+00:00:36,100 --> 00:00:40,570
+to see what kind of functionality GitHub offers. And we're going to specify our
+
+11
+00:00:40,570 --> 00:00:44,190
+username and password. And as you can see on the GitHub website,
+
+12
+00:00:44,190 --> 00:00:47,695
+you can use this menu up on the right to create a new repository or
+
+13
+00:00:47,695 --> 00:00:51,500
+change the account settings. Let's click on our user profile. And
+
+14
+00:00:51,500 --> 00:00:54,270
+here we can see some statistics for our user. For
+
+15
+00:00:54,270 --> 00:00:59,190
+example, we can see statistic about our contributions and our repositories. So
+
+16
+00:00:59,190 --> 00:01:02,560
+now if we go to the Repositories view, we can create a new repository.
+
+17
+00:01:02,560 --> 00:01:07,117
+We give it a name. Let's call it myrepo. We can provide the description for
+
+18
+00:01:07,117 --> 00:01:11,680
+the repository. If we want, we can initialize the repository by adding a README
+
+19
+00:01:11,680 --> 00:01:15,860
+file. And even though we are not doing it right now, if you can see up here,
+
+20
+00:01:15,860 --> 00:01:19,820
+you can also add a license here on the right and it allows you
+
+21
+00:01:19,820 --> 00:01:24,831
+to choose from a set of predefined licenses. And you can also a .gitignore file,
+
+22
+00:01:24,831 --> 00:01:28,410
+which, in case you don't know what that is, it's a very convenient file that
+
+23
+00:01:28,410 --> 00:01:32,740
+will automatically exclude from the repositories file that should not be added.
+
+24
+00:01:32,740 --> 00:01:35,690
+So if you remember in the lesson we said there are things that you should not
+
+25
+00:01:35,690 --> 00:01:39,263
+add to the repositories. For example, derived files. So
+
+26
+00:01:39,263 --> 00:01:42,360
+here, using this menu, you can pick the type of project that you have.
+
+27
+00:01:42,360 --> 00:01:47,740
+For example, Java project or PHP project or many other kinds of projects. And
+
+28
+00:01:47,740 --> 00:01:50,510
+the GitHub will automatically add that file for you.
+
+29
+00:01:50,510 --> 00:01:53,680
+But let's skip that for now and simply create our repository. And
+
+30
+00:01:53,680 --> 00:01:58,000
+that creates a repository that contains the README file because that's what we
+
+31
+00:01:58,000 --> 00:02:02,580
+decided to do. And it also allows you to edit the README file by clicking on it.
+
+32
+00:02:02,580 --> 00:02:05,560
+It will bring up an editor and here you can write, you know,
+
+33
+00:02:05,560 --> 00:02:08,949
+for example, initial readme for your project. Then you can add your
+
+34
+00:02:08,949 --> 00:02:13,070
+commit message up there and then you can commit the changes to your README file.
+
+35
+00:02:13,070 --> 00:02:18,212
+The site also provides many other features, like, for example, creating issues,
+
+36
+00:02:18,212 --> 00:02:22,030
+pull requests, adding and editing a wiki, and also, you know,
+
+37
+00:02:22,030 --> 00:02:25,740
+defining other characteristics and settings for the repository. Now, if we go to
+
+38
+00:02:25,740 --> 00:02:30,500
+the repository, you can see that we also get the HTTPS link for the repository.
+
+39
+00:02:30,500 --> 00:02:35,870
+So this is the URL that you can use to clone your repository. If you remember,
+
+40
+00:02:35,870 --> 00:02:39,250
+with a git clone command, that's the URL that you can specify. So
+
+41
+00:02:39,250 --> 00:02:43,480
+let's try to do that and clone that repository. So we're going to copy this URL.
+
+42
+00:02:43,480 --> 00:02:48,300
+To do that, we're going to execute git clone and specify the URL that we
+
+43
+00:02:48,300 --> 00:02:52,310
+just copied. And you can see that the project was created, was cloned locally.
+
+44
+00:02:52,310 --> 00:02:55,760
+And if we go under myrepo, which is the name of the repository, you can see that
+
+45
+00:02:55,760 --> 00:02:59,570
+the README file that we created on GitHub is here. So if we create a new file,
+
+46
+00:02:59,570 --> 00:03:03,340
+which we're going to call again, newFile just to be clear. And then we
+
+47
+00:03:03,340 --> 00:03:07,920
+can add it, commit it, specifying as usual a commit message. So at this point,
+
+48
+00:03:07,920 --> 00:03:11,940
+we can push our locked out changes to the remote GitHub repository. And
+
+49
+00:03:11,940 --> 00:03:14,340
+because the GitHub repository is password protected,
+
+50
+00:03:14,340 --> 00:03:17,660
+we have to specify our login and password. And of course, if you
+
+51
+00:03:17,660 --> 00:03:21,770
+pass the wrong password, GitHub is not going to let you in. So let's try again.
+
+52
+00:03:21,770 --> 00:03:25,110
+Let's try to get the password right this time. I'm going to specify again,
+
+53
+00:03:25,110 --> 00:03:31,130
+my login and my password. At this point, the push is successful and
+
+54
+00:03:31,130 --> 00:03:35,220
+my changes are actually pushed to the master, which is the GitHub repository.
+
+55
+00:03:35,220 --> 00:03:39,020
+To double check that, let's go back to the GitHub repository and as you can see,
+
+56
+00:03:39,020 --> 00:03:42,470
+that the file that we added, newFile, is there as expected. And of course,
+
+57
+00:03:42,470 --> 00:03:45,880
+there's many more things that you can do on the GitHub website, so
+
+58
+00:03:45,880 --> 00:03:48,410
+I strongly encourage you to go and try out things. But
+
+59
+00:03:48,410 --> 00:03:51,980
+the key message here is that the GitHub is a Git hosting website where you
+
+60
+00:03:51,980 --> 00:03:54,990
+can get an account and create your remote repositories.
diff --git a/usth/ICT2.7/P1L4 Version Control Subtitles/16 - GIT Recap - lang_en_vs5.srt b/usth/ICT2.7/P1L4 Version Control Subtitles/16 - GIT Recap - lang_en_vs5.srt
new file mode 100644
index 0000000..b35fc59
--- /dev/null
+++ b/usth/ICT2.7/P1L4 Version Control Subtitles/16 - GIT Recap - lang_en_vs5.srt	
@@ -0,0 +1,35 @@
+1
+00:00:00,110 --> 00:00:02,212
+Now that we are done with our demo, I just want
+
+2
+00:00:02,212 --> 00:00:05,910
+to go through a quick GIT recap to remind you of the
+
+3
+00:00:05,910 --> 00:00:08,720
+main commands that we saw, and what they do. And you can
+
+4
+00:00:08,720 --> 00:00:11,290
+also use these as sort of a reference when you work with
+
+5
+00:00:11,290 --> 00:00:13,940
+GIT. And by the way, if you look around and you do
+
+6
+00:00:13,940 --> 00:00:16,960
+a search, you can see that there's tons of examples on the
+
+7
+00:00:16,960 --> 00:00:22,170
+web of GitHub tutorials, videos, examples, manuals. So feel free to
+
+8
+00:00:22,170 --> 00:00:25,910
+explore. And I'm actually going to put some references to tutorials and
+
+9
+00:00:25,910 --> 00:00:29,100
+videos that I found particularly useful in the notes for the class.
diff --git a/usth/ICT2.7/P1L4 Version Control Subtitles/17 - GIT Recap: Local Repositories - lang_en_vs5.srt b/usth/ICT2.7/P1L4 Version Control Subtitles/17 - GIT Recap: Local Repositories - lang_en_vs5.srt
new file mode 100644
index 0000000..c29fae8
--- /dev/null
+++ b/usth/ICT2.7/P1L4 Version Control Subtitles/17 - GIT Recap: Local Repositories - lang_en_vs5.srt	
@@ -0,0 +1,163 @@
+1
+00:00:00,100 --> 00:00:02,460
+So, let me start by recapping some of the operations that
+
+2
+00:00:02,460 --> 00:00:06,000
+we can perform on local repositories. I'm just going to list them
+
+3
+00:00:06,000 --> 00:00:09,240
+here and go through them by separating them into three main
+
+4
+00:00:09,240 --> 00:00:12,930
+categories. The first one is commands that, to create a repository and
+
+5
+00:00:12,930 --> 00:00:15,470
+notice that not all of these are git commands, that for
+
+6
+00:00:15,470 --> 00:00:18,710
+example, to create the repository, we would normally want to. Create a
+
+7
+00:00:18,710 --> 00:00:21,560
+directory, which is exactly what we did in our demo. We want
+
+8
+00:00:21,560 --> 00:00:25,310
+to go to that directory and then execute the git init statement,
+
+9
+00:00:25,310 --> 00:00:29,110
+which initializes that directory as a git repository. The second
+
+10
+00:00:29,110 --> 00:00:32,530
+category includes commands that we'll use to modify the content of
+
+11
+00:00:32,530 --> 00:00:35,280
+the repository. We saw that we can use git add
+
+12
+00:00:35,280 --> 00:00:39,190
+to add a specific file or a complete directory to our
+
+13
+00:00:39,190 --> 00:00:41,650
+index. So to the list of files that will be
+
+14
+00:00:41,650 --> 00:00:44,510
+committed, that will be considered in the next commit. Then we
+
+15
+00:00:44,510 --> 00:00:47,620
+can use commit to actually commit the changes that we
+
+16
+00:00:47,620 --> 00:00:50,374
+made to those files to our local repository, and we can
+
+17
+00:00:50,374 --> 00:00:54,030
+also use git move and git rm or git remove
+
+18
+00:00:54,030 --> 00:00:57,420
+to move files around and to remove files. Finally, the
+
+19
+00:00:57,420 --> 00:01:00,270
+third category is the category of commands that we can
+
+20
+00:01:00,270 --> 00:01:04,950
+use to inspect the concrete repository. And this set includes git
+
+21
+00:01:04,950 --> 00:01:06,960
+log, that we can use to see the log of
+
+22
+00:01:06,960 --> 00:01:09,970
+the repository, git status, that can give us important information
+
+23
+00:01:09,970 --> 00:01:12,810
+about the status of the file center repository. Git diff,
+
+24
+00:01:12,810 --> 00:01:15,500
+that we can use to see the differences between for example,
+
+25
+00:01:15,500 --> 00:01:19,160
+our local files. And the remote files. And finally git
+
+26
+00:01:19,160 --> 00:01:23,270
+show, that will show us information about our last commit. What
+
+27
+00:01:23,270 --> 00:01:25,940
+we committed, what were the changes and so on. And again,
+
+28
+00:01:25,940 --> 00:01:29,290
+we saw most or all of these commands in our demo.
+
+29
+00:01:29,290 --> 00:01:31,920
+So let me also remind you of a possible workflow. Which
+
+30
+00:01:31,920 --> 00:01:34,350
+again, we already saw but it's always good to go through
+
+31
+00:01:34,350 --> 00:01:37,670
+it once more. And remember that this is just an example.
+
+32
+00:01:37,670 --> 00:01:40,520
+It's just a possible workflow. You can do many different things,
+
+33
+00:01:40,520 --> 00:01:43,210
+you can have many different workflows with git. This is just
+
+34
+00:01:43,210 --> 00:01:45,980
+up to illustrate some of the things that you can do. So,
+
+35
+00:01:45,980 --> 00:01:49,430
+you might do some local editing. Execute git status to see what
+
+36
+00:01:49,430 --> 00:01:53,020
+files you changed. Then you might run a git diff on the
+
+37
+00:01:53,020 --> 00:01:56,230
+files to see what are these changes. And then you can run
+
+38
+00:01:56,230 --> 00:01:59,460
+git commit -a to commit your changes. And in case you
+
+39
+00:01:59,460 --> 00:02:02,520
+want to specify the commit message right away without having to go
+
+40
+00:02:02,520 --> 00:02:06,040
+through an editor, you can also add the -m parameter and
+
+41
+00:02:06,040 --> 00:02:08,110
+specify the message here on the same line.
diff --git a/usth/ICT2.7/P1L4 Version Control Subtitles/18 - GIT Recap: Remote Repositories - lang_en_vs3.srt b/usth/ICT2.7/P1L4 Version Control Subtitles/18 - GIT Recap: Remote Repositories - lang_en_vs3.srt
new file mode 100644
index 0000000..9afccc9
--- /dev/null
+++ b/usth/ICT2.7/P1L4 Version Control Subtitles/18 - GIT Recap: Remote Repositories - lang_en_vs3.srt	
@@ -0,0 +1,59 @@
+1
+00:00:00,110 --> 00:00:02,960
+SImilarly, let's go through some commands that you can run on
+
+2
+00:00:02,960 --> 00:00:07,150
+remote repositories. First command is the command to copy a repository,
+
+3
+00:00:07,150 --> 00:00:10,840
+which is git clone in which you get a remote repository and you make a lot of
+
+4
+00:00:10,840 --> 00:00:14,850
+copy in your working directory. The repository can be specified as a URL.
+
+5
+00:00:14,850 --> 00:00:18,230
+It can be a local file, it can be specified using the HTTP or
+
+6
+00:00:18,230 --> 00:00:21,070
+the SSH protocol, and there's also other ways to do it.
+
+7
+00:00:21,070 --> 00:00:25,300
+This creates a complete local copy of the repository, as it says, and links it
+
+8
+00:00:25,300 --> 00:00:29,030
+to the remote repository, which is what is called the origin. And if you want,
+
+9
+00:00:29,030 --> 00:00:33,400
+you could also actually link to the repository, later. Then the normal way of
+
+10
+00:00:33,400 --> 00:00:37,800
+receiving changes from a repository is to perform a git pull command. And we saw
+
+11
+00:00:37,800 --> 00:00:42,345
+that you can also perform the same operation through two commands, get fetch and
+
+12
+00:00:42,345 --> 00:00:47,210
+git merge. In case you want to inspect the changes before actually merging them,
+
+13
+00:00:47,210 --> 00:00:49,550
+before actually getting them in your local copy. And
+
+14
+00:00:49,550 --> 00:00:52,940
+if you want to send changes that you have in your local repository to
+
+15
+00:00:52,940 --> 00:00:55,680
+a remote repository, you will use the git push command.
diff --git a/usth/ICT2.7/P1L4 Version Control Subtitles/19 - GitHub Setup Assignment - lang_en_vs2.srt b/usth/ICT2.7/P1L4 Version Control Subtitles/19 - GitHub Setup Assignment - lang_en_vs2.srt
new file mode 100644
index 0000000..9dec29b
--- /dev/null
+++ b/usth/ICT2.7/P1L4 Version Control Subtitles/19 - GitHub Setup Assignment - lang_en_vs2.srt	
@@ -0,0 +1,15 @@
+1
+00:00:00,160 --> 00:00:03,095
+This is ultimately pretty simple. All you need to do is visit
+
+2
+00:00:03,095 --> 00:00:08,720
+github.com/join and set up a free GitHub account. If you already have a GitHub,
+
+3
+00:00:08,720 --> 00:00:11,870
+account you can sign in using your existing account. If you want to
+
+4
+00:00:11,870 --> 00:00:14,550
+use a separate identity for the class, feel free to set up a second one.
diff --git a/usth/ICT2.7/P1L4 Version Control Subtitles/19 - GitHub Setup Assignment - lang_pt_vs1.srt b/usth/ICT2.7/P1L4 Version Control Subtitles/19 - GitHub Setup Assignment - lang_pt_vs1.srt
new file mode 100644
index 0000000..6dc6f48
--- /dev/null
+++ b/usth/ICT2.7/P1L4 Version Control Subtitles/19 - GitHub Setup Assignment - lang_pt_vs1.srt	
@@ -0,0 +1,19 @@
+1
+00:00:00,160 --> 00:00:03,095
+Na verdade é muito simples. 
+Só tens que ir a
+
+2
+00:00:03,095 --> 00:00:08,720
+github.com/join e criar uma conta grátis
+no GitHub. Se já tiveres uma conta GitHub,
+
+3
+00:00:08,720 --> 00:00:11,870
+podes entrar com a tua conta.
+Se quiseres
+
+4
+00:00:11,870 --> 00:00:14,550
+criar uma diferente para o curso,
+podes criar uma segunda sem problemas.
diff --git a/usth/ICT2.7/P1L4 Version Control Subtitles/2 - Interview with John Britton - lang_en_vs5.srt b/usth/ICT2.7/P1L4 Version Control Subtitles/2 - Interview with John Britton - lang_en_vs5.srt
new file mode 100644
index 0000000..999833f
--- /dev/null
+++ b/usth/ICT2.7/P1L4 Version Control Subtitles/2 - Interview with John Britton - lang_en_vs5.srt	
@@ -0,0 +1,435 @@
+1
+00:00:00,170 --> 00:00:02,630
+&gt;&gt; And I thought that the best way to break the ice on version
+
+2
+00:00:02,630 --> 00:00:04,970
+control systems and Git and some other
+
+3
+00:00:04,970 --> 00:00:07,939
+related concepts was to interview John Britton who
+
+4
+00:00:07,939 --> 00:00:11,840
+works with GitHub. So let's go and see what John has to say about
+
+5
+00:00:11,840 --> 00:00:14,120
+Git, about version control systems in general,
+
+6
+00:00:14,120 --> 00:00:17,809
+and about GitHub. John is in Tapei, if I'm not wrong.
+
+7
+00:00:17,809 --> 00:00:18,610
+&gt;&gt; That's correct.
+
+8
+00:00:18,610 --> 00:00:20,320
+&gt;&gt; Okay so we're, you know we couldn't
+
+9
+00:00:20,320 --> 00:00:22,570
+go there so we're interviewing him remotely. And I
+
+10
+00:00:22,570 --> 00:00:25,490
+want, I just want to thank you so much and John for agreeing to talk to us.
+
+11
+00:00:25,490 --> 00:00:27,940
+&gt;&gt; Thank you very much for having me it was my pleasure.
+
+12
+00:00:27,940 --> 00:00:30,560
+&gt;&gt; And, I'm just going to ask, a few
+
+13
+00:00:30,560 --> 00:00:32,938
+general questions because John is an expert on,
+
+14
+00:00:32,938 --> 00:00:36,270
+Git and GitHub. John is a developer and
+
+15
+00:00:36,270 --> 00:00:38,550
+a community builder is active in both the
+
+16
+00:00:38,550 --> 00:00:42,200
+open source and the open education areas. And
+
+17
+00:00:42,200 --> 00:00:44,860
+as an educational liaison we have, is working
+
+18
+00:00:44,860 --> 00:00:47,580
+to improve Computer Science education by bringing the
+
+19
+00:00:47,580 --> 00:00:51,460
+principles of open source into the classroom. And
+
+20
+00:00:51,460 --> 00:00:53,160
+I'm going to start with an general question,
+
+21
+00:00:53,160 --> 00:00:55,320
+which is what is a version control system?
+
+22
+00:00:55,320 --> 00:00:57,960
+&gt;&gt; So, a version control system is
+
+23
+00:00:57,960 --> 00:01:00,360
+a tool that software developers use. Anybody
+
+24
+00:01:00,360 --> 00:01:02,560
+who's doing you know, working with digital
+
+25
+00:01:02,560 --> 00:01:06,540
+assets, digital projects can also use for
+
+26
+00:01:06,540 --> 00:01:11,320
+keeping track of, you know, revisions of your project, and when I say revisions, I
+
+27
+00:01:11,320 --> 00:01:16,850
+mean essentially snapshots of your project over time. So you can imagine doing
+
+28
+00:01:16,850 --> 00:01:19,720
+some work and then every so often, be it, every couple of
+
+29
+00:01:19,720 --> 00:01:23,799
+hours, every couple of days, saving a permanent snapshot of your project.
+
+30
+00:01:24,880 --> 00:01:26,650
+&gt;&gt; Why is this useful? I understand that
+
+31
+00:01:26,650 --> 00:01:28,720
+it is nice to take a snapshot of your
+
+32
+00:01:28,720 --> 00:01:30,070
+project, but what did you do with the
+
+33
+00:01:30,070 --> 00:01:33,420
+snapshot afterwards? I think the most immediately obvious benefit
+
+34
+00:01:33,420 --> 00:01:36,340
+to having snapshots of your project to keeping
+
+35
+00:01:36,340 --> 00:01:38,280
+revisions is that you can go back. If you
+
+36
+00:01:38,280 --> 00:01:40,190
+have ever worked on a project and got to
+
+37
+00:01:40,190 --> 00:01:41,940
+a point where you solved a bunch of your
+
+38
+00:01:41,940 --> 00:01:45,330
+problems, and there is just one more step to do. And
+
+39
+00:01:45,330 --> 00:01:47,640
+you start working on trying to solve that last step, and
+
+40
+00:01:47,640 --> 00:01:51,350
+you break things, you make it worse then it was an
+
+41
+00:01:51,350 --> 00:01:54,420
+hour ago. At that point its easier to just go back
+
+42
+00:01:54,420 --> 00:01:56,780
+to what you had then trying to figure out what you
+
+43
+00:01:56,780 --> 00:01:59,320
+broke. So you can always go back in time, and the
+
+44
+00:01:59,320 --> 00:02:02,660
+other big one is being able to collaborate with multiple people,
+
+45
+00:02:02,660 --> 00:02:07,450
+so its pretty seldom these days that you. Work on a production
+
+46
+00:02:07,450 --> 00:02:09,860
+totally on your own. It's most common to work in, you
+
+47
+00:02:09,860 --> 00:02:12,993
+know, in teams and small groups. And so, using a revision
+
+48
+00:02:12,993 --> 00:02:16,340
+control system allows you to collaborate with other people. And make
+
+49
+00:02:16,340 --> 00:02:19,060
+sure that you don't step on each other's toes as you're working.
+
+50
+00:02:19,060 --> 00:02:21,310
+&gt;&gt; Alright, that's great, because those are exactly some of the
+
+51
+00:02:21,310 --> 00:02:25,250
+topics that we're going to cover in the lesson. And so since we're
+
+52
+00:02:25,250 --> 00:02:28,470
+going to talk about the specifics of version control system which is
+
+53
+00:02:28,470 --> 00:02:32,660
+Git and you're definitely an expert in, in Git. So what would
+
+54
+00:02:32,660 --> 00:02:36,510
+you say is specifically special about Git? What characterizes it
+
+55
+00:02:36,510 --> 00:02:39,940
+and how does it compare to other version control systems.
+
+56
+00:02:39,940 --> 00:02:43,140
+&gt;&gt; So if any of you have used version control systems before, you
+
+57
+00:02:43,140 --> 00:02:47,850
+may have heard of something like subversion, CVS, or maybe a commercial solution
+
+58
+00:02:47,850 --> 00:02:53,550
+like ProForce. I think the main important characteristics of Git are first that
+
+59
+00:02:53,550 --> 00:02:56,050
+it's open source. And the second,
+
+60
+00:02:56,050 --> 00:02:59,030
+that it's a distributed version control system.
+
+61
+00:02:59,030 --> 00:03:00,430
+So what that means, the distributed version
+
+62
+00:03:00,430 --> 00:03:04,260
+control system is essentially a system for tracking
+
+63
+00:03:04,260 --> 00:03:07,700
+revisions of your software that doesn't have any
+
+64
+00:03:07,700 --> 00:03:11,730
+central repository. So the biggest characteristic is that
+
+65
+00:03:11,730 --> 00:03:14,520
+I can do my work and you can also work on the same project at
+
+66
+00:03:14,520 --> 00:03:16,900
+the same time without communicating with each other
+
+67
+00:03:16,900 --> 00:03:19,650
+and without communicating to a central system.
+
+68
+00:03:19,650 --> 00:03:24,190
+&gt;&gt; Okay, great. And so now that we saw what Git is, what is
+
+69
+00:03:24,190 --> 00:03:26,050
+GitHub and how does it fit into
+
+70
+00:03:26,050 --> 00:03:29,320
+this picture of the distributed, revision control system?
+
+71
+00:03:29,320 --> 00:03:34,800
+&gt;&gt; So GitHub is, the world's largest code host, and we essentially have a
+
+72
+00:03:34,800 --> 00:03:36,940
+website where you can collaborate with people
+
+73
+00:03:36,940 --> 00:03:39,950
+when you're writing code. There's two ways you
+
+74
+00:03:39,950 --> 00:03:43,650
+can use GitHub. You can use it publicly for open source and you can use
+
+75
+00:03:43,650 --> 00:03:49,660
+it in private within your team, or your company, or within your class. And, Git
+
+76
+00:03:49,660 --> 00:03:53,960
+Hub started out just as a way to host your Git repositories. But it's
+
+77
+00:03:53,960 --> 00:03:56,000
+actually grown into quite a bit more. It's
+
+78
+00:03:56,000 --> 00:03:59,820
+an entire collaboration system around your code.
+
+79
+00:03:59,820 --> 00:04:00,580
+&gt;&gt; How many users do you have?
+
+80
+00:04:00,580 --> 00:04:03,620
+&gt;&gt; I would say that we're approaching five million.
+
+81
+00:04:03,620 --> 00:04:05,570
+I don't know the exact number. We're definitely more
+
+82
+00:04:05,570 --> 00:04:08,080
+than four million right now. But yeah, I'd say
+
+83
+00:04:08,080 --> 00:04:10,330
+somewhere, somewhere close to between four and five million.
+
+84
+00:04:10,330 --> 00:04:14,750
+&gt;&gt; So that's a lot space I'd guess. Terabytes of disk
+
+85
+00:04:14,750 --> 00:04:15,840
+space, I would imagine.
+
+86
+00:04:15,840 --> 00:04:19,170
+&gt;&gt; There are a lot of GIT repositories on, on our servers.
+
+87
+00:04:19,170 --> 00:04:21,180
+&gt;&gt; Something else you want to say? I
+
+88
+00:04:21,180 --> 00:04:23,920
+guess that the when taking about GitHub there's one
+
+89
+00:04:23,920 --> 00:04:26,110
+thing that you kind of can't leave out and
+
+90
+00:04:26,110 --> 00:04:28,670
+that's that's a feature that's called a pull request.
+
+91
+00:04:28,670 --> 00:04:31,090
+So when you're using GitHub, you can share
+
+92
+00:04:31,090 --> 00:04:34,940
+your Git repository, do some work, and actually do
+
+93
+00:04:34,940 --> 00:04:37,880
+do a code review. Of proposed changes which
+
+94
+00:04:37,880 --> 00:04:39,770
+is what we call a pull request on github.com.
+
+95
+00:04:39,770 --> 00:04:42,790
+Essentially what it lets you do is have a discussion
+
+96
+00:04:42,790 --> 00:04:46,320
+about a set of proposed changes and leave feedback in
+
+97
+00:04:46,320 --> 00:04:48,870
+line with the code. You could say for example, this
+
+98
+00:04:48,870 --> 00:04:51,670
+method needs to be re-factored or I think I found if
+
+99
+00:04:51,670 --> 00:04:54,830
+off by one error here, just different kinds of feedback
+
+100
+00:04:54,830 --> 00:04:59,120
+so that before you totally integrate some proposed changes. You have,
+
+101
+00:04:59,120 --> 00:05:01,180
+kind of a conversation about what your code. And I
+
+102
+00:05:01,180 --> 00:05:03,050
+think that's really valuable when you are working in a team.
+
+103
+00:05:03,050 --> 00:05:05,510
+&gt;&gt; Thank you, John, that was very informative and
+
+104
+00:05:05,510 --> 00:05:07,440
+thanks again for taking the time to talk to us.
+
+105
+00:05:07,440 --> 00:05:10,160
+&gt;&gt; No problem, thanks for having me. I'll talk to you soon.
+
+106
+00:05:10,160 --> 00:05:13,990
+&gt;&gt; Let's thank again John for enlightening us
+
+107
+00:05:13,990 --> 00:05:17,350
+on some aspects of version control systems, Git and
+
+108
+00:05:17,350 --> 00:05:19,410
+GitHub. And now, let's go over some of the
+
+109
+00:05:19,410 --> 00:05:21,650
+topics that we discussed with John to recap them.
diff --git a/usth/ICT2.7/P1L4 Version Control Subtitles/3 - Version Control System Introduction - lang_en_vs5.srt b/usth/ICT2.7/P1L4 Version Control Subtitles/3 - Version Control System Introduction - lang_en_vs5.srt
new file mode 100644
index 0000000..be0515b
--- /dev/null
+++ b/usth/ICT2.7/P1L4 Version Control Subtitles/3 - Version Control System Introduction - lang_en_vs5.srt	
@@ -0,0 +1,207 @@
+1
+00:00:00,160 --> 00:00:02,080
+So first of all, what is a version
+
+2
+00:00:02,080 --> 00:00:05,550
+control system? A version control system or VCS,
+
+3
+00:00:05,550 --> 00:00:07,670
+is a system that allows you to manage
+
+4
+00:00:07,670 --> 00:00:11,180
+multiple revisions of the same unit of information. For
+
+5
+00:00:11,180 --> 00:00:14,330
+example of documents, of source files or any
+
+6
+00:00:14,330 --> 00:00:17,380
+other item of that sort. And as the graphical
+
+7
+00:00:17,380 --> 00:00:21,240
+depiction shows, a VCS allows a multiple actors.
+
+8
+00:00:21,240 --> 00:00:25,020
+Here we have four, to cooperate and share files.
+
+9
+00:00:25,020 --> 00:00:26,980
+Now, let's drill into this concept in a little
+
+10
+00:00:26,980 --> 00:00:29,720
+more detail. And let's do that by discussing why
+
+11
+00:00:29,720 --> 00:00:32,870
+is VCS useful, especially in the context of software
+
+12
+00:00:32,870 --> 00:00:35,790
+engineering and of software development. So first of all,
+
+13
+00:00:35,790 --> 00:00:39,570
+using a version control system enforces discipline, because it
+
+14
+00:00:39,570 --> 00:00:43,030
+manages the process by which the control of items
+
+15
+00:00:43,030 --> 00:00:46,720
+passes from one person to another. Another important aspect
+
+16
+00:00:46,720 --> 00:00:51,170
+of VCS is that it allows you for archiving versions.
+
+17
+00:00:51,170 --> 00:00:54,330
+So you can store subsequent versions of source controlled
+
+18
+00:00:54,330 --> 00:00:57,450
+items into a VCS. And not only you can
+
+19
+00:00:57,450 --> 00:01:00,450
+store versions, you can also maintain a lot of
+
+20
+00:01:00,450 --> 00:01:03,480
+interesting and important historical information
+
+21
+00:01:03,480 --> 00:01:05,810
+about these versions. For example,
+
+22
+00:01:05,810 --> 00:01:08,070
+a VCL will store information such as, who is
+
+23
+00:01:08,070 --> 00:01:11,270
+the author for this specific version stored in the system.
+
+24
+00:01:11,270 --> 00:01:13,820
+Or, for another example, on what day and what
+
+25
+00:01:13,820 --> 00:01:16,260
+time that version was stored. And a lot of other
+
+26
+00:01:16,260 --> 00:01:19,240
+interesting information about the specific version of the
+
+27
+00:01:19,240 --> 00:01:21,600
+item. Information that you can then retrieve and for
+
+28
+00:01:21,600 --> 00:01:25,040
+example, use to compare versions. Obviously, the fact of
+
+29
+00:01:25,040 --> 00:01:27,970
+having a central repository in which all these items
+
+30
+00:01:27,970 --> 00:01:31,350
+are stored enables collaboration, so people can more easily
+
+31
+00:01:31,350 --> 00:01:35,510
+share data, share files, share documents through the use
+
+32
+00:01:35,510 --> 00:01:37,950
+of VCS. And I'm sure that you all had
+
+33
+00:01:37,950 --> 00:01:41,320
+the experience of deleting a file by mistake or
+
+34
+00:01:41,320 --> 00:01:43,860
+modifying a file in the wrong way, or in the
+
+35
+00:01:43,860 --> 00:01:47,830
+most common case of changing something in your code for instance.
+
+36
+00:01:47,830 --> 00:01:50,490
+And breaking something and not being able to go back
+
+37
+00:01:50,490 --> 00:01:53,630
+to a version that was working. Not remembering, for example, what
+
+38
+00:01:53,630 --> 00:01:56,130
+is that you changed that broke the code. In all
+
+39
+00:01:56,130 --> 00:01:59,850
+these cases a version control system can be extremely useful because
+
+40
+00:01:59,850 --> 00:02:03,330
+it will allow you to recover from this accidental deletions
+
+41
+00:02:03,330 --> 00:02:06,690
+or edits. And for example, to go back of yesterdays version
+
+42
+00:02:06,690 --> 00:02:09,949
+that was working perfectly, and also to compare, for example, yesterdays
+
+43
+00:02:09,949 --> 00:02:12,920
+version with today version and see what is that you changed.
+
+44
+00:02:12,920 --> 00:02:16,000
+Finally, a version control system will normally also allow you to
+
+45
+00:02:16,000 --> 00:02:20,460
+conserve and save disk space on both the source control client
+
+46
+00:02:20,460 --> 00:02:23,880
+and on the server. Why? Well, for instance because it's centralizing
+
+47
+00:02:23,880 --> 00:02:26,570
+the management of the version. So instead of having many copies
+
+48
+00:02:26,570 --> 00:02:29,480
+spread around, you'll have only one central point where these copies
+
+49
+00:02:29,480 --> 00:02:32,240
+are stored or a few points where these copies are stored.
+
+50
+00:02:32,240 --> 00:02:34,330
+In addition, version control system often
+
+51
+00:02:34,330 --> 00:02:37,470
+uses efficient algorithms to store these changes.
+
+52
+00:02:37,470 --> 00:02:41,310
+And therefore, you can keep many versions without taking up too much space.
diff --git a/usth/ICT2.7/P1L4 Version Control Subtitles/4 - VCS Quiz - lang_en_vs4.srt b/usth/ICT2.7/P1L4 Version Control Subtitles/4 - VCS Quiz - lang_en_vs4.srt
new file mode 100644
index 0000000..26d9c55
--- /dev/null
+++ b/usth/ICT2.7/P1L4 Version Control Subtitles/4 - VCS Quiz - lang_en_vs4.srt	
@@ -0,0 +1,31 @@
+1
+00:00:00,100 --> 00:00:02,430
+Now before we continue, and we look at more details
+
+2
+00:00:02,430 --> 00:00:04,400
+of version control systems, I want to ask you a
+
+3
+00:00:04,400 --> 00:00:07,230
+quick question about VCS. I want to know whether you
+
+4
+00:00:07,230 --> 00:00:10,190
+have used a version control system before, and if so,
+
+5
+00:00:10,190 --> 00:00:12,090
+which one or which ones. I'm going to list in
+
+6
+00:00:12,090 --> 00:00:15,260
+here some of the most commonly used version control systems,
+
+7
+00:00:15,260 --> 00:00:18,840
+like CVS, Subversion, GIT, and I'm also allowing you to
+
+8
+00:00:18,840 --> 00:00:22,640
+specify other VCS in case you have used different ones.
diff --git a/usth/ICT2.7/P1L4 Version Control Subtitles/5 - VCS Quiz Solution - lang_en_vs7.srt b/usth/ICT2.7/P1L4 Version Control Subtitles/5 - VCS Quiz Solution - lang_en_vs7.srt
new file mode 100644
index 0000000..1a380a5
--- /dev/null
+++ b/usth/ICT2.7/P1L4 Version Control Subtitles/5 - VCS Quiz Solution - lang_en_vs7.srt	
@@ -0,0 +1,11 @@
+1
+00:00:00,130 --> 00:00:03,030
+And of course there's no right answer for this. I just wanted to collect some
+
+2
+00:00:03,030 --> 00:00:05,020
+statistics. To see what kind of previous
+
+3
+00:00:05,020 --> 00:00:07,100
+experience you have with this kind of systems.
diff --git a/usth/ICT2.7/P1L4 Version Control Subtitles/6 - Essential Actions - lang_en_vs5.srt b/usth/ICT2.7/P1L4 Version Control Subtitles/6 - Essential Actions - lang_en_vs5.srt
new file mode 100644
index 0000000..5159d9b
--- /dev/null
+++ b/usth/ICT2.7/P1L4 Version Control Subtitles/6 - Essential Actions - lang_en_vs5.srt	
@@ -0,0 +1,79 @@
+1
+00:00:00,140 --> 00:00:02,220
+What I want to do next, is to look at how
+
+2
+00:00:02,220 --> 00:00:05,780
+version control systems actually work. We saw what they are. We
+
+3
+00:00:05,780 --> 00:00:08,130
+saw why they are useful. But how do they actually work?
+
+4
+00:00:08,130 --> 00:00:11,460
+And we're going to do that by starting from some essential
+
+5
+00:00:11,460 --> 00:00:15,400
+actions that version control systems perform. The first one is the
+
+6
+00:00:15,400 --> 00:00:18,920
+addition of files. So, when you use a version control system,
+
+7
+00:00:18,920 --> 00:00:22,280
+you can add a file to the repository. And at that
+
+8
+00:00:22,280 --> 00:00:25,400
+point the file will be accessible to other people who have access
+
+9
+00:00:25,400 --> 00:00:28,640
+to the repository. And now the fundamental action is commit.
+
+10
+00:00:28,640 --> 00:00:31,230
+When you change a file, a file that is already in
+
+11
+00:00:31,230 --> 00:00:33,610
+the repository, when you make some local changes to a
+
+12
+00:00:33,610 --> 00:00:36,430
+file that is already in the repository, you want then to
+
+13
+00:00:36,430 --> 00:00:39,460
+commit your changes to the central repository, so they can
+
+14
+00:00:39,460 --> 00:00:43,990
+become visible to all of the other users on the repository. Finally,
+
+15
+00:00:43,990 --> 00:00:47,770
+another fundamental action is the action of updating a file. If
+
+16
+00:00:47,770 --> 00:00:50,650
+we have a repository and someone else can modify the files
+
+17
+00:00:50,650 --> 00:00:52,800
+in the repository, I want to be able to get
+
+18
+00:00:52,800 --> 00:00:55,550
+the changes that other people made to the files in the
+
+19
+00:00:55,550 --> 00:00:58,980
+repository. And these are just three of the basic actions, but
+
+20
+00:00:58,980 --> 00:01:01,870
+there are many, many more. And we'll see several of those.
diff --git a/usth/ICT2.7/P1L4 Version Control Subtitles/7 - Example Workflow - lang_en_vs5.srt b/usth/ICT2.7/P1L4 Version Control Subtitles/7 - Example Workflow - lang_en_vs5.srt
new file mode 100644
index 0000000..c2f58df
--- /dev/null
+++ b/usth/ICT2.7/P1L4 Version Control Subtitles/7 - Example Workflow - lang_en_vs5.srt	
@@ -0,0 +1,111 @@
+1
+00:00:00,160 --> 00:00:02,830
+Before looking at additional actions, though, I would like to
+
+2
+00:00:02,830 --> 00:00:06,770
+see what is the basic workflow in a version control system
+
+3
+00:00:06,770 --> 00:00:09,370
+using the three actions that we just saw. And to
+
+4
+00:00:09,370 --> 00:00:11,760
+do that I'm going to use two of our friends, Brad
+
+5
+00:00:11,760 --> 00:00:14,590
+and Janet. So we have Janet here, Brad, and a
+
+6
+00:00:14,590 --> 00:00:18,440
+VCS that they are using. Now imagine that Janet creates a
+
+7
+00:00:18,440 --> 00:00:23,020
+file called foo.txt and puts some information in the file.
+
+8
+00:00:23,020 --> 00:00:25,250
+At that point she might want to add the file to
+
+9
+00:00:25,250 --> 00:00:28,340
+the repository and to commit it so that her changes
+
+10
+00:00:28,340 --> 00:00:31,210
+and the file get to the central repository. And when she
+
+11
+00:00:31,210 --> 00:00:33,900
+adds and commit, that's exactly what will happen, in foo
+
+12
+00:00:33,900 --> 00:00:36,870
+will be come available here, and will be accessible to the
+
+13
+00:00:36,870 --> 00:00:40,330
+other users. In this case it'll be accessible to Brad.
+
+14
+00:00:40,330 --> 00:00:44,190
+If Brett were to run an update command, what will happen
+
+15
+00:00:44,190 --> 00:00:47,800
+is that the file foo.txt will be copied on the local
+
+16
+00:00:47,800 --> 00:00:50,460
+work space of Brad and Brad will be able to access
+
+17
+00:00:50,460 --> 00:00:52,980
+the file. At this point Brad might want to modify
+
+18
+00:00:52,980 --> 00:00:57,110
+the file, for example add something to this existing file.
+
+19
+00:00:57,110 --> 00:00:59,410
+After doing that, he also may want to share the
+
+20
+00:00:59,410 --> 00:01:02,900
+updated file with Janet. To do that, he will commit the
+
+21
+00:01:02,900 --> 00:01:06,070
+file and the result will be exactly the same of
+
+22
+00:01:06,070 --> 00:01:09,470
+when Janet committed her file. That the updated file will
+
+23
+00:01:09,470 --> 00:01:11,890
+be sent to the repository and the repository will store
+
+24
+00:01:11,890 --> 00:01:15,570
+that information and make it available for other users. So now,
+
+25
+00:01:15,570 --> 00:01:18,290
+if Janet performs an update, she will get the
+
+26
+00:01:18,290 --> 00:01:21,860
+new version of foo.txt with the additional information that was
+
+27
+00:01:21,860 --> 00:01:24,950
+added by Brad. And we will see all of this
+
+28
+00:01:24,950 --> 00:01:27,350
+in action in our next demo in a few minutes.
diff --git "a/usth/ICT2.7/P1L4 Version Control Subtitles/8 - \"Don'ts\" in VCS - lang_en_vs5.srt" "b/usth/ICT2.7/P1L4 Version Control Subtitles/8 - \"Don'ts\" in VCS - lang_en_vs5.srt"
new file mode 100644
index 0000000..f5d27fb
--- /dev/null
+++ "b/usth/ICT2.7/P1L4 Version Control Subtitles/8 - \"Don'ts\" in VCS - lang_en_vs5.srt"	
@@ -0,0 +1,175 @@
+1
+00:00:00,100 --> 00:00:02,020
+Before getting to the demo, I want to say a few
+
+2
+00:00:02,020 --> 00:00:06,550
+more things. In particular, I discuss the main don'ts in VCS. So,
+
+3
+00:00:06,550 --> 00:00:09,110
+what are some things that you don't want to do, and
+
+4
+00:00:09,110 --> 00:00:12,687
+you should not do, when you're using a version control system? And
+
+5
+00:00:12,687 --> 00:00:15,382
+I'm going to mention two, in particular, because these are two
+
+6
+00:00:15,382 --> 00:00:18,028
+that I witnessed several times when I was teaching this class and
+
+7
+00:00:18,028 --> 00:00:21,820
+also when collaborating with other people. So, there are two kinds
+
+8
+00:00:21,820 --> 00:00:25,460
+of resources that you don't want to add to a VCS normally.
+
+9
+00:00:25,460 --> 00:00:29,070
+One is derived files. For example an executable that is
+
+10
+00:00:29,070 --> 00:00:31,930
+derived by compiling a set of source files, where the
+
+11
+00:00:31,930 --> 00:00:34,480
+source files all already in the repository. At that point,
+
+12
+00:00:34,480 --> 00:00:37,680
+there is no reason to also add the executable file in
+
+13
+00:00:37,680 --> 00:00:41,150
+the repository. So in general, any executable file should not
+
+14
+00:00:41,150 --> 00:00:44,570
+be added to repository. The second class of files that I
+
+15
+00:00:44,570 --> 00:00:47,760
+want to mention is these bulky binary files. If you
+
+16
+00:00:47,760 --> 00:00:50,600
+have one such file, it is normally not a good idea
+
+17
+00:00:50,600 --> 00:00:53,430
+to store them under a version control system, to store them
+
+18
+00:00:53,430 --> 00:00:56,670
+in the repository. There might be exceptions to these rules, but in
+
+19
+00:00:56,670 --> 00:00:59,070
+general, these are the kind of files that you want to
+
+20
+00:00:59,070 --> 00:01:02,540
+keep local, and you don't want to put in the VCS repository.
+
+21
+00:01:02,540 --> 00:01:06,500
+Another typical mistake, and that happens all the time, especially to
+
+22
+00:01:06,500 --> 00:01:10,650
+novice users of VCS. Is that you get your file from VCS
+
+23
+00:01:10,650 --> 00:01:13,120
+and so you get your local copy of the file that
+
+24
+00:01:13,120 --> 00:01:16,270
+was in the VCS, and you want to make some changes, and
+
+25
+00:01:16,270 --> 00:01:20,090
+before making the changes you decided, no, no let me actually save
+
+26
+00:01:20,090 --> 00:01:22,410
+a local copy of the file, and I'm going to work on
+
+27
+00:01:22,410 --> 00:01:24,950
+that one. Or let me save it before I modify it, or
+
+28
+00:01:24,950 --> 00:01:28,350
+let take a snap shot of a whole tree of files. Just because
+
+29
+00:01:28,350 --> 00:01:30,830
+I don't really trust the fact that VCS is going to be
+
+30
+00:01:30,830 --> 00:01:33,170
+able to help and is going to be able to recover from possible
+
+31
+00:01:33,170 --> 00:01:36,980
+mistakes. Never ever do that. I have seen that done many times,
+
+32
+00:01:36,980 --> 00:01:41,570
+and it always leads to disasters. First of all it is useless, and
+
+33
+00:01:41,570 --> 00:01:44,000
+second it's risky. Because then what happens is that at
+
+34
+00:01:44,000 --> 00:01:46,610
+the time in which you have to turn in your assignment,
+
+35
+00:01:46,610 --> 00:01:48,330
+in the case you are doing an assignment, but even in
+
+36
+00:01:48,330 --> 00:01:50,740
+more serious situation, when you have to turn in your code,
+
+37
+00:01:50,740 --> 00:01:54,620
+for example to your colleagues. You always end up being confused
+
+38
+00:01:54,620 --> 00:01:59,010
+about which is the version that you're really using. So absolutely
+
+39
+00:01:59,010 --> 00:02:03,262
+no local copies. No local redundancy when you're using a version
+
+40
+00:02:03,262 --> 00:02:06,798
+control system. Trust the version control system, and trust the version
+
+41
+00:02:06,798 --> 00:02:09,280
+control system to be able to manage your versions. You
+
+42
+00:02:09,280 --> 00:02:13,350
+can always save it, commit it, retrieve previous versions, and you'll
+
+43
+00:02:13,350 --> 00:02:15,530
+be able to do everything that you can do by copying
+
+44
+00:02:15,530 --> 00:02:19,240
+the file yourself, and even more. So again, try the VCS.
diff --git a/usth/ICT2.7/P1L4 Version Control Subtitles/9 - Two Main Types of VCS - lang_en_vs5.srt b/usth/ICT2.7/P1L4 Version Control Subtitles/9 - Two Main Types of VCS - lang_en_vs5.srt
new file mode 100644
index 0000000..3c6eba4
--- /dev/null
+++ b/usth/ICT2.7/P1L4 Version Control Subtitles/9 - Two Main Types of VCS - lang_en_vs5.srt	
@@ -0,0 +1,163 @@
+1
+00:00:00,160 --> 00:00:01,970
+Something else I want to mention is that there
+
+2
+00:00:01,970 --> 00:00:05,460
+are many different version control systems but we can classify
+
+3
+00:00:05,460 --> 00:00:09,250
+them normally in two main types: centralized VCS's and
+
+4
+00:00:09,250 --> 00:00:13,230
+decentralized VCS's. So what is the difference between these two?
+
+5
+00:00:13,230 --> 00:00:16,750
+Let's use again our friends Janet and Brett.
+
+6
+00:00:16,750 --> 00:00:19,510
+In the case of a centralized version control system
+
+7
+00:00:19,510 --> 00:00:22,290
+there is a single centralized, as the name says,
+
+8
+00:00:22,290 --> 00:00:25,230
+repository. On which they are commiting their files. So when
+
+9
+00:00:25,230 --> 00:00:27,290
+Janet commits a file. The file will go from
+
+10
+00:00:27,290 --> 00:00:30,390
+her local working directory to the repository, and the same
+
+11
+00:00:30,390 --> 00:00:33,520
+will happen to Brett. The decentralized system is a little
+
+12
+00:00:33,520 --> 00:00:37,310
+more interesting because in this case, they will both have
+
+13
+00:00:37,310 --> 00:00:40,790
+sort of a local repository in which they can commit
+
+14
+00:00:40,790 --> 00:00:43,970
+their changes. So they can commit changes without the other
+
+15
+00:00:43,970 --> 00:00:47,940
+users of the VCS being able to see these changes.
+
+16
+00:00:47,940 --> 00:00:50,300
+And when they're happy with the version. And when they're
+
+17
+00:00:50,300 --> 00:00:53,900
+ready to release the version, they can push it to a central
+
+18
+00:00:53,900 --> 00:00:56,840
+repository. And at that point, it will become available to the other
+
+19
+00:00:56,840 --> 00:01:01,100
+users of the repository. To the other users of the VCS. There
+
+20
+00:01:01,100 --> 00:01:02,870
+are several advantages in a distributive
+
+21
+00:01:02,870 --> 00:01:04,300
+system. I'm just going to mention a few,
+
+22
+00:01:04,300 --> 00:01:07,520
+because there are really many. One is the fact of having this
+
+23
+00:01:07,520 --> 00:01:10,570
+local version. If you used VCS before, I'm sure you've been in
+
+24
+00:01:10,570 --> 00:01:13,280
+the situation in which you want to kind of take a snapshot
+
+25
+00:01:13,280 --> 00:01:15,820
+of what you have. But you don't want that snapshot to be available
+
+26
+00:01:15,820 --> 00:01:18,200
+to the other users. Because it's still not ready to be
+
+27
+00:01:18,200 --> 00:01:21,240
+released, to be looked up. If you're using a centralized system,
+
+28
+00:01:21,240 --> 00:01:23,140
+there's really no way you can do that, unless you make
+
+29
+00:01:23,140 --> 00:01:25,150
+a local copy, which is something we said you don't want
+
+30
+00:01:25,150 --> 00:01:28,625
+to do. With a distributor, with a decentralized VCS you can
+
+31
+00:01:28,625 --> 00:01:32,444
+commit your local changes here, in your local repository, and you
+
+32
+00:01:32,444 --> 00:01:37,030
+can push them to the central repository only when you're ready.
+
+33
+00:01:37,030 --> 00:01:40,870
+Another big advantage, is that you can use multiple remote repository.
+
+34
+00:01:40,870 --> 00:01:43,210
+In fact, centralized is not the right name for this
+
+35
+00:01:43,210 --> 00:01:45,980
+one. This is just a remote repository, and I can have
+
+36
+00:01:45,980 --> 00:01:48,910
+more than one. For example, Brad might want to push
+
+37
+00:01:48,910 --> 00:01:52,150
+to another remote repository. As well. For instance, this could be
+
+38
+00:01:52,150 --> 00:01:55,940
+a repository where the files are accessible for wider distribution.
+
+39
+00:01:55,940 --> 00:01:59,620
+Imagine developing a software system in which a team is sharing
+
+40
+00:01:59,620 --> 00:02:02,930
+internal versions, and then only some of these versions are actually
+
+41
+00:02:02,930 --> 00:02:06,080
+pushed to the repository that is seeable to the whole world.
diff --git a/usth/ICT2.7/P1L5 Requirements Gathering Subtitles/1 - Gathering Requirements - lang_en_vs3.srt b/usth/ICT2.7/P1L5 Requirements Gathering Subtitles/1 - Gathering Requirements - lang_en_vs3.srt
new file mode 100644
index 0000000..c01c859
--- /dev/null
+++ b/usth/ICT2.7/P1L5 Requirements Gathering Subtitles/1 - Gathering Requirements - lang_en_vs3.srt	
@@ -0,0 +1,63 @@
+1
+00:00:00,270 --> 00:00:02,969
+Gathering requirements is one of the most difficult tasks a software
+
+2
+00:00:02,969 --> 00:00:07,010
+engineer faces. In industry, you may gather requirements from end users,
+
+3
+00:00:07,010 --> 00:00:09,580
+external clients, or from co-workers in other areas of your own
+
+4
+00:00:09,580 --> 00:00:14,320
+company. Occasionally, you may receive a well documented set of requirements.
+
+5
+00:00:14,320 --> 00:00:16,970
+However, in most cases, you will need to glean the requirements
+
+6
+00:00:16,970 --> 00:00:20,230
+from conversations with the prospective clients, and distill them down into
+
+7
+00:00:20,230 --> 00:00:23,150
+something actionable on your own. Suppose a teacher came to you
+
+8
+00:00:23,150 --> 00:00:25,310
+with a request for a piece of software their students could
+
+9
+00:00:25,310 --> 00:00:28,500
+use to find out the average length of the sentences in
+
+10
+00:00:28,500 --> 00:00:31,390
+their essays. What questions come into mind to help you figure
+
+11
+00:00:31,390 --> 00:00:34,620
+out the full requirements for this project. Write down a list
+
+12
+00:00:34,620 --> 00:00:37,630
+of at least ten questions that might help you determine them.
+
+13
+00:00:37,630 --> 00:00:40,240
+Please take the time to do this before moving on. There's
+
+14
+00:00:40,240 --> 00:00:42,670
+no penalty for looking ahead, but if you skip this exercise
+
+15
+00:00:42,670 --> 00:00:44,920
+you'll cheat yourself out of the benefits of brainstorming and getting
+
+16
+00:00:44,920 --> 00:00:48,190
+your mind around the project before being bombarded by more information.
diff --git a/usth/ICT2.7/P1L5 Requirements Gathering Subtitles/2 - Choosing Good Questions - lang_en_vs3.srt b/usth/ICT2.7/P1L5 Requirements Gathering Subtitles/2 - Choosing Good Questions - lang_en_vs3.srt
new file mode 100644
index 0000000..a834b21
--- /dev/null
+++ b/usth/ICT2.7/P1L5 Requirements Gathering Subtitles/2 - Choosing Good Questions - lang_en_vs3.srt	
@@ -0,0 +1,15 @@
+1
+00:00:00,150 --> 00:00:03,400
+Now that you've written some of your own questions, consider the following
+
+2
+00:00:03,400 --> 00:00:07,120
+three. Which is the most likely to be useful for determining the detailed
+
+3
+00:00:07,120 --> 00:00:11,730
+requirements? Maybe, what OSes should it run on? Or maybe, how will the
+
+4
+00:00:11,730 --> 00:00:16,210
+user specify input? Or finally, how many lines of code should it take?
diff --git a/usth/ICT2.7/P1L5 Requirements Gathering Subtitles/3 - Choosing Good Questions Solution - lang_en_vs3.srt b/usth/ICT2.7/P1L5 Requirements Gathering Subtitles/3 - Choosing Good Questions Solution - lang_en_vs3.srt
new file mode 100644
index 0000000..3c29d6b
--- /dev/null
+++ b/usth/ICT2.7/P1L5 Requirements Gathering Subtitles/3 - Choosing Good Questions Solution - lang_en_vs3.srt	
@@ -0,0 +1,55 @@
+1
+00:00:00,450 --> 00:00:03,260
+The last question is almost never a reasonable one. For one
+
+2
+00:00:03,260 --> 00:00:05,660
+thing, the client should not need to know or care about
+
+3
+00:00:05,660 --> 00:00:08,412
+how many lines of code make up the program's source code.
+
+4
+00:00:08,412 --> 00:00:09,910
+In forming requirements, you should avoid
+
+5
+00:00:09,910 --> 00:00:11,940
+implementation specific questions that do not
+
+6
+00:00:11,940 --> 00:00:15,290
+directly interface with the user. The first question is very relevant
+
+7
+00:00:15,290 --> 00:00:18,830
+in some situations. For example, a graphic sentence with video game or
+
+8
+00:00:18,830 --> 00:00:21,630
+performance is key. However, you should not write any operating system
+
+9
+00:00:21,630 --> 00:00:25,620
+specific code unless absolutely needed, and should strive to make your code
+
+10
+00:00:25,620 --> 00:00:28,070
+platform independent whenever possible. The
+
+11
+00:00:28,070 --> 00:00:30,990
+second question, however, is very relevant.
+
+12
+00:00:30,990 --> 00:00:32,870
+Now that you've thought a bit about what you might ask of
+
+13
+00:00:32,870 --> 00:00:35,810
+the client requesting this program, let's watch Alvin, one of Udasea's
+
+14
+00:00:35,810 --> 00:00:39,850
+engineers, asking his own questions. He'll be speaking with Lauren, the client.
diff --git a/usth/ICT2.7/P1L5 Requirements Gathering Subtitles/4 - Requirements Interview - lang_en_vs3.srt b/usth/ICT2.7/P1L5 Requirements Gathering Subtitles/4 - Requirements Interview - lang_en_vs3.srt
new file mode 100644
index 0000000..74a0b79
--- /dev/null
+++ b/usth/ICT2.7/P1L5 Requirements Gathering Subtitles/4 - Requirements Interview - lang_en_vs3.srt	
@@ -0,0 +1,323 @@
+1
+00:00:00,430 --> 00:00:01,050
+Hi, I'm Lauren.
+
+2
+00:00:01,050 --> 00:00:01,990
+&gt;&gt; Hi, I'm Alvin.
+
+3
+00:00:01,990 --> 00:00:06,470
+&gt;&gt; I'm an instructor at a university nearby and I've been noticing that when
+
+4
+00:00:06,470 --> 00:00:09,700
+my students write their essays, they have
+
+5
+00:00:09,700 --> 00:00:13,100
+very long, very wordy sentences and I would
+
+6
+00:00:13,100 --> 00:00:17,600
+like to develop some kind of tool that they can use to keep track of
+
+7
+00:00:17,600 --> 00:00:20,440
+this and maybe perfect their writing style.
+
+8
+00:00:20,440 --> 00:00:21,410
+Do you think that's something you could do?
+
+9
+00:00:21,410 --> 00:00:25,850
+&gt;&gt; I think so. Let's start by helping me get acquainted with the students
+
+10
+00:00:25,850 --> 00:00:29,620
+in the class. So how many students do we have in this class typically?
+
+11
+00:00:29,620 --> 00:00:34,000
+&gt;&gt; Usually about 45 per unit, but I can have up to six units a semester.
+
+12
+00:00:34,000 --> 00:00:36,420
+&gt;&gt; 45 students, and six sections per
+
+13
+00:00:36,420 --> 00:00:39,220
+semester. That's a farily reasonable size. So,
+
+14
+00:00:39,220 --> 00:00:42,790
+do you know anything about what the students are using as far as computers go?
+
+15
+00:00:42,790 --> 00:00:46,640
+&gt;&gt; I don't know what kind of computers they're using. And they
+
+16
+00:00:46,640 --> 00:00:50,960
+could be, I don't know, anywhere from having no tech experience to
+
+17
+00:00:50,960 --> 00:00:52,200
+being pretty proficient.
+
+18
+00:00:52,200 --> 00:00:54,930
+&gt;&gt; Do you know anything about how
+
+19
+00:00:54,930 --> 00:00:57,350
+familiar the students are with computers in general?
+
+20
+00:00:57,350 --> 00:00:59,540
+&gt;&gt; I'm sure we have some people on the low end that have
+
+21
+00:00:59,540 --> 00:01:01,430
+never done any type of programming, and
+
+22
+00:01:01,430 --> 00:01:03,680
+then some people who are pretty self-sufficient.
+
+23
+00:01:03,680 --> 00:01:07,210
+&gt;&gt; Okay, and I guess my last question related to
+
+24
+00:01:07,210 --> 00:01:10,170
+the students is, what is the students actually submitting to you.
+
+25
+00:01:10,170 --> 00:01:14,080
+&gt;&gt; They've been sending just raw text files via email to me.
+
+26
+00:01:14,080 --> 00:01:16,660
+&gt;&gt; So from the sounds of things
+
+27
+00:01:16,660 --> 00:01:19,140
+we have a fairly broad, I guess base
+
+28
+00:01:19,140 --> 00:01:23,100
+of students to work with, both in technical proficiency
+
+29
+00:01:23,100 --> 00:01:27,180
+as well as their operating system environments potentially.
+
+30
+00:01:27,180 --> 00:01:29,420
+So I think what we'll probably do to start
+
+31
+00:01:29,420 --> 00:01:33,270
+off with is make a command line, Java
+
+32
+00:01:33,270 --> 00:01:36,760
+based tool. That the students can run and we'll
+
+33
+00:01:36,760 --> 00:01:39,910
+give them a fair amount of you know, documentation
+
+34
+00:01:39,910 --> 00:01:41,690
+on how to use the tool. And I expect
+
+35
+00:01:41,690 --> 00:01:45,090
+that there will be a lot of little error conditions that may happen
+
+36
+00:01:45,090 --> 00:01:49,320
+that we want to produce a reasonably friendly message were anything to go wrong.
+
+37
+00:01:49,320 --> 00:01:50,480
+&gt;&gt; Yeah. That'd be great.
+
+38
+00:01:50,480 --> 00:01:54,750
+&gt;&gt; So, a little bit more, I guess about
+
+39
+00:01:54,750 --> 00:01:58,539
+the actual essay itself, its submission, what constitutes a word?
+
+40
+00:01:59,820 --> 00:02:03,190
+&gt;&gt; I really only care about the longer words, so, is there a
+
+41
+00:02:03,190 --> 00:02:06,140
+way that we can only count words that are maybe above three letters?
+
+42
+00:02:06,140 --> 00:02:06,830
+&gt;&gt; I think
+
+43
+00:02:06,830 --> 00:02:08,508
+that's something we can do. And I think
+
+44
+00:02:08,508 --> 00:02:10,030
+that because you seem a little bit unsure
+
+45
+00:02:10,030 --> 00:02:11,540
+we might be able to have that be
+
+46
+00:02:11,540 --> 00:02:13,820
+a little bit more flexible than we otherwise would.
+
+47
+00:02:13,820 --> 00:02:14,500
+&gt;&gt; Great.
+
+48
+00:02:14,500 --> 00:02:18,330
+&gt;&gt; What does a sentence mean to you? Is it kind of flexible?
+
+49
+00:02:18,330 --> 00:02:21,280
+&gt;&gt; I would say anything that ends in a period or
+
+50
+00:02:21,280 --> 00:02:25,870
+even a question mark. Maybe even an exclamation mark. or, something
+
+51
+00:02:25,870 --> 00:02:28,760
+even, maybe even with a comma or semi-colon. I really only
+
+52
+00:02:28,760 --> 00:02:32,370
+care about the sentences that aren't gramatically correct and are too long.
+
+53
+00:02:32,370 --> 00:02:35,180
+&gt;&gt; I think we can probably make that a little bit more flexible too
+
+54
+00:02:35,180 --> 00:02:37,520
+so that way, you can kind of say we're going to, or you want to include them.
+
+55
+00:02:37,520 --> 00:02:38,020
+&gt;&gt; Mm-hm.
+
+56
+00:02:38,020 --> 00:02:41,786
+&gt;&gt; So maybe, sounds like you are little bit on the fence
+
+57
+00:02:41,786 --> 00:02:45,100
+about whether or not say, a comma should be considered a sentence.
+
+58
+00:02:45,100 --> 00:02:45,130
+&gt;&gt; Mm.
+
+59
+00:02:45,130 --> 00:02:46,370
+&gt;&gt; Entirely on its own or not. So we
+
+60
+00:02:46,370 --> 00:02:49,830
+can probably make that a little bit configurable as well.
+
+61
+00:02:51,880 --> 00:02:56,510
+And so, just to confirm the actual end result to
+
+62
+00:02:56,510 --> 00:02:59,870
+the student is the average number of words per sentence?
+
+63
+00:02:59,870 --> 00:03:01,610
+&gt;&gt; Yeah, yeah that'd be fine.
+
+64
+00:03:01,610 --> 00:03:07,430
+&gt;&gt; Okay, overall to start off with, looks like we have some
+
+65
+00:03:07,430 --> 00:03:10,280
+sort of customization of the word length that we want to look for.
+
+66
+00:03:10,280 --> 00:03:10,780
+&gt;&gt; Mm-hm. Yeah.
+
+67
+00:03:12,000 --> 00:03:14,650
+&gt;&gt; We have some kind of variability in
+
+68
+00:03:14,650 --> 00:03:17,880
+what we want to have as acceptable sentence structure.
+
+69
+00:03:17,880 --> 00:03:24,570
+So, periods, question marks, semicolons, things like that. And, the end result
+
+70
+00:03:24,570 --> 00:03:27,260
+to the student is if we're successful, they'll get the average number of
+
+71
+00:03:27,260 --> 00:03:31,060
+words per sentence. Otherwise we tell them something a little bit helpful to
+
+72
+00:03:31,060 --> 00:03:33,240
+kind of put them on the right track to use the tool correctly.
+
+73
+00:03:33,240 --> 00:03:34,620
+&gt;&gt; Yeah that's the error codes right?
+
+74
+00:03:35,850 --> 00:03:38,150
+&gt;&gt; Hopefully not error codes but something a little bit nicer.
+
+75
+00:03:38,150 --> 00:03:39,800
+&gt;&gt; [LAUGH] Okay.
+
+76
+00:03:39,800 --> 00:03:41,150
+&gt;&gt; So I think I have enough to
+
+77
+00:03:41,150 --> 00:03:43,440
+get started and produce something that's you know,
+
+78
+00:03:43,440 --> 00:03:47,150
+a reasonable I guess, rough draft. Of something
+
+79
+00:03:47,150 --> 00:03:48,700
+that you can use to help your class out.
+
+80
+00:03:48,700 --> 00:03:49,590
+&gt;&gt; Great. Thank you.
+
+81
+00:03:49,590 --> 00:03:50,240
+&gt;&gt; Thank you.
diff --git a/usth/ICT2.7/P1L5 Requirements Gathering Subtitles/5 - Average Sentence Length Requirements - lang_en_vs3.srt b/usth/ICT2.7/P1L5 Requirements Gathering Subtitles/5 - Average Sentence Length Requirements - lang_en_vs3.srt
new file mode 100644
index 0000000..afd49e1
--- /dev/null
+++ b/usth/ICT2.7/P1L5 Requirements Gathering Subtitles/5 - Average Sentence Length Requirements - lang_en_vs3.srt	
@@ -0,0 +1,83 @@
+1
+00:00:00,340 --> 00:00:02,300
+You've heard Alvin come up with several conclusions for how to
+
+2
+00:00:02,300 --> 00:00:04,510
+set up the program. And we're going to ask that you follow his
+
+3
+00:00:04,510 --> 00:00:07,590
+instincts. We'll spell that out here in a little more technical details
+
+4
+00:00:07,590 --> 00:00:11,030
+so that everyone is working from the same basic starting point. The
+
+5
+00:00:11,030 --> 00:00:13,770
+program must be written in Java and must not make you any
+
+6
+00:00:13,770 --> 00:00:16,730
+nonstandard Java libraries. You will be tested on a machine with the
+
+7
+00:00:16,730 --> 00:00:21,060
+vanilla installation of Java 1.6. Your program must compile on the command
+
+8
+00:00:21,060 --> 00:00:25,360
+line using the Java C command without any additional options. All code
+
+9
+00:00:25,360 --> 00:00:27,530
+required to execute the program that is not part of the
+
+10
+00:00:27,530 --> 00:00:31,950
+standard JDK, must be included as source code with your program.
+
+11
+00:00:31,950 --> 00:00:34,380
+Your program should be an application. That is, it should have
+
+12
+00:00:34,380 --> 00:00:37,160
+a main method and should be executable from the command line using
+
+13
+00:00:37,160 --> 00:00:40,100
+the Java command. The user should be able to provide a
+
+14
+00:00:40,100 --> 00:00:42,450
+file path to the file they wish to be analyzed as a
+
+15
+00:00:42,450 --> 00:00:45,880
+command line argument. User should be able to specify which delimiters
+
+16
+00:00:45,880 --> 00:00:50,570
+count as sentence separators, using the flag -d, defaulting to Lauren's initial
+
+17
+00:00:50,570 --> 00:00:53,930
+thoughts on what should be used as delimiters. The user should be
+
+18
+00:00:53,930 --> 00:00:58,170
+able to specify a lower limit for word length, using the flag -l,
+
+19
+00:00:58,170 --> 00:01:02,100
+defaulting to Lauren's guess at what value might be good. Finally, the program's
+
+20
+00:01:02,100 --> 00:01:03,710
+output should be the average sentence
+
+21
+00:01:03,710 --> 00:01:05,720
+length. Rounded down to the nearest integer.
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/1 - Lesson Overview - lang_en_vs4.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/1 - Lesson Overview - lang_en_vs4.srt
new file mode 100644
index 0000000..27581a6
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/1 - Lesson Overview - lang_en_vs4.srt	
@@ -0,0 +1,55 @@
+1
+00:00:00,340 --> 00:00:05,670
+Hello and welcome to the second part of our software engineering course. In the
+
+2
+00:00:05,670 --> 00:00:09,030
+previous mini-course, we discussed some basic principles
+
+3
+00:00:09,030 --> 00:00:12,430
+behind software engineering. We provided an overview of
+
+4
+00:00:12,430 --> 00:00:15,790
+several software process models and we introduced
+
+5
+00:00:15,790 --> 00:00:18,530
+some important tools that can help developers
+
+6
+00:00:18,530 --> 00:00:21,363
+increase their productivity. In this mini-course, we
+
+7
+00:00:21,363 --> 00:00:25,740
+will focus on requirement and prototyping. More precisely,
+
+8
+00:00:25,740 --> 00:00:28,840
+we will discuss in depth requirements
+
+9
+00:00:28,840 --> 00:00:32,400
+engineering activities. We will also discuss
+
+10
+00:00:32,400 --> 00:00:34,950
+techniques to perform a system analysis
+
+11
+00:00:34,950 --> 00:00:38,720
+and design in an object-oriented fashion. So,
+
+12
+00:00:38,720 --> 00:00:42,250
+let's start the first lesson of this mini-course, which is about the use
+
+13
+00:00:42,250 --> 00:00:45,230
+of engineering techniques to understand and
+
+14
+00:00:45,230 --> 00:00:48,450
+specify the purpose of a software system.
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/10 - Completeness Quiz - lang_en_vs4.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/10 - Completeness Quiz - lang_en_vs4.srt
new file mode 100644
index 0000000..1ab5b4a
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/10 - Completeness Quiz - lang_en_vs4.srt	
@@ -0,0 +1,15 @@
+1
+00:00:00,130 --> 00:00:03,060
+So now that we saw which of these requirements are pertinent and
+
+2
+00:00:03,060 --> 00:00:06,520
+which ones are not, can we consider the above list of requirements
+
+3
+00:00:06,520 --> 00:00:09,710
+of the list of these requirements marked here as a complete list
+
+4
+00:00:09,710 --> 00:00:13,254
+of requirements for a gym? And you have two options, yes or no.
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/11 - Completeness Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/11 - Completeness Quiz Solution - lang_en_vs4.srt
new file mode 100644
index 0000000..2ddc7e9
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/11 - Completeness Quiz Solution - lang_en_vs4.srt	
@@ -0,0 +1,23 @@
+1
+00:00:00,160 --> 00:00:02,060
+And the answer is clearly no.
+
+2
+00:00:02,060 --> 00:00:05,060
+Obviously, there are many missing requirements here.
+
+3
+00:00:05,060 --> 00:00:07,910
+For example, requirements about registration for the
+
+4
+00:00:07,910 --> 00:00:11,560
+customers, requirements about fitness program creation, membership
+
+5
+00:00:11,560 --> 00:00:15,481
+types, and so on. Plus, we are also missing all of the nonfunctional
+
+6
+00:00:15,481 --> 00:00:19,270
+requirements, which we haven't seen yet, but that we will discuss in a bit.
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/12 - Irrelevant Requirements Quiz - lang_en_vs4.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/12 - Irrelevant Requirements Quiz - lang_en_vs4.srt
new file mode 100644
index 0000000..5b5fe86
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/12 - Irrelevant Requirements Quiz - lang_en_vs4.srt	
@@ -0,0 +1,43 @@
+1
+00:00:00,140 --> 00:00:02,400
+In the previous quiz, we saw that some of the requirements
+
+2
+00:00:02,400 --> 00:00:04,920
+that they put in the list were not pertinent. They were
+
+3
+00:00:04,920 --> 00:00:08,590
+irrelevant. So let me ask you. Why can irrelevant requirements be
+
+4
+00:00:08,590 --> 00:00:12,170
+harmful? Why is that a problem to have irrelevant requirements? So
+
+5
+00:00:12,170 --> 00:00:15,060
+here, I'm giving you four possible answers. And I'd like for
+
+6
+00:00:15,060 --> 00:00:18,150
+you to mark all that apply. Can irrelevant requirements be harmful
+
+7
+00:00:18,150 --> 00:00:21,210
+because they may lead to missing functionality in the final product.
+
+8
+00:00:21,210 --> 00:00:23,390
+Because they can introduce inconsistency. Because
+
+9
+00:00:23,390 --> 00:00:25,410
+they can waste the project resources.
+
+10
+00:00:25,410 --> 00:00:28,170
+Or because they may introduce bugs in the software system. And
+
+11
+00:00:28,170 --> 00:00:30,680
+as I said, more than one can be a valid reason.
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/13 - Irrelevant Requirements Quiz Solution - lang_en_vs5.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/13 - Irrelevant Requirements Quiz Solution - lang_en_vs5.srt
new file mode 100644
index 0000000..f1c51c1
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/13 - Irrelevant Requirements Quiz Solution - lang_en_vs5.srt	
@@ -0,0 +1,63 @@
+1
+00:00:00,200 --> 00:00:02,920
+So let's go through the list. Definitely irrelevant requirements
+
+2
+00:00:02,920 --> 00:00:06,370
+cannot lead to missing functionality in the final product, because
+
+3
+00:00:06,370 --> 00:00:10,730
+irrelevant requirements actually refer to unneeded functionality in the system.
+
+4
+00:00:10,730 --> 00:00:13,030
+So functionality that is put in the requirements, but it
+
+5
+00:00:13,030 --> 00:00:15,120
+is not really needed. So we're not going to mark
+
+6
+00:00:15,120 --> 00:00:19,400
+this one. Indeed, irrelevant requirements can introduce inconsistencies. So they
+
+7
+00:00:19,400 --> 00:00:22,490
+could be irrelevant requirements that not only are not pertinent
+
+8
+00:00:22,490 --> 00:00:25,620
+but they are inconsistent with some of the pertinent requirements.
+
+9
+00:00:25,620 --> 00:00:29,220
+They can also waste project resources, because if we spend time
+
+10
+00:00:29,220 --> 00:00:31,920
+designing and then implementing the parts of the system that we
+
+11
+00:00:31,920 --> 00:00:35,410
+refer to these irrelevant requirements, of course, we are wasting project
+
+12
+00:00:35,410 --> 00:00:38,570
+resources. And I will not mark the last one because there's really
+
+13
+00:00:38,570 --> 00:00:42,220
+no correlation between any irrelevant requirements and bugs in the software
+
+14
+00:00:42,220 --> 00:00:45,350
+system. Of course, by implementing the part of the system that refers
+
+15
+00:00:45,350 --> 00:00:47,960
+to an irrelevant requirement you might introduce a bug. But that's
+
+16
+00:00:47,960 --> 00:00:51,020
+not necessarily the case, and there really no correlation between the two.
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/14 - Best Practices - lang_en_vs5.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/14 - Best Practices - lang_en_vs5.srt
new file mode 100644
index 0000000..7497280
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/14 - Best Practices - lang_en_vs5.srt	
@@ -0,0 +1,83 @@
+1
+00:00:00,150 --> 00:00:02,290
+But we collect requirements all the time, right? Every
+
+2
+00:00:02,290 --> 00:00:04,960
+time we build a software system. So how do people
+
+3
+00:00:04,960 --> 00:00:08,320
+cope with these difficulties? What are the best practices?
+
+4
+00:00:08,320 --> 00:00:12,950
+In practice, developers or analysts usually identify a whole bunch
+
+5
+00:00:12,950 --> 00:00:16,590
+of requirements. Sometimes the easiest and most obvious ones. They
+
+6
+00:00:16,590 --> 00:00:19,370
+bring those to the stakeholders, and the stakeholders have to
+
+7
+00:00:19,370 --> 00:00:23,100
+read the requirements, understand them, and if they agree, sign
+
+8
+00:00:23,100 --> 00:00:25,580
+off on them. And the problem is that in general,
+
+9
+00:00:25,580 --> 00:00:28,910
+these requirements documents are difficult to read. They are long, they
+
+10
+00:00:28,910 --> 00:00:32,470
+are often unstructured. They typically contain a lot of information. And
+
+11
+00:00:32,470 --> 00:00:35,310
+in general, they are not exactly a pleasant read. So what
+
+12
+00:00:35,310 --> 00:00:39,710
+happens is that often the stakeholders are short on time, overwhelmed
+
+13
+00:00:39,710 --> 00:00:42,380
+by the amount of information they're given and so they give
+
+14
+00:00:42,380 --> 00:00:44,800
+in to the pressure and sign. And this is a bit
+
+15
+00:00:44,800 --> 00:00:47,300
+of a dramatization clearly but it's clear that what we are
+
+16
+00:00:47,300 --> 00:00:50,640
+looking at is not an ideal scenario. Clearly this is not
+
+17
+00:00:50,640 --> 00:00:53,810
+the way to identify the real purpose of a software system to
+
+18
+00:00:53,810 --> 00:00:57,920
+collect good requirements. And since one of the major causes for project
+
+19
+00:00:57,920 --> 00:01:02,130
+failure is the inadequacy of requirements, we should really avoid this kind
+
+20
+00:01:02,130 --> 00:01:03,590
+of scenario. We should follow a
+
+21
+00:01:03,590 --> 00:01:06,810
+rigorous and effective requirements engineering process instead.
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/15 - RE Definition Breakdown - lang_en_vs4.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/15 - RE Definition Breakdown - lang_en_vs4.srt
new file mode 100644
index 0000000..bcc06a5
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/15 - RE Definition Breakdown - lang_en_vs4.srt	
@@ -0,0 +1,207 @@
+1
+00:00:00,130 --> 00:00:02,540
+But how can we do that? How can we identify the purpose
+
+2
+00:00:02,540 --> 00:00:06,080
+of the system and collect good requirements? To answer that question, let me
+
+3
+00:00:06,080 --> 00:00:07,800
+give you another definition of requirements
+
+4
+00:00:07,800 --> 00:00:09,590
+engineering. And this one is a classical
+
+5
+00:00:09,590 --> 00:00:13,010
+one, one that summarizes what we discussed so far, and then we can
+
+6
+00:00:13,010 --> 00:00:16,180
+use as some sort of reference. And it is a little long.
+
+7
+00:00:16,180 --> 00:00:18,710
+Definitely longer than the one that we saw at the beginning. But it's
+
+8
+00:00:18,710 --> 00:00:21,840
+an important one and it contains a lot of very relevant points. So,
+
+9
+00:00:21,840 --> 00:00:25,210
+we're going to go through it and highlight these points. So the definition says,
+
+10
+00:00:25,210 --> 00:00:28,970
+that the requirements engineering is a set of activities concerned
+
+11
+00:00:28,970 --> 00:00:32,990
+with identifying and communicating the purpose of a software intensive
+
+12
+00:00:32,990 --> 00:00:35,770
+system and the context in which it will be used.
+
+13
+00:00:35,770 --> 00:00:38,570
+And this is exactly what we said at the beginning. But
+
+14
+00:00:38,570 --> 00:00:40,940
+something we can highlight in here, is the fact that
+
+15
+00:00:40,940 --> 00:00:44,210
+we're talking about a set of activities. So, what that means
+
+16
+00:00:44,210 --> 00:00:46,800
+is that requirements engineering is not just a phase or
+
+17
+00:00:46,800 --> 00:00:51,050
+a stage. It also says that it's about identifying and communicating.
+
+18
+00:00:51,050 --> 00:00:53,720
+And what that is telling us is that communication is
+
+19
+00:00:53,720 --> 00:00:56,670
+as important as the analysis. So, it's important to be
+
+20
+00:00:56,670 --> 00:00:59,990
+able to communicate these requirements not only to collect them.
+
+21
+00:00:59,990 --> 00:01:02,018
+And we will discuss many reasons why that is the
+
+22
+00:01:02,018 --> 00:01:05,880
+case. It explicitly talks about purpose. So that allows me
+
+23
+00:01:05,880 --> 00:01:10,310
+to stress, once more, that quality means fitness-for-purpose. We cannot
+
+24
+00:01:10,310 --> 00:01:14,410
+say anything about quality unless we understand the purpose. And
+
+25
+00:01:14,410 --> 00:01:16,210
+the last thing I want to point out in this first
+
+26
+00:01:16,210 --> 00:01:18,420
+part of the definition is the use of the term
+
+27
+00:01:18,420 --> 00:01:21,060
+context. This is also something else that we mentioned at
+
+28
+00:01:21,060 --> 00:01:24,890
+the beginning, that designers, analysts, need to know how and
+
+29
+00:01:24,890 --> 00:01:28,015
+where the system will be used. Without this information, you
+
+30
+00:01:28,015 --> 00:01:30,455
+cannot really understand what the system should do and you
+
+31
+00:01:30,455 --> 00:01:33,280
+cannot really build the system. So now, let's continue and
+
+32
+00:01:33,280 --> 00:01:35,755
+read the second part of the definition that says, hence.
+
+33
+00:01:35,755 --> 00:01:41,550
+Requirements engineering acts as the bridge between the real-world needs of
+
+34
+00:01:41,550 --> 00:01:45,315
+users, customers, and other constituencies affected by a
+
+35
+00:01:45,315 --> 00:01:49,440
+software system and the capabilities and opportunities afforded
+
+36
+00:01:49,440 --> 00:01:52,870
+by software-intensive technologies. This is a long sentence,
+
+37
+00:01:52,870 --> 00:01:55,030
+but also here, we can point out a
+
+38
+00:01:55,030 --> 00:01:57,670
+few interesting and relevant points. Let me start
+
+39
+00:01:57,670 --> 00:02:00,612
+by highlighting two parts. Real-world needs, and the
+
+40
+00:02:00,612 --> 00:02:04,150
+capabilities, and opportunities. So, what are these two
+
+41
+00:02:04,150 --> 00:02:07,000
+parts telling us? They are telling us that requirements
+
+42
+00:02:07,000 --> 00:02:09,949
+are partly about what is needed, the real-world needs
+
+43
+00:02:09,949 --> 00:02:13,520
+of all these stakeholders. But they're also partly about what
+
+44
+00:02:13,520 --> 00:02:16,100
+is possible, what we can actually build. We need
+
+45
+00:02:16,100 --> 00:02:19,260
+to compromise between these two things. And, finally, I would
+
+46
+00:02:19,260 --> 00:02:23,000
+like to point out this term constituencies, which indicates
+
+47
+00:02:23,000 --> 00:02:26,220
+that we need to identify all of the stakeholders, not
+
+48
+00:02:26,220 --> 00:02:29,130
+just the customer and the users, so anybody who is
+
+49
+00:02:29,130 --> 00:02:32,040
+affected by a software system. It is very important to
+
+50
+00:02:32,040 --> 00:02:35,130
+consider all of these actors. Otherwise, again,
+
+51
+00:02:35,130 --> 00:02:37,530
+we'll be missing requirements, we'll be missing
+
+52
+00:02:37,530 --> 00:02:41,120
+part of the purpose of the system and we will build a suboptimal system.
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/16 - Defining Requirements - lang_en_vs4.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/16 - Defining Requirements - lang_en_vs4.srt
new file mode 100644
index 0000000..2c8dde2
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/16 - Defining Requirements - lang_en_vs4.srt	
@@ -0,0 +1,219 @@
+1
+00:00:00,220 --> 00:00:02,120
+So at this point, we have talked quite a bit about
+
+2
+00:00:02,120 --> 00:00:03,800
+requirements engineering, but we haven't
+
+3
+00:00:03,800 --> 00:00:06,450
+really discussed what are requirements exactly.
+
+4
+00:00:06,450 --> 00:00:08,880
+So what is a requirement? To define that I am going
+
+5
+00:00:08,880 --> 00:00:11,860
+to use this diagram which is a classical one. So you might
+
+6
+00:00:11,860 --> 00:00:14,980
+have seen it before. So, discussing this diagram allows me to
+
+7
+00:00:14,980 --> 00:00:18,720
+point out a few interesting things about requirements and define them
+
+8
+00:00:18,720 --> 00:00:21,660
+in a better way. At a high level this diagram contains
+
+9
+00:00:21,660 --> 00:00:24,780
+two main parts, the domain of the machine, which is the hardware,
+
+10
+00:00:24,780 --> 00:00:27,670
+operating system, libraries and so on, on which the
+
+11
+00:00:27,670 --> 00:00:30,860
+software will run. And the domain of the application, which
+
+12
+00:00:30,860 --> 00:00:33,510
+is a world in which the software will operate.
+
+13
+00:00:33,510 --> 00:00:36,690
+And the machine domain is characterized by computers, which are
+
+14
+00:00:36,690 --> 00:00:39,980
+the hardware devices, and programs, which is the software
+
+15
+00:00:39,980 --> 00:00:43,430
+that runs on these devices. The application domain, conversely, is
+
+16
+00:00:43,430 --> 00:00:47,370
+characterized by domain properties, which are things that are true
+
+17
+00:00:47,370 --> 00:00:50,330
+of the world anyways, whether I'm building my system or
+
+18
+00:00:50,330 --> 00:00:53,510
+not, and requirements, which are things in the world we
+
+19
+00:00:53,510 --> 00:00:56,220
+would like to achieve by delivering the system that we are
+
+20
+00:00:56,220 --> 00:00:59,400
+building. Basically, to put it in a different way, the former,
+
+21
+00:00:59,400 --> 00:01:02,950
+the domain properties, represents the assumptions that we make on the
+
+22
+00:01:02,950 --> 00:01:06,740
+domain. And the latter, the requirements, are the actual requirements
+
+23
+00:01:06,740 --> 00:01:09,660
+that we aim to collect. So we have something here, right,
+
+24
+00:01:09,660 --> 00:01:13,380
+at the intersection of this application domain and this machine domain.
+
+25
+00:01:13,380 --> 00:01:15,570
+And what is that? And this is what we normally call
+
+26
+00:01:15,570 --> 00:01:19,225
+the specification, which is a description, often a formal description,
+
+27
+00:01:19,225 --> 00:01:22,120
+of what the system that we are building should do to
+
+28
+00:01:22,120 --> 00:01:25,520
+meet the requirements. So this is a bridge between these two
+
+29
+00:01:25,520 --> 00:01:29,380
+domains. And as the graphical depiction shows, the specification is written
+
+30
+00:01:29,380 --> 00:01:33,220
+in terms of shared phenomena. Things that are observable in both
+
+31
+00:01:33,220 --> 00:01:35,980
+the machine domain and the application domain. And just to make
+
+32
+00:01:35,980 --> 00:01:37,540
+things a little more concrete, I want to give you a
+
+33
+00:01:37,540 --> 00:01:41,180
+couple of examples of what these phenomena, these shared phenomena, are.
+
+34
+00:01:41,180 --> 00:01:43,350
+And we can think about two main kinds of phenomena.
+
+35
+00:01:43,350 --> 00:01:46,080
+The first one are events in the real world that the
+
+36
+00:01:46,080 --> 00:01:50,140
+machine can directly sense. For example, a button being pushed or
+
+37
+00:01:50,140 --> 00:01:53,910
+a sensor being activated. These are events that happen here, but
+
+38
+00:01:53,910 --> 00:01:56,500
+that the machine can detect. So they're events that can
+
+39
+00:01:56,500 --> 00:01:59,650
+be used to define the specification. And the second type of
+
+40
+00:01:59,650 --> 00:02:02,890
+phenomena are actions in the real world that the machine can
+
+41
+00:02:02,890 --> 00:02:06,380
+directly cause. For example, an image appearing on a screen or
+
+42
+00:02:06,380 --> 00:02:09,300
+a device being turned on and off. Again, this is something
+
+43
+00:02:09,300 --> 00:02:12,460
+that the machine can make happen and then can have manifestation in
+
+44
+00:02:12,460 --> 00:02:15,520
+the real world. And again this is therefore something on which
+
+45
+00:02:15,520 --> 00:02:17,720
+the specification can predicate, something that
+
+46
+00:02:17,720 --> 00:02:19,750
+we can describe in our specification.
+
+47
+00:02:19,750 --> 00:02:22,860
+And this is sort of a philosophical discussion, but even if
+
+48
+00:02:22,860 --> 00:02:26,210
+you don't care about the philosophical discussion, the one take away point
+
+49
+00:02:26,210 --> 00:02:28,800
+that I would like for you to get from this discussion is
+
+50
+00:02:28,800 --> 00:02:31,392
+the fact that when writing a specification you have to be aware
+
+51
+00:02:31,392 --> 00:02:34,860
+of the fact that you're talking about shared phenomena. Events in the real
+
+52
+00:02:34,860 --> 00:02:39,100
+world that the machine can sense and actions in the real world that the
+
+53
+00:02:39,100 --> 00:02:43,048
+machine can cause. So this is what the specification is about, a bridge between
+
+54
+00:02:43,048 --> 00:02:44,760
+these two worlds that define what the
+
+55
+00:02:44,760 --> 00:02:47,170
+system should do to satisfy the requirements.
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/17 - Defining Requirements Quiz - lang_en_vs4.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/17 - Defining Requirements Quiz - lang_en_vs4.srt
new file mode 100644
index 0000000..343e3cb
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/17 - Defining Requirements Quiz - lang_en_vs4.srt	
@@ -0,0 +1,79 @@
+1
+00:00:00,180 --> 00:00:01,780
+Since we just discussed application
+
+2
+00:00:01,780 --> 00:00:04,770
+domain, machine domain, and the specificiation,
+
+3
+00:00:04,770 --> 00:00:07,760
+let's make sure that these concepts are well understood. To do that,
+
+4
+00:00:07,760 --> 00:00:09,740
+I'm going to use a quiz, and I would like for you
+
+5
+00:00:09,740 --> 00:00:12,590
+to refer to the figure that we just discussed that I'm also
+
+6
+00:00:12,590 --> 00:00:16,050
+reproducing here on a small scale on the right. And then
+
+7
+00:00:16,050 --> 00:00:19,080
+referring to the figure, you should indicate for each of the items
+
+8
+00:00:19,080 --> 00:00:22,140
+that I'm going to show you here shortly. Whether they belong to
+
+9
+00:00:22,140 --> 00:00:25,360
+the machine domain. In this case, we're going to put a one next
+
+10
+00:00:25,360 --> 00:00:28,150
+to the icon. The application domain, in this case you should
+
+11
+00:00:28,150 --> 00:00:31,410
+put two. Or their intersection, and in this case you should
+
+12
+00:00:31,410 --> 00:00:34,100
+put three. So this is the lists of items. So let
+
+13
+00:00:34,100 --> 00:00:37,750
+me read it. An algorithm sorts a list of books in alphabetical
+
+14
+00:00:37,750 --> 00:00:41,070
+order by the first author's name. A notification of the arrival
+
+15
+00:00:41,070 --> 00:00:44,380
+of a message appears on a smart watch. An employee wants to
+
+16
+00:00:44,380 --> 00:00:47,150
+organize a meeting with a set of colleagues. And finally, a
+
+17
+00:00:47,150 --> 00:00:50,690
+user clicks a link on a web page. So again, put 1,
+
+18
+00:00:50,690 --> 00:00:55,740
+2, or 3 here in these lots, depending on whether you think that these items
+
+19
+00:00:55,740 --> 00:00:57,840
+belong to the machine domain, the application
+
+20
+00:00:57,840 --> 00:01:00,910
+domain, or their intersection. So, their specification, here.
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/18 - Defining Requirements Quiz Solution - lang_en_vs5.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/18 - Defining Requirements Quiz Solution - lang_en_vs5.srt
new file mode 100644
index 0000000..7fcbd53
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/18 - Defining Requirements Quiz Solution - lang_en_vs5.srt	
@@ -0,0 +1,103 @@
+1
+00:00:00,200 --> 00:00:03,460
+So let's look at each one of these items individually, starting from
+
+2
+00:00:03,460 --> 00:00:06,260
+the first one. And here this item has to do with how
+
+3
+00:00:06,260 --> 00:00:08,250
+the machine stores the information and
+
+4
+00:00:08,250 --> 00:00:10,240
+how the corresponding algorithm is written.
+
+5
+00:00:10,240 --> 00:00:12,920
+But it has no bearing in the real world. That is, in
+
+6
+00:00:12,920 --> 00:00:15,720
+the application domain. Therefore this. Definitely
+
+7
+00:00:15,720 --> 00:00:17,200
+belongs to the machine domain, and
+
+8
+00:00:17,200 --> 00:00:19,610
+we're going to put a one here. What about a notification of
+
+9
+00:00:19,610 --> 00:00:21,980
+the arrival of a message on a smart watch? This is an
+
+10
+00:00:21,980 --> 00:00:25,170
+event that is generated within the machine, but it has an effect,
+
+11
+00:00:25,170 --> 00:00:28,480
+an observable effect, in this case, in the real world as well.
+
+12
+00:00:28,480 --> 00:00:31,780
+Therefore, we're going to mark this as three. So this is an
+
+13
+00:00:31,780 --> 00:00:33,460
+event. This is something that belongs
+
+14
+00:00:33,460 --> 00:00:35,160
+to the intersection between the application
+
+15
+00:00:35,160 --> 00:00:37,480
+domain and the machine domain. So it's something that could be in
+
+16
+00:00:37,480 --> 00:00:40,730
+the specification. Now what about an employee that wants to organize a
+
+17
+00:00:40,730 --> 00:00:43,850
+meeting with a set of colleagues? This is an event that belongs
+
+18
+00:00:43,850 --> 00:00:46,460
+to the application domain because it is a fact that it's true
+
+19
+00:00:46,460 --> 00:00:50,290
+that exists. In the real world independently from the existence of a machine.
+
+20
+00:00:50,290 --> 00:00:52,380
+Therefore, we're going to mark this as two.
+
+21
+00:00:52,380 --> 00:00:54,890
+Finally, the event of a user clicking on a
+
+22
+00:00:54,890 --> 00:00:58,950
+link on a web page is an event that occurs in the real world but that has an
+
+23
+00:00:58,950 --> 00:01:01,932
+effect also within the machine and, therefore, we're
+
+24
+00:01:01,932 --> 00:01:04,920
+going to mark this as three, something that happens
+
+25
+00:01:04,920 --> 00:01:07,730
+at the intersection. between these two domains, and once
+
+26
+00:01:07,730 --> 00:01:10,060
+more, something that could be in a specification.
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/19 - Functional and Nonfunctional Requirements - lang_en_vs4.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/19 - Functional and Nonfunctional Requirements - lang_en_vs4.srt
new file mode 100644
index 0000000..1cff519
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/19 - Functional and Nonfunctional Requirements - lang_en_vs4.srt	
@@ -0,0 +1,139 @@
+1
+00:00:00,188 --> 00:00:02,360
+Among the requirement that we can collect from the application
+
+2
+00:00:02,360 --> 00:00:05,030
+domain, we need to distinguish between two main types. And you've
+
+3
+00:00:05,030 --> 00:00:06,540
+probably heard about these ones.
+
+4
+00:00:06,540 --> 00:00:09,650
+Functional requirments and non-functional requiremnts. Functional
+
+5
+00:00:09,650 --> 00:00:13,020
+requiremetns have to do with the functionality of the system, with
+
+6
+00:00:13,020 --> 00:00:16,660
+what the system does with the computation. For example the elevator
+
+7
+00:00:16,660 --> 00:00:19,660
+shall take people to the floor they select. That's a functional
+
+8
+00:00:19,660 --> 00:00:22,650
+requirement, that has to do with the functionality of the system.
+
+9
+00:00:22,650 --> 00:00:25,550
+Or for a very simple one, the system has to output
+
+10
+00:00:25,550 --> 00:00:27,620
+the square root of the number past as
+
+11
+00:00:27,620 --> 00:00:29,910
+an input. So these kind of requirements have in
+
+12
+00:00:29,910 --> 00:00:33,630
+general well defined satisfaction criteria. So, for example, if
+
+13
+00:00:33,630 --> 00:00:35,420
+for the latter one that we mentioned it is
+
+14
+00:00:35,420 --> 00:00:37,560
+pretty clear how to check whether the output
+
+15
+00:00:37,560 --> 00:00:39,784
+is actually the square root of the number passed
+
+16
+00:00:39,784 --> 00:00:43,535
+in input. Non-functional requirements, conversely, refer to a system's
+
+17
+00:00:43,535 --> 00:00:46,800
+non-functional properties, systems qualities.
+
+18
+00:00:46,800 --> 00:00:50,120
+Such as security, accuracy, performance,
+
+19
+00:00:50,120 --> 00:00:52,220
+cost. Or, you know, usability,
+
+20
+00:00:52,220 --> 00:00:55,910
+adaptability, interoperability, reusability and so
+
+21
+00:00:55,910 --> 00:00:58,850
+on. So, all these qualities the don't necessarily have to
+
+22
+00:00:58,850 --> 00:01:02,520
+do with the functionality. And, unlike functional requirements, non functional
+
+23
+00:01:02,520 --> 00:01:06,060
+requirements Do not always have clear satisfaction criteria. For example,
+
+24
+00:01:06,060 --> 00:01:08,670
+if we say that the elevator must be fast, that's
+
+25
+00:01:08,670 --> 00:01:10,640
+a non-functional requrement. Right? It has to do with the
+
+26
+00:01:10,640 --> 00:01:13,030
+speed of the elevator, which is a quality of the
+
+27
+00:01:13,030 --> 00:01:15,535
+elevator. But, it, it's not clear how such a requirement
+
+28
+00:01:15,535 --> 00:01:17,980
+could be satisfied. How could we tell whether the elevator
+
+29
+00:01:17,980 --> 00:01:20,000
+is fast or not. So, what we need to do
+
+30
+00:01:20,000 --> 00:01:22,390
+in these cases Is that we need to refine these
+
+31
+00:01:22,390 --> 00:01:25,300
+requirements so that they become verifiable. For the example that
+
+32
+00:01:25,300 --> 00:01:27,360
+I just mentioned, for instance, we might say that the
+
+33
+00:01:27,360 --> 00:01:30,730
+elevator must reach the requested floor in less than 30
+
+34
+00:01:30,730 --> 00:01:33,190
+seconds from the moment when the floor button is pushed.
+
+35
+00:01:33,190 --> 00:01:36,030
+This is still a non-functional requirment, but is a verifiable one.
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/2 - Interview with Jane Cleland-Huang - lang_en_vs5.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/2 - Interview with Jane Cleland-Huang - lang_en_vs5.srt
new file mode 100644
index 0000000..2a1bc1c
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/2 - Interview with Jane Cleland-Huang - lang_en_vs5.srt	
@@ -0,0 +1,411 @@
+1
+00:00:00,270 --> 00:00:02,800
+As we did for other lessons, before starting this
+
+2
+00:00:02,800 --> 00:00:06,150
+lesson on requirements engineering, I want to ask a world
+
+3
+00:00:06,150 --> 00:00:10,210
+expert on this topic a few questions. I'm here with
+
+4
+00:00:10,210 --> 00:00:14,150
+Jane Cleland-Huang, a professor at the DePaul University. And Jane
+
+5
+00:00:14,150 --> 00:00:16,500
+is a world expert in the area of requirements
+
+6
+00:00:16,500 --> 00:00:19,830
+engineering, which is the theme of this lesson. So I'm
+
+7
+00:00:19,830 --> 00:00:22,220
+talking to Jane who is currently in Chicago and I
+
+8
+00:00:22,220 --> 00:00:25,380
+want to. Ask her a few questions about requirements engineering.
+
+9
+00:00:25,380 --> 00:00:26,530
+So hi Jane how are you?
+
+10
+00:00:26,530 --> 00:00:27,990
+&gt;&gt; Fine. Thank you Alex.
+
+11
+00:00:27,990 --> 00:00:29,480
+&gt;&gt; And thank you so much for agreeing to
+
+12
+00:00:29,480 --> 00:00:31,960
+be interviewed for our course, I'm sure the students
+
+13
+00:00:31,960 --> 00:00:34,080
+will really benefit from this. And let me start
+
+14
+00:00:34,080 --> 00:00:37,240
+with the first question which is what are software requirements?
+
+15
+00:00:37,240 --> 00:00:40,900
+&gt;&gt; That's an interesting question. And software requirements
+
+16
+00:00:40,900 --> 00:00:44,220
+basically provide us a description of what a
+
+17
+00:00:44,220 --> 00:00:47,520
+system has to do. So, typically they describe
+
+18
+00:00:47,520 --> 00:00:50,550
+the functionality of the features. That the system has
+
+19
+00:00:50,550 --> 00:00:54,420
+to deliver in order to satisfy its stakeholders.
+
+20
+00:00:54,420 --> 00:00:59,010
+And we usually talk about the requirement specification
+
+21
+00:00:59,010 --> 00:01:01,050
+in terms of what the system's going to
+
+22
+00:01:01,050 --> 00:01:04,010
+do. And we describe it sometimes formally in
+
+23
+00:01:04,010 --> 00:01:07,300
+terms of set of shall statements, that the
+
+24
+00:01:07,300 --> 00:01:09,110
+system shall do this or shall do that.
+
+25
+00:01:09,110 --> 00:01:12,330
+Or we can use various templates to specify
+
+26
+00:01:12,330 --> 00:01:16,120
+both textural requirements. But requirements can also be represented
+
+27
+00:01:16,120 --> 00:01:20,790
+informally in, in the form of user stories, or use cases, or more
+
+28
+00:01:20,790 --> 00:01:26,180
+formally in the form of state transition diagrams and even in kind of
+
+29
+00:01:26,180 --> 00:01:32,260
+formal specifications. Especially for critical parts of safety critical systems.
+
+30
+00:01:32,260 --> 00:01:34,180
+&gt;&gt; And another should discuss what the
+
+31
+00:01:34,180 --> 00:01:37,230
+requirements are. What is the requirements engineering?
+
+32
+00:01:37,230 --> 00:01:41,180
+&gt;&gt; So, that's also an interesting question because if you notice
+
+33
+00:01:41,180 --> 00:01:45,330
+it's it's engineering and I'm sure in the
+
+34
+00:01:45,330 --> 00:01:47,750
+other parts of the software engineering process that
+
+35
+00:01:47,750 --> 00:01:51,130
+you're discussing in your course. Parts such as
+
+36
+00:01:51,130 --> 00:01:55,200
+testing or coding. They don't have the word engineering
+
+37
+00:01:55,200 --> 00:01:56,930
+there and I think one of the reasons
+
+38
+00:01:56,930 --> 00:02:00,310
+requirements engineering has that term is because it covers
+
+39
+00:02:00,310 --> 00:02:03,570
+a number of different activities. So it includes
+
+40
+00:02:03,570 --> 00:02:07,390
+things such as working with stakeholders to elicit or
+
+41
+00:02:07,390 --> 00:02:10,620
+to proactively discover what their requirements of the
+
+42
+00:02:10,620 --> 00:02:14,440
+system are. Analyzing those requirements so that we
+
+43
+00:02:14,440 --> 00:02:17,380
+understand the tradeoffs. So you might have different
+
+44
+00:02:17,380 --> 00:02:21,170
+stakeholders that care about different things, and it
+
+45
+00:02:21,170 --> 00:02:26,086
+might not be possible to deliver all of those things, so we have to analyze the
+
+46
+00:02:26,086 --> 00:02:29,140
+feasibility of the requirements, explore the tradeoffs, emerge
+
+47
+00:02:29,140 --> 00:02:32,550
+conflicts. And then of course the specification part,
+
+48
+00:02:32,550 --> 00:02:34,930
+which we talked about a little bit already,
+
+49
+00:02:34,930 --> 00:02:37,340
+and the validation, so did we in fact get
+
+50
+00:02:37,340 --> 00:02:40,480
+the requirements right? Did we build a system
+
+51
+00:02:40,480 --> 00:02:43,490
+that actually matches our, our requirements. And then on
+
+52
+00:02:43,490 --> 00:02:46,960
+into the requirements management process. And the requirements
+
+53
+00:02:46,960 --> 00:02:50,860
+management process. Kind of like goes through things like
+
+54
+00:02:50,860 --> 00:02:55,010
+change management. So what if customer or stakeholders
+
+55
+00:02:55,010 --> 00:02:57,630
+need the system to change? How do we manage
+
+56
+00:02:57,630 --> 00:03:00,180
+changing requirements? And I think this is one of
+
+57
+00:03:00,180 --> 00:03:03,230
+the reasons that we've coined the term engineering because
+
+58
+00:03:03,230 --> 00:03:06,490
+that it's, has to be a systematic process which
+
+59
+00:03:06,490 --> 00:03:09,550
+extends across. The whole of this is life cycle.
+
+60
+00:03:09,550 --> 00:03:12,890
+&gt;&gt; And I guess my last question here is
+
+61
+00:03:12,890 --> 00:03:15,100
+so now that we heard about software requirements and
+
+62
+00:03:15,100 --> 00:03:18,790
+about software requirements engineering, why is requirements engineering so
+
+63
+00:03:18,790 --> 00:03:20,770
+important? So what happens if we don't do it right?
+
+64
+00:03:20,770 --> 00:03:22,620
+&gt;&gt; Well, I'm sure that, you know,
+
+65
+00:03:22,620 --> 00:03:24,880
+many people have probably read the kind of
+
+66
+00:03:24,880 --> 00:03:28,560
+report like Spanish report, and other reports of failed
+
+67
+00:03:28,560 --> 00:03:31,900
+project, and things like that, and are aware that
+
+68
+00:03:31,900 --> 00:03:35,280
+one of the major reasons for projects failing
+
+69
+00:03:35,280 --> 00:03:37,360
+is because we didn't get the requirements right
+
+70
+00:03:37,360 --> 00:03:40,110
+in the first place. So if we don't understand
+
+71
+00:03:40,110 --> 00:03:42,970
+the requirements then we're simply going to build the
+
+72
+00:03:42,970 --> 00:03:47,960
+wrong system. Getting requirements right includes all sorts of
+
+73
+00:03:47,960 --> 00:03:52,900
+things such as finding the right group of stakeholders so we don't exclude major
+
+74
+00:03:52,900 --> 00:03:56,940
+groups of stakeholders. Understanding the requirements correctly.
+
+75
+00:03:56,940 --> 00:03:59,910
+There will be many, many different examples of
+
+76
+00:03:59,910 --> 00:04:02,310
+projects that have failed. For example, in
+
+77
+00:04:02,310 --> 00:04:06,500
+America the healthcare.gov failure, and while we cannot
+
+78
+00:04:06,500 --> 00:04:09,540
+put the blame squarely in the area
+
+79
+00:04:09,540 --> 00:04:13,040
+of requirements, because obviously the project was challenged
+
+80
+00:04:13,040 --> 00:04:15,650
+for a number of different reasons. But
+
+81
+00:04:15,650 --> 00:04:21,070
+clearly it underperformed in many respects related to
+
+82
+00:04:21,070 --> 00:04:25,740
+security, performance, and reliability and these are all
+
+83
+00:04:25,740 --> 00:04:28,300
+parts of the requirements process. Things that should
+
+84
+00:04:28,300 --> 00:04:30,000
+have been discovered and the system should have
+
+85
+00:04:30,000 --> 00:04:32,914
+been built in order to meet those requirements,
+
+86
+00:04:32,914 --> 00:04:36,240
+getting the requirements right in the first place.
+
+87
+00:04:36,240 --> 00:04:38,110
+Puts us, a project on the right foot.
+
+88
+00:04:38,110 --> 00:04:41,430
+And so that gives us a much better chance
+
+89
+00:04:41,430 --> 00:04:44,940
+of delivering to the customer what they need. And
+
+90
+00:04:44,940 --> 00:04:49,130
+designing a solution that really meets those requirements. So,
+
+91
+00:04:49,130 --> 00:04:52,800
+it's a critical part of the overall software engineering success.
+
+92
+00:04:52,800 --> 00:04:56,441
+&gt;&gt; Okay. So that's critical. I mean, we better get our requirements right.
+
+93
+00:04:56,441 --> 00:04:56,987
+&gt;&gt; Yeah.
+
+94
+00:04:56,987 --> 00:04:57,733
+&gt;&gt; That's, that's the message.
+
+95
+00:04:57,733 --> 00:04:57,743
+&gt;&gt; Yeah.
+
+96
+00:04:57,743 --> 00:05:00,822
+&gt;&gt; Okay. Well, thank you so much Jane, for taking
+
+97
+00:05:00,822 --> 00:05:03,435
+the time off your busy schedule to speak with us.
+
+98
+00:05:03,435 --> 00:05:07,150
+I'm sure. The students really appreciate this, and we'll talk to you soon.
+
+99
+00:05:07,150 --> 00:05:08,480
+&gt;&gt; Bye Alex, thank you.
+
+100
+00:05:08,480 --> 00:05:10,890
+&gt;&gt; Bye, Jane, bye bye. Jane gave
+
+101
+00:05:10,890 --> 00:05:13,410
+us an interesting perspective on requirements engineering
+
+102
+00:05:13,410 --> 00:05:15,410
+and its importance. Let's now start our
+
+103
+00:05:15,410 --> 00:05:18,050
+lesson with a general definition of requirements engineering.
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/20 - User and System Requirements - lang_en_vs4.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/20 - User and System Requirements - lang_en_vs4.srt
new file mode 100644
index 0000000..2da3f58
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/20 - User and System Requirements - lang_en_vs4.srt	
@@ -0,0 +1,111 @@
+1
+00:00:00,180 --> 00:00:03,170
+Another important distinction, when talking about requirements, is that
+
+2
+00:00:03,170 --> 00:00:07,220
+between user and system requirements. So, let's start with defining
+
+3
+00:00:07,220 --> 00:00:10,540
+user requirements. Those are requirements that are written for the
+
+4
+00:00:10,540 --> 00:00:13,400
+customers and they're often in natural language and they don't
+
+5
+00:00:13,400 --> 00:00:16,190
+contain technical details. And the reason for that is
+
+6
+00:00:16,190 --> 00:00:19,740
+that their purpose is to allow customers, stakeholders, to check
+
+7
+00:00:19,740 --> 00:00:22,210
+that the system will do what they intended. So it's
+
+8
+00:00:22,210 --> 00:00:25,470
+a way for the analyst, the developers, to communicate with
+
+9
+00:00:25,470 --> 00:00:28,460
+the customers, with the stakeholders. System requirements, on the
+
+10
+00:00:28,460 --> 00:00:32,560
+other hand, are written for developers. Contain detailed functional and
+
+11
+00:00:32,560 --> 00:00:35,330
+non functional requirements. Which we just discussed, and which
+
+12
+00:00:35,330 --> 00:00:39,860
+are clearly and more rigourously specified than the user requirements.
+
+13
+00:00:39,860 --> 00:00:42,130
+And the reason for this difference is that the
+
+14
+00:00:42,130 --> 00:00:45,410
+purpose of the system requirements is to tell developers what
+
+15
+00:00:45,410 --> 00:00:47,870
+to build. They must contain enough details so the
+
+16
+00:00:47,870 --> 00:00:50,480
+developers can take them and use them to design and
+
+17
+00:00:50,480 --> 00:00:52,530
+then develop a system. Just to give you a concrete
+
+18
+00:00:52,530 --> 00:00:55,750
+example, here I'm showing you a user requirement that just says
+
+19
+00:00:55,750 --> 00:00:59,510
+that the software must provide a means of representing and accessing
+
+20
+00:00:59,510 --> 00:01:03,940
+external files created by other tools, and the corresponding system requirement.
+
+21
+00:01:03,940 --> 00:01:05,700
+And as you can see, even if we don't read the
+
+22
+00:01:05,700 --> 00:01:09,380
+whole requirements. The former is an informal and high level description
+
+23
+00:01:09,380 --> 00:01:12,210
+of a piece of functionality, whereas the latter describes the same
+
+24
+00:01:12,210 --> 00:01:15,940
+functionality but in a much more extensive and rigorous way. As
+
+25
+00:01:15,940 --> 00:01:18,760
+I said, this is something that the developers can use to
+
+26
+00:01:18,760 --> 00:01:21,820
+design and then build a system whereas this is something that
+
+27
+00:01:21,820 --> 00:01:25,590
+can be used to communicate. With the stakeholders, with a non-technical
+
+28
+00:01:25,590 --> 00:01:29,490
+audience. And we need to define both because they serve different purposes.
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/21 - Requirements Quiz - lang_en_vs4.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/21 - Requirements Quiz - lang_en_vs4.srt
new file mode 100644
index 0000000..4b416e8
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/21 - Requirements Quiz - lang_en_vs4.srt	
@@ -0,0 +1,43 @@
+1
+00:00:00,160 --> 00:00:02,940
+After all these talking about requirements, let's have a small quiz, I
+
+2
+00:00:02,940 --> 00:00:04,019
+want to ask you which of the
+
+3
+00:00:04,019 --> 00:00:07,840
+following requirements are non-functional requirements? And here
+
+4
+00:00:07,840 --> 00:00:10,860
+I'm listing the requirements, the first one says at the BowlingAlley program
+
+5
+00:00:10,860 --> 00:00:13,420
+keeps track of the score during a game, the second one is that
+
+6
+00:00:13,420 --> 00:00:16,720
+the WordCount program should be able to process large files. The third
+
+7
+00:00:16,720 --> 00:00:19,580
+one is that the Login program for a website. Should be secure, and
+
+8
+00:00:19,580 --> 00:00:22,880
+finally the last one says that the vending machine program should take coins
+
+9
+00:00:22,880 --> 00:00:25,430
+as an input from the user. So, I want you to mark all
+
+10
+00:00:25,430 --> 00:00:27,590
+the ones that are non-functional requirements, that
+
+11
+00:00:27,590 --> 00:00:29,640
+don't refer to the functionality of the system.
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/22 - Requirements Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/22 - Requirements Quiz Solution - lang_en_vs4.srt
new file mode 100644
index 0000000..e957484
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/22 - Requirements Quiz Solution - lang_en_vs4.srt	
@@ -0,0 +1,63 @@
+1
+00:00:00,120 --> 00:00:03,710
+So, the first requirement clearly refers to some specific functionality of
+
+2
+00:00:03,710 --> 00:00:07,230
+the Bowling Alley system, because it talks about what the system has
+
+3
+00:00:07,230 --> 00:00:10,420
+to do from a functional standpoint. So, it's definitely not a non-functional
+
+4
+00:00:10,420 --> 00:00:13,400
+requirement. On the other hand, the fact that the Word Count system
+
+5
+00:00:13,400 --> 00:00:16,320
+should be able to process large files, is telling us something not
+
+6
+00:00:16,320 --> 00:00:19,580
+about the functionality of the system, but rather about its qualities. The
+
+7
+00:00:19,580 --> 00:00:21,600
+fact that it has to be scalable, that it has to be
+
+8
+00:00:21,600 --> 00:00:25,190
+efficient and so we can consider this to be a non-functional requirement.
+
+9
+00:00:25,190 --> 00:00:27,010
+Similarly, the fact that the Login program for a
+
+10
+00:00:27,010 --> 00:00:29,390
+website should be secure is definitely telling us something
+
+11
+00:00:29,390 --> 00:00:31,800
+about the quality of the system that has little
+
+12
+00:00:31,800 --> 00:00:34,026
+to do with its functionality. And so this is
+
+13
+00:00:34,026 --> 00:00:36,680
+also a non-functional requirement. Finally, the fact that the
+
+14
+00:00:36,680 --> 00:00:38,980
+Vending Machine program should take coins as an input
+
+15
+00:00:38,980 --> 00:00:41,010
+from the user is telling us something about the
+
+16
+00:00:41,010 --> 00:00:44,100
+functionality of the program and therefore, is a functional requirement.
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/23 - Requirement Origins - lang_en_vs4.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/23 - Requirement Origins - lang_en_vs4.srt
new file mode 100644
index 0000000..6fe4931
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/23 - Requirement Origins - lang_en_vs4.srt	
@@ -0,0 +1,71 @@
+1
+00:00:00,130 --> 00:00:01,880
+Now that we know what the requirements are and
+
+2
+00:00:01,880 --> 00:00:05,520
+their main types, let's discuss where requirements come from and
+
+3
+00:00:05,520 --> 00:00:08,610
+there are many possible sources for requirements so I'm
+
+4
+00:00:08,610 --> 00:00:10,610
+going to list here the main ones. The first one are
+
+5
+00:00:10,610 --> 00:00:14,440
+clearly stakeholders, anybody who is effected by the system
+
+6
+00:00:14,440 --> 00:00:18,830
+and its functionality. Customers, users, and so on. The second
+
+7
+00:00:18,830 --> 00:00:22,610
+typical social requirement is the application domain. For example,
+
+8
+00:00:22,610 --> 00:00:25,380
+the fact that my software is running within a bank,
+
+9
+00:00:25,380 --> 00:00:27,930
+or within a school. Why is the application domain a
+
+10
+00:00:27,930 --> 00:00:31,410
+social requirement? Well, because there are constraints that are characteristics
+
+11
+00:00:31,410 --> 00:00:34,140
+of the application domain that will affect the functionality of
+
+12
+00:00:34,140 --> 00:00:37,130
+the system. For a simple example, just think about regulations.
+
+13
+00:00:37,130 --> 00:00:40,400
+So banking regulations and school regulations in these cases. Those
+
+14
+00:00:40,400 --> 00:00:43,120
+are things that might affect the functionality of my system
+
+15
+00:00:43,120 --> 00:00:45,570
+and, therefore, that may become part of my requirements. And,
+
+16
+00:00:45,570 --> 00:00:50,120
+finally, documentation can be an additional source of requirements. For example,
+
+17
+00:00:50,120 --> 00:00:54,110
+notes, papers, manuals, books. So everything that refers to
+
+18
+00:00:54,110 --> 00:00:56,610
+the functionality of the system that we're going to build.
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/24 - Elicitation Problems - lang_en_vs4.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/24 - Elicitation Problems - lang_en_vs4.srt
new file mode 100644
index 0000000..2d81db7
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/24 - Elicitation Problems - lang_en_vs4.srt	
@@ -0,0 +1,179 @@
+1
+00:00:00,190 --> 00:00:03,440
+Unfortunately, extracting requirements from these sources is not
+
+2
+00:00:03,440 --> 00:00:06,220
+a straightforward task, as there are many issues involved
+
+3
+00:00:06,220 --> 00:00:09,470
+with the requirements elicitation. One first problem is the
+
+4
+00:00:09,470 --> 00:00:13,930
+thin spread of domain knowledge. Knowledge is rarely available
+
+5
+00:00:13,930 --> 00:00:15,970
+in an explicit form, that is, it is
+
+6
+00:00:15,970 --> 00:00:20,310
+almost never written down. Moreover, knowledge is often distributed
+
+7
+00:00:20,310 --> 00:00:23,410
+across many sources. For example, in the graphical depiction
+
+8
+00:00:23,410 --> 00:00:25,590
+here, to find out that this is the purpose
+
+9
+00:00:25,590 --> 00:00:28,240
+of the project. The developer, the analyist, needs to talk
+
+10
+00:00:28,240 --> 00:00:30,870
+to a lot of different people. And, to make things even
+
+11
+00:00:30,870 --> 00:00:34,400
+worse. There are often conflicts between the knowledge gathered from
+
+12
+00:00:34,400 --> 00:00:37,610
+different sources. A second issue is the fact that the knowledge
+
+13
+00:00:37,610 --> 00:00:41,090
+is often tacit. What is also called the say, do
+
+14
+00:00:41,090 --> 00:00:44,052
+problem. In the example shown here. For instance. We have a
+
+15
+00:00:44,052 --> 00:00:47,650
+customer that is describing to the analyst. The way in which
+
+16
+00:00:47,650 --> 00:00:51,060
+he accomplishes a task. So it performs these three steps and
+
+17
+00:00:51,060 --> 00:00:54,300
+reaches the goal. Whereas in practice, the actual way in
+
+18
+00:00:54,300 --> 00:00:57,530
+which this task accomplished is by going through a larger number
+
+19
+00:00:57,530 --> 00:00:59,880
+of steps to get to the same goal. So the point
+
+20
+00:00:59,880 --> 00:01:02,650
+here is that, even if the knowledge were more concentrated, so
+
+21
+00:01:02,650 --> 00:01:05,660
+not as spread as in this example. People simply find
+
+22
+00:01:05,660 --> 00:01:08,680
+it hard to describe knowledge that they regularly use. So it
+
+23
+00:01:08,680 --> 00:01:11,740
+is hard to make this knowledge explicit, to pass this knowledge
+
+24
+00:01:11,740 --> 00:01:13,130
+to someone else. Yet another
+
+25
+00:01:13,130 --> 00:01:16,690
+problem is limited observability. Identifying requirements
+
+26
+00:01:16,690 --> 00:01:20,570
+through observation is often difficult as the problem owners might be
+
+27
+00:01:20,570 --> 00:01:23,550
+too busy to perform the task that we need to observe.
+
+28
+00:01:23,550 --> 00:01:25,750
+Or they might be doing a lot of other things together
+
+29
+00:01:25,750 --> 00:01:27,980
+with the task that we need to observe, so that becomes
+
+30
+00:01:27,980 --> 00:01:31,530
+confusing. That introduces noise. Moreover, even when this is not the
+
+31
+00:01:31,530 --> 00:01:34,460
+case, the presence of an observer might change their problem. It
+
+32
+00:01:34,460 --> 00:01:38,020
+is very typical for human subjects to improve or modify an
+
+33
+00:01:38,020 --> 00:01:41,760
+aspect of their behavior, which is being experimentally measured in response
+
+34
+00:01:41,760 --> 00:01:44,110
+to the fact that they know that they're being studied. You know
+
+35
+00:01:44,110 --> 00:01:47,110
+that somebody's studying you and you change the way in which you behave.
+
+36
+00:01:47,110 --> 00:01:50,910
+A typical issue. Finally, the information that we collect might be biased.
+
+37
+00:01:50,910 --> 00:01:54,270
+For several reasons. People might not feel free to tell you what you
+
+38
+00:01:54,270 --> 00:01:57,030
+need to know. Or, people might not want to tell you what
+
+39
+00:01:57,030 --> 00:02:00,240
+you need to know. For example, in all the common cases in which
+
+40
+00:02:00,240 --> 00:02:03,870
+the outcome might effect them, people might provide you a different picture
+
+41
+00:02:03,870 --> 00:02:06,770
+from the real one. In order to influence you. So, they might have
+
+42
+00:02:06,770 --> 00:02:08,820
+a hidden agenda, and mislead you, either
+
+43
+00:02:08,820 --> 00:02:11,860
+consciously or unconsciously. So, all these issues
+
+44
+00:02:11,860 --> 00:02:14,370
+add to the complexity of collecting requirements,
+
+45
+00:02:14,370 --> 00:02:16,522
+of identifying the purpose of a system.
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/25 - Traditional Techniques - lang_en_vs5.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/25 - Traditional Techniques - lang_en_vs5.srt
new file mode 100644
index 0000000..cc58665
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/25 - Traditional Techniques - lang_en_vs5.srt	
@@ -0,0 +1,207 @@
+1
+00:00:00,140 --> 00:00:02,930
+To cover the intrinsic problem of eliciting requirements,
+
+2
+00:00:02,930 --> 00:00:05,670
+many different techniques have been proposed. So here
+
+3
+00:00:05,670 --> 00:00:08,260
+I list some of most traditional techniques for
+
+4
+00:00:08,260 --> 00:00:11,290
+requirement elicitation and as I present those, please keep
+
+5
+00:00:11,290 --> 00:00:13,140
+in mind that these techniques can be used
+
+6
+00:00:13,140 --> 00:00:17,230
+separately or combined. A first technique is called background
+
+7
+00:00:17,230 --> 00:00:20,740
+reading. And, this technique involves collecting information by
+
+8
+00:00:20,740 --> 00:00:24,840
+reading existing documents such as company reports, organizational charts,
+
+9
+00:00:24,840 --> 00:00:29,280
+policy manuals, job descriptions, documentation of existing systems and so
+
+10
+00:00:29,280 --> 00:00:32,400
+on. And, this technique is especially appropriate when one Is
+
+11
+00:00:32,400 --> 00:00:35,370
+not familiar with your organization for which the requirements are
+
+12
+00:00:35,370 --> 00:00:38,950
+being collected. So you want to get some background before interviewing
+
+13
+00:00:38,950 --> 00:00:41,240
+actual people. And one of the main imitations of these
+
+14
+00:00:41,240 --> 00:00:43,930
+kinds of approaches is that written documents might be out
+
+15
+00:00:43,930 --> 00:00:46,320
+of sync and they often are out of sync with
+
+16
+00:00:46,320 --> 00:00:49,970
+reality. Tend to be long winded. It may contain many irrelevant
+
+17
+00:00:49,970 --> 00:00:51,850
+details, so you may have to look at a lot
+
+18
+00:00:51,850 --> 00:00:54,810
+of materials to extract enough information. The hard data and
+
+19
+00:00:54,810 --> 00:00:58,650
+samples techniques consist in deciding which hard data we want
+
+20
+00:00:58,650 --> 00:01:01,680
+to collect and choosing the sample of the population for which
+
+21
+00:01:01,680 --> 00:01:04,750
+to collect such data and hard data includes facts and
+
+22
+00:01:04,750 --> 00:01:09,790
+figures such as forms, invoices, financial information, survey results, marketing
+
+23
+00:01:09,790 --> 00:01:12,300
+data, and so on. And the sampling of this data
+
+24
+00:01:12,300 --> 00:01:15,170
+can be done in different ways. For example, the typical ways
+
+25
+00:01:15,170 --> 00:01:19,200
+to do random selection. Interviews are another typical approach for
+
+26
+00:01:19,200 --> 00:01:21,870
+requirement solicitation, and this is the approach that we use for
+
+27
+00:01:21,870 --> 00:01:24,910
+the first project in this course, for instance. Interviews can be
+
+28
+00:01:24,910 --> 00:01:27,720
+structured in which case there is an agenda of fairly open
+
+29
+00:01:27,720 --> 00:01:30,450
+questions or they can be open ended in which case there
+
+30
+00:01:30,450 --> 00:01:32,770
+is no preset agenda and the interview is more of a
+
+31
+00:01:32,770 --> 00:01:36,500
+conversation. On the positive side, interviews can collect a rich set
+
+32
+00:01:36,500 --> 00:01:40,260
+of information because they allow for uncovering opinions as well as
+
+33
+00:01:40,260 --> 00:01:43,230
+hard facts. Moreover, they can probe in depth through follow
+
+34
+00:01:43,230 --> 00:01:46,790
+up questions. On the more negative side, interviewing requires special
+
+35
+00:01:46,790 --> 00:01:50,400
+skills that are difficult to master and require experience. And
+
+36
+00:01:50,400 --> 00:01:52,890
+it is not enough to collect a lot of information. If
+
+37
+00:01:52,890 --> 00:01:55,520
+this information is hard to analyze or even irrelevant, it
+
+38
+00:01:55,520 --> 00:01:58,250
+might become useless. So you need to know how to conduct
+
+39
+00:01:58,250 --> 00:02:01,180
+an interview in order to take advantage of these techniques.
+
+40
+00:02:01,180 --> 00:02:05,440
+Surveys can also be extremely useful for gathering new requirements because
+
+41
+00:02:05,440 --> 00:02:08,550
+they can quickly collect information from a large number
+
+42
+00:02:08,550 --> 00:02:11,520
+of people. Moreover, they can be administered remotely. For
+
+43
+00:02:11,520 --> 00:02:13,610
+example, by email, through the web. On the other
+
+44
+00:02:13,610 --> 00:02:16,750
+hand, surveys tend to severely constrain the information that
+
+45
+00:02:16,750 --> 00:02:19,430
+the user can provide and might miss opportunities to
+
+46
+00:02:19,430 --> 00:02:24,460
+collect unforeseen, relevant information. Finally, meetings are generally used
+
+47
+00:02:24,460 --> 00:02:27,690
+for summarization of findings and collection of feedback, so as
+
+48
+00:02:27,690 --> 00:02:30,500
+to confirm or refute what has been learned. So the
+
+49
+00:02:30,500 --> 00:02:32,660
+only additional thing I want to mention about meetings
+
+50
+00:02:32,660 --> 00:02:34,920
+is the fact that it is fundamental that have clearly
+
+51
+00:02:34,920 --> 00:02:37,970
+stated objectives and are planned carefully. This is something that
+
+52
+00:02:37,970 --> 00:02:40,730
+should be quite obvious, but doesn't always happen in practice.
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/26 - Other Techniques - lang_en_vs5.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/26 - Other Techniques - lang_en_vs5.srt
new file mode 100644
index 0000000..f29fb9c
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/26 - Other Techniques - lang_en_vs5.srt	
@@ -0,0 +1,71 @@
+1
+00:00:00,070 --> 00:00:02,370
+So just for completeness, I want to mention some other
+
+2
+00:00:02,370 --> 00:00:05,340
+techniques besides the traditional ones that we just saw that
+
+3
+00:00:05,340 --> 00:00:07,880
+can be used for requirements solicitation. And these other
+
+4
+00:00:07,880 --> 00:00:10,740
+techniques can be divided in three main groups. There are
+
+5
+00:00:10,740 --> 00:00:14,820
+collaborative techniques that were created to support incremental development
+
+6
+00:00:14,820 --> 00:00:18,850
+of complex systems with large diverse user populations. An example
+
+7
+00:00:18,850 --> 00:00:21,130
+of such techniques which is widely used and you
+
+8
+00:00:21,130 --> 00:00:25,120
+might know is brainstorming. There are also social approaches and
+
+9
+00:00:25,120 --> 00:00:28,140
+these are approaches, techniques that exploit the social
+
+10
+00:00:28,140 --> 00:00:31,520
+sciences to better collect information from the stakeholders and
+
+11
+00:00:31,520 --> 00:00:34,310
+the environment. And among those I just want to mention
+
+12
+00:00:34,310 --> 00:00:36,730
+ethnographic techniques which are based on the idea of
+
+13
+00:00:36,730 --> 00:00:40,100
+collecting information on the participants by observing them
+
+14
+00:00:40,100 --> 00:00:44,660
+in their original environment. Finally cognitive techniques, leverage cognitive
+
+15
+00:00:44,660 --> 00:00:48,490
+science approaches to discover expert knowledge for example they
+
+16
+00:00:48,490 --> 00:00:51,260
+can be used to understand the problem solving methods.
+
+17
+00:00:51,260 --> 00:00:54,000
+And in case you're interested in finding out more about this and
+
+18
+00:00:54,000 --> 00:00:57,580
+other techniques, I'm providing some references in the notes for the lesson.
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/27 - Modeling Requirements - lang_en_vs4.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/27 - Modeling Requirements - lang_en_vs4.srt
new file mode 100644
index 0000000..d4ade17
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/27 - Modeling Requirements - lang_en_vs4.srt	
@@ -0,0 +1,223 @@
+1
+00:00:00,220 --> 00:00:03,550
+Once we collected the required knowledge on the requirements for
+
+2
+00:00:03,550 --> 00:00:06,120
+the system that we're developing, we need to model it in
+
+3
+00:00:06,120 --> 00:00:08,430
+a structured and clear way, so that it can be
+
+4
+00:00:08,430 --> 00:00:12,100
+analyzed and refined. And there are really tons of ways to
+
+5
+00:00:12,100 --> 00:00:15,840
+do that, depending on your focus and objectives. More specifically,
+
+6
+00:00:15,840 --> 00:00:18,940
+when modeling requirements you need to decide what you want to
+
+7
+00:00:18,940 --> 00:00:21,710
+model and how you want to model it. So let's look
+
+8
+00:00:21,710 --> 00:00:25,390
+at these two aspects independently. What you decide to model depends
+
+9
+00:00:25,390 --> 00:00:28,270
+on where your emphasis is. That is on which
+
+10
+00:00:28,270 --> 00:00:31,390
+aspects of the requirements you want to focus. For
+
+11
+00:00:31,390 --> 00:00:34,880
+example if your emphasis is on the characteristics of
+
+12
+00:00:34,880 --> 00:00:37,970
+the enterprise of the company that you are analyzing you
+
+13
+00:00:37,970 --> 00:00:40,240
+may want to model goals and objectives of the
+
+14
+00:00:40,240 --> 00:00:44,380
+company, or its organizational structure, its task and dependencies
+
+15
+00:00:44,380 --> 00:00:47,040
+and so on. Conversely, if your focus is on
+
+16
+00:00:47,040 --> 00:00:50,500
+information and behaviors, you might want to concentrate on aspects
+
+17
+00:00:50,500 --> 00:00:53,800
+such as the structure of information, various behavioral views
+
+18
+00:00:53,800 --> 00:00:55,480
+some of which we will see in the next
+
+19
+00:00:55,480 --> 00:00:59,650
+lesson, or maybe time or sequencing requirements. Finally, if
+
+20
+00:00:59,650 --> 00:01:02,750
+you're mostly interested in the quality aspects of your
+
+21
+00:01:02,750 --> 00:01:06,790
+system, you will focus on the various non-functional properties
+
+22
+00:01:06,790 --> 00:01:09,070
+of the software that are relevant in the context
+
+23
+00:01:09,070 --> 00:01:13,570
+considered. For example reliability, robustness, security, and so on.
+
+24
+00:01:13,570 --> 00:01:15,550
+You will just pick the ones that are relevant for
+
+25
+00:01:15,550 --> 00:01:18,540
+your context. And as we said, there's a second dimension.
+
+26
+00:01:18,540 --> 00:01:21,050
+After you have decided what to model in your system,
+
+27
+00:01:21,050 --> 00:01:23,480
+you have to decide how you want to model it.
+
+28
+00:01:23,480 --> 00:01:25,860
+So I want to show here some options for modeling
+
+29
+00:01:25,860 --> 00:01:30,380
+enterprises, information, and quality aspects. And as you can see
+
+30
+00:01:30,380 --> 00:01:34,100
+here for each type of information there are many possible
+
+31
+00:01:34,100 --> 00:01:36,840
+models that we can use to represent it. And all
+
+32
+00:01:36,840 --> 00:01:38,750
+these models have advantages and
+
+33
+00:01:38,750 --> 00:01:41,400
+disadvantages, different levels of formality and
+
+34
+00:01:41,400 --> 00:01:44,000
+different focus. Something else that I want to point out
+
+35
+00:01:44,000 --> 00:01:47,145
+about these models is the fact that these models are often
+
+36
+00:01:47,145 --> 00:01:50,980
+orthogonal to one another, especially if we consider models in different
+
+37
+00:01:50,980 --> 00:01:54,620
+categories. So what that means is that they're complimentary rather than
+
+38
+00:01:54,620 --> 00:01:58,310
+mutually exclusive. Different models can be used to provide views
+
+39
+00:01:58,310 --> 00:02:01,290
+of the requirements from different perspectives, and we will not see
+
+40
+00:02:01,290 --> 00:02:03,700
+most of these models in this course, but I wanted to
+
+41
+00:02:03,700 --> 00:02:06,550
+list them anyways to give you an idea of how many
+
+42
+00:02:06,550 --> 00:02:09,490
+there are and how vast is this area. As far
+
+43
+00:02:09,490 --> 00:02:11,540
+as we are concerned in the course and for the
+
+44
+00:02:11,540 --> 00:02:14,660
+projects we will express requirements using one of two main
+
+45
+00:02:14,660 --> 00:02:19,010
+ways. Using natural language, that is informal specifications and using
+
+46
+00:02:19,010 --> 00:02:22,600
+UML diagrams, which is graphical models. And we will introduce
+
+47
+00:02:22,600 --> 00:02:25,840
+UML and the most important diagrams in the next lesson.
+
+48
+00:02:25,840 --> 00:02:27,330
+And the only other type of models that I want
+
+49
+00:02:27,330 --> 00:02:31,610
+to mentions explicitly are goal models because they're extremely popular.
+
+50
+00:02:31,610 --> 00:02:34,930
+So the main idea with goal models is it start with the main goal of
+
+51
+00:02:34,930 --> 00:02:36,990
+the system and then keep refining it
+
+52
+00:02:36,990 --> 00:02:39,654
+by decomposing it in sub-goals. So it's kind
+
+53
+00:02:39,654 --> 00:02:41,610
+of a very natural way of progressing.
+
+54
+00:02:41,610 --> 00:02:44,210
+And you continue this refinement until you get
+
+55
+00:02:44,210 --> 00:02:47,150
+to goals that can be operationalized, and represent
+
+56
+00:02:47,150 --> 00:02:49,380
+the basic units of functionality of the system.
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/28 - Analyzing Requirements - lang_en_vs4.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/28 - Analyzing Requirements - lang_en_vs4.srt
new file mode 100644
index 0000000..c7d4899
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/28 - Analyzing Requirements - lang_en_vs4.srt	
@@ -0,0 +1,155 @@
+1
+00:00:00,250 --> 00:00:01,940
+Now we are at the point in which we
+
+2
+00:00:01,940 --> 00:00:05,590
+have collected and modeled our requirements. So the next thing
+
+3
+00:00:05,590 --> 00:00:08,310
+that we can do is to analyze the requirements to
+
+4
+00:00:08,310 --> 00:00:11,720
+identify possible problems, and specifically there are three types of
+
+5
+00:00:11,720 --> 00:00:14,646
+analysis that we can perform. The first type of analysis
+
+6
+00:00:14,646 --> 00:00:16,820
+is verification. So in this case we're talking about the
+
+7
+00:00:16,820 --> 00:00:19,700
+requirements verification. And in verification
+
+8
+00:00:19,700 --> 00:00:21,990
+developers will study the requirements
+
+9
+00:00:21,990 --> 00:00:25,270
+to check whether they're correct, whether they accurately reflect the
+
+10
+00:00:25,270 --> 00:00:28,710
+customer needs as perceived by the developer. Developers can
+
+11
+00:00:28,710 --> 00:00:32,170
+also check the completeness of the requirements, check whether there
+
+12
+00:00:32,170 --> 00:00:34,510
+are any missing pieces in the requirements as we
+
+13
+00:00:34,510 --> 00:00:37,710
+discussed earlier. They can check whether the requirements are pertinent,
+
+14
+00:00:37,710 --> 00:00:41,260
+or contain irrelevant information, like the one shown here.
+
+15
+00:00:41,260 --> 00:00:44,670
+And they can also check whether they're consistent, unambiguous, testable
+
+16
+00:00:44,670 --> 00:00:46,920
+and so on, so all those properties that should
+
+17
+00:00:46,920 --> 00:00:50,380
+be satisfied for the requirements. A second type of analysis
+
+18
+00:00:50,380 --> 00:00:53,670
+that is typically performed on requirements is validation. And
+
+19
+00:00:53,670 --> 00:00:56,290
+the goal of validation is to assess whether the collected
+
+20
+00:00:56,290 --> 00:00:59,870
+requirements define the system that the stakeholders really want.
+
+21
+00:00:59,870 --> 00:01:02,330
+So the focus here is on the stakeholders. And in
+
+22
+00:01:02,330 --> 00:01:05,670
+some cases, stakeholders can check the requirements directly if
+
+23
+00:01:05,670 --> 00:01:08,910
+the requirements are expressed in a notation that they understand.
+
+24
+00:01:08,910 --> 00:01:11,120
+Or they might check them by discussing them with the
+
+25
+00:01:11,120 --> 00:01:15,490
+developers. Another possibility is that stakeholders asses the requirements by
+
+26
+00:01:15,490 --> 00:01:18,400
+interacting with a prototype of the system, in case
+
+27
+00:01:18,400 --> 00:01:21,690
+the requirements engineering process that is being used involves
+
+28
+00:01:21,690 --> 00:01:25,300
+early prototyping. And finally surveys, testing, and other techniques
+
+29
+00:01:25,300 --> 00:01:28,400
+can also be used to validate requirements. A final type
+
+30
+00:01:28,400 --> 00:01:30,780
+of analysis that we can perform on requirements is
+
+31
+00:01:30,780 --> 00:01:34,430
+risk analysis. And risk analysis aims to identify and
+
+32
+00:01:34,430 --> 00:01:37,680
+analyze the main risks involved with the development of
+
+33
+00:01:37,680 --> 00:01:40,560
+the system being considered. And if some requirements are deemed
+
+34
+00:01:40,560 --> 00:01:43,320
+to be too risky, like in this case, this might result in
+
+35
+00:01:43,320 --> 00:01:47,880
+changes in the requirements model to eliminate or address those risks. And note
+
+36
+00:01:47,880 --> 00:01:49,950
+that all these analysis activities can
+
+37
+00:01:49,950 --> 00:01:52,390
+be performed in many different ways depending
+
+38
+00:01:52,390 --> 00:01:53,990
+on the modeling languages chosen to
+
+39
+00:01:53,990 --> 00:01:56,150
+represent the requirements and on the context.
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/29 - Requirements Prioritization - lang_en_vs5.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/29 - Requirements Prioritization - lang_en_vs5.srt
new file mode 100644
index 0000000..09978d7
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/29 - Requirements Prioritization - lang_en_vs5.srt	
@@ -0,0 +1,59 @@
+1
+00:00:00,140 --> 00:00:04,010
+Why collecting, modeling, and analyzing requirements? We might realize
+
+2
+00:00:04,010 --> 00:00:07,310
+that the resources available for the project are not enough
+
+3
+00:00:07,310 --> 00:00:10,000
+to satisfy all of them. For example, there's not
+
+4
+00:00:10,000 --> 00:00:13,450
+enough time, not enough money, not enough manpower. And therefore,
+
+5
+00:00:13,450 --> 00:00:15,590
+there are some requirements that we won't be able
+
+6
+00:00:15,590 --> 00:00:19,760
+to satisfy. In these cases, we must prioritize our requirements,
+
+7
+00:00:19,760 --> 00:00:22,310
+by classifying them in one of three classes. The
+
+8
+00:00:22,310 --> 00:00:25,270
+first class is mandatory requirements, and these are the requirements
+
+9
+00:00:25,270 --> 00:00:29,770
+we must satisfy. Then there are the nice to have requirements that are the
+
+10
+00:00:29,770 --> 00:00:32,170
+ones that we will satisfy if resources
+
+11
+00:00:32,170 --> 00:00:34,740
+allow. And finally, there are the superfluous
+
+12
+00:00:34,740 --> 00:00:36,440
+requirements, and those are the requirements that
+
+13
+00:00:36,440 --> 00:00:37,770
+we're going to keep around, but that we're
+
+14
+00:00:37,770 --> 00:00:40,010
+going to postpone. For example, we might decide
+
+15
+00:00:40,010 --> 00:00:41,770
+to satisfy them in the next release.
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/3 - General RE Definition - lang_en_vs4.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/3 - General RE Definition - lang_en_vs4.srt
new file mode 100644
index 0000000..34ec511
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/3 - General RE Definition - lang_en_vs4.srt	
@@ -0,0 +1,103 @@
+1
+00:00:00,360 --> 00:00:03,900
+Basically, and roughly speaking, requirements engineering, which is
+
+2
+00:00:03,900 --> 00:00:06,630
+also called in short, RE, is the process
+
+3
+00:00:06,630 --> 00:00:10,520
+of establishing the services that the customer requires
+
+4
+00:00:10,520 --> 00:00:13,530
+from the software system. In addition to that, requirements
+
+5
+00:00:13,530 --> 00:00:16,360
+engineering also has to do with the constraints
+
+6
+00:00:16,360 --> 00:00:19,900
+under which the system operates and is developed. Requirements
+
+7
+00:00:19,900 --> 00:00:22,770
+engineering is a very important activity for several
+
+8
+00:00:22,770 --> 00:00:25,450
+reasons. In particular, as we also saw in earlier
+
+9
+00:00:25,450 --> 00:00:29,860
+lessons, many errors are made in requirement specifications. So many
+
+10
+00:00:29,860 --> 00:00:33,100
+errors are made because we don't do requirements engineering in
+
+11
+00:00:33,100 --> 00:00:35,670
+the right way. And many of these errors are not
+
+12
+00:00:35,670 --> 00:00:38,340
+being detected early. But they could be if we were
+
+13
+00:00:38,340 --> 00:00:41,350
+to do RE in the right way. And, unfortunately, not
+
+14
+00:00:41,350 --> 00:00:45,510
+detecting these errors can dramatically increase software costs. So that's
+
+15
+00:00:45,510 --> 00:00:48,250
+the reason why requirements engineering is important, and why it
+
+16
+00:00:48,250 --> 00:00:50,730
+is important to do it in the right way. The final
+
+17
+00:00:50,730 --> 00:00:53,660
+result of the requirements engineering process is a software
+
+18
+00:00:53,660 --> 00:00:58,230
+requirements specification that we also called SRS. We will discuss
+
+19
+00:00:58,230 --> 00:01:01,060
+SRS later in more details and also when we talk
+
+20
+00:01:01,060 --> 00:01:03,740
+about the projects for the course. For now, it is
+
+21
+00:01:03,740 --> 00:01:07,040
+enough to say that the software requirements specification and
+
+22
+00:01:07,040 --> 00:01:10,280
+the requirements engineering, in general, should focus on what the
+
+23
+00:01:10,280 --> 00:01:13,290
+proposed system is intended to do, and not on the
+
+24
+00:01:13,290 --> 00:01:16,280
+how it will do it. In fact, how the system
+
+25
+00:01:16,280 --> 00:01:18,450
+will do what it is required to do is something that we
+
+26
+00:01:18,450 --> 00:01:22,170
+will discuss when we talk about design of a system in later phases.
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/30 - Requirements Prioritization Quiz - lang_en_vs4.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/30 - Requirements Prioritization Quiz - lang_en_vs4.srt
new file mode 100644
index 0000000..9415793
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/30 - Requirements Prioritization Quiz - lang_en_vs4.srt	
@@ -0,0 +1,79 @@
+1
+00:00:00,110 --> 00:00:03,090
+Now that we talked about requirements prioritization, let's try to see
+
+2
+00:00:03,090 --> 00:00:06,110
+how this might work in practice. Imagine that you have collected the
+
+3
+00:00:06,110 --> 00:00:09,560
+folowing set of five requirements for an ATM system, but only
+
+4
+00:00:09,560 --> 00:00:12,680
+have resources to satisfy two of them. Possibly three. I would like
+
+5
+00:00:12,680 --> 00:00:15,550
+for you to look at this list and suitablely prioritize the
+
+6
+00:00:15,550 --> 00:00:19,220
+requirements by marking them as mandatory, in this case you're going to put
+
+7
+00:00:19,220 --> 00:00:21,840
+an M in the space. Nice to have, in this case you're
+
+8
+00:00:21,840 --> 00:00:25,350
+going to put an N. Or superfluous, in this case you're going to put
+
+9
+00:00:25,350 --> 00:00:28,005
+an S. This is the set of requirements, the first one
+
+10
+00:00:28,005 --> 00:00:30,342
+says that the system shall check the PIN of the ATM
+
+11
+00:00:30,342 --> 00:00:33,863
+card before allowing the customer to perform an operation. The second
+
+12
+00:00:33,863 --> 00:00:37,575
+says that the system shall perform an additional biometric verification of
+
+13
+00:00:37,575 --> 00:00:40,881
+the customer identity for example a check of the customer's finger
+
+14
+00:00:40,881 --> 00:00:44,294
+prints before it allows the customer to perform an operation. Then
+
+15
+00:00:44,294 --> 00:00:47,466
+we have that the system shall allow customers to withdraw cash
+
+16
+00:00:47,466 --> 00:00:50,580
+using an ATM card. The system shall allow customer to deposit
+
+17
+00:00:50,580 --> 00:00:53,350
+money using an ATM card. And the system shall allow
+
+18
+00:00:53,350 --> 00:00:56,330
+customers to change the pin of their ATM card. So again,
+
+19
+00:00:56,330 --> 00:01:00,600
+mark those as mandatory, nice to have, or superfluous considering the
+
+20
+00:01:00,600 --> 00:01:04,170
+fact that you can satisfy only two, possibly three of them.
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/31 - Requirements Prioritization Quiz Solution - lang_en_vs5.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/31 - Requirements Prioritization Quiz Solution - lang_en_vs5.srt
new file mode 100644
index 0000000..e2fd768
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/31 - Requirements Prioritization Quiz Solution - lang_en_vs5.srt	
@@ -0,0 +1,119 @@
+1
+00:00:00,130 --> 00:00:02,640
+Looking at the requirements, and knowing that we have only two
+
+2
+00:00:02,640 --> 00:00:05,630
+that we can satisfy for sure, it makes sense to first mark
+
+3
+00:00:05,630 --> 00:00:09,080
+as mandatory the ability to withdraw cash, which is the most typical
+
+4
+00:00:09,080 --> 00:00:12,650
+use of an ATM machine. We are therefore going to mark this requirement
+
+5
+00:00:12,650 --> 00:00:15,260
+with an M, for mandatory. It also makes sense to mark as
+
+6
+00:00:15,260 --> 00:00:18,390
+mandatory the fact that the ATM system checks the PIN of the
+
+7
+00:00:18,390 --> 00:00:21,480
+card being used by the customer, as that's the typical level of
+
+8
+00:00:21,480 --> 00:00:23,680
+security that the customer would expect,
+
+9
+00:00:23,680 --> 00:00:25,760
+therefore we're going to mark as mandatory
+
+10
+00:00:25,760 --> 00:00:28,320
+also the first requirement here. And of course we
+
+11
+00:00:28,320 --> 00:00:31,930
+could also perform biometric verification, but based on our knowledge
+
+12
+00:00:31,930 --> 00:00:33,640
+of the domain, it seems like that should be
+
+13
+00:00:33,640 --> 00:00:37,410
+an additional verification, rather than the main and only verification
+
+14
+00:00:37,410 --> 00:00:40,170
+for the system. We will therefore mark it superfluous.
+
+15
+00:00:40,170 --> 00:00:42,720
+That is something that we can postpone until a later
+
+16
+00:00:42,720 --> 00:00:45,100
+release, the second requirement. Finally,
+
+17
+00:00:45,100 --> 00:00:46,740
+another typical operation that customers
+
+18
+00:00:46,740 --> 00:00:51,070
+perform at ATM machines is depositing. Whereas changing an ATM
+
+19
+00:00:51,070 --> 00:00:53,850
+card's PIN is not such a common operation. We'll therefore mark
+
+20
+00:00:53,850 --> 00:00:57,710
+it nice to have this fourth requirement and as superfluous, the
+
+21
+00:00:57,710 --> 00:01:00,420
+last one. So at the end, what we have is that
+
+22
+00:01:00,420 --> 00:01:03,540
+we have two mandatory requirements which are the two that we can
+
+23
+00:01:03,540 --> 00:01:06,280
+satisfy for sure. One, nice to have the requirement, which is
+
+24
+00:01:06,280 --> 00:01:09,960
+the possible third requirement which we might have time to satisfy. And
+
+25
+00:01:09,960 --> 00:01:12,980
+the other two that are marked as superfluous, as something that
+
+26
+00:01:12,980 --> 00:01:16,100
+we might do later, for example in a subsequent release. And of
+
+27
+00:01:16,100 --> 00:01:19,060
+course there is something subjective in these answers. But
+
+28
+00:01:19,060 --> 00:01:22,020
+again, based on our knowledge on our understanding of
+
+29
+00:01:22,020 --> 00:01:23,910
+the domain, these are the one that makes more
+
+30
+00:01:23,910 --> 00:01:26,640
+sense for an ATM system as we know it.
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/32 - Requirements Engineering Process - lang_en_vs4.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/32 - Requirements Engineering Process - lang_en_vs4.srt
new file mode 100644
index 0000000..aa1ab28
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/32 - Requirements Engineering Process - lang_en_vs4.srt	
@@ -0,0 +1,99 @@
+1
+00:00:00,180 --> 00:00:02,580
+Let's now put together all that we have discussed
+
+2
+00:00:02,580 --> 00:00:06,340
+and see how a requirements engineering process actually works.
+
+3
+00:00:06,340 --> 00:00:08,450
+So, first of all, we saw that requirements engineering
+
+4
+00:00:08,450 --> 00:00:12,080
+consists of three main steps. Elicitation of the requirements,
+
+5
+00:00:12,080 --> 00:00:15,450
+in which we extract requirements from various sources. Modeling
+
+6
+00:00:15,450 --> 00:00:17,880
+in which we represent the requirements using one or
+
+7
+00:00:17,880 --> 00:00:21,650
+more notations or formal reasons and analysis, in which
+
+8
+00:00:21,650 --> 00:00:25,230
+we identify possible issues with our requirements and there is
+
+9
+00:00:25,230 --> 00:00:27,870
+actually a 4th step that we kind of mention
+
+10
+00:00:27,870 --> 00:00:30,670
+but not explicitly. And this is the negotiation that can
+
+11
+00:00:30,670 --> 00:00:34,320
+happen between the stakeholders and the developers, during which
+
+12
+00:00:34,320 --> 00:00:38,400
+requirements are discussed and modified until an agreement is reached.
+
+13
+00:00:38,400 --> 00:00:40,000
+So if you want to think of this as a
+
+14
+00:00:40,000 --> 00:00:43,030
+process, so as a sequence of steps, we can see
+
+15
+00:00:43,030 --> 00:00:46,000
+that we start from elicitation. So we start by eliciting
+
+16
+00:00:46,000 --> 00:00:50,450
+an initial setup requirements. We negotiate and refine this set,
+
+17
+00:00:50,450 --> 00:00:53,820
+then we model the resulting requirements. And finally, we
+
+18
+00:00:53,820 --> 00:00:58,190
+analyze such requirements. However, the process doesn't really stop here.
+
+19
+00:00:58,190 --> 00:01:00,620
+Why? Well, because as a result of the analysis,
+
+20
+00:01:00,620 --> 00:01:03,230
+we might have to perform further elicitation. And so this
+
+21
+00:01:03,230 --> 00:01:05,850
+process is not really a sequential one, but rather
+
+22
+00:01:05,850 --> 00:01:09,340
+an iterative process. So, in practice, we continue to iterate
+
+23
+00:01:09,340 --> 00:01:12,700
+over these four steps gathering a better and better understanding
+
+24
+00:01:12,700 --> 00:01:15,560
+of the requirements at every iteration until we are happy
+
+25
+00:01:15,560 --> 00:01:18,080
+with the settle requirement that we gather and stop the process.
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/33 - SRS - lang_en_vs5.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/33 - SRS - lang_en_vs5.srt
new file mode 100644
index 0000000..44076db
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/33 - SRS - lang_en_vs5.srt	
@@ -0,0 +1,183 @@
+1
+00:00:00,120 --> 00:00:01,800
+Before I conclude this lesson, I want to say
+
+2
+00:00:01,800 --> 00:00:06,150
+a few additional things about the Software Requirement Specification document
+
+3
+00:00:06,150 --> 00:00:08,510
+or the SRS. And I want to do that because this
+
+4
+00:00:08,510 --> 00:00:10,900
+is a very important document and some of the projects
+
+5
+00:00:10,900 --> 00:00:13,160
+actually require you to produce one. So why is
+
+6
+00:00:13,160 --> 00:00:16,760
+the Requirement Specification such an important document? That's because a
+
+7
+00:00:16,760 --> 00:00:20,840
+Software Requirement Specification document is an important fundamental way to
+
+8
+00:00:20,840 --> 00:00:25,310
+communicate. Requirements to others. For example they represent a common
+
+9
+00:00:25,310 --> 00:00:29,490
+ground between analysts and stakeholders. Note however, that different
+
+10
+00:00:29,490 --> 00:00:32,810
+projects might require different software requirement specifications so you
+
+11
+00:00:32,810 --> 00:00:35,560
+need to know your context. For example, the SRS
+
+12
+00:00:35,560 --> 00:00:38,140
+document that you have to create for a small project
+
+13
+00:00:38,140 --> 00:00:40,690
+performed by a few developers can in most cases.
+
+14
+00:00:40,690 --> 00:00:43,570
+Be a concise and informal one. Conversely the software
+
+15
+00:00:43,570 --> 00:00:47,000
+requirement specification for a multi-year project, involving a number
+
+16
+00:00:47,000 --> 00:00:50,480
+of developers can be a fairly complex and extensive document.
+
+17
+00:00:50,480 --> 00:00:52,000
+So again you have to be aware of your
+
+18
+00:00:52,000 --> 00:00:55,520
+context and build your software requirement specification accordingly. In
+
+19
+00:00:55,520 --> 00:00:58,536
+order to have a common format for the SRS
+
+20
+00:00:58,536 --> 00:01:01,380
+document, IEEE defined a standard that divides the document in
+
+21
+00:01:01,380 --> 00:01:04,349
+predefined sections. And in the context of this course,
+
+22
+00:01:04,349 --> 00:01:07,530
+we will use a simplified version of the IEEE
+
+23
+00:01:07,530 --> 00:01:11,400
+SRS format that includes three main sections. An introduction,
+
+24
+00:01:11,400 --> 00:01:15,540
+which discusses the purpose, context, and objectives of the project.
+
+25
+00:01:15,540 --> 00:01:18,500
+A user requirements definition, which contains the user
+
+26
+00:01:18,500 --> 00:01:22,690
+requirements. And the system requirements specification, which includes both
+
+27
+00:01:22,690 --> 00:01:26,800
+functional and non-functional requirements. And we provide more information
+
+28
+00:01:26,800 --> 00:01:29,430
+about this format when we discuss the projects. So
+
+29
+00:01:29,430 --> 00:01:31,140
+to conclude the lesson, I want to point
+
+30
+00:01:31,140 --> 00:01:33,670
+out and in some cases recap a few important
+
+31
+00:01:33,670 --> 00:01:37,150
+characteristics that requirements should have. First of all, requirements
+
+32
+00:01:37,150 --> 00:01:40,740
+should be simple. Not compound. Each requirement should express
+
+33
+00:01:40,740 --> 00:01:43,710
+one specific piece of functionality that the system
+
+34
+00:01:43,710 --> 00:01:47,000
+should provide. Requirements should be testable. We mentioned
+
+35
+00:01:47,000 --> 00:01:48,660
+this before, but I want to stress it
+
+36
+00:01:48,660 --> 00:01:51,820
+because it is a very important point. Untestable requirements
+
+37
+00:01:51,820 --> 00:01:53,850
+such as the system should be fast, are
+
+38
+00:01:53,850 --> 00:01:58,180
+useless. Requirements should be organized. Related requirements should be
+
+39
+00:01:58,180 --> 00:02:01,220
+grouped, more abstract requirements should contain more detailed
+
+40
+00:02:01,220 --> 00:02:05,400
+requirements, and priorities should be clearly indicated when present.
+
+41
+00:02:05,400 --> 00:02:07,532
+Finally, requirements should be numbered, so
+
+42
+00:02:07,532 --> 00:02:09,538
+that they can be traced. For example,
+
+43
+00:02:09,538 --> 00:02:11,430
+numbered requirements will allow you to trace
+
+44
+00:02:11,430 --> 00:02:14,510
+them to design. Implementation and testing elements
+
+45
+00:02:14,510 --> 00:02:17,350
+and items, which is something that you might have to do for one of
+
+46
+00:02:17,350 --> 00:02:20,680
+the projects. And that we will discuss in more detail in a later class.
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/4 - Software Intensive Systems - lang_en_vs5.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/4 - Software Intensive Systems - lang_en_vs5.srt
new file mode 100644
index 0000000..28c70ad
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/4 - Software Intensive Systems - lang_en_vs5.srt	
@@ -0,0 +1,111 @@
+1
+00:00:00,100 --> 00:00:03,100
+In our initial definition of requirements engineering, we talked about
+
+2
+00:00:03,100 --> 00:00:06,130
+software systems. But what do we really mean when we
+
+3
+00:00:06,130 --> 00:00:09,980
+use the term software? Software is an abstract description of
+
+4
+00:00:09,980 --> 00:00:13,920
+a set of computations that becomes concrete, and therefore useful, only
+
+5
+00:00:13,920 --> 00:00:16,600
+when we run the software on some hardware, and that,
+
+6
+00:00:16,600 --> 00:00:19,310
+in the context of some human activity that it can
+
+7
+00:00:19,310 --> 00:00:22,530
+support. So what does that mean exactly? What that means
+
+8
+00:00:22,530 --> 00:00:25,235
+is that when we say software, what we really mean is
+
+9
+00:00:25,235 --> 00:00:28,790
+a software intensive system. That is, the combination
+
+10
+00:00:28,790 --> 00:00:31,930
+of 3 things, the software, the hardware on which
+
+11
+00:00:31,930 --> 00:00:34,610
+the software runs, and the context in which the
+
+12
+00:00:34,610 --> 00:00:37,470
+software is used. Just to illustrate, let me show
+
+13
+00:00:37,470 --> 00:00:40,010
+you this through a picture. What I'm showing here
+
+14
+00:00:40,010 --> 00:00:42,830
+is a customer, a user, that is using, is
+
+15
+00:00:42,830 --> 00:00:47,000
+accessing, an ATM machine. And this action involves several
+
+16
+00:00:47,000 --> 00:00:50,650
+things. There is the software that drives the logic
+
+17
+00:00:50,650 --> 00:00:53,410
+of the ATM machine. There is the hardware on
+
+18
+00:00:53,410 --> 00:00:57,280
+which the software runs. And there is the context
+
+19
+00:00:57,280 --> 00:00:59,850
+In which the software is used. And in this
+
+20
+00:00:59,850 --> 00:01:02,660
+case, the context is the bank. And only by
+
+21
+00:01:02,660 --> 00:01:06,105
+considering these 3 things together can we really understand
+
+22
+00:01:06,105 --> 00:01:09,510
+the functionality that is represented here. So the bottom
+
+23
+00:01:09,510 --> 00:01:12,690
+line here is that we usually take hardware and
+
+24
+00:01:12,690 --> 00:01:15,750
+context for granted in this equation. But they actually
+
+25
+00:01:15,750 --> 00:01:18,210
+need to be explicitly considered when building a
+
+26
+00:01:18,210 --> 00:01:20,770
+system. Otherwise, we might forget this is all
+
+27
+00:01:20,770 --> 00:01:23,850
+the functionality, and ultimately of the requirements. And
+
+28
+00:01:23,850 --> 00:01:25,640
+we might end up with the wrong system.
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/5 - Software Quality - lang_en_vs4.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/5 - Software Quality - lang_en_vs4.srt
new file mode 100644
index 0000000..86db606
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/5 - Software Quality - lang_en_vs4.srt	
@@ -0,0 +1,111 @@
+1
+00:00:00,170 --> 00:00:02,920
+So, let's see how this affects the concept of software
+
+2
+00:00:02,920 --> 00:00:05,620
+quality. Another way to express what we just said is
+
+3
+00:00:05,620 --> 00:00:08,220
+to say that the software runs on some hardware and
+
+4
+00:00:08,220 --> 00:00:11,750
+is developed for a purpose that is related to human
+
+5
+00:00:11,750 --> 00:00:14,870
+activities. And given this perspective, we can define what we
+
+6
+00:00:14,870 --> 00:00:18,440
+mean by software quality in this light. Software quality is
+
+7
+00:00:18,440 --> 00:00:22,290
+not just a function of the software. So, the software
+
+8
+00:00:22,290 --> 00:00:25,610
+itself does not define the quality of the overall system.
+
+9
+00:00:25,610 --> 00:00:28,880
+Rather, software quality is a function of both the
+
+10
+00:00:28,880 --> 00:00:32,259
+software and its purpose. Where purpose has to do with
+
+11
+00:00:32,259 --> 00:00:34,840
+the way in which the software will be used. So
+
+12
+00:00:34,840 --> 00:00:37,950
+a software system can be of low quality not only
+
+13
+00:00:37,950 --> 00:00:40,580
+because it does not work well. So, for example, not
+
+14
+00:00:40,580 --> 00:00:43,620
+only because it crashes. Of course, that's an issue. But
+
+15
+00:00:43,620 --> 00:00:47,000
+just as importantly, a software can also be of low
+
+16
+00:00:47,000 --> 00:00:50,720
+quality because it does not fulfill its purpose, and this
+
+17
+00:00:50,720 --> 00:00:53,960
+happens quite often. It is unfortunately not rare for
+
+18
+00:00:53,960 --> 00:00:57,310
+the software producers to have an inadequate understanding, or even
+
+19
+00:00:57,310 --> 00:01:00,450
+a complete misunderstanding of the purpose of the software,
+
+20
+00:01:00,450 --> 00:01:03,200
+of what the users want to do and will do
+
+21
+00:01:03,200 --> 00:01:05,770
+with it. Turning these around, we can therefore define
+
+22
+00:01:05,770 --> 00:01:09,890
+the quality of software in terms of fitness for purpose.
+
+23
+00:01:09,890 --> 00:01:12,990
+The more the software fulfills its purpose, the more
+
+24
+00:01:12,990 --> 00:01:16,040
+the software is on target, the higher is its quality.
+
+25
+00:01:16,040 --> 00:01:19,600
+And identifying the purpose of the software, so hitting
+
+26
+00:01:19,600 --> 00:01:23,550
+this target, is exactly the goal of requirements engineering.
+
+27
+00:01:23,550 --> 00:01:25,970
+And it is the reason why requirements engineering is
+
+28
+00:01:25,970 --> 00:01:29,370
+such a fundamental activity in the context of software engineering.
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/6 - Identifying Purpose - lang_en_vs4.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/6 - Identifying Purpose - lang_en_vs4.srt
new file mode 100644
index 0000000..0accc39
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/6 - Identifying Purpose - lang_en_vs4.srt	
@@ -0,0 +1,107 @@
+1
+00:00:00,050 --> 00:00:03,480
+And identifying the purpose of a softer system means
+
+2
+00:00:03,480 --> 00:00:06,980
+defining the requirements for the system. And if you have
+
+3
+00:00:06,980 --> 00:00:09,540
+ever done anything like that, for example, we did
+
+4
+00:00:09,540 --> 00:00:12,060
+it for the first project in the previous mini course,
+
+5
+00:00:12,060 --> 00:00:14,720
+you will know that it is an extremely hard
+
+6
+00:00:14,720 --> 00:00:17,760
+task. Identifying the purpose of the software and defining its
+
+7
+00:00:17,760 --> 00:00:21,600
+requirements is very, very hard. Why is it so hard?
+
+8
+00:00:21,600 --> 00:00:25,560
+First of all, the purpose of most systems is inherently,
+
+9
+00:00:25,560 --> 00:00:27,920
+extremely complex, so this has to do with the
+
+10
+00:00:27,920 --> 00:00:31,330
+sheer complexity of the purpose of the requirements. Just think
+
+11
+00:00:31,330 --> 00:00:34,810
+of how complex is the functionality provided by most systems.
+
+12
+00:00:34,810 --> 00:00:38,790
+Second, it is hard, very hard to extract from humans
+
+13
+00:00:38,790 --> 00:00:41,780
+this purpose and make it explicit. So, paraphrasing a
+
+14
+00:00:41,780 --> 00:00:45,130
+famous quote from the late Steve Jobs, often people don't
+
+15
+00:00:45,130 --> 00:00:47,475
+know what they want until you show it to them.
+
+16
+00:00:47,475 --> 00:00:50,490
+It's hard to figure out what people really want. Third,
+
+17
+00:00:50,490 --> 00:00:54,260
+requirements often change over time. Customers change their
+
+18
+00:00:54,260 --> 00:00:57,490
+mind. Designing and building a system raises new requirements.
+
+19
+00:00:57,490 --> 00:01:00,270
+So for many reasons requirements tend not to
+
+20
+00:01:00,270 --> 00:01:02,760
+be stable, tend to evolve. And that, of course,
+
+21
+00:01:02,760 --> 00:01:05,440
+makes it harder to collect them. Finally, for
+
+22
+00:01:05,440 --> 00:01:09,600
+any realistic system, there are many stakeholders and they
+
+23
+00:01:09,600 --> 00:01:12,990
+often have conflicting goals and requirements. And it
+
+24
+00:01:12,990 --> 00:01:15,900
+can be very hard to reconcile the possibly conflicting
+
+25
+00:01:15,900 --> 00:01:19,630
+requirements that might emerge in these cases. So for all these reasons,
+
+26
+00:01:19,630 --> 00:01:21,230
+it is very, very difficult to
+
+27
+00:01:21,230 --> 00:01:23,930
+perform requirements engineering in an effective way.
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/7 - Completeness and Pertinence - lang_en_vs5.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/7 - Completeness and Pertinence - lang_en_vs5.srt
new file mode 100644
index 0000000..c0ce159
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/7 - Completeness and Pertinence - lang_en_vs5.srt	
@@ -0,0 +1,103 @@
+1
+00:00:00,350 --> 00:00:03,610
+These issues and difficulties can result in requirements
+
+2
+00:00:03,610 --> 00:00:06,780
+that show various problems. Two particularly relevant and
+
+3
+00:00:06,780 --> 00:00:10,880
+common problems are completeness and pertinence. Or better,
+
+4
+00:00:10,880 --> 00:00:14,750
+the lack of completeness and pertinence. Completeness refers to
+
+5
+00:00:14,750 --> 00:00:17,560
+the fact that it is often extremely difficult
+
+6
+00:00:17,560 --> 00:00:20,370
+to identify all of the requirements. That is it
+
+7
+00:00:20,370 --> 00:00:22,890
+is very difficult to have a complete picture
+
+8
+00:00:22,890 --> 00:00:25,780
+of the purpose of the software. So what happens
+
+9
+00:00:25,780 --> 00:00:28,540
+is that incomplete requirements are collected and the software
+
+10
+00:00:28,540 --> 00:00:32,500
+is missing functionality that is important for the user. Pertinence
+
+11
+00:00:32,500 --> 00:00:34,720
+conversely has to do with the relevance of the
+
+12
+00:00:34,720 --> 00:00:38,770
+requirements. To avoid completeness problems developers often end up collecting
+
+13
+00:00:38,770 --> 00:00:42,640
+a lot of irrelevant when not conflicting requirements. In
+
+14
+00:00:42,640 --> 00:00:45,060
+these cases what can happen is that the software could
+
+15
+00:00:45,060 --> 00:00:47,120
+either end up being bloated that is it might
+
+16
+00:00:47,120 --> 00:00:51,290
+contain a needed functionality. The functionality represented by these extra
+
+17
+00:00:51,290 --> 00:00:54,120
+requirements or it might even be impossible to build the
+
+18
+00:00:54,120 --> 00:00:57,480
+software due to the conflicting additional requirements. And to make
+
+19
+00:00:57,480 --> 00:01:00,920
+things even worse collecting all of these requirements sometimes doesn't
+
+20
+00:01:00,920 --> 00:01:03,390
+even solve the completeness issue. So you might end up
+
+21
+00:01:03,390 --> 00:01:05,800
+with a set of requirements that is not only incomplete
+
+22
+00:01:05,800 --> 00:01:08,740
+but it also contains extra information that can be harmful
+
+23
+00:01:08,740 --> 00:01:11,450
+to the system. So again the bottom line is that
+
+24
+00:01:11,450 --> 00:01:14,310
+gathering an adequate, accurate, complete,
+
+25
+00:01:14,310 --> 00:01:16,500
+and pertinent set of requirements that
+
+26
+00:01:16,500 --> 00:01:20,100
+identify the purpose of a software system is an arduous task.
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/8 - Pertinence Quiz - lang_en_vs5.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/8 - Pertinence Quiz - lang_en_vs5.srt
new file mode 100644
index 0000000..a04a9a9
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/8 - Pertinence Quiz - lang_en_vs5.srt	
@@ -0,0 +1,35 @@
+1
+00:00:00,100 --> 00:00:03,530
+Now that we talked about completeness and pertinence, let's consider an
+
+2
+00:00:03,530 --> 00:00:06,200
+information system for a gym. I'm going to give you a
+
+3
+00:00:06,200 --> 00:00:09,580
+list of possible requirements and I want you to mark in
+
+4
+00:00:09,580 --> 00:00:13,530
+that list all the requirements that you believe are pertinent. So let
+
+5
+00:00:13,530 --> 00:00:16,030
+me read the list. Members of the gym shall be able
+
+6
+00:00:16,030 --> 00:00:18,770
+to access their training programs. The system shall be able to
+
+7
+00:00:18,770 --> 00:00:21,894
+read member cards. The system shall be able to store members'
+
+8
+00:00:21,894 --> 00:00:25,150
+commute time. Personal trainers shall be able to add clients. And the
+
+9
+00:00:25,150 --> 00:00:27,570
+list of members shall be stored as a linked list.
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/9 - Pertinence Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/9 - Pertinence Quiz Solution - lang_en_vs4.srt
new file mode 100644
index 0000000..ee4f04f
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/9 - Pertinence Quiz Solution - lang_en_vs4.srt	
@@ -0,0 +1,75 @@
+1
+00:00:00,190 --> 00:00:03,620
+So the first requirement is definitely pertinent. Members of the gym shall
+
+2
+00:00:03,620 --> 00:00:06,740
+be able to access their training programs. It's pretty normal for members of
+
+3
+00:00:06,740 --> 00:00:09,710
+the gym to have a training program. And therefore, the system should allow
+
+4
+00:00:09,710 --> 00:00:12,900
+them to access them. Similarly for the second one. The system shall be
+
+5
+00:00:12,900 --> 00:00:15,450
+able to read member cards. Normally when you get into a gym
+
+6
+00:00:15,450 --> 00:00:17,420
+if you have a member card, you'll have to either show it to
+
+7
+00:00:17,420 --> 00:00:21,010
+somebody, or nowadays swipe it, and so the system should be able to
+
+8
+00:00:21,010 --> 00:00:23,410
+recognize the customer given the card.
+
+9
+00:00:23,410 --> 00:00:25,710
+The third requirement is probably not pertinent,
+
+10
+00:00:25,710 --> 00:00:29,090
+because I cannot think of any meaningful case in which the system
+
+11
+00:00:29,090 --> 00:00:32,729
+should know what is the members' commute time. The fourth requirement, personal
+
+12
+00:00:32,729 --> 00:00:36,750
+trainers shall be able to add clients, is also probably pertinent. Assuming
+
+13
+00:00:36,750 --> 00:00:38,870
+that we have personal trainers in the gym, and they should be
+
+14
+00:00:38,870 --> 00:00:41,710
+able to get clients, to work with the clients of the gym,
+
+15
+00:00:41,710 --> 00:00:44,140
+and therefore, they should be able to add them as their clients
+
+16
+00:00:44,140 --> 00:00:47,620
+to the system. And finally, the last requirement, the list of members
+
+17
+00:00:47,620 --> 00:00:50,800
+shall be stores as a linked list. This is really something about
+
+18
+00:00:50,800 --> 00:00:54,130
+the how, more than the what. And therefore, for what we say before
+
+19
+00:00:54,130 --> 00:00:57,720
+is probably not a pertinent requirement, so we're not going to mark this one.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/1 - Lesson Overview - lang_en_vs4.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/1 - Lesson Overview - lang_en_vs4.srt
new file mode 100644
index 0000000..3cc0326
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/1 - Lesson Overview - lang_en_vs4.srt	
@@ -0,0 +1,35 @@
+1
+00:00:00,460 --> 00:00:03,770
+Hi. In the last lesson we discussed
+
+2
+00:00:03,770 --> 00:00:08,370
+requirements engineering. This lesson is about object orientation
+
+3
+00:00:08,370 --> 00:00:11,958
+and other related concepts. The lesson is split
+
+4
+00:00:11,958 --> 00:00:14,720
+in two main parts. In the first part,
+
+5
+00:00:14,720 --> 00:00:16,870
+we will provide a quick introduction to
+
+6
+00:00:16,870 --> 00:00:20,890
+object orientation and object oriented analysis and design.
+
+7
+00:00:20,890 --> 00:00:22,750
+In the second part, we will cover the
+
+8
+00:00:22,750 --> 00:00:25,710
+essential of UML, which is the notation that
+
+9
+00:00:25,710 --> 00:00:29,190
+we will use in the rest of the course and also in our projects.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/10 - Modeling Classes Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/10 - Modeling Classes Quiz Solution - lang_en_vs4.srt
new file mode 100644
index 0000000..4dd6994
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/10 - Modeling Classes Quiz Solution - lang_en_vs4.srt	
@@ -0,0 +1,47 @@
+1
+00:00:00,120 --> 00:00:03,110
+Looking at the requirements, item is definitely a relevant element
+
+2
+00:00:03,110 --> 00:00:07,060
+for my system, so it is appropriate to model item as
+
+3
+00:00:07,060 --> 00:00:09,300
+a class. Sale, on the other hand, is more of
+
+4
+00:00:09,300 --> 00:00:12,610
+a characteristic of an item, an attribute of an item, rather
+
+5
+00:00:12,610 --> 00:00:14,960
+than a class in itself. So, we're not going to mark
+
+6
+00:00:14,960 --> 00:00:18,460
+this one. Shopping cart sounds, as well, as an important element
+
+7
+00:00:18,460 --> 00:00:21,550
+for my system. Time can be an important system in some
+
+8
+00:00:21,550 --> 00:00:25,420
+contexts, but in this case we're measuring time just because more
+
+9
+00:00:25,420 --> 00:00:28,430
+than one item at a time can be added to the shopping cart.
+
+10
+00:00:28,430 --> 00:00:32,770
+So, time really doesn't have any reason for being modeled as a class.
+
+11
+00:00:32,770 --> 00:00:36,550
+And finally, user also seems to also have an important role to play
+
+12
+00:00:36,550 --> 00:00:40,260
+in the system, and therefore we will model user as a class as well.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/11 - Running Example Explanation - lang_en_vs5.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/11 - Running Example Explanation - lang_en_vs5.srt
new file mode 100644
index 0000000..6d86101
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/11 - Running Example Explanation - lang_en_vs5.srt	
@@ -0,0 +1,115 @@
+1
+00:00:00,100 --> 00:00:02,700
+This concludes the first part of this lesson in which
+
+2
+00:00:02,700 --> 00:00:06,080
+we discussed the basic object-oriented concepts. And, we started to
+
+3
+00:00:06,080 --> 00:00:09,830
+look at how to perform object-oriented analysis. In the second
+
+4
+00:00:09,830 --> 00:00:12,630
+part of the lesson, I will introduce UML, and we will
+
+5
+00:00:12,630 --> 00:00:15,990
+perform the object-oriented analysis steps that we just saw using
+
+6
+00:00:15,990 --> 00:00:19,240
+an example. A course management system so before getting to
+
+7
+00:00:19,240 --> 00:00:22,380
+the second part, let me introduce the example. As we
+
+8
+00:00:22,380 --> 00:00:25,420
+mentioned before, the first step is to start from a textual
+
+9
+00:00:25,420 --> 00:00:27,800
+description of the system the we need to analyze and
+
+10
+00:00:27,800 --> 00:00:30,080
+that we need to build. So that's exactly what I'm going
+
+11
+00:00:30,080 --> 00:00:33,272
+to do. I'm just going to read through this description then we'll
+
+12
+00:00:33,272 --> 00:00:36,590
+reuse throughout the rest of the lesson. The registration manager sets
+
+13
+00:00:36,590 --> 00:00:40,090
+up the curriculum for a semester using a scheduling algorithm and
+
+14
+00:00:40,090 --> 00:00:43,600
+the registration manager here is the registrar. So we will refer
+
+15
+00:00:43,600 --> 00:00:47,510
+to the registration manager both as registration manager and as registrar
+
+16
+00:00:47,510 --> 00:00:50,500
+in the rest of the lesson. One course may have multiple
+
+17
+00:00:50,500 --> 00:00:52,860
+course offerings, which is pretty standard. Each
+
+18
+00:00:52,860 --> 00:00:55,490
+course offering has a number, location, and a
+
+19
+00:00:55,490 --> 00:00:59,160
+time associated with it. Students select four primary
+
+20
+00:00:59,160 --> 00:01:02,410
+courses and two alternative courses by submitting a
+
+21
+00:01:02,410 --> 00:01:05,860
+registration form. Students might use the course management
+
+22
+00:01:05,860 --> 00:01:08,460
+system to add or drop courses for a
+
+23
+00:01:08,460 --> 00:01:11,660
+period of time after registration. Professors use the
+
+24
+00:01:11,660 --> 00:01:15,250
+system to receive their course offering rosters. Finally,
+
+25
+00:01:15,250 --> 00:01:19,280
+users of the registration system are assigned passwords which are used for
+
+26
+00:01:19,280 --> 00:01:21,882
+login validation. So, as you can see, this is a kind of a
+
+27
+00:01:21,882 --> 00:01:25,440
+high-level description of a standard course management system. So, if you ever
+
+28
+00:01:25,440 --> 00:01:27,160
+used a course management system, you'll
+
+29
+00:01:27,160 --> 00:01:29,836
+recognize some of the functionality described here.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/12 - UML Structural Diagrams:  Class Diagram - lang_en_vs4.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/12 - UML Structural Diagrams:  Class Diagram - lang_en_vs4.srt
new file mode 100644
index 0000000..b2c9579
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/12 - UML Structural Diagrams:  Class Diagram - lang_en_vs4.srt	
@@ -0,0 +1,47 @@
+1
+00:00:00,200 --> 00:00:04,410
+Let's now start talking about UML, the Unified Modeling Language.
+
+2
+00:00:04,410 --> 00:00:06,530
+And we are going to start by looking at UML
+
+3
+00:00:06,530 --> 00:00:11,390
+structural diagrams. This are the diagrams that represent static characteristics
+
+4
+00:00:11,390 --> 00:00:13,430
+of the system that we need to model. This is
+
+5
+00:00:13,430 --> 00:00:17,170
+in contrast with dynamic models which instead behaviors of the
+
+6
+00:00:17,170 --> 00:00:19,200
+system that we need to model. And we will also
+
+7
+00:00:19,200 --> 00:00:22,424
+discuss dynamic models, later on in the lesson. We're going
+
+8
+00:00:22,424 --> 00:00:25,670
+to discuss several kinds of diagrams, starting from the class
+
+9
+00:00:25,670 --> 00:00:28,228
+diagram, which is a fundamental one in UML.
+
+10
+00:00:28,228 --> 00:00:31,390
+The class diagram represents a static, structural view of
+
+11
+00:00:31,390 --> 00:00:34,190
+the system, and it describes the classes and their
+
+12
+00:00:34,190 --> 00:00:37,630
+structure, and the relationships among classes in the system.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/13 - Class Diagram: Class - lang_en_vs5.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/13 - Class Diagram: Class - lang_en_vs5.srt
new file mode 100644
index 0000000..b02e6ea
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/13 - Class Diagram: Class - lang_en_vs5.srt	
@@ -0,0 +1,259 @@
+1
+00:00:00,120 --> 00:00:02,370
+So how do we represent a class in a class
+
+2
+00:00:02,370 --> 00:00:06,140
+diagram? Class is represented as a rectangle with three parts. The
+
+3
+00:00:06,140 --> 00:00:09,290
+first part is the class name. Classes should be named using
+
+4
+00:00:09,290 --> 00:00:12,160
+the vocabulary of the domain, so we should pick names that
+
+5
+00:00:12,160 --> 00:00:16,059
+make sense. And the normal naming standard requires that the classes
+
+6
+00:00:16,059 --> 00:00:19,720
+are singular nouns starting with a capital letter. The second part
+
+7
+00:00:19,720 --> 00:00:22,840
+of the class are the attributes of the class, where the
+
+8
+00:00:22,840 --> 00:00:25,310
+set of attribute for the class, we find the state for
+
+9
+00:00:25,310 --> 00:00:27,940
+the class. And, we can list an attribute simply by
+
+10
+00:00:27,940 --> 00:00:31,060
+name, or we can provide the additional information. For example,
+
+11
+00:00:31,060 --> 00:00:33,520
+we might define the title of the attribute, and we
+
+12
+00:00:33,520 --> 00:00:37,450
+might also define the initial. Value for the attribute. Finally, the
+
+13
+00:00:37,450 --> 00:00:40,850
+third part of the class consist of the operations of
+
+14
+00:00:40,850 --> 00:00:44,050
+the class. And normally, the operations of the class are represented
+
+15
+00:00:44,050 --> 00:00:47,090
+by name, with a list of arguments. That the operation
+
+16
+00:00:47,090 --> 00:00:50,340
+will take as input, and with a result type. So the
+
+17
+00:00:50,340 --> 00:00:53,750
+type of the result produced by the operation. Something
+
+18
+00:00:53,750 --> 00:00:55,940
+else you can notice in this representation is the
+
+19
+00:00:55,940 --> 00:00:58,450
+fact that there is a minus before these attributes
+
+20
+00:00:58,450 --> 00:01:01,810
+and a plus before this operation. This indicates what is
+
+21
+00:01:01,810 --> 00:01:04,739
+called the visibility of these class members. So the
+
+22
+00:01:04,739 --> 00:01:08,950
+minus indicates that the attributes are private to the class.
+
+23
+00:01:08,950 --> 00:01:12,600
+So only instances of this class, roughly speaking, can
+
+24
+00:01:12,600 --> 00:01:15,340
+access these attributes. And notice that this is what allows
+
+25
+00:01:15,340 --> 00:01:19,030
+to enforce the information hiding principle, because clients of
+
+26
+00:01:19,030 --> 00:01:22,000
+the class cannot see what's inside this box, what are
+
+27
+00:01:22,000 --> 00:01:25,360
+these attributes. The plus conversely indicates that this is a
+
+28
+00:01:25,360 --> 00:01:28,850
+public operation. So something that is visible outside the class.
+
+29
+00:01:28,850 --> 00:01:30,790
+And, in fact, normally, this is what we use to
+
+30
+00:01:30,790 --> 00:01:35,110
+define the interface for my class. So we encapsulate the
+
+31
+00:01:35,110 --> 00:01:37,730
+state of the class and we make it accessible to
+
+32
+00:01:37,730 --> 00:01:40,370
+the extent that we want and that is needed through
+
+33
+00:01:40,370 --> 00:01:43,850
+a set of public operations. Last thing I want to
+
+34
+00:01:43,850 --> 00:01:46,730
+note is the use of these ellipses that we can
+
+35
+00:01:46,730 --> 00:01:49,520
+utilize if we want to indicate that there are more
+
+36
+00:01:49,520 --> 00:01:52,400
+attributes for example, or more operations. But we just don't
+
+37
+00:01:52,400 --> 00:01:55,160
+want to list them now. Okay now that we know what
+
+38
+00:01:55,160 --> 00:01:58,020
+a class is, and how it is represented, let's start
+
+39
+00:01:58,020 --> 00:02:02,150
+our analysis of our course management system. By identifying the
+
+40
+00:02:02,150 --> 00:02:05,530
+relevant classes in the system, we need to bring back the
+
+41
+00:02:05,530 --> 00:02:08,270
+description of our system. And what we want to
+
+42
+00:02:08,270 --> 00:02:10,389
+do, is that we want to go through the description
+
+43
+00:02:10,389 --> 00:02:14,840
+and underline the relevant nouns in the description. And here
+
+44
+00:02:14,840 --> 00:02:17,020
+I encourage you to stop the video and to do
+
+45
+00:02:17,020 --> 00:02:20,450
+the exercise of underlying such nouns yourself before listening to
+
+46
+00:02:20,450 --> 00:02:23,910
+my explanation into how I do it. For example in
+
+47
+00:02:23,910 --> 00:02:28,030
+this case I might want to underlined the registration manager which
+
+48
+00:02:28,030 --> 00:02:30,820
+is a noun and probably a relevant one. The scheduling
+
+49
+00:02:30,820 --> 00:02:33,800
+algorithm, also seems like a relevant concept, so
+
+50
+00:02:33,800 --> 00:02:37,890
+is the course. The course offerings, again, course offerings
+
+51
+00:02:37,890 --> 00:02:40,930
+over here. Definitely, the students seem to be a
+
+52
+00:02:40,930 --> 00:02:44,750
+relevant noun and so is probably the registration form
+
+53
+00:02:44,750 --> 00:02:47,140
+and the professors. Okay, so, at this point, I
+
+54
+00:02:47,140 --> 00:02:50,630
+identified seven possible classes for my system. So, what
+
+55
+00:02:50,630 --> 00:02:53,340
+I'm going to do is simply to create classes for
+
+56
+00:02:53,340 --> 00:02:55,980
+each one of these nouns. So my initial class
+
+57
+00:02:55,980 --> 00:03:00,100
+diagram looks exactly like this, with the seven classes where
+
+58
+00:03:00,100 --> 00:03:03,140
+for each class, I picked the name that is representative of
+
+59
+00:03:03,140 --> 00:03:05,680
+the domain. So, in this case, it's pretty straightforward. The
+
+60
+00:03:05,680 --> 00:03:08,950
+registration form is called registration form, the student is called student
+
+61
+00:03:08,950 --> 00:03:10,780
+and so on and so forth. But you can already
+
+62
+00:03:10,780 --> 00:03:14,490
+see how this analysis method is starting from a description of
+
+63
+00:03:14,490 --> 00:03:17,950
+the real world and it's just identifying objects or classes
+
+64
+00:03:17,950 --> 00:03:21,240
+in the real world and transforming them into entities in my
+
+65
+00:03:21,240 --> 00:03:22,260
+analysis document.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/14 - Class Diagram: Attributes - lang_en_vs5.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/14 - Class Diagram: Attributes - lang_en_vs5.srt
new file mode 100644
index 0000000..e1230c9
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/14 - Class Diagram: Attributes - lang_en_vs5.srt	
@@ -0,0 +1,135 @@
+1
+00:00:00,090 --> 00:00:02,435
+Now that we identify the classes in my system,
+
+2
+00:00:02,435 --> 00:00:04,930
+let's see how we can identify the attributes for
+
+3
+00:00:04,930 --> 00:00:08,680
+these classes. First of all let's recall what attributes
+
+4
+00:00:08,680 --> 00:00:12,355
+are. Attributes represent the structure of a class the individual
+
+5
+00:00:12,355 --> 00:00:15,530
+data items that compose the state of the class.
+
+6
+00:00:15,530 --> 00:00:18,530
+So how do we identify these attributes? Attributes may be
+
+7
+00:00:18,530 --> 00:00:21,070
+found in one of three ways. By examining class
+
+8
+00:00:21,070 --> 00:00:25,330
+definitions, by studying the requirements, and by applying domain knowledge.
+
+9
+00:00:25,330 --> 00:00:28,400
+And notice that I want to stress, that this is always
+
+10
+00:00:28,400 --> 00:00:31,800
+a very important aspect. No matter what kind of system you're
+
+11
+00:00:31,800 --> 00:00:35,670
+developing. Domain knowledge tends to be fairly important to identify things
+
+12
+00:00:35,670 --> 00:00:38,200
+Which might not be provided in the descriptions of the system
+
+13
+00:00:38,200 --> 00:00:41,070
+that tend to be incomplete. And that you can derive by
+
+14
+00:00:41,070 --> 00:00:44,390
+the fact that you are familiar with the domain. So always
+
+15
+00:00:44,390 --> 00:00:47,340
+keep in mind the domain knowledge is important for analysis, for
+
+16
+00:00:47,340 --> 00:00:50,430
+design, for requirements gathering and so on. So now let's go
+
+17
+00:00:50,430 --> 00:00:53,530
+back to our description of the system. As I said,
+
+18
+00:00:53,530 --> 00:00:55,450
+I will bring you back for each step of our
+
+19
+00:00:55,450 --> 00:00:58,200
+analysis. And in this case, we're going to focus on
+
+20
+00:00:58,200 --> 00:01:01,550
+course offering. And we can say that the course offering, according
+
+21
+00:01:01,550 --> 00:01:04,610
+to the description, has a number, a location, and a
+
+22
+00:01:04,610 --> 00:01:08,140
+time. So this is a pretty clear indication that these are
+
+23
+00:01:08,140 --> 00:01:11,650
+important aspects of the course offering. So they probably should
+
+24
+00:01:11,650 --> 00:01:15,600
+become attributes of the course offering class. So now if we
+
+25
+00:01:15,600 --> 00:01:19,400
+report here that sentence, and once more, we underline
+
+26
+00:01:19,400 --> 00:01:22,330
+the information that we underlined in the description. We can
+
+27
+00:01:22,330 --> 00:01:25,540
+clearly see how this can be mapped into the definition
+
+28
+00:01:25,540 --> 00:01:28,730
+of the class. So our class course offering after this
+
+29
+00:01:28,730 --> 00:01:32,900
+step the analysis will have 3 attributes: number, location, and
+
+30
+00:01:32,900 --> 00:01:35,270
+time. And as you can see here, I'm not specifying
+
+31
+00:01:35,270 --> 00:01:37,540
+the type or any other additional information. So in this
+
+32
+00:01:37,540 --> 00:01:40,640
+first step I'm just interested in having a first draft.
+
+33
+00:01:40,640 --> 00:01:42,170
+of the class diagram, that I can then
+
+34
+00:01:42,170 --> 00:01:44,440
+refine in the next iterations of my analysis.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/15 - Class Diagram: Operations - lang_en_vs5.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/15 - Class Diagram: Operations - lang_en_vs5.srt
new file mode 100644
index 0000000..8943fca
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/15 - Class Diagram: Operations - lang_en_vs5.srt	
@@ -0,0 +1,111 @@
+1
+00:00:00,110 --> 00:00:02,920
+At this point we have our classes, our attributes,
+
+2
+00:00:02,920 --> 00:00:05,740
+what we're missing is the operations for the class.
+
+3
+00:00:05,740 --> 00:00:08,340
+Let me remind you that operations represent the behavior
+
+4
+00:00:08,340 --> 00:00:10,370
+of a class, and that they may be found by
+
+5
+00:00:10,370 --> 00:00:14,310
+examining interactions among entities in the description of my
+
+6
+00:00:14,310 --> 00:00:18,480
+system. So once more, let's bring back our description, and
+
+7
+00:00:18,480 --> 00:00:22,090
+let's in this case focus on this specific item.
+
+8
+00:00:22,090 --> 00:00:25,330
+That says that the students may use the system to
+
+9
+00:00:25,330 --> 00:00:29,800
+add courses. So this is clearly indicating an action
+
+10
+00:00:29,800 --> 00:00:32,320
+that the students should be able to perform. But notice
+
+11
+00:00:32,320 --> 00:00:35,100
+that this doesn't mean that this is an operation that
+
+12
+00:00:35,100 --> 00:00:38,370
+should be provided by the student's class. It rather means
+
+13
+00:00:38,370 --> 00:00:41,860
+that there should be, somewhere in the system, the possibility
+
+14
+00:00:41,860 --> 00:00:45,080
+of performing this operation. So let's see what this means
+
+15
+00:00:45,080 --> 00:00:47,920
+for our example. This might mean, for example, if we
+
+16
+00:00:47,920 --> 00:00:50,400
+focus on the RegistrationManager, so that there should be an
+
+17
+00:00:50,400 --> 00:00:53,520
+operation in the RegistrationManager that allows me to add
+
+18
+00:00:53,520 --> 00:00:56,300
+a student to a course. And this, in turn, means
+
+19
+00:00:56,300 --> 00:01:00,270
+that both Course and CourseOffering should provide a way to
+
+20
+00:01:00,270 --> 00:01:04,140
+add a student. And therefore, I add this corresponding operation
+
+21
+00:01:04,140 --> 00:01:07,790
+to the RegistrationManager, to the Course, and to the CourseOffering.
+
+22
+00:01:07,790 --> 00:01:10,020
+So after doing that we will continue and populate in
+
+23
+00:01:10,020 --> 00:01:13,080
+a similar way, the other classes in the system. So
+
+24
+00:01:13,080 --> 00:01:16,040
+let me recap. Now we saw how to identify classes.
+
+25
+00:01:16,040 --> 00:01:18,300
+How to identify members of the classes, and
+
+26
+00:01:18,300 --> 00:01:21,910
+particular attributes, and operations. There is one thing that
+
+27
+00:01:21,910 --> 00:01:24,060
+we're missing, a very important aspect of the
+
+28
+00:01:24,060 --> 00:01:28,140
+class diagram which is the relationships between these classes.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/16 - Class Diagram: Relationships - lang_en_vs5.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/16 - Class Diagram: Relationships - lang_en_vs5.srt
new file mode 100644
index 0000000..ef6550d
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/16 - Class Diagram: Relationships - lang_en_vs5.srt	
@@ -0,0 +1,111 @@
+1
+00:00:00,130 --> 00:00:02,620
+And that's exactly what we're going to look at next,
+
+2
+00:00:02,620 --> 00:00:05,630
+relationships in the class diagram, how they're represented and
+
+3
+00:00:05,630 --> 00:00:08,010
+what they mean. First of all relationships as the
+
+4
+00:00:08,010 --> 00:00:12,550
+name says, describe interactions between classes or between objects in
+
+5
+00:00:12,550 --> 00:00:15,510
+my system. And we will describe three main types
+
+6
+00:00:15,510 --> 00:00:19,060
+of relationships. The first one is called a Dependency
+
+7
+00:00:19,060 --> 00:00:22,450
+relationship. And we can express that as X uses
+
+8
+00:00:22,450 --> 00:00:25,840
+Y and we represent it with a dashed directed line.
+
+9
+00:00:25,840 --> 00:00:28,170
+So when we have such a line between two classes
+
+10
+00:00:28,170 --> 00:00:31,020
+that means that the first class uses the second one. And
+
+11
+00:00:31,020 --> 00:00:33,520
+we're going to provide an example of a dependency in a
+
+12
+00:00:33,520 --> 00:00:37,960
+minute. The second type of relationship is an association that can
+
+13
+00:00:37,960 --> 00:00:40,880
+also be an aggregation. We'll see what the distinction is.
+
+14
+00:00:40,880 --> 00:00:43,470
+But basically, what this means is that we can express that
+
+15
+00:00:43,470 --> 00:00:47,640
+as a X has a y. So x contains a
+
+16
+00:00:47,640 --> 00:00:50,950
+y. And if it is in association, we indicate it with
+
+17
+00:00:50,950 --> 00:00:53,570
+a solid undirected line. If it's an aggregation,
+
+18
+00:00:53,570 --> 00:00:55,740
+we indicate it in the same way, but with
+
+19
+00:00:55,740 --> 00:00:58,510
+a diamond at one of the ends. Finally, the
+
+20
+00:00:58,510 --> 00:01:02,740
+third type of relationship is what is called Generalization.
+
+21
+00:01:02,740 --> 00:01:05,300
+And this can be expressed as x is a
+
+22
+00:01:05,300 --> 00:01:09,620
+y. So this is the relationship that expresses inheritance.
+
+23
+00:01:09,620 --> 00:01:13,600
+Specialization between two classes. It's represented with a solid
+
+24
+00:01:13,600 --> 00:01:16,190
+directed line with a large open arrow head at
+
+25
+00:01:16,190 --> 00:01:19,030
+the end. Going from the more specialized class to
+
+26
+00:01:19,030 --> 00:01:21,770
+the less specialized class. So going from the subclass to
+
+27
+00:01:21,770 --> 00:01:24,740
+the super class. So now let's look at each relationship
+
+28
+00:01:24,740 --> 00:01:28,360
+in more detail using our example, our course management system.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/17 - Class Diagram Relationships Quiz - lang_en_vs4.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/17 - Class Diagram Relationships Quiz - lang_en_vs4.srt
new file mode 100644
index 0000000..90ffe63
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/17 - Class Diagram Relationships Quiz - lang_en_vs4.srt	
@@ -0,0 +1,55 @@
+1
+00:00:00,200 --> 00:00:02,840
+Before doing that, though, now that we discuss the different kinds
+
+2
+00:00:02,840 --> 00:00:05,510
+of relationships among classes in the class diagram. I would like
+
+3
+00:00:05,510 --> 00:00:08,230
+to ask you to look at a list of relationships that
+
+4
+00:00:08,230 --> 00:00:11,920
+I'm providing here and mark the relationships that you think actually
+
+5
+00:00:11,920 --> 00:00:15,120
+hold for the classes in the system that we are modeling.
+
+6
+00:00:15,120 --> 00:00:18,260
+So here I have a list of possible relationships for each
+
+7
+00:00:18,260 --> 00:00:22,070
+relationship. I'm first defining what the relationship is and then what
+
+8
+00:00:22,070 --> 00:00:25,270
+kind of relationship that is, for example, for the first one I'm
+
+9
+00:00:25,270 --> 00:00:27,500
+saying that the registration manager uses
+
+10
+00:00:27,500 --> 00:00:30,090
+the scheduling algorithm, which is a dependency
+
+11
+00:00:30,090 --> 00:00:33,860
+relationship. And similarly for the other ones. So like for you to go back
+
+12
+00:00:33,860 --> 00:00:37,070
+to the example, look at the classes that we defined, think about the
+
+13
+00:00:37,070 --> 00:00:40,360
+requirements, and identify which ones of this
+
+14
+00:00:40,360 --> 00:00:42,610
+relationships you think hold in the system.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/18 - Class Diagram Relationships Quiz Solution - lang_en_vs5.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/18 - Class Diagram Relationships Quiz Solution - lang_en_vs5.srt
new file mode 100644
index 0000000..ca674bf
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/18 - Class Diagram Relationships Quiz Solution - lang_en_vs5.srt	
@@ -0,0 +1,23 @@
+1
+00:00:00,130 --> 00:00:02,130
+So, I'm going to start by marking the
+
+2
+00:00:02,130 --> 00:00:04,920
+relationships that actually hold in the system.
+
+3
+00:00:04,920 --> 00:00:08,860
+Which are these ones. And then what I'm going to do, I'm going to explain this
+
+4
+00:00:08,860 --> 00:00:12,480
+answers. Not here but in the next part of this lesson. By looking at the
+
+5
+00:00:12,480 --> 00:00:14,860
+different relationships in the context of our
+
+6
+00:00:14,860 --> 00:00:17,240
+example. Which will make the explanation much clearer.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/19 - Class Diagram: Dependency Relationship - lang_en_vs4.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/19 - Class Diagram: Dependency Relationship - lang_en_vs4.srt
new file mode 100644
index 0000000..54c7da3
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/19 - Class Diagram: Dependency Relationship - lang_en_vs4.srt	
@@ -0,0 +1,71 @@
+1
+00:00:00,110 --> 00:00:03,040
+So let's start with the dependency example. A dependency,
+
+2
+00:00:03,040 --> 00:00:06,720
+as we said, expresses the relationship between a supplier
+
+3
+00:00:06,720 --> 00:00:09,290
+and a client that relies on it. There is
+
+4
+00:00:09,290 --> 00:00:12,490
+a dependency because changes in the supplier can affect the
+
+5
+00:00:12,490 --> 00:00:14,770
+client. Here in this example I am showing that
+
+6
+00:00:14,770 --> 00:00:18,510
+a dependency example involving the registration manager and the
+
+7
+00:00:18,510 --> 00:00:21,590
+scheduling algorithm. As you can see the, the dependency
+
+8
+00:00:21,590 --> 00:00:25,710
+is indicated with a dashed line pointing from the client
+
+9
+00:00:25,710 --> 00:00:28,520
+to the supplier. And here it's pretty clear why
+
+10
+00:00:28,520 --> 00:00:31,820
+the RegistrationManager is dependent on the Scheduling Algorithm. It's
+
+11
+00:00:31,820 --> 00:00:35,710
+because the RegistrationManager uses this Scheduling Algorithm. And therefore,
+
+12
+00:00:35,710 --> 00:00:39,130
+if the Scheduling Algorithm changes, the RegistrationManager might be
+
+13
+00:00:39,130 --> 00:00:42,210
+affected by that change. Another less obvious example is
+
+14
+00:00:42,210 --> 00:00:45,600
+the dependency between the Registration Manager and the Student.
+
+15
+00:00:45,600 --> 00:00:48,040
+In this case, because the Registration Manager gets a
+
+16
+00:00:48,040 --> 00:00:51,620
+Student object as a parameter here there is a dependency
+
+17
+00:00:51,620 --> 00:00:55,740
+between the two. Again, if the Student class were to change the Registration
+
+18
+00:00:55,740 --> 00:01:00,270
+Manager might be affected because it's relying on the Student for it's behavior.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/2 - Object Orientation Introduction - lang_en_vs5.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/2 - Object Orientation Introduction - lang_en_vs5.srt
new file mode 100644
index 0000000..44fdd74
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/2 - Object Orientation Introduction - lang_en_vs5.srt	
@@ -0,0 +1,187 @@
+1
+00:00:00,390 --> 00:00:03,750
+Let's start with a quick introduction to object orientation and
+
+2
+00:00:03,750 --> 00:00:07,920
+the fundamental concepts behind it. And let's start by discussing what
+
+3
+00:00:07,920 --> 00:00:11,100
+exactly is object orientation? If you're younger than me, it
+
+4
+00:00:11,100 --> 00:00:13,700
+could be that the first programming language you learned was already
+
+5
+00:00:13,700 --> 00:00:17,030
+an object-oriented language. But things were not always like this.
+
+6
+00:00:17,030 --> 00:00:20,660
+Before object orientation became prevalent, people were not used to thinking
+
+7
+00:00:20,660 --> 00:00:23,447
+in terms of objects. So what happened afterwards? And what does
+
+8
+00:00:23,447 --> 00:00:25,727
+it mean to think in terms of objects and to follow
+
+9
+00:00:25,727 --> 00:00:28,583
+an object-oriented approach? First of all, it
+
+10
+00:00:28,583 --> 00:00:32,203
+means to give precedence of data over function.
+
+11
+00:00:32,203 --> 00:00:35,377
+Did items rather than functionality become the center
+
+12
+00:00:35,377 --> 00:00:39,020
+of development activities. This also allows for enforcing
+
+13
+00:00:39,020 --> 00:00:42,200
+the very important concept of information hiding,
+
+14
+00:00:42,200 --> 00:00:45,460
+which is the encapsulation and segregation of data
+
+15
+00:00:45,460 --> 00:00:49,710
+behind well-defined and ideally stable interfaces. In order
+
+16
+00:00:49,710 --> 00:00:51,490
+to be able to hide the design and
+
+17
+00:00:51,490 --> 00:00:54,130
+also implementation decisions. And note that the terms
+
+18
+00:00:54,130 --> 00:00:58,580
+encapsulation and information hiding are often used interchangeably, although
+
+19
+00:00:58,580 --> 00:01:01,270
+some people prefer to think of information hiding
+
+20
+00:01:01,270 --> 00:01:04,709
+as being the principle and encapsulation being the technique
+
+21
+00:01:04,709 --> 00:01:07,990
+to achieve information hiding. The key concept though,
+
+22
+00:01:07,990 --> 00:01:10,110
+no matter which term you use, is really to
+
+23
+00:01:10,110 --> 00:01:13,460
+gather, to seclude this data behind sort of
+
+24
+00:01:13,460 --> 00:01:16,610
+a wall and give access to the data only
+
+25
+00:01:16,610 --> 00:01:20,270
+through interfaces that you, the developer define. And why is
+
+26
+00:01:20,270 --> 00:01:22,800
+that important? Oh, for many reasons, and one of the main
+
+27
+00:01:22,800 --> 00:01:26,690
+ones is that it makes code more maintainable. Because the
+
+28
+00:01:26,690 --> 00:01:28,860
+rest of the code, the rest of the system doesn't have
+
+29
+00:01:28,860 --> 00:01:32,370
+to be concerned on how the implementation details or the
+
+30
+00:01:32,370 --> 00:01:37,220
+design are defined. And therefore, any change that happens behind this
+
+31
+00:01:37,220 --> 00:01:39,580
+wall doesn't concern the rest of the system. And, doesn't
+
+32
+00:01:39,580 --> 00:01:41,820
+affect the rest of the system, as long as you keep
+
+33
+00:01:41,820 --> 00:01:45,730
+your interfaces consistent. Another advantage of focusing on
+
+34
+00:01:45,730 --> 00:01:49,230
+objects and encapsulating the information into cohesive entities is
+
+35
+00:01:49,230 --> 00:01:52,130
+that it allows the reuse of object definitions
+
+36
+00:01:52,130 --> 00:01:55,000
+by incremental refinement. Which is what we normally call
+
+37
+00:01:55,000 --> 00:01:58,830
+inheritance. And inheritance is definitely a fundamental concept
+
+38
+00:01:58,830 --> 00:02:01,560
+in object orientation. For example, we can define a
+
+39
+00:02:01,560 --> 00:02:04,030
+car as a refinement of the vehicle. That there's
+
+40
+00:02:04,030 --> 00:02:06,850
+some additional characteristics with respect to a generic vehicle.
+
+41
+00:02:06,850 --> 00:02:11,220
+And then we can use the car wherever a vehicle can be used, which is what we
+
+42
+00:02:11,220 --> 00:02:14,200
+call polymorphism. And we'll continue this discussion for a
+
+43
+00:02:14,200 --> 00:02:16,440
+very long time. Because there's so many things that
+
+44
+00:02:16,440 --> 00:02:18,860
+could be discussed when we talk about object orientation,
+
+45
+00:02:18,860 --> 00:02:21,890
+its characteristics and its advantages. But in the interest
+
+46
+00:02:21,890 --> 00:02:24,000
+of time, let's for now just stop here. And
+
+47
+00:02:24,000 --> 00:02:27,020
+start talking about two key concepts in object orientation.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/20 - Class Diagram: Association & Aggregation Relationships - lang_en_vs5.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/20 - Class Diagram: Association & Aggregation Relationships - lang_en_vs5.srt
new file mode 100644
index 0000000..8770928
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/20 - Class Diagram: Association & Aggregation Relationships - lang_en_vs5.srt	
@@ -0,0 +1,219 @@
+1
+00:00:00,080 --> 00:00:02,469
+The next example of relationship we're going to look at is
+
+2
+00:00:02,469 --> 00:00:06,740
+the association relationship. This is a relationship in which objects of
+
+3
+00:00:06,740 --> 00:00:09,570
+one class are connected to objects of another. And it's
+
+4
+00:00:09,570 --> 00:00:12,480
+called an has a relationship. So it means that objects of
+
+5
+00:00:12,480 --> 00:00:15,930
+one class have objects of another class. So let's see
+
+6
+00:00:15,930 --> 00:00:18,750
+what that means. Let's do it by considering two classes in
+
+7
+00:00:18,750 --> 00:00:22,370
+our example system. The student class and the course offering class.
+
+8
+00:00:22,370 --> 00:00:25,300
+In this case, there is an association between the student and
+
+9
+00:00:25,300 --> 00:00:28,010
+the course offering, because the student is registering for the
+
+10
+00:00:28,010 --> 00:00:31,750
+course offering. So, in a sense, the course offering has students.
+
+11
+00:00:31,750 --> 00:00:35,360
+Contains students, to indicate this fact we add a solid
+
+12
+00:00:35,360 --> 00:00:38,750
+line between the student class and the course offering. And the
+
+13
+00:00:38,750 --> 00:00:40,540
+fact that having a solid line doesn't really tell us
+
+14
+00:00:40,540 --> 00:00:44,780
+much about the nature of the relationship, so to clarify such
+
+15
+00:00:44,780 --> 00:00:47,550
+nature we can use what we call adornments that we
+
+16
+00:00:47,550 --> 00:00:51,010
+can apply to associations we can add to associations to clarify
+
+17
+00:00:51,010 --> 00:00:53,850
+their meaning. In particular we can add a label to
+
+18
+00:00:53,850 --> 00:00:57,550
+an association and the label describes the nature of the relationship.
+
+19
+00:00:57,550 --> 00:01:00,440
+In this case, for example, it clarifies that the student
+
+20
+00:01:00,440 --> 00:01:03,970
+registers for CourseOffering. We can also add a triangle to
+
+21
+00:01:03,970 --> 00:01:07,050
+further clarify the direction of the relationship. So in this
+
+22
+00:01:07,050 --> 00:01:10,240
+case, the triangle will indicate that it's the student That registers
+
+23
+00:01:10,240 --> 00:01:13,120
+for the course offering, and not the other way around. Another
+
+24
+00:01:13,120 --> 00:01:16,650
+important adornment or limitation that we can put on an association,
+
+25
+00:01:16,650 --> 00:01:20,800
+is multiplicity. Multiplicity defines the number of instances of one
+
+26
+00:01:20,800 --> 00:01:23,540
+class that are related to one instance of the other
+
+27
+00:01:23,540 --> 00:01:26,900
+class. We can define multiplicity at either end of the
+
+28
+00:01:26,900 --> 00:01:29,620
+relationship. In this case, for instance, we can say that
+
+29
+00:01:29,620 --> 00:01:31,890
+if we look at the student, the student can register
+
+30
+00:01:31,890 --> 00:01:35,410
+for two or more course offerings. Whereas, if we look
+
+31
+00:01:35,410 --> 00:01:37,560
+at the course offering, we can say that each course
+
+32
+00:01:37,560 --> 00:01:42,260
+offering can have or can enroll between 1 and 50 students.
+
+33
+00:01:42,260 --> 00:01:45,120
+So as you can see by adding a label, a direction,
+
+34
+00:01:45,120 --> 00:01:49,590
+and multiplicity, we make it much clearer what the relationship is
+
+35
+00:01:49,590 --> 00:01:52,170
+and what it means and what are its characteristics. As we
+
+36
+00:01:52,170 --> 00:01:55,130
+saw when we introduced relationships, there is a different kind of
+
+37
+00:01:55,130 --> 00:01:58,860
+association, kind of a specialized one, which we call aggregation. So
+
+38
+00:01:58,860 --> 00:02:01,130
+here we're going to look at an example of an aggregation. So
+
+39
+00:02:01,130 --> 00:02:03,490
+first of all what is an aggregation? An aggregation is a
+
+40
+00:02:03,490 --> 00:02:07,580
+relationship between 2 classes in which 1 represents a larger class
+
+41
+00:02:07,580 --> 00:02:10,610
+like a whole which consists of smaller classes which are
+
+42
+00:02:10,610 --> 00:02:13,430
+the parts of this whole. So lets look at an example
+
+43
+00:02:13,430 --> 00:02:16,960
+in the context of our system. Let's consider a Course
+
+44
+00:02:16,960 --> 00:02:19,160
+and the CourseOffering. And in this case, we can see
+
+45
+00:02:19,160 --> 00:02:23,000
+that the Course consists of multiple CourseOfferings. So in
+
+46
+00:02:23,000 --> 00:02:26,520
+a sense, a course is a whole and the course offerings
+
+47
+00:02:26,520 --> 00:02:29,430
+are the parts of this whole. So this a perfect case
+
+48
+00:02:29,430 --> 00:02:32,620
+in which we will use an aggregation to express this relationship.
+
+49
+00:02:32,620 --> 00:02:37,630
+So we will add a solid line with a diamond on the side of the whole class
+
+50
+00:02:37,630 --> 00:02:42,380
+to indicate that the course consists of multiple course offerings.
+
+51
+00:02:42,380 --> 00:02:44,670
+And as we did for associations even though we
+
+52
+00:02:44,670 --> 00:02:46,010
+are not going to do it for this specific
+
+53
+00:02:46,010 --> 00:02:49,540
+example, we could also in this case add multiplicity
+
+54
+00:02:49,540 --> 00:02:52,830
+information on the aggregation to indicate how many classes
+
+55
+00:02:52,830 --> 00:02:55,310
+of the two types are involved in the relationships.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/21 - Class Diagram: Generalization Relationship - lang_en_vs5.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/21 - Class Diagram: Generalization Relationship - lang_en_vs5.srt
new file mode 100644
index 0000000..513413b
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/21 - Class Diagram: Generalization Relationship - lang_en_vs5.srt	
@@ -0,0 +1,75 @@
+1
+00:00:00,100 --> 00:00:02,420
+The third type of relationship that we saw, is
+
+2
+00:00:02,420 --> 00:00:07,060
+Generalization. Generalization is a relationship, between a general class,
+
+3
+00:00:07,060 --> 00:00:10,150
+which we normally call super-class and the more specific
+
+4
+00:00:10,150 --> 00:00:13,510
+class, a class the refines the super-class and that
+
+5
+00:00:13,510 --> 00:00:16,950
+we normally call sub-class. It's also known as a
+
+6
+00:00:16,950 --> 00:00:19,690
+kind of or is a relationship because we can
+
+7
+00:00:19,690 --> 00:00:22,850
+say that the subclass is a super class and
+
+8
+00:00:22,850 --> 00:00:25,450
+it's expressed with a solid line with a big arrow
+
+9
+00:00:25,450 --> 00:00:27,580
+head at the end. So let's see an example of
+
+10
+00:00:27,580 --> 00:00:30,160
+that. In this case I'm going to indicate. Two of this kind
+
+11
+00:00:30,160 --> 00:00:33,950
+of relationships. The first one involving the RegistrationUser and
+
+12
+00:00:33,950 --> 00:00:37,000
+a student. And the second one, a RegistrationUser and the
+
+13
+00:00:37,000 --> 00:00:39,960
+professor. So, basically what we're showing here is a
+
+14
+00:00:39,960 --> 00:00:43,170
+typical case in which the registration user is a more general
+
+15
+00:00:43,170 --> 00:00:46,630
+concept then the Student and the Professor. So both the student
+
+16
+00:00:46,630 --> 00:00:50,710
+and the professor are RegistrationUsers. So there is a relationship,
+
+17
+00:00:50,710 --> 00:00:54,360
+the Professor is a registration user and the Student is a RegistrationUser.
+
+18
+00:00:54,360 --> 00:00:56,780
+And therefore we can indicate that using
+
+19
+00:00:56,780 --> 00:01:00,040
+the generalization relationship in our class diagram.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/22 - Class Diagram: Creation Tips - lang_en_vs5.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/22 - Class Diagram: Creation Tips - lang_en_vs5.srt
new file mode 100644
index 0000000..8aa0204
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/22 - Class Diagram: Creation Tips - lang_en_vs5.srt	
@@ -0,0 +1,143 @@
+1
+00:00:00,140 --> 00:00:02,320
+The last thing that I want to mention about class diagrams is
+
+2
+00:00:02,320 --> 00:00:05,830
+some creation tips. So something I know based on my experience and the
+
+3
+00:00:05,830 --> 00:00:09,300
+experience of others, I can recommend to do when creating a class
+
+4
+00:00:09,300 --> 00:00:12,780
+diagram. So the first tip is to understand the problem. So take the
+
+5
+00:00:12,780 --> 00:00:15,070
+time to look at the description of the system that you have
+
+6
+00:00:15,070 --> 00:00:18,500
+to build, to make sure that you understand the domain. That you understand
+
+7
+00:00:18,500 --> 00:00:21,230
+what you are supposed to build. Because that is going to save you
+
+8
+00:00:21,230 --> 00:00:25,550
+time later. It's going to help you identify from the beginning, a more relevant
+
+9
+00:00:25,550 --> 00:00:28,370
+set of entities in the description of the system. This
+
+10
+00:00:28,370 --> 00:00:30,730
+one might seem trivial but is very important to choose
+
+11
+00:00:30,730 --> 00:00:34,910
+good class names. Why? Because class names communicate the intent
+
+12
+00:00:34,910 --> 00:00:37,770
+of the class, and clarify what the class refers to. So
+
+13
+00:00:37,770 --> 00:00:40,510
+having a good class name allows you, makes it easier, to
+
+14
+00:00:40,510 --> 00:00:44,390
+create the mapping between the real-world object and the entities in
+
+15
+00:00:44,390 --> 00:00:46,610
+your model. And of course, it also makes it easier
+
+16
+00:00:46,610 --> 00:00:50,100
+to understand the system, after the system is built. Third tip,
+
+17
+00:00:50,100 --> 00:00:53,480
+concentrate on the what. So here, in the class diagram,
+
+18
+00:00:53,480 --> 00:00:57,390
+we're just representing the structure of the system. We're representing
+
+19
+00:00:57,390 --> 00:01:00,150
+what is in the system. What are the entities? What
+
+20
+00:01:00,150 --> 00:01:03,140
+are the characteristics of the entities? We are not focusing
+
+21
+00:01:03,140 --> 00:01:06,850
+at all, on how things are done. So, be careful.
+
+22
+00:01:06,850 --> 00:01:09,430
+Don’t think about the how, just think about the what.
+
+23
+00:01:09,430 --> 00:01:12,150
+Proceed in an itinerary way. So, start with a simple
+
+24
+00:01:12,150 --> 00:01:14,910
+diagram and refine it. There is no need to identify,
+
+25
+00:01:14,910 --> 00:01:17,650
+right away, all of the details of the system you need to
+
+26
+00:01:17,650 --> 00:01:21,570
+build. It is much easier to look at the description, identify an initial
+
+27
+00:01:21,570 --> 00:01:24,670
+rough class diagram and then refine it, because in this way, you'll
+
+28
+00:01:24,670 --> 00:01:27,650
+also gather more understanding of the system as you build it, and you'll
+
+29
+00:01:27,650 --> 00:01:30,670
+most likely end up with a better product at the end. And
+
+30
+00:01:30,670 --> 00:01:33,360
+if you proceed in this way, then make sure to refine until you
+
+31
+00:01:33,360 --> 00:01:36,920
+feel the class diagram is complete, until you feel that you represent
+
+32
+00:01:36,920 --> 00:01:39,960
+the system that you're supposed to build. So your final goal should be
+
+33
+00:01:39,960 --> 00:01:41,820
+to have a class diagram that is complete.
+
+34
+00:01:41,820 --> 00:01:43,870
+So it represents all of the relevant entities
+
+35
+00:01:43,870 --> 00:01:45,870
+in the system and their characteristics, and it's
+
+36
+00:01:45,870 --> 00:01:48,170
+correct so it represents them in the right way
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/23 - UML Structural Diagrams: Component Diagram - lang_en_vs5.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/23 - UML Structural Diagrams: Component Diagram - lang_en_vs5.srt
new file mode 100644
index 0000000..8ce2080
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/23 - UML Structural Diagrams: Component Diagram - lang_en_vs5.srt	
@@ -0,0 +1,235 @@
+1
+00:00:00,100 --> 00:00:02,160
+There's two more structural diagrams that I want to
+
+2
+00:00:02,160 --> 00:00:04,670
+mention before we move to the behavioral ones. The
+
+3
+00:00:04,670 --> 00:00:07,420
+first one's the component diagram. A component diagram is
+
+4
+00:00:07,420 --> 00:00:09,690
+a static view of components in a system and of
+
+5
+00:00:09,690 --> 00:00:13,010
+their relationships. More precisely, a node in a component
+
+6
+00:00:13,010 --> 00:00:16,700
+diagram represents a component where a component consists of one
+
+7
+00:00:16,700 --> 00:00:21,090
+or more classes with a well-defined interface. Edges conversely
+
+8
+00:00:21,090 --> 00:00:25,290
+indicate relationships between the components. You can read this relationship
+
+9
+00:00:25,290 --> 00:00:29,600
+as component A uses services of component B. And notice that the
+
+10
+00:00:29,600 --> 00:00:32,990
+component diagrams can be used to represent an architecture, which is
+
+11
+00:00:32,990 --> 00:00:36,110
+a topic that we will cover extensively in the next mini-course.
+
+12
+00:00:36,110 --> 00:00:39,540
+So let's illustrate this with an example. So, what I'm representing
+
+13
+00:00:39,540 --> 00:00:43,160
+here is a component diagram for our example system, the course
+
+14
+00:00:43,160 --> 00:00:46,220
+management system. And as you can see, it's slightly more complex
+
+15
+00:00:46,220 --> 00:00:48,390
+than the other diagrams that we saw. But there's really no
+
+16
+00:00:48,390 --> 00:00:50,700
+need to go through all the steps and all the details.
+
+17
+00:00:50,700 --> 00:00:53,470
+Important thing is to point out some key aspects of
+
+18
+00:00:53,470 --> 00:00:56,370
+this diagram. So the first one is that these rectangular
+
+19
+00:00:56,370 --> 00:00:58,560
+nodes are the nodes in the system, so are my
+
+20
+00:00:58,560 --> 00:01:02,960
+components. For example, student is a component, schedule is a component,
+
+21
+00:01:02,960 --> 00:01:05,069
+and so on. And as far as edges are concerned,
+
+22
+00:01:05,069 --> 00:01:08,580
+I'm representing two kinds of edges. The first kind of dashed
+
+23
+00:01:08,580 --> 00:01:12,060
+edges which were part of the original uml definition and
+
+24
+00:01:12,060 --> 00:01:16,120
+indicate use. So an edge, for example, between this compnent and
+
+25
+00:01:16,120 --> 00:01:19,570
+this compnent indicated that the seminar management uses the
+
+26
+00:01:19,570 --> 00:01:23,890
+facilities component. More recently, in UML two, a richer representation
+
+27
+00:01:23,890 --> 00:01:26,240
+was introduced, which is the one that I'm also showing
+
+28
+00:01:26,240 --> 00:01:27,860
+here. So if we look at this part of the
+
+29
+00:01:27,860 --> 00:01:29,540
+diagram, you can see this sort of you now,
+
+30
+00:01:29,540 --> 00:01:34,080
+lollipop socket representation. And in this case, what this represents,
+
+31
+00:01:34,080 --> 00:01:37,920
+is that a lollipop indicates a provided interface. So an
+
+32
+00:01:37,920 --> 00:01:41,500
+interface that is provided by the component. So, for example,
+
+33
+00:01:41,500 --> 00:01:45,940
+this security component provides encryption capabilities. The socket,
+
+34
+00:01:45,940 --> 00:01:49,190
+conversely, indicates a required interface. So, for example, in
+
+35
+00:01:49,190 --> 00:01:52,270
+this case, it's saying that the facilities component
+
+36
+00:01:52,270 --> 00:01:55,920
+is needing access control capabilities, which, by the way,
+
+37
+00:01:55,920 --> 00:01:58,660
+is provided by the security component. So in
+
+38
+00:01:58,660 --> 00:02:02,240
+a sense these sockets and lollipop indicate interfaces between
+
+39
+00:02:02,240 --> 00:02:04,770
+a provider of some of functionality, and the client
+
+40
+00:02:04,770 --> 00:02:06,630
+of that functionality and you can look at those
+
+41
+00:02:06,630 --> 00:02:09,740
+as basically APIs. So sets of methods that
+
+42
+00:02:09,740 --> 00:02:12,160
+provide a given functionality. To give you another
+
+43
+00:02:12,160 --> 00:02:14,760
+example, if we look at the persistence components
+
+44
+00:02:14,760 --> 00:02:19,110
+the persistence component provides, unsurprisingly, persistent services. And
+
+45
+00:02:19,110 --> 00:02:21,650
+those persistent services are required by several other
+
+46
+00:02:21,650 --> 00:02:24,520
+components in the system. And in turn, the persistent
+
+47
+00:02:24,520 --> 00:02:28,320
+components relies on the University database component to
+
+48
+00:02:28,320 --> 00:02:31,740
+provide such services. So, there's the University DB components
+
+49
+00:02:31,740 --> 00:02:34,700
+provide these sort of low-level database services that are used
+
+50
+00:02:34,700 --> 00:02:38,150
+by the persistence component To in turn provided services. Last thing
+
+51
+00:02:38,150 --> 00:02:41,080
+I want to note is that components or relationships can be
+
+52
+00:02:41,080 --> 00:02:44,450
+annotated, so, for example if we look at the seminar management
+
+53
+00:02:44,450 --> 00:02:47,090
+and the student administration components you can see that they
+
+54
+00:02:47,090 --> 00:02:51,360
+are annotated here to indicate that they are user inferfaces. So
+
+55
+00:02:51,360 --> 00:02:53,600
+that's all I wanted to say on the component diagrams, but
+
+56
+00:02:53,600 --> 00:02:56,750
+again the key piece of information is that they represent components
+
+57
+00:02:56,750 --> 00:03:00,250
+in the system where a component consists of one or more classes indicate the
+
+58
+00:03:00,250 --> 00:03:03,540
+interfaces that these components provide or require.
+
+59
+00:03:03,540 --> 00:03:06,210
+and describe the interactions between these components.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/24 - UML Structural Diagrams: Deployment - lang_en_vs4.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/24 - UML Structural Diagrams: Deployment - lang_en_vs4.srt
new file mode 100644
index 0000000..07c9a3e
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/24 - UML Structural Diagrams: Deployment - lang_en_vs4.srt	
@@ -0,0 +1,95 @@
+1
+00:00:00,100 --> 00:00:02,980
+The last UML structural diagram I want to discuss
+
+2
+00:00:02,980 --> 00:00:06,750
+is the deployment diagram. The deployment diagram provides a static
+
+3
+00:00:06,750 --> 00:00:10,220
+deployment view of a system, and unlike previous diagram,
+
+4
+00:00:10,220 --> 00:00:13,980
+it is about the physical allocation of components to computational
+
+5
+00:00:13,980 --> 00:00:16,950
+units. Think, for example, of a client-server system in
+
+6
+00:00:16,950 --> 00:00:19,130
+which you'll have to define which components will go on
+
+7
+00:00:19,130 --> 00:00:20,880
+the server and which component will go on the
+
+8
+00:00:20,880 --> 00:00:25,200
+client. For deployment diagram, the nodes correspond to computation unit;
+
+9
+00:00:25,200 --> 00:00:29,090
+for example, a specific device. And the edges indicate communication
+
+10
+00:00:29,090 --> 00:00:32,880
+between these units. Also in this case, I'm going to illustrate deployment
+
+11
+00:00:32,880 --> 00:00:36,720
+diagrams using an example for our course management system. And
+
+12
+00:00:36,720 --> 00:00:39,820
+also in this case, I'm going to use a slightly more complex
+
+13
+00:00:39,820 --> 00:00:41,910
+diagram than usual. But I don't want you to look
+
+14
+00:00:41,910 --> 00:00:45,170
+at all the individual details. Instead, I would like to focus
+
+15
+00:00:45,170 --> 00:00:47,530
+on a few main aspects. So, if you look at
+
+16
+00:00:47,530 --> 00:00:50,700
+this diagram, there are three things that you should clearly see.
+
+17
+00:00:50,700 --> 00:00:53,555
+First, you should see how the system involves four
+
+18
+00:00:53,555 --> 00:00:56,590
+nodes, a web server, an application server, a DB
+
+19
+00:00:56,590 --> 00:00:59,740
+server, and a mainframe. Second, you should see which
+
+20
+00:00:59,740 --> 00:01:03,500
+components are deployed on which nodes. For example, the student
+
+21
+00:01:03,500 --> 00:01:07,400
+component is deployed on the application server. And finally,
+
+22
+00:01:07,400 --> 00:01:09,570
+you should see how the nodes communicate with one
+
+23
+00:01:09,570 --> 00:01:11,880
+another. For example, you can see that the application
+
+24
+00:01:11,880 --> 00:01:17,030
+server and the university database communicate using a JDBC protocol.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/25 - UML Behavioral Diagrams: Use Case - lang_en_vs5.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/25 - UML Behavioral Diagrams: Use Case - lang_en_vs5.srt
new file mode 100644
index 0000000..bdfe33a
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/25 - UML Behavioral Diagrams: Use Case - lang_en_vs5.srt	
@@ -0,0 +1,111 @@
+1
+00:00:00,110 --> 00:00:04,700
+We now discuss UML's behavioral diagrams. Those diagrams that
+
+2
+00:00:04,700 --> 00:00:07,490
+have to do with the behavior, the dynamic aspects
+
+3
+00:00:07,490 --> 00:00:09,940
+of the system, rather than the static ones. The
+
+4
+00:00:09,940 --> 00:00:12,670
+first behavioral diagram I want to discuss is a very
+
+5
+00:00:12,670 --> 00:00:15,590
+fundamental one, the Use Case Diagram. So, let's start
+
+6
+00:00:15,590 --> 00:00:18,370
+by seeing what a Use Case is. A Use Case
+
+7
+00:00:18,370 --> 00:00:21,800
+represents two main things. First the sequence of interactions
+
+8
+00:00:21,800 --> 00:00:25,250
+of outside entities which is what we normally call actors
+
+9
+00:00:25,250 --> 00:00:27,990
+with the system that we're modelling and the second thing
+
+10
+00:00:27,990 --> 00:00:32,290
+is the system actions that yield an observable result of values
+
+11
+00:00:32,290 --> 00:00:35,380
+to the actors. And basically these two things, and nothing else
+
+12
+00:00:35,380 --> 00:00:38,010
+that the outside view of the system. So the view of
+
+13
+00:00:38,010 --> 00:00:41,060
+the system in which we look at the interaction between
+
+14
+00:00:41,060 --> 00:00:44,170
+this system, and the outside world. If you want to parallel, think
+
+15
+00:00:44,170 --> 00:00:48,070
+about designing a house. Considering how you would use the house.
+
+16
+00:00:48,070 --> 00:00:50,550
+And you might have seen use cases called with different names.
+
+17
+00:00:50,550 --> 00:00:54,820
+So for example, they're also called scenarios, scripts or user stories,
+
+18
+00:00:54,820 --> 00:00:58,220
+but in the context of UML, we'll call the use cases.
+
+19
+00:00:58,220 --> 00:01:00,650
+Now let's look at the basic notation for a use case,
+
+20
+00:01:00,650 --> 00:01:03,910
+which is fairly simple. We have a use case which is represented
+
+21
+00:01:03,910 --> 00:01:05,760
+by an oval, with a name, which is the name of
+
+22
+00:01:05,760 --> 00:01:08,520
+the use case. We have an actor, which is represented by
+
+23
+00:01:08,520 --> 00:01:12,330
+this icon and is normally identified by a role name. And
+
+24
+00:01:12,330 --> 00:01:15,820
+finally we have an edge which is a solid line that connects
+
+25
+00:01:15,820 --> 00:01:18,970
+actors and use cases and indicates that an actor
+
+26
+00:01:18,970 --> 00:01:21,270
+is the actor of a given use case. And just
+
+27
+00:01:21,270 --> 00:01:24,360
+for completeness let me note there are some additional notational
+
+28
+00:01:24,360 --> 00:01:27,750
+elements but now for simplicity we'll just use these ones.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/26 - Use Case Diagram: Actors - lang_en_vs5.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/26 - Use Case Diagram: Actors - lang_en_vs5.srt
new file mode 100644
index 0000000..4d80c61
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/26 - Use Case Diagram: Actors - lang_en_vs5.srt	
@@ -0,0 +1,167 @@
+1
+00:00:00,110 --> 00:00:02,320
+Now, let's look at use cases in a little more detail.
+
+2
+00:00:02,320 --> 00:00:05,480
+And start by defining exactly what an actor is. An actor
+
+3
+00:00:05,480 --> 00:00:08,710
+represents an entity, which can be a human or a device,
+
+4
+00:00:08,710 --> 00:00:12,750
+that plays a role within my system, so that interacts with my
+
+5
+00:00:12,750 --> 00:00:15,660
+system. It's some entity from the outside world, with respect to
+
+6
+00:00:15,660 --> 00:00:18,510
+my system, that interacts with my system. It is important to
+
+7
+00:00:18,510 --> 00:00:21,750
+clarify that an entity can play more than one role. For
+
+8
+00:00:21,750 --> 00:00:25,240
+example, you might have somebody working in a bank that can be
+
+9
+00:00:25,240 --> 00:00:28,400
+both an employee of the bank, or a customer of
+
+10
+00:00:28,400 --> 00:00:31,280
+the bank, depending on how it interacts with the banking
+
+11
+00:00:31,280 --> 00:00:34,360
+system. And, obviously, more than one entity can play the
+
+12
+00:00:34,360 --> 00:00:37,570
+same role. Using the same example, we can have both an
+
+13
+00:00:37,570 --> 00:00:40,350
+employee of the bank and just a regular customer, playing
+
+14
+00:00:40,350 --> 00:00:43,280
+the role of the customer. So again, it all depends on
+
+15
+00:00:43,280 --> 00:00:46,120
+what the entity does, how the entity interacts with the
+
+16
+00:00:46,120 --> 00:00:50,150
+system, what kind of functionality of the system the entity uses.
+
+17
+00:00:50,150 --> 00:00:53,270
+And finally, actors may appear in more than one use case.
+
+18
+00:00:53,270 --> 00:00:55,930
+So it's fairly normal for the same actor to interact with
+
+19
+00:00:55,930 --> 00:00:58,540
+the system in different ways. And therefore, to appear in more
+
+20
+00:00:58,540 --> 00:01:00,710
+than one use case. Just think about the use cases in
+
+21
+00:01:00,710 --> 00:01:04,230
+scenarios of usage. If the same actor can interact with the
+
+22
+00:01:04,230 --> 00:01:07,440
+system in different ways, that actor will appear in multiple use
+
+23
+00:01:07,440 --> 00:01:11,210
+cases. Now let's go back to the description of our course
+
+24
+00:01:11,210 --> 00:01:15,140
+management system, and see how we can identify actors in the system.
+
+25
+00:01:15,140 --> 00:01:17,500
+And as we did for the class diagram before, I encourage
+
+26
+00:01:17,500 --> 00:01:20,160
+you to stop the video and try to identify the actors
+
+27
+00:01:20,160 --> 00:01:22,301
+in the system yourself, before I do it.
+
+28
+00:01:23,475 --> 00:01:27,250
+If we look at the description, we can see that, for example, the Registration
+
+29
+00:01:27,250 --> 00:01:30,890
+Manager is clearly an actor for the system. Students are actors
+
+30
+00:01:30,890 --> 00:01:34,400
+for the system. Professors are actors for the system. And notice
+
+31
+00:01:34,400 --> 00:01:36,060
+that we're not doing the same thing that we were doing
+
+32
+00:01:36,060 --> 00:01:38,360
+when identifying classes. Here we're identifying
+
+33
+00:01:38,360 --> 00:01:40,460
+entities that are from the outside
+
+34
+00:01:40,460 --> 00:01:43,090
+world, and have an active role in interacting with my
+
+35
+00:01:43,090 --> 00:01:46,830
+system. Again, Registration Manager, that we will just call registrar for
+
+36
+00:01:46,830 --> 00:01:50,660
+simplicity, students, and professors. So once we have identified the
+
+37
+00:01:50,660 --> 00:01:53,760
+actors for our example, we can simply draw them, using the
+
+38
+00:01:53,760 --> 00:01:56,550
+notation that we just introduced. So we have the registrar,
+
+39
+00:01:56,550 --> 00:01:59,830
+and notice how for every actor we clarify the role that
+
+40
+00:01:59,830 --> 00:02:02,450
+the actor plays. We have the professor, and we have
+
+41
+00:02:02,450 --> 00:02:05,480
+the student. So here, these are the three actors that we
+
+42
+00:02:05,480 --> 00:02:07,000
+identified for our system.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/27 - Building a Use Case Diagram - lang_en_vs5.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/27 - Building a Use Case Diagram - lang_en_vs5.srt
new file mode 100644
index 0000000..4c62396
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/27 - Building a Use Case Diagram - lang_en_vs5.srt	
@@ -0,0 +1,203 @@
+1
+00:00:00,080 --> 00:00:02,120
+Now if you want to build a use case diagram for
+
+2
+00:00:02,120 --> 00:00:04,520
+our example, we have to add the use cases for
+
+3
+00:00:04,520 --> 00:00:07,710
+these different actors. For instance, if we consider the student
+
+4
+00:00:07,710 --> 00:00:10,810
+and the registrar, they might be both interacting with the maintain
+
+5
+00:00:10,810 --> 00:00:14,950
+schedule system, the registrar by updating the schedule and the
+
+6
+00:00:14,950 --> 00:00:18,125
+students by using the schedule that has been updated by the
+
+7
+00:00:18,125 --> 00:00:20,860
+registrar. As you can see, different roles for the same
+
+8
+00:00:20,860 --> 00:00:24,962
+use case. Another possible use case is the request course roster.
+
+9
+00:00:24,962 --> 00:00:28,520
+And on this case, the professor will request the roster
+
+10
+00:00:28,520 --> 00:00:31,960
+by interacting with the system. We will continue in this way
+
+11
+00:00:31,960 --> 00:00:35,270
+by further refining and by further adding use cases as we
+
+12
+00:00:35,270 --> 00:00:39,240
+identify possible interactions of the actors that we identified with our
+
+13
+00:00:39,240 --> 00:00:42,380
+system. So in summary, what the use case diagram is doing
+
+14
+00:00:42,380 --> 00:00:45,370
+is to show the actors and their interaction with the system
+
+15
+00:00:45,370 --> 00:00:47,680
+through a set of use cases. At this point, it should
+
+16
+00:00:47,680 --> 00:00:49,990
+be pretty clear that sure, this gives us an idea of
+
+17
+00:00:49,990 --> 00:00:53,630
+the interactions but we don't really know how these interactions occur.
+
+18
+00:00:53,630 --> 00:00:55,870
+So there is one piece that is missing, which is how
+
+19
+00:00:55,870 --> 00:00:58,850
+do we document the use cases, how do we describe what
+
+20
+00:00:58,850 --> 00:01:02,010
+happens and what these interactions actually are. And that's exactly what
+
+21
+00:01:02,010 --> 00:01:05,410
+we're going to discuss now, how to document use cases. So the
+
+22
+00:01:05,410 --> 00:01:09,000
+behavior of a use case can be specified by describing its
+
+23
+00:01:09,000 --> 00:01:11,650
+flow of events. And it is important to note that the
+
+24
+00:01:11,650 --> 00:01:15,190
+flow of events should be described from an actor's point of view,
+
+25
+00:01:15,190 --> 00:01:17,690
+so from the point of view of the external entity that
+
+26
+00:01:17,690 --> 00:01:22,070
+is interacting with my system. So the description should detail what
+
+27
+00:01:22,070 --> 00:01:24,480
+the system must provide to the actor when the use case
+
+28
+00:01:24,480 --> 00:01:28,170
+is executed. In particular, it should describe how the use case
+
+29
+00:01:28,170 --> 00:01:31,670
+starts and ends. It should describe the normal flow of events,
+
+30
+00:01:31,670 --> 00:01:34,280
+what is the normal interaction. And in addition to the normal
+
+31
+00:01:34,280 --> 00:01:37,720
+flow of events, it should also describe possibly alternative flows of
+
+32
+00:01:37,720 --> 00:01:40,240
+events. For example, in the case in which there are multiple
+
+33
+00:01:40,240 --> 00:01:44,450
+ways of accomplishing one action or performing a task. And finally,
+
+34
+00:01:44,450 --> 00:01:47,880
+it should also describe exceptional flow of events. For example, assume that
+
+35
+00:01:47,880 --> 00:01:50,910
+you are describing a use case for withdrawing money from an
+
+36
+00:01:50,910 --> 00:01:54,230
+ATM. You may want to describe the normal flow of events in which
+
+37
+00:01:54,230 --> 00:01:56,590
+I insert my card, I provide my pin and so on.
+
+38
+00:01:56,590 --> 00:01:59,750
+An alternative one in which, in addition to withdrawing cash, maybe I'll
+
+39
+00:01:59,750 --> 00:02:02,550
+also first ask for some information about how much money is
+
+40
+00:02:02,550 --> 00:02:05,390
+in my account. And finally, I may want to also describe an exceptional
+
+41
+00:02:05,390 --> 00:02:07,900
+flow of events in which I get my pin wrong and,
+
+42
+00:02:07,900 --> 00:02:11,140
+therefore, I'm not able to perform the operation. One more thing I
+
+43
+00:02:11,140 --> 00:02:14,140
+want to mention, when we talk about documenting use cases, is
+
+44
+00:02:14,140 --> 00:02:17,770
+the fact that the description of this information can be provided in
+
+45
+00:02:17,770 --> 00:02:20,650
+two main ways, in an informal way or in a formal
+
+46
+00:02:20,650 --> 00:02:23,330
+way. In the case of an informal description, we could just have
+
+47
+00:02:23,330 --> 00:02:27,540
+a textual description of the flow of events in natural language.
+
+48
+00:02:27,540 --> 00:02:30,250
+In the case of a formal or structured description, we may use,
+
+49
+00:02:30,250 --> 00:02:32,610
+for example, pre and post conditions, pseudo
+
+50
+00:02:32,610 --> 00:02:34,680
+code to indicate the steps. We could
+
+51
+00:02:34,680 --> 00:02:38,010
+also use the sequence diagrams, which is something that we will see in a minute.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/28 - Use Case Example - lang_en_vs5.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/28 - Use Case Example - lang_en_vs5.srt
new file mode 100644
index 0000000..8f8bead
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/28 - Use Case Example - lang_en_vs5.srt	
@@ -0,0 +1,243 @@
+1
+00:00:00,140 --> 00:00:02,310
+So, as we did for the previous cases, now let's look
+
+2
+00:00:02,310 --> 00:00:06,890
+at an example. Let's consider a specific use case, maintain curriculum, in
+
+3
+00:00:06,890 --> 00:00:10,570
+which we have the registrar that interacts with the system to do
+
+4
+00:00:10,570 --> 00:00:14,320
+operations for maintaining the curriculum. And, let's define the flow of events
+
+5
+00:00:14,320 --> 00:00:17,040
+for this use case. To do this, we're going to go back, as
+
+6
+00:00:17,040 --> 00:00:20,380
+usual, to the description of our system. So this is the one
+
+7
+00:00:20,380 --> 00:00:22,670
+that you already saw several times, but I would like for you
+
+8
+00:00:22,670 --> 00:00:25,080
+to do something. I would like for you to stop the video,
+
+9
+00:00:25,080 --> 00:00:27,890
+look back at the spec, the one that is shown here.
+
+10
+00:00:27,890 --> 00:00:30,850
+And write on your own, what you think is the informal flow
+
+11
+00:00:30,850 --> 00:00:35,060
+of events that categorizes the interaction of the registration manager with
+
+12
+00:00:35,060 --> 00:00:37,500
+the system. And it is very important that you keep in mind
+
+13
+00:00:37,500 --> 00:00:40,140
+something as you're doing that. You should keep in mind that,
+
+14
+00:00:40,140 --> 00:00:41,940
+as it always happens, when extracting
+
+15
+00:00:41,940 --> 00:00:44,270
+requirements from an initial specification, in
+
+16
+00:00:44,270 --> 00:00:47,570
+particular an informal one like this one, a high-level one, you
+
+17
+00:00:47,570 --> 00:00:50,130
+will have to be able to read between the lines and fill
+
+18
+00:00:50,130 --> 00:00:52,690
+in the blanks. That is, you have to provide the information
+
+19
+00:00:52,690 --> 00:00:55,770
+for the missing parts using your domain knowledge. So try to
+
+20
+00:00:55,770 --> 00:00:58,820
+do that exercise. Read the description, and see how you will
+
+21
+00:00:58,820 --> 00:01:02,470
+define the steps, the flow of events for the maintain curriculum use
+
+22
+00:01:02,470 --> 00:01:06,230
+case. If you're done with that, now let's see the possible
+
+23
+00:01:06,230 --> 00:01:09,080
+informal paragraph that describes that flow of events. And the one
+
+24
+00:01:09,080 --> 00:01:12,070
+I'm providing now is just one possibility, based on my experience
+
+25
+00:01:12,070 --> 00:01:15,040
+and based on the way I see this possible flow of events.
+
+26
+00:01:15,040 --> 00:01:17,950
+So yours might look different, of course. In my case, because
+
+27
+00:01:17,950 --> 00:01:20,880
+the description was measuring the fact that every user has got
+
+28
+00:01:20,880 --> 00:01:23,590
+a log-in and a password. I decided that the first step
+
+29
+00:01:23,590 --> 00:01:27,120
+should be that the registrar logs onto the system and enters his
+
+30
+00:01:27,120 --> 00:01:30,390
+or her password. As it normally happens with password protected systems,
+
+31
+00:01:30,390 --> 00:01:32,660
+if the password is valid, the registrar will get into the
+
+32
+00:01:32,660 --> 00:01:35,870
+system. And the system at this point should ask to specify
+
+33
+00:01:35,870 --> 00:01:40,810
+a semester for which the maintain curriculum activity has to be performed.
+
+34
+00:01:40,810 --> 00:01:44,290
+The registrar will therefor enter the desired semester. The interface
+
+35
+00:01:44,290 --> 00:01:46,740
+I envisioned is one in which the system will prompt
+
+36
+00:01:46,740 --> 00:01:50,690
+the registrar to select the desired activity. Add, delete, review,
+
+37
+00:01:50,690 --> 00:01:53,560
+or quit. And if the registrar selects add, the system
+
+38
+00:01:53,560 --> 00:01:56,060
+will allow the registrar to add a course to the
+
+39
+00:01:56,060 --> 00:01:59,660
+course list for the selected semester. Similarly, if the registrar
+
+40
+00:01:59,660 --> 00:02:02,550
+selects delete, the system will let the registrar delete a
+
+41
+00:02:02,550 --> 00:02:05,840
+course from the course list for the selected semester. And again
+
+42
+00:02:05,840 --> 00:02:08,660
+similarly, if the registrar selects review, the system will
+
+43
+00:02:08,660 --> 00:02:12,030
+simply display the course information in the course list for
+
+44
+00:02:12,030 --> 00:02:15,230
+the selected semester. And finally, if the registrar selects quit,
+
+45
+00:02:15,230 --> 00:02:18,110
+the system will simply exit and our use case will
+
+46
+00:02:18,110 --> 00:02:21,150
+end. So, again, there's the main knowledge that goes into
+
+47
+00:02:21,150 --> 00:02:23,620
+this. But this is a good example of how you
+
+48
+00:02:23,620 --> 00:02:27,960
+can refine the initial description to identify these scenarios that
+
+49
+00:02:27,960 --> 00:02:30,830
+then you will use to specify and implement your system.
+
+50
+00:02:30,830 --> 00:02:33,770
+And as we discussed a few minutes ago, we provided the information
+
+51
+00:02:33,770 --> 00:02:37,420
+that is requested for the use case, how the use case starts,
+
+52
+00:02:37,420 --> 00:02:40,620
+by logging into the system. And how it ends, by selecting quit.
+
+53
+00:02:40,620 --> 00:02:43,294
+We described the normal flow of events. And, of course, these flow
+
+54
+00:02:43,294 --> 00:02:46,580
+of events could be improved, because right now even though we described
+
+55
+00:02:46,580 --> 00:02:50,020
+how the use case starts and ends, we just described one possible
+
+56
+00:02:50,020 --> 00:02:53,340
+flow of events. But there's many alternative ways we could provide and
+
+57
+00:02:53,340 --> 00:02:55,890
+we do not describe any exception of flow of events. So this could
+
+58
+00:02:55,890 --> 00:02:58,540
+be the starting point for multiple use cases, or
+
+59
+00:02:58,540 --> 00:03:02,092
+for use cases just richer and contains more information, more
+
+60
+00:03:02,092 --> 00:03:04,474
+steps to a richer flow. But you should have
+
+61
+00:03:04,474 --> 00:03:06,510
+gotten the idea of what a use case should be.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/29 - Role of Use Cases - lang_en_vs5.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/29 - Role of Use Cases - lang_en_vs5.srt
new file mode 100644
index 0000000..11c0187
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/29 - Role of Use Cases - lang_en_vs5.srt	
@@ -0,0 +1,151 @@
+1
+00:00:00,100 --> 00:00:02,510
+As I mentioned when we started talking about use cases, use
+
+2
+00:00:02,510 --> 00:00:06,040
+cases are fundamental in UML, and in general. So, now I
+
+3
+00:00:06,040 --> 00:00:08,510
+would like to discuss why they're so important and what are
+
+4
+00:00:08,510 --> 00:00:11,900
+the different roles that use cases can play. The first obvious one
+
+5
+00:00:11,900 --> 00:00:15,510
+is for requirements elicitation. It is much easier to describe what
+
+6
+00:00:15,510 --> 00:00:17,650
+the system should do if we think about the system in
+
+7
+00:00:17,650 --> 00:00:21,070
+terms of scenarios of usage. Rather than trying to describe the
+
+8
+00:00:21,070 --> 00:00:25,450
+whole functionality of the system at once. So, use cases can help
+
+9
+00:00:25,450 --> 00:00:28,890
+performing a more effective requirement solicitation. As we will
+
+10
+00:00:28,890 --> 00:00:31,700
+see when we discuss the unified software process, they can
+
+11
+00:00:31,700 --> 00:00:34,980
+be used for architectural analysis. So, use cases are the
+
+12
+00:00:34,980 --> 00:00:38,165
+starting point for the analysis of the architecture of the
+
+13
+00:00:38,165 --> 00:00:40,765
+system that can help identify the main blocks of
+
+14
+00:00:40,765 --> 00:00:44,016
+the system. And therefore, can help define in the initial
+
+15
+00:00:44,016 --> 00:00:47,360
+architecture. And as I said, we'll talk more extensively about
+
+16
+00:00:47,360 --> 00:00:50,460
+that. They can be used for user prioritization. For example,
+
+17
+00:00:50,460 --> 00:00:53,230
+imagine to have multiple actors in the system, and you
+
+18
+00:00:53,230 --> 00:00:56,160
+might want to prioritize some of them. For instance, using
+
+19
+00:00:56,160 --> 00:00:59,810
+again the banking system example, we might want to first
+
+20
+00:00:59,810 --> 00:01:03,477
+provide functionality for the administrators of the bank. And only
+
+21
+00:01:03,477 --> 00:01:06,384
+in a second time provide functionality for the customers, because
+
+22
+00:01:06,384 --> 00:01:09,342
+of course, if the administrator cannot perform any operation, the
+
+23
+00:01:09,342 --> 00:01:12,030
+customers cannot use the system. So again, they can be
+
+24
+00:01:12,030 --> 00:01:15,980
+used to prioritize the users. Or the actors, and therefore
+
+25
+00:01:15,980 --> 00:01:19,390
+define which part of the system should be built in which order.
+
+26
+00:01:19,390 --> 00:01:22,120
+Related to this point, they can be used for planning. If I
+
+27
+00:01:22,120 --> 00:01:25,000
+know which pieces of functionality I need to build and in which
+
+28
+00:01:25,000 --> 00:01:27,980
+order, I can better plan the development of my system. And again,
+
+29
+00:01:27,980 --> 00:01:31,280
+we will see how this becomes very important in many different software
+
+30
+00:01:31,280 --> 00:01:35,037
+life cycles. So, both in the unified software process, for instance, but
+
+31
+00:01:35,037 --> 00:01:38,570
+also in more agile development processes. And finally, use cases can be
+
+32
+00:01:38,570 --> 00:01:40,980
+used for testing. If I have an early description of what the
+
+33
+00:01:40,980 --> 00:01:44,290
+system should do, what are the main pieces of functionality of the system. And I
+
+34
+00:01:44,290 --> 00:01:46,700
+know how the interaction between the actors and
+
+35
+00:01:46,700 --> 00:01:49,510
+the system is, I can easily define test
+
+36
+00:01:49,510 --> 00:01:52,010
+cases, even before writing the code, even before
+
+37
+00:01:52,010 --> 00:01:54,180
+defining my system. And when we discuss testing,
+
+38
+00:01:54,180 --> 00:01:57,590
+we will get back to this and talk a little more extensively about this, as well.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/3 - Objects and Classes - lang_en_vs5.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/3 - Objects and Classes - lang_en_vs5.srt
new file mode 100644
index 0000000..85bb32f
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/3 - Objects and Classes - lang_en_vs5.srt	
@@ -0,0 +1,83 @@
+1
+00:00:00,090 --> 00:00:02,770
+Let's start with objects. An object is a
+
+2
+00:00:02,770 --> 00:00:06,330
+computing unit organized around a collection of state
+
+3
+00:00:06,330 --> 00:00:09,350
+or instance variables that define the state of
+
+4
+00:00:09,350 --> 00:00:12,390
+the object. In addition, each object has associated
+
+5
+00:00:12,390 --> 00:00:15,150
+with it a set operations or methods that
+
+6
+00:00:15,150 --> 00:00:17,850
+operate on such state. So what that means
+
+7
+00:00:17,850 --> 00:00:21,420
+is that operations and methods read and write
+
+8
+00:00:21,420 --> 00:00:25,210
+instance variables. And in traditional object orientation, we say
+
+9
+00:00:25,210 --> 00:00:28,240
+that operations are invoked by sending a message
+
+10
+00:00:28,240 --> 00:00:30,520
+to the appropriate object, which is what we call
+
+11
+00:00:30,520 --> 00:00:33,660
+normally a method implication. So now that we define
+
+12
+00:00:33,660 --> 00:00:37,590
+what an object is, state variables, or attributes, and
+
+13
+00:00:37,590 --> 00:00:41,440
+operations or methods, let's see what a class is.
+
+14
+00:00:41,440 --> 00:00:44,900
+A class is basically a template. A blueprint, if
+
+15
+00:00:44,900 --> 00:00:47,700
+you wish, from which new objects, which is what
+
+16
+00:00:47,700 --> 00:00:50,655
+we call instances of the class can be created.
+
+17
+00:00:50,655 --> 00:00:52,800
+And notice that the fact of having a blueprint for
+
+18
+00:00:52,800 --> 00:00:55,610
+objects that allows us to create as many objects as
+
+19
+00:00:55,610 --> 00:00:58,390
+we want can further reuse, and also contribute to make
+
+20
+00:00:58,390 --> 00:01:00,300
+the code more readable, understandable,
+
+21
+00:01:00,300 --> 00:01:02,270
+and therefore ultimately more maintainable.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/30 - Use Case Diagram: Creation Tips - lang_en_vs5.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/30 - Use Case Diagram: Creation Tips - lang_en_vs5.srt
new file mode 100644
index 0000000..ccf7d0e
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/30 - Use Case Diagram: Creation Tips - lang_en_vs5.srt	
@@ -0,0 +1,127 @@
+1
+00:00:00,080 --> 00:00:02,190
+Now, as we did for the class diagram, let's look at
+
+2
+00:00:02,190 --> 00:00:05,440
+some creation tips for use case diagrams. The first tip is that
+
+3
+00:00:05,440 --> 00:00:09,050
+when you define a use case, use a name that communicates purpose.
+
+4
+00:00:09,050 --> 00:00:12,080
+It should be clear what the use case refers to by just
+
+5
+00:00:12,080 --> 00:00:14,320
+looking at the name of the use case. Second tip is
+
+6
+00:00:14,320 --> 00:00:17,700
+to define one atomic behavior per use case. So try not to
+
+7
+00:00:17,700 --> 00:00:21,900
+put more than one specific scenario into a use case. Why? Because
+
+8
+00:00:21,900 --> 00:00:25,380
+these will make the use cases easier to understand and better suited
+
+9
+00:00:25,380 --> 00:00:28,940
+for their roles that we just discussed to define test cases,
+
+10
+00:00:28,940 --> 00:00:31,370
+to do planning, to define an architecture and so on and
+
+11
+00:00:31,370 --> 00:00:34,790
+so forth. Define the flow of events clearly. So again, do
+
+12
+00:00:34,790 --> 00:00:37,820
+it from the perspective of an outsider. An outsider should be able
+
+13
+00:00:37,820 --> 00:00:40,390
+to read the description of the flow of events and understand
+
+14
+00:00:40,390 --> 00:00:43,770
+exactly how the system works or how that specific piece of
+
+15
+00:00:43,770 --> 00:00:47,572
+functionality works. As we suggested for the class diagram, provide only
+
+16
+00:00:47,572 --> 00:00:50,450
+essential details. So there is no need to provide all the nitty
+
+17
+00:00:50,450 --> 00:00:53,720
+gritty details about the use case, just provide enough details so
+
+18
+00:00:53,720 --> 00:00:57,540
+that the use case is complete and understandable. And finally, even
+
+19
+00:00:57,540 --> 00:00:59,960
+though we didn't cover that, there is a way to factor
+
+20
+00:00:59,960 --> 00:01:03,890
+common behaviors and factor variants when defining use cases. So I will
+
+21
+00:01:03,890 --> 00:01:06,580
+encourage you to look at how to do that. For example,
+
+22
+00:01:06,580 --> 00:01:09,290
+by looking at the additional UML documentation and to try to
+
+23
+00:01:09,290 --> 00:01:12,875
+factor out this common behaviors and variants. Typical example would be
+
+24
+00:01:12,875 --> 00:01:15,550
+a system that requires login, like the one that we just discussed,
+
+25
+00:01:15,550 --> 00:01:18,350
+will probably require an initial login step for each use
+
+26
+00:01:18,350 --> 00:01:22,080
+case. It is possible that instead of describing the same steps,
+
+27
+00:01:22,080 --> 00:01:24,600
+or same sub-steps, for each use case, you can factor
+
+28
+00:01:24,600 --> 00:01:26,740
+that out. And create a use case that you should then
+
+29
+00:01:26,740 --> 00:01:29,180
+include in your own use cases. As I said, we
+
+30
+00:01:29,180 --> 00:01:32,790
+didn't cover this for simplicity, but feel free to further read
+
+31
+00:01:32,790 --> 00:01:35,450
+about UML and to see how you can actually factor out
+
+32
+00:01:35,450 --> 00:01:38,890
+behaviors and factor variants. Which can be very useful in practice.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/31 - UML Behavioral Diagrams: Sequence - lang_en_vs5.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/31 - UML Behavioral Diagrams: Sequence - lang_en_vs5.srt
new file mode 100644
index 0000000..cbeb4d8
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/31 - UML Behavioral Diagrams: Sequence - lang_en_vs5.srt	
@@ -0,0 +1,227 @@
+1
+00:00:00,080 --> 00:00:02,400
+Now that we have seen use cases, the next behavioral
+
+2
+00:00:02,400 --> 00:00:05,540
+diagram I want to discuss is the sequence diagram. So
+
+3
+00:00:05,540 --> 00:00:08,070
+what is a sequence diagram? It is an interaction diagram
+
+4
+00:00:08,070 --> 00:00:12,710
+that emphasizes how objects communicate and the time ordering of
+
+5
+00:00:12,710 --> 00:00:15,940
+the messages between objects. To illustrate sequence diagrams in a
+
+6
+00:00:15,940 --> 00:00:18,600
+practical way, and hopefully in a clear way, I will
+
+7
+00:00:18,600 --> 00:00:21,960
+introduce them by creating an actual sequence diagram using an
+
+8
+00:00:21,960 --> 00:00:25,160
+example taken from our course management system. So let's see what
+
+9
+00:00:25,160 --> 00:00:28,050
+are the steps needed to build such a sequence diagram. The first
+
+10
+00:00:28,050 --> 00:00:30,900
+thing we want to do is place the objects that participate in
+
+11
+00:00:30,900 --> 00:00:34,460
+the interaction at the top of the diagram along the x-axis, and
+
+12
+00:00:34,460 --> 00:00:36,410
+you also want to place them in a specific way. You want
+
+13
+00:00:36,410 --> 00:00:39,770
+to place objects that initiate the interaction at the left, and place
+
+14
+00:00:39,770 --> 00:00:42,260
+increasingly more subordinate objects to the
+
+15
+00:00:42,260 --> 00:00:44,430
+right. So basically, this should reflect
+
+16
+00:00:44,430 --> 00:00:47,660
+the way the events will flow for the majority of the interactions
+
+17
+00:00:47,660 --> 00:00:50,202
+in the system. Next thing you want to do is to add
+
+18
+00:00:50,202 --> 00:00:53,910
+what is called the object lifeline. It's a vertical line that
+
+19
+00:00:53,910 --> 00:00:57,300
+shows the existence of objects over a period of time. And
+
+20
+00:00:57,300 --> 00:01:00,660
+it's normally represented with a dashed line, except for the outermost
+
+21
+00:01:00,660 --> 00:01:03,190
+object for which it is a solid line. Now that you
+
+22
+00:01:03,190 --> 00:01:06,450
+have your object lifeline you can start placing messages that these
+
+23
+00:01:06,450 --> 00:01:09,285
+objects send and receive. You want to put them along the
+
+24
+00:01:09,285 --> 00:01:12,860
+y-axis in order of increasing time, from top to bottom. And
+
+25
+00:01:12,860 --> 00:01:15,550
+you can also put a number on the message to further
+
+26
+00:01:15,550 --> 00:01:18,230
+clarify the sequence. So in this case what we're showing
+
+27
+00:01:18,230 --> 00:01:21,550
+is that the student will send the fill in info
+
+28
+00:01:21,550 --> 00:01:24,330
+message to the registration form. And this is the first
+
+29
+00:01:24,330 --> 00:01:27,960
+message in the sequence diagram, the first interaction. Then the student
+
+30
+00:01:27,960 --> 00:01:30,900
+might submit the form and this is also a message
+
+31
+00:01:30,900 --> 00:01:33,370
+that goes to the registration form. At this point, when
+
+32
+00:01:33,370 --> 00:01:36,440
+the submission takes place, the registration form will send the
+
+33
+00:01:36,440 --> 00:01:39,990
+message, so it will invoke some functionality in the registration manager.
+
+34
+00:01:39,990 --> 00:01:43,560
+Specifically you will invoke the add course functionality
+
+35
+00:01:43,560 --> 00:01:46,400
+and pass Joe, the name of the student and
+
+36
+00:01:46,400 --> 00:01:49,410
+Math 101 which is the specific course for which
+
+37
+00:01:49,410 --> 00:01:53,180
+Joe is registering. Then the registration manager will ask
+
+38
+00:01:53,180 --> 00:01:56,780
+the Math 101 course whether it accepts registrations,
+
+39
+00:01:56,780 --> 00:01:59,780
+and the interaction will continue. So that Math 101
+
+40
+00:01:59,780 --> 00:02:02,820
+will actually check for a specific offering, if everything
+
+41
+00:02:02,820 --> 00:02:05,070
+goes fine, you will receive an ack, you'll send
+
+42
+00:02:05,070 --> 00:02:07,180
+back the act to the registration manager and so
+
+43
+00:02:07,180 --> 00:02:10,650
+on. Until at the end, Joe will be registered for
+
+44
+00:02:10,650 --> 00:02:13,390
+Math 101. As you can see, it is very
+
+45
+00:02:13,390 --> 00:02:17,600
+easy to see how the interaction occurs between these different
+
+46
+00:02:17,600 --> 00:02:21,010
+objects at run time, dynamically. So what the behavior
+
+47
+00:02:21,010 --> 00:02:24,070
+of the system is for this specific scenario. So the
+
+48
+00:02:24,070 --> 00:02:26,780
+last notational element that I want to add to this
+
+49
+00:02:26,780 --> 00:02:30,350
+diagram is the focus of control. Which is this tall
+
+50
+00:02:30,350 --> 00:02:32,880
+thin rectangle, that shows the period of time
+
+51
+00:02:32,880 --> 00:02:35,190
+that an object is performing an action, either
+
+52
+00:02:35,190 --> 00:02:37,270
+directly or indirectly. So if we look at
+
+53
+00:02:37,270 --> 00:02:39,240
+the registration form, this is telling us that
+
+54
+00:02:39,240 --> 00:02:41,670
+the registration form is active for this amount
+
+55
+00:02:41,670 --> 00:02:43,170
+of time. And the same thing we can
+
+56
+00:02:43,170 --> 00:02:45,520
+do for the registration manager, the Math 101
+
+57
+00:02:45,520 --> 00:02:49,170
+course offering, and the Math 101 specific section.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/32 - UML Behavioral Diagrams: State Transition Diagram - lang_en_vs5.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/32 - UML Behavioral Diagrams: State Transition Diagram - lang_en_vs5.srt
new file mode 100644
index 0000000..ab1bd6a
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/32 - UML Behavioral Diagrams: State Transition Diagram - lang_en_vs5.srt	
@@ -0,0 +1,175 @@
+1
+00:00:00,100 --> 00:00:02,430
+The very last diagram that I want to discuss is
+
+2
+00:00:02,430 --> 00:00:05,900
+the state transition diagram. The state transition diagram is defined for
+
+3
+00:00:05,900 --> 00:00:09,270
+each relevant class in the system and basically shows the
+
+4
+00:00:09,270 --> 00:00:12,880
+possible live history of a given class or object. So what
+
+5
+00:00:12,880 --> 00:00:15,090
+does it mean to describe the life history? It means
+
+6
+00:00:15,090 --> 00:00:18,630
+that it describes the possible states of the class as defined
+
+7
+00:00:18,630 --> 00:00:21,910
+by the values of the class attributes. And it also describes
+
+8
+00:00:21,910 --> 00:00:25,710
+the events that cause a transition from one state to another.
+
+9
+00:00:25,710 --> 00:00:28,800
+Finally, it describes the actions that result from a state
+
+10
+00:00:28,800 --> 00:00:31,050
+change. So if you put all of this together you
+
+11
+00:00:31,050 --> 00:00:33,760
+can see how this can represent the whole history of
+
+12
+00:00:33,760 --> 00:00:36,860
+the class, from its creation to its destruction. So let me
+
+13
+00:00:36,860 --> 00:00:40,610
+discuss the transition diagram in more detail, and also provide
+
+14
+00:00:40,610 --> 00:00:43,550
+information about the notation used to represent them. We have
+
+15
+00:00:43,550 --> 00:00:46,770
+states, that are represented by ovals with a name. And
+
+16
+00:00:46,770 --> 00:00:51,820
+we have transitions marked by the event that triggers the transition.
+
+17
+00:00:51,820 --> 00:00:55,500
+What transitions indicate is the passage from one state to
+
+18
+00:00:55,500 --> 00:00:59,430
+another state as the consequence of some external stimuli. Notice
+
+19
+00:00:59,430 --> 00:01:01,930
+that not all events will cause a state transition. So
+
+20
+00:01:01,930 --> 00:01:04,930
+for example, some events might be consumed within a single state.
+
+21
+00:01:04,930 --> 00:01:06,500
+And we'll get to that in a second. But in
+
+22
+00:01:06,500 --> 00:01:10,200
+most cases, an event will trigger some state transition. Events
+
+23
+00:01:10,200 --> 00:01:13,480
+may also produce actions and they may also have attributes
+
+24
+00:01:13,480 --> 00:01:17,100
+which are analogous to parameters in a method call. And Boolean
+
+25
+00:01:17,100 --> 00:01:20,830
+conditions that guard the state transition that is prevented
+
+26
+00:01:20,830 --> 00:01:22,860
+from happening in the case the conditions are not
+
+27
+00:01:22,860 --> 00:01:26,630
+satisfied. States may also be associated with activities and
+
+28
+00:01:26,630 --> 00:01:31,450
+actions. Specifically, activities are operations performed by an object
+
+29
+00:01:31,450 --> 00:01:33,410
+when it is in a given state and that
+
+30
+00:01:33,410 --> 00:01:36,690
+takes time to complete. Actions, conversely, just like the
+
+31
+00:01:36,690 --> 00:01:40,270
+actions corresponding to an event are instantaneous operations that
+
+32
+00:01:40,270 --> 00:01:42,420
+are performed by an object. And can be triggered
+
+33
+00:01:42,420 --> 00:01:46,050
+on entry. So, when the object reaches a given state,
+
+34
+00:01:46,050 --> 00:01:48,970
+when the object exits that state, and also when a
+
+35
+00:01:48,970 --> 00:01:53,240
+specific event occurs. And in this case, this notation is
+
+36
+00:01:53,240 --> 00:01:55,930
+basically a shortcut for any event that will cause a
+
+37
+00:01:55,930 --> 00:01:58,840
+state transition that will bring the object back into the
+
+38
+00:01:58,840 --> 00:02:01,696
+same state. Since we have several actions and activities, it
+
+39
+00:02:01,696 --> 00:02:04,480
+is probably worthwhile clarifyinig the ordering of such actions and
+
+40
+00:02:04,480 --> 00:02:07,559
+activities. So the way in which these actions and activities
+
+41
+00:02:07,559 --> 00:02:10,079
+occur is, first of all, we have the actions on the
+
+42
+00:02:10,079 --> 00:02:13,737
+incoming transition, so this is performed first. Then if there is an
+
+43
+00:02:13,737 --> 00:02:17,321
+entry action that is the next action that would be performed, then
+
+44
+00:02:17,321 --> 00:02:22,370
+we have activity and event actions as appropriate. And finally exit actions.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/33 - State Transition Diagram Example - lang_en_vs5.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/33 - State Transition Diagram Example - lang_en_vs5.srt
new file mode 100644
index 0000000..6c4c1bf
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/33 - State Transition Diagram Example - lang_en_vs5.srt	
@@ -0,0 +1,227 @@
+1
+00:00:00,090 --> 00:00:02,850
+As usual were going to illustrate these kind of diagrams by
+
+2
+00:00:02,850 --> 00:00:06,050
+using an example. In particular we are going to describe the state
+
+3
+00:00:06,050 --> 00:00:09,330
+transition diagram for part of our example, for part of
+
+4
+00:00:09,330 --> 00:00:12,640
+our course management system. And we're going to focus on the course
+
+5
+00:00:12,640 --> 00:00:15,540
+offering class. When the class is created, it enters the
+
+6
+00:00:15,540 --> 00:00:19,490
+initialization state, in which the activity performed is to initialize the
+
+7
+00:00:19,490 --> 00:00:22,580
+course. At this point, a simple case is the case in
+
+8
+00:00:22,580 --> 00:00:25,550
+which the class is cancelled, so there is a cancelled event.
+
+9
+00:00:25,550 --> 00:00:28,700
+And if that happens, the class is simply cancelled. So it
+
+10
+00:00:28,700 --> 00:00:31,720
+gets into this final state, which is the state cancelled. And
+
+11
+00:00:31,720 --> 00:00:35,500
+the activity in this case is to notify the registered students.
+
+12
+00:00:35,500 --> 00:00:38,580
+Obviously if this is the flow there will be no registered students.
+
+13
+00:00:38,580 --> 00:00:41,110
+However something else can happen when we are in this initial
+
+14
+00:00:41,110 --> 00:00:43,930
+state. So what can happen is that a student can register, so
+
+15
+00:00:43,930 --> 00:00:47,260
+in this case the add student event is triggered. And the
+
+16
+00:00:47,260 --> 00:00:50,620
+corresponding action is to set the count, in this case it would
+
+17
+00:00:50,620 --> 00:00:53,270
+be the count of students for the course offering, to one. And
+
+18
+00:00:53,270 --> 00:00:55,570
+there will be a change of state and the course offering will
+
+19
+00:00:55,570 --> 00:00:58,870
+get into this open state. And the action that will be performed
+
+20
+00:00:58,870 --> 00:01:02,260
+on entry will be to register the student. At this point more
+
+21
+00:01:02,260 --> 00:01:06,920
+students may register. So other student events might occur and notice that we
+
+22
+00:01:06,920 --> 00:01:10,630
+have a curve here that tells us this event will trigger this
+
+23
+00:01:10,630 --> 00:01:13,790
+transition only if the count is less than 10. So we're assuming
+
+24
+00:01:13,790 --> 00:01:16,120
+that we're not going to have more than 10 students just for lack
+
+25
+00:01:16,120 --> 00:01:19,010
+of a better number in our course offering. So if that
+
+26
+00:01:19,010 --> 00:01:21,960
+happens, if the count is less than ten so then the count
+
+27
+00:01:21,960 --> 00:01:25,880
+is incremented so the increment count action takes place. And the
+
+28
+00:01:25,880 --> 00:01:28,910
+system goes back into the open state, and the new student
+
+29
+00:01:28,910 --> 00:01:32,100
+is registered. Now here we have an interesting transition, because there's
+
+30
+00:01:32,100 --> 00:01:35,380
+no event triggering the transition, but simply the fact that the
+
+31
+00:01:35,380 --> 00:01:37,780
+count is equal to 10. So you can imagine this as
+
+32
+00:01:37,780 --> 00:01:40,930
+being a transition that is always enabled so can always be triggered,
+
+33
+00:01:40,930 --> 00:01:43,410
+but will be guarded. By the fact that the count has
+
+34
+00:01:43,410 --> 00:01:46,750
+to be exactly ten. So basically this transition will take place
+
+35
+00:01:46,750 --> 00:01:49,800
+only when enough students are added, such we get to count
+
+36
+00:01:49,800 --> 00:01:52,900
+them. Being incremented and being equal to ten and then the transition
+
+37
+00:01:52,900 --> 00:01:55,590
+will occur. And we will get into the closed state, in
+
+38
+00:01:55,590 --> 00:01:59,025
+which the class is no longer open because there are enough students
+
+39
+00:01:59,025 --> 00:02:01,730
+registered. And at this point, what will happen is that the
+
+40
+00:02:01,730 --> 00:02:06,320
+course will be finalized. So there will be this activity which performs
+
+41
+00:02:06,320 --> 00:02:09,699
+some operation that is needed to finalize the course. Another possibility
+
+42
+00:02:09,699 --> 00:02:12,150
+is that when we are in the open state, the course
+
+43
+00:02:12,150 --> 00:02:14,680
+is cancelled. And if the course is cancelled, in this case,
+
+44
+00:02:14,680 --> 00:02:18,320
+we go again to the cancel state. But here, the activity
+
+45
+00:02:18,320 --> 00:02:21,850
+of notifying registered students makes more sense. Because we will have
+
+46
+00:02:21,850 --> 00:02:24,960
+at least one registered student in this state, and therefore we'll
+
+47
+00:02:24,960 --> 00:02:28,190
+need to notify such student that the course offering has been
+
+48
+00:02:28,190 --> 00:02:31,470
+cancelled. Finally, is it also possible also to cancel a course
+
+49
+00:02:31,470 --> 00:02:34,050
+after it has been closed? And in this case again, the
+
+50
+00:02:34,050 --> 00:02:38,040
+same thing will happen. The class will reach the cancelled state and
+
+51
+00:02:38,040 --> 00:02:40,850
+all the students, in this case ten students, that are registered
+
+52
+00:02:40,850 --> 00:02:43,730
+for the course will be notified that the course has been cancelled.
+
+53
+00:02:43,730 --> 00:02:46,100
+So, if we look at this state transition diagram, you can
+
+54
+00:02:46,100 --> 00:02:49,860
+see that it's pretty easy to see what the evolution of objects
+
+55
+00:02:49,860 --> 00:02:52,590
+of this class can be. How they can go from their initial
+
+56
+00:02:52,590 --> 00:02:56,660
+state to various final states depending on what are the external events
+
+57
+00:02:56,660 --> 00:02:57,750
+that reach the system.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/34 - Recap Quiz - lang_en_vs4.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/34 - Recap Quiz - lang_en_vs4.srt
new file mode 100644
index 0000000..458137f
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/34 - Recap Quiz - lang_en_vs4.srt	
@@ -0,0 +1,31 @@
+1
+00:00:00,190 --> 00:00:02,260
+I'd like to conclude this lesson with a couple of
+
+2
+00:00:02,260 --> 00:00:05,350
+quizzes. Just to recap what we saw. And, make sure that
+
+3
+00:00:05,350 --> 00:00:08,000
+everybody's on the same page. In the first quiz, I want to
+
+4
+00:00:08,000 --> 00:00:11,930
+know whether an UML state transition diagram specifies a set of
+
+5
+00:00:11,930 --> 00:00:15,320
+objects that work together to perform some action. The events that
+
+6
+00:00:15,320 --> 00:00:17,870
+cause an object to move from one state to another. The
+
+7
+00:00:17,870 --> 00:00:20,840
+set of components in a system, or the effects of a
+
+8
+00:00:20,840 --> 00:00:24,270
+state change. And as usual, you should mark all that apply.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/35 - Recap Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/35 - Recap Quiz Solution - lang_en_vs4.srt
new file mode 100644
index 0000000..1172c26
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/35 - Recap Quiz Solution - lang_en_vs4.srt	
@@ -0,0 +1,47 @@
+1
+00:00:00,095 --> 00:00:03,320
+A UML state transition diagram does not specify a set
+
+2
+00:00:03,320 --> 00:00:05,960
+of object that work together to perform some action, because
+
+3
+00:00:05,960 --> 00:00:09,270
+this is what a sequence diagram does instead. Conversely, the
+
+4
+00:00:09,270 --> 00:00:12,530
+second one is correct. As we said, a state transition diagram
+
+5
+00:00:12,530 --> 00:00:15,790
+describes the events that cause a transition from one state
+
+6
+00:00:15,790 --> 00:00:19,300
+to another. Again, a UML state transition diagram does not
+
+7
+00:00:19,300 --> 00:00:22,270
+specify the set of components in a system, because this
+
+8
+00:00:22,270 --> 00:00:25,700
+is what a component diagram does, not a state transition diagram.
+
+9
+00:00:25,700 --> 00:00:27,620
+As for the last one, this is correct,
+
+10
+00:00:27,620 --> 00:00:30,510
+because, as we also discussed, a state transition diagram
+
+11
+00:00:30,510 --> 00:00:33,000
+describes the actions that result from a state
+
+12
+00:00:33,000 --> 00:00:35,890
+change, that is, the effects of such state change.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/36 - Recap Quiz - lang_en_vs4.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/36 - Recap Quiz - lang_en_vs4.srt
new file mode 100644
index 0000000..bdc7298
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/36 - Recap Quiz - lang_en_vs4.srt	
@@ -0,0 +1,15 @@
+1
+00:00:00,140 --> 00:00:01,580
+And for the last quiz, I want to know
+
+2
+00:00:01,580 --> 00:00:05,250
+which of the following diagrams are UML Structural
+
+3
+00:00:05,250 --> 00:00:08,790
+Diagrams? Use case diagram, class diagram, deployment diagram
+
+4
+00:00:08,790 --> 00:00:11,580
+and sequence diagram. Again, mark all that apply.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/37 - Recap Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/37 - Recap Quiz Solution - lang_en_vs4.srt
new file mode 100644
index 0000000..7f8f313
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/37 - Recap Quiz Solution - lang_en_vs4.srt	
@@ -0,0 +1,63 @@
+1
+00:00:00,140 --> 00:00:02,580
+And in this case, the correct answer is that class
+
+2
+00:00:02,580 --> 00:00:06,870
+diagram and deployment diagrams are the only two UML structural
+
+3
+00:00:06,870 --> 00:00:09,950
+diagrams among these four. So the answer to this quiz
+
+4
+00:00:09,950 --> 00:00:12,250
+was probably pretty obvious, but I wanted to use it
+
+5
+00:00:12,250 --> 00:00:15,840
+also to stress, once more, the difference between structural and
+
+6
+00:00:15,840 --> 00:00:19,560
+behavioral diagrams. Structural diagrams provide the static picture of the
+
+7
+00:00:19,560 --> 00:00:23,100
+system being modeled, presented from different perspective. For example, from
+
+8
+00:00:23,100 --> 00:00:26,630
+the perspective of the class diagram and of the deployment diagram.
+
+9
+00:00:26,630 --> 00:00:29,760
+Behavioral diagrams, on the other hand, provide information on
+
+10
+00:00:29,760 --> 00:00:32,460
+the dynamic behavior of the system being modeled, also
+
+11
+00:00:32,460 --> 00:00:35,020
+presented from different perspective. So it's important to be
+
+12
+00:00:35,020 --> 00:00:38,020
+able to distinguish between these two types of diagrams. This
+
+13
+00:00:38,020 --> 00:00:41,450
+concludes this lesson on object orientation and UML. But
+
+14
+00:00:41,450 --> 00:00:43,960
+I encourage you to look at the references provided
+
+15
+00:00:43,960 --> 00:00:45,390
+in the class notes, in case you want to
+
+16
+00:00:45,390 --> 00:00:49,440
+know more about object orientation, object oriented analysis, and UML.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/4 - Benefits of OO - lang_en_vs5.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/4 - Benefits of OO - lang_en_vs5.srt
new file mode 100644
index 0000000..2650d6e
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/4 - Benefits of OO - lang_en_vs5.srt	
@@ -0,0 +1,51 @@
+1
+00:00:00,090 --> 00:00:02,110
+So in more general terms, why do we want to
+
+2
+00:00:02,110 --> 00:00:05,330
+use object orientation? The first reason is that object
+
+3
+00:00:05,330 --> 00:00:10,530
+orientation can help reduce long-term maintenance costs by limiting
+
+4
+00:00:10,530 --> 00:00:12,700
+the effects of changes. As we saw, the effect
+
+5
+00:00:12,700 --> 00:00:15,990
+of using encapsulation and information hiding makes it easier
+
+6
+00:00:15,990 --> 00:00:18,700
+to modify parts of the system without affecting the
+
+7
+00:00:18,700 --> 00:00:21,590
+rest of the system. Object orientation can also improve
+
+8
+00:00:21,590 --> 00:00:25,870
+the developing process by favoring code and design reuse.
+
+9
+00:00:25,870 --> 00:00:27,840
+In general, object orientation helps
+
+10
+00:00:27,840 --> 00:00:31,750
+enforcing good design principles. Principles such
+
+11
+00:00:31,750 --> 00:00:34,880
+as the ones that we saw in encapuslation, information hiding, high
+
+12
+00:00:34,880 --> 00:00:39,470
+cohesion, low coupling and we will discuss these aspects more extensively
+
+13
+00:00:39,470 --> 00:00:42,750
+in the next mini course which is centered around design concepts.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/5 - OO Benefits Quiz - lang_en_vs4.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/5 - OO Benefits Quiz - lang_en_vs4.srt
new file mode 100644
index 0000000..5942254
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/5 - OO Benefits Quiz - lang_en_vs4.srt	
@@ -0,0 +1,43 @@
+1
+00:00:00,110 --> 00:00:02,600
+Now let's make sure that we understand the benefits of
+
+2
+00:00:02,600 --> 00:00:06,270
+object orientation through a quiz. Imagine that acme corporation decided
+
+3
+00:00:06,270 --> 00:00:09,180
+to use an objetory entered approach in its software development
+
+4
+00:00:09,180 --> 00:00:12,230
+process. If this is the case what benefits can they expect
+
+5
+00:00:12,230 --> 00:00:14,640
+to receive from this decision. And here I'm listing some
+
+6
+00:00:14,640 --> 00:00:18,120
+possible benefits. Increased reuse because of the modular cooling style.
+
+7
+00:00:18,120 --> 00:00:21,450
+Increased maintainability because the system design can accommodate changes more
+
+8
+00:00:21,450 --> 00:00:25,530
+easily. Increased speed because object oriented systems tend to run faster.
+
+9
+00:00:25,530 --> 00:00:27,770
+And increased understandability because the
+
+10
+00:00:27,770 --> 00:00:30,680
+design models real world entities. So,
+
+11
+00:00:30,680 --> 00:00:33,310
+I would like, as usual, for you to mark all that apply.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/6 - OO Benefits Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/6 - OO Benefits Quiz Solution - lang_en_vs4.srt
new file mode 100644
index 0000000..c97c453
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/6 - OO Benefits Quiz Solution - lang_en_vs4.srt	
@@ -0,0 +1,71 @@
+1
+00:00:00,080 --> 00:00:01,280
+So, now let's see which ones of these
+
+2
+00:00:01,280 --> 00:00:04,410
+benefits can actually be expected. Definitely, the first one.
+
+3
+00:00:04,410 --> 00:00:07,720
+The modular coding style typical of object-oriented approaches can,
+
+4
+00:00:07,720 --> 00:00:11,280
+and normally does, increase reuse. Similarly, because of the
+
+5
+00:00:11,280 --> 00:00:15,830
+characteristics of typical object-oriented systems, these systems are normally
+
+6
+00:00:15,830 --> 00:00:18,390
+easier to change. Because they're more modular, they're more
+
+7
+00:00:18,390 --> 00:00:21,890
+cohesive, they're more decoupled. And therefore, all of this
+
+8
+00:00:21,890 --> 00:00:25,520
+contributes to increase the maintainability of the resulting systems.
+
+9
+00:00:25,520 --> 00:00:27,810
+So we're going to mark this benefit as well.
+
+10
+00:00:27,810 --> 00:00:31,500
+There's really nothing about object-oriented systems. That make them
+
+11
+00:00:31,500 --> 00:00:34,550
+run faster and, therefore, this is not a benefit
+
+12
+00:00:34,550 --> 00:00:36,432
+that we can expect from the use of an
+
+13
+00:00:36,432 --> 00:00:39,910
+object-oriented approach. Conversely, the last one is an expected
+
+14
+00:00:39,910 --> 00:00:43,950
+benefit because normally, the fact of designing real-world entities,
+
+15
+00:00:43,950 --> 00:00:46,120
+which is one of the characteristics of the object
+
+16
+00:00:46,120 --> 00:00:50,530
+oriented approaches, does increase understandability. It's easier to understand
+
+17
+00:00:50,530 --> 00:00:54,370
+the system because we can relate. To the system because we can recognize in
+
+18
+00:00:54,370 --> 00:00:58,000
+the systems, real world entities that we are used to see and that we understand.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/7 - OO Analysis History - lang_en_vs4.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/7 - OO Analysis History - lang_en_vs4.srt
new file mode 100644
index 0000000..843126e
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/7 - OO Analysis History - lang_en_vs4.srt	
@@ -0,0 +1,175 @@
+1
+00:00:00,060 --> 00:00:02,160
+The use of object orientation and object oriented
+
+2
+00:00:02,160 --> 00:00:06,430
+concepts led to what we call OOAD, object oriented
+
+3
+00:00:06,430 --> 00:00:10,650
+analysis and design. OOAD is a software engineering approach
+
+4
+00:00:10,650 --> 00:00:13,790
+whose main characteristics is to model a software system
+
+5
+00:00:13,790 --> 00:00:16,600
+as a group of interacting objects, and we'll
+
+6
+00:00:16,600 --> 00:00:19,160
+see what that means. In particular, in this lesson
+
+7
+00:00:19,160 --> 00:00:21,590
+we will specifically focus on the first part of
+
+8
+00:00:21,590 --> 00:00:25,360
+this, object oriented analysis, which is a requirements analysis
+
+9
+00:00:25,360 --> 00:00:29,650
+technique that concentrates on modeling real world objects. And
+
+10
+00:00:29,650 --> 00:00:31,340
+as I usually like to do, I would like
+
+11
+00:00:31,340 --> 00:00:34,812
+to start by providing some historical perspective on object
+
+12
+00:00:34,812 --> 00:00:37,472
+oriented analysis to better understand how we went from a
+
+13
+00:00:37,472 --> 00:00:40,990
+function-centric world to a data-centric world. And several people
+
+14
+00:00:40,990 --> 00:00:43,800
+contributed to this shift in perspective, but I'd like
+
+15
+00:00:43,800 --> 00:00:46,960
+to mention a few that were particularly influential. Starting
+
+16
+00:00:46,960 --> 00:00:50,540
+from James Rumbaugh, which in the 90s developed an integrated
+
+17
+00:00:50,540 --> 00:00:53,900
+approach to object oriented modelling with three main aspects.
+
+18
+00:00:53,900 --> 00:00:56,680
+A data aspect, so the modelling was based on
+
+19
+00:00:56,680 --> 00:01:00,390
+using an extended version of entity relationship diagrams to
+
+20
+00:01:00,390 --> 00:01:03,680
+describe classes and inheritance. So that's what was called
+
+21
+00:01:03,680 --> 00:01:06,770
+the object model. And the second aspect has to
+
+22
+00:01:06,770 --> 00:01:09,770
+do with functions. So data flow diagrams were used
+
+23
+00:01:09,770 --> 00:01:12,850
+to represent the functional aspects of the system, where
+
+24
+00:01:12,850 --> 00:01:16,070
+each function was then becoming a method in a class.
+
+25
+00:01:16,070 --> 00:01:18,500
+So this is what is called the functional model.
+
+26
+00:01:18,500 --> 00:01:22,120
+So object model and functional model. The third model
+
+27
+00:01:22,120 --> 00:01:25,120
+in Rumbaugh's methodology had to do with control. So
+
+28
+00:01:25,120 --> 00:01:29,301
+it was representing the dynamic aspects of a system. And
+
+29
+00:01:29,301 --> 00:01:31,880
+it uses state machines, which we'll cover in more
+
+30
+00:01:31,880 --> 00:01:35,730
+detail, to represent how a system would evolve going from
+
+31
+00:01:35,730 --> 00:01:37,650
+one state to the other based on what happened
+
+32
+00:01:37,650 --> 00:01:41,260
+to the system. These three models together represented what was
+
+33
+00:01:41,260 --> 00:01:44,950
+called the Object Modeling Technique, or OMT. And
+
+34
+00:01:44,950 --> 00:01:47,860
+OMT combined with contributions from several people, and in
+
+35
+00:01:47,860 --> 00:01:51,290
+particular Jacobson and Booch, evolved into what we call
+
+36
+00:01:51,290 --> 00:01:54,910
+the Unified Modeling Language, which is UML, which is
+
+37
+00:01:54,910 --> 00:01:56,910
+probably the modeling language that most of you
+
+38
+00:01:56,910 --> 00:02:00,480
+are familiar with. UML extends OMT by providing more
+
+39
+00:02:00,480 --> 00:02:03,460
+diagrams and a broader view of a system from
+
+40
+00:02:03,460 --> 00:02:06,270
+multiple perspectives. So, in the second part of the
+
+41
+00:02:06,270 --> 00:02:07,850
+lesson, we will cover some of these
+
+42
+00:02:07,850 --> 00:02:10,530
+diagrams in details, but before that, I'd like
+
+43
+00:02:10,530 --> 00:02:12,215
+to talk a little bit more about object
+
+44
+00:02:12,215 --> 00:02:14,540
+oriented analysis, and how we can perform it.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/8 - OO Analysis Overview - lang_en_vs4.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/8 - OO Analysis Overview - lang_en_vs4.srt
new file mode 100644
index 0000000..fccd722
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/8 - OO Analysis Overview - lang_en_vs4.srt	
@@ -0,0 +1,147 @@
+1
+00:00:00,110 --> 00:00:02,540
+So let's look at the object-oriented analysis in a
+
+2
+00:00:02,540 --> 00:00:05,540
+little more detail. As I said earlier, traditional analysis
+
+3
+00:00:05,540 --> 00:00:08,890
+and design techniques were functionally oriented. What that means
+
+4
+00:00:08,890 --> 00:00:11,980
+is that they concentrated on the functions to be performed,
+
+5
+00:00:11,980 --> 00:00:14,510
+whereas the data upon which the functions operated were
+
+6
+00:00:14,510 --> 00:00:18,900
+secondary to the functions themselves. Conversely, object oriented analysis, is
+
+7
+00:00:18,900 --> 00:00:22,100
+primarily concerned that with a data objects, so we
+
+8
+00:00:22,100 --> 00:00:25,500
+went from a functional oriented view to a data oriented
+
+9
+00:00:25,500 --> 00:00:28,070
+view, what that means is that during the analysis phase,
+
+10
+00:00:28,070 --> 00:00:30,770
+we define a system first in terms of the data
+
+11
+00:00:30,770 --> 00:00:34,380
+types and their relationships, and the functions or methods are
+
+12
+00:00:34,380 --> 00:00:38,130
+defined only later and associated with specific objects which are sets
+
+13
+00:00:38,130 --> 00:00:40,380
+of data. So let's see how we can perform object
+
+14
+00:00:40,380 --> 00:00:44,040
+orientated analysis in practice, so the basic idea is to be
+
+15
+00:00:44,040 --> 00:00:47,060
+focused on the objects of the real world. So to
+
+16
+00:00:47,060 --> 00:00:51,310
+go from a real world objects to a set of requirements.
+
+17
+00:00:51,310 --> 00:00:55,340
+And we can describe this as a four-step process. The first
+
+18
+00:00:55,340 --> 00:00:57,790
+step is to obtain or prepare a textual description of the
+
+19
+00:00:57,790 --> 00:01:00,400
+problem to be solved. So obviously, we need to start from
+
+20
+00:01:00,400 --> 00:01:03,300
+some description of the system that we need to build. And
+
+21
+00:01:03,300 --> 00:01:06,120
+this is a very practical oriented approach, so that the next
+
+22
+00:01:06,120 --> 00:01:08,390
+thing we do is that we take the description and we
+
+23
+00:01:08,390 --> 00:01:12,670
+underline nouns. In this description. And the nouns that we underline
+
+24
+00:01:12,670 --> 00:01:16,710
+will become classes in my analysis. We then look at adjectives in
+
+25
+00:01:16,710 --> 00:01:19,530
+the document. We underline those, and we use that
+
+26
+00:01:19,530 --> 00:01:23,130
+information to identify the attributes of the classes that we've
+
+27
+00:01:23,130 --> 00:01:26,370
+previously identified. At this point we focus on active
+
+28
+00:01:26,370 --> 00:01:29,610
+verbs in the description, and the analysis of the active
+
+29
+00:01:29,610 --> 00:01:32,710
+verbs will give us the operations that we'll need
+
+30
+00:01:32,710 --> 00:01:36,830
+to define for our classes. So, again, underline nouns, and
+
+31
+00:01:36,830 --> 00:01:38,950
+those will become the classes in my system. Then,
+
+32
+00:01:38,950 --> 00:01:42,150
+objectives. And, those will be the attributes of the classes.
+
+33
+00:01:42,150 --> 00:01:46,650
+And, finally, active verbs that will become the operations of my classes. And
+
+34
+00:01:46,650 --> 00:01:48,840
+of course, this is a high level view to take this with a
+
+35
+00:01:48,840 --> 00:01:51,790
+grain of salt. But we will see that it's a very good pragmatic
+
+36
+00:01:51,790 --> 00:01:54,760
+approach to identifying requirements, starting from a
+
+37
+00:01:54,760 --> 00:01:56,570
+description of the system to be built.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/9 - Modeling Classes Quiz - lang_en_vs4.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/9 - Modeling Classes Quiz - lang_en_vs4.srt
new file mode 100644
index 0000000..6c3c61b
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/9 - Modeling Classes Quiz - lang_en_vs4.srt	
@@ -0,0 +1,35 @@
+1
+00:00:00,190 --> 00:00:02,890
+Now let's see how object oriented analysis might work
+
+2
+00:00:02,890 --> 00:00:06,640
+in practice by considering the following requirement for an online
+
+3
+00:00:06,640 --> 00:00:10,230
+shopping website. The requirement says that users can add
+
+4
+00:00:10,230 --> 00:00:12,890
+more than one item on sale at a time to
+
+5
+00:00:12,890 --> 00:00:15,590
+a shopping cart. So, looking at this requirement I
+
+6
+00:00:15,590 --> 00:00:18,180
+would like you to tell me which of the following
+
+7
+00:00:18,180 --> 00:00:21,285
+elements should be modeled as classes. And the elements
+
+8
+00:00:21,285 --> 00:00:25,650
+are: item, sale, shopping cart, time and user. So mark
+
+9
+00:00:25,650 --> 00:00:26,370
+all that apply.
diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/1 - Lesson Overview - lang_en_vs4.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/1 - Lesson Overview - lang_en_vs4.srt
new file mode 100644
index 0000000..89008af
--- /dev/null
+++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/1 - Lesson Overview - lang_en_vs4.srt	
@@ -0,0 +1,47 @@
+1
+00:00:00,360 --> 00:00:02,910
+Hello, and welcome to the third part
+
+2
+00:00:02,910 --> 00:00:06,426
+of our software engineering course. In this mini-course,
+
+3
+00:00:06,426 --> 00:00:09,250
+we will discuss software design. We will
+
+4
+00:00:09,250 --> 00:00:13,170
+also introduce the Unified Software Process. And we
+
+5
+00:00:13,170 --> 00:00:15,730
+will work on a more complex project,
+
+6
+00:00:15,730 --> 00:00:18,330
+in which we will develop a distributed software
+
+7
+00:00:18,330 --> 00:00:22,960
+system that involves multiple different platforms. In
+
+8
+00:00:22,960 --> 00:00:25,730
+our first lesson of this mini-course, in particular,
+
+9
+00:00:25,730 --> 00:00:28,150
+we will talk about software architecture. A
+
+10
+00:00:28,150 --> 00:00:31,650
+software engineering discipline whose goal is to lay
+
+11
+00:00:31,650 --> 00:00:34,980
+the foundation on which to build successful
+
+12
+00:00:34,980 --> 00:00:38,130
+and long lasting software systems. So let's begin.
diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/10 - Architectural Recovery Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/10 - Architectural Recovery Quiz Solution - lang_en_vs4.srt
new file mode 100644
index 0000000..bd45907
--- /dev/null
+++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/10 - Architectural Recovery Quiz Solution - lang_en_vs4.srt	
@@ -0,0 +1,67 @@
+1
+00:00:00,120 --> 00:00:03,210
+The first sentence is definitely false. Prescriptive architecture
+
+2
+00:00:03,210 --> 00:00:06,530
+and descriptive architecture tend to diverge as systems evolve,
+
+3
+00:00:06,530 --> 00:00:08,960
+and sometimes, even when the system is first developed,
+
+4
+00:00:08,960 --> 00:00:10,680
+as we will see in some of the upcoming
+
+5
+00:00:10,680 --> 00:00:14,340
+examples. Conversely, the second sentence is true. By
+
+6
+00:00:14,340 --> 00:00:18,150
+adding unnecessary elements to the architecture, architectural drift can
+
+7
+00:00:18,150 --> 00:00:22,470
+transform an otherwise clean architecture into a complex sub-optimal,
+
+8
+00:00:22,470 --> 00:00:25,960
+and often ugly, architecture. The third sentence is false.
+
+9
+00:00:25,960 --> 00:00:30,540
+Architectural erosion and architectural drift are, indeed, different phenomena.
+
+10
+00:00:30,540 --> 00:00:32,940
+But they both result in a less than ideal, and
+
+11
+00:00:32,940 --> 00:00:36,160
+in some cases, highly degraded architecture. And the fourth
+
+12
+00:00:36,160 --> 00:00:39,600
+sentence is also false, as we discussed a minute ago.
+
+13
+00:00:39,600 --> 00:00:42,050
+Just tweaking at the code is very unlikely to
+
+14
+00:00:42,050 --> 00:00:44,930
+improve the code. Quite the opposite, actually. The best way
+
+15
+00:00:44,930 --> 00:00:48,420
+to repair a degraded architectural design is to first, understand
+
+16
+00:00:48,420 --> 00:00:51,110
+the current architecture, and then, try to fix it in
+
+17
+00:00:51,110 --> 00:00:52,280
+a more principled way.
diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/11 - Real World Example - lang_en_vs6.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/11 - Real World Example - lang_en_vs6.srt
new file mode 100644
index 0000000..4e64d4a
--- /dev/null
+++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/11 - Real World Example - lang_en_vs6.srt	
@@ -0,0 +1,183 @@
+1
+00:00:00,210 --> 00:00:02,770
+Now to drive home some of the points that I just
+
+2
+00:00:02,770 --> 00:00:05,920
+made, I would like to show you a few real world examples
+
+3
+00:00:05,920 --> 00:00:09,150
+of architectures that kind of went astray. The first example I
+
+4
+00:00:09,150 --> 00:00:11,970
+want to use is an example from the Linux kernel. Actually, from
+
+5
+00:00:11,970 --> 00:00:15,260
+an earlier version of the Linux kernel. A research group studied
+
+6
+00:00:15,260 --> 00:00:17,020
+the documentation of Linux, and also
+
+7
+00:00:17,020 --> 00:00:19,440
+interviewed several Linux developers. And by
+
+8
+00:00:19,440 --> 00:00:21,710
+doing that, they were able to come up with a software
+
+9
+00:00:21,710 --> 00:00:25,260
+architecture of Linux at different levels of obstruction. So the one that
+
+10
+00:00:25,260 --> 00:00:27,365
+I'm showing you here on the left, is the
+
+11
+00:00:27,365 --> 00:00:31,120
+software architecture at the level of Linux's main subsystems. So
+
+12
+00:00:31,120 --> 00:00:34,540
+this is the prescriptive architecture of Linux at the level
+
+13
+00:00:34,540 --> 00:00:38,060
+of Linux's main subsystems. So the researchers, after identifying this
+
+14
+00:00:38,060 --> 00:00:40,420
+architecture, they showed it to the developers, and the
+
+15
+00:00:40,420 --> 00:00:43,180
+developers agreed that, that was indeed the architecture of the
+
+16
+00:00:43,180 --> 00:00:46,540
+system. The researchers then studied the source code of Linux
+
+17
+00:00:46,540 --> 00:00:50,380
+and reverse engineered its actual architecture. So the architecture as
+
+18
+00:00:50,380 --> 00:00:54,020
+implemented, it's descriptive architecture. And this one here, on the
+
+19
+00:00:54,020 --> 00:00:56,610
+right, is the result. And as you can see, they found
+
+20
+00:00:56,610 --> 00:01:00,940
+a number of differences or violations between the prescriptive architecture and
+
+21
+00:01:00,940 --> 00:01:04,080
+the descriptive architecture. In particular, if we look at this architecture,
+
+22
+00:01:04,080 --> 00:01:06,820
+we can see that pretty much everything talks to everything else,
+
+23
+00:01:06,820 --> 00:01:09,010
+which is, in general, not a good thing. And in addition
+
+24
+00:01:09,010 --> 00:01:11,890
+to that, there are also several things that don't really make
+
+25
+00:01:11,890 --> 00:01:15,630
+much sense. For example the library calls the file system and
+
+26
+00:01:15,630 --> 00:01:19,290
+also the network interface which doesn't make much sense. Another thing
+
+27
+00:01:19,290 --> 00:01:21,850
+that is kind of weird is the fact that file system
+
+28
+00:01:21,850 --> 00:01:25,250
+calls the kernel initialization code. Which is also a little bit
+
+29
+00:01:25,250 --> 00:01:28,100
+weird. So basically, the bottom line here is that not even
+
+30
+00:01:28,100 --> 00:01:32,020
+the developers realized how the actual architecture of the system was,
+
+31
+00:01:32,020 --> 00:01:35,170
+and how it was different from the architecture they have conceived.
+
+32
+00:01:35,170 --> 00:01:37,870
+And in fact another interesting thing here is the reaction of
+
+33
+00:01:37,870 --> 00:01:41,020
+the developers when they were shown the actual architecture. So basically
+
+34
+00:01:41,020 --> 00:01:44,110
+they justified the differences by saying things such as, well you
+
+35
+00:01:44,110 --> 00:01:47,120
+know it had to be done fast, and therefore I changed it
+
+36
+00:01:47,120 --> 00:01:50,110
+and then I didn't have time to go back and update the documentation
+
+37
+00:01:50,110 --> 00:01:52,800
+and things of this sort. And by the way these are exactly some
+
+38
+00:01:52,800 --> 00:01:55,640
+of the reasons that we mentioned early on in the lesson for the
+
+39
+00:01:55,640 --> 00:01:58,410
+discrepancy between prescriptive and descriptive software
+
+40
+00:01:58,410 --> 00:01:59,990
+architecture. So one last thing that I
+
+41
+00:01:59,990 --> 00:02:02,840
+want to mention here as an aside and we can get back to
+
+42
+00:02:02,840 --> 00:02:06,495
+that later is the fact that you can probably clearly show how representing
+
+43
+00:02:06,495 --> 00:02:10,880
+software architectures graphically can be extremely useful, because it allows
+
+44
+00:02:10,880 --> 00:02:14,140
+for easily seeing the structure of the system. Look at different
+
+45
+00:02:14,140 --> 00:02:17,140
+views identify problematic points and so on. And we will see
+
+46
+00:02:17,140 --> 00:02:19,740
+how that can be useful in many cases also later on.
diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/12 - More Examples - lang_en_vs6.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/12 - More Examples - lang_en_vs6.srt
new file mode 100644
index 0000000..6f929eb
--- /dev/null
+++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/12 - More Examples - lang_en_vs6.srt	
@@ -0,0 +1,107 @@
+1
+00:00:00,180 --> 00:00:03,090
+As another example, I want to show you the architecture of the
+
+2
+00:00:03,090 --> 00:00:06,290
+iRods system. This is a data grid system that was built by
+
+3
+00:00:06,290 --> 00:00:09,720
+a biologist. And it's a system for storing and accessing big
+
+4
+00:00:09,720 --> 00:00:11,910
+data. So what I'm going to do, I'm going to do the same thing
+
+5
+00:00:11,910 --> 00:00:14,010
+that I did for the Linux system. I'm going to show you
+
+6
+00:00:14,010 --> 00:00:18,080
+here, on the left hand side, this clean prescriptive architecture for the
+
+7
+00:00:18,080 --> 00:00:21,000
+iRODS system. And I'm going to show you here on the right the
+
+8
+00:00:21,000 --> 00:00:22,660
+actual architecture of the system. The
+
+9
+00:00:22,660 --> 00:00:25,780
+descriptive architecture of iRODS. So here,
+
+10
+00:00:25,780 --> 00:00:27,640
+even if we don't go in and look at the details, you
+
+11
+00:00:27,640 --> 00:00:31,800
+can see very easily that the system is badly drifted and eroded
+
+12
+00:00:31,800 --> 00:00:34,500
+with respect to the way it was supposed to be. Continuing
+
+13
+00:00:34,500 --> 00:00:36,500
+with the examples. What I want to show you now is the
+
+14
+00:00:36,500 --> 00:00:39,980
+view of the complete architecture of HADOOP. As many of you probably
+
+15
+00:00:39,980 --> 00:00:44,210
+already know, HADOOP is an open source software framework for storage and
+
+16
+00:00:44,210 --> 00:00:47,990
+large scale processing of data sets. It's very broadly used. And here
+
+17
+00:00:47,990 --> 00:00:50,820
+is a picture of the architecture, and I hope you can see it
+
+18
+00:00:50,820 --> 00:00:54,290
+because the architecture is so complex and so broad and so
+
+19
+00:00:54,290 --> 00:00:57,050
+intertwined, and in order to be able to represent it here
+
+20
+00:00:57,050 --> 00:00:59,690
+in one page, I had to zoom out quite a bit.
+
+21
+00:00:59,690 --> 00:01:02,120
+But also in this case, you don't really have to look
+
+22
+00:01:02,120 --> 00:01:05,640
+at details. The important point here is that in this software architecture
+
+23
+00:01:05,640 --> 00:01:09,540
+61 out of the 67 components in the system have circular
+
+24
+00:01:09,540 --> 00:01:12,570
+dependencies. Which means that they depend on each other in a
+
+25
+00:01:12,570 --> 00:01:15,820
+circular way and this is normally not a good thing and also
+
+26
+00:01:15,820 --> 00:01:18,790
+in this case a few developers when shown the diagram had no
+
+27
+00:01:18,790 --> 00:01:22,120
+idea that the structure of the system was so complex and messy.
diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/13 - Final Example - lang_en_vs4.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/13 - Final Example - lang_en_vs4.srt
new file mode 100644
index 0000000..4fab0c6
--- /dev/null
+++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/13 - Final Example - lang_en_vs4.srt	
@@ -0,0 +1,127 @@
+1
+00:00:00,220 --> 00:00:02,130
+I'm going to conclude this set of examples with
+
+2
+00:00:02,130 --> 00:00:04,750
+a system that you might also know, Bash. And in
+
+3
+00:00:04,750 --> 00:00:08,000
+case you don't, Bash is a Unix shell written as
+
+4
+00:00:08,000 --> 00:00:11,000
+a free software replacement for the traditional Bourne shell, also
+
+5
+00:00:11,000 --> 00:00:13,690
+called sh. So what I'm showing here is the
+
+6
+00:00:13,690 --> 00:00:17,950
+descriptive architecture of the command component of Bash. So, is
+
+7
+00:00:17,950 --> 00:00:22,170
+the architecture, as implemented, of the command component of Bash.
+
+8
+00:00:22,170 --> 00:00:25,390
+And the component is the one here sort of highlighted
+
+9
+00:00:25,390 --> 00:00:28,120
+in gray. And what you can see here, these names are
+
+10
+00:00:28,120 --> 00:00:31,640
+the sub components of the command component. And if we look at
+
+11
+00:00:31,640 --> 00:00:35,000
+this architecture, two design problems of the component can kind of jump
+
+12
+00:00:35,000 --> 00:00:37,870
+at us. The first one is the lack of cohesion within the
+
+13
+00:00:37,870 --> 00:00:40,830
+component. So, if you look here, you can see that only
+
+14
+00:00:40,830 --> 00:00:44,820
+a few connections exist between the sub-components. And having a low cohesion
+
+15
+00:00:44,820 --> 00:00:47,430
+is normally not a good thing for a design. The second thing
+
+16
+00:00:47,430 --> 00:00:50,860
+that we can note is the high coupling. The component has tons
+
+17
+00:00:50,860 --> 00:00:54,200
+of connections with other components. They're, these edges that are
+
+18
+00:00:54,200 --> 00:00:57,890
+leaving the components and going towards other parts of the system.
+
+19
+00:00:57,890 --> 00:01:01,190
+So basically, this component has low cohesion and high coupling, which
+
+20
+00:01:01,190 --> 00:01:04,730
+is exactly the opposite of how a good design should be.
+
+21
+00:01:04,730 --> 00:01:07,410
+Given the structure, it is clear that anytime you change
+
+22
+00:01:07,410 --> 00:01:09,970
+this component you might need to change a bunch of other
+
+23
+00:01:09,970 --> 00:01:13,440
+components in the system. And of course, when changing other components
+
+24
+00:01:13,440 --> 00:01:15,910
+in the system, you might also need to chance the command
+
+25
+00:01:15,910 --> 00:01:19,060
+component as well. And along similar lines, to understand this
+
+26
+00:01:19,060 --> 00:01:21,890
+component you probably need to look at many other parts of
+
+27
+00:01:21,890 --> 00:01:24,690
+the system, which is also less than ideal. And one
+
+28
+00:01:24,690 --> 00:01:27,580
+important point here is that with all these examples, I'm not
+
+29
+00:01:27,580 --> 00:01:30,500
+really trying to criticize any specific system, what I'm trying
+
+30
+00:01:30,500 --> 00:01:34,380
+to show instead, is how complex software architectures can be, and
+
+31
+00:01:34,380 --> 00:01:37,040
+how much they can degrade over time. And this is true
+
+32
+00:01:37,040 --> 00:01:39,660
+for most systems, not just the ones that I showed you.
diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/14 - Architectural Design Quiz - lang_en_vs4.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/14 - Architectural Design Quiz - lang_en_vs4.srt
new file mode 100644
index 0000000..e1e95e6
--- /dev/null
+++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/14 - Architectural Design Quiz - lang_en_vs4.srt	
@@ -0,0 +1,31 @@
+1
+00:00:00,110 --> 00:00:02,330
+At this point, we have seen some examples of
+
+2
+00:00:02,330 --> 00:00:05,070
+things that might go wrong with the software architecture. So
+
+3
+00:00:05,070 --> 00:00:07,220
+I'd like to ask you also to recap some of
+
+4
+00:00:07,220 --> 00:00:10,800
+the concepts that we've touched upon. What are ideal characteristics
+
+5
+00:00:10,800 --> 00:00:13,526
+of an architectural design? And I'm showing you three possibilities
+
+6
+00:00:13,526 --> 00:00:16,970
+here: scalability, low cohesion, and low coupling. And some of
+
+7
+00:00:16,970 --> 00:00:20,260
+these concepts we did not explicitly define, but we talked
+
+8
+00:00:20,260 --> 00:00:22,400
+about it when discussing the examples that we just saw.
diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/15 - Architectural Design Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/15 - Architectural Design Quiz Solution - lang_en_vs4.srt
new file mode 100644
index 0000000..465687c
--- /dev/null
+++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/15 - Architectural Design Quiz Solution - lang_en_vs4.srt	
@@ -0,0 +1,107 @@
+1
+00:00:00,110 --> 00:00:02,540
+So, let's look at these three characteristics one by
+
+2
+00:00:02,540 --> 00:00:06,660
+one. Scalability for software architecture is its ability to handle
+
+3
+00:00:06,660 --> 00:00:09,320
+the growth of the software system. For example, for a
+
+4
+00:00:09,320 --> 00:00:12,610
+web based system, scalability could be the ability to handle
+
+5
+00:00:12,610 --> 00:00:15,620
+a larger workload by adding new servers to the system.
+
+6
+00:00:15,620 --> 00:00:19,508
+Scalability is therefore an important characteristic of a software architecture,
+
+7
+00:00:19,508 --> 00:00:21,938
+especially for the kinds of systems that can grow over
+
+8
+00:00:21,938 --> 00:00:24,990
+time. So, we're going to mark it as an ideal characteristic.
+
+9
+00:00:24,990 --> 00:00:27,901
+Cohesion is a measure of how strongly related are
+
+10
+00:00:27,901 --> 00:00:30,920
+the elements of a module. Clearly, we should shoot
+
+11
+00:00:30,920 --> 00:00:33,760
+for high and not low cohesion when developing a
+
+12
+00:00:33,760 --> 00:00:37,100
+system. We want to develop modules whose elements cooperate to
+
+13
+00:00:37,100 --> 00:00:40,480
+provide the specific piece of functionality rather than modules
+
+14
+00:00:40,480 --> 00:00:43,410
+consisting of a bunch of elements that provide different
+
+15
+00:00:43,410 --> 00:00:47,040
+unrelated pieces of functionality. Therefor, low cohesion is definitely
+
+16
+00:00:47,040 --> 00:00:49,980
+not something that we want. We want high cohesion instead.
+
+17
+00:00:49,980 --> 00:00:53,040
+As for coupling, coupling is a concept related to cohesion
+
+18
+00:00:53,040 --> 00:00:55,070
+and is also a measure. In this case though, it
+
+19
+00:00:55,070 --> 00:00:58,130
+is a measure of how strongly related are the different
+
+20
+00:00:58,130 --> 00:01:01,830
+modules in a system. Low coupling, which is often correlated with
+
+21
+00:01:01,830 --> 00:01:05,570
+high cohesion, is an important and ideal characteristic of a
+
+22
+00:01:05,570 --> 00:01:08,660
+software architecture as it indicates that the different modules in
+
+23
+00:01:08,660 --> 00:01:12,220
+the system are independent from one another. Each module provides
+
+24
+00:01:12,220 --> 00:01:15,300
+a specific piece of functionality and it can provide it without
+
+25
+00:01:15,300 --> 00:01:17,530
+relying too much on other modules.
+
+26
+00:01:17,530 --> 00:01:19,960
+Basically, systems characterized by low coupling
+
+27
+00:01:19,960 --> 00:01:23,330
+and high cohesion, are systems that are easier to understand, and to maintain.
diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/16 - Architectural Elements - lang_en_vs5.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/16 - Architectural Elements - lang_en_vs5.srt
new file mode 100644
index 0000000..c8de83f
--- /dev/null
+++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/16 - Architectural Elements - lang_en_vs5.srt	
@@ -0,0 +1,115 @@
+1
+00:00:00,170 --> 00:00:02,770
+Now that we have discussed a few foundational aspects
+
+2
+00:00:02,770 --> 00:00:05,410
+of software architectures, and we have looked at some real
+
+3
+00:00:05,410 --> 00:00:07,900
+world examples that help us to illustrate some of these
+
+4
+00:00:07,900 --> 00:00:10,560
+points, to discuss some of these aspects. I want to
+
+5
+00:00:10,560 --> 00:00:13,730
+introduce and define the different elements that compose a software
+
+6
+00:00:13,730 --> 00:00:17,700
+architecture and also talk about architectural styles. So let's start
+
+7
+00:00:17,700 --> 00:00:20,190
+by discussing a software architecture's
+
+8
+00:00:20,190 --> 00:00:22,880
+elements. A software system's architecture
+
+9
+00:00:22,880 --> 00:00:26,690
+typically is not, and should not be, a uniform monolith.
+
+10
+00:00:26,690 --> 00:00:28,770
+On the contrary, an architecture should be a
+
+11
+00:00:28,770 --> 00:00:32,910
+composition and interplay of different elements. In particular,
+
+12
+00:00:32,910 --> 00:00:34,510
+as we quickly mentioned at the beginning of
+
+13
+00:00:34,510 --> 00:00:36,970
+the lesson, there are three main types of elements
+
+14
+00:00:36,970 --> 00:00:40,160
+in an architecture. Processing elements, data elements, and
+
+15
+00:00:40,160 --> 00:00:44,580
+interaction elements. Processing elements are those elements that implement
+
+16
+00:00:44,580 --> 00:00:48,260
+the business logic and perform transformations on data.
+
+17
+00:00:48,260 --> 00:00:51,760
+Data elements, also called information or state, are those
+
+18
+00:00:51,760 --> 00:00:54,180
+elements that contain the information that is used
+
+19
+00:00:54,180 --> 00:00:57,440
+and transformed by the processing elements. And finally,
+
+20
+00:00:57,440 --> 00:01:00,030
+the interaction elements are the glue that holds
+
+21
+00:01:00,030 --> 00:01:02,760
+the different pieces of the architecture together. Now,
+
+22
+00:01:02,760 --> 00:01:06,030
+the processing elements and the data are contained
+
+23
+00:01:06,030 --> 00:01:10,350
+into the system components, whereas the interaction elements
+
+24
+00:01:10,350 --> 00:01:13,900
+are maintained and controlled by the system connectors.
+
+25
+00:01:13,900 --> 00:01:17,100
+And components and connectors get all cooked together
+
+26
+00:01:17,100 --> 00:01:19,980
+into a systems configuration, which models
+
+27
+00:01:19,980 --> 00:01:22,940
+components, connectors and their relationships. So
+
+28
+00:01:22,940 --> 00:01:24,850
+now, let's look at components, connectors
+
+29
+00:01:24,850 --> 00:01:26,770
+and configurations in a little more detail.
diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/17 - Components, Connectors, and Configurations - lang_en_vs5.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/17 - Components, Connectors, and Configurations - lang_en_vs5.srt
new file mode 100644
index 0000000..5fc4df3
--- /dev/null
+++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/17 - Components, Connectors, and Configurations - lang_en_vs5.srt	
@@ -0,0 +1,111 @@
+1
+00:00:00,250 --> 00:00:02,350
+And let's start with software components. A
+
+2
+00:00:02,350 --> 00:00:06,700
+software component is an architectural entity that encapsulates
+
+3
+00:00:06,700 --> 00:00:09,940
+a subset of the system's functionality and or
+
+4
+00:00:09,940 --> 00:00:13,180
+the system's data. So basically components typically provide
+
+5
+00:00:13,180 --> 00:00:16,100
+application specific services. In addition to that, a
+
+6
+00:00:16,100 --> 00:00:19,650
+software component also restricts access to that subset
+
+7
+00:00:19,650 --> 00:00:23,570
+via an explicitly defined interface. And, in addition,
+
+8
+00:00:23,570 --> 00:00:25,610
+which I'm not showing here, a component
+
+9
+00:00:25,610 --> 00:00:28,010
+can also have explicitly defined dependencies
+
+10
+00:00:28,010 --> 00:00:30,990
+on its required execution environment. In complex
+
+11
+00:00:30,990 --> 00:00:33,680
+systems, interactions might become more important and
+
+12
+00:00:33,680 --> 00:00:36,220
+challenging than functionality. And this is why
+
+13
+00:00:36,220 --> 00:00:40,000
+connectors are very important architectural elements. A
+
+14
+00:00:40,000 --> 00:00:42,935
+software connector is an architectural building block
+
+15
+00:00:42,935 --> 00:00:46,990
+tasked with effecting and regulating interactions among
+
+16
+00:00:46,990 --> 00:00:50,980
+components. So basically, connectors typically provide application
+
+17
+00:00:50,980 --> 00:00:54,610
+independent interaction facilities. And it's worth noting here
+
+18
+00:00:54,610 --> 00:00:57,530
+that in many software systems, connectors might simply be
+
+19
+00:00:57,530 --> 00:01:01,140
+procedure calls or shared data accesses. So all constants
+
+20
+00:01:01,140 --> 00:01:03,589
+that we're familiar with. But consider that much more
+
+21
+00:01:03,589 --> 00:01:06,690
+sophisticated and complex connectors are also possible. And
+
+22
+00:01:06,690 --> 00:01:10,310
+components and connectors are composed in a specific way
+
+23
+00:01:10,310 --> 00:01:13,510
+in a given system architecture to accomplish that system's
+
+24
+00:01:13,510 --> 00:01:17,400
+objective And this is expressed through an architectural configuration.
+
+25
+00:01:17,400 --> 00:01:21,070
+More precisely, an architectural configuration, or topology, is a
+
+26
+00:01:21,070 --> 00:01:25,630
+set of specific associations between the components and connectors
+
+27
+00:01:25,630 --> 00:01:28,380
+of a software system's architecture. So now, let's look
+
+28
+00:01:28,380 --> 00:01:30,880
+at an example that brings all of this together.
diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/18 - Configuration Example - lang_en_vs5.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/18 - Configuration Example - lang_en_vs5.srt
new file mode 100644
index 0000000..775f11c
--- /dev/null
+++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/18 - Configuration Example - lang_en_vs5.srt	
@@ -0,0 +1,75 @@
+1
+00:00:00,180 --> 00:00:02,880
+What I'm showing here is what an architectural configuration of
+
+2
+00:00:02,880 --> 00:00:05,460
+a system might look like in practice. And as you
+
+3
+00:00:05,460 --> 00:00:08,560
+can see, the configuration includes a set of components, which
+
+4
+00:00:08,560 --> 00:00:12,200
+are these rectangles over here. The components have various kinds of
+
+5
+00:00:12,200 --> 00:00:15,460
+ports, which are the ones marked here on the components
+
+6
+00:00:15,460 --> 00:00:17,760
+with different graphical representations. And
+
+7
+00:00:17,760 --> 00:00:19,760
+the components communicate through various
+
+8
+00:00:19,760 --> 00:00:22,860
+types of connectors, which are the grey elements here which
+
+9
+00:00:22,860 --> 00:00:25,570
+as you can see are used to connect the different components.
+
+10
+00:00:25,570 --> 00:00:28,180
+And something else that you can notice by looking at
+
+11
+00:00:28,180 --> 00:00:30,720
+this configuration is the fact that you can also have
+
+12
+00:00:30,720 --> 00:00:34,980
+hierarchically decomposable components. For example, if you look at the strategy
+
+13
+00:00:34,980 --> 00:00:39,250
+analyzer component, you can see that it has three subcomponents: one,
+
+14
+00:00:39,250 --> 00:00:42,110
+two, and three and two internal connectors as part of
+
+15
+00:00:42,110 --> 00:00:44,832
+it. And it is worth recalling here that a component
+
+16
+00:00:44,832 --> 00:00:47,152
+diagram as we said when first discussed in UML in
+
+17
+00:00:47,152 --> 00:00:51,230
+the course, can also be used to represent an architectural configuration.
+
+18
+00:00:51,230 --> 00:00:52,920
+So sometimes you will see architectural
+
+19
+00:00:52,920 --> 00:00:56,250
+configurations represented as UML component diagrams.
diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/19 - Deployment Architectural Perspective - lang_en_vs5.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/19 - Deployment Architectural Perspective - lang_en_vs5.srt
new file mode 100644
index 0000000..1cc7d89
--- /dev/null
+++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/19 - Deployment Architectural Perspective - lang_en_vs5.srt	
@@ -0,0 +1,103 @@
+1
+00:00:00,180 --> 00:00:03,100
+A system cannot fulfill its purpose until it is
+
+2
+00:00:03,100 --> 00:00:06,727
+deployed. And deploying a system involves physically placing the
+
+3
+00:00:06,727 --> 00:00:09,960
+system's executable modules on the hardware devices on which
+
+4
+00:00:09,960 --> 00:00:12,490
+they are supposed to run. So when you do that,
+
+5
+00:00:12,490 --> 00:00:16,132
+you're basically mapping your components and connectors to specific
+
+6
+00:00:16,132 --> 00:00:19,810
+hardware elements. Here in this diagram, for instance, I'm
+
+7
+00:00:19,810 --> 00:00:22,160
+showing the same components that we saw in the
+
+8
+00:00:22,160 --> 00:00:25,400
+previous diagram, but we see them deployed on a laptop,
+
+9
+00:00:25,400 --> 00:00:28,620
+which is depicted here in this way, and on two
+
+10
+00:00:28,620 --> 00:00:32,820
+smartphones that are represented here, or PDAs, if you wish.
+
+11
+00:00:32,820 --> 00:00:34,730
+So why do we this, why do we create
+
+12
+00:00:34,730 --> 00:00:38,540
+a deployment perspective for our architecture? Well, because the deployment
+
+13
+00:00:38,540 --> 00:00:41,710
+view of an architecture can be critical in assessing whether
+
+14
+00:00:41,710 --> 00:00:44,920
+the system will be able to satisfy its requirement. Because
+
+15
+00:00:44,920 --> 00:00:47,860
+doing this mapping allows you to discover and assess other
+
+16
+00:00:47,860 --> 00:00:50,840
+characteristics of your system that you might not have considered
+
+17
+00:00:50,840 --> 00:00:53,440
+up to now. For instance, using a deployment view like this
+
+18
+00:00:53,440 --> 00:00:57,030
+one and knowing the characteristics of the hardware devices, one might
+
+19
+00:00:57,030 --> 00:01:00,056
+be able to assess the system in terms of available memory.
+
+20
+00:01:00,056 --> 00:01:02,610
+Is there going to be enough memory available to run the system,
+
+21
+00:01:02,610 --> 00:01:06,140
+for example, on this device? Power consumption. Is the power consumption
+
+22
+00:01:06,140 --> 00:01:09,270
+profile going to be larger than what the device can handle?
+
+23
+00:01:09,270 --> 00:01:12,580
+Or again the required network bandwidth. Does the system have enough
+
+24
+00:01:12,580 --> 00:01:16,170
+network bandwidth to enable the required interactions? And so on. So all
+
+25
+00:01:16,170 --> 00:01:19,140
+of these characteristics, all of these qualities, you can assess when
+
+26
+00:01:19,140 --> 00:01:22,730
+you do this final mapping of the components to the hardware elements.
diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/2 - Interview with Nenad Medvidovic - lang_en_vs6.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/2 - Interview with Nenad Medvidovic - lang_en_vs6.srt
new file mode 100644
index 0000000..40fa57c
--- /dev/null
+++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/2 - Interview with Nenad Medvidovic - lang_en_vs6.srt	
@@ -0,0 +1,499 @@
+1
+00:00:00,220 --> 00:00:02,900
+Because the topic of today's lecture is software architecture,
+
+2
+00:00:02,900 --> 00:00:05,390
+it seemed appropriate to start the lesson by asking a
+
+3
+00:00:05,390 --> 00:00:08,960
+world expert on this topic, what is software architecture, and
+
+4
+00:00:08,960 --> 00:00:11,570
+why it is important. To do that, let's fly to
+
+5
+00:00:11,570 --> 00:00:14,910
+California, and more precisely, Los Angeles, and visit Professor
+
+6
+00:00:14,910 --> 00:00:19,540
+Nenad Medvidovic. Hi, I'm here visiting Professor Nenad Medvidovic from
+
+7
+00:00:19,540 --> 00:00:22,310
+the University of Southern California. And Neno is one of
+
+8
+00:00:22,310 --> 00:00:25,250
+the world experts in software architecture, actually one of the
+
+9
+00:00:25,250 --> 00:00:28,300
+authors of, of a recent book which is, sort of the
+
+10
+00:00:28,300 --> 00:00:31,660
+book in software architecture. What I would like to discuss with
+
+11
+00:00:31,660 --> 00:00:34,500
+Neno is the concept of software architecture and its importance. Because
+
+12
+00:00:34,500 --> 00:00:37,520
+people are very familiar with the idea and the cost of the
+
+13
+00:00:37,520 --> 00:00:41,240
+design. And software architecture is something is very related to that,
+
+14
+00:00:41,240 --> 00:00:43,690
+but is less known. So I would like for Nenad to
+
+15
+00:00:43,690 --> 00:00:46,350
+elaborate on that, and tell us why is it important to
+
+16
+00:00:46,350 --> 00:00:49,880
+focus also on this specific you know, architectural aspects of the software.
+
+17
+00:00:49,880 --> 00:00:50,380
+&gt;&gt; When you
+
+18
+00:00:50,380 --> 00:00:53,220
+build any software system, even a simple, relatively simple
+
+19
+00:00:53,220 --> 00:00:56,840
+one. You're going to go through, a process of making
+
+20
+00:00:56,840 --> 00:01:00,070
+many, many design decisions. Hundreds or thousands sometimes even tens
+
+21
+00:01:00,070 --> 00:01:03,140
+of thousands of design decisions, so any program that you
+
+22
+00:01:03,140 --> 00:01:06,090
+write at some point you get to deciding what
+
+23
+00:01:06,090 --> 00:01:09,385
+the interface of a particular method is going to be.
+
+24
+00:01:09,385 --> 00:01:12,170
+Are you're going to put in a parameter that is
+
+25
+00:01:12,170 --> 00:01:15,530
+an integer or a float. When you're writing your routine
+
+26
+00:01:15,530 --> 00:01:17,400
+about some sort you have to decide whether you're
+
+27
+00:01:17,400 --> 00:01:18,900
+going to use a static data structure or a
+
+28
+00:01:18,900 --> 00:01:22,410
+dynamic data structure. All these things are design decisions.
+
+29
+00:01:22,410 --> 00:01:25,770
+Many of them however, will typically, in the average
+
+30
+00:01:25,770 --> 00:01:29,030
+case, not really impact the success of your system
+
+31
+00:01:29,030 --> 00:01:31,640
+and the long term well-being of your system. But
+
+32
+00:01:31,640 --> 00:01:35,390
+typically the things that software engineers start struggling with
+
+33
+00:01:35,390 --> 00:01:40,760
+are other design decisions. Design decisions that are the equivalent
+
+34
+00:01:40,760 --> 00:01:42,080
+of load baring walls in a building
+
+35
+00:01:42,080 --> 00:01:42,660
+&gt;&gt; Mm hm
+
+36
+00:01:42,660 --> 00:01:43,950
+&gt;&gt; These are the things that, if you
+
+37
+00:01:43,950 --> 00:01:45,960
+don't get them right, or if you compromise
+
+38
+00:01:45,960 --> 00:01:50,190
+them, will in fact potentially impact how the
+
+39
+00:01:50,190 --> 00:01:54,300
+system operates. They might result in failures of different
+
+40
+00:01:54,300 --> 00:01:56,780
+kinds. They may result in a system that
+
+41
+00:01:56,780 --> 00:01:59,460
+is not easily maintainable and so forth. In
+
+42
+00:01:59,460 --> 00:02:01,680
+a sense, to make a long story short,
+
+43
+00:02:01,680 --> 00:02:05,888
+architectural design decisions are really the principle design decisions
+
+44
+00:02:05,888 --> 00:02:07,900
+in your system. These are the things that are
+
+45
+00:02:07,900 --> 00:02:10,550
+very important. All of the other design decisions you
+
+46
+00:02:10,550 --> 00:02:13,520
+could sort of tag with being important, but they're
+
+47
+00:02:13,520 --> 00:02:17,730
+sort of below this very important or highly important threshold.
+
+48
+00:02:17,730 --> 00:02:21,400
+&gt;&gt; So if you need to change a low level design decision, sometimes
+
+49
+00:02:21,400 --> 00:02:23,970
+it's kind of easy to do. It might change a little structure. Is it
+
+50
+00:02:23,970 --> 00:02:27,140
+the case that you know, being the architecture is sort of the pillar of
+
+51
+00:02:27,140 --> 00:02:29,020
+the software, is that going to be much
+
+52
+00:02:29,020 --> 00:02:32,380
+more difficult to change an architectural decision?
+
+53
+00:02:32,380 --> 00:02:34,400
+And architecture is deemed to be you know,
+
+54
+00:02:34,400 --> 00:02:36,120
+say if you start with the wrong architecture the
+
+55
+00:02:36,120 --> 00:02:39,510
+software is going to, you know, necessarily be unsuccessful.
+
+56
+00:02:39,510 --> 00:02:41,320
+Or you can also do something that is better.
+
+57
+00:02:41,320 --> 00:02:46,070
+&gt;&gt; A system could be successful and very poorly architected. Just
+
+58
+00:02:46,070 --> 00:02:50,630
+like a building or an airplane or a car, any other
+
+59
+00:02:50,630 --> 00:02:54,700
+engineering artifact could be successful but poorly architected. So success we
+
+60
+00:02:54,700 --> 00:02:57,440
+can separated from this, but the, the point that you make in
+
+61
+00:02:57,440 --> 00:03:00,530
+asking this question is an important one. The
+
+62
+00:03:00,530 --> 00:03:04,260
+non-architectural design decisions, should be on the
+
+63
+00:03:04,260 --> 00:03:06,250
+average, there are exceptions and we need to
+
+64
+00:03:06,250 --> 00:03:09,580
+acknowledge that there is no one size fits all
+
+65
+00:03:09,580 --> 00:03:11,640
+type of solution for anything in software engineering
+
+66
+00:03:11,640 --> 00:03:15,060
+really. But on the average, the non-architectural design decisions,
+
+67
+00:03:15,060 --> 00:03:17,650
+should be much easier to make. So the
+
+68
+00:03:17,650 --> 00:03:22,600
+scale of the consequences of making such a change.
+
+69
+00:03:22,600 --> 00:03:25,880
+Really can vary from very minor, highly localized
+
+70
+00:03:25,880 --> 00:03:29,670
+to very important and sometimes, even system wide.
+
+71
+00:03:29,670 --> 00:03:33,570
+&gt;&gt; To conclude, I just like to ask you about some concept that is
+
+72
+00:03:33,570 --> 00:03:35,110
+we here about a lot. Which is
+
+73
+00:03:35,110 --> 00:03:37,430
+architectural erosion. Since, we're talking about in with
+
+74
+00:03:37,430 --> 00:03:39,760
+fine architecture and software evolution. So, what is,
+
+75
+00:03:39,760 --> 00:03:42,090
+exactly, an architectural erosion and why does that
+
+76
+00:03:42,090 --> 00:03:47,600
+happen? So, to go back to our non software metaphors. Imagine you buy a car.
+
+77
+00:03:47,600 --> 00:03:49,810
+And your car has four wheels, it has a steering wheel, it has
+
+78
+00:03:49,810 --> 00:03:53,700
+a nice chassis, it looks pretty nice. At one point, you end up
+
+79
+00:03:53,700 --> 00:03:54,950
+replacing its 150 horsepower engine with
+
+80
+00:03:54,950 --> 00:03:56,800
+a 250 horsepower engine because that's what
+
+81
+00:03:56,800 --> 00:04:01,510
+you want. And you start putting a spoiler on the back of the car
+
+82
+00:04:01,510 --> 00:04:04,680
+and then you replace the headlights. And then you replace the side view
+
+83
+00:04:04,680 --> 00:04:08,000
+mirrors with smaller ones because you want your car to be more aerodynamic.
+
+84
+00:04:08,000 --> 00:04:10,620
+And then you start tinkering with other things, like you cut the, maybe
+
+85
+00:04:10,620 --> 00:04:13,380
+the roof of the car because you want to turn it into a convertible,
+
+86
+00:04:13,380 --> 00:04:15,990
+et cetera. And in the end, what you have is
+
+87
+00:04:15,990 --> 00:04:19,810
+a car that is still your car. Looks very different, It's
+
+88
+00:04:19,810 --> 00:04:23,650
+structural and behavioral properties are very different And, what you
+
+89
+00:04:23,650 --> 00:04:27,260
+might find is that the car doesn't handle nearly as well.
+
+90
+00:04:27,260 --> 00:04:29,670
+For example, in a very sharp turn it might not
+
+91
+00:04:29,670 --> 00:04:31,910
+be able to negotiate a steep hill as well. Because you
+
+92
+00:04:31,910 --> 00:04:35,760
+pretty much changed it all along the way. Architectural erosion in
+
+93
+00:04:35,760 --> 00:04:38,620
+the case of a software system is the exact same thing
+
+94
+00:04:38,620 --> 00:04:41,480
+with one huge caveat. Very few, if any of us,
+
+95
+00:04:41,480 --> 00:04:44,970
+will ever put a new engine into our car or tinker
+
+96
+00:04:44,970 --> 00:04:47,390
+with the structural soundness of the car by cutting off the
+
+97
+00:04:47,390 --> 00:04:50,260
+roof etc. In a software system we do it all the
+
+98
+00:04:50,260 --> 00:04:53,530
+time. We'll add a feature. We'll change one bit of the
+
+99
+00:04:53,530 --> 00:04:57,088
+user interface here. We'll port it to a new platform, some
+
+100
+00:04:57,088 --> 00:05:00,990
+kind of a, a mobile platform, for example. And pretty soon,
+
+101
+00:05:00,990 --> 00:05:03,750
+what you end up with is really a software system that,
+
+102
+00:05:03,750 --> 00:05:06,990
+that is maybe a distant relative of your original
+
+103
+00:05:06,990 --> 00:05:10,500
+system. It is a mutant in many ways, because often
+
+104
+00:05:10,500 --> 00:05:12,986
+times these little tinkerings happen on a one off
+
+105
+00:05:12,986 --> 00:05:15,610
+basis. There is no over-arching vision of how you should
+
+106
+00:05:15,610 --> 00:05:19,060
+do this. So, you are basically going through a
+
+107
+00:05:19,060 --> 00:05:21,980
+subsequent set of steps where you are making locally optimal
+
+108
+00:05:21,980 --> 00:05:25,240
+decisions for any one of these changes and what
+
+109
+00:05:25,240 --> 00:05:29,140
+you might end up finding is that the globally optimal
+
+110
+00:05:29,140 --> 00:05:32,100
+behavior of the system is badly compromised. The structural
+
+111
+00:05:32,100 --> 00:05:34,952
+soundness in a sense of the system badly compromised.
+
+112
+00:05:34,952 --> 00:05:38,510
+The non-functional properties of the system could be seriously
+
+113
+00:05:38,510 --> 00:05:42,390
+affected. This is how security flaws creep into systems. This
+
+114
+00:05:42,390 --> 00:05:44,250
+is how reliability flaws. This is how we use
+
+115
+00:05:44,250 --> 00:05:48,420
+the usability of a system often times suffers. And most
+
+116
+00:05:48,420 --> 00:05:50,920
+importantly for software engineers, the people who actually build the
+
+117
+00:05:50,920 --> 00:05:54,950
+software, the maintainability of the system becomes a huge problem.
+
+118
+00:05:54,950 --> 00:05:59,130
+Because now you're looking at this thing, it's got all these various appendages,
+
+119
+00:05:59,130 --> 00:06:03,170
+its original design has pretty badly eroded and yet somehow you have to
+
+120
+00:06:03,170 --> 00:06:06,850
+figure out how to keep fixing it. Making sure that it operates in
+
+121
+00:06:06,850 --> 00:06:11,380
+a continuous fashion because many of these systems live for 20, 30, 40 years.
+
+122
+00:06:11,380 --> 00:06:13,840
+&gt;&gt; Thank you so much for your insight; it is a perfect
+
+123
+00:06:13,840 --> 00:06:16,500
+introduction for our lesson. So we'll get to the lesson now. And.
+
+124
+00:06:16,500 --> 00:06:17,920
+&gt;&gt; Thank you very much.
+
+125
+00:06:17,920 --> 00:06:18,300
+&gt;&gt; Thank you.
diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/20 - Architectural Styles - lang_en_vs5.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/20 - Architectural Styles - lang_en_vs5.srt
new file mode 100644
index 0000000..b4ee115
--- /dev/null
+++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/20 - Architectural Styles - lang_en_vs5.srt	
@@ -0,0 +1,111 @@
+1
+00:00:00,210 --> 00:00:01,569
+The last topic I want to cover in
+
+2
+00:00:01,569 --> 00:00:04,939
+this lesson is architectural styles. So, let's see
+
+3
+00:00:04,939 --> 00:00:07,400
+what those architectural styles are. There are certain
+
+4
+00:00:07,400 --> 00:00:10,240
+design choices that when applied in a given context
+
+5
+00:00:10,240 --> 00:00:14,420
+regularly result in solutions with superior properties. What
+
+6
+00:00:14,420 --> 00:00:17,290
+this means is that, compared to other possible alternatives,
+
+7
+00:00:17,290 --> 00:00:20,952
+these solutions are more elegant, effective, efficient, dependable,
+
+8
+00:00:20,952 --> 00:00:25,560
+evolve-able, scale-able, and so on. Architectural styles capture exactly
+
+9
+00:00:25,560 --> 00:00:28,490
+these solutions. They capture idioms that we can
+
+10
+00:00:28,490 --> 00:00:30,870
+use when designing a system. For a more formal
+
+11
+00:00:30,870 --> 00:00:34,160
+definition, let's look how Mary Shaw and David Garlan
+
+12
+00:00:34,160 --> 00:00:37,480
+define a architectural style. They say that an architectural
+
+13
+00:00:37,480 --> 00:00:40,000
+style defines a family of systems in terms
+
+14
+00:00:40,000 --> 00:00:43,550
+of a pattern of structural organization; a vocabulary of
+
+15
+00:00:43,550 --> 00:00:47,880
+components and connectors and constraints on how these components
+
+16
+00:00:47,880 --> 00:00:50,620
+and connectors can be combined. So in summary we
+
+17
+00:00:50,620 --> 00:00:53,650
+can say that an architectural style is a named collection
+
+18
+00:00:53,650 --> 00:00:57,680
+of architectural design decisions applicable in a given context. And I
+
+19
+00:00:57,680 --> 00:01:00,100
+want to stress that it is important to study and
+
+20
+00:01:00,100 --> 00:01:04,670
+know these architectural styles for several reasons. Because knowing them allows
+
+21
+00:01:04,670 --> 00:01:07,660
+us to avoid reinventing the wheel. It also allows us
+
+22
+00:01:07,660 --> 00:01:10,330
+to choose the right solution to a known problem and in
+
+23
+00:01:10,330 --> 00:01:12,910
+some cases it even allows us to move on and
+
+24
+00:01:12,910 --> 00:01:16,400
+discover even more advanced styles if we know the basic ones.
+
+25
+00:01:16,400 --> 00:01:19,340
+So we should be familiar with architectural styles, what
+
+26
+00:01:19,340 --> 00:01:22,000
+they are, and in which context they work, and
+
+27
+00:01:22,000 --> 00:01:23,800
+in which context they do not work. So as
+
+28
+00:01:23,800 --> 00:01:26,090
+to be able to apply them in the right situations.
diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/21 - Types of Architectural Styles - lang_en_vs5.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/21 - Types of Architectural Styles - lang_en_vs5.srt
new file mode 100644
index 0000000..05011c7
--- /dev/null
+++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/21 - Types of Architectural Styles - lang_en_vs5.srt	
@@ -0,0 +1,239 @@
+1
+00:00:00,130 --> 00:00:02,410
+So what does it mean to know architectural styles? There
+
+2
+00:00:02,410 --> 00:00:06,390
+are many many, many architectural styles. So we cannot cover them
+
+3
+00:00:06,390 --> 00:00:08,730
+all here. What I want to do instead is, I want to
+
+4
+00:00:08,730 --> 00:00:10,960
+mention a few of those. And then I want to go in
+
+5
+00:00:10,960 --> 00:00:13,300
+more depth, on one of them. So the first item I
+
+6
+00:00:13,300 --> 00:00:17,420
+want to mention is pipes and filters. And pipes and filters indicate
+
+7
+00:00:17,420 --> 00:00:21,110
+an architectural style in which a chain of processing elements, which
+
+8
+00:00:21,110 --> 00:00:25,410
+can be processes, threads, co-routines, is arranged so that the output
+
+9
+00:00:25,410 --> 00:00:28,420
+of each element is the input of the next one
+
+10
+00:00:28,420 --> 00:00:31,840
+and usually with some buffering in between consecutive elements. A
+
+11
+00:00:31,840 --> 00:00:34,120
+typical example of this, if you're familiar with Unix are
+
+12
+00:00:34,120 --> 00:00:37,900
+Unix pipes, that you can use to concatenate Unix commands.
+
+13
+00:00:37,900 --> 00:00:40,310
+Another style I want to mention is the event driven
+
+14
+00:00:40,310 --> 00:00:43,540
+one. An event driven system typically consists of event
+
+15
+00:00:43,540 --> 00:00:46,590
+emittors, like the alarm over here, and event consumers, like
+
+16
+00:00:46,590 --> 00:00:50,720
+the fire truck, down here, and consumers are notified when events
+
+17
+00:00:50,720 --> 00:00:53,810
+of interest occurr and have the responsibility of reacting
+
+18
+00:00:53,810 --> 00:00:56,676
+to those events. A typical example will be a GUI,
+
+19
+00:00:56,676 --> 00:00:59,950
+in which widgets generate events and listeners listen to those
+
+20
+00:00:59,950 --> 00:01:02,550
+events and react to them. For example, they react to
+
+21
+00:01:02,550 --> 00:01:05,060
+the push of a button. A very commonly used
+
+22
+00:01:05,060 --> 00:01:09,250
+architectural style is Publish-subscribe, represented by the paper boy. Over
+
+23
+00:01:09,250 --> 00:01:12,420
+here. And this is an architectural style in which senders
+
+24
+00:01:12,420 --> 00:01:15,870
+of messages, they're called publishers, do not send messages directly
+
+25
+00:01:15,870 --> 00:01:19,330
+to specific recievers. Instead, they publish messages with one
+
+26
+00:01:19,330 --> 00:01:22,530
+or more associated texts without knowledge of who will
+
+27
+00:01:22,530 --> 00:01:26,810
+receive such messages. Similarly subscribers will express interest in
+
+28
+00:01:26,810 --> 00:01:29,340
+one or more tags. And will only receive messages of
+
+29
+00:01:29,340 --> 00:01:32,095
+interest according to such tags. A typical example of
+
+30
+00:01:32,095 --> 00:01:35,240
+a publish-subscribe system, will be Twitter. And I'm pretty
+
+31
+00:01:35,240 --> 00:01:36,835
+sure that most of you are familiar with the
+
+32
+00:01:36,835 --> 00:01:41,170
+client-server architecture. In which computers in a network, assume one
+
+33
+00:01:41,170 --> 00:01:43,930
+of two roles. The server provides the resources and
+
+34
+00:01:43,930 --> 00:01:47,630
+functionality. And the client initiates contact with the server,
+
+35
+00:01:47,630 --> 00:01:50,920
+and requests the use of those resources and functionality.
+
+36
+00:01:50,920 --> 00:01:53,340
+Also in this case, a typical example would be
+
+37
+00:01:53,340 --> 00:01:56,470
+email, in which an email server provides email storage
+
+38
+00:01:56,470 --> 00:01:59,390
+and management capabilities, and an email client will use
+
+39
+00:01:59,390 --> 00:02:02,580
+those capabilities. You may also be familiar with peer-to-peer,
+
+40
+00:02:02,580 --> 00:02:06,530
+or P2P, systems. A P2P system is a type
+
+41
+00:02:06,530 --> 00:02:10,850
+of decentralized and distributed network system in which individual nodes
+
+42
+00:02:10,850 --> 00:02:14,220
+in the network, that are called peers, act as independent
+
+43
+00:02:14,220 --> 00:02:17,940
+agents that are both suppliers and consumers of resources. This
+
+44
+00:02:17,940 --> 00:02:20,700
+is in contrast to the centralized client-server model, where client
+
+45
+00:02:20,700 --> 00:02:23,660
+nodes interact with the central authority. And I'm not going to
+
+46
+00:02:23,660 --> 00:02:26,030
+say anything more about peer-to-peer, because I'm going to show you
+
+47
+00:02:26,030 --> 00:02:28,940
+two examples, of peer-to-peer systems in the rest of the
+
+48
+00:02:28,940 --> 00:02:32,040
+lesson. And you probably have at least heard of rest.
+
+49
+00:02:32,040 --> 00:02:33,990
+Which in this case is not an invitation to
+
+50
+00:02:33,990 --> 00:02:36,970
+relax as the graphic might indicate. But rather stands for
+
+51
+00:02:36,970 --> 00:02:41,400
+Representational State Transfer. REST is a hybrid architectural style
+
+52
+00:02:41,400 --> 00:02:45,150
+for distributed hypermedia systems, that is derived from several other
+
+53
+00:02:45,150 --> 00:02:48,210
+network based architectural styles. And that is characterized by
+
+54
+00:02:48,210 --> 00:02:51,970
+uniform connector interface, and even if I'm not going to say
+
+55
+00:02:51,970 --> 00:02:54,230
+anything else about the rest, I wanted to mention
+
+56
+00:02:54,230 --> 00:02:57,440
+it, because it is an extremely well known architectural style.
+
+57
+00:02:57,440 --> 00:02:59,300
+And the reason for this is that REST is
+
+58
+00:02:59,300 --> 00:03:03,310
+very widely used, because it is basically the architectural style
+
+59
+00:03:03,310 --> 00:03:06,050
+that governs the world wide web. So we use it
+
+60
+00:03:06,050 --> 00:03:08,330
+all the time when we browse the internet, for instance.
diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/22 - Architectural Styles Quiz - lang_en_vs4.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/22 - Architectural Styles Quiz - lang_en_vs4.srt
new file mode 100644
index 0000000..2e8c051
--- /dev/null
+++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/22 - Architectural Styles Quiz - lang_en_vs4.srt	
@@ -0,0 +1,27 @@
+1
+00:00:00,090 --> 00:00:02,630
+Consider now the following architectural styles
+
+2
+00:00:02,630 --> 00:00:04,356
+that we just saw: pipes and filters,
+
+3
+00:00:04,356 --> 00:00:09,310
+event-driven, publish-subscribe, client-server, peer-to-peer, and rest.
+
+4
+00:00:09,310 --> 00:00:11,150
+I'm showing you here, a list of
+
+5
+00:00:11,150 --> 00:00:15,220
+four different systems, and I would like for you to mark here which
+
+6
+00:00:15,220 --> 00:00:18,750
+architectural style, or styles, characterize Each of
+
+7
+00:00:18,750 --> 00:00:21,510
+these systems. Again, mark all that apply.
diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/23 - Architectural Styles Quiz Solution - lang_en_vs5.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/23 - Architectural Styles Quiz Solution - lang_en_vs5.srt
new file mode 100644
index 0000000..d48320b
--- /dev/null
+++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/23 - Architectural Styles Quiz Solution - lang_en_vs5.srt	
@@ -0,0 +1,79 @@
+1
+00:00:00,150 --> 00:00:02,680
+Okay, let's start with the Android Operating System. The Android
+
+2
+00:00:02,680 --> 00:00:07,170
+system, heavily based on the generation and handling of events,
+
+3
+00:00:07,170 --> 00:00:10,640
+so it is mostly an event driven system. However, it
+
+4
+00:00:10,640 --> 00:00:13,870
+also has some elements of publish, subscribe, in the way
+
+5
+00:00:13,870 --> 00:00:17,480
+elements in the system can register for elements of interest.
+
+6
+00:00:17,480 --> 00:00:20,570
+So we can mark both styles here. So what about
+
+7
+00:00:20,570 --> 00:00:23,449
+Skype? We haven't discussed Skype yet. So here we probably
+
+8
+00:00:23,449 --> 00:00:25,019
+had to take a little bit of a wild guess.
+
+9
+00:00:25,019 --> 00:00:27,068
+But as we will see in more detail in the
+
+10
+00:00:27,068 --> 00:00:29,736
+rest of the lesson. Skype is mainly a peer to
+
+11
+00:00:29,736 --> 00:00:34,035
+peer architecture, with some minimal elements of a client server
+
+12
+00:00:34,035 --> 00:00:37,770
+architecture. For example, when you start Skype and sign in
+
+13
+00:00:37,770 --> 00:00:40,420
+to a conceptually centralized server. So let's move to the
+
+14
+00:00:40,420 --> 00:00:42,930
+World Wide Web. As we just discussed, the Word Wide
+
+15
+00:00:42,930 --> 00:00:46,255
+Web is based on a rest architecture. And because rest
+
+16
+00:00:46,255 --> 00:00:50,170
+style, is a hybrid derived from other architectural styles, including the
+
+17
+00:00:50,170 --> 00:00:53,960
+client server architectural styles. Both of those styles apply here.
+
+18
+00:00:53,960 --> 00:00:57,465
+And finally Dropbox is by and large, a client server
+
+19
+00:00:57,465 --> 00:01:01,904
+architecture. As conceptually, we upload our documents to a Dropbox
+
+20
+00:01:01,904 --> 00:01:05,370
+central server, and get the files from the same server.
diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/24 - P2P Architectures - lang_en_vs5.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/24 - P2P Architectures - lang_en_vs5.srt
new file mode 100644
index 0000000..927c773
--- /dev/null
+++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/24 - P2P Architectures - lang_en_vs5.srt	
@@ -0,0 +1,39 @@
+1
+00:00:00,170 --> 00:00:02,110
+We're not going to be able to study indepth
+
+2
+00:00:02,110 --> 00:00:05,590
+any of the architectural styles that we just discussed. However, I
+
+3
+00:00:05,590 --> 00:00:08,790
+want to at least discuss two representative examples of P2P
+
+4
+00:00:08,790 --> 00:00:12,100
+architectures. Because, these are systems that you probably used, or at
+
+5
+00:00:12,100 --> 00:00:14,090
+least, you used one of them. And, they will allow
+
+6
+00:00:14,090 --> 00:00:17,590
+me to highlight some interesting points. So, as we just mentioned,
+
+7
+00:00:17,590 --> 00:00:22,450
+P2P systems are decentralized resource sharing and discovery systems. And the
+
+8
+00:00:22,450 --> 00:00:25,370
+two systems that I want to discuss, and that are representative
+
+9
+00:00:25,370 --> 00:00:29,630
+of this kind of architectures, are Napster and Skype. And you may or
+
+10
+00:00:29,630 --> 00:00:32,920
+may not be familiar with Napster, but I'm pretty sure that you know Skype.
diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/25 - Napster Example - lang_en_vs4.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/25 - Napster Example - lang_en_vs4.srt
new file mode 100644
index 0000000..d3ab75b
--- /dev/null
+++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/25 - Napster Example - lang_en_vs4.srt	
@@ -0,0 +1,231 @@
+1
+00:00:00,160 --> 00:00:03,160
+So let's start by considering Napster. In it's first
+
+2
+00:00:03,160 --> 00:00:07,210
+incarnation, Napster was a peer-to-peer file sharing system. And
+
+3
+00:00:07,210 --> 00:00:10,200
+it was mostly used, actually, to illegally share mp3s.
+
+4
+00:00:10,200 --> 00:00:12,630
+Which is also why it got sued and later
+
+5
+00:00:12,630 --> 00:00:16,129
+on, it basically ceased operations. But nevertheless, I think
+
+6
+00:00:16,129 --> 00:00:19,710
+Napster is an interesting example of mixed architecture. And
+
+7
+00:00:19,710 --> 00:00:22,020
+I'm going to illustrate the way Napster works by showing
+
+8
+00:00:22,020 --> 00:00:25,820
+you, here, the basic configuration of Napster and the interactions
+
+9
+00:00:25,820 --> 00:00:28,950
+between its elements. So let's look at how such interaction
+
+10
+00:00:28,950 --> 00:00:32,250
+can take place for the three peers shown here. And
+
+11
+00:00:32,250 --> 00:00:34,430
+in this case Peer A and B are the only
+
+12
+00:00:34,430 --> 00:00:37,290
+ones really involved in the action. So let's look at
+
+13
+00:00:37,290 --> 00:00:40,700
+a typical sequence of events for the Napster system. We
+
+14
+00:00:40,700 --> 00:00:44,340
+have Peer A that will start by registering, here, with
+
+15
+00:00:44,340 --> 00:00:47,530
+the content directory. Peer B will also register with the
+
+16
+00:00:47,530 --> 00:00:50,970
+content directory. And when these two peers register, the content directory
+
+17
+00:00:50,970 --> 00:00:54,370
+will know what kind of content they can provide. Later on,
+
+18
+00:00:54,370 --> 00:00:57,660
+Peer A will request a song. And one first observation that
+
+19
+00:00:57,660 --> 00:01:00,550
+we can make, based on this interaction, is the fact that,
+
+20
+00:01:00,550 --> 00:01:03,900
+up to now, this is a purely client-server system. This is
+
+21
+00:01:03,900 --> 00:01:06,530
+the client. This is the client. And this is the server.
+
+22
+00:01:06,530 --> 00:01:10,320
+And the interaction is a typical client-server interaction. But now we're
+
+23
+00:01:10,320 --> 00:01:12,410
+at the point in which things start to change a little
+
+24
+00:01:12,410 --> 00:01:16,008
+bit. At this point, after Peer A has requested the song,
+
+25
+00:01:16,008 --> 00:01:18,820
+the peer and content directory will look up its
+
+26
+00:01:18,820 --> 00:01:22,730
+gigantic index and will see that Peer B actually has
+
+27
+00:01:22,730 --> 00:01:24,850
+the song that Peer A requested. So it will
+
+28
+00:01:24,850 --> 00:01:27,690
+send to Peer A a handle that Peer A can
+
+29
+00:01:27,690 --> 00:01:31,052
+use to connect directly to Peer B. So this
+
+30
+00:01:31,052 --> 00:01:34,540
+is where the system is no longer a client-server system.
+
+31
+00:01:34,540 --> 00:01:37,890
+Because at this point, the two peers are connected directly.
+
+32
+00:01:37,890 --> 00:01:41,000
+So at this point, we have a peer-to-peer interaction. And,
+
+33
+00:01:41,000 --> 00:01:43,770
+after getting the request from Peer A, then Peer B
+
+34
+00:01:43,770 --> 00:01:47,170
+will start sending the content to Peer A. And I said
+
+35
+00:01:47,170 --> 00:01:50,660
+earlier that one of the useful things about representing an
+
+36
+00:01:50,660 --> 00:01:52,440
+architecture and interaction within an
+
+37
+00:01:52,440 --> 00:01:54,580
+architecture graphically, is the fact that
+
+38
+00:01:54,580 --> 00:01:57,550
+it allows you to spot possible problems. And in this
+
+39
+00:01:57,550 --> 00:02:00,666
+case, by representing the Napster architecture in this way, and by
+
+40
+00:02:00,666 --> 00:02:03,300
+studying how things work, we can see that there's an
+
+41
+00:02:03,300 --> 00:02:06,010
+issue with the architecture of Napster that will not make this
+
+42
+00:02:06,010 --> 00:02:10,020
+architecture scale. As some of you might have already noticed, this peer
+
+43
+00:02:10,020 --> 00:02:13,720
+and content directory is a single point of failure, and is very
+
+44
+00:02:13,720 --> 00:02:17,230
+likely to cause problems when the number of peers grows too large.
+
+45
+00:02:17,230 --> 00:02:19,890
+Because at that point, there are going to be too many requests to
+
+46
+00:02:19,890 --> 00:02:22,840
+the peer and content directory, and the peer and content directory is
+
+47
+00:02:22,840 --> 00:02:25,460
+unlikely to be able to keep up with all the requests. So
+
+48
+00:02:25,460 --> 00:02:27,840
+some changes in the architecture will have to be made. In the
+
+49
+00:02:27,840 --> 00:02:31,310
+case of Napster, we didn't see this problem occurring because, as I said
+
+50
+00:02:31,310 --> 00:02:34,420
+earlier, Napster got sued and ceased operation before the problem
+
+51
+00:02:34,420 --> 00:02:37,650
+actually manifested. Now looking at the system for an architecture-style
+
+52
+00:02:37,650 --> 00:02:40,560
+perspective, we can see that Napster was a hybrid architecture
+
+53
+00:02:40,560 --> 00:02:43,920
+with both client-server and peer-to-peer elements. And something I would
+
+54
+00:02:43,920 --> 00:02:45,870
+like to stress here, is that this is not at
+
+55
+00:02:45,870 --> 00:02:49,400
+all uncommon. So in real world nontrivial architectures, it is
+
+56
+00:02:49,400 --> 00:02:52,470
+very common to see multiple styles used in the same
+
+57
+00:02:52,470 --> 00:02:56,209
+system. The next system that we will consider, Skype, is instead,
+
+58
+00:02:56,209 --> 00:02:59,885
+an example of a well-designed, almost purely peer-to-peer system.
diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/26 - Skype Example - lang_en_vs5.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/26 - Skype Example - lang_en_vs5.srt
new file mode 100644
index 0000000..2118c73
--- /dev/null
+++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/26 - Skype Example - lang_en_vs5.srt	
@@ -0,0 +1,287 @@
+1
+00:00:00,220 --> 00:00:03,040
+So even if you're too young to have used Napster,
+
+2
+00:00:03,040 --> 00:00:06,150
+I'm pretty sure that most of you know and use Skype,
+
+3
+00:00:06,150 --> 00:00:10,180
+a Voice Over IP and instant messaging service. Many of
+
+4
+00:00:10,180 --> 00:00:13,790
+you, however, probably don't know how Skype works. To understand that,
+
+5
+00:00:13,790 --> 00:00:16,360
+let's have a look at Skype's architecture, which I'm sketching
+
+6
+00:00:16,360 --> 00:00:19,890
+here, and which is a peer-to-peer architecture with a small twist.
+
+7
+00:00:19,890 --> 00:00:22,300
+So first of all, by looking at the architecture we can
+
+8
+00:00:22,300 --> 00:00:25,600
+see that whereas Napster was a client-server system with an element
+
+9
+00:00:25,600 --> 00:00:29,960
+of peer-to-peer, Skype is a much more decentralized system. Why
+
+10
+00:00:29,960 --> 00:00:31,940
+is that? Well, if we look here, we can see
+
+11
+00:00:31,940 --> 00:00:34,720
+that there is a login server -- this node over
+
+12
+00:00:34,720 --> 00:00:38,670
+here -- and that means that every Skype user has to register
+
+13
+00:00:38,670 --> 00:00:42,000
+with this centralized service. But that's the only interaction of
+
+14
+00:00:42,000 --> 00:00:44,930
+this kind within Skype. After you log in, all you
+
+15
+00:00:44,930 --> 00:00:47,580
+get is a connection through a super node like this
+
+16
+00:00:47,580 --> 00:00:50,760
+one. So, what are super nodes? Super nodes are highly reliable
+
+17
+00:00:50,760 --> 00:00:54,680
+nodes with high bandwidth that are not behind a firewall
+
+18
+00:00:54,680 --> 00:00:58,180
+and that runs Skype regularly, which means that nodes that shut
+
+19
+00:00:58,180 --> 00:01:01,540
+down Skype occasionally will not qualify as super nodes. And one
+
+20
+00:01:01,540 --> 00:01:04,239
+interesting thing about super nodes is that they're not owned by
+
+21
+00:01:04,239 --> 00:01:07,990
+Skype. They're just regular nodes that get promoted by Skype to
+
+22
+00:01:07,990 --> 00:01:11,500
+super nodes, and that know about each other. So basically Skype
+
+23
+00:01:11,500 --> 00:01:13,710
+has an algorithm that looks at the nodes in the system
+
+24
+00:01:13,710 --> 00:01:15,880
+and decides whether a node can be a super node or
+
+25
+00:01:15,880 --> 00:01:18,932
+not based on its characteristics. So now that we've discussed
+
+26
+00:01:18,932 --> 00:01:22,040
+super nodes, let's see what will happen if peer two wanted
+
+27
+00:01:22,040 --> 00:01:25,091
+to communicate with peer three. So let's represent this by
+
+28
+00:01:25,091 --> 00:01:27,956
+creating a dashed line between peer two and peer three. In
+
+29
+00:01:27,956 --> 00:01:30,980
+this case, peer two will contact this super node, which
+
+30
+00:01:30,980 --> 00:01:33,750
+is super node A. And super node A, based on its
+
+31
+00:01:33,750 --> 00:01:36,570
+knowledge of the Skype network and the position of the super
+
+32
+00:01:36,570 --> 00:01:40,930
+nodes, will contact and route the communication through super node C,
+
+33
+00:01:40,930 --> 00:01:44,100
+which will in turn route the communication to peer three.
+
+34
+00:01:44,100 --> 00:01:46,620
+And in that way peer two and peer three will be
+
+35
+00:01:46,620 --> 00:01:50,740
+able to communicate with each other. And this will happen just
+
+36
+00:01:50,740 --> 00:01:53,970
+as if peer two and peer three were connected directly, as
+
+37
+00:01:53,970 --> 00:01:57,760
+peers, even though the communication goes through two super nodes. Another
+
+38
+00:01:57,760 --> 00:02:00,470
+thing that is important to know about the behavior of Skype
+
+39
+00:02:00,470 --> 00:02:03,760
+is that, if the link between super nodes A and C
+
+40
+00:02:03,760 --> 00:02:05,950
+were to go down. So let's assume that there is a
+
+41
+00:02:05,950 --> 00:02:10,840
+problem with this link, then Skype will automatically, or automagically
+
+42
+00:02:10,840 --> 00:02:14,550
+reroute the communication through super node B, which will in
+
+43
+00:02:14,550 --> 00:02:17,950
+turn reroute it super node C, which will again reroute
+
+44
+00:02:17,950 --> 00:02:20,020
+to peer three. So peer two and three will still
+
+45
+00:02:20,020 --> 00:02:22,550
+be connected, but this time they will be going through
+
+46
+00:02:22,550 --> 00:02:25,620
+three super nodes. And just in case you wondered, this
+
+47
+00:02:25,620 --> 00:02:28,620
+is exactly what happens when you are talking over Skype.
+
+48
+00:02:28,620 --> 00:02:31,790
+The quality of the communication degrades, and you are reconnected.
+
+49
+00:02:31,790 --> 00:02:34,880
+So there is this rerouting going on through different nodes. So
+
+50
+00:02:34,880 --> 00:02:37,640
+although this architecture is more effective than the Napster's one, it
+
+51
+00:02:37,640 --> 00:02:40,640
+is not without problems. For example, you might remember that a
+
+52
+00:02:40,640 --> 00:02:44,640
+few years ago, Skype went down for about 36 hours. And
+
+53
+00:02:44,640 --> 00:02:47,880
+later on it was discovered that the cause was the algorithm
+
+54
+00:02:47,880 --> 00:02:51,460
+used by Skype to determine which nodes could be super nodes.
+
+55
+00:02:51,460 --> 00:02:54,330
+And remember, as I said, that one requirement for these nodes
+
+56
+00:02:54,330 --> 00:02:57,130
+is that have to up all the time. So what happened
+
+57
+00:02:57,130 --> 00:03:00,420
+is most of the super nodes were running on Windows machines,
+
+58
+00:03:00,420 --> 00:03:03,820
+and Microsoft pushed a critical patch that required a reboot to
+
+59
+00:03:03,820 --> 00:03:06,860
+be installed. So a large number of machines, and therefore a
+
+60
+00:03:06,860 --> 00:03:10,150
+large number of super nodes were down roughly at the same
+
+61
+00:03:10,150 --> 00:03:13,980
+time throughout the globe. And Skype's algorithm for determining super nodes
+
+62
+00:03:13,980 --> 00:03:17,230
+didn't have enough nodes to work with. So the whole system
+
+63
+00:03:17,230 --> 00:03:19,790
+crashed and burned. So the message I want to give here,
+
+64
+00:03:19,790 --> 00:03:22,340
+is that when you have a large peer to peer distributed
+
+65
+00:03:22,340 --> 00:03:24,650
+system, such as this one, such as Skype,
+
+66
+00:03:24,650 --> 00:03:27,200
+these kind of perfect storms can happen. Because you
+
+67
+00:03:27,200 --> 00:03:29,560
+are not really in control. Because the control
+
+68
+00:03:29,560 --> 00:03:33,170
+is distributed. So the algorithms become more complex. So
+
+69
+00:03:33,170 --> 00:03:35,140
+to wrap up our Skype example, in case
+
+70
+00:03:35,140 --> 00:03:37,280
+you are interested, Skype then fixed the issue by
+
+71
+00:03:37,280 --> 00:03:39,950
+changing the algorithm for identifying super nodes. And
+
+72
+00:03:39,950 --> 00:03:44,084
+more recently actually, Skype ditched peer-to-peer super nodes altogether.
diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/27 - Takeaway Message - lang_en_vs5.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/27 - Takeaway Message - lang_en_vs5.srt
new file mode 100644
index 0000000..9cd15c3
--- /dev/null
+++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/27 - Takeaway Message - lang_en_vs5.srt	
@@ -0,0 +1,131 @@
+1
+00:00:00,100 --> 00:00:02,620
+And I want to conclude this lesson with three takeaway
+
+2
+00:00:02,620 --> 00:00:06,190
+messages. The first one is that having an effective architecture is
+
+3
+00:00:06,190 --> 00:00:09,450
+fundamental in a software project. Or as I say here,
+
+4
+00:00:09,450 --> 00:00:13,050
+a great architecture is a ticket to a successful project. To
+
+5
+00:00:13,050 --> 00:00:15,290
+put it in a different way, although a great architecture
+
+6
+00:00:15,290 --> 00:00:17,940
+does not guarantee that your project will be successful, having a
+
+7
+00:00:17,940 --> 00:00:21,930
+poor architecture will make it much more difficult for your project
+
+8
+00:00:21,930 --> 00:00:25,280
+to be successful. The second message is that an architecture cannot
+
+9
+00:00:25,280 --> 00:00:28,120
+come about in a vacuum. You need to understand
+
+10
+00:00:28,120 --> 00:00:30,550
+the domain of the problem that you're trying to solve
+
+11
+00:00:30,550 --> 00:00:33,480
+in order to define an architectural solution that fits the
+
+12
+00:00:33,480 --> 00:00:37,220
+characteristics of the problem. So a great architecture reflects a
+
+13
+00:00:37,220 --> 00:00:40,500
+deep understanding of the problem domain. And finally, a great
+
+14
+00:00:40,500 --> 00:00:44,630
+architecture is likely to combine aspects of several simpler architectures.
+
+15
+00:00:44,630 --> 00:00:47,880
+It is typical for engineers to see problems that are
+
+16
+00:00:47,880 --> 00:00:50,590
+new, but such that parts of the problems have already
+
+17
+00:00:50,590 --> 00:00:53,540
+been solved by someone else. An effective engineer should
+
+18
+00:00:53,540 --> 00:00:56,270
+therefore, first of all, know what is out there,
+
+19
+00:00:56,270 --> 00:00:59,760
+know the solution space. Second, an engineer should understand
+
+20
+00:00:59,760 --> 00:01:02,420
+what has worked well and what has failed miserably in
+
+21
+00:01:02,420 --> 00:01:05,870
+similar occasions in the past. And finally, an effective
+
+22
+00:01:05,870 --> 00:01:10,100
+engineer should be able to suitably combine existing solutions appropriately
+
+23
+00:01:10,100 --> 00:01:12,870
+to come up with an effective overall solution for
+
+24
+00:01:12,870 --> 00:01:15,750
+the specific problem at hand. And this is just as
+
+25
+00:01:15,750 --> 00:01:18,960
+true in the context of software architectures. When defining a software
+
+26
+00:01:18,960 --> 00:01:22,330
+architecture, you should innovate only as much as you need to and
+
+27
+00:01:22,330 --> 00:01:24,850
+reuse as much as you can. As we said early in the
+
+28
+00:01:24,850 --> 00:01:27,770
+lesson, by doing so, that is, by innovating only as much as
+
+29
+00:01:27,770 --> 00:01:30,100
+you need to and reusing as much as you can, you will
+
+30
+00:01:30,100 --> 00:01:32,960
+be able to avoid reinventing the wheel. You will be able to
+
+31
+00:01:32,960 --> 00:01:37,320
+choose the right solution to known problems. And identify suitable solutions for
+
+32
+00:01:37,320 --> 00:01:40,925
+new problems. So ultimately, you will be able to realize an effective
+
+33
+00:01:40,925 --> 00:01:44,080
+software architecture that will help the success of your project.
diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/3 - What is Software Architecture? - lang_en_vs6.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/3 - What is Software Architecture? - lang_en_vs6.srt
new file mode 100644
index 0000000..8689e43
--- /dev/null
+++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/3 - What is Software Architecture? - lang_en_vs6.srt	
@@ -0,0 +1,127 @@
+1
+00:00:00,140 --> 00:00:02,460
+After this interesting conversation with Neno, let me start
+
+2
+00:00:02,460 --> 00:00:06,060
+the lesson by defining what a software architecture is.
+
+3
+00:00:06,060 --> 00:00:07,600
+And to do that, I'm going to use two
+
+4
+00:00:07,600 --> 00:00:11,030
+seminal definitions. The first one is from Dewayne Perry
+
+5
+00:00:11,030 --> 00:00:13,990
+and Alex Wolf. And they define a software architecture
+
+6
+00:00:13,990 --> 00:00:17,940
+as elements, form and rationale. In this definition, the
+
+7
+00:00:17,940 --> 00:00:21,300
+elements are the what, which means the processes, data,
+
+8
+00:00:21,300 --> 00:00:25,430
+and connectors that compose a software architecture. The form
+
+9
+00:00:25,430 --> 00:00:27,780
+is the how, the set of properties of
+
+10
+00:00:27,780 --> 00:00:32,030
+in relationships among these elements. And, finally, the rationale
+
+11
+00:00:32,030 --> 00:00:35,390
+is the why, the justification for the elements and
+
+12
+00:00:35,390 --> 00:00:38,440
+their relationships. The second definition I want to use
+
+13
+00:00:38,440 --> 00:00:40,710
+is from Mary Shaw and David Garland. And
+
+14
+00:00:40,710 --> 00:00:43,480
+they defined a software architecture as a level of
+
+15
+00:00:43,480 --> 00:00:47,300
+design that involves four main things, a description of
+
+16
+00:00:47,300 --> 00:00:50,860
+elements from which these systems are built, the interactions
+
+17
+00:00:50,860 --> 00:00:54,800
+among those elements, the patterns that guide their composition, and
+
+18
+00:00:54,800 --> 00:00:58,320
+finally, the constraints on these patterns. As you can see, these
+
+19
+00:00:58,320 --> 00:01:01,420
+definitions are fairly similar and there are many more alternative
+
+20
+00:01:01,420 --> 00:01:04,870
+definitions of software architecture. In fact, if we try to search
+
+21
+00:01:04,870 --> 00:01:08,540
+the term software architecture, we get over two million entries.
+
+22
+00:01:08,540 --> 00:01:10,670
+And if we look at the images in the results of
+
+23
+00:01:10,670 --> 00:01:13,110
+the search this is what we get. And I like this
+
+24
+00:01:13,110 --> 00:01:16,120
+sort of graphical depiction because it gives you a clear idea
+
+25
+00:01:16,120 --> 00:01:19,300
+the software architecture are prevalent concept, given the number of
+
+26
+00:01:19,300 --> 00:01:22,600
+results. But they also show you clearly, that software architecture are
+
+27
+00:01:22,600 --> 00:01:25,550
+complex entities, if you look at some of these pictures.
+
+28
+00:01:25,550 --> 00:01:28,930
+And ultimately, they show that software architecture are presented in all
+
+29
+00:01:28,930 --> 00:01:31,700
+kinds of ways including in 3D, if you look at this
+
+30
+00:01:31,700 --> 00:01:34,970
+picture. We cannot clearly cover all of these definitions in one
+
+31
+00:01:34,970 --> 00:01:37,340
+lesson. So what I will do instead, is to introduce
+
+32
+00:01:37,340 --> 00:01:40,750
+a very general definition that encompasses most of the existing ones.
diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/4 - General Definition of SWA - lang_en_vs6.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/4 - General Definition of SWA - lang_en_vs6.srt
new file mode 100644
index 0000000..13042a7
--- /dev/null
+++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/4 - General Definition of SWA - lang_en_vs6.srt	
@@ -0,0 +1,131 @@
+1
+00:00:00,110 --> 00:00:03,240
+I'm going to define a software systems architecture as
+
+2
+00:00:03,240 --> 00:00:07,660
+the set of principal design decisions about the system. Where
+
+3
+00:00:07,660 --> 00:00:10,950
+principal here, implies a degree of importance, that grants
+
+4
+00:00:10,950 --> 00:00:14,810
+a design decision architectural status. And the point here, as
+
+5
+00:00:14,810 --> 00:00:17,060
+we discussed with Neno early on, is that when
+
+6
+00:00:17,060 --> 00:00:20,210
+building a system, we make tons of design decisions, and
+
+7
+00:00:20,210 --> 00:00:22,470
+most of them do not affect the architecture of
+
+8
+00:00:22,470 --> 00:00:25,270
+the system. For example, the effect of choosing a for
+
+9
+00:00:25,270 --> 00:00:27,640
+loop, instead of a while loop, in the code, or the
+
+10
+00:00:27,640 --> 00:00:30,140
+fact of deciding that we are going to use data structure A
+
+11
+00:00:30,140 --> 00:00:33,620
+instead of data structure B. Some decisions however, do affect the
+
+12
+00:00:33,620 --> 00:00:37,470
+architecture of the system. And in some cases the distinction between these
+
+13
+00:00:37,470 --> 00:00:40,600
+two kinds of design decisions is clear. In some other cases
+
+14
+00:00:40,600 --> 00:00:43,340
+it is much fuzzier and it depends on the context. The
+
+15
+00:00:43,340 --> 00:00:46,000
+bottom line here, is that if you believe that something is
+
+16
+00:00:46,000 --> 00:00:50,380
+an important design decision, that becomes an architectural decision. That is a
+
+17
+00:00:50,380 --> 00:00:53,960
+decision that impacts a system's architecture. In this spirit,
+
+18
+00:00:53,960 --> 00:00:56,650
+we can see a software architecture as the blueprint
+
+19
+00:00:56,650 --> 00:00:58,390
+for a software system, that we can use to
+
+20
+00:00:58,390 --> 00:01:01,320
+construct and evolve the system. And the key point
+
+21
+00:01:01,320 --> 00:01:05,300
+about software architecture is that this blueprint encompasses every
+
+22
+00:01:05,300 --> 00:01:08,600
+facet of the system under development. It encompasses its
+
+23
+00:01:08,600 --> 00:01:11,540
+structure, of course, but not only. It also involves
+
+24
+00:01:11,540 --> 00:01:15,420
+the behavior of the system, the interactions within the system,
+
+25
+00:01:15,420 --> 00:01:18,880
+and the non-functional properties of the system. And we will see
+
+26
+00:01:18,880 --> 00:01:21,960
+how this happens in the rest of the lesson. Another important
+
+27
+00:01:21,960 --> 00:01:25,590
+point about software architecture is that there is a temporal aspect
+
+28
+00:01:25,590 --> 00:01:27,570
+to it. And the point here is that you don't build the
+
+29
+00:01:27,570 --> 00:01:30,660
+software architecture in a single shot, but you do it iteratively,
+
+30
+00:01:30,660 --> 00:01:34,100
+over time. So, basically, you go from having no architecture to
+
+31
+00:01:34,100 --> 00:01:37,330
+your final architecture. So, at any point in time, there is
+
+32
+00:01:37,330 --> 00:01:40,550
+a software architecture, but it will change over time. And this happens
+
+33
+00:01:40,550 --> 00:01:44,780
+because design decisions are made, unmade and changed over a system's lifetime.
diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/5 - Prescriptive vs Descriptive Architecture - lang_en_vs5.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/5 - Prescriptive vs Descriptive Architecture - lang_en_vs5.srt
new file mode 100644
index 0000000..11ecd46
--- /dev/null
+++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/5 - Prescriptive vs Descriptive Architecture - lang_en_vs5.srt	
@@ -0,0 +1,51 @@
+1
+00:00:00,120 --> 00:00:02,200
+We can look at the software architecture from two
+
+2
+00:00:02,200 --> 00:00:07,120
+main standpoints. There are prescriptive and descriptive software architectures.
+
+3
+00:00:07,120 --> 00:00:09,900
+So what does that mean? A prescriptive architecture captures
+
+4
+00:00:09,900 --> 00:00:12,620
+the design decisions that are made prior to the
+
+5
+00:00:12,620 --> 00:00:15,398
+system's construction. This is what we normally call the
+
+6
+00:00:15,398 --> 00:00:18,280
+as-conceived software architecture. Conversely,
+
+7
+00:00:18,280 --> 00:00:20,550
+a descriptive architecture describes how
+
+8
+00:00:20,550 --> 00:00:23,010
+the system has actually been built. So it's based
+
+9
+00:00:23,010 --> 00:00:25,860
+on observing the system as it is and extracting
+
+10
+00:00:25,860 --> 00:00:28,200
+the architecture from the observation. This is what we call
+
+11
+00:00:28,200 --> 00:00:31,890
+the as-implemented software architecture. And one key point here is
+
+12
+00:00:31,890 --> 00:00:35,780
+that often, these two architectures, the prescriptive and the descriptive
+
+13
+00:00:35,780 --> 00:00:39,290
+architectures end up being different. So let's see why that happens.
diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/6 - Architectural Evolution - lang_en_vs5.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/6 - Architectural Evolution - lang_en_vs5.srt
new file mode 100644
index 0000000..edcf77e
--- /dev/null
+++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/6 - Architectural Evolution - lang_en_vs5.srt	
@@ -0,0 +1,115 @@
+1
+00:00:00,090 --> 00:00:02,810
+To do that let's look at how architectural evolution
+
+2
+00:00:02,810 --> 00:00:06,880
+occurs in practice. Ideally when a system evolves, its prescriptive
+
+3
+00:00:06,880 --> 00:00:09,340
+architecture should be modified first. Just like when you
+
+4
+00:00:09,340 --> 00:00:12,170
+modify a building. You change the blueprint and then you
+
+5
+00:00:12,170 --> 00:00:13,940
+change the actual building. You don't go the other
+
+6
+00:00:13,940 --> 00:00:17,820
+way around. In software, unfortunately this rarely ever happens in
+
+7
+00:00:17,820 --> 00:00:21,706
+practice. In practice the system, and therefore it's descriptive
+
+8
+00:00:21,706 --> 00:00:25,150
+architecture are often directly modified. Like in this case that
+
+9
+00:00:25,150 --> 00:00:27,870
+I'm showing here. So what happens is that the architecture
+
+10
+00:00:27,870 --> 00:00:32,259
+as conceived does not change. Whereas the architecture as implemented, does
+
+11
+00:00:32,259 --> 00:00:35,600
+change. And therefore these two things start diverging. And this really
+
+12
+00:00:35,600 --> 00:00:38,720
+happens for a number of reasons. So I'm just going to list
+
+13
+00:00:38,720 --> 00:00:41,740
+a few of those reasons here. In some cases it
+
+14
+00:00:41,740 --> 00:00:45,620
+just happens for plain sloppiness. I need to make this modification
+
+15
+00:00:45,620 --> 00:00:47,290
+and I don't really want to go back and look at
+
+16
+00:00:47,290 --> 00:00:50,610
+the prescriptive architecture modified. I'm just going to make the change, and
+
+17
+00:00:50,610 --> 00:00:53,800
+maybe I'll fix the description later. And then you never really get
+
+18
+00:00:53,800 --> 00:00:56,950
+to it. In other cases you do this because of the perception
+
+19
+00:00:56,950 --> 00:01:00,290
+of short deadlines. If you have to do something by this afternoon,
+
+20
+00:01:00,290 --> 00:01:01,300
+you're not going through a four
+
+21
+00:01:01,300 --> 00:01:03,410
+month software architecture review, you normally just
+
+22
+00:01:03,410 --> 00:01:06,460
+get to it, and do it. In some cases a prescriptive architecture
+
+23
+00:01:06,460 --> 00:01:09,510
+is not even present, so there's a lack of documentation. So in these
+
+24
+00:01:09,510 --> 00:01:12,450
+cases, clearly, you cannot go and modify something that does not even
+
+25
+00:01:12,450 --> 00:01:15,880
+exist, and so you jump directly to the code and start modifying that.
+
+26
+00:01:15,880 --> 00:01:18,280
+And as I said there's many, many more
+
+27
+00:01:18,280 --> 00:01:21,080
+other reasons why that happen. But important point here is
+
+28
+00:01:21,080 --> 00:01:23,770
+that it does happen and it does happen often
+
+29
+00:01:23,770 --> 00:01:27,250
+and the result is that prescriptive and descriptive architectures diverge.
diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/7 - Architectural Degradation - lang_en_vs6.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/7 - Architectural Degradation - lang_en_vs6.srt
new file mode 100644
index 0000000..2313f82
--- /dev/null
+++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/7 - Architectural Degradation - lang_en_vs6.srt	
@@ -0,0 +1,131 @@
+1
+00:00:00,150 --> 00:00:02,790
+And there are two important and related concepts that
+
+2
+00:00:02,790 --> 00:00:04,790
+have to do with the way software architecture
+
+3
+00:00:04,790 --> 00:00:08,109
+evolves. The first one is Architectural Drift, which is
+
+4
+00:00:08,109 --> 00:00:12,140
+the introduction of architectural design decisions that are orthogonal to
+
+5
+00:00:12,140 --> 00:00:15,870
+a system's prescriptive architecture. That is, they're not included
+
+6
+00:00:15,870 --> 00:00:20,080
+in, encompassed by, or implied by the prescriptive architecture.
+
+7
+00:00:20,080 --> 00:00:22,300
+And the result of Architectural Drift is that you
+
+8
+00:00:22,300 --> 00:00:25,220
+start from a clean architecture, like the one that I'm
+
+9
+00:00:25,220 --> 00:00:28,830
+showing here, and then you start adding pieces without following a clear plan.
+
+10
+00:00:28,830 --> 00:00:32,229
+Like, for example, here, we add an additional room here, but we don't really
+
+11
+00:00:32,229 --> 00:00:34,380
+do it in the right way so we need to add something else
+
+12
+00:00:34,380 --> 00:00:37,090
+to keep it stable. And then maybe we want some more room so we
+
+13
+00:00:37,090 --> 00:00:40,310
+add a tent. And then another side of the house, it doesn't really
+
+14
+00:00:40,310 --> 00:00:43,540
+follow the same architecture but it doesn't matter, we just put it there because
+
+15
+00:00:43,540 --> 00:00:46,690
+we want to expand. And maybe then we want to put something classic
+
+16
+00:00:46,690 --> 00:00:48,210
+there, even though it doesn't really fit
+
+17
+00:00:48,210 --> 00:00:50,520
+the overall design and the overall architecture.
+
+18
+00:00:50,520 --> 00:00:52,160
+So I think you get my point, the fact
+
+19
+00:00:52,160 --> 00:00:56,210
+that the architecture then becomes unnecessarily complex, hard to understand
+
+20
+00:00:56,210 --> 00:00:58,410
+and ultimately awkward, just like the one that I'm
+
+21
+00:00:58,410 --> 00:01:00,880
+showing here, that goes from the original building into this
+
+22
+00:01:00,880 --> 00:01:04,870
+final monstrosity. The second concept is Architectural Erosion, which
+
+23
+00:01:04,870 --> 00:01:08,560
+is the introduction of architectural design decisions that violate a
+
+24
+00:01:08,560 --> 00:01:12,070
+system prescriptive architecture. So in this case, that we were
+
+25
+00:01:12,070 --> 00:01:14,070
+introducing decisions that were orthogonal,
+
+26
+00:01:14,070 --> 00:01:15,580
+here, were introducing this decisions
+
+27
+00:01:15,580 --> 00:01:17,410
+that don't comply with the prescriptive
+
+28
+00:01:17,410 --> 00:01:20,140
+architecture. And the result of Architectural Erosion
+
+29
+00:01:20,140 --> 00:01:22,590
+is typically a poor architecture an
+
+30
+00:01:22,590 --> 00:01:24,550
+architecture that is going to have problems in
+
+31
+00:01:24,550 --> 00:01:27,040
+the future. So both Architectural Drift
+
+32
+00:01:27,040 --> 00:01:29,640
+and Architectural Erosion take you away in
+
+33
+00:01:29,640 --> 00:01:32,940
+different ways from what you think your software architecture is or should be.
diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/8 - Architectural Recovery - lang_en_vs4.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/8 - Architectural Recovery - lang_en_vs4.srt
new file mode 100644
index 0000000..6104ae0
--- /dev/null
+++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/8 - Architectural Recovery - lang_en_vs4.srt	
@@ -0,0 +1,67 @@
+1
+00:00:00,180 --> 00:00:03,560
+And sometimes, architectural drift and erosion gets you so
+
+2
+00:00:03,560 --> 00:00:06,450
+far away from the point where your software architecture should
+
+3
+00:00:06,450 --> 00:00:10,476
+be, that your architecture is completely degraded. And at this
+
+4
+00:00:10,476 --> 00:00:13,290
+point, you have two main options. The first option is
+
+5
+00:00:13,290 --> 00:00:17,140
+to keep frantically tweaking the code. And this normally leads
+
+6
+00:00:17,140 --> 00:00:20,370
+to disaster. Why? Because you only make things worse. You
+
+7
+00:00:20,370 --> 00:00:22,570
+don't know exactly what you are changing and therefore, you're
+
+8
+00:00:22,570 --> 00:00:25,570
+basically stabbing in the dark, trying to fix your system.
+
+9
+00:00:25,570 --> 00:00:27,580
+The other possiblity is that you can try to
+
+10
+00:00:27,580 --> 00:00:29,830
+determine the software system architecture
+
+11
+00:00:29,830 --> 00:00:31,710
+from its implementation level artifacts,
+
+12
+00:00:31,710 --> 00:00:34,520
+so you try to derive what the architecture is
+
+13
+00:00:34,520 --> 00:00:36,610
+and try to fix it, once you have derived the
+
+14
+00:00:36,610 --> 00:00:39,266
+architecture. And this is what is normally called, architectural
+
+15
+00:00:39,266 --> 00:00:44,210
+recovery, determining a software architecture from an implementation and fixing
+
+16
+00:00:44,210 --> 00:00:46,410
+it. And as you can imagine, this is normally
+
+17
+00:00:46,410 --> 00:00:49,330
+a more recommended way to go than the first solution.
diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/9 - Architectural Recovery Quiz - lang_en_vs4.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/9 - Architectural Recovery Quiz - lang_en_vs4.srt
new file mode 100644
index 0000000..0750374
--- /dev/null
+++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/9 - Architectural Recovery Quiz - lang_en_vs4.srt	
@@ -0,0 +1,35 @@
+1
+00:00:00,120 --> 00:00:03,070
+Now that we discussed some important concepts about
+
+2
+00:00:03,070 --> 00:00:05,060
+software architectures, I would like for you to
+
+3
+00:00:05,060 --> 00:00:07,290
+tell me which of the following sentences is
+
+4
+00:00:07,290 --> 00:00:11,420
+true. Prescriptive architecture and descriptive architecture are typically the
+
+5
+00:00:11,420 --> 00:00:15,970
+same. Architectural drift results in unnecessarily complex architectures.
+
+6
+00:00:15,970 --> 00:00:20,320
+Architectural erosion is less problematic than architectural drift. And
+
+7
+00:00:20,320 --> 00:00:22,660
+the best way to improve a degraded architecture,
+
+8
+00:00:22,660 --> 00:00:25,250
+is to keep fixing the code until the system
+
+9
+00:00:25,250 --> 00:00:29,270
+starts looking and behaving as expected. Which of these sentences is true?
diff --git a/usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/1 - Introduction - lang_en.srt b/usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/1 - Introduction - lang_en.srt
new file mode 100644
index 0000000..f6386ed
--- /dev/null
+++ b/usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/1 - Introduction - lang_en.srt	
@@ -0,0 +1,88 @@
+1
+00:00:00,430 --> 00:00:05,994
+Hello and welcome to a tale of analysis and design, featuring
+
+2
+00:00:05,994 --> 00:00:10,809
+Spencer Rugaber, as the librarian, and Alex Orso,
+
+3
+00:00:10,809 --> 00:00:15,779
+as the software engineer. [SOUND]
+
+4
+00:00:15,779 --> 00:00:21,520
+>> Hi! I'm here waiting for Spencer, my librarian friend. He needs some
+
+5
+00:00:21,520 --> 00:00:25,470
+help developing an information system for a library. So I asked him to write
+
+6
+00:00:25,470 --> 00:00:29,669
+down the requirements for the libra... Oh, [SOUND] that must be him.
+
+7
+00:00:29,669 --> 00:00:30,850
+>> Hello Alex.
+
+8
+00:00:30,850 --> 00:00:32,470
+>> Hey Spencer. How's it going?
+
+9
+00:00:32,470 --> 00:00:34,690
+>> Good. Did you get those requirements I emailed you?
+
+10
+00:00:34,690 --> 00:00:36,890
+>> Oh, you emailed them. Now let me check.
+
+11
+00:00:36,890 --> 00:00:38,780
+And, by the way, get some coffee for you here.
+
+12
+00:00:38,780 --> 00:00:39,880
+>> Thank you very much.
+
+13
+00:00:41,840 --> 00:00:46,790
+>> Oh yeah. They're right here. Let me see. Oh, good. Oh, yeah,
+
+14
+00:00:46,790 --> 00:00:50,580
+good. We have, what we need. So the, the way I like to do
+
+15
+00:00:50,580 --> 00:00:52,500
+this is. I like to start by
+
+16
+00:00:52,500 --> 00:00:55,430
+looking at the requirements and identifying the nouns
+
+17
+00:00:55,430 --> 00:00:57,530
+in the requirements, because those tell us
+
+18
+00:00:57,530 --> 00:01:00,080
+the kind of the relevant elements in the,
+
+19
+00:01:00,080 --> 00:01:03,360
+in the requirements. So if you don't mind we can start looking at those and
+
+20
+00:01:03,360 --> 00:01:07,070
+you can tell me you know, whether the ones that I am identifying make sense or not.
+
+21
+00:01:07,070 --> 00:01:07,920
+>> Sounds good.
+
+22
+00:01:07,920 --> 00:01:08,500
+>> All right.
+
diff --git a/usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/10 - Debriefing - lang_en.srt b/usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/10 - Debriefing - lang_en.srt
new file mode 100644
index 0000000..cc76d09
--- /dev/null
+++ b/usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/10 - Debriefing - lang_en.srt	
@@ -0,0 +1,104 @@
+1
+00:00:00,210 --> 00:00:02,200
+>> So Spencer, now that we went through
+
+2
+00:00:02,200 --> 00:00:05,340
+this process and, I'd just like to hear
+
+3
+00:00:05,340 --> 00:00:07,090
+whether you enjoyed it, whether you think it
+
+4
+00:00:07,090 --> 00:00:09,640
+was useful. What are your thoughts?
+
+5
+00:00:09,640 --> 00:00:11,661
+>> Well, ti was very interesting. I not only
+
+6
+00:00:11,661 --> 00:00:16,541
+learned something about computers and about how you design information systems
+
+7
+00:00:16,541 --> 00:00:19,713
+in UML, but I, it was interesting. I also learned something
+
+8
+00:00:19,713 --> 00:00:25,290
+interesting about the library. And things that, that I knew but
+
+9
+00:00:25,290 --> 00:00:27,920
+I never really, explicitly written down.
+
+10
+00:00:27,920 --> 00:00:28,099
+>> Uh-huh.
+
+11
+00:00:28,099 --> 00:00:32,280
+>> Came up during the course of doing this. And I think I now
+
+12
+00:00:32,280 --> 00:00:35,800
+much better understand what this information system that you're
+
+13
+00:00:35,800 --> 00:00:38,590
+going to build for us, is really all about.
+
+14
+00:00:38,590 --> 00:00:40,480
+>> Okay, well, I mean, I'm very happy that you say
+
+15
+00:00:40,480 --> 00:00:43,040
+that, because I really believe that, you know, doing this kind
+
+16
+00:00:43,040 --> 00:00:46,870
+of analysis and design exercises really helps you figuring out whether
+
+17
+00:00:46,870 --> 00:00:50,480
+there's any issues with the requirements. So for example, you can find
+
+18
+00:00:50,480 --> 00:00:53,580
+out whether there's any missing information, or maybe conflicting
+
+19
+00:00:53,580 --> 00:00:56,820
+information. And I think that's exactly what happened today.
+
+20
+00:00:56,820 --> 00:01:01,120
+So I'm very glad to hear that it worked for you. That you enjoyed it. I hope you
+
+21
+00:01:01,120 --> 00:01:03,690
+enjoyed it as well. And I strongly encourage you
+
+22
+00:01:03,690 --> 00:01:06,000
+to do this kind of exercises for different kinds
+
+23
+00:01:06,000 --> 00:01:08,630
+of systems. So as you can become more familiar
+
+24
+00:01:08,630 --> 00:01:12,410
+with analysis and design techniques. So, any final thoughts?
+
+25
+00:01:12,410 --> 00:01:15,440
+>> I look forward to receiving your delivered software.
+
+26
+00:01:15,440 --> 00:01:16,440
+>> All right. Will do.
+
diff --git a/usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/2 - Analyzing Requirements - lang_en.srt b/usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/2 - Analyzing Requirements - lang_en.srt
new file mode 100644
index 0000000..909fb2d
--- /dev/null
+++ b/usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/2 - Analyzing Requirements - lang_en.srt	
@@ -0,0 +1,579 @@
+1
+00:00:00,220 --> 00:00:04,900
+Okay so let me start underlining these nouns, and I'll start
+
+2
+00:00:04,900 --> 00:00:07,810
+identifying the ones that are relevant, and I'll ask you some
+
+3
+00:00:07,810 --> 00:00:10,550
+questions or you can ask me questions if
+
+4
+00:00:10,550 --> 00:00:14,666
+you see something that doesn't make sense to you. Good enough.
+
+5
+00:00:14,666 --> 00:00:17,650
+>> okay, let's see, patron. It seems to
+
+6
+00:00:17,650 --> 00:00:19,670
+me that patron is definitely an important entity.
+
+7
+00:00:19,670 --> 00:00:20,808
+>> That's, that's what its all about.
+
+8
+00:00:20,808 --> 00:00:23,270
+>> Okay, all right, so actually, the way
+
+9
+00:00:23,270 --> 00:00:25,750
+I'm going to do this, I'm going to take all these relevant
+
+10
+00:00:25,750 --> 00:00:28,610
+entities and I'm going to start putting them into what I call a class
+
+11
+00:00:28,610 --> 00:00:32,450
+diagram. So you don't really need to know what that is exactly, but imagine
+
+12
+00:00:32,450 --> 00:00:37,150
+this being a, a diagram in which I'm drawing, I represent in all development
+
+13
+00:00:37,150 --> 00:00:42,260
+items as rectangles with a given name and, and then later on some attributes.
+
+14
+00:00:42,260 --> 00:00:42,660
+>> Okay.
+
+15
+00:00:42,660 --> 00:00:44,055
+>> Okay, and I'm, I'm just going to put
+
+16
+00:00:44,055 --> 00:00:45,600
+them there. So I'm going to start with patron.
+
+17
+00:00:45,600 --> 00:00:48,420
+I'm going to create one class for the
+
+18
+00:00:48,420 --> 00:00:50,250
+patron. I'm going to give it the name patron.
+
+19
+00:00:51,380 --> 00:00:54,120
+And by the way, assuming that you'd probably figure out, it's important that we
+
+20
+00:00:54,120 --> 00:00:57,430
+represent, we use the right names so that it's clear when we're looking at
+
+21
+00:00:57,430 --> 00:01:00,790
+the class diagram what we're referring to, so I'll just use the, the nouns
+
+22
+00:01:00,790 --> 00:01:06,520
+themselves as names. Okay, library card seems to be also a relevant element.
+
+23
+00:01:06,520 --> 00:01:08,072
+>> Every patron has a library card.
+
+24
+00:01:08,072 --> 00:01:09,530
+>> All right, perfect, so we'll just
+
+25
+00:01:09,530 --> 00:01:12,880
+create a library card here. And let's see.
+
+26
+00:01:12,880 --> 00:01:16,530
+As, as long as they're in the system. And I saw that there's a system
+
+27
+00:01:16,530 --> 00:01:19,000
+here, this concept of system, this concept
+
+28
+00:01:19,000 --> 00:01:22,076
+of library. And based on my experience, normally,
+
+29
+00:01:22,076 --> 00:01:26,574
+those are kind of in an overarching themes. So this is really what we are
+
+30
+00:01:26,574 --> 00:01:28,597
+modeling. So the only
+
+31
+00:01:28,597 --> 00:01:30,297
+thing that will make a difference is
+
+32
+00:01:30,297 --> 00:01:34,120
+if there were more than one library or more than one system. Is that the case?
+
+33
+00:01:34,120 --> 00:01:36,740
+>> We just want one system for our one library
+
+34
+00:01:36,740 --> 00:01:38,770
+>> Okay so, in this case I won't even represent
+
+35
+00:01:38,770 --> 00:01:41,540
+those because basically what I'm representing is the system and
+
+36
+00:01:41,540 --> 00:01:41,990
+the library.
+
+37
+00:01:41,990 --> 00:01:42,740
+>> I understand, I understand.
+
+38
+00:01:42,740 --> 00:01:44,420
+
+39
+00:01:44,420 --> 00:01:48,350
+Okay and then, oh name, address and phone
+
+40
+00:01:48,350 --> 00:01:51,510
+number are interesting because these are important entities,
+
+41
+00:01:51,510 --> 00:01:53,180
+but this seems like, you know, they're not
+
+42
+00:01:53,180 --> 00:01:56,550
+entities in themselves, so they're more attributes
+
+43
+00:01:56,550 --> 00:01:58,070
+of something else. I would imagine that
+
+44
+00:01:58,070 --> 00:02:00,080
+this is the way you identify, or these
+
+45
+00:02:00,080 --> 00:02:01,860
+are elements that are important for the patron?
+
+46
+00:02:01,860 --> 00:02:04,880
+>> That's what we take down when we issue the cards.
+
+47
+00:02:04,880 --> 00:02:06,800
+>> Okay. Perfect. So, I'm going to
+
+48
+00:02:06,800 --> 00:02:09,710
+take those and make those attributes of the patron, which means
+
+49
+00:02:09,710 --> 00:02:12,350
+that I'm going to take the class that I created before, and I'm
+
+50
+00:02:12,350 --> 00:02:16,430
+just going to write them down here so that they're represented and,
+
+51
+00:02:16,430 --> 00:02:19,360
+and we know that these are kind of what characterizes the patron.
+
+52
+00:02:19,360 --> 00:02:20,070
+>> Gotcha.
+
+53
+00:02:20,070 --> 00:02:25,540
+>> Okay? And then, I guess similar consideration for the library
+
+54
+00:02:25,540 --> 00:02:28,750
+card number. So this is to be associated with the library card?
+
+55
+00:02:28,750 --> 00:02:29,902
+>> It's printed right on it.
+
+56
+00:02:29,902 --> 00:02:32,180
+>> All right, so we'll put this as
+
+57
+00:02:32,180 --> 00:02:38,130
+an attribute of the library card, then. And then, in addition, at any particular point
+
+58
+00:02:38,130 --> 00:02:43,630
+in time. Okay, so time seems to be a relevant entity right,
+
+59
+00:02:43,630 --> 00:02:47,880
+because time seems to occur several times in this description. For example, I
+
+60
+00:02:47,880 --> 00:02:53,940
+think you guys keep track of how long a book has been loaned, right?
+
+61
+00:02:53,940 --> 00:02:54,300
+>> Right.
+
+62
+00:02:54,300 --> 00:02:57,270
+>> And there's some time associated also here.
+
+63
+00:02:57,270 --> 00:02:58,380
+>> And a children's age.
+
+64
+00:02:58,380 --> 00:02:59,760
+>> Oh yeah. The children's age here that
+
+65
+00:02:59,760 --> 00:03:02,200
+I didn't see before. Yeah. So, what
+
+66
+00:03:02,200 --> 00:03:03,800
+I'm going to do, I'm going to represent this in
+
+67
+00:03:03,800 --> 00:03:05,520
+a sort of generic way, as a date.
+
+68
+00:03:05,520 --> 00:03:06,520
+>> Okay.
+
+69
+00:03:06,520 --> 00:03:08,380
+>> These are kind of, kind of classes, utility
+
+70
+00:03:08,380 --> 00:03:10,880
+classes we call them, that are normally in every system.
+
+71
+00:03:10,880 --> 00:03:10,970
+>> Okay.
+
+72
+00:03:10,970 --> 00:03:13,060
+>> So I'm just going to put it down here
+
+73
+00:03:13,060 --> 00:03:14,940
+as a utility class that will be used
+
+74
+00:03:14,940 --> 00:03:18,780
+by different elements in the diagram. Okay, so
+
+75
+00:03:18,780 --> 00:03:23,070
+I want to calculate the items. So the items also
+
+76
+00:03:23,070 --> 00:03:25,230
+I mean I for what I know about libraries they
+
+77
+00:03:25,230 --> 00:03:28,490
+seem to be pretty relevant elements, right? So these are all
+
+78
+00:03:28,490 --> 00:03:31,305
+>> This is what we check out, this is what we're for.
+
+79
+00:03:31,305 --> 00:03:34,459
+>> Okay, so then items definitely will become a
+
+80
+00:03:34,459 --> 00:03:37,349
+class, and then we have a due. Oh there's also
+
+81
+00:03:37,349 --> 00:03:39,730
+this concept of fines. I guess that seems to be
+
+82
+00:03:39,730 --> 00:03:42,330
+important. Right? You guys give fines to people who are late.
+
+83
+00:03:42,330 --> 00:03:42,700
+>> Right, right.
+
+84
+00:03:42,700 --> 00:03:49,160
+>> Right, collect fines and so on. So we create a fine class down here and
+
+85
+00:03:49,160 --> 00:03:54,150
+the children. So children are special customers, right? It's
+
+86
+00:03:55,240 --> 00:03:56,890
+their age makes a difference? Is that the way it works?
+
+87
+00:03:56,890 --> 00:03:58,950
+>> Right. They, they can only check out a few books.
+
+88
+00:03:58,950 --> 00:04:01,410
+>> Okay. So I'll create them a special
+
+89
+00:04:01,410 --> 00:04:03,170
+kind of case, a special kind of customer so
+
+90
+00:04:03,170 --> 00:04:06,000
+I just create here a class for children. And
+
+91
+00:04:06,000 --> 00:04:08,682
+I can see that they're categorized by their age.
+
+92
+00:04:08,682 --> 00:04:09,340
+>> Right.
+
+93
+00:04:09,340 --> 00:04:13,160
+>> So I'll just put the age here as an attribute of the child.
+
+94
+00:04:14,220 --> 00:04:15,712
+And, okay, so the next one is
+
+95
+00:04:15,712 --> 00:04:19,653
+restriction. And restriction is kind of tricky because just
+
+96
+00:04:19,653 --> 00:04:22,010
+to be sort of a general concept. I mean,
+
+97
+00:04:22,010 --> 00:04:24,915
+in a sense, all of those are restrictions, right?
+
+98
+00:04:24,915 --> 00:04:28,250
+>> Right, this is just another one of these requirements.
+
+99
+00:04:28,250 --> 00:04:31,180
+>> Oh, okay, so, so we don't need to represent it explicitly, right?
+
+100
+00:04:31,180 --> 00:04:31,430
+>> Right, right.
+
+101
+00:04:31,430 --> 00:04:34,390
+>> It's just telling us how the children, yeah, okay, right; this is
+
+102
+00:04:34,390 --> 00:04:39,151
+just another requirement, so I just won't consider that for now. And oh,
+
+103
+00:04:39,151 --> 00:04:43,444
+I see that these books and audio video materials, I guess these
+
+104
+00:04:43,444 --> 00:04:48,902
+are things that the patrons can check out, right?
+
+105
+00:04:48,902 --> 00:04:50,725
+>> Those are some of the items, right.
+
+106
+00:04:50,725 --> 00:04:53,770
+>> There are two
+
+107
+00:04:53,770 --> 00:04:56,380
+more down here, right? Reference books and magazines?
+
+108
+00:04:56,380 --> 00:04:57,990
+>> But, they can't be checked
+
+109
+00:04:57,990 --> 00:04:59,270
+out, but they're definitely in the library.
+
+110
+00:04:59,270 --> 00:05:01,338
+>> Okay, so then I'm going to represent all of those
+
+111
+00:05:01,338 --> 00:05:04,180
+actually, now. So, I'm going to have books, I'm going to have audio
+
+112
+00:05:04,180 --> 00:05:07,990
+video materials, reference books, and magazines. And
+
+113
+00:05:07,990 --> 00:05:12,150
+I'm just going to have those as classes. Then,
+
+114
+00:05:12,150 --> 00:05:14,060
+okay here we have week, and we
+
+115
+00:05:14,060 --> 00:05:16,630
+already represented this general concept of time, so
+
+116
+00:05:16,630 --> 00:05:23,270
+week will be represented by the date class as well. And oh, I see best sellers.
+
+117
+00:05:23,270 --> 00:05:27,520
+So best sellers are also, I guess, items that can be checked out, right?
+
+118
+00:05:27,520 --> 00:05:28,150
+>> Right.
+
+119
+00:05:28,150 --> 00:05:29,330
+>> Okay, so I'll
+
+120
+00:05:29,330 --> 00:05:32,900
+just represent those as a class as well and an additional item that
+
+121
+00:05:32,900 --> 00:05:38,480
+is relevant for the library. And the limit, this is also a time limit, right?
+
+122
+00:05:38,480 --> 00:05:39,150
+>> Right.
+
+123
+00:05:39,150 --> 00:05:41,500
+>> So it can also be represented with a, with a class.
+
+124
+00:05:43,860 --> 00:05:47,380
+Oh, here we have cents, and for cents, same consideration that made
+
+125
+00:05:47,380 --> 00:05:50,430
+for time. This is kind of the money, is a general concept
+
+126
+00:05:50,430 --> 00:05:54,240
+that in all currency, many, in many IT systems. So, I'm, I'm
+
+127
+00:05:54,240 --> 00:05:57,430
+going to just have a money class here, which is another utility class.
+
+128
+00:05:57,430 --> 00:05:57,740
+>> Okay
+
+129
+00:05:57,740 --> 00:06:04,000
+>> Okay, and, oh, here I have value, so value is a property.
+
+130
+00:06:04,000 --> 00:06:09,320
+Let me look again at the requirement. Oh, it's the value of the item. So value
+
+131
+00:06:09,320 --> 00:06:11,450
+I'm going to put in the item as an attribute. Okay?
+
+132
+00:06:11,450 --> 00:06:13,120
+>> Okay. That's how much it cost us.
+
+133
+00:06:13,120 --> 00:06:14,090
+>> Okay. Perfect.
+
+134
+00:06:14,090 --> 00:06:18,400
+>> Seems like we got them all. Right? Anything I forgot?
+
+135
+00:06:18,400 --> 00:06:19,640
+>> That looks like it.
+
+136
+00:06:19,640 --> 00:06:22,580
+>> Okay, so this one, what I'd like to do. We have a kind of
+
+137
+00:06:22,580 --> 00:06:26,890
+a first take, first cut at the class diagram. I'd like to kind of
+
+138
+00:06:26,890 --> 00:06:31,480
+move to that and go through the different classes with you. And I'll ask
+
+139
+00:06:31,480 --> 00:06:33,440
+you some questions again. And you can
+
+140
+00:06:33,440 --> 00:06:34,510
+tell me whether there is something that
+
+141
+00:06:34,510 --> 00:06:36,894
+jumps at you that's not right. And
+
+142
+00:06:36,894 --> 00:06:38,930
+then we're going to try to refine that.
+
+143
+00:06:38,930 --> 00:06:39,180
+>> Okay
+
+144
+00:06:39,180 --> 00:06:39,510
+>> Okay.
+
+145
+00:06:39,510 --> 00:06:39,800
+>> Sounds good.
+
diff --git a/usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/3 - Refining Classes and Attributes - lang_en.srt b/usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/3 - Refining Classes and Attributes - lang_en.srt
new file mode 100644
index 0000000..271c2fd
--- /dev/null
+++ b/usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/3 - Refining Classes and Attributes - lang_en.srt	
@@ -0,0 +1,535 @@
+1
+00:00:00,880 --> 00:00:03,920
+Okay, so this is our first, class diagram.
+
+2
+00:00:03,920 --> 00:00:06,260
+>> So, let me ask you something about.
+
+3
+00:00:06,260 --> 00:00:06,520
+>> Okay.
+
+4
+00:00:06,520 --> 00:00:08,930
+>> What we've done so far. I also sent, in what
+
+5
+00:00:08,930 --> 00:00:14,490
+I sent you, I also had some stories about how the actual
+
+6
+00:00:14,490 --> 00:00:16,400
+>> Library is used. You asked me to do
+
+7
+00:00:16,400 --> 00:00:18,950
+that and are we going to take, use that here?
+
+8
+00:00:20,160 --> 00:00:23,300
+>> Glad you asked actually. yeah. Those are, you know, what we call use
+
+9
+00:00:23,300 --> 00:00:25,940
+cases, or what we will use as scenarios kind of things that we will
+
+10
+00:00:25,940 --> 00:00:28,340
+use to derive use cases. And they're also a very good
+
+11
+00:00:28,340 --> 00:00:31,450
+way of extracting requirements. We're not going to look at them right
+
+12
+00:00:31,450 --> 00:00:33,890
+now because now, because we're more working on kind of the static
+
+13
+00:00:33,890 --> 00:00:37,860
+structure of the system. But after we're done with the class diagram,
+
+14
+00:00:37,860 --> 00:00:40,700
+you know, we will do it at a different time. But
+
+15
+00:00:40,700 --> 00:00:43,410
+we're going to use those to see how the
+
+16
+00:00:43,410 --> 00:00:45,850
+libraries actually use them, and see whether we can get more
+
+17
+00:00:45,850 --> 00:00:49,000
+information that we can use to refine our requirements based on that.
+
+18
+00:00:49,000 --> 00:00:49,770
+>> Okay.
+
+19
+00:00:49,770 --> 00:00:51,020
+>> Okay,
+
+20
+00:00:51,020 --> 00:00:52,940
+So, for now, we'll just focus in on the,
+
+21
+00:00:52,940 --> 00:00:54,630
+structure, but, just so you know, I'm,
+
+22
+00:00:54,630 --> 00:00:55,870
+I'm glad you sent them, because they were going
+
+23
+00:00:55,870 --> 00:00:57,380
+very useful as well.
+
+24
+00:00:59,410 --> 00:01:00,840
+Okay. So let's see. Well, first of all, let
+
+25
+00:01:00,840 --> 00:01:03,030
+me, seems like that this is already pretty crowded,
+
+26
+00:01:03,030 --> 00:01:06,770
+right? We have a number of, classes. So let's
+
+27
+00:01:06,770 --> 00:01:10,580
+see if there's, some class that may be superfluous and
+
+28
+00:01:10,580 --> 00:01:13,310
+we can model in a different way. So, for
+
+29
+00:01:13,310 --> 00:01:16,360
+example, you, while, while thinking of this I was thinking,
+
+30
+00:01:16,360 --> 00:01:19,450
+the library card, it doesn't really contain much
+
+31
+00:01:19,450 --> 00:01:22,736
+information, right? So is it basically just the number?
+
+32
+00:01:22,736 --> 00:01:23,948
+
+33
+00:01:23,948 --> 00:01:30,760
+The card has a number on it. We have a separate vendor that does that for us so.
+
+34
+00:01:30,760 --> 00:01:30,810
+>> Oh.
+
+35
+00:01:30,810 --> 00:01:33,270
+>> We don't need, it doesn't need to be part of this system,
+
+36
+00:01:33,270 --> 00:01:35,450
+we just have to make sure that every patron has a library card.
+
+37
+00:01:35,450 --> 00:01:37,670
+>> Okay, so basically for you, in a sense, the library
+
+38
+00:01:37,670 --> 00:01:41,560
+card is just an ID that gets associated with a patron.
+
+39
+00:01:41,560 --> 00:01:42,120
+>> That's right.
+
+40
+00:01:42,120 --> 00:01:45,380
+>> So I think that the best way to represent this, I mean, unless you
+
+41
+00:01:45,380 --> 00:01:47,000
+need an entity because you are creating it
+
+42
+00:01:47,000 --> 00:01:49,160
+yourself, but it seems like you are not.
+
+43
+00:01:49,160 --> 00:01:52,710
+I would just remove this one and I would like to put this,
+
+44
+00:01:52,710 --> 00:01:56,020
+basically to take the library card number and add it to the pattern.
+
+45
+00:01:56,020 --> 00:01:57,100
+>> Okay, makes sense.
+
+46
+00:01:57,100 --> 00:02:03,000
+>> Okay, so I'll add it here. And as
+
+47
+00:02:03,000 --> 00:02:06,160
+an additional attribute. Okay, and it will eliminate this class.
+
+48
+00:02:06,160 --> 00:02:06,410
+>> Okay.
+
+49
+00:02:06,410 --> 00:02:07,580
+>> Okay.
+
+50
+00:02:09,690 --> 00:02:11,700
+Oh, and, wait a second, so I guess
+
+51
+00:02:11,700 --> 00:02:13,940
+also the child needs a library card number, right?
+
+52
+00:02:13,940 --> 00:02:18,320
+>> Child needs a library card number, but let me ask you about that. Is,
+
+53
+00:02:18,320 --> 00:02:22,050
+is child a separate class, or is it just another kind of patron?
+
+54
+00:02:22,050 --> 00:02:24,920
+>> Oh, I see, I see. Because, yeah, it
+
+55
+00:02:24,920 --> 00:02:28,490
+is sort of a special patron, right? And, so
+
+56
+00:02:28,490 --> 00:02:31,730
+maybe we should, maybe we should represent it as
+
+57
+00:02:31,730 --> 00:02:35,640
+a kind of a refinement of the patron.
+
+58
+00:02:35,640 --> 00:02:38,730
+Hm, but then that made me think. So what is
+
+59
+00:02:38,730 --> 00:02:42,510
+the only thing that characterizes children? Is it just the age?
+
+60
+00:02:42,510 --> 00:02:47,440
+>> Well, if they're, that they can't check out more than five books.
+
+61
+00:02:47,440 --> 00:02:48,890
+>> Okay. And the, and the only difference is the
+
+62
+00:02:48,890 --> 00:02:52,010
+fact that they are less than, you know, twelve years old.
+
+63
+00:02:52,010 --> 00:02:52,710
+>> Twelve or less, right.
+
+64
+00:02:52,710 --> 00:02:56,090
+>> Twelve or less. So, I guess, you know, I would probably
+
+65
+00:02:56,090 --> 00:03:01,120
+like to represent this by making the age explicit in the patron rather
+
+66
+00:03:01,120 --> 00:03:04,730
+than to represent it as a class. And I'll tell you why,
+
+67
+00:03:04,730 --> 00:03:08,300
+because one, one of the issues, and you know, that might happen
+
+68
+00:03:08,300 --> 00:03:13,070
+again, is that, basically, there are patrons that are children. And they're
+
+69
+00:03:13,070 --> 00:03:17,130
+no longer children, when they come you know 13 or older right.
+
+70
+00:03:17,130 --> 00:03:18,100
+>> Right.
+
+71
+00:03:18,100 --> 00:03:21,990
+>> And if we represent them with a separate class in a sense, then we
+
+72
+00:03:21,990 --> 00:03:26,620
+cannot really change the type of an instance of these classes.
+
+73
+00:03:26,620 --> 00:03:28,920
+So we're left to kind of destroy the patron, create
+
+74
+00:03:28,920 --> 00:03:31,190
+a new one, so that means we also have to transfer
+
+75
+00:03:31,190 --> 00:03:33,510
+any history we want to keep history and so on.
+
+76
+00:03:33,510 --> 00:03:35,680
+So I, I think I kind of like better the idea
+
+77
+00:03:35,680 --> 00:03:39,560
+that I represent the age exclusively in
+
+78
+00:03:39,560 --> 00:03:42,700
+the patron, and then I'll behave differently, based on whether the
+
+79
+00:03:42,700 --> 00:03:45,910
+patron is 12 years old, or younger, or 13 or,
+
+80
+00:03:45,910 --> 00:03:49,600
+13 or older. This, do you see any problem with that?
+
+81
+00:03:49,600 --> 00:03:51,210
+>> It makes things a little simpler.
+
+82
+00:03:51,210 --> 00:03:51,490
+>> Okay,
+
+83
+00:03:51,490 --> 00:03:53,550
+and we actually, it allows us also to eliminate
+
+84
+00:03:53,550 --> 00:03:56,450
+one class here. So I'm going to proceed this way.
+
+85
+00:03:56,450 --> 00:03:59,450
+I'm going to eliminate the children class, and I'm going to
+
+86
+00:03:59,450 --> 00:04:03,600
+put the age in the patron. Okay, and let me
+
+87
+00:04:03,600 --> 00:04:07,020
+see. But in this spirit, actually, something else that jumps
+
+88
+00:04:07,020 --> 00:04:09,740
+at me is this idea of the bestseller, because I
+
+89
+00:04:09,740 --> 00:04:11,850
+kind of feel like, we might have the same
+
+90
+00:04:11,850 --> 00:04:15,085
+problem. So, what is the story? What is a bestseller.
+
+91
+00:04:15,085 --> 00:04:16,850
+>> Well it's
+
+92
+00:04:16,850 --> 00:04:20,750
+an item that we want to restrict how
+
+93
+00:04:20,750 --> 00:04:23,896
+long people can keep, because there is such demand for it.
+
+94
+00:04:23,896 --> 00:04:26,880
+>> I see, and so basically a book that's a
+
+95
+00:04:26,880 --> 00:04:30,450
+bestseller, like the New York Times bestseller, is a bestseller forever?
+
+96
+00:04:30,450 --> 00:04:32,683
+>> No, no, no it's hot for
+
+97
+00:04:32,683 --> 00:04:35,940
+awhile, and then it becomes just a regular item.
+
+98
+00:04:35,940 --> 00:04:38,318
+>> I see. Hm. Then I guess it's a
+
+99
+00:04:38,318 --> 00:04:40,349
+similar situation to the one I was mentioning before, right?
+
+100
+00:04:40,349 --> 00:04:40,980
+>> Okay.
+
+101
+00:04:40,980 --> 00:04:41,800
+>> That if we have a book,
+
+102
+00:04:41,800 --> 00:04:44,530
+it will kind of have to change its type if it becomes a best seller.
+
+103
+00:04:44,530 --> 00:04:47,218
+Then we have to change its type again, if it's no longer a best seller.
+
+104
+00:04:47,218 --> 00:04:47,790
+>> Right.
+
+105
+00:04:47,790 --> 00:04:48,920
+>> So it seems to me that a better
+
+106
+00:04:48,920 --> 00:04:52,150
+way to represent this, is just to eliminate this BestSeller
+
+107
+00:04:52,150 --> 00:04:55,060
+class and instead, I'm going to put the best seller
+
+108
+00:04:55,060 --> 00:04:58,190
+attribute, which would just be a Boolean in the book.
+
+109
+00:04:58,190 --> 00:05:00,190
+>> Okay, what do you mean by Boolean?
+
+110
+00:05:00,190 --> 00:05:02,280
+>> Right. We don't know what Boolean is, right? The Boolean is
+
+111
+00:05:02,280 --> 00:05:04,940
+basically just a number. It can have two values, right? True or false.
+
+112
+00:05:04,940 --> 00:05:05,380
+>> Okay.
+
+113
+00:05:05,380 --> 00:05:06,830
+>> So we usually, normally use it
+
+114
+00:05:06,830 --> 00:05:09,510
+in this in this case. Imagine one, zero,
+
+115
+00:05:09,510 --> 00:05:10,970
+right? Then it's just kind of the basic.
+
+116
+00:05:10,970 --> 00:05:11,120
+>> Okay.
+
+117
+00:05:11,120 --> 00:05:12,250
+>> You know, the bits, right?
+
+118
+00:05:12,250 --> 00:05:12,590
+>> Okay.
+
+119
+00:05:12,590 --> 00:05:14,730
+>> So, this is just telling us, it's like a flag
+
+120
+00:05:14,730 --> 00:05:16,672
+that is telling this book is a best seller, or not.
+
+121
+00:05:16,672 --> 00:05:17,053
+>> Okay.
+
+122
+00:05:17,053 --> 00:05:20,920
+>> It's very easy to change this value and make a book a best
+
+123
+00:05:20,920 --> 00:05:22,880
+seller or not a best seller, than
+
+124
+00:05:22,880 --> 00:05:26,210
+just creating and destroying instances of these classes.
+
+125
+00:05:26,210 --> 00:05:27,135
+>> Okay, makes sense.
+
+126
+00:05:27,135 --> 00:05:32,630
+>> Okay, so at this point, this already looks better, right? Because we have,
+
+127
+00:05:32,630 --> 00:05:35,590
+less classes, and I think we did, yeah, we
+
+128
+00:05:35,590 --> 00:05:38,775
+did some serious cleanup. That's good. Okay, so now that
+
+129
+00:05:38,775 --> 00:05:40,975
+we eliminated some of this, what I would like to
+
+130
+00:05:40,975 --> 00:05:42,845
+do, as I said, we are going to both clean
+
+131
+00:05:42,845 --> 00:05:45,222
+up, but also refine. I would like to go
+
+132
+00:05:45,222 --> 00:05:48,826
+back to our, requirements and see whether we can identify
+
+133
+00:05:48,826 --> 00:05:52,566
+additional attributes for this, class that maybe are not as
+
+134
+00:05:52,566 --> 00:05:55,120
+obvious as the one that we saw so far, okay?
+
diff --git a/usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/4 - Adding Attributes - lang_en.srt b/usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/4 - Adding Attributes - lang_en.srt
new file mode 100644
index 0000000..0a48aae
--- /dev/null
+++ b/usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/4 - Adding Attributes - lang_en.srt	
@@ -0,0 +1,352 @@
+1
+00:00:00,240 --> 00:00:02,880
+Okay, so let me look at the requirements and
+
+2
+00:00:05,500 --> 00:00:09,150
+it's something that I can see here that we didn't point out before is that
+
+3
+00:00:09,150 --> 00:00:13,540
+there seems to be clearly some concept of a due date. And I'm telling you why
+
+4
+00:00:13,540 --> 00:00:17,610
+I'm saying that because here, for example, I notice that it says when items are
+
+5
+00:00:17,610 --> 00:00:22,580
+due. We mention overdue several times, so is
+
+6
+00:00:22,580 --> 00:00:24,410
+this something we need to keep track of?
+
+7
+00:00:24,410 --> 00:00:27,510
+>> Yeah remember when we used to stamp them on the books? In the stamp pad?
+
+8
+00:00:27,510 --> 00:00:28,240
+>> Oh yeah yeah yeah! Oh course!
+
+9
+00:00:28,240 --> 00:00:30,600
+>> Right? Yeah we definitely keep track of,
+
+10
+00:00:30,600 --> 00:00:32,390
+the system has to keep track of when books are due.
+
+11
+00:00:32,390 --> 00:00:35,300
+>> Okay. So it seems to me that one good way
+
+12
+00:00:35,300 --> 00:00:39,660
+of doing that is by basically adding an attribute to the, item.
+
+13
+00:00:39,660 --> 00:00:40,590
+>> Okay.
+
+14
+00:00:40,590 --> 00:00:41,910
+>> And I'll just call it due date.
+
+15
+00:00:41,910 --> 00:00:42,400
+>> Okay.
+
+16
+00:00:42,400 --> 00:00:45,360
+>> So basically for each item in case it's loaned
+
+17
+00:00:45,360 --> 00:00:48,315
+there will be this attribute that will contain the value of
+
+18
+00:00:48,315 --> 00:00:48,520
+>> Okay.
+
+19
+00:00:48,520 --> 00:00:55,710
+>> Of when, when the item is due. And then, something else that I noticed
+
+20
+00:00:55,710 --> 00:00:58,734
+here is that down here, it seems like
+
+21
+00:00:58,734 --> 00:01:00,900
+the requirements are saying that an item can
+
+22
+00:01:00,900 --> 00:01:04,190
+be renewed only once. So, I guess, that's
+
+23
+00:01:04,190 --> 00:01:05,933
+something we need to keep track of, right?
+
+24
+00:01:05,933 --> 00:01:06,056
+>> Yeah.
+
+25
+00:01:06,056 --> 00:01:06,700
+>> The system needs to know.
+
+26
+00:01:06,700 --> 00:01:08,360
+>> We have to know whether they've renewed it or not.
+
+27
+00:01:08,360 --> 00:01:14,132
+>> Okay so, I'll do a similar thing here. I think I want to go and add a an
+
+28
+00:01:14,132 --> 00:01:19,140
+attribute that we'd call number of times renewed, and add it to the item class.
+
+29
+00:01:19,140 --> 00:01:19,760
+>> Okay.
+
+30
+00:01:19,760 --> 00:01:21,140
+>> And this is kind of more generic
+
+31
+00:01:21,140 --> 00:01:23,180
+than what you need, because here it says only once, but
+
+32
+00:01:23,180 --> 00:01:25,800
+let's say that in the future you want to allow it to,
+
+33
+00:01:25,800 --> 00:01:28,690
+kind of renew twice, you'll be able to use these attributes again
+
+34
+00:01:28,690 --> 00:01:31,090
+because, we can just count how many times it was renewed. Okay?
+
+35
+00:01:31,090 --> 00:01:31,680
+>> Makes sense.
+
+36
+00:01:31,680 --> 00:01:35,980
+>> Alright. And one last thing I want to point out.
+
+37
+00:01:35,980 --> 00:01:38,310
+And this seems obvious but I'm going to check with
+
+38
+00:01:38,310 --> 00:01:43,150
+you anyways. And seems like there is a basically the
+
+39
+00:01:43,150 --> 00:01:46,090
+need to keep track of whether an item is checked
+
+40
+00:01:46,090 --> 00:01:48,210
+out or not. If you look at the text here,
+
+41
+00:01:48,210 --> 00:01:51,080
+the requirements here, I can see that check out and checked out are
+
+42
+00:01:51,080 --> 00:01:55,070
+mentioned five times. So, I'm assuming that that's something also
+
+43
+00:01:55,070 --> 00:01:58,080
+that we want to know about an item, whether it's checked out or not.
+
+44
+00:01:58,080 --> 00:01:59,970
+>> We have to keep track of whether they're checked out.
+
+45
+00:01:59,970 --> 00:02:01,930
+>> Okay, so I'll add an
+
+46
+00:02:01,930 --> 00:02:04,340
+additional attribute there. So I'm going to again go
+
+47
+00:02:04,340 --> 00:02:06,480
+back to the diagram and I'm
+
+48
+00:02:06,480 --> 00:02:10,139
+just going to write here also the checked out attribute.
+
+49
+00:02:12,260 --> 00:02:14,590
+And, I think that's it as far as I'm
+
+50
+00:02:14,590 --> 00:02:16,330
+concerned. Is there anything that you think is missing?
+
+51
+00:02:16,330 --> 00:02:21,077
+>> Well, I do have a question. Would checked out,
+
+52
+00:02:21,077 --> 00:02:27,140
+better not be the case that someone can check out a reference book.
+
+53
+00:02:27,140 --> 00:02:28,400
+>> Oh, I see, I see.
+
+54
+00:02:28,400 --> 00:02:30,120
+>> Okay. I mean, it's only the books and
+
+55
+00:02:30,120 --> 00:02:31,780
+the audio visual material that can be checked out.
+
+56
+00:02:31,780 --> 00:02:37,790
+>> Right, right, right. Okay, so I, I guess, well the way I will fix that is,
+
+57
+00:02:37,790 --> 00:02:42,300
+I'll probably put yet another attribute in the item class, and I'll
+
+58
+00:02:42,300 --> 00:02:45,860
+call it loanable. And basically, this attribute is just telling us whether
+
+59
+00:02:45,860 --> 00:02:49,580
+an item is loanable or not. So, when it's not true and
+
+60
+00:02:49,580 --> 00:02:53,480
+loanable is not on. Basically, that item can be checked out.
+
+61
+00:02:53,480 --> 00:02:55,174
+>> Okay. And, the system would know this.
+
+62
+00:02:55,174 --> 00:02:56,450
+>> The system will know that.
+
+63
+00:02:56,450 --> 00:02:57,160
+>> And prevent it from happening.
+
+64
+00:02:57,160 --> 00:02:58,240
+>> And prevent it from happening. Okay?
+
+65
+00:02:58,240 --> 00:02:58,750
+>> Alright.
+
+66
+00:02:58,750 --> 00:03:02,918
+>> Perfect. So, we're going to do that and, any other objections,
+
+67
+00:03:02,918 --> 00:03:04,035
+any other?
+
+68
+00:03:04,035 --> 00:03:05,730
+>> No, that was my question.
+
+69
+00:03:05,730 --> 00:03:08,040
+>> Okay, perfect, so what I'm going to do next, I
+
+70
+00:03:08,040 --> 00:03:11,130
+mean, I haven't mentioned that yet, but you know classes right
+
+71
+00:03:11,130 --> 00:03:12,890
+now we just looked at the attributes right that give
+
+72
+00:03:12,890 --> 00:03:16,140
+you sort of the state of the class. And there's something
+
+73
+00:03:16,140 --> 00:03:19,185
+else, there's a second part of the class that is kind of
+
+74
+00:03:19,185 --> 00:03:22,520
+an orthogonal aspect, which is what the class can do. And we
+
+75
+00:03:22,520 --> 00:03:25,640
+call those operations. So normally these kinds also have operations, I
+
+76
+00:03:25,640 --> 00:03:28,000
+guess you know it would make sense to you as well.
+
+77
+00:03:28,000 --> 00:03:30,070
+And one way, one very natural way to
+
+78
+00:03:30,070 --> 00:03:33,310
+identify operations is to look at the requirements and
+
+79
+00:03:33,310 --> 00:03:36,850
+look for verbs. Because verbs associated with an item
+
+80
+00:03:36,850 --> 00:03:38,480
+will tell you basically what the item can do.
+
+81
+00:03:38,480 --> 00:03:38,900
+>> Okay.
+
+82
+00:03:38,900 --> 00:03:41,250
+>> So I, I'd like to go back to the requirements and
+
+83
+00:03:41,250 --> 00:03:45,110
+start, the same way in which we underlined, nouns, we're going to underline
+
+84
+00:03:45,110 --> 00:03:49,340
+verbs and we're going to see which ones of those verbs actually represent
+
+85
+00:03:49,340 --> 00:03:53,120
+actions that we want to represent explicitly, we want to model explicitly in
+
+86
+00:03:53,120 --> 00:03:53,950
+our class diagram.
+
+87
+00:03:53,950 --> 00:03:54,490
+>> Okay.
+
+88
+00:03:54,490 --> 00:03:54,750
+>> Okay.
+
diff --git a/usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/5 - Identifying Operations - lang_en.srt b/usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/5 - Identifying Operations - lang_en.srt
new file mode 100644
index 0000000..74ca388
--- /dev/null
+++ b/usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/5 - Identifying Operations - lang_en.srt	
@@ -0,0 +1,304 @@
+1
+00:00:00,460 --> 00:00:03,276
+>> And before we get started actually, I'd like to mention that there's
+
+2
+00:00:03,276 --> 00:00:05,124
+just, you know, FYI, there's different kinds
+
+3
+00:00:05,124 --> 00:00:06,708
+of verbs because what I'm looking for
+
+4
+00:00:06,708 --> 00:00:10,099
+is really action verbs. So verb, verbs that clearly express an action that
+
+5
+00:00:10,099 --> 00:00:13,580
+can tell me that, you know, what, for example, an item could do, 'kay?
+
+6
+00:00:13,580 --> 00:00:13,820
+>> Okay?
+
+7
+00:00:13,820 --> 00:00:16,620
+>> Not the verbs that represent, for example, relationships, 'kay?
+
+8
+00:00:16,620 --> 00:00:17,076
+>> Okay.
+
+9
+00:00:17,076 --> 00:00:19,080
+>> So, and the, there, and the ones
+
+10
+00:00:19,080 --> 00:00:22,020
+that I've identified und, underlined here actually, I,
+
+11
+00:00:22,020 --> 00:00:26,158
+I underlined complete sentences so that you kind of we can look at the verbs in
+
+12
+00:00:26,158 --> 00:00:29,150
+in context. And the first one is this
+
+13
+00:00:29,150 --> 00:00:30,850
+sentence that says that the library may need
+
+14
+00:00:30,850 --> 00:00:33,190
+to know or to calculate the items a
+
+15
+00:00:33,190 --> 00:00:35,790
+patron has checked out, when they are due, and
+
+16
+00:00:35,790 --> 00:00:38,860
+any outstanding overdue fines. So I, I will
+
+17
+00:00:38,860 --> 00:00:41,430
+imagine that this is representing a situation in
+
+18
+00:00:41,430 --> 00:00:44,224
+which you bring up a patron's record and
+
+19
+00:00:44,224 --> 00:00:46,131
+you start looking up this information. Is that [CROSSTALK]
+
+20
+00:00:46,131 --> 00:00:50,970
+>> The, the patron often wants to know what they have currently checked out.
+
+21
+00:00:50,970 --> 00:00:51,044
+>> Oh,
+
+22
+00:00:51,044 --> 00:00:51,282
+alright.
+
+23
+00:00:51,282 --> 00:00:53,260
+>> Or when are their due or how much they're owed or.
+
+24
+00:00:53,260 --> 00:00:55,100
+>> Oh, in fact, and then now that you mentioned it,
+
+25
+00:00:55,100 --> 00:00:57,500
+I think you sent me. One of the scenarios you sent
+
+26
+00:00:57,500 --> 00:00:59,400
+me had to do with that, right, with the patron coming
+
+27
+00:00:59,400 --> 00:01:01,930
+in and asking for this information. So yeah, and it makes
+
+28
+00:01:01,930 --> 00:01:05,025
+a lot of sense. So what I'm going to do, I'm going to
+
+29
+00:01:05,025 --> 00:01:10,520
+model this by adding this three operations to the patron method.
+
+30
+00:01:10,520 --> 00:01:13,410
+The first one, I'm going to call, itemsCheckedOut and, basically, it's an
+
+31
+00:01:13,410 --> 00:01:16,520
+operation, but you don't need to, you know, understand the implementation
+
+32
+00:01:16,520 --> 00:01:18,820
+details, but when you call this operation, it will
+
+33
+00:01:18,820 --> 00:01:21,770
+give you back exactly this information, so the items
+
+34
+00:01:21,770 --> 00:01:23,864
+that are checked out by that patron. The second
+
+35
+00:01:23,864 --> 00:01:25,965
+one, I'm going to call it whenDue. That will tell you
+
+36
+00:01:25,965 --> 00:01:29,080
+basically when a, when an item is due. And
+
+37
+00:01:29,080 --> 00:01:32,550
+the third one is going to be called the outstandingOverdueFines and,
+
+38
+00:01:32,550 --> 00:01:34,510
+you know, as the name says, it's going to tell
+
+39
+00:01:34,510 --> 00:01:36,860
+you what are the outstanding overdue fines for that patron.
+
+40
+00:01:36,860 --> 00:01:37,300
+>> Okay.
+
+41
+00:01:37,300 --> 00:01:39,306
+>> And as you might notice I mean,
+
+42
+00:01:39,306 --> 00:01:41,843
+I, I'm going to separate the, the, the attributes
+
+43
+00:01:41,843 --> 00:01:44,085
+from the operations by having a separate kind
+
+44
+00:01:44,085 --> 00:01:46,386
+of subrectangle so, in this way, it's clear
+
+45
+00:01:46,386 --> 00:01:48,274
+what is attribute and what is, what is
+
+46
+00:01:48,274 --> 00:01:51,000
+an attribute and what's an, what's an operation.
+
+47
+00:01:51,000 --> 00:01:51,420
+>> Gotcha.
+
+48
+00:01:51,420 --> 00:01:57,540
+>> And let me see then. Okay, for the
+
+49
+00:01:57,540 --> 00:02:00,040
+second one you can see that that patron can check
+
+50
+00:02:00,040 --> 00:02:02,990
+out books and audio visual materials. So I guess,
+
+51
+00:02:02,990 --> 00:02:06,880
+similarly you, you build kind of the record for a patron.
+
+52
+00:02:06,880 --> 00:02:09,150
+The patron will give you an item and you will record
+
+53
+00:02:09,150 --> 00:02:11,020
+the fact that the patron is kind of checking it out.
+
+54
+00:02:11,020 --> 00:02:15,730
+>> Right. And is that operation related to this,
+
+55
+00:02:15,730 --> 00:02:18,150
+the checked out attribute that we did a minute ago?
+
+56
+00:02:18,150 --> 00:02:21,495
+>> It is actually because what will happen then again, you know, if we jump
+
+57
+00:02:21,495 --> 00:02:24,975
+ahead a little bit would be that every time you invoke this operation. So I'm
+
+58
+00:02:24,975 --> 00:02:26,810
+going to represent this as a checkOut operation
+
+59
+00:02:26,810 --> 00:02:28,896
+for the patron. Every time you invoke this,
+
+60
+00:02:28,896 --> 00:02:31,920
+you will also have to say something about the item and so we will also
+
+61
+00:02:31,920 --> 00:02:35,700
+flip kind of that that, that build information in the, in the, in the item.
+
+62
+00:02:35,700 --> 00:02:36,904
+>> Okay.
+
+63
+00:02:36,904 --> 00:02:39,680
+>> Mm, 'kay? And, and finally, here, I can see that
+
+64
+00:02:39,680 --> 00:02:42,660
+a patron can request a book or an audio video item Is
+
+65
+00:02:42,660 --> 00:02:46,240
+not currently in. So I guess this is referring to items that
+
+66
+00:02:46,240 --> 00:02:48,980
+are already checked out but for which there is interest. Is that?
+
+67
+00:02:48,980 --> 00:02:54,770
+>> Right. So, particularly, the popular items the patrons want to get on
+
+68
+00:02:54,770 --> 00:02:57,140
+the list so that they get notified when it comes back in and.
+
+69
+00:02:57,140 --> 00:02:57,204
+>> Oh.
+
+70
+00:02:57,204 --> 00:02:57,730
+>> And check it out.
+
+71
+00:02:57,730 --> 00:03:00,570
+>> I see. I see. Okay. Then I'm going to do
+
+72
+00:03:00,570 --> 00:03:04,400
+the same thing here. I'm, I'm going to add this method,
+
+73
+00:03:04,400 --> 00:03:08,510
+which I'm going to call request and I'm going to put it
+
+74
+00:03:08,510 --> 00:03:11,340
+here in the list of the methods in the list.
+
+75
+00:03:11,340 --> 00:03:11,450
+>> Okay.
+
+76
+00:03:11,450 --> 00:03:12,810
+>> Of operations for the, for the patron, okay?
+
diff --git a/usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/6 - Adding Relationships - lang_en.srt b/usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/6 - Adding Relationships - lang_en.srt
new file mode 100644
index 0000000..d47ef80
--- /dev/null
+++ b/usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/6 - Adding Relationships - lang_en.srt	
@@ -0,0 +1,488 @@
+1
+00:00:00,420 --> 00:00:02,740
+OK I like the way this class diagram is
+
+2
+00:00:02,740 --> 00:00:05,850
+coming along. So at this point I think we
+
+3
+00:00:05,850 --> 00:00:08,300
+have all the classes that we need. For each
+
+4
+00:00:08,300 --> 00:00:12,250
+class we specified the attributes or the characteristics of the
+
+5
+00:00:12,250 --> 00:00:15,150
+class. And we also specified the operations so we
+
+6
+00:00:15,150 --> 00:00:18,710
+know what the class can do And, I like to
+
+7
+00:00:18,710 --> 00:00:22,110
+kind of move forward on this, but I first
+
+8
+00:00:22,110 --> 00:00:25,690
+want to see that you're fine with the class structure.
+
+9
+00:00:25,690 --> 00:00:27,500
+So that's the way the class structure is going
+
+10
+00:00:27,500 --> 00:00:29,880
+to be in terms of attributes and operations. So anything
+
+11
+00:00:29,880 --> 00:00:34,910
+that bothers you? Well, one thing I didn't understand
+
+12
+00:00:34,910 --> 00:00:38,090
+is how come you put check out over where
+
+13
+00:00:38,090 --> 00:00:40,350
+the patron when it's really the item being checked
+
+14
+00:00:40,350 --> 00:00:46,280
+out? Right. Okay. So that actually is you know, is a perfect
+
+15
+00:00:46,280 --> 00:00:48,030
+segway for the next thing that really wanted
+
+16
+00:00:48,030 --> 00:00:50,780
+to model. Because what you're talking about is basically a
+
+17
+00:00:50,780 --> 00:00:54,100
+relationship between two classes which is something we haven't touched on
+
+18
+00:00:54,100 --> 00:00:57,582
+yet. So we haven't, haven't looked at individual classes. But now, it
+
+19
+00:00:57,582 --> 00:01:00,720
+is typical, now we are looking more at requirements, we're starting to
+
+20
+00:01:00,720 --> 00:01:04,800
+find more things about our system, and what you're pointed out right
+
+21
+00:01:04,800 --> 00:01:08,370
+now is the fact that patron and item are somehow related. So
+
+22
+00:01:08,370 --> 00:01:11,020
+this checkout operation is not really something that belongs only on in
+
+23
+00:01:11,020 --> 00:01:13,660
+the patron, because it needs to know about the item. And it
+
+24
+00:01:13,660 --> 00:01:15,790
+doesn't belong only on the item because it needs to know about
+
+25
+00:01:15,790 --> 00:01:19,640
+the patron. So, it's something that associates the patron and
+
+26
+00:01:19,640 --> 00:01:22,600
+the item. Okay. And that's exactly the way we call
+
+27
+00:01:22,600 --> 00:01:24,630
+in the UML which is the notation that we're using
+
+28
+00:01:24,630 --> 00:01:29,060
+here this kind of relationship. So, we're going to represent that
+
+29
+00:01:29,060 --> 00:01:32,820
+by drawing a line between these two classes that tells
+
+30
+00:01:32,820 --> 00:01:35,220
+us there is an association. And we're also going to
+
+31
+00:01:35,220 --> 00:01:37,890
+give a name to this. Since this refers to the
+
+32
+00:01:37,890 --> 00:01:40,280
+fact of checking out items. We're just going to call
+
+33
+00:01:40,280 --> 00:01:43,794
+it, checkout. Gotcha. And notice that this basically you
+
+34
+00:01:43,794 --> 00:01:48,500
+know,eventually will end up kind of replacing this attribute. Because
+
+35
+00:01:48,500 --> 00:01:51,780
+the existence of this association will tell us that
+
+36
+00:01:51,780 --> 00:01:53,932
+this is checked out. We're, we're not going to, you know,
+
+37
+00:01:53,932 --> 00:01:55,428
+do it right now, but in the final cleanup
+
+38
+00:01:55,428 --> 00:01:58,750
+or the diagram, this name will disappear. Okay. Okay.
+
+39
+00:01:58,750 --> 00:02:02,190
+And so since we started talking about relationships and
+
+40
+00:02:02,190 --> 00:02:05,280
+associations, is there any other kind of relationship that you
+
+41
+00:02:05,280 --> 00:02:08,805
+see here? Well, what you just did with checked
+
+42
+00:02:08,805 --> 00:02:12,009
+out is, it seems similar to the whole issue
+
+43
+00:02:12,009 --> 00:02:16,090
+of requests. It is, it is. So a request
+
+44
+00:02:16,090 --> 00:02:19,580
+is something else that happens in both, you know, in
+
+45
+00:02:19,580 --> 00:02:22,090
+the patron and in the item, it involves both.
+
+46
+00:02:22,090 --> 00:02:24,070
+And in fact in a request, I would definitely
+
+47
+00:02:24,070 --> 00:02:26,950
+represent this as an additional association. So I will
+
+48
+00:02:26,950 --> 00:02:30,730
+just draw an another line between these two that represent
+
+49
+00:02:30,730 --> 00:02:33,804
+that specific kind of relationship and I will call it
+
+50
+00:02:33,804 --> 00:02:37,330
+request. So that indicates that this association refers to a
+
+51
+00:02:37,330 --> 00:02:41,660
+request that also connects the patron with an item. Okay.
+
+52
+00:02:41,660 --> 00:02:45,710
+And, let's see. Any, anything else that jumps at you?
+
+53
+00:02:45,710 --> 00:02:47,590
+Yeah, well, how about all these ones down at the
+
+54
+00:02:47,590 --> 00:02:50,080
+bottom? I mean book and item's got to be
+
+55
+00:02:50,080 --> 00:02:52,920
+related, right? A book is a kind of item, And
+
+56
+00:02:52,920 --> 00:02:55,860
+audiovisual... are there associations between them? Can you repeat
+
+57
+00:02:55,860 --> 00:02:58,790
+that, you said that the book, yeah? Is
+
+58
+00:02:58,790 --> 00:03:02,550
+a kind of item. Perfect, that's exactly what we're
+
+59
+00:03:02,550 --> 00:03:04,700
+modeling next, which is, this, what we call the
+
+60
+00:03:04,700 --> 00:03:07,900
+is-a relationship. So you said, a book is an item?
+
+61
+00:03:07,900 --> 00:03:13,346
+A book is an item. And, we can model that in the diagram. So, we do that
+
+62
+00:03:13,346 --> 00:03:17,409
+using another kind of relationship between the classes. So
+
+63
+00:03:17,409 --> 00:03:21,210
+we're going to represent that as a specialization we call it.
+
+64
+00:03:21,210 --> 00:03:24,890
+And, a specialization is indicated in this way. Okay?
+
+65
+00:03:24,890 --> 00:03:27,410
+With this arrow at the end, so a solid
+
+66
+00:03:27,410 --> 00:03:30,800
+with this kind of arrow at the end. And
+
+67
+00:03:30,800 --> 00:03:34,160
+we can do the same for book, magazine, reference book
+
+68
+00:03:34,160 --> 00:03:36,200
+and audiovisual material. So we're all going to connect,
+
+69
+00:03:36,200 --> 00:03:37,950
+we're going to connect all of them, to the
+
+70
+00:03:37,950 --> 00:03:43,190
+item, using the same kind of connection. And now
+
+71
+00:03:43,190 --> 00:03:47,200
+that we have connected all these four, with item
+
+72
+00:03:47,200 --> 00:03:50,620
+and indicated them in subclasses. That's something else that we can
+
+73
+00:03:50,620 --> 00:03:54,370
+do. So we can make this kind of cleaner. And I'll
+
+74
+00:03:54,370 --> 00:03:56,360
+tell you what I mean by that. So now we have
+
+75
+00:03:56,360 --> 00:04:00,190
+this loanable attribute that refers to item, but it seems to
+
+76
+00:04:00,190 --> 00:04:03,100
+me from what you were saying before, that loanable is not
+
+77
+00:04:03,100 --> 00:04:05,490
+really an attribute of an item. Right? It's more of a
+
+78
+00:04:05,490 --> 00:04:09,240
+characteristic of the type of item. Right. Is that right? Right.
+
+79
+00:04:09,240 --> 00:04:13,120
+Books, and audio/visual are loanable but the others aren't.
+
+80
+00:04:13,120 --> 00:04:16,450
+Okay, and so representing it here, it's okay to,
+
+81
+00:04:16,450 --> 00:04:20,579
+it will work. But it's not really right so from
+
+82
+00:04:20,579 --> 00:04:23,590
+the style standpoint it doesn't really you know,
+
+83
+00:04:23,590 --> 00:04:26,100
+it's not the best way of modeling this. What we're going to
+
+84
+00:04:26,100 --> 00:04:30,130
+do instead, we're going to use this specialization relationship to make
+
+85
+00:04:30,130 --> 00:04:33,000
+that more explicit. To make it cleaner. Okay, so what
+
+86
+00:04:33,000 --> 00:04:35,300
+I'm doing here is I'm going to take this hierarchy
+
+87
+00:04:35,300 --> 00:04:38,130
+of classes, this is just on two levels now, and I'm
+
+88
+00:04:38,130 --> 00:04:40,380
+going to kind of make it a little richer.
+
+89
+00:04:40,380 --> 00:04:43,470
+So I'm going to add an intermediate set of
+
+90
+00:04:43,470 --> 00:04:45,756
+classes. And in particular I'm going to have these two
+
+91
+00:04:45,756 --> 00:04:48,306
+classes that I'm going to call non loanable item and loanable
+
+92
+00:04:48,306 --> 00:04:51,790
+item. So, they're both items but they tell me
+
+93
+00:04:51,790 --> 00:04:55,490
+clearly that some items are loanable and some items
+
+94
+00:04:55,490 --> 00:04:59,392
+are not. Okay. Okay. And then I'm simply going to
+
+95
+00:04:59,392 --> 00:05:03,192
+put book and audio video material as subclasses of loanable
+
+96
+00:05:03,192 --> 00:05:07,980
+item and reference book and magazine as subclasses of non-loanable
+
+97
+00:05:07,980 --> 00:05:10,510
+item. So, if we look at this diagram now it's
+
+98
+00:05:10,510 --> 00:05:13,650
+pretty clear what is loanable and what is not. And
+
+99
+00:05:13,650 --> 00:05:16,070
+it's actually is a very clean, much cleaner
+
+100
+00:05:16,070 --> 00:05:18,980
+design. And, and I see you've, gotten rid of
+
+101
+00:05:18,980 --> 00:05:21,560
+the loanable attribute, too. I did. Because at
+
+102
+00:05:21,560 --> 00:05:24,130
+this point this is already represented by the fact of
+
+103
+00:05:24,130 --> 00:05:28,570
+having these two classes. And actually, something else that I did
+
+104
+00:05:28,570 --> 00:05:31,820
+is that I moved all these attributes, value,
+
+105
+00:05:31,820 --> 00:05:34,220
+due date, renewed and checked out, that makes
+
+106
+00:05:34,220 --> 00:05:37,452
+sense only for loanable item. From item to
+
+107
+00:05:37,452 --> 00:05:40,450
+loanable item. So at this point, this really
+
+108
+00:05:40,450 --> 00:05:42,600
+is telling me that, you know, these
+
+109
+00:05:42,600 --> 00:05:46,410
+characteristics are just meaningful for the loanable item,
+
+110
+00:05:46,410 --> 00:05:53,800
+and not for the other ones. Well, speaking of that, the way that you got the
+
+111
+00:05:53,800 --> 00:05:57,270
+lines going in the diagram here is you still have
+
+112
+00:05:57,270 --> 00:05:59,920
+request and checked out going to item, even though you
+
+113
+00:05:59,920 --> 00:06:02,610
+can't request non loanable Items. You can't check out non
+
+114
+00:06:02,610 --> 00:06:05,630
+loanable Items. Oh, you were right actually. You got me on
+
+115
+00:06:05,630 --> 00:06:10,940
+that one. You're exactly right. So this associations are between
+
+116
+00:06:10,940 --> 00:06:13,440
+the two wrong classes. So, I guess, at this point,
+
+117
+00:06:13,440 --> 00:06:16,450
+you can probably go and fix the diagram yourself. Well,
+
+118
+00:06:16,450 --> 00:06:19,120
+can we just make the lines go from patron to loanable
+
+119
+00:06:19,120 --> 00:06:21,640
+item instead of to item? That's exactly the way in which we
+
+120
+00:06:21,640 --> 00:06:25,550
+are going to fix it. So, we're going to move these two associations down
+
+121
+00:06:25,550 --> 00:06:29,190
+here. And at this point, this will represent the right relationships in
+
+122
+00:06:29,190 --> 00:06:31,850
+the, in the diagram, and in the system. Makes sense to me.
+
diff --git a/usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/7 - Refining Relationships - lang_en.srt b/usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/7 - Refining Relationships - lang_en.srt
new file mode 100644
index 0000000..44f9165
--- /dev/null
+++ b/usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/7 - Refining Relationships - lang_en.srt	
@@ -0,0 +1,188 @@
+1
+00:00:00,350 --> 00:00:03,460
+Spencer, I gotta tell you, I'm impressed.
+
+2
+00:00:03,460 --> 00:00:05,441
+You're getting very good at this. So, why
+
+3
+00:00:05,441 --> 00:00:07,190
+don't you go wild and continue, there
+
+4
+00:00:07,190 --> 00:00:09,240
+anything else you think we can improve here?
+
+5
+00:00:09,240 --> 00:00:11,800
+>> Well something was bothering
+
+6
+00:00:11,800 --> 00:00:14,600
+me, that what happens if there's more
+
+7
+00:00:14,600 --> 00:00:19,110
+than one book with the same title and somebody puts in a request?
+
+8
+00:00:19,110 --> 00:00:25,360
+>> Oh, I see. That's a good point. So basically what you are telling me is
+
+9
+00:00:25,360 --> 00:00:28,630
+there's kind of a difference between an item and
+
+10
+00:00:28,630 --> 00:00:30,660
+the title, so the title is kind of a more
+
+11
+00:00:30,660 --> 00:00:32,940
+general concept, in a sense. So if you can
+
+12
+00:00:32,940 --> 00:00:35,830
+have multiple copies of a given title, is that right?
+
+13
+00:00:35,830 --> 00:00:38,460
+>> Yeah, we have five copies of Tom Sawyer, and the
+
+14
+00:00:38,460 --> 00:00:42,810
+persons, the patrons, really putting in a request for any Tom Sawyer.
+
+15
+00:00:42,810 --> 00:00:45,332
+>> They don't want like copy number three of Tom Sawyer, right? They want,
+
+16
+00:00:45,332 --> 00:00:50,530
+they want to read Tom Sawyer. Okay and I can represent that. So, in which
+
+17
+00:00:50,530 --> 00:00:55,230
+I suggest we do that, and you can tell me whether it makes sense to you is by
+
+18
+00:00:55,230 --> 00:00:59,650
+introducing an additional class, which I call Title. And
+
+19
+00:00:59,650 --> 00:01:02,614
+that represents exactly the concept that you're mentioning. So
+
+20
+00:01:02,614 --> 00:01:04,666
+this is a title which represents some
+
+21
+00:01:04,666 --> 00:01:09,180
+specific content. That is not related to a specific
+
+22
+00:01:09,180 --> 00:01:12,110
+physical element. Like it can be rated to multiple,
+
+23
+00:01:12,110 --> 00:01:15,520
+physical elements. So basically I'm going to create this title.
+
+24
+00:01:15,520 --> 00:01:18,100
+And then I'm going to create a relationship between
+
+25
+00:01:18,100 --> 00:01:20,500
+the title and the item. And what
+
+26
+00:01:20,500 --> 00:01:22,530
+the relationship is telling me, the the association
+
+27
+00:01:22,530 --> 00:01:25,512
+between these two in this case. Is an association,
+
+28
+00:01:25,512 --> 00:01:30,320
+that we call aggregation. So it's a special kind of association, that basically
+
+29
+00:01:30,320 --> 00:01:35,450
+indicates that an item of this type, so a title can
+
+30
+00:01:35,450 --> 00:01:40,692
+consist of a multiple elements of this type of multiple items.
+
+31
+00:01:40,692 --> 00:01:42,710
+So it's telling me that one title can
+
+32
+00:01:42,710 --> 00:01:45,700
+consist of multiple items, and I'm going to indicate
+
+33
+00:01:45,700 --> 00:01:48,560
+it with this annotation, which is a this
+
+34
+00:01:49,700 --> 00:01:53,200
+diamond at the top of the association.
+
+35
+00:01:53,200 --> 00:01:55,570
+>> And so we can move our request
+
+36
+00:01:55,570 --> 00:01:57,510
+line, up from loanable item to
+
+37
+00:01:57,510 --> 00:01:59,010
+title, because that's what they're really requesting.
+
+38
+00:01:59,010 --> 00:02:00,710
+>> Definitely, definitely, and in fact,
+
+39
+00:02:00,710 --> 00:02:02,420
+you know, that represents exactly the situation
+
+40
+00:02:02,420 --> 00:02:06,350
+that you are mentioning, at this point when the patron makes a request.
+
+41
+00:02:06,350 --> 00:02:12,240
+It makes a request to a title and not to a loanable item. And then, and
+
+42
+00:02:12,240 --> 00:02:15,420
+when the actual loan will take place,
+
+43
+00:02:15,420 --> 00:02:18,420
+then that will be connected to a specific item.
+
+44
+00:02:18,420 --> 00:02:20,090
+>> Right. Okay that makes sense.
+
+45
+00:02:20,090 --> 00:02:20,388
+>> Makes sense?
+
+46
+00:02:20,388 --> 00:02:20,779
+>> Yeah.
+
+47
+00:02:20,779 --> 00:02:21,214
+>> Okay, good.
+
diff --git a/usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/8 - Refining the Class Diagram - lang_en.srt b/usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/8 - Refining the Class Diagram - lang_en.srt
new file mode 100644
index 0000000..1e47ea6
--- /dev/null
+++ b/usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/8 - Refining the Class Diagram - lang_en.srt	
@@ -0,0 +1,328 @@
+1
+00:00:00,260 --> 00:00:01,720
+Okay, so let me see if
+
+2
+00:00:01,720 --> 00:00:07,930
+anything changed after we did this last modification.
+
+3
+00:00:07,930 --> 00:00:09,530
+Acutally, there is someting that I would like
+
+4
+00:00:09,530 --> 00:00:12,120
+to do here. Because looking at this a little
+
+5
+00:00:12,120 --> 00:00:15,560
+bit more, I noticed that there are two
+
+6
+00:00:15,560 --> 00:00:18,760
+attributes, renewed and due date. That we have in
+
+7
+00:00:18,760 --> 00:00:21,640
+loanable Item, right? But they don't seem to
+
+8
+00:00:21,640 --> 00:00:25,590
+be really, attributes or characteristics of loanable Item.
+
+9
+00:00:25,590 --> 00:00:29,150
+They're more of the characteristics of the association between the
+
+10
+00:00:29,150 --> 00:00:31,450
+Loanable Item and the patron. Wouldn't you agree?
+
+11
+00:00:32,470 --> 00:00:34,230
+>> Well, yeah, it's not like you could
+
+12
+00:00:34,230 --> 00:00:37,644
+only renew a book once in it's entire history.
+
+13
+00:00:37,644 --> 00:00:41,220
+>> Right. Exactly, exactly. So, that's why what l like
+
+14
+00:00:41,220 --> 00:00:43,970
+to do is I would like to move those out of loanable
+
+15
+00:00:43,970 --> 00:00:48,020
+item. And actually there is a construct that we can use
+
+16
+00:00:48,020 --> 00:00:50,710
+to express this. It's called, we haven't seen it yet, but it's
+
+17
+00:00:50,710 --> 00:00:52,780
+a special kind of class. It's called an association
+
+18
+00:00:52,780 --> 00:00:55,480
+class. So, it's a class that is connected to
+
+19
+00:00:55,480 --> 00:00:57,730
+a specific association. So what we can do
+
+20
+00:00:57,730 --> 00:01:00,730
+here, we can create this class, which I'm going to
+
+21
+00:01:00,730 --> 00:01:05,200
+call checked out. I'm going to, associate it with
+
+22
+00:01:05,200 --> 00:01:09,520
+this, association. I'm going to connect it with this association. And
+
+23
+00:01:09,520 --> 00:01:11,620
+then I'm going to move the due date and the
+
+24
+00:01:11,620 --> 00:01:16,300
+renewed attributes From the LoanableItem here in this checked
+
+25
+00:01:16,300 --> 00:01:18,520
+out class. So in this way, seems to me that
+
+26
+00:01:18,520 --> 00:01:20,910
+it makes it very explicit for somebody looking at this
+
+27
+00:01:20,910 --> 00:01:25,530
+class diagram, that these characteristics are characteristics of the loan,
+
+28
+00:01:25,530 --> 00:01:28,200
+and not of the elements involved in the loan.
+
+29
+00:01:28,200 --> 00:01:33,410
+>> Can you do the same thing with Fine, isn't Fine a property of the
+
+30
+00:01:33,410 --> 00:01:36,740
+loan? Yeah, actually is right because
+
+31
+00:01:36,740 --> 00:01:39,120
+a fine is a fine for a specific loan, right?
+
+32
+00:01:39,120 --> 00:01:39,910
+>> That's correct.
+
+33
+00:01:39,910 --> 00:01:41,950
+>> Okay, so yeah. Then we can do that.
+
+34
+00:01:41,950 --> 00:01:45,900
+We don't need to represent fine as a class, we can just transform
+
+35
+00:01:45,900 --> 00:01:49,460
+that into an attribute that we can put into the checked out association class.
+
+36
+00:01:49,460 --> 00:01:50,560
+>> Gotcha.
+
+37
+00:01:50,560 --> 00:01:52,760
+>> Anything else?
+
+38
+00:01:52,760 --> 00:01:57,990
+>> Yeah. It occurred to me that there's another thing that happens in one
+
+39
+00:01:57,990 --> 00:02:00,260
+of my scenarios, I put down
+
+40
+00:02:00,260 --> 00:02:02,770
+about the patron actually returning an item.
+
+41
+00:02:02,770 --> 00:02:07,620
+>> Right. Okay, so we would probably need an additional operation,
+
+42
+00:02:07,620 --> 00:02:08,550
+I guess, for the patron.
+
+43
+00:02:08,550 --> 00:02:08,990
+>> Right.
+
+44
+00:02:08,990 --> 00:02:11,310
+>> So, okay, so what I'm going to do, that's pretty easy
+
+45
+00:02:11,310 --> 00:02:15,350
+to do, I'm just going to add the return operation here in the
+
+46
+00:02:15,350 --> 00:02:19,310
+patron, and when that happens, that will mean that I'll get rid
+
+47
+00:02:19,310 --> 00:02:23,490
+of this association class because the item is returned. Is that right?
+
+48
+00:02:23,490 --> 00:02:27,060
+>> Well, what happens if somebody drops the
+
+49
+00:02:27,060 --> 00:02:29,400
+book in the book drop, but doesn't pay the,
+
+50
+00:02:29,400 --> 00:02:31,050
+if it's overdue and doesn't pay the fine?
+
+51
+00:02:31,050 --> 00:02:32,700
+Will that get rid of the information about what
+
+52
+00:02:32,700 --> 00:02:33,040
+they owe?
+
+53
+00:02:33,040 --> 00:02:37,960
+>> Oh, I see. So you can have the item being available, but you still
+
+54
+00:02:37,960 --> 00:02:42,510
+want to know whether there is any pending fines on the book.
+
+55
+00:02:42,510 --> 00:02:44,390
+>> Uh-huh, and how much those fines are.
+
+56
+00:02:44,390 --> 00:02:46,340
+>> And how do you compute how much it is?
+
+57
+00:02:47,420 --> 00:02:52,710
+>> It's how many days it was, from the time it was
+
+58
+00:02:52,710 --> 00:02:58,170
+due, to when they returned it. I see. OK.
+
+59
+00:02:58,170 --> 00:03:00,380
+So you know what we can do? I think
+
+60
+00:03:00,380 --> 00:03:03,690
+we can put an additional attribute in the checked out
+
+61
+00:03:03,690 --> 00:03:07,190
+class and I'm going to call it when returned and
+
+62
+00:03:07,190 --> 00:03:10,200
+that item will have either a special value or it
+
+63
+00:03:10,200 --> 00:03:12,040
+will contain the date in which the book was
+
+64
+00:03:12,040 --> 00:03:14,520
+returned. So in this way you should be able to
+
+65
+00:03:14,520 --> 00:03:18,040
+keep this in the system until it's paid, and also to compute
+
+66
+00:03:18,040 --> 00:03:19,970
+how much the fine is. Is that working?
+
+67
+00:03:19,970 --> 00:03:23,210
+>> So the special value is for a normal situation when they
+
+68
+00:03:23,210 --> 00:03:25,880
+haven't, they don't owe anything and haven't returned it yet.
+
+69
+00:03:25,880 --> 00:03:28,080
+>> Exactly so that will tell us that,
+
+70
+00:03:28,080 --> 00:03:29,970
+that the loan is still active basically.
+
+71
+00:03:29,970 --> 00:03:30,500
+>> Great.
+
+72
+00:03:30,500 --> 00:03:31,480
+>> Does that work for you?
+
+73
+00:03:31,480 --> 00:03:35,200
+>> Yes. And you know, I like this. I mean, I feel pretty good
+
+74
+00:03:35,200 --> 00:03:38,490
+about it. I think we have a nice class diagram. So what I'd like to
+
+75
+00:03:38,490 --> 00:03:43,280
+do is just go off and clean it up a little bit, and put it
+
+76
+00:03:43,280 --> 00:03:48,640
+in an IDE so I can pretty print it and rearrange things a little bit.
+
+77
+00:03:48,640 --> 00:03:50,080
+And then I'd like to sit down again and
+
+78
+00:03:50,080 --> 00:03:52,730
+just go through it for a last time. And
+
+79
+00:03:52,730 --> 00:03:54,900
+for some final considerations. So if you don't mind
+
+80
+00:03:54,900 --> 00:03:56,880
+we will take a ten minute break and reconvene here.
+
+81
+00:03:56,880 --> 00:03:57,500
+>> That's fine.
+
+82
+00:03:57,500 --> 00:03:57,990
+>> Alright.
+
diff --git a/usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/9 - Final Considerations - lang_en.srt b/usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/9 - Final Considerations - lang_en.srt
new file mode 100644
index 0000000..0dbfccd
--- /dev/null
+++ b/usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/9 - Final Considerations - lang_en.srt	
@@ -0,0 +1,196 @@
+1
+00:00:00,140 --> 00:00:03,202
+Okay. So this is what I've done as you see,
+
+2
+00:00:03,202 --> 00:00:06,130
+it looks a little nicer than it was before. And I didn't
+
+3
+00:00:06,130 --> 00:00:08,530
+really change that much. I just made a few changes, so
+
+4
+00:00:08,530 --> 00:00:11,560
+I just wanted to point them out to you, so that you
+
+5
+00:00:11,560 --> 00:00:13,690
+know what they are. And the main thing, one of the
+
+6
+00:00:13,690 --> 00:00:18,210
+main things I did is really to introduce these derived attributes. So
+
+7
+00:00:18,210 --> 00:00:19,860
+these are attributes that are basically
+
+8
+00:00:19,860 --> 00:00:22,520
+computed. Based on some other attributes.
+
+9
+00:00:22,520 --> 00:00:26,010
+Okay, they don't have a value themselves, but their value is computed.
+
+10
+00:00:26,010 --> 00:00:28,900
+And I used two. The first one is age. So
+
+11
+00:00:28,900 --> 00:00:31,930
+basically we know the age of the patron based on
+
+12
+00:00:31,930 --> 00:00:34,920
+the birthday, of the patron. So you guys, I don't
+
+13
+00:00:34,920 --> 00:00:37,150
+know if you have that information currently in the system.
+
+14
+00:00:37,150 --> 00:00:38,480
+>> No, we'll have to add that to the
+
+15
+00:00:38,480 --> 00:00:40,280
+form patrons fill out, when they get their card.
+
+16
+00:00:40,280 --> 00:00:42,255
+>> Is that, that an issue? Can you do it?
+
+17
+00:00:42,255 --> 00:00:44,130
+>> No yes, we, we can easily do that.
+
+18
+00:00:44,130 --> 00:00:46,670
+>> Okay, so then, perfect. So we'll do it that way. I think it's
+
+19
+00:00:46,670 --> 00:00:51,310
+a, in a little cleaner. And similarly, since you told me that the fine
+
+20
+00:00:51,310 --> 00:00:54,480
+was computed based on the amount of days that an
+
+21
+00:00:54,480 --> 00:00:58,310
+item was late. The patron was late returning the item, then I
+
+22
+00:00:58,310 --> 00:01:02,010
+also added this as a derived attribute that is computed based on
+
+23
+00:01:02,010 --> 00:01:05,140
+the due date and when the item is actually returned.
+
+24
+00:01:05,140 --> 00:01:05,780
+>> Makes sense.
+
+25
+00:01:05,780 --> 00:01:08,389
+>> Makes sense? Okay. And the rest
+
+26
+00:01:08,389 --> 00:01:10,590
+is kind of really minor things. So the, the only one I
+
+27
+00:01:10,590 --> 00:01:14,340
+want to point out is I didn't, you know, discuss that with
+
+28
+00:01:14,340 --> 00:01:17,260
+you before, but I added this, which is called cardinality
+
+29
+00:01:17,260 --> 00:01:20,700
+for some of these relationships. And what they say is basically
+
+30
+00:01:20,700 --> 00:01:25,360
+is how many elements are involved in the relationship.
+
+31
+00:01:25,360 --> 00:01:26,580
+>> So, you mean the stars?
+
+32
+00:01:26,580 --> 00:01:27,960
+>> Yeah, like the stars and the one...
+
+33
+00:01:27,960 --> 00:01:28,290
+>> Okay.
+
+34
+00:01:28,290 --> 00:01:31,380
+>> Here for example, this is telling you that for each item there
+
+35
+00:01:31,380 --> 00:01:35,490
+is only one title. And that for each title, there are multiple items.
+
+36
+00:01:35,490 --> 00:01:36,490
+>> So, star means many.
+
+37
+00:01:36,490 --> 00:01:37,716
+>> Stars mean many, yeah.
+
+38
+00:01:37,716 --> 00:01:39,045
+>> Okay, go you.
+
+39
+00:01:39,045 --> 00:01:42,321
+>> Sorry that's kind of computer science lingo - we use the star
+
+40
+00:01:42,321 --> 00:01:45,500
+for that kind of stuff. And, similarly, for the patron, it's
+
+41
+00:01:45,500 --> 00:01:48,510
+telling me that, you know, each patron can have multiple, can
+
+42
+00:01:48,510 --> 00:01:52,550
+request multiple titles, and that the same title can be requested
+
+43
+00:01:52,550 --> 00:01:55,650
+by multiple patrons, which I think is the way the system works.
+
+44
+00:01:55,650 --> 00:01:59,080
+>> Right. So except for these minor changes,
+
+45
+00:01:59,080 --> 00:02:01,850
+we already had a pretty good model in our hands, so
+
+46
+00:02:01,850 --> 00:02:04,620
+I think is a, we can finalize this and then just
+
+47
+00:02:04,620 --> 00:02:07,350
+move to the low level design and then implementation, and be
+
+48
+00:02:07,350 --> 00:02:07,970
+done with the system.
+
+49
+00:02:07,970 --> 00:02:08,979
+>> Sounds good.
+
diff --git a/usth/ICT2.7/P3L3 Design Patterns Subtitles/1 - Lesson Overview - lang_en_vs4.srt b/usth/ICT2.7/P3L3 Design Patterns Subtitles/1 - Lesson Overview - lang_en_vs4.srt
new file mode 100644
index 0000000..152b961
--- /dev/null
+++ b/usth/ICT2.7/P3L3 Design Patterns Subtitles/1 - Lesson Overview - lang_en_vs4.srt	
@@ -0,0 +1,31 @@
+1
+00:00:00,230 --> 00:00:04,560
+In the last lesson, we talked about design, and we saw how difficult it can
+
+2
+00:00:04,560 --> 00:00:10,010
+be to come up with a good and effective design for a given software system. To
+
+3
+00:00:10,010 --> 00:00:12,620
+help address these difficulties, we will discuss
+
+4
+00:00:12,620 --> 00:00:16,560
+design patterns, which can support design activities by
+
+5
+00:00:16,560 --> 00:00:20,710
+providing general, reusable solutions to commonly occurring design
+
+6
+00:00:20,710 --> 00:00:25,410
+problems. Similar to architectural styles, design patterns can
+
+7
+00:00:25,410 --> 00:00:30,400
+help developers build better designed systems by reusing design solutions that
+
+8
+00:00:30,400 --> 00:00:33,730
+worked well in the past and by building on those solutions.
diff --git a/usth/ICT2.7/P3L3 Design Patterns Subtitles/10 - Choosing a Pattern - lang_en_vs5.srt b/usth/ICT2.7/P3L3 Design Patterns Subtitles/10 - Choosing a Pattern - lang_en_vs5.srt
new file mode 100644
index 0000000..f273441
--- /dev/null
+++ b/usth/ICT2.7/P3L3 Design Patterns Subtitles/10 - Choosing a Pattern - lang_en_vs5.srt	
@@ -0,0 +1,95 @@
+1
+00:00:00,150 --> 00:00:03,200
+But with so many patterns, how do we choose a pattern? So
+
+2
+00:00:03,200 --> 00:00:05,970
+this is a possible approach that you can follow. First of all, you
+
+3
+00:00:05,970 --> 00:00:09,140
+want to make sure that you understand your design context. You understand
+
+4
+00:00:09,140 --> 00:00:12,800
+what you're designing and what are the issues involved with this design. What
+
+5
+00:00:12,800 --> 00:00:15,200
+are the problems that you need to solve. At this point, you
+
+6
+00:00:15,200 --> 00:00:17,160
+can examine the patterns catalog, or,if
+
+7
+00:00:17,160 --> 00:00:18,750
+you're already familiar with the catalog, just
+
+8
+00:00:18,750 --> 00:00:22,430
+think about the possible patterns that you could use. Once you identify
+
+9
+00:00:22,430 --> 00:00:25,440
+the patterns that you can use, you also want to study them and
+
+10
+00:00:25,440 --> 00:00:29,090
+study the related patterns. So normally if you look at any pattern catalog,
+
+11
+00:00:29,090 --> 00:00:32,229
+for each pattern there will also be a list of related patterns. So
+
+12
+00:00:32,229 --> 00:00:35,010
+you can also look at those to see whether maybe some of those
+
+13
+00:00:35,010 --> 00:00:38,370
+might be more applicable. And finally, once you identify the pattern that you
+
+14
+00:00:38,370 --> 00:00:41,360
+think is appropriate, you will apply that pattern. When you do that, just
+
+15
+00:00:41,360 --> 00:00:44,850
+be mindful that there are pitfalls in the use of patterns. One obvious
+
+16
+00:00:44,850 --> 00:00:47,490
+one is the fact that you might select the wrong pattern and make
+
+17
+00:00:47,490 --> 00:00:50,460
+your design worse instead of better. The second one is that if you
+
+18
+00:00:50,460 --> 00:00:52,560
+get too excited about patterns, then you
+
+19
+00:00:52,560 --> 00:00:54,850
+might be abusing patterns, so just using too
+
+20
+00:00:54,850 --> 00:00:56,370
+many patterns, and end up with a design
+
+21
+00:00:56,370 --> 00:00:58,980
+that is more complicated rather than less complicated.
+
+22
+00:00:58,980 --> 00:01:01,890
+So always be careful, spend the time to figure out which one is the right
+
+23
+00:01:01,890 --> 00:01:03,577
+pattern to apply, and make sure that you
+
+24
+00:01:03,577 --> 00:01:05,190
+don't use patterns that you don't actually need.
diff --git a/usth/ICT2.7/P3L3 Design Patterns Subtitles/11 - Choosing a Pattern Quiz - lang_en_vs4.srt b/usth/ICT2.7/P3L3 Design Patterns Subtitles/11 - Choosing a Pattern Quiz - lang_en_vs4.srt
new file mode 100644
index 0000000..76a78e0
--- /dev/null
+++ b/usth/ICT2.7/P3L3 Design Patterns Subtitles/11 - Choosing a Pattern Quiz - lang_en_vs4.srt	
@@ -0,0 +1,31 @@
+1
+00:00:00,160 --> 00:00:02,780
+Now that we've discussed how to choose a pattern. Imagine that
+
+2
+00:00:02,780 --> 00:00:05,210
+you have to write a class that can have only one
+
+3
+00:00:05,210 --> 00:00:08,090
+instance. So to satisfy this requirement, I would like for you
+
+4
+00:00:08,090 --> 00:00:10,720
+to pick one of the design patterns that we discussed in
+
+5
+00:00:10,720 --> 00:00:14,580
+this lesson, and write the code here that satisfies that requirement.
+
+6
+00:00:14,580 --> 00:00:16,270
+And when you write the code, please make sure that your
+
+7
+00:00:16,270 --> 00:00:21,140
+class has only one method, without counting possible constructors, and that
+
+8
+00:00:21,140 --> 00:00:25,120
+the class is called Singleton. And write your class right here.
diff --git a/usth/ICT2.7/P3L3 Design Patterns Subtitles/12 - Choosing a Pattern Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P3L3 Design Patterns Subtitles/12 - Choosing a Pattern Quiz Solution - lang_en_vs4.srt
new file mode 100644
index 0000000..c348a2c
--- /dev/null
+++ b/usth/ICT2.7/P3L3 Design Patterns Subtitles/12 - Choosing a Pattern Quiz Solution - lang_en_vs4.srt	
@@ -0,0 +1,79 @@
+1
+00:00:00,220 --> 00:00:01,750
+As we discussed in the class the right thing to
+
+2
+00:00:01,750 --> 00:00:05,050
+do here was to use the factory pattern. So here is
+
+3
+00:00:05,050 --> 00:00:07,910
+a possible code to solve the problem. Of course that there
+
+4
+00:00:07,910 --> 00:00:11,220
+are different possible solutions. So what we did for this code
+
+5
+00:00:11,220 --> 00:00:16,210
+was to first create a private, static, Singleton object called
+
+6
+00:00:16,210 --> 00:00:19,340
+instance, which is the one that will keep track of the
+
+7
+00:00:19,340 --> 00:00:22,250
+only instance that can be created on the class. Then we
+
+8
+00:00:22,250 --> 00:00:25,750
+define the default constructor, the constructor that doesn't take any parameter
+
+9
+00:00:25,750 --> 00:00:29,900
+as private. In this way other classes cannot create instances
+
+10
+00:00:29,900 --> 00:00:33,310
+of Singleton without calling our factory method, and finally we
+
+11
+00:00:33,310 --> 00:00:35,650
+create the factory method. And the factory method is very
+
+12
+00:00:35,650 --> 00:00:38,600
+simple. The method will first check whether an instance of
+
+13
+00:00:38,600 --> 00:00:40,970
+the class was already created. If it was created, it
+
+14
+00:00:40,970 --> 00:00:44,010
+would just return that instance. Otherwise, it will create a
+
+15
+00:00:44,010 --> 00:00:47,550
+new instance and assign it to that instance member variable
+
+16
+00:00:47,550 --> 00:00:50,960
+and then return the newly created instance. So with this code
+
+17
+00:00:50,960 --> 00:00:53,540
+you're guaranteed that other classes cannot bypass the factory
+
+18
+00:00:53,540 --> 00:00:56,530
+method, because the default constructor is private. And the that
+
+19
+00:00:56,530 --> 00:00:59,600
+the factory method will create one and only one instance
+
+20
+00:00:59,600 --> 00:01:02,020
+of the class, which is exactly what our requirements were.
diff --git a/usth/ICT2.7/P3L3 Design Patterns Subtitles/13 - Negative Design Patterns - lang_en_vs4.srt b/usth/ICT2.7/P3L3 Design Patterns Subtitles/13 - Negative Design Patterns - lang_en_vs4.srt
new file mode 100644
index 0000000..6433019
--- /dev/null
+++ b/usth/ICT2.7/P3L3 Design Patterns Subtitles/13 - Negative Design Patterns - lang_en_vs4.srt	
@@ -0,0 +1,51 @@
+1
+00:00:00,100 --> 00:00:02,210
+To conclude this lesson, I want to discuss the
+
+2
+00:00:02,210 --> 00:00:06,170
+concept of negative design patterns, that is, patterns that should
+
+3
+00:00:06,170 --> 00:00:09,600
+be avoided. Interestingly, negative patterns were also mentioned in
+
+4
+00:00:09,600 --> 00:00:12,950
+Christopher Alexander's book, so in the first formulation of patterns.
+
+5
+00:00:12,950 --> 00:00:16,219
+So negative design pattern are basically guidelines on how
+
+6
+00:00:16,219 --> 00:00:19,689
+not to do things. In consoles with patterns, the guidelines
+
+7
+00:00:19,689 --> 00:00:21,920
+on how to do things. So basically, what the negative
+
+8
+00:00:21,920 --> 00:00:25,170
+design patterns do is, they enable recurring design defects to
+
+9
+00:00:25,170 --> 00:00:28,070
+be avoided. And as we will see in this class extensively,
+
+10
+00:00:28,070 --> 00:00:30,080
+in mini-course four, negative patterns are
+
+11
+00:00:30,080 --> 00:00:33,380
+also called anti-patterns or bad smells,
+
+12
+00:00:33,380 --> 00:00:36,540
+or bad code smells. So in mini-course four we will see several
+
+13
+00:00:36,540 --> 00:00:39,480
+examples of bad smells and what we can do to eliminate them.
diff --git a/usth/ICT2.7/P3L3 Design Patterns Subtitles/2 - History of Design Patterns - lang_en_vs6.srt b/usth/ICT2.7/P3L3 Design Patterns Subtitles/2 - History of Design Patterns - lang_en_vs6.srt
new file mode 100644
index 0000000..5fbb886
--- /dev/null
+++ b/usth/ICT2.7/P3L3 Design Patterns Subtitles/2 - History of Design Patterns - lang_en_vs6.srt	
@@ -0,0 +1,179 @@
+1
+00:00:00,160 --> 00:00:02,780
+Let's start our decision of design patterns by looking
+
+2
+00:00:02,780 --> 00:00:05,280
+at the history of patterns. As you know, I like
+
+3
+00:00:05,280 --> 00:00:07,810
+to give this sort of historical perspective on how and
+
+4
+00:00:07,810 --> 00:00:10,600
+when concepts were defined. In this case, we have to
+
+5
+00:00:10,600 --> 00:00:14,830
+go back to 1977, when Christopher Alexander, an American professor
+
+6
+00:00:14,830 --> 00:00:18,300
+of architecture at UC Berkeley, introduces the idea of patterns,
+
+7
+00:00:18,300 --> 00:00:21,700
+successful solutions to problems, in his book called a Pattern
+
+8
+00:00:21,700 --> 00:00:25,640
+Language. The book contains about 250 patterns. And the idea
+
+9
+00:00:25,640 --> 00:00:27,700
+is that occupants of a building should be able
+
+10
+00:00:27,700 --> 00:00:30,110
+to design it. And the patterns in the book provide
+
+11
+00:00:30,110 --> 00:00:32,368
+a way to do that. And this idea of design
+
+12
+00:00:32,368 --> 00:00:35,964
+patterns, so, a formal way of documenting successful solutions to
+
+13
+00:00:35,964 --> 00:00:41,200
+problems, inspired several other disciplines. In particular, in 1987,
+
+14
+00:00:41,200 --> 00:00:44,810
+Ward Cunningham and Kent Beck leveraged this idea of Alexander's
+
+15
+00:00:44,810 --> 00:00:48,360
+patterns in the context of an object oriented language.
+
+16
+00:00:48,360 --> 00:00:50,840
+And in this specific the language was Smalltalk.
+
+17
+00:00:50,840 --> 00:00:52,666
+Some of you might know the language. So what Cunningham
+
+18
+00:00:54,492 --> 00:00:56,320
+and Beck did, was to create a 5 pattern
+
+19
+00:00:56,320 --> 00:00:59,880
+language for guiding novice Smalltalk programmers. So they did
+
+20
+00:00:59,880 --> 00:01:03,090
+an experiment and had several developers using their patterns, and
+
+21
+00:01:03,090 --> 00:01:06,330
+the experiment was extremely successful. The users were able to
+
+22
+00:01:06,330 --> 00:01:09,940
+create elegant designs using the provided patterns. And in case
+
+23
+00:01:09,940 --> 00:01:12,210
+you are interested in reading about it, Cunningham and Beck
+
+24
+00:01:12,210 --> 00:01:15,660
+reported the results in the article, Using Pattern Languages for
+
+25
+00:01:15,660 --> 00:01:17,940
+Object Oriented Programs, which was published at the
+
+26
+00:01:17,940 --> 00:01:21,854
+International Conference on Object Oriented Programming, Systems, Languages, and
+
+27
+00:01:21,854 --> 00:01:25,390
+Applications, also called OOPSLA, in 1987. At the
+
+28
+00:01:25,390 --> 00:01:28,480
+same time, Eric Gamma was working on his dissertation,
+
+29
+00:01:28,480 --> 00:01:31,030
+whose topic was the importance of patterns and
+
+30
+00:01:31,030 --> 00:01:34,430
+how to capture them. Between 1987 and 1992, there
+
+31
+00:01:34,430 --> 00:01:37,520
+were several workshops related to design patterns. And
+
+32
+00:01:37,520 --> 00:01:40,740
+in 1992, Jim Coplien compiled a catalog of C++
+
+33
+00:01:40,740 --> 00:01:43,140
+items, which are some sort of patterns, and
+
+34
+00:01:43,140 --> 00:01:45,130
+he listed this catalog of patterns in his
+
+35
+00:01:45,130 --> 00:01:48,720
+book, which was titled Advanced C++ Programming Styles
+
+36
+00:01:48,720 --> 00:01:52,952
+and Idioms. Finally, in 1993 and 1994, there were
+
+37
+00:01:52,952 --> 00:01:56,160
+several additional workshops focused on patterns. And this
+
+38
+00:01:56,160 --> 00:01:59,625
+workshop brought together many patterns folks, including these
+
+39
+00:01:59,625 --> 00:02:03,040
+4 guys, Erich Gamma, Richard Helm, Ralph Johnson,
+
+40
+00:02:03,040 --> 00:02:06,040
+and John Vlissides. These guys are also known as
+
+41
+00:02:06,040 --> 00:02:08,970
+the gang of 4. And the result of this collaboration was the
+
+42
+00:02:08,970 --> 00:02:11,840
+famous book Design Patterns: Elements of
+
+43
+00:02:11,840 --> 00:02:14,320
+Reusable Object Oriented Software. So this
+
+44
+00:02:14,320 --> 00:02:17,640
+is basically The Book on design patterns. If you want to buy
+
+45
+00:02:17,640 --> 00:02:19,780
+a book on design pattern, this is the one you should get.
diff --git a/usth/ICT2.7/P3L3 Design Patterns Subtitles/3 - Patterns Catalogue - lang_en_vs4.srt b/usth/ICT2.7/P3L3 Design Patterns Subtitles/3 - Patterns Catalogue - lang_en_vs4.srt
new file mode 100644
index 0000000..764a309
--- /dev/null
+++ b/usth/ICT2.7/P3L3 Design Patterns Subtitles/3 - Patterns Catalogue - lang_en_vs4.srt	
@@ -0,0 +1,79 @@
+1
+00:00:00,230 --> 00:00:03,380
+This book contains a patterns catalog which is
+
+2
+00:00:03,380 --> 00:00:06,725
+a number of design patterns classified by purpose. And
+
+3
+00:00:06,725 --> 00:00:09,122
+there are five main classes of patterns. There are
+
+4
+00:00:09,122 --> 00:00:11,890
+fundamental patterns which are the basic patterns. There are
+
+5
+00:00:11,890 --> 00:00:15,170
+creational patterns which are the patterns that support object
+
+6
+00:00:15,170 --> 00:00:18,290
+creation. Then there are structural patterns and these are
+
+7
+00:00:18,290 --> 00:00:22,090
+patterns that help compose objects, put objects together. The
+
+8
+00:00:22,090 --> 00:00:25,280
+next class of patterns are behavioral patterns and these
+
+9
+00:00:25,280 --> 00:00:28,840
+are patterns that are mostly focused on realizing interactions
+
+10
+00:00:28,840 --> 00:00:32,820
+among different objects. Finally, there are concurrency patterns and these
+
+11
+00:00:32,820 --> 00:00:36,400
+are patterns that support, as the name says, concurrency, so
+
+12
+00:00:36,400 --> 00:00:39,700
+they're more related to concurrency aspects. And for each of
+
+13
+00:00:39,700 --> 00:00:43,560
+these classes there are a number of specific patterns, and
+
+14
+00:00:43,560 --> 00:00:46,130
+here I'm just listing some of them. Clearly we cannot
+
+15
+00:00:46,130 --> 00:00:48,740
+cover in one lesson all of these patterns, but what
+
+16
+00:00:48,740 --> 00:00:50,440
+I want to do is to cover at least a few
+
+17
+00:00:50,440 --> 00:00:52,670
+of those to give an idea of what patterns are and
+
+18
+00:00:52,670 --> 00:00:55,430
+how they can be used. In particular, we will see in
+
+19
+00:00:55,430 --> 00:00:59,200
+detail the Factory Method Pattern and the Strategy Pattern. And we
+
+20
+00:00:59,200 --> 00:01:01,590
+will also discuss a few more patterns at a higher level.
diff --git a/usth/ICT2.7/P3L3 Design Patterns Subtitles/4 - Pattern Format - lang_en_vs5.srt b/usth/ICT2.7/P3L3 Design Patterns Subtitles/4 - Pattern Format - lang_en_vs5.srt
new file mode 100644
index 0000000..7df86c0
--- /dev/null
+++ b/usth/ICT2.7/P3L3 Design Patterns Subtitles/4 - Pattern Format - lang_en_vs5.srt	
@@ -0,0 +1,71 @@
+1
+00:00:00,180 --> 00:00:02,711
+So let's start by seeing how patterns are defined. So
+
+2
+00:00:02,711 --> 00:00:05,620
+what is the format of the pattern definitions. If we look
+
+3
+00:00:05,620 --> 00:00:08,000
+at the Gang of Four's book we can see that these
+
+4
+00:00:08,000 --> 00:00:11,630
+definitions contain a lot of information. In fact, what I'm listing
+
+5
+00:00:11,630 --> 00:00:14,980
+here is just a subset of this information. In this lesson,
+
+6
+00:00:14,980 --> 00:00:17,510
+what I want to do is to focus on four essential
+
+7
+00:00:17,510 --> 00:00:21,480
+elements of a design pattern. It's name, the intent which is
+
+8
+00:00:21,480 --> 00:00:25,270
+the goal of the pattern. The pattern's applicability which is the
+
+9
+00:00:25,270 --> 00:00:28,040
+list of situations or context in which the
+
+10
+00:00:28,040 --> 00:00:31,560
+pattern is applicable. I also want to cover the structure
+
+11
+00:00:31,560 --> 00:00:34,700
+and participants. Which is the static model that describes
+
+12
+00:00:34,700 --> 00:00:37,870
+the elements, so normally the classes or the object
+
+13
+00:00:37,870 --> 00:00:39,900
+involved in the pattern. In addition to that
+
+14
+00:00:39,900 --> 00:00:41,400
+the structure also describes
+
+15
+00:00:41,400 --> 00:00:44,420
+the relationships, responsibilities and collaborations
+
+16
+00:00:44,420 --> 00:00:47,264
+among these classes or objects. Finally what I want
+
+17
+00:00:47,264 --> 00:00:50,560
+to cover is sample code. So examples that illustrate
+
+18
+00:00:50,560 --> 00:00:51,490
+the use of patterns.
diff --git a/usth/ICT2.7/P3L3 Design Patterns Subtitles/5 - Factory Method Pattern - lang_en_vs5.srt b/usth/ICT2.7/P3L3 Design Patterns Subtitles/5 - Factory Method Pattern - lang_en_vs5.srt
new file mode 100644
index 0000000..c7ebddd
--- /dev/null
+++ b/usth/ICT2.7/P3L3 Design Patterns Subtitles/5 - Factory Method Pattern - lang_en_vs5.srt	
@@ -0,0 +1,179 @@
+1
+00:00:00,012 --> 00:00:02,350
+Let's now look at the first design pattern that we
+
+2
+00:00:02,350 --> 00:00:05,700
+will discuss, the factory method pattern. And I'm going to start
+
+3
+00:00:05,700 --> 00:00:09,220
+by discussing the intent of the pattern and its applicability.
+
+4
+00:00:09,220 --> 00:00:12,210
+As far as the intent is concerned, the factory method pattern
+
+5
+00:00:12,210 --> 00:00:16,690
+allows for creating objects without specifying their class, by invoking
+
+6
+00:00:16,690 --> 00:00:19,370
+what we call a factory method. And what that is, is
+
+7
+00:00:19,370 --> 00:00:22,680
+a method whose main goal is to create class instances.
+
+8
+00:00:22,680 --> 00:00:25,510
+So when is this pattern useful? So when is it applicable?
+
+9
+00:00:25,510 --> 00:00:28,080
+For example, it is applicable in cases in which a class
+
+10
+00:00:28,080 --> 00:00:31,890
+cannot anticipate the type of object it must create. That is,
+
+11
+00:00:31,890 --> 00:00:34,800
+the type of an object is not known at compile time,
+
+12
+00:00:34,800 --> 00:00:37,800
+is not known until the code runs. A typical example of
+
+13
+00:00:37,800 --> 00:00:40,500
+this, are frameworks. So if you ever used a framework, you
+
+14
+00:00:40,500 --> 00:00:44,280
+will know that, normally, frameworks only know about interfaces and abstract
+
+15
+00:00:44,280 --> 00:00:47,450
+classes. So the exact type of the objects of these classes
+
+16
+00:00:47,450 --> 00:00:50,840
+is only known at runtime. The second case in which the factory
+
+17
+00:00:50,840 --> 00:00:53,835
+method pattern is applicable, is when a class wants its
+
+18
+00:00:53,835 --> 00:00:57,160
+subclasses to specify the type of objects it creates. And we'll
+
+19
+00:00:57,160 --> 00:00:59,920
+see an example of this in a minute. Finally, factory
+
+20
+00:00:59,920 --> 00:01:03,580
+method patterns are applicable when a class needs control over the
+
+21
+00:01:03,580 --> 00:01:06,760
+creation of its objects. And in this case, one possible
+
+22
+00:01:06,760 --> 00:01:09,380
+example is when there is a limit on the number of
+
+23
+00:01:09,380 --> 00:01:12,930
+objects that can be created. Special example, it's a singleton. If
+
+24
+00:01:12,930 --> 00:01:15,840
+you're familiar with a singleton, a singleton is a class for
+
+25
+00:01:15,840 --> 00:01:18,930
+which only one instance can be created. The factory method pattern
+
+26
+00:01:18,930 --> 00:01:21,760
+is perfect in these cases, because it allows to control how many
+
+27
+00:01:21,760 --> 00:01:24,640
+objects get created. So in this case, it would allow the creation
+
+28
+00:01:24,640 --> 00:01:27,290
+only of a single object. And from the second time that it
+
+29
+00:01:27,290 --> 00:01:30,040
+is invoked, it will just return the object that was previously
+
+30
+00:01:30,040 --> 00:01:33,700
+created. Now let's go ahead and see how this pattern actually works,
+
+31
+00:01:33,700 --> 00:01:37,100
+and let's do that by discussing the structure and the participants for
+
+32
+00:01:37,100 --> 00:01:41,330
+the pattern. The structure that is represented here, using the UML notation,
+
+33
+00:01:41,330 --> 00:01:45,530
+includes three classes, the Creator, the ConcreteCreator,
+
+34
+00:01:45,530 --> 00:01:48,000
+and the Product. The Creator provides the
+
+35
+00:01:48,000 --> 00:01:50,710
+interface for the factory method. So this
+
+36
+00:01:50,710 --> 00:01:53,200
+here, is the interface for the factory method
+
+37
+00:01:53,200 --> 00:01:55,950
+that, when invoked, returns an object of
+
+38
+00:01:55,950 --> 00:01:59,440
+type Product. The ConcreteCreator provides the actual
+
+39
+00:01:59,440 --> 00:02:02,350
+method for creating the Product. So this
+
+40
+00:02:02,350 --> 00:02:06,170
+method is a concrete implementation of this interface.
+
+41
+00:02:06,170 --> 00:02:10,630
+Finally, the Product is the object created by the factory method. So
+
+42
+00:02:10,630 --> 00:02:12,350
+summarizing, we have the interface for
+
+43
+00:02:12,350 --> 00:02:14,300
+the factory method, the actual implementation of
+
+44
+00:02:14,300 --> 00:02:17,540
+the summary method, and the object that is created by the factory method,
+
+45
+00:02:17,540 --> 00:02:21,020
+when it is invoked. So let's look at an example of this pattern.
diff --git a/usth/ICT2.7/P3L3 Design Patterns Subtitles/6 - Factory Method Pattern Example - lang_en_vs5.srt b/usth/ICT2.7/P3L3 Design Patterns Subtitles/6 - Factory Method Pattern Example - lang_en_vs5.srt
new file mode 100644
index 0000000..2812c39
--- /dev/null
+++ b/usth/ICT2.7/P3L3 Design Patterns Subtitles/6 - Factory Method Pattern Example - lang_en_vs5.srt	
@@ -0,0 +1,127 @@
+1
+00:00:00,220 --> 00:00:03,260
+The example I'm going to use consists of a class called
+
+2
+00:00:03,260 --> 00:00:07,380
+ImageReaderFactory which provides the factory method which is this one;
+
+3
+00:00:07,380 --> 00:00:10,250
+createImageReader. As you can see the method takes an InputStream
+
+4
+00:00:10,250 --> 00:00:13,570
+as input and returns an object of type ImageReader, and it's
+
+5
+00:00:13,570 --> 00:00:15,645
+static so that we can invoke it even if we
+
+6
+00:00:15,645 --> 00:00:18,390
+don't have an instance of the ImageReaderFactory. So what does the
+
+7
+00:00:18,390 --> 00:00:22,275
+method do? Well the method first invokes, getImageType, passing the
+
+8
+00:00:22,275 --> 00:00:25,780
+InputStream as a parameter and this method figures out the type
+
+9
+00:00:25,780 --> 00:00:28,820
+of the image that is stored in this Inputstream and it's
+
+10
+00:00:28,820 --> 00:00:32,740
+an integer. Then, based on the value of this integer, the
+
+11
+00:00:32,740 --> 00:00:35,352
+method does one of several things. If the image type is
+
+12
+00:00:35,352 --> 00:00:38,970
+a GIF, it will invoke the constructor for GifReader passing the
+
+13
+00:00:38,970 --> 00:00:41,610
+stream as a parameter. And what will happen is that the
+
+14
+00:00:41,610 --> 00:00:44,450
+GIF reader will read a GIF from the stream, create a
+
+15
+00:00:44,450 --> 00:00:47,887
+corresponding object and return it. So in this case, the ImageReader
+
+16
+00:00:47,887 --> 00:00:51,460
+object return will be the object representing a GIF as appropriate.
+
+17
+00:00:51,460 --> 00:00:54,610
+Similarly, if the image type is JPEG, then the method will
+
+18
+00:00:54,610 --> 00:00:58,579
+invoke the constructor for JPEG Reader and in this case, this constructor
+
+19
+00:00:58,579 --> 00:01:01,981
+will read from the stream a JPEG, create a corresponding object
+
+20
+00:01:01,981 --> 00:01:05,640
+and return it. And so on for different types of images. So
+
+21
+00:01:05,640 --> 00:01:07,880
+why is this a situation in which it is appropriate to
+
+22
+00:01:07,880 --> 00:01:11,100
+use the factory method pattern? One, because it corresponds exactly to the
+
+23
+00:01:11,100 --> 00:01:14,250
+cases that we saw before, of applicability. This is a case
+
+24
+00:01:14,250 --> 00:01:16,560
+in which we don't know the type of the object that we
+
+25
+00:01:16,560 --> 00:01:20,080
+need to create until we run the code, because it depends
+
+26
+00:01:20,080 --> 00:01:22,530
+on the value of the InputStream. It depends on the content
+
+27
+00:01:22,530 --> 00:01:25,590
+of the InputStream. So, until we read the InputStream, we cannot
+
+28
+00:01:25,590 --> 00:01:28,380
+figure out whether we need to create a GIF, a JPEG or
+
+29
+00:01:28,380 --> 00:01:30,780
+some other type of image. So in this case, we want to
+
+30
+00:01:30,780 --> 00:01:33,630
+do, we want to simply delegate to this classes the creation of
+
+31
+00:01:33,630 --> 00:01:35,610
+the object, once we know what type of object needs to
+
+32
+00:01:35,610 --> 00:01:38,790
+be created. So perfect example of application of a factory method pattern.
diff --git a/usth/ICT2.7/P3L3 Design Patterns Subtitles/7 - Strategy Pattern - lang_en_vs5.srt b/usth/ICT2.7/P3L3 Design Patterns Subtitles/7 - Strategy Pattern - lang_en_vs5.srt
new file mode 100644
index 0000000..288b8d6
--- /dev/null
+++ b/usth/ICT2.7/P3L3 Design Patterns Subtitles/7 - Strategy Pattern - lang_en_vs5.srt	
@@ -0,0 +1,143 @@
+1
+00:00:00,230 --> 00:00:02,110
+The second pattern I want to discuss is the
+
+2
+00:00:02,110 --> 00:00:05,050
+strategy pattern, which provides a way to configure a
+
+3
+00:00:05,050 --> 00:00:07,900
+class with one of many behaviors. What does that
+
+4
+00:00:07,900 --> 00:00:11,040
+mean? Well, more precisely, this pattern allows for defining
+
+5
+00:00:11,040 --> 00:00:15,330
+a family of algorithms, encapsulating them into separate classes,
+
+6
+00:00:15,330 --> 00:00:17,900
+so each algorithm in one class, and making these
+
+7
+00:00:17,900 --> 00:00:21,490
+classes interchangeable, but providing a common interface for all
+
+8
+00:00:21,490 --> 00:00:25,350
+the encapsulated algorithms. So in essence, the intent of
+
+9
+00:00:25,350 --> 00:00:29,250
+a strategy pattern is to allow for switching between
+
+10
+00:00:29,250 --> 00:00:33,490
+different algorithms for accomplishing a given task. For example, imagine
+
+11
+00:00:33,490 --> 00:00:36,610
+having different sorting algorithms with different space or time
+
+12
+00:00:36,610 --> 00:00:38,800
+tradeoffs. You might want to be able to have them
+
+13
+00:00:38,800 --> 00:00:42,670
+all available and use different ones in different situations.
+
+14
+00:00:42,670 --> 00:00:44,820
+And this pattern is applicable not only when we have
+
+15
+00:00:44,820 --> 00:00:47,260
+different variants of an algorithm, but also when we
+
+16
+00:00:47,260 --> 00:00:51,690
+have many related classes that differ only in their behavior.
+
+17
+00:00:51,690 --> 00:00:53,640
+So let's get more concrete and see how this is
+
+18
+00:00:53,640 --> 00:00:55,960
+done. And I'm going to do it as before, by
+
+19
+00:00:55,960 --> 00:00:59,700
+discussing the structure and the participants for this strategy pattern.
+
+20
+00:00:59,700 --> 00:01:02,540
+In this case, we have 3 types of participants for this
+
+21
+00:01:02,540 --> 00:01:07,210
+pattern, the context, the algorithm, and the concrete strategies. There
+
+22
+00:01:07,210 --> 00:01:09,580
+can be as many as the number of behaviors that
+
+23
+00:01:09,580 --> 00:01:12,300
+I need to implement. So, let's see what those are.
+
+24
+00:01:12,300 --> 00:01:16,690
+The context is the interface to the outside world. It maintains
+
+25
+00:01:16,690 --> 00:01:19,180
+a reference to the current algorithm and allows for
+
+26
+00:01:19,180 --> 00:01:22,860
+updating this reference at run time. So, basically the outside
+
+27
+00:01:22,860 --> 00:01:26,370
+world will invoke the functionality provided by the different algorithms,
+
+28
+00:01:26,370 --> 00:01:29,170
+by using this interface. And depending on which algorithm is
+
+29
+00:01:29,170 --> 00:01:31,640
+currently selected, that's the one that will be executed when
+
+30
+00:01:31,640 --> 00:01:35,920
+the functionality is involved. The algorithm, also called the strategy,
+
+31
+00:01:35,920 --> 00:01:37,970
+so that's where the pattern gets its name, Is the
+
+32
+00:01:37,970 --> 00:01:42,130
+common interface for the different algorithims. So all the algorithms
+
+33
+00:01:42,130 --> 00:01:46,690
+implement this interface. Finally, the concrete strategies are the
+
+34
+00:01:46,690 --> 00:01:49,920
+actual implementations of the algorithms. So if I have 10
+
+35
+00:01:49,920 --> 00:01:53,030
+different variants of my algorithm, I will implement 10 different
+
+36
+00:01:53,030 --> 00:01:56,550
+concrete strategies. They will all be implementations of this interface.
diff --git a/usth/ICT2.7/P3L3 Design Patterns Subtitles/8 - Strategy Pattern Example & Demo - lang_en_vs5.srt b/usth/ICT2.7/P3L3 Design Patterns Subtitles/8 - Strategy Pattern Example & Demo - lang_en_vs5.srt
new file mode 100644
index 0000000..6d298d0
--- /dev/null
+++ b/usth/ICT2.7/P3L3 Design Patterns Subtitles/8 - Strategy Pattern Example & Demo - lang_en_vs5.srt	
@@ -0,0 +1,511 @@
+1
+00:00:00,130 --> 00:00:03,320
+Now let's see how this whole thing works in practice by
+
+2
+00:00:03,320 --> 00:00:06,800
+using an example. We're going to consider a program that takes as
+
+3
+00:00:06,800 --> 00:00:10,450
+input a text file and produce it as output, a filtered
+
+4
+00:00:10,450 --> 00:00:14,170
+file. So basically it outputs a subset of the content of
+
+5
+00:00:14,170 --> 00:00:16,928
+this text file based on some filter. And we're going to have
+
+6
+00:00:16,928 --> 00:00:19,440
+four different types of filters. So the first one is
+
+7
+00:00:19,440 --> 00:00:21,680
+not filtering which means that the whole content of the text
+
+8
+00:00:21,680 --> 00:00:25,320
+file will be produced on the output. The second filter will output
+
+9
+00:00:25,320 --> 00:00:27,990
+only words that starts with t. So you'll take the text file
+
+10
+00:00:27,990 --> 00:00:30,540
+and simply ignore all of the words that do not start with
+
+11
+00:00:30,540 --> 00:00:33,130
+t. So in the output we'll have only those words that starts
+
+12
+00:00:33,130 --> 00:00:36,030
+with letter t. The third filter will produce in the output only
+
+13
+00:00:36,030 --> 00:00:39,180
+words that are longer than five characters. So all the other words
+
+14
+00:00:39,180 --> 00:00:43,740
+will be simply disregarded. And finally, the four filter will produce as
+
+15
+00:00:43,740 --> 00:00:47,630
+output only words in the text file that are palindromes, and in
+
+16
+00:00:47,630 --> 00:00:50,590
+case you don't know what a palindrome is, a palindrome is a word
+
+17
+00:00:50,590 --> 00:00:52,700
+that is the same whether you read it from left
+
+18
+00:00:52,700 --> 00:00:55,800
+to right or from right to left. For example, the
+
+19
+00:00:55,800 --> 00:00:58,480
+word kayak, you can read it in this direction, or
+
+20
+00:00:58,480 --> 00:01:00,740
+in this direction, and it's exactly the same word. So
+
+21
+00:01:00,740 --> 00:01:03,560
+let's see how this program could be implemented using a
+
+22
+00:01:03,560 --> 00:01:05,980
+strategy pattern. And let's do it for real as a
+
+23
+00:01:05,980 --> 00:01:10,100
+demo. What we're looking at here is the editor page
+
+24
+00:01:10,100 --> 00:01:15,520
+for Eclipse, open with the strategy pattern implementation for our example.
+
+25
+00:01:15,520 --> 00:01:17,130
+So what I'm going to do is that, I'm going to look at a
+
+26
+00:01:17,130 --> 00:01:20,310
+different part of implementation. And you will see that, you know, despite
+
+27
+00:01:20,310 --> 00:01:23,420
+the fact that it's slightly longer, it's really fairly simple, it's kind
+
+28
+00:01:23,420 --> 00:01:26,230
+of a straightforward implementation of what we just saw. As I just
+
+29
+00:01:26,230 --> 00:01:29,820
+said, what we are doing is basically building the strategy patterns that
+
+30
+00:01:29,820 --> 00:01:34,330
+allows for changing the strategies with which we're filtering an input file.
+
+31
+00:01:34,330 --> 00:01:37,380
+And we have different strategies, we'll look at those in detail, and
+
+32
+00:01:37,380 --> 00:01:41,050
+we said that the three participants for this pattern are the context,
+
+33
+00:01:41,050 --> 00:01:43,650
+the algorithm, which is the general interface and then the concrete
+
+34
+00:01:43,650 --> 00:01:47,270
+strategies, which are the concrete implementations of this algorithm. So let's
+
+35
+00:01:47,270 --> 00:01:49,790
+start by looking at the context. Which is this class here.
+
+36
+00:01:49,790 --> 00:01:52,960
+And as you can see it contains a reference at the current
+
+37
+00:01:52,960 --> 00:01:56,240
+strategy. We call this the check strategy, which is basically our
+
+38
+00:01:56,240 --> 00:01:59,910
+filter, and when the context is created by default it sets a
+
+39
+00:01:59,910 --> 00:02:02,890
+strategy to the old strategy. The old strategy is the one
+
+40
+00:02:02,890 --> 00:02:06,380
+that accepts all the input, so basically it doesn't filter out anything.
+
+41
+00:02:06,380 --> 00:02:08,320
+And we said that the context is the interface to the
+
+42
+00:02:08,320 --> 00:02:10,889
+outside world, right? So it has to provide the outside world
+
+43
+00:02:10,889 --> 00:02:14,140
+with a way of selecting the strategy, the specific algorithm to
+
+44
+00:02:14,140 --> 00:02:16,850
+be used, and it does that in this case by providing
+
+45
+00:02:16,850 --> 00:02:21,360
+this change strategy method. This method takes a strategy as input,
+
+46
+00:02:21,360 --> 00:02:24,930
+and simply replaces the current strategy with the one specified as
+
+47
+00:02:24,930 --> 00:02:28,035
+a parameter. And at this point, the context also will perform
+
+48
+00:02:28,035 --> 00:02:31,830
+the filtering. The filtering is pretty straightforward, so what it does is
+
+49
+00:02:31,830 --> 00:02:34,620
+that it opens a file that is passed as a parameter
+
+50
+00:02:34,620 --> 00:02:37,450
+so that this the file, the input file to be filtered. And
+
+51
+00:02:37,450 --> 00:02:40,560
+then it reads the file line by line and then splits
+
+52
+00:02:40,560 --> 00:02:43,620
+the lines into its composing words and then for each word in
+
+53
+00:02:43,620 --> 00:02:46,480
+each line, what it will do, it will basically invoke the
+
+54
+00:02:46,480 --> 00:02:50,270
+check method in the current strategy, which is basically the filtering method
+
+55
+00:02:50,270 --> 00:02:53,580
+and if the check method returns true, which basically means that
+
+56
+00:02:53,580 --> 00:02:57,150
+the word should be printed, it prints the word. Otherwise, it'll just
+
+57
+00:02:57,150 --> 00:03:00,480
+skip it. So basically the filter will return false for all the
+
+58
+00:03:00,480 --> 00:03:03,470
+words that have to be filtered out. Okay? This is the basic
+
+59
+00:03:03,470 --> 00:03:06,770
+way in which context works. Let's see how this is used in
+
+60
+00:03:06,770 --> 00:03:10,660
+our main method. The main method simply creates the context, reads the input file
+
+61
+00:03:10,660 --> 00:03:12,910
+from the arguments, and then what he does is simply as a
+
+62
+00:03:12,910 --> 00:03:16,720
+demonstration, it will perform the filtering using all the different filters. So
+
+63
+00:03:16,720 --> 00:03:19,310
+starting from the default one, which is the one that basically doesn't
+
+64
+00:03:19,310 --> 00:03:22,150
+do any filtering that reports all words, then it will switch to the
+
+65
+00:03:22,150 --> 00:03:25,400
+algorithm, that only considers the words that start with t, and
+
+66
+00:03:25,400 --> 00:03:28,880
+it will do that by invoking a change strategy and passing this
+
+67
+00:03:28,880 --> 00:03:30,890
+strategy as the argument, and then
+
+68
+00:03:30,890 --> 00:03:32,760
+performing the actual filtering through context.
+
+69
+00:03:32,760 --> 00:03:35,040
+And it will do exactly the same for the strategy that only
+
+70
+00:03:35,040 --> 00:03:37,540
+prints words that are longer than five and the one that
+
+71
+00:03:37,540 --> 00:03:40,460
+only prints words that are palindromes. So now let's look at the
+
+72
+00:03:40,460 --> 00:03:44,090
+actual algorithm. This is the interface, the algorithm interface. And you can
+
+73
+00:03:44,090 --> 00:03:47,080
+see that the only thing that the interface provides is this method,
+
+74
+00:03:47,080 --> 00:03:49,760
+which is the check method, that takes a string as input and will
+
+75
+00:03:49,760 --> 00:03:52,470
+return a boolean. So, basically, it's the boolean that we were seeing before.
+
+76
+00:03:52,470 --> 00:03:55,010
+The one that is true for the words that have to be printed
+
+77
+00:03:55,010 --> 00:03:57,490
+and false for the ones that have to be filtered out. Now, we have
+
+78
+00:03:57,490 --> 00:04:01,250
+all the different implementations of the algorithm, the simplest one is the all
+
+79
+00:04:01,250 --> 00:04:05,110
+algorithm, the simple return is always true, so all the words will be printed.
+
+80
+00:04:05,110 --> 00:04:08,740
+The second one starts with t, and again, without looking at the details
+
+81
+00:04:08,740 --> 00:04:10,660
+of implementations that don't really matter, what
+
+82
+00:04:10,660 --> 00:04:12,390
+it does is basically check that
+
+83
+00:04:12,390 --> 00:04:15,111
+the first character is t, and returns true in that case and
+
+84
+00:04:15,111 --> 00:04:17,720
+false otherwise. Similarly, for the LongerThan5
+
+85
+00:04:17,720 --> 00:04:19,380
+algorithm, also in this case, this
+
+86
+00:04:19,380 --> 00:04:23,000
+will implement the check strategy interface, and the check will be performed
+
+87
+00:04:23,000 --> 00:04:25,980
+by checking that the word is longer than five characters and returning
+
+88
+00:04:25,980 --> 00:04:29,440
+true in that case and false otherwise. And finally the Palindrome check
+
+89
+00:04:29,440 --> 00:04:32,240
+is a little more complicated, but basically it just checks whether the
+
+90
+00:04:32,240 --> 00:04:35,190
+word is a Palindrome and returns true in that case. Okay, so
+
+91
+00:04:35,190 --> 00:04:37,950
+as I said, it doesn't really matter too much what is the specific
+
+92
+00:04:37,950 --> 00:04:40,630
+implementations of these matters. What matters is that we have
+
+93
+00:04:40,630 --> 00:04:44,150
+a general interface for the algorithm and then any different concrete
+
+94
+00:04:44,150 --> 00:04:48,130
+implementations of the algorithm that implement different strategies. So again,
+
+95
+00:04:48,130 --> 00:04:50,730
+this allows you to change the behavior of your class without
+
+96
+00:04:50,730 --> 00:04:53,420
+changing class. So we have this context class that does
+
+97
+00:04:53,420 --> 00:04:57,015
+different things when the filter method in invoked, depending on what
+
+98
+00:04:57,015 --> 00:04:59,930
+is the current strategy. So the behavior of the class can
+
+99
+00:04:59,930 --> 00:05:03,310
+change dynamically, and it changes dynamically every time that we change
+
+100
+00:05:03,310 --> 00:05:06,300
+the strategy. At this point, the way this whole thing works should
+
+101
+00:05:06,300 --> 00:05:08,430
+be clear, so what we're going to do is that we're going to go to
+
+102
+00:05:08,430 --> 00:05:12,010
+our console, and we're actually going to run the strategy pattern and see
+
+103
+00:05:12,010 --> 00:05:15,710
+what happens. So here I have a file, it's called foo.txt. And if
+
+104
+00:05:15,710 --> 00:05:18,290
+we look at the content of foo, you can see that it
+
+105
+00:05:18,290 --> 00:05:21,190
+says that this is just a test to assess how well this program
+
+106
+00:05:21,190 --> 00:05:24,430
+performs when used on files of text. And since it checks for
+
+107
+00:05:24,430 --> 00:05:28,560
+palindromes, we will also insert one such word, level. Level is a palindrome,
+
+108
+00:05:28,560 --> 00:05:31,042
+because you can read it from both sides. Okay, so let's
+
+109
+00:05:31,042 --> 00:05:33,657
+see what happens when we run our code. So we're going to
+
+110
+00:05:33,657 --> 00:05:36,900
+run java pattern.strategy.StrategyPattern which is
+
+111
+00:05:36,900 --> 00:05:38,550
+our class, and we going to fetch
+
+112
+00:05:38,550 --> 00:05:41,460
+foo.txt as an input, and let's go back to the beginning
+
+113
+00:05:41,460 --> 00:05:43,980
+of the output to see what happened exactly. You can see
+
+114
+00:05:43,980 --> 00:05:48,040
+here that for the default strategy, which was the old strategy,
+
+115
+00:05:48,040 --> 00:05:50,810
+the whole file is printed, so every word is printed. This
+
+116
+00:05:50,810 --> 00:05:53,485
+is just a test to assess and so on and so forth,
+
+117
+00:05:53,485 --> 00:05:57,290
+as expected. For the filter that only prints words that
+
+118
+00:05:57,290 --> 00:06:00,230
+start with t, only words that start with t are printed,
+
+119
+00:06:00,230 --> 00:06:04,180
+again, as expected. Similarly, for the filter that only prints words
+
+120
+00:06:04,180 --> 00:06:06,970
+that are longer than 5, and finally for the one that prints
+
+121
+00:06:06,970 --> 00:06:09,540
+palindromes. And here you can see that we actually have two
+
+122
+00:06:09,540 --> 00:06:12,410
+because the way in which this is implemented we'll also consider
+
+123
+00:06:12,410 --> 00:06:15,300
+single letter words as palindromes because you can read them from
+
+124
+00:06:15,300 --> 00:06:18,450
+both sides. But you definitely will also have level in the output.
+
+125
+00:06:18,450 --> 00:06:21,040
+And in case you want to play with this code yourself, I
+
+126
+00:06:21,040 --> 00:06:24,600
+have made this code and also the implementation for examples of other
+
+127
+00:06:24,600 --> 00:06:28,440
+design partners available as a compressed archive. And the archive is accessible
+
+128
+00:06:28,440 --> 00:06:31,120
+through a URL that is provided in the notes for the cost.
diff --git a/usth/ICT2.7/P3L3 Design Patterns Subtitles/9 - Other Common Patterns - lang_en_vs5.srt b/usth/ICT2.7/P3L3 Design Patterns Subtitles/9 - Other Common Patterns - lang_en_vs5.srt
new file mode 100644
index 0000000..756f38f
--- /dev/null
+++ b/usth/ICT2.7/P3L3 Design Patterns Subtitles/9 - Other Common Patterns - lang_en_vs5.srt	
@@ -0,0 +1,295 @@
+1
+00:00:00,060 --> 00:00:03,460
+Before concluding this lesson, let's look at a few more patterns. And
+
+2
+00:00:03,460 --> 00:00:05,880
+although it will take too long to cover them in detail, I
+
+3
+00:00:05,880 --> 00:00:08,986
+would like to at least mention and quickly discuss a few more
+
+4
+00:00:08,986 --> 00:00:12,080
+of these more commonly-used patterns. In fact, some of the patterns that
+
+5
+00:00:12,080 --> 00:00:15,400
+I will discuss, you might have used yourself. Maybe without knowing their
+
+6
+00:00:15,400 --> 00:00:18,300
+name or the fact that they were design patterns. So let's start
+
+7
+00:00:18,300 --> 00:00:21,660
+with a Visitor pattern, which is a way of separating an algorithm
+
+8
+00:00:21,660 --> 00:00:25,150
+from an object structure on which it operates. And a practical result
+
+9
+00:00:25,150 --> 00:00:28,010
+of this separation is the ability to add the new operation
+
+10
+00:00:28,010 --> 00:00:31,680
+to exist in object structures, without modifying the structures. So, basically
+
+11
+00:00:31,680 --> 00:00:34,540
+what this pattern does, is to allow for defining and easily
+
+12
+00:00:34,540 --> 00:00:37,870
+modifying set of operations to perform on the objects of the collection.
+
+13
+00:00:37,870 --> 00:00:40,570
+And the typical usage of this is, for example, when you're
+
+14
+00:00:40,570 --> 00:00:43,140
+visiting a graph, or a set of objects, and you want
+
+15
+00:00:43,140 --> 00:00:46,090
+to perform some operations on these objects. By using a visitor
+
+16
+00:00:46,090 --> 00:00:48,410
+pattern, you can decouple the operation
+
+17
+00:00:48,410 --> 00:00:50,830
+from the objects. Although not straightforward,
+
+18
+00:00:50,830 --> 00:00:53,360
+this pattern is very, very useful. So, I really encourage you
+
+19
+00:00:53,360 --> 00:00:56,060
+to look at it in more detail and get familiar with it.
+
+20
+00:00:56,060 --> 00:00:59,040
+The second pattern I want to mention is the decorator pattern.
+
+21
+00:00:59,040 --> 00:01:02,820
+The decorator pattern is basically a wrapper that adds functionality to a
+
+22
+00:01:02,820 --> 00:01:05,030
+class. So the way in which it works, is that you
+
+23
+00:01:05,030 --> 00:01:08,230
+will take a class, you will build a class that basically wraps
+
+24
+00:01:08,230 --> 00:01:12,250
+this class. So it reproduces the functionality of the original class, but
+
+25
+00:01:12,250 --> 00:01:15,900
+it also adds some functionality. And for all the functionality that was
+
+26
+00:01:15,900 --> 00:01:18,750
+already in the original class, it will simply invoke this
+
+27
+00:01:18,750 --> 00:01:21,080
+functionality and for the new one, you will implement it
+
+28
+00:01:21,080 --> 00:01:24,510
+using the services of the class. And a nice property
+
+29
+00:01:24,510 --> 00:01:26,760
+of the decorator pattern is that it's stackable. So you can
+
+30
+00:01:26,760 --> 00:01:30,210
+add decorators on decorators on decorators, and further increase the
+
+31
+00:01:30,210 --> 00:01:34,052
+functionality provided by your class. The iterator is another very
+
+32
+00:01:34,052 --> 00:01:37,810
+commonly-used pattern. And, you probably use this one yourself because,
+
+33
+00:01:37,810 --> 00:01:41,090
+it's also part of many standard libraries. What the iterator allows
+
+34
+00:01:41,090 --> 00:01:44,220
+you to do, is basically to access elements of a collection
+
+35
+00:01:44,220 --> 00:01:47,490
+without knowing the underlying representation. So the iterator will allow you
+
+36
+00:01:47,490 --> 00:01:50,630
+to just go through a set of objects without worrying about
+
+37
+00:01:50,630 --> 00:01:53,200
+how the objects are stored. So you basically just ask the
+
+38
+00:01:53,200 --> 00:01:55,810
+iterator to give you the first object, the next object and
+
+39
+00:01:55,810 --> 00:02:00,130
+so on. Another very commonly-used pattern is the observer pattern. And
+
+40
+00:02:00,130 --> 00:02:02,650
+this pattern is very useful when you have an object of
+
+41
+00:02:02,650 --> 00:02:06,190
+interest and a set of other objects that are interested in
+
+42
+00:02:06,190 --> 00:02:09,240
+the changes that might occur in this first object. So
+
+43
+00:02:09,240 --> 00:02:12,690
+what the observer pattern allows you to do is to register
+
+44
+00:02:12,690 --> 00:02:15,460
+these objects, so that they let the system know that
+
+45
+00:02:15,460 --> 00:02:18,690
+they're interested in changes in this first object. And then, every
+
+46
+00:02:18,690 --> 00:02:20,840
+time that there is a change, these other objects will
+
+47
+00:02:20,840 --> 00:02:23,030
+be automatically notified. So basically,
+
+48
+00:02:23,030 --> 00:02:25,290
+the observer pattern allows for notifying
+
+49
+00:02:25,290 --> 00:02:29,310
+dependents when an object of interest changes. If you want
+
+50
+00:02:29,310 --> 00:02:32,020
+an example of this, just think about the file system and
+
+51
+00:02:32,020 --> 00:02:35,870
+imagine having a folder. All the views of this folder will
+
+52
+00:02:35,870 --> 00:02:37,970
+want to be notified every time that there's a change in
+
+53
+00:02:37,970 --> 00:02:40,720
+the folder because they need to refresh. So instead of continuously
+
+54
+00:02:40,720 --> 00:02:44,390
+checking the state of the folder, they will just register and basically
+
+55
+00:02:44,390 --> 00:02:47,430
+say, hey, we're interested in knowing when something changes in this
+
+56
+00:02:47,430 --> 00:02:50,320
+folder. And when something changes in the folder, they will be automatically
+
+57
+00:02:50,320 --> 00:02:53,300
+notified. So it will be some sort of a push notification
+
+58
+00:02:53,300 --> 00:02:56,590
+instead of a pull notification, if you are familiar with that terminology.
+
+59
+00:02:56,590 --> 00:03:00,020
+Finally the proxy pattern is a pattern in which a surrogate
+
+60
+00:03:00,020 --> 00:03:04,370
+controls access to an object. In other words, we have our object,
+
+61
+00:03:04,370 --> 00:03:07,220
+and we have our proxy here. So all the requests to the
+
+62
+00:03:07,220 --> 00:03:09,950
+object will go through the proxy that will then forward them. And
+
+63
+00:03:09,950 --> 00:03:12,020
+all the responses from the object will also go through the
+
+64
+00:03:12,020 --> 00:03:15,580
+proxy. They will then forward them to the original requester. So what
+
+65
+00:03:15,580 --> 00:03:18,710
+the proxy allows you to do is to control how this object,
+
+66
+00:03:18,710 --> 00:03:22,180
+that is behind the proxy, is actually accessed, for example, by filtering
+
+67
+00:03:22,180 --> 00:03:24,500
+some calls. So in a sense, the proxy allows use
+
+68
+00:03:24,500 --> 00:03:27,470
+for masking some of the functionality of the object that
+
+69
+00:03:27,470 --> 00:03:31,070
+is behind the proxy. And there's many, many, many more
+
+70
+00:03:31,070 --> 00:03:34,424
+useful patterns. That can help you when designing and implementing
+
+71
+00:03:34,424 --> 00:03:37,220
+the system. So once more, I really encourage you to
+
+72
+00:03:37,220 --> 00:03:38,740
+have a look at the book, to look at the
+
+73
+00:03:38,740 --> 00:03:41,570
+resources online, and to really get more familiar with these
+
+74
+00:03:41,570 --> 00:03:43,890
+patterns, and to try to use them in your everyday work.
diff --git a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/1 - Lesson Overview - lang_en_vs4.srt b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/1 - Lesson Overview - lang_en_vs4.srt
new file mode 100644
index 0000000..4abf070
--- /dev/null
+++ b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/1 - Lesson Overview - lang_en_vs4.srt	
@@ -0,0 +1,31 @@
+1
+00:00:00,770 --> 00:00:02,830
+In the previous lessons of this mini-course,
+
+2
+00:00:02,830 --> 00:00:06,620
+we discussed high level design, or architecture,
+
+3
+00:00:06,620 --> 00:00:12,380
+low level design, and design patterns. Now, we're going to see how we can put
+
+4
+00:00:12,380 --> 00:00:15,380
+this and also others software engineering activities
+
+5
+00:00:15,380 --> 00:00:18,436
+together in the context of a UML-based
+
+6
+00:00:18,436 --> 00:00:21,820
+process model, the unified software process, or
+
+7
+00:00:21,820 --> 00:00:25,580
+USP. We will discuss how USP was defined,
+
+8
+00:00:25,580 --> 00:00:30,492
+its main characteristics, its phases, and how we can apply it in practice.
diff --git a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/10 - Iterative and Incremental - lang_en_vs6.srt b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/10 - Iterative and Incremental - lang_en_vs6.srt
new file mode 100644
index 0000000..e542660
--- /dev/null
+++ b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/10 - Iterative and Incremental - lang_en_vs6.srt	
@@ -0,0 +1,147 @@
+1
+00:00:00,190 --> 00:00:03,100
+We just saw two of the three distinguishing aspects of
+
+2
+00:00:03,100 --> 00:00:05,800
+the rational unified process. The fact that it is used
+
+3
+00:00:05,800 --> 00:00:08,810
+case driven and the fact that it is architecture centric.
+
+4
+00:00:08,810 --> 00:00:11,950
+The third and final distinguished aspect of R.U.P. is that
+
+5
+00:00:11,950 --> 00:00:15,210
+it is iterative and incremental. So let's see what that
+
+6
+00:00:15,210 --> 00:00:18,870
+means by considering the lifetime of a software project. Basically,
+
+7
+00:00:18,870 --> 00:00:22,120
+the lifetime of a rational unified process consists of a
+
+8
+00:00:22,120 --> 00:00:24,920
+series of cycles, such as the ones that are represented here.
+
+9
+00:00:24,920 --> 00:00:28,070
+Cycle one, cycle two, through cycle n. And as
+
+10
+00:00:28,070 --> 00:00:30,990
+you can see, these cycles can also be called increments.
+
+11
+00:00:30,990 --> 00:00:33,280
+And each one of the cycles involves all of
+
+12
+00:00:33,280 --> 00:00:36,700
+the main phases of software development. In addition, each cycle
+
+13
+00:00:36,700 --> 00:00:39,700
+results in a product release which can be internal
+
+14
+00:00:39,700 --> 00:00:43,210
+or external. More precisely, each cycle terminates with a product
+
+15
+00:00:43,210 --> 00:00:46,340
+release that includes a complete set of artifacts for
+
+16
+00:00:46,340 --> 00:00:50,150
+the project. That means code, manuals, use cases, non-functional
+
+17
+00:00:50,150 --> 00:00:52,840
+specification, test cases, and so on. So, I've just
+
+18
+00:00:52,840 --> 00:00:55,760
+said, that each cycle involves all of the main phases
+
+19
+00:00:55,760 --> 00:00:59,440
+of software development. Specifically, each cycle is further divided
+
+20
+00:00:59,440 --> 00:01:04,040
+in four phases. Inception, elaboration, construction and transition. In a
+
+21
+00:01:04,040 --> 00:01:06,290
+minute, we will look at each one of these
+
+22
+00:01:06,290 --> 00:01:08,840
+phases in detail and see how they relate to the
+
+23
+00:01:08,840 --> 00:01:12,150
+traditional activities of software development. Before that, I want
+
+24
+00:01:12,150 --> 00:01:15,760
+to mention the last level of these iterations, which happens
+
+25
+00:01:15,760 --> 00:01:20,330
+within these individual phases More precisely, inside each of these
+
+26
+00:01:20,330 --> 00:01:24,230
+phases, there might be multiple iterations. So what are these
+
+27
+00:01:24,230 --> 00:01:28,070
+iterations? Well, basically, each iteration corresponds to a group of
+
+28
+00:01:28,070 --> 00:01:30,550
+use cases that are selected so as to deal with
+
+29
+00:01:30,550 --> 00:01:33,200
+the most important risks first. So if you have a
+
+30
+00:01:33,200 --> 00:01:35,510
+set of use cases that you're considering, which means that
+
+31
+00:01:35,510 --> 00:01:37,450
+you have a set of features that you need to
+
+32
+00:01:37,450 --> 00:01:41,260
+implement, you will select for each iteration the most risky
+
+33
+00:01:41,260 --> 00:01:44,720
+ones that you still haven't realized, and realize them in that
+
+34
+00:01:44,720 --> 00:01:47,720
+iteration. And then continue in the following iterations with less and
+
+35
+00:01:47,720 --> 00:01:50,980
+less risky ones. So basically what happens in the end is
+
+36
+00:01:50,980 --> 00:01:52,960
+that essentially each iteration extends
+
+37
+00:01:52,960 --> 00:01:55,220
+the functionality beyond the previous iteration.
diff --git a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/11 - Cycle Example - lang_en_vs6.srt b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/11 - Cycle Example - lang_en_vs6.srt
new file mode 100644
index 0000000..af70543
--- /dev/null
+++ b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/11 - Cycle Example - lang_en_vs6.srt	
@@ -0,0 +1,147 @@
+1
+00:00:00,230 --> 00:00:02,590
+To make this a little more concrete, let's look at
+
+2
+00:00:02,590 --> 00:00:07,466
+an example involving cycles, phases, and iterations. Let's assume that we
+
+3
+00:00:07,466 --> 00:00:10,250
+have to develop a banking IT system. The first possible
+
+4
+00:00:10,250 --> 00:00:12,730
+cycle for such a system could be one in which we
+
+5
+00:00:12,730 --> 00:00:16,280
+implement the basic withdrawal facilities. What this means is that,
+
+6
+00:00:16,280 --> 00:00:18,400
+at the end of this cycle, there will be the release
+
+7
+00:00:18,400 --> 00:00:22,130
+of the product that implements this piece of functionality. But notice
+
+8
+00:00:22,130 --> 00:00:25,500
+that this will not be the only product release because within
+
+9
+00:00:25,500 --> 00:00:28,580
+the cycle, we will perform also the four phases that
+
+10
+00:00:28,580 --> 00:00:31,020
+we mentioned before, inception, elaboration,
+
+11
+00:00:31,020 --> 00:00:33,550
+construction, and transition. And within each
+
+12
+00:00:33,550 --> 00:00:36,980
+of these phases, we might have multiple iterations. And at the
+
+13
+00:00:36,980 --> 00:00:39,710
+end of each iteration, we will also have a product release.
+
+14
+00:00:39,710 --> 00:00:41,790
+Which in this case, will be an internal one. As
+
+15
+00:00:41,790 --> 00:00:44,690
+you can see, the iterative nature is really inherent in the
+
+16
+00:00:44,690 --> 00:00:48,030
+unified rational process. So, now let's clean up here, and let's
+
+17
+00:00:48,030 --> 00:00:50,814
+see what some other possible cycles could be for our banking
+
+18
+00:00:50,814 --> 00:00:54,070
+IT system. Here, I'm showing two possible additional ones. The first
+
+19
+00:00:54,070 --> 00:00:57,800
+one, cycle two, which will develop the account and system management. And
+
+20
+00:00:57,800 --> 00:01:00,230
+the third one, cycle three, which will develop the full account
+
+21
+00:01:00,230 --> 00:01:04,620
+management and cross selling. Similarly to cycle one, also these cycles will
+
+22
+00:01:04,620 --> 00:01:07,570
+produce a product, both at the end of the cycle, and
+
+23
+00:01:07,570 --> 00:01:10,740
+within the cycle in the different phases. And there's a few more
+
+24
+00:01:10,740 --> 00:01:13,150
+things to note. So the first one, is that each cycle
+
+25
+00:01:13,150 --> 00:01:15,900
+focuses on a different part of the system. So what you will
+
+26
+00:01:15,900 --> 00:01:19,350
+do, when you use the rational unified process, you will select a
+
+27
+00:01:19,350 --> 00:01:23,320
+subset of use cases that you want to realize within your cycle.
+
+28
+00:01:23,320 --> 00:01:26,640
+And the final product for that cycle, will be a product that
+
+29
+00:01:26,640 --> 00:01:30,190
+realizes those use cases. This is the first aspect. The second one,
+
+30
+00:01:30,190 --> 00:01:33,290
+is that these cycles, as you can see, are slightly overlapping. So
+
+31
+00:01:33,290 --> 00:01:35,880
+it is not the case that you finish a cycle, and then
+
+32
+00:01:35,880 --> 00:01:37,580
+you start the next one. So there is a little bit of
+
+33
+00:01:37,580 --> 00:01:41,250
+overlap among cycles, and we'll talk about that more. And finally,
+
+34
+00:01:41,250 --> 00:01:43,600
+I want to stress one more that each cycle
+
+35
+00:01:43,600 --> 00:01:46,960
+contains four phases, and each one of these phases might
+
+36
+00:01:46,960 --> 00:01:49,890
+be further splayed in iterations. So that's kind of a
+
+37
+00:01:49,890 --> 00:01:52,610
+high level view of how the whole process will work.
diff --git a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/12 - Phases within a Cycle - lang_en_vs5.srt b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/12 - Phases within a Cycle - lang_en_vs5.srt
new file mode 100644
index 0000000..c58be49
--- /dev/null
+++ b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/12 - Phases within a Cycle - lang_en_vs5.srt	
@@ -0,0 +1,199 @@
+1
+00:00:00,240 --> 00:00:02,505
+Now let's go back to the phases within a cycle.
+
+2
+00:00:02,505 --> 00:00:04,930
+because I want to show you how they relate to traditional
+
+3
+00:00:04,930 --> 00:00:08,196
+activities of software development. Because this is the first time that
+
+4
+00:00:08,196 --> 00:00:12,066
+we talk about inception, elaboration, construction and transition. So we will
+
+5
+00:00:12,066 --> 00:00:14,859
+know what they mean, in terms of the traditional software
+
+6
+00:00:14,859 --> 00:00:18,380
+development. So I'm going to first discuss these relations and then
+
+7
+00:00:18,380 --> 00:00:22,198
+I'm going to talk about each individual phase in further detail.
+
+8
+00:00:22,198 --> 00:00:25,570
+So I'm going to start by representing the four RUP phases here
+
+9
+00:00:25,570 --> 00:00:29,810
+with possible internal iterations. I1, E1 and E2, C1,
+
+10
+00:00:29,810 --> 00:00:32,490
+C2, and so on. And just as a reference, this
+
+11
+00:00:32,490 --> 00:00:34,670
+is the way in which time will progress. So we
+
+12
+00:00:34,670 --> 00:00:37,890
+will start with inception and we will finish with transition.
+
+13
+00:00:37,890 --> 00:00:39,710
+So what I'm want to do now is to show the
+
+14
+00:00:39,710 --> 00:00:43,930
+actual, traditional, software development activities here on the left. And
+
+15
+00:00:43,930 --> 00:00:46,970
+I also want to show you, using this diagram, how these
+
+16
+00:00:46,970 --> 00:00:51,610
+activities are actually performed in each of the RUP phases.
+
+17
+00:00:51,610 --> 00:00:54,540
+So, let's see what this representation means. Basically, what
+
+18
+00:00:54,540 --> 00:00:58,410
+I'm showing here, is that requirements engineering actually starts in
+
+19
+00:00:58,410 --> 00:01:00,480
+the inception phase. So, you can see the height
+
+20
+00:01:00,480 --> 00:01:03,090
+of this bar as the amount of effort devoted to
+
+21
+00:01:03,090 --> 00:01:05,890
+this activity in this specific phase. So you can
+
+22
+00:01:05,890 --> 00:01:09,950
+see that requirements engineering starts in inception phase, is mostly
+
+23
+00:01:09,950 --> 00:01:13,210
+performed in the elaboration phase, and then it continues,
+
+24
+00:01:13,210 --> 00:01:16,820
+although to a lesser extent, throughout all phases up until
+
+25
+00:01:16,820 --> 00:01:18,570
+the end of the transition. But the bulk is really
+
+26
+00:01:18,570 --> 00:01:22,940
+performed here in the elaboration phase. Similarly, if we consider analysis
+
+27
+00:01:22,940 --> 00:01:25,450
+and design, we can see that analysis and design are
+
+28
+00:01:25,450 --> 00:01:29,510
+mainly performed in the elaboration phase. But a considerable amount of
+
+29
+00:01:29,510 --> 00:01:31,900
+it also continues in the construction phase, and then it
+
+30
+00:01:31,900 --> 00:01:34,514
+kind of phases out. So there's very little of that done
+
+31
+00:01:34,514 --> 00:01:37,300
+in the transition phase. Looking now at implementation, you can see
+
+32
+00:01:37,300 --> 00:01:41,190
+that the implementation happens mostly in the construction phase, which is,
+
+33
+00:01:41,190 --> 00:01:45,460
+unsurprisingly, the phase that is mostly concerned with actual code development,
+
+34
+00:01:45,460 --> 00:01:47,620
+as we will see in a minute. Testing, on the other
+
+35
+00:01:47,620 --> 00:01:50,990
+hand, is performed throughout most phases, with, peaks in some specific
+
+36
+00:01:50,990 --> 00:01:54,260
+point, for example, at the end of some iterations, like here
+
+37
+00:01:54,260 --> 00:01:57,880
+and here. To conclude, we have the business modeling activity that
+
+38
+00:01:57,880 --> 00:02:00,160
+happens mainly in the inception and a little bit in the
+
+39
+00:02:00,160 --> 00:02:04,100
+elaboration phase and the deployment activity which happens a little bit
+
+40
+00:02:04,100 --> 00:02:06,420
+throughout, but the bulk of it is really in the transition
+
+41
+00:02:06,420 --> 00:02:08,699
+phase, which is actually the phase that has to do
+
+42
+00:02:08,699 --> 00:02:12,070
+with deployment and then maintenance. So I hope this kind
+
+43
+00:02:12,070 --> 00:02:14,970
+of high level view gives you a better understanding of
+
+44
+00:02:14,970 --> 00:02:17,940
+what is the mapping between these new phases and, the
+
+45
+00:02:17,940 --> 00:02:21,760
+typical software development activities that we are more familiar with.
+
+46
+00:02:21,760 --> 00:02:24,360
+So to further this understanding, later in the lesson, I'm
+
+47
+00:02:24,360 --> 00:02:28,220
+also going to talk about these specific phases individually. First, however,
+
+48
+00:02:28,220 --> 00:02:31,610
+I want to spend a little more time discussing what happens
+
+49
+00:02:31,610 --> 00:02:35,200
+inside each one of these iterations, just to make sure
+
+50
+00:02:35,200 --> 00:02:38,410
+that we are all understand what an iteration is exactly.
diff --git a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/13 - Iterations - lang_en_vs5.srt b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/13 - Iterations - lang_en_vs5.srt
new file mode 100644
index 0000000..fbdc2b0
--- /dev/null
+++ b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/13 - Iterations - lang_en_vs5.srt	
@@ -0,0 +1,95 @@
+1
+00:00:00,420 --> 00:00:03,520
+So what happens, exactly, within an iteration? In
+
+2
+00:00:03,520 --> 00:00:07,680
+almost every iteration, developers perform the following activities.
+
+3
+00:00:07,680 --> 00:00:10,830
+So they identify which pieces of functionality this
+
+4
+00:00:10,830 --> 00:00:14,450
+iteration will develop, will implement. After doing that, they
+
+5
+00:00:14,450 --> 00:00:17,240
+will create a design, for the considered use
+
+6
+00:00:17,240 --> 00:00:19,640
+cases, and they will do that guided by the
+
+7
+00:00:19,640 --> 00:00:22,334
+chosen architecture. So the set of use cases
+
+8
+00:00:22,334 --> 00:00:25,666
+plus the architectural guidelines will result in a design
+
+9
+00:00:25,666 --> 00:00:29,035
+for the selected use cases. Once the design is defined,
+
+10
+00:00:29,035 --> 00:00:32,060
+then the developers will implement the design, which will result
+
+11
+00:00:32,060 --> 00:00:35,430
+in a set of software components. They will then verify
+
+12
+00:00:35,430 --> 00:00:38,992
+the components against the use cases to make sure that the
+
+13
+00:00:38,992 --> 00:00:41,740
+components satisfy the use cases, they suitably realize the use
+
+14
+00:00:41,740 --> 00:00:43,995
+cases. And they will do that through testing or some
+
+15
+00:00:43,995 --> 00:00:47,730
+other verification and validation activity. Finally, after verifying that the
+
+16
+00:00:47,730 --> 00:00:51,320
+code actually implements the use cases, they will release a product,
+
+17
+00:00:51,320 --> 00:00:53,840
+which also represent the end of the iteration. And notice that
+
+18
+00:00:53,840 --> 00:00:56,370
+what I put here is an icon for the world,
+
+19
+00:00:56,370 --> 00:00:59,330
+in double quotes. Because in many cases the release will be
+
+20
+00:00:59,330 --> 00:01:02,050
+just an internal release or maybe a release that will just
+
+21
+00:01:02,050 --> 00:01:04,813
+go to some of the stakeholders so that they can provide
+
+22
+00:01:04,813 --> 00:01:07,040
+feedback on that. Okay. So it doesn't have to be an
+
+23
+00:01:07,040 --> 00:01:09,080
+external release. It doesn't have to be a release to the
+
+24
+00:01:09,080 --> 00:01:12,270
+world. But it is, nevertheless, a release of a software product. .
diff --git a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/14 - Iterative Approach Quiz - lang_en_vs5.srt b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/14 - Iterative Approach Quiz - lang_en_vs5.srt
new file mode 100644
index 0000000..d4b7808
--- /dev/null
+++ b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/14 - Iterative Approach Quiz - lang_en_vs5.srt	
@@ -0,0 +1,43 @@
+1
+00:00:00,182 --> 00:00:02,850
+So now, since we're talking about the incremental and iterative
+
+2
+00:00:02,850 --> 00:00:05,950
+nature of the Rational Unified Process, let's have a quiz on
+
+3
+00:00:05,950 --> 00:00:09,460
+the benefits of iterative approaches. So I'd like for you to tell
+
+4
+00:00:09,460 --> 00:00:12,710
+me what are these benefits. Is one benefit the fact that
+
+5
+00:00:12,710 --> 00:00:16,129
+iterative approaches keep developers busy or maybe that they give developers
+
+6
+00:00:16,129 --> 00:00:19,480
+early feedback, that they allow for doing the same thing over
+
+7
+00:00:19,480 --> 00:00:22,930
+and over in an iterative way. Maybe they also minimize the
+
+8
+00:00:22,930 --> 00:00:25,210
+risk of developing the wrong system. Can they be used to
+
+9
+00:00:25,210 --> 00:00:27,170
+improve planning, or is it the benefit
+
+10
+00:00:27,170 --> 00:00:30,160
+that they accommodate evolving requirements. Also, in this
+
+11
+00:00:30,160 --> 00:00:34,360
+case, I would like for you to check all the answers that you think are correct.
diff --git a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/15 - Iterative Approach Quiz Solution - lang_en_vs5.srt b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/15 - Iterative Approach Quiz Solution - lang_en_vs5.srt
new file mode 100644
index 0000000..6e69cec
--- /dev/null
+++ b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/15 - Iterative Approach Quiz Solution - lang_en_vs5.srt	
@@ -0,0 +1,179 @@
+1
+00:00:00,180 --> 00:00:01,740
+Okay so let's look at the first one. Well I
+
+2
+00:00:01,740 --> 00:00:04,760
+don't think that the fact of keeping developers busy is really
+
+3
+00:00:04,760 --> 00:00:08,020
+one of the highlights or the main benefits of iterative
+
+4
+00:00:08,020 --> 00:00:12,310
+approaches. Developers are really busy without any need for additional help.
+
+5
+00:00:12,310 --> 00:00:14,950
+So I will just not mark this one. The second
+
+6
+00:00:14,950 --> 00:00:19,280
+one conversely is definitely one of the advantages of iterative approaches.
+
+7
+00:00:19,280 --> 00:00:21,710
+So the fact that iterative approaches give the developers a early
+
+8
+00:00:21,710 --> 00:00:25,890
+feedback, is a great advantage which has in turn additional advantages.
+
+9
+00:00:25,890 --> 00:00:29,340
+For example, it increases the project tempo, so it gives the developers
+
+10
+00:00:29,340 --> 00:00:32,350
+not busy but more focused. It's easier to be focused when you
+
+11
+00:00:32,350 --> 00:00:35,790
+have a short term deadline, or a short term goal
+
+12
+00:00:35,790 --> 00:00:38,670
+rather than a release that is planned in six months or even
+
+13
+00:00:38,670 --> 00:00:42,420
+later. Another advantage of this early feedback is the fact that developers
+
+14
+00:00:42,420 --> 00:00:45,390
+are rewarded for their efforts so, there is sort of an immediate
+
+15
+00:00:45,390 --> 00:00:48,360
+rewards because you can see the results of your effort instead of
+
+16
+00:00:48,360 --> 00:00:51,310
+having to wait a long time to see such results. And last,
+
+17
+00:00:51,310 --> 00:00:55,126
+but not least the fact of getting early feedback also minimizes
+
+18
+00:00:55,126 --> 00:00:58,570
+the risks of developing the wrong system. So why is that?
+
+19
+00:00:58,570 --> 00:01:01,820
+Well because getting early feedback will also allow us to find
+
+20
+00:01:01,820 --> 00:01:05,140
+out whether we're going in the wrong direction early in the development process
+
+21
+00:01:05,140 --> 00:01:08,460
+rather than at the end. And therefore, will minimize this risk.
+
+22
+00:01:08,460 --> 00:01:10,760
+Going back to the previous question, yeah, I don't think that, you
+
+23
+00:01:10,760 --> 00:01:12,960
+know, doing the same thing over and over is a great
+
+24
+00:01:12,960 --> 00:01:16,170
+advantage. And in fact, iterative approaches do not do the same thing
+
+25
+00:01:16,170 --> 00:01:18,940
+over and over. So they keep iterating, but they keep
+
+26
+00:01:18,940 --> 00:01:21,930
+augmenting the amount of functionality in the system. They don't
+
+27
+00:01:21,930 --> 00:01:24,960
+just repeat the same thing. As for improving planning, actually
+
+28
+00:01:24,960 --> 00:01:27,980
+improving planning is not really a strength of these approaches,
+
+29
+00:01:27,980 --> 00:01:30,880
+because sometimes the number of iterations is hard to predict,
+
+30
+00:01:30,880 --> 00:01:33,050
+so it's hard to do a natural planning when you
+
+31
+00:01:33,050 --> 00:01:36,440
+are using an iterative approach. So finally, are iterative approaches
+
+32
+00:01:36,440 --> 00:01:38,700
+good for accomodating evolving requirements?
+
+33
+00:01:38,700 --> 00:01:41,630
+Most definitely. First, iterative approaches, and
+
+34
+00:01:41,630 --> 00:01:44,590
+in particular, the one that we're discussing consider requirements
+
+35
+00:01:44,590 --> 00:01:47,900
+incrementally, so they can better incorporate your requirements. So if
+
+36
+00:01:47,900 --> 00:01:51,030
+there are new requirements, it's easier to accommodate them using
+
+37
+00:01:51,030 --> 00:01:55,210
+an iterative approach. Second, these approaches realize a few requirements
+
+38
+00:01:55,210 --> 00:01:57,740
+at a time. Something from the most risky ones, as
+
+39
+00:01:57,740 --> 00:02:00,600
+we said. So any problem with those risky requirements will
+
+40
+00:02:00,600 --> 00:02:04,220
+be discovered early, and suitable course corrections could be taken.
+
+41
+00:02:04,220 --> 00:02:06,850
+So in case you still have doubts about iterative approaches,
+
+42
+00:02:06,850 --> 00:02:08,460
+it might be worth it to go back to
+
+43
+00:02:08,460 --> 00:02:11,390
+mini course number one, lesson number two to discuss the
+
+44
+00:02:11,390 --> 00:02:14,620
+life cycle models. Because we talk about iterative approaches
+
+45
+00:02:14,620 --> 00:02:17,770
+and their advantages and their characteristics there in some detail.
diff --git a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/16 - Inception Phase - lang_en_vs4.srt b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/16 - Inception Phase - lang_en_vs4.srt
new file mode 100644
index 0000000..60ab80a
--- /dev/null
+++ b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/16 - Inception Phase - lang_en_vs4.srt	
@@ -0,0 +1,323 @@
+1
+00:00:00,175 --> 00:00:03,510
+Let's talk a little bit more about phases. The rational unified
+
+2
+00:00:03,510 --> 00:00:07,050
+process phases are fundamental aspects of this process and which just touched
+
+3
+00:00:07,050 --> 00:00:09,200
+on them so we just give a quick overview. And I want to
+
+4
+00:00:09,200 --> 00:00:12,010
+look at these phases in a little more detail. So, what I'm
+
+5
+00:00:12,010 --> 00:00:14,960
+going to do is, for each phase, I'm going to discuss what it is,
+
+6
+00:00:14,960 --> 00:00:18,310
+what it produces and how is the result of the phase suppose
+
+7
+00:00:18,310 --> 00:00:21,910
+to be,. Assessed, and what are the consequences of this assessment. So
+
+8
+00:00:21,910 --> 00:00:25,350
+let's start with the first phase, the inception phase. The first phase
+
+9
+00:00:25,350 --> 00:00:27,920
+goes from the idea of the product to the
+
+10
+00:00:27,920 --> 00:00:30,990
+vision of the end product. What this involves is basically
+
+11
+00:00:30,990 --> 00:00:34,230
+to delimiting the project scope. And making the business case
+
+12
+00:00:34,230 --> 00:00:37,040
+for the product presented. Why is it worth doing? What
+
+13
+00:00:37,040 --> 00:00:39,870
+are the success criteria? What are the main risks? What
+
+14
+00:00:39,870 --> 00:00:43,690
+resources will be needed? And so on, specifically these phases
+
+15
+00:00:43,690 --> 00:00:47,310
+answer three main questions. The first one is, what are
+
+16
+00:00:47,310 --> 00:00:51,330
+the major users or actors, to use the UML terminology.
+
+17
+00:00:51,330 --> 00:00:53,450
+And what will the system do for them? To
+
+18
+00:00:53,450 --> 00:00:56,780
+answer this, these phases produce a simplified use-case model where
+
+19
+00:00:56,780 --> 00:01:00,480
+only a few use-cases are represented and described. So this
+
+20
+00:01:00,480 --> 00:01:03,390
+is a sort of initial use-case model. The second question
+
+21
+00:01:03,390 --> 00:01:05,610
+is about the architecture, what could be an architecture
+
+22
+00:01:05,610 --> 00:01:08,370
+for the system? So in this phase we will normally
+
+23
+00:01:08,370 --> 00:01:12,420
+also develop a tentative architecture. So an initial architecture that
+
+24
+00:01:12,420 --> 00:01:16,540
+describes the most crucial subsystems. Finally this phase also answers
+
+25
+00:01:16,540 --> 00:01:18,890
+the question, what is the plan and how much
+
+26
+00:01:18,890 --> 00:01:21,620
+will it cost? To answer this question. This phase will
+
+27
+00:01:21,620 --> 00:01:24,930
+identify the main risks for the project and also produce
+
+28
+00:01:24,930 --> 00:01:28,600
+a rough plan with estimates for resources, initial planning for
+
+29
+00:01:28,600 --> 00:01:32,820
+the phases and dates and milestones. Specifically, the inception phase
+
+30
+00:01:32,820 --> 00:01:36,370
+generates several deliverables. It is very important that you pay
+
+31
+00:01:36,370 --> 00:01:39,600
+attention so that you understand what this deliberate approach are.
+
+32
+00:01:39,600 --> 00:01:42,320
+Starting from the first one, which is the vision document.
+
+33
+00:01:42,320 --> 00:01:44,800
+And this is a document that provides a general
+
+34
+00:01:44,800 --> 00:01:48,420
+vision of the core projects requirements, key features and main
+
+35
+00:01:48,420 --> 00:01:51,890
+constraints. Together with this, the inception phase also produces an
+
+36
+00:01:51,890 --> 00:01:54,900
+initial use case model, as I just mentioned. So this
+
+37
+00:01:54,900 --> 00:01:57,720
+is a use case model that includes an initial set
+
+38
+00:01:57,720 --> 00:02:00,670
+of use cases, and then will be later refined. Two
+
+39
+00:02:00,670 --> 00:02:04,300
+additional variables are the initial project glossary, which describes the
+
+40
+00:02:04,300 --> 00:02:07,330
+main terms, using the project and their meaning, and the
+
+41
+00:02:07,330 --> 00:02:10,229
+initial business case which includes business context. And
+
+42
+00:02:10,229 --> 00:02:13,470
+success criteria. Yet another deliverable for the inception phase
+
+43
+00:02:13,470 --> 00:02:15,770
+is the initial project plan, which shows the
+
+44
+00:02:15,770 --> 00:02:20,650
+phases, iterations, roles of the participants, schedule and initial
+
+45
+00:02:20,650 --> 00:02:23,610
+estimates. In addition, the inception phase also produces
+
+46
+00:02:23,610 --> 00:02:26,810
+a risk assessment document, which describes the main risks
+
+47
+00:02:26,810 --> 00:02:29,970
+and counters measures for this risk. Finally, and this
+
+48
+00:02:29,970 --> 00:02:32,430
+is an optional deliverable, in the sense that it,
+
+49
+00:02:32,430 --> 00:02:34,990
+it might or might not be produced, depending on the specific
+
+50
+00:02:34,990 --> 00:02:37,870
+project. As part of the inception phase we might also generate
+
+51
+00:02:37,870 --> 00:02:41,780
+1 or more prototypes. For example, we might develop prototypes to
+
+52
+00:02:41,780 --> 00:02:45,590
+address some specific risks that we have identified or to show some
+
+53
+00:02:45,590 --> 00:02:48,380
+specific aspect of the system of which we are unsure to
+
+54
+00:02:48,380 --> 00:02:51,910
+the stakeholders. So basically all the typical users of prototypes that
+
+55
+00:02:51,910 --> 00:02:54,600
+we discussed before. So when we're done with the inception phase
+
+56
+00:02:54,600 --> 00:02:58,300
+we hit the first milestone for the cycle we are currently performing.
+
+57
+00:02:58,300 --> 00:03:00,600
+And so there are some evaluation criteria that will tell
+
+58
+00:03:00,600 --> 00:03:03,640
+us whether we can consider the inception phase concluded or not.
+
+59
+00:03:03,640 --> 00:03:06,840
+And the first of this criteria is stakeholder concurrence, which
+
+60
+00:03:06,840 --> 00:03:10,510
+means that all the stakeholders must agree on the scope, definition,
+
+61
+00:03:10,510 --> 00:03:13,510
+and cost schedule estimates for the projects. The second criteria
+
+62
+00:03:13,510 --> 00:03:17,040
+needs requirements understanding, out of the initial primary use cases that
+
+63
+00:03:17,040 --> 00:03:20,380
+we have identified so far, the right one for our system.
+
+64
+00:03:20,380 --> 00:03:23,760
+And other criteria is the credibility of the cost schedule estimates,
+
+65
+00:03:23,760 --> 00:03:28,280
+the priorities, defined the risks identifies and the countermeasures for
+
+66
+00:03:28,280 --> 00:03:31,590
+those risks, and the development process that we're following. Finally, in
+
+67
+00:03:31,590 --> 00:03:34,000
+the case we produce prototypes as part of the inceptional
+
+68
+00:03:34,000 --> 00:03:37,520
+phase, this will also be evaluated and assessed to judge the
+
+69
+00:03:37,520 --> 00:03:39,960
+overall outcome of the phase. So what happens if the
+
+70
+00:03:39,960 --> 00:03:43,170
+project fails to pass this milestone? So if the outcome of
+
+71
+00:03:43,170 --> 00:03:46,020
+the inception phase is considered to be inadequate with respect
+
+72
+00:03:46,020 --> 00:03:48,642
+to one or more of these criteria. Well at this point,
+
+73
+00:03:48,642 --> 00:03:51,240
+since we're kind of an initial phase of the cycle
+
+74
+00:03:51,240 --> 00:03:54,370
+the project may be cancelled or considerably re-thought. So to
+
+75
+00:03:54,370 --> 00:03:57,610
+summarize all of these in one sentence the Inception Phase
+
+76
+00:03:57,610 --> 00:04:00,320
+is the phase in which we produce. Then you shall vision,
+
+77
+00:04:00,320 --> 00:04:04,750
+used case model, project plan, risk assessment and possibly, prototypes
+
+78
+00:04:04,750 --> 00:04:07,290
+for the project. And we have to make sure, that
+
+79
+00:04:07,290 --> 00:04:10,680
+all of this deliverables satisfy a set of criteria, so
+
+80
+00:04:10,680 --> 00:04:13,770
+that we can continue on the project. And otherwise, we'll either
+
+81
+00:04:13,770 --> 00:04:17,160
+cancel the project or rethink its scope, or other aspects of it.
diff --git a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/17 - Elaboration Phase - lang_en_vs5.srt b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/17 - Elaboration Phase - lang_en_vs5.srt
new file mode 100644
index 0000000..1025b2c
--- /dev/null
+++ b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/17 - Elaboration Phase - lang_en_vs5.srt	
@@ -0,0 +1,215 @@
+1
+00:00:00,350 --> 00:00:02,400
+Now that we've discussed the inception phase, let's move
+
+2
+00:00:02,400 --> 00:00:04,180
+on to the second phase of RUP, which is
+
+3
+00:00:04,180 --> 00:00:07,280
+the elaboration phase. And there are four main goals
+
+4
+00:00:07,280 --> 00:00:10,900
+and activities for the elaboration phase. Analyzing the problem domain
+
+5
+00:00:10,900 --> 00:00:13,690
+to get a better understanding of the domain. Establishing
+
+6
+00:00:13,690 --> 00:00:17,840
+a solid architectural foundation for the project. Eliminating the highest
+
+7
+00:00:17,840 --> 00:00:21,454
+risk elements which basically means addressing the most critical
+
+8
+00:00:21,454 --> 00:00:25,590
+use cases. And finally, refine the plan of activities and estimates
+
+9
+00:00:25,590 --> 00:00:28,250
+of resources to complete the project. The outcome
+
+10
+00:00:28,250 --> 00:00:31,310
+of the elaboration phase reflects these activities and also
+
+11
+00:00:31,310 --> 00:00:34,440
+in this case produces several artifacts. The first one
+
+12
+00:00:34,440 --> 00:00:38,700
+is an almost complete use case model with all use cases
+
+13
+00:00:38,700 --> 00:00:42,560
+and actors identified and most use case descriptions developed.
+
+14
+00:00:42,560 --> 00:00:44,070
+As part of this phase we also identify a
+
+15
+00:00:44,070 --> 00:00:47,550
+set of what we called supplementary requirements. So these
+
+16
+00:00:47,550 --> 00:00:50,685
+are basically all the requirements that are not associated
+
+17
+00:00:50,685 --> 00:00:53,483
+with a use case. And these sets includes in particular all
+
+18
+00:00:53,483 --> 00:00:56,110
+non-functional requirements such as security,
+
+19
+00:00:56,110 --> 00:00:58,630
+reliability, maintainability and so on. So
+
+20
+00:00:58,630 --> 00:01:00,770
+all the ones that are relevant for the system that
+
+21
+00:01:00,770 --> 00:01:02,280
+you're developing. We mentioned before
+
+22
+00:01:02,280 --> 00:01:04,410
+that the software architecture is developed
+
+23
+00:01:04,410 --> 00:01:07,220
+in an incremental way, so it's not created at once.
+
+24
+00:01:07,220 --> 00:01:09,650
+And this is exactly what happens in the elaboration phase, that
+
+25
+00:01:09,650 --> 00:01:12,990
+we take the initial architecture that was defined in the inception
+
+26
+00:01:12,990 --> 00:01:16,280
+phase and we refine it until we get to a software
+
+27
+00:01:16,280 --> 00:01:19,400
+architecture which is complete. And that is part of the
+
+28
+00:01:19,400 --> 00:01:22,410
+deliverables for this phase. And the list continues, so let
+
+29
+00:01:22,410 --> 00:01:25,020
+me make some room. In addition to producing a complete
+
+30
+00:01:25,020 --> 00:01:28,270
+architecture for our system, in the elaboration phase we also
+
+31
+00:01:28,270 --> 00:01:32,130
+define the lower-level design for the system. And, therefore, as
+
+32
+00:01:32,130 --> 00:01:35,560
+part of this phase, we produce as deliverables a design
+
+33
+00:01:35,560 --> 00:01:38,000
+model, and together with that, a complete set of test
+
+34
+00:01:38,000 --> 00:01:41,770
+cases, and an executable prototype. We also produce a revised
+
+35
+00:01:41,770 --> 00:01:44,390
+project plan. Now that we have more information about the
+
+36
+00:01:44,390 --> 00:01:47,120
+project we can refine the various estimates and the various
+
+37
+00:01:47,120 --> 00:01:50,020
+pieces of information in the project plan. And also an
+
+38
+00:01:50,020 --> 00:01:54,160
+updated risk assessment document. Finally, in this phase we also generate
+
+39
+00:01:54,160 --> 00:01:57,680
+a preliminary user manual that describes to the users how
+
+40
+00:01:57,680 --> 00:02:00,350
+the system can be used and should be used. So now
+
+41
+00:02:00,350 --> 00:02:03,630
+let's see what are the evaluation criteria for the elaboration
+
+42
+00:02:03,630 --> 00:02:06,880
+phase which is our second milestone. So I'm just going to list
+
+43
+00:02:06,880 --> 00:02:09,400
+them here. The first one is whether the vision
+
+44
+00:02:09,400 --> 00:02:12,620
+and the architecture are stable or they're still changing so
+
+45
+00:02:12,620 --> 00:02:15,680
+did we converge into a final complete vision for the
+
+46
+00:02:15,680 --> 00:02:18,620
+system? Does the prototype show that the major risks that
+
+47
+00:02:18,620 --> 00:02:22,090
+we have identified have been resolved or at least addressed
+
+48
+00:02:22,090 --> 00:02:25,390
+in this phase? Is the project plan sufficiently detailed and
+
+49
+00:02:25,390 --> 00:02:29,030
+accurate? Do all stakeholders agree that the vision can be
+
+50
+00:02:29,030 --> 00:02:32,320
+achieved with the current plan? Is the actual resource expenditure
+
+51
+00:02:32,320 --> 00:02:35,840
+versus the planned expenditure acceptable? So now we study consumer
+
+52
+00:02:35,840 --> 00:02:39,120
+resources and therefore we can check whether our estimates were
+
+53
+00:02:39,120 --> 00:02:41,964
+correct. And also in this case the project might be
+
+54
+00:02:41,964 --> 00:02:45,730
+cancelled or considerably reshaped if it fails to pass this milestone.
diff --git a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/18 - Construction Phase - lang_en_vs5.srt b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/18 - Construction Phase - lang_en_vs5.srt
new file mode 100644
index 0000000..70051fd
--- /dev/null
+++ b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/18 - Construction Phase - lang_en_vs5.srt	
@@ -0,0 +1,247 @@
+1
+00:00:00,230 --> 00:00:03,170
+So if the elaboration phase is successful, we then move
+
+2
+00:00:03,170 --> 00:00:06,560
+to the construction phase, which is our third phase. And
+
+3
+00:00:06,560 --> 00:00:09,550
+the construction phase is basically the phase in which most
+
+4
+00:00:09,550 --> 00:00:13,860
+of the actual development occurs. In short, all the features considered
+
+5
+00:00:13,860 --> 00:00:17,360
+are developed. So we'll continue with our car metaphor that
+
+6
+00:00:17,360 --> 00:00:19,310
+we used for the prototype. And in this case we
+
+7
+00:00:19,310 --> 00:00:22,390
+will have our complete car ready. Not only the features
+
+8
+00:00:22,390 --> 00:00:25,940
+are developed but they're also thoroughly tested. So we have performed
+
+9
+00:00:25,940 --> 00:00:29,490
+quality assurance. We have verified and validated the software,
+
+10
+00:00:29,490 --> 00:00:32,580
+the system and we know that it works correctly. Or
+
+11
+00:00:32,580 --> 00:00:34,620
+at least that it works correctly as far as
+
+12
+00:00:34,620 --> 00:00:37,850
+we can tell. So, in general, the construction phase is
+
+13
+00:00:37,850 --> 00:00:39,760
+the phase in which there is a shift in
+
+14
+00:00:39,760 --> 00:00:42,640
+emphasis from intellectual property development
+
+15
+00:00:42,640 --> 00:00:45,460
+to product development. From ideas
+
+16
+00:00:45,460 --> 00:00:47,650
+to products. So, what is the outcome of the
+
+17
+00:00:47,650 --> 00:00:51,250
+construction phase? Well, basically the construction phrase produces a product
+
+18
+00:00:51,250 --> 00:00:54,520
+that is ready to be deployed to the users. Specifically,
+
+19
+00:00:54,520 --> 00:00:57,570
+the phase generates the following outcomes. First of all, at the
+
+20
+00:00:57,570 --> 00:01:00,150
+end of this phase, all the use cases have been
+
+21
+00:01:00,150 --> 00:01:03,220
+realized with traceability information. What does that mean? It means that
+
+22
+00:01:03,220 --> 00:01:06,640
+not only all the functionality expressed by the use cases
+
+23
+00:01:06,640 --> 00:01:10,240
+have been implemented, but also that we have traceability information from
+
+24
+00:01:10,240 --> 00:01:13,530
+the use cases, to the different artifacts. So for example,
+
+25
+00:01:13,530 --> 00:01:16,780
+we know which part of the design realizes which use case.
+
+26
+00:01:16,780 --> 00:01:19,230
+We know which part of the implementation is related to a
+
+27
+00:01:19,230 --> 00:01:22,150
+given use case. Which use cases were derived from a use
+
+28
+00:01:22,150 --> 00:01:24,390
+case, and so on and so forth. And in this way
+
+29
+00:01:24,390 --> 00:01:28,310
+we can trace our requirements throughout the system. Throughout the different
+
+30
+00:01:28,310 --> 00:01:32,162
+artifacts that were developed during the software process. As we were
+
+31
+00:01:32,162 --> 00:01:35,790
+saying, we also have complete software product here, which is integrated
+
+32
+00:01:35,790 --> 00:01:39,240
+on all the needed platforms. Since the system, the software product,
+
+33
+00:01:39,240 --> 00:01:42,200
+has to be thoroughly tested, we will also have a complete
+
+34
+00:01:42,200 --> 00:01:44,900
+set of results for our tests. As part of this
+
+35
+00:01:44,900 --> 00:01:47,980
+phase, we will also finalize the user manual, so you'll have
+
+36
+00:01:47,980 --> 00:01:51,050
+a user manual ready to be provided to the users, and
+
+37
+00:01:51,050 --> 00:01:53,700
+ready to be used. And finally, we will have a complete
+
+38
+00:01:53,700 --> 00:01:58,370
+set of artifacts that include design documents, code, test cases, and
+
+39
+00:01:58,370 --> 00:02:00,440
+so on and so forth, so basically all of the artifacts
+
+40
+00:02:00,440 --> 00:02:04,240
+that have been produced during the development process. So roughly speaking,
+
+41
+00:02:04,240 --> 00:02:07,280
+we can consider the product that is produced at the end
+
+42
+00:02:07,280 --> 00:02:10,570
+of this phase as a typical beta release. So in case
+
+43
+00:02:10,570 --> 00:02:12,920
+you're not familiar with that, a beta release is an initial
+
+44
+00:02:12,920 --> 00:02:16,050
+release normally meant for a selected subset of users. So it
+
+45
+00:02:16,050 --> 00:02:19,250
+is something that is not quite yet ready for primetime, but
+
+46
+00:02:19,250 --> 00:02:22,540
+almost. So let's see also in this case, what are the evaluation
+
+47
+00:02:22,540 --> 00:02:25,740
+criteria for the construction phase. So how do we assess, that
+
+48
+00:02:25,740 --> 00:02:29,620
+this third milestone has been accomplished, successfully? We pretty much have
+
+49
+00:02:29,620 --> 00:02:32,510
+a complete product ready to be shipped right? So the first question
+
+50
+00:02:32,510 --> 00:02:35,260
+we want to ask is, whether the product is stable and mature
+
+51
+00:02:35,260 --> 00:02:37,910
+enough to be deployed to users. At the end of this
+
+52
+00:02:37,910 --> 00:02:40,510
+phase it has to be. Are the stakeholders ready for the
+
+53
+00:02:40,510 --> 00:02:44,160
+transition into the user community? Are we ready to go from development
+
+54
+00:02:44,160 --> 00:02:45,450
+to production? Are the actual
+
+55
+00:02:45,450 --> 00:02:48,060
+resource expenditures versus the planned expenditures
+
+56
+00:02:48,060 --> 00:02:50,890
+still acceptable? So what this means is that at this point we
+
+57
+00:02:50,890 --> 00:02:54,660
+can really assess whether our estimates were accurate enough with respect
+
+58
+00:02:54,660 --> 00:02:57,740
+to what we actually spent for the project up to this point.
+
+59
+00:02:57,740 --> 00:03:00,390
+So unless we can answer in a positive way to
+
+60
+00:03:00,390 --> 00:03:03,790
+all these questions, the transition might be postponed by one release.
+
+61
+00:03:03,790 --> 00:03:05,930
+Because that means that we're still not ready to go
+
+62
+00:03:05,930 --> 00:03:08,660
+to the market. We're still not ready to deploy our product.
diff --git a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/19 - Transition Phase - lang_en_vs5.srt b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/19 - Transition Phase - lang_en_vs5.srt
new file mode 100644
index 0000000..e09b6fc
--- /dev/null
+++ b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/19 - Transition Phase - lang_en_vs5.srt	
@@ -0,0 +1,231 @@
+1
+00:00:00,300 --> 00:00:02,080
+But if we are ready to go to the market,
+
+2
+00:00:02,080 --> 00:00:04,800
+if we are ready to deploy our product, then we can
+
+3
+00:00:04,800 --> 00:00:07,160
+move to the transition phase, which has mainly to do
+
+4
+00:00:07,160 --> 00:00:10,360
+with deployment and maintainence of a system. So what are the
+
+5
+00:00:10,360 --> 00:00:12,950
+main activities in the transition phase? As we discussed in
+
+6
+00:00:12,950 --> 00:00:16,280
+our initial lessons, in most real world cases, there are issues
+
+7
+00:00:16,280 --> 00:00:20,820
+that manifest themselves after deployment, when we release our software and
+
+8
+00:00:20,820 --> 00:00:22,870
+actual users interact with the
+
+9
+00:00:22,870 --> 00:00:26,230
+software. Specifically, users might report failures
+
+10
+00:00:26,230 --> 00:00:28,965
+that they experienced while using the system. So, what we call
+
+11
+00:00:28,965 --> 00:00:33,120
+bug reports. Or they might report improvements they might want to see
+
+12
+00:00:33,120 --> 00:00:36,798
+in the software. So typically these will be new feature requests. And
+
+13
+00:00:36,798 --> 00:00:40,270
+in addition, there might be issues that don't come necessarily from the
+
+14
+00:00:40,270 --> 00:00:42,734
+users but that are related to the fact that our system
+
+15
+00:00:42,734 --> 00:00:45,920
+has to operate, has to work in a new execution environment. For
+
+16
+00:00:45,920 --> 00:00:48,930
+example, the new version of an operating system, or the new version
+
+17
+00:00:48,930 --> 00:00:51,474
+of a set of libraries. When this happens, we have to address
+
+18
+00:00:51,474 --> 00:00:55,020
+these issues by performing maintenance. Specifically, corrective maintenance
+
+19
+00:00:55,020 --> 00:00:58,900
+for bug reports, perfective maintenance, for feature requests, and
+
+20
+00:00:58,900 --> 00:01:02,270
+adaptive maintenance, for environment changes. And the result of
+
+21
+00:01:02,270 --> 00:01:04,319
+this is that we will have a new release
+
+22
+00:01:04,319 --> 00:01:06,550
+of the software. Other activities that are performed in
+
+23
+00:01:06,550 --> 00:01:10,480
+this phase include training, customer service, and providing help-line
+
+24
+00:01:10,480 --> 00:01:13,350
+assistance. Finally, if you remember what we saw when
+
+25
+00:01:13,350 --> 00:01:16,810
+we were looking at the banking IT system example,
+
+26
+00:01:16,810 --> 00:01:21,300
+the cycles within a development are not necessarily completely dis-joined, but
+
+27
+00:01:21,300 --> 00:01:23,940
+they might overlap a little bit. So something else that might
+
+28
+00:01:23,940 --> 00:01:26,650
+happen in the transition phase is that a new cycle may
+
+29
+00:01:26,650 --> 00:01:29,020
+start. So there might be some activities that are related to
+
+30
+00:01:29,020 --> 00:01:32,190
+the fact that we're starting to think about the new cycle.
+
+31
+00:01:32,190 --> 00:01:35,150
+So now let's see what kind of outcome these activities will
+
+32
+00:01:35,150 --> 00:01:38,410
+produce. The first one is a complete project with all the
+
+33
+00:01:38,410 --> 00:01:41,820
+artifacts that we mentioned before. Another outcome is that the product will
+
+34
+00:01:41,820 --> 00:01:44,090
+be actually in use. So the product will be in the
+
+35
+00:01:44,090 --> 00:01:46,870
+hands of the users and the users will start using it, will
+
+36
+00:01:46,870 --> 00:01:49,760
+start interacting with it, for real, not just in a beta testing
+
+37
+00:01:49,760 --> 00:01:53,260
+setting. Another outcome will be a lesson learnt. What worked. What didn't
+
+38
+00:01:53,260 --> 00:01:56,240
+work. What should we do different in the next cycle or in
+
+39
+00:01:56,240 --> 00:01:59,446
+the next development? And this is a very important part of the
+
+40
+00:01:59,446 --> 00:02:01,651
+whole process, because it;s what provides
+
+41
+00:02:01,651 --> 00:02:04,378
+feedback between cycles, and between projects.
+
+42
+00:02:04,378 --> 00:02:07,018
+And as we said before, in case we have a next released
+
+43
+00:02:07,018 --> 00:02:09,478
+planned or a next cycle coming up, we might want to
+
+44
+00:02:09,478 --> 00:02:12,922
+start planning for the next release. So another outcome will be
+
+45
+00:02:12,922 --> 00:02:15,783
+the plan for the next release. So similar to the other
+
+46
+00:02:15,783 --> 00:02:19,147
+phases, also for the transition phase, we have a milestone, which
+
+47
+00:02:19,147 --> 00:02:21,733
+is the fourth milestone in this case. And therefore we
+
+48
+00:02:21,733 --> 00:02:25,061
+have evaluation criteria for the transition phase that will define whether
+
+49
+00:02:25,061 --> 00:02:28,530
+we've reached the milestone or not. And in this case, one
+
+50
+00:02:28,530 --> 00:02:32,040
+important assessment is whether the user is satisfied. So users are
+
+51
+00:02:32,040 --> 00:02:34,370
+actually using our product now, so we can get feedback
+
+52
+00:02:34,370 --> 00:02:36,260
+from them, we can see whether the product makes them
+
+53
+00:02:36,260 --> 00:02:40,390
+happy or not. And we continue assessing whether our expenditures
+
+54
+00:02:40,390 --> 00:02:43,460
+are fine with respect to our estimates. And in this case,
+
+55
+00:02:43,460 --> 00:02:46,882
+problems with this milestone might lead to further maintenance of
+
+56
+00:02:46,882 --> 00:02:48,840
+the system. So for example, we might need to produce
+
+57
+00:02:48,840 --> 00:02:51,460
+a new release to address some of the issues that
+
+58
+00:02:51,460 --> 00:02:54,410
+the users identified, as we discussed a couple of minutes ago.
diff --git a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/2 - History of RUP - lang_en_vs6.srt b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/2 - History of RUP - lang_en_vs6.srt
new file mode 100644
index 0000000..83a656b
--- /dev/null
+++ b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/2 - History of RUP - lang_en_vs6.srt	
@@ -0,0 +1,115 @@
+1
+00:00:00,320 --> 00:00:02,252
+As I just said, today we're going to talk about the
+
+2
+00:00:02,252 --> 00:00:04,876
+Rational Unified Process. And you know that I like to provide
+
+3
+00:00:04,876 --> 00:00:07,632
+the historical perspective of the topics that we cover in class
+
+4
+00:00:07,632 --> 00:00:10,070
+and this lesson is no exception. So let's see a little bit
+
+5
+00:00:10,070 --> 00:00:12,500
+of history of RUP. To do that we have to go
+
+6
+00:00:12,500 --> 00:00:17,620
+back to 1997 when Rational defined six best practices for modern software
+
+7
+00:00:17,620 --> 00:00:20,930
+engineering. So let's look at what these practices were. The first
+
+8
+00:00:20,930 --> 00:00:25,330
+practice involved developing in an iterative way with risk as the primary
+
+9
+00:00:25,330 --> 00:00:27,700
+iteration driver. The second practice had to do
+
+10
+00:00:27,700 --> 00:00:31,375
+with managing requirements, including updating them and keeping
+
+11
+00:00:31,375 --> 00:00:34,570
+traceability information between requirements and other software
+
+12
+00:00:34,570 --> 00:00:37,675
+artifacts. Practice number three was to employ a
+
+13
+00:00:37,675 --> 00:00:40,830
+component-based architecture. What that means is to have
+
+14
+00:00:40,830 --> 00:00:43,540
+a high level design that focuses on cooperating
+
+15
+00:00:43,540 --> 00:00:46,780
+components that are nevertheless very cohesive and highly
+
+16
+00:00:46,780 --> 00:00:50,710
+decoupled. Modeling software visually is another key aspect
+
+17
+00:00:50,710 --> 00:00:53,250
+of the rational unified process. And the key concept
+
+18
+00:00:53,250 --> 00:00:56,070
+here is to use visual diagrams, and in particular UML
+
+19
+00:00:56,070 --> 00:00:58,520
+visual diagrams, in a very extensive way so as
+
+20
+00:00:58,520 --> 00:01:01,950
+to make artifacts easier to understand and agree upon among
+
+21
+00:01:01,950 --> 00:01:04,849
+stakeholders. And the fact that the process is defined
+
+22
+00:01:04,849 --> 00:01:08,510
+in an iterative way, allows for performing quality assurance activities
+
+23
+00:01:08,510 --> 00:01:11,430
+in a continuous way. So it allows for continuously
+
+24
+00:01:11,430 --> 00:01:13,860
+verifying quality throughout the development
+
+25
+00:01:13,860 --> 00:01:16,220
+process. Finally, change management and
+
+26
+00:01:16,220 --> 00:01:18,750
+control were also at the center of the rational
+
+27
+00:01:18,750 --> 00:01:22,100
+approach These six practices, that I just mentioned were
+
+28
+00:01:22,100 --> 00:01:24,740
+the starting point for the development of the Rational
+
+29
+00:01:24,740 --> 00:01:27,300
+Unified Process, which is what we're going to discuss next.
diff --git a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/20 - Phases and Iterations - lang_en_vs4.srt b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/20 - Phases and Iterations - lang_en_vs4.srt
new file mode 100644
index 0000000..01689f9
--- /dev/null
+++ b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/20 - Phases and Iterations - lang_en_vs4.srt	
@@ -0,0 +1,107 @@
+1
+00:00:00,170 --> 00:00:02,210
+So now I would like to wrap up this lesson
+
+2
+00:00:02,210 --> 00:00:05,720
+by going back to our discussion of rational unified process
+
+3
+00:00:05,720 --> 00:00:08,630
+phases and iterations. So to do that I'm going to bring
+
+4
+00:00:08,630 --> 00:00:12,480
+back the presentation that I used before, the summary representation
+
+5
+00:00:12,480 --> 00:00:16,840
+about phases and traditional software engineering activities. And I want to
+
+6
+00:00:16,840 --> 00:00:19,720
+use this representation to stress and discuss a couple of
+
+7
+00:00:19,720 --> 00:00:22,140
+things. Mainly I want to recap it because I think
+
+8
+00:00:22,140 --> 00:00:25,480
+it is very important. What is the relation between the rational
+
+9
+00:00:25,480 --> 00:00:29,270
+unified process, and the traditional software engineering phases, and software
+
+10
+00:00:29,270 --> 00:00:31,540
+engineering activities? And I like to do it now that
+
+11
+00:00:31,540 --> 00:00:33,648
+we have discussed the phases in a little more detail.
+
+12
+00:00:33,648 --> 00:00:35,920
+So I want to make sure that it is clear by now
+
+13
+00:00:35,920 --> 00:00:39,660
+how and when the traditional software engineering activities, the ones
+
+14
+00:00:39,660 --> 00:00:42,620
+listed here, take place in the context of the RUP
+
+15
+00:00:42,620 --> 00:00:45,850
+phases, the four listed up here. For instance, it should
+
+16
+00:00:45,850 --> 00:00:50,410
+be clear why implementation takes place mainly in the construction phase.
+
+17
+00:00:50,410 --> 00:00:54,140
+Why requirements engineering is prominent in the elaboration phase
+
+18
+00:00:54,140 --> 00:00:58,290
+and why deployment activities occur mostly in the transition phase,
+
+19
+00:00:58,290 --> 00:01:00,120
+and so on. So it should be clear now
+
+20
+00:01:00,120 --> 00:01:03,930
+why the activities are so distributed in the four phases.
+
+21
+00:01:03,930 --> 00:01:06,130
+It should also be clear that although there is
+
+22
+00:01:06,130 --> 00:01:09,350
+normally one main phase for each activity, the activities really
+
+23
+00:01:09,350 --> 00:01:12,550
+span multiple phases. Which is actually one of the interesting
+
+24
+00:01:12,550 --> 00:01:15,580
+aspect of RUP. So the fact that you're not really
+
+25
+00:01:15,580 --> 00:01:19,700
+done with an activity even in later phases. Why? Well, because that allows
+
+26
+00:01:19,700 --> 00:01:22,070
+you, in subsequent iterations, to address
+
+27
+00:01:22,070 --> 00:01:24,370
+problems that came up in previous iterations.
diff --git a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/3 - Key Features of RUP - lang_en_vs6.srt b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/3 - Key Features of RUP - lang_en_vs6.srt
new file mode 100644
index 0000000..74dc52a
--- /dev/null
+++ b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/3 - Key Features of RUP - lang_en_vs6.srt	
@@ -0,0 +1,103 @@
+1
+00:00:00,300 --> 00:00:03,450
+So let's start by seeing how these activities and principles
+
+2
+00:00:03,450 --> 00:00:06,640
+are reflected in the key features of the Rational Unified
+
+3
+00:00:06,640 --> 00:00:10,010
+Process. First of all, the Rational Unified Process is a
+
+4
+00:00:10,010 --> 00:00:13,700
+software process model. So if you recall our introductory lessons,
+
+5
+00:00:13,700 --> 00:00:16,670
+that means two main things. The first one is that
+
+6
+00:00:16,670 --> 00:00:19,200
+it defines an order of phases that have to be
+
+7
+00:00:19,200 --> 00:00:21,970
+followed in the software process. And the second thing is
+
+8
+00:00:21,970 --> 00:00:25,420
+that it also prescribes transition criteria, so when to go
+
+9
+00:00:25,420 --> 00:00:28,030
+from one phase to the next. The second key
+
+10
+00:00:28,030 --> 00:00:31,290
+feature of RUP is that it is component based. And
+
+11
+00:00:31,290 --> 00:00:33,810
+also in this case, this implies two main things.
+
+12
+00:00:33,810 --> 00:00:36,410
+The first one is that a software system is defined
+
+13
+00:00:36,410 --> 00:00:39,420
+and built as a set of software components. So
+
+14
+00:00:39,420 --> 00:00:43,110
+software components are the building blocks of our software system.
+
+15
+00:00:43,110 --> 00:00:45,550
+And the second one is that there must be well-defined
+
+16
+00:00:45,550 --> 00:00:48,440
+interfaces between these components, interfaces
+
+17
+00:00:48,440 --> 00:00:50,750
+through which these components communicate.
+
+18
+00:00:50,750 --> 00:00:53,020
+In addition, the Rational Unified Process is
+
+19
+00:00:53,020 --> 00:00:56,080
+tightly related to UML. And in particular, it
+
+20
+00:00:56,080 --> 00:00:58,820
+relies extensively on UML for its notation, and
+
+21
+00:00:58,820 --> 00:01:02,120
+with respect to its basic principles. Finally, the
+
+22
+00:01:02,120 --> 00:01:05,140
+three main distinguishing aspects of the Rational Unified
+
+23
+00:01:05,140 --> 00:01:09,830
+Process are that it is use-case driven, architecture-centric
+
+24
+00:01:09,830 --> 00:01:12,680
+and iterative and incremental. So let's now look
+
+25
+00:01:12,680 --> 00:01:15,565
+in more detail at these three distinguishing aspects,
+
+26
+00:01:15,565 --> 00:01:17,540
+and we're going to look at each one of them individually.
diff --git a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/4 - UML Quiz - lang_en_vs5.srt b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/4 - UML Quiz - lang_en_vs5.srt
new file mode 100644
index 0000000..4f4af17
--- /dev/null
+++ b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/4 - UML Quiz - lang_en_vs5.srt	
@@ -0,0 +1,47 @@
+1
+00:00:00,160 --> 00:00:03,440
+Before doing that though, let's have a quiz to check whether you remember
+
+2
+00:00:03,440 --> 00:00:07,160
+the basics of UML. Since we're going to talk about use cases, I want
+
+3
+00:00:07,160 --> 00:00:10,040
+to ask you, what is the difference between a use case and a
+
+4
+00:00:10,040 --> 00:00:13,330
+use case model. So here are the possible answers, and you can mark
+
+5
+00:00:13,330 --> 00:00:16,710
+more than one. First one is that only use case models include actors.
+
+6
+00:00:16,710 --> 00:00:19,150
+The second is that they are the same thing. The third one is
+
+7
+00:00:19,150 --> 00:00:22,000
+that a use case model is a set of use cases. The fourth
+
+8
+00:00:22,000 --> 00:00:24,950
+one says that a use case is a set of use case models.
+
+9
+00:00:24,950 --> 00:00:26,520
+Finally, the last one says that use cases
+
+10
+00:00:26,520 --> 00:00:29,650
+are a dynamic representation, whereas use case models
+
+11
+00:00:29,650 --> 00:00:31,880
+are a static representation of a system. So
+
+12
+00:00:31,880 --> 00:00:33,810
+mark all the answers that you think are correct.
diff --git a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/5 - UML Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/5 - UML Quiz Solution - lang_en_vs4.srt
new file mode 100644
index 0000000..c107545
--- /dev/null
+++ b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/5 - UML Quiz Solution - lang_en_vs4.srt	
@@ -0,0 +1,15 @@
+1
+00:00:00,150 --> 00:00:02,350
+And the correct answer, in this case it's only one,
+
+2
+00:00:02,350 --> 00:00:04,720
+is that a use case model is a set of use
+
+3
+00:00:04,720 --> 00:00:07,390
+cases. So a use case model is simply a collection of
+
+4
+00:00:07,390 --> 00:00:10,790
+use cases that represent different pieces of functionality for the system.
diff --git a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/6 - UML Quiz - lang_en_vs6.srt b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/6 - UML Quiz - lang_en_vs6.srt
new file mode 100644
index 0000000..c2627aa
--- /dev/null
+++ b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/6 - UML Quiz - lang_en_vs6.srt	
@@ -0,0 +1,39 @@
+1
+00:00:00,330 --> 00:00:02,650
+So, since we are talking about use case diagrams, I also want
+
+2
+00:00:02,650 --> 00:00:05,593
+to ask you, what are use case diagrams used for? So, what
+
+3
+00:00:05,593 --> 00:00:08,600
+are they good for? Why are they useful within a software process?
+
+4
+00:00:08,600 --> 00:00:12,130
+Also in this case, I'm providing several possible answers. They are not really
+
+5
+00:00:12,130 --> 00:00:15,420
+used for anything. Or, they can be used to prioritize requirements. Or,
+
+6
+00:00:15,420 --> 00:00:18,220
+maybe they can be used for user interface design. They can be
+
+7
+00:00:18,220 --> 00:00:20,280
+used during requirements elicitation. They can
+
+8
+00:00:20,280 --> 00:00:21,890
+be used for code optimization. And
+
+9
+00:00:21,890 --> 00:00:25,570
+finally, they can be used for test case design. Also, in this case,
+
+10
+00:00:25,570 --> 00:00:28,650
+I would like you to mark all the answers that you think are correct.
diff --git a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/7 - UML Quiz Solution - lang_en_vs6.srt b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/7 - UML Quiz Solution - lang_en_vs6.srt
new file mode 100644
index 0000000..c201e96
--- /dev/null
+++ b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/7 - UML Quiz Solution - lang_en_vs6.srt	
@@ -0,0 +1,143 @@
+1
+00:00:00,140 --> 00:00:02,910
+In this case there are multiple, correct answers. So you should have
+
+2
+00:00:02,910 --> 00:00:05,800
+marked several of those. So let's go through the list. Well this
+
+3
+00:00:05,800 --> 00:00:08,970
+is definitely not true. They are used for something. The second answer,
+
+4
+00:00:08,970 --> 00:00:11,880
+is a correct one, because you can order, the use cases that
+
+5
+00:00:11,880 --> 00:00:13,320
+you planned to realize, according to
+
+6
+00:00:13,320 --> 00:00:15,580
+your prioritization criteria. So basically what
+
+7
+00:00:15,580 --> 00:00:19,100
+you're doing you're prioritizing either in terms of functionality. So you, you
+
+8
+00:00:19,100 --> 00:00:21,680
+can decide which piece of functionality you want to realize first in
+
+9
+00:00:21,680 --> 00:00:25,430
+your system. Or you can also prioritize based on the actors involved.
+
+10
+00:00:25,430 --> 00:00:27,530
+Maybe there are some actors, maybe there are some user
+
+11
+00:00:27,530 --> 00:00:30,580
+roles that you want to support before others, and we'll
+
+12
+00:00:30,580 --> 00:00:33,580
+see some examples of that. The next correct question is
+
+13
+00:00:33,580 --> 00:00:37,190
+that they can be used for requirements elicitation. Why? Well
+
+14
+00:00:37,190 --> 00:00:40,130
+because used cases express what the system is supposed to
+
+15
+00:00:40,130 --> 00:00:43,490
+do for each user. They're an ideal way to collect,
+
+16
+00:00:43,490 --> 00:00:47,110
+represent, and check functional requirements. And we'll also get back
+
+17
+00:00:47,110 --> 00:00:50,700
+to this. And finally, use cases can definitely be used
+
+18
+00:00:50,700 --> 00:00:54,160
+for test case design. So why is that? Because each
+
+19
+00:00:54,160 --> 00:00:58,500
+use case represents a scenario of interaction between users and the
+
+20
+00:00:58,500 --> 00:01:03,470
+system. So testers can very naturally construct test cases based
+
+21
+00:01:03,470 --> 00:01:06,570
+on use cases. And in addition, and most importantly, they can
+
+22
+00:01:06,570 --> 00:01:09,320
+do that even in the absence of code that realizes
+
+23
+00:01:09,320 --> 00:01:11,490
+a use case. So they can do it as soon as
+
+24
+00:01:11,490 --> 00:01:13,740
+they have the requirements. They don't have to wait until the
+
+25
+00:01:13,740 --> 00:01:16,150
+code is ready. So this is not very a important point.
+
+26
+00:01:16,150 --> 00:01:18,400
+So you can have your test cases ready even before
+
+27
+00:01:18,400 --> 00:01:21,150
+writing the code. And now for completeness. Even though this is
+
+28
+00:01:21,150 --> 00:01:23,787
+not listed in the quiz. I also want to mention two
+
+29
+00:01:23,787 --> 00:01:27,040
+additional uses for use cases. The first one is that use
+
+30
+00:01:27,040 --> 00:01:30,080
+cases can be used to estimate effort as we will discuss
+
+31
+00:01:30,080 --> 00:01:32,710
+in more detail in mini course four, when we talk about
+
+32
+00:01:32,710 --> 00:01:35,770
+agile software development. And they can also be used by
+
+33
+00:01:35,770 --> 00:01:38,290
+customers to assess requirements. Which
+
+34
+00:01:38,290 --> 00:01:41,170
+is another fundamentally important role of
+
+35
+00:01:41,170 --> 00:01:44,640
+the use cases. They provide a common language between the customers
+
+36
+00:01:44,640 --> 00:01:47,850
+and the developers which makes it easier to collect the right requirements.
diff --git a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/8 - Use Case Driven - lang_en_vs5.srt b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/8 - Use Case Driven - lang_en_vs5.srt
new file mode 100644
index 0000000..14ddaab
--- /dev/null
+++ b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/8 - Use Case Driven - lang_en_vs5.srt	
@@ -0,0 +1,71 @@
+1
+00:00:00,150 --> 00:00:02,370
+Now let's go back to the distinguishing aspects of
+
+2
+00:00:02,370 --> 00:00:04,710
+RUP, starting from the first one. That is, that the
+
+3
+00:00:04,710 --> 00:00:08,170
+rational unified process is use-case driven. So let's see what
+
+4
+00:00:08,170 --> 00:00:11,310
+that means. Generally speaking, we can see a system as
+
+5
+00:00:11,310 --> 00:00:14,500
+something that performs a sequence of actions in response to
+
+6
+00:00:14,500 --> 00:00:18,100
+user inputs. So the user submits some requests, or requests
+
+7
+00:00:18,100 --> 00:00:22,140
+some functionality, and the system responds to those requests. Use
+
+8
+00:00:22,140 --> 00:00:25,750
+cases, as we just said, capture exactly this interaction and
+
+9
+00:00:25,750 --> 00:00:28,620
+answer the question, what is the system supposed to do
+
+10
+00:00:28,620 --> 00:00:32,150
+for each user? So, this is a very important point.
+
+11
+00:00:32,150 --> 00:00:34,160
+So they can represent what a system can do for
+
+12
+00:00:34,160 --> 00:00:37,240
+each of the different types of users of the system.
+
+13
+00:00:37,240 --> 00:00:39,430
+For this reason, and as we will see in more
+
+14
+00:00:39,430 --> 00:00:42,430
+detail, in the rational unified process, use cases are a
+
+15
+00:00:42,430 --> 00:00:46,680
+central element of the whole development life cycle. From requirements
+
+16
+00:00:46,680 --> 00:00:51,360
+engineering, all the way through the process until testing and maintenance.
+
+17
+00:00:51,360 --> 00:00:54,620
+So, once more, use cases are used to support and
+
+18
+00:00:54,620 --> 00:00:58,162
+help each one of these phases in the rational unified process.
diff --git a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/9 - Architecture Centric - lang_en_vs5.srt b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/9 - Architecture Centric - lang_en_vs5.srt
new file mode 100644
index 0000000..b0f5487
--- /dev/null
+++ b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/9 - Architecture Centric - lang_en_vs5.srt	
@@ -0,0 +1,131 @@
+1
+00:00:00,180 --> 00:00:02,760
+The second distinguishing aspect of RUP is that it
+
+2
+00:00:02,760 --> 00:00:06,290
+is architecture-centric. As we saw in the first lesson
+
+3
+00:00:06,290 --> 00:00:09,340
+of this mini-course, a software architecture is a view
+
+4
+00:00:09,340 --> 00:00:12,740
+of the entire system that represents all high level
+
+5
+00:00:12,740 --> 00:00:15,710
+principal design decisions. Another way to see this is
+
+6
+00:00:15,710 --> 00:00:18,640
+by saying that use cases define the function of
+
+7
+00:00:18,640 --> 00:00:22,220
+the system, where as architecture defines the form of
+
+8
+00:00:22,220 --> 00:00:25,260
+the system. Use cases give the functionality, architecture tells
+
+9
+00:00:25,260 --> 00:00:28,670
+you how the system should be structured to provide the functionality.
+
+10
+00:00:28,670 --> 00:00:31,000
+So how do we define a software architecture in the rational
+
+11
+00:00:31,000 --> 00:00:33,730
+unified process. Also in this case this happens through
+
+12
+00:00:33,730 --> 00:00:37,340
+a sort of a iterative process. We start by creating a rough
+
+13
+00:00:37,340 --> 00:00:40,070
+outline of the system. And in this case we do it
+
+14
+00:00:40,070 --> 00:00:44,260
+independently from the functionality. So this is just the general structure
+
+15
+00:00:44,260 --> 00:00:46,770
+of the system. For example, we model aspects such as the
+
+16
+00:00:46,770 --> 00:00:50,840
+platform on which the system will run, the overall style. For example,
+
+17
+00:00:50,840 --> 00:00:52,780
+whether it's a client server or a peer to peer
+
+18
+00:00:52,780 --> 00:00:56,450
+system and so on. We then use the key use cases
+
+19
+00:00:56,450 --> 00:01:00,550
+in our use case diagram to define the main subsystems of
+
+20
+00:01:00,550 --> 00:01:03,470
+my architecture. For example, in the case of a banking IT
+
+21
+00:01:03,470 --> 00:01:07,150
+system, one of these subsystems might be the withdrawal system. So
+
+22
+00:01:07,150 --> 00:01:09,410
+what will happen in that case is that we will have
+
+23
+00:01:09,410 --> 00:01:13,240
+some use case that refers to the withdrawal activity, and by
+
+24
+00:01:13,240 --> 00:01:16,470
+analyzing that use case, we'll realize that we need a subsystem
+
+25
+00:01:16,470 --> 00:01:19,810
+that implements that piece of functionality. So again, we use
+
+26
+00:01:19,810 --> 00:01:22,680
+the key use cases to identify and define the key
+
+27
+00:01:22,680 --> 00:01:26,290
+subsystems for my architecture. So once we have that we
+
+28
+00:01:26,290 --> 00:01:30,510
+keep refining the architecture by using additional use cases. So
+
+29
+00:01:30,510 --> 00:01:33,030
+considering more and more pieces of functionality that will help
+
+30
+00:01:33,030 --> 00:01:35,430
+us to refine the architecture of the system and also
+
+31
+00:01:35,430 --> 00:01:39,260
+leveraging our increasing understanding of the system that we're modeling.
+
+32
+00:01:39,260 --> 00:01:41,470
+And this will continue until we are happy with the
+
+33
+00:01:41,470 --> 00:01:42,550
+architecture that we define.
diff --git a/usth/ICT2.7/P4L1 General Concepts Subtitles/1 - Lesson Overview - lang_en_vs5.srt b/usth/ICT2.7/P4L1 General Concepts Subtitles/1 - Lesson Overview - lang_en_vs5.srt
new file mode 100644
index 0000000..df7cdbe
--- /dev/null
+++ b/usth/ICT2.7/P4L1 General Concepts Subtitles/1 - Lesson Overview - lang_en_vs5.srt	
@@ -0,0 +1,91 @@
+1
+00:00:00,700 --> 00:00:03,682
+Hello, and welcome back. In the previous
+
+2
+00:00:03,682 --> 00:00:07,160
+mini course we covered software design, discussed the
+
+3
+00:00:07,160 --> 00:00:10,020
+UML and the unified software process, and worked
+
+4
+00:00:10,020 --> 00:00:12,160
+on a complex project in which we developed
+
+5
+00:00:12,160 --> 00:00:16,020
+a distributed software system. In this mini course,
+
+6
+00:00:16,020 --> 00:00:17,900
+which is the last one for this class,
+
+7
+00:00:17,900 --> 00:00:21,080
+we will cover my very favorite topic, software
+
+8
+00:00:21,080 --> 00:00:24,850
+testing or more generally, software verification and validation.
+
+9
+00:00:25,860 --> 00:00:28,850
+So why do I love software testing? Well,
+
+10
+00:00:28,850 --> 00:00:32,430
+I love it because it is extremely important. It
+
+11
+00:00:32,430 --> 00:00:38,330
+is very challenging and it is fun but only if you do it in the right way.
+
+12
+00:00:38,330 --> 00:00:40,900
+In the upcoming lessons we will discuss why
+
+13
+00:00:40,900 --> 00:00:44,710
+software verification is important, why software testing, which is
+
+14
+00:00:44,710 --> 00:00:47,730
+a specific type of verification, is important, and
+
+15
+00:00:47,730 --> 00:00:50,730
+what are the main techniques for performing software testing.
+
+16
+00:00:51,910 --> 00:00:54,866
+We will also discuss test-driven development and agile methods,
+
+17
+00:00:54,866 --> 00:00:57,780
+in which we'll lose some of the rigidity of
+
+18
+00:00:57,780 --> 00:01:01,340
+the earlier processes and turn things around by writing
+
+19
+00:01:01,340 --> 00:01:04,260
+tests before we write the code and then writing
+
+20
+00:01:04,260 --> 00:01:08,280
+code that makes the test pass. Finally, we will
+
+21
+00:01:08,280 --> 00:01:10,750
+perform a project, in which you get to apply
+
+22
+00:01:10,750 --> 00:01:14,010
+most of the principles and practices of agile development
+
+23
+00:01:14,010 --> 00:01:17,430
+in a realistic scenario. So let's jump right in.
diff --git a/usth/ICT2.7/P4L1 General Concepts Subtitles/10 - Verification Approaches - lang_en_vs4.srt b/usth/ICT2.7/P4L1 General Concepts Subtitles/10 - Verification Approaches - lang_en_vs4.srt
new file mode 100644
index 0000000..a671818
--- /dev/null
+++ b/usth/ICT2.7/P4L1 General Concepts Subtitles/10 - Verification Approaches - lang_en_vs4.srt	
@@ -0,0 +1,239 @@
+1
+00:00:00,320 --> 00:00:01,630
+Now that we got out of the way this
+
+2
+00:00:01,630 --> 00:00:04,460
+initial set of basic definitions. Let's go back to our
+
+3
+00:00:04,460 --> 00:00:08,770
+main concept, which is software verification. We said that software
+
+4
+00:00:08,770 --> 00:00:11,730
+is buggy, and because software is buggy, we need to
+
+5
+00:00:11,730 --> 00:00:14,690
+verify the software as much as we can. But how
+
+6
+00:00:14,690 --> 00:00:17,960
+can we verify software? There are several ways to verify
+
+7
+00:00:17,960 --> 00:00:21,150
+a software system. Among those, we will discuss four mainstream
+
+8
+00:00:21,150 --> 00:00:25,410
+approaches. The first one is testing, also called dynamic verification.
+
+9
+00:00:25,410 --> 00:00:29,400
+The second approach is static verification. The third approach is
+
+10
+00:00:29,400 --> 00:00:33,000
+inspections. And finally, we're going to consider a fourth approach which is
+
+11
+00:00:33,000 --> 00:00:36,090
+formal proofs of correctness. So what I'm going to do
+
+12
+00:00:36,090 --> 00:00:39,570
+next, I'm going to first provide an overview of these approaches and
+
+13
+00:00:39,570 --> 00:00:41,930
+then discuss some of them in more depth and please
+
+14
+00:00:41,930 --> 00:00:44,430
+note that although we will discuss all four approaches we will
+
+15
+00:00:44,430 --> 00:00:47,350
+spend most of our time on software testing. As software
+
+16
+00:00:47,350 --> 00:00:50,850
+testing is the most popular and most used approach in industry.
+
+17
+00:00:50,850 --> 00:00:53,050
+So let's start with our overview and in particular
+
+18
+00:00:53,050 --> 00:00:58,050
+with testing. Testing a software system means exercising the system
+
+19
+00:00:58,050 --> 00:01:01,680
+to try to make it fail. More precisely, let's consider
+
+20
+00:01:01,680 --> 00:01:04,440
+a program. Its input domain, which is the set of
+
+21
+00:01:04,440 --> 00:01:06,990
+all the possible inputs for the program and, its output
+
+22
+00:01:06,990 --> 00:01:09,470
+domain, which is a set of all the possible corresponding
+
+23
+00:01:09,470 --> 00:01:13,010
+outputs. Given this context, we can define what a test
+
+24
+00:01:13,010 --> 00:01:16,360
+case is. A test case is a pair that consists
+
+25
+00:01:16,360 --> 00:01:19,090
+of a, an input from the input domain D,
+
+26
+00:01:19,090 --> 00:01:22,620
+and then, expected output O from the output domain.
+
+27
+00:01:22,620 --> 00:01:25,950
+And O is the element in the output domain
+
+28
+00:01:25,950 --> 00:01:29,670
+that a correct software would produce when ran against I.
+
+29
+00:01:29,670 --> 00:01:32,170
+We can also define the concept of test suite,
+
+30
+00:01:32,170 --> 00:01:34,840
+which is a set of test cases, and we're going to
+
+31
+00:01:34,840 --> 00:01:37,730
+use these two concepts of test case and test
+
+32
+00:01:37,730 --> 00:01:41,400
+suite quite a bit in the rest of the lessons.
+
+33
+00:01:41,400 --> 00:01:44,980
+Subject verification, tries to identify specific classes of problems
+
+34
+00:01:44,980 --> 00:01:47,620
+in the program. Such as null pointer dereferences. And
+
+35
+00:01:47,620 --> 00:01:49,750
+unlike testing, what it does is that it does
+
+36
+00:01:49,750 --> 00:01:53,610
+not just consider individual inputs, it instead considers all
+
+37
+00:01:53,610 --> 00:01:56,594
+possible inputs for the program. So it consider in
+
+38
+00:01:56,594 --> 00:01:59,366
+a sense all possible executions of the program and
+
+39
+00:01:59,366 --> 00:02:02,402
+all possible behaviors of the program, that's why we
+
+40
+00:02:02,402 --> 00:02:06,560
+save the verification unlike testing it's complete. The 3rd technique
+
+41
+00:02:06,560 --> 00:02:08,755
+we are going to consider is inspections,
+
+42
+00:02:08,755 --> 00:02:12,804
+and inspections are also called reviews or walkthroughs.
+
+43
+00:02:12,804 --> 00:02:15,010
+And unlike the previous techniques, inspections are a
+
+44
+00:02:15,010 --> 00:02:18,660
+human intensive activity, more precisely, they are a
+
+45
+00:02:18,660 --> 00:02:22,520
+manual and group activity in which several
+
+46
+00:02:22,520 --> 00:02:25,700
+people from the organization that developed the software,
+
+47
+00:02:25,700 --> 00:02:29,190
+look at the code or other artifacts developed
+
+48
+00:02:29,190 --> 00:02:31,888
+during the software production and try to identify
+
+49
+00:02:31,888 --> 00:02:35,950
+defects in these artifacts. And interestingly inspections
+
+50
+00:02:35,950 --> 00:02:37,580
+have been shown to be quite effective in
+
+51
+00:02:37,580 --> 00:02:39,820
+practice and that's the reason why they're used
+
+52
+00:02:39,820 --> 00:02:42,550
+quite widely in the industry. Finally, the last
+
+53
+00:02:42,550 --> 00:02:45,100
+technique I want to mention is Formal
+
+54
+00:02:45,100 --> 00:02:49,650
+Proof (of correctness). Given a software specification, and
+
+55
+00:02:49,650 --> 00:02:53,370
+actually a formal specification, so a document that
+
+56
+00:02:53,370 --> 00:02:57,410
+formally defines and specifies the behavior, the expected
+
+57
+00:02:57,410 --> 00:03:00,320
+behavior of the program. A form of proof of
+
+58
+00:03:00,320 --> 00:03:05,400
+correctness proves that the program being verified, actually implements
+
+59
+00:03:05,400 --> 00:03:07,922
+the program specification and it does that through a
+
+60
+00:03:07,922 --> 00:03:12,880
+sophisticated mathematical analysis of the specifications and of the code.
diff --git a/usth/ICT2.7/P4L1 General Concepts Subtitles/11 - Pros and Cons of Approaches - lang_en_vs4.srt b/usth/ICT2.7/P4L1 General Concepts Subtitles/11 - Pros and Cons of Approaches - lang_en_vs4.srt
new file mode 100644
index 0000000..36a58ee
--- /dev/null
+++ b/usth/ICT2.7/P4L1 General Concepts Subtitles/11 - Pros and Cons of Approaches - lang_en_vs4.srt	
@@ -0,0 +1,195 @@
+1
+00:00:00,230 --> 00:00:02,870
+The four different techniques that we just discussed have
+
+2
+00:00:02,870 --> 00:00:06,120
+a number of pros and cons. So next we
+
+3
+00:00:06,120 --> 00:00:08,780
+are going to discuss the main pros and cons
+
+4
+00:00:08,780 --> 00:00:11,140
+for these techniques, so as to be able to compare
+
+5
+00:00:11,140 --> 00:00:14,330
+them. When testing is concerned the main positive about
+
+6
+00:00:14,330 --> 00:00:17,600
+this technique is that it does not generate false
+
+7
+00:00:17,600 --> 00:00:21,740
+alarms. In other words, it doesn't generate false positives.
+
+8
+00:00:21,740 --> 00:00:25,180
+What that means, is that when testing generates a failure,
+
+9
+00:00:25,180 --> 00:00:27,230
+that means that there is an actual problem in the
+
+10
+00:00:27,230 --> 00:00:30,060
+code. The main limitation of testing, however, is that it
+
+11
+00:00:30,060 --> 00:00:33,680
+is highly incomplete. Consider again the picture that we drew
+
+12
+00:00:33,680 --> 00:00:36,430
+a little earlier. The one representing the input domain of
+
+13
+00:00:36,430 --> 00:00:39,430
+the program being tested. Even in the best scenario, testing
+
+14
+00:00:39,430 --> 00:00:44,050
+can consider only a tiny fraction of the problem domain,
+
+15
+00:00:44,050 --> 00:00:47,430
+and therefor a tiny fraction of the program's behavior, and
+
+16
+00:00:47,430 --> 00:00:50,308
+we'll say a lot more about that in the following lessons.
+
+17
+00:00:50,308 --> 00:00:53,780
+Static verification, unlike testing, has the main advantage
+
+18
+00:00:53,780 --> 00:00:57,320
+that it considers all program behaviors. If we
+
+19
+00:00:57,320 --> 00:01:00,370
+look back at our diagram, whereas testing will
+
+20
+00:01:00,370 --> 00:01:04,010
+select only a few of those inputs, static verification
+
+21
+00:01:04,010 --> 00:01:07,120
+will consider them all. Unfortunately, however, this comes
+
+22
+00:01:07,120 --> 00:01:08,990
+with a price. Due to limitation of this
+
+23
+00:01:08,990 --> 00:01:11,490
+kind of analysis and due to infeasibility issues,
+
+24
+00:01:11,490 --> 00:01:15,260
+static verifiation considers not only all the possible behaviours,
+
+25
+00:01:15,260 --> 00:01:18,870
+but also some impossible behaviors. And what that means is
+
+26
+00:01:18,870 --> 00:01:22,472
+that static gratificaition can generate false positives. And this is,
+
+27
+00:01:22,472 --> 00:01:24,590
+in fact, the main issue with static verification techniques. As
+
+28
+00:01:24,590 --> 00:01:28,550
+we will further discuss later in the class, static verification can
+
+29
+00:01:28,550 --> 00:01:31,280
+generate results that are not true. For example, it might
+
+30
+00:01:31,280 --> 00:01:33,970
+report a possible no point of the refernce that cannot
+
+31
+00:01:33,970 --> 00:01:37,590
+actually occur in practice. The strongest point about inspections is
+
+32
+00:01:37,590 --> 00:01:40,950
+that, when they're done in a rigorous way, they're systematic and
+
+33
+00:01:40,950 --> 00:01:43,420
+they result in a thorough analysis of the code.
+
+34
+00:01:43,420 --> 00:01:46,840
+They are nevertheless a manual process, a human process.
+
+35
+00:01:46,840 --> 00:01:49,890
+So they're not formal and their effectiveness may depend
+
+36
+00:01:49,890 --> 00:01:53,560
+on the specific people performing the inspection. So its results
+
+37
+00:01:53,560 --> 00:01:57,150
+can be subjective. Finally, the main pro about formal
+
+38
+00:01:57,150 --> 00:02:01,090
+proofs of correctness is that they provide strong guarantees.
+
+39
+00:02:01,090 --> 00:02:03,740
+They can guarantee that the program is correct, which
+
+40
+00:02:03,740 --> 00:02:06,280
+is not something that any of the other approaches can
+
+41
+00:02:06,280 --> 00:02:09,505
+do, including study verification. But the main limitation of
+
+42
+00:02:09,505 --> 00:02:12,680
+formal proofs is that they need a form of specification,
+
+43
+00:02:12,680 --> 00:02:15,750
+a complete mathematical description of the expected behavior of
+
+44
+00:02:15,750 --> 00:02:19,060
+the whole program, and unfortunately such a specification is rarely
+
+45
+00:02:19,060 --> 00:02:21,920
+available, and it is very complex to build one.
+
+46
+00:02:21,920 --> 00:02:25,170
+In addition, it is also very complex, and possibly expensive,
+
+47
+00:02:25,170 --> 00:02:27,720
+to prove that the program corresponds to a specification.
+
+48
+00:02:27,720 --> 00:02:30,990
+That is a process that requires strong mathematical skills and,
+
+49
+00:02:30,990 --> 00:02:32,551
+therefore, a very specialized personnel.
diff --git a/usth/ICT2.7/P4L1 General Concepts Subtitles/12 - Verification Approaches Quiz - lang_en_vs5.srt b/usth/ICT2.7/P4L1 General Concepts Subtitles/12 - Verification Approaches Quiz - lang_en_vs5.srt
new file mode 100644
index 0000000..a5aa4f7
--- /dev/null
+++ b/usth/ICT2.7/P4L1 General Concepts Subtitles/12 - Verification Approaches Quiz - lang_en_vs5.srt	
@@ -0,0 +1,47 @@
+1
+00:00:00,240 --> 00:00:02,570
+So let's have another simple quiz, and we're going to
+
+2
+00:00:02,570 --> 00:00:05,490
+have our developer Brett introducing the quiz. And the
+
+3
+00:00:05,490 --> 00:00:07,900
+starting point for this quiz is the fact that
+
+4
+00:00:07,900 --> 00:00:11,970
+today, quality assurance, or verification, if you wish, is mostly
+
+5
+00:00:11,970 --> 00:00:15,730
+testing. That is, testing is the most commonly used
+
+6
+00:00:15,730 --> 00:00:19,550
+activity to perform software verification. So now, I'm going to show
+
+7
+00:00:19,550 --> 00:00:22,310
+you a quote, 50% of my company employees are
+
+8
+00:00:22,310 --> 00:00:25,691
+testers and the rest spends 50% of their time testing,
+
+9
+00:00:25,691 --> 00:00:27,347
+so I want to ask you, who said
+
+10
+00:00:27,347 --> 00:00:29,664
+that? I'm going to give you some possibilities. Was
+
+11
+00:00:29,664 --> 00:00:34,215
+that Yogi Berra, Steve Jobs, Henry Ford, Bill
+
+12
+00:00:34,215 --> 00:00:37,360
+Gates or Frank Gehry? Take your best guess.
diff --git a/usth/ICT2.7/P4L1 General Concepts Subtitles/13 - Verification Approaches Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P4L1 General Concepts Subtitles/13 - Verification Approaches Quiz Solution - lang_en_vs4.srt
new file mode 100644
index 0000000..b8a0076
--- /dev/null
+++ b/usth/ICT2.7/P4L1 General Concepts Subtitles/13 - Verification Approaches Quiz Solution - lang_en_vs4.srt	
@@ -0,0 +1,11 @@
+1
+00:00:00,260 --> 00:00:04,090
+And the correct answer is Bill Gates. So this gives you an idea of how
+
+2
+00:00:04,090 --> 00:00:07,070
+important testing is in Microsoft in particular,
+
+3
+00:00:07,070 --> 00:00:09,350
+but in many other software companies in general.
diff --git a/usth/ICT2.7/P4L1 General Concepts Subtitles/14 - Testing Introduction - lang_en_vs4.srt b/usth/ICT2.7/P4L1 General Concepts Subtitles/14 - Testing Introduction - lang_en_vs4.srt
new file mode 100644
index 0000000..70df565
--- /dev/null
+++ b/usth/ICT2.7/P4L1 General Concepts Subtitles/14 - Testing Introduction - lang_en_vs4.srt	
@@ -0,0 +1,119 @@
+1
+00:00:00,340 --> 00:00:02,290
+So let's talk more about testing, as we said a
+
+2
+00:00:02,290 --> 00:00:06,500
+little earlier in the lesson, testing means executing the program on
+
+3
+00:00:06,500 --> 00:00:09,400
+a sample of the input domain, that is of all
+
+4
+00:00:09,400 --> 00:00:12,210
+the possible input data and I really want to stress that
+
+5
+00:00:12,210 --> 00:00:16,190
+this sample is tiny sample of the input domain. There
+
+6
+00:00:16,190 --> 00:00:19,154
+are two important aspects of testing that I'm want to mention here,
+
+7
+00:00:19,154 --> 00:00:22,360
+there first one is that testing is a dynamic technique. And
+
+8
+00:00:22,360 --> 00:00:25,370
+what that means is that the program must be executed in
+
+9
+00:00:25,370 --> 00:00:28,130
+order to perform testing. The second important point is that
+
+10
+00:00:28,130 --> 00:00:32,040
+testing is an optimistic approximation. And what does it mean
+
+11
+00:00:32,040 --> 00:00:35,590
+to be optimistic? Well, it means that the program under
+
+12
+00:00:35,590 --> 00:00:38,820
+test is exercised with a very small subset of all the
+
+13
+00:00:38,820 --> 00:00:41,260
+possible inputs as we just said. And this is done
+
+14
+00:00:41,260 --> 00:00:45,150
+under the assumption that the behavior with any other input
+
+15
+00:00:45,150 --> 00:00:47,770
+is consistent with the behavior shown for the selected subset
+
+16
+00:00:47,770 --> 00:00:51,140
+of input data, that is why it is an optimistic approach.
+
+17
+00:00:51,140 --> 00:00:54,620
+Another concept that I want to mention explicitly, is the
+
+18
+00:00:54,620 --> 00:00:57,930
+concept of successful test. And I'm going to do that,
+
+19
+00:00:57,930 --> 00:01:01,260
+using another quote. This one from Goodenough and Gerhart
+
+20
+00:01:01,260 --> 00:01:03,850
+in their paper Towards a Theory of Test Data Selection,
+
+21
+00:01:03,850 --> 00:01:06,420
+and what the quote says is that a test
+
+22
+00:01:06,420 --> 00:01:10,000
+is successful if the program fails. And this might sound
+
+23
+00:01:10,000 --> 00:01:13,650
+counterintuitive, but the point here is that testing cannot
+
+24
+00:01:13,650 --> 00:01:16,490
+prove the absence of errors, but only reveal their presence.
+
+25
+00:01:16,490 --> 00:01:21,550
+If a set of tests does not produce any failure, we are either in the extremely
+
+26
+00:01:21,550 --> 00:01:24,050
+unlikely case of a correct program, or in
+
+27
+00:01:24,050 --> 00:01:26,650
+the very likely situation of a bad set of
+
+28
+00:01:26,650 --> 00:01:30,932
+tests that are not able to reveal failures of the program. And that is why we
+
+29
+00:01:30,932 --> 00:01:32,730
+say that the test is successful if you
+
+30
+00:01:32,730 --> 00:01:35,110
+can show that there are problems in the program.
diff --git a/usth/ICT2.7/P4L1 General Concepts Subtitles/15 - Testing Granularity Levels - lang_en_vs4.srt b/usth/ICT2.7/P4L1 General Concepts Subtitles/15 - Testing Granularity Levels - lang_en_vs4.srt
new file mode 100644
index 0000000..83df7ea
--- /dev/null
+++ b/usth/ICT2.7/P4L1 General Concepts Subtitles/15 - Testing Granularity Levels - lang_en_vs4.srt	
@@ -0,0 +1,275 @@
+1
+00:00:00,160 --> 00:00:03,050
+And before I start talking about specific testing techniques, there's
+
+2
+00:00:03,050 --> 00:00:05,490
+something else that I want to discuss, which is Testing
+
+3
+00:00:05,490 --> 00:00:09,090
+Granularity Levels. So let's consider a software system, a system
+
+4
+00:00:09,090 --> 00:00:12,310
+made out of components that interact with one another. So the
+
+5
+00:00:12,310 --> 00:00:15,000
+first level that we consider in testing is called Unit
+
+6
+00:00:15,000 --> 00:00:18,490
+Testing, which is the testing of the individual units or modules
+
+7
+00:00:18,490 --> 00:00:20,690
+in isolation. The next step, is to see there are
+
+8
+00:00:20,690 --> 00:00:25,340
+multiple modules and their interactions. And this is called Integration Testing.
+
+9
+00:00:25,340 --> 00:00:28,650
+So, integration testing is the testing of the interactions among
+
+10
+00:00:28,650 --> 00:00:31,460
+different modules. And it can be performed according to different
+
+11
+00:00:31,460 --> 00:00:34,260
+strategies. Depending on the order in which the modules are
+
+12
+00:00:34,260 --> 00:00:37,570
+integrated and on whether we integrate one module at a time
+
+13
+00:00:37,570 --> 00:00:40,510
+or multiple modules together, all at once. And in this
+
+14
+00:00:40,510 --> 00:00:43,240
+latter case, we call this kind of integration testing, the one that
+
+15
+00:00:43,240 --> 00:00:47,640
+integrates all the modules at once, Big Bang integration testing.
+
+16
+00:00:47,640 --> 00:00:50,520
+And after performing integration testing, the next step is to test
+
+17
+00:00:50,520 --> 00:00:52,750
+the complete system as a whole. And this level of
+
+18
+00:00:52,750 --> 00:00:56,190
+testing is normally called, System Testing. So system testing in the
+
+19
+00:00:56,190 --> 00:00:59,560
+testing of the complete system and it includes both functional and
+
+20
+00:00:59,560 --> 00:01:03,250
+non functional testing. We will discuss functional and non functional testing
+
+21
+00:01:03,250 --> 00:01:05,575
+in details in the next two lessons. But I just
+
+22
+00:01:05,575 --> 00:01:08,330
+want to give you an idea of what they are intuitively. Functional
+
+23
+00:01:08,330 --> 00:01:12,250
+tests are the test that aim to verify the functionality provided
+
+24
+00:01:12,250 --> 00:01:15,680
+by the system. For example if you consider the function double
+
+25
+00:01:15,680 --> 00:01:17,840
+value that we saw earlier in the lesson, a
+
+26
+00:01:17,840 --> 00:01:20,660
+functional test will try to assess that that function
+
+27
+00:01:20,660 --> 00:01:23,970
+is producing the right value given a specific input.
+
+28
+00:01:23,970 --> 00:01:26,826
+Conversely, no functional test are the one that target, as
+
+29
+00:01:26,826 --> 00:01:30,540
+surprisingly, no functional properties of the system. For example,
+
+30
+00:01:30,540 --> 00:01:34,060
+no functional test will include performance tests, load tests,
+
+31
+00:01:34,060 --> 00:01:37,310
+robustness tests. In general, no functional tests will try
+
+32
+00:01:37,310 --> 00:01:41,410
+to assess different qualities of the system, such as reliability,
+
+33
+00:01:41,410 --> 00:01:45,970
+maintainability, usability, so basically, all the ilities that you can
+
+34
+00:01:45,970 --> 00:01:49,760
+think about. In addition to these three basic testing levels, there
+
+35
+00:01:49,760 --> 00:01:51,830
+are two more levels that I want to consider and that
+
+36
+00:01:51,830 --> 00:01:55,150
+I want to discuss. And they both involve the whole system.
+
+37
+00:01:55,150 --> 00:01:57,610
+And the first one is Acceptance Testing which is the
+
+38
+00:01:57,610 --> 00:02:01,320
+validation of the software against the Customer requirements. So this is
+
+39
+00:02:01,320 --> 00:02:04,090
+the testing that makes sure that the system does what the
+
+40
+00:02:04,090 --> 00:02:06,720
+customer wants it to do. And the last type of testing
+
+41
+00:02:06,720 --> 00:02:09,729
+that I want to mention is Regression Testing. And regression testing
+
+42
+00:02:09,729 --> 00:02:13,260
+is the type of testing or retesting, that we perform every time
+
+43
+00:02:13,260 --> 00:02:15,540
+that we change our system. And we need to make sure
+
+44
+00:02:15,540 --> 00:02:19,060
+that the changes behave as intended and that the unchanged code is
+
+45
+00:02:19,060 --> 00:02:22,680
+not negatively affected by the modification, by these changes. In fact,
+
+46
+00:02:22,680 --> 00:02:25,070
+what can happen when you modify the code is that parts of
+
+47
+00:02:25,070 --> 00:02:28,120
+the code that are related to the changes, are actually affected
+
+48
+00:02:28,120 --> 00:02:32,110
+by the changes, and start misbehaving. And we call those regression errors.
+
+49
+00:02:32,110 --> 00:02:35,080
+And regression errors, are very common. For example, you're probably
+
+50
+00:02:35,080 --> 00:02:38,070
+familiar with the situation in which, one software update is
+
+51
+00:02:38,070 --> 00:02:41,350
+released, and just a few days later, another software update
+
+52
+00:02:41,350 --> 00:02:44,640
+is released. In many cases that happens because the first update
+
+53
+00:02:44,640 --> 00:02:47,760
+was containing regression errors. So the changes in the code
+
+54
+00:02:47,760 --> 00:02:51,100
+that broke some functionality, that resulted in failures on the user's
+
+55
+00:02:51,100 --> 00:02:53,940
+machine and in bug reports and therefore that caused further
+
+56
+00:02:53,940 --> 00:02:57,090
+maintenance, further bug fixes, and a release on a new version.
+
+57
+00:02:57,090 --> 00:02:59,790
+Something else I'd like to mention about regression testing, is that
+
+58
+00:02:59,790 --> 00:03:02,535
+regression testing is one of the main causes why software maintenance is
+
+59
+00:03:02,535 --> 00:03:05,679
+so expensive. And that's also why researchers have invested a great
+
+60
+00:03:05,679 --> 00:03:07,481
+deal of effort into refining regression
+
+61
+00:03:07,481 --> 00:03:09,495
+testing techniques that can make regression
+
+62
+00:03:09,495 --> 00:03:12,599
+testing more effective and more efficient. So let me leave you,
+
+63
+00:03:12,599 --> 00:03:15,129
+with a little piece of advice which is try to automate as
+
+64
+00:03:15,129 --> 00:03:19,470
+much as possible regression testing. For example use scripts, use tools, make
+
+65
+00:03:19,470 --> 00:03:22,660
+sure to save your harness, make sure to save your input, and
+
+66
+00:03:22,660 --> 00:03:24,820
+outputs for the test, because you want to be able
+
+67
+00:03:24,820 --> 00:03:27,680
+to rerun your test, at a push of a button as
+
+68
+00:03:27,680 --> 00:03:29,750
+much as possible every time you change your code, to
+
+69
+00:03:29,750 --> 00:03:32,560
+avoid the presence of regression errors in the code you release.
diff --git a/usth/ICT2.7/P4L1 General Concepts Subtitles/16 - Alpha and Beta Testing - lang_en_vs4.srt b/usth/ICT2.7/P4L1 General Concepts Subtitles/16 - Alpha and Beta Testing - lang_en_vs4.srt
new file mode 100644
index 0000000..f81f551
--- /dev/null
+++ b/usth/ICT2.7/P4L1 General Concepts Subtitles/16 - Alpha and Beta Testing - lang_en_vs4.srt	
@@ -0,0 +1,95 @@
+1
+00:00:00,510 --> 00:00:02,754
+All the testing levels that we've seen so far is what
+
+2
+00:00:02,754 --> 00:00:06,058
+we can call developer's testing. So that's testing that is performed
+
+3
+00:00:06,058 --> 00:00:09,649
+either within the testing organization, or by somebody who's doing like
+
+4
+00:00:09,649 --> 00:00:13,520
+third-party testers on behalf of the testing organization. But there are two
+
+5
+00:00:13,520 --> 00:00:16,280
+other kinds of testing that are worth mentioning that are also
+
+6
+00:00:16,280 --> 00:00:19,600
+related to testing phases and these are alpha and beta testing.
+
+7
+00:00:19,600 --> 00:00:23,050
+Alpha testing is the testing performed by distributing a software system
+
+8
+00:00:23,050 --> 00:00:26,000
+ready to be released to a set of users that are internal
+
+9
+00:00:26,000 --> 00:00:29,480
+to the organization that developed the software. So you can consider these
+
+10
+00:00:29,480 --> 00:00:32,460
+users as, if you pass me the term, guinea pigs that will
+
+11
+00:00:32,460 --> 00:00:35,170
+use an early version of the code and will likely discover errors
+
+12
+00:00:35,170 --> 00:00:37,850
+that escaped testing and will have made it to the field if
+
+13
+00:00:37,850 --> 00:00:41,390
+not caught. Beta testing is the next step after alpha testing, in
+
+14
+00:00:41,390 --> 00:00:44,530
+which the software is released to a selected subset of users, in
+
+15
+00:00:44,530 --> 00:00:47,770
+this case, outside your organization. And also in this case, the users
+
+16
+00:00:47,770 --> 00:00:51,110
+are likely to discover latent errors in the code before it is officially
+
+17
+00:00:51,110 --> 00:00:54,240
+released to the broader user population, so before we have an
+
+18
+00:00:54,240 --> 00:00:56,850
+actual product release. So you may wonder why do we need
+
+19
+00:00:56,850 --> 00:00:59,360
+to do both alpha and beta testing. Why not just one
+
+20
+00:00:59,360 --> 00:01:02,980
+of the two? The reason is that alpha testing is performed
+
+21
+00:01:02,980 --> 00:01:06,730
+to iron out the very obvious issues that still escape testing,
+
+22
+00:01:06,730 --> 00:01:09,610
+but we want to do that before involving people outside your
+
+23
+00:01:09,610 --> 00:01:12,730
+organization. And the rationale is that alpha testers have a higher
+
+24
+00:01:12,730 --> 00:01:16,710
+tolerance for problems than beta testers, who expect a mostly working system.
diff --git a/usth/ICT2.7/P4L1 General Concepts Subtitles/17 - Black and White Box Testing Introduction - lang_en_vs4.srt b/usth/ICT2.7/P4L1 General Concepts Subtitles/17 - Black and White Box Testing Introduction - lang_en_vs4.srt
new file mode 100644
index 0000000..c61e331
--- /dev/null
+++ b/usth/ICT2.7/P4L1 General Concepts Subtitles/17 - Black and White Box Testing Introduction - lang_en_vs4.srt	
@@ -0,0 +1,115 @@
+1
+00:00:00,370 --> 00:00:02,520
+We're almost at the end of this lesson. In the
+
+2
+00:00:02,520 --> 00:00:05,520
+next two lessons we're going to talk about two main families
+
+3
+00:00:05,520 --> 00:00:07,800
+of testing techniques, black-box testing
+
+4
+00:00:07,800 --> 00:00:10,340
+techniques, and white-box testing techniques. So,
+
+5
+00:00:10,340 --> 00:00:12,730
+what I want to do before getting into the discussion of the
+
+6
+00:00:12,730 --> 00:00:15,385
+specific techniques in this families. I want to give you an
+
+7
+00:00:15,385 --> 00:00:19,440
+overview of what black-box testing and white-box testing are. Black box
+
+8
+00:00:19,440 --> 00:00:21,950
+testing is the kind of testing in which we consider the
+
+9
+00:00:21,950 --> 00:00:25,570
+software as a closed box. That's why it's called black box.
+
+10
+00:00:25,570 --> 00:00:27,770
+So we don't look inside the software, we don't want to
+
+11
+00:00:27,770 --> 00:00:30,131
+look at the code. We just going to look at the description
+
+12
+00:00:30,131 --> 00:00:33,210
+of the software. So this is the testing that is based
+
+13
+00:00:33,210 --> 00:00:36,100
+on a description of the software, which is what we normally
+
+14
+00:00:36,100 --> 00:00:39,690
+call the specification for the software. And what black box testing
+
+15
+00:00:39,690 --> 00:00:44,040
+tries to do is to cover as much specified behavior as
+
+16
+00:00:44,040 --> 00:00:47,290
+possible, and the main limitation black box testing and the reason
+
+17
+00:00:47,290 --> 00:00:51,540
+why this is complimentary to white-box testing is that it cannot reveal
+
+18
+00:00:51,540 --> 00:00:56,590
+errors due to implementation details. Conversely, white-box testing
+
+19
+00:00:56,590 --> 00:00:58,430
+is the kind of testing that looks inside the
+
+20
+00:00:58,430 --> 00:01:00,360
+box. So looks at the code and how
+
+21
+00:01:00,360 --> 00:01:02,760
+the code is written and uses this information to
+
+22
+00:01:02,760 --> 00:01:06,300
+perform the testing. So white-box testing is based
+
+23
+00:01:06,300 --> 00:01:09,120
+on the code, its goal is to cover as
+
+24
+00:01:09,120 --> 00:01:13,210
+much coded behavior in this case, as possible, and
+
+25
+00:01:13,210 --> 00:01:17,100
+its limitation is that unlike black-box testing, it can't
+
+26
+00:01:17,100 --> 00:01:21,880
+reveal errors due to missing paths. Where missing paths are
+
+27
+00:01:21,880 --> 00:01:25,250
+a part of a software specification that are not implemented and
+
+28
+00:01:25,250 --> 00:01:27,320
+the reason why you can not reveal them is because
+
+29
+00:01:27,320 --> 00:01:29,790
+it is focused on the code and not on the specification.
diff --git a/usth/ICT2.7/P4L1 General Concepts Subtitles/18 - Black Box Testing Example - lang_en_vs4.srt b/usth/ICT2.7/P4L1 General Concepts Subtitles/18 - Black Box Testing Example - lang_en_vs4.srt
new file mode 100644
index 0000000..dab72eb
--- /dev/null
+++ b/usth/ICT2.7/P4L1 General Concepts Subtitles/18 - Black Box Testing Example - lang_en_vs4.srt	
@@ -0,0 +1,135 @@
+1
+00:00:00,500 --> 00:00:03,185
+To give you a slightly better understanding of the differences
+
+2
+00:00:03,185 --> 00:00:06,300
+between black-box testing and white-box testing, I am going to provide you
+
+3
+00:00:06,300 --> 00:00:10,040
+a couple of simple examples that illustrate the, the strengths and
+
+4
+00:00:10,040 --> 00:00:12,920
+limitations of these two techniques. So, in this case, let's start
+
+5
+00:00:12,920 --> 00:00:15,750
+with black-box testing, so we're only working with this specification.
+
+6
+00:00:15,750 --> 00:00:18,540
+So, let's say that our specification says that this is a
+
+7
+00:00:18,540 --> 00:00:23,550
+program that inputs an integer value and prints it. And implementation,
+
+8
+00:00:23,550 --> 00:00:25,900
+we don't know because we're working at the black box level.
+
+9
+00:00:25,900 --> 00:00:28,710
+If we wanted to test this function according to its
+
+10
+00:00:28,710 --> 00:00:32,060
+specification, what we will probably do is to select a positive
+
+11
+00:00:32,060 --> 00:00:35,370
+integer, a negative integer, and the zero as test inputs
+
+12
+00:00:35,370 --> 00:00:37,840
+and see how the program behaves for these inputs. So let
+
+13
+00:00:37,840 --> 00:00:41,500
+me now show you a possible implementation for this specification.
+
+14
+00:00:41,500 --> 00:00:44,590
+What I'm showing here is this function that we called print
+
+15
+00:00:44,590 --> 00:00:48,010
+NumBytes, which takes the parameter and prints it. And one thing
+
+16
+00:00:48,010 --> 00:00:50,905
+that we notice right away is that, although in the specification,
+
+17
+00:00:50,905 --> 00:00:53,960
+numbers that are less than 1024 and numbers that
+
+18
+00:00:53,960 --> 00:00:57,320
+are greater or equal to 1024 are exactly equivalent from
+
+19
+00:00:57,320 --> 00:01:01,020
+the specification standpoint. They're however treated differently in the
+
+20
+00:01:01,020 --> 00:01:04,140
+code, so the developer decided that the program was just
+
+21
+00:01:04,140 --> 00:01:06,200
+going to print the value of the parameter if it's
+
+22
+00:01:06,200 --> 00:01:09,300
+less than 1024. But it was actually divided by 1024
+
+23
+00:01:09,300 --> 00:01:13,560
+and printing it with a kilobyte mark after it
+
+24
+00:01:13,560 --> 00:01:16,170
+if you are greater than 1024. And notice that here,
+
+25
+00:01:16,170 --> 00:01:19,370
+there is a problem. The developer, just a number 124, instead
+
+26
+00:01:19,370 --> 00:01:22,840
+of 1024. So there's probably a typo in this point in the
+
+27
+00:01:22,840 --> 00:01:26,260
+code. So this is a case in which by simply doing black-box
+
+28
+00:01:26,260 --> 00:01:28,750
+testing, so by simply looking at the specific issue, we might miss
+
+29
+00:01:28,750 --> 00:01:31,510
+this problem. Because we have no reason to consider numbers that are
+
+30
+00:01:31,510 --> 00:01:34,780
+less than 1024 or greater than 1024. However if we were to
+
+31
+00:01:34,780 --> 00:01:38,010
+look at the code, so operating at white-box manner, we will right
+
+32
+00:01:38,010 --> 00:01:41,340
+away see that we need to have a test case that checks
+
+33
+00:01:41,340 --> 00:01:44,880
+the program when the parameter is greater than 1024. And we will find
+
+34
+00:01:44,880 --> 00:01:47,300
+the problem right away. So now let me show you a dual example.
diff --git a/usth/ICT2.7/P4L1 General Concepts Subtitles/19 - White Box Testing Example - lang_en_vs4.srt b/usth/ICT2.7/P4L1 General Concepts Subtitles/19 - White Box Testing Example - lang_en_vs4.srt
new file mode 100644
index 0000000..896f9b1
--- /dev/null
+++ b/usth/ICT2.7/P4L1 General Concepts Subtitles/19 - White Box Testing Example - lang_en_vs4.srt	
@@ -0,0 +1,143 @@
+1
+00:00:00,080 --> 00:00:03,086
+In this case we focus on white box testing. So consider now this
+
+2
+00:00:03,086 --> 00:00:06,556
+other function, called fun. And let's assume that we want to test this function
+
+3
+00:00:06,556 --> 00:00:09,777
+without having a specification. So without knowing exactly what it needs to do.
+
+4
+00:00:09,777 --> 00:00:12,996
+But just by looking at the code. So we will try to do the
+
+5
+00:00:12,996 --> 00:00:16,030
+problem in this case is to try to just execute all the statements.
+
+6
+00:00:16,030 --> 00:00:18,995
+In the function. And notice I will talk extensively of what does it
+
+7
+00:00:18,995 --> 00:00:22,560
+means to do white box testing later on in the next, two classes.
+
+8
+00:00:22,560 --> 00:00:25,560
+So if that's our goal, if our goal is to cover all the statements,
+
+9
+00:00:25,560 --> 00:00:27,670
+any input will really do. So any test case
+
+10
+00:00:27,670 --> 00:00:30,250
+will excecute all statements in the code. And we'll a
+
+11
+00:00:30,250 --> 00:00:33,801
+complete, you know, white-box testing coverage for the program.
+
+12
+00:00:33,801 --> 00:00:35,865
+Imagine that I now give you a specification for this
+
+13
+00:00:35,865 --> 00:00:39,071
+function. And what the specification says is that this
+
+14
+00:00:39,071 --> 00:00:43,232
+function inputs an integer parameter, param, and returns half of
+
+15
+00:00:43,232 --> 00:00:45,860
+its value, if param is even, and its value
+
+16
+00:00:45,860 --> 00:00:50,740
+unchanged otherwise. That means if param is odd. So looking
+
+17
+00:00:50,740 --> 00:00:54,320
+at this specification, we can clearly see that the function fun
+
+18
+00:00:54,320 --> 00:00:57,740
+works correctly only for even integers, and it doesn't work for
+
+19
+00:00:57,740 --> 00:01:00,570
+odd integers. Because it computes. Half of the value of the
+
+20
+00:01:00,570 --> 00:01:04,410
+parameter and returns it every time, no matter what param is. So
+
+21
+00:01:04,410 --> 00:01:07,320
+this is a case in which white box testing could easily
+
+22
+00:01:07,320 --> 00:01:10,620
+miss the problem, because as we said any input will exercise
+
+23
+00:01:10,620 --> 00:01:12,900
+the code. It's just by chance that we could reveal one
+
+24
+00:01:12,900 --> 00:01:15,750
+that revealed the problem in the code. Conversely if we were to
+
+25
+00:01:15,750 --> 00:01:19,520
+work, in a black box manner. Typically looking at the specification, we
+
+26
+00:01:19,520 --> 00:01:22,390
+will select at least one odd, and one even input number to
+
+27
+00:01:22,390 --> 00:01:25,010
+exercise all of the specified behavior. And we will find the problem
+
+28
+00:01:25,010 --> 00:01:28,110
+right away. So these two examples are just very small examples, and
+
+29
+00:01:28,110 --> 00:01:30,910
+they're kind of, you know, stretched. But these kind of issues occur
+
+30
+00:01:30,910 --> 00:01:33,680
+on a much bigger scale and in much more subtle ways in
+
+31
+00:01:33,680 --> 00:01:36,970
+real world software. And so what this examples do is to show
+
+32
+00:01:36,970 --> 00:01:41,270
+you, how black box and white box tests are really complimentary techniques.
+
+33
+00:01:41,270 --> 00:01:43,130
+So in the next two lessions we will explore
+
+34
+00:01:43,130 --> 00:01:45,130
+these two types of techniques in detail. We will
+
+35
+00:01:45,130 --> 00:01:48,020
+see different kinds of white box and black box
+
+36
+00:01:48,020 --> 00:01:50,670
+testing. And we'll talk about their strengths and the mutations
diff --git a/usth/ICT2.7/P4L1 General Concepts Subtitles/2 - Introduction - lang_en_vs4.srt b/usth/ICT2.7/P4L1 General Concepts Subtitles/2 - Introduction - lang_en_vs4.srt
new file mode 100644
index 0000000..1a25089
--- /dev/null
+++ b/usth/ICT2.7/P4L1 General Concepts Subtitles/2 - Introduction - lang_en_vs4.srt	
@@ -0,0 +1,103 @@
+1
+00:00:00,280 --> 00:00:02,750
+So let me start with some examples that motivate the
+
+2
+00:00:02,750 --> 00:00:06,330
+need for very fine software. The first example I want to
+
+3
+00:00:06,330 --> 00:00:09,580
+use is the famous Arian five. And if you remember
+
+4
+00:00:09,580 --> 00:00:13,060
+that's a rocket that exploded not too long after departure.
+
+5
+00:00:13,060 --> 00:00:15,800
+Because of a software error. And even without going to
+
+6
+00:00:15,800 --> 00:00:19,400
+such dramatic examples. I'm sure you're all familiar with this
+
+7
+00:00:19,400 --> 00:00:22,470
+kind of situation. Or this one, or again in this
+
+8
+00:00:22,470 --> 00:00:26,070
+one. And here I'm not really picking on any specific organization,
+
+9
+00:00:26,070 --> 00:00:32,280
+operating system or software. The point I want to make is that software is
+
+10
+00:00:32,280 --> 00:00:34,730
+buggy. In fact, a federal report from
+
+11
+00:00:34,730 --> 00:00:37,810
+a few years ago assessed that software bugs
+
+12
+00:00:37,810 --> 00:00:41,300
+are costing the US economy, $60 billion
+
+13
+00:00:41,300 --> 00:00:44,120
+every year. In addition, studies have shown that
+
+14
+00:00:44,120 --> 00:00:47,810
+software contains on average one to five
+
+15
+00:00:47,810 --> 00:00:51,472
+bugs every 1000 lines of code. Building 100%
+
+16
+00:00:51,472 --> 00:00:55,940
+correct mass-market software is just impossible. And if
+
+17
+00:00:55,940 --> 00:00:58,270
+this is the case, what can we do?
+
+18
+00:00:58,270 --> 00:01:03,520
+What we need to do is to verify software as much as possible. In this part of
+
+19
+00:01:03,520 --> 00:01:05,750
+the course, we will discuss how we can
+
+20
+00:01:05,750 --> 00:01:09,480
+do this. We will discuss different alternative ways
+
+21
+00:01:09,480 --> 00:01:13,980
+of very fine software systems. With particular attention
+
+22
+00:01:13,980 --> 00:01:16,570
+to the most common type of verification. Which is
+
+23
+00:01:16,570 --> 00:01:19,470
+software testing. Before doing that however, let
+
+24
+00:01:19,470 --> 00:01:21,090
+me go over some basic terms that are
+
+25
+00:01:21,090 --> 00:01:23,190
+commonly used. And I have to say,
+
+26
+00:01:23,190 --> 00:01:26,330
+often misused in the context of software verification.
diff --git a/usth/ICT2.7/P4L1 General Concepts Subtitles/3 - Failure, Fault, and Error - lang_en_vs4.srt b/usth/ICT2.7/P4L1 General Concepts Subtitles/3 - Failure, Fault, and Error - lang_en_vs4.srt
new file mode 100644
index 0000000..e6459c0
--- /dev/null
+++ b/usth/ICT2.7/P4L1 General Concepts Subtitles/3 - Failure, Fault, and Error - lang_en_vs4.srt	
@@ -0,0 +1,79 @@
+1
+00:00:00,390 --> 00:00:03,460
+The first term I want to define, is failure.
+
+2
+00:00:03,460 --> 00:00:09,080
+A failure is an observable incorrect behavior of the software.
+
+3
+00:00:09,080 --> 00:00:10,910
+It is conceptually related to the behavior of the
+
+4
+00:00:10,910 --> 00:00:13,910
+program, rather than its code. The second term I want
+
+5
+00:00:13,910 --> 00:00:17,600
+to introduce is fault, which is also called bug.
+
+6
+00:00:17,600 --> 00:00:20,540
+And the fault or bug, is an incorrect piece of
+
+7
+00:00:20,540 --> 00:00:22,780
+code. In other words, a fault is related to
+
+8
+00:00:22,780 --> 00:00:25,900
+the code. And is a necessary, but not sufficient condition
+
+9
+00:00:25,900 --> 00:00:28,160
+for the occurrence of a failure. The final
+
+10
+00:00:28,160 --> 00:00:30,880
+term I want to introduce is, error. Where an
+
+11
+00:00:30,880 --> 00:00:33,630
+error is the cause of a fault. It is
+
+12
+00:00:33,630 --> 00:00:36,990
+usually a human error, which can be conceptual. A
+
+13
+00:00:36,990 --> 00:00:39,620
+typo or something along those lines. And know that
+
+14
+00:00:39,620 --> 00:00:43,422
+this terminology, failure, fault and error, is the official
+
+15
+00:00:43,422 --> 00:00:46,945
+[UNKNOWN] terminology. So you cannot go wrong if you
+
+16
+00:00:46,945 --> 00:00:51,282
+use it. Now, let me illustrate the difference between
+
+17
+00:00:51,282 --> 00:00:57,153
+failure, fault and error. Using a small example. What I'm showing here is
+
+18
+00:00:57,153 --> 00:01:00,876
+a small function that, as you can see from its name, takes an
+
+19
+00:01:00,876 --> 00:01:04,920
+integer parameter i. And is supposed to double the value of i, and
+
+20
+00:01:04,920 --> 00:01:08,420
+return it. As we can clearly see, this is not what the function does.
diff --git a/usth/ICT2.7/P4L1 General Concepts Subtitles/4 - Failure, Fault, and Error Quiz - lang_en_vs4.srt b/usth/ICT2.7/P4L1 General Concepts Subtitles/4 - Failure, Fault, and Error Quiz - lang_en_vs4.srt
new file mode 100644
index 0000000..03f6a6a
--- /dev/null
+++ b/usth/ICT2.7/P4L1 General Concepts Subtitles/4 - Failure, Fault, and Error Quiz - lang_en_vs4.srt	
@@ -0,0 +1,15 @@
+1
+00:00:00,120 --> 00:00:02,900
+So now I have a few questions for you. And so we use, as
+
+2
+00:00:02,900 --> 00:00:07,350
+usual, our developer Janet to introduce a quiz. And the first question I want to
+
+3
+00:00:07,350 --> 00:00:11,710
+ask you is the following. A call to double passing three as a parameter returns
+
+4
+00:00:11,710 --> 00:00:16,149
+the value nine. What is this? Is that a failure, a fault, or an error?
diff --git a/usth/ICT2.7/P4L1 General Concepts Subtitles/5 - Failure, Fault, and Error Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P4L1 General Concepts Subtitles/5 - Failure, Fault, and Error Quiz Solution - lang_en_vs4.srt
new file mode 100644
index 0000000..1bcde7f
--- /dev/null
+++ b/usth/ICT2.7/P4L1 General Concepts Subtitles/5 - Failure, Fault, and Error Quiz Solution - lang_en_vs4.srt	
@@ -0,0 +1,15 @@
+1
+00:00:00,440 --> 00:00:06,614
+The fact that the call to double three returns nine instead of six is clearly
+
+2
+00:00:06,614 --> 00:00:13,000
+a failure because it is an observable incorrect behavior of the program.
+
+3
+00:00:13,000 --> 00:00:16,110
+So let me remind you that the failure is conceptually related to the
+
+4
+00:00:16,110 --> 00:00:20,076
+behavior of the program, to the way the program acts and not its code.
diff --git a/usth/ICT2.7/P4L1 General Concepts Subtitles/6 - Failure, Fault, and Error Quiz - lang_en_vs4.srt b/usth/ICT2.7/P4L1 General Concepts Subtitles/6 - Failure, Fault, and Error Quiz - lang_en_vs4.srt
new file mode 100644
index 0000000..f51ac9f
--- /dev/null
+++ b/usth/ICT2.7/P4L1 General Concepts Subtitles/6 - Failure, Fault, and Error Quiz - lang_en_vs4.srt	
@@ -0,0 +1,19 @@
+1
+00:00:00,310 --> 00:00:02,690
+So now, let me ask you a second question. We just saw that we
+
+2
+00:00:02,690 --> 00:00:04,640
+can, reveal a failure in the program
+
+3
+00:00:04,640 --> 00:00:06,640
+by calling double with parameter three. Where
+
+4
+00:00:06,640 --> 00:00:09,750
+is the fault that causes such failure in the program? So I want you
+
+5
+00:00:09,750 --> 00:00:12,900
+to write the number of the line of code that, that contains the fault.
diff --git a/usth/ICT2.7/P4L1 General Concepts Subtitles/7 - Failure, Fault, and Error Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P4L1 General Concepts Subtitles/7 - Failure, Fault, and Error Quiz Solution - lang_en_vs4.srt
new file mode 100644
index 0000000..bc55603
--- /dev/null
+++ b/usth/ICT2.7/P4L1 General Concepts Subtitles/7 - Failure, Fault, and Error Quiz Solution - lang_en_vs4.srt	
@@ -0,0 +1,31 @@
+1
+00:00:00,190 --> 00:00:02,404
+Before telling you what the right answer is, let
+
+2
+00:00:02,404 --> 00:00:04,240
+me remind you that the fault is related to
+
+3
+00:00:04,240 --> 00:00:06,508
+the code, and is a necessary, but not sufficient
+
+4
+00:00:06,508 --> 00:00:09,560
+condition for the occurrence of a failure. So in this
+
+5
+00:00:09,560 --> 00:00:12,450
+case, a single faulty line is responsible for the
+
+6
+00:00:12,450 --> 00:00:17,435
+failure, which is line three. So the correct answer, is
+
+7
+00:00:17,435 --> 00:00:20,700
+three. At line three, the program computes i times
+
+8
+00:00:20,700 --> 00:00:23,080
+i, instead of i times 2, as it should do.
diff --git a/usth/ICT2.7/P4L1 General Concepts Subtitles/8 - Failure, Fault, and Error Quiz - lang_en_vs4.srt b/usth/ICT2.7/P4L1 General Concepts Subtitles/8 - Failure, Fault, and Error Quiz - lang_en_vs4.srt
new file mode 100644
index 0000000..18515a6
--- /dev/null
+++ b/usth/ICT2.7/P4L1 General Concepts Subtitles/8 - Failure, Fault, and Error Quiz - lang_en_vs4.srt	
@@ -0,0 +1,15 @@
+1
+00:00:00,370 --> 00:00:02,090
+So, I want to ask you one last question about
+
+2
+00:00:02,090 --> 00:00:05,480
+this problem. What is the error that cause the fault
+
+3
+00:00:05,480 --> 00:00:08,180
+at line three? Remember that an error is the
+
+4
+00:00:08,180 --> 00:00:11,010
+cause of a fault and it's usually a human error.
diff --git a/usth/ICT2.7/P4L1 General Concepts Subtitles/9 - Failure, Fault, and Error Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P4L1 General Concepts Subtitles/9 - Failure, Fault, and Error Quiz Solution - lang_en_vs4.srt
new file mode 100644
index 0000000..56db4c1
--- /dev/null
+++ b/usth/ICT2.7/P4L1 General Concepts Subtitles/9 - Failure, Fault, and Error Quiz Solution - lang_en_vs4.srt	
@@ -0,0 +1,39 @@
+1
+00:00:00,350 --> 00:00:02,740
+And I apologize, but this was a tricky question that
+
+2
+00:00:02,740 --> 00:00:06,770
+we cannot really answer. We really have no way to
+
+3
+00:00:06,770 --> 00:00:08,860
+know what the error was. It could have been a
+
+4
+00:00:08,860 --> 00:00:13,240
+typo, an erroneous copy and paste operation, or even worse
+
+5
+00:00:13,240 --> 00:00:16,079
+a conceptual error. In case a developer did not know
+
+6
+00:00:16,079 --> 00:00:19,910
+what it means to double a number. Unfortunately though, the
+
+7
+00:00:19,910 --> 00:00:22,200
+developer is the only one who could actually answer this
+
+8
+00:00:22,200 --> 00:00:25,610
+question. So even though we cannot really answer this question,
+
+9
+00:00:25,610 --> 00:00:28,000
+having it help us think about how the
+
+10
+00:00:28,000 --> 00:00:31,000
+error is in fact related to human behavior.
diff --git a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/1 - Lesson Overview - lang_en_vs4.srt b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/1 - Lesson Overview - lang_en_vs4.srt
new file mode 100644
index 0000000..09a8f10
--- /dev/null
+++ b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/1 - Lesson Overview - lang_en_vs4.srt	
@@ -0,0 +1,47 @@
+1
+00:00:00,320 --> 00:00:02,620
+In the previous lesson, we discussed the fundamental
+
+2
+00:00:02,620 --> 00:00:06,380
+concepts behind software verification in general, and software testing
+
+3
+00:00:06,380 --> 00:00:09,470
+in particular. In this lesson, we will discuss
+
+4
+00:00:09,470 --> 00:00:12,310
+one of the two main testing approaches. Black box
+
+5
+00:00:12,310 --> 00:00:16,180
+testing, also called functional testing. We will cover
+
+6
+00:00:16,180 --> 00:00:19,180
+the main characteristic of black box testing, its pros
+
+7
+00:00:19,180 --> 00:00:22,260
+and cons, and discuss some commonly used black
+
+8
+00:00:22,260 --> 00:00:25,350
+box testing techniques. We will conclude the lesson with
+
+9
+00:00:25,350 --> 00:00:28,520
+a practical exercise in which we will apply a specific black
+
+10
+00:00:28,520 --> 00:00:32,520
+box testing technique to a real program. We will derive test
+
+11
+00:00:32,520 --> 00:00:34,980
+cases for the program and assess how the use of a
+
+12
+00:00:34,980 --> 00:00:38,690
+systematic approach, in contrast to a brute force approach, can help.
diff --git a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/10 - Test Data Selection Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/10 - Test Data Selection Quiz Solution - lang_en_vs4.srt
new file mode 100644
index 0000000..418ed91
--- /dev/null
+++ b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/10 - Test Data Selection Quiz Solution - lang_en_vs4.srt	
@@ -0,0 +1,79 @@
+1
+00:00:00,025 --> 00:00:02,900
+Okay, so now we're going to answer the question. So if we want
+
+2
+00:00:02,900 --> 00:00:06,520
+to consider all these inputs, and run them all on the software,
+
+3
+00:00:06,520 --> 00:00:09,490
+let's see how it will work. Let's assume that these are, 32
+
+4
+00:00:09,490 --> 00:00:12,280
+bit integers. So at this point what we will have is, a
+
+5
+00:00:12,280 --> 00:00:15,130
+number of combination, which is 2 to the 32, times 2 to
+
+6
+00:00:15,130 --> 00:00:18,390
+the 32. They're two integers. This is equal to 2 to the
+
+7
+00:00:18,390 --> 00:00:21,910
+64, which in turn, is more or less equal, to 10 to
+
+8
+00:00:21,910 --> 00:00:25,110
+the 19. So 10 to the 19 is the number of tests that
+
+9
+00:00:25,110 --> 00:00:27,960
+we need to run to cover the whole domain. Now let's assume
+
+10
+00:00:27,960 --> 00:00:31,400
+that we can run one test per nanosecond. So what that means
+
+11
+00:00:31,400 --> 00:00:34,290
+is that we can run 10 to the 9 tests per second,
+
+12
+00:00:34,290 --> 00:00:37,240
+and that's a lot. If we do the math, that results in 10
+
+13
+00:00:37,240 --> 00:00:40,750
+to the 10 seconds over all, because we have 10 to the
+
+14
+00:00:40,750 --> 00:00:43,760
+19 tests, we could run 10 to the 9 tests per second
+
+15
+00:00:43,760 --> 00:00:46,630
+so, we do the math, and we can run all these tests
+
+16
+00:00:46,630 --> 00:00:50,340
+in 10 to the 10 seconds. And what that corresponds to, it's about
+
+17
+00:00:50,340 --> 00:00:54,470
+600 years, so a lot of time. So even for such
+
+18
+00:00:54,470 --> 00:00:57,710
+a simple problem, a problem that takes two integers and adds them,
+
+19
+00:00:57,710 --> 00:01:00,990
+it will take more than 500 years to test it exhaustively. So
+
+20
+00:01:00,990 --> 00:01:04,690
+the bottom line here is that we just can't do exhaustive testing.
diff --git a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/11 - Why Not Random Testing? - lang_en_vs4.srt b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/11 - Why Not Random Testing? - lang_en_vs4.srt
new file mode 100644
index 0000000..a91af45
--- /dev/null
+++ b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/11 - Why Not Random Testing? - lang_en_vs4.srt	
@@ -0,0 +1,143 @@
+1
+00:00:00,310 --> 00:00:02,250
+So then maybe what we can do is just to
+
+2
+00:00:02,250 --> 00:00:05,720
+pick our test inputs randomly so to do what is called
+
+3
+00:00:05,720 --> 00:00:08,850
+random testing. And what that means is that we pick the
+
+4
+00:00:08,850 --> 00:00:11,720
+inputs to test just as we pick a number by rolling
+
+5
+00:00:11,720 --> 00:00:15,410
+a set of dice randomly. And this will have several advantages.
+
+6
+00:00:15,410 --> 00:00:18,780
+First, we will pick inputs uniformly. So if we use a
+
+7
+00:00:18,780 --> 00:00:21,790
+uniform distribution as the basis for our random testing, we will
+
+8
+00:00:21,790 --> 00:00:25,540
+make no preferences. In other words, all inputs will be considered
+
+9
+00:00:25,540 --> 00:00:28,324
+equal, of equal value. And what that means in turn, is
+
+10
+00:00:28,324 --> 00:00:32,640
+that random testing eliminates designer bias. So what does designer bias
+
+11
+00:00:32,640 --> 00:00:36,030
+mean? Designer bias is the problem of making the same assumption,
+
+12
+00:00:36,030 --> 00:00:38,570
+when we read the specification and we interpret it and when we
+
+13
+00:00:38,570 --> 00:00:42,100
+develop test cases. Which means that the developer might develop code,
+
+14
+00:00:42,100 --> 00:00:44,930
+assuming a given behavior of the user. And we may write
+
+15
+00:00:44,930 --> 00:00:47,520
+tests, making the same assumptions. And the problem, of course, is
+
+16
+00:00:47,520 --> 00:00:50,690
+even worse if it's the same person that develops the code and
+
+17
+00:00:50,690 --> 00:00:53,730
+writes the test cases. With random testing, the problem is gone,
+
+18
+00:00:53,730 --> 00:00:57,440
+because we just pick randomly what our inputs will be. So
+
+19
+00:00:57,440 --> 00:01:00,180
+why not do in random? The problem is that when testing,
+
+20
+00:01:00,180 --> 00:01:03,610
+we are looking for a needle in a haystack. Actually, multiple
+
+21
+00:01:03,610 --> 00:01:06,620
+needles in multiple haystacks, if we want to be precise. So,
+
+22
+00:01:06,620 --> 00:01:09,500
+random approaches are not necessarily the best way to go about
+
+23
+00:01:09,500 --> 00:01:12,430
+it, because we might just be looking in all the wrong
+
+24
+00:01:12,430 --> 00:01:15,760
+places. So let me show you this, using a different representation
+
+25
+00:01:15,760 --> 00:01:18,000
+for the haystack. What I'm showing here is a grid, and
+
+26
+00:01:18,000 --> 00:01:22,130
+imagine this grid just expanding indefinitely outside the screen, and this grid
+
+27
+00:01:22,130 --> 00:01:26,120
+represents the domain for the program, so each box in the grid,
+
+28
+00:01:26,120 --> 00:01:29,050
+each square in the grid, it's a possible input. So what happens
+
+29
+00:01:29,050 --> 00:01:32,670
+with bugs is that bugs are very scarce in this grid. Maybe
+
+30
+00:01:32,670 --> 00:01:35,070
+there is a bug here, so that means that there is a
+
+31
+00:01:35,070 --> 00:01:38,090
+bug, than an input, in this point we'll reveal. And maybe there
+
+32
+00:01:38,090 --> 00:01:40,820
+is another bug that will be triggered by an input over here.
+
+33
+00:01:40,820 --> 00:01:44,570
+So imagine this spread out over this infinite grid. Its very unlikely
+
+34
+00:01:44,570 --> 00:01:47,440
+that just by picking randomly that we will be able to get to
+
+35
+00:01:47,440 --> 00:01:50,910
+these two points. Fortunately not all is lost, there is a silver lining.
+
+36
+00:01:50,910 --> 00:01:53,410
+So we need to look a little more in depth into this grid.
diff --git a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/12 - Partition Testing - lang_en_vs4.srt b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/12 - Partition Testing - lang_en_vs4.srt
new file mode 100644
index 0000000..b91462c
--- /dev/null
+++ b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/12 - Partition Testing - lang_en_vs4.srt	
@@ -0,0 +1,67 @@
+1
+00:00:00,110 --> 00:00:02,570
+So let me use a slightly expanded version of this
+
+2
+00:00:02,570 --> 00:00:05,560
+grid. Although we're indeed looking at a needle in a haystack.
+
+3
+00:00:05,560 --> 00:00:09,560
+And failing inputs are generally sparse, very sparse, in the input
+
+4
+00:00:09,560 --> 00:00:12,890
+domain. However, they tend to be dense in some parts of
+
+5
+00:00:12,890 --> 00:00:15,860
+the domain. Like here or here. So how can we leverage
+
+6
+00:00:15,860 --> 00:00:18,920
+this? The fact that the failures are dense in some subdomains?
+
+7
+00:00:18,920 --> 00:00:22,290
+As it turns out, the domain is naturally split into partitions.
+
+8
+00:00:22,290 --> 00:00:25,340
+Where partitions are areas of the domain that are treated homogeneously
+
+9
+00:00:25,340 --> 00:00:28,070
+by the software. And this is what happens, that normally,
+
+10
+00:00:28,070 --> 00:00:31,020
+failures tend to be dense in this partitions. So the way
+
+11
+00:00:31,020 --> 00:00:34,000
+to leverage this characteristic of failures, is that we don't know
+
+12
+00:00:34,000 --> 00:00:36,950
+want to pick inputs randomly, in the input domain. Just here
+
+13
+00:00:36,950 --> 00:00:39,460
+and there. Rather we want to do two things. First we
+
+14
+00:00:39,460 --> 00:00:43,300
+want to identify partitions of our domain. And second we want
+
+15
+00:00:43,300 --> 00:00:46,950
+to select inputs from each partition. And by doing so, we
+
+16
+00:00:46,950 --> 00:00:50,300
+can dramatically increase our chances to reveal faults in the code.
+
+17
+00:00:50,300 --> 00:00:54,170
+So the name that is normally used for this process, is partition testing.
diff --git a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/13 - Partition Testing Example - lang_en_vs4.srt b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/13 - Partition Testing Example - lang_en_vs4.srt
new file mode 100644
index 0000000..6738346
--- /dev/null
+++ b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/13 - Partition Testing Example - lang_en_vs4.srt	
@@ -0,0 +1,167 @@
+1
+00:00:00,120 --> 00:00:02,969
+So let's look at how this will work with an example.
+
+2
+00:00:02,969 --> 00:00:06,210
+I'm going to use this simple program that takes two inputs. The
+
+3
+00:00:06,210 --> 00:00:08,790
+first input is a string, str, and the second one is
+
+4
+00:00:08,790 --> 00:00:11,575
+an integer, size. And the problem is called split. And as
+
+5
+00:00:11,575 --> 00:00:14,363
+the name says what it does is to take this string,
+
+6
+00:00:14,363 --> 00:00:17,491
+str, and split it into sub string, into chunks of size
+
+7
+00:00:17,491 --> 00:00:21,550
+characters each. So how do we identify some possible partitions for
+
+8
+00:00:21,550 --> 00:00:25,620
+this program? If we consider the input size, we can identify
+
+9
+00:00:25,620 --> 00:00:29,630
+three neutral partitions which are size less than 0. For example,
+
+10
+00:00:29,630 --> 00:00:32,259
+we want to test how the program behaves. But if we pass an
+
+11
+00:00:32,259 --> 00:00:36,100
+incorrect size, size equal to 0, which is also a partition. In
+
+12
+00:00:36,100 --> 00:00:39,390
+this case, a partition with a single element. And the third case
+
+13
+00:00:39,390 --> 00:00:42,540
+is size greater than 0, which I will consider to be
+
+14
+00:00:42,540 --> 00:00:44,960
+kind of the standard case. And actually let me do a, you
+
+15
+00:00:44,960 --> 00:00:48,220
+know, slight aggression so when I was talking about designer bias. So
+
+16
+00:00:48,220 --> 00:00:50,630
+this is a case in which designer bias might not make you
+
+17
+00:00:50,630 --> 00:00:53,050
+think of using size less than 0 because you read the
+
+18
+00:00:53,050 --> 00:00:56,210
+spec. And you sort of assume that the size will be positive.
+
+19
+00:00:56,210 --> 00:00:58,556
+Whereas the right thing to do when we test is to consider
+
+20
+00:00:58,556 --> 00:01:01,700
+the complete domain rather than just parts of it. So now let's
+
+21
+00:01:01,700 --> 00:01:04,760
+look at string, str, and let's see what kind of sub
+
+22
+00:01:04,760 --> 00:01:06,538
+domains we could identify for this
+
+23
+00:01:06,538 --> 00:01:08,670
+parameter. And notice another important aspect
+
+24
+00:01:08,670 --> 00:01:12,290
+here is that we treat each different part of the input independently,
+
+25
+00:01:12,290 --> 00:01:15,760
+which also helps breaking down the problem. One interesting sub domain is
+
+26
+00:01:15,760 --> 00:01:18,980
+the domain that includes all the strings whose length is less than
+
+27
+00:01:18,980 --> 00:01:22,310
+size. So all the strings that will not be displayed. Another subdomain
+
+28
+00:01:22,310 --> 00:01:25,000
+is all the strings with length which is between the value of
+
+29
+00:01:25,000 --> 00:01:28,350
+size and twice the value of size. A third subdomain is the one
+
+30
+00:01:28,350 --> 00:01:31,820
+including all the strings whose length is greater than twice the value
+
+31
+00:01:31,820 --> 00:01:35,140
+of size. And we can continue and identify more and more subdomain.
+
+32
+00:01:35,140 --> 00:01:38,350
+The key thing here is that we have to do that based
+
+33
+00:01:38,350 --> 00:01:41,180
+on the domain. So we need to adapt what we just did here
+
+34
+00:01:41,180 --> 00:01:44,620
+based on, on the specific domain involved and on the type
+
+35
+00:01:44,620 --> 00:01:47,190
+of data in this domain. So at this point we said that
+
+36
+00:01:47,190 --> 00:01:49,630
+there were two steps. One was to identify the subdomains and
+
+37
+00:01:49,630 --> 00:01:52,990
+the second one was to pick values in this subdomain. The values
+
+38
+00:01:52,990 --> 00:01:55,320
+that we'll actually use for the testing. In this case, we
+
+39
+00:01:55,320 --> 00:01:58,218
+do not want to just pick any value. Rather we want to
+
+40
+00:01:58,218 --> 00:01:59,871
+pick values that are particularly
+
+41
+00:01:59,871 --> 00:02:02,710
+interesting, particularly representative. So what does
+
+42
+00:02:02,710 --> 00:02:05,800
+that mean? Well, we're going to do that based on an intuitive idea.
diff --git a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/14 - Boundary Values - lang_en_vs4.srt b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/14 - Boundary Values - lang_en_vs4.srt
new file mode 100644
index 0000000..3d54ad4
--- /dev/null
+++ b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/14 - Boundary Values - lang_en_vs4.srt	
@@ -0,0 +1,55 @@
+1
+00:00:00,150 --> 00:00:02,590
+So let's go back again to our domain, with
+
+2
+00:00:02,590 --> 00:00:06,580
+all the sub-domains identified. And the basic idea, or the
+
+3
+00:00:06,580 --> 00:00:09,750
+intuitive idea I was talking about, is that errors tend
+
+4
+00:00:09,750 --> 00:00:12,425
+to occur at the boundary of a domain, or a
+
+5
+00:00:12,425 --> 00:00:15,510
+sub-domain. Like in this case. And why? Because these
+
+6
+00:00:15,510 --> 00:00:19,360
+are the cases that are less understood by the developers.
+
+7
+00:00:19,360 --> 00:00:22,155
+Like for example, the last iteration of a loop, or
+
+8
+00:00:22,155 --> 00:00:25,150
+a special value like zero for integers. So if this
+
+9
+00:00:25,150 --> 00:00:29,590
+is true, what we want to do is to select inputs at these
+
+10
+00:00:29,590 --> 00:00:32,189
+boundaries. And this is complementary to partition
+
+11
+00:00:32,189 --> 00:00:34,270
+testing, in the sense that partition testing
+
+12
+00:00:34,270 --> 00:00:38,160
+will identify the partitions in which we want to select inputs, and boundary
+
+13
+00:00:38,160 --> 00:00:40,570
+testing. So the selection of boundary values
+
+14
+00:00:40,570 --> 00:00:43,060
+will help select inputs in these partitions.
diff --git a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/15 - Boundary Values Example - lang_en_vs4.srt b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/15 - Boundary Values Example - lang_en_vs4.srt
new file mode 100644
index 0000000..b344802
--- /dev/null
+++ b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/15 - Boundary Values Example - lang_en_vs4.srt	
@@ -0,0 +1,99 @@
+1
+00:00:00,200 --> 00:00:03,320
+So now let's go back to our split example. Let me
+
+2
+00:00:03,320 --> 00:00:05,790
+rearrange things a little bit to make more room. So now I'm
+
+3
+00:00:05,790 --> 00:00:09,160
+going to put the domains for size and for strength one next to
+
+4
+00:00:09,160 --> 00:00:12,210
+the other. So let's look at what some possible inputs will be
+
+5
+00:00:12,210 --> 00:00:15,140
+for the sub domains that we identified when we use the idea
+
+6
+00:00:15,140 --> 00:00:17,790
+of selecting input of the boundary. If we look at the first
+
+7
+00:00:17,790 --> 00:00:21,860
+subdomain, size less than zero, one reasonable input is, size equals to
+
+8
+00:00:21,860 --> 00:00:25,360
+minus 1, because minus 1 is the boundary value for the domain
+
+9
+00:00:25,360 --> 00:00:28,530
+of the integers less than zero. If we look at the third
+
+10
+00:00:28,530 --> 00:00:32,119
+subdomain, possibly interesting case is the one of size of equal to
+
+11
+00:00:32,119 --> 00:00:34,900
+1, for the same reasoning that we used for the previous subdomain,
+
+12
+00:00:34,900 --> 00:00:37,670
+for size less than zero. And, let's try to select another one
+
+13
+00:00:37,670 --> 00:00:40,870
+for this subdomain, for the integers greater than zero. If there is
+
+14
+00:00:40,870 --> 00:00:44,200
+a concept of maximal integer, we can select that one as our
+
+15
+00:00:44,200 --> 00:00:47,140
+boundary value. And of course we could select much more, but this
+
+16
+00:00:47,140 --> 00:00:50,630
+is just to give you an idea. Other possible inputs. One interesting
+
+17
+00:00:50,630 --> 00:00:53,310
+example for the first one, string with length less than
+
+18
+00:00:53,310 --> 00:00:57,690
+size will be a string with length size minus one. Again
+
+19
+00:00:57,690 --> 00:01:00,240
+this is the boundary value for this domain. And we could
+
+20
+00:01:00,240 --> 00:01:03,500
+continue in this way like for example selecting a string who's
+
+21
+00:01:03,500 --> 00:01:07,310
+length is exactly size as a boundary value for this
+
+22
+00:01:07,310 --> 00:01:10,490
+other domain. Instant one, and we look back actually to this
+
+23
+00:01:10,490 --> 00:01:12,940
+example and look at it in a more extensive way when
+
+24
+00:01:12,940 --> 00:01:15,690
+we actually talk about a specific method for doing this kind
+
+25
+00:01:15,690 --> 00:01:16,340
+of process.
diff --git a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/16 - Deriving Test Case Specifications - lang_en_vs4.srt b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/16 - Deriving Test Case Specifications - lang_en_vs4.srt
new file mode 100644
index 0000000..5164f1a
--- /dev/null
+++ b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/16 - Deriving Test Case Specifications - lang_en_vs4.srt	
@@ -0,0 +1,199 @@
+1
+00:00:00,140 --> 00:00:02,790
+Now, let's go back to our systematic functional testing
+
+2
+00:00:02,790 --> 00:00:05,540
+approach and all the steps in this process. So
+
+3
+00:00:05,540 --> 00:00:07,680
+far we've seen the first step and the second
+
+4
+00:00:07,680 --> 00:00:10,340
+step. Now we're going to look at this step in which,
+
+5
+00:00:10,340 --> 00:00:13,290
+once we have identified the values of interest, we
+
+6
+00:00:13,290 --> 00:00:18,110
+derive test case specifications for these values, or using these
+
+7
+00:00:18,110 --> 00:00:21,300
+values. And the test case specification defines how the
+
+8
+00:00:21,300 --> 00:00:25,230
+values should be put together when actually testing the system.
+
+9
+00:00:25,230 --> 00:00:29,110
+And test case specification describe how these values should be put
+
+10
+00:00:29,110 --> 00:00:32,360
+together when testing the system. So let me go back one more
+
+11
+00:00:32,360 --> 00:00:34,780
+time to our split program, so that we can use the
+
+12
+00:00:34,780 --> 00:00:37,450
+information that we already computed. At this point what we have is
+
+13
+00:00:37,450 --> 00:00:41,670
+some possible inputs for "string," our first parameter, and for "size,"
+
+14
+00:00:41,670 --> 00:00:44,410
+our second parameter. And we want to put them together, to generate
+
+15
+00:00:44,410 --> 00:00:47,080
+the description of what the test case should be. So let
+
+16
+00:00:47,080 --> 00:00:50,420
+me once more rearrange this a little bit. I first remove the
+
+17
+00:00:50,420 --> 00:00:53,360
+description of the subdomains, because we won't use them in this step.
+
+18
+00:00:53,360 --> 00:00:55,800
+And I moved out the set of all our possible inputs, that we're
+
+19
+00:00:55,800 --> 00:00:59,470
+going to combine to create the test case specification. And one possible way
+
+20
+00:00:59,470 --> 00:01:03,320
+of doing that is simply to combine the values for the first parameter,
+
+21
+00:01:03,320 --> 00:01:06,370
+and the values for the second parameter. So the Cartesian product. So
+
+22
+00:01:06,370 --> 00:01:09,060
+if we do that, what we will obtain is, for example, if we
+
+23
+00:01:09,060 --> 00:01:12,470
+consider the first possible input, size is equal to minus 1, we can
+
+24
+00:01:12,470 --> 00:01:15,510
+combine it with these two possible inputs for string, and we will get
+
+25
+00:01:15,510 --> 00:01:18,680
+size is equal to minus 1 string with length minus 2, or
+
+26
+00:01:18,680 --> 00:01:21,680
+size is equal to minus 1 string with length minus 1. And we'll
+
+27
+00:01:21,680 --> 00:01:24,200
+go back in a second to see what this means. Now if we
+
+28
+00:01:24,200 --> 00:01:27,510
+consider the second possible value for size, size is equal to one, we
+
+29
+00:01:27,510 --> 00:01:30,260
+also have two cases so the first one in this case that will
+
+30
+00:01:30,260 --> 00:01:34,030
+be considered a string with length zero. So the antistring. And we can
+
+31
+00:01:34,030 --> 00:01:37,410
+continue combining this value, but one thing I want to point out is
+
+32
+00:01:37,410 --> 00:01:40,570
+that if we just go in this straight forward and brute force sort
+
+33
+00:01:40,570 --> 00:01:43,390
+of way, we will obtain many combinations that don't make any sense,
+
+34
+00:01:43,390 --> 00:01:46,500
+like for example, this combination which doesn't make any sense because we can
+
+35
+00:01:46,500 --> 00:01:50,410
+not create the string with length minus 2. Similar for this combination, because
+
+36
+00:01:50,410 --> 00:01:53,190
+then by the same token, we cannot raise things with length minus 1.
+
+37
+00:01:53,190 --> 00:01:55,730
+And so there's a lot of cases that we will have to eliminate
+
+38
+00:01:55,730 --> 00:01:59,380
+afterwards. So what we're going to see in a few minutes is a possible
+
+39
+00:01:59,380 --> 00:02:02,970
+way in which we can avoid producing these meaningless cases. And at the
+
+40
+00:02:02,970 --> 00:02:06,380
+same time, keep under control, the number of test cases that we generate.
+
+41
+00:02:06,380 --> 00:02:09,070
+So lets go back for the last time to our steps
+
+42
+00:02:09,070 --> 00:02:11,980
+for systematic functional testing. What we just did was to derive
+
+43
+00:02:11,980 --> 00:02:15,040
+test case specification from a set of relevant inputs. The following
+
+44
+00:02:15,040 --> 00:02:18,420
+step is to use these test case specifications to generate actual test
+
+45
+00:02:18,420 --> 00:02:21,170
+cases. And this is normally a fairly mechanical step in the
+
+46
+00:02:21,170 --> 00:02:23,900
+sense that we just have to instantiate what is in the test
+
+47
+00:02:23,900 --> 00:02:27,970
+case specification as actual test cases. And it's really dependent on
+
+48
+00:02:27,970 --> 00:02:32,300
+the specific type of partitions and values identified on the specific context.
+
+49
+00:02:32,300 --> 00:02:35,100
+So instead of looking at that here in the, in the abstract,
+
+50
+00:02:35,100 --> 00:02:37,480
+I'm going to show you with an example later on, in the lesson.
diff --git a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/17 - Category Partition Method - lang_en_vs4.srt b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/17 - Category Partition Method - lang_en_vs4.srt
new file mode 100644
index 0000000..938e80c
--- /dev/null
+++ b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/17 - Category Partition Method - lang_en_vs4.srt	
@@ -0,0 +1,99 @@
+1
+00:00:00,200 --> 00:00:03,690
+What we will discuss next is a specific black-box testing
+
+2
+00:00:03,690 --> 00:00:07,240
+approach. So a specific instance of the general approach that
+
+3
+00:00:07,240 --> 00:00:10,814
+we just saw. And this approach is the category-partition method,
+
+4
+00:00:10,814 --> 00:00:13,418
+and was defined by Ostrand &amp; Balcer in 1988 in
+
+5
+00:00:13,418 --> 00:00:16,760
+an article to the peer [UNKNOWN] communication of the ACM.
+
+6
+00:00:16,760 --> 00:00:19,490
+So this is a method for going from a specification,
+
+7
+00:00:19,490 --> 00:00:21,370
+a description of the system, to a set of test
+
+8
+00:00:21,370 --> 00:00:26,170
+cases like any other black-box testing approach by following six steps.
+
+9
+00:00:26,170 --> 00:00:28,370
+So let's look at what these steps are. The first
+
+10
+00:00:28,370 --> 00:00:31,850
+step is to identify independently testable features and this is
+
+11
+00:00:31,850 --> 00:00:33,870
+a step that we are familiar with because its exactly
+
+12
+00:00:33,870 --> 00:00:36,950
+the same step that we performed in the generic black box
+
+13
+00:00:36,950 --> 00:00:39,480
+testing approach that we just discussed. The second step is
+
+14
+00:00:39,480 --> 00:00:42,250
+to identify categories. Then the next step is to partition
+
+15
+00:00:42,250 --> 00:00:45,070
+categories into choices. Identify constraints
+
+16
+00:00:45,070 --> 00:00:47,530
+among choices. Produce and evaluate
+
+17
+00:00:47,530 --> 00:00:51,330
+test case specifications. And finally, the sixth step is to generate
+
+18
+00:00:51,330 --> 00:00:54,100
+test cases from test case specifications. So two of
+
+19
+00:00:54,100 --> 00:00:56,970
+the key elements in these six steps are the two
+
+20
+00:00:56,970 --> 00:00:59,430
+that give the name to the technique so the identification
+
+21
+00:00:59,430 --> 00:01:02,240
+of the categories and the partition of these categories into
+
+22
+00:01:02,240 --> 00:01:04,810
+choices. What we're going to do next is to go
+
+23
+00:01:04,810 --> 00:01:07,670
+and look at each one of the steps independently, except
+
+24
+00:01:07,670 --> 00:01:10,285
+for the first one. Because we're already familiar with that
+
+25
+00:01:10,285 --> 00:01:12,650
+step, and this method doesn't really add much to it.
diff --git a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/18 - Identify Categories - lang_en_vs4.srt b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/18 - Identify Categories - lang_en_vs4.srt
new file mode 100644
index 0000000..a1eb4dd
--- /dev/null
+++ b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/18 - Identify Categories - lang_en_vs4.srt	
@@ -0,0 +1,127 @@
+1
+00:00:00,140 --> 00:00:02,980
+In the second step of the category partition technique, the goal is
+
+2
+00:00:02,980 --> 00:00:05,630
+to Identify Categories. Where categories are
+
+3
+00:00:05,630 --> 00:00:08,650
+characteristics of each input element. So
+
+4
+00:00:08,650 --> 00:00:11,490
+let me illustrate what that means using an example. And to do
+
+5
+00:00:11,490 --> 00:00:14,440
+that I'm going to use again the example of the split program, as
+
+6
+00:00:14,440 --> 00:00:16,830
+we are already familiar with it and we kind of already played
+
+7
+00:00:16,830 --> 00:00:20,110
+with it. When we were talking about the generic black box approach.
+
+8
+00:00:20,110 --> 00:00:22,293
+So let me bring back the program, and let me remind you
+
+9
+00:00:22,293 --> 00:00:25,440
+that what the program does is to take two inputs, a string and
+
+10
+00:00:25,440 --> 00:00:28,560
+the size, and it breaks down the string into chunks,
+
+11
+00:00:28,560 --> 00:00:31,300
+whose length is size. If we look at the split program
+
+12
+00:00:31,300 --> 00:00:34,330
+there are two input elements, str and size so we going to
+
+13
+00:00:34,330 --> 00:00:37,930
+identify categories for these two. So starting from str, what are
+
+14
+00:00:37,930 --> 00:00:41,228
+the interesting characteristics of the string? In, in this step
+
+15
+00:00:41,228 --> 00:00:44,948
+you're going to use your domain knowledge, your understanding of what a
+
+16
+00:00:44,948 --> 00:00:47,986
+string is, and for example we might identify the length of
+
+17
+00:00:47,986 --> 00:00:50,528
+the string and the content of the string as the two
+
+18
+00:00:50,528 --> 00:00:53,840
+main characteristics that we want to focus on. If we now
+
+19
+00:00:53,840 --> 00:00:57,540
+move our focus to size, the only characteristic I can really
+
+20
+00:00:57,540 --> 00:01:00,340
+think of for an integer is its value. So that's what
+
+21
+00:01:00,340 --> 00:01:02,470
+I'm going to mark here. So at the end of the step
+
+22
+00:01:02,470 --> 00:01:05,030
+what we have is that we have two categories. So two
+
+23
+00:01:05,030 --> 00:01:08,930
+interesting characteristics for the string input str, which are the length
+
+24
+00:01:08,930 --> 00:01:12,940
+and the content. And one category for the integer input size
+
+25
+00:01:12,940 --> 00:01:16,480
+which is its value. And notice that there's not only one solution.
+
+26
+00:01:16,480 --> 00:01:18,200
+So there's not only one possibility.
+
+27
+00:01:18,200 --> 00:01:20,384
+So that the specific characteristics that you
+
+28
+00:01:20,384 --> 00:01:22,800
+will identify are somehow subjective. But the
+
+29
+00:01:22,800 --> 00:01:25,630
+important point is that you identify characteristics
+
+30
+00:01:25,630 --> 00:01:29,259
+that are meaningful and they sort of cover the main aspects of the
+
+31
+00:01:29,259 --> 00:01:31,200
+inputs, which is the case for the
+
+32
+00:01:31,200 --> 00:01:33,440
+categories that we've identified in this example.
diff --git a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/19 - Partition Categories into Choices - lang_en_vs4.srt b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/19 - Partition Categories into Choices - lang_en_vs4.srt
new file mode 100644
index 0000000..a411c30
--- /dev/null
+++ b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/19 - Partition Categories into Choices - lang_en_vs4.srt	
@@ -0,0 +1,151 @@
+1
+00:00:00,230 --> 00:00:03,250
+Now we move to the next step, which involves partitioning the
+
+2
+00:00:03,250 --> 00:00:07,680
+categories that we just identified into choices. And these choices are the
+
+3
+00:00:07,680 --> 00:00:11,930
+interesting cases for each category. So the interesting subdomains for each one
+
+4
+00:00:11,930 --> 00:00:14,810
+of these categories. So once more, lets look at that using our
+
+5
+00:00:14,810 --> 00:00:18,110
+example, the split program. So lets start by considering length. What are
+
+6
+00:00:18,110 --> 00:00:20,710
+the interesting cases when we think about the length of a string?
+
+7
+00:00:20,710 --> 00:00:23,220
+Some of those we already saw, one interesting case is the case
+
+8
+00:00:23,220 --> 00:00:26,190
+of the length of size zero, so a string with no characters.
+
+9
+00:00:26,190 --> 00:00:29,030
+Another interesting case is the one in which the length of the
+
+10
+00:00:29,030 --> 00:00:31,780
+string is size minus one, so the string is just one character
+
+11
+00:00:31,780 --> 00:00:34,610
+short of the size at which it will be cut by the
+
+12
+00:00:34,610 --> 00:00:38,160
+split program. And we can continue along these lines, so we will select
+
+13
+00:00:38,160 --> 00:00:42,950
+size, size plus one, size twice the value of size minus one,
+
+14
+00:00:42,950 --> 00:00:45,560
+and so on and so forth. But even without listing all of
+
+15
+00:00:45,560 --> 00:00:47,500
+those, I'm sure you get the idea of what it means to
+
+16
+00:00:47,500 --> 00:00:49,780
+identify this interesting cases. Let's see
+
+17
+00:00:49,780 --> 00:00:51,702
+the movements that are considering the content.
+
+18
+00:00:51,702 --> 00:00:53,990
+So without the interesting cases when we think about the content
+
+19
+00:00:53,990 --> 00:00:56,520
+of the string. So possible interesting case is the string that
+
+20
+00:00:56,520 --> 00:01:00,660
+contains only spaces. Why? Well maybe because a split is written
+
+21
+00:01:00,660 --> 00:01:04,290
+spaces in a special way. Similarly a string that contains special
+
+22
+00:01:04,290 --> 00:01:06,780
+characters, like non printable characters,
+
+23
+00:01:06,780 --> 00:01:09,020
+like tabulation characters, new line might
+
+24
+00:01:09,020 --> 00:01:12,240
+also be an interesting case, something that we want to test. Also
+
+25
+00:01:12,240 --> 00:01:14,280
+in this case we could continue and go on and on.
+
+26
+00:01:14,280 --> 00:01:17,250
+So basically here you just want to put all the interesting cases
+
+27
+00:01:17,250 --> 00:01:20,010
+that you can think of when you consider the content
+
+28
+00:01:20,010 --> 00:01:22,440
+of a string. Now let's move to the value as the
+
+29
+00:01:22,440 --> 00:01:25,740
+next category. So the value of the input size. And
+
+30
+00:01:25,740 --> 00:01:29,280
+here we might want to consider a size zero, special case, a
+
+31
+00:01:29,280 --> 00:01:33,640
+normal situation, like size greater than zero, another special case,
+
+32
+00:01:33,640 --> 00:01:36,420
+size less than zero or maxint. And these are, if you
+
+33
+00:01:36,420 --> 00:01:39,420
+remember, I accepted the cases that we consider when we look
+
+34
+00:01:39,420 --> 00:01:42,350
+at this example, before. And also here we can continue and
+
+35
+00:01:42,350 --> 00:01:43,970
+go on and on. So, at the end of the
+
+36
+00:01:43,970 --> 00:01:46,860
+step, what we have is a set of interesting cases
+
+37
+00:01:46,860 --> 00:01:49,220
+for each one of the categories, and now we can
+
+38
+00:01:49,220 --> 00:01:51,150
+start to think about how we want to combine them.
diff --git a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/2 - Overview - lang_en_vs4.srt b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/2 - Overview - lang_en_vs4.srt
new file mode 100644
index 0000000..2af56c5
--- /dev/null
+++ b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/2 - Overview - lang_en_vs4.srt	
@@ -0,0 +1,103 @@
+1
+00:00:00,450 --> 00:00:03,400
+As we said at the end of the previous lesson, black-box testing is
+
+2
+00:00:03,400 --> 00:00:06,230
+the testing of the software when we look at it as a black box,
+
+3
+00:00:06,230 --> 00:00:09,110
+as a closed box, without looking at it inside, without looking at the
+
+4
+00:00:09,110 --> 00:00:10,750
+code. And there are several advantages in
+
+5
+00:00:10,750 --> 00:00:12,680
+using black-box testing. So let me recap
+
+6
+00:00:12,680 --> 00:00:15,590
+those advantages, some of which we already mentioned, and let me also expand
+
+7
+00:00:15,590 --> 00:00:18,220
+on that a little bit. The first advantage of when I mentioned is that
+
+8
+00:00:18,220 --> 00:00:22,760
+black box focuses on the domain, on the input domain of the software. And
+
+9
+00:00:22,760 --> 00:00:25,750
+as such, we can use it to make sure that we are actually covering
+
+10
+00:00:25,750 --> 00:00:28,400
+this domain, that we are actually covering the important behaviors of
+
+11
+00:00:28,400 --> 00:00:32,200
+the software. A second advantage is that black box testing does not
+
+12
+00:00:32,200 --> 00:00:35,402
+need the code. What that means is that you can perform early
+
+13
+00:00:35,402 --> 00:00:38,801
+test design. So you can start designing and writing your test cases,
+
+14
+00:00:38,801 --> 00:00:41,423
+even before writing your code, so that when the code is
+
+15
+00:00:41,423 --> 00:00:44,520
+ready, we can test it right away. And that helps prevent a
+
+16
+00:00:44,520 --> 00:00:48,054
+problem that is very typical in real life software development, which is
+
+17
+00:00:48,054 --> 00:00:50,790
+getting an idea of the project and having no time to create
+
+18
+00:00:50,790 --> 00:00:53,040
+the tests. In this way, we already have the tests, so
+
+19
+00:00:53,040 --> 00:00:56,170
+we just have to run them. Another advantage is that black-box testing
+
+20
+00:00:56,170 --> 00:00:59,530
+can catch logic defects, because it focuses on the description of what
+
+21
+00:00:59,530 --> 00:01:02,440
+the software should do, and therefore on its logic. If we derive
+
+22
+00:01:02,440 --> 00:01:05,250
+test cases from such description, then we can catch these kind of
+
+23
+00:01:05,250 --> 00:01:07,510
+problems. And finally, black-box testing is
+
+24
+00:01:07,510 --> 00:01:09,900
+applicable at all granularity levels, which
+
+25
+00:01:09,900 --> 00:01:13,490
+means that we can use black-box testing in unit testing, integration testing,
+
+26
+00:01:13,490 --> 00:01:16,290
+system testing, and so on. We can use it at all levels.
diff --git a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/20 - Identify Constraints Among Choices - lang_en_vs4.srt b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/20 - Identify Constraints Among Choices - lang_en_vs4.srt
new file mode 100644
index 0000000..0278cc8
--- /dev/null
+++ b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/20 - Identify Constraints Among Choices - lang_en_vs4.srt	
@@ -0,0 +1,239 @@
+1
+00:00:00,160 --> 00:00:02,080
+Something that we saw when we were looking at the split
+
+2
+00:00:02,080 --> 00:00:05,760
+program before is that if we just combine the interesting values that
+
+3
+00:00:05,760 --> 00:00:08,490
+we identify, we might end up with a lot of cases.
+
+4
+00:00:08,490 --> 00:00:11,030
+And I mentioned that we, we're going to look at some way of
+
+5
+00:00:11,030 --> 00:00:13,720
+addressing that problem. And this is exactly what happens in the
+
+6
+00:00:13,720 --> 00:00:17,420
+next step of the category partition method, in which we identify constraints
+
+7
+00:00:17,420 --> 00:00:20,510
+among choices. And why do we identify these constraints? We do
+
+8
+00:00:20,510 --> 00:00:23,440
+that to eliminate meaningless combinations of
+
+9
+00:00:23,440 --> 00:00:25,460
+inputs. If you remember, for example,
+
+10
+00:00:25,460 --> 00:00:27,260
+we had the case in which we were trying to
+
+11
+00:00:27,260 --> 00:00:30,110
+create a string with a size less than 0, which
+
+12
+00:00:30,110 --> 00:00:32,930
+doesn't make any sense. And very importantly, we also do
+
+13
+00:00:32,930 --> 00:00:37,070
+that to reduce the number of test cases. Because every time
+
+14
+00:00:37,070 --> 00:00:40,930
+we constrain one of the possible choices, we eliminate possible
+
+15
+00:00:40,930 --> 00:00:43,250
+test cases, so we can use it to keep under
+
+16
+00:00:43,250 --> 00:00:45,960
+control the number of tests that we generate. There are
+
+17
+00:00:45,960 --> 00:00:47,571
+three types of properties. The
+
+18
+00:00:47,571 --> 00:00:50,610
+pair property...if, error properties, and properties
+
+19
+00:00:50,610 --> 00:00:52,610
+of type single. So we're going to look at what these
+
+20
+00:00:52,610 --> 00:00:56,230
+properties mean, using, once more, our example of the split program.
+
+21
+00:00:56,230 --> 00:00:58,750
+In particular, we're going to use some of the choices that we
+
+22
+00:00:58,750 --> 00:01:02,080
+identified earlier. So let's look, for example, at choice 0, for
+
+23
+00:01:02,080 --> 00:01:04,599
+category length of the string. All we can say is that,
+
+24
+00:01:04,599 --> 00:01:07,860
+if the length is 0, this define a special property of
+
+25
+00:01:07,860 --> 00:01:11,160
+the string. And that was specified in this way by saying
+
+26
+00:01:11,160 --> 00:01:15,610
+that this identifies property zerovalue. So every time that we use
+
+27
+00:01:15,610 --> 00:01:19,080
+this choice, zerovalue is defined. At this point, we can use
+
+28
+00:01:19,080 --> 00:01:20,550
+this to exclude some meaningless
+
+29
+00:01:20,550 --> 00:01:23,170
+combinations. For instance, consider special characters.
+
+30
+00:01:23,170 --> 00:01:25,130
+If we have a string of length 0, which means a
+
+31
+00:01:25,130 --> 00:01:26,850
+string with no characters. Obviously, there
+
+32
+00:01:26,850 --> 00:01:28,760
+cannot be special characters. So, considering
+
+33
+00:01:28,760 --> 00:01:31,020
+this combination will just be a waste of time. So what
+
+34
+00:01:31,020 --> 00:01:33,770
+we do is that we specify next to this choice, that we
+
+35
+00:01:33,770 --> 00:01:36,360
+will only consider this if length is not 0. And we
+
+36
+00:01:36,360 --> 00:01:41,110
+do this by saying that we consider this only if not zerovalue.
+
+37
+00:01:41,110 --> 00:01:43,970
+So, if zerovalue is not defined. So this pair is an
+
+38
+00:01:43,970 --> 00:01:47,640
+example of a property...if case. Define a property and use that
+
+39
+00:01:47,640 --> 00:01:49,770
+property. Now let's look at a case in which we might
+
+40
+00:01:49,770 --> 00:01:52,580
+want to use an error property. For instance, when we look at
+
+41
+00:01:52,580 --> 00:01:56,480
+the category value for the input size, the choice value less
+
+42
+00:01:56,480 --> 00:01:59,510
+than 0 is an erroneous choice. So it's a choice that
+
+43
+00:01:59,510 --> 00:02:02,630
+we selected to test a possibly erroneous situation, so we can
+
+44
+00:02:02,630 --> 00:02:06,160
+mark this as an error property. And what that means is that
+
+45
+00:02:06,160 --> 00:02:09,949
+when generating a combination of choices, we will consider this only
+
+46
+00:02:09,949 --> 00:02:12,990
+once because we assume that we just want to test this error condition
+
+47
+00:02:12,990 --> 00:02:16,260
+once. Finally, the single property is a property that we use
+
+48
+00:02:16,260 --> 00:02:19,050
+when we want to limit the number of test cases. And it's
+
+49
+00:02:19,050 --> 00:02:21,900
+similar as an effect to error. It just has a different
+
+50
+00:02:21,900 --> 00:02:24,410
+meaning. So what we do when we use the single property is
+
+51
+00:02:24,410 --> 00:02:27,420
+that we're saying that this choice, we want to use in only
+
+52
+00:02:27,420 --> 00:02:31,120
+one combination. So don't combine it multiple times. And that, of course,
+
+53
+00:02:31,120 --> 00:02:34,260
+given the combinatorial nature of the problem, cuts down dramatically
+
+54
+00:02:34,260 --> 00:02:36,370
+the number of test cases. And we might use, for
+
+55
+00:02:36,370 --> 00:02:39,500
+instance, the single property for maxint, which means that we
+
+56
+00:02:39,500 --> 00:02:41,890
+will only have one test case in which the size is
+
+57
+00:02:41,890 --> 00:02:44,300
+equal to maxint. We're actually going to see a demo
+
+58
+00:02:44,300 --> 00:02:46,880
+on this topic so we'll have more chances of seeing how
+
+59
+00:02:46,880 --> 00:02:49,370
+properties work in practice and how good they are at
+
+60
+00:02:49,370 --> 00:02:53,022
+eliminating meaningless combinations and at reducing the number of test cases.
diff --git a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/21 - Produce and Evaluate Test Case Specifications - lang_en_vs4.srt b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/21 - Produce and Evaluate Test Case Specifications - lang_en_vs4.srt
new file mode 100644
index 0000000..ebf8098
--- /dev/null
+++ b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/21 - Produce and Evaluate Test Case Specifications - lang_en_vs4.srt	
@@ -0,0 +1,111 @@
+1
+00:00:00,130 --> 00:00:03,200
+Before getting to our demo, we still have two steps to consider.
+
+2
+00:00:03,200 --> 00:00:06,570
+The first step corresponds to the identification of the test case specifications
+
+3
+00:00:06,570 --> 00:00:09,890
+in our general systematic approach. And in fact, it's called produce and
+
+4
+00:00:09,890 --> 00:00:13,410
+evaluate test case specifications. This is a step than can be completely
+
+5
+00:00:13,410 --> 00:00:16,590
+automated given the results of the previous steps. And the final result
+
+6
+00:00:16,590 --> 00:00:19,860
+of this step is the production of a set of test frames.
+
+7
+00:00:19,860 --> 00:00:22,820
+Where a test frame is the specification of a test. Let me
+
+8
+00:00:22,820 --> 00:00:25,330
+show you an example of this. What we are looking at here
+
+9
+00:00:25,330 --> 00:00:28,380
+is a test frame for the program split. Test frames are normally
+
+10
+00:00:28,380 --> 00:00:31,460
+identified by a sequence number. But in this case we are looking at
+
+11
+00:00:31,460 --> 00:00:34,290
+the 30th six test frame. And what they do is simply to
+
+12
+00:00:34,290 --> 00:00:38,280
+specify the characteristic of the inputs for that test. In this case, since
+
+13
+00:00:38,280 --> 00:00:40,920
+we have two inputs, we have two entries, the first one for
+
+14
+00:00:40,920 --> 00:00:44,010
+string str tells us that the length of the string has to be
+
+15
+00:00:44,010 --> 00:00:47,840
+size minus 1, and that the string has to contain special characters. And
+
+16
+00:00:47,840 --> 00:00:50,380
+for size, it tells us that the value of size has to be
+
+17
+00:00:50,380 --> 00:00:53,340
+greater than zero. As the title says, this step is meant
+
+18
+00:00:53,340 --> 00:00:56,790
+to produce but also evaluate the case specification. What does it mean
+
+19
+00:00:56,790 --> 00:01:00,070
+to evaluate? One of the advantages of this approach is that we
+
+20
+00:01:00,070 --> 00:01:03,420
+can easily use it to assess how many test frames and therefore
+
+21
+00:01:03,420 --> 00:01:06,120
+how many test cases we will generate with the current least
+
+22
+00:01:06,120 --> 00:01:09,340
+of categories, choices and constraints. And the beauty of this is that
+
+23
+00:01:09,340 --> 00:01:12,320
+if the number is too large we can just add additional constraints
+
+24
+00:01:12,320 --> 00:01:15,840
+and reduce it. And given then the step is automated we just
+
+25
+00:01:15,840 --> 00:01:19,030
+add constraints push a button and we get our new set of
+
+26
+00:01:19,030 --> 00:01:21,580
+test frames. And again we can have a wait it either go
+
+27
+00:01:21,580 --> 00:01:24,560
+hat or add more constraints if we need to further reduce it
+
+28
+00:01:24,560 --> 00:01:26,320
+and this is something else that we will see in our demo.
diff --git a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/22 - Generate Test Cases from Test Case Specifications - lang_en_vs4.srt b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/22 - Generate Test Cases from Test Case Specifications - lang_en_vs4.srt
new file mode 100644
index 0000000..7d74ae3
--- /dev/null
+++ b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/22 - Generate Test Cases from Test Case Specifications - lang_en_vs4.srt	
@@ -0,0 +1,91 @@
+1
+00:00:00,135 --> 00:00:01,935
+So we get to the last step of the technique in
+
+2
+00:00:01,935 --> 00:00:05,142
+which once we have generated test case specifications. We create test
+
+3
+00:00:05,142 --> 00:00:09,180
+cases starting from this specifications. This step mainly consists in a
+
+4
+00:00:09,180 --> 00:00:12,840
+simple instantiation of frames and it's final result is a set of
+
+5
+00:00:12,840 --> 00:00:16,840
+concrete tests. For our example, test frame number 36 that we
+
+6
+00:00:16,840 --> 00:00:19,270
+just saw, this will be the resulting test case, which has
+
+7
+00:00:19,270 --> 00:00:21,490
+the same ID, so that we can track it and will
+
+8
+00:00:21,490 --> 00:00:25,520
+specify to concrete values, not just the specification for the input elements.
+
+9
+00:00:25,520 --> 00:00:29,130
+So string STR will have this value. And the integer size
+
+10
+00:00:29,130 --> 00:00:31,720
+will have this value. And these two values satisfy what this
+
+11
+00:00:31,720 --> 00:00:35,260
+test case specification was. Which was, having a string contain special
+
+12
+00:00:35,260 --> 00:00:38,760
+characters. Here, we have two special characters, like the new line
+
+13
+00:00:38,760 --> 00:00:41,900
+and the tab. And, we have a size which is greater
+
+14
+00:00:41,900 --> 00:00:44,430
+than zero, in particular, okay? And this is a test case
+
+15
+00:00:44,430 --> 00:00:46,880
+that we can actually run on our code. That we can
+
+16
+00:00:46,880 --> 00:00:50,730
+run on the split program. So, to summarize, we perform six steps
+
+17
+00:00:50,730 --> 00:00:54,400
+in which we went from a high level description of what the program does, to a
+
+18
+00:00:54,400 --> 00:00:56,070
+set of concrete test cases. And this is
+
+19
+00:00:56,070 --> 00:00:57,880
+one of those test cases. So what, what we're
+
+20
+00:00:57,880 --> 00:01:00,210
+going to do next, we're going to do a mini-demo,
+
+21
+00:01:00,210 --> 00:01:02,260
+in which we do this for real. We take
+
+22
+00:01:02,260 --> 00:01:05,440
+the program, we identify categories, choices, constraints, and
+
+23
+00:01:05,440 --> 00:01:07,800
+we actually generate test frames and then test cases.
diff --git a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/23 - Category Partition Demo - lang_en_vs4.srt b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/23 - Category Partition Demo - lang_en_vs4.srt
new file mode 100644
index 0000000..51c2e52
--- /dev/null
+++ b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/23 - Category Partition Demo - lang_en_vs4.srt	
@@ -0,0 +1,867 @@
+1
+00:00:01,290 --> 00:00:03,210
+In this demo, we're going to do exactly what we
+
+2
+00:00:03,210 --> 00:00:06,370
+did just now in the lesson. We're going to use
+
+3
+00:00:06,370 --> 00:00:09,250
+the category partition method to go from a high-level
+
+4
+00:00:09,250 --> 00:00:12,930
+description of a piece of software of a program to
+
+5
+00:00:12,930 --> 00:00:15,512
+a set of test cases for that program. To
+
+6
+00:00:15,512 --> 00:00:17,640
+do that, we're going to use a simple tool. So
+
+7
+00:00:17,640 --> 00:00:21,040
+I'm going to show you here the tool that is
+
+8
+00:00:21,040 --> 00:00:26,380
+called a tsl generator right here. This tool is available
+
+9
+00:00:26,380 --> 00:00:28,520
+to you, so you can look in the class notes to
+
+10
+00:00:28,520 --> 00:00:31,900
+see information on how to download it. And together with the tool,
+
+11
+00:00:31,900 --> 00:00:34,890
+we are also going to provide a manual for the tool, and
+
+12
+00:00:34,890 --> 00:00:37,680
+a set of files that I'm going to use in this demo. So
+
+13
+00:00:37,680 --> 00:00:40,420
+you should be able to do exactly what I'm doing. So
+
+14
+00:00:40,420 --> 00:00:45,110
+again, all of those are available from the class notes. So specifically,
+
+15
+00:00:45,110 --> 00:00:48,390
+today we're going to write test cases for the grep program. So in
+
+16
+00:00:48,390 --> 00:00:51,970
+case you're familiar with the grep utility, this is a simplified version
+
+17
+00:00:51,970 --> 00:00:55,060
+of that utility. So basically the grep utility allows you
+
+18
+00:00:55,060 --> 00:00:58,410
+to search a file for the occurrences of a given
+
+19
+00:00:58,410 --> 00:01:01,552
+pattern. So you can invoke it, as it's shown here
+
+20
+00:01:01,552 --> 00:01:05,570
+in the synopsis, by executing grep, the pattern that you're
+
+21
+00:01:05,570 --> 00:01:08,310
+looking for, and the filename in which you want to
+
+22
+00:01:08,310 --> 00:01:10,300
+look for the pattern. And let me read the description
+
+23
+00:01:10,300 --> 00:01:13,650
+of the grep utility. The grep utility searches files for
+
+24
+00:01:13,650 --> 00:01:17,110
+a pattern and brings all lines that contain that pattern
+
+25
+00:01:17,110 --> 00:01:20,900
+on the standard output. A line that contains multiple occurrences of
+
+26
+00:01:20,900 --> 00:01:24,350
+the pattern is printed only once. The pattern is any sequence
+
+27
+00:01:24,350 --> 00:01:27,700
+of characters. To include a blank in the pattern, the entire
+
+28
+00:01:27,700 --> 00:01:31,060
+pattern must be enclosed in single quotes. To include a quote
+
+29
+00:01:31,060 --> 00:01:34,420
+sign in the pattern, the quote sign must be escaped, which
+
+30
+00:01:34,420 --> 00:01:36,260
+means that we have to put a slash in front of
+
+31
+00:01:36,260 --> 00:01:39,290
+the quotes sign. And in general, it is safest to enclose
+
+32
+00:01:39,290 --> 00:01:42,210
+the entire pattern in single quotes. So this is our high
+
+33
+00:01:42,210 --> 00:01:45,420
+level description for the program, for the softer system, that
+
+34
+00:01:45,420 --> 00:01:47,270
+we need to test. So now let me show you
+
+35
+00:01:47,270 --> 00:01:50,600
+what a possible set of categories and partitions could be
+
+36
+00:01:50,600 --> 00:01:53,770
+for this program. So what I have here is a
+
+37
+00:01:53,770 --> 00:01:58,080
+file, a textual file, which contains all the categories and
+
+38
+00:01:58,080 --> 00:02:02,760
+partitions for the elements that are relevant for my program.
+
+39
+00:02:02,760 --> 00:02:05,240
+In particular, when we look at the file, we can
+
+40
+00:02:05,240 --> 00:02:07,809
+see that the file can be characterized by its size.
+
+41
+00:02:08,889 --> 00:02:12,160
+And in this case, I've got two choices. The file can
+
+42
+00:02:12,160 --> 00:02:16,050
+be empty or not empty. The second characteristic of the file
+
+43
+00:02:16,050 --> 00:02:19,490
+that I'm considering is the number of occurrences of the pattern
+
+44
+00:02:19,490 --> 00:02:22,320
+in the file. And I'm considering that the pattern might not occur
+
+45
+00:02:22,320 --> 00:02:25,780
+in the file or it might occur once, or multiple times.
+
+46
+00:02:25,780 --> 00:02:28,264
+I'm not going to go through the rest of the file because we
+
+47
+00:02:28,264 --> 00:02:31,234
+already covered how to apply the category partition method in the
+
+48
+00:02:31,234 --> 00:02:34,226
+lesson. So if you had doubts about that, about the method and
+
+49
+00:02:34,226 --> 00:02:36,952
+how to apply, you might want to go back and watch again the
+
+50
+00:02:36,952 --> 00:02:40,040
+lesson. What I want to show you here is how you can go
+
+51
+00:02:40,040 --> 00:02:43,670
+from this information that you have here, that we have derived by
+
+52
+00:02:43,670 --> 00:02:47,020
+applying the, the first steps of the method, to a set of
+
+53
+00:02:47,020 --> 00:02:50,650
+test frames, and then, a set of test packs. So to do
+
+54
+00:02:50,650 --> 00:02:53,240
+that we're going to use the tool that I just mentioned. So let
+
+55
+00:02:53,240 --> 00:02:56,670
+me bring back my terminal. So first of all, let's see how
+
+56
+00:02:56,670 --> 00:02:59,570
+we can run the tool. So you have a manual that will explain
+
+57
+00:02:59,570 --> 00:03:02,180
+all the details on how to build the file that we're
+
+58
+00:03:02,180 --> 00:03:04,350
+going to feed the tool. So what is the format and so
+
+59
+00:03:04,350 --> 00:03:07,780
+on. Here I'm just going to see how I can run the
+
+60
+00:03:07,780 --> 00:03:10,828
+tool. So first of all, let me point out that this was
+
+61
+00:03:10,828 --> 00:03:15,028
+developed together by professors from the University of California Irvine and
+
+62
+00:03:15,028 --> 00:03:18,020
+Oregon State University. And as you can see, we can run
+
+63
+00:03:18,020 --> 00:03:20,968
+TSL generator and specify that we want to see the main
+
+64
+00:03:20,968 --> 00:03:24,361
+page. So in this case if we run it this, this way,
+
+65
+00:03:24,361 --> 00:03:27,723
+you'll have some basic information on how to run
+
+66
+00:03:27,723 --> 00:03:30,720
+the tool. And from the main page you can see
+
+67
+00:03:30,720 --> 00:03:33,520
+that you can specify the minus c flag and in
+
+68
+00:03:33,520 --> 00:03:37,360
+this case the TSL generator will report the number of
+
+69
+00:03:37,360 --> 00:03:41,410
+test frames generated without writing them to output. For
+
+70
+00:03:41,410 --> 00:03:43,828
+example, you might want to use this as we will do
+
+71
+00:03:43,828 --> 00:03:46,308
+to see how many tests that you will generate with
+
+72
+00:03:46,308 --> 00:03:49,630
+a current set of category partitions and choices. The minus
+
+73
+00:03:49,630 --> 00:03:52,620
+s option will bring the result of the TSL
+
+74
+00:03:52,620 --> 00:03:55,620
+generator on the standard output. And finally, you can
+
+75
+00:03:55,620 --> 00:03:58,330
+use minus o to specify an output file, where
+
+76
+00:03:58,330 --> 00:04:01,010
+to put the output of the program. So let's
+
+77
+00:04:01,010 --> 00:04:05,070
+at first run our TSL generator by specifying the
+
+78
+00:04:05,070 --> 00:04:08,620
+minus c option and by bypassing our current set
+
+79
+00:04:08,620 --> 00:04:11,860
+of category partitions and choices. Okay, so let me
+
+80
+00:04:11,860 --> 00:04:15,140
+remind you that what the, the tool will do
+
+81
+00:04:15,140 --> 00:04:17,790
+is what we will do manually. Otherwise, which is
+
+82
+00:04:17,790 --> 00:04:20,380
+to combine all these choices so as to have one
+
+83
+00:04:20,380 --> 00:04:23,305
+test case for each combination. So if we do
+
+84
+00:04:23,305 --> 00:04:27,412
+that, you can see that the tool tells us that
+
+85
+00:04:27,412 --> 00:04:32,383
+we will generate 7776 test frames in this case.
+
+86
+00:04:32,383 --> 00:04:34,660
+And this seems to be a little too much for
+
+87
+00:04:34,660 --> 00:04:36,868
+a program as small as the one that we are
+
+88
+00:04:36,868 --> 00:04:40,341
+testing. And assume for instance that we don't have the
+
+89
+00:04:40,341 --> 00:04:43,149
+resources to run this many test cases for, for
+
+90
+00:04:43,149 --> 00:04:46,518
+the grep program. In addition, consider that in this case,
+
+91
+00:04:46,518 --> 00:04:50,356
+we're computing all possible combinations of choices. And there's going to
+
+92
+00:04:50,356 --> 00:04:52,384
+be some combination that do not make sense as we
+
+93
+00:04:52,384 --> 00:04:54,945
+discussed in the lesson. So what we might want to
+
+94
+00:04:54,945 --> 00:04:57,051
+do in this case is to go back to our
+
+95
+00:04:57,051 --> 00:05:03,120
+spec and start adding constraints to eliminate this meaningless combination.
+
+96
+00:05:03,120 --> 00:05:05,980
+So I'm going to show you the result of doing that.
+
+97
+00:05:05,980 --> 00:05:08,690
+And I'm going to show you a few examples.
+
+98
+00:05:08,690 --> 00:05:11,670
+For example here, when the file is empty, I'm going to
+
+99
+00:05:11,670 --> 00:05:15,010
+define this property empty file. And how am I
+
+100
+00:05:15,010 --> 00:05:18,490
+going to use this property? Well for example here, it
+
+101
+00:05:18,490 --> 00:05:20,760
+doesn't make sense to consider the case in which
+
+102
+00:05:20,760 --> 00:05:24,660
+we have one or many occurrences of the pattern in
+
+103
+00:05:24,660 --> 00:05:27,020
+the file if the file is empty. Therefore I'm
+
+104
+00:05:27,020 --> 00:05:31,650
+going to tell the tool that it should consider this specific
+
+105
+00:05:31,650 --> 00:05:35,780
+choice only if the file is not empty, only if
+
+106
+00:05:35,780 --> 00:05:38,660
+empty file is not defined. And that will skip, for
+
+107
+00:05:38,660 --> 00:05:41,330
+example, all of the combinations in which the file is
+
+108
+00:05:41,330 --> 00:05:44,171
+empty. And I'm trying to generate the test case that has
+
+109
+00:05:44,171 --> 00:05:46,364
+one occurrence of the pattern in the file, which is
+
+110
+00:05:46,364 --> 00:05:49,355
+simply not possible. For another example, in case I have
+
+111
+00:05:49,355 --> 00:05:52,824
+an empty pattern, I define the property empty pattern. And
+
+112
+00:05:52,824 --> 00:05:56,725
+then I avoid the choices that involve the pattern in case
+
+113
+00:05:56,725 --> 00:05:59,820
+the pattern is empty. because, for example, I cannot
+
+114
+00:05:59,820 --> 00:06:03,900
+have quotes in a pattern that is empty. For example,
+
+115
+00:06:03,900 --> 00:06:06,760
+it doesn't make sense to have blanks. So, one or
+
+116
+00:06:06,760 --> 00:06:10,250
+more blanks if the pattern is empty. So I'm going to
+
+117
+00:06:10,250 --> 00:06:14,180
+specify again that this choice should be considered only if
+
+118
+00:06:14,180 --> 00:06:16,140
+we don't have an empty pattern. And so on and
+
+119
+00:06:16,140 --> 00:06:20,080
+so forth. So now after I edit these constraints, I
+
+120
+00:06:20,080 --> 00:06:21,890
+can go back and compute again the number of test
+
+121
+00:06:21,890 --> 00:06:23,970
+frames and therefore the test cases that will be
+
+122
+00:06:23,970 --> 00:06:27,530
+generated with these constraints. So let me go again
+
+123
+00:06:27,530 --> 00:06:30,381
+to my terminal. Okay, so now I'm going to run
+
+124
+00:06:30,381 --> 00:06:34,061
+my TSL generator again, and I'm going to run it on
+
+125
+00:06:34,061 --> 00:06:37,389
+the second version of this file. And you can
+
+126
+00:06:37,389 --> 00:06:40,546
+see that I reduced the, the number of test frames
+
+127
+00:06:40,546 --> 00:06:43,889
+from about 7800 to about 1700. So it's quite
+
+128
+00:06:43,889 --> 00:06:46,967
+a, quite a big reduction by eliminating all these combinations
+
+129
+00:06:46,967 --> 00:06:49,540
+that do not make sense. But let's assume again that
+
+130
+00:06:49,540 --> 00:06:52,040
+we want to reduce this further so that we don't want to
+
+131
+00:06:52,040 --> 00:06:55,610
+generate those many test frames and therefore test cases. So
+
+132
+00:06:55,610 --> 00:06:58,660
+what can we do? We go back to our spec. And
+
+133
+00:06:58,660 --> 00:07:02,280
+in this case, we start adding error constraints. So if
+
+134
+00:07:02,280 --> 00:07:05,200
+you remember what we said in the lesson, error constraints are
+
+135
+00:07:05,200 --> 00:07:08,310
+constraints that indicate a choice that has to do with an
+
+136
+00:07:08,310 --> 00:07:11,980
+erroneous behaviour. For example, an erroneous input provided to the problem.
+
+137
+00:07:11,980 --> 00:07:15,210
+So here for instance, we're indicating the presence
+
+138
+00:07:15,210 --> 00:07:20,060
+of incorrectly enclosing quotes as an error choice. Same
+
+139
+00:07:20,060 --> 00:07:22,270
+thing if there's no file corresponding to the
+
+140
+00:07:22,270 --> 00:07:23,970
+name that we provide to the tool, we say
+
+141
+00:07:23,970 --> 00:07:26,760
+that this corresponds to an error. So how
+
+142
+00:07:26,760 --> 00:07:29,130
+is the tool going to use this information? It uses
+
+143
+00:07:29,130 --> 00:07:33,980
+this information by producing only one combination that involves
+
+144
+00:07:33,980 --> 00:07:37,270
+error choices, instead of combining them with other choices.
+
+145
+00:07:37,270 --> 00:07:39,780
+So let's see what happens after we added this
+
+146
+00:07:39,780 --> 00:07:43,370
+error constraints. So we go back to our console
+
+147
+00:07:43,370 --> 00:07:46,920
+once more. And in this case, we want to run
+
+148
+00:07:46,920 --> 00:07:50,910
+the TSL generator with the version of the, of my
+
+149
+00:07:50,910 --> 00:07:53,900
+file that contains the area of constraints. And again,
+
+150
+00:07:53,900 --> 00:07:56,390
+I reduce quite a bit the number of test frames.
+
+151
+00:07:56,390 --> 00:07:59,110
+So now I have only 562 test frames that
+
+152
+00:07:59,110 --> 00:08:02,660
+will be generated by using the file that I provided.
+
+153
+00:08:02,660 --> 00:08:05,460
+So for the last time, let's assume that we really want
+
+154
+00:08:05,460 --> 00:08:07,780
+to cut down the number of test frames or the number of
+
+155
+00:08:07,780 --> 00:08:10,380
+test cases. So once more, we go back to our file, and
+
+156
+00:08:10,380 --> 00:08:12,980
+at this point what we can add is the final type of
+
+157
+00:08:12,980 --> 00:08:14,170
+constraints that we have, which are
+
+158
+00:08:14,170 --> 00:08:17,245
+single constraints. And single constraints are
+
+159
+00:08:17,245 --> 00:08:21,360
+basically indicated choices that we don't want to combine with other choices.
+
+160
+00:08:21,360 --> 00:08:24,210
+So they have the same effect of the error constraints, but they
+
+161
+00:08:24,210 --> 00:08:28,120
+have a different meaning, so they do not indicate choices that corresponds
+
+162
+00:08:28,120 --> 00:08:29,860
+to an error. In other words, I can use a
+
+163
+00:08:29,860 --> 00:08:35,280
+single constraints to identify choices that I want to test only once.
+
+164
+00:08:35,280 --> 00:08:38,510
+So for example in this case, I might decide that I
+
+165
+00:08:38,510 --> 00:08:42,520
+want to have only one test frame that tests my program
+
+166
+00:08:42,520 --> 00:08:44,420
+with a file being empty and I can do the
+
+167
+00:08:44,420 --> 00:08:47,370
+same for other choices. So basically I can continue adding this
+
+168
+00:08:47,370 --> 00:08:50,400
+single constraint until I get down to the number of test
+
+169
+00:08:50,400 --> 00:08:53,410
+frames and therefore the number of test cases that I want.
+
+170
+00:08:53,410 --> 00:08:57,770
+So now let's go back once more to our console. And so now if we run
+
+171
+00:08:59,060 --> 00:09:04,450
+using this file as input, you can see that we have 35 test frames generated. So
+
+172
+00:09:04,450 --> 00:09:07,750
+this is a fairly low number of test cases, so we might decide that we want to
+
+173
+00:09:07,750 --> 00:09:13,380
+go ahead and write these test frames to a file. So now let's open this file
+
+174
+00:09:15,990 --> 00:09:25,500
+that we just generated. And as you can see here, I have exactly 35 test frames,
+
+175
+00:09:26,670 --> 00:09:30,900
+as expected. Some of those correspond to the single and error cases. So in this
+
+176
+00:09:30,900 --> 00:09:33,330
+case, the only choice that I have indicated
+
+177
+00:09:33,330 --> 00:09:35,690
+is the one that corresponds to the single
+
+178
+00:09:35,690 --> 00:09:38,310
+or error constraint. What is for the other
+
+179
+00:09:38,310 --> 00:09:42,170
+ones? I actually have the whole test spec.
+
+180
+00:09:42,170 --> 00:09:45,530
+So let's pick one just to give you an example.
+
+181
+00:09:45,530 --> 00:09:48,440
+In this case, that's frame number 15 that will correspond to
+
+182
+00:09:48,440 --> 00:09:51,910
+test case number 15. And here you can see that
+
+183
+00:09:51,910 --> 00:09:55,280
+we have all the information. So this is a test specification.
+
+184
+00:09:55,280 --> 00:09:57,560
+All the information that we need to generate the corresponding
+
+185
+00:09:57,560 --> 00:09:59,760
+test. We know that we need a file that is not
+
+186
+00:09:59,760 --> 00:10:03,810
+empty. That we need to have one occurrence of the pattern
+
+187
+00:10:03,810 --> 00:10:07,580
+in the file. One occurrence of the pattern in one line.
+
+188
+00:10:08,680 --> 00:10:10,360
+The position of the pattern in the file can
+
+189
+00:10:10,360 --> 00:10:13,740
+be any position. The length of the pattern must
+
+190
+00:10:13,740 --> 00:10:16,640
+be more than one character. The pattern should not
+
+191
+00:10:16,640 --> 00:10:20,140
+be enclosed in quotes. There should be one white
+
+192
+00:10:20,140 --> 00:10:24,460
+space, one quote within the pattern, and finally the
+
+193
+00:10:24,460 --> 00:10:27,230
+file that would pass through the program should exist.
+
+194
+00:10:27,230 --> 00:10:29,680
+So the file should be present. So I can
+
+195
+00:10:29,680 --> 00:10:33,950
+easily transform all of this into an actual test case.
+
+196
+00:10:33,950 --> 00:10:35,540
+And notice that even though we're not, we're not
+
+197
+00:10:35,540 --> 00:10:38,420
+going to do it here. In cases like this, it might
+
+198
+00:10:38,420 --> 00:10:42,190
+even be possible to automatically generate the test cases
+
+199
+00:10:42,190 --> 00:10:45,020
+from the test specifications because, here for example, here it
+
+200
+00:10:45,020 --> 00:10:48,150
+should be relatively straight forward to parse these test
+
+201
+00:10:48,150 --> 00:10:52,450
+specifications and generate test cases accordingly. So, just to summarize,
+
+202
+00:10:52,450 --> 00:10:55,910
+what we have done is to go from one high-level
+
+203
+00:10:55,910 --> 00:10:58,880
+description of a program to a set of categories, partitions,
+
+204
+00:10:58,880 --> 00:11:01,820
+and choices for that program. Then we have combined them
+
+205
+00:11:01,820 --> 00:11:04,930
+in different ways, adding more and more constraints to reduce the
+
+206
+00:11:04,930 --> 00:11:07,600
+number of combinations until we ended up with the right number
+
+207
+00:11:07,600 --> 00:11:09,650
+of test cases, so the number of test cases that we
+
+208
+00:11:09,650 --> 00:11:14,630
+were fine generating. We generated the corresponding test specifications. And at
+
+209
+00:11:14,630 --> 00:11:17,340
+that point, we could just go ahead, generate the test case,
+
+210
+00:11:17,340 --> 00:11:20,660
+and test our application. So, and you can see how this
+
+211
+00:11:20,660 --> 00:11:23,720
+can result in a much more thorough testing of your application.
+
+212
+00:11:23,720 --> 00:11:27,890
+Because instead of reading this description and just trying to come up with test
+
+213
+00:11:27,890 --> 00:11:33,900
+cases for it, we can break down the process in steps that are easy to perform
+
+214
+00:11:33,900 --> 00:11:36,960
+individually. They can be automated as much
+
+215
+00:11:36,960 --> 00:11:38,600
+as possible. And they will end up with
+
+216
+00:11:38,600 --> 00:11:40,380
+a set of test cases that will test
+
+217
+00:11:40,380 --> 00:11:42,790
+all the interests and aspects of your application.
diff --git a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/24 - Model Based Testing - lang_en_vs4.srt b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/24 - Model Based Testing - lang_en_vs4.srt
new file mode 100644
index 0000000..3d41cd9
--- /dev/null
+++ b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/24 - Model Based Testing - lang_en_vs4.srt	
@@ -0,0 +1,83 @@
+1
+00:00:00,370 --> 00:00:02,950
+What we just saw with the category-partition method, is a
+
+2
+00:00:02,950 --> 00:00:05,530
+specific instance of this systematic
+
+3
+00:00:05,530 --> 00:00:08,230
+functional testing approach. So specific instance
+
+4
+00:00:08,230 --> 00:00:10,900
+of the steps that we represented here. And, as I
+
+5
+00:00:10,900 --> 00:00:13,100
+mentioned earlier on, this is not the only way in which
+
+6
+00:00:13,100 --> 00:00:16,700
+you can generate test cases, starting from a functional specification.
+
+7
+00:00:16,700 --> 00:00:20,190
+In particular, this step, in which we identified relevant inputs and
+
+8
+00:00:20,190 --> 00:00:23,390
+then we combine them to generate test case specifications, can also
+
+9
+00:00:23,390 --> 00:00:25,490
+be done in different ways. And, we're going to look at one
+
+10
+00:00:25,490 --> 00:00:28,170
+of these ways. Which is through the construction of a
+
+11
+00:00:28,170 --> 00:00:31,040
+model. And, the reason why I want to talk about models.
+
+12
+00:00:31,040 --> 00:00:34,090
+Is because, model based testing is also, fairly popular in
+
+13
+00:00:34,090 --> 00:00:37,680
+industry. And fairly used in practice. In model based testing, the
+
+14
+00:00:37,680 --> 00:00:41,150
+way in which we go from specifications, to test cases,
+
+15
+00:00:41,150 --> 00:00:44,220
+is through the construction of a model. Where a model is
+
+16
+00:00:44,220 --> 00:00:47,670
+an abstract representation of the software under test. Also in
+
+17
+00:00:47,670 --> 00:00:50,860
+this case there are many possible models, that we can use.
+
+18
+00:00:50,860 --> 00:00:52,180
+And what we're going to do, we're going to focus
+
+19
+00:00:52,180 --> 00:00:54,370
+on a specific kind of model. And I'll
+
+20
+00:00:54,370 --> 00:00:57,010
+just point you to additional sources of information,
+
+21
+00:00:57,010 --> 00:00:59,070
+in case you're interested in seeing other examples.
diff --git a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/25 - Finite State Machines - lang_en_vs4.srt b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/25 - Finite State Machines - lang_en_vs4.srt
new file mode 100644
index 0000000..26f2fd7
--- /dev/null
+++ b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/25 - Finite State Machines - lang_en_vs4.srt	
@@ -0,0 +1,103 @@
+1
+00:00:00,160 --> 00:00:02,320
+The model that we will consider, is a very well
+
+2
+00:00:02,320 --> 00:00:05,330
+known one. Which is finite state machines. And you might have
+
+3
+00:00:05,330 --> 00:00:08,320
+seen them before. At a high level, a state machine is
+
+4
+00:00:08,320 --> 00:00:11,990
+a graph in which nodes represent states of the system. For
+
+5
+00:00:11,990 --> 00:00:15,650
+example, in this case, state 1, state 2, and state 3.
+
+6
+00:00:15,650 --> 00:00:19,950
+Edges represent transitions between states. For instance, in this case we
+
+7
+00:00:19,950 --> 00:00:22,850
+have one edge from state 1, to state 2. That means
+
+8
+00:00:22,850 --> 00:00:25,640
+that the system can go from state 1, to state 2.
+
+9
+00:00:25,640 --> 00:00:29,530
+And finally, the labels on the edges represent events
+
+10
+00:00:29,530 --> 00:00:32,800
+and actions. For example, what this label means is that
+
+11
+00:00:32,800 --> 00:00:35,400
+the system goes from state three to state two
+
+12
+00:00:35,400 --> 00:00:39,140
+when event five occurs. And when going from state three
+
+13
+00:00:39,140 --> 00:00:42,190
+to state two, it generates action four. And does
+
+14
+00:00:42,190 --> 00:00:45,430
+reacher model, sir reacher's kind of state machines, but we're
+
+15
+00:00:45,430 --> 00:00:48,160
+just going to stick to this ones which are enough. For
+
+16
+00:00:48,160 --> 00:00:50,760
+our purpose. So how do we build such a final
+
+17
+00:00:50,760 --> 00:00:53,530
+state machine starting from a specification? The first thing
+
+18
+00:00:53,530 --> 00:00:56,660
+we need to do is to identify the system's boundaries
+
+19
+00:00:56,660 --> 00:00:59,250
+and the input and output to the system. Once we
+
+20
+00:00:59,250 --> 00:01:01,960
+have done that, we can identify, within the boundaries of
+
+21
+00:01:01,960 --> 00:01:06,070
+the system, the relevant states and transitions. So we split
+
+22
+00:01:06,070 --> 00:01:09,670
+this single state We'll refine it into several states. And
+
+23
+00:01:09,670 --> 00:01:12,640
+we also identify how the system can go from one
+
+24
+00:01:12,640 --> 00:01:16,830
+state to another. Including which inputs cause which transition, and
+
+25
+00:01:16,830 --> 00:01:19,350
+which result in outputs we can obtain. To
+
+26
+00:01:19,350 --> 00:01:21,810
+better illustrate that, let's look at a concrete example.
diff --git a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/26 - Finite State Machines Example - lang_en_vs4.srt b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/26 - Finite State Machines Example - lang_en_vs4.srt
new file mode 100644
index 0000000..f889057
--- /dev/null
+++ b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/26 - Finite State Machines Example - lang_en_vs4.srt	
@@ -0,0 +1,251 @@
+1
+00:00:00,140 --> 00:00:03,010
+In this example, we're going to start from an informal specification, and the
+
+2
+00:00:03,010 --> 00:00:06,670
+specification is the one shown here in file spec.txt. This is the
+
+3
+00:00:06,670 --> 00:00:10,210
+specification for the maintenance function in a specific system. So what we're
+
+4
+00:00:10,210 --> 00:00:13,630
+doing is that we're taking the description of the functionality of a system,
+
+5
+00:00:13,630 --> 00:00:16,219
+and we're building a model, in this case a final state machine
+
+6
+00:00:16,219 --> 00:00:18,710
+for it. And there is no need to look at all the details
+
+7
+00:00:18,710 --> 00:00:21,350
+for this specification, but I want to point out that if you
+
+8
+00:00:21,350 --> 00:00:25,640
+look at the way the specification is written, we can identify specific cases
+
+9
+00:00:25,640 --> 00:00:28,210
+that we need to take into account. Like here if something
+
+10
+00:00:28,210 --> 00:00:31,920
+happens, something else will follow. Again, if something happens something else
+
+11
+00:00:31,920 --> 00:00:35,690
+will follow. So we have multiple choices here. Here will determine
+
+12
+00:00:35,690 --> 00:00:38,140
+the next steps and so on. So all we have to
+
+13
+00:00:38,140 --> 00:00:42,420
+do is to go through this process, identify these cases and
+
+14
+00:00:42,420 --> 00:00:45,300
+then build a machine that represents these cases. For the spec
+
+15
+00:00:45,300 --> 00:00:47,830
+that we just consider this is the state machine that will
+
+16
+00:00:47,830 --> 00:00:50,960
+result. Again there is no need to go through all the details,
+
+17
+00:00:50,960 --> 00:00:53,090
+but what I want to point out is that we have
+
+18
+00:00:53,090 --> 00:00:55,710
+a set of states. So for instance, we have state zero,
+
+19
+00:00:55,710 --> 00:00:58,380
+which is no maintenance, and if a request comes in, the
+
+20
+00:00:58,380 --> 00:01:01,350
+system will move, and the system wait for pickup. Then if
+
+21
+00:01:01,350 --> 00:01:04,400
+the pickup actually occurs, the system will move to the repair
+
+22
+00:01:04,400 --> 00:01:07,540
+state, and so on and so forth. So this is just
+
+23
+00:01:07,540 --> 00:01:13,070
+a more systematic representation of what was in the former specification.
+
+24
+00:01:13,070 --> 00:01:16,160
+And I will argue that this is much easier to understand at
+
+25
+00:01:16,160 --> 00:01:19,170
+least for somebody who has to develop tests for this system. In
+
+26
+00:01:19,170 --> 00:01:21,770
+fact what we're going to see next is how we can go from that
+
+27
+00:01:21,770 --> 00:01:24,790
+representation to a set of test cases. And the way which we do
+
+28
+00:01:24,790 --> 00:01:28,950
+it is by covering the behaviors represented by defining state machine. And we
+
+29
+00:01:28,950 --> 00:01:31,500
+can decide how we want to cover them. For example we might want
+
+30
+00:01:31,500 --> 00:01:35,080
+to cover all the states. So we might want to identify paths in
+
+31
+00:01:35,080 --> 00:01:38,310
+the state machine that go through all the states in the machine. Like
+
+32
+00:01:38,310 --> 00:01:41,840
+the one I just draw or this one, this one and this one.
+
+33
+00:01:41,840 --> 00:01:44,900
+So if we consider these four test cases, we can see that all the
+
+34
+00:01:44,900 --> 00:01:48,470
+states in my system or at least all the states that I have identified
+
+35
+00:01:48,470 --> 00:01:51,450
+are covered. I might want to go a little further, and decide that I
+
+36
+00:01:51,450 --> 00:01:54,210
+don't only want to cover all of the states, but I want to cover, all
+
+37
+00:01:54,210 --> 00:01:57,930
+of the transitions, because, it makes sense to visit a state, when coming from
+
+38
+00:01:57,930 --> 00:02:00,380
+different states. And, if I want to do that, and I look at the
+
+39
+00:02:00,380 --> 00:02:03,440
+test cases that I generated so far, I can see that there is one
+
+40
+00:02:03,440 --> 00:02:06,910
+transition, the one here, that is not covered. And, the same can be said for
+
+41
+00:02:06,910 --> 00:02:09,210
+the two transitions here. So what I can decide to do is
+
+42
+00:02:09,210 --> 00:02:13,370
+to generate another test case, that covers those or extend an existing one.
+
+43
+00:02:13,370 --> 00:02:16,500
+For instance, I could extend this test case by adding a visit to
+
+44
+00:02:16,500 --> 00:02:20,760
+the state, before going back to these two. Alternatively, I could also generate
+
+45
+00:02:20,760 --> 00:02:24,390
+new test cases, such as this one. To cover the missing transitions.
+
+46
+00:02:24,390 --> 00:02:26,350
+And once I have these test cases, I can express them in a
+
+47
+00:02:26,350 --> 00:02:29,860
+clearer way by simply specifying what are the states that they cover. I'm
+
+48
+00:02:29,860 --> 00:02:31,990
+just going to give you a couple of examples. Say, if we look
+
+49
+00:02:31,990 --> 00:02:34,280
+at the last one that I added, which will be test case
+
+50
+00:02:34,280 --> 00:02:37,190
+number five, I just need to specify that it will go through state
+
+51
+00:02:37,190 --> 00:02:41,090
+zero, which is this one, five, which is this one, six, and
+
+52
+00:02:41,090 --> 00:02:43,130
+then back to zero. And I can do the same for the other
+
+53
+00:02:43,130 --> 00:02:46,500
+test cases. So this will be my complete set of test cases.
+
+54
+00:02:46,500 --> 00:02:50,060
+So the bottom line here is that it is much harder to build
+
+55
+00:02:50,060 --> 00:02:53,080
+a set of test cases that will cover the behavior of an informal
+
+56
+00:02:53,080 --> 00:02:56,970
+description. But by going through a model, so by building in this case,
+
+57
+00:02:56,970 --> 00:03:01,700
+a finite state machine for that description, we can, in a much easier way, see
+
+58
+00:03:01,700 --> 00:03:04,100
+what the behaviors of interest of the system
+
+59
+00:03:04,100 --> 00:03:05,960
+are, and try to cover them. And there
+
+60
+00:03:05,960 --> 00:03:07,400
+is again in the spirit of breaking
+
+61
+00:03:07,400 --> 00:03:09,950
+down a complex problem into smaller steps that
+
+62
+00:03:09,950 --> 00:03:11,620
+we can better manage, which in the end,
+
+63
+00:03:11,620 --> 00:03:14,450
+results in a more efficient and effective testing.
diff --git a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/27 - Finite State Machines Considerations - lang_en_vs4.srt b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/27 - Finite State Machines Considerations - lang_en_vs4.srt
new file mode 100644
index 0000000..64c2c00
--- /dev/null
+++ b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/27 - Finite State Machines Considerations - lang_en_vs4.srt	
@@ -0,0 +1,99 @@
+1
+00:00:00,100 --> 00:00:03,060
+There are some important considerations I want to make on final state
+
+2
+00:00:03,060 --> 00:00:06,410
+machines. And more in general, on model based testing. The first one
+
+3
+00:00:06,410 --> 00:00:10,600
+is about applicability. Testing based on final state machines is a very
+
+4
+00:00:10,600 --> 00:00:13,890
+general approach, that we can apply in a number of contexts. And in
+
+5
+00:00:13,890 --> 00:00:16,510
+particular, if you are working with UML, you have state machines for
+
+6
+00:00:16,510 --> 00:00:19,720
+free. Because state charts are nothing else but a special kind of
+
+7
+00:00:19,720 --> 00:00:22,210
+state machine. So you can apply the technique that we just saw
+
+8
+00:00:22,210 --> 00:00:26,010
+directly on state charts, and try to cover their states and their transitions.
+
+9
+00:00:26,010 --> 00:00:29,980
+Another important point is that abstraction is key. You have to find the
+
+10
+00:00:29,980 --> 00:00:33,280
+right level of abstraction. The bigger the system, the more you have to
+
+11
+00:00:33,280 --> 00:00:36,130
+abstract if you want to represent it with a model, and in particular, with
+
+12
+00:00:36,130 --> 00:00:38,710
+the final state machine. So it's like having a slider, and you have
+
+13
+00:00:38,710 --> 00:00:41,840
+to decide where you want to move on that slider. The more you represent,
+
+14
+00:00:41,840 --> 00:00:44,700
+the more complex your system is going to be and the more thorough your
+
+15
+00:00:44,700 --> 00:00:48,110
+testing is going to be but also more expensive. The less you represent the
+
+16
+00:00:48,110 --> 00:00:51,330
+less expensive testing is going to be, but also testing might not be as
+
+17
+00:00:51,330 --> 00:00:53,500
+thorough as it would be otherwise. So you have to find
+
+18
+00:00:53,500 --> 00:00:56,150
+the right balance between abstracting the weight too much and abstracting
+
+19
+00:00:56,150 --> 00:00:59,840
+the weight too little. And finally there are many other approaches.
+
+20
+00:00:59,840 --> 00:01:02,840
+So we just scratched the surface, and we just saw one possible
+
+21
+00:01:02,840 --> 00:01:05,760
+approach. But for instance, other models that you can use are
+
+22
+00:01:05,760 --> 00:01:09,780
+decision tables, flow graphs and even historical models. Models that can
+
+23
+00:01:09,780 --> 00:01:13,560
+guide your testing based on problems that occurred in your system
+
+24
+00:01:13,560 --> 00:01:16,500
+in the past. And also, in this case, I'm going to put pointers
+
+25
+00:01:16,500 --> 00:01:18,460
+to additional materials in the class notes.
diff --git a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/28 - Summary - lang_en_vs4.srt b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/28 - Summary - lang_en_vs4.srt
new file mode 100644
index 0000000..1b68b9f
--- /dev/null
+++ b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/28 - Summary - lang_en_vs4.srt	
@@ -0,0 +1,67 @@
+1
+00:00:00,110 --> 00:00:01,600
+Now we are at the end of this lesson, and I
+
+2
+00:00:01,600 --> 00:00:04,450
+just want to wrap it up by summarizing what we've seen. We talked
+
+3
+00:00:04,450 --> 00:00:06,340
+about black-box testing, the testing of
+
+4
+00:00:06,340 --> 00:00:08,760
+software based on a functional specification,
+
+5
+00:00:08,760 --> 00:00:11,510
+a description of the software rather than its code. We saw a
+
+6
+00:00:11,510 --> 00:00:15,500
+systematic way of doing that, that allows for breaking down the problem
+
+7
+00:00:15,500 --> 00:00:19,140
+of testing software, so the problem of going from this functional specification
+
+8
+00:00:19,140 --> 00:00:22,540
+to a set of test cases into smaller steps, more manageable steps.
+
+9
+00:00:22,540 --> 00:00:25,466
+And we saw two main ways of doing this. One by identifying
+
+10
+00:00:25,466 --> 00:00:28,304
+relevant inputs for the main features in the system
+
+11
+00:00:28,304 --> 00:00:31,802
+and then deriving test case specifications and test cases from
+
+12
+00:00:31,802 --> 00:00:34,180
+this set of inputs. And the second way by
+
+13
+00:00:34,180 --> 00:00:36,780
+building a model for the main features of the system
+
+14
+00:00:36,780 --> 00:00:39,210
+and then using this model to decide how to
+
+15
+00:00:39,210 --> 00:00:41,680
+test the system. In the next lesson, we are going
+
+16
+00:00:41,680 --> 00:00:44,440
+to discuss, how to do testing by looking inside the
+
+17
+00:00:44,440 --> 00:00:47,716
+box? So, how to do testing in a white-box fashion.
diff --git a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/3 - Systematic Functional Testing Approach - lang_en_vs4.srt b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/3 - Systematic Functional Testing Approach - lang_en_vs4.srt
new file mode 100644
index 0000000..75da7e8
--- /dev/null
+++ b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/3 - Systematic Functional Testing Approach - lang_en_vs4.srt	
@@ -0,0 +1,179 @@
+1
+00:00:00,140 --> 00:00:02,690
+So what is the starting point of black box testing? Black
+
+2
+00:00:02,690 --> 00:00:06,010
+box testing start from a description of the software or as we
+
+3
+00:00:06,010 --> 00:00:09,590
+call it, a functional specification. And the final result of black
+
+4
+00:00:09,590 --> 00:00:12,760
+box testing is a set of test cases, a set of actual
+
+5
+00:00:12,760 --> 00:00:16,410
+inputs and corresponding outputs that we can use to exercise our
+
+6
+00:00:16,410 --> 00:00:19,030
+code and to try to find defects in our code. So the
+
+7
+00:00:19,030 --> 00:00:22,060
+question is, how do we get from functional specification to test
+
+8
+00:00:22,060 --> 00:00:25,510
+cases? Doing these derivations, so going from this description to a concrete
+
+9
+00:00:25,510 --> 00:00:28,550
+set of tests, is a very complex analytical process.
+
+10
+00:00:28,550 --> 00:00:31,220
+And normally brute force generation is not a good
+
+11
+00:00:31,220 --> 00:00:34,430
+idea because it's inefficient and ineffective. What we want
+
+12
+00:00:34,430 --> 00:00:37,540
+to do instead is to have a systematic approach to
+
+13
+00:00:37,540 --> 00:00:40,250
+derive test cases from a functional specification. What a
+
+14
+00:00:40,250 --> 00:00:43,970
+systematic approach does is to simplify the overall problem by
+
+15
+00:00:43,970 --> 00:00:48,320
+dividing the process into elementary steps. In particular, in
+
+16
+00:00:48,320 --> 00:00:50,520
+this case, we will perform three main steps. The first
+
+17
+00:00:50,520 --> 00:00:55,790
+step is to identify independently testable features. Individual features in
+
+18
+00:00:55,790 --> 00:00:57,600
+the soft hood that we can test. And we're going to
+
+19
+00:00:57,600 --> 00:00:59,990
+expand on each one of these steps in the next
+
+20
+00:00:59,990 --> 00:01:02,490
+part of the lesson. The following step is once we have
+
+21
+00:01:02,490 --> 00:01:06,000
+these independently testable features to identify what are the relevant
+
+22
+00:01:06,000 --> 00:01:08,590
+inputs. So what are the inputs or the behavior that is
+
+23
+00:01:08,590 --> 00:01:11,610
+worth testing for these features. Next once we have these
+
+24
+00:01:11,610 --> 00:01:13,020
+inputs, we're going to derive test
+
+25
+00:01:13,020 --> 00:01:15,770
+specifications. And test case specifications are
+
+26
+00:01:15,770 --> 00:01:19,490
+description of the test cases that we can then use
+
+27
+00:01:19,490 --> 00:01:23,270
+to generate actual test cases. And proceeding in this way,
+
+28
+00:01:23,270 --> 00:01:26,050
+by this steps, has many advantages. It allows for the
+
+29
+00:01:26,050 --> 00:01:29,920
+coupling different activities. It allows for dividing brain intensive steps from
+
+30
+00:01:29,920 --> 00:01:32,240
+steps that can be automated, which is a great advantage.
+
+31
+00:01:32,240 --> 00:01:34,980
+And also we will see, it allows you for monitoring
+
+32
+00:01:34,980 --> 00:01:38,040
+the testing process. So to figure out whether your testing
+
+33
+00:01:38,040 --> 00:01:41,000
+process is going as expected, for example, if you're generating too
+
+34
+00:01:41,000 --> 00:01:44,160
+many test cases. Or you're generating the number of test cases that your
+
+35
+00:01:44,160 --> 00:01:47,880
+amount of resources available allows you to run. So let's start by looking
+
+36
+00:01:47,880 --> 00:01:51,230
+at the first step of this process in which our goal is to
+
+37
+00:01:51,230 --> 00:01:54,820
+go from a Functional Specification to a set of features that we can
+
+38
+00:01:54,820 --> 00:01:57,700
+test in the software. So what we want to do is to identify all
+
+39
+00:01:57,700 --> 00:02:00,290
+of the feature of the software. And why do we want to do this?
+
+40
+00:02:00,290 --> 00:02:02,650
+Well you know, in the spirit of breaking down the complexity of the
+
+41
+00:02:02,650 --> 00:02:06,170
+problem, it does not make sense to just try to devise test cases for
+
+42
+00:02:06,170 --> 00:02:08,750
+all the features of the software at once. For any non-trivial
+
+43
+00:02:08,750 --> 00:02:11,980
+software, that's a humongous problem, and something that we cannot really
+
+44
+00:02:11,980 --> 00:02:16,300
+handle effectively. A much better way is to identify independently testable
+
+45
+00:02:16,300 --> 00:02:19,100
+features and consider one of them at a time when generating tests.
diff --git a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/4 - Overview Quiz - lang_en_vs4.srt b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/4 - Overview Quiz - lang_en_vs4.srt
new file mode 100644
index 0000000..dda3144
--- /dev/null
+++ b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/4 - Overview Quiz - lang_en_vs4.srt	
@@ -0,0 +1,35 @@
+1
+00:00:00,740 --> 00:00:02,780
+So, now I want to do a little quiz about
+
+2
+00:00:02,780 --> 00:00:05,530
+identifying testable features. Let's consider
+
+3
+00:00:05,530 --> 00:00:07,700
+this simple problem called printSum.
+
+4
+00:00:07,700 --> 00:00:09,680
+We won't see the implementation because we are doing black-box
+
+5
+00:00:09,680 --> 00:00:12,780
+testing. And all we need to know is that printSum takes
+
+6
+00:00:12,780 --> 00:00:15,550
+two integers, a and b, and prints the sum of
+
+7
+00:00:15,550 --> 00:00:17,540
+these two numbers. So what I want to ask, is
+
+8
+00:00:17,540 --> 00:00:20,700
+how many independently testable features do we have here? Do
+
+9
+00:00:20,700 --> 00:00:24,860
+we have one, two, three features? Or more than three features?
diff --git a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/5 - Overview Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/5 - Overview Quiz Solution - lang_en_vs4.srt
new file mode 100644
index 0000000..5503f98
--- /dev/null
+++ b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/5 - Overview Quiz Solution - lang_en_vs4.srt	
@@ -0,0 +1,15 @@
+1
+00:00:00,360 --> 00:00:03,760
+Sum is a very simple program, that only does one thing,
+
+2
+00:00:03,760 --> 00:00:07,540
+summing two number, adding two numbers. So the answer in this
+
+3
+00:00:07,540 --> 00:00:10,640
+case, it's one. There's only one feature that we can test
+
+4
+00:00:10,640 --> 00:00:14,060
+in PrintSum. So let's look at the slightly more interesting example.
diff --git a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/6 - Overview Quiz - lang_en_vs4.srt b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/6 - Overview Quiz - lang_en_vs4.srt
new file mode 100644
index 0000000..96c643e
--- /dev/null
+++ b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/6 - Overview Quiz - lang_en_vs4.srt	
@@ -0,0 +1,19 @@
+1
+00:00:00,150 --> 00:00:02,469
+Let's look at this spreadsheet. I'm pretty sure most of you
+
+2
+00:00:02,469 --> 00:00:05,990
+are familiar with what a spreadsheet is and have used them before.
+
+3
+00:00:05,990 --> 00:00:08,119
+So now I'm going to ask the same question, which is I'd
+
+4
+00:00:08,119 --> 00:00:10,480
+like you to identify three possible
+
+5
+00:00:10,480 --> 00:00:13,190
+independently testable features for a spreadsheet.
diff --git a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/7 - Overview Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/7 - Overview Quiz Solution - lang_en_vs4.srt
new file mode 100644
index 0000000..88e7cd5
--- /dev/null
+++ b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/7 - Overview Quiz Solution - lang_en_vs4.srt	
@@ -0,0 +1,71 @@
+1
+00:00:00,190 --> 00:00:03,030
+In this case there's not really a right answer because there's
+
+2
+00:00:03,030 --> 00:00:05,750
+many, many features that you could identify in a piece of
+
+3
+00:00:05,750 --> 00:00:08,655
+software as complex as a, a spreadsheet. So I'm just going
+
+4
+00:00:08,655 --> 00:00:11,900
+to give you three examples. So one could be the cell merging
+
+5
+00:00:11,900 --> 00:00:14,950
+operation. So the operation in which we merge two cells in
+
+6
+00:00:14,950 --> 00:00:18,550
+the spreadsheet. Another example could be chart creation, so I might want
+
+7
+00:00:18,550 --> 00:00:21,370
+to test the feature that allows you to create charts in
+
+8
+00:00:21,370 --> 00:00:23,310
+your spreadsheets. Yet another example could
+
+9
+00:00:23,310 --> 00:00:25,540
+be the test of statistical functions,
+
+10
+00:00:25,540 --> 00:00:29,350
+so the function that allows you to do various statistical calculations on
+
+11
+00:00:29,350 --> 00:00:32,650
+the numbers in your cells. And as I said there's many, many
+
+12
+00:00:32,650 --> 00:00:35,900
+more example that we could use. But the key thing I want
+
+13
+00:00:35,900 --> 00:00:38,770
+to convey here is the fact that there is no way you
+
+14
+00:00:38,770 --> 00:00:42,020
+can look at a spreadsheet with all the functionality that it provides
+
+15
+00:00:42,020 --> 00:00:44,160
+and just go and test it. The first step, what you need
+
+16
+00:00:44,160 --> 00:00:47,430
+to do first, is to identify which ones are the pieces of
+
+17
+00:00:47,430 --> 00:00:50,620
+functionality that I can test individually. So that's why this is the
+
+18
+00:00:50,620 --> 00:00:52,310
+first step in black-box testing.
diff --git a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/8 - Test Data Selection - lang_en_vs4.srt b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/8 - Test Data Selection - lang_en_vs4.srt
new file mode 100644
index 0000000..51aaffe
--- /dev/null
+++ b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/8 - Test Data Selection - lang_en_vs4.srt	
@@ -0,0 +1,103 @@
+1
+00:00:00,230 --> 00:00:03,550
+Once we have identified Independently Testable Features, the next step is to
+
+2
+00:00:03,550 --> 00:00:07,720
+identify the Relevant Inputs for each one of these features. And there are
+
+3
+00:00:07,720 --> 00:00:10,420
+many ways to do that. So, what we're going to do, instead of
+
+4
+00:00:10,420 --> 00:00:13,770
+looking at them all, is that we're just going to focus on two different
+
+5
+00:00:13,770 --> 00:00:16,239
+ways of doing it. And they are fairly general ways. So, they
+
+6
+00:00:16,239 --> 00:00:19,910
+are applicable to a number of situations. And in addition, what I will
+
+7
+00:00:19,910 --> 00:00:22,190
+do, I will point you to other sources in which you can
+
+8
+00:00:22,190 --> 00:00:25,530
+look at different ways of doing this in the class notes. The problem
+
+9
+00:00:25,530 --> 00:00:28,390
+of identifying relevant inputs for some Software or some feature
+
+10
+00:00:28,390 --> 00:00:31,930
+of it is called Test Data Selection and can be expressed
+
+11
+00:00:31,930 --> 00:00:35,040
+as followed. Let's consider our software as usual we have
+
+12
+00:00:35,040 --> 00:00:38,190
+our Input Domain, which is the set of inputs for all
+
+13
+00:00:38,190 --> 00:00:40,980
+the software. And again as usual, we have our Output
+
+14
+00:00:40,980 --> 00:00:44,050
+Domain, which is the set of corresponding outlets for these inputs.
+
+15
+00:00:44,050 --> 00:00:47,450
+So the question here is, how can we select a meaningful
+
+16
+00:00:47,450 --> 00:00:50,920
+set of inputs in my domain? And of course corresponding outputs
+
+17
+00:00:50,920 --> 00:00:53,240
+because we know that test cases are an input, plus an
+
+18
+00:00:53,240 --> 00:00:56,900
+expected output. So how can we select interesting inputs for our
+
+19
+00:00:56,900 --> 00:01:00,040
+software? So a set of inputs that, after we run them
+
+20
+00:01:00,040 --> 00:01:02,950
+on the software, if the software behaves correctly, we'll have enough
+
+21
+00:01:02,950 --> 00:01:07,060
+confidence that the software is correctly implemented. So one possible idea
+
+22
+00:01:07,060 --> 00:01:09,830
+is, hey, why don't we just test them all? We just
+
+23
+00:01:09,830 --> 00:01:12,800
+do exhaustive testing. We do all the inputs, nowadays we have
+
+24
+00:01:12,800 --> 00:01:16,290
+powerful machines, we have a lot of computational power in the cloud.
+
+25
+00:01:16,290 --> 00:01:17,890
+Why not just doing it? So to answer that
+
+26
+00:01:17,890 --> 00:01:20,480
+question, what I'm going to do? I'm going to use another quiz.
diff --git a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/9 - Test Data Selection Quiz - lang_en_vs4.srt b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/9 - Test Data Selection Quiz - lang_en_vs4.srt
new file mode 100644
index 0000000..9ffead6
--- /dev/null
+++ b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/9 - Test Data Selection Quiz - lang_en_vs4.srt	
@@ -0,0 +1,31 @@
+1
+00:00:00,200 --> 00:00:02,180
+So I'm going to ask you something. Which is if
+
+2
+00:00:02,180 --> 00:00:04,750
+we consider again our function print sum, the one
+
+3
+00:00:04,750 --> 00:00:06,760
+that takes two integers and prints the sum. How
+
+4
+00:00:06,760 --> 00:00:09,300
+long would it take to exhaustively test this function? And
+
+5
+00:00:09,300 --> 00:00:10,950
+this is a very simple one. There's just two
+
+6
+00:00:10,950 --> 00:00:13,240
+inputs, right? So we can just enumerate them all.
+
+7
+00:00:13,240 --> 00:00:15,950
+And put them throw them at the computer form,
+
+8
+00:00:15,950 --> 00:00:18,440
+and wait for the results. How long would that take?
diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/1 - Lesson Overview - lang_en_vs4.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/1 - Lesson Overview - lang_en_vs4.srt
new file mode 100644
index 0000000..64f1576
--- /dev/null
+++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/1 - Lesson Overview - lang_en_vs4.srt	
@@ -0,0 +1,47 @@
+1
+00:00:00,110 --> 00:00:02,570
+In the previous lesson we discussed black box
+
+2
+00:00:02,570 --> 00:00:05,120
+testing, which is the testing performed based on a
+
+3
+00:00:05,120 --> 00:00:08,760
+description of the software, but without considering any of
+
+4
+00:00:08,760 --> 00:00:12,440
+software's internal details. In this lesson, we will discuss
+
+5
+00:00:12,440 --> 00:00:15,490
+the counterpart of black box testing, which is called
+
+6
+00:00:15,490 --> 00:00:20,590
+unsurprisingly white box testing or structural testing. And just
+
+7
+00:00:20,590 --> 00:00:22,780
+like we did for black box testing, we will
+
+8
+00:00:22,780 --> 00:00:25,740
+cover the main characteristics of white box testing and
+
+9
+00:00:25,740 --> 00:00:30,620
+this casts the most commonly used white box testing techniques. We
+
+10
+00:00:30,620 --> 00:00:33,650
+will conclude the lesson with the discussion of the main strengths and
+
+11
+00:00:33,650 --> 00:00:37,540
+limitations of white box testing. So that you will know, when to
+
+12
+00:00:37,540 --> 00:00:40,950
+use it? How to use it? And what to expect from it?
diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/10 - Statement Coverage Quiz Solution - lang_en_vs7.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/10 - Statement Coverage Quiz Solution - lang_en_vs7.srt
new file mode 100644
index 0000000..c18d579
--- /dev/null
+++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/10 - Statement Coverage Quiz Solution - lang_en_vs7.srt	
@@ -0,0 +1,31 @@
+1
+00:00:00,210 --> 00:00:01,900
+To get the answer to this question, I'm
+
+2
+00:00:01,900 --> 00:00:03,540
+going to ask you to be a little patient, and
+
+3
+00:00:03,540 --> 00:00:05,120
+to wait until the end of the lesson.
+
+4
+00:00:05,120 --> 00:00:06,792
+Because there are a couple of more topics that
+
+5
+00:00:06,792 --> 00:00:08,244
+I want to cover, before I actually get in
+
+6
+00:00:08,244 --> 00:00:10,210
+to this. Nevertheless, I wanted to ask you right
+
+7
+00:00:10,210 --> 00:00:11,880
+away, because I wanted you to think about
+
+8
+00:00:11,880 --> 00:00:13,560
+this, before you see the rest of the lesson.
diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/11 - Control Flow Graphs - lang_en_vs5.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/11 - Control Flow Graphs - lang_en_vs5.srt
new file mode 100644
index 0000000..83d5860
--- /dev/null
+++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/11 - Control Flow Graphs - lang_en_vs5.srt	
@@ -0,0 +1,167 @@
+1
+00:00:00,320 --> 00:00:03,450
+Let's look at the code for PrintSum in a slightly different way
+
+2
+00:00:03,450 --> 00:00:06,140
+by making something explicit. If we go through the code, we can
+
+3
+00:00:06,140 --> 00:00:08,578
+see that the, the code does something in that case, if the
+
+4
+00:00:08,578 --> 00:00:11,720
+result greater then zero, does something else if the result is not
+
+5
+00:00:11,720 --> 00:00:14,890
+greater than zero but is less than zero, and otherwise in the
+
+6
+00:00:14,890 --> 00:00:17,800
+case in which neither of these two conditions is true. Nothing really
+
+7
+00:00:17,800 --> 00:00:19,090
+happens. So we're going to make that
+
+8
+00:00:19,090 --> 00:00:21,290
+explicit, we're going to say here, otherwise
+
+9
+00:00:21,290 --> 00:00:25,430
+do nothing, which is exactly our problem, the code does nothing, in this
+
+10
+00:00:25,430 --> 00:00:28,380
+case where it should do something. So now, let's look again in
+
+11
+00:00:28,380 --> 00:00:31,470
+our test cases, let's consider the first one, and I'm going to go a
+
+12
+00:00:31,470 --> 00:00:34,410
+little faster in this case, because we already saw what happens If
+
+13
+00:00:34,410 --> 00:00:37,890
+we execute the first test case, we get to this point, we execute
+
+14
+00:00:37,890 --> 00:00:40,710
+this statement, and then we just jump to the end, as we
+
+15
+00:00:40,710 --> 00:00:44,020
+saw. Now we, if we execute the second test case, we do the
+
+16
+00:00:44,020 --> 00:00:46,740
+same, we get to the else statement, the condition for the if is
+
+17
+00:00:46,740 --> 00:00:50,770
+true, and therefore we execute this statement. And we never reached this point
+
+18
+00:00:50,770 --> 00:00:53,320
+for either of the test cases. So how can we express
+
+19
+00:00:53,320 --> 00:00:56,470
+this? In order to do that, I'm going to introduce a very useful
+
+20
+00:00:56,470 --> 00:01:00,450
+concept. The concept of control flow graphs. The control flow graphs
+
+21
+00:01:00,450 --> 00:01:03,310
+is just a representation for the code that is very convenient when
+
+22
+00:01:03,310 --> 00:01:06,030
+we run our reason about the code and its structure. And
+
+23
+00:01:06,030 --> 00:01:09,910
+it's a fairly simple one that represents statement with notes and the
+
+24
+00:01:09,910 --> 00:01:12,900
+flow of control within the code with edges. So here's an
+
+25
+00:01:12,900 --> 00:01:16,180
+example of control flow graph for this code. There is the entry
+
+26
+00:01:16,180 --> 00:01:19,790
+point of the code right here, then our statement in which we
+
+27
+00:01:19,790 --> 00:01:23,320
+assign the result of A plus B to variable result. Our if
+
+28
+00:01:23,320 --> 00:01:25,720
+statement and as you can see the if statement it's got two
+
+29
+00:01:25,720 --> 00:01:28,930
+branches coming out of it, because based on the outcome of this
+
+30
+00:01:28,930 --> 00:01:32,376
+predicate we will go one way or the other. In fact normally
+
+31
+00:01:32,376 --> 00:01:36,000
+what we do, we will label this edges accordingly. So for example,
+
+32
+00:01:36,000 --> 00:01:38,580
+here we will say that this is the label to be executed
+
+33
+00:01:38,580 --> 00:01:41,470
+when the predicate is true. And this is the label that is executed
+
+34
+00:01:41,470 --> 00:01:44,120
+when the predicate is false. Now, at this point, similar
+
+35
+00:01:44,120 --> 00:01:47,080
+thing, statement five which corresponds with this one, we have another
+
+36
+00:01:47,080 --> 00:01:49,650
+if statement and if that statement is true, then we get
+
+37
+00:01:49,650 --> 00:01:51,830
+to this point and if it's false, we get to this
+
+38
+00:01:51,830 --> 00:01:54,370
+point. So as you can see, this graph represents my
+
+39
+00:01:54,370 --> 00:01:57,040
+code, in a much more intuitive way, because I can see
+
+40
+00:01:57,040 --> 00:02:00,650
+right away where the control flows, while I execute the code.
+
+41
+00:02:00,650 --> 00:02:01,730
+So we're going to use this
+
+42
+00:02:01,730 --> 00:02:04,430
+representation to introduce further coverage criteria.
diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/12 - Branch Coverage - lang_en_vs3.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/12 - Branch Coverage - lang_en_vs3.srt
new file mode 100644
index 0000000..a1dedad
--- /dev/null
+++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/12 - Branch Coverage - lang_en_vs3.srt	
@@ -0,0 +1,267 @@
+1
+00:00:00,400 --> 00:00:03,780
+So now that we know what the CFG is, let's see how we can get into a count,
+
+2
+00:00:03,780 --> 00:00:07,860
+that else part, that is missing in our example code by introducing a new
+
+3
+00:00:07,860 --> 00:00:10,480
+kind of coverage. Branch coverage. As usual,
+
+4
+00:00:10,480 --> 00:00:13,550
+I'm going to describe branch coverage in terms of test requirements and
+
+5
+00:00:13,550 --> 00:00:17,100
+coverage measure. So starting from test requirements. The test requirement for
+
+6
+00:00:17,100 --> 00:00:21,080
+branch coverage are the branches in the program. In other words,
+
+7
+00:00:21,080 --> 00:00:25,240
+the goal of branch coverage is to execute all of the branches in the program.
+
+8
+00:00:25,240 --> 00:00:28,370
+The coverage measure is defined accordingly as the number of branches
+
+9
+00:00:28,370 --> 00:00:33,150
+executed by my test cases over the total number of branches in the program. And
+
+10
+00:00:33,150 --> 00:00:37,020
+let me remind you that branches are the outgoing edges from a decision point.
+
+11
+00:00:37,020 --> 00:00:40,410
+Therefore, an if statement, a switch statement, a while statement.
+
+12
+00:00:40,410 --> 00:00:44,400
+Any note in the c of g that has got more than one outgoing edge.
+
+13
+00:00:44,400 --> 00:00:48,170
+Those edges are called branches. So let's look at that using our example. So
+
+14
+00:00:48,170 --> 00:00:51,690
+now we're looking back at our printSum example. And in addition to the code,
+
+15
+00:00:51,690 --> 00:00:54,440
+I also want to represent the CFG for the program. So
+
+16
+00:00:54,440 --> 00:00:58,590
+let's start by looking at how many branches we have in our code. Which means how
+
+17
+00:00:58,590 --> 00:01:02,070
+many test requirements we have. And in this case there are two decision points.
+
+18
+00:01:02,070 --> 00:01:04,940
+The first one that corresponds to the first if, and the second one that
+
+19
+00:01:04,940 --> 00:01:10,100
+corresponds to the second if. So we have one, two, three, and four branches. So
+
+20
+00:01:10,100 --> 00:01:13,880
+now, let's bring back our current set of test cases. We had two test cases.
+
+21
+00:01:13,880 --> 00:01:17,440
+The one's that, with which we achieved a 100% statement coverage. And
+
+22
+00:01:17,440 --> 00:01:21,140
+let's see what happens in terms of branch coverage when we run these test cases.
+
+23
+00:01:21,140 --> 00:01:24,110
+I start from the first one, when we execute it, we follow the code,
+
+24
+00:01:24,110 --> 00:01:27,890
+we get to this decision point because the predicate in the if statement is true.
+
+25
+00:01:27,890 --> 00:01:30,770
+We follow the true branch, therefore we get here and then,
+
+26
+00:01:30,770 --> 00:01:34,970
+we exit from the program. So, in this case, we covered one of the branches,
+
+27
+00:01:34,970 --> 00:01:40,710
+which means that we got to 25% coverage. Now when we run the second test case,
+
+28
+00:01:40,710 --> 00:01:44,160
+again we follow this path. We get to this, the first if and
+
+29
+00:01:44,160 --> 00:01:47,730
+in this case the predicate of the if is false. Therefore, we go this way.
+
+30
+00:01:47,730 --> 00:01:51,160
+We reach the second predicate, the second if. The result is true, so
+
+31
+00:01:51,160 --> 00:01:55,490
+we follow the true branch and therefore, we cover these additional two branches.
+
+32
+00:01:55,490 --> 00:01:59,900
+So at this point, we are at 75% branch coverage. So what
+
+33
+00:01:59,900 --> 00:02:04,070
+happens is that we're missing this branch. For now, the inputs that we consider,
+
+34
+00:02:04,070 --> 00:02:07,740
+this branch is executed. Therefore, we need to add an additional test case. And
+
+35
+00:02:07,740 --> 00:02:11,600
+that this case that we need, is one for which this predicate is false and this
+
+36
+00:02:11,600 --> 00:02:15,680
+predicate is false. The simplest possibility in this case is the test case for
+
+37
+00:02:15,680 --> 00:02:20,170
+which A is equal to 0 and B is equal to 0. If we execute this test case,
+
+38
+00:02:20,170 --> 00:02:24,250
+our execution again followed this path, follows the fourth branch here.
+
+39
+00:02:24,250 --> 00:02:28,090
+And in this case, because result is not less than zero either, will follow
+
+40
+00:02:28,090 --> 00:02:33,090
+this branch as well. And therefore, we will reach our 100% branch coverage. And
+
+41
+00:02:33,090 --> 00:02:35,820
+this covered the problem. Something that I would like to clarify before we
+
+42
+00:02:35,820 --> 00:02:40,920
+move to the next topic, is that 100% coverage does not provide any guarantee of
+
+43
+00:02:40,920 --> 00:02:44,530
+finding the problems in the code. All we saw so far is the fact that by
+
+44
+00:02:44,530 --> 00:02:48,580
+testing more thoroughly we have more chances of finding a problem in the code.
+
+45
+00:02:48,580 --> 00:02:51,680
+But it doesn't matter which kind of coverage we utilize, and how much
+
+46
+00:02:51,680 --> 00:02:55,440
+coverage we achieve. There's always a chance that we might miss something. And
+
+47
+00:02:55,440 --> 00:02:59,760
+I will get back to this later on in the lesson. I just mentioned the fact that
+
+48
+00:02:59,760 --> 00:03:03,910
+we tested more fully when we went from statement coverage to branch coverage.
+
+49
+00:03:03,910 --> 00:03:06,900
+What does that mean exactly? To explain that, I'm going to introduce the concept
+
+50
+00:03:06,900 --> 00:03:11,420
+of test criteria subsumption. One test criteria subsumes another criteria when
+
+51
+00:03:11,420 --> 00:03:16,760
+all the tests widths that satisfy that criteria will also satisfy the other one.
+
+52
+00:03:16,760 --> 00:03:18,740
+So let me show you that with statement and
+
+53
+00:03:18,740 --> 00:03:23,220
+branch coverage. If we identify a test width that achieves 100% branch coverage,
+
+54
+00:03:23,220 --> 00:03:27,780
+the same test width will also achieve, necessarily, 100% statement coverage.
+
+55
+00:03:27,780 --> 00:03:31,290
+That's what happened for our example, and also what happens in general,
+
+56
+00:03:31,290 --> 00:03:35,660
+because branch coverage is a stronger criteria than statement coverage.
+
+57
+00:03:35,660 --> 00:03:39,670
+There is no way to cover all the branches without covering all the statements.
+
+58
+00:03:39,670 --> 00:03:43,480
+It is not true that any test results satisfies statement coverage will also
+
+59
+00:03:43,480 --> 00:03:47,040
+satisfy branch coverage. And, in fact, we just saw a counter example.
+
+60
+00:03:47,040 --> 00:03:50,569
+When we look at the printSum code. We had a test where there was achieving 100%
+
+61
+00:03:50,569 --> 00:03:53,910
+statement coverage and was not achieving 100% branch coverage. Therefore,
+
+62
+00:03:53,910 --> 00:03:58,301
+in this case we have a substantial relation in this direction. Branch coverage,
+
+63
+00:03:58,301 --> 00:04:02,860
+subsumes statement coverage. What it also means is that normally, or in general,
+
+64
+00:04:02,860 --> 00:04:06,910
+it is more expensive to achieve branch coverage than achieve statement coverage,
+
+65
+00:04:06,910 --> 00:04:09,490
+because achieving branch coverage requires the generation of
+
+66
+00:04:09,490 --> 00:04:13,770
+a larger number of test cases. So what this relation means is that
+
+67
+00:04:13,770 --> 00:04:17,779
+branch coverage is stronger than statement coverage but also more expensive.
diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/13 - Condition Coverage - lang_en_vs4.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/13 - Condition Coverage - lang_en_vs4.srt
new file mode 100644
index 0000000..bba72fc
--- /dev/null
+++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/13 - Condition Coverage - lang_en_vs4.srt	
@@ -0,0 +1,191 @@
+1
+00:00:00,470 --> 00:00:03,046
+What I'm going to do next is to introduce a few additional
+
+2
+00:00:03,046 --> 00:00:06,350
+coverage criteria using a slightly more complex example, but still a
+
+3
+00:00:06,350 --> 00:00:09,370
+pretty simple one. What I'm showing here is a program that
+
+4
+00:00:09,370 --> 00:00:12,145
+reads two real numbers, x and y. And then, if x
+
+5
+00:00:12,145 --> 00:00:15,148
+is equal to 0 or y is greater than 0, it
+
+6
+00:00:15,148 --> 00:00:19,360
+computes y as y divided by x. Otherwise, it computes x
+
+7
+00:00:19,360 --> 00:00:22,110
+as y plus 2, then it writes the value of x,
+
+8
+00:00:22,110 --> 00:00:25,730
+the value of y, and it terminates. Let's also introduce a CFG
+
+9
+00:00:25,730 --> 00:00:29,160
+for the program. As you can see, the CFG represents the statements
+
+10
+00:00:29,160 --> 00:00:31,900
+in the code and their control flow. And in this case, I made
+
+11
+00:00:31,900 --> 00:00:35,800
+explicit over the branches what are the conditions under which those branches
+
+12
+00:00:35,800 --> 00:00:38,530
+are taken to make it simpler to look at the example. Let's assume
+
+13
+00:00:38,530 --> 00:00:41,280
+that we have two tests for this code that are shown here.
+
+14
+00:00:41,280 --> 00:00:44,286
+For the first one, the inputs are 5 and 5. For the second
+
+15
+00:00:44,286 --> 00:00:47,610
+one, 5 and minus 5. If we consider branch coverage for this code
+
+16
+00:00:47,610 --> 00:00:50,990
+and we consider the two test cases, for the first one this condition
+
+17
+00:00:50,990 --> 00:00:53,440
+is true. Because x is not equal to 0 but y
+
+18
+00:00:53,440 --> 00:00:56,660
+is greater than 0. And therefore, we will follow this tree branch.
+
+19
+00:00:56,660 --> 00:00:59,640
+For the second one, the condition is false. Because x is not
+
+20
+00:00:59,640 --> 00:01:03,200
+equal to 0 and y is not greater than 0. Therefore, the
+
+21
+00:01:03,200 --> 00:01:05,990
+negation of it is true and we will follow this branch. In
+
+22
+00:01:05,990 --> 00:01:09,530
+other words, these two test cases achieve 100% branch coverage on this
+
+23
+00:01:09,530 --> 00:01:12,120
+code. If we look at the code though, we can see that
+
+24
+00:01:12,120 --> 00:01:15,879
+there is the possibility of making this code fail. Consider this statement,
+
+25
+00:01:15,879 --> 00:01:18,147
+if x is equal to 0, we could have a division
+
+26
+00:01:18,147 --> 00:01:21,710
+by 0. However, these two test cases, despite the fact that
+
+27
+00:01:21,710 --> 00:01:25,008
+they achieved 100% branch coverage, will not rebuild this problem. So
+
+28
+00:01:25,008 --> 00:01:27,564
+how can we be more thorough? I'll let you think about it
+
+29
+00:01:27,564 --> 00:01:29,964
+for a second, so think about how can we test more
+
+30
+00:01:29,964 --> 00:01:33,260
+thoroughly, in a more complete way, this code. So, in a way
+
+31
+00:01:33,260 --> 00:01:37,220
+that goes beyond branch coverage. And the answer is that we
+
+32
+00:01:37,220 --> 00:01:41,250
+can make each condition true and false. Instead of just considering the
+
+33
+00:01:41,250 --> 00:01:44,570
+whole predicate here. And that's exactly what is required by
+
+34
+00:01:44,570 --> 00:01:47,480
+the next criteria that we're going to consider which is condition
+
+35
+00:01:47,480 --> 00:01:49,880
+coverage. We're going to define it as usual in terms of
+
+36
+00:01:49,880 --> 00:01:53,070
+test requirements and coverage measure. In this case, the test
+
+37
+00:01:53,070 --> 00:01:57,540
+requirements for condition coverage are the individual conditions in the
+
+38
+00:01:57,540 --> 00:02:00,510
+program. So we want each condition in the program to
+
+39
+00:02:00,510 --> 00:02:03,900
+be both true and false first time execution. So the
+
+40
+00:02:03,900 --> 00:02:06,420
+way in which we can measure that is by measuring the
+
+41
+00:02:06,420 --> 00:02:09,150
+number of conditions that were both true and false
+
+42
+00:02:09,150 --> 00:02:11,580
+when we executed our tests over the total number
+
+43
+00:02:11,580 --> 00:02:14,180
+of conditions. And that gives us the percentage of
+
+44
+00:02:14,180 --> 00:02:17,270
+coverage that we achieved for condition coverage. Again, if you
+
+45
+00:02:17,270 --> 00:02:18,638
+want to look at this criteria in the form
+
+46
+00:02:18,638 --> 00:02:21,245
+of a question. The question would be, has each boolean
+
+47
+00:02:21,245 --> 00:02:25,480
+sub-expression, which means every condition in every predicate, evaluated
+
+48
+00:02:25,480 --> 00:02:28,010
+both to true and false when we run our tests.
diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/14 - Subsumption Quiz - lang_en_vs4.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/14 - Subsumption Quiz - lang_en_vs4.srt
new file mode 100644
index 0000000..de78093
--- /dev/null
+++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/14 - Subsumption Quiz - lang_en_vs4.srt	
@@ -0,0 +1,31 @@
+1
+00:00:00,080 --> 00:00:02,220
+So now that we introduced an additional criterion,
+
+2
+00:00:02,220 --> 00:00:04,290
+let's have a quiz to see whether everybody
+
+3
+00:00:04,290 --> 00:00:06,410
+understood the concept of subsumption. We know that
+
+4
+00:00:06,410 --> 00:00:09,490
+branch coverage subsumes statement coverage, but what about condition
+
+5
+00:00:09,490 --> 00:00:12,230
+coverage? Does it subsume branch coverage? Is it
+
+6
+00:00:12,230 --> 00:00:13,720
+the case that all of the test which
+
+7
+00:00:13,720 --> 00:00:16,980
+satisfy condition coverage will also satisfy branch coverage?
+
+8
+00:00:16,980 --> 00:00:19,160
+Think about it, and answer either yes or no.
diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/15 - Subsumption Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/15 - Subsumption Quiz Solution - lang_en_vs4.srt
new file mode 100644
index 0000000..87140c9
--- /dev/null
+++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/15 - Subsumption Quiz Solution - lang_en_vs4.srt	
@@ -0,0 +1,7 @@
+1
+00:00:00,170 --> 00:00:02,475
+In this case, the answer is no, and I'm
+
+2
+00:00:02,475 --> 00:00:04,650
+going to show you an example of this in a minute.
diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/16 - Branch and Condition Coverage - lang_en_vs4.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/16 - Branch and Condition Coverage - lang_en_vs4.srt
new file mode 100644
index 0000000..143a534
--- /dev/null
+++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/16 - Branch and Condition Coverage - lang_en_vs4.srt	
@@ -0,0 +1,143 @@
+1
+00:00:00,052 --> 00:00:03,407
+Let's go back to our test criteria subsumption representation, where
+
+2
+00:00:03,407 --> 00:00:06,770
+we already had branch coverage and statement coverage. In this case,
+
+3
+00:00:06,770 --> 00:00:09,350
+if we want to add condition coverage to this page, we
+
+4
+00:00:09,350 --> 00:00:12,050
+have to put it here on this side, with no relationship
+
+5
+00:00:12,050 --> 00:00:15,830
+of subsumption with either branch coverage or statement coverage, which
+
+6
+00:00:15,830 --> 00:00:19,270
+means that the criteria are not comparable. So now let's consider
+
+7
+00:00:19,270 --> 00:00:22,108
+again our last example, and let's use a different test
+
+8
+00:00:22,108 --> 00:00:25,060
+with this time. We still have two tests, but the first
+
+9
+00:00:25,060 --> 00:00:27,575
+one has x is equal to 0 and y is equal to minus
+
+10
+00:00:27,575 --> 00:00:30,370
+5. And the second one, x is equal to 5 and y is
+
+11
+00:00:30,370 --> 00:00:33,350
+equal to 5 as well. Let's see what happens in terms of condition
+
+12
+00:00:33,350 --> 00:00:36,740
+coverage, when we run these tests. If we look at the first condition, x
+
+13
+00:00:36,740 --> 00:00:39,820
+is equal to 0. It is both true, for the first test case,
+
+14
+00:00:39,820 --> 00:00:43,240
+and false for the second one. As for the second condition, y greater
+
+15
+00:00:43,240 --> 00:00:45,800
+than 0, it is false for the first test case and true for
+
+16
+00:00:45,800 --> 00:00:47,770
+the second one. Therefore we've achieved a
+
+17
+00:00:47,770 --> 00:00:50,400
+100% condition coverage with these two tests.
+
+18
+00:00:50,400 --> 00:00:54,020
+But what about branch coverage? If we consider the whole predicate,
+
+19
+00:00:54,020 --> 00:00:56,620
+instead of just the individual conditions, let's see what happens for the
+
+20
+00:00:56,620 --> 00:00:59,090
+two test cases. If we look at the first one, because
+
+21
+00:00:59,090 --> 00:01:02,200
+x is equal to 0, the overall predicate is true. As for
+
+22
+00:01:02,200 --> 00:01:05,750
+the second one, because the second condition is true, the overall
+
+23
+00:01:05,750 --> 00:01:09,110
+predicate is true. In other words, despite the fact that we're exercising
+
+24
+00:01:09,110 --> 00:01:12,520
+all the possible values for the two conditions, the overall predicate is
+
+25
+00:01:12,520 --> 00:01:16,540
+always true. And therefore, we're covering only one of the two branches.
+
+26
+00:01:16,540 --> 00:01:19,591
+So our coverage will be 50%. This is the reason
+
+27
+00:01:19,591 --> 00:01:22,231
+why normally the two criteria that we just saw, decision
+
+28
+00:01:22,231 --> 00:01:26,205
+coverage, and condition coverage are considered together. And the resulting
+
+29
+00:01:26,205 --> 00:01:30,320
+criterion is called branch and condition coverage, or also decision
+
+30
+00:01:30,320 --> 00:01:33,030
+and condition coverage. At this point the test requirements and
+
+31
+00:01:33,030 --> 00:01:35,590
+the coverage measure should be pretty straight forward, because they're
+
+32
+00:01:35,590 --> 00:01:38,120
+just considering the two criteria together. As far as the
+
+33
+00:01:38,120 --> 00:01:39,960
+requirements are concerned, they include
+
+34
+00:01:39,960 --> 00:01:41,880
+all the branches and individual conditions
+
+35
+00:01:41,880 --> 00:01:44,580
+in the program. Where as the coverage measure is computed
+
+36
+00:01:44,580 --> 00:01:49,180
+considering both coverage measures, both branch coverage and condition coverage.
diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/17 - Subsumption Quiz - lang_en_vs4.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/17 - Subsumption Quiz - lang_en_vs4.srt
new file mode 100644
index 0000000..9d99495
--- /dev/null
+++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/17 - Subsumption Quiz - lang_en_vs4.srt	
@@ -0,0 +1,15 @@
+1
+00:00:00,100 --> 00:00:02,810
+Let's have another quick quiz about Subsumption. If we
+
+2
+00:00:02,810 --> 00:00:06,720
+consider Branch and Condition Coverage, does it subsume Branch Coverage,
+
+3
+00:00:06,720 --> 00:00:09,512
+and therefore Statement Coverage? Or in other words, does branch
+
+4
+00:00:09,512 --> 00:00:12,750
+and condition coverage imply branch coverage? Answer yes, or no.
diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/18 - Subsumption Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/18 - Subsumption Quiz Solution - lang_en_vs4.srt
new file mode 100644
index 0000000..c836f04
--- /dev/null
+++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/18 - Subsumption Quiz Solution - lang_en_vs4.srt	
@@ -0,0 +1,19 @@
+1
+00:00:00,150 --> 00:00:01,880
+In this case it should be clear that the
+
+2
+00:00:01,880 --> 00:00:05,640
+answer is yes, because branch and condition coverage actually includes
+
+3
+00:00:05,640 --> 00:00:08,580
+branch coverage. Therefore, by definition, any test rate that
+
+4
+00:00:08,580 --> 00:00:10,505
+satisfies branch and condition coverage
+
+5
+00:00:10,505 --> 00:00:12,664
+will necessarily satisfy branch coverage.
diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/19 - Test Criteria Subsumption - lang_en_vs4.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/19 - Test Criteria Subsumption - lang_en_vs4.srt
new file mode 100644
index 0000000..f40ccdf
--- /dev/null
+++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/19 - Test Criteria Subsumption - lang_en_vs4.srt	
@@ -0,0 +1,47 @@
+1
+00:00:00,280 --> 00:00:03,400
+So we can now update our test criteria subsumption. We start
+
+2
+00:00:03,400 --> 00:00:06,700
+from this situation in which there are no relationship between condition
+
+3
+00:00:06,700 --> 00:00:09,650
+coverage, branch coverage and statement coverage. And when we add branch
+
+4
+00:00:09,650 --> 00:00:12,160
+and condition coverage, we can mark the fact that branch and
+
+5
+00:00:12,160 --> 00:00:14,470
+condition coverage subsumes branch coverage
+
+6
+00:00:14,470 --> 00:00:16,370
+and also subsumes condition coverage, for
+
+7
+00:00:16,370 --> 00:00:19,660
+the same reason. Therefore, this is a stronger criterion than both
+
+8
+00:00:19,660 --> 00:00:23,100
+branch coverage and condition coverage, and of course indirectly also soft
+
+9
+00:00:23,100 --> 00:00:25,330
+statement coverage. So once more, to make sure we are all
+
+10
+00:00:25,330 --> 00:00:29,255
+on the same page, if I develop a test rate that satisfies branch and condition
+
+11
+00:00:29,255 --> 00:00:31,380
+coverage, the same test will satisfy also
+
+12
+00:00:31,380 --> 00:00:35,210
+branch coverage, statement coverage and condition coverage, necessarily.
diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/2 - Overview - lang_en_vs4.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/2 - Overview - lang_en_vs4.srt
new file mode 100644
index 0000000..c032d40
--- /dev/null
+++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/2 - Overview - lang_en_vs4.srt	
@@ -0,0 +1,167 @@
+1
+00:00:00,420 --> 00:00:03,860
+In the last lesson, we talked about black-box testing or functional testing,
+
+2
+00:00:03,860 --> 00:00:06,110
+which is the kind of testing that you perform when you just
+
+3
+00:00:06,110 --> 00:00:09,860
+look at the description of the software. Today we're going to cover white-box
+
+4
+00:00:09,860 --> 00:00:12,490
+testing, which is the kind of testing that we perform when we
+
+5
+00:00:12,490 --> 00:00:15,800
+open up the box. We look inside the program, and we actually
+
+6
+00:00:15,800 --> 00:00:19,490
+test it based on its code. And there is one basic assumption
+
+7
+00:00:19,490 --> 00:00:22,320
+behind the idea of white-box testing, which is a very intuitive one,
+
+8
+00:00:22,320 --> 00:00:26,080
+and the assumption is that executing the faulty statement is a necessary
+
+9
+00:00:26,080 --> 00:00:29,380
+condition for revealing a fault. In other words, if there is
+
+10
+00:00:29,380 --> 00:00:31,690
+a bug in the program there is no way were going to be
+
+11
+00:00:31,690 --> 00:00:34,490
+able to find this bug or this fault, if we don't execute
+
+12
+00:00:34,490 --> 00:00:37,110
+the statement that contains it. Which makes a lot of sense. As
+
+13
+00:00:37,110 --> 00:00:40,240
+we did for black-box testing, we're going to start by summarizing what
+
+14
+00:00:40,240 --> 00:00:43,650
+are the main advantages of white-box testing. The main advantage is that
+
+15
+00:00:43,650 --> 00:00:48,050
+it's based on the code, and as such, the quality of white-box
+
+16
+00:00:48,050 --> 00:00:51,760
+testing can be measured objectively. And what I mean here by objectively
+
+17
+00:00:51,760 --> 00:00:54,390
+is that if you think about black-box testing In many
+
+18
+00:00:54,390 --> 00:00:57,630
+cases, there were subjective decisions, there were had to be made
+
+19
+00:00:57,630 --> 00:01:00,830
+in order to define tests in a black-box fashion. In the
+
+20
+00:01:00,830 --> 00:01:03,990
+case of white-box testing, because everything is based on the quota,
+
+21
+00:01:03,990 --> 00:01:07,965
+we don't have to make such subjective decisions. And similarly, because
+
+22
+00:01:07,965 --> 00:01:10,680
+white-box testing is based on the code, it can be measured
+
+23
+00:01:10,680 --> 00:01:14,250
+automatically. So we can build tools and actually there are tools,
+
+24
+00:01:14,250 --> 00:01:16,860
+and there's plenty of tools, that can be measured, the level
+
+25
+00:01:16,860 --> 00:01:19,670
+of white-box testing can be achieved in a fully automated way.
+
+26
+00:01:19,670 --> 00:01:21,620
+And we're going to see some of them in the course of the
+
+27
+00:01:21,620 --> 00:01:24,600
+class. Another advantage of white-box testing is that it can be
+
+28
+00:01:24,600 --> 00:01:27,700
+used to compare test suites. So if you have two alternative sets
+
+29
+00:01:27,700 --> 00:01:30,270
+of tests that you can use to assess the quality of
+
+30
+00:01:30,270 --> 00:01:34,360
+your software, white-box testing techniques can tell you which one of these
+
+31
+00:01:34,360 --> 00:01:37,580
+two test suites is likely to be more effective in testing
+
+32
+00:01:37,580 --> 00:01:42,350
+your code. And finally, white-box testing allows for covering the coded behavior
+
+33
+00:01:42,350 --> 00:01:44,470
+of the software. What that means is that if there is
+
+34
+00:01:44,470 --> 00:01:47,680
+some mistake in the code and is not obvious by looking at
+
+35
+00:01:47,680 --> 00:01:50,300
+the specification of the code, white box testing might be able
+
+36
+00:01:50,300 --> 00:01:53,330
+to catch it, because it tries to exercise the code. There's many
+
+37
+00:01:53,330 --> 00:01:56,430
+different kinds of white box testing, there are control flow based
+
+38
+00:01:56,430 --> 00:02:00,550
+techniques, data flow based techniques, and fault based techniques. And for each
+
+39
+00:02:00,550 --> 00:02:04,030
+one of these family of techniques there are many variations. So
+
+40
+00:02:04,030 --> 00:02:07,450
+this field is very, very broad. In this lesson we will talk
+
+41
+00:02:07,450 --> 00:02:09,110
+about white-box testing by focusing
+
+42
+00:02:09,110 --> 00:02:11,910
+mainly on control-flow based testing techniques.
diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/20 - B&C Coverage Quiz - lang_en_vs4.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/20 - B&C Coverage Quiz - lang_en_vs4.srt
new file mode 100644
index 0000000..6f5c9a1
--- /dev/null
+++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/20 - B&C Coverage Quiz - lang_en_vs4.srt	
@@ -0,0 +1,35 @@
+1
+00:00:00,130 --> 00:00:02,969
+So let's have another quiz using the example that we just
+
+2
+00:00:02,969 --> 00:00:06,660
+used. This one is about achieving 100% branch and condition coverage. So
+
+3
+00:00:06,660 --> 00:00:08,850
+let me bring back the two tests cases that we just saw,
+
+4
+00:00:08,850 --> 00:00:11,420
+and as we saw a few minutes ago, these tests cases do
+
+5
+00:00:11,420 --> 00:00:15,540
+not achieve 100% branch and condition coverage despite the fact that they
+
+6
+00:00:15,540 --> 00:00:19,430
+achieve 100% condition coverage. So both conditions are both true and false,
+
+7
+00:00:19,430 --> 00:00:21,820
+for these test cases. So what I want you to do is
+
+8
+00:00:21,820 --> 00:00:25,630
+to add a test case, to achieve 100% branch and condition coverages.
+
+9
+00:00:25,630 --> 00:00:29,740
+So specify the test case by writing here the value for x, and the value for y.
diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/21 - B&C Coverage Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/21 - B&C Coverage Quiz Solution - lang_en_vs4.srt
new file mode 100644
index 0000000..2b6fe4b
--- /dev/null
+++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/21 - B&C Coverage Quiz Solution - lang_en_vs4.srt	
@@ -0,0 +1,67 @@
+1
+00:00:00,190 --> 00:00:03,010
+Obviously there are many possible tests that we can use to
+
+2
+00:00:03,010 --> 00:00:05,910
+reach 100% branch and condition coverage. So I'm just going to show a
+
+3
+00:00:05,910 --> 00:00:08,740
+possible one, which is x equal to 3 and y is
+
+4
+00:00:08,740 --> 00:00:11,410
+equal to negative 2. If we specify this as case, you can
+
+5
+00:00:11,410 --> 00:00:14,900
+see that the overall condition is false, because neither x is
+
+6
+00:00:14,900 --> 00:00:17,990
+equal to 0 nor y is greater than 0. Therefore we will
+
+7
+00:00:17,990 --> 00:00:22,420
+follow the false, false branch, and achieve 100% branch and condition coverage
+
+8
+00:00:22,420 --> 00:00:25,400
+for this code. And we might require to be even more thorough,
+
+9
+00:00:25,400 --> 00:00:28,690
+that all the combinations of our conditions inside each
+
+10
+00:00:28,690 --> 00:00:31,790
+decision, inside each predicate, are tested. Which is what is
+
+11
+00:00:31,790 --> 00:00:36,010
+called, multiple condition coverage. But because of the way
+
+12
+00:00:36,010 --> 00:00:39,050
+this criterion is defined, it is combinatorial, becuse you have
+
+13
+00:00:39,050 --> 00:00:42,220
+to consider all the possible combinations of conditions. And
+
+14
+00:00:42,220 --> 00:00:45,210
+therefore it's extremely expensive, to the point of being impractical.
+
+15
+00:00:45,210 --> 00:00:47,610
+So instead of defining that criterion, we're going to find
+
+16
+00:00:47,610 --> 00:00:51,000
+another one which finds a good trade off between thoroughness
+
+17
+00:00:51,000 --> 00:00:52,815
+of the tests and their cost.
diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/22 - MC DC Coverage - lang_en_vs4.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/22 - MC DC Coverage - lang_en_vs4.srt
new file mode 100644
index 0000000..1a971f9
--- /dev/null
+++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/22 - MC DC Coverage - lang_en_vs4.srt	
@@ -0,0 +1,307 @@
+1
+00:00:00,120 --> 00:00:03,880
+And this criterion is called Modified Condition/Decision Coverage,
+
+2
+00:00:03,880 --> 00:00:07,750
+also called MC/DC. This criterion is very important because
+
+3
+00:00:07,750 --> 00:00:10,330
+it is often required for safety critical applications.
+
+4
+00:00:10,330 --> 00:00:13,920
+For example, the FAA, the Federal Aviation Administration, requires
+
+5
+00:00:13,920 --> 00:00:15,980
+for all the software that runs on commercial
+
+6
+00:00:15,980 --> 00:00:19,420
+airplanes to be tested according to the Modified Condition/Decision
+
+7
+00:00:19,420 --> 00:00:22,015
+Coverage. So what is the key idea behind the
+
+8
+00:00:22,015 --> 00:00:25,270
+MC/DC criterion? It is to test only the important
+
+9
+00:00:25,270 --> 00:00:28,710
+combinations of conditions instead of all of them, and limit
+
+10
+00:00:28,710 --> 00:00:32,189
+the testing cost by excluding the other combinations. And the way
+
+11
+00:00:32,189 --> 00:00:34,950
+in which it works is by extending branch and decision
+
+12
+00:00:34,950 --> 00:00:38,860
+coverage with the requirement that each condition should affect the decision
+
+13
+00:00:38,860 --> 00:00:41,940
+outcome independently. So let's see what this means with an
+
+14
+00:00:41,940 --> 00:00:45,030
+example that will also show you how you can reduce the
+
+15
+00:00:45,030 --> 00:00:46,940
+number of combinations in this way. I am going to
+
+16
+00:00:46,940 --> 00:00:50,460
+show you an example of how MC/DC works using this predicate
+
+17
+00:00:50,460 --> 00:00:53,870
+which consists of three conditions. a, b, and c, which are all
+
+18
+00:00:53,870 --> 00:00:57,070
+in and, so the overall predicate is a and b and c.
+
+19
+00:00:57,070 --> 00:00:58,980
+The first thing I'm going to do is to show you how
+
+20
+00:00:58,980 --> 00:01:03,370
+many test cases we will need to satisfy the multiple condition coverage
+
+21
+00:01:03,370 --> 00:01:06,440
+for this simple predicate. Which means, how many test cases we will
+
+22
+00:01:06,440 --> 00:01:09,780
+need to test all the possible combinations of true and false values
+
+23
+00:01:09,780 --> 00:01:12,740
+for these conditions. So I'm going to populate this table. And as you
+
+24
+00:01:12,740 --> 00:01:15,870
+can see, at the end we have eight test cases. Each test case
+
+25
+00:01:15,870 --> 00:01:18,650
+tests a different combination of values for a, b, and c.
+
+26
+00:01:18,650 --> 00:01:21,200
+I'm also showing, for each test case, the outcome of the overall
+
+27
+00:01:21,200 --> 00:01:23,930
+predicate. So, for example, if we look at the first one, the
+
+28
+00:01:23,930 --> 00:01:27,200
+first test case, will be such that a is true, b is
+
+29
+00:01:27,200 --> 00:01:30,210
+true, and c is true. And therefore, the overall outcome of
+
+30
+00:01:30,210 --> 00:01:34,360
+the predicate is true. Now lets consider the first condition, a. As
+
+31
+00:01:34,360 --> 00:01:36,300
+I said a minute ago, what we want to test are the
+
+32
+00:01:36,300 --> 00:01:39,160
+important combination. Which are the comibatinos
+
+33
+00:01:39,160 --> 00:01:41,930
+in which a single condition independently
+
+34
+00:01:41,930 --> 00:01:45,610
+effects the outcome of the overall predicate. So if we consider a
+
+35
+00:01:45,610 --> 00:01:48,490
+and we look at this possible set of this cases. Let's try to
+
+36
+00:01:48,490 --> 00:01:51,850
+find two test cases such that the only difference between the two
+
+37
+00:01:51,850 --> 00:01:54,960
+test cases is the value of a, and the overall outcome of the
+
+38
+00:01:54,960 --> 00:01:57,790
+predicate is different. If we look at the table, we can see
+
+39
+00:01:57,790 --> 00:02:00,920
+that this is true for test cases one and five. If we look
+
+40
+00:02:00,920 --> 00:02:04,030
+at these two cases, we can see that the overall of the predicate
+
+41
+00:02:04,030 --> 00:02:07,420
+in the two cases is true and false, and that the only difference
+
+42
+00:02:07,420 --> 00:02:10,720
+between the value of the conditions in the value of a. So
+
+43
+00:02:10,720 --> 00:02:13,990
+these test cases satisfy exactly what we wanted. There are two test
+
+44
+00:02:13,990 --> 00:02:18,270
+cases in which the value of a independently decides the overall value
+
+45
+00:02:18,270 --> 00:02:21,380
+of the predicate. What we do, therefore, is to add these first
+
+46
+00:02:21,380 --> 00:02:24,740
+two test cases to our set of tests down here. Now let's
+
+47
+00:02:24,740 --> 00:02:27,520
+focus on b and let's try to find two test cases such
+
+48
+00:02:27,520 --> 00:02:30,280
+that the value of b is the only value that changes between
+
+49
+00:02:30,280 --> 00:02:32,450
+the two test cases, but the overall value of the predicate is
+
+50
+00:02:32,450 --> 00:02:34,980
+different, the same thing we did for a. And in this case,
+
+51
+00:02:34,980 --> 00:02:37,610
+we can see that if we select test case number one, and test
+
+52
+00:02:37,610 --> 00:02:40,420
+case number three, we have exactly that situation. b is true in the
+
+53
+00:02:40,420 --> 00:02:44,250
+first case, false in the second one, a and c don't change, but
+
+54
+00:02:44,250 --> 00:02:46,830
+the overall value of the predicate changes. And now you can notice
+
+55
+00:02:46,830 --> 00:02:50,720
+something else. That even though we selected two test cases, tested two values,
+
+56
+00:02:50,720 --> 00:02:53,950
+one we already had. So, we only need three test cases overall to
+
+57
+00:02:53,950 --> 00:02:57,730
+test a and b according to MC/DC. Now, let's look at our last
+
+58
+00:02:57,730 --> 00:03:00,510
+condition, c. At this point, we know the game, so we
+
+59
+00:03:00,510 --> 00:03:02,780
+just have to look for two test cases that satisfy our
+
+60
+00:03:02,780 --> 00:03:06,380
+requirements. And in this case, one and two are suitable candidates.
+
+61
+00:03:06,380 --> 00:03:08,820
+And once more, because we already have one, we just have to
+
+62
+00:03:08,820 --> 00:03:11,070
+add two to our list. So as you can see from
+
+63
+00:03:11,070 --> 00:03:14,730
+this example, we went from having eight test cases needed to cover
+
+64
+00:03:14,730 --> 00:03:18,600
+all the possible combinations of conditions to only four test cases
+
+65
+00:03:18,600 --> 00:03:22,880
+to satisfy the MC/DC criteria. So let's see where MC/DC stands in
+
+66
+00:03:22,880 --> 00:03:25,510
+our substantion hierarchy. This is what we had so far
+
+67
+00:03:25,510 --> 00:03:28,430
+in the hierarchy and this is where the MC/DC criterion will
+
+68
+00:03:28,430 --> 00:03:31,930
+stand. MC/DC criterion is stronger than branch and condition coverage.
+
+69
+00:03:31,930 --> 00:03:35,210
+Why? Because it requires every single condition to be true and
+
+70
+00:03:35,210 --> 00:03:38,400
+false. And therefore, this section was a condition coverage criteria.
+
+71
+00:03:38,400 --> 00:03:41,610
+And it also requires every predicate to be true and false
+
+72
+00:03:41,610 --> 00:03:44,425
+and therefore, this section is branch coverage. And in addition,
+
+73
+00:03:44,425 --> 00:03:47,790
+it's got the additional requirements that the true and false values,
+
+74
+00:03:47,790 --> 00:03:50,330
+all the conditions have to also decide the overall
+
+75
+00:03:50,330 --> 00:03:53,190
+value of the predicate. So it's stronger. Which is more
+
+76
+00:03:53,190 --> 00:03:56,130
+thorough than branch and condition coverage and, as usual,
+
+77
+00:03:56,130 --> 00:03:59,380
+also stronger than branch coverage, statement coverage, and condition coverage.
diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/23 - Other Criteria - lang_en_vs4.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/23 - Other Criteria - lang_en_vs4.srt
new file mode 100644
index 0000000..27bf0fe
--- /dev/null
+++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/23 - Other Criteria - lang_en_vs4.srt	
@@ -0,0 +1,275 @@
+1
+00:00:00,120 --> 00:00:02,900
+As I mentioned at the beginning of the class, there are many, many,
+
+2
+00:00:02,900 --> 00:00:06,150
+many, white box criteria. And we're not going to have time to cover them
+
+3
+00:00:06,150 --> 00:00:08,000
+all. So what I like to do now is just to give you
+
+4
+00:00:08,000 --> 00:00:11,290
+the flavor, of some other criteria by just mentioning them, and saying a
+
+5
+00:00:11,290 --> 00:00:13,740
+couple of things, about the way they work. And the first one I
+
+6
+00:00:13,740 --> 00:00:15,370
+want to mention is path coverage. And
+
+7
+00:00:15,370 --> 00:00:17,800
+in path coverage, the test requirements are
+
+8
+00:00:17,800 --> 00:00:21,220
+all the paths in the program. So what that means is that to
+
+9
+00:00:21,220 --> 00:00:25,250
+satisfy this criteria, we need to generate enough test cases such that all
+
+10
+00:00:25,250 --> 00:00:27,230
+the paths in my program are covered. As you can
+
+11
+00:00:27,230 --> 00:00:31,970
+imagine this is incredibly expensive because any nontrivial program has got
+
+12
+00:00:31,970 --> 00:00:34,280
+a virtual infinite number of paths and therefore we will
+
+13
+00:00:34,280 --> 00:00:36,910
+need a virtual infinite number of test cases to satisfy the
+
+14
+00:00:36,910 --> 00:00:39,950
+path coverage criteria. Another family of criteria I want to mention
+
+15
+00:00:39,950 --> 00:00:43,970
+are data-flow coverage criteria and in data-flow coverage criteria, the focus
+
+16
+00:00:43,970 --> 00:00:47,480
+shifts from the coverage of individual elements in the code to
+
+17
+00:00:47,480 --> 00:00:50,320
+the coverage of pairs of elements. And in particular the coverage
+
+18
+00:00:50,320 --> 00:00:53,770
+of Statements, in which the content of some memory locations
+
+19
+00:00:53,770 --> 00:00:56,920
+modified, and statements in which the content of the same
+
+20
+00:00:56,920 --> 00:00:59,860
+memory location is used. So in this way, our test
+
+21
+00:00:59,860 --> 00:01:03,030
+will exercise the assignments of values to memory, and the
+
+22
+00:01:03,030 --> 00:01:06,020
+usage of those assignments,. Finally, I want to mention mutation
+
+23
+00:01:06,020 --> 00:01:09,150
+coverage. And this is a fairly different and new idea,
+
+24
+00:01:09,150 --> 00:01:11,910
+so the key concept in mutation coverage is that we
+
+25
+00:01:11,910 --> 00:01:16,156
+want to evaluate the goodness of our test by modifying the code.
+
+26
+00:01:16,156 --> 00:01:18,704
+For example here in this small I'm, I'm showing that I might
+
+27
+00:01:18,704 --> 00:01:21,820
+change it. An if statement from K greater than 9, to K
+
+28
+00:01:21,820 --> 00:01:24,310
+greater than or equal to 9. And the reason why I want to
+
+29
+00:01:24,310 --> 00:01:27,750
+do that, is that if I generate enough mutants, enough variation of
+
+30
+00:01:27,750 --> 00:01:30,340
+my program, then I can use them to assess how good are
+
+31
+00:01:30,340 --> 00:01:34,330
+my tests at distinguishing the original program and the mutants. And because
+
+32
+00:01:34,330 --> 00:01:37,430
+I'm changing the code based on the way I expect to introduce
+
+33
+00:01:37,430 --> 00:01:41,370
+errors in the code, the more my test can identify mutants, the better
+
+34
+00:01:41,370 --> 00:01:44,140
+they are at identifying real faults. This is a very high
+
+35
+00:01:44,140 --> 00:01:46,470
+level [UNKNOWN], but just to give you the intuition and the idea
+
+36
+00:01:46,470 --> 00:01:50,210
+behind these criteria, and I'm going to provide as usual, additional pointers
+
+37
+00:01:50,210 --> 00:01:52,930
+to go in more depth on these topics in the notes of
+
+38
+00:01:52,930 --> 00:01:55,170
+the class. So now, let's go back to our test criteria
+
+39
+00:01:55,170 --> 00:01:59,310
+subsumption hierarchy, and see how all of these criteria fit together in
+
+40
+00:01:59,310 --> 00:02:02,663
+this context. Let me start with multiple condition coverage. As we saw,
+
+41
+00:02:02,663 --> 00:02:06,740
+MC/DC is sort of as [UNKNOWN] way of doing multiple condition coverage
+
+42
+00:02:06,740 --> 00:02:09,229
+in the sense that it doesn't consider all the combinations,
+
+43
+00:02:09,229 --> 00:02:11,460
+but only the ones that are more likely to matter.
+
+44
+00:02:11,460 --> 00:02:14,930
+And as such, MC/DC exercises a subset of the elements
+
+45
+00:02:14,930 --> 00:02:16,220
+of the multiple condition coverage
+
+46
+00:02:16,220 --> 00:02:18,760
+exercises. And therefore, multiple condition coverage
+
+47
+00:02:18,760 --> 00:02:22,060
+is more thorough than MC/DC and subsumption, and it's also
+
+48
+00:02:22,060 --> 00:02:26,300
+as we saw incredibly more expensive. Path coverage subsumes branch coverage,
+
+49
+00:02:26,300 --> 00:02:28,090
+because if I cover all of the paths in the
+
+50
+00:02:28,090 --> 00:02:32,140
+code, I necessarily cover all the branches. However, it doesn't subsume
+
+51
+00:02:32,140 --> 00:02:34,130
+multiple condition coverage, MC/CD, or
+
+52
+00:02:34,130 --> 00:02:35,910
+branch and condition coverage. Because this
+
+53
+00:02:35,910 --> 00:02:38,590
+criteria, have additional requirements involving
+
+54
+00:02:38,590 --> 00:02:39,940
+the conditions of the predicate that
+
+55
+00:02:39,940 --> 00:02:42,730
+path coverage does not have. As for data-flow coverage criteria and
+
+56
+00:02:42,730 --> 00:02:45,010
+mutation coverage criteria, there really no
+
+57
+00:02:45,010 --> 00:02:46,860
+relation with the other criteria, because
+
+58
+00:02:46,860 --> 00:02:49,710
+they look at different aspects, of the code. So they're not
+
+59
+00:02:49,710 --> 00:02:52,220
+really comparable, and therefore we're just going to put them on the
+
+60
+00:02:52,220 --> 00:02:55,000
+side, without any relationship with the other ones. The reason why
+
+61
+00:02:55,000 --> 00:02:57,300
+I want to represent them all anyways is because I want to make
+
+62
+00:02:57,300 --> 00:02:59,950
+an important distinction between these different criteria. And
+
+63
+00:02:59,950 --> 00:03:02,690
+that's the distinction between practical criteria, which are
+
+64
+00:03:02,690 --> 00:03:05,490
+criteria that are actually not too expansive to
+
+65
+00:03:05,490 --> 00:03:08,790
+be used in real scenarios. And theoretical criteria, which
+
+66
+00:03:08,790 --> 00:03:11,590
+are criteria that are useful in theory from
+
+67
+00:03:11,590 --> 00:03:14,140
+the conceptual standpoint, but they're not really applicable
+
+68
+00:03:14,140 --> 00:03:16,540
+in practice because they're too expansive, because they
+
+69
+00:03:16,540 --> 00:03:19,460
+require basically too many test cases to be satisfied.
diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/24 - Review Quiz - lang_en_vs4.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/24 - Review Quiz - lang_en_vs4.srt
new file mode 100644
index 0000000..3f1d6ee
--- /dev/null
+++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/24 - Review Quiz - lang_en_vs4.srt	
@@ -0,0 +1,63 @@
+1
+00:00:00,160 --> 00:00:04,260
+White box testing, in general, and coverage criteria in particular, involve some
+
+2
+00:00:04,260 --> 00:00:07,550
+subtle concepts, so before I conclude this lesson, I want to have a
+
+3
+00:00:07,550 --> 00:00:10,960
+few more quizzes to make sure that we all understand these concepts.
+
+4
+00:00:10,960 --> 00:00:13,610
+The first one involves a very simple piece of code, a straight line
+
+5
+00:00:13,610 --> 00:00:16,540
+of code, three statements, in which we simply read an integer and
+
+6
+00:00:16,540 --> 00:00:20,180
+then prints 10 divided by the value of that integer minus 3. Now,
+
+7
+00:00:20,180 --> 00:00:22,250
+let's imagine that we have a test where there consists of three
+
+8
+00:00:22,250 --> 00:00:25,250
+test cases for this code, and what I'm showing in the test cases
+
+9
+00:00:25,250 --> 00:00:28,580
+is the input and the expected output. So for the first one,
+
+10
+00:00:28,580 --> 00:00:31,280
+the input is 1, and I expect the output to be minus 5.
+
+11
+00:00:31,280 --> 00:00:34,480
+For the second one, the input is minus 1, I'm expecting to
+
+12
+00:00:34,480 --> 00:00:37,120
+have 2.5. And for the third one, the input is 0, and I'm
+
+13
+00:00:37,120 --> 00:00:42,440
+expecting to have minus 3.3333 as the result. Now the first question
+
+14
+00:00:42,440 --> 00:00:45,180
+I want to ask, is if we considered this test suite, and we
+
+15
+00:00:45,180 --> 00:00:48,050
+run it on the code, does it achieve path coverage? And remember
+
+16
+00:00:48,050 --> 00:00:50,960
+that path coverage is one of the strongest coverage criteria that we saw.
diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/25 - Review Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/25 - Review Quiz Solution - lang_en_vs4.srt
new file mode 100644
index 0000000..19d1177
--- /dev/null
+++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/25 - Review Quiz Solution - lang_en_vs4.srt	
@@ -0,0 +1,7 @@
+1
+00:00:00,180 --> 00:00:04,040
+And the answer in this case is clearly yes. In fact, any input will really
+
+2
+00:00:04,040 --> 00:00:07,430
+achieve path coverage for this code because there is only one path in the code.
diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/26 - Review Quiz - lang_en_vs4.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/26 - Review Quiz - lang_en_vs4.srt
new file mode 100644
index 0000000..a07e712
--- /dev/null
+++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/26 - Review Quiz - lang_en_vs4.srt	
@@ -0,0 +1,15 @@
+1
+00:00:00,108 --> 00:00:03,890
+But now want to ask a different question which is, does this test reveal
+
+2
+00:00:03,890 --> 00:00:07,760
+the fault at line three? Clearly, here there is a possible problem, because
+
+3
+00:00:07,760 --> 00:00:10,440
+if we pass the right input, we can have a division by zero.
+
+4
+00:00:10,440 --> 00:00:13,760
+Is that revealed if we run this test within the code? Yes or no?
diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/27 - Review Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/27 - Review Quiz Solution - lang_en_vs4.srt
new file mode 100644
index 0000000..9945694
--- /dev/null
+++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/27 - Review Quiz Solution - lang_en_vs4.srt	
@@ -0,0 +1,55 @@
+1
+00:00:00,340 --> 00:00:03,581
+And the answer is no. So even path coverage's stronger criteria
+
+2
+00:00:03,581 --> 00:00:06,376
+that we saw is not enough to reveal this problem. And why
+
+3
+00:00:06,376 --> 00:00:08,526
+is that? So let me go back to a concept that
+
+4
+00:00:08,526 --> 00:00:12,491
+I mentioned in a previous lesson, the cost of exhaustive testing. Exhaustive
+
+5
+00:00:12,491 --> 00:00:15,236
+testing is really the only way in which we can exercise
+
+6
+00:00:15,236 --> 00:00:18,230
+all of the possible behaviors of a program. So we can say
+
+7
+00:00:18,230 --> 00:00:21,884
+even though it might sound like topology, that only exhaustive testing is
+
+8
+00:00:21,884 --> 00:00:25,710
+exhausted. All the coverage criteria that we saw are just process and
+
+9
+00:00:25,710 --> 00:00:30,900
+just approximation of a complete test. So test is a best effort kind
+
+10
+00:00:30,900 --> 00:00:33,180
+of activity. Coverage criteria help you assess
+
+11
+00:00:33,180 --> 00:00:35,430
+how well you tested but once more,
+
+12
+00:00:35,430 --> 00:00:40,060
+test can only reveal issues, can only reveal problems. You can never show the
+
+13
+00:00:40,060 --> 00:00:42,530
+absence of problems. And that's something is
+
+14
+00:00:42,530 --> 00:00:44,377
+important to remember when we do testing.
diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/28 - Review Quiz - lang_en_vs4.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/28 - Review Quiz - lang_en_vs4.srt
new file mode 100644
index 0000000..d6dd40a
--- /dev/null
+++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/28 - Review Quiz - lang_en_vs4.srt	
@@ -0,0 +1,31 @@
+1
+00:00:00,290 --> 00:00:03,220
+Now let's do another quiz considering a slightly different piece
+
+2
+00:00:03,220 --> 00:00:05,050
+of code. In this case we have five layers of
+
+3
+00:00:05,050 --> 00:00:08,684
+code. We have a variable i, a variable j. Variable
+
+4
+00:00:08,684 --> 00:00:11,620
+j is read from the input. And then based on
+
+5
+00:00:11,620 --> 00:00:14,500
+this predicate, we either print the value of i or
+
+6
+00:00:14,500 --> 00:00:16,850
+simply exit. And what I want to know from you is
+
+7
+00:00:16,850 --> 00:00:19,990
+whether you can create a test suite to achieve statement
+
+8
+00:00:19,990 --> 00:00:22,660
+coverage for this simple piece of code. Yes or no?
diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/29 - Review Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/29 - Review Quiz Solution - lang_en_vs4.srt
new file mode 100644
index 0000000..1e3228c
--- /dev/null
+++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/29 - Review Quiz Solution - lang_en_vs4.srt	
@@ -0,0 +1,119 @@
+1
+00:00:00,230 --> 00:00:02,520
+And the answer in this case is no. And
+
+2
+00:00:02,520 --> 00:00:05,480
+the reason for this is because this code is
+
+3
+00:00:05,480 --> 00:00:08,950
+unreachable. This is dead code because no matter the
+
+4
+00:00:08,950 --> 00:00:12,560
+value of j, this condition will always be false because
+
+5
+00:00:12,560 --> 00:00:14,770
+i will always be 0. And notice that this
+
+6
+00:00:14,770 --> 00:00:17,670
+is a small example, but another important truth is
+
+7
+00:00:17,670 --> 00:00:22,520
+that any non-trivial program contains dead or unreachable code,
+
+8
+00:00:22,520 --> 00:00:25,610
+code that no matter how well we test our system,
+
+9
+00:00:25,610 --> 00:00:28,450
+we will never be able to exercise. Why is that? Various
+
+10
+00:00:28,450 --> 00:00:31,030
+reasons. For example, defensive programming or,
+
+11
+00:00:31,030 --> 00:00:33,600
+for example, developing for future releases.
+
+12
+00:00:33,600 --> 00:00:36,320
+So there might be pieces of code that are added, but they're
+
+13
+00:00:36,320 --> 00:00:39,380
+still not activated. They're still not invoked by any other part of
+
+14
+00:00:39,380 --> 00:00:41,970
+the code because of modifications to the code. There are some
+
+15
+00:00:41,970 --> 00:00:44,480
+parts that were executed before and in the new version of the
+
+16
+00:00:44,480 --> 00:00:47,915
+program, they are no longer exercised. They are no longer executable. But
+
+17
+00:00:47,915 --> 00:00:50,760
+they still remain in the code base. And this is a very,
+
+18
+00:00:50,760 --> 00:00:54,560
+very normal situation for this reason and many more. And this is
+
+19
+00:00:54,560 --> 00:00:56,790
+an important concept because this affects
+
+20
+00:00:56,790 --> 00:00:58,760
+the very meaning of coverage measures. If
+
+21
+00:00:58,760 --> 00:01:01,225
+there is some unreachable code, we will never be able to reach
+
+22
+00:01:01,225 --> 00:01:04,709
+100% code coverage. And in fact, if you remember, at the beginning of
+
+23
+00:01:04,709 --> 00:01:07,380
+the lesson, we discussed this concept and asked you why you think
+
+24
+00:01:07,380 --> 00:01:10,470
+that, in the industry, the target for coverage is not 100% but less
+
+25
+00:01:10,470 --> 00:01:12,850
+that that. And that's the answer, to account for the fact that there
+
+26
+00:01:12,850 --> 00:01:15,890
+are infeasibility problems that I have to take into account when I test
+
+27
+00:01:15,890 --> 00:01:19,920
+the code, infeasible paths, unexecutable statements, conditions that can never
+
+28
+00:01:19,920 --> 00:01:22,780
+be true, and so on. So most criteria, if not
+
+29
+00:01:22,780 --> 00:01:24,620
+all, are affected, and we need to take that into
+
+30
+00:01:24,620 --> 00:01:27,270
+account when we try to achieve a given coverage target.
diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/3 - Coverage Criteria Intro - lang_en_vs4.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/3 - Coverage Criteria Intro - lang_en_vs4.srt
new file mode 100644
index 0000000..b1a38a7
--- /dev/null
+++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/3 - Coverage Criteria Intro - lang_en_vs4.srt	
@@ -0,0 +1,171 @@
+1
+00:00:00,320 --> 00:00:04,059
+So let's start our lesson on white docs testing by considering again the
+
+2
+00:00:04,059 --> 00:00:07,470
+program PrintSum. If you remember, this is the same program that we used when
+
+3
+00:00:07,470 --> 00:00:10,300
+we were talking about black box testing. It's the program that takes two
+
+4
+00:00:10,300 --> 00:00:14,050
+integers, A and B, and produces, as a result, the sum of the two.
+
+5
+00:00:14,050 --> 00:00:16,570
+And when we were looking at this problem in the context of black
+
+6
+00:00:16,570 --> 00:00:17,760
+box testing, we did not look at
+
+7
+00:00:17,760 --> 00:00:19,700
+implementation. But that's exactly what we're going to
+
+8
+00:00:19,700 --> 00:00:22,090
+do now. So we're going to open the box and look at how the
+
+9
+00:00:22,090 --> 00:00:25,700
+code is implemented. And as you can see, the programmer was kind of creative.
+
+10
+00:00:25,700 --> 00:00:28,670
+Because instead of just adding the two numbers and printing them, he
+
+11
+00:00:28,670 --> 00:00:32,080
+or she also decided to print them in a specific color depending
+
+12
+00:00:32,080 --> 00:00:36,840
+on whether they were positive numbers or negative numbers. So positive results
+
+13
+00:00:36,840 --> 00:00:40,040
+are printed in red and negative results are printed in blue. And as
+
+14
+00:00:40,040 --> 00:00:41,970
+you can see by looking at the code we can see some
+
+15
+00:00:41,970 --> 00:00:45,150
+interesting cases that we might want to test. For instance you can
+
+16
+00:00:45,150 --> 00:00:48,190
+see that there are two decisions made here. So we might decide
+
+17
+00:00:48,190 --> 00:00:51,100
+that this is an interesting case and therefore we want to test it.
+
+18
+00:00:51,100 --> 00:00:53,770
+Similarly we might look at this other case and we might
+
+19
+00:00:53,770 --> 00:00:56,465
+also decide that this is another interesting case and therefore we
+
+20
+00:00:56,465 --> 00:00:58,970
+want to test this one as well. So let's discuss this
+
+21
+00:00:58,970 --> 00:01:01,480
+in a slightly more formal way by introducing the concept of
+
+22
+00:01:01,480 --> 00:01:05,110
+coverage criteria which are really the essence of why box testing.
+
+23
+00:01:05,110 --> 00:01:08,930
+First of all coverage criteria are defined in terms of test
+
+24
+00:01:08,930 --> 00:01:13,460
+requirements where test requirements are the elements, the entities in the
+
+25
+00:01:13,460 --> 00:01:16,250
+code that we need to exercise. That we need to execute
+
+26
+00:01:16,250 --> 00:01:18,690
+in order to satisfy the criteria. And we'll see plenty
+
+27
+00:01:18,690 --> 00:01:21,430
+of examples of that. And normally, when I apply a coverage
+
+28
+00:01:21,430 --> 00:01:24,810
+criterion, my result is a set of test specifications. And we
+
+29
+00:01:24,810 --> 00:01:26,540
+already saw test specifications. Those
+
+30
+00:01:26,540 --> 00:01:29,540
+are basically descriptions, specifications, of how
+
+31
+00:01:29,540 --> 00:01:32,786
+the tests should be in order to satisfy the requirements. And
+
+32
+00:01:32,786 --> 00:01:36,210
+they also result in actual test cases, which are instantiations of
+
+33
+00:01:36,210 --> 00:01:39,470
+the test specifications. And again this is exactly analogous to what
+
+34
+00:01:39,470 --> 00:01:41,830
+we saw when we were talking about the black box testing.
+
+35
+00:01:41,830 --> 00:01:43,960
+So let's see what this means by going back to our
+
+36
+00:01:43,960 --> 00:01:46,680
+example. A minute ago, we looked at the print sum code
+
+37
+00:01:46,680 --> 00:01:50,000
+and we identified two interesting cases for our code. And those
+
+38
+00:01:50,000 --> 00:01:53,430
+are exactly our test requirements. So we have a first test
+
+39
+00:01:53,430 --> 00:01:57,840
+requirement here, which is the execution of this particular statement and
+
+40
+00:01:57,840 --> 00:02:01,500
+a second requirement here and this one corresponds to the execution
+
+41
+00:02:01,500 --> 00:02:04,580
+of this other statement. So for this example there are two
+
+42
+00:02:04,580 --> 00:02:06,920
+things that we need to do in order to satisfy our
+
+43
+00:02:06,920 --> 00:02:10,100
+coverage requirements. Execute this statement and execute this statement.
diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/30 - Summary - lang_en_vs4.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/30 - Summary - lang_en_vs4.srt
new file mode 100644
index 0000000..264491d
--- /dev/null
+++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/30 - Summary - lang_en_vs4.srt	
@@ -0,0 +1,127 @@
+1
+00:00:00,190 --> 00:00:02,800
+Now let me conclude the lesson by summarizing a few important
+
+2
+00:00:02,800 --> 00:00:06,840
+aspects of white-box testing. The first important aspect is that white-box
+
+3
+00:00:06,840 --> 00:00:09,770
+testing works on a formal model. The code itself are models
+
+4
+00:00:09,770 --> 00:00:12,430
+derived from the code. So when we do white-box testing, we
+
+5
+00:00:12,430 --> 00:00:15,160
+don't need to make subjective decision, for example, on the level
+
+6
+00:00:15,160 --> 00:00:18,890
+of obstruction of our models. Normally, we simply represent what's there.
+
+7
+00:00:18,890 --> 00:00:22,010
+And so what we will obtain are objective, results and objective
+
+8
+00:00:22,010 --> 00:00:25,400
+measures. As I also said at the beginning, coverage criteria allows
+
+9
+00:00:25,400 --> 00:00:28,790
+us to compare different test suites, different sets of tests,
+
+10
+00:00:28,790 --> 00:00:31,780
+because I can measure the coverage achieved by one test suite
+
+11
+00:00:31,780 --> 00:00:34,280
+and by the other, and then decide which one to use
+
+12
+00:00:34,280 --> 00:00:37,400
+based on this measure. And again, remember, these measures aren't perfect,
+
+13
+00:00:37,400 --> 00:00:40,700
+but they at least give you an objective number, an objective
+
+14
+00:00:40,700 --> 00:00:44,470
+measure of the likely effectiveness of your tests. So even though
+
+15
+00:00:44,470 --> 00:00:48,130
+achieving 100% coverage does not mean that you identify all the
+
+16
+00:00:48,130 --> 00:00:50,710
+problems in the code for sure. If your level of coverage
+
+17
+00:00:50,710 --> 00:00:53,700
+is 10%, for example, for stemen coverage. That means that
+
+18
+00:00:53,700 --> 00:00:57,360
+you haven't exercised 90% of your code, and therefore the trouble
+
+19
+00:00:57,360 --> 00:01:00,565
+is in a piece of software that is inadequately tested
+
+20
+00:01:00,565 --> 00:01:03,600
+and likely to be of inadequate quality. We also saw that
+
+21
+00:01:03,600 --> 00:01:07,370
+there are two broad classes of coverage criteria, practical criteria
+
+22
+00:01:07,370 --> 00:01:10,430
+that we can actually use, and theoretical criteria that are interesting
+
+23
+00:01:10,430 --> 00:01:13,410
+from a conceptual standpoint, but that they are totally impractical.
+
+24
+00:01:13,410 --> 00:01:16,170
+They are too expensive to be used on real world software.
+
+25
+00:01:16,170 --> 00:01:18,350
+And finally, as we also said at the beginning,
+
+26
+00:01:18,350 --> 00:01:20,820
+one of the great things about white box testing and
+
+27
+00:01:20,820 --> 00:01:23,910
+coverage criteria, is that they are fully automatable. There are
+
+28
+00:01:23,910 --> 00:01:27,380
+tools that can take your code, instrument it automatically. And
+
+29
+00:01:27,380 --> 00:01:29,050
+when you run your test cases, they will tell
+
+30
+00:01:29,050 --> 00:01:31,330
+you, what is the level of coverage that you achieve
+
+31
+00:01:31,330 --> 00:01:34,410
+with your test at no cost for you. So there's
+
+32
+00:01:34,410 --> 00:01:36,763
+really no reason not to measure coverage of your code.
diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/4 - Coverage Criteria Intro Quiz - lang_en_vs4.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/4 - Coverage Criteria Intro Quiz - lang_en_vs4.srt
new file mode 100644
index 0000000..2adce93
--- /dev/null
+++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/4 - Coverage Criteria Intro Quiz - lang_en_vs4.srt	
@@ -0,0 +1,39 @@
+1
+00:00:00,620 --> 00:00:03,310
+Now let's see if we are all on the same page
+
+2
+00:00:03,310 --> 00:00:07,180
+on the concept of testing specifications, and we're going to do that through
+
+3
+00:00:07,180 --> 00:00:09,280
+a quiz. What I would like for you to do is to
+
+4
+00:00:09,280 --> 00:00:12,830
+tell me, what are some possible test specifications that will satisfy the
+
+5
+00:00:12,830 --> 00:00:15,380
+requirements that we just saw? And I want you to express this
+
+6
+00:00:15,380 --> 00:00:17,270
+specification in terms of constraints on
+
+7
+00:00:17,270 --> 00:00:19,166
+the inputs. Which means, what constraints
+
+8
+00:00:19,166 --> 00:00:23,130
+should the input satisfy in order for this statement to be executed,
+
+9
+00:00:23,130 --> 00:00:26,210
+and this statement to be executed, and you can write your answer
+
+10
+00:00:26,210 --> 00:00:27,510
+here in these two slots.
diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/5 - Coverage Criteria Intro Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/5 - Coverage Criteria Intro Quiz Solution - lang_en_vs4.srt
new file mode 100644
index 0000000..2a1ff16
--- /dev/null
+++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/5 - Coverage Criteria Intro Quiz Solution - lang_en_vs4.srt	
@@ -0,0 +1,47 @@
+1
+00:00:00,080 --> 00:00:02,560
+To satisfy our first requirements, we need to find an
+
+2
+00:00:02,560 --> 00:00:06,300
+input that causes the execution of this statement. Because this statement
+
+3
+00:00:06,300 --> 00:00:09,080
+is executed only when result is greater than zero, our
+
+4
+00:00:09,080 --> 00:00:12,815
+test requirement is that a plus b must be greater than
+
+5
+00:00:12,815 --> 00:00:16,219
+0. When this is satisfied, this statement is executed therefore
+
+6
+00:00:16,219 --> 00:00:19,960
+any test case that implements this specification will cause the execution
+
+7
+00:00:19,960 --> 00:00:22,770
+of this statement. Similarly if we want to cover this statement
+
+8
+00:00:22,770 --> 00:00:25,220
+which is our second requirement we need to have a result
+
+9
+00:00:25,220 --> 00:00:27,370
+that is less than 0. Again, the result is equal
+
+10
+00:00:27,370 --> 00:00:29,490
+to a plus b, so all we need to do
+
+11
+00:00:29,490 --> 00:00:32,450
+is find the test case such that a plus b
+
+12
+00:00:32,450 --> 00:00:34,700
+is less than 0. So this is pretty straight forward.
diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/6 - Coverage Criteria Intro Quiz - lang_en_vs3.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/6 - Coverage Criteria Intro Quiz - lang_en_vs3.srt
new file mode 100644
index 0000000..42b5720
--- /dev/null
+++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/6 - Coverage Criteria Intro Quiz - lang_en_vs3.srt	
@@ -0,0 +1,63 @@
+1
+00:00:00,220 --> 00:00:03,780
+So, now that we have our test specifications. Test specification number one that
+
+2
+00:00:03,780 --> 00:00:06,740
+says that a plus b must be greater than zero. And test specification
+
+3
+00:00:06,740 --> 00:00:09,990
+number two, for which a plus b must be less than zero. I'd
+
+4
+00:00:09,990 --> 00:00:12,580
+like to do another small quiz and ask you to write some test
+
+5
+00:00:12,580 --> 00:00:16,440
+cases that will implement these specifications. And I want you to write the
+
+6
+00:00:16,440 --> 00:00:19,780
+test cases in this format. I want you to specify for each one
+
+7
+00:00:19,780 --> 00:00:22,300
+of the test cases, what is the value of a that you need
+
+8
+00:00:22,300 --> 00:00:25,160
+to use. What is the value of b that you need to use.
+
+9
+00:00:25,160 --> 00:00:28,200
+And since a test case, I like to remind you, is
+
+10
+00:00:28,200 --> 00:00:30,960
+not just a set of inputs. But is the set of
+
+11
+00:00:30,960 --> 00:00:34,050
+inputs plus expected output? I also want you to specify, what
+
+12
+00:00:34,050 --> 00:00:37,040
+is the expected output for these test cases? And in particular,
+
+13
+00:00:37,040 --> 00:00:39,540
+since we have two characteristics of the output, one is the
+
+14
+00:00:39,540 --> 00:00:41,630
+color of the output and the other one is the actual
+
+15
+00:00:41,630 --> 00:00:44,040
+value. I want you to specify for each test case, what
+
+16
+00:00:44,040 --> 00:00:46,790
+is the expected output color and what is the expected value?
diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/7 - Coverage Criteria Intro Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/7 - Coverage Criteria Intro Quiz Solution - lang_en_vs4.srt
new file mode 100644
index 0000000..749a57e
--- /dev/null
+++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/7 - Coverage Criteria Intro Quiz Solution - lang_en_vs4.srt	
@@ -0,0 +1,87 @@
+1
+00:00:00,090 --> 00:00:02,360
+In this case like in many other cases, there's not just a
+
+2
+00:00:02,360 --> 00:00:05,550
+single right answer because you can build many test cases that will
+
+3
+00:00:05,550 --> 00:00:09,730
+satisfy this test specification. So for example, we could pick value 3
+
+4
+00:00:09,730 --> 00:00:13,640
+for a and value 9 for b. Those satisfy the specification because a
+
+5
+00:00:13,640 --> 00:00:16,400
+plus b is equal to 12 and therefore is greater than 0,
+
+6
+00:00:16,400 --> 00:00:19,470
+and therefore this is a test case that implements this test specification.
+
+7
+00:00:19,470 --> 00:00:21,960
+And in terms of results, what we expect to see is in
+
+8
+00:00:21,960 --> 00:00:25,200
+the case of a result greater than 0, the caller should be red,
+
+9
+00:00:25,200 --> 00:00:28,109
+and the upper value should be 12. And obviously for this test
+
+10
+00:00:28,109 --> 00:00:30,971
+specification, we just need to pick two inputs such that the sum
+
+11
+00:00:30,971 --> 00:00:33,674
+of the two inputs is less than 0. So for example, we
+
+12
+00:00:33,674 --> 00:00:37,125
+could pick minus 5 and minus 8. The output color in this
+
+13
+00:00:37,125 --> 00:00:40,230
+case is going to be blue, and the output value is going to be
+
+14
+00:00:40,230 --> 00:00:43,780
+minus 13. So, what we just saw is basically how we can
+
+15
+00:00:43,780 --> 00:00:47,060
+go from a piece of code to a set of requirements, which
+
+16
+00:00:47,060 --> 00:00:50,260
+are the interesting aspects of the code that we want to exercise. How we
+
+17
+00:00:50,260 --> 00:00:52,800
+can satisfy the requirements by finding
+
+18
+00:00:52,800 --> 00:00:54,700
+the right test specifications, and then how
+
+19
+00:00:54,700 --> 00:00:58,450
+we can initiate the test specifications into actual test cases. And this is
+
+20
+00:00:58,450 --> 00:01:01,010
+what we will do in general when doing white books testing. And we'll
+
+21
+00:01:01,010 --> 00:01:02,520
+do things likely different way, depending on
+
+22
+00:01:02,520 --> 00:01:04,230
+the specific criteria that we are considering.
diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/8 - Statement Coverage - lang_en_vs4.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/8 - Statement Coverage - lang_en_vs4.srt
new file mode 100644
index 0000000..23cfb0a
--- /dev/null
+++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/8 - Statement Coverage - lang_en_vs4.srt	
@@ -0,0 +1,291 @@
+1
+00:00:00,270 --> 00:00:03,080
+Now that we saw this overview of white-box testing, I'd like
+
+2
+00:00:03,080 --> 00:00:06,270
+to start talking about specific coverage criterion. And I'm going to start
+
+3
+00:00:06,270 --> 00:00:09,010
+with the first one, which is Statement Coverage. This criterion is
+
+4
+00:00:09,010 --> 00:00:12,355
+going to be characterized by two aspects, the first one is which
+
+5
+00:00:12,355 --> 00:00:15,580
+are the Test requirements for the criteria and the second one
+
+6
+00:00:15,580 --> 00:00:18,830
+is how we measure Coverage for that criteria. In the case
+
+7
+00:00:18,830 --> 00:00:22,200
+of statement coverage, these test requirements are all the statements in
+
+8
+00:00:22,200 --> 00:00:25,804
+the program. So this is the basic, the first the, the simplest
+
+9
+00:00:25,804 --> 00:00:29,860
+coverage criteria in the white-box arena. Let me remind you the assumption
+
+10
+00:00:29,860 --> 00:00:33,280
+that we made at the beginning. White-box testing is based on the assumption
+
+11
+00:00:33,280 --> 00:00:35,990
+that if there isn't a faulty element in the code, we need
+
+12
+00:00:35,990 --> 00:00:38,390
+to exercise it. We need to execute it, in order to find the
+
+13
+00:00:38,390 --> 00:00:41,260
+fault. And that's exactly what statement coverage does. If there is a
+
+14
+00:00:41,260 --> 00:00:44,450
+statement that is faulty in the code, we need to exercise it, in
+
+15
+00:00:44,450 --> 00:00:47,490
+order to find the fault. And therefore, a good measure of how well
+
+16
+00:00:47,490 --> 00:00:51,480
+we exercise the code, is the ratio of the number of executed statements.
+
+17
+00:00:51,480 --> 00:00:54,950
+So all the statements that my test cases executed, to the total
+
+18
+00:00:54,950 --> 00:00:58,570
+number of statements in the program. The higher this number, the better
+
+19
+00:00:58,570 --> 00:01:01,870
+I exercise my code. And we can also look at coverage criterion
+
+20
+00:01:01,870 --> 00:01:04,290
+in terms of questions. So what is the questions they were trying
+
+21
+00:01:04,290 --> 00:01:06,940
+to answer when we look at a specific set of test cases
+
+22
+00:01:06,940 --> 00:01:09,870
+and we assess the statement coverage that they achieved. And the question
+
+23
+00:01:09,870 --> 00:01:13,440
+is whether each statement in the program has been executed. So, statement
+
+24
+00:01:13,440 --> 00:01:16,920
+coverage is satisfied when all the statements in the program have been executed.
+
+25
+00:01:16,920 --> 00:01:19,640
+And we can satisfy to different degrees and the degrees to which it's
+
+26
+00:01:19,640 --> 00:01:23,320
+satisfied is measured by this value. So now let's go ahead and measure
+
+27
+00:01:23,320 --> 00:01:27,250
+statement coverage on our printSum example. What I'm going to show down here is
+
+28
+00:01:27,250 --> 00:01:30,500
+this progress bar in which we show the amount of coverage, the percentage of
+
+29
+00:01:30,500 --> 00:01:33,060
+coverage achieved. So what this means is that the, if I get to
+
+30
+00:01:33,060 --> 00:01:36,680
+this point I've covered 25% of the statements in the code. And my goal
+
+31
+00:01:36,680 --> 00:01:39,160
+is to get up here to cover all the statements in the code.
+
+32
+00:01:39,160 --> 00:01:42,000
+We have two test cases for this code. The first one that we just
+
+33
+00:01:42,000 --> 00:01:45,700
+saw, consists of the inputs a equal to 3 and b equal
+
+34
+00:01:45,700 --> 00:01:48,200
+to 9, and the second one has the inputs a is equal to
+
+35
+00:01:48,200 --> 00:01:50,840
+minus 5 and b is equal to minus 8. So now let's see
+
+36
+00:01:50,840 --> 00:01:53,450
+what happens when we run this test case. When we run this test
+
+37
+00:01:53,450 --> 00:01:56,920
+case, I'm going to show you by highlighting in the code the parts that
+
+38
+00:01:56,920 --> 00:02:00,430
+we cover when we start executing the code. We cover the first statement,
+
+39
+00:02:00,430 --> 00:02:01,910
+then we always execute the second
+
+40
+00:02:01,910 --> 00:02:04,180
+statement, which computes the result, we continue
+
+41
+00:02:04,180 --> 00:02:07,070
+the execution, we get to the if statement. If the result is greater
+
+42
+00:02:07,070 --> 00:02:10,038
+than zero, in this case our result is 12 because we
+
+43
+00:02:10,038 --> 00:02:12,360
+are working with the inputs 3 and 9, and therefore we
+
+44
+00:02:12,360 --> 00:02:15,710
+execute the true part of the if, we execute the statement.
+
+45
+00:02:15,710 --> 00:02:18,850
+And at this point, we just jump to the end. Because we
+
+46
+00:02:18,850 --> 00:02:21,530
+do not execute the else part of the statement, since we
+
+47
+00:02:21,530 --> 00:02:24,240
+have executed a true one, and therefore, we cover this final
+
+48
+00:02:24,240 --> 00:02:27,534
+statement. So at the end of the execution of this test
+
+49
+00:02:27,534 --> 00:02:32,313
+case, we cover one, two, three, four, five statement out of seven
+
+50
+00:02:32,313 --> 00:02:36,299
+which is roughly speaking 71%. So we can mark in here
+
+51
+00:02:36,299 --> 00:02:39,779
+that we more or less got to 71% of coverage for
+
+52
+00:02:39,779 --> 00:02:42,719
+this code. Now let's look at what happens when we execute
+
+53
+00:02:42,719 --> 00:02:45,700
+test case number two. In this case again, we execute the
+
+54
+00:02:45,700 --> 00:02:48,660
+first statement, the second statement, the third statement. In this case
+
+55
+00:02:48,660 --> 00:02:52,010
+though, the first statement, when it evaluates the value of result,
+
+56
+00:02:52,010 --> 00:02:54,250
+it sees that the result is not greater than zero because
+
+57
+00:02:54,250 --> 00:02:57,590
+our inputs are minus five and minus eight. Therefore, you will execute
+
+58
+00:02:57,590 --> 00:03:00,090
+line number five. And because the result is less than
+
+59
+00:03:00,090 --> 00:03:02,810
+zero, you will also execute line number six. So, at
+
+60
+00:03:02,810 --> 00:03:05,230
+this point, all of the statements in our code are
+
+61
+00:03:05,230 --> 00:03:09,360
+executed and therefore, we achieved a 100% statement coverage, which
+
+62
+00:03:09,360 --> 00:03:13,090
+was our goal. Before looking at other kinds of coverage,
+
+63
+00:03:13,090 --> 00:03:16,060
+let's see how our statement coverage is used in practice.
+
+64
+00:03:16,060 --> 00:03:19,170
+First of all, statement coverage is the most used kind
+
+65
+00:03:19,170 --> 00:03:22,830
+of coverage criterion in industry. Normally for company that uses
+
+66
+00:03:22,830 --> 00:03:27,200
+statement coverage, the typical coverage target is 80-90%, which
+
+67
+00:03:27,200 --> 00:03:29,690
+mean the outcome of the test should be such
+
+68
+00:03:29,690 --> 00:03:32,770
+that 80-90% of the statements are exercised at the
+
+69
+00:03:32,770 --> 00:03:34,880
+end of testing. So at this point, you might
+
+70
+00:03:34,880 --> 00:03:36,850
+be wondering, why don't we just shoot for 100%?
+
+71
+00:03:36,850 --> 00:03:38,580
+Why don't we try to cover all of the
+
+72
+00:03:38,580 --> 00:03:40,050
+code? We just saw that we could do it.
+
+73
+00:03:40,050 --> 00:03:41,730
+And so I'm going to ask you the same question.
diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/9 - Statement Coverage Quiz - lang_en_vs4.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/9 - Statement Coverage Quiz - lang_en_vs4.srt
new file mode 100644
index 0000000..893fe06
--- /dev/null
+++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/9 - Statement Coverage Quiz - lang_en_vs4.srt	
@@ -0,0 +1,15 @@
+1
+00:00:00,100 --> 00:00:01,540
+so, I would like to hear from you. Why
+
+2
+00:00:01,540 --> 00:00:03,850
+do you think that we don't aim normally at
+
+3
+00:00:03,850 --> 00:00:05,939
+100 % college but, slightly less than that and
+
+4
+00:00:05,939 --> 00:00:07,560
+I want you to put your answer right here.
diff --git a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/1 - Lesson Overview - lang_en_vs4.srt b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/1 - Lesson Overview - lang_en_vs4.srt
new file mode 100644
index 0000000..2e839f9
--- /dev/null
+++ b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/1 - Lesson Overview - lang_en_vs4.srt	
@@ -0,0 +1,75 @@
+1
+00:00:00,270 --> 00:00:02,880
+In previous lessons, we covered testing principles and
+
+2
+00:00:02,880 --> 00:00:06,610
+techniques. In this lesson, we will discuss a
+
+3
+00:00:06,610 --> 00:00:09,550
+type of software process that is heavily based
+
+4
+00:00:09,550 --> 00:00:12,812
+on the use of testing. The agile development
+
+5
+00:00:12,812 --> 00:00:17,310
+process. Also called test-driven development. To do that,
+
+6
+00:00:17,310 --> 00:00:19,290
+we will revisit some of the assumptions that
+
+7
+00:00:19,290 --> 00:00:21,490
+led to the definition of the more traditional
+
+8
+00:00:21,490 --> 00:00:24,030
+software processes. The ones that we discussed so far.
+
+9
+00:00:25,440 --> 00:00:27,690
+We will see how, when some of these assumptions are
+
+10
+00:00:27,690 --> 00:00:30,210
+no longer valid, we can change the way in which we
+
+11
+00:00:30,210 --> 00:00:32,560
+look at software processes. And we can change the way
+
+12
+00:00:32,560 --> 00:00:36,120
+in which we look at software development in general. We will
+
+13
+00:00:36,120 --> 00:00:40,250
+discuss how this changing perspective, lets us rethink software processes
+
+14
+00:00:40,250 --> 00:00:43,520
+and make them more agile and better suited for context in
+
+15
+00:00:43,520 --> 00:00:46,120
+which changes are the norm and we need to adapt
+
+16
+00:00:46,120 --> 00:00:50,535
+fast. In particular, we will discuss two processes that apply the
+
+17
+00:00:50,535 --> 00:00:53,570
+principles of agile software development and that are commonly
+
+18
+00:00:53,570 --> 00:00:59,170
+used in industry. Extreme programming, also called XP, and Scrum.
+
+19
+00:00:59,170 --> 00:01:01,560
+[BLANK_AUDIO]
diff --git a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/10 - Refactoring - lang_en_vs4.srt b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/10 - Refactoring - lang_en_vs4.srt
new file mode 100644
index 0000000..800ffb5
--- /dev/null
+++ b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/10 - Refactoring - lang_en_vs4.srt	
@@ -0,0 +1,103 @@
+1
+00:00:00,100 --> 00:00:02,469
+A couple of minutes ago we talked about the fact that well, we
+
+2
+00:00:02,469 --> 00:00:05,260
+might need to change our design a lot, so how we going to do
+
+3
+00:00:05,260 --> 00:00:08,540
+that, that's going to be expensive. Well it's not very expensive, if we can
+
+4
+00:00:08,540 --> 00:00:10,876
+do efficient refactoring. Which is another
+
+5
+00:00:10,876 --> 00:00:13,120
+one of the important xp practices. And
+
+6
+00:00:13,120 --> 00:00:15,280
+what does it mean to refactor? It means to take a piece of
+
+7
+00:00:15,280 --> 00:00:19,530
+code who's design might be suboptimal, because for example, we evolved it, we
+
+8
+00:00:19,530 --> 00:00:22,600
+didn't take into account that from the beginning some of the features that
+
+9
+00:00:22,600 --> 00:00:25,110
+had to be added later, probably because we didn't even know about this
+
+10
+00:00:25,110 --> 00:00:28,200
+feature, because the requirements evolved. So we're going to take this piece
+
+11
+00:00:28,200 --> 00:00:31,870
+of code and we're going to restructure it, so that it becomes simple
+
+12
+00:00:31,870 --> 00:00:34,070
+and maintainable. Developers are expected to
+
+13
+00:00:34,070 --> 00:00:35,590
+refactor as soon as opportunities for
+
+14
+00:00:35,590 --> 00:00:39,530
+improvement, are found. And that happens for example, before adding some code.
+
+15
+00:00:39,530 --> 00:00:41,730
+You might look at the code that you're about to modify, or
+
+16
+00:00:41,730 --> 00:00:43,850
+to which you are about to add parts, and say can we
+
+17
+00:00:43,850 --> 00:00:47,060
+change the program to make the addition simple, that has maintainability or
+
+18
+00:00:47,060 --> 00:00:50,220
+we can do it after adding some code to our code base.
+
+19
+00:00:50,220 --> 00:00:52,730
+We might look at the code, the resulting code, and say well
+
+20
+00:00:52,730 --> 00:00:55,770
+can we make the program simpler? Was the running all the tests
+
+21
+00:00:55,770 --> 00:00:57,920
+and the key point here is that we don't want to refactor on
+
+22
+00:00:57,920 --> 00:01:01,580
+speculation, but we want to refactor on demand, on the system, and the
+
+23
+00:01:01,580 --> 00:01:04,840
+process needed. Again the goal is just to keep the code simple
+
+24
+00:01:04,840 --> 00:01:07,680
+and maintainable, not to over do it. And as I mentioned before
+
+25
+00:01:07,680 --> 00:01:10,810
+we're going to have a whole lesson, the next lesson on refactoring. So
+
+26
+00:01:10,810 --> 00:01:13,470
+we're going to go in more depth in the discussion of this topic.
diff --git a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/11 - Pair Programming - lang_en_vs4.srt b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/11 - Pair Programming - lang_en_vs4.srt
new file mode 100644
index 0000000..ad48828
--- /dev/null
+++ b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/11 - Pair Programming - lang_en_vs4.srt	
@@ -0,0 +1,99 @@
+1
+00:00:00,100 --> 00:00:02,530
+The next practice I want to discuss is a very important one
+
+2
+00:00:02,530 --> 00:00:05,750
+in XP, and also one of the scandal, controversial, and it's
+
+3
+00:00:05,750 --> 00:00:08,390
+the practice of pair programming. What does it mean? It means
+
+4
+00:00:08,390 --> 00:00:11,790
+that all production code is written with two people looking at one
+
+5
+00:00:11,790 --> 00:00:15,170
+machine. And not that they're, they're working with one keyboard and
+
+6
+00:00:15,170 --> 00:00:18,450
+one mouse or they're not just interfering and writing on each other's
+
+7
+00:00:18,450 --> 00:00:20,920
+code. And the way in which that happens is by playing
+
+8
+00:00:20,920 --> 00:00:25,180
+different roles at different times. So the two developers alternate between the
+
+9
+00:00:25,180 --> 00:00:29,080
+role of programming and strategizing, where strategizing means, for example,
+
+10
+00:00:29,080 --> 00:00:31,660
+looking at the code that has been written and thinking whether
+
+11
+00:00:31,660 --> 00:00:34,420
+that would work. Or what other tests that are not there
+
+12
+00:00:34,420 --> 00:00:37,050
+might not work, given the way the code is being written.
+
+13
+00:00:37,050 --> 00:00:39,300
+Or maybe looking at the code from a, you know, slightly
+
+14
+00:00:39,300 --> 00:00:42,380
+detached perspective and trying to figure out whether the code can
+
+15
+00:00:42,380 --> 00:00:46,900
+be made simpler, more maintainable, more efficient. And interestingly, there are
+
+16
+00:00:46,900 --> 00:00:48,440
+measurements, there are studies that
+
+17
+00:00:48,440 --> 00:00:50,340
+suggest that development productivity with pair
+
+18
+00:00:50,340 --> 00:00:52,550
+programming is similar to that of two people
+
+19
+00:00:52,550 --> 00:00:55,080
+working independently. And that answers one of the
+
+20
+00:00:55,080 --> 00:00:57,740
+main objections against pair programming, which is why
+
+21
+00:00:57,740 --> 00:00:59,840
+should I put two developers together, which is
+
+22
+00:00:59,840 --> 00:01:01,860
+going to cut their productivity in half. It is
+
+23
+00:01:01,860 --> 00:01:04,390
+not. Studies shows that that does not happen.
+
+24
+00:01:04,390 --> 00:01:06,380
+And that the resulting code can actually benefit
+
+25
+00:01:06,380 --> 00:01:08,350
+from the fact that two developers are working together.
diff --git a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/12 - Continuous Integration - lang_en_vs4.srt b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/12 - Continuous Integration - lang_en_vs4.srt
new file mode 100644
index 0000000..d40bda6
--- /dev/null
+++ b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/12 - Continuous Integration - lang_en_vs4.srt	
@@ -0,0 +1,111 @@
+1
+00:00:00,280 --> 00:00:02,980
+An important practice to get all of this to work is
+
+2
+00:00:02,980 --> 00:00:05,230
+continuous integration, which means integrating and
+
+3
+00:00:05,230 --> 00:00:06,770
+testing every few hours, or a
+
+4
+00:00:06,770 --> 00:00:10,390
+day at most, because we don't want problems to pile up and
+
+5
+00:00:10,390 --> 00:00:13,060
+to be discovered too late when there are too many of them
+
+6
+00:00:13,060 --> 00:00:16,020
+to fix. So what goes on here is a cycle. And the
+
+7
+00:00:16,020 --> 00:00:19,380
+cycle starts with the developer's programming, as soon as the developers are
+
+8
+00:00:19,380 --> 00:00:22,050
+done modifying the code and they have a stable version they will
+
+9
+00:00:22,050 --> 00:00:25,380
+run the local tests. If the local tests fail, the developers will
+
+10
+00:00:25,380 --> 00:00:28,350
+go back to programming to fix their code and possibly add
+
+11
+00:00:28,350 --> 00:00:31,990
+new code as needed, and this cycle, mini cycle will continue
+
+12
+00:00:31,990 --> 00:00:35,000
+until all the local tests pass. At that point the developers
+
+13
+00:00:35,000 --> 00:00:37,960
+can integrate their code with the code of other developers. And they
+
+14
+00:00:37,960 --> 00:00:41,220
+can run test for the integrated system, and when they run
+
+15
+00:00:41,220 --> 00:00:44,830
+this test again there are two possibilities. The test might fail, and
+
+16
+00:00:44,830 --> 00:00:47,160
+if the test fails you broke it, and therefore you'll have
+
+17
+00:00:47,160 --> 00:00:50,710
+to fix it. So developers will have to go back and modify
+
+18
+00:00:50,710 --> 00:00:54,010
+the system and again going through the cycle of running the local
+
+19
+00:00:54,010 --> 00:00:55,900
+tests, integrating, and running the systems
+
+20
+00:00:55,900 --> 00:00:57,890
+tests. Conversely, if all the systems
+
+21
+00:00:57,890 --> 00:01:00,150
+tests pass, then at that point the code is good to go
+
+22
+00:01:00,150 --> 00:01:02,500
+and it is integrated into the system. And it will be the problem
+
+23
+00:01:02,500 --> 00:01:05,370
+of some other developers if something breaks because at the time you
+
+24
+00:01:05,370 --> 00:01:09,530
+integrated your code, the code was compiling, running and passing the tests
+
+25
+00:01:09,530 --> 00:01:12,495
+successfully. So again, if we do this every few hours or every
+
+26
+00:01:12,495 --> 00:01:15,740
+day, we can find problems very early, and we can avoid the situations
+
+27
+00:01:15,740 --> 00:01:18,105
+in which we have many different changes coming from
+
+28
+00:01:18,105 --> 00:01:21,290
+many different developers in a integration nightmare as a result.
diff --git a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/13 - On Site Customer - lang_en_vs4.srt b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/13 - On Site Customer - lang_en_vs4.srt
new file mode 100644
index 0000000..a95cc07
--- /dev/null
+++ b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/13 - On Site Customer - lang_en_vs4.srt	
@@ -0,0 +1,55 @@
+1
+00:00:00,060 --> 00:00:03,500
+The last practice I want to mention is on-site customer, and what
+
+2
+00:00:03,500 --> 00:00:07,590
+that means is that literally the customer is an actual member of
+
+3
+00:00:07,590 --> 00:00:10,310
+the team. So the customer will sit with the team and will
+
+4
+00:00:10,310 --> 00:00:13,546
+bring requirements to the team and discuss the requirements with them. So
+
+5
+00:00:13,546 --> 00:00:16,461
+the typical objection to this practice is the fact that it's just
+
+6
+00:00:16,461 --> 00:00:19,640
+impossible in the real world. There is no way that the customer
+
+7
+00:00:19,640 --> 00:00:22,550
+can have one person staying with the team all the time, and
+
+8
+00:00:22,550 --> 00:00:25,130
+the answer to that objection is that if the system is not
+
+9
+00:00:25,130 --> 00:00:28,700
+worth the time of one customer then maybe the system is not worth building. In
+
+10
+00:00:28,700 --> 00:00:30,530
+other words, if you're investing tons of
+
+11
+00:00:30,530 --> 00:00:33,440
+dollars, tons of money in building a system,
+
+12
+00:00:33,440 --> 00:00:36,870
+you might just as well invest a little more and have one of the people
+
+13
+00:00:36,870 --> 00:00:39,080
+in the customer's organization stay with the
+
+14
+00:00:39,080 --> 00:00:41,450
+team and be involved in the whole process.
diff --git a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/14 - Requirements Engineering - lang_en_vs4.srt b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/14 - Requirements Engineering - lang_en_vs4.srt
new file mode 100644
index 0000000..7a00887
--- /dev/null
+++ b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/14 - Requirements Engineering - lang_en_vs4.srt	
@@ -0,0 +1,139 @@
+1
+00:00:00,210 --> 00:00:02,680
+Now that we saw what the main values and practices
+
+2
+00:00:02,680 --> 00:00:05,200
+of XP are, I want to go back for a minute
+
+3
+00:00:05,200 --> 00:00:08,800
+to discussion of requirements engineering in XP. In XP, user
+
+4
+00:00:08,800 --> 00:00:12,180
+requirements are expressed as scenarios or user stories, as we already
+
+5
+00:00:12,180 --> 00:00:15,500
+discussed. These are written by customers on cards, and what
+
+6
+00:00:15,500 --> 00:00:18,550
+the development team does is to take these cards, take these
+
+7
+00:00:18,550 --> 00:00:22,240
+users stories and break them down into implementation tasks. And
+
+8
+00:00:22,240 --> 00:00:25,310
+those implementation tasks are then used as a basis for scheduling
+
+9
+00:00:25,310 --> 00:00:29,210
+cost estimates. So given these estimates, and based on their priorities,
+
+10
+00:00:29,210 --> 00:00:31,770
+the customer will choose the stories that will be included in
+
+11
+00:00:31,770 --> 00:00:34,980
+the next release, in the next iteration. And at this point,
+
+12
+00:00:34,980 --> 00:00:39,220
+the corresponding cards will be taken by the developers and the,
+
+13
+00:00:39,220 --> 00:00:42,380
+the task will be performed, and the relative, and the corresponding
+
+14
+00:00:42,380 --> 00:00:44,350
+card will be developed. And just to give an idea of
+
+15
+00:00:44,350 --> 00:00:47,330
+the order of magnitude, if you consider a few months project,
+
+16
+00:00:47,330 --> 00:00:50,390
+there might be 50 to 100 user stories for a project of
+
+17
+00:00:50,390 --> 00:00:52,820
+that duration. So, now let me give you an example of what
+
+18
+00:00:52,820 --> 00:00:55,630
+the story card might look like, and I'm going to do it using
+
+19
+00:00:55,630 --> 00:00:58,930
+a story card for document downloading and you can really do all of
+
+20
+00:00:58,930 --> 00:01:00,780
+this, basically as seeing what the
+
+21
+00:01:00,780 --> 00:01:03,440
+scenario is, downloading and printing an article.
+
+22
+00:01:03,440 --> 00:01:06,590
+And it describes basically what happens when you do that, what is
+
+23
+00:01:06,590 --> 00:01:09,530
+the scenario. First, you select the article that you want from a displayed
+
+24
+00:01:09,530 --> 00:01:12,760
+list. You then have to tell the system how you will pay for
+
+25
+00:01:12,760 --> 00:01:15,680
+it. This can either be through a subscription, through a company account or
+
+26
+00:01:15,680 --> 00:01:18,670
+by credit card, and so on. So what developers do, they take
+
+27
+00:01:18,670 --> 00:01:22,020
+this story card, and they break it down in to development tasks.
+
+28
+00:01:22,020 --> 00:01:25,100
+So, here I'm showing you some examples of task cards for the
+
+29
+00:01:25,100 --> 00:01:28,360
+user story that we just saw. In particular I'm showing three task cards
+
+30
+00:01:28,360 --> 00:01:30,740
+and if we look at the third one, there is a name
+
+31
+00:01:30,740 --> 00:01:34,260
+for the task, which is implement payment collection. So this is the development
+
+32
+00:01:34,260 --> 00:01:37,600
+task that we have the perform and here, there's a description of
+
+33
+00:01:37,600 --> 00:01:41,240
+what that developed code should do. And notice that, you know, the task
+
+34
+00:01:41,240 --> 00:01:44,400
+card can even be more. explicit than this, more
+
+35
+00:01:44,400 --> 00:01:47,450
+specific than this, and talk about actual development tasks.
diff --git a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/15 - Testing Strategy - lang_en_vs4.srt b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/15 - Testing Strategy - lang_en_vs4.srt
new file mode 100644
index 0000000..af5ee6c
--- /dev/null
+++ b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/15 - Testing Strategy - lang_en_vs4.srt	
@@ -0,0 +1,147 @@
+1
+00:00:00,360 --> 00:00:03,320
+As you probably realized by now, at job development, it's a
+
+2
+00:00:03,320 --> 00:00:06,280
+lot about testing. So there is a lot of emphasis on
+
+3
+00:00:06,280 --> 00:00:09,420
+testing. Testing first, te, testing early. So that's the reason why
+
+4
+00:00:09,420 --> 00:00:12,710
+I also want to discuss what is the testing strategy in XP.
+
+5
+00:00:12,710 --> 00:00:14,820
+So first of all what is the basic principle? The basic
+
+6
+00:00:14,820 --> 00:00:18,770
+principle is that testing is Coded confidence. You write your test
+
+7
+00:00:18,770 --> 00:00:22,150
+cases and then you can run them anytime you want. And
+
+8
+00:00:22,150 --> 00:00:25,540
+if they pass, they'll give you confidence that your code is behaving
+
+9
+00:00:25,540 --> 00:00:27,920
+the way it's expected. If they don't pass on the other
+
+10
+00:00:27,920 --> 00:00:30,870
+hand, you'll know that there's something to fix. Another important concept is
+
+11
+00:00:30,870 --> 00:00:34,600
+that test might be isolated and automated. So both the running and
+
+12
+00:00:34,600 --> 00:00:37,400
+the checking of the tests has to be automated for all of
+
+13
+00:00:37,400 --> 00:00:39,830
+this to work. And there are two types of tests. The first
+
+14
+00:00:39,830 --> 00:00:43,170
+type of test is unit tests, that are created by the programmers,
+
+15
+00:00:43,170 --> 00:00:45,830
+and they're created by looking at the task cards. The task cards
+
+16
+00:00:45,830 --> 00:00:48,410
+describe what they implemented, functionality should
+
+17
+00:00:48,410 --> 00:00:50,740
+do, and therefore allows the developers.
+
+18
+00:00:50,740 --> 00:00:53,970
+The right test that can test this functionality. That can
+
+19
+00:00:53,970 --> 00:00:57,000
+check that the code's correctly implemented functionality. And as we
+
+20
+00:00:57,000 --> 00:01:00,670
+said, you should really test every meaninful feature. So, for
+
+21
+00:01:00,670 --> 00:01:04,250
+example, you should test every meaningful method in your classes.
+
+22
+00:01:04,250 --> 00:01:08,490
+You should put specific attention to possibly complex implementations, special
+
+23
+00:01:08,490 --> 00:01:11,100
+cases or specific problems that you might think of. while
+
+24
+00:01:11,100 --> 00:01:13,110
+reading the task cards. In some cases, when you do
+
+25
+00:01:13,110 --> 00:01:15,800
+refactoring, you might also want to write test cases specific
+
+26
+00:01:15,800 --> 00:01:18,300
+to that refactoring. But we'll say more about that. So this
+
+27
+00:01:18,300 --> 00:01:20,610
+was for the first kind of tests that are involved in
+
+28
+00:01:20,610 --> 00:01:23,650
+the, in the XP process. The second kind of tests are
+
+29
+00:01:23,650 --> 00:01:27,710
+the system tests, also called acceptance tests. And those tests involve
+
+30
+00:01:27,710 --> 00:01:30,920
+the customer. So basically what happens is that the customer provides
+
+31
+00:01:30,920 --> 00:01:33,760
+the test cases for their stores and then the development team
+
+32
+00:01:33,760 --> 00:01:37,630
+transforms those into actual automated tests. So these are tests created
+
+33
+00:01:37,630 --> 00:01:40,700
+by the developers. They run very quickly and they run very frequently.
+
+34
+00:01:40,700 --> 00:01:43,120
+These are tests developed with the help, with the
+
+35
+00:01:43,120 --> 00:01:46,170
+involvement of the customer they run longer. And run less
+
+36
+00:01:46,170 --> 00:01:48,710
+frequently, they run every time the system is integrated.
+
+37
+00:01:48,710 --> 00:01:50,890
+According to the cycle we saw a few minutes ago.
diff --git a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/16 - Testing Strategy Quiz - lang_en_vs4.srt b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/16 - Testing Strategy Quiz - lang_en_vs4.srt
new file mode 100644
index 0000000..c26e977
--- /dev/null
+++ b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/16 - Testing Strategy Quiz - lang_en_vs4.srt	
@@ -0,0 +1,47 @@
+1
+00:00:00,130 --> 00:00:02,776
+Now that we are done discussing XP Extreme Programming, I
+
+2
+00:00:02,776 --> 00:00:04,612
+would like to have a quiz, in which I make
+
+3
+00:00:04,612 --> 00:00:06,772
+sure that some of the concepts behind XP are well
+
+4
+00:00:06,772 --> 00:00:10,040
+understood. So, I'm going to ask you which of the following statements
+
+5
+00:00:10,040 --> 00:00:13,390
+about Extreme Programming are true, and here are the statements.
+
+6
+00:00:13,390 --> 00:00:17,700
+Because of pair programming, XP requires twice the number of developers.
+
+7
+00:00:17,700 --> 00:00:21,260
+In XP, code is rarely changed after being written. XP
+
+8
+00:00:21,260 --> 00:00:25,200
+follows the test driven development, or TDD, paradigm. The customer does
+
+9
+00:00:25,200 --> 00:00:27,560
+not need to provide any requirements in XP.
+
+10
+00:00:27,560 --> 00:00:31,120
+XP is an iterative software development process. So I
+
+11
+00:00:31,120 --> 00:00:32,700
+would like for you to mark all of
+
+12
+00:00:32,700 --> 00:00:35,020
+the statements that you think are true about XP.
diff --git a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/17 - Testing Strategy Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/17 - Testing Strategy Quiz Solution - lang_en_vs4.srt
new file mode 100644
index 0000000..b60861f
--- /dev/null
+++ b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/17 - Testing Strategy Quiz Solution - lang_en_vs4.srt	
@@ -0,0 +1,127 @@
+1
+00:00:00,120 --> 00:00:02,600
+The first statement is false. It is not true
+
+2
+00:00:02,600 --> 00:00:04,840
+that because of pair programming, we need twice as many
+
+3
+00:00:04,840 --> 00:00:08,039
+developers. In fact that there is some evidence that even
+
+4
+00:00:08,039 --> 00:00:11,700
+though in pair programming we have two developers working together,
+
+5
+00:00:11,700 --> 00:00:15,175
+that the overall efficiency of the programmers is not really
+
+6
+00:00:15,175 --> 00:00:19,080
+affected by use of this practice. In XP, code is
+
+7
+00:00:19,080 --> 00:00:23,280
+rarely changed after being written. This is also definitely false.
+
+8
+00:00:23,280 --> 00:00:25,233
+In fact in XP there is a lot of emphasis
+
+9
+00:00:25,233 --> 00:00:27,879
+on change on the fact that the code can be changed,
+
+10
+00:00:27,879 --> 00:00:30,462
+it can be resigned, because of the fact when we do
+
+11
+00:00:30,462 --> 00:00:32,793
+that, we have a set of these cases that we can
+
+12
+00:00:32,793 --> 00:00:35,439
+use to check right away that the code still works as
+
+13
+00:00:35,439 --> 00:00:39,850
+expected. So again in XP, it's all about steering rather than
+
+14
+00:00:39,850 --> 00:00:43,430
+just driving down one fixed direction. And therefore, the code can
+
+15
+00:00:43,430 --> 00:00:46,580
+be changed. So this statement is false. It is definitely true
+
+16
+00:00:46,580 --> 00:00:50,950
+that XP follows the test driven development paradigm. In XP we first
+
+17
+00:00:50,950 --> 00:00:53,320
+write tests, and then we write the code, which is
+
+18
+00:00:53,320 --> 00:00:55,980
+exactly what TDD is about. It is not true that
+
+19
+00:00:55,980 --> 00:00:58,740
+the customer does not need to provide requirements in XP.
+
+20
+00:00:58,740 --> 00:01:02,020
+The customer does provide requirements in the form of user
+
+21
+00:01:02,020 --> 00:01:04,879
+stories, and the user stories are the starting point of
+
+22
+00:01:04,879 --> 00:01:09,370
+the development process. Finally, XP is definitely an iterative software
+
+23
+00:01:09,370 --> 00:01:12,500
+development process. In fact, we saw that XP is based
+
+24
+00:01:12,500 --> 00:01:16,100
+on subsequent iterations of the same cycle, in which we
+
+25
+00:01:16,100 --> 00:01:18,110
+select from a set of story cards, or user
+
+26
+00:01:18,110 --> 00:01:21,270
+stories, the stories that we want to implement in the
+
+27
+00:01:21,270 --> 00:01:24,250
+next iteration. Based on that we develop task cards,
+
+28
+00:01:24,250 --> 00:01:26,060
+and then we use the task cards to write this
+
+29
+00:01:26,060 --> 00:01:28,400
+case and then to write code. And we continue
+
+30
+00:01:28,400 --> 00:01:31,140
+this cycle in an iterative way until we are done
+
+31
+00:01:31,140 --> 00:01:33,030
+with all the story cards, and all the user
+
+32
+00:01:33,030 --> 00:01:36,612
+stories, so definitely XP is an iterative software development process.
diff --git a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/18 - Scrum Intro - lang_en_vs4.srt b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/18 - Scrum Intro - lang_en_vs4.srt
new file mode 100644
index 0000000..4d8eab6
--- /dev/null
+++ b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/18 - Scrum Intro - lang_en_vs4.srt	
@@ -0,0 +1,99 @@
+1
+00:00:00,220 --> 00:00:02,830
+Before concluding this class on java development, I want to
+
+2
+00:00:02,830 --> 00:00:06,330
+talk about another process that is very popular these days, and
+
+3
+00:00:06,330 --> 00:00:09,990
+it's used in many companies, which is called Scrum. Which similar
+
+4
+00:00:09,990 --> 00:00:13,370
+to XP is another agile development process, and I'm going to
+
+5
+00:00:13,370 --> 00:00:16,400
+start by discussing what the Scrum actors are. There's three
+
+6
+00:00:16,400 --> 00:00:19,490
+main kinds of actors. The first one is the product owner,
+
+7
+00:00:19,490 --> 00:00:22,590
+which means the customer. The product owner is mainly responsible for
+
+8
+00:00:22,590 --> 00:00:25,460
+the product back log, where the product back log is basically
+
+9
+00:00:25,460 --> 00:00:27,660
+the list of things that have to be done, the
+
+10
+00:00:27,660 --> 00:00:30,670
+back log in fact for the project. And that is
+
+11
+00:00:30,670 --> 00:00:33,640
+analogous to the user stories to be realized in XP,
+
+12
+00:00:33,640 --> 00:00:36,190
+that we just saw. So what the product owner does is
+
+13
+00:00:36,190 --> 00:00:39,310
+to clearly express these back log items, and to also
+
+14
+00:00:39,310 --> 00:00:42,680
+order them by value, so they can be prioritized. The second
+
+15
+00:00:42,680 --> 00:00:45,680
+actor is the team. The team is responsible for delivering
+
+16
+00:00:45,680 --> 00:00:48,012
+shippable increments to estimate the
+
+17
+00:00:48,012 --> 00:00:50,600
+back log items. It's normally self-organized,
+
+18
+00:00:50,600 --> 00:00:53,055
+consists of four to nine people, and it's what you
+
+19
+00:00:53,055 --> 00:00:56,180
+would consider normally as the main development team in a
+
+20
+00:00:56,180 --> 00:00:59,080
+project. And finally we have the Scrum master. The Scrum
+
+21
+00:00:59,080 --> 00:01:02,860
+master is the person who's responsible for the overall Scrum process,
+
+22
+00:01:02,860 --> 00:01:05,980
+so he or she has to remove obstacles, facilitate events,
+
+23
+00:01:05,980 --> 00:01:08,668
+helps communications, and so on. So you you can see
+
+24
+00:01:08,668 --> 00:01:11,013
+the Scrum master as sort of a manager or the
+
+25
+00:01:11,013 --> 00:01:15,059
+person who's got oversight, or the supervisor of the Scrum process.
diff --git a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/19 - High Level Scrum Process - lang_en_vs4.srt b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/19 - High Level Scrum Process - lang_en_vs4.srt
new file mode 100644
index 0000000..d646b4e
--- /dev/null
+++ b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/19 - High Level Scrum Process - lang_en_vs4.srt	
@@ -0,0 +1,215 @@
+1
+00:00:00,100 --> 00:00:02,200
+So I want to conclude this lesson by providing a high
+
+2
+00:00:02,200 --> 00:00:05,790
+level view of this scrum process. The process is represented here,
+
+3
+00:00:05,790 --> 00:00:07,939
+and as you can see it has several components. We're going to
+
+4
+00:00:07,939 --> 00:00:09,860
+go through all of them one at a time. We're going to
+
+5
+00:00:09,860 --> 00:00:13,110
+start with a product backlog. Product backlog is the single source
+
+6
+00:00:13,110 --> 00:00:17,420
+of requirements, for the process. They're order by value raised priority
+
+7
+00:00:17,420 --> 00:00:21,110
+necessity, so that all of this characteristics can be taken into
+
+8
+00:00:21,110 --> 00:00:25,920
+account when selecting which backlog items to consider for the next iteration.
+
+9
+00:00:25,920 --> 00:00:28,710
+It's a living list in the sense that backlog items
+
+10
+00:00:28,710 --> 00:00:31,020
+can be added or removed. And it's not really defined
+
+11
+00:00:31,020 --> 00:00:33,200
+as we just said, by the product owner. In the
+
+12
+00:00:33,200 --> 00:00:36,260
+sprint planning, what happens is that the next increment or
+
+13
+00:00:36,260 --> 00:00:40,180
+the next sprint is defined. So basically, the backlog items
+
+14
+00:00:40,180 --> 00:00:43,348
+of interest are selected based on the characteristics we just
+
+15
+00:00:43,348 --> 00:00:46,890
+mentioned: value, [UNKNOWN], priority, and necessity. And the items are
+
+16
+00:00:46,890 --> 00:00:50,950
+converted into tasks and estimated. So the result is this sprint
+
+17
+00:00:50,950 --> 00:00:54,240
+backlog, which is the set of backlog items that will
+
+18
+00:00:54,240 --> 00:00:57,650
+be completed during the next sprint. The sprint is an actual
+
+19
+00:00:57,650 --> 00:01:01,040
+iteration of this scrum process. It's got a main part
+
+20
+00:01:01,040 --> 00:01:04,730
+that lasts two to four weeks, and within this main part,
+
+21
+00:01:04,730 --> 00:01:08,150
+there are many daily scrums that last 24 hours. So
+
+22
+00:01:08,150 --> 00:01:11,260
+let's see how this work. A daily scrum is typically characterized
+
+23
+00:01:11,260 --> 00:01:13,960
+by a 50-minute meeting at the beginning of the day
+
+24
+00:01:13,960 --> 00:01:16,220
+for the team to sync, and what happens during the meeting
+
+25
+00:01:16,220 --> 00:01:19,010
+is that there is a discussion of the accomplishments since
+
+26
+00:01:19,010 --> 00:01:21,210
+the last meeting. A to do list for the next
+
+27
+00:01:21,210 --> 00:01:24,210
+meeting is produced, and there is also an obstacle analysis.
+
+28
+00:01:24,210 --> 00:01:27,690
+So if some problem appear, they're discussing the daily scrum, and
+
+29
+00:01:27,690 --> 00:01:30,905
+possible solutions are proposed. At the end of the two
+
+30
+00:01:30,905 --> 00:01:34,840
+four-week cycle, there is a sprint review and retrospective. The sprint
+
+31
+00:01:34,840 --> 00:01:37,440
+review normally consists of a four hour meeting. In the
+
+32
+00:01:37,440 --> 00:01:41,270
+meeting, the product owner assesses the accomplishment for the specific sprint,
+
+33
+00:01:41,270 --> 00:01:44,020
+and the team discusses issues that were encountered and solved.
+
+34
+00:01:44,020 --> 00:01:46,530
+There is typically a demo of the deliverable for that
+
+35
+00:01:46,530 --> 00:01:48,810
+sprint. And at that point, the product owner will also
+
+36
+00:01:48,810 --> 00:01:52,610
+discuss the backlogs. And together with the team they will decide
+
+37
+00:01:52,610 --> 00:01:56,230
+what to do next. In the retrospective conversely what happens
+
+38
+00:01:56,230 --> 00:01:59,140
+is there is more focus on the process. So the
+
+39
+00:01:59,140 --> 00:02:02,010
+goal of that part of the meeting is discussing possible
+
+40
+00:02:02,010 --> 00:02:04,850
+process improvements. To identify them
+
+41
+00:02:04,850 --> 00:02:07,140
+and if promising improvements are identified
+
+42
+00:02:07,140 --> 00:02:10,810
+try to plan how to implement those improvements and use them
+
+43
+00:02:10,810 --> 00:02:13,790
+in the next iterations. And something else that might happen at
+
+44
+00:02:13,790 --> 00:02:16,720
+the end of a sprint is that if the product increment
+
+45
+00:02:16,720 --> 00:02:19,210
+is good enough as it reach the state in which it
+
+46
+00:02:19,210 --> 00:02:22,660
+can be actually shipped that will result in a release that
+
+47
+00:02:22,660 --> 00:02:25,730
+is not just internal. To show the product owner the progress
+
+48
+00:02:25,730 --> 00:02:28,510
+that can also be deployed and actually used in production. So
+
+49
+00:02:28,510 --> 00:02:32,650
+one final consideration is that as you can see, XP and scrum
+
+50
+00:02:32,650 --> 00:02:35,340
+are fairly similar, and that's because they're both agile development
+
+51
+00:02:35,340 --> 00:02:37,930
+processes. So the main thing to keep in mind is that
+
+52
+00:02:37,930 --> 00:02:40,620
+they both implement and enforce
+
+53
+00:02:40,620 --> 00:02:44,380
+those ideas, values, practices, and characteristics
+
+54
+00:02:44,380 --> 00:02:47,600
+that we saw when we discussed agile development process in general.
diff --git a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/2 - Cost of Change - lang_en_vs4.srt b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/2 - Cost of Change - lang_en_vs4.srt
new file mode 100644
index 0000000..3b5a261
--- /dev/null
+++ b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/2 - Cost of Change - lang_en_vs4.srt	
@@ -0,0 +1,207 @@
+1
+00:00:00,290 --> 00:00:03,500
+We will start our discussion about test written and development by going
+
+2
+00:00:03,500 --> 00:00:06,790
+back to a softer life cycle to examine a little bit ago
+
+3
+00:00:06,790 --> 00:00:09,460
+which is the waterfall life cycle. And if you remember, that was
+
+4
+00:00:09,460 --> 00:00:12,980
+a totally rigid process in which we were preparing documents and we
+
+5
+00:00:12,980 --> 00:00:16,570
+were not studying any phase before the previous one was finished. And
+
+6
+00:00:16,570 --> 00:00:19,710
+once a phase was finished, we were really going back to it.
+
+7
+00:00:19,710 --> 00:00:22,110
+So today we are going to examine how it is possible to go
+
+8
+00:00:22,110 --> 00:00:25,320
+from such a rigid process to an agile one, in which we can
+
+9
+00:00:25,320 --> 00:00:27,800
+better deal with changes. So remember what we saw in the
+
+10
+00:00:27,800 --> 00:00:31,510
+first lesson when Barry Boehm stated that the cost of change
+
+11
+00:00:31,510 --> 00:00:35,830
+grows exponentially with time. So if we imagine to have time
+
+12
+00:00:35,830 --> 00:00:39,400
+over here on the x-axis and cost on the y-axis, we
+
+13
+00:00:39,400 --> 00:00:41,650
+can see the cost that will go up more or less
+
+14
+00:00:41,650 --> 00:00:44,325
+this way. And what that means is finding a problem while
+
+15
+00:00:44,325 --> 00:00:47,890
+collecting requirements will cost you much less than finding a problem
+
+16
+00:00:47,890 --> 00:00:50,830
+in the analysis phase, which in turn, will cost you less
+
+17
+00:00:50,830 --> 00:00:53,130
+than finding a problem during design, and so on for
+
+18
+00:00:53,130 --> 00:00:56,110
+the subsequent phases. So if this is the case, and cost
+
+19
+00:00:56,110 --> 00:00:59,450
+is really growing this fast as we proceed in our process,
+
+20
+00:00:59,450 --> 00:01:01,530
+what should we do? The key thing is to discover errors
+
+21
+00:01:01,530 --> 00:01:04,700
+early before they become expensive, which in turn means doing a
+
+22
+00:01:04,700 --> 00:01:09,420
+lot of upfront planning. And because models are cheaper to modify
+
+23
+00:01:09,420 --> 00:01:13,150
+in code, we're willing to make large investments in upfront analysis
+
+24
+00:01:13,150 --> 00:01:16,150
+and design models. And only after we have built and checked
+
+25
+00:01:16,150 --> 00:01:18,750
+these models, we're going to go ahead and build the code. In
+
+26
+00:01:18,750 --> 00:01:20,178
+other words, we are following
+
+27
+00:01:20,178 --> 00:01:23,140
+a waterfall mentality. However, something definitely
+
+28
+00:01:23,140 --> 00:01:26,510
+changed in the last 30 years. For example, 30 years ago,
+
+29
+00:01:26,510 --> 00:01:28,770
+we needed to walk down the hall, submit a deck of
+
+30
+00:01:28,770 --> 00:01:31,490
+cards to an operator, and wait a day for our program
+
+31
+00:01:31,490 --> 00:01:34,280
+to run and produce some results. Today we can leverage the
+
+32
+00:01:34,280 --> 00:01:37,820
+computational power of the cloud. Computers used to be very slow
+
+33
+00:01:37,820 --> 00:01:42,322
+and very expensive. Today, computer are a thousand times faster and
+
+34
+00:01:42,322 --> 00:01:44,380
+a thousand times cheaper than what they used to be. In
+
+35
+00:01:44,380 --> 00:01:47,530
+particular, if you think about the compile and test cycle, that has
+
+36
+00:01:47,530 --> 00:01:51,110
+gone from days to seconds. Now we can change our code, compile
+
+37
+00:01:51,110 --> 00:01:54,460
+it, run it our tests, all in a matter of instants, something
+
+38
+00:01:54,460 --> 00:01:57,660
+that was unthinkable before. Finally, developers in the past had to
+
+39
+00:01:57,660 --> 00:02:01,380
+do a lot of tasks manually in a very time-consuming way and
+
+40
+00:02:01,380 --> 00:02:04,220
+often in a very painful way. Today, on the contrary, we can
+
+41
+00:02:04,220 --> 00:02:07,540
+now automate a lot of these tasks. We have high level programming
+
+42
+00:02:07,540 --> 00:02:11,890
+languages, version control systems, smart ideas. Basically a whole set of tools
+
+43
+00:02:11,890 --> 00:02:15,110
+that can help developers. And they can make them more efficient. In
+
+44
+00:02:15,110 --> 00:02:18,440
+general, what that means is, it's easy to change, much easier than
+
+45
+00:02:18,440 --> 00:02:21,310
+what it was before. So maybe if we take all that into account,
+
+46
+00:02:21,310 --> 00:02:23,430
+the cost of change can be flat. So if we go back
+
+47
+00:02:23,430 --> 00:02:26,580
+to our diagram, the one in which we showed the cost with
+
+48
+00:02:26,580 --> 00:02:29,930
+respect to the project time, maybe instead of having this kind of
+
+49
+00:02:29,930 --> 00:02:32,740
+curve, we might have a different kind of curve. Maybe the curve is
+
+50
+00:02:32,740 --> 00:02:36,020
+more like this one. So maybe we can make all of this happen, as long as
+
+51
+00:02:36,020 --> 00:02:38,440
+we use tools, practices and principles in the
+
+52
+00:02:38,440 --> 00:02:40,170
+right way. And we're going to see what that means.
diff --git a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/3 - Agile Software Development - lang_en_vs7.srt b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/3 - Agile Software Development - lang_en_vs7.srt
new file mode 100644
index 0000000..38fe4c3
--- /dev/null
+++ b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/3 - Agile Software Development - lang_en_vs7.srt	
@@ -0,0 +1,159 @@
+1
+00:00:00,150 --> 00:00:03,250
+And assuming that cost is flat that we can really lower that
+
+2
+00:00:03,250 --> 00:00:06,590
+curve then teher are a few interesting consequences. First of all upfront
+
+3
+00:00:06,590 --> 00:00:10,330
+work becomes a liability, we pay for speculative work some of which
+
+4
+00:00:10,330 --> 00:00:13,320
+is likely to be wrong. Some of which we are likely to undo
+
+5
+00:00:13,320 --> 00:00:16,870
+and the reason for ambiguity and volability for example in requirements then
+
+6
+00:00:16,870 --> 00:00:19,310
+it's good to delay We don't want to plan for something that
+
+7
+00:00:19,310 --> 00:00:22,380
+might never happen, to invest resources in something that we might have
+
+8
+00:00:22,380 --> 00:00:25,170
+to throw away later on. In general, if cost is flat it is
+
+9
+00:00:25,170 --> 00:00:28,820
+cost effective to delay all decisions until the last possible
+
+10
+00:00:28,820 --> 00:00:30,990
+moment and only pay for what we use, so to
+
+11
+00:00:30,990 --> 00:00:34,550
+speak. In other words, there is value in waiting, time
+
+12
+00:00:34,550 --> 00:00:37,810
+answers questions and removes uncertainty. And we want to take advantage
+
+13
+00:00:37,810 --> 00:00:40,610
+of that. This and other considerations led to the birth
+
+14
+00:00:40,610 --> 00:00:44,590
+of Agile Softer Development. Specifically for those of you who are
+
+15
+00:00:44,590 --> 00:00:47,200
+interested in a little bit of history. In February 2001
+
+16
+00:00:47,200 --> 00:00:50,430
+a group of software developers, 17 of them, met to discuss
+
+17
+00:00:50,430 --> 00:00:53,950
+lightweight development methods and published Manifesto for Agile
+
+18
+00:00:53,950 --> 00:00:57,630
+Software Developement. Which introduces and defines the concept of
+
+19
+00:00:57,630 --> 00:01:00,990
+agile software development, or agile methods. In a
+
+20
+00:01:00,990 --> 00:01:03,770
+nutshell, agile methods aim at flat cost and a
+
+21
+00:01:03,770 --> 00:01:06,190
+decrease in traditional overhead by following a set
+
+22
+00:01:06,190 --> 00:01:09,400
+of important principles. Our first principle is to focus
+
+23
+00:01:09,400 --> 00:01:11,700
+on the code, rather than the design, to avoid
+
+24
+00:01:11,700 --> 00:01:16,080
+unnecessary changes. Another principle is to focus on people,
+
+25
+00:01:16,080 --> 00:01:20,100
+value people over process, and make sure to reward people.
+
+26
+00:01:20,100 --> 00:01:22,990
+In addition agile methods are all based on iterative approaches to
+
+27
+00:01:22,990 --> 00:01:26,310
+software development, to deliver working software quickly, and to be
+
+28
+00:01:26,310 --> 00:01:29,230
+evolve it Just as quickly based on feedback. And feedback can
+
+29
+00:01:29,230 --> 00:01:31,740
+come from many sources, in particular, it'll come from the
+
+30
+00:01:31,740 --> 00:01:34,500
+customer, it'll be customer feedback. And to be able to do
+
+31
+00:01:34,500 --> 00:01:38,040
+so, agile methods need to involve the customer throughout the development
+
+32
+00:01:38,040 --> 00:01:41,260
+process. Finally, there are two more principles I want to mention.
+
+33
+00:01:41,260 --> 00:01:43,620
+Which are cornerstones of agile methods. The first
+
+34
+00:01:43,620 --> 00:01:46,520
+one is the expectation that requirements will change, and
+
+35
+00:01:46,520 --> 00:01:48,010
+therefore, we need to be able to handle some
+
+36
+00:01:48,010 --> 00:01:50,570
+changes. We can't count on the requirements to be
+
+37
+00:01:50,570 --> 00:01:52,890
+still and unmutable. And the last principle is
+
+38
+00:01:52,890 --> 00:01:56,430
+the mentality of simplicity. Simple design and simple code
+
+39
+00:01:56,430 --> 00:01:58,810
+and so on. But be careful, because simple does
+
+40
+00:01:58,810 --> 00:02:02,060
+not mean inadequate, but rather, as simple as possible.
diff --git a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/4 - Extreme Programming (XP) - lang_en_vs4.srt b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/4 - Extreme Programming (XP) - lang_en_vs4.srt
new file mode 100644
index 0000000..62cc2fa
--- /dev/null
+++ b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/4 - Extreme Programming (XP) - lang_en_vs4.srt	
@@ -0,0 +1,179 @@
+1
+00:00:00,100 --> 00:00:02,490
+So now let's talk about a specific agile method, which
+
+2
+00:00:02,490 --> 00:00:05,850
+is also one of the first ones, extreme programming, also called
+
+3
+00:00:05,850 --> 00:00:08,430
+XP. And to introduce XP, I'm going to start with
+
+4
+00:00:08,430 --> 00:00:12,520
+a quote. The quote says XP is a lightweight methodology for
+
+5
+00:00:12,520 --> 00:00:16,180
+small to medium sized teams developing software in the face
+
+6
+00:00:16,180 --> 00:00:19,770
+of vague or rapidly-changing requirements. And this is a quote from
+
+7
+00:00:19,770 --> 00:00:23,010
+Kent Beck the American Software Engineer that created extreme programming.
+
+8
+00:00:23,010 --> 00:00:25,630
+And by the way Beck was one of the original 17
+
+9
+00:00:25,630 --> 00:00:29,570
+developers who signed the manifesto in 2001. And as you can see
+
+10
+00:00:29,570 --> 00:00:31,940
+we are still talking about the methodology. So we are not just
+
+11
+00:00:31,940 --> 00:00:35,760
+talking about going out and just start writing software. There are principles.
+
+12
+00:00:35,760 --> 00:00:38,130
+And there are practices that we need to follow, but we're going
+
+13
+00:00:38,130 --> 00:00:40,330
+to do it in a much more agile, and a much more
+
+14
+00:00:40,330 --> 00:00:43,720
+flexible ways than we did for our software processes. And also note
+
+15
+00:00:43,720 --> 00:00:45,340
+that the vague and rapidly changing
+
+16
+00:00:45,340 --> 00:00:47,190
+requirements are explicitly mentioned, because this
+
+17
+00:00:47,190 --> 00:00:51,130
+is really one of the important parts about all of this agile methodologies.
+
+18
+00:00:51,130 --> 00:00:54,780
+so what is XP? XP is a. Lightweight. Humanistic.
+
+19
+00:00:54,780 --> 00:00:58,250
+Discipline. Of software development. It is lightweight because it doesn't
+
+20
+00:00:58,250 --> 00:01:02,190
+overburden the developers with an invasive process. So process
+
+21
+00:01:02,190 --> 00:01:04,510
+is kept to a minimum. It's humanistic because as we
+
+22
+00:01:04,510 --> 00:01:07,760
+said, it's centered on people. People, developers, customers, are
+
+23
+00:01:07,760 --> 00:01:10,520
+at the center of the process. It's a discipline, as
+
+24
+00:01:10,520 --> 00:01:12,870
+we said, it includes practices that we to Follow.
+
+25
+00:01:12,870 --> 00:01:16,470
+And finally, is of course about software development. Software development
+
+26
+00:01:16,470 --> 00:01:19,530
+is a key point of the whole method. In XP, developing
+
+27
+00:01:19,530 --> 00:01:22,910
+is like driving, imagine having a road, a wind road, we need
+
+28
+00:01:22,910 --> 00:01:25,110
+to able to drive our car down the road, take the
+
+29
+00:01:25,110 --> 00:01:29,640
+abrupt turns, react promptly to changes, for example obstacles on the road.
+
+30
+00:01:29,640 --> 00:01:32,610
+So, in a nutshell, change is the only constant. Eyes always
+
+31
+00:01:32,610 --> 00:01:34,980
+have to be on the road and it's about steering and not
+
+32
+00:01:34,980 --> 00:01:38,110
+pointing, and XP is trying to do the same thing, while creating
+
+33
+00:01:38,110 --> 00:01:42,190
+softer systems. In XP we need to adopt a mentality of sufficiency,
+
+34
+00:01:42,190 --> 00:01:44,820
+what does that mean? How would you program if you had all
+
+35
+00:01:44,820 --> 00:01:48,010
+the time in the world? No time constraints at all, you will probably
+
+36
+00:01:48,010 --> 00:01:51,090
+write tests instead of skipping them, because there's no more resources. You
+
+37
+00:01:51,090 --> 00:01:53,200
+will probably restructure your code often,
+
+38
+00:01:53,200 --> 00:01:55,210
+because you see opportunities to improve it,
+
+39
+00:01:55,210 --> 00:01:57,300
+and you will take them. And you will probably talk to fellow
+
+40
+00:01:57,300 --> 00:02:00,910
+programmers and with the customer, interact with them, and this is actually the
+
+41
+00:02:00,910 --> 00:02:04,700
+kind of mentality that XP is trying to promote and agile processes
+
+42
+00:02:04,700 --> 00:02:07,760
+in general. And we will see that the following some of the practices
+
+43
+00:02:07,760 --> 00:02:11,250
+that XP is advocating, you can actually achieve these goals and you can
+
+44
+00:02:11,250 --> 00:02:12,840
+actually behave in this way. And the
+
+45
+00:02:12,840 --> 00:02:15,010
+development process is going to benefit overall.
diff --git a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/5 - XP's Values, Principles, and Practices - lang_en_vs4.srt b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/5 - XP's Values, Principles, and Practices - lang_en_vs4.srt
new file mode 100644
index 0000000..d12e73d
--- /dev/null
+++ b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/5 - XP's Values, Principles, and Practices - lang_en_vs4.srt	
@@ -0,0 +1,151 @@
+1
+00:00:00,218 --> 00:00:03,030
+Next I'm going to go over some of the XP's values
+
+2
+00:00:03,030 --> 00:00:05,870
+and principles that I just hinted on earlier in the lesson.
+
+3
+00:00:05,870 --> 00:00:08,820
+The first one, the first important value is communication. There
+
+4
+00:00:08,820 --> 00:00:12,350
+is no good project without good communication. And XP tries to
+
+5
+00:00:12,350 --> 00:00:15,470
+keep the right communication flowing and it uses several practices
+
+6
+00:00:15,470 --> 00:00:18,890
+to do that. It's got practices based on and require information
+
+7
+00:00:18,890 --> 00:00:21,950
+and in general share the information. For example, pair programming.
+
+8
+00:00:21,950 --> 00:00:25,140
+And we're going to say more about that. User stories, customer involvement,
+
+9
+00:00:25,140 --> 00:00:28,240
+all activities that help communication,
+
+10
+00:00:28,240 --> 00:00:30,440
+that faster communication. Another important
+
+11
+00:00:30,440 --> 00:00:33,420
+principle that we already saw, is simplicity. And the motto here
+
+12
+00:00:33,420 --> 00:00:35,680
+is live for today without worrying too much about the
+
+13
+00:00:35,680 --> 00:00:38,230
+future. When you have to do something, look for the simplest
+
+14
+00:00:38,230 --> 00:00:40,580
+thing that works. And the emphasis here is on, that
+
+15
+00:00:40,580 --> 00:00:43,520
+works. We want to build something simple, but not something stupid.
+
+16
+00:00:43,520 --> 00:00:47,090
+Feedback. That's extremely important in XP, and it occurs at
+
+17
+00:00:47,090 --> 00:00:50,560
+different levels, and it is used to drive changes. For example,
+
+18
+00:00:50,560 --> 00:00:53,910
+developers write test cases. And that's immediate feedback. If your test cases
+
+19
+00:00:53,910 --> 00:00:56,140
+fail, there's something wrong with the code. Or there's something that you
+
+20
+00:00:56,140 --> 00:00:59,690
+still haven't developed. Developers also estimate new stories right away as soon
+
+21
+00:00:59,690 --> 00:01:02,060
+as they get them from the customers and that's immediate feedback to
+
+22
+00:01:02,060 --> 00:01:05,515
+the customer. And finally, on a slightly longer time frame, customers and
+
+23
+00:01:05,515 --> 00:01:07,820
+tester develop together functional system test
+
+24
+00:01:07,820 --> 00:01:09,600
+cases to assess the overall system.
+
+25
+00:01:09,600 --> 00:01:12,100
+And also in this case, that's a great way to provide feedback
+
+26
+00:01:12,100 --> 00:01:15,850
+and by the way, also to help communication. And finally, courage, the courage
+
+27
+00:01:15,850 --> 00:01:18,860
+to throw away code if it doesn't work. To change it if you
+
+28
+00:01:18,860 --> 00:01:21,710
+find a way to improve it. To fix it if you find a problem.
+
+29
+00:01:21,710 --> 00:01:24,300
+To try out new things if you think that they might work better
+
+30
+00:01:24,300 --> 00:01:27,410
+than what you have right now. Now, that we can build and test systems
+
+31
+00:01:27,410 --> 00:01:30,150
+very quickly, we can be much braver than what we were before. So
+
+32
+00:01:30,150 --> 00:01:33,790
+how do we accomplish all that? And what are XP's practices that are going to
+
+33
+00:01:33,790 --> 00:01:37,750
+help us follow these principles and adhere to those values? These are some
+
+34
+00:01:37,750 --> 00:01:40,900
+of XP practices. There are more, but those are the ones that I'd like
+
+35
+00:01:40,900 --> 00:01:44,240
+to discuss in a little more depth, individually. Incremental planning,
+
+36
+00:01:44,240 --> 00:01:48,230
+small releases, simple design, test first, refactoring. We will actually
+
+37
+00:01:48,230 --> 00:01:51,680
+have a whole lesson next on refactoring. Pair programming, continuous
+
+38
+00:01:51,680 --> 00:01:55,240
+integration, and on-site customer. So let's start with incremental planning.
diff --git a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/6 - Incremental Planning - lang_en_vs4.srt b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/6 - Incremental Planning - lang_en_vs4.srt
new file mode 100644
index 0000000..faf25db
--- /dev/null
+++ b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/6 - Incremental Planning - lang_en_vs4.srt	
@@ -0,0 +1,71 @@
+1
+00:00:00,140 --> 00:00:03,390
+Incremental planning is based on the idea that requirements are recorded
+
+2
+00:00:03,390 --> 00:00:07,260
+on story cards, sort of use cases or scenarios that the customer
+
+3
+00:00:07,260 --> 00:00:10,450
+provides. So the first step in incremental planning is to select
+
+4
+00:00:10,450 --> 00:00:14,120
+user stories for a given release, and which stories exactly to include
+
+5
+00:00:14,120 --> 00:00:16,975
+depends on the time available and on the priority. For example,
+
+6
+00:00:16,975 --> 00:00:19,147
+scenarios that we might want to realize right away because they are
+
+7
+00:00:19,147 --> 00:00:22,110
+particular important for the customer. After we select user stories for
+
+8
+00:00:22,110 --> 00:00:25,200
+the release, we break stories i to tasks. So what we do,
+
+9
+00:00:25,200 --> 00:00:29,260
+we take the user stories and we identify specific development tasks
+
+10
+00:00:29,260 --> 00:00:32,320
+that we need to perform in order to realize these stories. Once
+
+11
+00:00:32,320 --> 00:00:34,780
+we know our tasks, we can plan our release. And at
+
+12
+00:00:34,780 --> 00:00:38,050
+that point, we can develop, integrate and test our code. And of
+
+13
+00:00:38,050 --> 00:00:41,170
+course, this is more kind of an iterative process right here,
+
+14
+00:00:41,170 --> 00:00:44,250
+so we do this many times. When we're ready, when we accomplish
+
+15
+00:00:44,250 --> 00:00:46,990
+all of our tasks, all of our tests pass and we're happy,
+
+16
+00:00:46,990 --> 00:00:50,410
+we release this software. At the point, the released software is evaluated
+
+17
+00:00:50,410 --> 00:00:53,250
+by us, by the customer, and we can reiterate. We can
+
+18
+00:00:53,250 --> 00:00:56,360
+continue the process, select more stories and continue it this way.
diff --git a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/7 - Small Releases - lang_en_vs4.srt b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/7 - Small Releases - lang_en_vs4.srt
new file mode 100644
index 0000000..0437621
--- /dev/null
+++ b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/7 - Small Releases - lang_en_vs4.srt	
@@ -0,0 +1,95 @@
+1
+00:00:00,210 --> 00:00:02,790
+The first practice that we just saw goes together with
+
+2
+00:00:02,790 --> 00:00:06,320
+small releases practice. This idea that instead of having a big
+
+3
+00:00:06,320 --> 00:00:09,390
+release at the end of a long development cycle, we try
+
+4
+00:00:09,390 --> 00:00:12,610
+to release very often. And there are many advantages to small
+
+5
+00:00:12,610 --> 00:00:15,260
+releases and to releasing often. The first one is that
+
+6
+00:00:15,260 --> 00:00:18,980
+we deliver real business value on a very short cycle. And
+
+7
+00:00:18,980 --> 00:00:22,070
+what that means is that we get business value sooner, and
+
+8
+00:00:22,070 --> 00:00:25,550
+that in turn increase our customer confidence and makes the customer
+
+9
+00:00:25,550 --> 00:00:29,040
+more happy. So more releases also mean rapid feedback. We
+
+10
+00:00:29,040 --> 00:00:32,420
+release the software soon, we get feedback from the customer soon,
+
+11
+00:00:32,420 --> 00:00:34,710
+and we can in this way do exactly what we
+
+12
+00:00:34,710 --> 00:00:38,510
+were saying before, steer instead of driving, adapt weekly to possible
+
+13
+00:00:38,510 --> 00:00:41,680
+changes in the requirements. We avoid working for six months
+
+14
+00:00:41,680 --> 00:00:43,970
+on a project and find out six months later that the
+
+15
+00:00:43,970 --> 00:00:46,950
+customer wanted something else and we got the wrong requirements. In
+
+16
+00:00:46,950 --> 00:00:50,610
+addition having small releases, so seeing your product deployed and released
+
+17
+00:00:50,610 --> 00:00:54,040
+soon produces a sense of accomplishment for the developers.
+
+18
+00:00:54,040 --> 00:00:57,000
+And in addition, it also reduces risk because again,
+
+19
+00:00:57,000 --> 00:00:58,640
+if we're going down the wrong path, we will
+
+20
+00:00:58,640 --> 00:01:00,730
+know right away. If we're late, we will know right
+
+21
+00:01:00,730 --> 00:01:03,370
+away. So these are just additional advantages of having
+
+22
+00:01:03,370 --> 00:01:06,140
+this quick cycle and more releases. And finally, as we
+
+23
+00:01:06,140 --> 00:01:09,130
+also said before, we can quickly adapt in the
+
+24
+00:01:09,130 --> 00:01:12,540
+case our requirements change our code to the new requirements.
diff --git a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/8 - Simple Design - lang_en_vs4.srt b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/8 - Simple Design - lang_en_vs4.srt
new file mode 100644
index 0000000..3a8962c
--- /dev/null
+++ b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/8 - Simple Design - lang_en_vs4.srt	
@@ -0,0 +1,63 @@
+1
+00:00:00,160 --> 00:00:02,790
+The next practice is simple design. We want to avoid
+
+2
+00:00:02,790 --> 00:00:07,330
+creating a huge complicated possibly cumbersome design at the beginning of
+
+3
+00:00:07,330 --> 00:00:09,730
+the project. What we want to have instead is just
+
+4
+00:00:09,730 --> 00:00:14,580
+enough design to meet the requirements, so no duplicated functionality, fewest
+
+5
+00:00:14,580 --> 00:00:17,910
+possible classes and methods in general, just the amount of
+
+6
+00:00:17,910 --> 00:00:20,860
+design that we need to get our system to work. So
+
+7
+00:00:20,860 --> 00:00:23,012
+one might object that to for designing that way we
+
+8
+00:00:23,012 --> 00:00:25,210
+will have to change the code a lot, we will need
+
+9
+00:00:25,210 --> 00:00:27,300
+to adapt the design as the code evolves,
+
+10
+00:00:27,300 --> 00:00:29,180
+and that's exactly the point. That's what we will
+
+11
+00:00:29,180 --> 00:00:31,670
+do. XP is all about changing and adapting,
+
+12
+00:00:31,670 --> 00:00:34,850
+changing your design, changing your code, refactoring. And with
+
+13
+00:00:34,850 --> 00:00:37,420
+the fact that we have test cases throughout
+
+14
+00:00:37,420 --> 00:00:39,770
+the development process, we can do that with confidence.
+
+15
+00:00:39,770 --> 00:00:41,220
+Because if we break something we will know
+
+16
+00:00:41,220 --> 00:00:43,590
+right away, which leads us to the next practice.
diff --git a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/9 - Test First Development - lang_en_vs4.srt b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/9 - Test First Development - lang_en_vs4.srt
new file mode 100644
index 0000000..b2a461b
--- /dev/null
+++ b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/9 - Test First Development - lang_en_vs4.srt	
@@ -0,0 +1,59 @@
+1
+00:00:00,040 --> 00:00:03,610
+Which is test-first development. The key idea is that any program
+
+2
+00:00:03,610 --> 00:00:07,210
+feature that doesn't have an automatic test simply does not exist. If
+
+3
+00:00:07,210 --> 00:00:09,430
+there is a feature, you need to write a test for the
+
+4
+00:00:09,430 --> 00:00:13,630
+feature before. So, what developers do is to create unit tests for
+
+5
+00:00:13,630 --> 00:00:17,420
+each such piece of functionality even before the functionality is implemented.
+
+6
+00:00:17,420 --> 00:00:19,720
+And of course, when you run this test, they will fail. But
+
+7
+00:00:19,720 --> 00:00:22,190
+the beauty of it is that, as you write your code and
+
+8
+00:00:22,190 --> 00:00:25,680
+you add more and more fractionality to the feature that you're developing,
+
+9
+00:00:25,680 --> 00:00:27,820
+these test cases are going to start to pass.
+
+10
+00:00:27,820 --> 00:00:30,190
+And that's extremely rewarding because it gives you immediate
+
+11
+00:00:30,190 --> 00:00:32,530
+feedback, again feedback on the fact that you're
+
+12
+00:00:32,530 --> 00:00:34,530
+developing the code in the right way. As soon
+
+13
+00:00:34,530 --> 00:00:37,000
+as you write it, you will know. And if you write a piece of code and the
+
+14
+00:00:37,000 --> 00:00:38,550
+test says still fail, that means that the
+
+15
+00:00:38,550 --> 00:00:40,140
+code is not doing what it's supposed to do.
diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/1 - Lesson Overview - lang_en_vs4.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/1 - Lesson Overview - lang_en_vs4.srt
new file mode 100644
index 0000000..bab48c0
--- /dev/null
+++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/1 - Lesson Overview - lang_en_vs4.srt	
@@ -0,0 +1,71 @@
+1
+00:00:00,140 --> 00:00:02,220
+In the previous lesson, we discussed agile
+
+2
+00:00:02,220 --> 00:00:05,689
+software development. Its principles and practices. And two
+
+3
+00:00:05,689 --> 00:00:10,060
+specific agile processes. XP and Scrub. In
+
+4
+00:00:10,060 --> 00:00:12,230
+this lesson, we will introduce a practice that
+
+5
+00:00:12,230 --> 00:00:15,020
+is of fundamental importance in the context
+
+6
+00:00:15,020 --> 00:00:20,120
+of agile software development. Software refactoring. Software refactoring
+
+7
+00:00:20,120 --> 00:00:22,030
+is the process of taking a program and
+
+8
+00:00:22,030 --> 00:00:25,040
+transforming it to make it better. That is,
+
+9
+00:00:25,040 --> 00:00:27,240
+to make it easier to understand, make it
+
+10
+00:00:27,240 --> 00:00:29,880
+more maintainable, and in general to improve its
+
+11
+00:00:29,880 --> 00:00:34,300
+design. Specifically, we will discuss what the refactoring
+
+12
+00:00:34,300 --> 00:00:37,680
+is and why it is important? When to perform
+
+13
+00:00:37,680 --> 00:00:40,980
+refactoring, and when not to perform refactoring? And
+
+14
+00:00:40,980 --> 00:00:44,520
+how to perform refactoring in a fully automated way,
+
+15
+00:00:44,520 --> 00:00:47,293
+using tools. We will also introduce the concept
+
+16
+00:00:47,293 --> 00:00:50,040
+of bad smells, where a bad smell, in software,
+
+17
+00:00:50,040 --> 00:00:53,323
+is the indication that there might be something wrong with
+
+18
+00:00:53,323 --> 00:00:56,890
+the code that might call for the application of refactoring.
diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/10 - Consolidate Conditional Expression Solution - lang_en_vs3.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/10 - Consolidate Conditional Expression Solution - lang_en_vs3.srt
new file mode 100644
index 0000000..89f2722
--- /dev/null
+++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/10 - Consolidate Conditional Expression Solution - lang_en_vs3.srt	
@@ -0,0 +1,55 @@
+1
+00:00:00,080 --> 00:00:03,230
+So the resulting code will be like this. As you can see here,
+
+2
+00:00:03,230 --> 00:00:06,602
+now I don't have the conditionals any longer, but I just have a call to
+
+3
+00:00:06,602 --> 00:00:09,938
+this notEligibleForDisability method. And this makes the code so
+
+4
+00:00:09,938 --> 00:00:14,092
+much clearer, because if I just need to understand how disabilityAmount works,
+
+5
+00:00:14,092 --> 00:00:17,945
+I can clearly see there is an initial check that is actually checking whether
+
+6
+00:00:17,945 --> 00:00:22,030
+an employee's eligible for disabilities or not. And if the check is false, so
+
+7
+00:00:22,030 --> 00:00:26,180
+if the employee's eligible, then I'll just perform the rest of the computation.
+
+8
+00:00:26,180 --> 00:00:27,710
+Otherwise I'll simply return zero.
+
+9
+00:00:27,710 --> 00:00:30,500
+So if I don't need to understand the details of this check,
+
+10
+00:00:30,500 --> 00:00:33,630
+I can simply look at this method and understand it all. And if I need to look at
+
+11
+00:00:33,630 --> 00:00:36,990
+the details I can just go, and look at the implementation of this method,
+
+12
+00:00:36,990 --> 00:00:39,600
+and I will get exactly the same information that I have here. But I'm sort of
+
+13
+00:00:39,600 --> 00:00:43,220
+separating the concerns, and making the code overall more understandable, and
+
+14
+00:00:43,220 --> 00:00:46,160
+therefore more maintainable, which is the main goal of refactoring.
diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/11 - Decompose Conditionals - lang_en-us_vs2.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/11 - Decompose Conditionals - lang_en-us_vs2.srt
new file mode 100644
index 0000000..ef89eb8
--- /dev/null
+++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/11 - Decompose Conditionals - lang_en-us_vs2.srt	
@@ -0,0 +1,263 @@
+1
+00:00:00,080 --> 00:00:02,740
+Let's now see a related refactoring, which is the
+
+2
+00:00:02,740 --> 00:00:06,200
+decompose conditional refactoring. What happens here is that in some
+
+3
+00:00:06,200 --> 00:00:08,980
+cases, the complexity of the conditional logic in a program
+
+4
+00:00:08,980 --> 00:00:12,040
+can make a method hard to read and understand. Specifically
+
+5
+00:00:12,040 --> 00:00:15,760
+we might have one or more particularly complex conditional
+
+6
+00:00:15,760 --> 00:00:18,580
+statements. And similar to what we discussed for the previous
+
+7
+00:00:18,580 --> 00:00:21,630
+refactoring, the conditional, if it's too complex, might tell you
+
+8
+00:00:21,630 --> 00:00:25,170
+what happens, but obscure why it happens. To address this
+
+9
+00:00:25,170 --> 00:00:27,520
+issue, you can do a similar thing to what we did in
+
+10
+00:00:27,520 --> 00:00:31,800
+the previous refactoring. You can transform the condition into a method and then
+
+11
+00:00:31,800 --> 00:00:35,260
+replace the condition with a call to that method. And if you give
+
+12
+00:00:35,260 --> 00:00:37,930
+the right name to the method, as we saw in the last example,
+
+13
+00:00:37,930 --> 00:00:41,730
+that can make the code much clearer and much easier to understand. In
+
+14
+00:00:41,730 --> 00:00:44,360
+addition here you can also do something else. Let's assume that those are
+
+15
+00:00:44,360 --> 00:00:47,430
+the then and else part of the conditional are complex. We can do
+
+16
+00:00:47,430 --> 00:00:50,180
+the same thing with them. So what we can do, we can modify
+
+17
+00:00:50,180 --> 00:00:53,570
+the then and else part of the conditional by extracting the corresponding
+
+18
+00:00:53,570 --> 00:00:57,070
+code, making also that one into a method, suitably naming the method,
+
+19
+00:00:57,070 --> 00:00:59,930
+and then having the call to the method only in the then
+
+20
+00:00:59,930 --> 00:01:03,540
+and else part of the conditional statement. So let's see how that works
+
+21
+00:01:03,540 --> 00:01:06,940
+with an example. Here we have the matter that computes some charge.
+
+22
+00:01:06,940 --> 00:01:10,350
+And it computes the charge based on some corrective uses of the date
+
+23
+00:01:10,350 --> 00:01:12,930
+that is provided as input, or it's imagined or is just, you
+
+24
+00:01:12,930 --> 00:01:15,410
+know, one of the fields in the class. So as you can see,
+
+25
+00:01:15,410 --> 00:01:18,140
+there is a conditional here that checks that if the
+
+26
+00:01:18,140 --> 00:01:21,535
+dates is before the beginning of the summer, so before summer
+
+27
+00:01:21,535 --> 00:01:25,180
+start. Or it's after the summer end. Then it compute
+
+28
+00:01:25,180 --> 00:01:29,152
+the charge using some winterRate. Otherwise, if we are in the
+
+29
+00:01:29,152 --> 00:01:32,288
+summer, it will compute the quantity, the charge using a
+
+30
+00:01:32,288 --> 00:01:35,440
+summerRate. And this is just a small example, so it might
+
+31
+00:01:35,440 --> 00:01:37,990
+not look that complex. But, you know, just project this on
+
+32
+00:01:37,990 --> 00:01:40,458
+more realistic code, on larger code. You can end up with
+
+33
+00:01:40,458 --> 00:01:43,656
+the conditions that are hard to understand. And even in this case, even
+
+34
+00:01:43,656 --> 00:01:45,944
+such a small piece of code, you have to kind of look at
+
+35
+00:01:45,944 --> 00:01:48,752
+the conditionals, figure out what does it mean for the date to be
+
+36
+00:01:48,752 --> 00:01:51,800
+before the summer start and after the summer end. We can make this much
+
+37
+00:01:51,800 --> 00:01:54,780
+clearer. So, how can we do it? By applying this refactoring as we
+
+38
+00:01:54,780 --> 00:01:56,190
+described. Let's see what happens when
+
+39
+00:01:56,190 --> 00:01:58,380
+I apply the decompose conditionals refactoring to
+
+40
+00:01:58,380 --> 00:02:01,530
+this method. The first thing I will do is to take this condition,
+
+41
+00:02:01,530 --> 00:02:05,640
+create a method that perform exactly the same check, give it a meaningful name.
+
+42
+00:02:05,640 --> 00:02:09,380
+In this case I called it notSummer, which is pretty self-explanatory, and then
+
+43
+00:02:09,380 --> 00:02:12,340
+replacing the condition with a call to that matter. As you can see
+
+44
+00:02:12,340 --> 00:02:15,230
+here, there's a clear improvement in the code, because here I just need
+
+45
+00:02:15,230 --> 00:02:17,810
+to look at this statement and I see right away that the check. What
+
+46
+00:02:17,810 --> 00:02:20,680
+the check is doing is just checking whether the date is in the
+
+47
+00:02:20,680 --> 00:02:24,320
+summer or not. So, much easier than having to interpret this condition. And
+
+48
+00:02:24,320 --> 00:02:26,910
+the second thing I do is to take the code that computes the
+
+49
+00:02:26,910 --> 00:02:28,600
+charge and also in this case, creating
+
+50
+00:02:28,600 --> 00:02:31,028
+suitable methods that compute the winterCharge and
+
+51
+00:02:31,028 --> 00:02:34,838
+the summerCharge. And I called them exactly winterCharge and summerCharge which
+
+52
+00:02:34,838 --> 00:02:38,278
+again is self explanatory. And then I replace this computation with
+
+53
+00:02:38,278 --> 00:02:40,710
+a call to that method. So again, when I look at
+
+54
+00:02:40,710 --> 00:02:43,280
+this code, I can clearly see that the charge is computed
+
+55
+00:02:43,280 --> 00:02:46,570
+using some sort of winterCharge calculation and then using some sort
+
+56
+00:02:46,570 --> 00:02:50,490
+of summerCharge calculation. And if I don't want to know how
+
+57
+00:02:50,490 --> 00:02:52,670
+this is exactly computed, that's all I need to know to
+
+58
+00:02:52,670 --> 00:02:56,100
+understand what this method does. Easier and faster than looking at
+
+59
+00:02:56,100 --> 00:02:57,970
+this method and figuring out what it does. And if
+
+60
+00:02:57,970 --> 00:02:59,950
+I need to look at the details, exactly like in the
+
+61
+00:02:59,950 --> 00:03:01,550
+previous case, I can just go and look at the
+
+62
+00:03:01,550 --> 00:03:04,170
+implementation of winterCharge and summerCharge. But I will be looking at
+
+63
+00:03:04,170 --> 00:03:06,980
+that in its specific context. So, without having to understand
+
+64
+00:03:06,980 --> 00:03:09,760
+everything at once. So in this way, you make it clear
+
+65
+00:03:09,760 --> 00:03:12,840
+both why you're doing something, because it is notSummer, and
+
+66
+00:03:12,840 --> 00:03:16,300
+what exactly you're doing. You're computing a winterCharge, or a summerCharge.
diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/11 - Decompose Conditionals - lang_en_vs8.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/11 - Decompose Conditionals - lang_en_vs8.srt
new file mode 100644
index 0000000..ef89eb8
--- /dev/null
+++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/11 - Decompose Conditionals - lang_en_vs8.srt	
@@ -0,0 +1,263 @@
+1
+00:00:00,080 --> 00:00:02,740
+Let's now see a related refactoring, which is the
+
+2
+00:00:02,740 --> 00:00:06,200
+decompose conditional refactoring. What happens here is that in some
+
+3
+00:00:06,200 --> 00:00:08,980
+cases, the complexity of the conditional logic in a program
+
+4
+00:00:08,980 --> 00:00:12,040
+can make a method hard to read and understand. Specifically
+
+5
+00:00:12,040 --> 00:00:15,760
+we might have one or more particularly complex conditional
+
+6
+00:00:15,760 --> 00:00:18,580
+statements. And similar to what we discussed for the previous
+
+7
+00:00:18,580 --> 00:00:21,630
+refactoring, the conditional, if it's too complex, might tell you
+
+8
+00:00:21,630 --> 00:00:25,170
+what happens, but obscure why it happens. To address this
+
+9
+00:00:25,170 --> 00:00:27,520
+issue, you can do a similar thing to what we did in
+
+10
+00:00:27,520 --> 00:00:31,800
+the previous refactoring. You can transform the condition into a method and then
+
+11
+00:00:31,800 --> 00:00:35,260
+replace the condition with a call to that method. And if you give
+
+12
+00:00:35,260 --> 00:00:37,930
+the right name to the method, as we saw in the last example,
+
+13
+00:00:37,930 --> 00:00:41,730
+that can make the code much clearer and much easier to understand. In
+
+14
+00:00:41,730 --> 00:00:44,360
+addition here you can also do something else. Let's assume that those are
+
+15
+00:00:44,360 --> 00:00:47,430
+the then and else part of the conditional are complex. We can do
+
+16
+00:00:47,430 --> 00:00:50,180
+the same thing with them. So what we can do, we can modify
+
+17
+00:00:50,180 --> 00:00:53,570
+the then and else part of the conditional by extracting the corresponding
+
+18
+00:00:53,570 --> 00:00:57,070
+code, making also that one into a method, suitably naming the method,
+
+19
+00:00:57,070 --> 00:00:59,930
+and then having the call to the method only in the then
+
+20
+00:00:59,930 --> 00:01:03,540
+and else part of the conditional statement. So let's see how that works
+
+21
+00:01:03,540 --> 00:01:06,940
+with an example. Here we have the matter that computes some charge.
+
+22
+00:01:06,940 --> 00:01:10,350
+And it computes the charge based on some corrective uses of the date
+
+23
+00:01:10,350 --> 00:01:12,930
+that is provided as input, or it's imagined or is just, you
+
+24
+00:01:12,930 --> 00:01:15,410
+know, one of the fields in the class. So as you can see,
+
+25
+00:01:15,410 --> 00:01:18,140
+there is a conditional here that checks that if the
+
+26
+00:01:18,140 --> 00:01:21,535
+dates is before the beginning of the summer, so before summer
+
+27
+00:01:21,535 --> 00:01:25,180
+start. Or it's after the summer end. Then it compute
+
+28
+00:01:25,180 --> 00:01:29,152
+the charge using some winterRate. Otherwise, if we are in the
+
+29
+00:01:29,152 --> 00:01:32,288
+summer, it will compute the quantity, the charge using a
+
+30
+00:01:32,288 --> 00:01:35,440
+summerRate. And this is just a small example, so it might
+
+31
+00:01:35,440 --> 00:01:37,990
+not look that complex. But, you know, just project this on
+
+32
+00:01:37,990 --> 00:01:40,458
+more realistic code, on larger code. You can end up with
+
+33
+00:01:40,458 --> 00:01:43,656
+the conditions that are hard to understand. And even in this case, even
+
+34
+00:01:43,656 --> 00:01:45,944
+such a small piece of code, you have to kind of look at
+
+35
+00:01:45,944 --> 00:01:48,752
+the conditionals, figure out what does it mean for the date to be
+
+36
+00:01:48,752 --> 00:01:51,800
+before the summer start and after the summer end. We can make this much
+
+37
+00:01:51,800 --> 00:01:54,780
+clearer. So, how can we do it? By applying this refactoring as we
+
+38
+00:01:54,780 --> 00:01:56,190
+described. Let's see what happens when
+
+39
+00:01:56,190 --> 00:01:58,380
+I apply the decompose conditionals refactoring to
+
+40
+00:01:58,380 --> 00:02:01,530
+this method. The first thing I will do is to take this condition,
+
+41
+00:02:01,530 --> 00:02:05,640
+create a method that perform exactly the same check, give it a meaningful name.
+
+42
+00:02:05,640 --> 00:02:09,380
+In this case I called it notSummer, which is pretty self-explanatory, and then
+
+43
+00:02:09,380 --> 00:02:12,340
+replacing the condition with a call to that matter. As you can see
+
+44
+00:02:12,340 --> 00:02:15,230
+here, there's a clear improvement in the code, because here I just need
+
+45
+00:02:15,230 --> 00:02:17,810
+to look at this statement and I see right away that the check. What
+
+46
+00:02:17,810 --> 00:02:20,680
+the check is doing is just checking whether the date is in the
+
+47
+00:02:20,680 --> 00:02:24,320
+summer or not. So, much easier than having to interpret this condition. And
+
+48
+00:02:24,320 --> 00:02:26,910
+the second thing I do is to take the code that computes the
+
+49
+00:02:26,910 --> 00:02:28,600
+charge and also in this case, creating
+
+50
+00:02:28,600 --> 00:02:31,028
+suitable methods that compute the winterCharge and
+
+51
+00:02:31,028 --> 00:02:34,838
+the summerCharge. And I called them exactly winterCharge and summerCharge which
+
+52
+00:02:34,838 --> 00:02:38,278
+again is self explanatory. And then I replace this computation with
+
+53
+00:02:38,278 --> 00:02:40,710
+a call to that method. So again, when I look at
+
+54
+00:02:40,710 --> 00:02:43,280
+this code, I can clearly see that the charge is computed
+
+55
+00:02:43,280 --> 00:02:46,570
+using some sort of winterCharge calculation and then using some sort
+
+56
+00:02:46,570 --> 00:02:50,490
+of summerCharge calculation. And if I don't want to know how
+
+57
+00:02:50,490 --> 00:02:52,670
+this is exactly computed, that's all I need to know to
+
+58
+00:02:52,670 --> 00:02:56,100
+understand what this method does. Easier and faster than looking at
+
+59
+00:02:56,100 --> 00:02:57,970
+this method and figuring out what it does. And if
+
+60
+00:02:57,970 --> 00:02:59,950
+I need to look at the details, exactly like in the
+
+61
+00:02:59,950 --> 00:03:01,550
+previous case, I can just go and look at the
+
+62
+00:03:01,550 --> 00:03:04,170
+implementation of winterCharge and summerCharge. But I will be looking at
+
+63
+00:03:04,170 --> 00:03:06,980
+that in its specific context. So, without having to understand
+
+64
+00:03:06,980 --> 00:03:09,760
+everything at once. So in this way, you make it clear
+
+65
+00:03:09,760 --> 00:03:12,840
+both why you're doing something, because it is notSummer, and
+
+66
+00:03:12,840 --> 00:03:16,300
+what exactly you're doing. You're computing a winterCharge, or a summerCharge.
diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/12 - Extract Class - lang_en_vs4.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/12 - Extract Class - lang_en_vs4.srt
new file mode 100644
index 0000000..07c93ed
--- /dev/null
+++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/12 - Extract Class - lang_en_vs4.srt	
@@ -0,0 +1,99 @@
+1
+00:00:00,100 --> 00:00:02,890
+We are now going to talk about the extract class refactoring. When a
+
+2
+00:00:02,890 --> 00:00:06,040
+softer system evolves, we might end up with classes that really do the
+
+3
+00:00:06,040 --> 00:00:09,210
+work of more than one class because we keep adding functionality to
+
+4
+00:00:09,210 --> 00:00:11,010
+the class. Therefore also they're too
+
+5
+00:00:11,010 --> 00:00:13,160
+big, too complicated. In particular, we might
+
+6
+00:00:13,160 --> 00:00:15,250
+end up with a class that is doing the work of two
+
+7
+00:00:15,250 --> 00:00:18,890
+classes. Typical examples are classes with many methods and quite a lot of
+
+8
+00:00:18,890 --> 00:00:22,520
+data, quite a lot of fields. In this case, it's normally good idea
+
+9
+00:00:22,520 --> 00:00:25,120
+to split the class into two, so what you will do, you will
+
+10
+00:00:25,120 --> 00:00:28,700
+create a new class and move there the relevant fields and methods from
+
+11
+00:00:28,700 --> 00:00:31,700
+the original class. So as to have two classes, each one implementing a
+
+12
+00:00:31,700 --> 00:00:34,900
+piece of the functionality. Let's look at an example. In this case we're
+
+13
+00:00:34,900 --> 00:00:38,850
+going to use a UML like representation for the class. We have this class Person
+
+14
+00:00:38,850 --> 00:00:41,769
+that ends up representing also a phone number. And imagine that we add
+
+15
+00:00:41,769 --> 00:00:44,500
+up these pieces, you know, a little bit at the time so we end
+
+16
+00:00:44,500 --> 00:00:47,430
+up with something that really is doing the job of the person and
+
+17
+00:00:47,430 --> 00:00:50,490
+of the phone number. So what we can do, we can actually do exactly
+
+18
+00:00:50,490 --> 00:00:52,650
+what we described here. We split this class
+
+19
+00:00:52,650 --> 00:00:55,470
+into a Person class, and the Phone Number class.
+
+20
+00:00:55,470 --> 00:00:57,440
+And then we establish a use relation, so we
+
+21
+00:00:57,440 --> 00:00:59,470
+have a reference of the phone number class into
+
+22
+00:00:59,470 --> 00:01:01,960
+this class. And by separating the telephone number behavior
+
+23
+00:01:01,960 --> 00:01:04,680
+into its own class, I once more improved the
+
+24
+00:01:04,680 --> 00:01:06,980
+structure of the code, because now I have classes
+
+25
+00:01:06,980 --> 00:01:09,070
+that are more cohesive, and do exactly one thing.
diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/13 - Inline Class - lang_en_vs4.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/13 - Inline Class - lang_en_vs4.srt
new file mode 100644
index 0000000..a7f7f2f
--- /dev/null
+++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/13 - Inline Class - lang_en_vs4.srt	
@@ -0,0 +1,75 @@
+1
+00:00:00,150 --> 00:00:03,825
+This new refactoring called inline class is the reverse of the extract class
+
+2
+00:00:03,825 --> 00:00:06,700
+refactoring. And know that this is kind of a general situation in the
+
+3
+00:00:06,700 --> 00:00:09,500
+sense that it is often the case that the refactoring also has a
+
+4
+00:00:09,500 --> 00:00:11,480
+reverse refactoring that does exactly the
+
+5
+00:00:11,480 --> 00:00:13,202
+opposite. So basically, un-dos, in a sense,
+
+6
+00:00:13,202 --> 00:00:16,830
+the operation of the other refactoring. In this case, the motivation for the
+
+7
+00:00:16,830 --> 00:00:19,760
+refactoring is that during system evolution, we might end up with one or
+
+8
+00:00:19,760 --> 00:00:22,530
+more classes that do not do much. In this case what you want
+
+9
+00:00:22,530 --> 00:00:25,350
+to do is to take the class that is not doing that much and
+
+10
+00:00:25,350 --> 00:00:28,740
+move its features into another class. And then delete the original class.
+
+11
+00:00:28,740 --> 00:00:31,010
+So lets use an example similar to the one we've used for
+
+12
+00:00:31,010 --> 00:00:34,000
+the previous refactoring to illustrate how this works. Here we have in
+
+13
+00:00:34,000 --> 00:00:37,750
+this case, two classes, person and office. And the person class is
+
+14
+00:00:37,750 --> 00:00:40,720
+using the office class, but this latter class, the office class, only
+
+15
+00:00:40,720 --> 00:00:44,000
+contains a phone number. So it doesn't really do that much. What
+
+16
+00:00:44,000 --> 00:00:47,020
+we can do is therefore to fold the office class into the
+
+17
+00:00:47,020 --> 00:00:50,470
+person class, by simply moving its only field into the class. And so
+
+18
+00:00:50,470 --> 00:00:53,260
+the result will be this person class that also contains the information
+
+19
+00:00:53,260 --> 00:00:56,600
+about the office number, and overall a simpler design for the code.
diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/14 - Extract Method - lang_en_vs4.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/14 - Extract Method - lang_en_vs4.srt
new file mode 100644
index 0000000..88769e0
--- /dev/null
+++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/14 - Extract Method - lang_en_vs4.srt	
@@ -0,0 +1,163 @@
+1
+00:00:00,060 --> 00:00:02,406
+The next re-factoring which is also the last one that we'll
+
+2
+00:00:02,406 --> 00:00:05,640
+see, extract method is one of the most commonly used re-factoring. As
+
+3
+00:00:05,640 --> 00:00:09,080
+it is applicable in many, many situations. The starting point is
+
+4
+00:00:09,080 --> 00:00:12,720
+a method that is too long and contains cohesive code fragments, that
+
+5
+00:00:12,720 --> 00:00:16,180
+really serve a single very specific purpose. So we start from
+
+6
+00:00:16,180 --> 00:00:19,270
+a cohesive code fragment in a large method. What we can do
+
+7
+00:00:19,270 --> 00:00:22,370
+in this case, is to create a method using that code fragment.
+
+8
+00:00:22,370 --> 00:00:25,620
+And then replacing the code fragment with a call to that method.
+
+9
+00:00:25,620 --> 00:00:28,390
+Let's look at this with an example. Here over this method called
+
+10
+00:00:28,390 --> 00:00:31,070
+print owing, and what it does, imagine that it does a lot
+
+11
+00:00:31,070 --> 00:00:33,850
+of operations here that I'm just not listing, and then it's got
+
+12
+00:00:33,850 --> 00:00:37,620
+a set of print statements. That are just printing a lot of details
+
+13
+00:00:37,620 --> 00:00:41,280
+about the owing information. And then again, a lot of code after
+
+14
+00:00:41,280 --> 00:00:44,270
+that. So what I could do in this case to simplify. The
+
+15
+00:00:44,270 --> 00:00:47,940
+method is to transform this set of statements. They are cohesive in
+
+16
+00:00:47,940 --> 00:00:51,120
+the sense that they do just one thing, they just print these details
+
+17
+00:00:51,120 --> 00:00:53,890
+into a method, and then I had, replace the statements with a
+
+18
+00:00:53,890 --> 00:00:56,740
+call to that method. Which is actually something similar to what we did
+
+19
+00:00:56,740 --> 00:00:59,900
+as part of some the previous re-factoring's. Here I'm showing the result.
+
+20
+00:00:59,900 --> 00:01:02,770
+So here is the method that I extracted. As you can see. It
+
+21
+00:01:02,770 --> 00:01:05,790
+contains the code that was previously here. I give you the meaningful
+
+22
+00:01:05,790 --> 00:01:09,080
+name, I called it printDetails so it's clear what it does. And now
+
+23
+00:01:09,080 --> 00:01:12,820
+the print owning method is simpler. Because I still have the remaining code
+
+24
+00:01:12,820 --> 00:01:17,200
+the one I didn't touch. But now this potentially long list of details.
+
+25
+00:01:17,200 --> 00:01:20,560
+Of prints, of details is not replaced by a single method code.
+
+26
+00:01:20,560 --> 00:01:23,550
+So a gain similar to the previous refactorings that we saw. If
+
+27
+00:01:23,550 --> 00:01:26,370
+we just look at the printing method, it's very easy to figure
+
+28
+00:01:26,370 --> 00:01:29,490
+out what this part does. Oh, print some details. And once more I
+
+29
+00:01:29,490 --> 00:01:33,060
+really want to stress this. If you don't care about how, this
+
+30
+00:01:33,060 --> 00:01:36,350
+is implemented and knowing that this print some details is enough. Then
+
+31
+00:01:36,350 --> 00:01:38,980
+you're done. You don't need to understand anything more. It's clear, it's
+
+32
+00:01:38,980 --> 00:01:42,430
+self explanatory. And if you'll need to look at what print details does,
+
+33
+00:01:42,430 --> 00:01:44,390
+you just go and look at print details. And you look at
+
+34
+00:01:44,390 --> 00:01:47,280
+it in isolation. So it's easier to understand what this does without having
+
+35
+00:01:47,280 --> 00:01:49,640
+to think the rest of the code. So once more the color we
+
+36
+00:01:49,640 --> 00:01:52,740
+factor in is just to improve your design, made the code more readable
+
+37
+00:01:52,740 --> 00:01:56,020
+Make the code more maintainable. And also keep in mind all of these,
+
+38
+00:01:56,020 --> 00:01:59,080
+are kind of small examples. You also always have to think about the
+
+39
+00:01:59,080 --> 00:02:02,560
+effect that this can have on larger codebases. It can really improve a
+
+40
+00:02:02,560 --> 00:02:05,280
+lot. The understandabililty, and maintainability of
+
+41
+00:02:05,280 --> 00:02:07,220
+your code. So in general, it's design.
diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/15 - Refactoring Demo - lang_en_vs4.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/15 - Refactoring Demo - lang_en_vs4.srt
new file mode 100644
index 0000000..0559c88
--- /dev/null
+++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/15 - Refactoring Demo - lang_en_vs4.srt	
@@ -0,0 +1,599 @@
+1
+00:00:00,090 --> 00:00:03,110
+So now we saw, this set of re-factoring's. They're nice, but
+
+2
+00:00:03,110 --> 00:00:06,260
+how can we actually perform re-factoring's? In some cases you'll have to
+
+3
+00:00:06,260 --> 00:00:08,430
+do it by hand. And you'll do it in that case in
+
+4
+00:00:08,430 --> 00:00:10,880
+small steps, so that you can check at every step that you
+
+5
+00:00:10,880 --> 00:00:14,180
+didn't introduce any area. But there's also many cases in which at
+
+6
+00:00:14,180 --> 00:00:17,640
+least for the more standard re-factoring's, you can just apply, you can
+
+7
+00:00:17,640 --> 00:00:21,530
+just use a tool that actually supports re-factoring. I'm going to show
+
+8
+00:00:21,530 --> 00:00:24,550
+you how that works, into a specific ID, Eclipse through a demo.
+
+9
+00:00:26,120 --> 00:00:28,425
+To show you how Eclipse, can help in performing
+
+10
+00:00:28,425 --> 00:00:31,880
+re-factoring, in an automated way, I just opened the Eclipse
+
+11
+00:00:31,880 --> 00:00:35,050
+editor and I maximized it. So that we can look
+
+12
+00:00:35,050 --> 00:00:36,810
+at the code more clearly. And as you can see
+
+13
+00:00:36,810 --> 00:00:39,551
+here, I have this class. It's called Re-factorable, it's a
+
+14
+00:00:39,551 --> 00:00:43,550
+pretty indicative name. And what we're going to do, we're going to
+
+15
+00:00:43,550 --> 00:00:47,840
+try to apply the extract method re-factoring to this class.
+
+16
+00:00:47,840 --> 00:00:51,060
+And in particular, to parts of this print owing method.
+
+17
+00:00:51,060 --> 00:00:54,090
+So this is a matter than will print owing's,
+
+18
+00:00:54,090 --> 00:00:56,160
+as the name says. And it will do several things
+
+19
+00:00:56,160 --> 00:00:59,180
+such as, for example, printing a banner first, then
+
+20
+00:00:59,180 --> 00:01:03,650
+calculating the outstanding debts, and then printing some details. So
+
+21
+00:01:03,650 --> 00:01:06,980
+the starting point for an extract method re-fractoring, is
+
+22
+00:01:06,980 --> 00:01:10,650
+the identification of some cohesive code fragment. And here, for
+
+23
+00:01:10,650 --> 00:01:12,970
+instance, we can see that, if we can see there,
+
+24
+00:01:12,970 --> 00:01:16,350
+these three print statements. They are basically printing some banner,
+
+25
+00:01:16,350 --> 00:01:18,530
+for the method. And I also put a comment here
+
+26
+00:01:18,530 --> 00:01:21,160
+just to make that even more explicit. So this is a
+
+27
+00:01:21,160 --> 00:01:23,970
+perfect case in which we might want to just extract
+
+28
+00:01:23,970 --> 00:01:27,220
+this part, create an independent method, so that we can make
+
+29
+00:01:27,220 --> 00:01:31,410
+the code more readable and maintainable. So I select, the
+
+30
+00:01:31,410 --> 00:01:33,320
+part of the code, that I want to put in my
+
+31
+00:01:33,320 --> 00:01:37,080
+method. I invoke the contextual menu, and as you can see
+
+32
+00:01:37,080 --> 00:01:41,287
+there is a re-factor entry here. Here are some re-factoring's [UNKNOWN],
+
+33
+00:01:41,287 --> 00:01:45,039
+re-factoring's that I can apply, and I'm going to select extract
+
+34
+00:01:45,039 --> 00:01:48,120
+method. When I do that, Eclipse is going to ask me to
+
+35
+00:01:48,120 --> 00:01:51,610
+specify a method name. I'll just call this one print
+
+36
+00:01:51,610 --> 00:01:54,260
+banner. And as you can see, as soon as I do
+
+37
+00:01:54,260 --> 00:01:57,310
+that, Eclipse will show me the preview, for the method
+
+38
+00:01:57,310 --> 00:02:01,010
+that will be generated. I'm going to leave the access modifier. To
+
+39
+00:02:01,010 --> 00:02:03,290
+public and I'm not going to change anything else. So,
+
+40
+00:02:03,290 --> 00:02:07,760
+now when I click Ok. As you can see Eclipse modified
+
+41
+00:02:07,760 --> 00:02:10,669
+my code so that now I have the Print Banner method
+
+42
+00:02:10,669 --> 00:02:14,050
+down here that does exactly what that piece of code was doing
+
+43
+00:02:14,050 --> 00:02:16,090
+before. And I just have an invocation of the Print Banner
+
+44
+00:02:16,090 --> 00:02:19,440
+method, up here, where the code was before. And of course, this
+
+45
+00:02:19,440 --> 00:02:21,830
+is something that we could have done by hand. It's pretty
+
+46
+00:02:21,830 --> 00:02:25,480
+easy to do, but it's even easier, to do it using Eclipse's
+
+47
+00:02:25,480 --> 00:02:29,040
+capabilities. And this will become even more apparent, when we consider slightly
+
+48
+00:02:29,040 --> 00:02:32,866
+more complex case. So here, if we look at this piece of
+
+49
+00:02:32,866 --> 00:02:35,234
+code for instance, we can that see this code
+
+50
+00:02:35,234 --> 00:02:38,264
+prints some details, about the always. And the reason
+
+51
+00:02:38,264 --> 00:02:41,351
+why this case is likely more complicated, is because
+
+52
+00:02:41,351 --> 00:02:45,210
+this code needs to know about the value of outstanding.
+
+53
+00:02:45,210 --> 00:02:49,130
+And whereas that underscore name, is a member of
+
+54
+00:02:49,130 --> 00:02:51,150
+the class, and therefore will be available to the
+
+55
+00:02:51,150 --> 00:02:55,110
+method. Outstanding is a locker variable, so a method
+
+56
+00:02:55,110 --> 00:02:58,310
+different from print, oh it wouldn't know anything about outstanding.
+
+57
+00:02:58,310 --> 00:03:00,070
+So let's see what happens when we try to apply
+
+58
+00:03:00,070 --> 00:03:03,460
+a re-factoring for this code. So we go again here
+
+59
+00:03:03,460 --> 00:03:06,410
+to the re-factor menu, we select extract method, we will
+
+60
+00:03:06,410 --> 00:03:10,080
+pick a name again. So let's call it [SOUND] print details,
+
+61
+00:03:10,080 --> 00:03:12,660
+since this is what the code does. And as you
+
+62
+00:03:12,660 --> 00:03:17,270
+can see here, Eclipse was able to figure out, that outstanding
+
+63
+00:03:17,270 --> 00:03:20,290
+has to be a parameter, of this method. So if
+
+64
+00:03:20,290 --> 00:03:23,340
+you look at the signature here, this will be very clear.
+
+65
+00:03:23,340 --> 00:03:26,270
+So outstanding has to be passed to the matter because
+
+66
+00:03:26,270 --> 00:03:29,230
+it's a locker variable of the print owing method. so
+
+67
+00:03:29,230 --> 00:03:32,600
+it will not be visible to the other methods otherwise.
+
+68
+00:03:32,600 --> 00:03:34,990
+So since eclipse figured it out, all I have to do,
+
+69
+00:03:34,990 --> 00:03:37,630
+is to press Ok. And at this point what I
+
+70
+00:03:37,630 --> 00:03:41,280
+will have here is my new method, for in details
+
+71
+00:03:41,280 --> 00:03:45,140
+that takes outstanding as a parameter. And does exactly what
+
+72
+00:03:45,140 --> 00:03:48,880
+the code was doing before. And here, where the code was,
+
+73
+00:03:48,880 --> 00:03:51,630
+I will have my print details invocation, with outstanding
+
+74
+00:03:51,630 --> 00:03:54,930
+as a parameter. So now, let's continue to extract methods.
+
+75
+00:03:54,930 --> 00:03:58,470
+And let's look at a even more complex case. which
+
+76
+00:03:58,470 --> 00:04:01,550
+is, the one involving this piece of code. So this
+
+77
+00:04:01,550 --> 00:04:03,900
+piece of code, as you can see, will calculate
+
+78
+00:04:03,900 --> 00:04:07,820
+the value of the outstanding debt. Will calculate the owing's,
+
+79
+00:04:07,820 --> 00:04:09,600
+and the way in which it does that, is by
+
+80
+00:04:09,600 --> 00:04:14,080
+considering all the orders, that are part of this enumeration.
+
+81
+00:04:14,080 --> 00:04:16,519
+That is the declared here, and it will
+
+82
+00:04:16,519 --> 00:04:20,769
+compute for each one, of these orders, the amount,
+
+83
+00:04:20,769 --> 00:04:23,520
+and then added to outstanding. So what is the
+
+84
+00:04:23,520 --> 00:04:26,160
+additional complication here? Well, the additional complication here is
+
+85
+00:04:26,160 --> 00:04:29,520
+that this code needs to know, not only
+
+86
+00:04:29,520 --> 00:04:33,220
+about outstanding. It also needs to know, about this
+
+87
+00:04:33,220 --> 00:04:36,160
+enumeration, because this one is also a local variable.
+
+88
+00:04:36,160 --> 00:04:39,140
+And in addition to that, this code also has
+
+89
+00:04:39,140 --> 00:04:43,280
+some side effects. So outstanding, is modified as a
+
+90
+00:04:43,280 --> 00:04:46,600
+consequence of the execution of this code. So how can
+
+91
+00:04:46,600 --> 00:04:49,120
+we do that in the extracted method? Well lets
+
+92
+00:04:49,120 --> 00:04:51,000
+see what the clips will do and what the clips
+
+93
+00:04:51,000 --> 00:04:53,950
+will suggest. It will try to again re-factor this
+
+94
+00:04:53,950 --> 00:04:58,030
+code and extract the method. In this case as you
+
+95
+00:04:58,030 --> 00:05:01,160
+can see. The clips does two things. First of all,
+
+96
+00:05:01,160 --> 00:05:04,180
+it figures out as before, that there are some parameters,
+
+97
+00:05:04,180 --> 00:05:07,650
+that are needed for this method to operate correctly. The
+
+98
+00:05:07,650 --> 00:05:11,600
+enumeration e, as we said, and the outstanding variable. In
+
+99
+00:05:11,600 --> 00:05:14,880
+addition, if you look at the method signature Eclipse will
+
+100
+00:05:14,880 --> 00:05:17,490
+also figure out that this method has to return, a
+
+101
+00:05:17,490 --> 00:05:21,530
+double value. So what does this value correspond to? This
+
+102
+00:05:21,530 --> 00:05:24,700
+value corresponds to a new value of outstanding. So if
+
+103
+00:05:24,700 --> 00:05:27,490
+we, give a name to this method, so we just
+
+104
+00:05:27,490 --> 00:05:29,620
+use the name, [SOUND] that I put in the comment
+
+105
+00:05:29,620 --> 00:05:33,510
+over there. We click Ok, and this will create
+
+106
+00:05:33,510 --> 00:05:36,560
+a method by extracting the code. And here, where the
+
+107
+00:05:36,560 --> 00:05:39,100
+method used to be, we will have that the
+
+108
+00:05:39,100 --> 00:05:43,169
+value of outstanding is updated. Based on the return value
+
+109
+00:05:43,169 --> 00:05:46,260
+of calculate outstanding. So in the end if we
+
+110
+00:05:46,260 --> 00:05:48,730
+look at this code, you can see that if we
+
+111
+00:05:48,730 --> 00:05:51,980
+just focus, on this code it's very easy to
+
+112
+00:05:51,980 --> 00:05:55,150
+understand what it does. It prints the banner, it calculates
+
+113
+00:05:55,150 --> 00:05:59,180
+an outstanding value, and then it prints some details. And
+
+114
+00:05:59,180 --> 00:06:01,520
+in case we don't care, as I said before, about the
+
+115
+00:06:01,520 --> 00:06:04,840
+details of what these methods do, we're done. And if we
+
+116
+00:06:04,840 --> 00:06:07,740
+care about the details we can look at each matter individually.
+
+117
+00:06:07,740 --> 00:06:10,580
+And get exactly the same information that we got before,
+
+118
+00:06:10,580 --> 00:06:13,650
+in a sort of a separation of concerns kind of way,
+
+119
+00:06:13,650 --> 00:06:16,420
+by focusing on one problem at a time. So now let
+
+120
+00:06:16,420 --> 00:06:19,345
+me do one last thing. So let me modify the code,
+
+121
+00:06:19,345 --> 00:06:23,170
+slightly. So i'm going to go back, to the version of
+
+122
+00:06:23,170 --> 00:06:25,610
+the code before re-factoring. So this is what we had.
+
+123
+00:06:25,610 --> 00:06:32,480
+And I'm going to add, an additional variable here, [SOUND] called count,
+
+124
+00:06:32,480 --> 00:06:38,870
+which I initialize to zero. Here I'm going to increase, [SOUND]
+
+125
+00:06:38,870 --> 00:06:41,360
+the value of count at every iteration. And
+
+126
+00:06:41,360 --> 00:06:44,570
+finally, here I'm going to print out the value
+
+127
+00:06:44,570 --> 00:06:50,130
+of count. Okay, now that I have this code up. So let's imagine that I
+
+128
+00:06:50,130 --> 00:06:55,665
+want to, again as I did before, extract this matter. So, I'm going to
+
+129
+00:06:55,665 --> 00:06:58,430
+give you a second. Have a look at this and see, if you see
+
+130
+00:06:58,430 --> 00:07:02,170
+any problem with that. Feel free to stop the video, if you need more time.
+
+131
+00:07:07,350 --> 00:07:11,440
+So the problem here is that I have two side effects.
+
+132
+00:07:11,440 --> 00:07:14,820
+Both outstanding and count are modified. And therefore it's not really
+
+133
+00:07:14,820 --> 00:07:19,600
+possible to extract this method, and preserve the semantics of this
+
+134
+00:07:19,600 --> 00:07:23,260
+code. Let's see if Eclipse will be able to figure that out.
+
+135
+00:07:26,130 --> 00:07:28,950
+And it does. If we try to extract the matter here,
+
+136
+00:07:28,950 --> 00:07:32,250
+you'll tell us that's an ambiguous return value. The selected block
+
+137
+00:07:32,250 --> 00:07:35,800
+contains more than one assignment to look at variables. And the
+
+138
+00:07:35,800 --> 00:07:40,170
+affected variables are outstanding, just a Double and Count which is
+
+139
+00:07:40,170 --> 00:07:44,780
+an integer. So it will refuse to extract the method. So
+
+140
+00:07:44,780 --> 00:07:46,470
+at this point if we wanted to do that we have
+
+141
+00:07:46,470 --> 00:07:48,650
+we'll have to do the re-factoring a different way, but I
+
+142
+00:07:48,650 --> 00:07:51,110
+don't really want to get there. I want to conclude here,
+
+143
+00:07:51,110 --> 00:07:53,440
+and I hope this this little demo helped you
+
+144
+00:07:53,440 --> 00:07:55,310
+realize how useful it can be to use an
+
+145
+00:07:55,310 --> 00:07:58,270
+id that supports re-factoring that can automate this important
+
+146
+00:07:58,270 --> 00:08:00,160
+task. And I also encourage you to try to play
+
+147
+00:08:00,160 --> 00:08:03,170
+with this, and try to use different re-factoring's, on
+
+148
+00:08:03,170 --> 00:08:05,480
+your code. So as to get familiar with the kind
+
+149
+00:08:05,480 --> 00:08:08,060
+of re-factoring's that are supported by the ID. And
+
+150
+00:08:08,060 --> 00:08:10,800
+also with the re-factoring's themselves and how should be used.
diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/16 - Extract Method Refactoring Quiz - lang_en_vs5.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/16 - Extract Method Refactoring Quiz - lang_en_vs5.srt
new file mode 100644
index 0000000..07f5e44
--- /dev/null
+++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/16 - Extract Method Refactoring Quiz - lang_en_vs5.srt	
@@ -0,0 +1,31 @@
+1
+00:00:00,160 --> 00:00:02,580
+After the demo I would like to have a little quiz
+
+2
+00:00:02,580 --> 00:00:05,430
+about the extract method refactoring. And I would like to ask you
+
+3
+00:00:05,430 --> 00:00:08,910
+when is it appropriate to apply the extract method refactoring. Here I
+
+4
+00:00:08,910 --> 00:00:11,890
+have a set of possible scenarios. First one is when there is
+
+5
+00:00:11,890 --> 00:00:14,730
+duplicated code in two or more methods. When a class is too
+
+6
+00:00:14,730 --> 00:00:17,730
+large. When the names of two classes are too similar. Or when
+
+7
+00:00:17,730 --> 00:00:20,840
+a method is highly coupled with a class other than the one
+
+8
+00:00:20,840 --> 00:00:24,370
+where it is defined. So as usual, please mark all that apply.
diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/17 - Extract Method Refactoring Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/17 - Extract Method Refactoring Quiz Solution - lang_en_vs4.srt
new file mode 100644
index 0000000..6545de0
--- /dev/null
+++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/17 - Extract Method Refactoring Quiz Solution - lang_en_vs4.srt	
@@ -0,0 +1,83 @@
+1
+00:00:00,110 --> 00:00:03,000
+The first scenario is the typical case in which it is
+
+2
+00:00:03,000 --> 00:00:07,040
+recommended to use the extract method refactoring, when there is duplicated code
+
+3
+00:00:07,040 --> 00:00:09,190
+in two or more methods and we want to take this
+
+4
+00:00:09,190 --> 00:00:12,420
+code and factor is out, and basically have the two methods called
+
+5
+00:00:12,420 --> 00:00:14,960
+a third method, which is the one we create using the
+
+6
+00:00:14,960 --> 00:00:18,060
+refactoring. When a class is too large, normally we don't want to
+
+7
+00:00:18,060 --> 00:00:21,330
+apply the extract. Extract method. Instead, in this cases, it is
+
+8
+00:00:21,330 --> 00:00:22,900
+usually more appropriate to use the
+
+9
+00:00:22,900 --> 00:00:26,420
+extract class or extract subclass refactorings.
+
+10
+00:00:26,420 --> 00:00:29,750
+Analogously, when the names of two classes are too similar, extracting a
+
+11
+00:00:29,750 --> 00:00:32,729
+method will normally not help much. And all we need to do
+
+12
+00:00:32,729 --> 00:00:35,810
+in case having too similar names is actually a problem. Is to
+
+13
+00:00:35,810 --> 00:00:39,600
+rename one of the two classes, or both, if we wish. Finally,
+
+14
+00:00:39,600 --> 00:00:42,530
+it is definitely appropriate to apply the extract method of refactoring in
+
+15
+00:00:42,530 --> 00:00:45,900
+cases in which a method is highly coupled with a class other
+
+16
+00:00:45,900 --> 00:00:48,330
+than the one where it is defined. In this case, which we
+
+17
+00:00:48,330 --> 00:00:51,740
+will discuss also later in the lesson, the extract method of refactoring
+
+18
+00:00:51,740 --> 00:00:55,710
+allows us to extract part of the metal to With the other class.
+
+19
+00:00:55,710 --> 00:00:58,690
+Then we can take the matter that we just extracted and move it
+
+20
+00:00:58,690 --> 00:01:01,880
+to the class where it actually belongs. So the extract method is one
+
+21
+00:01:01,880 --> 00:01:05,560
+of the two refactorings that it is appropriate to apply in these cases.
diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/18 - Refactoring Risks - lang_en_vs4.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/18 - Refactoring Risks - lang_en_vs4.srt
new file mode 100644
index 0000000..0aae00c
--- /dev/null
+++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/18 - Refactoring Risks - lang_en_vs4.srt	
@@ -0,0 +1,143 @@
+1
+00:00:00,150 --> 00:00:02,520
+Now that we saw a number of refactorings, we also saw
+
+2
+00:00:02,520 --> 00:00:05,950
+how refactorings can be performed automatically within an ID, I'd like
+
+3
+00:00:05,950 --> 00:00:09,230
+to make you aware of some risks involved with the user
+
+4
+00:00:09,230 --> 00:00:12,510
+refactorings. Refactorings are a very powerful tool, but you also have to
+
+5
+00:00:12,510 --> 00:00:15,820
+be careful, first of all when you do more complex refactorings,
+
+6
+00:00:15,820 --> 00:00:18,540
+you may also introduce subtle faults. What, we don't really call
+
+7
+00:00:18,540 --> 00:00:21,040
+regression errors. You might change something in the class. You might
+
+8
+00:00:21,040 --> 00:00:23,140
+think that that's a behavior preserving
+
+9
+00:00:23,140 --> 00:00:25,200
+transformation when considering the whole code,
+
+10
+00:00:25,200 --> 00:00:27,860
+and instead your change is affecting the behavior of some of the
+
+11
+00:00:27,860 --> 00:00:30,980
+other parts of the code. So, it's introducing a regression that will cause
+
+12
+00:00:30,980 --> 00:00:32,670
+some other functionality, some other piece
+
+13
+00:00:32,670 --> 00:00:34,320
+of functionality some other feature, to
+
+14
+00:00:34,320 --> 00:00:37,190
+work incorrectly. So you always have to be careful, and as we saw
+
+15
+00:00:37,190 --> 00:00:39,750
+at the beginning one way to avoid that is to run tests.
+
+16
+00:00:39,750 --> 00:00:43,080
+Every time you make a refactoring every time you change your code and
+
+17
+00:00:43,080 --> 00:00:46,280
+refactor your code. So is to get the least some confidence in
+
+18
+00:00:46,280 --> 00:00:47,540
+the fact that your refactoring is
+
+19
+00:00:47,540 --> 00:00:50,290
+indeed behavior preserving. Also consider the refactoring
+
+20
+00:00:50,290 --> 00:00:54,680
+should not. Be abused. Refactoring should be performed when it's needed. It's
+
+21
+00:00:54,680 --> 00:00:57,570
+useful to improve the design of your code when you see problems
+
+22
+00:00:57,570 --> 00:00:59,680
+with the design of the code. Shouldn't just be applied for the
+
+23
+00:00:59,680 --> 00:01:02,720
+final code because you can apply, for example, easily within a tool.
+
+24
+00:01:02,720 --> 00:01:06,030
+So be careful not over doing it when you refactor. And for
+
+25
+00:01:06,030 --> 00:01:08,310
+the same reason that we mentioned at the beginning, you should be
+
+26
+00:01:08,310 --> 00:01:10,600
+particularly careful when you're using refactoring
+
+27
+00:01:10,600 --> 00:01:12,290
+for systems that are in production.
+
+28
+00:01:12,290 --> 00:01:15,260
+Because if you introduce a problem, before the system goes in production,
+
+29
+00:01:15,260 --> 00:01:16,750
+then you might be able to catch it earlier,
+
+30
+00:01:16,750 --> 00:01:19,780
+with testing. Or before it's released. But, if you introduce
+
+31
+00:01:19,780 --> 00:01:21,750
+a problem for a system in production, then you have
+
+32
+00:01:21,750 --> 00:01:24,440
+to issue a new version of the code. You'll be
+
+33
+00:01:24,440 --> 00:01:26,860
+affecting, you might be affecting some users, because the code
+
+34
+00:01:26,860 --> 00:01:29,050
+fails on their machine. So, you have to be twice
+
+35
+00:01:29,050 --> 00:01:31,190
+as careful, when you are doing refactoring, when you're changing
+
+36
+00:01:31,190 --> 00:01:33,010
+your code for a system that is already in production.
diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/19 - Cost of Refactoring - lang_en_vs4.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/19 - Cost of Refactoring - lang_en_vs4.srt
new file mode 100644
index 0000000..e09868d
--- /dev/null
+++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/19 - Cost of Refactoring - lang_en_vs4.srt	
@@ -0,0 +1,127 @@
+1
+00:00:00,080 --> 00:00:03,800
+Let's also talk about the cost of refactoring. Refactoring might be
+
+2
+00:00:03,800 --> 00:00:06,750
+free or almost free if you're using a tool to do refactoring
+
+3
+00:00:06,750 --> 00:00:08,570
+as we did in our demo. But that's not always the
+
+4
+00:00:08,570 --> 00:00:12,530
+case. In many cases, refactoring involves quite a bit of manual work
+
+5
+00:00:12,530 --> 00:00:16,309
+if you're doing some manual refactoring. And how much that costs
+
+6
+00:00:16,309 --> 00:00:19,460
+depends on how well the operations on the source code are supported.
+
+7
+00:00:19,460 --> 00:00:22,379
+You might have partial support from an ID. You might have complete
+
+8
+00:00:22,379 --> 00:00:25,017
+support, in which case it's greater. Or you might have no support,
+
+9
+00:00:25,017 --> 00:00:26,879
+in which case you have to be very careful about
+
+10
+00:00:26,879 --> 00:00:28,888
+how you change your code and how you check that you
+
+11
+00:00:28,888 --> 00:00:32,030
+didn't change the behavior of the code. There's also an additional
+
+12
+00:00:32,030 --> 00:00:34,460
+cost associated with refactoring. Remember
+
+13
+00:00:34,460 --> 00:00:36,990
+that refactoring relies heavily on testing
+
+14
+00:00:36,990 --> 00:00:39,808
+after each small step of refactoring. So you might have
+
+15
+00:00:39,808 --> 00:00:43,451
+to develop test cases, specifically to check your refactoring. And even
+
+16
+00:00:43,451 --> 00:00:47,163
+if you have an existing test because, for example, you're working
+
+17
+00:00:47,163 --> 00:00:50,235
+some agile context and therefore you develop a lot of UNIX
+
+18
+00:00:50,235 --> 00:00:53,550
+test cases before writing your code. And therefore you have a good
+
+19
+00:00:53,550 --> 00:00:56,635
+regression test with it you can use every time you modify your code.
+
+20
+00:00:56,635 --> 00:00:59,550
+Nevertheless, when you refactor and you change your code, you might need
+
+21
+00:00:59,550 --> 00:01:03,255
+to update your test so it's not only the development of the test
+
+22
+00:01:03,255 --> 00:01:05,379
+cases but also it's maintaining the test cases. And if you have
+
+23
+00:01:05,379 --> 00:01:07,970
+a lot of test cases, you have to maintain more test cases. So
+
+24
+00:01:07,970 --> 00:01:12,460
+that's a cost that is not directly visible but can affect quite
+
+25
+00:01:12,460 --> 00:01:15,800
+a bit the overall cost of refactoring and the overall cost of system
+
+26
+00:01:15,800 --> 00:01:18,342
+development therefore. And finally, you should not
+
+27
+00:01:18,342 --> 00:01:21,191
+under estimate the cost of documentation maintenance.
+
+28
+00:01:21,191 --> 00:01:24,241
+Applying refactoring may involve changes in interfaces,
+
+29
+00:01:24,241 --> 00:01:26,528
+names, for example, names of classes. And
+
+30
+00:01:26,528 --> 00:01:29,384
+when you make this kind of changes, you might need to update the documentation,
+
+31
+00:01:29,384 --> 00:01:30,890
+and that's also cost. It's something that
+
+32
+00:01:30,890 --> 00:01:32,900
+takes effort and therefore should be considered.
diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/2 - Introduction - lang_en_vs4.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/2 - Introduction - lang_en_vs4.srt
new file mode 100644
index 0000000..a50a2e5
--- /dev/null
+++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/2 - Introduction - lang_en_vs4.srt	
@@ -0,0 +1,127 @@
+1
+00:00:00,090 --> 00:00:02,790
+Let me start this lesson by discussing what is refactoring.
+
+2
+00:00:02,790 --> 00:00:06,590
+Refactoring is the process of applying transformation or refactoring to a
+
+3
+00:00:06,590 --> 00:00:09,320
+program. So as to obtain a refactor program. With an
+
+4
+00:00:09,320 --> 00:00:12,850
+improved design but with same functionality as the original program. So
+
+5
+00:00:12,850 --> 00:00:15,520
+key aspect of refactoring is the fact that refactoring should
+
+6
+00:00:15,520 --> 00:00:18,150
+be somatic to perserving So what is the main goal of
+
+7
+00:00:18,150 --> 00:00:22,030
+refactoring? The goal is to keep the program readable, understandable, and
+
+8
+00:00:22,030 --> 00:00:25,260
+maintainable as we evolve it. And to do this by eliminating
+
+9
+00:00:25,260 --> 00:00:28,530
+small problems soon, so that you can avoid big trouble later. And
+
+10
+00:00:28,530 --> 00:00:31,750
+I want to stress once more a key feature of refactoring, which
+
+11
+00:00:31,750 --> 00:00:34,790
+is the fact that it is behavior per serving. But how can
+
+12
+00:00:34,790 --> 00:00:38,130
+we ensure that the refactoring is behavior per serving? In other words,
+
+13
+00:00:38,130 --> 00:00:40,980
+how can we ensure that the program does the same thing before
+
+14
+00:00:40,980 --> 00:00:43,560
+and after applying a refactoring. So what we would like to do
+
+15
+00:00:43,560 --> 00:00:47,160
+is to have some guarantee that, that happens. And unfortunately in general,
+
+16
+00:00:47,160 --> 00:00:50,360
+there are no guarantees. But something we can do is to test
+
+17
+00:00:50,360 --> 00:00:53,690
+the code. For example, we can write tests that exercise the
+
+18
+00:00:53,690 --> 00:00:56,390
+parts of the program affected by the refactoring, and if we're in
+
+19
+00:00:56,390 --> 00:00:59,430
+a [INAUDIBLE] context, we might already have plenty of test cases
+
+20
+00:00:59,430 --> 00:01:01,914
+that exercise that part of the code. So we might just have
+
+21
+00:01:01,914 --> 00:01:04,780
+to rerun the test cases after the refactoring. And in fact,
+
+22
+00:01:04,780 --> 00:01:07,930
+that's a very advantageous situation, and that's a very good use of
+
+23
+00:01:07,930 --> 00:01:10,970
+existing test cases. And I want to make sure that you remember,
+
+24
+00:01:10,970 --> 00:01:15,500
+and that you beware that tests provide no guarantees. Testing can only
+
+25
+00:01:15,500 --> 00:01:18,990
+show the presence of defects, but cannot demonstrate their absence.
+
+26
+00:01:18,990 --> 00:01:21,090
+So we can use testing to get confidence in our
+
+27
+00:01:21,090 --> 00:01:23,990
+refactorings, but we can't really guarantee that the refactorings are
+
+28
+00:01:23,990 --> 00:01:26,820
+behavior preserving. I'd also like to point out that for some
+
+29
+00:01:26,820 --> 00:01:30,100
+simple refactoring, we can use a static analysis to actually
+
+30
+00:01:30,100 --> 00:01:33,160
+provide these guarantees. And in fact we will see examples of
+
+31
+00:01:33,160 --> 00:01:37,050
+such refactorings that are incorporated into IDs and that leverage
+
+32
+00:01:37,050 --> 00:01:40,070
+these kinds of analysis to perform refactoring in a safe way.
diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/20 - When Not To Refactor - lang_en_vs4.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/20 - When Not To Refactor - lang_en_vs4.srt
new file mode 100644
index 0000000..53938de
--- /dev/null
+++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/20 - When Not To Refactor - lang_en_vs4.srt	
@@ -0,0 +1,103 @@
+1
+00:00:00,088 --> 00:00:02,860
+Now I want to conclude this discussion on refactoring by telling you
+
+2
+00:00:02,860 --> 00:00:07,190
+when you should not refactor. One first clear case is when
+
+3
+00:00:07,190 --> 00:00:10,410
+your code is broken. I want to make it very clear, refactoring
+
+4
+00:00:10,410 --> 00:00:13,450
+is not a way to fix your code in terms of its
+
+5
+00:00:13,450 --> 00:00:16,250
+functionality. It's a way to improve the design of your code.
+
+6
+00:00:16,250 --> 00:00:19,040
+So if your code does not compile or does not run
+
+7
+00:00:19,040 --> 00:00:21,780
+in a stable way, it's probably better to throw it away
+
+8
+00:00:21,780 --> 00:00:25,250
+and rewrite it rather then trying to refactor it. By definition refactoring
+
+9
+00:00:25,250 --> 00:00:26,780
+should maintain the functionality of the
+
+10
+00:00:26,780 --> 00:00:28,360
+system. It should be behavior preserving.
+
+11
+00:00:28,360 --> 00:00:31,100
+So if the code was broken before, it, it's probably going to be broken
+
+12
+00:00:31,100 --> 00:00:33,950
+afterwards as well. You may also want to avoid refactoring when a
+
+13
+00:00:33,950 --> 00:00:37,370
+deadline is close. Well, first of all, because refactoring might take a long
+
+14
+00:00:37,370 --> 00:00:41,360
+time and therefore might introduce risks of being late for the deadline.
+
+15
+00:00:41,360 --> 00:00:44,555
+And also, because of what we said before about introducing problems, you don't
+
+16
+00:00:44,555 --> 00:00:47,780
+want to introduce problems that might take you time to fix right before a
+
+17
+00:00:47,780 --> 00:00:50,660
+deadline. So if the deadline is too close, you might want to avoid
+
+18
+00:00:50,660 --> 00:00:54,310
+refactoring the code at that point. And finally, do not refactor if there
+
+19
+00:00:54,310 --> 00:00:58,430
+is no reason to. As we said before, you should refactor on demand. You
+
+20
+00:00:58,430 --> 00:01:00,960
+see a problem with the design of your code, with the structure of your
+
+21
+00:01:00,960 --> 00:01:03,790
+code, it's okay to refactor. If the code is fine, there is no reason
+
+22
+00:01:03,790 --> 00:01:06,470
+to refactor. I know that refactoring is fine, but you don't want to do
+
+23
+00:01:06,470 --> 00:01:09,280
+it all the time. The next thing I want to discuss, after discussing when
+
+24
+00:01:09,280 --> 00:01:12,970
+not to refactor, is when to refactor without an indication that will tell us
+
+25
+00:01:12,970 --> 00:01:15,820
+that it's time to refactor the code. And that leads us to the discussion
+
+26
+00:01:15,820 --> 00:01:17,280
+of a very interesting concept.
diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/21 - Bad Smells - lang_en_vs4.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/21 - Bad Smells - lang_en_vs4.srt
new file mode 100644
index 0000000..240d37b
--- /dev/null
+++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/21 - Bad Smells - lang_en_vs4.srt	
@@ -0,0 +1,99 @@
+1
+00:00:00,070 --> 00:00:03,450
+The concept of bad smells. What are bad smells? Well, we
+
+2
+00:00:03,450 --> 00:00:06,700
+mentioned earlier that refactoring is typically applied when there is something
+
+3
+00:00:06,700 --> 00:00:09,130
+that does not look right, does not feel right in the
+
+4
+00:00:09,130 --> 00:00:12,260
+code. And that's exactly what bad smells are. Bad smells, or
+
+5
+00:00:12,260 --> 00:00:15,320
+code smells if you wish, are symptoms in the code of
+
+6
+00:00:15,320 --> 00:00:18,868
+a program that might indicate deeper problems. So there might be
+
+7
+00:00:18,868 --> 00:00:21,775
+parts of my system, classes in my systems, that just don't
+
+8
+00:00:21,775 --> 00:00:25,309
+smell right, and it feels like there's, there might be something wrong
+
+9
+00:00:25,309 --> 00:00:29,010
+with them. And if you are an experienced developer just like Brad,
+
+10
+00:00:29,010 --> 00:00:31,320
+you'll be able to figure out there is something wrong with the
+
+11
+00:00:31,320 --> 00:00:33,950
+classes. You'll be able to smell that there's something wrong and you'll
+
+12
+00:00:33,950 --> 00:00:36,880
+do something about it. And I want to mention one more, just to make
+
+13
+00:00:36,880 --> 00:00:39,270
+sure that we're all on the same page here. That these bad
+
+14
+00:00:39,270 --> 00:00:43,070
+smells are usually not bugs and don't prevent the program from functioning. They
+
+15
+00:00:43,070 --> 00:00:46,190
+however indicate weaknesses in the design of the system that might cause
+
+16
+00:00:46,190 --> 00:00:48,480
+problems during maintenance. In other words,
+
+17
+00:00:48,480 --> 00:00:50,440
+they might make the code less maintainable,
+
+18
+00:00:50,440 --> 00:00:53,650
+harder to understand, and so on. Just like refactorings,
+
+19
+00:00:53,650 --> 00:00:56,610
+there's also many possible different bad smells. So what
+
+20
+00:00:56,610 --> 00:00:59,160
+I'm providing here is just a possible list of
+
+21
+00:00:59,160 --> 00:01:02,190
+some very common bad smells. And you can find plenty
+
+22
+00:01:02,190 --> 00:01:04,349
+of information on this online. So what I want
+
+23
+00:01:04,349 --> 00:01:06,910
+to do next is just to cover before finishing the
+
+24
+00:01:06,910 --> 00:01:08,700
+lesson a few of those to show you some
+
+25
+00:01:08,700 --> 00:01:11,140
+examples of smells and what you can do about them.
diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/22 - Bad Smell Examples - lang_en_vs4.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/22 - Bad Smell Examples - lang_en_vs4.srt
new file mode 100644
index 0000000..b26a698
--- /dev/null
+++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/22 - Bad Smell Examples - lang_en_vs4.srt	
@@ -0,0 +1,263 @@
+1
+00:00:00,100 --> 00:00:03,080
+The first example I want to mention is this called duplicated
+
+2
+00:00:03,080 --> 00:00:06,950
+code. So what happens here what the symptom is, is that you
+
+3
+00:00:06,950 --> 00:00:10,400
+have the same piece of code. The same fragment of code or
+
+4
+00:00:10,400 --> 00:00:14,570
+code structure replicated in more than one place. And that's pretty common
+
+5
+00:00:14,570 --> 00:00:16,880
+when we do for example copy and paste programming. Is something
+
+6
+00:00:16,880 --> 00:00:19,730
+that we mention at the beginning of the lessons. So for example
+
+7
+00:00:19,730 --> 00:00:22,780
+we are just instead reimplementing a piece of functionality we know we
+
+8
+00:00:22,780 --> 00:00:25,510
+already have. We simply copy from a different part of the code.
+
+9
+00:00:25,510 --> 00:00:27,760
+So what do you do if you have duplicated code? This can
+
+10
+00:00:27,760 --> 00:00:30,100
+be a problem over time because we might end up with a lot
+
+11
+00:00:30,100 --> 00:00:34,480
+of duplication in your system. You can use the extract method. Refactoring that
+
+12
+00:00:34,480 --> 00:00:37,610
+we just saw, and basically create a method that has exactly the same
+
+13
+00:00:37,610 --> 00:00:40,700
+function as this fragment of code and then replace the fragment of code
+
+14
+00:00:40,700 --> 00:00:43,030
+with an invocation to run and you will do it in all the
+
+15
+00:00:43,030 --> 00:00:47,520
+places where the code is duplicated. That simply finds the code and favors
+
+16
+00:00:47,520 --> 00:00:48,660
+reuse, because there can be more
+
+17
+00:00:48,660 --> 00:00:51,050
+places that benefit from that additional method.
+
+18
+00:00:51,050 --> 00:00:54,960
+Especially if it implements some popular piece of functionality. Another example
+
+19
+00:00:54,960 --> 00:00:57,930
+of best mal a typical one is the long method. So you
+
+20
+00:00:57,930 --> 00:01:00,530
+have a very long method with a lot of statements. And we
+
+21
+00:01:00,530 --> 00:01:03,570
+know that the longer procedure, the more difficult it is to understand
+
+22
+00:01:03,570 --> 00:01:05,650
+it and maintain it. So what I'm going to do in this
+
+23
+00:01:05,650 --> 00:01:08,690
+case is to factor in such as an extract method or a
+
+24
+00:01:08,690 --> 00:01:12,900
+decompose conditional to make the code simpler, shorten it. And extract some
+
+25
+00:01:12,900 --> 00:01:16,450
+of the functionality into other methods. So basically break down the method
+
+26
+00:01:16,450 --> 00:01:20,180
+in smaller methods that are more cohesive. Another typical example
+
+27
+00:01:20,180 --> 00:01:22,380
+of best mail which is something that can happen very
+
+28
+00:01:22,380 --> 00:01:25,720
+commonly during maintenance, is that you keep adding functionality to
+
+29
+00:01:25,720 --> 00:01:28,470
+a class and you end up with a large class. So
+
+30
+00:01:28,470 --> 00:01:32,410
+class is clearly to big. It contains too many fields
+
+31
+00:01:32,410 --> 00:01:35,620
+too many methods, and is just too complex to understand. This
+
+32
+00:01:35,620 --> 00:01:37,990
+case the obvious solution is to use the extract class
+
+33
+00:01:37,990 --> 00:01:42,230
+or subclass and basically break down the class in multiple classes.
+
+34
+00:01:42,230 --> 00:01:45,390
+Each one with a more cohesive piece of functionality. So, the
+
+35
+00:01:45,390 --> 00:01:46,930
+classes are more cohesive, are more
+
+36
+00:01:46,930 --> 00:01:48,360
+understandable, and the overall structure The
+
+37
+00:01:48,360 --> 00:01:52,440
+structure of the system is improved. Shotgun surgery is an interesting smell
+
+38
+00:01:52,440 --> 00:01:55,980
+and the case here is we are in a situation and you,
+
+39
+00:01:55,980 --> 00:01:58,270
+probably will happen to you, it definitely happened to me, in
+
+40
+00:01:58,270 --> 00:02:01,110
+which every time you make some kind of change to the system
+
+41
+00:02:01,110 --> 00:02:03,850
+you have to make many little changes. All over the place to
+
+42
+00:02:03,850 --> 00:02:07,280
+many different classes. And this can be a symptom of the fact
+
+43
+00:02:07,280 --> 00:02:11,080
+that the functionality is spread among these different classes. So
+
+44
+00:02:11,080 --> 00:02:13,610
+there's too much coupling between the classes and too little
+
+45
+00:02:13,610 --> 00:02:16,540
+cohesion within the classes. Also in this case you can
+
+46
+00:02:16,540 --> 00:02:19,540
+use refactoring, for example by using the move method or move
+
+47
+00:02:19,540 --> 00:02:22,650
+field or inline class to bring the pieces of related
+
+48
+00:02:22,650 --> 00:02:26,470
+functionality together. So that your resulting classes are more cohesive, you
+
+49
+00:02:26,470 --> 00:02:29,220
+reduce the dependencies between the different classes, and you address
+
+50
+00:02:29,220 --> 00:02:32,305
+this problem. Because at this point, each class is much more
+
+51
+00:02:32,305 --> 00:02:34,020
+self-contained and therefore it can be
+
+52
+00:02:34,020 --> 00:02:36,100
+modified by itself without having to affect
+
+53
+00:02:36,100 --> 00:02:38,560
+the rest of the system. The last smell I want to mention is
+
+54
+00:02:38,560 --> 00:02:42,040
+one I really like, is the feature envy, and it refers to a
+
+55
+00:02:42,040 --> 00:02:45,340
+method that seems more interested In a class other than the one it
+
+56
+00:02:45,340 --> 00:02:48,370
+belongs to. So for example this method is using a lot of public
+
+57
+00:02:48,370 --> 00:02:51,030
+fields of another class, is calling a lot of methods of the other
+
+58
+00:02:51,030 --> 00:02:53,830
+class. And so in this case the solution is really clear. What you
+
+59
+00:02:53,830 --> 00:02:57,420
+want to do it to perform the extract method refactoring and then the move
+
+60
+00:02:57,420 --> 00:02:59,680
+method refactoring so as to take the jealous
+
+61
+00:02:59,680 --> 00:03:01,210
+method out of the class where it doesn't
+
+62
+00:03:01,210 --> 00:03:04,770
+belong and get it home. To the class where it really belongs and once more the
+
+63
+00:03:04,770 --> 00:03:06,790
+effect of this is that you decrease the
+
+64
+00:03:06,790 --> 00:03:09,990
+coupling between the two classes and therefore you
+
+65
+00:03:09,990 --> 00:03:11,910
+have a better system and also you eliminate
+
+66
+00:03:11,910 --> 00:03:13,150
+the envy. Which is always a good thing.
diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/23 - Bad Smell Quiz - lang_en_vs3.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/23 - Bad Smell Quiz - lang_en_vs3.srt
new file mode 100644
index 0000000..971d639
--- /dev/null
+++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/23 - Bad Smell Quiz - lang_en_vs3.srt	
@@ -0,0 +1,31 @@
+1
+00:00:00,100 --> 00:00:01,620
+So now, I would like for you to tell me
+
+2
+00:00:01,620 --> 00:00:04,810
+which of the following can be considered bad smells in
+
+3
+00:00:04,810 --> 00:00:07,320
+the context of refactoring. The fact that the program takes
+
+4
+00:00:07,320 --> 00:00:10,070
+too long to execute? The fact that method M in class
+
+5
+00:00:10,070 --> 00:00:12,460
+C is very long? Or the, the fact that Class
+
+6
+00:00:12,460 --> 00:00:16,120
+Cat and Dog are subclasses of class Animal? Or finally the
+
+7
+00:00:16,120 --> 00:00:18,960
+fact that every time we modify method M1 we also
+
+8
+00:00:18,960 --> 00:00:22,120
+need to modify method M2? So please mark all that apply.
diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/24 - Bad Smell Quiz Solution - lang_en_vs3.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/24 - Bad Smell Quiz Solution - lang_en_vs3.srt
new file mode 100644
index 0000000..2773116
--- /dev/null
+++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/24 - Bad Smell Quiz Solution - lang_en_vs3.srt	
@@ -0,0 +1,75 @@
+1
+00:00:00,110 --> 00:00:03,090
+So let's look at this one by one. The fact the program takes
+
+2
+00:00:03,090 --> 00:00:06,620
+too long to execute is not really a bad smell. It probably indicates
+
+3
+00:00:06,620 --> 00:00:08,800
+some problem with the code and the fact that we might need to
+
+4
+00:00:08,800 --> 00:00:11,420
+modify the code to make it more efficient, but it's not something that
+
+5
+00:00:11,420 --> 00:00:14,030
+we will normally classify it as a bad smell, so we're not going to
+
+6
+00:00:14,030 --> 00:00:17,850
+mark it. The second one, conversely, is definitely a bad smell. The fact
+
+7
+00:00:17,850 --> 00:00:21,700
+that the method is too long is a typical example of bad smell
+
+8
+00:00:21,700 --> 00:00:25,000
+and one in which we might want to apply some refactoring, for example,
+
+9
+00:00:25,000 --> 00:00:26,450
+the extract method or the
+
+10
+00:00:26,450 --> 00:00:29,240
+decomposed conditional refactorings. There's definitely
+
+11
+00:00:29,240 --> 00:00:32,159
+nothing wrong with the fact that the classes cat and dog
+
+12
+00:00:32,159 --> 00:00:35,600
+are subclasses of class animal. Actually, that sounds pretty appropriate, so
+
+13
+00:00:35,600 --> 00:00:38,270
+this is not a problem and definitely not a bad smell.
+
+14
+00:00:38,270 --> 00:00:40,990
+Whereas the fact that every time we modify method M1,
+
+15
+00:00:40,990 --> 00:00:44,210
+we also need to modify method some other method M2 as
+
+16
+00:00:44,210 --> 00:00:46,690
+a typical example of bad smell. So this can actually be
+
+17
+00:00:46,690 --> 00:00:50,590
+considered a specific example of what we just called "shotgun surgery."
+
+18
+00:00:50,590 --> 00:00:52,500
+So it is a case in which we might want to
+
+19
+00:00:52,500 --> 00:00:55,750
+use, for instance, the move method refactoring to fix the issue.
diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/3 - Introduction - lang_en_vs4.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/3 - Introduction - lang_en_vs4.srt
new file mode 100644
index 0000000..7631180
--- /dev/null
+++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/3 - Introduction - lang_en_vs4.srt	
@@ -0,0 +1,27 @@
+1
+00:00:00,120 --> 00:00:04,280
+So let's have a small quiz and see whether you can remember why can testing
+
+2
+00:00:04,280 --> 00:00:06,250
+guarantee that that a refactoring is behavior is
+
+3
+00:00:06,250 --> 00:00:08,590
+preserving. So why testing can only show the
+
+4
+00:00:08,590 --> 00:00:11,080
+absence of defects and not their presence?
+
+5
+00:00:11,080 --> 00:00:12,960
+Is that because testing and refactoring are different
+
+6
+00:00:12,960 --> 00:00:15,980
+activities? Because testing is inherently incomplete? Or, just
+
+7
+00:00:15,980 --> 00:00:19,560
+because testers are often inexperienced? Make your choice.
diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/4 - Introduction Solution - lang_en_vs4.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/4 - Introduction Solution - lang_en_vs4.srt
new file mode 100644
index 0000000..7888f8d
--- /dev/null
+++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/4 - Introduction Solution - lang_en_vs4.srt	
@@ -0,0 +1,39 @@
+1
+00:00:00,220 --> 00:00:03,180
+And the reason for this is because testing is inherently
+
+2
+00:00:03,180 --> 00:00:06,080
+incomplete. So let me re-size this a little bit, so that
+
+3
+00:00:06,080 --> 00:00:08,340
+I can make room for an illustration. And what I'm
+
+4
+00:00:08,340 --> 00:00:11,170
+going to show you here is just a reminder, that when we
+
+5
+00:00:11,170 --> 00:00:15,380
+test, we have a huge virtually infinite input domain, and
+
+6
+00:00:15,380 --> 00:00:17,956
+we have to derive from this input domain a few test
+
+7
+00:00:17,956 --> 00:00:21,330
+cases. By picking specific inputs in the domain, and of
+
+8
+00:00:21,330 --> 00:00:25,260
+course, corresponding outputs. And so what happens normally is that these
+
+9
+00:00:25,260 --> 00:00:28,280
+test cases represent the teeny tiny fraction of
+
+10
+00:00:28,280 --> 00:00:30,920
+the domain, and therefore testing is always incomplete.
diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/5 - Reasons to Refactor - lang_en_vs4.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/5 - Reasons to Refactor - lang_en_vs4.srt
new file mode 100644
index 0000000..1da50e6
--- /dev/null
+++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/5 - Reasons to Refactor - lang_en_vs4.srt	
@@ -0,0 +1,131 @@
+1
+00:00:00,230 --> 00:00:02,000
+We saw at the beginning of the lesson, what are the
+
+2
+00:00:02,000 --> 00:00:05,490
+goals of refactoring? Or what are the reasons ,why we need to
+
+3
+00:00:05,490 --> 00:00:09,130
+refactor in the first place? The first reason is that requirements
+
+4
+00:00:09,130 --> 00:00:12,370
+change, and when the requirements change, we often need to change our
+
+5
+00:00:12,370 --> 00:00:16,356
+design accordingly. In other cases if any of the requirements unchange,
+
+6
+00:00:16,356 --> 00:00:19,690
+we might need to improve our design. And this happens for many
+
+7
+00:00:19,690 --> 00:00:22,300
+reasons. For example, we need to add a new feature, we
+
+8
+00:00:22,300 --> 00:00:25,330
+want to make the code more maintainable, and also in general programmers
+
+9
+00:00:25,330 --> 00:00:28,110
+don't come up with the best design the first time. So they might
+
+10
+00:00:28,110 --> 00:00:31,130
+need to adapt it after the fact. And the final reason I want to
+
+11
+00:00:31,130 --> 00:00:33,040
+mention is sloppiness, and to some
+
+12
+00:00:33,040 --> 00:00:35,700
+extent laziness, of programmers. And a typical
+
+13
+00:00:35,700 --> 00:00:38,520
+example of this is something that we all have done, which is copy
+
+14
+00:00:38,520 --> 00:00:41,890
+and paste programming. So instead of rewriting a new piece of code, because
+
+15
+00:00:41,890 --> 00:00:44,620
+we know that there is some code in some other parts for the
+
+16
+00:00:44,620 --> 00:00:47,900
+program that does a similar thing, we'll just copy the code over. And
+
+17
+00:00:47,900 --> 00:00:51,080
+before we know, we end up with tons of copies of the same functionality.
+
+18
+00:00:51,080 --> 00:00:54,150
+And when that happens, a good way of consolidating that code and
+
+19
+00:00:54,150 --> 00:00:57,580
+extracting that functionality is to use refactoring, for example, by creating a
+
+20
+00:00:57,580 --> 00:01:01,080
+method or a class that provides the functionality. And we'll see specific
+
+21
+00:01:01,080 --> 00:01:03,830
+examples of that. A question I would like to ask at this
+
+22
+00:01:03,830 --> 00:01:07,330
+point of the class is whether you have used refactoring before? So
+
+23
+00:01:07,330 --> 00:01:09,690
+I want you to take a second and think about it. And
+
+24
+00:01:09,690 --> 00:01:12,590
+no matter what you're history is, if you ever coded I bet
+
+25
+00:01:12,590 --> 00:01:16,180
+you any money that the answer is yes, you have done refactoring.
+
+26
+00:01:16,180 --> 00:01:17,300
+What do I mean? I'm going to give you an
+
+27
+00:01:17,300 --> 00:01:19,610
+example. I'm sure you renamed the class or a
+
+28
+00:01:19,610 --> 00:01:22,190
+method or change the name of some variables in
+
+29
+00:01:22,190 --> 00:01:25,490
+the code before. That's refactoring. Even something as simple as
+
+30
+00:01:25,490 --> 00:01:28,030
+renaming a class is refactoring, because, for example, it
+
+31
+00:01:28,030 --> 00:01:30,230
+might help you making your code more understandable. And of
+
+32
+00:01:30,230 --> 00:01:32,520
+course I'll admit that in this case, this is
+
+33
+00:01:32,520 --> 00:01:35,690
+a trivial refactoring, and there are much more interesting ones.
diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/6 - History of Refactoring - lang_en_vs4.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/6 - History of Refactoring - lang_en_vs4.srt
new file mode 100644
index 0000000..3405b65
--- /dev/null
+++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/6 - History of Refactoring - lang_en_vs4.srt	
@@ -0,0 +1,171 @@
+1
+00:00:00,110 --> 00:00:02,340
+So if you follow my class so far, you know that
+
+2
+00:00:02,340 --> 00:00:04,570
+I like to give a little bit of history when I talk
+
+3
+00:00:04,570 --> 00:00:06,900
+about a specific topic. So I'm going to do the same also
+
+4
+00:00:06,900 --> 00:00:09,900
+in this case for refactoring. I'm going to start by mentioning, the fact
+
+5
+00:00:09,900 --> 00:00:13,440
+that refactoring is something that programmers have always done. I gave
+
+6
+00:00:13,440 --> 00:00:16,300
+you a trivial example just a minute ago of what refactoring is.
+
+7
+00:00:16,300 --> 00:00:18,080
+So even more complicated refactorings are
+
+8
+00:00:18,080 --> 00:00:20,880
+something that are commonplace for developers.
+
+9
+00:00:20,880 --> 00:00:23,110
+Somehow refactoring is especially important in
+
+10
+00:00:23,110 --> 00:00:25,240
+the context of object-oriented languages and
+
+11
+00:00:25,240 --> 00:00:28,080
+probably it's because the object-oriented features are well suited to
+
+12
+00:00:28,080 --> 00:00:31,640
+make designs flexible and reusable. Because of the fact that help
+
+13
+00:00:31,640 --> 00:00:35,120
+encapsulation, information hiding, and so they make it easier to
+
+14
+00:00:35,120 --> 00:00:38,330
+modify something without changing the functionality that it provides to the
+
+15
+00:00:38,330 --> 00:00:40,960
+outside world. However, you should keep in mind that refactoring
+
+16
+00:00:40,960 --> 00:00:44,330
+is really not specific to object oriented languages, you can also
+
+17
+00:00:44,330 --> 00:00:47,320
+refactor other languages, it's just more common to see it in
+
+18
+00:00:47,320 --> 00:00:50,450
+that context. So one of the first examples of a specific
+
+19
+00:00:50,450 --> 00:00:53,630
+discussion of what the refactorings are is Opdyke's PhD
+
+20
+00:00:53,630 --> 00:00:57,710
+thesis in 1990. Which discusses refactorings for small talk.
+
+21
+00:00:57,710 --> 00:00:59,360
+And some of you might be familiar with small
+
+22
+00:00:59,360 --> 00:01:02,600
+talk, which is a specific objectory language. And in
+
+23
+00:01:02,600 --> 00:01:06,590
+more recent times, refactoring's becoming increasing popular due to
+
+24
+00:01:06,590 --> 00:01:10,370
+lightweight development methodoogies, due to agile development, which is
+
+25
+00:01:10,370 --> 00:01:12,630
+something that we just discussed in this class. For
+
+26
+00:01:12,630 --> 00:01:15,830
+example, when we talked about extreme programming, we mentioned refactoring
+
+27
+00:01:15,830 --> 00:01:17,950
+a few times. And the reason why its so popular
+
+28
+00:01:17,950 --> 00:01:20,690
+is because re-factoring is one of the practices that help.
+
+29
+00:01:20,690 --> 00:01:24,780
+Making changes less expensive. And therefore adapt to changing requirements
+
+30
+00:01:24,780 --> 00:01:26,980
+and changing environments more quickly.
+
+31
+00:01:26,980 --> 00:01:29,140
+And continuing with historical perspective, one
+
+32
+00:01:29,140 --> 00:01:31,760
+of the milestones in the history of re-factoring [INAUDIBLE] is
+
+33
+00:01:31,760 --> 00:01:34,660
+a book by Martin Fowler. This is a book entitled
+
+34
+00:01:34,660 --> 00:01:37,610
+Improving the Design of Existing [INAUDIBLE]. And it contains a
+
+35
+00:01:37,610 --> 00:01:41,320
+catalog of refactorings, a list of bad smells, in code, and
+
+36
+00:01:41,320 --> 00:01:43,450
+we're going to see what that mean exactly. Nothing to
+
+37
+00:01:43,450 --> 00:01:45,570
+do with other kinds of bad smells. It talks about
+
+38
+00:01:45,570 --> 00:01:48,900
+guidelines on when to apply refactoring. And finally, which is
+
+39
+00:01:48,900 --> 00:01:52,540
+very useful, it provides example of code, before and after.
+
+40
+00:01:52,540 --> 00:01:54,660
+Applying the refactoring and we're going to use more of the
+
+41
+00:01:54,660 --> 00:01:57,190
+same style when discussing refactoring in the rest of this
+
+42
+00:01:57,190 --> 00:02:01,090
+lesson. More specifically what we're discussing next, are some examples
+
+43
+00:02:01,090 --> 00:02:05,130
+of refactoring and also some examples of code bad smells.
diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/7 - Types of Refactorings - lang_en_vs4.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/7 - Types of Refactorings - lang_en_vs4.srt
new file mode 100644
index 0000000..b646b14
--- /dev/null
+++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/7 - Types of Refactorings - lang_en_vs4.srt	
@@ -0,0 +1,43 @@
+1
+00:00:00,170 --> 00:00:03,630
+There are many refactorings in Fowler's book, and what I'm
+
+2
+00:00:03,630 --> 00:00:06,480
+showing here is just a partial list. And we're not going to
+
+3
+00:00:06,480 --> 00:00:08,930
+have time to go through the complete list of refactorings,
+
+4
+00:00:08,930 --> 00:00:10,830
+so what I'm going to do instead, I'm just going to pick a
+
+5
+00:00:10,830 --> 00:00:13,870
+few of those, but I'm going to explain in more depth,
+
+6
+00:00:13,870 --> 00:00:16,600
+and for which I'm going to provide some examples. In particular, we're
+
+7
+00:00:16,600 --> 00:00:18,000
+going to talk about the collapse
+
+8
+00:00:18,000 --> 00:00:20,630
+hierarchy refactoring, the consolidate conditional
+
+9
+00:00:20,630 --> 00:00:23,600
+expressions, the decompose conditionals, extract
+
+10
+00:00:23,600 --> 00:00:25,418
+method, extract class, and inline class.
+
+11
+00:00:25,418 --> 00:00:29,420
+And we're going to see each of those individually in the rest of the lesson.
diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/8 - Collapse Hierarchy - lang_en_vs4.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/8 - Collapse Hierarchy - lang_en_vs4.srt
new file mode 100644
index 0000000..8711182
--- /dev/null
+++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/8 - Collapse Hierarchy - lang_en_vs4.srt	
@@ -0,0 +1,67 @@
+1
+00:00:00,110 --> 00:00:03,080
+The first refactoring we're going to see is the collapse hierarchy
+
+2
+00:00:03,080 --> 00:00:06,340
+refactoring. When a software system undergoes a number of changes, over
+
+3
+00:00:06,340 --> 00:00:09,730
+time the collapse hierarchy may become, let's say, sub-optimal. There are
+
+4
+00:00:09,730 --> 00:00:11,300
+several refactorings that address this
+
+5
+00:00:11,300 --> 00:00:13,200
+issue for example, refactorings that allow
+
+6
+00:00:13,200 --> 00:00:15,900
+you to move methods and fields up and down the class
+
+7
+00:00:15,900 --> 00:00:18,360
+hierarchy. So what happens when you apply a number of these
+
+8
+00:00:18,360 --> 00:00:22,360
+refactorings, is that a subclass might become too similar to its
+
+9
+00:00:22,360 --> 00:00:25,878
+superclass and might not be adding much value to the system.
+
+10
+00:00:25,878 --> 00:00:28,010
+In this case, it is a good idea to merge
+
+11
+00:00:28,010 --> 00:00:31,300
+the classes together. That's exactly what the Collapse Hierarchy refactoring
+
+12
+00:00:31,300 --> 00:00:34,600
+does. Imagine, for instance, that we have two classes: employee
+
+13
+00:00:34,600 --> 00:00:38,210
+and salesman. And that salesman is just so similar to
+
+14
+00:00:38,210 --> 00:00:40,380
+employee that it does not make sense to keep them
+
+15
+00:00:40,380 --> 00:00:43,870
+separated. In this case, you could merge the two classes,
+
+16
+00:00:43,870 --> 00:00:46,730
+so that at the end of the refactoring, only employee
+
+17
+00:00:46,730 --> 00:00:50,070
+is left. And the resulting structure of the system is improved.
diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/9 - Consolidate Conditional Expression - lang_en_vs4.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/9 - Consolidate Conditional Expression - lang_en_vs4.srt
new file mode 100644
index 0000000..be2b3fe
--- /dev/null
+++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/9 - Consolidate Conditional Expression - lang_en_vs4.srt	
@@ -0,0 +1,131 @@
+1
+00:00:00,070 --> 00:00:00,860
+We're now going to talk about
+
+2
+00:00:00,860 --> 00:00:03,390
+the consolidate conditional expression refactoring.
+
+3
+00:00:03,390 --> 00:00:05,730
+A common situation in code is that you have a set
+
+4
+00:00:05,730 --> 00:00:08,530
+of conditionals with the same result. What that means that
+
+5
+00:00:08,530 --> 00:00:12,090
+sometimes the code contains a series of conditional checks in which
+
+6
+00:00:12,090 --> 00:00:14,760
+each check is different, yet the resulting action is the
+
+7
+00:00:14,760 --> 00:00:18,440
+same. In these cases, the code could be improved by combining
+
+8
+00:00:18,440 --> 00:00:22,100
+the conditionals using, for example, and, and or, as connectors. So
+
+9
+00:00:22,100 --> 00:00:25,390
+as to have a single conditional check, with a single result.
+
+10
+00:00:25,390 --> 00:00:28,500
+At that point you can also extract those conditional into a
+
+11
+00:00:28,500 --> 00:00:32,310
+method. And replace the conditional with a call, to debt matter consolidating
+
+12
+00:00:32,310 --> 00:00:35,110
+the conditional code in this way can make the checks clearer
+
+13
+00:00:35,110 --> 00:00:38,170
+by showing that you're really making a single check rather than multiple
+
+14
+00:00:38,170 --> 00:00:41,150
+checks, and extracted that condition and having that matter instead of
+
+15
+00:00:41,150 --> 00:00:44,550
+a condition can clarify your code by explaining why you're doing a
+
+16
+00:00:44,550 --> 00:00:47,350
+given check, rather than how you're doing it. You can see an
+
+17
+00:00:47,350 --> 00:00:52,020
+example of that situation in this code, which is the disabilityAmount method.
+
+18
+00:00:52,020 --> 00:00:54,580
+As the name of the method says, the purpose of this code
+
+19
+00:00:54,580 --> 00:00:58,300
+is to compute the disability amount for a given, for example, employee.
+
+20
+00:00:58,300 --> 00:01:01,250
+And there is a set of initial checks in the methods whose
+
+21
+00:01:01,250 --> 00:01:05,090
+goal is to decide whether there's this disabilityAmount should be instead zero.
+
+22
+00:01:05,090 --> 00:01:07,750
+And as you can see, there's multiple conditions. For example, there's a
+
+23
+00:01:07,750 --> 00:01:10,630
+check about the seniority level, and about the number of months that
+
+24
+00:01:10,630 --> 00:01:14,350
+the employee's been disabled. So far, whether the employee is part time
+
+25
+00:01:14,350 --> 00:01:17,060
+and the outcome of all these check is always the same. If they're
+
+26
+00:01:17,060 --> 00:01:19,740
+true, if the check is satisfied then there is no disability
+
+27
+00:01:19,740 --> 00:01:22,564
+amount. So the disabilityAmount is zero. So what I will do
+
+28
+00:01:22,564 --> 00:01:25,986
+if I apply the consolidate conditional expression to this matter, is
+
+29
+00:01:25,986 --> 00:01:29,690
+that I will take these three conditionals. I will put them together
+
+30
+00:01:29,690 --> 00:01:32,772
+by saying basically that if seniority is less than 2 or
+
+31
+00:01:32,772 --> 00:01:36,524
+monthsDisabled is greater than 12 or isPartTime is true then the
+
+32
+00:01:36,524 --> 00:01:40,170
+return should be zero. And once I have this combined conditional,
+
+33
+00:01:40,170 --> 00:01:42,601
+as I see here, I will just extract that into a method.
diff --git a/usth/ICT2.7/fuzzy-find b/usth/ICT2.7/fuzzy-find
new file mode 100755
index 0000000..70f14de
--- /dev/null
+++ b/usth/ICT2.7/fuzzy-find
@@ -0,0 +1,26 @@
+#!/usr/bin/env python3.8
+from glob import glob
+from itertools import islice
+from os import path
+from textwrap import wrap
+
+from fuzzywuzzy import fuzz, process
+
+
+transcripts = {}
+for filename in glob(path.join('*', '*')):
+    with open(filename) as f:
+        subtitles = ' '.join(' '.join(islice(f, 2, None, 4)).split())
+        transcripts[filename] = subtitles.replace('.', '. ').replace('?', '? ')
+
+while query := input('>>> '):
+    bests = process.extractBests(query, transcripts, scorer=fuzz.partial_ratio)
+    for index, (transcript, score, filename) in enumerate(bests):
+        print(index, filename)
+    while index := input('... '):
+        try:
+            chosen = bests[int(index)]
+        except (IndexError, ValueError):
+            pass
+        else:
+            print(chosen[2], *wrap(chosen[0], 80), sep='\n')
-- 
cgit 1.4.1