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

---
 .../2 - History of RUP - lang_en_vs6.srt           | 115 +++++++++++++++++++++
 1 file changed, 115 insertions(+)
 create mode 100644 usth/ICT2.7/P3L4 Unified Software Process Subtitles/2 - History of RUP - lang_en_vs6.srt

(limited to 'usth/ICT2.7/P3L4 Unified Software Process Subtitles/2 - History of RUP - lang_en_vs6.srt')

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.
-- 
cgit 1.4.1