Статья "Методы и средства программной инженерии при проектировании ИИС"(Прочитано 11130 раз)
Доброго времени суток, уважаемые участники сообщества системных аналитиков!

На данный момент я работаю в одной из самарских компаний, занимающейся разработкой ПО, в должности бизнес-аналитик. Работаю с недавних пор. В 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. Архитектура и платформа тоже определяется на этапе моделирования, а не после кодирования.

I will use Google, before asking dumb questions !!!



Прочитал. Есть некоторые замечания:
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. Тогда лучше использовать понятие модуль или компонента, ну или уровень декомпозиции.
I will use Google, before asking dumb questions !!!



Только для того, что бы определить Концепцию, нужно собрать требования, только более высокого уровня :)
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



Цитата: LastLegion86
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. Отличие бизнес-требований от пользовательских и функциональных требований
"Politics is the art of looking for trouble, finding it, misdiagnosing it, and then misapplying the wrong remedies" (c)
Мой блог
http://www.yurybuluy.blogspot.com/



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

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

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

НУ вообще, речь идет о статье, а не о моей правильной речи. Хотя вы безусловно правы. Да и вопрос стоял не о использовании термина, а о методе представления классов системы.
I will use Google, before asking dumb questions !!!



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



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

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



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

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




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19