RRRRR - 54.159.202.12

Обсуждения-аналоги

Скрыть / Показать Сортировать по дате
2007-04-26 01:20:16
Валерий » Всем

Добрый Вечер,

Если вам не интересно читать предистроию моей проблемы, начните читать с 4-го абзаца.

Я организовал маленькую фирму по разработке программных продуктов. Основной вид деятельности - разработка ПО для веб-сайтов (скриптов). Работаю с 2000 года. Фирма постепенно росла, увеличиливался штат сотрудников(раст дошел до 12 человек), но доход я получал от старых "массовых проектов" (веб сайтов, продающих программные продукты), которые были созданы в начале развития фирмы, когда работники только пришли на работу. И получилось так что - все проекты которые делались по заказу либо были не успешными (клиент просто отказывался от работы), либо сроки были сорваны (по некоторым проектам на год либо полтора).

 

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


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

Задача: Организовать упрвляемый и прогнозируемый процесс планирования и разработки ПО.

Как я его вижу:

2007-04-26 01:49:47
Валерий » Всем
продолжение... (т.к. случайно нажал на кнопку Add)

1. Разработка требований. Документы: Варианты Использования (Пользователь-Система), описание интерфейса. Анкета опросник клиента
2. Составление плана работ. Версии программного продукта, в которых будут реализованы определнные варианты использования.
3. Разработка макета программы. HTML страницы связанные между собой.
4. Разработка архитектуры программы. Разбиение на сущности, классы и методы. Диаграммы потока данных, связанные с вариантами использования. Детельное описание каждого метода в классе, и алгоритм его работы. Поиск уже готовых решений (частей кода, модулей).
5. Кодирование. Результат данного этапа это код программы. Сборка в готовый продукт.
6. Тестирование. Тестирование кода и логики работы.
7. Написание документации для пользователя.

Из работников которые обязанны присутвать в процессе разработки это:
на этапе 1 - 2. Менеджер проекта. Его обязанность сбор требований, написание документации и плана работ, совметно с аналитиком проекта.
на этапе 2-4. Аналитик проекта. Его задача, план проекта, создание архитектуры проекта.
на этапе 3. Дизайнер интерфейса и верстальщик. Создание дизайна и верстка страниц.
на этапе 6-7. Программисты.

Я пробовал давать программисту принимать решения во всех ситуация, но результат плачевный. Много спорят - работа идет медленно или вообще не идет. Теперь мое мнение таково - обязательна дисциплина и четкий технологический процесс.

Стимул к работе это штрафы и премии(бонусы).

Какие будут возражения и дополнения по поводу процесса разработки?
Какие стандарты и документы предлагаете внедрить?
В каком виде лучше оформлять требованию к проекту?
Есть ли у кого-то технология сбора требования к проекту?

Жду Ваших отзывов.

С уважением,
Валерий
2007-04-29 01:05:33
Попов Роман Анатольевич » Валерий

Добрый день,  Валерий.

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

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

  1. Что побудило клиента заказать этот продукт, почему старая структура бизнеса не может обойтись без этого нововведения.
  2. Если это В2В или В2C, то кто будет управлять программой или сайтом со стороны Заказчика, кто будет пользоваться программой или сайтом со стороны Клиента, какова их квалификация
  3. Сколько времени этот проект можно будет строить, не устареет ли он морально раньше, чем попадет к заказчику.
  4. Кто конкуренты, что у них уже есть, не строим ли мы то, что можно купить готовое.
  5. Какие задачи проект не должен решать ни при каких согласованиях ТЗ, т.е. какие границы будут означать не изменение этого проекта, а создание нового.
  6. В терминах ТРИЗ – идеальный конечный результат, его подробное описание. Это самый главный документ.

Этап 7  Написание документации для пользователя, рекомендую переставить стразу после этапа 0. Дело в том, что когда Ваш менеджер проекта напишет инструкцию к будущей программе и даст прочитать её Заказчику, то удивительным образом услышит: «вот тут и тут неправильно, должно быть так и так». Согласитесь, что дешевле это услышать до того, как создана программа, чем после.

Я считаю, что в Вашем плане разработки этапы со второго по пятый клиенту и показывать особо не стоит. Не в том смысле, что держать его в неведении

или делать из этого секрет, а не стоит загружать его подписанием протоколов, в которых он ничего не понимает. Все равно, если он не сможет сам загрузить краткое описание товара, а только длинное, хотя он это просил, то ему, Клиенту, будет всё равно, что там перепутано сущности, классы или методы. Ему нужна система, которая соответствует пункту 0, даже не пункту 1.

А вот показывать клиенту еженедельно/ежемесячно стабильные версии обязательно. Да

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

