Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - AlexTheRaven

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 »
106
Нововведения / Объектная прививка?
« : 14 Января 2008, 21:00:12 »
Задача просто замечательная, и не обязательно паскалевская. Одних паттернов к ней прикрутить можно - косой десяток, и добрая половина из них будет к месту :) .
Про бонус... IMHO лучше - нещадно, на 2 балла, штрафовать не использующих, но предупредить об этом в самом начале :).
Про культуру - IMHO это от отвращения к учёбе, своей профессии и работе вообще. Лучше бы шли в музыканты или бармены. Мало их на первых курсах [вы]гоняли. Хотя, возможно, их просто с самого начала плохо учили.

107
Я тоже рад, что вроде бы "переварил" задачи, которые на меня упали, и у меня освободились некоторые временнЫе ресурсы и вычислительные мощности для обмена опытом :) .
У Золотухиной - вполне работоспособная методология, но мне НЕ нравится использовать UML для описания бизнес-процессов. Activity, Sequence и Collaboration не имеют такой выразительности, как eEPC. Действительно, при помощи собственных стереотипов экземпляров и связей можно показать всё то же самое, но удобство не то: в ARIS eEPC, по сути, все необходимые стереотипы уже введены, исполнителей можно показывать не только с помощью swimlanes.
Опять же, ARIS Toolset как инструмент значительно удобнее CASE-средств, специализированных для UML, имеет модули Simulation, ABC, BSC и др. В UML CASE-средстве создаётся схема БП, а в ARIS - визуальное изображение мат. модели БП, готовое к мат. анализу и имитационному моделированию.

108
Нововведения / Объектная прививка?
« : 14 Января 2008, 01:18:04 »
Да они сразу должны мылсить объектно, структурно как минимум. Почему не получается? Потому как такова система образования (по крайней мере на нашей кафедре). Что очень жаль.
Потому для них структурный код или ОО код - неестественный :(
А ведь стоит учесть еще и тот факт, что это 5 курс после сдачи квалификационной работы на бакалавра!!!
Alex, давайте не будем путать божий дар с яичницей. Все-таки курс у меня другой, задача подобная бух учету решается на 3 курсе в рамках соотвествующих дисциплин - смотрите мои опыты преподавания в разделе Обучения.
Прадва бухучета у них нет как предмета, что конечно сильно жаль.
Возможно, звучит как ересь, но объектное мышление (интересно, а как ещё можно мыслить?) и ООП - не одно и то же. Да и ООП имеет границы применения:
1) Дополнительная, по сравнению с процедурным программированием, сложность разработки и отладки должна быть оправдана. А ведь алгоритм прост и, судя по тому, что задачи изначально рассчитаны на Pascal, они замечательно решаются в процедурном подходе.
2) Разработка должна быть рассчитана на повторное использование - а ведь студенты знают, что их код после сдачи контрольной никогда никому не пригодится.

IMHO если так уж хотите увидеть ООП, нужно:
1) сказать: идеально работающее решение без ООП - максимум на тройку;
И/ИЛИ
2) потребовать, чтобы предметная область включала большое количество экземпляров сложных классов, у каждого из которых - разные свойства и методы (например, моделирование боя и большое количество различных боевых единиц);
И/ИЛИ
3) сказать, что для решения нельзя использовать язык, на котором простые задачи решаются простыми средствами (нельзя использовать PHP, Delphi или VB; можно использовать C++ и Java).

(1) и (3) я считаю искусственным навязыванием архитектуры, что может вызвать у программиста приверженность к необоснованно сложным решениям. Когда такие приходят - их приходится мучительно переучивать.

На всякий случай: ООП начал особенно хорошо развиваться, когда начали развиваться GUI. Действительно, рисовать GUI без объектов "глиф" сложно. А ядра всех ОС (хотя проскакивало что-то экзотическое...) и серверные части большинства "старых" приложений (в т.ч. SAP R/3) написаны без применения ООП, хотя ООП тогда уже было - при этом замечательно работают и неплохо развиваются.

