Ускорение разработки программного обеспечения. Методология RAD
В связи с развитием CASE-технологий в рамках спиральной модели жизненного цикла ПО в последнее время широкое распространение получила методология быстрой разработки приложений RAD (Rapid Application Development). Процесс разработки при этом содержит три элемента : небольшую команду программистов...(Технология разработки программного обеспечения)
Пакеты прикладных программ
Классификация пакетов прикладных программ (ППП) приведена на рис. 1.8. Проблемно-ориентированные ППП. Для некоторых предметных областей возможна типизация функций управления, структуры данных и алгоритмов обработки. Это вызвало разработку значительного количества ППП одинакового функционального назначения:...(Технология разработки программного обеспечения)
Пакет прикладных программ Microsoft Office
Прикладные программы часто объединяются в пакеты по роду деятельности пользователя. Наиболее популярным пакетом, предназначенным для решения задач автоматизации офиса, является Microsoft Office. Он представляет собой семейство прикладных программных продуктов, которое объединяет различные приложения...(Информатика)
Система контроля версий Subversion
Subversion - свободно распространяемая система управления версиями с открытым кодом. Subversion разработана специально для замены CVS, самой распространенной открытой системы управления версиями. Она обладает всеми основными функциями CVS (хотя некоторые из них выполняет другими способами) и лишена ряда...(Технология разработки программного обеспечения)
ОСНОВЫ РАБОТЫ В СРЕДЕ РАЗРАБОТКИ STUDIO 2010 ИНТЕГРИРОВАННОЙ MICROSOFT VISUAL
В настоящее время для разработки программного обеспечения используются интегрированные среды разработчика - ИСР (англ. IDE - Integrated development environment). Интегрированная среда разработчика позволяет повысить производительность и эффективность работы программиста. Одной из интегрированных сред...(Программирование на языке высокого уровня. Программирование на языке С++)
Разработка программного обеспечения, кроме достаточно сложного технического аспекта, имеет сложный организационный или даже психологический аспект.
Так известно, например, что потребности заказчика всегда достаточно сложно определить полностью в какие-то начальные моменты разработки и даже после обследования. Это влечет за собой большое количество незапланированных работ, что отрицательно сказывается на качестве продукта.
Вопрос в том, как построить модель отношений заказчика и разработчика с учетом интересов обеих сторон и без потери качества?
Каждая сторона состоит из независящих функционально ролей. Каждая роль может включать в себя несколько человек. Роли совместимы только внутри сторон.
Итак, сторона заказчика имеет следующие ключевые роли: менеджер продукта и бизнес-аналитик.
Менеджер продукта — это представитель разработчика у заказчика, он обязан представлять интересы заказчика у разработчика. Это главный источник информации как для заказчика, так и для разработчика, его цель — полное удовлетворение потребностей заказчика в рамках выделенных ресурсов.
Бизнес-аналитик — это представитель заказчика, ответственный за создание системы. Он досконально знает бизнес-процесс своего предприятия и обязан предоставлять полную и достоверную информацию.
Сторона разработчика : менеджер программы, аналитик, программист, тестировщик.
Менеджер программы — это главный технический специалист проекта, он является хранителем спецификации и заинтересован в ее минимальных изменениях во время разработки.
Аналитик формализует информацию, получаемую со стороны заказчика в виде моделей, он обязан уметь выявлять закономерности и делать правильные обобщения, анализировать и проектировать комплекс взаимосвязанных программ для реализации функций предметной области.
Программист — непосредственно кодировщик.
Тестировщик — специалист по тестированию, он отвечает за соответствие системы ее спецификации.
Сторона качества : бизнес-аналитик и технолог.
Бизнес-аналитик — специалист по предметной области вообще, независимо от конкретного предприятия.
Технолог — специалист по технологии, контролирующий правильность ее использования.
В реальности каждая сторона работает в противовес двум остальным и необходима для сохранения общего баланса.
Каждая роль может включать в себя несколько человек. Нужно учитывать, что при работе над большим проектом возникает проблема взаимодействия исполнителей между собой. Взаимодействие исполнителей друг с другом требует времени, что в определенной степени снижает производительность труда . Причем взаимное непонимание приводит к дополнительным затратам на последующих стадиях разработки, например, непонимание среди программистов приводит к дополнительным затратам на тестирование.
Проблема взаимодействия возникает уже при работе группы из четырех и более человек. Для управления их работой необходим руководитель.
Решением этой проблемы может стать организация бригад
, например бригады главного программиста
,если рассматривать на примере программистов.
Бригададолжна включать от 3 до 7 человек. Число 10 является верхней границей численности бригады. Это обусловлено требованием максимальной управляемости коллектива.
В бригаде в зависимости от квалификации выделяют следующих специалистов.
Руководитель бригады (например, главный программист) — это превосходно подготовленный, творчески мыслящий, наделенный организационными способностями специалист. Он выполняет работу верхнего уровня, в том числе распределение работы внутри бригады.
Заместитель руководителя бригады (например, старший программист) поддерживает тесную связь с руководителем бригады и дорабатывает более мелкие вопросы. При обсуждении проекта заместитель должен выступать в роли оппонента руководителю бригады.
Непосредственно исполнители (например, младшие программисты) — два или три "менее опытных" (но не "менее способных") специалиста. Они выполняют работу нижнего уровня, определенную руководителем бригады.
В большом проекте в состав каждой или нескольких бригад могут входить следующие специалисты.
Администратор отвечает за распределение времени, подбор кадров, размещение исполнителей, финансирование, поддержку связи с высшим руководством.
Библиотекарь ведет системную библиотеку, например, библиотеку модулей, используемых в оперативном режиме. Все изменения в программные модули вносит только библиотекарь. Он также ведет системную документацию — системный журнал.
Технический исполнитель (документатор) занимается написанием документации по проекту, что освобождает более квалифицированных специалистов от этой рутинной работы.
Секретарь выполняет обычную работу секретаря.
Опыт разработки крупных ПО показывает, что для повышения эффективности работ необходимо разбить проект на отдельные слабо связанные по данным и функциям подсистемы . Реализация подсистем должна выполняться отдельными группами специалистов. В случае использования CASE-средств это означает деление функциональной модели системы (диаграммы потоков данных для структурного подхода).
Поэтому после первоначального определения функций, которые должно выполнять разрабатываемое ПО, проект распределяется между различными командами разработчиков (рис. 12.1).
Рис. 12.1. Группы специалистов, занятых в разработке ПО
(n — количество функций ПО)
При этом необходимо обеспечить координацию ведения общего проекта и исключить дублирование результатов работ каждой проектной группы, которое может возникнуть в силу наличия общих данных и функций.
Результатом стадии должны быть:
Общая информационная модель системы;
Глобальные функциональные модели системы в целом и подсистем, реализуемых отдельными командами разработчиков;
Точно определенные интерфейсы между автономно разрабатываемыми подсистемами (те данные, которые передаются между ними);
Построенные прототипы экранных форм, отчетов, диалогов (должен быть определен стандарт интерфейса пользователя).
После окончания работ каждой отдельной команды разработчиков производится постепенная интеграция данной части системы с остальными, формируется полный программный код, выполняется тестирование совместной работы данной части приложения, а затем тестирование системы в целом.
30 июня в МГТУ СТАНКИН состоялось заседание общественного совета по реализации проектов в области коллективной разработки программного обеспечения. 3 Июль 2015, 11:03
30 июня в МГТУ СТАНКИН состоялось заседание общественного совета по реализации проектов в области коллективной разработки программного обеспечения. В нем приняли участие сотрудники ФПИ, ООО «Рексофт», ЗАО «Топ Системы», АО «Системы управления», АО «Объединенная приборостроительная корпорация», ОАО «Объединенная авиастроительная корпорация», ГК "Росатом", АО «Вертолеты России», ОАО «Объединенная ракетно-космической корпорация», ИТ кластера Сколково и других научных и производственных организаций ОПК, научные сотрудники институтов РАН, МГУ им.М.В.Ломоносова, ведущих технических ВУЗов, представители Минкомсвязи и Минпромторга России.
Участники совещания отметили, что задачами общественного совета являются научно-техническая и технико-экономическая экспертиза планируемых и выполняемых проектов коллективной разработки ПО, участие в приёмке и подготовка предложений по внедрению результатов, полученных при выполнении проектов коллективной разработки ПО, подготовка предложений в органы исполнительной власти Российской Федерации, общественные и другие организации по вопросам повышения эффективности выполнения работ в области коллективной разработки ПО, подготовка предложений в организации по стандартизации, связанных с подготовкой новых и корректировкой существующих нормативных документов в области коллективной разработки ПО. Целью деятельности общественного совета является повышение эффективности выполнения проектов, направленных на решение проблем импортозависимости и обеспечения технологического лидерства страны на основе коллективной разработки отечественного программного обеспечения.
На заседании были утверждены: положение об общественном совете по реализации проектов в области коллективной разработки ПО, план заседаний общественного совета, сформирована рабочая группа по стандартизации, а также группы потребителей и образовательных учреждений. Участники совещания одобрили технологические принципы, заложенные в основу интегрированной инженерной программной платформы. Председателем общественного совета был избран заместитель генерального директора – руководитель направления информационных исследований Фонда перспективных исследований Сергей Гарбук. Заместителем председателя был избран заместитель генерального директора АО «Объединённая приборостроительная корпорация» Андрей Чендаров.
Кроме того, участники совещания решили, что требуется регулярное доведение информации по проекту «Гербарий» до заинтересованных сторон. В ходе проработки вопросов управления НСИ следует рассмотреть возможность использования современных международных стандартов и сформировать профиль требований, предъявляемых к ИПО, а также предложить инструментарий для управления требованиями. В части квалификационного тестирования поступило предложение проанализировать возможность использования сторонних продуктов, а также включить в сценарии нагрузочное тестирование. Замечено, что при лицензировании продуктов необходимо обеспечить вариант лицензирования по АРМ, а не только по пользователям. Также отмечено, что изложенные в ходе выступлений принципы являются актуальными и могут эффективно использоваться при разработке других типов программного обеспечения. Гарантией работоспособности решений на технологической платформе «Гербарий» являются обязательные для всех без исключения разработчиков механизмы валидации и квалификационного тестирования модулей. Предложенные к реализации механизмы коммерциализации и лицензирования призваны увеличить заинтересованность разработчиков и потребителей в переходе на данную технологическую платформу. Для реализации планов по импортозамещению в области инженерного ПО разработку программных средств управления полным жизненным циклом высокотехнологической продукции целесообразно осуществлять на базе предложенных технологических решений и принципов коллективной разработки.
3. menu – меню. Реализовано в виде списка, причем каждый пункт может содержать подменю, которое тоже представляет собой список. Каждый элемент списка обязательно содержит текст (часто с горячей клавишей) и может содержать иконку 32*32, сочетание «горячих клавиш» для вызова элемента без вхождения в меню или символ 4. Сочетание icon+menu = Tool panel (Панель инструментов)
4. pointers – механизм индивидуальной настройки пользователя. Обозначается маленькой стрелкой в левом нижнем углу иконки. Пользователь может конфигурировать под себя любое количество указателей в любой папке и области.
Разработчик и архитектор в больших программах – разные люди.
Задача архитектора: представить предметную область с точки зрения пользователя (удобство использования интерфейса). Архитектор должен выяснить тезаурус пользователя и обеспечить лингвистическое обеспечение проекта.
Замечание: невозможно учесть все требования пользователя, поэтому желательны пункты Параметры, Сервис, Настройка, Конфигурация – варьирует характеристиками создаваемого программным продуктом под конкретного пользователя. Например: цвет фона, меню, наличие строки состоянии. В общем случае, чем лучше проработан интерфейс пользователя, тем конкурентоспособнее он.
19. Требования к программистам. Формирование команды программистов.
Требование к программистам и их оценка
- Уровень образования
По учреждению выясняются возможности
Тестирование знаний
Резюме – представление опыта программистов, характеризующее его возможное применение.
На производительность влияют:
- Наличие амбиций человека (собственная оценка своих качеств и себя в коллективе)
- Уровень притязания. Самооценка может быть источником конфликтов в коллективе.
- Коммуникабельность! при сдаче проекта.
Задача руководителя после подбора команды организовать работу так, чтобы по максимуму использовать профессиональные и персональные данные программистов.
20. Организация процесса работы команды программистов (персональная организация и коллективная работа).
Осуществляет руководитель проекта.
Опытный руководитель распараллеливает работы. Идет пересечение этапов.
По каждому этапу четко сформулирован результат. Если результата нет, то этап не завершен.
Документирование процесса работы. Все, что делается - оформляется.
Документация создается с начала реализации проекта. Оформляется в соответствии с ГОСТом (ISO) или с корпоративными стандартами документациями.
Удобно использовать маршрутный лист.
Достоинства подхода:
1. документация нужна не только тем, кто пишет программу, но и тем, кто работает рядом, т.е. вынужден использовать ваши результаты.
2. документация отражает текущее состояние работы над проектом
3. при окончании проекта требуется минимум усилий для оформления документации для передачи заказчику.
Организация персональной работы программиста
Менеджер планирует работу программисту, формулирует суть работы, сроки. Ежедневный самоотчет о проделанной работе позволяет менеджеру лучше планировать рабочее время программиста. Написание самоотчета занимает от 15 до 30 минут в день, но дисциплинирует программиста и дает возможность менеджеру перепланировать работу так, чтобы успеть.
Чем больше проект, тем большее значение принимает работа каждого программиста в отдельности и тем важнее любые инструменты, с помощью которых контролируется ход и выполнение работы.
Организация коллективной работы
Координация коллективной работы подразумевает информационное взаимодействие всех участников процесса, т.е. любой человек, участвующий в создании системы должен иметь возможность получать информацию о любых проектных решениях.
«Рабочая тетрадь». Все проектные решения документируются в рабочую тетрадь. Иногда размер всех рабочих тетрадей по проекту достигал толщины в 1 м.
Идея рабочей тетради поддерживается в виде выпуска очередной версии программного продукта, где документация и сам ПП отражают эволюцию его изменения.
Версия 0 является версией, готовой в бета-тестированию.
Согласование работ:
1. Распараллеливание работ
2. Сетевое планирование
Программные продукты, позволяющие осуществлять планирование работ и оптимизировать сроки:
- MS Outlook
- Time manager
- MS Project – управление ресурсами, планирование с дискретностью от часа до месяца. Позволяет работать удаленным пользователям надо удаленным проектом.
21. Планирование работы команды программистов. Эффект второй системы.
После того, как намечены все этапы, определены исполнители (ресурсы проекта и сроки), необходимо организовать получение информации о текущем состоянии проекта. Для этого можно организовать карты учёта такой структуры:
- Шифр, номер работы
- Описание выполнения
- Время окончания
- Результат, если работа окончена.
Отслеживает эту информацию менеджер группы.
По оценкам 28-33% времени программист пишет программу. Остальное – совещания, согласования, поиск литературы, обучение, координация с программистами, пишущими совместные с его модулями – 60%.
Задача менеджера – минимизировать 60% так, чтобы увеличить время работы программиста над программой. Если менеджер хороший, то он сможет снизить 60% до 50%.
Критическая ситуация – проект не успевает по срокам:
В этом случае возможны следующие шаги:
- увеличить число программистов на проект (зачастую только усугубляет положение);
- на существующем количестве перераспределить работу, ввести дополнительное время;
Эффект второй системы
Часть фирм планируют разработку системы на «выброс», чтобы получить представление о трудностях, ошибках, проверить основные идеи, а после разрабатывать вторую систему.
22. Работа с заказчиком.
Специфическая функция взаимодействия с потенциальным или реальным потребителем ПП.
- 1 Заказчик, 1 Разработчик
- Заказчик объявляет тендер на разработку. Выигрывает фирма, которая либо уменьшает стоимость разработки, либо за эту же сумму предоставляет больше возможностей. Играет роль имидж компании (участие и завершение аналогичных разработок, участие в семинарах, совещаниях по теме, открытость компании).
Преимущества:
Заказчик в курсе всей работы
Тестирование параллельно с написанием
Считается, что у нас в стране прекрасные программисты, и это действительно так!
Наши соотечественники работают во многих ведущих софтверных компаниях мира. Однако с точки зрения среднего уровня технологии производства массового ПО мы пока далеки от западных стран или, например, Индии, известной высоким уровнем организации оффшорного программирования.
Разобраться в причинах данного явления весьма важно для дальнейшего развития отечественной индустрии ПО.
Отчасти проблема связана с тем, что во многих ведущих зарубежных странах навык коллективного творчества развивается буквально со школы и продолжает формироваться в колледже и университете. У нас, к сожалению, такая традиция практически отсутствует. Каждый программист по отдельности, что называется, может подковать блоху, а вот наладить коллективный процесс в обычной кузнице не получается. При этом, надо сказать, что разрыв в этой области по сравнению с западными компаниями, к сожалению, не уменьшается, а увеличивается. В советские времена существовало множество крупных проектов, которые требовали создания технологий коллективной разработки продукта, а сейчас, в условиях отсутствия финансирования на крупные проекты, эти технологии утрачиваются.
Известно, что основное различие при написании программы разработчиком-одиночкой и коллективом состоит в том, что в первом случае программист создает продукт для окружающих и заботится о том, чтобы продукт был отторжимым извне (понятным в использовании), а во втором случае программист создает некий отторжимый от себя продукт на внутреннем уровне, то есть таким образом, чтобы другой программист мог продолжить работу в случае, например, болезни первого. А для этого другой программист должен знать множество нюансов: как выглядит алгоритм, при каких условиях он устойчиво работает и т.д. Помимо обучения отдельных программистов данная работа требует хорошей организации и культуры производства. При том, что средний уровень технологии производства программных продуктов (ПП) в России достаточно низок, существует ряд компаний, которым удается создавать продукты мирового уровня. В связи с этим их опыт является весьма интересным. Поэтому мы попросили рассказать, как организован данный процесс в успешных компаниях, включив в список последних коллективы, ориентированные как на внутренний, так и на внешний рынок. Мы задали приблизительно один круг вопросов, и оказалось, что в каждой компании есть своя специфика организации рабочего процесса, свои правила и, можно даже сказать, секреты. Надеемся, что результаты данного опроса будут интересны как российским компаниям, нацеленным на разработку качественного программного продукта, так и начинающим программистам, связывающим свое будущее с работой в подобных компаниях.
Фирма «1С»
«1С» - это чисто российская фирма со штатом более 160 человек, работающая в основном на отечественный рынок и опирающаяся исключительно на собственные профессиональные успехи. По данным многочисленных опросов, «1С» отличается рекордной отдачей от одного сотрудника. В связи с этим информация о том, как организован процесс производства на фирме, представляет особый интерес. Как известно, в «1С» существует два основных направления: первое (традиционное) связано с экономическими программами и второе - «1С:Мультимедиа» - посвящено производству игр. В силу того что оба направления имеют свою специфику, мы попросили рассказать о каждом из них отдельно.
Экономическое ПО
На вопросы об организации процесса создания программных продуктов делового назначения фирмы «1С» и прежде всего системы программ «1С:Предприятие» ответил Алексей Харитонов , руководитель отдела продвижения экономических программ фирмы «1С».
Алексей Харитонов: Поскольку речь идет о разработке тиражного софта, требуются очень квалифицированные специалисты. Мы рассматриваем очень много кандидатур, но в штат берем относительно мало. По сравнению с фирмами, занимающимися разработкой и внедрением заказного ПО, мы считаем, что разработчики массового софта - это элитные войска (спецназ) по сравнению с регулярной армией. Они более высокооплачиваемые, но и гораздо более квалифицированные; каждый много чего умеет. У нас практически нет так называемых простых кодировщиков, которые занимаются программированием по подробно расписанной задаче - каждый разработчик отвечает за какой-либо проект или за его часть и должен профессионально выполнять очень разные работы, требующие и квалификации, и творческого подхода, и умения слаженно работать в команде. Разработчики системной части специализируются по различным технологиям, составляющим платформу «1С:Предприятие», разработчики прикладных решений в той или иной предметной области - (бухгалтерский учет, торговый, производственный и т.п.).
Стыковка модулей сильно различается в системной и прикладной части. В системной части используются специализированные технологии разработки больших проектов (частично стандартные, частично выработанные собственно в «1С»). В прикладной части отдельные проекты являются, с одной стороны, независимыми прикладными решениями, а с другой - частью единой методологической системы. Они и работать могут как вместе, так и по отдельности.
Коллективная работа сама по себе является весьма важным организующим фактором. Есть и большое количество формальных инструкций, расписывающих порядок ведения проекта и взаимодействия разработчиков, но многое зависит от готовности самих специалистов помочь друг другу, чтобы наладить совместную работу.
По принятой у нас технологии разработки очень большая роль отводится руководителям проектов. Конечно, руководитель проекта планирует и координирует работы, следит за соблюдением технических требований к проекту и сроков его выполнения, собирает готовый проект. Но главное - каждый руководитель проекта в «1С» фактически является руководителем направления, его идеологом. Он творчески развивает свое направление, руководствуясь при этом не только анализом текущих потребностей рынка, но, что очень важно, - своим видением перспективы развития, вносит в разработки те новшества, потребность в которых будет осознана рынком только в будущем.
КП: Расскажите поподробнее, как организовано тестирование? Какое ПО для этого используется? Кто занимается тестированием?
А.Х.: Технология и порядок тестирования зависят от того, что именно тестируется. Отдельно выходят новые платформы, отдельно - конфигурации к ним. Платформа - это ядро, на нем пишутся типовые конфигурации, которые образуют прикладной уровень с определенными правилами учета, набором документов и взаимосвязями между документами, правилами заполнения реквизитов и пр. Конечно, они не полностью независимы друг от друга, но их делают разные группы, и выходят они в разные сроки, по-разному тестируются. Многое зависит от того, какой это продукт: абсолютно новый или модификация существующей конфигурации (новый релиз). В среднем новая версия тестируется самими разработчиками примерно в течение месяца (модули, естественно, тестируются по мере готовности), а затем начинается более формальный процесс - альфа-тестирование внутри самой фирмы.
Мы сами являемся пользователями собственных продуктов, и учет у нас поставлен так, что наши бухгалтеры, учетчики, менеджеры, являются альфа-тестерами наших новинок.
Очень важную роль в жизни фирмы играет отдел технической поддержки, один из самых многочисленных. Они отвечают на вопросы пользователей и партнеров, они же занимаются тестированием. Это очень хорошее решение по двум причинам: во-первых, они часто сталкиваются с ошибками в реальной «жизни» продукта, а во-вторых, это позволяет им хорошо изучить, «пощупать» продукт и таким образом к началу консультирования пользователей накопить немалый опыт обращения с ним.
Затем наступает этап бета-тестирования. К нему мы привлекаем в первую очередь наиболее продвинутых партнеров, но и «предметники», специалисты по учету, тоже занимаются тестированием.
Условия тестирования разные. Если тестируются конфигурации, то допускается установка системы у конечных пользователей. Пользователей предупреждают, что это бета-версия и что обычно у них эксплуатируется предыдущая, рабочая версия и параллельно проверяется и осваивается новая. Так, чтобы кто-то один мог протестировать все «1С:Предприятие» сразу, не бывает - обычно в бета-тестировании только одной новой конфигурации, например «Производство+Услуги+Бухгалтерия», принимает участие около 150 партнерских организаций. Бета-версии мы, как правило, продаем им по обычной цене, но с обязательным условием прислать потом отчет. Если партнер присылает нормальный отчет, то бета-версия ему потом заменяется на обычную. Бета-тестирование длится от полутора до трех месяцев, поступающие отчеты сводятся и обобщаются, затем выпускается «боевой» релиз, который тиражируется и поступает в продажу.
КП: Существуют ли какие-либо нормативные документы, предписывающие, как нужно писать программы внутри коллектива?
А.Х.: Такие документы, конечно, есть - на разработку как системной части, так и прикладных решений (конфигураций). Есть также внутренние инструкции и нормативы на контроль исправления ошибок и другие работы. Эти документы совершенствуются, со временем их становится все больше, на их основе мы создаем, например, открытые нормативы по сертификации тиражных партнерских разработок на получение логотипа «Совместимо! Система программ «1С:Предприятие».
КП: Если можно, расскажите, как документируется ПО.
А.Х.: Подробное и всестороннее документирование своих программ мы считаем исключительно важной задачей. Ведь современные системы автоматизации учета - это гибкие и в то же время функционально очень насыщенные продукты. Эффективно их использовать, корректно настраивать, вести учет с высокой степенью автоматизации без качественной документации нельзя. Так, например, официальные пользователи «1С:Бухгалтерия 7.7» получают в комплекте поставки семь томов документации общим объемом более 3000 страниц.
В написании документации участвуют и собственно разработчики, и специальные сотрудники, приглашаются сторонние специалисты, например аудиторы.
Выпускается и широкий спектр дополнительной методической литературы, посвященной ведению различных разделов учета с использованием программ «1С». Такие книги пишут профессиональные экономисты и специалисты по бухучету, например заведующий кафедрой Финансовой академии при Правительстве РФ профессор Д.В.Чистов или известный аудитор С.А.Харитонов.
А.Х.: Основное средство разработки системной части - MS Visual C++. Все прикладные решения пишутся собственно на технологической платформе «1С:Предприятие», возможности которой позволяют эффективно создавать и модифицировать прикладные решения.
Использование в «1С:Предприятие» набора типовых объектов предметной области позволяет избавить проектировщика от целого этапа разработки, а также от комплекса проблем, встающих при проектировании структур таблиц базы данных.
Объекты «1С:Предприятие» существенно упрощают не только проектирование и поддержание структуры базы данных. Второй их важной особенностью является то, что они реализуют существенную часть бизнес-логики задачи автоматизации. Три функциональных компонента «1С:Предприятие» поддерживают три основных механизма учета: оперативный учет, бухгалтерский учет и сложные периодические расчеты. Настройка этих механизмов выполняется визуально и обеспечивает не только все необходимые структуры данных, но и расчетные и аналитические операции.
В случае тиражируемого прикладного решения очень важно, может ли разработчик передать его поддержку сторонней организации. В системе «1С:Предприятие» структура конфигурации сама по себе является четко организованной схемой построения прикладного решения. Состав объектов конфигурации является формализованным описанием и структуры данных, и бизнес-логики прикладной задачи. Специалист, знакомый с объектами «1С:Предприятие», практически за несколько минут может по составу объектов конфигурации понять ее основные принципы.
Вообще конфигурация «1С:Предприятие» - нечто большее, чем программа, написанная на некотором языке. Фактически это проект, который вмещает в себя и алгоритмы, и интерфейс, и словарь данных, и даже документацию. Структура конфигурации сама по себе является четко организованной схемой построения прикладного решения.
По нашему мнению, для средств разработки экономических программ (в отличие от большинства других) очень важны возможности поддержки уже работающих проектов. Средства конфигурирования «1С:Предприятие» обеспечивают не только собственно разработку, но и сопровождение работающей конфигурации. Даже при самом качественном и всестороннем проектировании на практике не удается избежать модификации прикладного решения. Даже если у пользователей не появятся новые требования, то о необходимости модификации обязательно позаботятся соответствующие правительственные организации.
Возможности платформы «1С:Предприятие» позволяют без особых усилий обеспечить отчуждаемость от разработчика самого процесса обновления прикладного решения. Это помогает легко поддерживать одинаковые или сходные прикладные решения многим пользователям. Получив обновленное прикладное решение, пользователь может самостоятельно установить его, не прибегая к сложным манипуляциям с базой данных. При этом средства конфигурирования позволяют выполнять обновление прикладного решения, даже если работающая конфигурация была модифицирована заказчиком самостоятельно и соответственно отличается от того оригинала, в который вносит изменение разработчик. Весьма полезной является также возможность сравнения конфигураций, позволяющая выявить все внесенные изменения - от структур данных до алгоритмов программных модулей.
Другим полезным механизмом является ведение журнала работы пользователей с фиксацией всех существенных действий пользователя и возможностью полного или выборочного просмотра журнала. При этом разработчик конфигурации может вносить в журнал дополнительные события, не протоколируемые системой по умолчанию. Используя журнал регистрации, разработчик имеет возможность получить не только список ошибок, возникавших в системе за то время, когда пользователи работали «без присмотра», но и проследить последовательность действий, приведших к возникновению этих ошибок.
Такие возможности системы «1С:Предприятие 7.7» позволили реализовать технологию непрерывного индустриального сопровождения эксплуатируемых учетных систем, которую мы считаем очень перспективной. Сейчас центральным звеном поддержки всех категорий пользователей и специалистов по внедрению является ежемесячно выпускаемый компакт-диск информационно-технологического сопровождения (ИТС). Это подписное издание, на котором содержатся обновления текущих версий программ, дополнения к типовым конфигурациям, новые формы отчетности, методические материалы и рекомендации по использованию программных продуктов, комментарии и правовая информация по учету, налогообложению и многое другое. В результате пользователю, работающему с системой, для внесения в нее очередных обновлений, например отражения изменений в правилах расчета налогов, достаточно установить новый релиз типовой конфигурации с диска ИТС.
Разработка на платформе «1С» ведется не только в пределах фирмы, но и в масштабах всей страны - «1С:Предприятие» изначально предназначалось для того, чтобы независимые специалисты могли настраивать продукты в точном соответствии с потребностями предприятий, используя наши типовые конфигурации в качестве основы. Эти работы выполняют сейчас около 1500 фирм, входящих в сеть «1С:Франчайзинг». Возможности «1С:Предприятие» позволяют франчайзи создавать эффективные тиражные решения для автоматизации предприятий различных отраслей.
Поэтому фирма «1С» принимает серьезные меры по технологической и методической поддержке партнеров-разработчиков, разработке технологий и стандартов интеграции «1С:Предприятия» с другими системами. Кроме упомянутой выше методики сертификации партнерских разработок на совместимость с «1С:Предприятие», выпущены методики интеграции с торговым оборудованием, совместно с ведущими разработчиками банковского ПО разработан открытый стандарт обмена данными с системами типа «клиент банка», сейчас совместно с Microsoft ведутся работы над стандартами по электронному обмену торговой информацией в формате XML..
(Продолжение следует)
КомпьютерПресс 10"2000