Сегодня на специальном брифинге для журналистов в министерстве внутренних дел Украины премьер-министр Арсений Яценюк совместно с министром МВД Арсеном Аваковым объявил о создании отдельного Департамента киберполиции, которое будет заниматься проблемами информационной безопасности в стране. Структурно новое подразделение будет частью Национальной полиции и будет насчитывать 400 человек: среди них будет 187 инспекторов и 39 специальных агентов информационных технологий.
Читать полностью »
Рубрика «требования» - 3
МВД Украины озвучило требования к сотрудникам киберполиции и их зарплату
2015-10-15 в 16:20, admin, рубрики: инспектор, информационная безопасность, киберполиция, мвд, требованияУ нас же есть техническое задание на систему – сайт – приложение – проект…
2015-08-17 в 13:24, admin, рубрики: техническое задание, требования, требования заказчика, требования к системе, Управление продуктом, управление проектамиСитуация
- На входе в студию клиент (виртуально / реально не важно).
- Клиент хочет что-то заказать у нас — систему, сайт, приложение, аппу, что угодно — все что можно разработать и даже потом скрестить бульдога с муровьедом например (1С битрикс, просто 1С, другие системы и наша разработка).
- Высылает он нам нечто (как мы это видим), называя это «тз» (как он это видит) и говорит — оценить / посчитать / задать вопросы и далее везде, ожидая в ответ как правило получить вполне конкретную точную цифру и срок (беру пример крайней клиники) когда это будет готово.
- Ждет.
За годы работы я пришел к работающей конструкции в данной части воронки моих продаж — я всегда отвечаю на такие письма — отлично, получил, я вижу ваши пожелания к решениям в письме и, а тз вы забыли приложить?
В такой конструкции диалог не выглядит слишком агрессивным и всегда случается плавный переход в следующий шаг воронки — позитивный диалог что такое тз и что там должно быть, что еще необходимо изложить именно клиенту, а особенно что не нужно излагать клиенту, а делать это должны мы.
От проблемы к требованиям. Теория принятия решений в разработке ПО
2015-02-12 в 18:56, admin, рубрики: анализ требований, аналитика проекта, менеджмент в IT, разработка программного обеспечения, требования, требования заказчика, Управление продуктомВведение
Некоторое время назад обратил свое внимание на артефакт Концепция продукта (product vision) методологии разработки программного обеcпечения RUP (Rational Unified Process) и обнаружил, что отправной точкой разработки программного продукта является выявление проблемы, на решение которой нацелен продукт.
Аналогичный подход существует и в отечественной практике – так в ГОСТ 34.601-90 говорится, что на стадии Формирование требований к АС (автоматизированной системе) производится «выявление проблем, решение которых возможно средствами автоматизации».
В настоящей статье хочу поделиться с читателями своими выводами касательно природы проблемы, ее важности и отношении к разработке программного продукта.
Читать полностью »
Пример написания функциональных требований к Enterprise-системе
2014-12-11 в 14:05, admin, рубрики: ERP-системы, Анализ и проектирование систем, проектирование, разработка, системный анализ, требованияНедавно мой друг, программист, рассказал, что он не читает требования, а вместо этого приглашает аналитика на чашку чая, они вместе садятся, и аналитик рассказывает, что должно быть реализовано. Мой друг — умный человек и хороший программист, и причина, почему он получает знания о требованиях именно так, не в том, что ему лень читать документацию, а в том, что, даже прочитав ее, он до конца не разберется, что же надо сделать. В данной статье я хочу рассказать, как можно написать требования к программному продукту так, что программисты не просто используют требования, но и участвуют в их написании; на основе собственно опыта я хочу показать, каким образом можно описать требования, чтобы эти описания были достаточными для реализации системы.
Целью нашей разработки было создание с нуля учетной системы для одной из крупных российских компаний. Система была призвана заменить текущую, написанную в конце 90-х. В результате были реализованы платформа и один из бизнес-модулей. В реализованной части было порядка 120 объектов, 180 таблиц, около 30 печатных форм.
Хочу оговориться, что подход, описанный ниже, не универсален для написания любого ПО. Он подходит для систем уровня предприятия, которые строятся на основе объектно-ориентированного подхода: учетных, CRM-, ERP-систем, систем документооборота и т.п.
Вся документация на наш программный продукт состояла из следующих разделов:
- Общая часть
• Список терминов и определений
• Описание бизнес-ролей - Требования
• Бизнес-требования- Общие сценарии
- Сценарии использования
- Алгоритмы и проверки
• Системные требования
• Нефункциональные требования
• Требования к интеграции
• Требования к пользовательскому интерфейсу - Реализация
- Тестирование
- Руководства
- Управление
Starban. Гибкая методология разработки, геймификация и еще много модных слов
2014-10-15 в 10:46, admin, рубрики: agile, scrum, геймификация, гибкое управление, разработка по, требования, управление проектами, метки: разработка поПоскольку пост некороткий и даже неуместные картинки не делают его чтение легче, то давайте первым делом обозначим целевую аудиторию.
- Вы разработчик ПО, руководитель группы разработки, менеджер проекта или его эквивалент.
- Над проектом работает больше одного программиста, желательно — больше трех.
- Вы пробовали все эти скрамы и эджайлы, почувствовали их прелесть, но есть определенные нарекания к догматическому следованию методологии. Возможно, у вас никто не занимается постановкой процессов совсем и задачи просто «накидываются».
- Команда устала (от проекта, от стресса, ...) и в скором времени всех ждут кнуты и пряники.
Хорошо, есть методология, которая выдумана командой программистов «для себя», но которую, по нашему мнению, будет интересно попробовать и другим. Внутри команды воссоздаётся небольшая экономическая модель рыночных отношений, а приоритеты регулируются при помощи курса внутрикомандной валюты. Читать полностью »
Уровни зрелости процесса управления требованиями
2014-10-15 в 6:04, admin, рубрики: разработка, требования, управление проектами, уровень зрелостиОт меня: Наблюдая за проектами разработки программного обеспечения в компаниях разного масштаба я утвердился в мысли, что требования – это основа успешности. Если компания или проектная команда не уделяет времени выявлению и управлению требованиями к разрабатываемому ими программному продукту, то качество выпускаемого продукта будет неизбежно снижается, и долго оставаться конкурентоспособной на рынке такая организация не сможет. Несмотря на это, у большинства руководителей проектов имеется крайне поверхностное понимание роли требований в процессе разработки программного обеспечения, а то и вовсе отсутствует.
Работая над статьей о роли требований в процессе разработки программного обеспечения я обнаружил шкалу уровней зрелости процесса управления требованиями (requirements management maturity), предложенную в 2003 году одним из специалистов по работе с требованиями Rational Software Джимом Хьюманном (Jim Heumann).
Хочу поделиться с читателями habrahabr данной классификацией.
Введение
Термин «зрелость» – определяется как полное, состоявшееся развитие той или иной системы. Так как любое развитие требует затрат, в контексте бизнеса это означает, что организация принимает решение об объемах инвестиций в собственное развитие, четко понимая какие выгоды она при этом получает.
Ниже приведена шкала уровней зрелости процесса управления требованиями, построенная по аналогии с моделью CMMI. Эти модели никак не связаны между собой, но имеют некоторое пересечение. Так, достижение уровня 5 (Интеграция требований) зрелости процесса управления требованиями позволит получить как минимум уровень 3 (Процессы определены на уровне всей организации) по модели CMMI. Однако это не является прямым следствием, так как достижение высокого уровня зрелости в одном процессе не гарантирует общего повышения зрелости организации в целом.
Читать полностью »
Нефункциональные требования к программному обеспечению. Часть 1
2014-08-01 в 15:33, admin, рубрики: Анализ и проектирование систем, нефункциональные требования, требованияВведение
Разрабатывая новую информационную систему или внедряя уже существующую, вы неизбежно сталкиваетесь с необходимостью определить нефункциональные требования к вашей системе.
В этой статье я расскажу о следующем:
- какими бывают нефункциональные требования,
- как определять нефункциональные требования,
- откуда берутся численные значения для нефункциональных требований.
Планирование сроков и бюджетов для фрилансера
2013-10-23 в 14:07, admin, рубрики: бизнес студии, деньги, продажи, студия, требования, фриланс, метки: деньги, продажи, студия, требования, фриланс Вот уже почти три месяца я уволился из офиса и работаю на «вольных хлебах». «Халтуры» попадались и до этого, но я не брал более одного проекта и делал лишь то, что входило в мою широкую, но не безграничную область компетенции.
Я занимаюсь «программированием под ключ» и считаю себя μISV. Специализируюсь на проектах, требующих смежной компетенции, обычно я работаю с заказчиками долго — по нескольку лет. Я за то, чтобы исполнитель и заказчик работали вместе и помогали друг-другу найти оптимальное видение проекта. Мой процесс разработки выглядит так:Читать полностью »
Требования для программного обеспечения: Рекомендации по сбору и документированию
2013-03-04 в 11:27, admin, рубрики: Блог компании Издательский дом «Питер», Оценка и экспертиза IT-проектов, требования, Читальный зал, метки: требованияСегодня мы хотит предложить вашему вниманию книгу Ильи Корнипаева «Требования для программного обеспечения: Рекомендации по сбору и документированию», которая готовится к выходу в нашем издательстве.
Аннотация
Эта книга о том, как собирать, документировать и проверять требования. Она рассчитана на самый широкий круг читателей: начинающих аналитиков, проектировщиков, архитекторов, разработчиков, тестировщиков, руководителей проектов, и других специалистов задействован в проектах по разработке ПО на ранних стадиях.
Читатель, независимо от того работает ли он на стороне компании разработчика, является или он представителям заказчика, или работает в ИТ-отделе компании, не связанной с разработкой ПО, может найти в книге полезные для себя советы и рекомендации.
Книга написана на основе более чем пятнадцатилетнего опыта автора, а также по материалам авторских курсов по разработке и управлению требованиями.
Читать полностью »
Больше, чем plain vanilla scrum. Общепринятые практики работы с требованиями
2013-02-26 в 9:39, admin, рубрики: agile, Блог компании «SCRUMguides», скрам, требования, управление проектами, метки: скрам, требованияНедавно, на Скрам портале была опубликована статья Майка Кона об Общепринятых практиках в Скраме — практиках, которые довольно часто встречаются в Скрам-проектах, но не являются базовыми правилами Скрам.
Скрам поощряет подобные добавления и специально построен минималистично, дабы команды могли добавить то, что им по вкусу. Не стоит путать подобные улучшения процесса с печально известным Скрам-ном. В отличие от последнего, добавленные практики улучшают процесс, повышая эффективность выпуска продуктов и выравнивая поток работ.
Сегодня я хочу поделиться множеством таких практик, собранных вокруг работы с требованиями. За последние несколько лет перечисленные практики мне не раз довелось наблюдать за кулисами у успешных команд в роли agile-коуча и рассказывать о них на тренингах Certified ScrumMaster в роли скрам-тренера.
Я ни в коем случае не претендую на полноту практик и буду рад услышать дополнения. Некоторые из перечисленных практик заслуживают отдельных статей — это work in progress.