Как создать успешный образовательный продукт
Для начала, договоримся о том, что такое успешный продукт.
Я думаю, успех — это три составных части:
- Аудитория проекта видит для себя его ценность и получает ожидаемый результат;
- Проект отвечает финансовым ожиданиям владельца;
- Создатель получает радость и драйв от его реализации.
Кажется просто, однако далеко не каждый проект в сфере обучения можно считать успешным. Возможно, потому что есть еще элемент удачи: ты никогда не знаешь наперед «взлетит-не взлетит», понравится или нет.
Конечно, чем опытнее методист, тем выше вероятность того, что все составные части сойдутся, но алхимия может произойти и в начале пути.
Как примириться с таким высоким уровнем неопределенности? Мой ответ прост: полюбить ошибки.
О том, как создать успешный курс, избежать типовых ошибок, и найти в себе ресурсы для роста Татьяна Загривная расскажет на образовательной программе «Метод».
Зарегистрироваться
Знать абсолютно все невозможно — это факт, и каждый педагог понимает, что в ошибках кроется огромная сила приобретения опыта и знаний.
Тем не менее, поощряя позитивное отношение к ошибкам у своих учеников, мы, учителя, нередко сами боимся признаться себе и окружающим в собственном несовершенстве.
Выход — занять открытую позицию: быть готовым принять ошибку, и не обесценивать из-за нее свой труд. Продолжать работать, благодарить того, кто эту ошибку показал.
У меня есть любимое упражнение, которое придумал и описал профессор психологии Николай Иванович Козлов. Оно называется «Ошибочка» и помогает принять любой свой промах, и найти силы, чтобы его исправить.
Работает это упражнение так:
Признаем сам факт совершения ошибки. Вспомните ситуацию ошибки. Разведите руки в стороны, как если бы вы были сильно удивлены. А ведь так и есть, давайте признаем, скажите: «Ошибочка!». Лучше если ваш голос будет веселым.
Отделим себя от ошибки. Двумя руками ласково обхватите себя за плечи, погладьте и напомните себе: «Я хороший!» или «Я умница!». Ошибка есть, но она НЕ ДЕЛАЕТ МЕНЯ ХУЖЕ.
В полном ресурсе приступим к исправлению ситуации. Вы почувствовали себя спокойно, тогда самое время вытянуть руку вперед и сказать решительно: «Работать! Исправлять». В этот момент сил на решение ситуации уже больше, ведь «вы хороший», а значит справитесь с любой неудачей.
На ошибках учатся
Помните фразу «за одного битого двух не битых дают»? Это очень применимо в работе методолога. Ошибаются все, но важно уметь отрефлексировать свои ошибки, понять, что надо сделать иначе.
Например, мои первые онлайн уроки были перенасыщены визуальным материалом: я очень сосредотачивалась на том, чтобы сделать красивую презентацию и всю её показать, старалась впихнуть как можно больше смысла и в результате теряла все. Где-то после 15-ой минуты у моих маленьких учеников начинались помехи, отключались экраны, а некоторые откровенно зевали и отвлекались. Мне пришла идея добавить физкультминутки, которые позволили детям отвлечься и разбили информацию на удобные для них порции и сократить программу, выбрав основное.
Вот несколько ошибок, которые мешают начинающим методистам:
- Неверие автора в себя и свои знания.
Учебному процессу здорово мешает так называемый «синдром самозванца», когда человек не верит в то, что заслуживает успех. В активных продажах есть методика: продай себе, продай себя, продай продукт. Так же и автор курса в первую очередь сам должен быть твердо уверен в ценности своих знаний, а потом доносить их до остальных. Если у методиста есть сомнения, убедить аудиторию будет сложно. - Чрезмерная увлеченность темой и отсутствие логики.
Если автору хочется рассказать все и сразу, переизбыток информации вносит путаницу и нарушает структуру, учащиеся не успевают за логикой, путаются и теряют интерес. - Жонглирование методиками.
Как и в содержании, в методических приемах важна мера. Порой не требуется весь арсенал техник, а достаточно одного самого банального упражнения, и все уже понятно ученикам. Методика ради результата, а не ради самой методики. - Эмоциональный дисбаланс.
Если эмоционально педагог недостаточно включен в рассказ — его неинтересно слушать. Но и чрезмерная театральщина грозит потерей смысла. Задача — найти золотую середину и впадать в крайности - Игнорирование или не правильная работа с обратной связью от учеников.
Методист как открытое ухо: не боится ошибок и негативных отзывов, готов услышать то, что, возможно, требует изменений. Если это не так, то он рискует упустить нечто важное. - Размытые критерии оценивания.
Если результат не измерен, то его нет — этот принцип справедлив и для образовательных проектов. Без четкой и логичной шкалы оценки результата мы рискуем не достичь цели - Неопределенная целевая аудитория.
Если методист четко не определил, для кого конкретно он создает свой курс, ему сложно выявить нужды аудитории, грамотно определить содержание и техники программы. А всем обо всем рассказать невозможно.
Последняя ошибка одна из самых распространенных, но решить ее достаточно просто: составить опросный лист и протестировать идею курса. Даже не прописывая целиком и полностью методологию, можно провести «краш-тесты» или сделать какой-то прототип в соцсетях. То есть объективно узнать мнение той аудитории, на которую ориентируемся, чтобы выяснить, нужно им это или нет.
Эти и другие типовые ошибки мы будем разбирать на мастерской в образовательной программе «Метод». На семинаре мы обсудим теорию, а после участники попробуют создать и презентовать свои курсы, избегая изученных промахов. Одна из команд будет составлять методику с учетом разобранных ошибок, а две другие устроят ей «краш-тест». В итоге, кто-то воспримет разбор на слух, кто-то попробует в действии, и каждый запомнит свои недочеты. А если ошибка запомнилась, значит, есть вероятность, что она уже не будет допущена.
Приходите на курс и мы будем ошибаться вместе, а значит станем сильнее и успешнее.
Избежать ошибок помогает не только практика, но и теория. Я составила свой список литературы, который рекомендую педагогам и методологам. Он пригодиться не только при проектировании образовательных программ, но в повседневной работе.
Берн Э. «Игры, в которые играют люди: психология человеческих отношений»;
2. Виноградов С. и Кузьмин А. «Логика. Учебник для средней школы» (издание восстановленное с оригинала 1954 года);
3. Гин А. «Приемы педагогической техники: Свобода выбора. Открытость. Деятельность. Обратная связь. Идеальность: Пособие для учителя»;
4. Голви У. «Работа как внутренняя игра: Фокус, обучение, удовольствие и мобильность на рабочем месте»;
5. Коннорс Р. , Хикман К. «Принцип Оз. Достижение результатов через персональную и организационную ответственность».
Сбор и анализ требований (Planning and Requirement Analysis)
Это, пожалуй самый ответственный и важный из всех шагов к созданию успешной программной системы. Вся собранная информация используется для планирования базового проектного подхода.
Дополнительно идет планирование требований по обеспечению качества и выявления различных рисков, связанных с проектом. Результатом анализа является определение различных технических подходов, которые можно использовать для успешной реализации проекта с минимальными рисками. Планируйте то, что вы можете контролировать, и помните о вещах, планировать которые вы не сможете. Это поможет вам получить прочную основу для перехода ко второму этапу.
Проблема: Не соответствующие ожидания и часто изменяющиеся требования: заказчик и команда не понимают, какую реально пользу принесёт продукт.
Решение: Определить скоп работ, согласовать четкий, краткий документ с требованиями, создать прототипы (макеты) для подтверждения и уточнения окончательных требований.
Документирование требований (Defining Requirements)
Как только базовый анализ требований будет выполнен, следующим шагом будет четкое определение и документирование требований к продукту, утверждение со стороны клиента. Если одной из целей первого этапа является понимание и анализ требований, то на этом этапе все цели должны быть прописаны, это защита обеих сторон.
Важно четко определить и прописать, что требуется выполнить, это делается с помощью SRS (Software Requirement Specification). Документ содержит все требования к продукту, которые должны быть спроектированы и разработаны в течение жизненного цикла проекта.
Проблема: Большой многостраничный список требований
Решение: Выяснить высокоуровневые требования и, в ходе разработки и коммуникации с заказчиком, дописывать ТЗ. То есть разработка идет параллельно с Техническим заданием, а в процессе корректируется план.
В SolveIt мы всегда стараемся быть гибкими и подстраиваться под клиента. Работающий продукт важнее исчерпывающей документации.
Дизайн (Design the Product Architecture)
SRS это ориентир для разработчиков, чтобы предложить лучшую архитектуру для продукта. Обычно предлагается несколько подходов к проектированию архитектуры продукта. Все предложенные подходы документируются в спецификации DDS (Design Document Specification) и выбирается наилучший подход к проектированию. Данный подход очень четко определяет все архитектурные модули продукта, а также его связь с внешними и сторонними модулями.
Проблема: Выбрали неправильную архитектуру.
Решение: Наличие в команде разработчиков опытных лидов, которые смогли бы предложить подходящую архитектуру, на основе своего успешного опыта в схожих проектах.
Разработка ПО (Building or Developing the Product)
Здесь начинается разработка и сборка продукта. Весь программный код, новые модули и фичи разрабатываются на основании DDS. Чем лучше написана эта документация, тем быстрее будет идти имплементация. На этом этапе подключается команда разработчиков. Написанный код должен покрываться Unit-тестами, а взаимодействие новых фич с другими модулями тестироваться с помощью интеграционных тестов. Эти активности выполняются именно командой разработчиков, а не QA специалистами.
Проблема №1: Слабая коммуникация между командой
Разработчик не интересуется прогрессом проекта, проблемами коллег.
Решение: Daily meetings, 100% вовлеченность, Скрам доска (интерактивность).
Проблема №2: Невыполнимые сроки
Заказчик хочет, чтобы его продукт был готов в ближайшее время. Менеджер проекта пытается объяснить клиенту к чему приведет такая спешка, но этого не достаточно. Клиент ставит невыполнимые дедлайны и не слушает возражения менеджера проекта. В результате, команда разработчиков сдается и пробует закрыть задачи в слишком короткие сроки. Как следствие – критические баги из-за спешки: команда не успевает, качество продукта снижается, клиент не доволен и решает, что виновата команда.
Решение: Менеджер проекта должен стоять на своём и аргументировать дедлайны. Клиент должен понять, что если команда разработчиков будет торопиться, то не реализует часть функционала. Если всё же такой срок реализации критичен для клиента, мы стараемся выявить какие задачи находятся у заказчика в приоритете.
Проблема №3: Добавление не оговоренных фич
99% заказчиков ошибаются именно в этом месте. В ходе разработки клиент отклоняется от оговоренного тз и хочет добавить ещё фич в продукт. В результате вместе с ростом скопа фич, увеличиваются сроки и бюджет на разработку, деньги заканчиваются, а готово только 50% продукта.
Решение: Менеджер проекта должен объяснить клиенту, к чему приведет добавление новых фич в проект, отстаивать свою позицию и держаться SRS. Поэтому так важна вторая фаза Жизненного цикла разработки ПО.
Тестирование (Testing the Product)
Именно тестирование, в основном, затрагивает все этапы жизненного цикла. Дефекты продукта регистрируются, отслеживаются, исправляются и повторно тестируются. Это происходит до тех пор, пока продукт не достигнет стандартов качества, которые прописаны в SRS. На данном этапе в процесс разработки подключается команда мануальных тестировщиков или автоматизаторы.
Проблема: Тратится слишком много времени на поиск причин багов. Попытки найти и исправить дефекты после завершения разработки – сложный процесс, который может привести к большому количеству исправлений.
Решение: Проводить тестирование параллельно задачам, сразу же по их завершению.
Внедрение и поддержка продукта (Deployment in the Market and Maintenance)
Проблема №1: Отсутствие обратной связи, реальных отзывов потенциальных пользователей продукта.
Решение: Не ждать конца разработки, а как можно скорее запускать продукт, чтобы получить отзывы от реальных пользователей и на основе их предпочтений приоритезировать дальнейший функционал.
Проблема №2: Слабая инфраструктура проекта на стороне клиента.
Часть заказчиков предпочитают размещать сервера приложений не на Azure, AWS, Google и т. д, а в своей внутренней сети. Команда не может гарантировать стабильную работу, из-за сбоев, которые происходят на стороне клиента.
Решение: Предупредить клиента, о возможных проблемах, предложить решения для их устранения.
Это шесть основных стадий жизненного цикла разработки системы, и это повторяющийся процесс для каждого проекта. Важно отметить, что должен поддерживаться отличный уровень коммуникации с заказчиком. Для реализации требований очень важны и полезны прототипы. Строя систему короткими итерациями, можно гарантировать соответствие требованиям потребителя до того, как построить целую систему.
Если вам нужен качественный продукт, свяжитесь с нами и мы сделаем оценку вашего проекта!
Прошлые попытки
Намучавшись с прохождением экспертизы по ряду объектов, когда разные эксперты предъявляли разные требования, я обратился с официальным письмом к руководству экспертизы, предложив реализовать совместный проект.
Мне показалось, что проектировщикам нужно издание, в котором будут описаны все нюансы прохождения государственной экспертизы: подробно описать, что эксперты хотят увидеть в проектах, а что там будет лишним, как писать пояснительные записки, чтобы было меньше замечаний и экспертам было проще работать, что хотят видеть эксперты в расчетных записках и обоснованиях, а также, как правильно работать с проверяющими во время прохождения экспертизы. К примеру, у меня был один редкий, но тяжелый опыт получения отрицательного заключения, который мы приобрели вовсе не из-за проектных ошибок, а из-за непонимания внутренней кухни работы экспертизы.
Рис. Вот так это выглядит ☹
Из этого мог бы получиться крайне полезный инструмент, который упростил бы жизнь тысячам компаний и сотням экспертов. Ведь каждый эксперт талдычит одно и тоже каждому жаждущему получить положительное заключение. И делает это он изо дня в день.
Разве вместо этих непродуктивных действий сотен экспертов, не является эффективным управленческим шагом систематизировать все ключевые данные и описать их один раз, а потом раздать/продать эту книгу, и уже с чистой совестью отчитывать бездельников, кто ее не прочитал?
Но наверно не нужно объяснять, получил ли я поддержку со стороны руководства экспертизы и был ли реализован этот проект?
Вспоминаю моего партнера по монтажному бизнесу. Мы начинали с ним с самого нуля, и подписав контракты, сами шли на площадку и управляли работами, как умели. Он показал себя, как эффективный прораб и руководитель проекта. Когда мы уже выросли, и в компании работали сотни сотрудников, я несколько раз спрашивал его: «Почему ты ругаешь прорабов за нерадивость, но не передаешь свой опыт? Не объясняешь?».
На что он мне отвечал: «Я добился и дошел до всего сам, теперь хочу, чтобы и они прошли свой путь». Это подход крепко прижился в нашей сфере – «я помучался, теперь твоя очередь».
Возможно, это неплохой вариант для воспитания силы духа сотрудников, но это – самое настоящее дно эффективности и искусства менеджмента.
Давно хотелось собрать инструкции для сотрудников и мне, но поскольку по образованию я ни разу не строитель, то решил привлечь к этому ответственному делу наших инженеров. Очевидно, что такая творческая задумка может выполняться не из-под палки, а по сильному желанию, поэтому сначала мы провели опрос, кто готов этим заняться за дополнительную оплату.
Результат ударил по моей надежде. Ноль человек. Никто не взялся за это. Были робкие попытки меня поддержать, но не более. Но при этом я получил и такое мнение: «Не нужно ничего описывать, есть интернет и СП, каждый должен разбираться сам».
Возможно, причина такого отношения лежит в особенности нашего свободолюбивого духа, не терпящего рамки и ограничения. Но мне доводилось слышать, что некоторые народы западного мира также отличаются непокорным нравом, но на папки с инструкциями их свободолюбие не распространяется.
Рис. Инструкции не нарушат вашу свободу
Чем сложнее сфера, тем важнее наличие в компании описанной технологии правильного выполнения действий.
Перед каждым полетом авиалайнера, опытные и слетавшиеся друг с другом экипажи, которые провели тысячи часов в воздухе, не проявляют свой нрав и бунтарство, а достают контрольные списки и проходят по ним. Шаг за шагом, пункт за пунктом. А мы, сидящие в салоне пассажиры, очень надеемся, что они ничего не упустят, и будут действовать строго по инструкции, написанной кровью летчиков-испытателей (а иногда и погибших пассажиров).
Рис. Безопасность в гражданской авиации немыслима без чек-листов
Есть ли такие подробные инструкции и чек-листы в проектных компаниях? Наверняка где-то есть, но это такая же редкость, как красный алмаз.
Возможно, кто-то скажет, что в сложном и творческом процессе, как проектирование, не может быть описанной технологии, ведь все слишком индивидуально. Это, конечно, хорошая отговорка, но поговорите с любым талантливым творцом, и на основе его ответов вы сможете составить гениальный обзор профессии и даже первый чек-лист.
Инструкции не одарят человека талантом, но дадут более глубокое понимание предмета, научат правильной последовательности, исключат ошибки, воспитают культуру работы. Тогда и до таланта останется не так далеко, разве нет?
Кто должен писать такие инструкции?
Секретарь или самый низкоквалифицированный сотрудник, которого не жалко?
Наоборот – тот, кто является носителем или разработчиком технологии проектирования конкретной компании. Если во главе стоит талантливый архитектор, конструктор или инженер, он должен отложить часть дел и потратить несколько месяцев, чтобы систематизировать свои знания и переложить их на бумагу. Если же руководитель не является самым умным сотрудником, то он должен выявить такого и поручить ему это сделать.
Кроме того, к этому процессу нужно подключить всех ключевых сотрудников, ведь они каждый день сталкиваются с проектными или управленческими проблемами, находят решения или же совершают ошибки, и обе разновидности такого бесценного опыта должны быть бережно описаны и сохранены.
А потом все это нужно отдать в руки эффективному администратору, который организует процесс передачи этих знаний всем своим сотрудникам.
Как результат, молодой сотрудник, появившейся в компании, получит в руки самый ценный подарок – профессию, с которой у него будут связана жизнь, мечты и стремления.
А более опытный коллега приобретет инструмент, такой же ценный, как монитор или компьютерная мышь.
С болью вспоминаю горящие глаза некоторых молодых специалистов, которые приходили к нам на работу, с восхищением смотря на объекты, с которыми им придется работать. Но проходило всего несколько месяцев, и они с потухшим взором покидали нашу команду. Я уверен, что в большинстве случаев рухнувших надежд можно было избежать, дав им в руки папку с описанной технологией проектирования, с которой они не будут расставаться, пока из них не выйдет толк.
Раз таких инструкций никто не создает, тогда есть только два пути развития компаний:
Путь №1 (самый распространенный):Молодой специалист (или более опытный проектировщик, который повышает свою квалификацию) учится работать на реальных объектах, а за его ошибки отвечают владельцы бизнеса или заказчики – своими деньгами, репутацией и срывом сроков. А потом этот человек научится основам ремесла и, щеголяя своими (запоротыми) объектами, уйдет работать в другую компанию, где ему заплатят больше денег. Это точно не стратегия win-win.
Проверка никогда не бывает лишней, но, если трудозатраты на проверку соизмеримы с трудозатратами на проектирование, это становится довольно накладно.
Если при чтении статьи вам показалось, что я говорю о должностных инструкциях, которые выдает отдел кадров при оформлении на работу, то мне не удалось донести до вас свою мысль. То, что предоставляет кадровик может быть всем, чем угодно, но только не ноу-хау для специалиста.
Рынку требуется все больше и больше проектировщиков, и чем больше их нужно, тем более подробные и простые инструкции по проектированию должны быть.
Уже сейчас очевидна тенденция — желающих разрабатывать рабочую документации становится все меньше и меньше, и кто будет проектировать квадратные километры жилья и социальных объектов в ближайшем времени – не понятно.
К счастью, современные информационные технологии сильно облегчают жизнь, в том числе и при создании таких фундаментальных трудов.
Пишите, встречались ли вам полезные, работающие инструкции, применимые в вашей профессии?
2 Жизненный цикл
Неотъемлемым элементом процесса разработки программ является жизненный цикл. Жизненный цикл можно представить в виде совокупности следующих этапов, на которых необходимо выполнять следующие действия:
- Провести анализ предметной области и составить техническое задание (на этом этапе разработчики взаимодействуют с заказчиком)
- Разработать структуру программы
- Набрать программный код согласно проектной документации
- Протестировать и произвести отладку
- Внедрить программное обеспечение в эксплуатацию
- Сопроводить программное обеспечение
- Утилизировать.
Предметную область это часть сферы деятельности человека, выделенную и описанную согласно установленным критериям. Описываемое понятие должно состоять из следующих сведений:
- сведения об элементах,
- сведения о явлениях,
- сведения об отношениях,
- сведения о процессах.
Все эти сведения должны отражать различные аспекты этой деятельности. Также к описанию предметной области относятся характеристики возможного влияния окружающей среды на элементы и явления предметной области, а также обратные воздействия этих элементов и явлений на среду. От работы по изучению и анализу предметной области зависит эффективность дальнейших этапов работы.
Изучение предметной области – это одно из первых действий выполняемых программистом. От предметной области зависят будущие аспекты проекта, такие как, требования к системе, взаимодействие с пользователем, модель хранения данных, реализацию и т.
Анализ предметной области, позволяет выделить ее сущности, определить первоначальные требования к функциональности и определить границы проекта. Модель предметной области должна быть документирована, храниться и поддерживаться в актуальном состоянии до этапа реализации. Для документирования могут быть использованы различные средства.
Сначала производится проектирование архитектуры программной системы. Это предполагает первичную стадию проектирования структуры системы.
Следующим шагом является детальное проектирование. На этом этапе происходит процедурное описание программы, выбор и оценка алгоритма для реализации каждого модуля.
Для проектирования модульных программ применяются два основных метода: нисходящего и восходящего проектирования.
В соответствие с методом нисходящего проектирования сначала кодируются, тестируются и отлаживаются модули самого высокого уровня.
Применение метода нисходящего проектирования основано на пошаговой детализации решения задачи. Начиная с верхних, самых общих шагов, на каждом следующем происходит все большее уточнение функций, выполняемых программой, до полной их реализации.
Понятие жизненного цикла (software life cycle) рассматривают как, период с момента возникновения идеи до изъятия его из эксплуатации. Жизненный цикл включате в себя довольно сложный процесс создания и использования (software process). Организация этого процесса зависит от класса программного продукта и коллектива разработчиков.
На рисунке 1 приводится пример взаимосвязи между стандартными процессами и стадиями жизненного цикла.
Рисунок 1. Пример взаимосвязи между стандартными процессами и стадиями
На сегодняшний день выделяют следующие основные подходы к организации процесса создания и использования программного обеспечения.
Рисунок 2. Водопадный подход
Следующий подход — Исследовательское программирование. В этом подходе предполагается быстрая реализация рабочих версий программ, которые выполняют основные требования. После экспериментального использования реализованных программ разработчики модифицируют программу, добавляя новые функции необходимые пользователю. Эти действия повторяются до тех пор, пока программный продукт не будет удовлетворять всем условиям клиента. Данный способ применялся раннее, когда технологиям программирования не придавалось большого значения (использовалась интуитивная технология). На данный момент этот способ используется только для таких программных продуктов, где клиенты не имеют возможности формулировать свои требования.
Рисунок 3 — Модель прототипирования
Рисунок 4 — Схема процессов в CASE-технологиях
И еще один подход — сборочное программирование. Этот подход используется в таких случаях, когда его можно собрать из готовых компонентов.
1 Этапы разработки ПО согласно ГОСТ 2. 103-68
Среди российских программистов распространена практика создания программ согласно стадиям ГОСТ 2. 103-68:
- Техническое предложение,
- Эскизный проект,
- Технический проект,
- Рабочий проект.
На каждом из этапов формируется свой комплект документов, называемый проектом (проектной документацией).
На стадии Техническое предложение выполняются следующие виды работ:
- Подбор материалов.
- Разработка технического предложения с присвоением документам литеры «П».
- Рассмотрение и утверждение технического предложения
Стадия Эскизный проект характеризуется следующими работами:
- Разработка эскизного проекта с присвоением документам литеры «Э».
- Изготовление и испытание макетов (при необходимости)
- Рассмотрение и утверждение эскизного проекта.
Для стадии Технический проект характерны следующие действия:
- Разработка технического проекта с присвоением документам литеры «Т».
- Изготовление и испытание макетов (при необходимости).
- Рассмотрение и утверждение технического проекта.
Стадия Рабочий проект самая объемная по количеству работ. На этой стадии выполняются такие действия, как:
- Рассмотрение и утверждение технического проекта.
- Разработка конструкторской документации, предназначенной для изготовления и испытания опытного образца (опытной партии), без присвоения литеры.
- Изготовление и предварительные испытания опытного образца (опытной партии).
- Корректировка конструкторской документации по результатам изготовления и предварительных испытаний опытного образца (опытной партии) с присвоением документам литеры «О».
- Приемочные испытания опытного образца (опытной партии).
2 Этапы разработки ПО Software Architecture Document
В зарубежной практике регламентирующими документами, например, являются Software Architecture Document, Software Design Document
В ее основе лежит итерационная модель разработки программного обеспечения, представляющая собой последовательно расположенные этапы разработки с обратной связью между ними. Промежуточный контроль и корректировка разрабатываемой системы проводятся на каждом из этапов, что позволяет существенно снизить трудоемкость процесса производства.
Весь процесс разработки состоит из фаз.
Первая фаза называется — Анализ и разработка требований. Она предполагает сбор сведений о предметной области и технологических процессах для создания такой системы, которая бы лучше отвечала требованиям заказчика.
Этот этап сопровождается следующей документацией:
- Техническое задание (Software Requirement Specification)
- Проектное предложение (Project Proposal)
- План проекта (Project Plan)
- Архитектура приложения (Software Architecture Document)
Техническое задание (Software Requirement Specification)определяет технические требования, в общем то, что клиент ожидает от будущей программы.
Проектное предложение является результатом анализа проектных требований. Он создается для клиента. Документ содержит такие сведения как, оценку трудоемкости, стоимость проекта и приблизительные временные рамки его исполнения. На основании этого документа клиент принимает решение о начале проекта.
План проекта определяет такие параметры проекта как, сроки, задачи, промежуточные этапы проекта, ответственных участников проекта. Основная цель Плана заключается в документировании предположений и решений, налаживание связей между сторонами и указание целей проекта, его стоимости и времени на его исполнение.
Документ Архитектура приложения заключает в себе всесторонний обзор архитектуры. Он описывает различные стороны решения. А также служит для фиксирования и передачи важных архитектурных решений при разработке.
Вторая фаза — проектирование системы
Успех проекта определяется разработкой правильной архитектуры и концепции построения системы. К проектированию обычно приступают после завершения фазы анализа и проверки. Этот этап определяет ее компонентный состав и средства ее разработки. Зачастую этап разработки рассматривают, как возможность увеличить скорость и эффективность последующей разработки.
Этот этап сопровождается документом — Технический дизайн (Design Document).
В этом документе представляют полное описание программы для предоставления группе разработчиков наиболее полного руководства по архитектуре проекта. Этот документ можно представить в виде модели разрабатываемого программного продукта. Это модель состоит из четырех составляющих:
- разработка структуры данных,
- архитектурное проектирование,
- разработка интерфейсов ,
- процедурное разработка.
Третья фаза представляет собой собственно процесс разработки.
Стандартный процесс разработки состоит из таких этапов как, прототипирование, кодирование, модульное и системное тестирование. На этапе используется итеративный подход, который позволяет обеспечить требуемую надежность разрабатываемой системы.
На данном этапе создаются такие документы как, План тестирования (Test Plan) и Тестовые примеры (System Test Cases).
План тестирования — это документ, который определяет область действия, методы, средства и график планируемых тестовых операций. Именно в этом документе отражаются такие сведения как:
- предмет тестирования,
- функции, подлежащие тестированию,
- задачи тестирования,
- исполнителей тестирования,
- области риска, требующие особого внимания.
Тестовые примеры содержат тесты для проверки функций программы. В данных тестах используются известные входные данные. Затем результат сравнивается с ожидаемым. Основное назначение тестовых примеров это выявления ошибок, ограничений и различных погрешностей перед началом запуска программы.
Следующая фаза — Системное тестирование.
Фаза системного тестирования очень важна, так как клиенты увеличивают требования к таким характеристикам программных систем, как надежность, масштабируемость и производительность. Прежде чем, дойти до клиента программный проходит несколько этапов тестирования.
Эта фаза характеризуется следующими действиями:
- Прохождение тестовых примеров (Test cases running)
- Исправление найденных ошибок (Bug Fixing)
- Анализ запросов на изменения/исправления (Change request review)
- Уточнение тестовых примеров (Update test cases)
- Уточнение технического дизайна приложения (Update Design Document)
- Уточненные Тестовые примеры (Test Cases)
- Журнал испытаний (Test Log sheet)
- Запрос на модификацию(Approved Change Requests)
- Уточненный Технический дизайн (Updated Design Document)
Последняя фаза — Установка и интеграция.
После создания системы наступает этап ее внедрения в рабочее окружение на территории клиента. А также интеграция с существующими бизнес-приложениями.
В ходе данного этапа создается следующая документация:
- Акт приемки системы (Sign Off on Acceptance)
- Перечень ошибок (List of QA bugs)
- Инструкция по установке системы (Installation/Release Notes)
Участники процесса разработки ПО
- Пользователь
- Заказчик
- Разработчик
- Руководитель проекта
- Аналитик
- Тестировщик
- Поставщик
3 Майлстоун
Майлстоун (milestone) — метафора, которой в software development обозначают промежуточный этап разработки проекта.
Процесс разработки разбивается майлстоунами согласно специальному плану с целью минимизировать риски и успеть в заданные сроки. Каждый майлстоун подразумевает список задач, которые должны быть решены и воплощены в проекте до дедлайна. Если решить все задачи не успевают, происходит срыв майлстоуна. В этом случае либо выделяют дополнительное время на реализацию и сдвигают сроки, либо отказываются от проблемной фичи совсем.
Майлстоун фиксирует все принятые решения, чтобы у разработчиков не возникало соблазна переделывать всё до бесконечности.
Исторически, майлстоуны — это каменные плиты с указанием расстояний до населённых пунктов, которые расставлялись вдоль дорог и служили ориентиром путешественникам.
Milestone — этапы разработки, каждая из которых имеет свой номер (1, 2, 3 и т. Это может быть как пре-альфа, как и бета, так и ранний этап разработки (раньше пре-альфы). Некоторые этапы разработки могут помечаться как pre-. Например pre-Milestone 1.
Рассмотрим каждый этап Milestone.
Начальная стадия разработки — Пре-альфа. Это период времени от начала проектирования до выпуска версии Альфа (В случае отсутствия стадии Альфа — до любой другой). Программы, не вышедшие еще в стадию альфа или бета, но прошедшие этап разработки, также именуют пре-альфа. Такие пре-альфа выпускаются для первоначального анализа функциональных возможностей в действии. Отличие пре-альфа от альфа и бета версий заключается в том, что, пре-альфа могут иметь не все функциональные возможности программы. Пре-альфа содержит следующие действия
- разработка дизайна,
- анализ требований,
- собственно разработка приложения,
- отладка отдельных модулей.
Следующий этап – Альфа. По-другому внутреннее тестирование. Это стадия, на которой специалисты-тестеры тестируют программный продукт. Также на этой стадии возможно добавление новых функциональных возможностей. Использование программ на этой стадии возможно только в качестве знакомства с будущими возможностями.
Следующий этап – Бета. Также его называют Публичное тестирование. Это стадия активного бета-тестирования и отладки, прошедшей альфа-тестирование (если таковое было). Для испытания совместимости другие разработчики могут использовать версии программного продукта этого уровня. Наличие ошибок в программе на этом уровне не отрицается.
Бета-продукт не претендует на название финальной версией. Так как публичное тестирование производится усмотрение пользователя, то разработчик снимает с себя ответственность за ущерб, причинённый в результате использования бета-версии. Такой положение предоставляет многим производителям возможность уйти от ответственности, представляя только бета-версии продукта.
Следующая стадия используется крайне редко — Beta Escrow. Другое название стадия бета-тестирования, релиз-кандидат на Beta.
Релиз-кандидат – одна из основных стадий.
Релиз-кандидат или RC (англ. release candidate), Пре-релиз или Pre — стадия — кандидат на то, чтобы стать стабильной. В программах на этой стадии были найдены и исправлены все найденные ошибки, то есть они прошли комплексное тестирование. Тем не менее, не исключено появление некоторого числа ошибок, которые были не найдены на тестировании.
Стадия RC Escrow – это релиз, который готов получить звание релиз-кандидата. В этом релизе могут быть ещё ошибки.
Стадия релиз или RTM (англ. release to manufacturing промышленное издание) – это выпуск программного продукта, который готов к тиражированию. Обычно — это стабильная версия программного обеспечения, который прошел все предыдущие стадии. На предыдущих стадиях были исправлены основные ошибки. Также существует малая вероятность появления новых, ранее не замеченных, ошибок.
Стадия RTM Escrow – это конечный этап разработки программы, которая готова стать RTM-релизом.
Стадия Пост-релиз или Post-RTM (англ. post-release to manufacturing) — это издание продукта, у которого есть несколько отличий от RTM. Иногда из этой стадии получается первая стадия разработки следующего продукта. Такие релизы продаются, а раздаются бета-тестерам. Это может быть как и стабильная (если не замечено ошибок) либо с ошибками.
Эти стадии разработки (Beta Escrow, RC Escrow, RTM Escrow и Post-RTM) бывают редко. Beta-Escrow, RC-Escrow, RTM-Escrow — статус, указывающий, что на определенном этапе продукт не имеет серьезных ошибок в коде. Сборки с этим статусом передаются для тестирования ключевым и TAP-партнерам. Если тестирование не выявляет серьезных проблем — код подписывается для публичного тестирования
4 MSF
Microsoft предлагает MSF (Microsoft Solution Framework) Process Model. MSF – методология разработки программного обеспечения от компании Microsoft, опирающаяся на практический опыт компании и описывающая управление людьми и управление процессами в ходе разработки решения.
Еще есть RUP – Rational Unified Process.
Рассмотрим суть MSF. Разработка продукта согласно MSF включает следующие фазы:
- Формулирование идеи (концепции) проекта.
- Планирование.
- Разработка.
- Стабилизация решения.
- Развертывание.
Каждая фаза оканчивается контрольной точкой или вехой или milestone (рис.
Рисунок 5 – Схема процессов MSF
Для работы над проектом создается команда с четко разделенными ролями. Важно, что каждый участник команды вносит существенный вклад в достижении общей цели. Задачи и область ответственности участников могут меняться от этапа к этапу.
Роли могут быть следующие.
- Руководство проектом. Ответственны за общение с заказчиком. Во время этапа проектирования собирают требования пользователей к продукту. На следующих этапах демонстрируют промежуточные результаты заказчику, собирают замечания и пожелания.
- Руководство разработкой. Ответственны за процесс разработки, который должен завершиться в требуемые сроки.
- Разработчики. Ответственны за применение технологий для создания продукта согласно спецификации, предоставленной руководством разработки.
- Тестировщики. Ответственны за все вопросы, связанные с качеством продукта. Допускают продукт к релизу. Проверяют соответствие продукта требования различного рода.
- Руководство выпуском релиза. Ответственны за развертывание продукта у заказчика и обеспечение для этого всей необходимой инфраструктуры.
- Поддержка пользователей. Принимают вопросы и пожелания пользователей.
В небольших командах возможно объединение ролей, однако это рискованно. Рекомендации по распределению ролей приведены на рис
Рисунок 6 — Рекомендации по распределению ролей
4 Трудности при проектировании программного обеспечения
Рассмотрим основные затруднения, возникающие в процессе создания программного обеспечения.
Одной из проблем является недостаток прозрачности. Она заключается в сложности отслеживания процесса проектирования.
Такая ситуация возникает обычно при недостаточном финансировании проекта. За счет сокращения этапа проектирования выполняются остальные этапы. В результате не всегда становится известным, из скольких этапов состоит разработка и сколько времени занимает каждый этап.
Еще одной проблемой является недостаток контроля. Без точной оценки процесса разработки может превышаться бюджет проекта или сорваться графики выполнения работ. Также становится затруднительным определить объём выполненной и оставшейся работы. Обычно такая ситуация образуется вследствие дополнительного финансирования проекта, который уже находится в стадии разработки.
Еще одной из возможных проблем является недостаток мониторинга. Если у менеджеров нет возможности отслеживать ход развития проекта, они не могут контролировать ход разработки в реальном времени. Обычно мониторинг производится специальными программами. Если стоимость обучения и приобретения такой программы сопоставима со стоимостью самой разработки, зачастую от таких программ отказываются.
Очень часто проблемы создают заказчики. Например, такие затруднения как неконтролируемые изменения создаются из-за того, что у потребителя появляются новые идеи. Но если бесконтрольно вносить изменения в разработку программы, это скажется на всех этапах в целом. Например, увеличится бюджет проекта или продолжительность проекта. Каждое изменение должно быть согласовано всей командой разработчиков, после анализа влияния этого изменения на весь проект в целом.
Недостаточная надёжность также является типичным затруднением в процессе проектирования программного обеспечения. Выявление и исправление ошибок одни из самых сложных действий. Так количество ошибок невозможно предугадать, то и определить время, отводимое на их исправление также невозможно предсказать. Гарантировать отсутствие ошибок не представляется возможным. Решением может являться доказательный подход к процессу. Свой вклад в развитие данного подхода внесли такие ученые как Кнут, Дейкстра и Вирт. Доказательный подход позволяет обнаружить ошибки в программе до её выполнения.
Обычно такое затруднение появляется, когда разработчики неправильно выбирают средства. Например, при создании сложных программ, использующих средства высокого уровня, с помощью средств низкого уровня. В итоге исходный код программы становится слишком сложным и слабо структурированным.
Неудачный выбор методологии конструирования программ. От выбора необходимой методологии зависят многие показатели программного обеспечения, такие как гибкость, стоимость и функциональность. Так называемые гибкие методологии разработки помогают решить основные проблемы, однако, стоит отметить, что и каскадная модель (waterfall) так же имеет свои преимущества. В некоторых случаях наиболее целесообразным будет применение гибридных методологий в связке Agile + каскадная модель + MSF + RUP и т.
Некоторые разработчики к проблемам относят и отсутствие гарантий качества и надежности программ из-за отсутствия гарантий отсутствия ошибок в программах вплоть до формальной сдачи программ заказчикам.
Однако данное затруднение не является проблемой, относящейся исключительно к разработке ПО. Гарантия качества — это проблема выбора поставщика товара (не продукта).
3 Жизненный цикл программного обеспечения
Известны несколько основных моделей жизненного цикла ПО.
Жизненный цикл программного обеспечения (ПО) – период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации.
Для облегчения проектирования, создания и выпуска качественного программного продукта существуют различные модели жизненного цикла ПО.
Каскадная или водопадная модель (Waterfall model)
При такой модели каждая из фаз проекта проводится единожды, следуя одна за другой. Для того, чтобы начать следующую стадию, необходимо полное завершение предыдущей.
все стадии проекта выполняются в строгой последовательности;
строгость этапов позволяет планировать сроки завершения всех работ и соответствующие ресурсы (денежные и человеческие);
требования остаются неизменными в течение всего цикла.
сложности при формулировке четких требований и невозможность их изменения;
тестирование начинается только с середины развития проекта;
до завершения процесса разработки пользователи не могут убедиться, качествен ли разрабатываемый продукт.
Рисунок 1. 1 Каскадная модель
V-образная модель (V-model)
Суть этой модели состоит в том, что процессы на всех этапах контролируются, чтобы убедиться в возможности перехода на следующий уровень. Уже на стадии написания требований начинается процесс тестирования.
минимизация рисков и устранение потенциальных проблем за счет того, что тестирование появляется на самых ранних стадиях;
усовершенствованный тайм-менеджмент.
невозможность адаптироваться к измененным требованиям заказчика;
длительное время разработки (иногда длится до нескольких лет) приводит к тому, что продукт может быть уже не нужен заказчику, поскольку его потребности меняются;
нет действий, направленных на анализ рисков.
Рисунок 1. 2 V-образная модель
Инкрементная модель (Incremental model)
При инкрементной модели (англ. increment – увеличение, приращение) программное обеспечение разрабатывается с линейной последовательностью стадий, но в несколько инкрементов (версий). Таким образом улучшение продукта проходит запланировано все время пока жизненный цикл разработки ПО не завершится.
Требования к системе определяются в самом начале работы, после чего процесс разработки проводится в виде последовательности версий, каждая из которых является законченным и работоспособным продуктом.
заказчик может дать свой отзыв касательно каждой версии продукта;
есть возможность пересмотреть риски, которые связаны с затратами и соблюдением графика;
привыкание заказчика к новой технологии происходит постепенно.
функциональная система должна быть полностью определена в начале жизненного цикла для выделения итераций;
при постоянных изменениях структура системы может быть нарушена;
сроки сдачи системы могут быть затянуты из-за ограниченности ресурсов (исполнители, финансы).
Рисунок 1. 3 Инкрементная модель модель
Спиральная модель (Spiral model)
управлению рисками уделяется особое внимание;
дополнительные функции могут быть добавлены на поздних этапах;
есть возможность гибкого проектирования.
оценка рисков на каждом этапе является довольно затратной;
постоянные отзывы и реакция заказчика может провоцировать все новые и новые итерации, которые могут приводить к временному затягиванию разработки продукта;
более применима для больших проектов.
Рисунок 1. 4 Спиральная модель
Гибкая модель (Agile model)
Представляет собой совокупность различных подходов к разработке ПО. Включает серии подходов к разработке программного обеспечения, ориентированных на использование итеративной разработки (в Scrum итерации называются спринтами), динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля. Отдельная итерация представляет собой миниатюрный программный проект. Одной из основных идей Agile является взаимодействие внутри команды и с заказчиком лицом к лицу.
быстрое принятие решений за счет постоянных коммуникаций;
облегченная работа с документацией.
большое количество митингов и бесед, что может увеличить время разработки продукта;
сложно планировать процессы, так как требования постоянно меняются;
редко используется для реализации больших проектов.
Рисунок 1. 5 Гибкая модель
Скрам – это гибкая модель разработки ПО, в которой делается акцент на качественном контроле процесса разработки.
Роли в методологии (Scrum Master, Product Owner, Team) позволяют четко распределить обязанности в процессе разработки. За успех Scrum в проекте отвечает Scrum Master и является связующим звеном между менеджментом и командой. За разработку продукта отвечает Product Owner, который также ставит задачи и принимает окончательные решения для команды.
Команда – это единое целое, в ней результаты оцениваются не по каждому отдельному участнику, а по тому, что получается в итоге у всех. Спринты в данной методологии длятся от 1 до 4 недель. После каждого спринта команда предоставляет вариант законченного продукта.
быстрая обратная связь от специалистов в разных сферах (дизайнеров, архитекторов, тестировщиков и пр
благодаря вовлеченности тестировщика в работу происходит быстрое добавление нового функционала и быстрый запуск продукта с минимальными функциями;
самостоятельная и самоорганизованная команда.
некоторые люди, знающие продукт, становятся незаменимыми, так как документация не предоставляется в процессе разработки;
невозможно спланировать точную дату завершения, так как всё уточняется по результатам предыдущего спринта;
заказчики не всегда могут понять суть данной методологии и необходимо потратить время на “ликбез”.
Рисунок 1. 6 Скрам (Scrum)
4 Стандарты жизненного цикла ПО
Существует целый ряд стандартов, регламентирующих ЖЦ ПО, а в некоторых случаях и процессы разработки.
Среди наиболее известных стандартов можно выделить следующие:
ГОСТ 34. 601-90 — распространяется на автоматизированные системы и устанавливает стадии и этапы их создания. Кроме того, в стандарте содержится описание содержания работ на каждом этапе. Стадии и этапы работы, закрепленные в стандарте, в большей степени соответствуют каскадной модели жизненного цикла.
ISO/IEC 12207:1995 — стандарт на процессы и организацию жизненного цикла. Распространяется на все виды заказного ПО. Стандарт не содержит описания фаз, стадий и этапов.
CustomDevelopmentMethod(методика Oracle) по разработке прикладных информационных систем — технологический материал, детализированный до уровня заготовок проектных документов, рассчитанных на использование в проектах с применением Oracle. Применяется CDM для классической модели ЖЦ (предусмотрены все работы/задачи и этапы), а также для технологий «быстрой разработки» (Fast Track) или «облегченного подхода», рекомендуемых в случае малых проектов.
RationalUnifiedProcess(RUP)предлагает итеративную модель разработки, включающую четыре фазы: начало, исследование, построение и внедрение. Каждая фаза может быть разбита на этапы (итерации), в результате которых выпускается версия для внутреннего или внешнего использования. Прохождение через четыре основные фазы называется циклом разработки, каждый цикл завершается генерацией версии системы. Если после этого работа над проектом не прекращается, то полученный продукт продолжает развиваться и снова минует те же фазы. Суть работы в рамках RUP — это создание и сопровождение моделей на базе UML.
MicrosoftSolutionFramework(MSF)сходна с RUP, так же включает четыре фазы: анализ, проектирование, разработка, стабилизация, является итерационной, предполагает использование объектно-ориентированного моделирования. MSF в сравнении с RUP в большей степени ориентирована на разработку бизнес- приложений.
ExtremeProgramming(XP). Экстремальное программирование (самая новая среди рассматриваемых методологий) сформировалось в 1996 году. В основе методологии командная работа, эффективная коммуникация между заказчиком и исполнителем в течение всего проекта по разработке ИС, а разработка ведется с использованием последовательно дорабатываемых прототипов.
Понятие программы
Компьютерная программа – это последовательность инструкций, которая предназначена для исполнения вычислительной машиной. Образ программы, чаще всего, хранится в памяти машины (например, на диске) как исполняемый модуль (один или несколько файлов). Из образа на диске с помощью специального программного загрузчика может быть построена исполняемая программа уже в оперативной памяти машины.
Термин «компьютерная программа» в зависимости от своего контекста, может применяться также к исходным текстам (или кодам) программы. Их примеры могут быть просмотрены в специальных каталогах исходников. Вместе с правилами и процедурами, а также с документацией по функционированию программных систем обработки данных, компьютерные программы составляют понятие программного обеспечения.
В системном программировании имеет место более формальное определение программы как машинных кодов и данных, загруженных в оперативную память компьютера, и исполняемых процессором машины для достижения поставленной цели. В этом определении подчеркиваются две особенности компьютерной программы: нахождение ее в памяти и исполнение процессором машины.
Процесс поиска ошибок в программах и их исправления называется отладкой программ. Обычно, заранее неизвестно, сколько ошибок содержит программа. По этой причине заранее неизвестна и продолжительность отладки программ.
Программы с исходными текстами, доступными для прочтения и изменения любым желающим, называются открытыми программами. Любая компьютерная программа является объектом авторского права. Авторы или собственники программ имеют право ограничивать и даже полностью закрывать доступ к их исходным текстам, которые являются интеллектуальной собственностью правообладателей.