Рубрика «формирование требований»

в 20:35, , рубрики: бизнес аналитика, книги, проектирование требования, Профессиональная литература, системный анализ, формирование требований, Читальный зал

В книге описан один метод написания части постановки задачи, а именно метод use case.

Что это такое? Это описание сценария взаимодействия пользователя с системой (или с бизнесом). Система при этом выступает как черный ящик (и это дает возможность разделить сложную задачу проектирования на проектирование взаимодействия и обеспечение этого взаимодействия). При этом вводятся стандарты нотации, что обеспечивает простоту прочтения в том числе не участникам, и позволяет делать некоторые проверки на полноту и соответствие целям стейкхолдера.
Читать полностью »

в 5:02, , рубрики: Анализ и проектирование систем, визуализация данных, менеджмент продукта, Программирование, проектирование, Проектирование и рефакторинг, Промышленное программирование, требования, управление проектами, формирование требований

С частью 4 можно ознакомиться, перейдя по ссылке

VIII Определяем сущности предметной области

Все, что видим мы, — видимость только одна.
Далеко от поверхности мира до дна.
Полагай несущественным явное в мире,
Ибо тайная сущность вещей — не видна
Омар Хайям

Практика формирования требований в ИТ проектах от А до Я. Часть 5. Сущности предметной области. Немного о стратегиях - 1
Определив абстрактные хранилища продукта, мы получаем костяк для построения детальной модели данных. При проектировании структуры сущностей продукта, удобно использовать канонические диаграммы «Сущность-связь» (ERD), логическую диаграмму (Logic Diagram) или диаграмму классов (Class diagram).

Цель этой группы работ — спроектировать модель хранилищ данных для использования в продукте, а также задокументировать сущности системы и способы их взаимодействия.

Теория проектирования такого типа диаграмм детально изложена в литературе, описывающей работу с UML. Например, эта тема очень удачно представлена в [11]. Поэтому остановлюсь лишь на некоторых аспектах, интересных на мой взгляд,.
Читать полностью »

в 11:59, , рубрики: Анализ и проектирование систем, визуализация данных, менеджмент продукта, Программирование, проектирование, Проектирование и рефакторинг, Промышленное программирование, требования, управление проектами, формирование требований

С частью 2 можно ознакомиться, перейдя по ссылке

VI ОПРЕДЕЛЯЕМ ФУНКЦИИ СИСТЕМЫ И ГРАНИЦЫ ПРОЕКТА

Каждая модель ограничена в своих ответах, но нет ограничения на то, как и что моделирует модель, как нет ограничения на человеческую мысль
Дуглас Т. Росс

Практика формирования требований в ИТ проектах от А до Я. Часть 3. Функции системы и Границы проекта - 1

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

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

Границы проекта (project scope) показывают, какая область конечного продукта будет реализована в текущем проекте. Другими словами, определяется черта между тем, что мы будем делать сейчас и тем, что отложим на потом или от чего вообще сможем отказаться. Для этого в арсенале команды должен быть инструмент, позволяющий не просто строить модели создаваемого продукта, а помогающий наглядно очертить рамки автоматизируемых процессов, а также предоставлять возможность легко выносить процессы за границу или включать их обратно. Это очень важно для осознания и более качественного планирования объемов работ. Подобный инструмент полезен не только для «борьбы» с непомерными желаниями заказчика, но и для маневров менеджмента со стороны разработчиков.
Читать полностью »

в 6:05, , рубрики: бизнес-модели, менеджмент проектов, проектирование, требования, Управление продуктом, управление проектами, управление разработкой, формирование требований

С частью 1 можно ознакомиться, перейдя по ссылке

IV ОПРЕДЕЛЯЕМ ЦЕЛИ, ПРОЕКТА

Цель не обязательно должна достигаться. Порой это просто направление двигаться дальше.
Брюс Ли.

Практика формирования требований в ИТ проектах от А до Я. Часть 2. Цели и Потребности - 1

Одним из основных признаков системы, отличающим ее от разрозненных компонентов, является подчиненность всей организации системы — некоторой цели. Проектная работа команды, представляет собой тоже некую систему и соответственно должна «идти на поводу» у какой-то цели. Потому, установив коммуникации между участниками проекта, начнем определять цели, которые мы хотим достичь в результате создания нового продукта.

Цель данной группы работ: определить основные задачи, которые ставят перед собой группы заинтересованных лиц, участвующих в проекте.
Читать полностью »

в 13:24, , рубрики: Анализ и проектирование систем, визуализация данных, менеджмент проектов, Программирование, проектирование, Проектирование и рефакторинг, Промышленное программирование, требования, управление проектами, формирование требований

