Доброго времени суток, уважаемые участники сообщества системных аналитиков!

На данный момент я работаю в одной из самарских компаний, занимающейся разработкой ПО, в должности бизнес-аналитик. Работаю с недавних пор. В 2010 году закончил Самарский государственний аэрокосмический университет им. С.П. Королёва (национальный исследовательский университет) по специальности 220305 "Автоматизированное управление жизненным циклом продукции (CALS/ИПИ-технологии)", на данный момент являюсь магистрантом СГАУ.

Хочу предложить Вашему вниманию статью на тему "Методы и средства программной инженерии при проектировании интегрированной информационной системы предприятия аэрокосмической отрасли", которая была написана мною на международную конференцию ПИТ-2010, которая проходила с 31 сентября по 1 октября 2010 года в Самаре, на базе Самарского государственного аэрокосмического университета им. С.П. Королёва (национальный исследовательский университет).

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

один вопрос: а должны применяться какие ОСОБЫЕ методы и средства?

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

P.S. вообще-то разумнее было бы послать в какое-нибудь издание (правильно, где платят больше (с))

прочитал - потерял время, для прочтения не рекомендую, статья ни о чем. все заключения из серии "общеизвестно, что".
для студента - в качестве вводных слов для курсовика какого-нибудь или может быть даже диплома годится (если нет жестких требований). и только!
P.S. вообще-то разумнее было бы послать в какое-нибудь издание (правильно, где платят больше (с))

Спасибо за ответ! Мне как раз и нужно было уточнить - насколько актуальна и правильна статья, есть ли в ней какие-либо недочёты/ошибки и т.п. А что касается отправки в какое-либо издание, то она вошла в сборник трудов конференции ПИТ-2010. Прошу прощения, что сразу не уведомил о том, что она содержит общую концепцию построения ИИС и будет не совсем интересна для экспертов бизнес/системного анализа.

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

Прочитал. Есть некоторые замечания:
1. Стоит более широко рассматривать средства моделирования. Как то мало.
2. Объектно - ориентированный подход сам по себе не повышает надежность.
3. UML никак не связан с ООП.
4. Использование всех диаграмм UML не делает модель лучше, а зачастую ухудшает ее и делает менее прозрачной.
5. Начальным этапом является на мой взгляд не сбор требований, а определение концепции продукта.
6. Не совсем понимаю почему диаграмма классов строится с чьей то точки зрения. Для каждого stakeholder'a свои классы ? Не разу такого не видел.
7. Как Activity diagramm и Use case diagramm соотносятся со структурным моделированием выделенным у вас в первый этап ?
8. Архитектура и платформа тоже определяется на этапе моделирования, а не после кодирования.

Прочитал. Есть некоторые замечания:
1. Стоит более широко рассматривать средства моделирования. Как то мало.
2. Объектно - ориентированный подход сам по себе не повышает надежность.
3. UML никак не связан с ООП.
4. Использование всех диаграмм UML не делает модель лучше, а зачастую ухудшает ее и делает менее прозрачной.
5. Начальным этапом является на мой взгляд не сбор требований, а определение концепции продукта.
6. Не совсем понимаю почему диаграмма классов строится с чьей то точки зрения. Для каждого stakeholder'a свои классы ? Не разу такого не видел.
7. Как Activity diagramm и Use case diagramm соотносятся со структурным моделированием выделенным у вас в первый этап ?
8. Архитектура и платформа тоже определяется на этапе моделирования, а не после кодирования.

1. Выбирал на мой взгляд самые известные и практичные средства визуального моделирования. В том числе те, которыми пользовался на дипломном проектировании.
2. Согласен, что ООП сам по себе не повышает надёжность. Но применение ООП повышает надёжность разрабатываемого ПО - данная информация взята из опубликованного источника, а не просто выдумана.
3. Почему UML не связан с ООП? UML ведь является базовым языком описания/проектирования объектно-ориентированных систем?
4. Согласен с Вашим утверждением по поводу использования всех диаграмм UML.
5. Согласен с вами: определении концепции - сбор требований -> формализация требований -> разработка ТЗ и т.д.
6. Про диаграмму классов. Я имел в виду не чью-то точку зрения на систему (например, человека), а аспект системы вообще, то есть если вся система представляет собой совокупность классов (их огромное множество - для большой системы), то имеет смысл не отображать все классы и отношения между ними, а использовать только необходимые классы и ассоциации между ними для понимания только той определённой части системы.
7. Согласен, что Activity diagramm моделируют поведение системы. Я лишь хотел указать, что вариант использования может быть раскрыт этой диаграммой.
8. Солидарен с Вами.

