Xây dựng các thông số kỹ thuật cho hệ thống thông tin. Thiết kế và phát triển hệ thống thông tin sử dụng ví dụ về cửa hàng Computer Master

Tôi thường được hỏi: “Làm thế nào để phát triển chính xác các thông số kỹ thuật cho hệ thống tự động?” Một chủ đề tương tự liên tục được thảo luận trên các diễn đàn khác nhau. Câu hỏi này rộng đến mức không thể trả lời một cách ngắn gọn. Vì vậy, tôi quyết định viết một bài dài về chủ đề này.

Ở phần đầu tiên" Phát triển các thông số kỹ thuật. Nó là gì, tại sao cần thiết, bắt đầu từ đâu và nó trông như thế nào? Tôi sẽ cố gắng trả lời chi tiết các câu hỏi của chủ đề, xem xét cấu trúc và mục đích của Điều khoản tham chiếu và đưa ra một số khuyến nghị về việc xây dựng các yêu cầu.
Phần thứ hai" Phát triển các thông số kỹ thuật. Cách xây dựng các yêu cầu? sẽ hoàn toàn dành cho việc xác định và hình thành các yêu cầu cho một hệ thống thông tin.

Trước tiên, bạn cần tìm ra câu hỏi nào thực sự thu hút những người hỏi “Làm thế nào để phát triển một đặc tả kỹ thuật?” Thực tế là cách tiếp cận để phát triển các thông số kỹ thuật sẽ phụ thuộc rất nhiều vào mục đích thực hiện cũng như đối tượng sử dụng. Tôi đang nói về những lựa chọn nào:

Một tổ chức thương mại quyết định triển khai một hệ thống tự động. Nó không có dịch vụ CNTT riêng và quyết định thực hiện việc này: Bên quan tâm phải phát triển Thông số kỹ thuật và gửi nó để phát triển cho bên thứ ba;
Một tổ chức thương mại quyết định triển khai một hệ thống tự động. Nó có dịch vụ CNTT riêng. Chúng tôi đã quyết định thực hiện việc này: phát triển Thông số kỹ thuật, sau đó thống nhất về nó giữa dịch vụ CNTT và các bên quan tâm và tự mình triển khai nó;
Cơ quan chính phủ quyết định khởi động một dự án CNTT. Mọi thứ ở đây thật âm u, nhiều thủ tục, lại quả, cắt giảm, v.v. Tôi sẽ không xem xét lựa chọn này trong bài viết này.
Một công ty CNTT cung cấp dịch vụ phát triển và/hoặc triển khai các hệ thống tự động. Đây là trường hợp khó khăn nhất, vì bạn phải làm việc trong nhiều điều kiện khác nhau:
- Khách hàng có các chuyên gia riêng có quan điểm riêng và họ đưa ra các yêu cầu cụ thể cho Thông số kỹ thuật;
- Các điều khoản tham chiếu được phát triển cho các nhà phát triển nội bộ (khách hàng không quan tâm);
- Các điều khoản tham chiếu được phát triển để chuyển giao cho nhà thầu (tức là một nhóm lập trình viên trong đội ngũ nhân viên của công ty hoặc một chuyên gia cá nhân);
- Có sự hiểu lầm nảy sinh giữa công ty và khách hàng về kết quả thu được và công ty liên tục đặt ra câu hỏi: “Thông số kỹ thuật nên được phát triển như thế nào?” Trường hợp cuối cùng có vẻ như là một nghịch lý nhưng nó lại là sự thật.
- Các lựa chọn khác ít phổ biến hơn cũng có thể thực hiện được;

Tôi nghĩ bây giờ người đọc sẽ có câu hỏi:

Tại sao Thông số kỹ thuật không thể luôn được phát triển theo cùng một cách?;
Có tiêu chuẩn, phương pháp, khuyến nghị nào không? Tôi có thể lấy chúng ở đâu?
Ai nên phát triển Điều khoản tham chiếu? Người này có nên có kiến thức đặc biệt gì không?
Làm thế nào để hiểu được Điều khoản tham chiếu có được viết tốt hay không?
Ai nên phát triển nó với chi phí của ai, và liệu nó có cần thiết không?

Danh sách này có thể là vô tận. Tôi tự tin nói điều này vì tôi đã làm việc trong lĩnh vực phát triển phần mềm chuyên nghiệp được 15 năm và câu hỏi về Thông số kỹ thuật luôn xuất hiện trong bất kỳ nhóm phát triển nào mà tôi làm việc cùng. Những lý do cho điều này là khác nhau. Nêu lên chủ đề phát triển Điều khoản tham chiếu, tôi biết rõ rằng tôi sẽ không thể trình bày nó 100% cho tất cả những người quan tâm đến chủ đề này. Tuy nhiên, tôi sẽ cố gắng, như người ta nói, “sắp xếp mọi thứ”. Những người đã quen thuộc với các bài viết của tôi đều biết rằng tôi không sử dụng tính năng “sao chép-dán” tác phẩm của người khác, không in lại sách của người khác, không trích dẫn các tiêu chuẩn nhiều trang và các tài liệu khác mà bạn có thể tìm thấy trên Internet, biến chúng thành những suy nghĩ thiên tài của riêng bạn. Chỉ cần gõ vào công cụ tìm kiếm “Cách phát triển Thông số kỹ thuật” và bạn có thể đọc được rất nhiều điều thú vị, nhưng thật không may, lại lặp đi lặp lại. Theo quy định, những người thích khéo léo trên các diễn đàn (cứ thử tìm kiếm nhé!) chưa bao giờ tự mình đưa ra Thông số kỹ thuật phù hợp và liên tục trích dẫn các khuyến nghị của GOST về vấn đề này. Và những người thực sự nghiêm túc với vấn đề này thường không có thời gian ngồi trên diễn đàn. Nhân tiện, chúng ta cũng sẽ nói về các tiêu chuẩn GOST. Trong nhiều năm làm việc của mình, tôi đã thấy nhiều phiên bản tài liệu kỹ thuật được biên soạn bởi các cá nhân chuyên gia cũng như các nhóm và công ty tư vấn nổi tiếng. Đôi khi tôi cũng tham gia vào hoạt động này: Tôi phân bổ thời gian cho bản thân và tìm kiếm thông tin về chủ đề quan tâm từ những nguồn khác thường (chẳng hạn như một chút trí thông minh). Kết quả là tôi phải xem tài liệu về những con quái vật như GazProm, Đường sắt Nga và nhiều công ty thú vị khác. Tất nhiên, tôi tuân thủ chính sách bảo mật, bất chấp thực tế là những tài liệu này đến với tôi từ các nguồn công khai hoặc sự vô trách nhiệm của các nhà tư vấn (tung tán thông tin trên Internet). Vì vậy, tôi xin nói ngay: Tôi không chia sẻ thông tin mật của công ty khác, bất kể nguồn nào (đạo đức nghề nghiệp).

Thông số kỹ thuật là gì?

Điều đầu tiên chúng ta sẽ làm bây giờ là tìm hiểu xem “Thông số kỹ thuật” này là loại quái thú gì.

Có, thực sự có các GOST và tiêu chuẩn cố gắng điều chỉnh phần hoạt động này (phát triển phần mềm). Ngày xửa ngày xưa, tất cả các GOST này đều có liên quan và được sử dụng tích cực. Hiện nay có nhiều ý kiến khác nhau về mức độ liên quan của các tài liệu này. Một số người cho rằng GOST được phát triển bởi những người có tầm nhìn xa và vẫn còn phù hợp. Những người khác nói rằng họ đã lỗi thời một cách vô vọng. Có lẽ giờ đây ai đó đã nghĩ rằng sự thật nằm ở đâu đó ở giữa. Tôi sẽ trả lời theo lời của Goethe: “Người ta nói rằng giữa hai ý kiến đối lập nhau thì có sự thật. Không có trường hợp nào! Giữa họ có vấn đề." Vì vậy, không có sự thật giữa những ý kiến này. Bởi vì GOST không bộc lộ những vấn đề thực tế của sự phát triển hiện đại và những người chỉ trích chúng không đưa ra những giải pháp thay thế (cụ thể và có hệ thống).

Lưu ý rằng GOST rõ ràng thậm chí không đưa ra định nghĩa mà chỉ nói: “TK cho nhà máy điện hạt nhân là tài liệu chính xác định các yêu cầu và quy trình tạo ra (phát triển hoặc hiện đại hóa - sau đó tạo ra) một hệ thống tự động, theo đó việc phát triển một nhà máy điện hạt nhân được thực hiện và sự chấp nhận của nó khi đưa vào hoạt động."

Nếu có ai quan tâm đến GOST mà tôi đang nói đến thì đây là:

GOST 2.114-95 Hệ thống tài liệu thiết kế thống nhất. Thông số kỹ thuật;
GOST 19.201-78 Hệ thống tài liệu chương trình thống nhất. Nhiệm vụ kỹ thuật. Yêu cầu về nội dung và thiết kế;
GOST 34.602-89 Công nghệ thông tin. Bộ tiêu chuẩn cho hệ thống tự động. Điều khoản tham chiếu cho việc tạo ra một hệ thống tự động.

Một định nghĩa tốt hơn nhiều được trình bày trên Wikipedia (mặc dù về các thông số kỹ thuật nói chung và không chỉ dành cho phần mềm): “ Nhiệm vụ kỹ thuật– đây là tài liệu thiết kế gốc kỹ thuật sự vật. Nhiệm vụ kỹ thuật thiết lập mục đích chính của đối tượng đang được phát triển, các đặc tính kỹ thuật và chiến thuật-kỹ thuật, chỉ số chất lượng và yêu cầu kinh tế kỹ thuật, hướng dẫn hoàn thành các giai đoạn cần thiết trong việc tạo tài liệu (thiết kế, công nghệ, phần mềm, v.v.) và thành phần của nó, như cũng như những yêu cầu đặc biệt. Nhiệm vụ như một tài liệu ban đầu để tạo ra một cái gì đó mới tồn tại trong mọi lĩnh vực hoạt động, khác nhau về tên, nội dung, trình tự thực hiện, v.v. (ví dụ: nhiệm vụ thiết kế trong xây dựng, nhiệm vụ chiến đấu, bài tập về nhà, hợp đồng xây dựng). một tác phẩm văn học, v.v.). d.)"

Và do đó, như sau định nghĩa, mục đích chính của Thông số kỹ thuật là hình thành các yêu cầu đối với đối tượng đang được phát triển, trong trường hợp của chúng tôi, đối với một hệ thống tự động.

Đó là điều chính, nhưng là điều duy nhất. Đã đến lúc đi vào vấn đề chính: đặt mọi thứ “lên kệ”, như đã hứa.

Bạn cần biết gì về các yêu cầu? Cần phải hiểu rõ ràng rằng tất cả các yêu cầu phải được chia theo loại và tính chất. Bây giờ chúng ta sẽ học cách làm điều này. Để phân tách các yêu cầu theo loại, GOST sẽ giúp chúng tôi. Danh sách các loại yêu cầu được trình bày là một ví dụ điển hình về những loại yêu cầu cần được xem xét. Ví dụ:

Yêu cầu về chức năng;
Yêu cầu về bảo mật và quyền truy cập;
Yêu cầu về trình độ nhân sự;
…. Vân vân. Bạn có thể đọc về chúng trong GOST đã đề cập (và bên dưới tôi cũng sẽ xem xét chúng chi tiết hơn một chút).

Tôi nghĩ bạn thấy rõ ràng rằng yếu tố then chốt tạo nên một Đặc tả Kỹ thuật thành công là các yêu cầu về chức năng được xây dựng chính xác và chính xác. Hầu hết các công việc và phương pháp mà tôi nói đến đều dành cho những yêu cầu này. Yêu cầu về chức năng chiếm 90% mức độ phức tạp của công việc phát triển Điều khoản tham chiếu. Mọi thứ khác thường là “ngụy trang” để che đậy những yêu cầu này. Nếu các yêu cầu được đưa ra không tốt thì cho dù bạn có ngụy trang đẹp đẽ thế nào đi chăng nữa thì một dự án thành công cũng sẽ không thành công. Có, về mặt chính thức, tất cả các yêu cầu sẽ được đáp ứng (theo GOST J), thông số kỹ thuật đã được phát triển, phê duyệt và ký kết và tiền đã được nhận cho nó. Vậy thì sao? Và sau đó phần thú vị nhất bắt đầu: phải làm gì? Nếu đây là một dự án theo Lệnh của Nhà nước thì không có vấn đề gì - ngân sách ở đó không vừa với túi tiền của bất kỳ ai và trong quá trình thực hiện (nếu có), mọi thứ sẽ được làm rõ. Đây chính xác là cách mà phần lớn ngân sách dự án được chi cho các Đơn đặt hàng của Nhà nước (họ viết nguệch ngoạc “TZ”, mất hàng chục triệu, nhưng không thực hiện dự án. Mọi thủ tục đều được tuân thủ, không có bên nào có tội, một chiếc xe mới ở gần ngôi nhà. Vẻ đẹp!). Nhưng chúng ta đang nói về các tổ chức thương mại, nơi tiền được tính và cần một kết quả khác. Vì vậy, chúng ta hãy hiểu điều chính, làm thế nào để phát triển Thông số kỹ thuật hữu ích và hoạt động.

Tôi đã nói về các loại yêu cầu, nhưng còn tài sản thì sao? Nếu các loại yêu cầu có thể khác nhau (tùy thuộc vào mục tiêu của dự án), thì với các thuộc tính, mọi thứ sẽ đơn giản hơn, có 3 trong số đó:

Yêu cầu phải được có thể hiểu được;
Yêu cầu phải được cụ thể;
Yêu cầu phải được người làm bài kiểm tra;

Hơn nữa, thuộc tính cuối cùng là không thể nếu không có hai thuộc tính trước đó, tức là. là một loại “thử giấy quỳ”. Nếu kết quả của một yêu cầu không thể được kiểm tra, điều đó có nghĩa là nó không rõ ràng hoặc không cụ thể. Hãy nghĩ về nó. Sự nắm vững ba đặc tính này của yêu cầu thể hiện sự thành thạo và tính chuyên nghiệp. Nó thực sự rất đơn giản. Khi bạn tìm ra nó.

Điều này kết thúc câu chuyện về Đặc tả kỹ thuật là gì và chuyển sang vấn đề chính: cách xây dựng các yêu cầu. Nhưng nó không nhanh như vậy. Còn một điểm cực kỳ quan trọng nữa:

Thông số kỹ thuật nên được viết bằng ngôn ngữ nào (về mức độ khó hiểu)?
Nó có nên mô tả các thông số kỹ thuật của các chức năng, thuật toán, kiểu dữ liệu và những thứ kỹ thuật khác không?
Nhân tiện, thiết kế kỹ thuật là gì, cũng được đề cập trong GOST và nó liên quan như thế nào đến Thông số kỹ thuật?

Có một điều rất xảo quyệt ẩn giấu trong câu trả lời cho những câu hỏi này. Đó là lý do tại sao các tranh chấp thường nảy sinh về tính đầy đủ hoặc thiếu chi tiết cần thiết của các yêu cầu, về tính dễ hiểu của tài liệu đối với Khách hàng và Nhà thầu, về sự dư thừa, hình thức trình bày, v.v. Đâu là ranh giới giữa Điều khoản tham chiếu và Dự án kỹ thuật?

Nhiệm vụ kỹ thuật– đây là tài liệu dựa trên các yêu cầu được xây dựng bằng ngôn ngữ dễ hiểu (thông thường, quen thuộc) đối với Khách hàng. Trong trường hợp này, thuật ngữ ngành mà Khách hàng có thể hiểu được có thể và nên được sử dụng. Không nên có mối liên hệ nào với các chi tiết cụ thể của việc triển khai kỹ thuật. Những thứ kia. về nguyên tắc, ở giai đoạn đặc tả kỹ thuật, việc thực hiện các yêu cầu này trên nền tảng nào không quan trọng. Mặc dù có những trường hợp ngoại lệ. Nếu chúng ta đang nói về việc triển khai một hệ thống dựa trên một sản phẩm phần mềm đã có sẵn thì mối liên kết đó có thể diễn ra nhưng chỉ ở cấp độ biểu mẫu màn hình, biểu mẫu báo cáo, v.v. Việc làm rõ và xây dựng các yêu cầu cũng như quá trình phát triển của Điều khoản tham chiếu phải được thực hiện phân tích kinh doanh. Và chắc chắn không phải là một lập trình viên (trừ khi anh ta kết hợp những vai trò này lại, điều này sẽ xảy ra). Những thứ kia. người này phải nói chuyện với Khách hàng bằng ngôn ngữ kinh doanh của mình.

Dự án kỹ thuật– đây là tài liệu nhằm mục đích thực hiện kỹ thuật các yêu cầu được nêu trong Điều khoản tham chiếu. Tài liệu này mô tả cấu trúc dữ liệu, trình kích hoạt và thủ tục lưu trữ, thuật toán và những thứ khác sẽ được yêu cầu chuyên gia kỹ thuật. Khách hàng hoàn toàn không cần phải tìm hiểu sâu về vấn đề này (ngay cả những điều khoản như vậy cũng có thể không rõ ràng đối với anh ta). Dự án kỹ thuật làm Kiến trúc hệ thống(kết hợp vai trò này với lập trình viên là điều khá bình thường). Hay đúng hơn là một nhóm chuyên gia của CTCP do một kiến trúc sư đứng đầu. Dự án càng lớn thì càng có nhiều người làm việc theo Điều khoản tham chiếu.

Chúng ta có gì trong thực tế? Thật buồn cười khi xem giám đốc đưa ra một đặc tả kỹ thuật để phê duyệt, trong đó có đầy đủ các thuật ngữ kỹ thuật, mô tả về các loại dữ liệu và giá trị của chúng, cấu trúc cơ sở dữ liệu, v.v. Tất nhiên, anh ấy cố gắng hiểu vì anh ấy cần phê duyệt , cố gắng tìm kiếm những từ ngữ quen thuộc giữa các dòng và không làm mất đi yêu cầu kinh doanh theo chuỗi. Đây có phải là một tình huống quen thuộc? Và nó kết thúc như thế nào? Theo quy định, các thông số kỹ thuật như vậy được phê duyệt, sau đó được triển khai và trong 80% trường hợp, chúng hoàn toàn không tương ứng với thực tế công việc được thực hiện, bởi vì họ quyết định thay đổi, làm lại rất nhiều thứ, hiểu lầm, nghĩ sai, v.v. và như thế. Và sau đó loạt bài về việc nộp bài bắt đầu. “Nhưng đây không phải là thứ chúng tôi cần,” mà là “cái này không phù hợp với chúng tôi”, “cái này quá phức tạp”, “điều này thật bất tiện”, v.v. Nghe có vẻ quen?!! Điều đó đã quá quen thuộc với tôi, tôi phải va chạm đúng lúc.

Vậy thực tế chúng ta có gì? Nhưng trên thực tế, chúng tôi có ranh giới mờ nhạt giữa Điều khoản tham chiếu và Dự án kỹ thuật. Cô ấy lơ lửng giữa TK và TP với nhiều biểu hiện khác nhau. Và điều đó thật tệ. Điều này xảy ra là do văn hóa phát triển đã trở nên yếu kém. Điều này một phần là do năng lực của các chuyên gia, một phần là do mong muốn giảm ngân sách và thời hạn (xét cho cùng, việc lập hồ sơ mất rất nhiều thời gian - đó là sự thật). Có một yếu tố quan trọng khác ảnh hưởng đến việc sử dụng Thiết kế kỹ thuật như một tài liệu riêng biệt: sự phát triển nhanh chóng của các công cụ phát triển nhanh chóng cũng như các phương pháp phát triển. Nhưng đây là một câu chuyện riêng, tôi sẽ nói vài lời về nó bên dưới.

Một điểm nhỏ nhưng quan trọng khác. Đôi khi Điều khoản tham chiếu được gọi là một phần yêu cầu nhỏ, đơn giản và dễ hiểu. Ví dụ: cải thiện việc tìm kiếm một đối tượng theo một số điều kiện, thêm một cột vào báo cáo, v.v. Cách tiếp cận này khá hợp lý, tại sao lại làm phức tạp cuộc sống. Nhưng nó không được sử dụng cho các dự án lớn mà cho những cải tiến nhỏ. Tôi có thể nói điều này gần với việc bảo trì sản phẩm phần mềm hơn. Trong trường hợp này, Điều khoản tham chiếu cũng có thể mô tả một giải pháp kỹ thuật cụ thể để thực hiện yêu cầu. Ví dụ: “Thực hiện thay đổi như vậy đối với thuật toán như vậy”, chỉ ra một quy trình cụ thể và một thay đổi cụ thể cho người lập trình. Đây là trường hợp ranh giới giữa Điều khoản tham chiếu và Dự án kỹ thuật bị xóa bỏ hoàn toàn, bởi vì không có tính khả thi về mặt kinh tế khi thổi phồng giấy tờ khi không cần thiết, nhưng một tài liệu hữu ích sẽ được tạo ra. Và nó đúng.

Thông số kỹ thuật có cần thiết không? Còn Dự án Kỹ thuật thì sao?

Tôi có quá nóng không? Điều này có thể thực hiện được mà không cần bất kỳ Thông số kỹ thuật? Hãy tưởng tượng điều đó là có thể (hay đúng hơn là có thể), và cách tiếp cận này có nhiều người theo dõi và số lượng của họ ngày càng tăng. Theo quy định, sau khi các chuyên gia trẻ đã đọc sách về Scrum, Agile và các công nghệ phát triển nhanh chóng khác. Trên thực tế, đây là những công nghệ tuyệt vời và hoạt động được nhưng chúng không có nghĩa đen là “không cần thực hiện các nhiệm vụ kỹ thuật”. Họ nói “tối thiểu giấy tờ”, đặc biệt là những giấy tờ không cần thiết, gần gũi hơn với Khách hàng, cụ thể hơn và kết quả nhanh hơn. Nhưng không ai hủy bỏ việc ghi lại các yêu cầu, và điều này được nêu rõ ở đó. Ở đó các yêu cầu được cố định dựa trên ba đặc tính đáng chú ý mà tôi đã đề cập ở trên. Chỉ là tâm trí của một số người được cấu trúc theo cách mà nếu điều gì đó có thể được đơn giản hóa thì hãy đơn giản hóa nó đến mức hoàn toàn không có. Như Einstein đã nói " Hãy làm cho nó đơn giản nhất có thể, nhưng không đơn giản hơn thế." . Đây là những lời vàng đi cùng với mọi thứ. Vì thế Nhiệm vụ kỹ thuật cần thiết, nếu không bạn sẽ không thấy một dự án thành công. Một câu hỏi khác là làm thế nào để soạn nó và những gì cần đưa vào đó. Dưới ánh sáng của các phương pháp phát triển nhanh chóng, bạn chỉ cần tập trung vào các yêu cầu và tất cả những “ngụy trang” đều có thể bị loại bỏ. Về nguyên tắc, tôi đồng ý với điều này.

