706

Управление Проектом / Re: Методы и средства инженерии программного обеспечения

« : 18 Апреля 2007, 22:25:40 »

Блин ... даже толком дух SWEBOK донести не могут ... зато MS прфинансировал сей опус :-).
еще перл .. "Существуют стандарты на разработку требований  на  систему и документы, в которых фиксируются результаты создания программного, технического, организационного и др. видов обеспечения автоматизированных систем (АС) на этапах жизненного цикла, включающие. В приложении 2, 3 дается краткое описание ГОСТ 34.601-90 «Стадии и этапы разработки АС» и ГОСТ 34.201-89 «Документация на разработку АС»."

А про ГОСТ 34.602 забыли сказать ...

Ивара Якобсона вообще Джекобсоном обозвали ... ну блин.

вобщем с моей точки зрения - халтура. А с другой стороны ... на безрыбье ...
Но почему бы не использовать то что уже сделано -- а именно перевод SWEBOK что у С. Орлика в блоге выложен ... хоть бы список литературы оттуда списали, чтоли ... у нас он ГОРАЗДО больше, в частности по теме требований.

707

Системный Анализ и Требования / Re: Потерянные требования

« : 18 Апреля 2007, 21:59:57 »

Огромное всем спасибо за советы. Сделала для себя определенные выводы. 

В проекте используются шаблоны некой методологии microscope. модели рисуем в RRose. больше по сути не пользуемся ни чем.

У меня есть ощущение, что вы работаете на одну _очень_ известную на отечественном оффшорном рынке компанию, в проекте на иминитого западного заказчика в сфере авиции, так?

Сейчас столкнулись с проблемой, что в use case не прописано ни одного поля, которые нужно заполнить. Например:
Пользователь добавляет новый элемент - Система открывает фору добавления нового элемента.
Пользователь заполнил атрибуты и нажал сохранить - Система проверила все ли обязательные атрибуты заполнены, сохраняет новый элемент. Если одно из обязательных полей не заполнено, система выдает ошибку.

А может так оно будет понятнее ...:
...
Главный успешный сценарий
1. Пользователь инициирует добваление нового элемента.
2. Система отобаражет форму добавления нового элемента и предлагает заполнить Атрибуты_элемента.
3. Пользователь заполнет Атрибуты_элемента и подтверждает ввод.
4. Система поддтверждает заполнение всех обязательных атрибутов и сохраняет элемент (или можно более детально -- Система в соответствии с бизнес-правилом BR33 подтверждает корректность заполнения Атрибутов_элемента и сохраняет элемент)

Альтернативные сценарии (или Расширения)
3а. Пользователь оказался от ввода
  3а1. <что происходит при этом>
4а. Не все обязательные атрибуты заполнены.
   4а1. Система предупреждает пользователя о проблеме и отображает (или выделяет         визуально) незаполненные атрибуты. (ИЛИ Система выдает Сообшение_об_ошбке_23 и ...)
   4а2. <что происходит далее ...>

Дополнительная информация
Атрибуты_элемента = Название чегото-то {max. 250 символов}
+ дата чего-то {в формате dd/mm/yyyy}
+ еще что-то ....
+ еще нечто
+ ...

Сообшение_об_ошбке_23 = "Hitler kaput!"

Еще на прошлой работе у меня был опыт следующего оформления спецификаций требований: в каждую спецификацию вставлялась модель сущность-связь из Erwin, где можно было четко увидеть все атрибуты сущности, участвующей в данном сценарии, просделить связь между всеми сущностями, участвующмими в процессе. На этой работе мы так не делаем и менять методику написания use case уже невозможно (тем более шаблоны и методику диктует нам заказчик). В вашей практике занимаетесь ли вы построением модели базы данных, диаграмм классов - и где это прописываться у вас в use case или в каком-либо отдельном документе?

См. как это можно сделать выше .. без всяких диаграмм ...

В одном из постов старожилы этого форму сетовали на то, что мол новички молчат, студенты только читают, а сказать ничего не могут. И вот меня понесло Но мне, действительно, нужны и важны ваши советы! Еще раз спасибо огромное!

Your welcome ...
P.S. Если то что я посоветовал поможет вам в работе, то скажите вашему директору центра качества, что я вышлю ему счет по почте, за консалтинг :-) ...

Disclaimer: То что в P.S. написано а) публикуется на правах шутки б) валидно, если я правильно угадал ваше место работы.

708

Вакансии / Re: Вакансия: системный аналитик

« : 11 Апреля 2007, 13:31:31 »

Чего вы накинулись на человека? Тут в разделе работа от работодателей и так полторы калеки, и те ходить перестанут.
Я хочу сказать еще, что реально внедренным хоть каким-то процессом может похвастаться подавляющее меньшинство компаний в России.

