[usth/ICT2.7] Remove Udacity transcribes

1 files changed, 0 insertions, 123 deletions

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
deleted file mode 100644
index b2224ea..0000000
--- a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/15 - Agile Process - lang_pt_vs1.srt
+++ /dev/null
@@ -1,123 +0,0 @@
-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.