Форум Сообщества Аналитиков
Общий раздел => Примеры => Тема начата: Kulgar от 22 Января 2014, 16:57:08
-
Доброго времени суток.
Есть проект, который будет включать в себя программно-аппаратный комлекс. Сам я программист. С такими большими проектами дел не имел. До этого справлялся наброском "в тетрадке". Однако, теперь без UML не обойтись. В сети нашёл множество сайтов по этой тематике. Однако, между ними множество различий, которые со стороны вовсе не понятны. Пытаюсь составить диаграммы в Visio 2010. Возникает множество попутных вопросов, которые хаотическим гуглением не решаются, а наооборот запутываются.
Вроде это полный комлпект UML диаграмм:
- Use case diagram (диаграммы прецедентов)
- Deployment diagram (диаграммы топологии)
- State Maсhine diagram (диаграммы состояний)
{Statechart diagram (диаграмма состояний) / Activity diagram (диаграммы активности)}
- Interaction diagram (диаграммы взаимодействия)
- Sequence diagram (диаграммы последовательностей действий)
- Collaboration diagram (диаграммы сотрудничества)
- Class diagram (диаграммы классов)
- Component diagram (диаграммы компонентов)
Без чего из этого списка можно обойтись, а что нужно обязательно?
P.S. Подскажите, пожалуйста, простенькую книжку для начинающих актуальную для UML 2.2.
-
...
Без чего из этого списка можно обойтись, а что нужно обязательно?
P.S. Подскажите, пожалуйста, простенькую книжку для начинающих актуальную для UML 2.2.
У моих коллег будут другие мнения, я выскажу свое:
Обойтись можно безо всех. Но некоторые удобны для каких то иллюстраций.
- * Чаще других я использовал диаграмму состояний.
- * В том или ином виде использовал диаграмму размещения.
- * Диаграмму юзкейсов не использую, хотя юзкекйсы пишу очень часто. Может быть это связано с тем, что я обычно работаю с довольно большими проектами. Предпоследний продукт, с которым я работал это около 12 000 юзкейсов уровня моря, а для такого числа диаграмма получится несколько большой. Да и структурирование с использованием оглавления и обобщенных вариантов мне кажется более наглядным.
- По "Диаграмме классов" согласен с мнением одного классного программиста: "можно использовать для анализа кода после написания такового. Создание до написания кода - бессмысленно".
- Вместо диаграммы активности предпочитаю EPC.
В Visio UML реализован "не очень". Лучше использовать что-то специализированное. Мне нравилась visual paradigm, но на вкус и цвет все фломастеры разные.
-
До этого справлялся наброском "в тетрадке".
А что теперь изменилось?
Однако, теперь без UML не обойтись.
Какая цель применения UML в проекте и почему именно UML?
P.S. Подскажите, пожалуйста, простенькую книжку для начинающих актуальную для UML 2.2.
Изучение самой нотации (в отрыве от принципов ООАП), мало что дает. Лучше почитать что-нибудь типа Джим Арлоу, Айла Нейштадт - UML 2 и унифицированный процесс. Еще на uml2.ru присутствует список рекомендуемой литературы.
-
В качестве справочного пособия, но не как руководство к действию подойдет uml-diagrams.org.
Разные диаграммы нужны для разных ситуаций. Если диаграмма нужна для того, чтобы объяснить свое решение - одна ситуация, если нужно тщательно задокументировать, чтобы повторно использовать, распространить - другая ситуация, если Вы конструируете на основе имеющегося фреймворка - третья.
У нас , поскольку решение, строится на базе платформы, в основном используют диаграммы классов.
-
Доброго времени суток.
Есть проект, который будет включать в себя программно-аппаратный комлекс. Сам я программист. С такими большими проектами дел не имел. До этого справлялся наброском "в тетрадке". Однако, теперь без UML не обойтись. В сети нашёл множество сайтов по этой тематике. Однако, между ними множество различий, которые со стороны вовсе не понятны. Пытаюсь составить диаграммы в Visio 2010. Возникает множество попутных вопросов, которые хаотическим гуглением не решаются, а наооборот запутываются.
Вроде это полный комлпект UML диаграмм:
- Use case diagram (диаграммы прецедентов)
- Deployment diagram (диаграммы топологии)
- State Maсhine diagram (диаграммы состояний)
{Statechart diagram (диаграмма состояний) / Activity diagram (диаграммы активности)}
- Interaction diagram (диаграммы взаимодействия)
- Sequence diagram (диаграммы последовательностей действий)
- Collaboration diagram (диаграммы сотрудничества)
- Class diagram (диаграммы классов)
- Component diagram (диаграммы компонентов)
Без чего из этого списка можно обойтись, а что нужно обязательно?
P.S. Подскажите, пожалуйста, простенькую книжку для начинающих актуальную для UML 2.2.
Зависит от цели, которую вы перед собой ставите. Если нужно моделировать устройство и поведение объектов, то самые распространённые и удобные:
- диаграмма состояний (state machine diagram aka диаграмма конечного автомата), показывающая возможные состояния объекта и пути перехода из одного состояния в другое;
- диаграмма деятельности (activity diagram aka блок-схема алгоритма), показывающая последовательность выполнения и условия переходов;
- диаграмма последовательности (sequence diagram - неудачное название), показывающая порядок взаимодействия между объектами.
Диаграмму последовательности правильнее было бы назвать диаграммой взаимодействия (interaction diagram), но это название уже оказалось занято другой диаграммой, которую использовать я очень не рекомендую из-за её неудобочитаемости. Они показывают одно и то же, но sequence diagram использует ось времени для изображения последовательности действий, а на interaction diagram порядок действий показывается цифрами возле стрелок - читать невозможно, буэ.
Их, на самом деле, достаточно в большинстве случаев. Они были изобретены задолго до UML, интуитивно понятны и знакомы большинству людей с техническим образованием. По моему мнению, специфичными для UML элементами в них лучше не злоупотреблять.
Для более высокого уровня абстракции (обзор системы, выявление требований) ещё очень полезны диаграммы:
- диаграмма вариантов использования (use case diagram) - позволяет проиллюстрировать, что кому из пользователей нужно от системы. Приверженцы модели use case в этом месте могут возмутиться, но imho возможности применения этой диаграммы простираются далеко за пределы собственно вариантов использования. С её помощью можно анализировать и возможности, и функции, и ожидания от системы, и ещё много чего.
- диаграмма развёртывания (deployment diagram) - позволяет проиллюстрировать, как логические объекты соотносятся с физическими (например, какие программные компоненты на каких серверах выполняются).
Если нужно документировать нижний, программный, уровень, то пригодятся диаграммы классов и пакетов. Они, на самом деле, тоже были изобретены до UML, но тут уже следование нотации может оказаться полезным. Это не столько диаграммы, сколько визуально структурированный текст.
Когда вы продумываете структуру классов, диаграммы классов можно рисовать на бумаге и потом выбрасывать, а то, что пойдёт в документацию, лучше генерировать прямо из кода.
-
Есть проект, который будет включать в себя программно-аппаратный комлекс. Сам я программист. С такими большими проектами дел не имел. До этого справлялся наброском "в тетрадке". Однако, теперь без UML не обойтись.
Поверьте человеку, на чьей совести изрядное количество программно-аппаратных комплексов, включая немаленькие и довольно ответственные. Без UML прекрасно можно обойтись, и обходимся в 9 случаях из 10 (в десятом в рядах заказчика или руководства разработчика оказывается эстет, и...).
Послушайте совета: если столкнулись со сложной и неизвестной задачей, не усложняйте себе жизнь еще и изучением модных фасонов бантиков (со сбором всех причитающихся новичку граблей). Забот и так хватит.
Ну а если "иначе никак", то коллеги с сайта подсказали, где читать. :)
-
В Visio UML реализован "не очень". Лучше использовать что-то специализированное. Мне нравилась visual paradigm, но на вкус и цвет все фломастеры разные.
Спасибо. Возьму на заметку.
А что теперь изменилось?
Теперь проект в разы стал больше. :)
Какая цель применения UML в проекте и почему именно UML?
Цель, наверно, в первую очередь вспомогательная/наглядная, возможно для отчётности. Что-то мне в голову не приходит ни одна альтернатива. А UML и в университете изучал. Что-то помню.
Изучение самой нотации (в отрыве от принципов ООАП), мало что дает. Лучше почитать что-нибудь типа Джим Арлоу, Айла Нейштадт - UML 2 и унифицированный процесс. Еще на uml2.ru присутствует список рекомендуемой литературы.
Это я запишу.
В качестве справочного пособия, но не как руководство к действию подойдет uml-diagrams.org.
Не по-русски владею. Но лучше бы по-русски.
диаграмма нужна для того, чтобы объяснить свое решение
нужно тщательно задокументировать, чтобы повторно использовать, распространить
Вот эти две ситуации какие диаграммы охватывают?
2 greesha
Хорошо написали. %) С первого раза не понял.
Мне бы что-нить попроще. В том плане, что Ваши советы идут через годы наработки "правильных" путей до "нужных". Я ещё "правильные" толком не знаю. Не думаю, что смогу сразу начать с "ныжных".
Я литературу спрашиваю, чтобы хоть какой-то академический базис заиметь. И уже на его основе суметь выбирать подходящее мне.
Ну а если "иначе никак", то коллеги с сайта подсказали, где читать. :)
Проект большой. Людей мало. Без структурного подхода приступать к написанию программы - методом проб и ошибок будем очень долго идти. Хоть какая-то системная аналитика должна быть. На сколько я понимаю самый простой вариант - UML диаграммы. Если есть более простой в разработке и наглядный в представлении сервис структурирования на этапе предпроекта, я только "за"!
-
Без структурного подхода приступать к написанию программы - методом проб и ошибок будем очень долго идти. Хоть какая-то системная аналитика должна быть.
UML это крутой инструмент из числа многих. Структурный подход и системная аналитика - содержимое головы.
Если есть более простой в разработке и наглядный в представлении сервис структурирования на этапе предпроекта, я только "за"!
Графический? Например, схемы вида "прямоугольник-стрелка-ромбик". С подписями, что есть что.
-
Теперь проект в разы стал больше. :) Цель, наверно, в первую очередь вспомогательная/наглядная, возможно для отчётности. Что-то мне в голову не приходит ни одна альтернатива. А UML и в университете изучал. Что-то помню.
Проект большой. Людей мало. Без структурного подхода приступать к написанию программы - методом проб и ошибок будем очень долго идти. Хоть какая-то системная аналитика должна быть. На сколько я понимаю самый простой вариант - UML диаграммы.
Цель использования UML так и не была четко сформулирована. Чем будут по Вашему отличаться проект без UML и с ним? Что потеряет проект если Вы не
будете применять UML? Какую проблему вы хотите решить с помощью UML?
-
Вот эти две ситуации какие диаграммы охватывают?
Надеюсь, контекст вопроса не потеряется. Понимаете, нельзя говорить так говорить. Ведь я писал довольно обще, а ситуации у вас конкретные.
Вы хотите объяснить решение. Сразу вопрос какое? Изобразить некую структуру классов, которая описывает структуру хранилища. Или показать реализацию некоторого варианта использования. А может вы хотите показать изменения состояний объекта? Тогда можно сделать диаграммой класса. Вы хотите описать алгоритм метода класса, или некоего аспекта - можно диаграмму активностей. Хотите показать взаимодействие объектов и проверить соответствия принципам GRASP или SOLID - Диаграмма последовательности или диаграмму коммуникации. Хотите показать как будут взаимодействовать модули, компоненты системы.
Документирование может потребоваться: вы хотите использовать данное решение в будущем, вы общаетесь с другими людьми, готовыми и умеющими читать UML, вам нужно для себя: как репозиторий решений.
Диаграмма классов - отражение детальной структуры решений
Диаграмма компонентов - отражение архитектуры решения
Диаграмма развертывания - отражение архитектуры решения и физического расположения частей системы
Диаграмма пакетов - для борьбы со сложностью - декомпозиция, структура программы
Диаграмма объектов - для анализа структуры классов
Диаграмма последовательности, диаграмма автоматов, диаграмма деятельности - для отражения поведенческих аспектов программы.
Диаграмма вариантов использования - для отражения функциональности системы с точки зрения внешних по отношению к ней сущностей, определение внешнепроявляемых функций системы, ее интерфейсов: программных или графически пользовательских.
Часто можно следовать такому пути: строить модель предметной области (статический и динамический аспекты), строить модель приложения (платформы, фреймверка), потом построить мостик соответствия элементов первой модели второй.
Но, мне кажется, пока самый дельный совет - совет Леонида :)
Возможно вы планируете использовать MDD или MDA.
По-русски могу присоветовать (но там начало и не все) book.uml3.ru
-
Мне системная аналитка интересна как таковая. В данный момент я в ней вижу возможность более продуктивного написания кода и, что гораздо более важнее, возмоность избежать тупиков.
Графический? Например, схемы вида "прямоугольник-стрелка-ромбик". С подписями, что есть что.
Да, именно так. Вместе с наличием хоть сколько-нибудь стандартизованного аппарата.
Вот весьма любопытно, а как разрабатывают программы в тот же самом Google?
Чем будут по Вашему отличаться проект без UML и с ним? Что потеряет проект если Вы не будете применять UML? Какую проблему вы хотите решить с помощью UML?
Без UML он будет долгим, сложным для понимания извне (сторонними людьми, новыми членами команды), а со временем возможно и изнутри (собственно самой командой).
Потеряет целостную структуру, единое видение.
Проблему наглядности в основном - чтобы можно было легко понять в каком именно блоке следует искать недочёт, в какой именно блок правильнее сделать дополнение и т.д.
2Galogen
Спасибо. :) В общем Вы весьма подробно описали.
Полагаю мне стоит прибегнуть к декомпозиции и перефразировать свой основой вопрос так:
С чего начать? Вот я "совершенно ничего" не понимаю в UML. Но хочу научиться. Какую первую диаграмму мне лучше разработать для своего проекта? И какая литература мне в этом поможет?
-
Без UML он будет долгим, сложным для понимания извне (сторонними людьми, новыми членами команды), а со временем возможно и изнутри (собственно самой командой).
Потеряет целостную структуру, единое видение.
Проблему наглядности в основном - чтобы можно было легко понять в каком именно блоке следует искать недочёт, в какой именно блок правильнее сделать дополнение и т.д.
Добрый день!
Мне кажется в этом моменте самое главное заблуждение.
С чего вы взяли что с UML он станет проще для понимания? Для этого необходимо, чтобы все ( все кто участвует в проекте) знали UML не хуже вас. Подумайте сами, так ли это?
У меня в компании например разработчики не знают UML. А вот блок-схемы проходили в школе все. По этому общий язык я нахожу с ними именно через них. Простые схемы со стрелочками, и подробным описанием что и зачем визуализируем.
Возможно кто-то сочтет это примитивным, но вздумай я строго следовать UML или допустим BPMN - это только усложнит общение с разработчиками и замедлит проект.
Новая нотация - это большой риск для проекта, который обязательно сыграет.
Ну и само собой картинки и диаграммы - это не самоцель. Без грамотного сопроводительного текста - они бесполезны.
Задача аналитика (несколько упрощая конечно) - выявить то что нужно заказчику и донести это разработчику без потерь.
UML просто инструмент. И если честно, из ваших сообщений я не увидел насущной необходимости использовать именно этот инструмент.
-
Мне кажется в этом моменте самое главное заблуждение.
С чего вы взяли что с UML он станет проще для понимания? Для этого необходимо, чтобы все ( все кто участвует в проекте) знали UML не хуже вас. Подумайте сами, так ли это?
Может я и заблуждаюсь. ???
Тогда какая альтернатива? Не именно UML, а вообще для упрощения разработки "большого" проекта.
-
Может я и заблуждаюсь. ???
Тогда какая альтернатива? Не именно UML, а вообще для упрощения разработки "большого" проекта.
Как говорится, слона надо есть по частям.
Ключ к успеху крупного проекта - грамотная декомпозиция задач.
Сначала делается общее видение проекта (аналитиком или ПМом), в котором охвачены все границы проекта. Этот документ - охватывает весь проект.
В нем упор идет на бизнес-цель и бизнес-процессы. Видение как раз подходящий документ для красивых и больших картинок, которые так любят руководители:)
Потом проект разбивается на задачи, каждая из которых делается отдельно.
Каждая задача прорабатывается документально, так, чтобы она была целостной, законченной и результат выполнения задачи был проверяем.
Каждому разработчику выдается своя задача со своим набором документации. По мере выполнения, разработчики заливают выполненные задачи в проект, наращивая функционал. Тестеры проверяют функционал согласно написанной документации.
В итоге, выполнение всех задач проекта приводит к выполнению самого проекта. Как бусинки на ниточку.
Правда это все к аналитике имеет весьма опосредованное отношение:)
А уж какие конкретно картинки нарисованы в ТЗ к каждой конкретной задаче - это дело личное, исключительно между заказчиком, аналитиком и разработчиком. И дело должно быть направлено не на следование формальной нотации, а на максимально качественное выявление и описание требований, если говорить об аналитике.
-
Спасибо. :) В общем Вы весьма подробно описали.
Полагаю мне стоит прибегнуть к декомпозиции и перефразировать свой основой вопрос так:
С чего начать? Вот я "совершенно ничего" не понимаю в UML. Но хочу научиться. Какую первую диаграмму мне лучше разработать для своего проекта? И какая литература мне в этом поможет?
Понимаете, это сложный момент. Нет однозначного ответа. Есть некоторые рекомендации в рамках некоторого подхода или практики. Опять же многое зависит от того этапа, на котором вы находитесь.
Вообще следует начинать с методологии. Ясное понимание методологии и обстоятельств дела, вероятно, подскажет стоит ли использовать UML. В любом случае вам следует отразить статический и динамический аспект системы. Какова последовательность - подскажет ситуация, работайте с той информацией, что имеется, формализуя ее.
Если вы начинаете с моделирования и анализа требований, то типично начинать с моделирования использования - диаграмма вариантов использования и текстовое их описание, поведенческие моменты (технологический процесс обработки информации, или описание БП) можно выполнять с использование диаграммы деятельности, статическую структуру (словарь предметной области) изображаем диаграммой классов. ДК может быть использована и для начального представления системы, если сразу имеется идея ее композиции. Все это производится циклически, итерационно. Главное, чтобы все модели были согласованы.
Скорее всего вы будете начинать не с пустого места, потому, вполне возможно, первое, что следует сделать, это продумать структуру проекта, произвести декомпозицию.
Как говорится it depends
Книги, их много, кк на русском, а еще больше на английском
Дж.Рамбо, М.Блаха. UML 2.0. Объектно-ориентированное моделирование и разработка. (2-е изд.)(2007)
E'dvard Jordon, Karl Argila. Ob~ektno-orientirovannyj analiz i proektirovanie sistem (2007)(K)(300dpi)(284s)
Shablony_realizacii_korporativnyh_prilozhenij._Kent_Bek
use-case-driven-object-modeling-with-uml-theory-and-practice.9781590597743.27892
uml2 and the unified process 2ed RUS
applying-uml-and-patterns-an-introduction-to-object-oriented-analysis-and-design-and-iterative-development-third-edition.9780131489066.16053
Booch_eng_3ed
-
Ключ к успеху крупного проекта - грамотная декомпозиция задач.
Сначала делается общее видение проекта (аналитиком или ПМом), в котором охвачены все границы проекта. Этот документ - охватывает весь проект.
В нем упор идет на бизнес-цель и бизнес-процессы. Видение как раз подходящий документ для красивых и больших картинок, которые так любят руководители:)
Хм. Вот эти "документы" мне бы и разработать. Только с Ваших слов мне не совсем ясно как и что именно входит в каждый.
Говоря о слонах... До начала обсуждения на этом форуме я его и видел. А теперь передо мной стадо слонов. И каждого надо есть по частям... :-\
И дело должно быть направлено не на следование формальной нотации, а на максимально качественное выявление и описание требований, если говорить об аналитике.
Ясно. Буквоедство плохо. Понимание реалий, живых тенденций хорошо.
С какой стороны начать?... Вот в программировании, условно скажем, в начале изучаются лексические основы языке, далее структуры обработки информации (линия, ветвление, цикл) и т.д. Вот что мне именно отрезать у слона и съесть первым?
-
Понимаете, это сложный момент. Нет однозначного ответа. Есть некоторые рекомендации в рамках некоторого подхода или практики.
Вы граммотный специалист. Возможно даже слишком. :) Для моего случае. По крайне мере у меня складывается ощущение, что Вы ведёте речь о красоте высокого слога Пушкина для того кто не умеет читать. (Воспринимание поэзии на слуг отбрасываем.)
Я понимаю, что задачи решаемые системными аналитками сложные. Я понимаю, что они даже сложнее, чем я могу понять. Но я не могу уделить этому вопросу достаточное количество времени, чтобы именно овладеть этой профессией сейчас. Может это в некоторой степени и грубо, неуважительно по отношению к Вашему труду. Однако, это не моя прихоть. Возможно в будущем я и стану системным аналитиком. Только сейчас нужен результат и нужен быстро.
Посему с десяток книг эт, конечно, хорошо, но мне бы одну. Чтобы начать.
Читаю http://book.uml3.ru - может позже смогу более точно "понять" что мне нужно.
-
Как говорится, слона надо есть по частям.
Ключ к успеху крупного проекта - грамотная декомпозиция задач.
Хотелось бы дополнить... Разделение на части начинается на уровне аналитика. Функциональные требования делятся на фичи и варианты использования. В свою очередь ВИ делятся на потоки. Разработчики, дизайнеры, архитекторы, тестировщики также работают с каждым ВИ или потоком ВИ в отдельности. На уровне архитектуры/дизайна система также разбивается на части - слои, подсистемы, компоненты, сервисы. Таким образом, работая с каждой частью в отдельности, слон съедается частями.
-
Я понимаю, что задачи решаемые системными аналитками сложные. Я понимаю, что они даже сложнее, чем я могу понять.
Задачи не сложнее, чем решает программист (а лично на мой взгляд - даже проще). Просто в другой плоскости.
Но я не могу уделить этому вопросу достаточное количество времени, чтобы именно овладеть этой профессией сейчас... сейчас нужен результат и нужен быстро.
...Посему с десяток книг эт, конечно, хорошо, но мне бы одну. Чтобы начать.
Вы всерьез вознамерились заняться боксом по книге? С намерением "прям завтра" выйти на профессиональный ринг (пусть даже всего на один матч)? Последствия представляете? Ну, для тех, кто на Вас поставит и лично для Вас?
Наймите на проект аналитика, хоть бы и задорого. С условием, что будете крутиться возле него, задавать глупые вопросы и получать непонятные ответы. Так у проекта будет шанс. И у Вас тоже. В противном случае можно с хорошей вероятностью ожидать, кто будет назначен виноватым за провал проекта, испортит себе карму и репутацию.
-
Только сейчас нужен результат и нужен быстро.
Полностью соглашусь с Леонидом. Он высказал похожие на мои мысли. Впрочем они очевидны.
Спрошу лишь. Можете ли вы точно объяснить
1 - какой результат вам нужен
2 - почему быстро
Спасибо.
-
Хм. Вот эти "документы" мне бы и разработать. Только с Ваших слов мне не совсем ясно как и что именно входит в каждый.
Говоря о слонах... До начала обсуждения на этом форуме я его и видел. А теперь передо мной стадо слонов. И каждого надо есть по частям... :-\
Состав документа - это уже проще и можно посмотреть в википедии.
Главная проблема у вас, как я понял, не знаете за что схватиться первым. Для этого я стащил из интернета картинку, которую приложу к цитате ниже.
Ясно. Буквоедство плохо. Понимание реалий, живых тенденций хорошо.
Воистину так!
С какой стороны начать?... Вот в программировании, условно скажем, в начале изучаются лексические основы языке, далее структуры обработки информации (линия, ветвление, цикл) и т.д. Вот что мне именно отрезать у слона и съесть первым?
Теперь о главном.
Вот картинка из книги Вигерса, которую я стащил откуда-то. Ей сто лет в обед, но она не теряет актуальности.
(http://pro100pro.com/wp-content/uploads/2008/06/wigers-trebovaniya2.jpg)
1. Функционал всегда отталкивается от бизнеса. Никто не разрабатывает коммерческое ПО просто так, ради опыта или использования крутых технологий.
2. Самое первое - надо понять что будет делать ПО. Т.е. какую глобальную бизнес-потребность оно будет удовлетворять.
3. Как раз эти бизнес-требования и записываются в видение проекта в документ "об образе и границах проекта".
4. Когда такой документ создан, следующий шаг - определение функционала, который удовлетворит бизнес-цель.
5. Для того чтобы определить весь нужный функционал, надо общаться с заинтересованными лицами. Можно использовать например диаграмму вариантов использования из UML. А можно и не использовать:)
6. Когда функционал определен, он разбивается на задачи. Под каждую задачу пишется ТЗ. Разработчики разрабатывают, тестеры тестируют. Дальше уже дело техники.
И последнее. То что сейчас нужно - просто влезть в дело с головой. Как только начнешь делать что-то на практике, появится прогресс, появятся конкретные вопросы по конкретным процессам. Пойдет дело:)
-
...Никто не разрабатывает коммерческое ПО просто так, ради опыта или использования крутых технологий.
Маленький оффтоп.
Жизненный опыт подсказывает, что порядка 2/3 личного состава команд разработки (от тестировщика до руководителя проекта) именно этим и занимаются. :)
-
Маленький оффтоп.
Жизненный опыт подсказывает, что порядка 2/3 личного состава команд разработки (от тестировщика до руководителя проекта) именно этим и занимаются. :)
Печально, если так!
Хорошо, я уточню формулировку:)
Никто не заказывает коммерческое ПО просто так, ради опыта или использования крутых технологий.
-
Спасибо, добрые люди! ;) Я ценю Ваше мнение. Долго не отвечал потому что, во-первых, у меня отвалилось оповещение о новых сообщениях в теме, во-вторых, в ближайшее время мне нужно решить несколько иную задачу. Надеюсь после вернусь к аналитике.