Пролог

Читая на этой площадке статьи по управлению проектами, часто ощущается рвущаяся наружу боль менеджеров, вызванная неэффективным использованием ресурсов в проекте. А одной из основных причин этих проблем чаще всего называется именно отсутствие качественных заданий на разработку продукта. Проявляться эта беда может в разных симптомах: в виде трудностей с делегированием абстрактных расплывчатых заданий, или взаимного непонимания на совещаниях по решениям, которые имеются только у каждого в голове, при этом представляются они абсолютно по разному и т.п. Читая об этом в сознании живо проносятся картинки из своей собственной практики. И вот Вы уже напряжены и пытаетесь быстрее перейти от симптомов к рецептам избавления от этой головной боли. И что же мы чаще всего можем увидеть? А дальше, как правило, идут оптимистические и решительные, лозунги — готовьте правильно задачи исполнителям, не надейтесь, что они быстро сами во всем разберутся, до всего догадаются или им внезапно придет озарение. Подождите! А как это сделать? Авторы, подняв проблему, почему-то поиски ее решения оставляют для самостоятельной работы читателя. А ведь это самое интересное и сложное.

В своей статье «О качестве требований в ИТ проектах, начистоту (с позиции команды разработки)», я попытался более конкретно подойти к решению этих проблем и рассказал на своем опыте, как можно преобразовать собранные требования для автоматизации в ИТ проекте так, чтобы максимально повысить результативность команды, воплощающую их в целевой продукт. Повысить именно за счет качественно сформулированных заданий на разработку продукта, покрывающую весь процесс.

Теперь я хочу рассказать, как можно качественно сформировать сами требования, ведя Заказчика от его «хотелок», к его счастливому и плодотворному сожительству с программным продуктом, его мечты.
Читать полностью »

в 5:40, , рубрики: виртландия, виртуальная реальность, Исследования и прогнозы в IT, реальность, социальные проекты, Учебный процесс в IT, формирование требований, Читальный зал

I ВСТУПЛЕНИЕ

У того, кто никогда не меняет взглядов, обычно нет никаких взглядов.
Альберто Моравиа.

Долгое время, проработав системным аналитиком в ИТ отрасли, я стал подмечать, что теперь по другому воспринимаю фильмы, так или иначе затрагивающие тему Виртуальной реальности («Матрица», «Начало», «Иллюзия обмана» и другие). Я ловлю себя на мысли, что пытаюсь систематизировать информацию, охарактеризовать суть и форму явлений, разложить сложные понятия на простые и представить, как это все используется в повседневной жизни. Я сейчас не имею в виду компьютерные технологии: шлемы, сенсорное обмундирование и т.п. Все что находится снаружи, не вызывает споров и неоднозначности, занятно обсудить что же там происходит внутри.

Чтобы как-то разобраться с этой навязчивой манией, я решил систематизировать и изложить свои размышления о явлении Виртуальной реальности, Измененном сознании и иже с ними, на бумаге и представить их в данной статье.

С другой стороны эта публикация является логическим продолжением моих статей «Где логика? Учимся мыслить системно» и «Социальный Организм — как форма эффективного взаимодействия команды», в которых я стараюсь популяризировать системное мышление в повседневной жизни, в быту и профессиональной деятельности.

Если Вы хотите об этом поговорить, тогда Вам сюда… Надеюсь, что будет увлекательно и не скучно.
Читать полностью »

в 7:13, , рубрики: Анализ и проектирование систем, оптимизация, Проектирование и рефакторинг, проектирование по, Промышленное программирование, разработка по, Тестирование IT-систем, тестирование по, управление проектами, формирование требований, функциональное программирование

С частью 1 можно ознакомиться, перейдя по ссылке
С частью 2 можно ознакомиться, перейдя по ссылке

Использование спецификаций требований в управлении проектом

Во вступительной части была упомянута группа участников проекта, для которой мы так же обещали облегчить жизнь и обеспечить условия для эффективного использования требований – это менеджеры проекта. Что получают эти глубокоуважаемые люди при выборе предлагаемого в статье подхода?

Планируя работы по таким детальным спецификациям, еще на ранних стадиях, можно с высокой точностью определить ресурсы и сроки, необходимые для их реализации. Время, которое необходимо затратить на создание Таблицы, Формы, Функции, Отчета и т.д. можно просчитать на примере одного проекта и в дальнейшем использовать эти данные как эталонные. А в наших спецификациях, как раз и перечислены все таблицы, формы, процедуры и т.д. и сосчитать их количество не составляет труда.