Còn Dự án Kỹ thuật thì sao? Tài liệu này rất hữu ích và không mất đi tính liên quan của nó. Hơn nữa, thường thì bạn không thể làm gì nếu không có nó. Đặc biệt là khi nói đến công việc phát triển gia công phần mềm, tức là. theo nguyên tắc thuê ngoài. Nếu không làm điều này, bạn có nguy cơ phải học hỏi rất nhiều về hệ thống mà bạn dự định sẽ trông như thế nào. Khách hàng có nên làm quen với nó không? Nếu anh ta muốn thì tại sao không, nhưng cũng không cần phải nài nỉ và phê duyệt văn bản này, nó sẽ chỉ kìm hãm, cản trở công việc mà thôi. Hầu như không thể thiết kế một hệ thống đến từng chi tiết nhỏ nhất. Trong trường hợp này, bạn sẽ phải liên tục thực hiện các thay đổi đối với Thiết kế kỹ thuật, việc này mất rất nhiều thời gian. Và nếu tổ chức có tính quan liêu nặng nề thì bạn sẽ để mọi lo lắng của mình ở đó. Giảm thiểu kiểu thiết kế này chính xác là những gì mà các phương pháp phát triển nhanh chóng hiện đại mà tôi đã đề cập ở trên hướng tới. Nhân tiện, tất cả chúng đều dựa trên XP cổ điển (lập trình cực đoan) - một cách tiếp cận đã có tuổi đời khoảng 20 năm. Vì vậy, hãy tạo Thông số kỹ thuật chất lượng cao mà Khách hàng có thể hiểu được và sử dụng Thiết kế kỹ thuật làm tài liệu nội bộ cho mối quan hệ giữa kiến trúc sư hệ thống và người lập trình.

Một chi tiết thú vị về thiết kế kỹ thuật: một số công cụ phát triển được thiết kế theo nguyên tắc thiết kế hướng chủ đề (chẳng hạn như 1C và tương tự) cho rằng thiết kế (nghĩa là quy trình tài liệu) chỉ được yêu cầu trong các khu vực thực sự phức tạp, nơi cần có sự tương tác giữa toàn bộ hệ thống con. Trong trường hợp đơn giản nhất, chẳng hạn như tạo một thư mục hoặc tài liệu, chỉ những yêu cầu kinh doanh được xây dựng chính xác là đủ. Điều này cũng được chứng minh qua chiến lược kinh doanh của nền tảng này về mặt đào tạo chuyên gia. Nếu nhìn vào phiếu thi của một chuyên gia (người ta gọi vậy chứ không phải “lập trình viên”), bạn sẽ thấy chỉ có những yêu cầu nghiệp vụ, còn việc triển khai chúng bằng ngôn ngữ chương trình như thế nào là nhiệm vụ của chuyên gia. Những thứ kia. Đó là một phần của vấn đề mà Dự án kỹ thuật dự định giải quyết, chuyên gia phải giải quyết “trong đầu” (chúng ta đang nói về các nhiệm vụ có độ phức tạp trung bình), tại đây và bây giờ, tuân theo các tiêu chuẩn thiết kế và phát triển nhất định, một lần nữa được hình thành bởi công ty 1C cho nền tảng của nó. Vì vậy, trong số hai chuyên gia có kết quả công việc giống hệt nhau, một người có thể vượt qua kỳ thi, còn người kia thì không, vì vi phạm trắng trợn các tiêu chuẩn phát triển. Nghĩa là, rõ ràng người ta giả định rằng các chuyên gia phải có trình độ chuyên môn đến mức họ có thể thiết kế các nhiệm vụ điển hình một cách độc lập, không có sự tham gia của các kiến trúc sư hệ thống. Và cách tiếp cận này hiệu quả.

Hãy tiếp tục nghiên cứu câu hỏi: “Điều khoản tham chiếu cần đưa những yêu cầu gì?”

Xây dựng các yêu cầu đối với hệ thống thông tin. Cấu trúc của Điều khoản tham chiếu

Hãy làm rõ ngay: chúng ta sẽ nói cụ thể về việc xây dựng các yêu cầu cho một hệ thống thông tin, tức là. giả định rằng công việc phát triển yêu cầu kinh doanh, chính thức hóa quy trình kinh doanh và tất cả các công việc tư vấn trước đó đã được hoàn thành. Tất nhiên, có thể đưa ra một số giải thích rõ ràng ở giai đoạn này, nhưng chỉ là giải thích rõ ràng thôi. Bản thân dự án tự động hóa không giải quyết được các vấn đề kinh doanh - hãy nhớ điều này. Đây là một tiên đề. Vì lý do nào đó, một số nhà quản lý đang cố gắng bác bỏ nó, tin rằng nếu họ mua chương trình, trật tự sẽ dẫn đến tình trạng kinh doanh hỗn loạn. Nhưng một tiên đề là một tiên đề vì nó không cần chứng minh.

Giống như bất kỳ hoạt động nào, việc xây dựng các yêu cầu có thể (và nên) được chia thành các giai đoạn. Mọi thứ đều có thời điểm của nó. Đây là công việc trí óc vất vả. Và, nếu bạn đối xử với nó không đủ sự quan tâm, thì kết quả sẽ như ý. Theo ước tính của chuyên gia, chi phí xây dựng Điều khoản tham chiếu có thể lên tới 30-50%. Tôi có cùng quan điểm Mặc dù 50 có lẽ là quá nhiều. Xét cho cùng, Thông số kỹ thuật không phải là tài liệu cuối cùng cần được phát triển. Suy cho cùng thì cũng phải có thiết kế kỹ thuật. Sự khác biệt này là do các nền tảng, cách tiếp cận và công nghệ tự động hóa khác nhau được các nhóm dự án sử dụng trong quá trình phát triển. Ví dụ, nếu chúng ta đang nói về việc phát triển bằng ngôn ngữ cổ điển như C++, thì thiết kế kỹ thuật chi tiết là không thể thiếu. Nếu chúng ta đang nói về việc triển khai một hệ thống trên nền tảng 1C, thì tình huống thiết kế có phần khác, như chúng ta đã thấy ở trên (mặc dù, khi phát triển một hệ thống từ đầu, nó được thiết kế theo sơ đồ cổ điển).

Mặc dù tuyên bố yêu cầu là phần chính Thông số kỹ thuật, và trong một số trường hợp, nó trở thành phần duy nhất của thông số kỹ thuật, bạn nên chú ý rằng đây là một tài liệu quan trọng và cần được soạn thảo cho phù hợp. Nơi để bắt đầu? Trước hết, bạn cần bắt đầu với nội dung. Viết nội dung và sau đó bắt đầu mở rộng nó. Cá nhân tôi làm điều này: đầu tiên tôi phác thảo nội dung, mô tả mục tiêu, tất cả thông tin giới thiệu, sau đó đi vào phần chính - xây dựng các yêu cầu. Tại sao không phải là cách khác? Tôi không biết, nó thuận tiện hơn cho tôi. Thứ nhất, đây là khoảng thời gian nhỏ hơn nhiều (so với yêu cầu), và thứ hai, trong khi mô tả tất cả các thông tin giới thiệu, bạn hãy tập trung vào nội dung chính. Thôi thì ai cũng thích. Theo thời gian, bạn sẽ phát triển mẫu Thông số kỹ thuật của riêng mình. Để bắt đầu, tôi khuyên bạn nên lấy nội dung chính xác như nội dung được mô tả trong GOST. Nó hoàn hảo về nội dung! Sau đó, chúng tôi lấy và bắt đầu mô tả từng phần, không quên đề xuất về ba đặc tính sau: tính dễ hiểu, tính đặc hiệu và khả năng kiểm tra. Tại sao tôi nhấn mạnh vào điều này rất nhiều? Thông tin thêm về điều này trong phần tiếp theo. Và bây giờ tôi đề xuất xem xét những điểm của thông số kỹ thuật được khuyến nghị trong GOST.

thông tin chung;
mục đích và mục tiêu tạo dựng (phát triển) của hệ thống;
đặc điểm của đối tượng tự động hóa;
yêu cầu hệ thống;
thành phần và nội dung công việc để tạo ra hệ thống;
thủ tục kiểm soát và chấp nhận hệ thống;
yêu cầu về thành phần, nội dung công việc chuẩn bị đối tượng tự động hóa đưa hệ thống vào vận hành;
yêu cầu về tài liệu;
các nguồn phát triển.

Tổng cộng có 9 phần, mỗi phần cũng được chia thành các phần phụ. Chúng ta hãy nhìn vào chúng theo thứ tự. Để thuận tiện, tôi sẽ trình bày mọi thứ dưới dạng bảng cho từng mục.

Mục 1. Thông tin chung.

Khuyến nghị theo GOST
tên đầy đủ của hệ thống và ký hiệu của nó;	Mọi thứ đều rõ ràng ở đây: chúng tôi viết hệ thống sẽ được gọi là gì, tên viết tắt của nó
mã chủ thể hoặc mã (số) hợp đồng;	Điều này không liên quan, nhưng bạn có thể chỉ định nó nếu cần
tên doanh nghiệp (hiệp hội) của nhà phát triển và khách hàng (người dùng) hệ thống và thông tin chi tiết của họ;	cho biết ai (tổ chức nào) sẽ làm việc trong dự án. Bạn cũng có thể chỉ định vai trò của họ, thậm chí có thể xóa phần này (khá trang trọng).
danh sách các tài liệu trên cơ sở đó hệ thống được tạo ra, ai và khi nào các tài liệu này được phê duyệt;	Thông tin hữu ích. Ở đây bạn nên chỉ ra tài liệu quy định và tài liệu tham khảo đã được cung cấp cho bạn để bạn làm quen với một phần nhất định của yêu cầu
ngày bắt đầu và kết thúc theo kế hoạch cho công việc tạo ra hệ thống;	Yêu cầu về thời gian. Đôi khi họ viết về điều này trong các thông số kỹ thuật, nhưng những điều như vậy thường được mô tả trong hợp đồng làm việc
thông tin về các nguồn và thủ tục tài trợ cho công việc;	Tương tự như trong đoạn trước về thời hạn. Phù hợp hơn với các mệnh lệnh của chính phủ (đối với nhân viên nhà nước)
thủ tục đăng ký và trình bày cho khách hàng về kết quả công việc tạo ra hệ thống (các bộ phận của nó), về việc sản xuất và điều chỉnh các phương tiện riêng lẻ (phần cứng, phần mềm, thông tin) và các tổ hợp phần mềm và phần cứng (phần mềm và phương pháp) của hệ thống. hệ thống.	Tôi thấy điểm này không cần thiết vì... Các yêu cầu về tài liệu được đặt ra riêng biệt và ngoài ra còn có một phần hoàn toàn riêng biệt “Quy trình kiểm soát và chấp nhận” của hệ thống.

Mục 2. Mục đích và mục tiêu của việc tạo ra (phát triển) hệ thống.

Khuyến nghị theo GOST	Phải làm gì với nó trong thực tế
Mục đích của hệ thống	Một mặt, mục đích rất đơn giản. Nhưng nó được khuyến khích để xây dựng nó một cách cụ thể. Nếu bạn viết một cái gì đó như “tự động hóa chất lượng cao của kế toán kho ở công ty X”, thì bạn có thể thảo luận về kết quả trong một thời gian dài sau khi hoàn thành, ngay cả khi các yêu cầu được xây dựng tốt. Bởi vì Khách hàng luôn có thể nói rằng chất lượng có ý nghĩa khác. Nói chung là có thể làm hỏng thần kinh của nhau rất nhiều, nhưng tại sao? Tốt hơn hết bạn nên viết ngay câu như thế này: “Hệ thống được thiết kế để duy trì hồ sơ kho hàng ở công ty X phù hợp với các yêu cầu được quy định trong Thông số kỹ thuật này”.
Mục tiêu xây dựng hệ thống	Mục tiêu chắc chắn là một phần quan trọng. Nếu muốn đưa nó vào thì chúng ta phải có khả năng hình thành những mục tiêu này. Nếu bạn gặp khó khăn trong việc xây dựng mục tiêu thì tốt hơn hết bạn nên loại trừ hoàn toàn phần này. Ví dụ về mục tiêu không thành công: “Đảm bảo rằng người quản lý hoàn thành tài liệu một cách nhanh chóng”. Nhanh là gì? Điều này sau đó có thể được chứng minh vô tận. Nếu điều này quan trọng thì tốt hơn nên trình bày lại mục tiêu này như sau: “Người quản lý bán hàng có thể đưa ra một tài liệu “Bán hàng” gồm 100 dòng trong 10 phút.” Ví dụ: một mục tiêu như thế này có thể xuất hiện nếu một người quản lý hiện đang dành khoảng một giờ cho việc này, điều này là quá nhiều đối với công ty đó và nó quan trọng đối với họ. Trong công thức này, mục tiêu đã giao nhau với các yêu cầu, điều này khá tự nhiên, bởi vì khi mở rộng cây mục tiêu (tức là chia chúng thành các mục tiêu nhỏ hơn có liên quan), chúng ta sẽ tiến gần hơn đến các yêu cầu. Vì vậy, bạn không nên mang đi.

Nói chung, khả năng xác định mục tiêu, xây dựng chúng và xây dựng cây mục tiêu là một chủ đề hoàn toàn riêng biệt. Hãy nhớ điều chính: nếu bạn biết cách thì hãy viết, nếu bạn không chắc chắn thì đừng viết gì cả. Điều gì xảy ra nếu bạn không xây dựng mục tiêu? Bạn sẽ làm việc theo yêu cầu, điều này thường được thực hiện.

Phần 3. Đặc điểm của đối tượng tự động hóa.

Phần 4. Yêu cầu hệ thống

GOST giải mã danh sách các yêu cầu đó:

yêu cầu về cấu trúc và chức năng của hệ thống;
yêu cầu về số lượng và trình độ của nhân viên hệ thống và phương thức hoạt động của họ;
chỉ số điểm đến;
yêu cầu về độ tin cậy;
yêu cầu an toàn;
yêu cầu về công thái học và thẩm mỹ kỹ thuật;
yêu cầu về khả năng vận chuyển của loa di động;
yêu cầu vận hành, bảo trì, sửa chữa và bảo quản các bộ phận của hệ thống;
yêu cầu bảo vệ thông tin khỏi bị truy cập trái phép;
yêu cầu về an toàn thông tin khi xảy ra sự cố;
yêu cầu bảo vệ khỏi ảnh hưởng bên ngoài;
yêu cầu về độ tinh khiết của bằng sáng chế;
yêu cầu tiêu chuẩn hóa, thống nhất;

Mặc dù thực tế rằng phần chính chắc chắn sẽ là phần có các yêu cầu cụ thể (chức năng), phần này cũng có thể có tầm quan trọng lớn (và trong hầu hết các trường hợp là như vậy). Điều gì có thể quan trọng và hữu ích:

Yêu cầu trình độ. Có thể hệ thống đang được phát triển sẽ yêu cầu đào tạo lại các chuyên gia. Đây có thể là cả người dùng của hệ thống trong tương lai và các chuyên gia CNTT sẽ cần hỗ trợ hệ thống đó. Sự quan tâm không đầy đủ đến vấn đề này thường phát triển thành vấn đề. Nếu trình độ của nhân sự hiện tại rõ ràng là không đủ, tốt hơn nên nêu rõ các yêu cầu về tổ chức đào tạo, chương trình đào tạo, thời gian, v.v.
Yêu cầu bảo vệ thông tin khỏi bị truy cập trái phép. Không có bình luận ở đây. Đây chính xác là những yêu cầu để phân định quyền truy cập vào dữ liệu. Nếu các yêu cầu đó được lên kế hoạch thì chúng cần được viết riêng, càng chi tiết càng tốt, theo các quy tắc giống như các yêu cầu chức năng (dễ hiểu, cụ thể, có thể kiểm thử). Vì vậy, những yêu cầu này có thể được đưa vào phần yêu cầu chức năng.
Yêu cầu về tiêu chuẩn hóa. Nếu có bất kỳ tiêu chuẩn thiết kế nào có thể áp dụng cho dự án, chúng có thể được đưa vào yêu cầu. Theo quy định, các yêu cầu đó được khởi tạo bởi dịch vụ CNTT của Khách hàng. Ví dụ: công ty 1C có yêu cầu về thiết kế mã chương trình, thiết kế giao diện, v.v.;
Yêu cầu về cấu trúc và hoạt động của hệ thống.Ở đây có thể mô tả các yêu cầu để tích hợp các hệ thống với nhau và trình bày mô tả về kiến trúc chung. Thông thường, các yêu cầu tích hợp thường được tách thành một phần riêng biệt hoặc thậm chí là Thông số kỹ thuật riêng biệt, bởi vì những yêu cầu này có thể khá phức tạp.

Tất cả các yêu cầu khác ít quan trọng hơn và không cần phải mô tả. Theo tôi, chúng chỉ làm cho tài liệu nặng nề hơn và ít có lợi ích thực tế. Và rất khó để mô tả các yêu cầu ecgônômi dưới dạng các yêu cầu chung, tốt hơn là chuyển chúng sang các yêu cầu chức năng. Ví dụ: có thể đặt yêu cầu “Nhận thông tin về giá của sản phẩm chỉ bằng cách nhấn một nút”. Theo tôi, điều này vẫn gần với các yêu cầu chức năng cụ thể hơn, mặc dù nó liên quan đến công thái học.Yêu cầu đối với các chức năng (nhiệm vụ) do hệ thống thực hiện Đây là điểm chính và then chốt sẽ quyết định thành công. Ngay cả khi mọi thứ khác được thực hiện một cách hoàn hảo và phần này là “3”, thì kết quả của dự án tốt nhất sẽ là “3”, hoặc thậm chí dự án sẽ thất bại hoàn toàn. Đây là những gì chúng ta sẽ đề cập chi tiết hơn trong bài viết thứ hai, sẽ được đưa vào số thứ 5 của bản tin. Đến thời điểm này, “quy tắc ba đặc tính của yêu cầu” mà tôi đã nói đến đã được áp dụng.

GOST xác định các loại sau:

Toán học
Thông tin
ngôn ngữ học
Phần mềm
Kỹ thuật
đo lường
tổ chức
có phương pháp
và những người khác…

Thoạt nhìn, những yêu cầu này có vẻ không quan trọng. Trong hầu hết các dự án, điều này đúng. Nhưng không phải lúc nào cũng vậy. Khi nào cần mô tả các yêu cầu này:

Không có quyết định nào được đưa ra về việc phát triển ngôn ngữ (hoặc nền tảng) nào sẽ được thực hiện;
Hệ thống yêu cầu giao diện đa ngôn ngữ (ví dụ: tiếng Nga/tiếng Anh)
Để hệ thống hoạt động, phải thành lập một đơn vị riêng biệt hoặc phải thuê nhân viên mới;
Để hệ thống hoạt động, Khách hàng phải trải qua những thay đổi về phương pháp làm việc và những thay đổi này phải được chỉ định và lập kế hoạch;
Việc tích hợp với bất kỳ thiết bị nào là điều cần thiết và các yêu cầu được đặt ra đối với thiết bị đó (ví dụ: chứng nhận, khả năng tương thích, v.v.)
Các tình huống khác đều có thể xảy ra, tất cả phụ thuộc vào mục tiêu cụ thể của dự án.

Phần 5. Thành phần và nội dung công việc xây dựng hệ thống

Mục 6. Quy trình kiểm soát, nghiệm thu hệ thống

Yêu cầu chung về nghiệm thu công việc theo từng giai đoạn (danh sách doanh nghiệp, tổ chức tham gia, địa điểm, thời gian), quy trình phối hợp và phê duyệt hồ sơ nghiệm thu; tôi đặc biệt đề nghị các bạn chịu trách nhiệm về thủ tục nộp công việc và kiểm tra hệ thống. Đây chính xác là lý do tại sao cần có các yêu cầu có thể kiểm thử, nhưng ngay cả sự hiện diện của các yêu cầu có thể kiểm thử cũng có thể không đủ khi hệ thống được chuyển giao nếu thủ tục chấp nhận và chuyển giao công việc không được nêu rõ ràng. Ví dụ: một cái bẫy phổ biến: hệ thống được xây dựng và hoạt động đầy đủ, nhưng vì lý do nào đó Khách hàng chưa sẵn sàng làm việc trong đó. Những lý do này có thể là bất kỳ lý do nào: không có thời gian, mục tiêu đã thay đổi, ai đó bỏ việc, v.v. Và anh ấy nói: “Vì chúng tôi chưa làm việc trong hệ thống mới, điều đó có nghĩa là chúng tôi không thể chắc chắn rằng nó hoạt động.” Vì vậy, hãy học cách xác định chính xác các giai đoạn của công việc và cách kiểm tra kết quả của các giai đoạn này. Hơn nữa, những phương pháp như vậy phải được Khách hàng hiểu rõ ngay từ đầu. Nếu chúng được cố định ở cấp Thông số kỹ thuật, thì bạn luôn có thể chuyển sang chúng nếu cần và hoàn thành công việc với việc chuyển giao.

Mục 7. Yêu cầu về thành phần, nội dung công việc chuẩn bị đối tượng tự động hóa đưa hệ thống vào vận hành

Có thể có bất kỳ quy tắc nào khác về việc nhập thông tin được công ty thông qua (hoặc dự định). Ví dụ: thông tin về hợp đồng trước đây được nhập dưới dạng chuỗi văn bản dưới bất kỳ hình thức nào, nhưng bây giờ bắt buộc phải nhập số riêng, ngày riêng, v.v. Có thể có rất nhiều điều kiện như vậy. Một số trường hợp có thể bị nhân viên phản đối, vì vậy tốt hơn hết bạn nên đăng ký tất cả các trường hợp đó ở mức độ yêu cầu về thứ tự nhập dữ liệu.

Tạo các điều kiện cho hoạt động của đối tượng tự động hóa, theo đó sự tuân thủ của hệ thống được tạo ra với các yêu cầu trong thông số kỹ thuật được đảm bảo. Ví dụ, công ty không có mạng cục bộ, một nhóm máy tính lỗi thời mà hệ thống sẽ không hoạt động.

Có lẽ một số thông tin cần thiết đã được xử lý trên giấy và bây giờ nó cần được nhập vào hệ thống. Nếu bạn không làm điều này thì một số mô-đun sẽ không hoạt động, v.v.

Có lẽ điều gì đó đã được đơn giản hóa, nhưng bây giờ cần phải tính đến chi tiết hơn, vì vậy ai đó phải thu thập thông tin theo những quy tắc nhất định.

Danh sách này có thể dài, hãy xem xét trường hợp cụ thể của dự án của bạn: Tạo các bộ phận và dịch vụ cần thiết cho hoạt động của hệ thống;

Thời gian và thủ tục bố trí nhân sự và đào tạo Chúng tôi đã nói về vấn đề này trước đó. Có lẽ hệ thống đang được phát triển cho một cấu trúc hoặc loại hoạt động mới chưa tồn tại trước đây. Nếu không có nhân sự phù hợp, thậm chí không có nhân sự được đào tạo, hệ thống sẽ không hoạt động, cho dù nó được xây dựng thành thạo đến đâu.

Phần 8. Yêu cầu về tài liệu

Xem xét cách trình bày hướng dẫn sử dụng.

Có lẽ Khách hàng đã chấp nhận các tiêu chuẩn của công ty, điều đó có nghĩa là chúng ta cần tham khảo các tiêu chuẩn đó.

