Get trong phân tính thiết kế hệ thống là gì năm 2024
Để giải quyết vấn đề đó, trước hết chúng ta hãy hiểu các quá trình của phát triển phần mềm. Vui lòng xem hình bên dưới "Quy trình phát triển phần mềm" Show Phần lập trình mà chúng ta vẫn hay học tương ứng với phần "Thực hiện". Như vậy, có tới bốn quá trình cần thực hiện trước khi bạn có thể thể hiện kỹ năng lập trình của mình. Vì vậy, trong bài viết này, tôi sẽ trình bày về điều cần thiết trước khi bắt đầu thực hiện lập trình đó là các bước từ "Lập kế hoạch ~ Thiết kế". Đặc biệt, chúng ta sẽ tập trung vào việc "Định nghĩa yêu cầu" và "Thiết kế" mà các kỹ sư phần mềm nên hiểu. Người ta nói rằng thời gian được sử dụng để thực hiện lập trình trong toàn bộ quá trình phát triển là 20 đến 30% tổng thời gian. Mặt khác, 50% tổng số thời gian được sử dụng cho các quy trình phía trên (tiếng Nhật gọi là 上流工程) như là xác định yêu cầu và thiết kế. Nói cách khác, những cá nhân có thể thực hiện việc Định nghĩa yêu cầu và Thiết kế chắc chắn sẽ đóng góp nhiều hơn cho các dự án phát triển. Hãy đọc bài viết này để hiểu được nó và nâng cao đóng góp của bản thân trong công việc. Bài viết này bao gồm những phần sau:
Sự quan trọng của Định nghĩa yêu cầuCó hai nhóm tham gia vào các dự án phát triển hệ thống.
Nếu bạn muốn tạo ra hệ thống mà bạn muốn, không có vấn đề gì vì bạn đã có hình ảnh hoàn chỉnh về những gì bạn muốn làm trong đầu. Trong nhiều trường hợp đó là việc phát triển sẽ theo yêu cầu "Người đặt hàng ⇒ Nhà phát triển". Khi đó, Nhà phát triển không biết phải làm sao nếu không làm rõ được hình ảnh trong đầu người đặt hàng. Các định nghĩa yêu cầu tồn tại cho nhằm mục đích hỗ trợ cho việc giao tiếp này. Hãy so sánh nó với cuộc sống hàng ngày. Khi bạn khát nước, bạn có yêu cầu người khác là "Hãy mua đồ uống đi!” không? Nếu bạn không nói là "Hãy mua cà phê đi" hay cụ thể hơn là "Mua cà phê đường hảo hạng nóng. Đó là chai nhựa chứ không phải lon!" thì bạn sẽ không thể được mua hộ món cà phê mà bạn mong muốn. Phát triển hệ thống cũng vậy. Mục đích của định nghĩa yêu cầu là để thống nhất rõ ràng rằng“Tôi cần làm gì để khách hàng hài lòng?". Tóm lại, Tốt nhất nên có một Định nghĩa yêu cầu = Danh sách những mục đã được thống nhất trước để khi giao hàng người đặt hàng có thể kiểm tra theo và xác nhận rằng "Làm thế này là ổn rồi nhé". Quy trình xác định định nghĩa yêu cầuBây giờ bạn đã biết mục đích của Định nghĩa yêu cầu, hãy tìm hiểu ba bước để hoàn thành Định nghĩa yêu cầu.
Giao tiếp thông qua "Kiểm tra" và "Đề xuất" là cần thiết cho quá trình ba bước này. Nó sẽ như sau khi sắp xếp theo thứ tự.
Các vấn đề cần được quyết định trong Định nghĩa yêu cầuBây giờ bạn đã biết quy trình, hãy sắp xếp sơ bộ các vấn đề sẽ được quyết định trong Định nghĩa yêu cầu. Nếu bạn tổ chức lại nó bằng cách sử dụng 3W (Why, What, How), nội dung sẽ được sắp xếp gọn gàng.
Cách thiết kế cơ bản (thiết kế màn hình, thiết kế chức năng, thiết kế dữ liệu)Bạn có thể tưởng tượng rằng có rất nhiều thứ cần quyết định trong định nghĩa yêu cầu, nhưng đừng lo lắng. Phần What (Quy trình kinh doanh, Yêu cầu chức năng, Yêu cầu phi chức năng) thì không phải là kỹ sư, mà có xu hướng được giải quyết bởi các “Nhân viên kinh doanh” và “Sales engineer”. Do đó, chúng ta sẽ tìm hiểu sâu hơn về phần How (thiết kế), nơi mà các kỹ sư thể hiện khả năng của họ. Trong số đó, thiết kế cơ bản là chủ đạo, vì vậy bài viết này sẽ tập trung vào điều đó. Như đã đề cập ở trên, trong thiết kế cơ bản, "màn hình / chức năng / dữ liệu" được thiết kế. Chỉ khi có những điều này thì một lập trình viên mới có thể bắt đầu phát triển phần mềm. |