Рассылка закрыта
Вы можете найти рассылки сходной тематики в Каталоге рассылок.
C+Sharp+and+.NET [CSharp & .NET] 2001.08.29
Сегодняшний выпуск будет не совсем обычным. Я прошу вас прокомментировать (level3@mail.ru) идею:
Программирование в командах
В Лицее Информационных Технологий 1537 начинается учебный курс "программирование в командах" для учеников 10-ых (а потом 11-ых) классов. Курс продлится четыре триместра (триместр - треть учебного года) и закончится защитой работ.
Всего будет две команды по 8 человек. Им будет дано одинаковое задание и одинаковые общие советы. Обе команды состоят из незнакомых мне людей, поэтому ни одной из них по началу не будет отдаваться предпочтение. Если в ходе проекта какая-то команда расположит меня к более хорошему отношению к ней, чем к другой команде, значит, эта команда удачнее представляет себя, поэтому ей будут более высокие оценки.
Команда победитель будет только одна - та, чья программа будет использоваться на практике (все как можно ближе к жизни). Система подсчета рейтинга команд и участников пока не проработана, но общий принцип заключается в следующем - все, что на пользу проекта - в плюс, что во вред - в минус. Возможно изменение системы подсчета во время курса (например, введение бонусов за пунктуальность команды при приходе на начало лекций, соответственно минусов за опоздания).
В качестве учебного проекта выбрана, по пожеланию завуча, система учета и распределения помещений и рабочего времени (это чуть шире, чем программа составления расписаний). О выборе средств реализации чуть ниже.
Шаг первый - Набираем команды
Команда, это гораздо больше, чем группа людей, назначенных на проект. В эффективную команде подбираются люди, соответственно работе, которую они будут делать и несут ответственность за результаты в своей части. Наличие четко обозначенного участка работы и соответствие его способностям человека повышают результаты и устраняют препятствия к высоким достижениям.
Наличие эффективной модели команды позволяет достичь следующего:
- Каждый знает, сколько работы сделано и сколько еще осталось
- Документация будет подготовлена, а пожелания "клиентов" не останутся без внимания
- Программное обеспечение будет протестировано, и будет удовлетворять поставленным целям по качеству
- Несколько человек не будут дублировать работу друг друга
- Не будет участков работы, за которые никто не отвечает
Предлагаемый состав команды (все учащиеся распределены заранее по результатам их предыдущего обучения)
- организатор
- оформитель
- программист-оформитель
- программист по логике
- программист по данным
- программист пользовательского интерфейса
- менеджер по качеству
- ведущий программист
Это модель команды сотрудников, работающих независимо для достижения общей цели. Каждый участник команды играет свою особенную роль и участок работы, вклад каждого имеет значение. Такой подход вызывает чувство ответственности за свою работу, что в результате дает более качественный программный продукт.
- Каждый принимает участие в общем успехе
- Создается атмосфера ясности, эффективного взаимодействия, согласия и командного духа
- Это приводит к созданию продукта, действительно отвечающего пожеланиям "заказчика"
организатор
Учится организовывать взаимодействие, обучение, отдых. Узнает требование у "заказчика", добывает вспомогательную информацию. Разрабатывает требования к программе, планирует функциональность. Прорабатывает способы использования программы и показывает границы возможного "заказчику", чтобы проект не обманул ожиданий. Решает спорные вопросы (одно из решений - обратиться ко мне). Его оценка напрямую зависит от успеха команды в целом.
оформитель
Отвечает за подготовку документации к программе (встроенной помощи, руководства пользователя, руководства по установке, сайта программы, если таковой будет), проводит представления программы. Кроме того, решает, каким будет внешний дизайн программы. Ее (или его) решения по дизайну является окончательным и может быть изменено только организатором.
Кроме того, обучает пользователя работе с программой (разрабатывает план обучения), старается сделать программу более простой для использования и понимания.
программист-оформитель
Реализует встроенную помощь, программу инсталляции (или пользуется встроенной), другие вспомогательные утилиты, если надо (например, решает вопросы автоматического обновления предыдущей версии). Разрабатывает сценарий тестирования программы.
программист по логике
Реализует логическую часть программы (объектную модель, среднее звено трехзвенки, ...).
программист по данным
Реализует сохранение объектов логической модели, взаимодействие с другими приложениями (в частности с программой конкурирующей команды).
программист пользовательского интерфейса
Реализует формы и отчеты :)
менеджер по качеству
Ищет ошибки в программе и несоответствия в документации. Отвечает за соответствие программы требованиям к ней. Принимает решение о допуске или не допуске программы к "производству" (демонстрации).
ведущий программист
Принимает критические решения, необходимые для создания качественного продукта в нужное время. Координирует решения для соответствия их стандартам и требованиям по взаимодействию с другими программами. Отвечает за взаимодействие частей программы, планирование времени реализации, устранение найденных ошибок.
Разрешение конфликтов
Кто разрабатывает что-либо, тот и отвечает.
Если кто-либо не согласен с мнением участника, отвечающего за данную часть работы (например, кто-либо не согласен с организатором), то можно обратиться ко мне. Конфликты, которые не улаживаются сами мирным путем и доходят до меня, буду решать я, однако на рейтинг команды это будет влиять отрицательно.
Средства реализации
Инструмент не может быть для разных задач одновременно эффективным и универсальным. Для каждой задачи выбирают подходящий инструмент, например ткань - режут ножницами, а деревья - рубят топором.
В качестве средства реализации мной выбрана платформа .NET, так как в ней есть, сборка мусора, среда разработки программ, библиотеки для создания форм и доступа к данным. Кроме того, C# проще в изучении, чем C++ и похож на Java.
Почему не Java? Потому что пока ее поддержка инструментальными средствами оставляет желать лучшего.
Почему не Delphi? Я не знаю, есть ли в ней автоматическая сборка мусора (в последней версии, с которой я работал, пятой - не было). Это очень важно, т.к. сильно упрощает программирование.
Время
Проект будет построен по спиральному циклу (еще бывает "модель водопада"). Режим итеративного развития снижает риск провала проекта.
В конце триместра к защите должна быть представлена разработанная, документированная и полностью функционирующая система. В следующем триместре должны быть проанализированы пожелания и замечания, учтены преимущества продукта "конкурента" и реализована следующая версия программы.
Рекомендуется использовать план с "вехами", ориентируясь на поставленные задачи и имеющееся время.
- Должны быть определены основные сроки работ
- Работы должны быть распределены между участниками
- Трудности должны быть выявлены как можно раньше
- Нужно сразу определить, что в программе будет наверняка, а чем можно будет пожертвовать
Рекомендуется выделить четыре этапа: Создание образа, планирование, разработка и отладка. Каждый этап должен иметь четко обозначенную дату окончания. К этой дате должны быть оформлены результаты этапа.
Наличие первого этапа позволяет отвлечься от сиюминутных задач и охватить работу в целом. Создание набора требований к программе заканчивается утверждением их "заказчиком". Требования менее важны, чем создание общего образа продукта
Планирование определяет что, когда, кем и каким способом будет сделано. Этап заканчивается вехой "план одобрен". В плане предпочтение должно быть отдано срокам, установленным "заказчиком", а не тому, как хочется команде. Каждая веха - это возможность уточнить пожелания заказчика к программе.
Разработка заканчивается вехой "функции реализованы".
Стадия стабилизации заканчивается вехой "программа готова к 'производству'". Предпочтение следует отдать постепенному увеличению функциональности. Как правило, используется более качественный продукт, хоть и с меньшим количеством функций. Захваченный "рынок" тяжело отвоевывать ;)
Планирование с вехами позволяет принимать более качественные решения, приводит к меньшему количеству переделок (которые потеря времени) и к созданию более качественного продукта. Кроме того, оно уменьшает риск срыва проекта.
Структура программы
Программа должна быть построена по модульному
принципу
Здесь программа 1 - это например программа для составления расписания, программа 2 - это программа для учета учеников (куда поступили выпускники и т.п.)
На этом же рисунке можно рассмотреть части системы.
Гладко это на бумаге, кто покажет мне овраги?
| http://subscribe.ru/
E-mail: ask@subscribe.ru |
Отписаться
Убрать рекламу | Рейтингуется SpyLog |
| В избранное | ||
