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

×


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

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


Сообщения - Григорий Печенкин

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 »
136
Все требования - опыт администрирования. Но почему вы тогда разместили эту вакансию на форуме аналитиков?

К сожалению, женщин не рассматриваем на данную позицию (требование руководства).

Иными словами, закондательство РФ в вашей компании не признают?

137
Диаграмма нужна для описания модели взаимодействий, повторюсь пример это ОЧЕНЬ упрощенная задача .. то есть та часть задачи которую я не смог описать в UML
а полная задача вот:
----
Есть в ORACLE такая сущность как Синоним
он ссылается на процедуру ..
процедура проверяет ряд условий .. готовит так сказать данные для дальнейшего запроса ... после чего по исходным данным + подготовленным "временкам" делает курсоры, которые в свою очередь используют промежуточные вызовы процедур.
всё это исключая блоки (select from dual) я описал на диаграмме последовательностей
---
А теперь внемание ... иногда!! при накате патчей на некоторые таблицы синоним перестает работать ... согласно документации он перестает работать из за того что процедура на которую смотрит синоним становится инвалидной, но перекомпилить её автоматом нельзя, процедура согласно документации падает если хотя-бы один объект на который она ссылается становится инвалидны ..

мне поставлена задача расписать логику синонима до уровня таблиц

С точки зрения пользователя, у синонима нет логики. Это просто другое имя объекта.
Вам нужно описать внутреннюю логику СУБД при разборе и выполнении запроса с использованием синонима? При этом синоним определён для процедуры, а не для таблицы?

Вы как-то очень запутанно описываете задачу. Такое ощущение, что вы сами её не поняли. А правильно поставленный вопрос, как известно, содержит половину ответа.

138
Алгоритм - это последовательность шагов. Какие шаги вам нужно изобразить?
Приведите пример, иначе непонятна задача, которую вы решаете.

139
Эксперты, дайте лучше совет человеку.

Я вот ничего, кроме традиционного совета читать книги Вигерса, пока не могу сформулировать.

140
а что это?

Ой, я имел в виду не ту, которая здесь приведена в начале топика, а ту, которую обсуждают, она в статье. Прилагаю её.
Здесь "доставить еду" - это цель. Но я бы не сказал, что это usecase.


141
Эти картинки только иллюстрируют возможности применения схемы, а вовсе не представляют "полную модель юскейсов".

Если расписать всех возможных пользователей и все их цели по отношению к системе, получится карта, которую можно вешать на стену, а не использовать в качестве иллюстрации к статье.

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

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

142
А по-моему, отличный пример. Понятная и простая иллюстрация.

143
ГОСТ как шаблон для требований гораздо лучше, чем отсутствие всякого шаблона, но при разработке игры он мало поможет. Потому что создание всякой игры начинается с идеи (а лучше - системы идей), которые затем формализовано излагаются в виде концепт-документа. А вот ГОСТа для изложения концепции игры не существует.

ГОСТ 34 - для автоматизированных систем, а игра под определение АС не подходит.

144
Стремительное развитие железа в последние 2 десятилетия всё чаще приводит к тому, что разработчики просто перестают думать например о том, на чем будет работать конечный продукт. Таких примеров можно массу привести.

А должны ли разработчики тетрисов об этом думать? Может, это забота разработчиков железа и операционной системы?

145
Насчет реанимации - это я не в курсе :) Но ничего страшного - меня зомби не смущают, доводилось работать на очень разном ПО.
Гораздо больше на данный момент ценно, что полная версия понятна по интерфейсу и весит всего 70$. Если пообвыкнусь за  триальный период - и купить не жалко. Понятное дело, что SPARX например выглядит куда мощнее и даже (через пень правда но ..) держит привычный BPMN. Но и денег на Corporate-версию (а ниже - нет смысла, ибо если уж брать, то хотя бы с моделированием GUI) нужно будет уже у шефа просить, сам не потяну наверное. А триала всего 30 дней.


У меня до сих пор стоит старая версию StarUML. Но при работе с ней возникают некоторые неприятные глюки, и нужно либо с ними смириться, либо переходить на другой инструмент.

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


