- Что делать, если все пропало
- Возможно, вас также заинтересует:
- Генеральная репетиция
- Замечания
- Какие проверки входят в программу и методику испытаний?
- Назначение программы и методики испытаний
- Направления троллинга в ходе испытаний
- Пми программа и методика испытаний
- Подготовка к поступлению
- Программа и методика испытаний
- Протокол испытаний
- Процесс пошел!
- Стандарты для программы и методики испытаний
- Стоимость разработки программы и методики испытаний
- Эффективный дуэт
- Заключение
Что делать, если все пропало
Когда вы понимаете, что испытания идут неудовлетворительно, система безобразно глючит, а заказчик уже исчерпал запас ругательств, не нужно сдаваться! Караван должен продолжать идти вперед, будет новый релиз, новые испытания. И даже если проект будет завален, ничего в этом страшного для вас нет.
Чтобы не терять время в бесплотных препирательствах, я бы рекомендовал применить тактику «бей своих, чтобы чужие боялись». Начните вместе с заказчиком ругать «этих криворуких программеров», «жадное руководство», а когда накал страстей уменьшится, предложите заказчику собрать максимум багов «этого глюкалова», чтобы показать этим нехорошим людям какие они нехорошие.
Тогда активные сотрудники заказчика во главе с троллем-киллером начнут собирать баги и радостно наполнять протокол сотнями замечаний. Фактически, за свои собственные деньги они проведут вам высокоуровневое функциональное тестирование, на которое, судя по результатам испытаний, ваши разработчики так и не сподобились.
По хорошему, описанной безобразной ситуации вообще быть не должно. Но проектный бизнес отличается иногда странными флуктуациями, когда первый прототип пытаются сдать как полноценную систему, начальство врет подчиненным и самим себе, все вокруг делают хорошую мину при плохой игре и уверяют друг друга в обязательном и непременном успехе.
Вторым советом в подобной ситуации было бы, как я уже говорил, сразу уволиться из конторы, допускающей подобные «косяки». Потому что по всем меркам настоящему профессионалу не стоит портить свою репутацию подобным образом.
Возможно, вас также заинтересует:
– создание пояснительной записки к эскизному и техническому проекту;– разработка технического задания;– этапы разработки документации.
Генеральная репетиция
Без нее нельзя. Только так вы можете отловить все шероховатости в тестах, выявить тесты, крадущие время и тесты, результаты которых сомнительны. Помните, что визуальная составляющая должна быть безупречна. Постарайтесь забить в систему данные, которые выглядят натурально и похожи на то, с чем имеет дело клиент.
Не бойтесь переписать ПМИ с нуля. Один раз мы пожалели время и перекомпоновали тесты вместо того, чтобы переписать их. В итоге мы просто успокоили сами себя, не изменив общей плачевной картины. За что и огребли.
Если вы сдаете вдвоем, гоняйте тесты вместе. Приглашайте коллег, пусть они придираются, изображая из себя комиссию. Потраченное на эти игры время в итоге позволит всем вам получить деньги от довольного заказчика.
Замечания
Они будут, можете не сомневаться. Нет такой системы, к которой не было бы замечаний. Ваша задача — заставить заказчика поделить все замечания на критические и не критические. Первые должны быть исправлены для успешного перевода в опытную эксплуатацию.
Когда заказчик делает замечание, вы фиксируете его формулировку в протоколе. Обязательно проговорите записанные слова, убедитесь, что вы друг друга поняли. Будет лучше, если в ходе испытаний будет работать диктофон. Постарайтесь сделать так, чтобы формулировка замечания была конструктивной, то есть, было понятно, что нужно сделать, чтобы замечание было снято.
Слов «все», «ничего», «каждый», «любой», а также неизмеряемых качественных оценок «плохо», «медленно», «слишком быстро» и т.п. в замечании быть не должно! Если «система работает медленно», то должно быть написано «запрошенная форма должна отображаться в течении 5 сек». Если «символы на схеме плохо различимы», то должно быть написано «увеличить символы на схеме до 18 пунктов». И так далее.
Конкретизация позволит минимизировать возможность необоснованного перетаскивания того или иного замечания в ранг критического. Заказчик может утверждать, что отработка запроса за 6 секунд для него неприемлема, а за 5 секунд — в самый раз. Пусть это появится в протоколе! Но что-то мне подсказывает, что не появится. Или замечание будет признано некритическим.
Все замечания, признанные критическим фиксируются в акте: «Комиссия постановила, что система соответствует ТЗ и рекомендует принять ее в опытную эксплуатацию при условиях отработки следующих замечаний:…» При этом список некритических замечаний лучше непосредственно в акт не включать.
Их обычно много и они могут напугать ответственного сотрудника, ставящего подпись. Если заказчик беспокоится, что вы не будете отрабатывать некритические замечания, успокойте его при помощи документа «Методика проведения опытной эксплуатации», котрый настоятельно рекомендуется подготовить.
Там вы в простой и доступной форме должны описать как будет проходить опытная эксплуатация, как будут отрабатываться найденные баги и как будет заполняться журнал опытной эксплуатации, являющийся гарантом безболезненного окончания ОЭ, ввода системы в промышленную эксплуатацию и салюта с шампанским по причине окончания проекта.
Какие проверки входят в программу и методику испытаний?
Согласно руководящему документу РД 50-34.698-90, в этом документе перечисляются все проверки, призванные установить эффективность проектных решений, выявить причины отказов или сбоев, определить качество проведенных работ, проверить соответствие АСУ технике безопасности, а также устанавливается продолжительность всех опытов, их режим и прочее.
Программа и методика испытаний содержит перечень необходимых проверок, проводимых во время испытаний. К таким проверкам обычно относится:
Назначение программы и методики испытаний
После формирования технического предложения и разработки эскизного и технического проектов наступает момент, когда необходимо четко определить, как будет решаться вопрос о соответствии системы всем требованиям, описанным в проектной документации, как будет определяться степень ее надежности, а также, что самое главное, уровень соответствия системы своему назначению. Именно для этого и предназначен документ Программа и методика испытаний (ПМИ).
Направления троллинга в ходе испытаний
Вы не представляете, сколько людей заинтересовано в вашем провале! Кто-то хочет доказать свою правоту насчет ваших умственных способностей, кто-то хочет оттянуть сроки, кто-то мечтает о штрафных санкциях, кому-то нужно новую резину на BMW… В подобных случаях в комиссию подсадят тролля-киллера (см. первый пост). На данном этапе есть три направления троллинга, с которыми приходится иметь дело:
- Формальная приемка. Тролль тыкает в ТЗ, где написано что-то вроде этого: «система должна иметь архитектуру клиент-сервер». Вам требуется показать, как пункт закрывается. А вы забыли включить в пояснительную записку к техпроекту строчку «Система имеет архитектуру клиент-сервер» или с перепугу не смогли ее найти. Потратьте время, прочешите все разделы ТЗ и найдите нужные строчки.
- Ошибки в тестах. При формулировании тестов избегайте возможности намеренного неверного истолкования. Например, вы пишете, «Из списка пользователей Оператор выбирает любого пользователя». Тролль выберет из списка системного юзера или админа, под которыми тесты работать не будут. Или вы пишете «Отобразились свойства всех объектов». Тролль ткнет в тот объект, свойства которого не отобразились. А вы имели в виду «всех требуемых объектов», но поезд ушел, и вы получаете страшное замечание «Свойства всех объектов не отображаются».
- «Крайне важные замечания». Когда пушки основного боя отгремели, начинается разбор замечаний на критические и не критические. Критические будут у вас костью в горле, они мешают подписанию акта. Поэтому тролль будет пытаться сделать каждое замечание критическим. Включается весь имеющийся пафос, привлекаются авторитетные товарищи, кивающие головами, и прочий цирк с конями.
А теперь рассмотрим то, что нам потребуется, чтобы избежать описанных неприятностей при сдаче работ.
Пми программа и методика испытаний
Программы и методика испытаний – это документ, который обязательно должен входить в комплект конструкторской документации. Данная документация составляется на систему либо программу на этапе разработок. Методика испытаний требуется, чтобы установить нужные в этом случае сведения, которые подлежали проверке во время организации испытаний полностью всей системы или же каких-либо отдельных ее частей. Данным документом устанавливается порядок организации проведения необходимых в этом случае тестов, а также способы по контролю полученных результатов.
Каков порядок и какие проверки включают в методику испытаний?
В соответствии с РД 50-34.698-90, в этом документе (а именно — в методиках испытания) указываются все необходимые проверки, которые нужны для того, чтобы понять насколько проектные решения работают, а при наличии сбоев, выявить их причину, определить качество работ, а также проконтролировать на соответствие АСУ ТБ. Кроме того, благодаря данному документу можно определить длительность проведения всех необходимых опытов, а также режим и т.д.
Программы и методики испытаний содержат в себе исчерпывающий перечень проверок, которые должны быть организованы специалистами и проведены во время испытаний. К проводимым специалистами проверкам обычно относится:
- Контроль на соответствие ТЗ (технического задания);
- Проверка качества, необходимой в этих случаях документации. Кроме того, требуется осуществить проверку и на комплектность;
- На комплектность с-мы;
- Проверка сотрудников, которые будут осуществлять обслуживание, наличие необходимой квалификации;
- Установление полноты, а также надлежащего качества программной поддержки и документации, которая для нее требуется;
- Проверка соответствия требованиям, касающимся функционального назначения с-мы;
- Проверка нарушений в области ТБ (техники безопасности);
- Проверка на приспособленность системы к контрольным мероприятиям;
- Проверка с-мы на сочетание с другими компонентами и средствами.
В некоторых случаях может потребоваться провести дополнительные – необходимость в этом устанавливается в индивидуальном порядке.
Оформление
Если говорить об оформлении, то согласно ГОСТ 19.301-79, «программа и методика испытаний» должна быть оформлена в соответствии с требованиями ГОСТ 19.105-78, где указаны общие требования, предъявляемые к оформлению необходимых в этом случае программных документов. Так, данный документ в соответствии с требованиями, должен содержать в себе такие разделы как:
- Объект испытаний, с указанием его названия, сферы, где он должен использоваться (применяться), а также обозначения автоматизированных СУ.
- Перечень необходимых для работы приложений. Методики и программы испытаний могут содержать в себе различные дополнительные материалы, в числе которых – необходимые графики, таблицы и т.д. (при этом их количество не ограничено – так, приложений может быть, как 34, так и 134).
- Цель организуемых и проводимых испытаний. Помимо цели, в данном разделе, должен быть указан перечень сведений, которые должны быть получены в ходе проведения данных опытов и проверок.
- Требования, выдвигаемые к программной документации. Здесь должен быть указан состав необходимых документов. Кроме того, здесь должны быть указаны отдельные требования для испытания данных систем, которые устанавливаются ТЗ.
- Методы организации требующихся испытаний. Описание применяемой в этом случае методологии, с перечислением сведений, которые должны быть взяты в момент проведения испытаний.
- Порядок организации требуемых испытаний, с указанием конкретных программных средств, которые требуется использовать для проведения этих испытаний.
- Требования, выдвигаемые к данной программе. В данном разделе должен быть указан перечень условий, соответствии технического задания, которые должны быть организованы в ходе проведения соответствующих опытов.
Согласно ГОСТ, часть, являющуюся информационной, а именно – содержание, аннотацию и т.д. – на такой документ, испытаний, допускается не оформлять.
Куда обратиться если требуется ПМИ программа и методика испытаний?
Для этого требуется в специализированную организацию, имеющую квалифицированных сотрудников, а также необходимое оборудование и техническое обеспечение. Кроме того, перед обращением требуется убедиться, что сотрудники компании, имеют достаточный опыт – в противном случае, велик риск получения документа, содержащего в себе ошибки и неточности, что может повлечь за собой достаточно серьезные последствия в ходе проведения испытания. Кроме того, серьезные последствия могут быть в случае, если будет нарушен порядок при испытаниях (проведения испытаний).
Наша организация специализируется на предоставлении услуг в области разработки документации на ПО, а также на системы управления. Воспользовавшись нашими услугами, вы можете быть уверены, что составление данных документов будет организовано в максимально короткие сроки, с учетом всех установленных требований.
В нашей команде работают специалисты, которые досконально знают все действующие условия для оформления программ и методик испытания, а также иных требующихся документов, необходимых в этом случае.
Сроки, в течении которых будет разработана ПМИ программа и методика испытаний ГОСТ?
Сроки разработки документации для проведения испытания (ПМИ) устанавливаются в индивидуальном порядке т.к. все зависит от требований заказчика. Для того, чтобы узнать точную стоимость необходимо обратиться в компанию, специализирующуюся на предоставлении данного вида услуг, специалисты которой обозначат точные сроки.
Для разработки документов, вам требуется связаться с нашими специалистами, направив заявку, заполненную через наш сайт, или связавшись любым другим удобным способом. После поступления заявки, наши сотрудники свяжутся с вами в максимально короткие сроки для уточнения необходимых деталей (порядок, требования и т.д.). После уточнения н необходимых деталей, мы предоставим перечень необходимых документов, которые нам потребуются. Когда эти документы будут предоставлены, между сторонами будет заключен договор. Далее мы приступим к совершению мероприятий, необходимых для выполнения поставленной задачи. После выполнения всех необходимых мероприятий технического плана и проверки, мы предоставим полный комплект документации, после чего вы сможете распоряжаться ей по своему усмотрению.
Если у вас остались вопросы, вы можете связаться с нами любым из способов, указанных на сайте – по телефону, электронной почте или же лично подъехав в наше представительство. Для получения более точной консультации большинство организаций выбирают именно личное посещение т.к. у специалистов появляется возможность ознакомиться с документами и дать более полный ответ.
Подготовка к поступлению
Первым делом любому абитуриенту нужно полностью убедиться, что компьютерные науки, прикладная математика и программирование, это то, чем он хочет заниматься в жизни. Для этого можно порекомендовать посмотреть лекции Малого ШАД Яндекса.
Поступление на программу “Прикладная математика и информатика” по большей части ведется по результатам олимпиад по математике и по информатике. Список олимпиад школьников, победителям и призерам которых предоставляются особые права при поступлении на программу ПМИ в 2020, можно посмотреть в выложенном документе на сайте Абитуриентам бакалавриата.
.jpg)
Для подготовки к олимпиадам очень полезны дополнительные занятия, такие как Летняя компьютерная школа (ЛКШ), Летняя школа по компьютерным наукам, Летний компьютерный лагерь, Лицей Академии Яндекса илиМосковская Школа Программистов.
Желающим как следует подготовиться к занятиям на факультете рекомендуется изучить онлайн курсы Основы программирования на Python и Введение в программирование (С ). Множество полезных материалов для дистанционной подготовки по программированию можно найти на сайте МЦНМО.
Программа и методика испытаний
Документ ПМИ, или программа и методика испытаний, на мой взгляд, более важен, чем даже ТЗ. От качества этого документа зависит половина, если не две третьих успеха испытаний.
Протокол испытаний
На основе тестов ПМИ вы должны подготовить протокол испытаний. Протокол будет являться документом, подтверждающим то, что ваша система выполнена в соответствии с ТЗ, о чем делается соответствующая запись в акте. Не доверяйте подготовку протокола никому другому, если не хотите иметь бледный вид перед комиссией. Обычно протокол является «копипастом» из ПМИ, так что его подготовка много времени у вас не займет.
Протокол испытаний состоит из общей части, таблицы тестов и списка замечаний.
Таблица, в которую заносятся результаты тестов, может состоять из следующих колонок:
Процесс пошел!
Когда вы приступили к испытаниям, не смейте лезть в систему сразу! Постарайтесь пройти сначала всю формальную часть. Сверьте коды документации, носителей информации, откройте ТЗ, положите на стол Руководство пользователя. Пройдитесь по нефункциональным требованиям.
ОС Windows — галочка. Поддерживаемые версии браузеров — раз, два, три, галочка. Язык разработки, архитектура, база данных, да мало ли что там в ТЗ понаписано! Все нужно показать в документации. Хотя бы там всего лишь одно предложение, оно обязано там быть!
Не пренебрегайте этой бюрократией, тролли только этого и ждут. Вам хочется получить в протоколе, что «Исполнитель не продемонстрировал, что язык java является кроссплатформенным языком высокого уровня. Требования ТЗ 1.2.3 и 3.2.1 не выполнены»? А ведь это не придуманный маразм, это сама жизнь.
Когда вы закончили с формальной стороной дела, тоже не спешите лезть в систему! Следующая группа тестов заключается во включении монитора и демонстрации рабочего стола, иконок и запуска программы (если запуск нужно тестировать). Вход в систему с неправильным паролем, галочка, вход с правильным — опять галочка, галочка, галочка. Меню — эка невидаль! Главная форма, список чего-нибудь. Галочка.
Когда дойдет дело до нажатия кнопок в системе, комиссия уже порядком устанет и проголодается. А вы в первый день сможете проскочить, к примеру, основные справочники и базовые функции. А на другой день оставить бекапирование, администрирование и еще какую-нибудь ерунду.
Стандарты для программы и методики испытаний
Приведенная выше схема документа по ГОСТ 19.301 является обязательной, а в случае использования ГОСТ серии 34 следует применять иную схему в соответствии с РД 50-34.698. Также нельзя забывать и о том, что ПМИ, как и любой другой документ из комплекта проектной документации, должен соответствовать требованиям ГОСТов к оформлению.
Стоимость разработки программы и методики испытаний
ТехРайтКонсалт возьмет на себя разработку ПМИ, и наши специалисты, обладая большим опытом и знаниями как в области проектирования, так и в области тестирования автоматизированных систем, создадут для вас все необходимые документы в срок и по доступной цене. И пусть результаты тестирования всегда будут успешными!
Эффективный дуэт
Оптимальной командой для сдачи является пара из внедренца (или программиста) и бизнес-аналитика (консультанта).
Внедренец (программист):
Аналитик (консультант):
Такая бригада позволит реализовать прием, который можно назвать «передача микрофона». Если программист вдруг наступил на багу, консультант может дать ему подзатыльник и быстро заболтать заказчика, негодуя по поводу чьих-то кривых рук. Эффект будет как в цирке. Заказчик посмеется про себя и тут же подумает, что он-то не клоун и руки-то у него попрямее будут.
Точно так же, если консультант скажет глупость, а заказчик нахмурится в ответ, программист может с лицом оскорбленной невинности продемонстрировать очередную фишку системы и тогда заказчик проникнется к нему симпатией, так как поймет, кто тут настоящий профи, а кто клоун в галстуке.
В особенно напряженные моменты можно устроить дружескую перепалку, разрядив тем самым обстановку и отведя внимание аудитории от не совсем корректной работы системы.
Не зря же западные «айтишные евангелисты» любят работать парами.
Заключение
Итак, коллеги, на этом я спешу завершить трилогию о корпоративных троллях, которых не нужно бояться, а нужно уважать и даже некоторым образом любить, так как они не дают ленивым обезьянам ИТ бизнеса падать от обжорства с деревьев, держат нас в тонусе и даже привносят некоторый интерес в безумно скучные, но крайне необходимые проектные работы.
UPD от 23.06.2022. Пользователь igendo добавляет в комментариях, что неплохо бы уже на этапе заключения договора утвердить формы официальных документов проекта.
Цитирую:
Добавлю, что очень помогает в работе, когда формы актов, протоколов и прочих формальных документов зафиксированы в контракте. Дабы не было необходимости их предварительно согласовывать, пересогласовывать и переделыватьпереподписывать в середине проекта.
От себя тоже могу добавить, что в совсем уж тяжелых и масштабных проектах принято составлять устав проекта, некий документ о глубинном смысле которого можно говорить часами. Там, кроме всего прочего, можно обговорить и формы документов проекта, и процедуры контроля хода проекта, и высокоуровневые бизнес-задачи. Но это, опять же, тема для другого поста.
Пользователь ЖЖ ryzhij_papa Добавляет, что существует практика ранжирования замечаний по степени их влияния на бизнес, методика ранжирования также заносится в ПМИ.
Цитирую:
Нужно формально описать что является замечаниями крического, высокого, среднего и низкого приоритета. Описание делается в терминах бизнеса. Если утрировать, то так: критический приоритет при потере 1000$, высокий если 100$, средний когда сотрудники в мыле, но убытков у нас нет, низкий — возможны случаи легкого умопомрачения на 5-6 году жизни с такой багой…
