Phương pháp luận xây dựng phần mềm quản lý cổ đông cổ tức: Lập trình và lựa chọn ngôn ngữ lập trình phù hợp

Lập trình và lựa chọn ngôn ngữ lập trình sử dụng

Bước lập trình là một tiến trình dịch thiết kế chi tiết thành chương trình bao gồm các tập hợp các dòng mã lệnh máy tính có thể hiểu được. Mỗi ngôn ngữ lập trình có những giới hạn nhất định do vậy dựa trên các đặc trưng của ngôn ngữ, chúng ta sẽ chọn ngôn ngữ lập trình phù hợp với chương trình ứng dụng tránh lựa chọn sai dẫn đến phải hay đổi ngôn ngữ hoặc sửa đổi thiết kế hệ thống. Có bốn mức kiểm tra dữ liệu để đảm bảo sự phù hợp của dữ liệu được nhập vào với kiểu dữ liệu được định nghĩa trong các phép toán học và toán tử logic, từ không kiểm tra đến kiểm tra chặt.

Với những ngôn ngữ không cung cấp khả năng này, chương trình có thể bị treo do không có khả năng cung cấp, phát bộ nhớ lúc cần thiết. Phạm vi cấu trúc ngôn ngữ trong quản lý bộ nhớ, biến cục bộ/ tổng thể, quản lý chương trình con là sẵn dùng, nó quyết định tính hỗ trợ đa người dùng. Các đặc trưng của chương trình bao gồm sự kết cấu có cấu trúc, từ khoá và viết tắt, hàm có sẵn đã đơn giản hoá việc lập trình.

• Tính địa phương - cục bộ: là sự cung cấp sự phân đoạn tự nhiên của mã lệnh, làm đơn giản hoá việc học, trực quan hoá từng phần của vấn đề và có thể mô phỏng các giải pháp. Ví dụ như chương trình gốc có thể được chuyển từ bộ xử lý này sang bộ xử lý khác và từ chương trình biên dịch này sang chương trình biên dịch khác với rất ít hoặc không cần sửa đổi gì, chương trình gốc vẫn không thay đổi ngay cả khi môi trường của nó thay đổi như việc cài đặt mới hệ điều hành…. Công cụ này không những hỗ trợ trọng quá trình thiết kế mà còn hỗ trợ lập trình, sinh mã và nhiều công đoạn của quá trình sản xuất phần mềm.

Tóm lại, như chúng ta đã biết đặc thù của phần mềm quản lý cổ đông, cổ tức là kiểu ứng dụng thời gian thực và tập trung vào luồng dữ liệu vào ra. Do vậy những yêu cầu quan trọng của một ngôn ngữ trong chương trình quản lý cổ đông, cổ tức là phải hỗ trợ đa người dùng, quản lý được các kiểu dữ liệu như dữ.

Phong cách lập trình [3]

Thảo luận về dữ liệu thích hợp (như các biến quan trọng và những hạn chế, giới hạn về cách dùng chúng) và các thông tin quan trọng khác. Các chú thích chức năng được nhúng vào bên trong thân của chương trình gốc và được dùng để mô tả cho các khối chương trình. Thứ tự khai báo dữ liệu nên được chuẩn hoá cho dù ngôn ngữ lập trình không có yêu cầu bắt buộc nào về điều đó.

Các tên biến ngoài việc có nghĩa còn nên mang thông tin về kiểu của chúng. Ví dụ nên thống nhất các tên biến cho kiểu số nguyên, kiểu số thực… Cần phải chú giải về mục đích đối với các biến quan trọng, đặc biệt là các biến tổng thể. Các cấu trúc dữ liệu nên được chú giải đầy đủ về cấu trúc và chức năng, và các đặc thù về sử dụng.

Việc xây dựng câu lệnh nên tuân theo một quy tắc quan trọng hơn cả: mỗi câu lệnh nên đơn giản và trực tiếp. Cách xây dựng câu lệnh đơn và việc lùi trong lề minh hoạ cho các đặc trưng logic và chức năng của đoạn này. Dùng dấu cách và/ hoặc các ký hiệu dễ đọc để làm sáng tỏ nội dung câu lệnh.

Để hướng tới chương trình dễ hiểu luôn nên đặt ra câu hỏi: liệu có thể hiểu được điều này nếu ta không là người lập trình cho nó không?. Giữ cho định dạng thông tin vào thống nhất khi một ngôn ngữ lập trình có các yêu cầu định dạng nghiêm ngặt.

Kiểm tra và đảm bảo chất lượng phần mềm