Việc bỏ qua các yêu cầu về tài liệu rất thường dẫn đến những hậu quả không mong muốn nhất cho dự án. Ví dụ, mọi thứ đều được thực hiện và mọi thứ đều hoạt động. Người dùng cũng biết cách làm việc. Không có thỏa thuận hay cuộc trò chuyện nào về tài liệu cả. Và đột nhiên, khi bàn giao công việc, một trong những người quản lý cấp cao của Khách hàng, người thậm chí không tham gia vào dự án nhưng đang tham gia nghiệm thu công việc, hỏi bạn: “Hướng dẫn sử dụng ở đâu?” Và nó bắt đầu thuyết phục bạn rằng không cần thiết phải đồng ý về sự sẵn có của hướng dẫn sử dụng, điều này được cho là “tất nhiên” ngụ ý. Và thế là xong, anh ấy không muốn nhận công việc của bạn. Bạn sẽ phát triển các hướng dẫn bằng chi phí của ai? Nhiều đội đã rơi vào cái móc này.

Mục 9. Nguồn phát triển

Vì vậy, tốt hơn hết bạn chỉ nên tham khảo báo cáo khảo sát và yêu cầu của những người chủ chốt.

Và vì vậy, chúng tôi đã xem xét tất cả các phần có thể được đưa vào Điều khoản tham chiếu. Chính xác là “Có thể” chứ không phải “Phải” vì bất kỳ tài liệu nào cũng phải được phát triển để đạt được kết quả. Do đó, nếu bạn thấy rõ rằng một phần cụ thể sẽ không đưa bạn đến gần hơn với kết quả, thì bạn không cần nó và không cần lãng phí thời gian cho nó.

Nhưng không có thông số kỹ thuật có thẩm quyền nào có thể làm được nếu không có điều chính: yêu cầu chức năng. Tôi muốn lưu ý rằng trong thực tế, các Thông số kỹ thuật như vậy xảy ra và bằng cách nào! Có những người sẽ có thể tách nước thành tất cả các phần, mô tả các yêu cầu chung một cách chung chung, và tài liệu hóa ra rất nặng nề và có rất nhiều từ ngữ thông minh trong đó, và thậm chí Khách hàng có thể thích nó (nghĩa là anh ấy sẽ chấp thuận nó). Nhưng nó có thể không hoạt động theo nó, tức là. Nó có ít ứng dụng thực tế. Trong hầu hết các trường hợp, những tài liệu như vậy ra đời khi bạn cần kiếm được nhiều tiền dành riêng cho Điều khoản tham chiếu, nhưng nó cần được thực hiện nhanh chóng và không đi sâu vào chi tiết. Và đặc biệt nếu biết rằng vấn đề sẽ không đi xa hơn hoặc những người hoàn toàn khác sẽ làm điều đó. Nói chung là chỉ để quản lý ngân sách, đặc biệt là ngân sách nhà nước.

Trong bài viết thứ hai, chúng tôi sẽ chỉ nói về phần 4 “Yêu cầu hệ thống” và cụ thể là chúng tôi sẽ xây dựng các yêu cầu vì lý do rõ ràng, cụ thể và khả năng kiểm thử.

Tại sao yêu cầu phải rõ ràng, cụ thể và có thể kiểm chứng được.

Bởi vì thực tế cho thấy: lúc đầu, hầu hết các thông số kỹ thuật do các chuyên gia phát triển đều không có nhu cầu (không phù hợp với thực tế) hoặc trở thành vấn đề đối với người phải thực hiện chúng, bởi vì Khách hàng bắt đầu thao túng các điều khoản và yêu cầu mơ hồ. Tôi sẽ đưa ra một vài ví dụ về những cụm từ đã gặp phải, điều này dẫn đến điều gì và sau đó tôi sẽ cố gắng đưa ra khuyến nghị về cách tránh những vấn đề như vậy.

Yêu cầu này có thể kiểm tra được không? Chuyện tưởng chừng như đơn giản nhưng không có thông tin cụ thể thì làm sao kiểm tra được?

Làm thế nào điều này có thể được điều chỉnh lại: “Mức chi phí quy định trong văn bản phải được phân bổ cho tất cả hàng hóa được quy định trong văn bản này theo tỷ lệ tương ứng với giá thành của những hàng hóa này”. Hóa ra vừa rõ ràng vừa cụ thể. Cách kiểm tra cũng không khó.

Công thái học Chương trình phải có giao diện thân thiện với người dùng, tôi phải thừa nhận rằng, tôi đã từng phải tự mình đăng ký công thức này - sau này có vô số vấn đề. Tất nhiên, những công thức như vậy không nên tồn tại. Không có chi tiết cụ thể ở đây, cũng như không có cơ hội để xác minh yêu cầu này. Mặc dù tất nhiên là có thể hiểu được (chủ quan). Không có cách nào để định dạng lại nó; mỗi yếu tố “tiện lợi” phải được mô tả chi tiết vì Khách hàng yêu cầu điều đó. Ví dụ:

Các dòng phải được thêm vào tài liệu bằng cách nhấp vào nút “Thêm” và bằng cách nhấn phím “chèn”, cũng như bằng cách người dùng nhập một phần tên;
Khi xem danh sách sản phẩm, có thể tìm kiếm theo tên, mã vạch và mặt hàng;
Vân vân.

Phân biệt quyền truy cập Quyền truy cập vào dữ liệu lợi nhuận chỉ được cung cấp cho giám đốc tài chính. Điều đó có rõ ràng không? Hầu hết. Đúng, lợi nhuận khác nhau, chúng ta cần làm rõ. Cụ thể? Dĩ nhiên là không. Điều này trông như thế nào khi thực hiện? Nếu chúng ta đang nói về lợi nhuận gộp, thì cần hạn chế quyền truy cập vào dữ liệu về chi phí mua hàng, bởi vì mặt khác, lợi nhuận gộp sẽ không khó tính toán, vì dữ liệu về giá vốn hàng bán đã được nhiều người biết đến. Những gì liên quan đến quyền truy cập phải được xử lý rất cẩn thận. Và nếu động lực của người quản lý bán hàng dựa trên lợi nhuận gộp thì những yêu cầu này cũng mâu thuẫn với nhau, bởi vì các nhà quản lý sẽ không bao giờ có thể xác minh được điều này. Nếu chúng tôi muốn đưa ra yêu cầu như vậy thì chúng tôi cần chỉ định các báo cáo cụ thể và đối tượng hệ thống cho biết phần nào của dữ liệu sẽ có sẵn cho một số loại người nhất định. Và xem xét từng trường hợp riêng lẻ. Năng suất Báo cáo bán hàng sẽ được tạo trong 1 phút. Vâng, tôi hiểu. Và thậm chí còn có giới hạn thời gian cụ thể: 1 phút. Nhưng không biết nên trình bày chi tiết như thế nào: cho từng sản phẩm, nhóm sản phẩm, khách hàng hay điều gì khác? không được hiển thị quá 1 phút với điều kiện số lượng sản phẩm trong mẫu không vượt quá 5000 dòng.”

Tôi hy vọng ý tưởng là rõ ràng. Nếu bạn có câu hỏi cụ thể, hãy viết thư, tôi sẽ cố gắng giúp đỡ.

ĐẾN Điều khoản tham chiếu có nhiều chi tiết cụ thể hơn, có nhiều khuyến nghị. Thậm chí còn có một danh sách các từ không được khuyến khích sử dụng trong Thông số kỹ thuật. K. Wiegers viết rất thú vị về điều này trong cuốn sách “Phát triển các yêu cầu phần mềm”. Theo ý kiến của tôi, tôi sẽ đưa ra những khuyến nghị thú vị và đơn giản nhất:

Bạn không nên sử dụng những từ có nhiều từ đồng nghĩa. Nếu điều này là cần thiết, tốt hơn hết bạn nên đưa ra định nghĩa rõ ràng về thuật ngữ này trong phần “Điều khoản và Định nghĩa” của Điều khoản Tham chiếu.
Bạn nên cố gắng không sử dụng những câu dài;
Nếu một yêu cầu có vẻ quá chung chung đối với bạn, thì nó cần được chi tiết hóa thành các yêu cầu nhỏ hơn nhưng cụ thể hơn;
Sử dụng nhiều sơ đồ, đồ thị, bảng biểu, hình vẽ - cách này giúp bạn tiếp nhận thông tin dễ dàng hơn nhiều;
Những từ cần tránh là: “hiệu quả”, “đầy đủ”, “đơn giản”, “rõ ràng”, “nhanh”, “linh hoạt”, “cải tiến”, “tối ưu”, “minh bạch”, “bền vững”, “đủ”, “ thân thiện”, “dễ dàng”, v.v. Danh sách này có thể được tiếp tục, nhưng tôi nghĩ ý tưởng đã rõ ràng (hãy cố gắng tự tiếp tục).

Tất cả mọi thứ được viết ở trên là thông tin quan trọng, nhưng không phải là quan trọng nhất. Như các bạn còn nhớ, ở đầu bài tôi đã gọi đây là thuật ngữ “ngụy trang”, bởi vì. điều quan trọng nhất sẽ chiếm ít nhất 90% thời gian và độ phức tạp khi làm việc trên một tài liệu là xác định và hình thành các yêu cầu. Và bạn vẫn cần có khả năng thu thập, cấu trúc và hình thành thông tin về các yêu cầu. Nhân tiện, điều này có nhiều điểm chung giữa một cuộc khảo sát về hoạt động của doanh nghiệp và một mô tả tiếp theo về các quy trình kinh doanh. Nhưng cũng có những khác biệt quan trọng. Một trong những khác biệt chính này là sự hiện diện của giai đoạn xây dựng nguyên mẫu của hệ thống tương lai, hay còn gọi là “mô hình hệ thống thông tin”.

Trong bài viết tiếp theo, chúng tôi sẽ chỉ nói về các phương pháp xác định yêu cầu, đồng thời xem xét những điểm chung giữa công việc thu thập yêu cầu cho hệ thống thông tin và thu thập thông tin để mô tả các quy trình nghiệp vụ.

Các loại công việc khi thu thập các yêu cầu về hệ thống kế toán và thông tin để mô tả các quy trình kinh doanh. Phần 2

Trong phần này, chúng ta sẽ nói về cách tổ chức giai đoạn thu thập yêu cầu, giai đoạn này bao gồm những gì và có thể sử dụng những công cụ nào. Tôi nhắc lại rằng xét từ góc độ các giai đoạn, công việc này rất giống với một cuộc khảo sát doanh nghiệp để mô tả các quy trình kinh doanh.

Như thường lệ xảy ra trong cuộc sống:

Đây là cách nó xảy ra trong hầu hết các dự án.
	Làm thế nào điều này xảy ra
	Rõ ràng là có lý do để vui mừng, đặc biệt nếu dự án lớn thì không có gì sai cả! Cái chính là không nên vui mừng quá lâu, trì hoãn việc bắt đầu công việc thực tế, từ giờ trở đi thời gian sẽ khác đi.
	Thông thường quá trình này được giới hạn ở một số cuộc họp với ban quản lý, sau đó với các trưởng bộ phận. Sau khi ghi lại một số “thúc giục” nhất định từ phía Khách hàng, chúng được ghi lại dưới dạng công thức chung. Đôi khi các tài liệu hiện có được thêm vào (có người đã từng thực hiện một cuộc khảo sát, các tài liệu theo quy định hiện hành, các mẫu báo cáo được sử dụng) Thật ngạc nhiên, sau đó, phần lớn những người triển khai hệ thống tự động hóa đều vui mừng kêu lên: “vâng, hệ thống của chúng tôi có tất cả những thứ này”. ! Chà, chỉnh sửa nó một chút và mọi thứ sẽ hoạt động.” Khi được hỏi có nên thảo luận về cách mọi thứ sẽ hoạt động (hoặc cách thực hiện một quy trình cụ thể) với người dùng cuối hay không, câu trả lời thường là không. Ý kiến được bày tỏ là người lãnh đạo biết tất cả mọi thứ cho cấp dưới của mình. Nhưng vô ích... Đằng sau điều này ẩn chứa rất nhiều cạm bẫy và chướng ngại vật, và việc nộp bài có thể biến thành một cuộc chạy marathon vượt chướng ngại vật. Như bạn đã biết, người ta thường chạy marathon trên đường bằng phẳng và chỉ có thể chạy vượt chướng ngại vật ở những quãng đường ngắn (thậm chí bạn có thể không về đích).
Ghi lại kết quả công việc	Sau đó, việc ghi lại kết quả bắt đầu, tùy thuộc vào mục tiêu của công việc: Nếu cần xây dựng Thông số kỹ thuật, chuyên gia tư vấn bắt đầu đưa thông tin nhận được vào mẫu tài liệu đã chuẩn bị sẵn sao cho đẹp mắt và các yêu cầu chính là được ghi lại (do quản lý lên tiếng, nếu không họ có thể không phê duyệt). Hiểu rằng trong thực tế, các Điều khoản tham chiếu như vậy không được sử dụng cụ thể và mọi thứ đều phải được tìm hiểu “trong quá trình thực hiện”, ông đặt mục tiêu chính của Điều khoản tham chiếu là thời gian tối thiểu để phối hợp và phê duyệt. Và, nếu có thể, thông tin để ước tính sơ bộ chi phí cho công việc trong tương lai (nhân tiện, cũng rất quan trọng). Nếu bạn cần mô tả quy trình kinh doanh. Thật kỳ lạ, nhưng thường thì tất cả các hành động trước đó đều trông giống nhau, như trường hợp phát triển Thông số kỹ thuật. Sự khác biệt duy nhất là trong tài liệu. Ở đây có các lựa chọn: chuyên gia tư vấn mô tả quy trình bằng các từ tùy ý hoặc sử dụng bất kỳ quy tắc nào để mô tả quy trình kinh doanh (ký hiệu). Trong trường hợp đầu tiên, tài liệu đó giống một cách đáng ngạc nhiên với Thông số kỹ thuật. Thậm chí, nếu bạn thay thế trang tiêu đề, bạn sẽ không thấy bất kỳ sự khác biệt nào, trong trường hợp sau, điểm nhấn thường không phải là sự phù hợp với thực tế mà là “tính chính xác của mô tả”, tức là. tuân thủ chính thức các quy tắc mô tả. Thật không may, cả hai lựa chọn đều không phải là cách thực hành tốt nhất, bởi vì mang tính hình thức và không mang lại nhiều lợi ích.

Tại sao thực hành lại phát triển như mô tả ở trên? Thành thật mà nói, tôi không biết. Hỏi ai cũng không ai biết. Đồng thời, tình hình không thay đổi nhanh chóng, mặc dù mọi người liên tục thảo luận về chủ đề này, trao đổi kinh nghiệm, viết sách... Đối với tôi, có vẻ như một trong những nguyên nhân là chất lượng giáo dục phù hợp còn thấp. Cũng có thể là do nhiều chuyên gia đến từ các doanh nghiệp khác và học mọi thứ trong thực tế, tức là. kinh nghiệm của họ được hình thành trong môi trường nơi họ tìm thấy chính mình. Thái độ của các trường đại học và việc họ không mong muốn gần gũi hơn với thực tế cũng là một thực tế ai cũng biết, nhưng đôi khi tôi rất ngạc nhiên về quan điểm của họ. Ví dụ, tôi gặp trường hợp một sinh viên mới tốt nghiệp, một chuyên gia tài năng, muốn viết luận văn trên nền tảng 1C (một ngành phát triển tốt), nhưng khoa nói với cô ấy rằng bất kể chủ đề nào, cô ấy cũng không thể tin tưởng vào một “ loại xuất sắc”, bởi vì 1C không phải là một hệ thống nghiêm túc. Vấn đề ở đây không phải là mức độ nghiêm túc và khách quan của ý kiến này, mà thực tế là một nhiệm vụ nguyên thủy trong ngôn ngữ lập trình cổ điển ngay lập tức được coi là xứng đáng được đánh giá “xuất sắc”.

Chúng ta hãy cố gắng cung cấp cho quá trình được thảo luận ở trên một cách tiếp cận có hệ thống hơn. Lúc đó anh ấy có thể trông như thế nào?

Như bạn có thể thấy, quá trình này kết thúc bằng một câu hỏi, bởi vì Tại thời điểm này, công việc còn lâu mới hoàn thành, và khi đó những điều khó khăn và thiết thực nhất sẽ bắt đầu - chính xác điều gì sẽ quyết định khả năng ứng dụng kết quả thu được vào cuộc sống thực. Đây chính xác là điều sẽ quyết định số phận của tác phẩm trước đó: hoặc nó sẽ cất vào tủ (trên kệ hoặc nơi nào khác), hoặc nó sẽ là một nguồn thông tin có giá trị. Và càng tuyệt vời hơn nếu nó trở thành hình mẫu cho những dự án tiếp theo.

Tôi đặc biệt muốn lưu ý rằng cho đến bước cuối cùng trong sơ đồ (nơi đặt câu hỏi), nguyên tắc chung của việc thu thập thông tin về hoạt động của công ty vẫn giống nhau, bất kể bạn dự định làm gì trong tương lai, mô tả các quy trình kinh doanh hay thực hiện một hệ thống tự động. Có, trình tự các bước giống nhau nhưng các công cụ được sử dụng trong một số bước có thể khác nhau. Chúng tôi chắc chắn sẽ xem xét điểm này khi nghiên cứu các phương pháp và công cụ của từng giai đoạn riêng lẻ. Chúng tôi sẽ làm điều này một cách chi tiết trong các bài viết riêng biệt, nhưng bây giờ chúng tôi sẽ chỉ xem xét những điều quan trọng nhất. Các bước tiếp theo sẽ khác nhau và sẽ được xác định bởi những gì được yêu cầu từ dự án: mô tả quy trình kinh doanh hoặc triển khai hệ thống kế toán.

Hãy xem cách chúng ta có thể tổ chức lại cách tiếp cận thu thập thông tin về hoạt động của công ty.

Làm thế nào điều này có thể xảy ra với một tổ chức làm việc có năng lực hơn
	Làm thế nào điều này xảy ra