Не далее чем на этой неделе я общался с заказчиком. Разговор начался с  стандартной фразы «мне нужен сайт», а закончился тем, что будет продолжение переговоров на предмет того, что и как можно улучшить в текущей модели бизнеса и каким боком для этого нужен сайт. И какого типа будет сайт. И нужен ли он там вообще. Если бы я сразу начал делать сайт, то велика вероятность того, что время-деньги-репутация канули в воду.

С уважением, Попов Роман Анатольевич.

2007-04-30 10:44:52
Георгий Соколов » Валерий
Уважаемый Валерий!

Возможно, Вас эмоционально вдохновит этот материал: Правильные
бизнес-процессы для гениев программирования


Успехов!
2007-05-01 22:13:38
Власюк Валерий » Попов Роман Анатольевич
Большое спасибо за ответы. С данного форума я почерпнул огромное количество идей, связанных с работой с клиентами, должностными инструкциями и рекламой. По поводу написания документации (этап 0) спасибо за совет, попробую.

Я пытаюсь разбить на субэтапы, четвертый этап "Разработка архитектуры", у меня получились такие подэтапы:
1. На основании документов описывающих систему выделить сущности
2. На основании сущностей выделить классы
3. На основании прошлых проектов и библиотеки заготовок кода выделить уже готовые решения
4. На основании Вариантов Использований выделить методы
5. Для каждого варианта использования создать диаграмму потока данных.
6. Написать алгоритм действий для кадого метода либо входящие данные и выходящие, а программист пусть сам решает как будет функционировать данный метод?
7. Написать задание для кодера - документ, описывающий что должен написать/изменить программист (классы, методы либо функции).

На данном этапе можно сильно ограничить творчество кодера, описав алгоритм работы каждого метода/функции.

Есть ли смысл это делать или нет? Какое у Вас из личного опыта сложилось по данным этапам мнение (давать детальный алгоритм или давать свободу действий, а рамки творчества ограничить тем, что на входе и выходе должен быть определенный результат)?

Как в Вашей огранизации построен процесс разработки ПО?

Насчет статьи "Правильные бизнес-процессы для гениев программирования". Спасибо за ссылку, статья как Вы и говорили эмоционально меня вдохновила. Она показала, что проблемы с котороыми я столкнулся, существуют не только у меня.

К сожалению описние бизнес-процесса разработки ПО в компании HP в интернете я не нашел... Может подскажете где посмотреть информацию по данному вопросу?

С уважением,
Власюк Валерий
2007-05-02 08:32:36
Редакция » Власюк Валерий

Уважаемый Валерий!

а также прочтите статьи С.В. Сычева и К.А. Лебедева:

, а также группу материалов тех же авторов из серии "TStupid или Новейший Органон":

Успеха,

2007-05-04 00:52:11
Кирилл Лебедев » Власюк Валерий

Уважаемый Валерий!


Я пытаюсь разбить на субэтапы, четвертый этап "Разработка архитектуры", у меня получились такие подэтапы:
1. На основании документов описывающих систему выделить сущности
2. На основании сущностей выделить классы

На основе 11-летнего опыта разработки программ могу сказать, что все-таки правильнее начинать проектирование не с выявления сущностей, а с формулировки функций, которые должна выполнять программа. Такие функции я называю пользовательскими или бизнес-функциями, потому что они решают задачи пользователя (или бизнеса). Как правило, одна бизнес-функция может быть реализована при помощи нескольких классов и/или функций, написанных на языке программирования.

В процессе проектирования важна концентрация на функциях именно потому, что разрабатываемая программа должна решать определенные бизнес-задачи. Нередко – даже опытные! – программисты забывают об этом, и, в результате, получается нечто монстроподобное, что трудно сопровождать и что не решает необходимые задачи.

Как правило, когда обращаешь внимание программистов на то, что нужно проектировать программу для выполнения бизнес-функций, сталкиваешься с двумя эффектами непонимания.

Эффект № 1. «Очевидный факт».

Программисты понимают, что программа разрабатывается для решения определенных бизнес-задач Клиента, и считают, что им сообщают очевидный факт.

Между тем, не смотря на понимание этой, вроде бы очевидной, вещи, в процессе проектирования бизнес-задачи не берутся в расчет. Обычно процесс проектирования начинается с одной из четырех вещей:

1.      с поиска объектов предметной области и проб их на роль классов;

2.      с поиска какого-нибудь паттерна проектирования;

3.      с поиска уже готового кода (например, в виде бесплатной библиотеки), который можно просто вставить в программу или который можно «передрать»;

4.      с выявления произвольных атрибутов объектов предметной области и попытки сгруппировать эти атрибуты в иерархию классов – когда атрибуты, присутствующие у всех объектов, выносятся в базовые, а все остальные – в производные классы.

