Исследование по использованию UML в организациях(Прочитано 5229 раз)
Интересное забугорное исследование по использованию UML в организациях:
http://www.projectpragmatics.com/Home/resources-for-you-1/the-uml-survey-results-are-in
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



Вот, что ответили по поводу как проводилось исследование:
Цитата: Bob Maksimchuk
Responses were solicited from numerous groups / people, no geographic limitations. The study was promoted on related LinkedIn groups, Twitter, my blog and website. This is by no means a scientific study. The sample size (i.e. number of responses) was smaller than hoped (44). I certainly had no expectations regarding precision or trends. However after publishing the results a number of people wrote to me stating their (more rigorous) research or that of others confirms the same results. This also tracks what I have seen with clients worldwide. I think Ibrahims #4 may be a prime driver in this situation.  
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



А вот ответ по поводу того, по чему UML мало используется:
Цитата: Hemant Jha
As a trainer ..my interaction with my participants(ranging from 1-20 years of experience) shows, the following are the reasons for the non usage of UML in software companies. Some of the points might look rude but it is a sad reality as well.

1) Majority of the software professionals in India don't know about UML (as much as 90%).

2)For the professionals who know about UML... They really don't know why and in which phase should UML be used? In my programs almost 99% of the people believe that UML is used in the design phase and is used for designing systems. Professionals are greatly confused between analysis and design.

3)Managers consider Analysis and UML modeling as a waste of time. Their reasoning is "If one can create systems by writing code then why draw diagrams".

4)Young software professionals are more open and excited to using UML and doing it the right way, but the top management isn't technically sound enough to understand the importance of analysis and UML and hence they don't promote the usage of the same.

5)Unfortunately the most of the people in the top management are excellent man managers (not technical managers ) only bothered about parameters like,increasing the number of billable heads and the timeline there by increasing the revenues for the company while cutting the cost as much as possible.

6)Although UML is a set of standardized graphical diagrams for modeling the structural and behavioral complexities of any software system, A myth that UML is only meant for Object Oriented Programming Languages limits its usage.

7)Knowing the syntax of UML diagrams is a much simpler task as compared to knowing the best practices of using these diagrams to understand the structural and behavioral complexity of systems. For example knowing a syntax of a class diagram is a simple task while knowing and using the best practices of structural modeling using class diagrams is a completely different ball game.

8)Even UML Diagrams need to be designed for parameters like usability, extensibility and flexibility.

9)As UML Diagrams represents the structural and behavioral complexity of a real world system (mostly business systems). By the very nature business systems are dynamic and will continuously change which will result in changes in the UML Models as well. Unfortunately I have seen people drawing UML diagrams in such a unplanned manner that with every change, their entire diagrams needs to be drawn. Ask yourself, In a highly compressed project life cycle do we have the time to re draw the diagrams again and again? This is one of the reasons why the UML diagrams and the code goes out of sync with the passage of time.

10)The time taken to draw these diagrams is also critical as well. I have seen software professional take more than a days time to draw one UML diagram while for an experienced professional, it might be a matter of minutes. Ask your self if the engineers start taking more than a day to draw a single diagram then how long will the analysis phase take and how will the project manager accommodate the same within the project life cycle.

Although these points are India specific, but I feel some of them are generic as well
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



Саша, а где отвечают и обсуждают статью?



Цитировать
1) Majority of the software professionals in India don't know about UML (as much as 90%).
Это типично и для наших специалистов. Но означает ли это, что это проблема? Возникают новые программные языки и новые технологии программирования, которые в начале не знают более 99% профессионалов. Так узнают, если поймут полезность. Дело в том пока, что полезность UML неощутима пока, несмотря на огромное количество литературы. Возможно причина в том, что большинство команд делают небольшие короткоживущие проекты и справляются со своими проблемами без всякого UML?

Цитировать
2)For the professionals who know about UML... They really don't know why and in which phase should UML be used? In my programs almost 99% of the people believe that UML is used in the design phase and is used for designing systems. Professionals are greatly confused between analysis and design.
Несовсем понял, чем уж так смущенны или запутаны эти самые профессионалы? Анализ и конструирование - две стороны одной медали.

Цитировать
3)Managers consider Analysis and UML modeling as a waste of time. Their reasoning is "If one can create systems by writing code then why draw diagrams".
Это и понятно, если диаграммы используются лишь как картинки. Хотя, если я как программист рисую блок-схемы, разрабатывая алгоритм, и сохраняю это где-то, чем будет недоволен менеджер??

Цитировать
4)Young software professionals are more open and excited to using UML and doing it the right way, but the top management isn't technically sound enough to understand the importance of analysis and UML and hence they don't promote the usage of the same.
так пусть и доказывают этому самому топменеджменту, что решение задач с помощью UML происходит быстрее. Если уж они так возбуждаются от использования UML...

