Bảng 1.1 Chủ đề câu hỏi sẽ liên quan đến các chương trong bài.
|
Chủ đề |
Câu hỏi |
|
Chu trình phát triển phần mềm |
1,2 |
|
Các mẫu thiết kế thông dụng |
3,4 |
|
Linux BASH |
5,6 |
|
Quản lý phiên bản phần mềm |
7 |
|
Git |
8-10 |
|
Review Code |
11 |
Lưu ý:
Mục tiêu của việc tự đánh giá là kiểm tra mức độ hiểu biết của bạn về các chủ đề trong chương này. Nếu bạn không biết câu trả lời cho câu hỏi hay chỉ chắc chắn một phần về câu trả lời thì nên đánh dấu câu hỏi lại. Tự trả lời dựa trên việc đoán sẽ làm sai lệch kết quả đánh giá bản thân.
Câu 1: Thế nào là mô hình thác nước (Waterfall)?
1. Mô tả về cách đổ lỗi từ ban quản lý đối với các dự án phần mềm thất bại.
2. Một loại SDLC.
3. Một hướng tiếp cận để phát triển các phần mềm dựa trên một phạm vi cố định.
4. Tất cả các ý trên.
Câu 2: Agile là gì ?
1. Một hình thức quản lý dự án cho Lean.
2. Một cách triển khai mô hình Lean để phát triển phần mềm.
3. Một chiến lược để vượt qua kỳ thi CCNA DevNet.
4. Một lợi ích chính của tự động hóa trong cơ sở hạ tầng.
Câu 3: Mô hình Model-View-Controller thường được sử dụng trong ứng dụng nào sau đây? (Chọn ba.)
1. Ứng dụng web với giao diện đồ họa.
2. Client/server ứng dụng với nhiều loại client khác nhau.
3. PowerShell scripts.
4. Django.
Câu 4: Đâu là câu trả lời đúng về Observer pattern? (Chọn 2)
1. Nó là một mô hình nhà phát hành/ người đăng kí .
2. Nó là một mô hình multicast.
3. Nó được sử dụng cho các ứng dụng quản lý cấu hình và xử lý sự kiện.
4. Nó không thường được sử dụng trong thiết kế ứng dụng cơ sở hạ tầng.
Câu 5: BASH là viết tắt của từ gì ?
1. Born Again Shell.
2. Basic Shell.
3. Bourne Again Shell.
4. None of the above.
Câu 6: Câu lệnh nào sau đây là lựa chọn tốt nhất để hiển thị các biến môi trường trong hệ thống hiện tại?
1. env | cat > env.txt
2. env | more
3. export $ENV | cat
4. echo env
Câu 7: Điều nào sau đây là đúng với version control (quản lý phiên bản) trong phần mềm?
1. Đây là một quy ước đặt tên cho các bản phát hành phần mềm.
2. Nó còn được gọi là quản lý mã nguồn .
3. Nó cũng giống như BitKeeper.
4. Tất cả đều sai
Câu 8: Ai đã tạo ra Git?
1. Junio Hamano.
2. Marc Andreesen.
3. John Chambers.
4. Linus Torvalds.
Câu 9: Ba cấu trúc chính của Git là gì ?
1. Index, head, and local repo.
2. Local workspace, index, và local repository.
3. Remote repository, head, và local index.
4. Tất cả đều sai
Câu 10: Để thêm tệp có tên file.py vào index của Git, bạn dùng câu lệnh nào sau đây?
1. git add .
2. git index file.py
3. git index add .
4. git add file.py
Câu 11: Một trong những lợi ích chính của việc review code là gì?
1. Giúp tạo phần mềm chất lượng cao hơn.
2. Giúp tìm ra những lập trình viên yếu cần đào tạo thêm.
3. Giúp phát hiện ra những lỗi hiển nhiên trong phần mềm
4. Tất cả đều sai
Bất kỳ ai cũng có thể lập trình. Khi bạn học cú pháp của một ngôn ngữ lập trình, bạn chỉ cần kết hợp tất cả lại với nhau để ứng dụng của bạn để có thể làm được những gì bạn muốn, phải không? Trên thực tế, phần mềm được xây dựng cần phải có một cấu trúc nhất định để mang lại cho nó tính bền vững, khả năng quản lý và tính đồng nhất . Có thể bạn đã nghe qua cụm từ "cowboy coding", để ám chỉ một dự án phần mềm phi cấu trúc, nơi mà công đoạn thiết kế chỉ chiếm một phần rất ít, các lập trình viên chỉ cần “tùy cơ ứng biến” và viết code mà không cần suy nghĩ gì (nhiều). Đây là con đường nhanh nhất dẫn đến nhưng cuộc gọi vào đêm khuya để yêu cầu hỗ trợ và fix bug. Nếu một ngày bạn phải phải bảo trì một mớ hỗn độn như thế này, nhận yêu cầu sửa chữa, mở rộng hoặc nâng cấp nó. Khả năng cao là bạn sẽ cập nhật CV và thu dọn hành lý để nhảy sang một công ty khác.
Để ngăn chặn các vấn đề của các phương pháp như “cowboy coding”, cũng như thiết lập các quy tắc và tiêu chuẩn trong quá trình xây dựng. Trong thế giới phần mềm, thuật ngữ Software Development Lifecycle (SDLC) sẽ cung cấp hướng dẫn về việc xây dựng các phần mềm bền vững. SDLC đưa ra kế hoạch xây dựng, sửa chữa, thay thế và thực hiện các thay đổi đối với phần mềm.Như thể hiện trong Hình 2-1, đây là các giai đoạn của SDLC:
Giai đoạn 1 - Planning: Xác định use case hiện tại hoặc vấn đề mà phần mềm dự định sẽ giải quyết. Nhận ý kiến đóng góp từ các bên liên quan, người dùng cuối và các chuyên gia để xác định “thành công” sẽ trông như thế nào. Giai đoạn này còn được gọi là phân tích yêu cầu.
Giai đoạn 2 - Defining: Giai đoạn này liên quan đến việc phân tích các thông số kỹ thuật chức năng của software— chính xác hơn là xác định những gì phần mềm phải làm .
Giai đoạn 3 - Designing: Trong giai đoạn này, ta sẽ chuyển các đặc tả phần mềm thành một đặc tả thiết kế. Đây là một giai đoạn quan trọng vì các bên liên quan cần phải thống nhất để xây dựng phần mềm một cách thích hợp; nếu không, người dùng sẽ không hài lòng và dự án sẽ không thành công
Giai đoạn 4 - Building: Khi đặc tả thiết kế phần mềm hoàn tất, các lập trình viên bắt tay vào biến nó thành hiện thực. Nếu những giai đoạn trước được thực hiện thành công, giai đoạn này sẽ dễ dàng hơn nhiều.
Giai đoạn 5 - Testing: Phần mềm có hoạt động như mong đợi không? Trong giai đoạn này, các lập trình viên kiểm tra các lỗi và khiếm khuyết. Phần mềm liên tục được kiểm tra và thử nghiệm cho đến khi đáp ứng thành công các thông số kỹ thuật đã xác định từ ban đầu.
Giai đoạn 6 - Deployment: Trong giai đoạn này, phần mềm được đưa vào hoạt động để người dùng cuối sử dụng nó. Việc triển khai thường được thực hiện từ ban đầu để có thể dễ dàng bổ sung những chỉnh sửa cuối cùng hoặc phát hiện những lỗi bị bỏ sót. Khi người dùng đã chấp nhận phần mềm và nó đã được đưa vào hoạt động hoàn chỉnh, giai đoạn này sẽ chuyển sang giai đoạn bảo trì, nơi việc sửa lỗi và chỉnh sửa phần mềm cũng như các thay đổi nhỏ hơn được thực hiện theo yêu cầu của người dùng doanh nghiệp.
Hình 2.1 Software Development Lifecycle
Lưu ý : ISO / IEC 12207 là tiêu chuẩn quốc tế cho các quy trình vòng đời phần mềm và có nhiều tổ chức trên toàn cầu sử dụng tiêu chuẩn này để chứng nhận các nỗ lực phát triển phần mềm của họ. Tiêu chuẩn này tương thích với bất kỳ mô hình SDLC nào và góp phần cải tiến chúng với mục tiêu đảm bảo chất lượng và quy trình. Tuy nhiên, nó không thay thế cho những mô hình SDLC đã được chọn.
Có khá nhiều mô hình SDLC cải tiến thêm quy trình chung vừa mô tả. Tất cả đều sử dụng các khái niệm cốt lõi giống nhau nhưng khác nhau về cách triển khai và sẽ phù hợp với các dự án, các nhóm khác nhau. Sau đây là một số mô hình SDLC phổ biến nhất:
May thay, bạn không cần phải biết hết tất cả những mô hình này để có thể vượt qua kỳ thi DEVASC 200-901 DevNet Associate. Các phần sau đây bao gồm những thứ bạn nên biết nhất: Waterfall, Lean và Agile.
