Russian Language English Language

3. Модели и методы для обоснования выбора состав программных средств ВС

3.1 МЕТОДОЛОГИЧЕСКИЕ ОСНОВЫ СОЗДАНИЯ И ПРИМЕНЕНИЯ КИС ВУЗА .

3.2 УПРАВЛЕНИЕ КАЧЕСТВОМ В ЖИЗНЕННОМ ЦИКЛЕ ПРОГРАММНЫХ СРЕДСТВ (СТАНДАРТЫ И МЕТОДЫ).

3.3 О ВЫБОРЕ ПОДХОДА ДЛЯ ОБОСНОВАНИЯ ЦЕЛЕСООБРАЗНОСТИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ НА ОСНОВЕ ПРЕДВАРИТЕЛЬНОЙ ОЦЕНКИ ОСНОВНЫХ ПОКАЗАТЕЛЕЙ ИТ-ПРОЕКТА .

3.4 ОБЕСПЕЧЕНИЕ КАЧЕСТВА ПРОГРАММНЫХ СРЕДСТВ НА ОСНОВЕ АВТОМАТИЗАЦИИ ТЕСТИРОВАНИЯ.

3.5 . К ВОПРОСУ О ПЕРСПЕКТИВНОСТИ РАСШИРЕННОГО ПРИМЕНЕНИЯ МЕТОДОВ КОНТЕКСТНОГО МОДЕЛИРОВАНИЯ В АЛГОРИТМЕ JPEG 2000.


Экспресс информация

Редколлегия журнала

Подписка на новости

Гостевая книга

Предоставление материалов

Письмо в редакцию

На начало


2006, Номер 2 ( 9)



Place for sale
BC/NW 2006, №2, (9) :3

BC/NW 2006, №2, (9) :3.3

 

О ВЫБОРЕ ПОДХОДА ДЛЯ ОБОСНОВАНИЯ ЦЕЛЕСООБРАЗНОСТИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНЯ НА ОСНОВЕ ПРЕДВАРИТЕЛЬНОЙ ОЦЕНКИ ОСНОВНЫХ ПОКАЗАТЕЛЕЙ ИТ-ПРОЕКТА

 

Васильева А.К.

 

(Москва, ГОУ МГТУ «Станкин», Россия)

 

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

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

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

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

На сегодняшний день практически все ведущие компании - разработчики технологий и программных продуктов (IBM, Oracle, Borland, Computer Associates и др.) располагают развитыми технологиями создания ПО, которые создавались как собственными силами, так и за счет приобретения продуктов и технологий, созданных небольшими специализированными компаниями (табл.1). Выбор в качестве примера четырех перечисленных компаний объясняется их ведущими позициями на мировом рынке ТС ПО и присутствием на российском рынке.

Однако рынок испытывает явный дефицит предложения в области интеграции информационных систем для производителей программного обеспечения. Такие решения, как линейка продуктов Rational, пока остаются недоступны большинству российских компаний-разработчиков, хотя отдельные компоненты получили заметное распространение. Альтернативные варианты представлены слабо. При этом выглядит недостаточно обоснованным утверждение, что цель может быть достигнута только путем перехода на средства одного производителя. На повестке дня выработка методики и технологий интеграции, и в их формировании должны участвовать как разработчики, так и консультанты.

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

Основная трудность при инициации (внешних) проектов — слишком позднее получение исполнительными подразделениями информации о проекте и зачастую неадекватные или ошибочные предварительные оценки объема работ. Нередки ситуации, когда прикидочные оценки менеджеров не совпадают с реальными исполнители узнают о проекте уже после подписания договора, когда ничего изменить или отложить уже нельзя. Довольно частым заблуждением менеджеров по продажам является уверенность в готовности остальных сотрудников выполнить любой объем работ в любые поставленные сроки, обеспечив при этом отличное качество.


Таблица 1. Современные технологии создания ПО ведущих компаний-поставщиков

Компания

Методология

Инструментальная поддержка

IBM Rational Software

Rational Unified Process

§         Rational Suite AnalystStudio - предназначен для определения и управления полным набором требований к разрабатываемой системе;

§         Rational Suite DevelopmentStudio - предназначен для проектирования и реализации ПО;

§         Rational Suite TestStudio - представляет собой набор продуктов, предназначенных для автоматического тестирования приложений;

§         Rational Suite Enterprise - обеспечивает поддержку полного жизненного цикла ПО и предназначен как для менеджеров проекта, так и отдельных разработчиков, выполняющих несколько функциональных ролей в команде разработчиков.