Цитировать
5)Unfortunately the most of the people in the top management are excellent man managers (not technical managers ) only bothered about parameters like,increasing the number of billable heads and the timeline there by increasing the revenues for the company while cutting the cost as much as possible.
ну и что? кесарю кесарево :)

Цитировать
6)Although UML is a set of standardized graphical diagrams for modeling the structural and behavioral complexities of any software system, A myth that UML is only meant for Object Oriented Programming Languages limits its usage.
Почему миф? UML изначально и создавался как визуальный ОО язык моделирования, однако он вполне может использоваться и для других языков программирования. Я бы уж сказал, что многие части UML как раз зачастую уводят нас от ОО проектирования...

Цитировать
7)Knowing the syntax of UML diagrams is a much simpler task as compared to knowing the best practices of using these diagrams to understand the structural and behavioral complexity of systems. For example knowing a syntax of a class diagram is a simple task while knowing and using the best practices of structural modeling using class diagrams is a completely different ball game.
Ну извините, знание родного языка не делает нас великолепным писателем или поэтом. К тому же и языку слава богу учат 16 лет - сначала в школе, потом в вузах. И что - что мы видим, посмотрите на этом же форуме, некоторые двух слов связать не могут, не то, что выразить свою мысль.
Так что естественно кроме синтаксиса, нужно учить семантику и прагматику, друзья - индийцы.

Цитировать
8)Even UML Diagrams need to be designed for parameters like usability, extensibility and flexibility.
Пардон, коллега. Давайте не класть все яйца в одну корзину. Для usability - есть совершенно другие и хорошо зарекомендовавшие себя методы, хроме того в ней еще много психологии и т.п. творчества.
extensibility - это что имеется в виду, расширяемость самого UML или передача семантики расширяемости с помощью UML? Если первое - так это благо, все же ясно - бери стереотип и вперед или в этом сложность? Ну извините, сколько там диалектов у английского?


Цитировать
9)As UML Diagrams represents the structural and behavioral complexity of a real world system (mostly business systems). By the very nature business systems are dynamic and will continuously change which will result in changes in the UML Models as well. Unfortunately I have seen people drawing UML diagrams in such a unplanned manner that with every change, their entire diagrams needs to be drawn. Ask yourself, In a highly compressed project life cycle do we have the time to re draw the diagrams again and again? This is one of the reasons why the UML diagrams and the code goes out of sync with the passage of time.
Ну и? Да меняется и что? Меняете же вы программный код, когда меняются требования? Что Вы делаете? так вы как раз и изменяете модель, ведь программный код - и есть модель, выраженная на языке программирования. В чем разница. Разница в наглядности. Тогда учите своих профессионалов читать код так - словно роман на ночь, чтобы при прочтении у человека в голове сразу весь функционал высвечивался - тогда UML и им подобные системы не нужны, согласен...

Цитировать
10)The time taken to draw these diagrams is also critical as well. I have seen software professional take more than a days time to draw one UML diagram while for an experienced professional, it might be a matter of minutes. Ask your self if the engineers start taking more than a day to draw a single diagram then how long will the analysis phase take and how will the project manager accommodate the same within the project life cycle.
Это уже дело технологий. Да первый раз сделать это сложно, и второй и возможно третий. Все это понятно. Программа - идеальная спецификация самой себя, но как говорится смотри выше. К тому же совсем не обязательно наверняка все поддерживать в идеально согласованном виде. Тут так же как и в программирования постепенно будет формироваться системный общеупотребительный уровень и некий прикладной авторский. Удачные решения будут переходить в разряд рекомендуемых или обязательных.

Знаете чем отличаются программисты 60-80 годов прошлого столетия от нынешних вундеркиндов. Нашим дедам приходилось продумывать свою программу до мелочей заранее, исправляй потом ошибку на перфоленте или перфокарте и жди очереди. Потому они делали гораздо меньше ошибок и тщательно продумывали свои решения. Сейчас проще программировать методом проб и ошибок, а порой и вообще сваливать "отладку" на тестировщиков и аналитиков, принимающих исполнение задачи.

Что-то говорит мне, дело в другом. Да не знают, но почему не хотят узнать?



Саша, а где отвечают и обсуждают статью?
В LinkedIn:
http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&discussionID=22510303&gid=144346&commentID=21054067&trk=view_disc

Просто не у всех есть там логин и соответственно доступа.
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



В LinkedIn:
http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&discussionID=22510303&gid=144346&commentID=21054067&trk=view_disc
Группа-то какая?
Просто не у всех есть там логин и соответственно доступа.



Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.




 

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