Quyết định đã được đưa ra, dự án sẽ được triển khai!	Không có gì thay đổi ở đây so với lựa chọn đầu tiên, cảm xúc vẫn chưa bị hủy bỏ
Chúng tôi đã tổ chức một cuộc họp với các nhà quản lý và thu thập một số thông tin về tầm nhìn của họ về kết quả.	Bước này cũng vẫn còn và nó có tầm quan trọng lớn. Nhưng mục đích chính của cuộc gặp đầu tiên (hoặc nhiều cuộc gặp) với người quản lý và chủ sở hữu là để tìm hiểu nhau. Làm quen với mọi người và công ty trước tiên. Các mục tiêu và mong muốn được đưa ra tại các cuộc họp chung như vậy có thể rất khác nhau, kể cả những điều tuyệt vời. Tất nhiên, tất cả chúng sẽ được lắng nghe, nhưng thực tế không phải là chúng sẽ được thực hiện. Khi đi sâu hơn vào hoạt động kinh doanh của công ty, các mục tiêu khác sẽ xuất hiện và những mục tiêu trước đó sẽ bị từ chối. Ý tôi là không thể đưa ra mục tiêu rõ ràng từ các cuộc họp sơ bộ, tất cả những điều này cần phải nghiên cứu kỹ lưỡng, tại những cuộc họp như vậy cần phải ghi chép lại tất cả các thông điệp từ chủ sở hữu và các quan chức cấp cao để sau này có thể quay lại. với họ và thảo luận về chúng khi đã thu thập đủ lượng thông tin. Ngay cả một yêu cầu tưởng chừng đơn giản cũng có thể trở thành không thể thực hiện được hoặc tốn rất nhiều công sức.
Thành lập nhóm làm việc từ Khách hàng và Nhà thầu, phân bổ vai trò	Cần phải quyết định ai sẽ làm việc trong dự án, cả về phía Khách hàng và về phía Nhà thầu. Mặc dù giai đoạn này có vẻ đơn giản nhưng nó có một vai trò rất quan trọng. Nếu không ghi rõ ai chịu trách nhiệm về việc gì, bạn có nguy cơ gặp phải sự nhầm lẫn trong quá trình thực hiện công việc. Về phần mình, nếu bạn luôn có thể chỉ định các vai trò trong nhóm của mình thì Khách hàng có thể gặp vấn đề với điều này. Điều bạn nên chú ý: nhóm làm việc của Khách hàng phải bao gồm những người trong tương lai ít nhất sẽ ảnh hưởng đến việc chấp nhận kết quả bằng cách nào đó. Nếu chúng ta giả sử tình huống khi công việc được bàn giao, nhân viên của Khách hàng không tham gia vào công việc xây dựng mục tiêu và xác định yêu cầu sẽ tham gia thì đảm bảo sẽ có vấn đề. Ngay cả một tình huống vô lý như vậy cũng có thể xảy ra là mọi việc không được thực hiện theo yêu cầu. Trong thực tế, tôi đã hơn một lần gặp phải tình huống như vậy. Vì vậy, bạn có thể tự bảo vệ mình nếu bạn quy định và ghi chép rằng không ai ngoại trừ Khách hàng đang làm việc. nhóm có thể tham gia vào việc nghiệm thu và bàn giao công việc. Và tốt nhất bạn nên ghi điều này vào điều khoản hợp đồng (trong hợp đồng hoặc điều lệ dự án). Tôi nhớ có một trường hợp như vậy: trong một dự án lớn, người sáng lập đã quyết định tham gia vào quá trình này (tôi không biết tại sao, nó có vẻ nhàm chán) và tham dự một trong những cuộc họp làm việc thảo luận về vấn đề tạo hóa đơn cho khách hàng. Anh ấy rất ngạc nhiên khi biết rằng người quản lý bán hàng sẽ xuất hóa đơn cho khách hàng. Trong suy nghĩ của anh ấy, kế toán nên xuất hóa đơn và không có gì khác. Nhưng trên thực tế, kế toán viên không hiểu anh ta đang nói về cái gì, và người quản lý cũng không thể tưởng tượng được cách làm việc như thế này nếu anh ta phải chạy đến kế toán để lấy từng hóa đơn. Kết quả là chúng tôi mất rất nhiều thời gian nhưng không có gì thay đổi, người quản lý tiếp tục xuất hóa đơn. Và người sáng lập vẫn không bị thuyết phục nhưng cũng không can thiệp vào quá trình này nữa. Ở giai đoạn tương tự, nên xây dựng Điều lệ Dự án, trong đó nêu rõ vai trò của những người tham gia, quy trình liên lạc, quy định và báo cáo, cũng như mọi thứ khác cần được quy định trong Điều lệ. Việc xây dựng Điều lệ Dự án một lần nữa lại là một chủ đề riêng biệt.
Đào tạo nhóm dự án về phương pháp và công cụ làm việc, thống nhất các quy tắc làm việc, loại hình và thành phần tài liệu	Đầu tiên, cần giải thích cho nhóm dự án mọi điều được nêu trong Điều lệ và cách áp dụng nó vào thực tế. Thứ hai, nhóm dự án của Khách hàng phải được đào tạo về các phương pháp làm việc mà bạn sẽ sử dụng ở tất cả các giai đoạn tiếp theo. Sẽ rất hợp lý khi thảo luận về các định dạng tài liệu sẽ được sử dụng và xem xét các mẫu. Nếu bất kỳ quy tắc nào để mô tả mô hình hoặc quy trình kinh doanh sẽ được áp dụng thì những quy tắc này phải được thảo luận sao cho rõ ràng.
Bảng câu hỏi	Giai đoạn khảo sát cho phép bạn có được thông tin tổng hợp khá đáng tin cậy về công ty một cách tương đối nhanh chóng. Chất lượng của những thông tin đó sẽ được quyết định bởi ba yếu tố: Trước hết là cách bạn đào tạo nhóm dự án của Khách hàng. Họ phải hiểu rõ ràng cách thức hoạt động của quá trình khảo sát và có thể truyền tải thông tin đến tất cả những người tham gia Bản thân bảng câu hỏi được hình thành. Bảng câu hỏi phải dễ hiểu. Nên có hướng dẫn điền bảng câu hỏi. Sẽ tốt hơn nữa nếu có một ví dụ về cách điền nó. Danh sách những người tham gia. Cần phải chọn đúng thành phần người tham gia. Nếu bạn chỉ giới hạn mình ở những người quản lý, bạn sẽ không thể thu thập thông tin đáng tin cậy. Tôi khuyên bạn nên đưa vào cuộc khảo sát tất cả những người sẽ là người sử dụng kết quả cuối cùng trong tương lai. Ví dụ: nếu chúng ta đang nói về việc triển khai một hệ thống tự động, thì cần bao gồm tất cả những người sẽ là người dùng. Đôi khi trong số 10 nhân viên của một vị trí có một người thực hiện một số chức năng đặc biệt mà không ai trong số 9 người còn lại biết đến (ví dụ: chuẩn bị một báo cáo đặc biệt cho quản lý). Nếu chúng ta đang nói về việc phân bổ lại trách nhiệm hơn nữa hoặc phát triển các mô tả công việc, bạn cũng nên làm như vậy. Xin lưu ý rằng phương pháp khảo sát để triển khai hệ thống tự động tiếp theo hoặc mô tả quy trình kinh doanh trong trường hợp phù hợp sẽ khác nhau. Tất nhiên, cấu trúc của các câu hỏi có thể giống nhau, nhưng đây không phải là lựa chọn tốt nhất. Khi chúng ta mô tả các quy trình kinh doanh, các câu hỏi thường có tính chất tổng quát hơn, bởi vì Người ta không biết chính xác những gì bạn sẽ phải đối mặt. Nếu chúng ta đang nói về việc triển khai một hệ thống tự động cụ thể, thì tốt hơn là nên có các câu hỏi có tính đến các tính năng của hệ thống này. Với phương pháp này, bạn có thể xác định ngay tất cả các điểm nghẽn của hệ thống không phù hợp với một doanh nghiệp nhất định. Theo quy định, các phương pháp triển khai các hệ thống làm sẵn phải có các bảng câu hỏi như vậy. Những câu hỏi như vậy có thể được phát triển cho các lĩnh vực kế toán cụ thể (ví dụ: kế toán đơn hàng, bán hàng, định giá) hoặc cho các vị trí cụ thể (ví dụ: giám đốc tài chính). Thành phần của các câu hỏi gần như giống nhau.
Thăm dò ý kiến	Khảo sát là một cuộc phỏng vấn bằng miệng với các chuyên gia nhằm tìm ra đặc điểm của các quy trình riêng lẻ. Cần tổ chức khảo sát sao cho không chỉ giống như một buổi “gặp gỡ nói chuyện” mà có tổ chức hơn. Để làm điều này, bạn cần chuẩn bị một kế hoạch khảo sát. Bạn có thể đưa vào đó những phần của bảng câu hỏi đặt ra câu hỏi cho bạn, thông tin trái ngược với các bảng câu hỏi khác hoặc thông tin được trình bày một cách hời hợt. Nên thêm câu hỏi đơn giản từ kinh nghiệm cá nhân, câu trả lời phải được ghi lại một cách chắc chắn. Đó là lý tưởng nếu bạn đồng ý ghi âm. Đồng thời, bạn phải đảm bảo tính đầy đủ của thông tin được cung cấp trên luồng tài liệu (cả dạng tài liệu chính và các báo cáo khác nhau)
Xác định các quy trình kinh doanh chính hoặc các lĩnh vực tự động hóa	Sau bảng câu hỏi và khảo sát, có thể giả định một cách hợp lý rằng có đủ thông tin để đưa ra kết luận về việc xác định các quy trình kinh doanh chính. Trên thực tế, không chỉ có thể xác định các quy trình kinh doanh chính mà còn có thể xác định hầu hết mọi thứ (nếu những người tham gia được chọn chính xác). Vấn đề xác định quy trình nghiệp vụ là một chủ đề hoàn toàn riêng biệt và không hề đơn giản. Việc học ở đây rất khó khăn và được phát triển chủ yếu bằng kinh nghiệm. Một danh sách (phân loại) cần được tổng hợp từ các quy trình kinh doanh đã xác định. Sau đó, bạn có thể đưa ra quyết định xem cái nào nên được khám phá sâu hơn, cái nào không và ưu tiên.
Xây dựng các yêu cầu chính cho hệ thống, mục tiêu, tiêu chí thành công của dự án, quy trình nghiên cứu chi tiết	Ở giai đoạn này, tất cả thông tin chính về hoạt động của công ty phải được thu thập và phải biên soạn danh sách các quy trình kinh doanh. Bây giờ là lúc quay lại các mục tiêu, xác định rõ chúng và nếu cần, hãy thảo luận chúng với các quan chức cấp cao nhất của công ty. Khi xây dựng mục tiêu, chúng ta nên tính đến các chỉ số cụ thể, khi đạt được mục tiêu đó chúng ta sẽ coi dự án là thành công. Nếu chúng ta đang nói về việc triển khai một hệ thống tự động, thì một danh sách riêng có thể nêu bật các yêu cầu đối với hệ thống đối với những người dùng chính. Tôi thực hiện việc này dưới dạng một bảng riêng biệt, trong đó tất cả các yêu cầu được nhóm theo hệ thống con, đối với mỗi yêu cầu, tác giả của yêu cầu, từ ngữ và mức độ ưu tiên được chỉ định. Thông tin này có thể được sử dụng để lập kế hoạch triển khai hệ thống (trình tự triển khai các hệ thống con riêng lẻ), cũng như các đề xuất phát triển hệ thống hơn nữa (nếu các hệ thống con riêng lẻ không được lên kế hoạch triển khai trong dự án hiện tại). Nếu cần mô tả các quy trình kinh doanh, các quyết định sẽ được đưa ra về những quy trình cần được nghiên cứu chi tiết hơn.

Vì vậy, chúng ta nhận được câu hỏi "Tiếp theo là gì?" Tiếp theo chúng ta sẽ xem xét các nhiệm vụ mô tả quy trình kinh doanh và phát triển các thông số kỹ thuật một cách riêng biệt. Không phải ngẫu nhiên mà tôi coi những nhiệm vụ này là song song. Thực sự có rất nhiều điểm chung giữa họ, đó là điều tôi muốn chứng minh. Đầu tiên, chúng ta hãy xem trình tự công việc khi mô tả các quy trình nghiệp vụ.

	Làm gì và làm như thế nào
Chúng tôi nhấn mạnh quá trình kinh doanh	Từ danh sách chung các quy trình kinh doanh thu được ở các giai đoạn trước, chúng tôi chọn một quy trình (theo mức độ ưu tiên) để phát triển chi tiết. Sau đó chúng tôi làm tương tự với phần còn lại.
Nghiên cứu chi tiết quá trình kinh doanh	Chúng tôi đưa quy trình kinh doanh đã chọn vào một nghiên cứu chi tiết: chúng tôi phân tích các tài liệu, báo cáo chính nhận được và cấu trúc của chúng được sử dụng trong quy trình chương trình, các tệp khác nhau (ví dụ: Excel) và nói chuyện với những người thực hiện cuối cùng. Chúng tôi thu thập nhiều ý tưởng khác nhau về cách cải thiện quy trình. Sẽ rất hữu ích nếu bạn có thể quan sát chính xác quá trình trong các điều kiện mà nó đang được thực hiện (không nhiều người thích bị theo dõi, nhưng bạn có thể làm gì)
Mô tả bằng đồ họa và/hoặc văn bản của quy trình kinh doanh (chính)	Chúng tôi bắt đầu mô tả thông tin chi tiết nhận được, trước khi mô tả quy trình, chúng tôi cần quyết định xem liệu quy trình đó có yêu cầu mô tả bằng đồ họa hay không. Nếu quy trình này đơn giản và rõ ràng, có ít chức năng trong đó và việc trình bày bằng đồ họa sẽ không cải thiện được sự hiểu biết hoặc nhận thức của nó thì không cần thiết phải lãng phí thời gian cho nó. Trong trường hợp này, chỉ cần mô tả nó ở dạng văn bản ở dạng bảng là đủ. Nếu quá trình phức tạp, với nhiều điều kiện logic khác nhau thì tốt hơn nên cung cấp sơ đồ đồ họa của nó. Sơ đồ luôn dễ hiểu hơn. Nếu bạn quyết định mô tả một quy trình bằng đồ họa, điều này không có nghĩa là bạn không cần cung cấp mô tả bằng văn bản. Những thứ kia. Trong mọi trường hợp, phải có một mô tả văn bản về quy trình và nó phải được thực hiện theo cùng một sơ đồ. Sẽ rất thuận tiện khi thực hiện việc này dưới dạng bảng trong đó bạn chỉ ra: người thực hiện từng bước, thông tin họ nhận được làm đầu vào, mô tả từng bước, thông tin nào được tạo ở đầu ra. Dưới đây chúng ta sẽ xem xét một ví dụ về cách điều này có thể trông như thế nào.
Phối hợp với người thực hiện và chủ sở hữu quy trình kinh doanh	Cách tốt nhất để hiểu bạn đã chọn phong cách trình bày thông tin tốt đến mức nào là hiển thị kết quả cho người dùng (người thực hiện) quy trình. Điều quan trọng nhất trong việc trình diễn như vậy là hiểu bạn hiểu quy trình đó chính xác như thế nào thực hiện Nếu quá trình đào tạo của nhóm dự án thành công thì bạn có thể mong đợi phản hồi khá đầy đủ từ những người thực hiện. Và nếu họ bắt đầu quan tâm thì mọi thứ sẽ tiến triển nhanh hơn nhiều, những nội dung làm rõ và mâu thuẫn đã xác định phải được phản ánh trong mô tả (cập nhật) và nếu cần, thao tác phải được lặp lại.
Cô lập các chỉ số quy trình kinh doanh	Khi bạn đã hiểu đúng về cách thức thực hiện một quy trình kinh doanh, bạn cần nghĩ đến các chỉ số có thể đo lường chất lượng hoặc tốc độ của quy trình. Điều này không dễ dàng, nhưng nó là cần thiết. Chỉ số phải đo lường được, tức là được biểu thị bằng số và phải có một cách đơn giản để có được giá trị này. Nếu không thể xác định được chỉ số đo được thì có nguy cơ quy trình kinh doanh được xác định không thành công. Ngoài ra, sẽ không có cách nào để hiểu (xét cho cùng thì không thể đo lường được) liệu những thay đổi trong quy trình có dẫn đến sự cải thiện của nó hay không.
Tài liệu cuối cùng của quy trình kinh doanh	Sau khi đảm bảo rằng chúng tôi hiểu rõ về cách thực hiện (hoặc nên) một quy trình, chúng tôi có thể đưa quy trình đó vào tài liệu.
	Có thể có các lựa chọn khác: các quy trình đang được xem xét sẽ được phân tích và tối ưu hóa, mô tả công việc sẽ được phát triển, các quyết định sẽ được đưa ra về nhu cầu tự động hóa các quy trình riêng lẻ, v.v. Đây có thể là một dự án riêng biệt: mô tả các quy trình kinh doanh.

Bây giờ chúng ta hãy xem cách tiếp cận nghiên cứu các yêu cầu đối với một hệ thống thông tin sẽ như thế nào với sự phản ánh sâu hơn của chúng trong Điều khoản tham chiếu

	Làm gì và làm như thế nào
Chúng tôi nhấn mạnh yêu cầu kinh doanh/lĩnh vực tự động hóa	Cô lập toàn bộ khu vực tự động hóa (ví dụ: “Hàng tồn kho”) làm yêu cầu được sử dụng trong thực tế, tuy nhiên, đây không phải là cách hiệu quả nhất để trình bày chi tiết các yêu cầu. Khu vực tự động hóa là một nhóm các yêu cầu và tốt nhất nên xem xét chúng một cách riêng lẻ. Ví dụ: “Kế toán nhận hàng tại kho”
Nghiên cứu chi tiết về yêu cầu kinh doanh	Nghiên cứu chi tiết về một yêu cầu kinh doanh đề cập đến cách người dùng cuối muốn xem nó và sẽ sử dụng nó như thế nào (tất nhiên là phù hợp với mục tiêu của dự án). Trong công nghệ công nghệ phần mềm, điều này thường được gọi là "trường hợp sử dụng". Do đó, việc nghiên cứu chi tiết về yêu cầu kinh doanh sẽ hướng tới việc phát triển các trường hợp sử dụng. Một ví dụ về tùy chọn này được đưa ra trong Phụ lục 2 của bài viết. Trong những trường hợp đơn giản nhất, các ca sử dụng không nhất thiết phải được vẽ dưới dạng sơ đồ đồ họa; bạn có thể giới hạn bản thân trong việc xây dựng văn bản. Ví dụ: yêu cầu “Khi nhập một mặt hàng, giá phải được tính bằng giá mua + 20%” là không có ý nghĩa. Ở dạng sơ đồ, việc thể hiện các yêu cầu kết hợp với khu vực tự động hóa là hợp lý, như trong ví dụ ở Phụ lục 2.
Yêu cầu mô hình hóa trong hệ thống thông tin	Đây rồi! Có thể bạn còn nhớ, tôi đã lưu ý đến yếu tố quan trọng nhất này trong phương pháp phát triển Thông số kỹ thuật. “Xây dựng mô hình - bạn sẽ nhận được kết quả!” Những gì cần phải được mô hình hóa? Cần phải mô hình hóa các trường hợp sử dụng thu được ở giai đoạn trước. Đầu ra của mô phỏng sẽ là gì? Kết quả phải là một chương trình trình diễn trong đó dữ liệu người dùng được nhập vào, tốt nhất là chương trình quen thuộc với thính giác của người dùng (người dùng), có tính đến các chi tiết cụ thể của ngành và các vấn đề hiện tại. Và chúng được nhập vào là có lý do, nhưng phải rõ ràng dữ liệu này đến từ đâu và nó được tính toán như thế nào. Đến đây, người đọc sẽ có câu hỏi: Nhưng điều gì sẽ xảy ra nếu bạn dự định phát triển một hệ thống mới và đơn giản là không có gì để lập mô hình? Điều gì sẽ xảy ra nếu bản demo thiếu chức năng và hệ thống cần được cải thiện? Tất nhiên, bạn phải đối mặt với tình huống như vậy và đó là điều bình thường. Phải làm gì? Nếu hệ thống hoàn toàn mới (như người ta nói, “từ đầu”), thì bạn sẽ phải lập mô hình chủ yếu trên giấy, ở đây sơ đồ ca sử dụng sẽ giúp ích cho bạn rất nhiều. Một phần, việc phác thảo một số dạng màn hình được cho là sẽ được phát triển (ngay trong môi trường mà quá trình phát triển sẽ được thực hiện) là rất hợp lý, bởi vì vẽ chúng trong một số trình soạn thảo sẽ mất nhiều thời gian hơn và công việc này thật nhàm chán. Nếu một hệ thống làm sẵn đang được triển khai và nó thiếu chức năng thì không có gì phải lo lắng, dữ liệu được nhập thủ công và người dùng sẽ được thông báo rằng sau những sửa đổi cần thiết, dữ liệu sẽ được tính toán theo cách này và cách khác (và anh ấy nhìn thấy nó). Nên đính kèm một mô hình như vậy với một mô tả văn bản, thậm chí là mô tả ngắn gọn, để người dùng có thể độc lập thử làm việc với mô hình đó khi rảnh rỗi. Trong cùng một mô tả, bạn có thể đưa ra các yêu cầu cải tiến.
Trình diễn mô hình thông tin cho nhóm làm việc	Chúng tôi hiển thị mô hình kết quả cho Khách hàng và cho biết mọi thứ sẽ hoạt động như thế nào. Tốt hơn là nên chứng minh mô hình bằng các hệ thống con, tức là. theo nhóm yêu cầu. Nếu sơ đồ được đề xuất sẽ không hiệu quả với khách hàng, bạn cần suy nghĩ về các trường hợp sử dụng khác, thực hiện các thay đổi đối với mô hình và hiển thị lại. Chỉ khi có niềm tin rằng mô hình được hoạch định sẽ “sống” cho một khách hàng nhất định thì mô hình đó mới được coi là thành công.
Phát triển thử nghiệm	Tại sao cần xét nghiệm? Cách chúng tôi có thể thực hiện các yêu cầu sẽ cần phải được kiểm tra. Theo đó, nên làm bài kiểm tra tất cả các lĩnh vực trọng điểm, các thuật toán phức tạp, v.v. Những bài kiểm tra này cũng có thể được sử dụng khi nộp bài. Không nhất thiết phải thực hiện kiểm tra mọi chức năng của hệ thống; ý thức chung nên được sử dụng ở mọi nơi. Nếu chúng ta đang nói về một hệ thống làm sẵn, thì việc thực hiện thử nghiệm “nhập một phần tử mới vào danh mục khách hàng” sẽ trông thật ngu ngốc và lãng phí thời gian và công sức. Nhưng nếu đây là một hệ thống hoàn toàn mới thì điều này hoàn toàn có thể xảy ra. Tại sao phải kiểm tra nếu chưa có hệ thống?Thứ nhất, nhà phát triển sẽ hiểu rõ hơn những gì họ muốn đạt được từ anh ta. Thứ hai, chúng tôi làm cho cuộc sống của người thử nghiệm trở nên dễ dàng hơn (ai đó sẽ kiểm tra kết quả phát triển). Nhìn chung, kiểm thử là một bộ môn riêng biệt, không hề đơn giản với nhiều kỹ thuật. Trong thực tế, theo quy định, các phương pháp thử nghiệm đơn giản nhất vẫn được sử dụng.
Tài liệu hóa các yêu cầu dưới dạng Thông số kỹ thuật	Thông tin được thu thập ở các giai đoạn trước sẽ chính xác là những gì cần được đưa vào cơ sở của tài liệu “Thông số kỹ thuật” trong phần yêu cầu. Vì vậy, tất cả những gì còn lại là định dạng chính xác tất cả.
Các bước tiếp theo (hoặc thiếu), tùy thuộc vào mục tiêu của dự án	Có thể mất nhiều thời gian hơn để bắt đầu quá trình phát triển, tìm kiếm đối tác cho dự án, đấu thầu, v.v., tất cả đều phụ thuộc vào tình hình.

Có, việc xây dựng Điều khoản tham chiếu là một quá trình tốn nhiều công sức và do đó tốn kém. Nhưng nếu nó được thực hiện một cách chính xác, nó sẽ giúp Khách hàng giảm bớt những kỳ vọng chưa được đáp ứng. Nhà thầu phải làm theo yêu cầu của Khách hàng và không được làm lại một việc cả trăm lần. Và nói chung, nó mang lại sự minh bạch cho toàn bộ dự án.

GOST 34.602-89 Công nghệ thông tin. Một bộ tiêu chuẩn cho các hệ thống tự động. Thông số kỹ thuật để tạo ra một hệ thống tự động (Thay vì GOST 24.201-85)

Ngày giới thiệu từ 01/01/1990

Tiêu chuẩn này áp dụng cho các hệ thống tự động hóa (AS) để tự động hóa các loại hoạt động khác nhau (quản lý, thiết kế, nghiên cứu, v.v.), bao gồm cả sự kết hợp của chúng và thiết lập thành phần, nội dung, quy tắc để soạn thảo tài liệu “Thông số kỹ thuật để tạo ( hệ thống phát triển hoặc hiện đại hóa)" (sau đây gọi tắt là TK cho AS).

1. QUY ĐỊNH CHUNG

1.1. Thông số kỹ thuật của nhà máy điện hạt nhân là tài liệu chính xác định các yêu cầu và quy trình tạo ra (phát triển hoặc hiện đại hóa - sau đó là tạo ra) một hệ thống tự động, theo đó việc phát triển nhà máy điện hạt nhân được thực hiện và sự chấp nhận của nó khi vận hành.

1.2. Thông số kỹ thuật cho NPP được phát triển cho toàn bộ hệ thống, nhằm mục đích hoạt động độc lập hoặc là một phần của hệ thống khác.

Ngoài ra, có thể phát triển các thông số kỹ thuật cho các bộ phận của NPP:

đối với các hệ thống con AS, tổ hợp nhiệm vụ AS, v.v... phù hợp với các yêu cầu của tiêu chuẩn này;
đối với linh kiện phần cứng và hệ thống phần mềm, phần cứng theo tiêu chuẩn ESKD, SRPP;
đối với phần mềm theo tiêu chuẩn ESPD;
đối với các sản phẩm thông tin phù hợp với GOST 19.201 và NTD hợp lệ trong bộ phận khách hàng của AS.

Ghi chú. Các thông số kỹ thuật cho hệ thống điều khiển tự động cho một nhóm đối tượng được kết nối với nhau chỉ nên bao gồm các yêu cầu chung cho nhóm đối tượng đó. Các yêu cầu cụ thể của đối tượng điều khiển riêng lẻ phải được phản ánh trong thông số kỹ thuật của hệ thống điều khiển tự động của đối tượng này.

1.3. Các yêu cầu đối với AS trong phạm vi được thiết lập theo tiêu chuẩn này có thể được đưa vào nhiệm vụ thiết kế cho một cơ sở tự động hóa mới được tạo ra. Trong trường hợp này, các thông số kỹ thuật của nhà máy điện hạt nhân không được phát triển.

1.4. Các yêu cầu trong quy định kỹ thuật đối với nhà máy điện hạt nhân phải phù hợp với trình độ phát triển khoa học và công nghệ hiện nay và không thua kém các yêu cầu tương tự đối với các nhà máy điện tương tự hiện đại nhất trong và ngoài nước. Các yêu cầu được quy định trong thông số kỹ thuật cho NPP không được hạn chế nhà phát triển hệ thống trong việc tìm kiếm và triển khai các giải pháp kỹ thuật, kỹ thuật, kinh tế và các giải pháp khác hiệu quả nhất.

1.5. Các thông số kỹ thuật cho nhà máy điện hạt nhân được phát triển trên cơ sở dữ liệu ban đầu, bao gồm cả dữ liệu có trong tài liệu cuối cùng của giai đoạn “Nghiên cứu và biện minh cho việc tạo ra các nhà máy điện hạt nhân”, do GOST 24.601 thiết lập.

1.6. Các thông số kỹ thuật cho AS chỉ bao gồm những yêu cầu bổ sung cho các yêu cầu dành cho các hệ thống loại này (ACS, CAD, ASNI, v.v.) có trong tài liệu kỹ thuật và quy chuẩn hiện hành và được xác định bởi các chi tiết cụ thể của đối tượng cụ thể mà nó yêu cầu. hệ thống đang được tạo ra.