109
<...>Около 2х месяцев назад поставили передо мной задачу по необходимости описания бизнес процессов деятельности штатного отделения одного из медицинских учреждений. Была оговорена цель моделирования, необходимая точка зрения и требуемые границы модели, а также конкретный субъект описания. Решил попробовать сделать по методичке от Золотухиной (скачал у Вас с сайта). Согласно ее рекомендациям, иерархия пакетов бизнес сущностей должна повторять соответствующую иерархию пакетов бизнес процессов (бизнес сущности моделируются в разбивке по бизнес процессам). Однако при построении иерархии бизнес процессов так получилось, что один и тотже object из колонки входной/выходной информации диаграммы потока работ упоминается в разных пакетах одновременно. Получается, что и при разработке моделей бизнес сущностей данный object также должен фигурировать в разных пакетах? Я планирую описать конкретный object только в одном пакете, а в остальные просто ссылки покидать на него. Так можно? В методичке это не упоминается, там конкретный пакет содержит только уникальные для него объекты.
Так вполне можно. Правда, мой практический опыт основывается только на курсовой, который Елена Болеславовна нам в своё время давала в качестве курсовой.

Лично мне не нравится применять UML для моделирования бизнес-процессов. Может, потому, что Скворцов читал нам моделирование бизнес-процессов при помощи ARIS уже после того, как Золотухина читала то же самое при помощи UML.

Советую Вам использовать если не ARIS Toolset, то хотя бы Visio, чтобы смоделировать Ваши бизнес-процессы с помощью моделей в нотациях ARIS VAD, eEPC, Organizational Chart, ERD.

110
<...>Для проверки знаний устраиваю контрольные. Алгоритмы простенькие. Задачки беру из методички 1 курса по паскалю. Естественно прошу реализовать на РНР, и не просто реализовать а постараться показать свою профпригодность. Куда-там! сплошной линейный код с кучей условий и циклов, в лучшем случае кто-то сруппирует это по функциям и то совершенно не корректно: каждой функции свое действие. Про использование объектов - вообще молчу. Хотя мой выстраданный пример - бери и пользуйся. Сложно мыслить объектно!
<...>
Всё правильно. Студенты - умные и ленивые, алгоритмы простые, ресурсы (особенно временнЫе) у них на контрольной ограничены. Вот они и идут более естественным способом. Вот если бы Вы разделили их на команды и дали каждой команде огромный курсовик (есть у них бух. учёт? ИС бух. учёта) - могли бы увидеть как минимум структурное программирование и правильную разбивку по функциям.

111
По поводу UML вместо естественного языка:
- наверное, это возможно - все ведь помнят мат. анализ с его интернациональным формальным языком (хотя, как выясняется, у каждого математика - свой диалект этого языка);
- это расходится с agile методологиями, в которых, как известно, главный носитель знаний - не документ, а человек;
- созданная модель будет понятна только архитекторам (хотя бы "по совместительству"); как объяснять новому участнику команды, о чём вообще эта модель без слов - не представляю; а ведь модель как раз и нужна, чтобы её ВСЕ использовали в виде справочника.

112
RUP EUP AUP OpenUP / Re: Как Agile вытесняет RUP
« : 13 Января 2008, 14:24:05 »
IMHO потому, что маленьких (до 1 года, до 10 человек) проектов, в которых agile методологии эффективны, больше, чем крупных, в которых они вообще неприменимы.

113
Вот никто не написал, что чтобы научиться управлять, нужно сначала научиться подчиняться, а именно:
- выяснять, уточнять, разбивать, оценивать и выполнять собственные задачи;
- обсуждать свои задачи, отстаивать своё мнение, ОТКАЗЫВАТЬСЯ от задач, если они представляются невыполнимыми;
- понимать, от результатов каких задач других участников команды они зависят - и чьи задачи зависят от ваших результатов;
- "показывать лицом" результаты своей работы;
- передавать свои задачи, контролировать их выполнение, работать с "новичками";
- выстраивать отношения с другими участниками команды, не выходить из себя, использовать аргументы вместо чёрной риторики (повышенных тонов, перехода на личности, лишения собеседника возможности вставить слово и т.д.).

Но всему этому учиться просто ДОЛГО, а деньги хочется получать прямо сейчас (кстати, ни разу не видел ситуации, когда подчинённый, будь он хоть трижды ведущий разработчик, получал бы больше своего ПМа). Вот и получается, что ПМов много, а работать некому :) .

114
Сначала Sparx Systems Enterprise Architect (связь с UC, функциональность, навигация), затем, при необходимости, MS Visio (эргономика, дизайн, даже "работающий" прототип - с элементами-ссылками).

