Сегодняшняя тема, связанная с не выполненным вовремя домашним заданием на курсах по тестированию, также необходима для подготовки к собеседованию на вакансию тестировщика и к практике тестирования, анонсированной ранее.
Мое знакомство с информационными системами началось в аспирантуре. Я получила инженерную специальность в горном институте, изучила предметную область, как можно более подробно, и собиралась все это, по возможности, автоматизировать в рамках научно-исследовательской работы. Мой выбор пал на трудоемкий процесс проектирования. Расскажу, как я работала над своим проектом, и заодно повторим модели разработки программного обеспечения информационной системы.
В начале работы над проектом я занималась структурированием информации об объекте и определением необходимых исходных данных. Поскольку объект я хорошо знала, это не составило для меня труда, но в последствии к этому этапу пришлось вернуться. Дело в том, что в то время в нашей стране перестали выпускать большие вычислительные комплексы, такие как Эльбрус, и все расчеты были перенесены на персональные компьютеры, которые в то время не отличались большой производительностью. Поэтому мне приходилось несколько раз сокращать данные для вычислений, упрощать расчеты и количество данных для временного хранения на диске. Энтузиазма у меня было много и сдаваться я не собиралась. Компьютер, который бы меня на то время устроил, стоил 40 тысяч долларов и я надеялась, что мне его когда-нибудь купят на деньги заказчика, а пока занималась разработкой на той технике, которая была в наличии.
Работа над проектом была разделена на этапы, выполнявшиеся последовательно, как было принято в первых моделях разработки, но следующим этапом была декомпозиция. Так сказал руководитель. Стандарт для разработки автоматизированных систем ГОСТ 34.601-90 вступил в действие в 1992 году и включал в себя последовательность организационных этапов и необходимую документацию: требования, концепцию автоматизированной системы, техническое задание, эскизный проект, технический проект, рабочую документацию. По выполнению технического проекта никакой детализации не было, т.к. методы и подходы еще разрабатывались и не было достаточной практики их применения. Пришлось руководствоваться исключительно опытом руководителя, который уже многократно принимал участие в исследовательских проектах. Моя работа проводилась с конца 1994 по 1997 год. Перед дефолтом 1998 года, финансирование было прекращено, а потом нас ждал еще один неприятный сюрприз, связанный с появлением в России крупной западной компании. Работа над проектом была остановлена на этапе первых испытаний системы и выявления критических уязвимостей.
Таким образом, в моем исследовательском проекте по моделированию сложной технической системы была использована гибридная методология разработки, включавшая в себя следующие модели:
- водопадная: были четко определены этапы разработки, которые выполнялись последовательно. Но как мы знаем, водопадная модель хорошо работает на небольших проектах, поэтому в моем случае ее было необходимо дополнить моделями, применяемыми для более сложных систем;
- итерационная: постепенно увеличивалось количество проводимых расчетов для каждого моделируемого цикла, т.к. работа моделируемого объекта также циклична. В условиях ограниченных вычислительных ресурсов это был необходимый инструмент для построения автоматизированной системы проектирования. Декомпозиция объекта помогла уточнить входные данные и промежуточные результаты вычислений. Не могу назвать применяемую модель инкрементальной, т.к. "приращения" могли включаться как в основной расчетный модуль, так и в дополнительные, что не соответствует современным коммерческим моделям, для которых было бы нецелесообразным включать дополнения в уже принятые и оплаченные расчетные модули.
Стандарт, по которому мы работали, был заменен только в 2022 году! Теперь он называется ГОСТ Р 59793–2021. Кроме того, изменения коснулись и других стандартов на разработку автоматизированных систем: технического задания, комплекта документов, требований к содержанию документов. Обновлены термины и определения. используемые в технических документах на автоматизированную систему. Изменились требования к техническим испытаниям системы. Полный перечень изменений можно найти в статье на Хабре. Наряду с обновленными стандартами, продолжает действовать ГОСТ 19.101–77 на Единую систему программной документации (ЕСПД) от 1977 года, с изменением №1, сделанным в 1981 году! Возможно, изменения коснутся и таких "древних" стандартов, будем следить за изменениями.
В процессе работы над системой мне приходилось рисовать много экранных форм, из который состоял мой эскизный проект технической системы. В то время еще не было программ наподобие Figma, и мне приходилось выполнять всю работу вручную: придумывать расположение элементов форм так, чтобы количество вложенных форм не превышало трех; разрабатывать навигацию между экранными формами, следить за тем, чтобы количество входных элементов формы не было чрезмерным; разрабатывать структуру текстового документа, в который можно заранее занести все входные данные и не вводить их часами во время работы программы;
В то время мне казалось, что все, что я делаю, к научной работе никакого отношения не имеет. До первых результатов было еще далеко. Организационные процессы и визуализация системы казались мне какими-то несерьезными задачами, хотелось большего. Сейчас, когда изучаю стандарты на документацию, понимаю, что к этим задачам следует относиться серьезно, от них зависит, какой продукт в результате получит заказчик, последовательность и количество этапов проектирования и разработки, виды работ, выполняемые на каждой итерации разработки системы.
Если остались вопросы, пишите, будем разбираться вместе.