1.7. Những thay đổi về thông số kỹ thuật của NPP được chính thức hóa bằng phần bổ sung hoặc giao thức được ký bởi khách hàng và nhà phát triển. Giao thức bổ sung hoặc quy định cụ thể là một phần không thể thiếu trong thông số kỹ thuật của NPP. Trên trang tiêu đề của thông số kỹ thuật của loa phải có mục “Hợp lệ từ…”.

2. THÀNH PHẦN VÀ NỘI DUNG

2.1. Thông số kỹ thuật của NPP bao gồm các phần sau, có thể được chia thành các phần phụ:

1. Thông tin chung;
2) mục đích và mục tiêu của việc tạo ra (phát triển) hệ thống;
3) đặc điểm của đối tượng tự động hóa;
4) yêu cầu hệ thống;
5) thành phần và nội dung công việc tạo ra hệ thống;
6) quy trình kiểm soát và chấp nhận hệ thống;
7) yêu cầu về thành phần và nội dung công việc chuẩn bị đối tượng tự động hóa đưa hệ thống vào vận hành;
8) yêu cầu về tài liệu;
9) nguồn phát triển.

Các ứng dụng có thể được bao gồm trong thông số kỹ thuật của loa.

2.2. Tùy thuộc vào loại, mục đích, tính năng cụ thể của đối tượng tự động hóa và điều kiện hoạt động của hệ thống, có thể xây dựng các phần thông số kỹ thuật dưới dạng ứng dụng, giới thiệu các phần bổ sung, loại trừ hoặc kết hợp các tiểu mục của thông số kỹ thuật. .

Thông số kỹ thuật cho các bộ phận của hệ thống không bao gồm các phần trùng lặp nội dung của các phần thông số kỹ thuật cho toàn bộ hệ thống.

2.3. Trong phần “Thông tin chung” cho biết:

1) tên đầy đủ của hệ thống và ký hiệu của nó;
2) mã chủ đề hoặc mã (số) hợp đồng;
3) tên doanh nghiệp (hiệp hội) của nhà phát triển và khách hàng (người dùng) hệ thống và thông tin chi tiết của họ;
4) danh sách các tài liệu trên cơ sở đó hệ thống được tạo ra, ai và khi nào các tài liệu này được phê duyệt;
5) ngày dự kiến bắt đầu và kết thúc công việc xây dựng hệ thống;
6) thông tin về các nguồn và thủ tục tài trợ cho công việc;
7) quy trình đăng ký và trình bày cho khách hàng về kết quả công việc tạo ra hệ thống (các bộ phận của nó), về sản xuất và điều chỉnh các phương tiện riêng lẻ (phần cứng, phần mềm, thông tin) và các tổ hợp phần mềm và phần cứng (phần mềm và phương pháp luận) của hệ thống.

2.4. Mục “Mục đích và mục tiêu hình thành (phát triển) hệ thống” gồm các tiểu mục:

1) mục đích của hệ thống;
2) mục tiêu của việc tạo ra hệ thống.

2.4.1. Trong tiểu mục “Mục đích của hệ thống”, chúng chỉ ra loại hoạt động được tự động hóa (quản lý, thiết kế, v.v.) và danh sách các đối tượng tự động hóa (cơ sở vật chất) mà nó được cho là sẽ được sử dụng.

Đối với các hệ thống điều khiển tự động, danh sách các cơ quan (điểm) điều khiển tự động và các đối tượng được điều khiển được chỉ định bổ sung.

2.4.2. Trong tiểu mục Mục tiêu của việc tạo ra một hệ thống, tên và các giá trị cần thiết của các chỉ số kỹ thuật, công nghệ, sản xuất, kinh tế hoặc các chỉ số khác của đối tượng tự động hóa phải đạt được khi tạo ra một hệ thống tự động được đưa ra và chỉ ra tiêu chí để đánh giá việc đạt được các mục tiêu của việc tạo ra hệ thống.

2.5. Trong phần “Đặc điểm của đối tượng tự động hóa” được đưa ra như sau:

1) thông tin ngắn gọn về đối tượng tự động hóa hoặc các liên kết đến tài liệu chứa thông tin đó;
2) thông tin về điều kiện hoạt động của đối tượng tự động hóa và đặc điểm của môi trường.

Ghi chú: Đối với CAD, phần này cung cấp thêm các thông số và đặc điểm chính của đối tượng thiết kế.

2.6. Phần “Yêu cầu hệ thống” bao gồm các phần phụ sau:

1) các yêu cầu đối với toàn bộ hệ thống;
2) yêu cầu về chức năng (nhiệm vụ) do hệ thống thực hiện;
3) các yêu cầu đối với các loại hình an ninh.

Thành phần các yêu cầu đối với hệ thống có trong phần này của thông số kỹ thuật dành cho NPP được thiết lập tùy thuộc vào loại, mục đích, tính năng cụ thể và điều kiện vận hành của một hệ thống cụ thể. Mỗi tiểu mục cung cấp các liên kết đến tài liệu kỹ thuật và quy chuẩn hiện hành xác định các yêu cầu đối với các hệ thống thuộc loại tương ứng.

2.6.1. Trong tiểu mục “Yêu cầu đối với toàn bộ hệ thống” chỉ ra:

yêu cầu về cấu trúc và chức năng của hệ thống;
yêu cầu về số lượng và trình độ của nhân viên hệ thống và phương thức hoạt động của họ;
chỉ số điểm đến;
yêu cầu về độ tin cậy;
yêu cầu an toàn;
yêu cầu về công thái học và thẩm mỹ kỹ thuật;
yêu cầu về khả năng vận chuyển của loa di động;
yêu cầu vận hành, bảo trì, sửa chữa và bảo quản các bộ phận của hệ thống;
yêu cầu bảo vệ thông tin khỏi bị truy cập trái phép;
yêu cầu về an toàn thông tin khi xảy ra sự cố;
yêu cầu bảo vệ khỏi ảnh hưởng bên ngoài;
yêu cầu về độ tinh khiết của bằng sáng chế;
yêu cầu tiêu chuẩn hóa, thống nhất;
Các yêu cầu bổ sung.

2.6.1.1. Yêu cầu về cấu trúc và hoạt động của hệ thống bao gồm:

1) danh sách các hệ thống con, mục đích và đặc điểm chính của chúng, yêu cầu về số lượng cấp bậc và mức độ tập trung của hệ thống;
2) yêu cầu về phương pháp và phương tiện liên lạc để trao đổi thông tin giữa các thành phần hệ thống;
3) yêu cầu về đặc điểm mối quan hệ của hệ thống được tạo ra với các hệ thống liên quan, yêu cầu về tính tương thích của nó, bao gồm hướng dẫn về phương pháp trao đổi thông tin (tự động, bằng cách gửi tài liệu, qua điện thoại, v.v.);
4) yêu cầu về chế độ vận hành hệ thống;
5) yêu cầu chẩn đoán hệ thống;
6) triển vọng phát triển và hiện đại hóa hệ thống.

2.6.1.2. Yêu cầu về số lượng và trình độ nhân sự tại các nhà máy điện hạt nhân bao gồm:

yêu cầu về số lượng nhân sự (người sử dụng) của NMĐHN;
yêu cầu về trình độ nhân sự, quy trình đào tạo và kiểm soát kiến thức và kỹ năng của họ;
chế độ vận hành cần thiết cho nhân viên nhà máy.

2.6.1.3. Trong các yêu cầu về các chỉ số về mục đích của AS, các giá trị của các tham số mô tả mức độ tuân thủ của hệ thống với mục đích của nó được đưa ra.

Đối với ACS chỉ ra:

mức độ thích ứng của hệ thống với những thay đổi trong quy trình và phương pháp điều khiển, với những sai lệch trong các tham số của đối tượng điều khiển;
giới hạn chấp nhận được của việc hiện đại hóa và phát triển hệ thống;
đặc điểm xác suất-thời gian theo đó mục đích dự định của hệ thống được bảo tồn.

2.6.1.4. Yêu cầu về độ tin cậy bao gồm:

1) thành phần và giá trị định lượng của các chỉ số độ tin cậy cho toàn bộ hệ thống hoặc các hệ thống con của nó;
2) danh sách các tình huống khẩn cấp mà các yêu cầu về độ tin cậy phải được quy định và giá trị của các chỉ số tương ứng;
3) các yêu cầu về độ tin cậy của phần cứng và phần mềm;
4) yêu cầu về phương pháp đánh giá và giám sát các chỉ số độ tin cậy ở các giai đoạn khác nhau của quá trình tạo hệ thống theo các tài liệu quy định và kỹ thuật hiện hành.

2.6.1.5. Yêu cầu về an toàn bao gồm các yêu cầu đảm bảo an toàn trong quá trình lắp đặt, vận hành, bảo trì, sửa chữa các thiết bị kỹ thuật của hệ thống (bảo vệ khỏi tác động của dòng điện, điện từ trường, ồn âm thanh…), mức độ chiếu sáng, độ rung và tiếng ồn cho phép. tải .

2.6.1.6. Các yêu cầu về công thái học và thẩm mỹ kỹ thuật bao gồm các chỉ báo AC đặt ra chất lượng cần thiết trong tương tác giữa người và máy và sự thoải mái về điều kiện làm việc cho nhân viên.

2.6.1.7. Đối với loa di động, yêu cầu về khả năng vận chuyển bao gồm yêu cầu về thiết kế đảm bảo khả năng vận chuyển của các phương tiện kỹ thuật của hệ thống cũng như yêu cầu về phương tiện đi lại.

2.6.1.8. Yêu cầu vận hành, bảo trì, sửa chữa và bảo quản bao gồm:

1) các điều kiện và quy định (phương thức) vận hành phải đảm bảo sử dụng các phương tiện kỹ thuật (TS) của hệ thống với các chỉ số kỹ thuật được chỉ định, bao gồm loại và tần suất bảo trì TS của hệ thống hoặc cho phép vận hành mà không cần bảo trì ;
2) các yêu cầu sơ bộ về diện tích cho phép dành cho người và hệ thống phương tiện, về các thông số của mạng lưới cung cấp điện, v.v.;
3) các yêu cầu về số lượng, trình độ của nhân viên phục vụ và phương thức hoạt động của họ;
4) các yêu cầu về thành phần, vị trí và điều kiện bảo quản của bộ sản phẩm và dụng cụ dự phòng;
5) yêu cầu về quy định bảo trì.

2.6.1.9. Các yêu cầu để bảo vệ thông tin khỏi bị truy cập trái phép bao gồm các yêu cầu được thiết lập trong tài liệu khoa học và kỹ thuật áp dụng trong ngành (bộ phận) của khách hàng.

2.6.1.10. Yêu cầu về an toàn thông tin đưa ra danh sách các sự kiện: sự cố, hỏng hóc của thiết bị kỹ thuật (trong đó có mất điện),... trong đó phải đảm bảo an toàn thông tin trong hệ thống.

2.6.1.11. Các yêu cầu đối với phương tiện bảo vệ chống ảnh hưởng từ bên ngoài bao gồm:

1) các yêu cầu về bảo vệ vô tuyến điện tử của nhà máy điện hạt nhân;
2) yêu cầu về độ bền, độ ổn định và độ bền trước các tác động bên ngoài (môi trường sử dụng).

2.6.1.12. Các yêu cầu về độ tinh khiết bằng sáng chế chỉ ra danh sách các quốc gia mà độ tinh khiết bằng sáng chế của hệ thống và các bộ phận của nó phải được đảm bảo.

2.6.1.13. Yêu cầu tiêu chuẩn hóa, thống nhất bao gồm: các chỉ số xác định mức độ yêu cầu sử dụng tiêu chuẩn, các phương pháp thống nhất để thực hiện các chức năng (nhiệm vụ) của hệ thống, phần mềm được cung cấp, các phương pháp và mô hình toán học tiêu chuẩn, các giải pháp thiết kế tiêu chuẩn, các biểu mẫu tài liệu quản lý thống nhất được thiết lập bởi GOST 6.10.1, Bộ phân loại thông tin kinh tế và kỹ thuật của Liên minh và các bộ phân loại thuộc các danh mục khác phù hợp với phạm vi ứng dụng, yêu cầu của chúng đối với việc sử dụng các máy trạm, bộ phận và tổ hợp tự động tiêu chuẩn.

2.6.1.14. Các yêu cầu bổ sung bao gồm:

1) các yêu cầu về việc trang bị hệ thống các thiết bị đào tạo nhân sự (máy mô phỏng, các thiết bị khác cho mục đích tương tự) và tài liệu về chúng;
2) các yêu cầu đối với thiết bị dịch vụ, biểu tượng của các thành phần hệ thống thử nghiệm;
3) các yêu cầu hệ thống liên quan đến điều kiện vận hành đặc biệt;
4) các yêu cầu đặc biệt theo quyết định của nhà phát triển hệ thống hoặc khách hàng.

2.6.2. Trong tiểu mục “Yêu cầu đối với chức năng (nhiệm vụ)” do hệ thống thực hiện bao gồm:

1) đối với mỗi hệ thống con, danh sách các chức năng, nhiệm vụ hoặc tổ hợp của chúng (bao gồm cả những chức năng đảm bảo sự tương tác giữa các bộ phận của hệ thống) được tự động hóa;

khi tạo một hệ thống trong hai hàng đợi trở lên - danh sách các hệ thống con chức năng, các chức năng hoặc nhiệm vụ riêng lẻ được đưa vào hoạt động trong hàng đợi đầu tiên và các hàng tiếp theo;

2) Quy định về thời gian thực hiện từng chức năng, nhiệm vụ (hoặc bộ nhiệm vụ);

3) yêu cầu về chất lượng thực hiện từng chức năng (nhiệm vụ hoặc tập hợp nhiệm vụ), hình thức trình bày thông tin đầu ra, đặc điểm về độ chính xác cần thiết và thời gian thực hiện, yêu cầu về thực hiện đồng thời một nhóm chức năng, độ tin cậy về kết quả;

4) danh sách và tiêu chí hư hỏng cho từng chức năng mà các yêu cầu về độ tin cậy được quy định.

2.6.3. Trong tiểu mục “Yêu cầu đối với các loại hỗ trợ”, tùy thuộc vào loại hệ thống, các yêu cầu về toán học, thông tin, ngôn ngữ, phần mềm, kỹ thuật, đo lường, tổ chức, phương pháp và các loại hỗ trợ khác được đưa ra cho hệ thống.

2.6.3.1. Để hỗ trợ toán học cho hệ thống, đưa ra các yêu cầu về thành phần, phạm vi ứng dụng (hạn chế) và phương pháp sử dụng các phương pháp, mô hình toán học trong hệ thống, các thuật toán chuẩn và thuật toán cần phát triển.

2.6.3.2. Yêu cầu hỗ trợ thông tin của hệ thống là:

1) thành phần, cấu trúc và phương pháp tổ chức dữ liệu trong hệ thống;
2) trao đổi thông tin giữa các thành phần hệ thống;
3) khả năng tương thích thông tin với các hệ thống liên quan;
4) về việc sử dụng các phân loại ngành, tài liệu và phân loại thống nhất của toàn Liên minh và đã đăng ký hoạt động tại một doanh nghiệp nhất định;
5) về việc sử dụng hệ thống quản lý cơ sở dữ liệu;
6) cấu trúc của quá trình thu thập, xử lý, truyền dữ liệu trong hệ thống và trình bày dữ liệu;
7) để bảo vệ dữ liệu khỏi bị phá hủy trong các sự cố và sự cố mất điện hệ thống;
8) để kiểm soát, lưu trữ, cập nhật và khôi phục dữ liệu;
9) thủ tục trao hiệu lực pháp lý cho các tài liệu được tạo ra bằng phương tiện kỹ thuật của NPP (theo GOST 6.10.4).

2.6.3.3. Để hỗ trợ ngôn ngữ của hệ thống, các yêu cầu được đưa ra về việc sử dụng ngôn ngữ lập trình cấp cao trong hệ thống, ngôn ngữ tương tác người dùng và phương tiện kỹ thuật của hệ thống, cũng như các yêu cầu về mã hóa và giải mã dữ liệu, nhập dữ liệu- ngôn ngữ đầu ra, ngôn ngữ thao tác dữ liệu, phương tiện mô tả lĩnh vực chủ đề (đối tượng tự động hóa), đến cách tổ chức đối thoại.

2.6.3.4. Đối với phần mềm hệ thống, danh sách phần mềm đã mua được cung cấp cũng như các yêu cầu:

1) sự độc lập của phần mềm với SVT đã sử dụng và môi trường vận hành;
2) chất lượng phần mềm cũng như các phương pháp cung cấp và kiểm soát phần mềm;
3) nếu cần thiết, phối hợp phần mềm mới được phát triển với quỹ thuật toán và chương trình.

2.6.3.5. Để hỗ trợ kỹ thuật cho hệ thống, các yêu cầu sau được đưa ra:

1) các loại phương tiện kỹ thuật, bao gồm các loại tổ hợp phương tiện kỹ thuật, tổ hợp phần mềm, phần cứng và các thành phần khác được phép sử dụng trong hệ thống;
2) các đặc tính chức năng, thiết kế và vận hành của các phương tiện hỗ trợ kỹ thuật của hệ thống.

2.6.3.6. Các yêu cầu về hỗ trợ đo lường bao gồm:

1) danh sách sơ bộ các kênh đo;
2) các yêu cầu về độ chính xác của phép đo các thông số và (hoặc) về đặc tính đo lường của các kênh đo;
3) các yêu cầu về tính tương thích về mặt đo lường của các phương tiện kỹ thuật của hệ thống;
4) danh sách các kênh điều khiển và tính toán của hệ thống cần đánh giá các đặc tính chính xác;
5) các yêu cầu về hỗ trợ đo lường của phần cứng và phần mềm có trong các kênh đo của hệ thống, các công cụ điều khiển tích hợp, sự phù hợp về mặt đo lường của các kênh đo và các dụng cụ đo được sử dụng trong quá trình vận hành và thử nghiệm hệ thống;
6) loại chứng nhận đo lường (cấp bang hoặc cấp cục) nêu rõ quy trình thực hiện chứng nhận đó và tổ chức tiến hành chứng nhận.

2.6.3.7. Để hỗ trợ tổ chức, các yêu cầu sau được đưa ra:

1) cơ cấu và chức năng của các đơn vị tham gia vận hành hệ thống hoặc đảm bảo vận hành;

2) tổ chức hoạt động của hệ thống và quy trình tương tác giữa nhân viên nhà máy và nhân viên cơ sở tự động hóa;

3) để bảo vệ khỏi những hành động sai lầm của nhân viên hệ thống.

2.6.3.8. Để hỗ trợ về mặt phương pháp, CAD cung cấp các yêu cầu về thành phần tài liệu quy định và kỹ thuật của hệ thống (danh sách các tiêu chuẩn, quy định, phương pháp, v.v. được sử dụng trong hoạt động của hệ thống).

2.7. Phần “Thành phần và nội dung công việc tạo ra (phát triển) hệ thống” phải có danh sách các giai đoạn và giai đoạn công việc tạo ra hệ thống theo GOST 24.601, thời gian thực hiện, danh sách các tổ chức thực hiện công việc, liên kết đến các tài liệu xác nhận sự đồng ý của các tổ chức này tham gia tạo ra hệ thống hoặc hồ sơ xác định người chịu trách nhiệm (khách hàng hoặc nhà phát triển) thực hiện công việc này.

Phần này cũng cung cấp:

1) danh sách các tài liệu, theo GOST 34.201-89, được trình bày ở cuối các giai đoạn và giai đoạn công việc liên quan;
2) loại hình và thủ tục tiến hành kiểm tra tài liệu kỹ thuật (giai đoạn, giai đoạn, khối lượng tài liệu được kiểm tra, tổ chức chuyên môn);
3) chương trình làm việc nhằm đảm bảo mức độ tin cậy cần thiết của hệ thống đang được phát triển (nếu cần);
4) danh sách các công việc hỗ trợ đo lường ở tất cả các giai đoạn tạo ra hệ thống, nêu rõ thời hạn và tổ chức thực hiện (nếu cần).

2.8. Trong phần “Quy trình kiểm soát và chấp nhận hệ thống” chỉ ra:

1) loại, thành phần, phạm vi và phương pháp thử nghiệm của hệ thống và các thành phần của nó (các loại thử nghiệm theo tiêu chuẩn hiện hành áp dụng cho hệ thống đang được phát triển);
2) yêu cầu chung về nghiệm thu công việc theo từng giai đoạn (danh sách doanh nghiệp, tổ chức tham gia, địa điểm và thời gian), quy trình phối hợp và phê duyệt hồ sơ nghiệm thu;
H) tình trạng của ủy ban tiếp nhận (tiểu bang, liên ngành, khoa).

2.9. Trong phần “Yêu cầu về thành phần và nội dung công việc chuẩn bị đối tượng tự động hóa để vận hành hệ thống”, cần đưa ra danh sách các hoạt động chính và người thực hiện chúng cần thực hiện khi chuẩn bị đối tượng tự động hóa để đưa vào vận hành. nhà máy đi vào hoạt động.

Danh sách các hoạt động chính bao gồm:

1) đưa thông tin vào hệ thống (theo yêu cầu về hỗ trợ thông tin và ngôn ngữ) sang dạng phù hợp để xử lý bằng máy tính;
2) những thay đổi cần được thực hiện trong đối tượng tự động hóa;
3) tạo điều kiện cho hoạt động của đối tượng tự động hóa, theo đó đảm bảo sự tuân thủ của hệ thống được tạo ra với các yêu cầu trong thông số kỹ thuật;
4) tạo ra các đơn vị và dịch vụ cần thiết cho hoạt động của hệ thống;
5) thời gian và thủ tục bố trí nhân sự và đào tạo.

Ví dụ: đối với hệ thống điều khiển tự động, họ đưa ra:

những thay đổi về phương pháp quản lý được áp dụng;
tạo điều kiện cho hoạt động của các thành phần của hệ thống điều khiển tự động, đảm bảo hệ thống tuân thủ các yêu cầu trong thông số kỹ thuật.

2.10. Trong phần “Yêu cầu về Tài liệu”, nội dung sau được đưa ra:

1) danh sách các bộ và loại tài liệu sẽ được phát triển, được nhà phát triển và Khách hàng của hệ thống thống nhất, đáp ứng các yêu cầu của GOST 34.201-89 và NTD của ngành khách hàng;
danh mục văn bản ban hành trên phương tiện máy tính;
các yêu cầu đối với tài liệu vi phim;
2) các yêu cầu về việc ghi lại các thành phần thành phần để sử dụng trong nhiều ngành phù hợp với các yêu cầu của ESKD và ESPD;
3) trong trường hợp không có tiêu chuẩn tiểu bang xác định các yêu cầu đối với các thành phần hệ thống tài liệu, hãy bổ sung thêm các yêu cầu về thành phần và nội dung của các tài liệu đó.

2.11. Phần “Nguồn phát triển” phải liệt kê các tài liệu và tài liệu thông tin (nghiên cứu khả thi, báo cáo về công việc nghiên cứu đã hoàn thành, tài liệu thông tin về các hệ thống tương tự trong và ngoài nước, v.v.), trên cơ sở đó các thông số kỹ thuật được phát triển và cần được áp dụng. được sử dụng để tạo ra hệ thống.

2.12. Với các phương pháp đã được phê duyệt, các thông số kỹ thuật cho nhà máy điện hạt nhân bao gồm các phụ lục có chứa:

1) tính toán hiệu quả dự kiến của hệ thống;
2) đánh giá trình độ khoa học và kỹ thuật của hệ thống.

Các ứng dụng được bao gồm trong thông số kỹ thuật của NPP theo thỏa thuận giữa nhà phát triển và khách hàng của hệ thống.

3. QUY TẮC ĐĂNG KÝ

3.1. Các phần và tiểu mục của thông số kỹ thuật của NPP phải được sắp xếp theo thứ tự đã được thiết lập trong phần. 2 của tiêu chuẩn này.

3.2. Các thông số kỹ thuật của AS được soạn thảo theo yêu cầu của GOST 2.105.95 trên tờ A4 theo GOST 2.301 không có khung, dòng chữ chính và các cột bổ sung.

Số trang (trang) được đặt, bắt đầu từ trang đầu tiên sau trang tiêu đề, ở đầu trang (phía trên văn bản, ở giữa) sau khi cho biết mã TK trên AC.

3.3. Theo quy định, các giá trị của các chỉ số, định mức và yêu cầu được chỉ định với độ lệch tối đa hoặc giá trị tối đa và tối thiểu. Nếu các chỉ số, định mức và yêu cầu này được quy định rõ ràng bằng tài liệu khoa học và kỹ thuật thì thông số kỹ thuật của nhà máy phải chứa liên kết đến các tài liệu này hoặc các phần của chúng, cũng như các yêu cầu bổ sung có tính đến các tính năng của hệ thống đang được áp dụng. tạo. Trường hợp không xác lập được giá trị cụ thể của các chỉ tiêu, chỉ tiêu, yêu cầu trong quá trình xây dựng quy chuẩn kỹ thuật cho NMĐHN thì phải lập biên bản quy trình xây dựng và thống nhất các chỉ tiêu, chỉ tiêu, yêu cầu này:

“Yêu cầu (giá trị) cuối cùng được làm rõ trong quy trình... và được thỏa thuận bởi giao thức với... ở giai đoạn…”

Đồng thời, không có thay đổi nào được thực hiện đối với nội dung của thông số kỹ thuật của NPP.

3.4. Trang tiêu đề có chữ ký của khách hàng, nhà phát triển và tổ chức phê duyệt, được đóng dấu chính thức. Nếu cần thiết, trang tiêu đề sẽ được vẽ thành nhiều trang. Chữ ký của người xây dựng các thông số kỹ thuật cho nhà máy điện hạt nhân và các quan chức liên quan đến việc phê duyệt, xem xét dự thảo thông số kỹ thuật của nhà máy điện hạt nhân được đặt ở tờ cuối cùng.

Mẫu trang tiêu đề của thông số kỹ thuật xe cơ giới được nêu tại Phụ lục 2. Mẫu trang tiêu chuẩn kỹ thuật cuối cùng của xe cơ giới được nêu tại Phụ lục 3.

3.5. Nếu cần thiết, các mã được thiết lập trong ngành có thể được đặt trên trang tiêu đề của đặc tả kỹ thuật trên AS, ví dụ: phân loại bảo mật, mã công việc, số đăng ký đặc tả kỹ thuật, v.v.

3.6. Trang tiêu đề của phần bổ sung thông số kỹ thuật cho NPP được thiết kế giống như trang tiêu đề của thông số kỹ thuật. Thay vì tên “Thông số kỹ thuật” họ viết “Số bổ sung ... vào thông số kỹ thuật cho AC…”.

3.7. Trên các trang tiếp theo của phụ lục về thông số kỹ thuật của AS, cơ sở cho sự thay đổi, nội dung của sự thay đổi và các liên kết đến các tài liệu theo đó những thay đổi này được thực hiện.

3.8. Khi trình bày văn bản bổ sung cho các thông số kỹ thuật, bạn nên chỉ ra số lượng các đoạn, tiểu đoạn, bảng tương ứng của các thông số kỹ thuật chính trên AS, v.v. và sử dụng các từ: “thay thế”, “bổ sung”, “ loại trừ”, “nêu rõ trong lần xuất bản mới”.

THỦ TỤC PHÁT TRIỂN, PHÊ DUYỆT VÀ PHÊ DUYỆT TOR CHO NPP

1. Dự thảo thông số kỹ thuật cho NPP do tổ chức phát triển hệ thống xây dựng với sự tham gia của khách hàng trên cơ sở các yêu cầu kỹ thuật (ứng dụng, thông số kỹ thuật, chiến thuật, v.v.).

Trong quá trình tổ chức công việc mang tính cạnh tranh, khách hàng sẽ xem xét các phương án về thông số kỹ thuật thiết kế cho NPP, họ chọn phương án ưu tiên hoặc dựa trên phân tích so sánh, chuẩn bị phiên bản cuối cùng của thông số kỹ thuật cho AC với sự tham gia của nhà phát triển NPP tương lai.

2. Nhu cầu điều phối dự thảo thông số kỹ thuật của nhà máy điện hạt nhân với các cơ quan giám sát nhà nước và các tổ chức quan tâm khác được khách hàng của hệ thống và nhà phát triển các thông số kỹ thuật của dự án cho nhà máy điện hạt nhân cùng xác định,

Công việc điều phối dự thảo thông số kỹ thuật cho AC được thực hiện bởi nhà phát triển thông số kỹ thuật cho AC và khách hàng của hệ thống, mỗi bên thuộc các tổ chức thuộc Bộ (bộ) của mình.

3. Thời gian phê duyệt dự thảo quy chuẩn kỹ thuật của Nhà máy điện hạt nhân ở mỗi tổ chức không quá 15 ngày kể từ ngày nhận được. Nên gửi đồng thời các bản sao dự thảo thông số kỹ thuật cho AS (bản sao) tới tất cả các tổ chức (bộ phận) để phê duyệt.

4. Ý kiến góp ý về dự thảo thông số kỹ thuật của Nhà máy điện hạt nhân phải được trình bày kèm theo luận cứ kỹ thuật. Việc quyết định lấy ý kiến phải được chủ trì xây dựng dự thảo quy chuẩn kỹ thuật nhà máy điện hạt nhân và khách hàng sử dụng hệ thống đưa ra trước khi phê duyệt quy chuẩn kỹ thuật nhà máy điện hạt nhân.

5. Nếu khi thống nhất về dự thảo thông số kỹ thuật của nhà máy điện hạt nhân mà có sự bất đồng giữa chủ đầu tư và khách hàng (hoặc các tổ chức quan tâm khác) thì lập biên bản bất đồng ý kiến (hình thức tùy ý) và đưa ra quyết định cụ thể. được thực hiện theo cách thức quy định.

6. Việc phê duyệt dự thảo thông số kỹ thuật của Nhà máy điện hạt nhân có thể được chính thức hóa bằng một văn bản (thư) riêng. Trong trường hợp này, dưới tiêu đề “Đồng ý”, một liên kết được tạo tới tài liệu này.

7. Việc phê duyệt các thông số kỹ thuật của nhà máy điện do người đứng đầu doanh nghiệp (tổ chức) của nhà phát triển và khách hàng của hệ thống thực hiện.

8. Trước khi trình phê duyệt, thông số kỹ thuật của NPP (bổ sung cho thông số kỹ thuật) phải được kiểm tra bởi cơ quan quản lý kiểm soát của tổ chức đã phát triển thông số kỹ thuật và, nếu cần, phải được kiểm tra đo lường.

9. Bản sao các thông số kỹ thuật đã được phê duyệt của nhà máy được nhà phát triển gửi các thông số kỹ thuật của nhà máy tới những người tham gia tạo hệ thống trong vòng 10 ngày sau khi được phê duyệt.

10. Việc phối hợp và phê duyệt bổ sung các thông số kỹ thuật của nhà máy điện hạt nhân được thực hiện theo phương thức đã xác lập đối với các thông số kỹ thuật của nhà máy điện hạt nhân.

11. Các thay đổi về thông số kỹ thuật của nhà máy điện hạt nhân không được phép phê duyệt sau khi hệ thống hoặc đến lượt hệ thống được đệ trình để thử nghiệm nghiệm thu.

12. Việc đăng ký, hạch toán và lưu trữ các thông số kỹ thuật của NPP và việc bổ sung nó được thực hiện theo yêu cầu của GOST 2.501.

MẪU TRANG TIÊU ĐỀ CỦA TK TRÊN AC

________________________________________________________

Tên
tổ chức - nhà phát triển các thông số kỹ thuật cho NPP

TÔI TÁN THÀNH

Người giám sát
(chức vụ, tên doanh nghiệp - khách hàng của AS)

Chữ ký cá nhân
Họ và tên

Niêm phong

ngày

TÔI TÁN THÀNH

Người giám sát
(chức vụ, tên doanh nghiệp - “Nhà phát triển AS”)

Chữ ký cá nhân
Họ và tên

Niêm phong

ngày

________________________________________________________

tên loại loa

________________________________________________________

Tên của môn học
tự động hóa

________________________________________________________

viết tắt
tên của người nói

NHIỆM VỤ KỸ THUẬT

Trên ____ tờ

Có hiệu lực
Với

ĐÃ ĐỒNG Ý

Người giám sát
(chức vụ, tên tổ chức phê duyệt)

Chữ ký cá nhân
Họ và tên

Niêm phong

ngày

MẪU BẢNG CUỐI CÙNG CỦA TOR TRÊN AC

(mã TK)

HOÀN THÀNH NHƯ THỎA THUẬN

PHỤ LỤC 4
Thông tin

QUY ĐỊNH VỀ TẠO BỘ TIÊU CHUẨN THỐNG NHẤT HỆ THỐNG TỰ ĐỘNG

1. Điều kiện ban đầu để tạo tổ hợp

1.1. Việc tạo và triển khai các hệ thống tự động thuộc nhiều loại và mục đích khác nhau được thực hiện trong nhiều ngành theo tài liệu quy định và kỹ thuật thiết lập các tiêu chuẩn, quy tắc và quy định về tổ chức, phương pháp và kỹ thuật khác nhau làm phức tạp việc tích hợp các hệ thống và hoạt động chung hiệu quả của chúng.

1.2. Trong thời kỳ Tiêu chuẩn Nhà nước Liên Xô đưa ra quyết định cải tiến các bộ tiêu chuẩn liên ngành, các bộ và hệ thống tiêu chuẩn sau đây đã có hiệu lực, thiết lập các yêu cầu cho nhiều loại AS khác nhau:

1) hệ thống tiêu chuẩn thống nhất cho hệ thống điều khiển tự động (hệ thống thứ 24), bao gồm các hệ thống điều khiển tự động, hệ thống điều khiển tự động, hệ thống kiểm soát quá trình và các hệ thống tổ chức và kinh tế khác;
2) bộ tiêu chuẩn (hệ thống 23501); mở rộng sang các hệ thống thiết kế có sự trợ giúp của máy tính;
3) nhóm thứ tư của hệ thống tiêu chuẩn thứ 14, bao gồm các hệ thống tự động hóa để chuẩn bị công nghệ sản xuất.

1.3. Thực tiễn áp dụng tiêu chuẩn cho các hệ thống điều khiển tự động, CAD, hệ thống điều khiển quá trình tự động, hệ thống điều khiển quá trình tự động cho thấy chúng sử dụng chung một bộ máy khái niệm, có nhiều đối tượng tiêu chuẩn hóa chung nhưng yêu cầu của tiêu chuẩn chưa thống nhất với nhau. mặt khác, có sự khác biệt về thành phần, nội dung của tác phẩm, khác nhau về chức danh, thành phần, nội dung và cách thực hiện văn bản, v.v..

1.4. Trong bối cảnh thiếu chính sách kỹ thuật thống nhất trong lĩnh vực tạo AS, sự đa dạng của các tiêu chuẩn đã không đảm bảo khả năng tương thích rộng rãi của AS trong quá trình tương tác, không cho phép nhân rộng các hệ thống và cản trở sự phát triển của các lĩnh vực đầy hứa hẹn cho AS. sử dụng công nghệ máy tính.

1.5. Hiện tại, quá trình chuyển đổi đang được thực hiện để tạo ra các hệ thống tự động phức tạp (hệ thống CAD - CAM ở nước ngoài), bao gồm các hệ thống điều khiển tự động cho các quy trình công nghệ và sản xuất, CAD - nhà thiết kế, CAD - kỹ thuật viên, ASNI và các hệ thống khác. Việc sử dụng các quy tắc xung đột khi tạo ra các hệ thống như vậy sẽ dẫn đến giảm chất lượng, tăng chi phí công việc và trì hoãn việc vận hành các nhà máy điện hạt nhân.

1.6. Một bộ tiêu chuẩn và tài liệu hướng dẫn thống nhất sẽ áp dụng cho các hệ thống tự động hóa cho nhiều mục đích khác nhau: ASNI, CAD, OASU, ASUP, ASUTP, ASUGPS, ASK, ASPP, bao gồm cả sự tích hợp của chúng.

1.7. Khi phát triển các tài liệu liên ngành, cần tính đến các tính năng sau của AS với tư cách là đối tượng tiêu chuẩn hóa:

1) đặc tính kỹ thuật là tài liệu chính để thực hiện việc tạo ra AS và được khách hàng chấp nhận;
2) Các nhà máy điện hạt nhân, theo quy định, được tạo ra theo thiết kế, hoàn chỉnh với các sản phẩm sản xuất nối tiếp và sản xuất đơn lẻ và thực hiện các công việc xây dựng, lắp đặt, vận hành và chạy thử cần thiết để đưa nhà máy điện hạt nhân vào vận hành;
3) trong trường hợp chung, AS (hệ thống con AS) bao gồm phần mềm và phần cứng (SHC), tổ hợp phần mềm và phương pháp luận (PMK) và các thành phần hỗ trợ phần cứng, phần mềm và thông tin.
Các thành phần của các loại hỗ trợ này, cũng như PMC và PTK, phải được sản xuất và cung cấp dưới dạng sản phẩm cho mục đích công nghiệp và kỹ thuật.
Các thành phần có thể được đưa vào AS dưới dạng các bộ phận độc lập hoặc có thể được kết hợp thành các tổ hợp;
4) việc tạo AS trong các tổ chức (doanh nghiệp) đòi hỏi phải đào tạo đặc biệt cho người dùng và nhân viên bảo trì hệ thống;
5) chức năng của AS và các tổ hợp được đảm bảo bởi một bộ tài liệu về tổ chức và phương pháp luận, được xem xét trong quá trình tạo ra như các thành phần của các loại hỗ trợ pháp lý, phương pháp luận, ngôn ngữ, toán học, tổ chức và các loại hỗ trợ khác. Các giải pháp riêng lẻ thu được trong quá trình phát triển các phần mềm này có thể được triển khai dưới dạng các thành phần phần cứng, phần mềm hoặc hỗ trợ thông tin;
6) hoạt động chung và tương tác của các hệ thống và tổ hợp khác nhau được thực hiện trên cơ sở mạng máy tính cục bộ.

Các thông số kỹ thuật và thỏa thuận được áp dụng cho mạng máy tính cục bộ là bắt buộc để đảm bảo tính tương thích của các hệ thống, tổ hợp và thành phần.

2. Mối liên hệ của CEN AS với các hệ thống và bộ tiêu chuẩn khác

2.1. Tiêu chuẩn hóa trong lĩnh vực AS là một phần không thể thiếu trong công việc giải quyết vấn đề chung về “Công nghệ thông tin”.

2.2. Một bộ tiêu chuẩn thống nhất dành cho các tài liệu quản lý hệ thống tự động, cùng với các hệ thống và bộ tiêu chuẩn khác, sẽ tạo thành sự hỗ trợ kỹ thuật và quy định hoàn chỉnh cho các quá trình tạo và vận hành hệ thống tự động.

2.3. CEN AU nên bao gồm các lĩnh vực tiêu chuẩn hóa cụ thể cho các hệ thống tự động và mở rộng các lĩnh vực tiêu chuẩn hóa truyền thống sang phần mềm và phần cứng, các tổ hợp phương pháp và phần mềm cũng như các hệ thống tự động nói chung.

2.4. Phương hướng và nhiệm vụ tiêu chuẩn hóa trong hỗ trợ pháp lý và kỹ thuật trong quá trình hình thành và vận hành nhà máy điện hạt nhân được nhóm như sau:

1) thiết lập các yêu cầu kỹ thuật cho sản phẩm;
2) quy định về phương pháp thử nghiệm và quy tắc chứng nhận và chứng nhận sản phẩm;
3) quy định các quy tắc và thủ tục phát triển;
4) thiết lập các quy tắc về tài liệu;
5) đảm bảo tính tương thích;
6) quy định các vấn đề về tổ chức và phương pháp hoạt động của hệ thống.

Hướng 1-4 là truyền thống trong phát triển, sản xuất và cung cấp sản phẩm. Hướng 5, 6 mang tính cụ thể và phát sinh từ những đặc điểm vốn có của AS.

2.5. Việc cung cấp cho toàn bộ các nhà máy điện hạt nhân và các bộ phận của chúng các tài liệu quy định và kỹ thuật trong khuôn khổ các hướng dẫn và nhiệm vụ tiêu chuẩn hóa được chấp nhận là khác nhau.

Các thành phần của phần cứng, phần mềm và hỗ trợ thông tin, như các sản phẩm cho mục đích công nghiệp và kỹ thuật, được coi tương ứng là các sản phẩm thiết kế, phần mềm và thông tin. Các sản phẩm này phải tuân theo các bộ tiêu chuẩn hiện hành ESKD, SRPP, ESPD, SGIP, USD, bộ phân loại và bộ mã hóa thông tin kỹ thuật và kinh tế, các bộ tiêu chuẩn như “OTT”, “Phương pháp thử nghiệm”, “TU”, cũng như OTT của khách hàng.

2.5.1. Toàn bộ vòng đời của sản phẩm thiết kế được cung cấp đầy đủ các tài liệu quy định và kỹ thuật có giá trị trong lĩnh vực cơ khí và chế tạo dụng cụ.

2.5.2. Sản phẩm phần mềm được cung cấp các tài liệu khoa học kỹ thuật có trong ESPD và OTT của khách hàng. Tuy nhiên, phạm vi của các tài liệu kỹ thuật này cần được mở rộng để phản ánh các vấn đề liên quan đến việc phát triển, sáng tạo, phân phối và vận hành các sản phẩm phần mềm.

2.5.3. Các sản phẩm thông tin hiện chưa được cung cấp tài liệu khoa học kỹ thuật, mặc dù một số vấn đề nhất định đã được giải quyết trong khuôn khổ USD, bộ phân loại và mã hóa thông tin kỹ thuật và kinh tế.

2.6. Các tổ hợp phần mềm-phần cứng và phần mềm-phương pháp luận được coi là những sản phẩm phức tạp không có chất tương tự trong kỹ thuật cơ khí. Coi trạng thái của PTC và PMK là sản phẩm dành cho mục đích công nghiệp và kỹ thuật, các quy tắc và quy trình phát triển chúng phải tương tự với các yêu cầu được thiết lập bởi các tiêu chuẩn của hệ thống phát triển và sản xuất sản phẩm (SRPP).

Cơ sở giáo dục đại học cộng đồng khu vực

Viện "Chiến lược" khởi nghiệp

Khoa Điều khiển kinh tế

Khóa học

Chủ thể:

“Thiết kế và phát triển hệ thống thông tin sử dụng ví dụ về Computer Master store”

Nước Vàng 2010

Giới thiệu

Khóa học này xem xét một ví dụ về việc tạo ra một hệ thống thông tin dựa trên một doanh nghiệp tư nhân “ Bậc thầy máy tính" Mục đích của việc viết khóa học này là nghiên cứu các phương pháp và kỹ thuật phát triển hệ thống thông tin.

Đối với tình hình kinh tế nhất định trong nước, bất chấp khủng hoảng kinh tế, quá trình tin học hóa đang diễn ra khắp nơi, khóa học này rất quan trọng. Công việc triển khai hệ thống thông tin ngày càng trở nên cần thiết đối với nhiều doanh nghiệp khác nhau ở Ukraine, điều đó có nghĩa là nhu cầu về các chuyên gia có trình độ trong lĩnh vực tạo và triển khai hệ thống thông tin ngày càng tăng. Đồng thời, hệ thống thông tin không chỉ cần thiết đối với các doanh nghiệp công nghiệp lớn mà còn đối với các doanh nghiệp tư nhân nhỏ, những doanh nghiệp này cũng có thể gặp vấn đề trong việc quản lý và vận hành doanh nghiệp nói chung trong điều kiện tin học hóa các khu vực của Ukraine. Đây là những gì khóa học này thể hiện, cho thấy sự cần thiết phải triển khai hệ thống thông tin cho một doanh nghiệp tư nhân nhỏ “ Bậc thầy máy tính", và một phiên bản có thể có của việc triển khai này.

1. Giai đoạn tiền dự án

1.1 Đối thoại với khách hàng

Cuộc đối thoại với khách hàng diễn ra tại văn phòng công ty của anh ấy " Bậc thầy máy tính" Thời gian họp là ngày 7 tháng 11, thứ Sáu, 11 giờ.

Nhà phát triển (R): Xin chào! Tôi muốn gặp sếp của bạn !

Thư ký (C): Xin chào! Bạn có hẹn không!?

R: Vâng, chúng tôi đã gọi cho nhau về một cuộc họp!

VỚI:Đợi một chút, tôi sẽ thông báo rằng bạn đã đến! Vào đi, anh ấy đang đợi cậu!

Khách hàng (3): Chào buổi sáng, tên tôi là Viktor Ivanovich. Xin mời vào và ngồi xuống.

R: Xin chào, tên tôi là Ioschenko Ivan.

Z: Rất đẹp. Vấn đề của chúng tôi là tôi muốn tự động hóa việc hạch toán hàng hóa và số tiền nhận được từ việc bán hàng hóa và dịch vụ trong cửa hàng của chúng tôi. Hiện nay chúng tôi chưa có hệ thống kế toán. Tôi tin rằng vì điều này mà chúng tôi không làm việc hiệu quả như mong muốn.

R: Hiểu. Điều đó là có thể. Hiện nay có rất nhiều hệ thống tự động hóa, các hệ thống này được phổ biến rộng rãi và vận hành thành công ở nhiều doanh nghiệp. Tôi nghĩ chúng ta sẽ tìm ra cách tốt nhất để bạn sử dụng.

Z: Tuyệt vời. Bạn cần gì cho việc này?

R: Thông thường, quá trình nghiên cứu một doanh nghiệp và triển khai hệ thống thông tin mất từ 3 đến 6 tháng, tùy thuộc vào cơ cấu và đặc điểm của doanh nghiệp. Nhưng tôi nghĩ rằng trong trường hợp của bạn, hệ thống sẽ sẵn sàng hoạt động hoàn toàn vào khoảng giữa tháng 3. Bạn sẽ cần các chuyên gia để vận hành và bảo trì hệ thống. Bạn sẽ cần thuê một hoặc hai người để duy trì hệ thống.