Согласен, что могут и перестать публиковать тут объявления ... думаю что публикация объявлений на hh.ru имеет больше шансов.
Про внедрение процессов в команиях, которыми они не могут похвастаться. Проблема не в том, что они НЕ МОГУТ внедрить процессы ... а все и без процессов и так хорошо идет :-). Процессы внедряют когда есть в этом осознанная необходимость, когда именно с внедрением процессов ассоциируется выгоды для бизнеса. А изобретать собственную терминологию ... хм, А ЗАЧЕМ??? Это же сложнее чем использовать уже готовую. Другой вопрос, что не знают про готовую ...

709

Идеи и мозговой штурм / Re: Расчет динамики

« : 11 Апреля 2007, 01:11:38 »

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

710

Проектирование / Re: Вопросы практики проектирования Web-приложения

« : 11 Апреля 2007, 01:07:49 »

Как много - это значит "how much", а не да или нет.
Ну, на нет и суда нет. Заниматься задачей без понимания истинных целей - возить граблями по резине - можно потратить кучу сил, денег и времени на неполучение ненужного результата. Аналитик тем и отличается, что думает головой, а не технологиями.
Причём тут защита канала? Не надо додумывать за задающего вопрос его мотивы. Актуален вопрос или нет - решает тот, к кому вы обратились за помощью.

Доктор: Сколько у вас детей?
Пациентка: Вопрос неактуален, т.к. вы терапевт, а не гинеколог.

5 баллов ... !!!!

711

Вакансии / Re: Вакансия: системный аналитик

« : 11 Апреля 2007, 00:46:46 »

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

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

А если еще взглянуть сюда http://en.wikipedia.org/wiki/Functional_design, то как-то не вяжется.

Насчет собеседования: разные компании используют разные методологичские подходы. Вменяемый работодатель не будет требовать знания всех мало ли кем придуманных и опубликованных терминов, это не тест на знание, например, C++. Методологии вторичны, важным является понимание сути процесса формализации требований и проектирования систем в соответствии с ними. Эти навыки выясняются в ходе беседы - несколько сложнее, конечно, чем собеседование с кандидатом в кодировщики. Но если человек блеснул знанием терминологии, это еще не означает, что перед вами хороший аналист, isn't it?
Оч. помогают примеры документов, разработанных соискателем (их обсуждение в ходе интервью, разумеется).

Ой, мама ... в порядке выделенного.
1. Вменяемый работодатель обычно таки использует устоявшуюся терминологию, которя встречается в стандартах и методологиях, в соответствии с которыми выстроены собственные процессы работодателя или откровенно приводит ссылку на используемые стандарты и методологии (например в соответствии с ГОСТ 34.602 или IEEE или хотябы RUP/MSF ...). Отсутсвие внятной терминологии может навести на мысли о зрелости процессов данного работодателя. Иногда, если собственных процессов нет, используют терминологию ГОСТ :-).
2. Про "суть формализации требований" и методологии. Как раз обычно именно в стандартах и методологиях указывают про ту самую "суть формализации требований" (особенно в методологиях -- том же RUP) и если работодатель, например, мыслит в терминах IDEF0/3  и считает что это и есть формализация ТРЕБОВАНИЙ к ПО, а соискателя в ВУЗе учили,  что требования это то что например в SWEBOK описано ... то дело уже не в навыках и методологиях, и этот факт может быть вполне интерпретирован тем же соискателем как то, что компания-работодатель не уважает время людей, которые приходят к ней на собеседование.
3. Совет соискателям -- не оставляйте примеры своих документов работодателям. Показать мельком -- можно. Во-первых скорее всего эта информация составляет коммерческую тайну компании на которую вы работали или все еще работаете, во-вторых мир тесен :-), в третьих подумайте над тем, как (возможно) будут хихикать специалисты этой компании над вашими документами, пытаясь доказать в первую очередь самим себе, что они лучше вас :-) (это на правах шутки). Кроме этого вполне может случиться так, что  примеры ваших лучших работ (ведь вы же будете показывать лучшие свои работы!) могут быть использованы этой компанией для повышения собственной компетенции, но уже без вашего участия :-).

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

712

Проектирование / Re: Вопросы практики проектирования Web-приложения

« : 09 Апреля 2007, 18:54:15 »

может быть, может быть.
Я просто набираю информацию о том, какими средствами (технологией) _рациональнее решить задачу_.
Считал именно этим и занимаются Аналитики при построении концепции.
Причём в код не углублялся, а пытался увязать требования с современныйми возможностями IT систем (ограничениями Оных).

"Все не так было" (с) :-). Программная архитектура строится на основании требований к системе. Аналитики не занимаются программной архитектурой как таковой. они занимаются бизнес требованиями и функциональными и нефункциональными требованиями. Если ваш заказчик желает иметь под вэб такой же GUI как в Дельфи -- то это будет ОГРАНИЧЕНИЕ проектирования. Однако вызывает сомнение, что ваш заказчик хочет именно иметь гриды и сохранять каждую запись. Думаю это уже ваша интерпретация потребностей заказчика. Можно сделать предположение, что у вас проблема таки не в программной архитектуре, а в том, как достичь с заказчиком соглашения по юзабилити.