1. Выбирал на мой взгляд самые известные и практичные средства визуального моделирования. В том числе те, которыми пользовался на дипломном проектировании.
2. Согласен, что ООП сам по себе не повышает надёжность. Но применение ООП повышает надёжность разрабатываемого ПО - данная информация взята из опубликованного источника, а не просто выдумана.
3. Почему UML не связан с ООП? UML ведь является базовым языком описания/проектирования объектно-ориентированных систем?
4. Согласен с Вашим утверждением по поводу использования всех диаграмм UML.
5. Согласен с вами: определении концепции - сбор требований -> формализация требований -> разработка ТЗ и т.д.
6. Про диаграмму классов. Я имел в виду не чью-то точку зрения на систему (например, человека), а аспект системы вообще, то есть если вся система представляет собой совокупность классов (их огромное множество - для большой системы), то имеет смысл не отображать все классы и отношения между ними, а использовать только необходимые классы и ассоциации между ними для понимания только той определённой части системы.
7. Согласен, что Activity diagramm моделируют поведение системы. Я лишь хотел указать, что вариант использования может быть раскрыт этой диаграммой.
8. Солидарен с Вами.

1. Если самые известные, то вы никак не упомянули семейство Rational, а оно одно из средств в описанном сегменте. А Aris вообще больше для описания БП.
2. Вы сами себе противоречите. ООП дает инструментарий, применение которого может повысить, но может и понизить надежность.
3. Если смотреть определение в вики, то да. Но на самом деле UML применяется любых систем.
4. Тогда лучше использовать понятие модуль или компонента, ну или уровень декомпозиции.

Только для того, что бы определить Концепцию, нужно собрать требования, только более высокого уровня

4. Тогда лучше использовать понятие модуль или компонента, ну или уровень декомпозиции.

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

http://www.gramota.ru/slovari/dic/?word=%EA%EE%EC%EF%EE%ED%E5%ED%F2%E0&all=x
http://www.gramota.ru/slovari/dic/?word=%EA%EE%EC%EF%EE%ED%E5%ED%F2&all=x

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

Пролистал  статью ... автору имеет смысл обратить внимание на:
1. Определение и способы применения бизнес-юзкейсов (BUC). Т.е. что есть BUC, и для чего их используют
2. Определение бизнес-требований.
3. Способы представления бизнес-требований.
4. Отличие бизнес-требований от пользовательских и функциональных требований

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

http://www.gramota.ru/slovari/dic/?word=%EA%EE%EC%EF%EE%ED%E5%ED%F2%E0&all=x
http://www.gramota.ru/slovari/dic/?word=%EA%EE%EC%EF%EE%ED%E5%ED%F2&all=x

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

НУ вообще, речь идет о статье, а не о моей правильной речи. Хотя вы безусловно правы. Да и вопрос стоял не о использовании термина, а о методе представления классов системы.

по статье я уже высказался ранее, а вопрос был риторический - нетребующий ответа.

А мне понравилось. Добротная студенческая работа. Автор излагает свое текущее восприятие окружающей реальности, открывает мир и раздвигает границы своего познания. Да, наивные диаграммы и некоторые высказывания. Но для студенческого сборника очень неплохо. На прошлой неделе довелось слушать два подобных доклада на SECR-2010. Вот это было ужасно.

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

Пролистал  статью ... автору имеет смысл обратить внимание на:
1. Определение и способы применения бизнес-юзкейсов (BUC). Т.е. что есть BUC, и для чего их используют
2. Определение бизнес-требований.
3. Способы представления бизнес-требований.
4. Отличие бизнес-требований от пользовательских и функциональных требований

Юрий, спасибо за направление в нужное русло. Согласен, что нужно поглубже изучить то, что связано с бизнес-юзкейсами, да и не только это, на мой взгляд. Буду признателен, если подскажете полезную литературу для углубления знаний в данной области (на данный момент читаю Вигерса - Разработка требований к ПО, последующая литература: Коберн и Леффингуэлл).
А что касается пункта 4, то на данный момент это основной вопрос, который не даёт мне покоя. Никак не могу понять, каким образом различить бизнес-требования, требования пользователей и функциональные требования. Уверен, что вышеперечисленная мною литература даст ответы на эти вопросы, но если существует другой способ найти ответ на этот вопрос - пожалуйста посоветуйте. Хочу именно понять отличия и что именно описывать в ТЗ.

А мне понравилось. Добротная студенческая работа. Автор излагает свое текущее восприятие окружающей реальности, открывает мир и раздвигает границы своего познания. Да, наивные диаграммы и некоторые высказывания. Но для студенческого сборника очень неплохо. На прошлой неделе довелось слушать два подобных доклада на SECR-2010. Вот это было ужасно.
У Вас хороший стиль изложения. Добавить к этому опыта и знаний, и все будет отлично. Впереди еще много интересных открытий
Удачи Вам, Павел!

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