Z: Nó có thể chấp nhận được. Tôi nghĩ chúng ta có thể giải quyết vấn đề này. Bạn còn quan tâm đến điều gì nữa?

R:Để bắt đầu, ít nhất tôi cần phải làm quen một cách khái quát với các hoạt động chính của doanh nghiệp bạn, cơ cấu, luồng tài liệu, luồng thông tin...

Z: Công ty chúng tôi chuyên bán, sửa chữa và bảo trì thiết bị máy tính. Chúng tôi có khá nhiều khách hàng, một số là khách hàng thường xuyên. Chúng tôi có lợi nhuận khá cao hàng tháng và về nguyên tắc, mọi việc đang diễn ra tốt đẹp.

R: Theo bạn, cửa hàng của bạn hoạt động hiệu quả như thế nào?

Z: Tôi nghĩ hôm nay chúng tôi đang làm việc khá hiệu quả. Nhưng giống như mọi nhà quản lý, tôi mong muốn nâng cao hiệu quả của đối tượng mình quản lý.

R: Khách hàng được phục vụ như thế nào tại cửa hàng của bạn?

Z: Khách hàng tìm đến nhà tư vấn bán hàng, hỏi anh ta những thông tin cần thiết liên quan đến một sản phẩm cụ thể, và anh ta sẽ cố gắng giới thiệu nó và đưa ra sản phẩm mong muốn. Sau đó, khoản thanh toán cho sản phẩm sẽ được thực hiện nếu đó là sản phẩm không yêu cầu cài đặt hoặc cấu hình và còn hàng. Nếu không có, hàng hóa sẽ được đặt hàng từ nhà cung cấp và cung cấp cho khách hàng sau một thời gian nhất định. Khi mua PC, nhân viên tư vấn bán hàng sẽ đưa ra cấu hình phù hợp với mong muốn của khách hàng, nếu linh kiện có tại cửa hàng thì máy tính sẽ được lắp ráp trong vòng 1-3 giờ, nếu không thì đặt hàng từ nhà cung cấp thì PC sẽ được lắp ráp. hoàn thành. Khách hàng thanh toán sau khi nhận hàng.

R: Thông thoáng. Có bao nhiêu người và thiết bị làm việc trong cửa hàng của bạn?

Z: Cửa hàng của chúng tôi tuyển dụng hai nhân viên tư vấn bán hàng, 1 nhân viên thu ngân, 3 chuyên gia lắp ráp PC mới theo đơn đặt hàng, cũng như sửa chữa thiết bị văn phòng, nạp lại hộp mực, v.v.; và tôi cũng là giám đốc. Chúng tôi hiện cũng sử dụng 3 PC.

R: Làm thế nào để các chuyên gia tư vấn bán hàng của bạn nhận được thông tin về tình trạng sẵn có của hàng hóa trong kho và đặc điểm của chúng?

Z: Mỗi chuyên gia tư vấn bán hàng của chúng tôi đều có những thông tin nhất định về sản phẩm, quyền truy cập vào kho của chúng tôi hoặc từ nhà cung cấp. Họ cũng sử dụng thông tin từ tạp chí, danh mục có trên máy tính làm việc và bản in của họ.

R: Như tôi đã hiểu, bạn đang kinh doanh máy tính, linh kiện, thiết bị văn phòng và bạn có gặp vấn đề gì trong việc tổ chức kế toán và lưu chuyển chứng từ trong cửa hàng không?

Z: Vâng, đúng vậy.

R: Làm thế nào để bạn chọn loại của bạn?

Z: Chúng tôi luôn cố gắng cung cấp cho cửa hàng của mình nhiều loại PC và linh kiện của chúng, cũng như các sản phẩm mới nhất trên thị trường công nghệ thông tin. Chúng tôi cũng sử dụng rộng rãi dịch vụ “đặt hàng tùy chỉnh”, tức là. khách hàng có thể đặt hàng từ chúng tôi những gì anh ấy quan tâm. Chúng tôi làm việc chặt chẽ với các nhà cung cấp của chúng tôi.

R: Một vài lời về nhà cung cấp?

Z: Chúng tôi không có nhiều nhà cung cấp, họ có thể được chia thành nhiều nhóm:

Nhỏ và lớn,

Liên tục và định kỳ.

Tổng cộng thường không quá 5-6.

R: Bạn có thường xuyên mua sản phẩm mới trong cửa hàng của mình không?

Z: Chúng tôi thường mua hàng mới 2 tuần một lần. Trước đó, chúng tôi liên hệ với nhà cung cấp và đặt mua một số lượng hàng hóa nhất định từ anh ta. Tôi tự theo dõi nguồn cung cấp trên máy tính của mình bằng Excel nhưng tôi không hài lòng với những hạn chế về chức năng của nó đối với hoạt động này. Tôi cần một hệ thống được định dạng tốt và đáng tin cậy, cung cấp quyền truy cập nhanh vào thông tin tôi cần, các công cụ thuận tiện để tạo báo cáo, v.v. Bạn hiểu ý tôi muốn nói gì không?!

R: Vâng, chắc chắn rồi. Đó là tất cả những gì tôi quan tâm. Tôi sẽ làm quen với các bản sao của tài liệu mà bạn đã cung cấp cho tôi một cách chi tiết hơn và chúng ta sẽ bắt tay vào làm việc.

Z: Khỏe.

R: Cảm ơn bạn, 2 ngày nữa tôi sẽ gọi cho bạn, chúng ta sẽ gặp nhau và xem xét chi tiết thiết kế hệ thống của chúng tôi.

Z:Đã đồng ý. Tạm biệt.

R: Thấy bạn.

Kết quả của cuộc họp có thể rút ra những kết luận sau:

1. Khi phục vụ khách hàng, nhân viên tư vấn bán hàng đôi khi không thể cung cấp nhanh chóng mọi thông tin về bất kỳ sản phẩm nào (đặc tính kỹ thuật) và khách hàng phải đợi một thời gian mới nhận được những thông tin cần thiết.

2. do bảng giá hàng hóa hiếm khi được cập nhật nên việc cung cấp một số sản phẩm nhất định bị gián đoạn, bởi vì vào thời điểm chúng tôi đặt hàng, đơn giản là sản phẩm đó có thể không còn hàng tại nhà cung cấp.

3. Người quản lý cửa hàng, do có rất nhiều loại sản phẩm trong cửa hàng nên phải dành nhiều thời gian để xác định số lượng mua cần thiết của một sản phẩm cụ thể.

4. Cửa hàng không có hệ thống tự động ghi lại doanh số bán sản phẩm.

5. Người quản lý phải dành nhiều thời gian để phân tích doanh số bán hàng và lập báo cáo.

1.2 Mô tả đối tượng

Công ty " Bậc thầy máy tính» hoạt động trong lĩnh vực công nghệ thông tin và đặc biệt là kinh doanh máy tính và thiết bị ngoại vi. Hoạt động thương mại được thực hiện trong lĩnh vực thương mại bán lẻ. Để tham gia vào hoạt động thương mại, thực thể kinh tế trong lĩnh vực bán lẻ phải có cửa hàng, nhà kho, các khu chức năng, trong đó bao gồm khu bán lẻ và khu kho bãi khép kín để bảo quản, bán hàng hóa. Ngoài ra còn có một phòng lắp ráp và bảo trì máy tính và các bộ phận của chúng.

Cửa hàng là cơ sở bán lẻ cố định, có phòng riêng và có khu vực bán hàng cho khách hàng. Các chức năng của nhà kho bao gồm tạo ra các chủng loại cần thiết để đáp ứng các đơn đặt hàng của khách hàng. Tích lũy và bảo quản cho phép gia hạn và phân phối liên tục dựa trên khoảng không quảng cáo đã tạo. Kho được sử dụng như một mắt xích trung gian trong chuỗi nhà sản xuất - người mua.

1.3 Luồng hồ sơ tại doanh nghiệp

Doanh nghiệp có các loại giấy tờ sau:

1. hóa đơn

2. hóa đơn tiêu hao

3. hóa đơn thuế

4. hợp đồng

5. tất cả các loại báo cáo

6. Thẻ bảo hành, v.v.

1.4 Yêu cầu của khách hàng đối với hệ thống

Các yêu cầu cơ bản sau đây đã được đưa ra:

1. Hệ thống dễ sử dụng

2. Hiệu suất IS

3. Hệ thống sẽ giải quyết các vấn đề chính sau:

· kế toán hàng tồn kho;

· Kế toán số tiền thu được từ việc bán hàng hóa;

· giảm thời gian tạo báo cáo;

· tính trật tự của luồng tài liệu;

· Tiết kiệm thời gian phục vụ khách hàng.

2. Khái niệm hệ thống thông tin

Sau cuộc gặp đầu tiên với khách hàng, đối tượng tự động hóa đã được nghiên cứu chi tiết và tất cả các vấn đề hiện tại cần được giải quyết với sự trợ giúp của hệ thống thông tin tự động hóa kế toán hàng hóa và dòng tiền trong cửa hàng " Bậc thầy máy tính».

2.1 Mô tả công việc đã thực hiện

Qua kiểm tra, hóa ra cần phải cài đặt hệ thống trên hai máy tính hiện có. Trên một trong các máy tính (máy tính chính), sử dụng IS, hồ sơ sẽ được lưu giữ về quá trình di chuyển của hàng hóa và số tiền nhận được từ việc bán chúng. Chuyên gia sẽ được phân công làm việc tại cửa hàng sẽ nhập dữ liệu về việc hàng hóa đến kho, mức tiêu thụ và di chuyển từ kho đến sàn bán hàng của cửa hàng. Vào cuối mỗi tuần, anh ta sẽ phải lập báo cáo về số dư hàng hóa trong kho và kiểm tra tính thống nhất của dữ liệu trên máy tính với tình trạng hàng hóa còn sẵn trong kho và trên sàn bán hàng. Anh ta sẽ chịu trách nhiệm hoàn toàn về việc trao đổi dữ liệu trong máy tính với các dữ liệu khác trong kho. Máy tính thứ 2 sẽ được lắp đặt tại tầng bán hàng, nhân viên tư vấn bán hàng có thể tự mình ghi sổ hàng hóa khỏi cơ sở dữ liệu nếu sản phẩm này được đặt ở tầng bán hàng. Và nếu sản phẩm không thuộc quyền sử dụng của họ, thì họ sẽ chỉ chấp nhận đơn đặt hàng từ người mua và chuyên gia sẽ loại sản phẩm khỏi tình trạng sẵn có trong cơ sở dữ liệu (vì nó phản ánh đầy đủ mọi chuyển động của hàng hóa đến sàn bán hàng).

Theo cơ cấu tổ chức, các hoạt động của doanh nghiệp thường được chia thành hoạt động chính và hoạt động phụ trợ. Nhưng vì người sử dụng hệ thống thông tin sẽ là nhân viên thực hiện các hoạt động chính nên chúng ta sẽ tìm hiểu chi tiết hơn về các chức năng do những người này thực hiện.

Một kế toán viên lưu giữ hồ sơ cho một công ty và lập báo cáo tài chính.

Nhân viên thu ngân có trách nhiệm phát hành tiền lương và nhận tiền cho các sản phẩm được vận chuyển và giao hàng.

Trách nhiệm của thủ kho bao gồm giám sát tình trạng sẵn có và tình trạng hàng hóa trong kho.

Như vậy có thể đưa ra sơ đồ hệ thống tự động hóa việc hạch toán hàng hóa và dòng tiền trong cửa hàng" Bậc thầy máy tính».

2.2 Sự biện minh cho phiên bản đề xuất của khái niệm IS

Liên quan đến kết quả nghiên cứu đối tượng tự động hóa, nhà phát triển đề xuất triển khai hệ thống 1C tại doanh nghiệp.

Một doanh nghiệp cho phép bạn lưu giữ hồ sơ về hàng hóa và dòng tiền và thực hiện quyền kiểm soát chúng.

Để biện minh cho việc lựa chọn hệ thống 1C, doanh nghiệp được đưa ra các lập luận sau:

1. Hệ thống dễ sử dụng

2. có giao diện người dùng thân thiện

3. hệ thống có tính đến đặc thù của pháp luật Ukraine và đặc thù của kế toán tại các doanh nghiệp trong nước.

4. Hệ thống này tương đối rẻ trong số nhiều hệ thống được cung cấp trên thị trường phần mềm Ukraine.

5. Không khó để tìm được một chuyên gia có trình độ chuyên môn làm việc với hệ thống 1C: Enterprise.

2.3 Thành phần sơ bộ, thời hạn và chi phí thực hiện IS

Thời gian sơ bộ của công việc, thành phần của nó, cũng như chi phí gần đúng của nó có thể được trình bày dưới dạng bảng.

Tên tác phẩm	Thời gian quay vòng	Chi phí ước tính của công việc. UAH
Cài đặt mạng máy tính
Mua phần mềm 1C
Thuê chuyên gia triển khai và cấu hình hệ thống
Thiết lập cấu hình, tạo cơ sở thông tin (do chuyên gia thực hiện)
Đào tạo nhân sự (do chuyên gia của trung tâm đào tạo thực hiện)
Thuê chuyên gia hỗ trợ và bảo trì hệ thống
Chuẩn bị đưa hệ thống vào vận hành

Nếu bạn tính toán, khoảng thời gian từ khi bắt đầu công việc đến khi triển khai hệ thống là 3,5-4 tháng. Chi phí ước tính để tạo và triển khai IS để tự động hóa việc hạch toán hàng hóa và dòng tiền là từ 7480 đến 10200 UAH. Số tiền có thể chấp nhận được là bao nhiêu, có tính đến số tiền hiện có của khách hàng?

3. Điều khoản tham chiếu tạo IP

Các điều khoản tham chiếu được soạn thảo theo GOST 34.602–89 “thông số kỹ thuật để tự động hóa hệ thống điều khiển”.

Tự động hóa hệ thống. Các giai đoạn sáng tạo. Nhà phát triển chính chịu trách nhiệm phát triển các thông số kỹ thuật.

3.1 Thông tin chung

Tên đầy đủ của AIS: Hệ thống thông tin tự động hóa việc hạch toán hàng hóa và dòng tiền tại doanh nghiệp Computer Master.

Biểu tượng: AIS – “Bậc thầy máy tính”.

Việc phát triển được thực hiện trên cơ sở thỏa thuận số 1 ngày 09 tháng 11 năm 2009 giữa khách hàng (Viktor Ivanovich, giám đốc Computer Master) và nhà phát triển (Ioshchenko I.G.)

Tên đầy đủ của doanh nghiệp là PE “Computer Master”.

Địa chỉ: Vùng Kirovograd, Alexandria, Đại lộ Lenin 45.

Tài khoản hiện tại: Số 53425

Nhà phát triển: Ioshchenko I.G.

Địa chỉ: Vùng Kirovograd, Alexandria, st. Sadovaya 16.

Việc tạo lập hệ thống thông tin được thực hiện trên cơ sở thỏa thuận số 1 ngày 10 tháng 1 năm 2010 giữa chủ đầu tư và khách hàng.

Ngày bắt đầu công việc theo kế hoạch là ngày 9.11.09 và ngày kết thúc công việc là ngày 10.03.10.

Khách hàng sẽ cung cấp kinh phí cho việc tạo ra AIS.

Kết quả của công việc tạo IP hoặc các bộ phận của IP được nhà phát triển ghi lại bằng văn bản và cung cấp trong khung thời gian định trước.

3.2 Mục đích và mục tiêu tạo AIS

Hệ thống điều khiển tự động được thiết kế để tự động hóa việc quản lý các hoạt động của công ty, cụ thể là:

Kế toán hàng tồn kho

Kế toán tài sản cố định và tài sản vô hình

Tạo báo cáo

Kế toán luân chuyển hàng hóa trong kho

Mục đích của việc tạo ra IP là nhằm tăng cường hoạt động kinh tế của đối tượng. IS cũng cần tạo điều kiện thuận lợi và tăng tốc độ thu thập, xử lý và lưu trữ thông tin.

3.3 Đặc điểm của đối tượng tự động hóa

Hoạt động thương mại được thực hiện trong lĩnh vực bán lẻ; đơn vị kinh doanh có cửa hàng, kho bãi và văn phòng làm việc.

Cửa hàng là một cơ sở bán lẻ có một phòng riêng và có khu vực bán hàng cho khách hàng. Kho được sử dụng như một mắt xích trung gian trong chuỗi nhà sản xuất - người mua. Tồn kho càng ít thì thời gian lưu kho càng ngắn và chi phí lưu kho càng thấp.

Các hoạt động chính của cửa hàng được thực hiện trong điều kiện làm việc bình thường.

3.4 Yêu cầu về IS

Yêu cầu:

Hệ thống phải đơn giản và dễ hiểu đối với người dùng.

Việc áp dụng IP sẽ mang lại hiệu quả kinh tế tích cực.

Ghi chép hàng hóa trong cửa hàng

Lập kế hoạch chi phí liên quan đến việc mua và lưu trữ hàng hóa

Lập kế hoạch thu nhập liên quan đến việc bán hàng

Yêu cầu đối với các loại tài sản thế chấp sở hữu trí tuệ:

Hỗ trợ kỹ thuật phải là một tập hợp các phương tiện kỹ thuật được kết nối với mạng cục bộ.

Phần mềm phải bao gồm:

1. “Doanh nghiệp” 1C và các thành phần vận hành IS

2. Chương trình chống vi-rút

3. Các chương trình Office (MS Office hoặc Open Office)

Phần mềm phải bao gồm tất cả các phương pháp và thuật toán được phát triển và sử dụng trước đây tại doanh nghiệp để tính toán các chỉ số kinh tế chính.

Hỗ trợ thông tin nên bao gồm dữ liệu về hàng hóa, nhà cung cấp, giá cả.

Phần mềm là tập hợp các quy phạm pháp luật điều chỉnh các quan hệ pháp luật trong quá trình tạo lập và triển khai hệ thống. Hỗ trợ pháp lý ở giai đoạn phát triển nên bao gồm các quy định, quy định pháp lý về các mối quan hệ trong quá trình này.

Hệ thống thông tin này sẽ được triển khai trong vòng 3,5-4 tháng.

Để làm việc với IS cần phải đào tạo nhân sự.

3.5 Thành phần và nội dung công việc tạo ra hệ thống

Giai đoạn tiền dự án bao gồm:

Xác định yêu cầu của khách hàng;

Phát triển dự án AIS theo yêu cầu của khách hàng;

Phát triển các thông số kỹ thuật theo GOST 34.602–89.27.01.08–21.02.08;

Giai đoạn dự án:

triển khai IS;

Bảo trì hệ thống.

Người thực hiện công việc đó là:

nhà phát triển IP;

Chuyên gia tạo mạng LAN;

Chuyên cài đặt, cấu hình, bảo trì hệ thống.

Nhà phát triển IS chịu trách nhiệm thực hiện mọi công việc ở tất cả các giai đoạn.

3.6 Quy trình giám sát và tiếp nhận hệ thống

Để khách hàng chấp nhận hệ thống, cần phải tiến hành vận hành thử nghiệm, trong đó một bản ghi được lưu giữ để ghi lại tất cả các giải pháp cho vấn đề và mọi vi phạm. Dựa trên kết quả hoạt động, một giao thức được soạn thảo, trong đó bao gồm những thiếu sót và khung thời gian để loại bỏ được xác định.

Trong quá trình tiếp nhận, ủy ban phải nộp các tài liệu sau:

Thông số kỹ thuật của hệ thống

Các dự án kỹ thuật và làm việc cho hệ thống

Báo cáo thử nghiệm và nhật ký

Nhân sự các bộ phận khách hàng phục vụ hệ thống.

Hành vi chuyển giao toàn bộ các phần của hệ thống thông tin cho khách hàng

Dự thảo chương trình và phương pháp thử nghiệm

Hội đồng tuyển sinh có thể bao gồm các nhân viên quản lý cấp cao, do giám đốc đại diện.

3.7 Yêu cầu về thành phần và nội dung công việc chuẩn bị đưa đối tượng tự động hóa vào vận hành

Để chuẩn bị cơ sở cho việc vận hành, bạn nên làm như sau:

Chuẩn bị đối tượng để chuyển đổi sang hoạt động trong IS mới

Thử nghiệm tất cả các vật liệu của dự án kỹ thuật và chi tiết và thực hiện các thay đổi dựa trên kết quả

Để triển khai IS vào hoạt động cần thiết:

Lập báo cáo tình hình thực hiện kế hoạch hành động để chuẩn bị cơ sở thực hiện.

Sự sẵn có của tài liệu cho việc triển khai IS.

Sự sẵn có của nhân sự, đảm bảo việc chuẩn bị thực hiện và vận hành.

Sự sẵn có của các phương tiện kỹ thuật IS được chấp nhận.

3.8 Yêu cầu về tài liệu

Tài liệu được soạn thảo theo tiêu chuẩn ESKD, ESPD và GOST.

Trong quá trình phát triển IP, có thể sử dụng những điều sau:

GOST 19.001. – 77. TRỰC TIẾP. "Các quy định chung";

GOST 19.006. – 82. TRỰC TIẾP. “Yêu cầu chung đối với tài liệu chương trình in”;

ĐIỂM 19.201. – 82. TRỰC TIẾP. "thông số kỹ thuật để phát triển chương trình."

Ngoài ra, các loại hợp đồng lao động, văn bản về việc thực hiện các giai đoạn tạo lập sở hữu trí tuệ, lịch trình làm việc theo từng giai đoạn và các tài liệu được soạn thảo sau khi hoàn thành từng giai đoạn đều được nhà phát triển và khách hàng thống nhất.

Điều khoản tham chiếu để tạo ra hệ thống

Thông số kỹ thuật cho hệ thống điều khiển tự động

Thông tin thu được từ nhân viên quản lý và vận hành cũng như dựa trên yêu cầu của khách hàng cũng được sử dụng.

4. Dự thảo công tác kỹ thuật

4.1 Tài liệu hệ thống chung

4.1.1 Chú thích giải thích

Dự án làm việc kỹ thuật về AIS " Bậc thầy máy tính» là một trong những tài liệu chính hướng dẫn việc tạo lập và triển khai sở hữu trí tuệ. Tài liệu này cung cấp tài liệu về cách vận hành hệ thống cũng như tính toán hiệu quả kinh tế thu được từ việc triển khai IS. Tài liệu của dự án công tác kỹ thuật bao gồm tài liệu về thông tin, hỗ trợ kỹ thuật, tổ chức và toán học.

Tài liệu này đã được sự đồng ý của khách hàng và nhà phát triển chính. Thiết kế công trình kỹ thuật chỉ được thay đổi trong những trường hợp được quy định tại thỏa thuận số 1 ngày 9 tháng 11 năm 2009, việc tạo ra IP được thực hiện trên cơ sở thỏa thuận nêu trên được ký kết giữa khách hàng và IP nhà phát triển.

Mô tả chung về IP " Bậc thầy máy tính»

AIS đang được phát triển " Bậc thầy máy tính» được thiết kế nhằm tự động hóa việc hạch toán hàng hóa và dòng tiền tại cửa hàng, nhằm tăng hiệu quả kinh tế của doanh nghiệp. Tên đầy đủ của hệ thống “Hệ thống thông tin kế toán hàng hóa và dòng tiền tại doanh nghiệp” Bậc thầy máy tính».