713

Проектирование / Re: Вопросы практики проектирования Web-приложения

« : 09 Апреля 2007, 14:48:10 »

По-моему исходный вопрос звучал как "Чем всё-таки могут помочь дисциплинны по Аналитике и UML при проектировании Web-приложения?", а вы тут уже про Ajax начали тему ... или под термином "Аналитика" понимаем нечто очень общее и большое? Но тогда не стоит употреблять его в связке со словом "дисциплина" ибо есть устойчивая ассоциация с дисциплинами RUP.
Отвечая на исходный вопрос -- дисциплина Анализ и проектирование и соответственно использование языка UML может помочь при проектировании хоть web, хоть каких приложений, но при некоторых условиях:
1. Использование соответствующих архитектурных стилей, и в частности более четкое разделение на приложения на "слои" GUI, бизнес-логики, persistent и хранения данных.
2. Вы владеете языком UML и можете "на нем говорить" в равной степени с окружающими вас инженерами.

 

714

Варианты Использования (Use Case) / Re: Структурные Диаграммы представления ВИ

« : 08 Апреля 2007, 12:59:09 »

К сожалению, дело обстоит не совсем так.  Цитата из Коберна (стр 226 из текста из библиотеки сайта)
Коберном проделана выдающаяся работа по окультуриванию практики описания
алгоритмов, и его рекомендации по текстовому описанию юзкейсов действительно важный шаг в развитии IT, но к сожалению его взгляд на использование графических средств анализа и представления результатов является шагом назад, который серьезно оппонирует попыткам создания новых средств анализа и моделирования даже в качестве дополнительных к "текстовым инструментам" .

На самом деле мне не понятно, таки почему это "дело обстоит не совсем так" ... и почему ТОЛЬКО диаграммы юзкейсов не должны вызывать скепсис?? Особенно если учесть тот факт, что практика использования только диаграмм юзкейсов фактически приводит к функциональной декомпозиции но на юзкейсах ... и запросто при этом встречаем ВИ "Отправка уведомления о регистрации на мероприятие", который в лучшем случае будет "included". Никто не отрицает, что использование диаграммы юзкейсов в качестве "оглавления", предваряющего собственно текстовые спецификации вполне полезно, более того, я сам часто использовал диаграммы ВИ в "Modern SRS", но обязательно за ними следовали и сами юзкейсы. Кроме этого еще и графически показывал связь м/у диаграммами уровня "облака" и "user goal". Так что речь тут в большей степении о том, что имеет смысл использовать диаграммы СОВМЕСТНО с текстовыми спецификациями ... Но при этом, одни текстовые спеки дают больше value, чем одни диаграммы.
[/quote]

715

Вакансии / Re: Вакансия: системный аналитик

« : 07 Апреля 2007, 00:33:32 »

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

"- разработка информационно-логической модели системы" ...

Читаю и чуствую себя неловко ... вот придешь на собеседование, а тебя спросят "как вы будете описывать функцинальную архитектуру" ... и что тут ответить?

716

Варианты Использования (Use Case) / Re: Структурные Диаграммы представления ВИ

« : 07 Апреля 2007, 00:10:32 »

А насчет использования дигарамм UC, поднятой автором этой темы, ИМХО значительная часть скепсиса по поводу их применения связана с тем, что их "просто не умеют готовить". 

Скепсис в большей степени вызывают не столько сами диаграммы, сколько "только диаграммы" (читай "только диаграммы юзкейсов и ничего больше").

717

Варианты Использования (Use Case) / Re: Структурные Диаграммы представления ВИ

« : 07 Апреля 2007, 00:07:09 »

2. Берем всех выделенных на раннем этапе ЗЛ (заинтересованных лиц) и для каждого расписываем что-то же делает его счастливым (его ответственность) в рамках этого ВИ
3. Расписываем этот ВИ, чтобы удовлетворить все потребности из п. 2, хотя по сути актер один - "Админмитратор Курсов"

Не чуствуешь как от этого "пахнет Коберном" с его "защитить интересы всех стейкхолдеров" ;-) ?

718

Системный Анализ и Требования / Re: Образцы ТЗ по ГОСТу

« : 03 Апреля 2007, 12:18:23 »

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

719

О Сайте и Форуме / Re: Новая концепция нашего ресурса

« : 02 Апреля 2007, 18:08:52 »

уже тема :-).

720

Системный Анализ и Требования / Re: Образцы ТЗ по ГОСТу

« : 02 Апреля 2007, 18:06:46 »

Что касается данного ресурса, то размещенные там ТЗ не являются образцом хорошо написанной документации требований, во всяком случае я просмотрел несколько экземпляров от Ланит, IBS, и еще одной компании, запамятовал название. Вобщем, не впечатлило :-).