Theo đó, giai đoạn này cũng được chia thành hai hoạt động riêng lẻ là kiểm thử phần mềm (software testing) nhằm tìm các sai sót trong khi vận hành chương trình. Trong một số tài liệu khác, quá trình này được chia thành hai công việc là xác định (verification) đảm bảo phần mềm theo đúng đặc tả, thiết kế và tìm các lỗi lập trình và thẩm định (validation) để đảm bảo phần mềm đáp ứng nhu cầu người dùng, hoạt động hiệu quả và phát hiện các lỗi phân tích, lỗi thiết kế (lỗi mức cao) [18]. • Kiểm tra tích hợp (Subsystem integration test): kiểm tra mặt logic và xử lý phù hợp của các khối, kiểm tra việc truyền tin giữa chúng.

• Kiểm tra hệ thống (System test): đánh giá xem các đặc tả chức năng có được đáp ứng không, các thao tác giao diện có giống thiết kế không…. • Kiểm tra chấp thuận (Acceptance testing): đây là bước kiểm tra cuối cùng trước khi phần mềm được đưa vào sử dụng và thường được tiến hành trên dữ liệu thực của khách hàng. Kiểm tra chấp thuận có thể phát hiện ra các lỗi bị bỏ qua trong các giai đoạn trước do sự khác nhau giữa dữ liệu thực và dữ liệu kiểm tra.

Chiến lược kiểm tra black - box cho rằng module liên quan đến đầu vào và đầu ra các chi tiết logic chi tiết được che dấu và không cần phân tích. Top - down coi chương trình chính là quan trọng nhất nên cần phải phát triển và kiểm tra trước và tiếp tục trong quá trình phát triển. Các chiến lược kiểm tra kể trên không loại trừ lẫn nhau, chúng có thể được sử dụng độc lập đồng thời nhằm phát hiện hết các lỗi tiềm ẩn.

Quá trình kiểm thử này được thực hiện ngay trên chương trình, cần có mã nguồn từ đó sẽ xác định được các lỗi lập trình, đánh giá được tính hiệu quả của. Thu thập, kiểm soát các dữ liệu liên quan đến các hoạt động test Tính toán, phân tích các chi tiêu liên quan đến các hoạt động test.

Triển khai và đào tạo sử dụng

Xây dựng hướng dẫn test (bản thiết kế test, kịch bản test) Thực hiện test. Hỗ trợ các vấn đề liên quan đến test Báo cáo và tổng hợp kết quả test. Các bước công việc của bộ phận Test được thực hiện song song với các bước trong quá trình phát triển phần mềm (hình 2.10).

CÁC BƯỚC KHÁC TRONG QUÁ TRÌNH PHÁT TRIỂN PHẦN MỀM CÁC BƯỚC KHÁC TRONG QUÁ TRÌNH PHÁT TRIỂN PHẦN MỀM. Đào tạo người sử dụng là một hoạt động không thể thiếu trong quá trình triển khai bất kỳ một phần mềm nào. Mục tiêu của công tác này là người dùng được cổ đông, cổ tức để điều hành trôi chảy hệ thống mới, thông báo một số tình huống có thể gặp lỗi khi vận hành sản phẩm để người dùng biết cách xử trí.

Đào tạo không chỉ bao gồm các hoạt động nhập dữ liệu, lập báo cáo mà còn phải giúp người dùng. Đối với công tác tin học hoá các nghiệp vụ quản lý cổ đông, cổ tức, đây không chỉ là chuyển đổi phần mềm quản lý trong các phòng ban liên quan từ các tài liệu thiếu hệ thống, phân tán sang một hệ CSDL trong máy tính mà còn là sự thay đổi tư duy của người sử dụng. Những người sử dụng cần được đào tạo về những cách thức cụ thể trong công việc, giải thích các quy trình nghiệp vụ thủ công thay đổi như thế nào khi được thực hiện bằng phần mềm.

Tuy vậy, đào tạo cũng là một yếu tố mang tính chủ quan cao nên đòi hỏi phải có một phương pháp luận khoa học và dễ hiểu.

Bảo trì phần mềm

Yêu cầu thay đổiPhân tích các tác độngLập kế hoạch sửa đổi Triển khai sửa đổi Vận hành hệ thống. Hoạt động này chiếm hầu hết các công sức tiêu tốn cho việc bảo trì phần mềm. • Bảo trì phòng ngừa : phần mềm cần được thay đổi để cải thiện tính năng bảo trì hay độ tin cậy trong tương lai hoặc để cung cấp một nền tảng tốt hơn cho những mở rộng sau này.

Quá trình bảo trì thường xuất phát từ một tập hợp các yêu cầu thay đổi của người dùng hệ thống. Khi những thay đổi này được chấp nhận, kế hoạch phát triển hệ thống sẽ được xây dựng. Công nghệ bảo trì đưa ra chìa khoá để cải tiến năng suất bảo trì.

Với những thiết kế cẩn thận, sự cung cấp tài liệu kỹ lưỡng và một loạt các phương pháp kiểm tra hoàn thiện, các lỗi sẽ dễ dàng được chuẩn đoán và hiệu chỉnh khi chúng xảy ra, phần mềm sẽ dễ sửa.