Hệ thống đáp ứng các mục tiêu chính của việc tạo ra nó, cụ thể là:

1. Đảm bảo độ tin cậy của số liệu kế toán hàng hóa trong kho và dòng tiền.

2. Đảm bảo hiệu quả của việc thu thập thông tin sơ cấp, tổng hợp, phân tích và báo cáo về hàng hóa và tiền thu được từ việc bán hàng.

3. Giảm cường độ lao động trong việc thu thập, ghi chép, tổng hợp, phân tích thông tin về hàng hóa và dòng tiền trong doanh nghiệp.

4. Hình thành thông tin và hỗ trợ phân tích hiệu quả cho các cơ chế tối ưu hóa việc hạch toán hàng hóa và dòng tiền.

5. Giảm chi phí lưu kho hàng hóa.

4.1.2 Kế hoạch hành động chuẩn bị cơ sở vật chất đưa IS vào vận hành

Để đưa IS vào hoạt động bạn phải:

1. Chuẩn bị đối tượng tự động hóa để thực hiện.

2. Đào tạo nhân sự (đào tạo nhân viên và kiểm tra khả năng đảm bảo hoạt động của hệ thống).

3. Hoàn thiện IS với các sản phẩm được cung cấp.

4. Trang bị lại mặt bằng, bố trí nơi làm việc theo đúng tiêu chuẩn, định mức.

5. Thuê chuyên gia bảo trì, hỗ trợ IS (do khách hàng thực hiện theo khuyến nghị của nhà phát triển).

4.1.3 Tính toán hiệu quả kinh tế

Hiệu quả kinh tế của AIS được triển khai có thể được đánh giá thông qua các hiệu ứng được tính toán. Bao gồm các:

· Tăng cường kiểm soát hiệu quả công việc.

· Khả năng ghi lại các hoạt động đã thực hiện.

· Tăng mức độ tin cậy của thông tin.

· Hạn chế quyền truy cập thông tin theo yêu cầu của hệ thống được bảo vệ.

· Thu thập thông tin chi tiết hơn và tự động hóa việc thu thập thông tin.

· Các phương pháp tích hợp và hệ thống hóa mới để giải quyết các vấn đề kế toán và ra quyết định quản lý.

Nhờ tự động hóa cơ sở, số lượng nhân viên bán hàng có thể giảm xuống còn hai. Khi đó mức lương của hai người bán sẽ là 2∙12∙800=19200 UAH. trong năm. Nhưng chi phí duy trì một chuyên gia bảo trì hệ thống sẽ tốn 1∙12∙1000=12000 UAH. trong năm.

Do đó, hiệu quả kinh tế hàng năm từ việc áp dụng IP sẽ bằng: 19200 – 12000 = 7200 UAH. trong năm.

4.2 Tài liệu của phần chức năng

4.2.1 Mô tả chức năng tự động

Sơ đồ cấu trúc chức năng của IS.

· Đảm bảo hiệu quả của việc thu thập thông tin sơ cấp, tổng quát, phân tích và báo cáo về hàng tồn kho và dòng tiền được thực hiện bằng cách sử dụng các báo cáo và xử lý do IS biên soạn theo yêu cầu của người dùng.

· Việc thu thập, hạch toán, tổng hợp và phân tích thông tin về hàng tồn kho và dòng tiền được thực hiện nhờ các báo cáo và xử lý do IS biên soạn theo yêu cầu của người dùng.

· Hình thành thông tin và hỗ trợ phân tích hiệu quả cho cơ chế tối ưu hóa công tác kế toán hàng tồn kho và dòng tiền, giảm thiểu chi phí lưu kho.

4.2.2 Mô tả báo cáo vấn đề

Cơ sở để xây dựng AIS" Bậc thầy máy tính"là việc triển khai hệ thống 1C: Enterprise 7.7, với sự hỗ trợ của hệ thống này, giải pháp cho vấn đề tự động hóa kế toán hàng hóa và dòng tiền trong kho, kho được thực hiện. Cơ sở IS được xây dựng đáp ứng các mục tiêu được mô tả tại khoản 2 của thông số kỹ thuật của hệ thống và đáp ứng yêu cầu của khách hàng.

4.3 Tài liệu tổ chức hỗ trợ IS

Sơ đồ cơ cấu tổ chức của cơ sở được nêu trong phần phụ lục của báo cáo giai đoạn triển khai IS trước dự án.

Mô tả cơ cấu tổ chức của IS

Việc hạch toán hàng hóa được thực hiện bằng 2 máy tính được kết nối thành một hệ thống. Sử dụng máy tính của kho, hồ sơ về việc nhận và tiêu thụ hàng hóa được lưu giữ và dữ liệu đã xử lý sẽ được truyền đến những người tham gia mạng còn lại. Hồ sơ hàng hóa trong cửa hàng cũng sẽ được lưu giữ. Vào cuối mỗi tuần, chỉ cần hiển thị số dư và kiểm tra tình trạng còn hàng hóa trong cửa hàng, kho hàng với dữ liệu do máy tính cung cấp. Người bán phải nhập dữ liệu về biên lai hàng hóa có trong cửa hàng, nhập chi phí và rút số dư, đồng thời sử dụng hệ thống này khi phục vụ khách hàng.

4.4 Thông tin tài liệu hỗ trợ

Hỗ trợ thông tin (IS) của AIS bao gồm thông tin quy chuẩn và tham chiếu được trình bày dưới dạng hằng số trong hệ thống 1C: Enterprise và có thể được thay đổi bởi chuyên gia hỗ trợ AIS. Hỗ trợ thông tin còn bao gồm cơ sở dữ liệu ở định dạng DBF (cấu trúc của một số cơ sở dữ liệu được trình bày tại Phụ lục 4), trước đây doanh nghiệp chưa sử dụng để ghi hàng hóa và được biên soạn trong quá trình nhập thông tin ban đầu.

Hỗ trợ thông tin của AIS " Bậc thầy máy tính» Bao gồm các dữ liệu về hàng hóa (số serial, tên sản phẩm, tên nhà cung cấp, số lượng hàng hóa, ngày hàng về kho, giá mua, ngày xuất kho,...). Thông tin này được nhập vào cơ sở dữ liệu máy trạm (định dạng DBF) và được truy xuất từ đó nếu cần. Cơ sở dữ liệu chứa thông tin về hàng hóa, dòng tiền các năm trước cần được lưu trữ và lưu trữ (trong kho lưu trữ) trên ổ cứng của máy trạm. Cơ sở dữ liệu cũng lưu trữ dữ liệu về nhà cung cấp và khách hàng.

Hàng tháng, cấu hình hệ thống được lưu và lưu trữ trong kho lưu trữ trên máy tính chủ. Khi cần, mỗi người dùng có thể sử dụng thông tin mình cần bằng cách tải thông tin đó xuống từ máy tính chính.

4.5 Tài liệu phần cứng

Độ tin cậy của một bộ phương tiện kỹ thuật được đánh giá bằng việc sử dụng các thiết bị hiện có và mới, cũng như chế độ vận hành của IS. Vì tất cả các PC và thiết bị văn phòng có trong IS đều đã được mua nên tình trạng của chúng được đánh giá ở mức 90% tuân thủ độ tin cậy của hệ thống.

Hỗ trợ kỹ thuật của IP bao gồm: có sẵn hai máy tính có cùng cấu hình. Máy tính được kết nối với mạng cục bộ bằng cáp xoắn đôi và cấu trúc liên kết mạng vòng logic, cho phép truyền thông tin ở tốc độ 10–100 Mbit/giây.

Phần cứng cũng bao gồm một thiết bị in – máy in.

4.6 Tài liệu phần mềm

Phần mềm bao gồm tất cả các phương pháp và thuật toán được phát triển trước đây tại doanh nghiệp để tính toán các chỉ tiêu kinh tế chính liên quan đến quản lý, kế toán, kiểm soát hàng hóa và dòng tiền trong doanh nghiệp. Nó cũng cung cấp các thuật toán cho toàn bộ hoạt động của hệ thống và các nhiệm vụ riêng lẻ của nó.

4.7 Tài liệu phần mềm

Phần mềm AIS" Bậc thầy máy tính" bao gồm:

– Hệ điều hành MS Windows cài đặt trực tiếp trên máy trạm,

– 1C: Chương trình Enterprise 7.7, bao gồm tất cả các thành phần của nó để vận hành trực tiếp IS,

– phần mềm diệt virus,

– người lưu trữ

- Quản lý tập tin

– phần mềm Microsoft Office 2003 khác.

Phần mềm chính cho hoạt động AIS " Bậc thầy máy tính"là chương trình 1C: Enterprise 7.7 được cài đặt trên tất cả các PC là một phần của phần cứng IS. Tài liệu dành cho chương trình này đã được chấp nhận như một phần tài liệu dành cho toàn bộ IS.

Tất cả các chương trình trên được cài đặt trên tất cả các máy tính là một phần của mạng.

Hệ thống có cấu trúc thành phần. Chỉ có ba thành phần chính: “Kế toán”, “Kế toán hoạt động”, “Tính toán”. Mỗi thành phần mở rộng khả năng của hệ thống bằng cơ chế xử lý thông tin của nó.

Phần kết luận

Thiết kế này nhằm mục đích đảm bảo hoạt động hiệu quả của AIS và tương tác với các chuyên gia sử dụng máy tính trong lĩnh vực hoạt động của một thực thể kinh tế cụ thể và phát triển phương tiện liên lạc để thực hiện các nhiệm vụ chuyên môn và đưa ra quyết định quản lý. Đó là thiết kế chất lượng cao đảm bảo tạo ra một hệ thống có khả năng hoạt động với sự cải tiến liên tục về các thành phần kỹ thuật, phần mềm, thông tin, tức là cơ sở công nghệ của nó và mở rộng phạm vi các chức năng quản lý được triển khai và các đối tượng tương tác. Việc giới thiệu AIS tại doanh nghiệp tạo điều kiện thuận lợi đáng kể cho công việc xử lý tài liệu, giúp giải quyết nhiều vấn đề một cách nhanh chóng và hiệu quả. Việc vận hành thành công hệ thống được phát triển và triển khai mang lại hiệu quả kinh tế rõ rệt bằng cách giảm chi phí, giải phóng thời gian làm việc của các chuyên gia, nâng cao chất lượng và độ tin cậy của công tác kế toán chuyển động của hàng hóa và tạo điều kiện thuận lợi cho việc chuẩn bị các tài liệu và báo cáo đi kèm.

Danh sách tài liệu được sử dụng

1. Hệ thống thông tin và công nghệ trong kinh tế. Ed. V.S. Ponomarenka, Kiev, “Học viện”, 2002.

2. Filimonenko N.I. Bài giảng “Mô hình và phương pháp quản lý dự án”

3. Công nghệ thông tin tự động hóa trong kinh tế. Dưới. Ed. G.A. Titarenko, Moscow, “Máy tính”, 1998.

4. Hệ thống tài liệu chương trình thống nhất. Ủy ban Tiêu chuẩn Nhà nước Liên Xô, M., 1982.

5. R. Fatrepp, D. Schafer, L. Schafer Quản lý dự án phần mềm. Thành tích. Đạt được chất lượng tối ưu với chi phí tối thiểu, Williams, Moscow - St. Petersburg - Kyiv, 2003.

6. Thiết kế hệ thống thông tin. Phía sau. Ed. V.S. Ponomarenko, Kiev, “Học viện”, 2002.

Trang chủ > Thông số kỹ thuật

BỘ VĂN HOÁ RF

Đại học Văn hóa và Nghệ thuật bang St. Petersburg

Khoa Tin học và Công nghệ thông tin

THIẾT KẾ HỆ THỐNG THÔNG TIN

NHIỆM VỤ KỸ THUẬT

cho sự phát triển

hệ thống thông tin giáo dục

< Tên đầy đủ của hệ thống và ký hiệu của nó >

trên 4 tờ

_.__.200_ đã ban hành

Saint Petersburg

Thông tin chung

Lý do phát triển

Một hệ thống thông tin giáo dục đang được phát triển như một phần của việc nghiên cứu và phát triển khóa học “Thiết kế và sử dụng hệ thống thông tin”.

Ngày dự kiến bắt đầu và hoàn thành công việc cũng như quy trình xử lý và trình bày kết quả công việc cho Khách hàng được xác định trong đoạn 4 và 5 của ĐKTC này.

Mục đích và mục tiêu xây dựng hệ thống thông tin giáo dục

Mục đích

Hệ thống thông tin giáo dục nhằm mục đích:

để chứng minh mức độ mà sinh viên đã nắm vững nội dung của khóa học “Thiết kế và sử dụng hệ thống thông tin”, để sử dụng làm mô hình trong công việc tiếp theo về việc tạo hoặc cải thiện một hệ thống thông tin thực sự.

Mục tiêu xây dựng dự án hệ thống thông tin giáo dục

Một hệ thống thông tin giáo dục được tạo ra để:

giúp học sinh đạt được sự hiểu biết về các khái niệm cơ bản của quy trình thiết kế hệ thống, nắm vững các mối liên hệ giữa các khái niệm cơ bản và phương pháp thiết kế, khả năng phát triển thiết kế hệ thống và tài liệu của nó, cũng như tạo IP thực, thể hiện kết quả công việc và mức độ nắm vững nội dung khóa học, tạo cơ sở cho công việc tiếp theo để cải thiện dự án và triển khai thực tế dự án.

Yêu cầu đối với tài liệu báo cáo của hệ thống thông tin giáo dục

Yêu cầu chung về vật liệu

Thành phần của tài liệu báo cáo. Tài liệu báo cáo phải bao gồm hai phần chính: tài liệu dự án và bố cục hệ thống thông tin (cơ sở dữ liệu hoàn chỉnh cùng với các truy vấn, biểu mẫu, báo cáo, trang truy cập), được triển khai bằng ACCESS DBMS (hoặc hệ thống khác). Việc bố trí phải được thực hiện phù hợp với dự án. Các vật liệu thiết kế phải mô tả được bố cục và khả năng của nó.

Nội dung tài liệu dự án

Tài liệu thiết kế phải có các phần sau.

Trang tiêu đề có tên IP được thiết kế, chỉ dẫn của nhà phát triển và khách hàng. Phần "Nghiên cứu khả thi", chứa mô tả ngắn gọn về lĩnh vực chủ đề:

đặc điểm chung của lĩnh vực chủ đề và tình hình công tác tự động hóa các hoạt động thông tin trong lĩnh vực này; phân tích khả năng và tính năng của các hệ thống tương tự hiện có; cơ cấu tổ chức của tổ chức mà IS được thiết kế đang được tạo ra; mục đích của tổ chức (hệ thống) sử dụng IS được thiết kế là gì, các chức năng của nó (tổ chức, “vật chất”, thông tin); các chỉ số kinh tế kỹ thuật chính của hoạt động của tổ chức; các quá trình thông tin, sự kết nối giữa chúng; thành phần của các tài liệu được sử dụng và mục đích của chúng.

Thông số kỹ thuật ngắn gọn. Các thông số kỹ thuật phải phản ánh:

mục đích, mục đích tạo lập sở hữu trí tuệ; yêu cầu đối với toàn bộ hệ thống; các chức năng, nhiệm vụ tự động hóa cơ bản, đặc điểm thời gian giải quyết vấn đề và yêu cầu trình bày thông tin trong hệ thống;

tiêu chí về tính hiệu quả của hệ thống đang được phát triển (các yếu tố quyết định tính hữu ích của hệ thống đang được phát triển, tiêu chí đánh giá chúng); danh sách các giai đoạn và giai đoạn của công việc và thời hạn hoàn thành, thời hạn xây dựng tài liệu dự án.

Mục “Thiết kế kỹ thuật”, gồm các tiểu mục sau:

mô hình chức năng của hệ thống (trình bày sơ đồ ngữ cảnh, sơ đồ cấp một và một hoặc hai sơ đồ cấp hai; mô tả thành phần của các chức năng chính, các kết nối của chúng: đầu vào, đầu ra, luồng điều khiển); mô hình luồng dữ liệu (trình bày sơ đồ ngữ cảnh, sơ đồ cấp một và một hoặc hai sơ đồ cấp hai; mô tả thành phần của các ổ đĩa, chức năng chính, kết nối thông tin của chúng: luồng đầu vào và đầu ra; đối với mỗi ổ dữ liệu, hãy mô tả đặc điểm ổ đĩa, tần suất và cường độ cập nhật); mô tả hỗ trợ thông tin: dạng tài liệu đầu vào và đầu ra, đặc điểm về khối lượng, tần suất, cường độ cập nhật, phân tích cấu trúc của chúng (chi tiết, thực thể được mô tả), phân loại được sử dụng, phương pháp mã hóa, yêu cầu đảm bảo độ tin cậy của dữ liệu.

Danh sách các nguồn được sử dụng (tài liệu). Mục “Bản thảo làm việc” gồm các tiểu mục sau:

mô tả lược đồ cơ sở dữ liệu trên ACCESS (hoặc trong DBMS khác), mô tả các tác vụ thực hiện các chức năng được xây dựng trong Thiết kế kỹ thuật (bao gồm các truy vấn, biểu mẫu, báo cáo, các trang truy cập được sử dụng trong các tác vụ này). Cần có các hình thức đối thoại và hướng dẫn sử dụng. Nếu dự án không chứa các biểu mẫu hoặc báo cáo phức tạp thì điểm sẽ giảm 1 điểm.

Kết luận: Tóm tắt tác phẩm. Chỉ ra những điều khoản nào của Thiết kế Kỹ thuật đã được thực hiện và chưa được thực hiện trong phần thứ hai và tại sao.

Sơ đồ hệ thống thông tin

Việc bố trí hệ thống thông tin phải được thực hiện phù hợp với dự án. Nó phải là một cơ sở dữ liệu hoàn chỉnh với các truy vấn, biểu mẫu, báo cáo thực hiện các nhiệm vụ được mô tả trong dự án.

Yêu cầu về tài liệu

Khi phát triển tài liệu, hãy xem xét các yêu cầu sau:

bố cục các phần, tiểu mục của tài liệu báo cáo phải tương ứng với những gì được liệt kê trong đoạn “Nội dung tài liệu dự án”; các sơ đồ mô hình chức năng, mô hình luồng dữ liệu, mô hình khái niệm và mô hình vật lý được vẽ dưới dạng bản vẽ và được có trong văn bản chính; Trong văn bản chính còn có các văn bản truy vấn, bản vẽ trình bày biểu mẫu, báo cáo, trang truy cập, tài liệu mẫu, bảng mô tả mô hình, bảng mô tả thuộc tính của các trường cơ sở dữ liệu được đưa ra dưới dạng phụ lục.

Danh sách các giai đoạn công việc và thời hạn hoàn thành

Công việc được thực hiện theo lịch trình ở trang tiếp theo (Bảng 4.1).

Thủ tục kiểm soát và chấp nhận tài liệu báo cáo

Tài liệu báo cáo được nộp trong hai thời hạn:

Trong học kỳ mùa thu, một báo cáo được nộp tương ứng với năm điểm đầu tiên của lịch trình. Trong học kỳ mùa xuân, kết quả cuối cùng của công việc được nộp: một báo cáo (bao gồm cả kết quả sửa đổi từ học kỳ trước), cũng như cơ sở dữ liệu - bố cục của IS đã phát triển.

Việc đánh giá công việc trong học kỳ mùa thu được thực hiện dưới hình thức kiểm tra. Trong học kỳ mùa xuân, tất cả bài tập trong năm đều được coi là bài tập khóa học. Chỉ những sinh viên đã hoàn thành khóa học của mình mới được phép tham gia kỳ thi. Hình phạt.

Kết quả thiết kế phải được giao đúng thời hạn quy định trong tiến độ. Vi phạm thời hạn sẽ bị phạt, nếu Nhà phát triển (sinh viên) không nộp báo cáo đầu tiên đúng thời gian quy định trong lịch trình thì không được phép dự thi. Nếu báo cáo được nộp muộn, quyết định cho phép tham gia kiểm tra sẽ được Khách hàng (giáo viên) đưa ra trong vòng một tuần. Nếu Nhà phát triển (sinh viên) nộp tài liệu báo cáo cuối cùng muộn hơn thời hạn quy định trong lịch trình, điểm cho bài tập của khóa học bị giảm 1 điểm. Việc bảo vệ bài tập đã nộp có thể diễn ra không sớm hơn một tuần sau khi trình bày tài liệu báo cáo. Quyết định cho phép dự thi do giáo viên đưa ra căn cứ vào kết quả bảo vệ môn học. Mong muốn nhận được học bổng của Chủ đầu tư không phải là cơ sở để hủy bỏ hình phạt.

Lịch trình làm việc để phát triển các tài liệu báo cáo

Bảng 4.1.

	Tên giai đoạn	Thời hạn	Tài liệu đã gửi
	CÔNG TRÌNH CHO HỌC KỲ MÙA THU
1	Lựa chọn lĩnh vực chủ đề và tổ chức mà hệ thống thông tin cần được thiết kế	Một tuần sau bài giảng đầu tiên	tên IP
2	“Nghiên cứu” về lĩnh vực chủ đề (dựa trên tài liệu và kết quả trao đổi với các chuyên gia)	Một tuần sau bài giảng thứ ba
3	Phát triển mô hình chức năng	Một tuần sau bài giảng thứ tư	Sơ đồ chức năng dạng viết tay
4	Phát triển mô hình luồng dữ liệu	Một tuần sau bài giảng thứ năm	Sơ đồ luồng dữ liệu viết tay
5	Xây dựng mô tả các tài liệu đầu vào và đầu ra	Kết thúc vào ngày 25 tháng 11	Cấu trúc chi tiết tài liệu, sự phụ thuộc chức năng của chi tiết
6	Xây dựng tài liệu thiết kế phù hợp với đoạn 3.2.1 – 3.2.5	Trong tiến trình. thực tế các lớp học.
7	Cung cấp tài liệu dự án	ngày 20 tháng 12	Tài liệu dưới dạng báo cáo
	CÔNG TRÌNH HỌC KỲ MÙA XUÂN
8	Phát triển sơ đồ ngữ cảnh miền	Một tuần sau bài giảng thứ hai	Sơ đồ phần mềm theo ngữ cảnh ở dạng viết tay
9	Phát triển lược đồ cơ sở dữ liệu bằng ngôn ngữ của DBMS đã chọn	Đến cuối buổi thực hành thứ hai. các lớp học
10	Triển khai hệ thống (điền bảng cơ sở dữ liệu, xây dựng truy vấn, biểu mẫu, báo cáo, trang truy cập)	Đến cuối bài thực hành thứ năm	Cơ sở dữ liệu đã hoàn thành với các truy vấn, biểu mẫu, v.v.; trình bày với giáo viên
11	Đăng ký kết quả (dự án và cơ sở dữ liệu)	Một tuần sau điểm 9	Khóa học: tài liệu, được trình bày dưới dạng báo cáo và trong một tập tin; cơ sở dữ liệu
12	Công việc bảo vệ khóa học	Không sớm hơn một tuần sau ngày đáo hạn trước đó