изненный цикл программного приложения

нформационные технологии

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

Программное обеспечение для инженеров:

1) Разработка программных продуктов

2) Система автоматизированного проектирования (САП)

3) Математическое программное обеспечение

4) Офисное программное обеспечение

роцесс разработки программного приложения

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

сновные этапы (разделы) разработки программного приложения

Этапы разработки программного приложения:

1. Разработка требований

2. Проектирование программного приложения

3. Инженерия (создание программного приложения)

4. Тестирование

5. Обслуживание

6. Управление конфигурацией

7. Управление разработки программного приложения

8. Инструменты

9. Качество программного приложения

10. Локализация

изненный цикл программного приложения

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

2.3 Модель процесса разработки программного приложения: каскадная модель.

Каскадная модель – это модель разработки программного приложения в котором процесс выглядит как поток в последовательно включающий в себя:

· Анализ требований

· Проектирование реализация

· Тестирование

· Интеграция

· Поддержка

2.4 Модель процесса разработки программного приложения: итеративная модель

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

Каждая итерация включает в себя:

· Анализ требований

· Проектирование

· Создание (кодирование)

· Тестирование

· Документирование

Интерактивная модель в отличии от каскадной модели делают упор на общение с заказчиком.

2.5 Модель процесса разработки программного приложения: экстремальное
программирование.

Экстрема́льное программи́рование— это одна из гибких методологий разработки программного приложения.

1. Короткий цикл обратной связи

1.1 Разработка через тестирование

1.2 Игра в планирование

1.3 Заказчик всегда рядом

1.4 Парное программирование

2. Непрерывный процесс

2.1 Непрерывная интеграция

2.2 Постоянное улучшение кода

2.3Частые небольшие релизы

3. Понимание, разделяемое всеми

4. Простота Социальная защищенность
2.6 Проблемы разработки программного приложения

· Недостаток прозрачности. В любой момент времени сложно сказать, в каком состоянии находится проект и каков процент его завершения.

· Недостаток контроля. Без точной оценки процесса разработки срываются графики выполнения работ и превышаются установленные бюджеты.

· Недостаток трассировки.

· Недостаток мониторинга. Невозможность наблюдать ход развития проекта не позволяет контролировать ход разработки в реальном времени.

· Неконтролируемые изменения. У потребителей постоянно возникают новые идеи относительно разрабатываемого программного обеспечения.

· Недостаточная надежность. Самый сложный процесс — поиск и исправление ошибок в программах на ЭВМ. Поскольку число ошибок в программах заранее неизвестно, то заранее неизвестна и продолжительность отладки программ и отсутствие гарантий отсутствия ошибок в программах.

· Отсутствие гарантий качества и надежности программ из-за отсутствия гарантий отсутствия ошибок в программах вплоть до формальной сдачи программ заказчикам.

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

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

3.1 UML: история, использование и преимущества

История:

Официально создание UML началось в октябре 1994 года, когда Рамбо перешел в компанию Rational Software, где работал Буч. Первоначальной целью было объединение методов Буча и ОМТ. Первая пробная версия 0.8 Унифицированного Метода (Unified Method), как его тогда называли, появилась в октябре 1995 года. Приблизительно в это же время в компанию Rational перешел Джекобсон, и проект UML был расширен с целью включить в него язык OOSE. В результате совместных усилий в июне 1996 года вышла версия 0.9 языка UML. На протяжении всего года создатели занимались сбором отзывов от основных компаний, работающих в области конструирования программного обеспечения. За это время стало ясно, что большинство таких компаний сочло UML языком, имеющим стратегическое значение для их бизнеса. В результате был основан консорциум UML, в который вошли организации, изъявившие желание предоставить ресурсы для работы, направленной на создание полного определения UML.

Использование:

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

Преимущества:

· UML объектно-ориентирован, в результате чего методы описания результатов анализа и проектирования семантически близки к методам программирования на современных объектно-ориентирован языках;

· UML позволяет описать систему практически со всех возможных точек зрения и разные аспекты поведения системы;

· Диаграммы UML сравнительно просты для чтения после достаточно быстрого ознакомления с его синтаксисом;

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

· UML получил широкое распространение и динамично развивается.

3.2 UML: диаграмма классов
Диаграмма классов - статическая структурная диаграмма, описывающая структуру системы, она демонстрирует классы системы, их атрибуты, методы и зависимости между классами.

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

· концептуальная точка зрения — диаграмма классов описывает модель предметной области, в ней присутствуют только классы прикладных объектов;

· точка зрения спецификации — диаграмма классов применяется при проектировании информационных систем;

· точка зрения реализации — диаграмма классов содержит классы, используемые непосредственно в программном коде (при использовании объектно-ориентированных языков программирования).

3.3 UML: диаграмма деятельности

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

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

3.4 UML: диаграмма взаимодействия

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

Этот тип диаграмм включает в себя диаграммы (диаграммы последовательностей действий) и (диаграммы сотрудничества). Эти диаграммы позволяют с разных точек зрения рассмотреть взаимодействие объектов в создаваемой системе.

3.5 UML: диаграмма вариантов использования

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

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

3.6 UML: диаграмма состояния

Диаграмма состояний — диаграмма, на которой представлен конечный автомат с простыми состояниями, переходами и композитными состояниями.

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