Методология структурного анализа и проектирования SADT (Idef0)
На инфостарте нет ни одной статьи по SADT, а на форме только редкие упоминания.
На мой взгляд хоть методология и не новая, но зато перспективная.
Сам я узнал про данную методологию в институте, естественно получил только представление.
Сейчас пытаюсь реализовать методология на практике.
И естественно вопросов больше чем ответов :)
Было бы очень интересно пообщаться с теми кто пользуется SADT.
На мой взгляд хоть методология и не новая, но зато перспективная.
Сам я узнал про данную методологию в институте, естественно получил только представление.
Сейчас пытаюсь реализовать методология на практике.
И естественно вопросов больше чем ответов :)
Было бы очень интересно пообщаться с теми кто пользуется SADT.
По теме из базы знаний
- Проектирование архитектуры и модификация программных продуктов как технология в сложных проектах системной интеграции и автоматизации на базе 1С: СППР
- Из хаоса в логику бизнес-процессов
- Котлеты по-одесски, или с чем кушать IDEF0
- Краткий путеводитель по методологиям и нотациям описания и моделирования бизнес-процессов. Часть 1
- Берримор, ты потерял рецепт овсянки? Не беда, нам поможет DFD!
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Пробовал использовать несколько раз. Да, удобно при проектировании, да удобно для документирования и передачи. Но если те с кем ты работаешь не понимают или даже не пытаются понять - то это чисто для себя игрушка. Хотя, это наверное с любой методологией так.
У тебя в чем будет заключаться практическое применение? Группа разработчиков или сам по себе? Какой результат хочется получить?
У тебя в чем будет заключаться практическое применение? Группа разработчиков или сам по себе? Какой результат хочется получить?
(2)
Я единственный 1С-ник в организации, будем считать что сам по себе.
Практическое применение и результат.
Изначально я работал по следующему принципу - любой сотрудник организации ставил задачу, и все хотелки исполнялись. Естественно, бардак был еще тот.
Затем все задания начали пропускать через начальников отделов. Стало получше.
Затем начали согласовывать задания с финансовым директором. Фактически начали реализовывать то, что нужно фин. директору.
Основная проблема заключалась в том, что процессы в организации практически никак не описаны. Есть регламенты, но они далеко не всю деятельность охватывают. Любой сотрудник, даже фин. директор, это не ИТ специалист, поэтому им тяжело поставить задачу.
От методологии ожидаю понятного описания (для меня и для руководства) процессов происходящих в компании.
Если вернуться к тем же регламентам, даже они уже сильно разрослись в организации, и уже даже руководство не может однозначно трактовать некоторые моменты, не говоря уже об остальных пользователях.
Привычная для 1С-ника фраза от пользователя: "1С не работает". Что означает фраза? Означает, что нигде не описано достаточно подробно, как должно работать, а у пользователя какая-то своя картина в голове, причем эта картина может меняться в зависимости от ситуации.
В целом, мне нужно взаимодействие с руководством организации. Причем в тех случаях, когда однозначно правильного решения нет, т.е. нужно принимать сложные решения, а иногда очень сложные. Приведу пример. Ставят задачу: нам нужны минимальные остатки на складах. Да легко, совсем остатков не будет на складе. А оказывается минимальные да не минимальные.
Я единственный 1С-ник в организации, будем считать что сам по себе.
Практическое применение и результат.
Изначально я работал по следующему принципу - любой сотрудник организации ставил задачу, и все хотелки исполнялись. Естественно, бардак был еще тот.
Затем все задания начали пропускать через начальников отделов. Стало получше.
Затем начали согласовывать задания с финансовым директором. Фактически начали реализовывать то, что нужно фин. директору.
Основная проблема заключалась в том, что процессы в организации практически никак не описаны. Есть регламенты, но они далеко не всю деятельность охватывают. Любой сотрудник, даже фин. директор, это не ИТ специалист, поэтому им тяжело поставить задачу.
От методологии ожидаю понятного описания (для меня и для руководства) процессов происходящих в компании.
Если вернуться к тем же регламентам, даже они уже сильно разрослись в организации, и уже даже руководство не может однозначно трактовать некоторые моменты, не говоря уже об остальных пользователях.
Привычная для 1С-ника фраза от пользователя: "1С не работает". Что означает фраза? Означает, что нигде не описано достаточно подробно, как должно работать, а у пользователя какая-то своя картина в голове, причем эта картина может меняться в зависимости от ситуации.
В целом, мне нужно взаимодействие с руководством организации. Причем в тех случаях, когда однозначно правильного решения нет, т.е. нужно принимать сложные решения, а иногда очень сложные. Приведу пример. Ставят задачу: нам нужны минимальные остатки на складах. Да легко, совсем остатков не будет на складе. А оказывается минимальные да не минимальные.
(3) ого, некоторым не дано дорасти до осознания этих вещей, держи "+" к карме :)
Относительно методологий - тут есть определенный момент, что пользователям - чем проще информация - тем понятнее. Ты можешь рисовать прекрасные схемы по всем правилам методологии - но если тёте Дусе непонятны картинка - кивнет головой, а через пару недель придет с той же фразой "1С не работает" и хоть запоказывайся ей то, на что он кивала и соглашалась. Поэтому часто встречается некий "симбиоз" методологий (на подобии того, о чем говорит ImHunter и оно реально работает).
А вот про UML - там тоже есть полезные вещи. Посмотри диаграммы: диаграмма прецедентов, диаграмма деятельности - они применимы не только для ООП. Как показывает практика, их пользователи достаточно быстро учатся воспринимать. Остальные при определенных оговорках тоже можно использовать в среде 1С.
Это я все к тому, что чисто на IDEF0 не уедешь. Нужно подбирать инструмент учитывая навыки твоих потребителей. Иногда схема, нарисованная в Paint с убогими квадратиками и стрелками дает гораздо лучший результат по сравнению с "правильной" диаграммой IDEF.
Относительно методологий - тут есть определенный момент, что пользователям - чем проще информация - тем понятнее. Ты можешь рисовать прекрасные схемы по всем правилам методологии - но если тёте Дусе непонятны картинка - кивнет головой, а через пару недель придет с той же фразой "1С не работает" и хоть запоказывайся ей то, на что он кивала и соглашалась. Поэтому часто встречается некий "симбиоз" методологий (на подобии того, о чем говорит ImHunter и оно реально работает).
А вот про UML - там тоже есть полезные вещи. Посмотри диаграммы: диаграмма прецедентов, диаграмма деятельности - они применимы не только для ООП. Как показывает практика, их пользователи достаточно быстро учатся воспринимать. Остальные при определенных оговорках тоже можно использовать в среде 1С.
Это я все к тому, что чисто на IDEF0 не уедешь. Нужно подбирать инструмент учитывая навыки твоих потребителей. Иногда схема, нарисованная в Paint с убогими квадратиками и стрелками дает гораздо лучший результат по сравнению с "правильной" диаграммой IDEF.
(8) У меня нет цели, чтобы все сотрудники понимали диаграммы, интересуют только лица принимающие решение, а их не так много, и они не глупые. А для остальных пишем инструкции.
В методологии SADT в итоге мы приходим к текстовому представлению информации, не знаю куда уж более унифицировано.
В плане проектирования сильное влияние на меня оказала книга Дэвида Алена "Как привести свои дела в порядок", которую порекомендовал прочитать в своем ролике Максим Дорофеев (Есть его статья на инфостарте). В книге очень наглядно описано, важность концентрации на решаемой задаче. А если задача не маленькая, и пытаться удержать в голове, что надо сделать это, а еще это, и еще вот это (вот поэтому я с ужасом вспоминаю работу во франчайзи, где надо было помнить проблемы всех клиентов) - то ни к чему хорошему окромя стресса, это не приведет. А также и Джедайская техника многое объясняет, что только описав понятным языком для своей "обезьяны" можно достичь хорошего результата.
Используя UML писал проекты под C#, использовал RUP. Реально применить к 1С, опять же оговорюсь, может я просто не умею готовить, но у меня вот никак не получалось.
Начинаю с функциональной модели. Уже на этом моменте функций просто тьма. Если говорить о пользователях больше 90% функций будут, по вводу данных, по поиску данных, формирование отчетов, проведение документов. Функции самой 1С тоже будут связаны с обработкой данных. Оно и не удивительно.
Диаграмма классов. С функциями выясняется что они уже реализованы 1С, фактически это различные события. Переходим к реквизитам и понимаем, что когда создаем объекты метаданных - мы создаем структуру ИБ.
Переходим к взаимодействию объектов. Тут мы понимаем, что объекты не особо и взаимодействуют друг с другом, а живут вполне себе самостоятельно. Т.е. модель не объектно ориентированная, а ориентированная на события, что собственно подтверждают и сами 1С, кстати, и что объектная модель уже ими разработана тоже об этом говорят.
В методологии SADT в итоге мы приходим к текстовому представлению информации, не знаю куда уж более унифицировано.
В плане проектирования сильное влияние на меня оказала книга Дэвида Алена "Как привести свои дела в порядок", которую порекомендовал прочитать в своем ролике Максим Дорофеев (Есть его статья на инфостарте). В книге очень наглядно описано, важность концентрации на решаемой задаче. А если задача не маленькая, и пытаться удержать в голове, что надо сделать это, а еще это, и еще вот это (вот поэтому я с ужасом вспоминаю работу во франчайзи, где надо было помнить проблемы всех клиентов) - то ни к чему хорошему окромя стресса, это не приведет. А также и Джедайская техника многое объясняет, что только описав понятным языком для своей "обезьяны" можно достичь хорошего результата.
Используя UML писал проекты под C#, использовал RUP. Реально применить к 1С, опять же оговорюсь, может я просто не умею готовить, но у меня вот никак не получалось.
Начинаю с функциональной модели. Уже на этом моменте функций просто тьма. Если говорить о пользователях больше 90% функций будут, по вводу данных, по поиску данных, формирование отчетов, проведение документов. Функции самой 1С тоже будут связаны с обработкой данных. Оно и не удивительно.
Диаграмма классов. С функциями выясняется что они уже реализованы 1С, фактически это различные события. Переходим к реквизитам и понимаем, что когда создаем объекты метаданных - мы создаем структуру ИБ.
Переходим к взаимодействию объектов. Тут мы понимаем, что объекты не особо и взаимодействуют друг с другом, а живут вполне себе самостоятельно. Т.е. модель не объектно ориентированная, а ориентированная на события, что собственно подтверждают и сами 1С, кстати, и что объектная модель уже ими разработана тоже об этом говорят.
Пытался самому себе внедрить использование MSF. Так и забросил. Ибо заниматься все-таки чем-то одним нужно - или проектировать-анализировать, или писать эффективный код. Мозги по-разному должны работать.
Поэтому ограничился тем, что прорисовываю самопальные диаграммы - смесь диаграммы взаимодействия и диаграммы классов. Понятно, что это применимо только к тактическим или оперативным задачам.
Поэтому ограничился тем, что прорисовываю самопальные диаграммы - смесь диаграммы взаимодействия и диаграммы классов. Понятно, что это применимо только к тактическим или оперативным задачам.
(5) Писать эффективный код, но при этом не проектировать и не анализировать. Даже как-то странно звучит.
Анализ - разбиение задачи на более мелкие задачи, для более детального изучения. Т.е. предпочитаете все в кучу писать? Сомневаюсь.
Диаграммы классов и диаграммы взаимодействий, похоже на названия диаграмм UML. Лично моё мнение UML, предназначен для ООП разработки, т.е. для 1С совершенно не подходит. Какие могут быть в 1С классы? Объектная модель полностью создана фирмой 1С.
Какое взаимодействие между классами в 1С? Типичный код модулей - получение данных путем запроса + запись данных через объекты.
Может я просто не умею готовить UML?
Анализ - разбиение задачи на более мелкие задачи, для более детального изучения. Т.е. предпочитаете все в кучу писать? Сомневаюсь.
Диаграммы классов и диаграммы взаимодействий, похоже на названия диаграмм UML. Лично моё мнение UML, предназначен для ООП разработки, т.е. для 1С совершенно не подходит. Какие могут быть в 1С классы? Объектная модель полностью создана фирмой 1С.
Какое взаимодействие между классами в 1С? Типичный код модулей - получение данных путем запроса + запись данных через объекты.
Может я просто не умею готовить UML?
Лично для себя сделал вывод, что внедрять какую-то методику для работы в одного - неоправданно большая трата времени. Никто более не оценит и не использует результаты. Вот если заниматься преимущественно бизнес-аналитикой... Тогда да, нужно придерживаться какой методики.
Да, даже в одного нужно заниматься проектированием. И тогда (мне) нужно полностью самоудалиться от написания кода или накидывания чего-то в дереве метаданных. И тогда я ухожу домой (на удаленку), рисую, хожу по квартире, матькаюсь, опять рисую. И так, пока не появится какая-то стройная схема.
Насчет классов в 1С. Гм. Совершенно очевидно, что они есть. Есть реквизиты (типа свойства), есть методы объекта и класса.
Насчет взаимодействия. Тут больше имеется в виду какое-то межсистемное (внутреннее или внешнее) взаимодействие. Или РИБ - что куда обменом уходит, что где получается централизованно из главного узла с помощью вспомогательных веб-сервисов. В общем, сценариев всяких много разных бывает. И вот каждый сценарий я и разрисовываю - где какой артефакт появляется, куда передается, как обрабатывается, во что превращается. И примерный состав этих артефактов тут же классом вписываю.
Да, даже в одного нужно заниматься проектированием. И тогда (мне) нужно полностью самоудалиться от написания кода или накидывания чего-то в дереве метаданных. И тогда я ухожу домой (на удаленку), рисую, хожу по квартире, матькаюсь, опять рисую. И так, пока не появится какая-то стройная схема.
Насчет классов в 1С. Гм. Совершенно очевидно, что они есть. Есть реквизиты (типа свойства), есть методы объекта и класса.
Насчет взаимодействия. Тут больше имеется в виду какое-то межсистемное (внутреннее или внешнее) взаимодействие. Или РИБ - что куда обменом уходит, что где получается централизованно из главного узла с помощью вспомогательных веб-сервисов. В общем, сценариев всяких много разных бывает. И вот каждый сценарий я и разрисовываю - где какой артефакт появляется, куда передается, как обрабатывается, во что превращается. И примерный состав этих артефактов тут же классом вписываю.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот