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



В триаде системного подхода учитывается, что:

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

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

Глава 2. Процесс разработки программных систем

2.1 Жизненный цикл ПО

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

системный анализ и обоснование необходимости разработки;

1. 
   Формирование требований.
   
2. 
   Проектирование.
   
3. 
   Программирование.
   
4. 
   Тестирование и отладка.
   
5. 
   Ввод программы в действие.
   
6. 
   Эксплуатация и сопровождение.
   
7. 
   Завершение эксплуатации.
   

Процессы жизненного цикла ПО в настоящее время регламентируются стандартом ISO 12207–1999 и показаны на (рис 2). Они объединены в три группы: основные, вспомогательные и организационные.



Основной процесс разработки ПО в данной модели жизненного цикла представляет собой анализ, проектирование и реализацию программной системы. Он включает работы по созданию ПО в соответствии с заданными требованиями,

---

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

2.2 Этапы проектирование программных систем

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

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

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

− определение требований.

− проектирование.

− конструирование (реализация, кодирование).

− воплощение.

− тестирование и отладка (в том числе верификация).

− инсталляция,

− поддержка.

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

---

2.3 Управление программных проектами

Процесс проектирования программной системы является, как правило, достаточно сложным и противоречивым.

К основным источникам возникающих сложностей относятся:

− наличие и доступность высококвалифицированных специалистов на рынке труда

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

−эффективность используемых методов разработки, включая методы моделирования, проектирования, тестирования и управления версиями

−наличие и доступность специалистов, обладающих экспертизой в прикладной области

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

−множество других организационных и технических переменных.

Данные сложности приводят к проблемам при управлении программными проектами, которые могут определяться следующими факторами.

1. 
   Многие процессы разработки неуправляемы, их исходные данные и желаемый результат неизвестны или определены очень нечетко.
   
2. 
   Процесс достижения желаемого результата не поддается формализации, наиболее это характерно для разработки архитектуры и исчерпывающего тестирования продукта.
   
3. 
   Идентифицированные процессы разработки сопровождаются неизвестным количеством неидентифицированных.
   
4. 
   Требования к продукту часто меняются в течение жизненного цикла проекта, что требует сложной процедуры изменения и согласования требований.
   
5. 
   Попытки предложить формальную, детализованную методологию разработки ПО оказываются безуспешны, потому что сам процесс разработки не поддается детализации и формализации.
   
6. 
   Слепое следование методологиям, предполагающим управляемость и предсказуемость процессов разработки, приводит к непредсказуемым результатам проекта.
   

Любой проект разработки ПО имеет свою организационную модель, которая определяет распределение обязанностей, ответственности и полномочий среди исполнителей проекта, а также отношений отчетности. Чем меньше проект, тем больше ролей приходится совмещать одному исполнителю. Всех исполнителей типового проекта разработки ПО можно условно разделить на пять категорий в соответствии с их ролями:

1. 
   анализ – сбор информации, исследование, составление и сопровождение требований к продукту
   
2. 
   управление – организация и управление производственными процессами
   
3. 
   производство – проектирование и разработка ПО
   
4. 
   тестирование – проверка и контрольные испытания ПО
   
5. 
   обеспечение – производство дополнительных продуктов и услуг
   

---

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

2.4 CASE - технологии

Многочисленные факторы, определяющие сложности в реализации программных проектов, привели к появлению программно-технологических средств автоматизации процесса проектирования ПО – CASE-средств. При этом реализуется специальная CASE-технология создания и сопровождения программных систем, которая представляет собой методологию автоматизированного проектирования ПО, а также инструментальные средства реализации. Это позволяет в наглядной форме представлять модель предметной области, анализировать ее на всех этапах разработки и сопровождения системы, разрабатывать программные компоненты в соответствии с информационными запросами пользователей. САSЕ технология включает в себя методы визуализации программных решений, с помощью которых на основе графической нотации строятся диаграммы, поддерживаемые инструментальной средой.

САSЕ-средства повышают производительность труда программистов и улучшают качество программного обеспечения. Это достигается тем, что они:

−Обеспечивают автоматизированный контроль совместимости спецификаций проекта

−Уменьшают время создания прототипа системы и ускоряют процесс проектирования и разработки

−Автоматизируют формирование проектной документации для всех этапов жизненного цикла

−Частично генерируют коды программ для различных сред разработки; − поддерживают технологии повторного использования компонентов

−Обеспечивают возможность восстановления проектной документации по имеющимся исходным кодам.

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

2.5 Методологии разработки ПО

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

---

На разных уровнях и по разным критериям выделяют пересекающиеся модели: − водопадная (каскадная) модель, реализующая основное направление нисходящего структурного программирования

− макетирование

− спиральная (итерационная) модель разработки ПО

− объектно-ориентированное программирование

− гибкие (agile) технологии: экстремальное программирование (ХР), Scrum, TDD, FDD

− методология моделирования RUP (Rational Unified Process); − методологии компонентного подхода (СОМ, CORBA, RAD).

---

Смотрите также файлы

• Практическая работа по теме Особенности конструирования современного урока географии.docx

• Контроль знаний Вопрос 1.docx

• Форма индивидуального задания Федеральное государственное образовательное бюджетное учреждение высшего образования Финансовый университет при Правительстве Российской Федерации.docx

• Реферат по дисциплине Закон организации и организационное поведение Вариант бн Тема Закон синергии Исполнитель студент Сагиндиков Руслан Бийманбетович Группы пменмз221 Факультета экономики и управления.docx

• Кто всю ночь по крыше бьет да постукивает, и бормочет, и поет, убаюкивает.pptx