CHƯƠNG 2: CHU TRÌNH PHÁT TRIỂN PHẦN MỀM
Bước 1: Hoạch định (Planning): Nhận ra các trường hợp ứng dụng hiện tại hay các vấn đề mà phần mềm đang giải quyết. Thu thập thông tin từ các người dùng, từ các chuyên gia để xác định một giải pháp thành công sẽ có dạng như thế nào. Bước này còn được biết đến như là phân tích yêu cầu.
Bước 2: Định nghĩa bài toán. Bước này bao gồm phân tích các chức năng của phần mềm, định nghĩa một cách cơ bản phần mềm sẽ làm gì.
Bước 3: Thiết kế. Trong bước này, bạn sẽ chuyển các đặc tả phần mềm sang các đặc tả thiết kế. Đây là bước quan trọng vì đơn vị đầu tư cần phải đạt thỏa thuận trước khi phần mềm được xây dựng phù hợp. Nếu họ không đạt được thỏa thuận trước, người dùng cuối sẽ không hài long với phần mềm được xây dựng và dự án sẽ không thành công.
Bước 4: Xây dựng phần mềm. Khi các đặc tả thiết kế được hoàn thành, các lập trình viên sẽ bắt đầu hiện thực. Nếu giai đoạn trước đó hoàn tất thành công, bước hiện thực này thường được xem là dễ dàng.
Bước 5: Kiểm tra. Phần mềm có hoạt động như yêu cầu không? Trong giai đoạn này, người lập trình kiểm tra các lỗi và các khiếm khuyết. Phần mềm liên tục được kiểm tra và thử nghiệm cho đến khi nó đáp ứng các đặc tả phần mềm ban đầu.
Bước 6: Triển khai. Trong bước này, phần mềm được đưa vào hoạt động cho người dùng cuối thông qua các bước. Quá trình triển khai thường được thực hiện theo một số cách giới hạn để rà soát và hiệu chỉnh các lỗi cuối cùng. Khi người dùng đã chấp nhận và nghiệm thu phần mềm, nó được đưa vào sử dụng hoàn toàn. Các bước về bảo trì, các thay đổi nhỏ được thực thi ở giai đoạn sau này.
Có nhiều mô hình phát triển phần mềm. Tuy nhiên trong khóa học DEVNET 200-901, chúng ta chỉ cần khảo sát ba mô hình: Waterfall, Lean và Agile.
MÔ HÌNH WATERFALL
Giải pháp Waterfall là một giải pháp phát triển phần mềm theo kiểu tuần từ, chia ra thành từng giai đoạn.
Mô hình này đã thành công trong một thời gian dài, tuy nhiên có một số nhược điểm của mô hình Waterfall đã bộc lộ. Đầu tiên là tính chất tuần tự của các giai đoạn trong mô hình đã làm cho phạm vi của một dự án bị giới hạn ở giai đoạn thiết kế. Nói một cách cơ bản, giải pháp Waterfall không đáp ứng tốt các nhu cầu thay đổi. Khi chúng ta đi đến giai đoạn viết code, chúng ta có thể nhận ra rằng các tính năng phần mềm mà chúng ta đang xây dựng không còn cần thiết nữa.
Khía cạnh thứ hai của mô hình Waterfall đó là các giá trị cần đạt được của dự án sẽ không thể nào có cho đến tận khi toàn bộ tiến trình hoàn thành. Chúng ta viết các phần mềm để tự động hóa các chức năng kinh doanh và các giá trị mà phần mềm mang lại chỉ được nhận ra khi phần mềm được đưa vào sử dụng và tạo ra các kết quả. Với giải pháp Waterfall, ngay cả khi chúng ta đã ở giữa đoạn đường của dự án, chúng ta vẫn chưa có một sản phẩm sử dụng được hay các giá trị mang đến cho kinh doanh.
Khía cạnh thứ ba của mô hình Waterfall là vấn đề chất lượng. Thời gian là kẻ thù khi chúng ta nói đến vấn đề cung cấp các phần mềm giá trị. Nếu chúng ta có thời gian vô hạn, chúng ta có thể tạo ra các phần mềm hoàn hảo. Khi các nhà phát triển ứng dụng không còn thời gian, tiến trình kiểm tra thường phải chịu đựng hay hy sinh để có thể hoàn thành dự án.
LEAN
Sau thế chiến thứ II, Nhật Bản đang trong tình trạng rất cần xây dựng lại nền kinh tế và hạ tầng. Năng lực sản xuất của nước Nhật hầu hết đã bị phá hủy, bao gồm cả những năng lực trong ngành công nghiệp ô tô. Khi Nhật Bản giải quyết việc xây dựng lại này, họ không chỉ tập trung vào các tòa nhà và cơ sở hạ tầng; họ đã xem xét những cách khác nhau để làm mọi thứ. Với sự cố gắng đó, hệ thống sản xuất Toyota (Toyota Production System: TPS) đã ra đời. Được tạo ra bởi Taiichi Ohno và Sakichi Toyoda (Người sáng lập Toyota), quá trình quản lý và sản suất này tập trung vào các khái niệm quan trọng sau:
Trong khi những khái niệm này có vẻ rõ ràng và thực tế, TPS (Toyota Production System) là nơi đầu tiên thực hiện những nguyên tắc này như một triết lý quản lý. TPS là bước khởi đầu của phương pháp sản xuất Lean tổng quát hơn đã được giới thiệu với thế giới phương Tây vào năm 1991 thông qua một cuốn sách do Womack, Jones và Roos viết, The Machine That Changed the World. Cuốn sách này dựa trên một nghiên cứu kéo dài 5 năm MIT thực hiện trên TPS, và nó đã được ghi nhận là đã đưa các khái niệm và quy trình Lean ra ngoài ngành công nghiệp ô tô. Tại sao lại dành thời gian này để nói về những cuốn sách quản lý đã quá cũ? Lean đã dẫn đến sự phát triển phần mềm Agile, đã đóng vai trò như một kim chỉ nam định hướng cho các hoạt động của Công nghệ thông tin.
AGILE
Agile là một áp dụng của các nguyên tắc Lean vào việc phát triển phần mềm. Tất cả các kinh nghiệm áp dụng trong việc tối ưu hóa quy trình sản xuất thông thường đã được áp dụng cho lĩnh vực phần mềm.
12 nguyên tắc sau là cốt lõi của Agile:
+ Làm hài lòng khách hàng bằng cách phân phối sớm và liên tục các phần mềm có giá trị với họ.
+ Mọi thay đổi trong như cầu của khách hàng phải luôn được tiếp nhận, cho dù sự thay đổi diễn ra vào phút chót.
+ Phần mềm đang hoạt động vẫn phải luôn được đánh giá thường xuyên (theo ngày thay vì tuần).
+Trong suốt quá trình hoạt động, giữa khách hàng và lập trình viên phải luôn giữ liên lạc thường xuyên.
+Phải luôn động viên, tin tưởng lập trình viên để họ có thể hoàn thành công việc tốt hơn.
+Trao đổi trực tiếp mặt đối mặt hiệu quả hơn tất cả phương tiện giao tiếp nào khác.
+Cách duy nhất để đo lường tiến độ là một phần mềm đang hoạt động. Đây là điểm duy nhất mà người dùng cuối có thể đánh giá tiến trình của nhóm phát triển.
+Phát triển bền vững đòi hỏi phải có khả năng duy trì nhịp độ liên tục.
+ Phần mềm có kỹ thuật xuất sắc và thiết kế tốt luôn đòi hỏi phải sự thận trọng và sự chú ý liên tục.
+ Sự đơn giản, nghệ thuật tối đa hóa khối lượng công việc chưa hoàn thành, là điều cần thiết.
+ Một nhóm phải thường xuyên nêu ý kiến về cách trở nên hiệu quả hơn và điều chỉnh cho phù hợp.
Những nguyên lý cốt lõi này là nguồn gốc chính của Agile.
Mary Poppendieck và Tom Poppendieck đã viết "Lean Software Development: An Agile Toolkit" vào năm 2003, dựa trên các nguyên tắc Agile và nhiều năm kinh nghiệm phát triển phần mềm của họ. Cuốn sách này vẫn được coi là một trong những cuốn sách hay nhất về các ứng dụng thực tế của Agile.
Phát triển phần mềm dựa trên nguyên tắc Agile cho ra kết quả khác biệt hoàn toàn so với nguyên tắc Waterfall. Với Waterfall, một dự án chưa hoàn thiện không thể nào được triển khai. Nhưng đối với Agile,khung thời gian thay đổi: Agile sử dụng khoảng tăng thời gian nhỏ hơn (thường là 2 tuần), hoặc "sprint", bao gồm toàn bộ quá trình phân tích, thiết kế, coding và thử nghiệm nhưng trên một khía cạnh nhỏ của ứng dụng.
Mục tiêu là hoàn thành một tính năng cho mỗi sprint, do đó, với Agile, nếu bạn chỉ hoàn thành 40% dự án, bạn vẫn có 100% code có thể sử dụng được.
Bằng cách tận dụng Agile, bạn có thể liên tục gia tăng giá trị phần mềm và thích ứng nhanh với sự thay đổi.
Nếu một tính năng được đề xuất hoặc không còn cần thiết, thì dự án có thể nhanh chóng thực hiện những điều chỉnh đó.
CÁC MẪU THIẾT KẾ PHẦN MỀM PHỔ BIẾN
Khi chúng ta tạo ra các phần mềm, chúng ta thường sẽ gặp lại nhiều lần các vấn đề cần giải quyết. Dĩ nhiên chúng ta không muốn “phát minh lại bánh xe”. Trong kỹ thuật phần mềm, nhiều mẫu thiết kế phổ biến được tạo ra. Phần bài viết sẽ giới thiệu ba thiết kế rất hữu ích cho các dự án tự động hóa network automation: Mô hình thiết kế Model-View-Controller (MVC) và mô hình thiết kế Observer.
Mẫu thiết kế Model-View-Controller (MVC)
Mẫu MVC là một trong những mẫu thiết kế đầu tiên đi theo triết lý tách biệt các mối quan tâm hay các yêu cầu. Nguyên lý này được dùng để tách sự phụ thuộc lẫn nhau giữ các ứng dụng và tách biệt các chức năng giữa các thành phần. Mục tiêu là làm cho các tầng khác nhau của phần mềm ứng dụng độc lập với nhau (chẳng hạn như lớp truy cập dữ liệu, các chức năng tính toán, các chức năng hiển thị đến người dùng cuối). Chức năng modun này giúp cho các ứng dụng dễ xây dựng và bảo trì truy khi vẫn duy trì tính linh động cho sự thay đổi trong chức năng business. Mẫu thiết kế này cũng cung cấp một cấu trúc tổ chức tự nhiên cho một chương trình mà bất cứ ai cũng có thể tham gia và phát triển. Nếu bạn từng sử dụng một ứng dụng web, rất có thể ứng dụng web đó được xây dựng theo mô hình MVC.
Có một số web framework dùng khái niệm MVC với các ngôn ngữ lập trình. Angular, Express và Backbome được viết bằng JavaScripts. Django và Flash được viết bởi Python.
Mẫu thiết kế MVC cổ điển có ba thành phần chính:
Thành phần Mô hình (Model): chịu trách nhiệm truy cập và thao tác dữ liệu. Thành phần này thường liên quan đến cơ sở dữ liệu database nhưng cũng có thể đơn giản là dữ liệu từ một file. Thành phần này thực thi tất cả các tác vụ dữ liệu, chẳng hạn như chọn lựa, chèn, cập nhật và các thao tác xóa. Thành phần model sẽ nhận các lệnh từ Controller.
Thành phần View: Thành phần View là những gì người dùng cuối end-user thấy trên thiết bị khi họ tương tác với chương trình. Nó có thể là một trang web hoặc một đoạn văn bản từ một dòng lệnh. Điểm mạnh của view là nó có thể kết hợp với bất kỳ thiết bị nào hay với bất kỳ định dạng nào mà không thay đổi tính logic của thành phần model. Thành phần View sẽ tương tác với controller bằng cách gửi hoặc nhận dữ liệu từ thành phần model thông qua controller. Chức năng chính của view là để đưa ra dữ liệu.
Thành phần Controller: Thành phần này là trung gian giữa những gì người dùng thất và các chức năng luận lý backend phía sau khi thao tác dữ liệu. Vai trò của controller là nhận các yêu cầu từ người dùng thông qua View và sau đó chuyển các yêu cầu này đến model và các nơi lưu trữ dữ liệu bên dưới.
Thiết kế theo mẫu Observer
Mẫu thiết kế Obserer được tạo ra để giải quyết vấn đề chia sẽ thông tin giữa một đối tượng và một số đối tượng khác. Mẫu này được mô tả là rất hữu ích cho các hệ thống phân bố, trong đó cần chia sẻ các cấu hình hay các chi tiết về sự thay đổi khi nó xảy ra. Mẫu thiết kế này khá đơn giản và bao gồm hai thành phần luận lý:
Chủ thể Subject: thành phần subject ám chỉ đến đối tượng đang được quan sát, nói cách khác, dữ liệu đang được đồng bộ. Thành phần subject có một quá trình đăng ký cho phép các thành phần khác hay các ứng dụng khác đăng ký theo dõi vào tiến trình. Khi đã đăng ký, một thuê bao subscriber được gửi một thông tin cập nhật bất cứ khi nào có một thay đổi trong dữ liệu của subject sao cho hệ thống ở xa có thể đồng bộ dữ liệu.
Thành phần Observer: thành phần này sẽ đăng lý với subject để cho phép thành phần subject biết được observer và làm thế nào để giao tiếp với nó. Chức năng duy nhất của observer là đồng bộ dữ liệu với subject khi được gọi. Điểm mấu chốt để hiểu về observer là nó không dùng tiến trình polling. Các cập nhật chỉ được push từ subject đến observers.