Если вы до сих пор использовали eEPC и BPMN, то вы, наверное, описывали в первую очередь бизнес-процессы? Тогда UML, может быть, разочарует. Он хоть и унифицированный, но в нём нет элементов, специфичных именно для бизнес-процессов. Ну, то есть, найти в нём при желании можно всё, но представление будет не таким удобным и наглядным, как при использовании специально "заточенных" на бизнес-процессы нотаций.

146
Из книг лучше порекомендую Мартина Фаулера. Есть в электронном виде: http://www.books.ru/books/uml-osnovy-3-e-izdanie-fail-pdf-595320/?show=1

Он выделяет три уровня моделирования на UML (или "режима применения UML"):
- Эскизы
- Проектирование
- Программирование

Для новичков сложность обычно в том, что авторы книг сразу берутся описывать модели на уровне программирования. Хотя аналитику в большинстве случаев это не нужно.


И... вау! Они реанимировали StarUML! А мы его уже было похоронили... Я только не понял, бесплатная версия - это то, что у них называется V1?

147
Сергей, пока студенты собираются с мыслями, попробуем обсудить формулировки:
проблем (issue) - потребностей (need) - возможноcтей (feature)

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

Попробуем разобрать какие? Не все, а на примере какой-то определенной части?

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

Если говорить о потребностях и возможностях при разработке документа уровня Vision (то есть бизнес-требований), то я склонен считать, что Цели / Проблемы / Возможности / Потребности предоставляют собой четыре разных точки зрения на систему и представляют собой разные источники для выявления бизнес-требований. На этом этапе их скорее вредно трассировать друг на друга.

Цели и проблемы существуют у организации-заказчика (или Пользователя в том смысле, который вкладывает в этот термин ГОСТ).
Потребности существуют у пользователей системы, которые будут с ней работать.
Возможности система предоставит пользователям после того, как она будет внедрена или приобретена. Это такой взгляд в будущее: давайте представим, что система у нас уже работает, и посмотрим, какие возможности она нам даёт.

Проанализировав эти источники, можно получить перечень функций (и нефункциональных требований), и их уже трассировать на источники.

Когда я смотрю на матрицу в исходном посте, я вижу и в строках, и в столбцах не возможности и потребности, а разноуровневые функции, которые трассируются друг на друга.
Чем "ведение БД о служащих" отличается от "Администрирования данных о служащих"? И что это за потребность такая - ведение БД?

148
Вот одна из научных заочных конференций:
http://www.uml2.ru/forum/index.php?topic=6274.0
Публикуют журнал по итогам. ИМХО они принимают все темы как-то связанные с проектированием систем.

А здесь у нас есть и ссылка на этот журнал: http://www.uml2.ru/partners/ix-международная-научно-практическая-к/

149
Для всех / Re: Пишем ТЗ по ГОСТ 34
« : 09 Апреля 2015, 11:47:54 »
Перечень вопросов для FAQ - это хорошо. А как видишь работу с ответами? (пока предложено только формировать перечень вопросов).

Попросим ответить экспертов. Одного мы уже знаем. :)

150
Для всех / Re: Пишем ТЗ по ГОСТ 34
« : 09 Апреля 2015, 01:02:22 »
Предлагаю в этой теме общими усилиями сформировать список вопросов по ГОСТ 34, а потом сделать из них FAQ.

У меня получился такой список. Критикуйте, предлагайте свои вопросы и более правильные формулировки.

Является ли ГОСТ 34 методологией разработки?
Когда следует использовать ГОСТ 34?
Когда не следует использовать ГОСТ 34?
В каких случаях ГОСТ 34 обязателен к исполнению?
На каких этапах жизненного цикла разрабатываются требования по ГОСТ 34?
В каких документах по ГОСТ 34 содержатся требования?
Какие документы ГОСТ 34 являются самыми важными?
Какие документы ГОСТ 34 являются самыми полезными?
Что нужно изучить, прежде чем браться за разработку ТЗ по ГОСТ 34?
Как артефакты ГОСТ 34 соотносятся с классификацией требований Вигерса?
Обязательно ли заполнять все разделы ТЗ, перечисленные в ГОСТ 34?
Какие ошибки чаще всего совершают аналитики, использующие ГОСТ 34?

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 »