Документация и стандарты

Все темы Systems Analyst

Чем ГОСТ 19 отличается от ГОСТ 34?

ГОСТ 19 и ГОСТ 34 в этом контексте обозначают комплексы стандартов, а не два отдельных документа:

1. ГОСТ 19, Единая система программной документации, задаёт виды программных документов и требования к их содержанию и оформлению. Объектом документирования является программа или программное изделие.

2. Комплекс ГОСТ 34 на автоматизированные системы охватывает их создание и документирование, включая виды и комплектность документов. Это не общее обозначение стандартов шифрования и информационной безопасности.

При выборе уточняют объект разработки и конкретные стандарты с годом редакции, предусмотренные договором: программу либо автоматизированную систему в целом.

Приходилось ли вам писать спецификации?

Назовите спецификации, которые действительно писали, их аудиторию и свою роль. Можно рассказать о требованиях, интерфейсах, схемах данных и критериях проверки, если они входили в вашу работу.

Какие документы по ГОСТУ вы писали?

Возможный пример: техническое задание на информационную систему. Назовите реальный документ и точный ГОСТ с редакцией, по которому работали. Следующий перечень является общим примером содержания и не воспроизводит обязательную структуру конкретного ГОСТ.

Цель документа: Определить требования к разработке новой информационной системы для автоматизации управления складскими запасами.

1. Введение

   • Описание задачи и необходимости разработки новой системы.

   • Краткий обзор текущих проблем и недостатков в управлении складскими запасами.

2. Основные требования

   • Функциональные требования: описание основных функций системы, таких как учет поступления и отгрузки товаров, инвентаризация, генерация отчетности.

   • Нефункциональные требования: требования к производительности, надежности, безопасности и пользовательскому интерфейсу.

3. Архитектура системы
   • Описание общей архитектуры системы, включая серверную и клиентскую части, базы данных и интерфейсы взаимодействия.
4. Интеграция
   • Требования к интеграции новой системы с существующими информационными системами компании.
5. Тестирование
   • План тестирования: описание методов тестирования функциональных и нефункциональных требований, критерии приемочного тестирования.
6. План разработки
   • Расписание работ и этапы разработки: оценка сроков выполнения работ, распределение задач между командами разработчиков.
7. Заключение
   • Общие выводы и рекомендации по разработке и внедрению системы.

Как бы вы сделали регистрацию программного обеспечения?

Сначала уточните, что означает регистрация ПО: учётная запись в продукте, лицензирование или официальная регистрация самого ПО. Ниже описана только регистрация пользовательского аккаунта; это не процедура регистрации программного обеспечения.

1. Идентификация пользователя:

   • Запрос данных о пользователе (имя, email, пароль).

   • Проверка уникальности email.

   • Хеширование пароля перед сохранением в базу данных.

2. Подтверждение email:

   • Отправка письма с ссылкой для подтверждения email.

   • Активация аккаунта после перехода по ссылке подтверждения.

3. Управление доступом:

   • Ролевая модель доступа (администратор, пользователь).

   • Возможность смены пароля и восстановления доступа.

4. Защита данных:

   • HTTPS для защищенной передачи данных.

   • Хранение паролей в хешированном виде.

   • Защита от атак перебора паролей и SQL-инъекций.

5. Дополнительные меры безопасности:

   • Двухфакторная аутентификация.

   • Мониторинг активности пользователей и журналирование событий.

6. Пользовательский интерфейс:

   • Интуитивно понятная форма регистрации и входа.

   • Возможность настройки профиля пользователя.

Что включить в программу и методику испытаний?

ПМИ задаёт общий контур приёмки системы. В ней фиксируют объект и объём испытаний, проверяемые требования, состав среды, версии компонентов, тестовые данные и ограничения. Для каждого сценария нужны предусловия, шаги, ожидаемый результат и однозначный критерий прохождения. Также указывают роли участников, порядок регистрации и устранения замечаний, критерии входа и завершения испытаний. Результат оформляют протоколом: какие проверки проведены, какие отклонения остались и принято ли решение о приёмке.

Какие разделы включить в SRS?

SRS обычно содержит цель документа, границы и контекст системы, термины и заинтересованных участников. Основная часть описывает функциональные требования, внешние интерфейсы, данные и бизнес-правила. Отдельно фиксируют нефункциональные требования: производительность, безопасность, доступность, аудит и другие измеримые качества. Также нужны ограничения, допущения, зависимости, критерии приёмки и трассировка к источникам или целям. Структуру подстраивают под проект: документ должен отвечать, что должна делать система и при каких ограничениях, не превращаясь в подробное описание реализации, если такое решение ещё не принято.

Как Vision and Scope удерживает границы проекта?

Vision and Scope связывает инициативу с бизнес-проблемой: зачем проект нужен, для кого, какой результат и метрика означают успех. В документе явно перечисляют, что входит и не входит в первую границу, ключевые возможности, ограничения, допущения и заинтересованных лиц. При новом запросе его сравнивают с целями и in/out scope: запрос может быть ценным, но относиться к другой инициативе или требовать пересмотра срока и бюджета. Документ не запрещает изменения. Он даёт общую базу для осознанного решения и обновляется, если уполномоченные участники действительно меняют границы.

Можно ли совмещать Responsible и Accountable в RACI?

В RACI Responsible выполняет работу, а Accountable несёт конечную ответственность и утверждает результат. Один человек может совмещать обе роли, особенно в небольшой задаче, если у него есть полномочия и это не лишает работу независимой проверки там, где она нужна. Для одного результата обычно назначают одного Accountable, иначе решение и эскалация размываются. Responsible может быть несколько, но тогда полезно уточнить конкретные части работы. Матрица должна отражать реальный процесс, а не формально заполнять все клетки: пустая или совмещённая роль допустима, если ответственность остаётся однозначной.