Rational Suite:

§         Rational Rose

§         Rational XDE

§         Rational Requisite Pro

§         Rational Rapid Developer

§         Rational ClearCase

§         Rational SoDA

§         Rational ClearQuest

§         Rational Quantify

§         Rational Purify

§         Rational PureCoverage

§         Rational TestManager

§         Rational Robot

§         Rational TestFactory

§         Rational Quality Architect

Oracle

Oracle Method:

  • CDM (Custom Development Method) - разработка прикладного ПО;
  • PJM (Project Management Method) - управление проектом;
  • AIM (Application Implementation Method) - внедрение прикладного ПО;
  • BPR (Business Process Reengineering) - реинжиниринг бизнес-процессов;

·         OCM (Organizational Change Management) - управление изменениями, и др.

Oracle Developer Suite:

§         Oracle Designer

§         Oracle Forms

§         Oracle Reports

§         Oracle JDeveloper

§         Oracle Discoverer

§         Oracle Warehouse Builder

§         Oracle Portal

Borland

Application Life Cycle Management (ALM)

§                  CaliberRM - система управления требованиями;

§                  Together ControlCenter - интегрированная среда проектирования и разработки;

§                  Optimizeit Suite 5, Optimizeit Profiler for .NET и Optimizeit ServerTrace - средства тестирования;

§                  StarTeam - система управления конфигурацией и изменениями

Computer Associates

 

AllFusion Modeling Suite:

§                  AllFusion Process Modeler (BPwin) - функциональное моделирование;

§                  AllFusion ERwin Data Modeler (ERwin) - моделирование данных;

§                  AllFusion Component Modeler (Paradigm Plus) - объектно-ориентированный анализ и проектирование с использованием UML и возможностью генерации кода;

§                  AllFusion Model Manager (Model Mart) - организация совместной работы команды разработчиков;

§                  AllFusion Data Model Validator (ERwin Examiner) - проверка структуры и качества моделей данных.

AllFusion Change Management Suite - комплекс средств управления конфигурацией и изменениями.

AllFusion Process Management Suite - средства управления процессами и проектами для различных типов приложений


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

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

Основная трудность при инициации (внешних) проектов — слишком позднее получение исполнительными подразделениями информации о проекте и зачастую неадекватные или ошибочные предварительные оценки объема работ. Нередки ситуации, когда прикидочные оценки менеджеров не совпадают с реальными исполнители узнают о проекте уже после подписания договора, когда ничего изменить или отложить уже нельзя. Довольно частым заблуждением менеджеров по продажам является уверенность в готовности остальных сотрудников выполнить любой объем работ в любые поставленные сроки, обеспечив при этом отличное качество. Предварительный анализ технико-экономических параметров проекта и заблаговременное информирование о целях, сроках и задачах проекта позволит заранее подготовиться к их реализации, спланировав эффективное использование ресурсов.

Цели ТЭА (технико-экономического анализа)

Первая цель – прогнозирование реальных затрат на разработку определенного проекта с учетом его сложности и требуемого качества.

Вторая цель – создание методик прогнозирования затрат и длительности разработки комплексов программ. Методики должны учитывать полученные значения ТЭП, основные характеристики создаваемых ПС, а также технологию, оснащенность и организацию их разработки.

Третья цель – обоснование и создание методов и средств снижения совокупных затрат, сроков разработки сложных ПС.

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

В числе причин возможных неудач, по мнению разработчиков, фигурируют:

-       нечеткая и неполная формулировка требований к ПО;

-       слабая (или вовсе отсутствующая) «обратная» связь с пользователями;

-       неадекватная оценка имеющихся ресурсов;

-       неудовлетворительное планирование и отсутствие грамотного управления проектом;

-       новизна и несовершенство используемой технологии;

-       недостаточная поддержка со стороны высшего руководства;

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

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

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

ЛИТЕРАТУРА.

1.     Боэм Б.У. Инженерное проектирование программного обеспечения. Пер. с англ./Под ред. А.А. Красилова. – М.: Радио и связь, 1985.

2.     Липаев В.В. Технико-экономическое обоснование проектов сложных программных средств. – М.: СИНТЕГ, 2004. – 284 с. (Серия «Управление качеством»)

3.     Костогрызов А.И., Нистратов Г.А. Стандартизация, математическое моделирование, рациональное управление и сертификация в области системной и программной инженерии – М.: Изд-во ВПК и 3 ЦНИИ МО РФ. 2004. – 396 с.

4.     Cockburn, A., Surviving Object-Oriented Projects, Addison-Wesley, 1998.