Чалый Сергей Фёдорович

Цель курса : освоение принципов модели ев и методов используемых в цикле разработке сложный программных систем

Технологий конструирование программных систем

Определение,

Классически жизненный цикл, макетирование

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

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

Средства – обеспечивают поддержку методов.

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

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

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

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

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

Диаграмма Ганта

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

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

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

Тестирование и верификация - суть верификация(требование проект и рабочая программа , между проектом и программой тестирование(все ли требование выполняет программа ), между требование и проектом верификация(определяет соответствие всели требование вложили в проект ))

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

Лекция 2

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

2. полные результаты работы только в конце разработки.

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

Макетирование

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

Варианты макетов :

1. Представление диалога(либо на бумаге либо прототип)

2. Макет с частичной функциональностью

3. Существующая программа коротая частично реализует требуемой функционал

Цикл макетирование :

1. Посторенние перовой версии макета

2. Оценка макета заказчиком

3. Предложение заказчика

4. Уточнение макета, поле этого go to 2

Достоинства : позволяет определить требование к программе.

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

Стратегия конструирование программных систем

Основные стратегии :

1. Водопадная стратегия- которая реализует рассмотренный ране классический жизненный цикл.

2. Инкрементная стратегия которая реализует инкрементную модель.

Суть : постепенное расширение функциональности в процессе разработке при заранее определённых требованье.(все требованье заранее преопределённые, а потом создавая версии, постепенно реализуем функционал ).

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

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

Реализация инкрементной стратегии модели RAD(Rapid Application development)

Особенности:

1. Очень короткий цикл разработки.

2. Распарелирование в процессе разработки.

3. Обычно используется для разработки бизнес приложений

Система разрабатывается на 2-3 месяца

Этапы RAD :

1. Бизнес моделирование. Суть : функции, потоки информации между функциями. Необходимо определить какая информация необходима для управлении соответствующими бизнес процессами

2. Какая информация должна быть сгенированая разрабатываемой системой

3. Где она применяется

4. Кто ее использует

!

!

!

1) Моделирование данных (создание реляционной базы ),

2) определить объекты с которыми будет работать программная система

3) моделирование обработки – реализация бизнес функций которые рассмотрены на этапе 1

4) генерация приложений

5) тестирование и объединение в единую систему.(распарелированье объедениям в единю систему ).

Достоинства:

1. Быстрая разработка, скорость.

2. Возможность построение макета .

3. Возможность уточнение требованье .

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

Реализация эволюционной стратегии

1. Спиральная модель

2. Компонентно-ориентированная модель

Лекция 3

С

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

Анализ

Оценка заказчика

Конструирование

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

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

Анализ – анализ рисков, анализируем варианты по предыдущий шагам и оцениваем, распознаем, выбираем допустив риск

Конструирование- разработка продукта следующий версии

Оценка заказчиком – оценка заказчиком текущих результатов.

С каждой ветком спирали строиться все более полные версии программной системы. Веток 1 определяет начальные цели, варианты, ограничение. Если анализ риска на первом ветке показывает не точность либо неопределённость требование, то мы используем макетировании. Заказчик оценивает наш макет и вносит предложение по усовершенствованью программного проекта. На этих результатах основывается следующий круг спирали. Со второго круга оценка риска видеться в бинарном виде (да-нет), то есть будем ли продолжать проект при таком уровне требованию. Со ветка обычно реализуются в конструированию реализуется классический жизненный цикл. Мы для каждой версии проходим всю цепочку.

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

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

Компонентная ориентированная модель

1. Развития спиральной модели.

2. Детализируются конструирование .

3. Основана на повторном использование программных компонентов.

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

Достоинства: сокращение времени разработки, уменьшает стоимость.

Недоставки: резкое повышение к аппаратным ресурсам

Экстремальное программирование

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

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

Основные особенности экстремального программирование : придуманная в 1999г., ориентирование на группы среднего и малого размера, обычно до 10 сотрудников и в одном помещении, неопределённые и быстро меняющие требование, низкая стоимость изменение в программном проекте, цикл разработки состоит из коротких итераций, их базовыми действиями являются : кодирование, тестирование, обсуждение с заказчиком и проектирование, при этом реализуется принцип минимализма , быстрая и обратная часть на базе тестирование и постоянная связь с заказчиком.

Методы экстремального программирование

Доступ к базам данных модели adо.Net

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

На разработку многоуровневых приложений корпоративного мастаба.

Таблицы

База данных

Общий подход:

Основные компоненты:

Провайдер данных(Data Provider) и набор данных(Data set). Провайдер данных отвечает за связь приложений источником данных и манипуляциями данными. Вариации: Connection обеспечивает соеденение с данными + управления транзакциями. Комент – дает возможность манипулировавать данные источника, манипулировать процедурами, в том числе с параметрами. ДатаАдаптер служит связующим звеном между источником данных и датсет. Использует объект коммент, для выполнения команд SQL/ DataReader – только для чтения. DataSet – некий аналог или образ реалиционной базы данных, который хранится в оперативной памяти клиента. Можем загрузить данные из одного источника или нескольких в дата сет потом соеденения разорвать и работатьь только с набором данных.