Общая ошибка, допускаемая разработчиками – это «проектирование от объекта» (или «выведение класса из объекта»). Наиболее детально она описана в этой статье.

Эффект № 2. «Вы нам рассказываете про структурное программирование…»

Увидев или услышав слово «функция», программисты считают, что речь идет о структурном программировании. А поскольку объектно-ориентированное программирование позволяет лучше бороться со сложностью, чем структурное программирование, совет «проектировать от функций» воспринимается ими, как попытка вернуться в прошлое.

Между тем, речь идет не о функциях языка программирования, а о бизнес-функциях.

Как же все-таки проектировать программу? В следующей части сообщения постараюсь описать ряд шагов, которые на практике показали свою эффективность. Это – не полный алгоритм, а лишь некоторые шаги…

Шаг 1. Сформулируйте назначение программы.

Говоря языком ТРИЗ, сформулируйте главную полезную функцию (ГПФ) и вспомогательные полезные  функции (ВПФ) программы.

ПРИМЕР. Необходимо разработать GPS-навигатор для автомобильного компьютера (карпьютера). Основная задача GPS-навигатора – автоматическая прокладка маршрута в заданную точку.

Шаг 2. Сформулируйте операции, необходимые для достижения ГПФ.

Для выполнения главной полезной функции, программа должна выполнить ряд операций. На этом шаге нужно сформулировать эти операции. Как правило, на макро-уровне, без детализации.

ПРИМЕР. Для прокладки маршрута GPS-навигатор должен:

1.      Получить текущее местоположение пользователя у GPS-приемника.

2.      Считать карту местности.

3.      Проложить маршрут в заданную точку.

4.      Отобразить карту местности и проложенный маршрут.

5.      Определить положение пользователя на маршруте и выдать указание по движению.

Шаг 3. Постройте структурную модель программы (в первом приближении).

Для этой цели каждую макро-операцию можно вынести в отдельный модуль. Структурная модель программы представляется в виде набора модулей и связей между ними.

ПРИМЕР. Структурная модель GPS-навигатора в первом приближении:

Модуль

Назначение

Использует

Reader

Считывает картографические данные.

 

Router

Прокладывает маршрут.

Reader

Rasterizer

Отображает карту местности и маршрут.

Reader, Router

Navigator

Определяет положение пользователя на маршруте и выдает указание по движению.

Reader, Router

Location Module

Получает текущие координаты у GPS-приемника.

 

Шаг 4. Упорядочите действия из шага 2.

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

ПРИМЕР.  Для GPS-навигатора последовательность операций может быть такова:

1.      Получить текущие координаты.

2.      Загрузить карту местности.

3.      Выполнить снэппинг (прикрепить точку к ближайшей дороге).

4.      Построить маршрут.

5.      Определить положение на маршруте.

6.      Если пользователь находится на маршруте, то получить указание по дальнейшему движению.

7.      Если пользователь находится не на маршруте, то пересчитать маршрут.

8.      Отобразить карту, маршрут и местоположение пользователя.

9.      Отобразить указания по движению.

Как видите, при упорядочении в список добавились дополнительные действия.

Шаг 5. Постройте модель выполнения программы.

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

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

ПРИМЕР. По прогнозам более-менее длительное время занимают такие операции:

1.      Построение и пересчет маршрута.

2.      Определение указания по дальнейшему движению.

3.      Отображение карты местности (формирование растрового изображения).

Загрузка необходимых данных из карты местности выполняется более-менее быстро за счет кэширования и оптимальной структуры базы данных с картографическими данными.

Перечисленные медленные операции можно вынести в отдельные потоки. Кроме того, в отдельный поток можно вынести и операцию получения текущих координат у GPS-приемника. Это лучше сделать, чтобы не нагружать главный поток программы чтением данных из COM-порта. Такая операция должна выполняться периодически (например, раз в секунду). И в главном потоке будет трудно за этим следить, поскольку он должен выполнять еще массу других операций.

В результате получился такой список потоков:

Поток

Назначение

Location Thread

Получение координат у GPS-устройства.

Routing Thread

Расчет и пересчет маршрута.

Navigation Thread

Определение указания по дальнейшему движению.

Rasterizing Thread

Отображение карты, маршрута и местоположения пользователя.

Main Thread

Загрузка карты местности.

Выполнение снэппинга (прикрепление точки к ближайшей дороге).

Определение положения на маршруте.

Отображение указания по движению.

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

Далее проектирование идет в двух направлениях:

1.      Детализация интерфейсов модулей и проектирование модулей.

2.      Детализация интерфейсов потоков, которые обмениваются друг с другом посредством асинхронных сообщений.

С уважением,



Яндекс.Метрика