Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - bas

3016
Проблема в том, что мы (я) не можем сказать количественные показатели оптимизации при внедрении ПУТ, т.е. не можем сказать точно, что время разработки снизится на столько, затраты уменьшаться на столько и т.д. Т.е. результат нельзя пощупать. Или можно???

3017
Столкнулся с проблемой убедить начальство\заказчика\маму\папу ... в том, что нормально выстроенный Процесс Управления Требованиями (ПУТ) это действительно нужно. Или как говорят небезызвестные нам консультанты -- what is the value of requirements management process?

Попытался сформулировать преимущества и риски, которые дает выстроенный ПУТ, но и они не дали результата. Давайте вместе подумаем, что можно придумать еще и переформулировать что есть.

4.   Преимущества внедрения процесса и средства Управления  Требованиями.
Ниже описаны все преимущества дающие внедрение процесса и средств Управления Требований.
4.1.   Внедрение регламентов по управлению требованиями позволит уменьшить время, требуемое на процесс анализа и всю разработку ПО в целом.
4.2.   Применение внедряемых техник сбора, анализа и документирования требований позволит разрабатывать ПО, наиболее полно отвечающее всем требованиям Заказчика. Что в итоге позволит сократить время разработки ПО
4.3.   Правильная организация требований позволит использовать требования и разработанные решения вторично, что сильно сократит время разработки .
4.4.   Полное описание требований и правильная их организация позволит более точно планировать разработку ПО.
4.5.   Полная база знаний (требования) ПО позволит делать более правильные стратегические решения по совершенствованию существующего ПО, разработки нового или интеграции ПО, имеющегося в наличии.
4.6.   Организация доступа, сохранности и версионности требований с помощью СУТ позволит уменьшить время разработки ПО и избежать ситуации работы с неактуальными требованиями. Кроме того, будет всегда известно – кто и по какой причине сделал изменения в требованиях, что увеличит контроль над процессом анализа.
4.7.   Совершенствование процессов целеполагания позволит разрабатывать ПО, которое будет помогать конечному Заказчику в достижении бизнес цели и автоматизировать наиболее необходимые и трудоемкие задачи.
4.8.   Правильное документирование и организация требований позволит легко и быстро ввести нового человека (Аналитика, Архитектора, Разработчика и Тестировщика) в проект.
4.9.   Правильное документирование и организация требований позволит улучшить качество требований, чтобы они стали более понятные, однозначные и тестируемые. Что в конечном итоге повысит качество создаваемого ПО.
4.10.   Правильное документирование и организация требований позволит улучшить взаимопонимание между Аналитиками и конечными Заказчиками. Что в итоге уменьшит время, требуемое на согласование требований.
4.11.   Правильное документирование и организация требований позволит улучшить взаимопонимание между Аналитиками и всеми членами команды разработки (Архитекторы, Разработчики и Тестировщики). Что в итоге позволит уменьшить время разработки и повысит качество ПО.
4.12.   Организация трассировки позволит понять – как одно требование влияет на другие и обнаружить ситуацию, когда требования определены не полностью. Данное преимущество позволит уменьшить время, требуемое на изменение требований, и описывать требования наиболее полно.
4.13.   Визуализация требований (моделирование) позволяется облегчить процесс понимания требований в целом и в деталях.
4.14.   СУТ позволит оптимально распределить права и обязанности между всеми задействованными лицами в проекте и обеспечит работу множества участников над многими проектами.

5.   Риски внедрения процесса Управления Требованиями.
Ниже представлен список возможных рисков при внедрении процесса Управления Требований. Данных рисков можно избежать, если правильно выстроить предлагаемый процесс.
5.1.   Требования должны быть известны всем участникам проекта
5.2.   В процесс анализа не должно быть вложено слишком много усилий
5.3.   Не следует быть через чур формальным с требованиями и спецификациями
5.4.   Не следует быть слишком не формальным
5.5.   Требования не должны быть слишком длинные и скучные для всех заинтересованных лиц, участвующих в процессе создания ПО

З.Ы. Следующим шагом должен быть описанный регламент УТ.

3018
Хочется еще добавить, что моделирование ради моделирования - плохая затея. Если Вы не видете плюсы, то рано еще его использовать. А вообще моделирование (хотябы в картинках) решает проблему представления сложного - проще, в виде модели. Мы же еще со школы рисовали задачки по математике, чтобы понять условие...

Если хотите использовать моделирование в работе, то во-первых, надо договориться со ВСЕМИ участниками проекта что делаем и для чего (а то действительно в конце пошлют). Во-вторых использовать только то, что Вам действительно нужно. В-третьих, показывать результаты как можно раньше ВСЕМ, чтобы Вас корректировали.

А для начала, просто для себя сделать несколько моделей, чтобы научиться их правильно делать.

3019
Для всех / Re: помогите начинаюшему.
« : 09 Июня 2008, 20:16:11 »
alys,

Так никто не против. Но есть ли такие примеры в природе. Эд дал ссылки на то что есть.

3020
RT,

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

3022
Юра,

Не понял большой разницы м\у твоим и моим вариантом :)

3023
Ира,

Ну ты шаман :) Может тебе уже представительство ЕА открывать в России.

3024
Т.е. я создаю ВИ "Создать шаблон отчета", в сценарии которого описываю последовательность действий пользователя. Все вроде бы нормально, но возникает проблема в том, что пользователь может размещать элементы на бланке в различной последовательности.
Может быть написать просто, пользователь выбирает элемент и добавляет его на бланк? Тогда необходимо описывать правила добавления и размещения для каждого типа элемента, например, в разделе связанные с ВИ бизнес-правила. Так?
Можно и так. Можно с шагом сценария связать ФТ, в котором будет описана ф-ть добавления эл-та и его прорисовка\масштабирование\т.д.
Например так:
Шаг Сценария №n: Пользователь добавляет один из перечисленных элементов на бланке:
* Таблица, см. ФТ №35
* Связь между таблицами, см. ФТ №36
* Что-то еще, см. ФТ №36
Шаг Сценария №n+1: Если Пользователь добавил все нужные ему элементы на бланк, то переходим к п. №n+2, если нужно добавить еще элемент, то переходим к п.№n

3025
Цитировать
Коллеги!

Сегодня в 18-00 в помещении кухни состоится семинар-тренинг на тему «Укрепление командного духа подручными средствами».
Лектор J.W. BlackLabel с 12 летним стажем.

3026
Забавно :) М.б. прикрепить эту сообщение к теме Тематические анекдоты и смешные истории?

3027
3.   Способность к принятию решений в условиях нехватки информации

Энто как  :o

3028
Теперь я даже теряюсь куда перенести эту тему, м.б. в раздел Теория моделирования и нотации?

3030
May12,

А ссылку на найденную тему дайте, я эту тогда удалю или присоединю туда.