Но, естественно есть погрешности и процедура – процедуре рознь, поэтому, для более точного расчета можно использовать коэффициенты сложности для реализуемых объектов. Например, «сложная форма» — 1,5; «обычная форма» — 1; «простая форма» — 0,5. Для каждого типа элемента подбираем свою линейку значений коэффициентов. Полученные таким образом данные можно занести в электронную таблицу и сбить итоговые затраты в человекоднях или человекочасах (как Вам удобнее) по подсистемам и проекту в целом.
Читать полностью »

в 10:50, , рубрики: Анализ и проектирование систем, оптимизация, Проектирование и рефакторинг, Промышленное программирование, разработка программного обеспечения, Тестирование IT-систем, требования, управление проектами, формирование требований, функциональное программирование

С частью 1 можно ознакомиться, перейдя по ссылке

Рекомендации по проектированию спецификаций требований с примерами

То, о чем не говорят, каждый понимает по-своему

Как и было анонсировано в предыдущих разделах, мы постараемся преобразовать требования на разработку ПО в такой формат, чтобы они максимально упростили и ускорили работу команды превращающую их в конечный продукт.

Готовим читателей к знакомству со спецификациями

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

Пример обзора документа:
О качестве требований в ИТ проектах, на чистоту (с позиции команды разработки). Часть 2 - 1

Для лучшего восприятия контекста разрабатываемой системы, помимо разделов, отобранных нами в структуру документа — как обязательные, я стараюсь включить в текст информацию о целях, которые должны быть достигнуты в результате разработки целевого продукта или его составного модуля. Разработчики все-таки должны осознавать, чего же желает заказчик получить на выходе проекта. Для описания этого раздела подойдут формализованные Потребности заказчика. Похожий раздел есть в большинстве стандартов, например в ГОСТ-34.602-89 [4] он называется «назначение и цели создания (развития) системы».
Читать полностью »

в 13:37, , рубрики: Анализ и проектирование систем, оптимизация, Проектирование и рефакторинг, Промышленное программирование, разработка программного обеспечения, Тестирование IT-систем, требования, управление проектами, формирование требований, функциональное программирование

По мотивам моей статьи, изданной ранее…

Вступление

Получить бы медаль, а уж с обратной ее стороной найдем, что делать.
(Георгий Александров)

В подавляющем большинстве работ, посвященных управлению требованиями, которые мне довелось читать [1], [2], [3] и другие, авторы хороводят вокруг заказчика, акцентируя основное внимание читателей, на том, как максимально эффективно организовать работу именно с ним. Ну и конечно, львиная доля труда обычно посвящена вопросам преобразования собранной информации в некие проектные решения, моделирующие разрабатываемую систему, а также оформление их со спецэффектами, бантиками и рюшами. Разумеется это все важно и я ни в коем случае не хочу умолить значение этих аспектов формирования требований, но есть еще и обратная сторона. Ведь дальше требования должны попадать непосредственно в “цех” по производству программного обеспечения. И именно там они, до самого рождения целевого продукта, останутся основным сводом законов и правил, по которым он будет зарождаться и являться миру. Этот факт уже сам по себе определяет важность того, насколько точно требования должны соответствовать интересам специалистов, призванных воплотить их в конечном продукте.

А посему давайте взглянем на качество требований глазами команды исполнителей: разработчиков, специалистов управления качеством, менеджеров проекта. Ведь именно эти люди и являются основными потребителями работы аналитика. И от того насколько точно созданные спецификации подходят конкретной команде для переработки их в готовый программный продукт, зависит качество и конечная себестоимость этого продукта.
Читать полностью »

в 11:10, , рубрики: команда стартапа, Развитие стартапа, управление персоналом, управление проектами, Управление сообществом, Формирование команды, формирование требований, метки:

С частью 1 можно ознакомиться, перейдя по ссылке

III Механизмы построения социального организма

Примешь синюю таблетку — и сказке конец.
Ты проснешься в своей постели и поверишь, что это был сон.
Примешь красную таблетку — войдешь в страну чудес.
Я покажу тебе, насколько глубока кроличья нора.
Морфеус (Фильм «Матрица»)

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

Фактически мы предпримем попытку построить новый социальный механизм, запустив ход которого, воспроизведем некую новую действительность, позволяющую погрузить людей в новый, комфортный для них Мир. При этом стоит понимать, что когда мы порождаем целый Мир, скорее всего, он меняет что-то и в нас самих.

Для удобства, пойдем сверху вниз по списку функций, указанных а разделе 6 предыдущей главы.
Читать полностью »

Главная   |  Архив новостей  |   Android  |   Google  |   Apple  |   Microsoft  |   Информационная безопасность  |   Веб – разработка
Публикации RSS  |  Комментарии RSS
https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js