Пробовал MS PowerPoint с анимацией. Красиво, но времени уходит столько, что проще настоящий интерфейс средствами IDE сделать сделать. Что неправильно: во избежание двойной работы программировать должны программисты.

115
Я считаю, что ТЗ - документ, фиксирующий предварительную договорённость относительно обязательств разработчика. Элементы концепции, варианты использования и требования там нужны в объёме и абстракции, позволяющих зафиксировать рамки системы, и не больше. Описание архитектуры и средств реализации - только для соответствия стандартам, поэтому - максимально абстрактное. Описания бизнес-процессов там не нужны - как описать рамки ориентированной на БП системы, если БП до этого не изучены? Зачем пытаться уместить всё в ТЗ - есть много других документов :) .
Но с другой стороны, практика - главный критерий всего. Если у Вас есть положительный опыт создания, утверждения и использования ТЗ, включающего всё выше перечисленное, этим опытом обязательно нужно поделиться.

116
Проектирование / Re: UML и MVC
« : 11 Октября 2007, 00:04:31 »
На этапе проектирования реализации. После проектирования структуры бизнес-объектов и алгоритмов их обработки. В общем, когда дело доходит до внешних интерфейсов системы, в т.ч. пользовательских.

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

<...> Все такие как то тяжело перейти от теории к практике и начать использовать UML. Возьмем задачу. <...>Решил использовать диаграмму последовательности..<...>
IMHO рано переходить. Лучше почитать теорию. Вдумчиво, не по диагонали. Лучше иностранных авторов. Знаю, нудно, но без этого никак.

118
<...>
Это определние мне нравится больше,но я бы сказал: как Пользователь должен взаимодействовать с системой...
Как пользователь работает и где ему нужна система - это бизнес-UC.
Как пользователю предлагается работать с системой - это системные UC.
А пользователь ничего не должен. Это система - должна.

119
Модель - это такая вещь, которая даёт обобщённое, упрощённое, иногда - идеализированное представление о чём-либо. Её ценность - только в том, что она упрощает понимание цели и структуры целого, а также поиск его частей. Сама по себе, в отрыве от реальности и исполнителей, она ценности не имеет. Если программистам удобнее без неё, чем с ней - значит, это плохая модель.
Не уверен, что имею опыт, позволяющий оспаривать классиков, но:
"4. Нельзя ограничиваться созданием только одной модели. Наилучший способ при разработке любой нетривиальной системы - использовать совокупность нескольких моделей, почти независимых друг от друга" - не согласен. Модели одной вещи всегда будут зависимы друг от друга. Понимание этой связи - IMHO основа системного подхода.
Бизнес-мотивация, "социальный капитал" и "душа компании"... Здорово, но я бы бюджета на построение таких моделей не дал. По-моему, самостоятельной ценности они не имеют. Записать всё нельзя. Не все вещи могут быть формализованы без искажения. А перечисленные вещи должны быть в голове у каждого менеджера, записывать это - всё равно, что записывать, с кем и почему дружишь.

120
<...>Какими методами проверки качества требований вы пользуетесь на практике?<...>
До разработки - отправляем требования на пересмотр лояльным представителям заказчика, собственным внедренцам, другим системным аналитикам, менеджеру проекта и архитектору, которым предстоит их реализовывать. Почти всегда должны присутствовать нефункциональные требования относительно определённых аспектов ПО. Если требования касаются архитектуры и реализации - это вызывает дополнительные вопросы, действительно ли заказчик хочет так, или это системный аналитик полез не в своё дело. PM замечательно может отсечь требования, выходящие за рамки системы, и "бантики", а архитектор и ведущие программисты - увидеть нереализуемые требования и требования, необоснованно ограничивающие реализацию.
Конечно, для этого требования должны быть максимум на 30 страниц 10-го Times New Roman, быть чётко структурированными не более, чем на 3-х уровнях, и изложенными языком, понятным нетехническим специалистам, знакомым с предметной областью. Ещё в них должно быть минимум ссылок на другие требования.

Во время разработки - следим за вопросами, которые возникают у архитекторов, программистов и тестировщиков (да, писать тестовые последовательности задолго до разработки у нас не получается). И следим за количеством изменений в требованиях, которые исходят от заказчиков и внедренцев. Если вопросов или изменений слишком много - улучшаем требования, вызывающие их.

После разработки - проверяем состояние своего счёта :) .

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 »