Нужно для обеспечения работы в глобальной сети. Детализуем основные моменты датасет, включает 2 колекции: таблиц, связей. DateTable collaction объединятет объекты DateTable, каждая из котоорых представляет одну таблицу. Каждая таблица состоит из колекции колонок и строк. Date columCollection включает непосредственно колонки базы данных и вычисляемые. DateRow cllection строки. Хранятся как исходные значения так и измененые. Ограничение constrain collection – набор ограничений целостности данных. DatarelationCollection связи между таблицами

Управление проэктом

1. Управление проэктом. Типовая схема

Управление проэктом предпологает разработку программного продукта в рамках отведенных средств и времени.Охватывает :

1. инфраструктуру(организационный момент).

2. Управляющий процесс(права и обязаности участников)

3. процесс разработки

4. Расписание

Факторы, которые влияют на упровление проэктом:

1. Стоимость

2. Возможности

3. Качество

4. Длительность проэкта

Типичная схема процесса управления проэктом:

1. Иследование прдметной области(внутренное содержание область применения временные рамки)

2. Определяемся со средствами разработки и технологиями.

3. Разработка Огр структуры

4. Распределение отвецтвенности.

5. Расписание

6. План под Буракадо

7. Управление рисками

8. Документы

9. Начало процесса разработки

Во 2 пункте выбераем каскадную, водопадную, инкрементную модель…

В 4 пункте кто перед кем отчитывается

В 5 помимо рассписание задается количество человека дней, количество сотрудников и тд

Подбор участников проэкта.

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

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

Выявление уменьшение рисков. Риск представляется в виде факторов, которые могут проявится в виде факторов, которые могут появится по ходу проэктов и негативно влиять на проэкт.

2 типа: которых можно избежать или предотвратить.

2 тип – которых избежать нельзя.

Пример 1 уходит руководитель проэкта, зарание подготовка зама зарание.

Риск 2-го типа – необходимо собрать данные работникам какого предприятия перед тем как сделать программу.

Управлеине рисками:

Необходимо идентифицироватьт риски. Основная проблемма: неиндецифицированые риски. Шаги управления рисками:

1. Идентификация

2. Планирование устранение

3. Выбор приорететов

4. Устранение или уменьшение рисков

Шаги делаются с самого начала проэкта.

Детализуем шаги выявление рисков:

Часто методом мозгового штурма.

Категории рисков

1. Переоценивание робочего времени

2. Слишком быстрое изменение требований

3. Отстутствие или невозможно найти необход инструментарий

4. Недостаточные навыки персонала

5. Нехватка времени для обучения

6. Неефективность использования существующих языков программирования.

Предупреждение рисков

Риски

Управление рисками состоит из идентификации

Руководство програмным проэктом

1. Процесс руководства програмным проэктом

- как планировать програмный проэкт

- как оценивать програмный проэкт

Руководство програмным проэктом позволяет определить объем предстоящих робот, риски, ресурсы, задачи, временные метки, материальные затраты, план рабботы.

До планирования необходимо:

1. установить цели проэкта

2. Получить краткую характеристику предметной области

3. Альтернативные пути разработки програмного обеспеченя

4. Ограничения(технические)

5. Время(управленчиские)

6. Финансовый

Меры элементов:

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

Все остальные свойства оцениваются как результат вычесления тех или иных функций от базовых свойств. Результатом являются числовые значения именуемые метрикой.

В программной инженерии мера и метрика рассматриваются как синонимы.

Офицыальное определение:

Метрика – мера степени обладания свойством, имеющее числовое значение.

Последовательность оценки:

1. Людские рисурсы человека в месяцах

2. Продолжительность: месяцев, дней

3. Стоимость в тысячах условных едениц

Риски(речь идет о скрытых проэктах)

1. Скрытые технические проблемы

2. Срыв срока

3. Срыв оплаты, или недостаточная оплата

Планирование:

- определяется набор проэктных задач

- устанавливается связи между задачами

- оценка сложности каждой с задач

- определяется необходимые ресурсы

- сетевой график(график выполнения + сетевые метки)

Контроль:

1. Каждая задача отслеживается руководителем проэкта

2. При отставании перепланирования(повторное планирование)

Важно: определить влияние этого отставания на общий процесс.

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

Результат планирования (контроля):

Реорганизация задач

Перераспределение ресурсов

Изменение обязательств

Планирование проэктных задач:

1. Системный анализ, анализ требований

Системный анализ:

1. Потребности

2. Оценка выполнимости разрабатываемой системы

3. Экономический анализ

4. Технический анализ(«как это реализовать?»)

5. Распределение функций

Распределение обязаностей

Определения нужного железа

Выбор софта

…