| Thành viên | Nội dung |
hoang
25 bài
| Nó bao gồm 5 bước theo mô hình water fall đơn giản thế thôi
|
hoang
25 bài
| 1. Requirement Specifications (Ðặc điểm kỹ thuật cần thiết)
Mặc dù khi trình bày các đề tài trong khoá này, ta chỉ sơ lược về các đặc điểm kỹ thuật cho các bài tập, bài làm ở nhà hay dự án nhưng ta có thể dựa vào đó mà linh động xắp xếp các đặc điểm kỹ thuật cần thiết phù hợp cho dự án của ta trong tương lai. Ngoài ra, ta có thể thêm bớt sao cho dự án của mình được thêm nhiều công dụng thích hợp yêu cầu đòi hỏi của khách hàng. Trên thực tế, Software Consultant phải phỏng vấn nhiều người trong công ty để có một hình ảnh đầy đủ vấn đề về Requirement Specifications.
|
hoang
25 bài
| 2. Design (Thiết kế)
Từ Requirement Specifications bước qua giai đoạn Thiết kế. Lúc nầy ta sẽ thấy có nhiều điểm không được nêu rõ trong Requirement Specifications và cần làm cho sáng tỏ (clarification) hơn. Công việc nầy do Systems Analyst thực hiện. Nếu dự án lớn thì có Software Architect thiết kế tổng quát trước khi chia ra các Team Leaders ( thường thường là Systems Analysts). Trong giai đoạn nầy có khi phải làm Prototype (thử mô hình mẫu) để biết chắc kỹ thuật mình dùng có đủ khả năng và thích hợp với nhu cầu dự án không. Thiết kế là giai đoạn quan trọng nhất trong chu kỳ phát triển một nhu liệu. Chẳng những ta nghĩ cách xây dựng nhu liệu, mà còn kế hoạch chi tiết cách thử lúc nào, ở đâu trong code. Ta phải tưởng tượng mọi hoàn cảnh bất thường (unusual scenarios) nhưng có thể xãy ra để tìm giải pháp đối phó. Trong các công ty nhỏ hoặc trung (small business), Web Master sẽ làm mọi chuyện từ ... 'cây kim' cho tới ... 'phi thuyền' khi thiết kế các trang ASP.NET.
|
hoang
25 bài
| 3. Coding hay Implementation (Thảo chương)
Ðây là giai đoạn thảo chương và debug. Trong phần Debug thì có Unit Test (thử từng bộ phận) và Integration Test (thử chung). Mỗi khi có sửa đổi một chút thì phải thử lại nhiều thứ nên nếu có thể viết Test Script để tự động hóa công việc thử nầy (gọi là Regression Test) thì tiết kiệm rất nhiều thời giờ. Nếu nhu liệu phải phản ứng nhanh chóng (good response) trong khi chạy Real-Time thì phải thử nó trong hoàn cảnh phải giải quyết nhiều thỉnh cầu cùng một lúc (gọi là Stress Test).
|
hoang
25 bài
| 4. Acceptance Test (Chạy Thử)
Khái niệm tổng quát về việc kiểm tra Functional and Acceptance Testing như sau:
Sự kiểm tra Functional and Acceptance Testing cũng đóng góp một phần rất quan trọng trong việc lập trình. Một cách tổng quát, trong nhiều kiểu kiểm tra thì sự kiểm tra về mặt chức năng (Functional Testing) giúp người triển khai kiểm soát lại xem phần lập trình ứng dụng đó có phù hợp với mọi chức năng đặt ra trước theo yêu cầu của dự án. Còn sự kiểm tra về mặt thừa nhận (Acceptance Testing) là để kiểm soát xem ứng dụng đó có phù hợp với hoàn cảnh hay môi trường sử dụng hay không, tỷ như chạy thử trong các nền Windows khác nhau, trong các phiên bản Browser khác nhau, trong các loại Browser khác nhau hay cùng phiên bản nhưng screen resolution khác nhau, ...
Trong nhiều trường hợp ở tại công ty của khách hàng, Software Consultant chứng kiến các giai đoạn chạy thử để xem nhu liệu xử lý mọi chuyện đúng như liệt kê trước đây. Các công chuyện xử lý chạy có nhanh đủ không, nhất là trong trường hợp nhu liệu phải giải quyết rất nhiều thỉnh cầu cùng một lúc. Trong những hoàn cảnh bất bình thường, nhu liệu có đứng vững không hay 'té' bất ngờ. Nếu dự án lớn, trước Acceptance Test còn có thêm một giai đoạn gọi là Factory Test khi Software Consultant đến tận công ty để chứng kiến ta chạy thử.
|
hoang
25 bài
| 5. Commissioning, Roll-Out (Áp dụng)
Khi cho áp dụng rồi là bắt đầu giai đoạn Bảo đảm (Warranty) và Bảo trì (Maintenance). Bảo trì là thăm viếng lại nhu liệu để chửa trị Bug (fixing bugs) hay sửa đổi (modification) hay làm thêm (enhancement). Lúc bấy giờ ta sẽ thấy giá trị của một nhu liệu được chú thích tỉ mĩ. Thường thường nhu liệu ta bảo trì là do người khác viết hoặc do chính mình viết từ lâu rồi, không còn nhớ nữa, nên nếu có kèm documentation và được chú thích rõ ràng thì công việc bảo trì sẽ dễ dàng hơn rất nhiều.
Khi lập trình cho một công việc hay dự án nhỏ, có khi ta không chú ý nhiều đến giai đoạn Requirement Specifications. Sau nầy lúc đã viết code rồi mới khám phá ra việc mình làm không đúng như điều khách hàng muốn thì rất phiền. Nếu Specifications đã viết rõ ràng thì ta có thể xin thêm tiền thay đổi (variation), nhưng có khi khách hàng vẫn trách là ta không chuyên nghiệp (professional) và có thể mình mất khách trong tương lai.
|
hoang
25 bài
| Thông thường anh em chúng ta chỉ nghĩ dến code nghĩa là giai đoạn thứ 3, nhưng ma không biết để làm được việc đó 1 cách chính xác các giai đoạn kia phải ngon mới làm được.
Nhưng mà cũng đúng một phần vì thời gian làm code là mất nhiều thời gian nhất trong tổng số các thời gian khác.
Đúng ra nếu ra ngoài đi làm thật thì thời gian đòi tiền cũng lâu chẳng kém và phải khéo nữa. Nhưng mà ít dự án tiến đến được giai đoạn đòi tiền suôn sẻ vì trong quá trình phân tích đã cãi nhau um của đội kỹ thuật. Đến giai đoạn thực hiện lại đội triển khai và khách hàng cãi nhau tiếp túm lại là khó suôn sẻ như mong đợi lắm bà con ạ !
hihi chỉ có bấy nhiêu chia sẻ với bà con
|
tancredi
1 bài
| 
|
 |