Повторное использование компонентов ИС

Одним из характерных признаков инженерной деятельности является использование готовых решений или деталей. Однако промышленное использование готовых решений в программной инженерии еще не стало повседневной практикой. Примерно 80 % программистов работают над созданием программ учета и организационного управления на нескольких уровнях: отдельного подразделения фирмы, отдельного аспекта деятельности фирмы, фирмы в целом, корпорации, отрасли и, наконец, государства. Это, преимущественно, задачи расчетов, статистики, помощи в принятии решений при управлении различными ресурсами - кадровыми, финансовыми и т.д.

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

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

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

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

Менеджмент разработка ИС

Следует отметить, что количество неудачных проектов уменьшилось в компаниях, которые работают над небольшими по объему, а потому более удобными для управления проектами.

Анализ проектов, которые потерпели крах, дал возможность выделить наиболее распространенные причины провалов. К ним можно отнести следующие:

o руководители проектов не понимают требований заказчика;

o масштабы проекта определено неправильно;

o изменения проекта производятся с большими трудностями;

o разработчики меняют выбранную технологию проектирования;

o заказчик меняет требования;

o избранный срок выполнения проекта нереальный;

o пользователь не принимает некоторых решений;

o инвестиции потеряно;

o для реализации проекта не хватает исполнителей;

o менеджеры проекта не применяют прогрессивных методов руководства.

Методология создания ИС

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

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

Известны такие стандарты жизненного цикла ИС:

o ГОСТ 34.601-90;

o ISO/IEC 12207:1995;

o Custom Development Method (методика Oracle);

o Rational Unif сву Process (RUP);

o Microsoft Solutions Framework (MSF) включает 4 фазы: анализ, проектирование, разработка, стабилизация; предполагает использование объектно-ориентированного моделирования;

o экстремальное программирование (Extrкme Programming, XP). В основе методологии - командная работа, эффективная коммуникация между заказчиком и исполнителем в течение всего проекта по разработке ИС. Разработка ведется с использованием последовательных прототипов.

Стандарт ГОСТ 34.601-90 предусматривает следующие стадии и этапы создания автоматизированной системы (АС):

1. Формирование требований к АС:

o обследование объекта и обоснование необходимости создания АС;

o формирование требований пользователя к АС;

o оформление отчета о выполнении работ и заявки на разработку АС.

2. Разработка концепции АС:

o изучение объекта;

o проведение необходимых научно-исследовательских работ;

o разработка вариантов концепции АС и выбор варианта концепции АС, удовлетворяющего требования пользователей;

o оформление отчета о проделанной работе.

3. Техническое задание; разработка и утверждение технического задания на создание АС:

4. Эскизный проект:разработка предварительных проектных решений по системе и ее частям; разработка документации на АС и ее части.

5. Технический проекте

o разработка проектных решений по системе и ее частям;

o разработка документации на АС и ее части;

o разработка и оформление документации на постачайня комплектующих изделий;

o разработка заданий на проектирование в смежных частях проекта.

6. Рабочая документация:

o разработка рабочей документации на АС и ее части;

o разработка и адаптация программ.

7. Введение в действие: подготовка объекта автоматизации и персонала.

8. Сопровождение АС:

o выполнения работ согласно гарантийных обязательств;

o послегарантийное обслуживание.

Эскизный, технический проекты и рабочая документация - это последовательное построение все более точных проектных решений всех видов обеспечения информационной системы. Допускается исключать стадию " Эскизный проект " и отдельные этапы работ на всех стадиях, объединять стадии " Технический проект и Рабочая документация в Технорабочий проект, параллельно выполнять различные этапы и работы, включать дополнительные.

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

Стандарт ISO/IEC 12207:1995 (Information Technology Software Life Cycle Processes) является основным нормативным документом, регламентирующим состав процессов жизненного цикла ИС.

Он определяет структуру жизненного цикла, содержащую действия, которые должны быть выполнены во время создания ИС.

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

 
< Пред   СОДЕРЖАНИЕ   След >