Методы проектирования.

Модели систем:

1) Модель потоков данных (дата логическая модель). Система представляется в виде потоков данных преобразуемых этой системой.

2) Инфологическая модель (модель «сущность – связь»). Здесь описываются объекты программной системы (сущность) и связи между ними.

3) Структурная модель предназначена для документирования системы компонентов и их взаимосвязей.

4) Объектно-ориентированная модель отображает иерархию системы, статические и динамические отношения между объектами и взаимодействие объектов во время работы системы.

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

Программирование и отладка:

Программирование – это индивидуальный процесс. Здесь не существует общих правил, которым необходимо следовать при написании кода.

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

Аттестация программных систем:

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

Этапы процесса тестирования:

1)Тестирование компонентов. Тестируются отдельные компоненты для проверки правильности их функционирования. Каждый компонент тестируется независимо от других тем, кто его создавал.

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

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

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

5)Приемочные испытания. Это конечный этап процесса тестирования после которого система принимается к эксплуатации. Здесь система тестируется с привлечением данных предоставляемых заказчиком, а не на основе тестовых данных, как на предыдущем этапе.

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

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

Введение в ПИ 11 лекция (24.11.11)

Эволюция программных систем.

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

Автоматизированные средства разработки ПО (CASE средства).

Case средства обозначают специальный тип программного обеспечения предназначенного для поддержки таких процессов создания ПО, как разработка требований, проектирование, кодирование и тестирование программ. Case технология предлагает поддержку процесса создания ПО, путём автоматизации некоторых этапов разработки, а так же создания и предоставления информации, необходимой для разработки. ПРИМЕРЫ:

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

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

3. Генерирование пользовательских интерфейсов на основе его описания, создаваемого в диалоговом режиме.

4. Автоматическая трансляция программ написанных на устаревших языках программирования в программы написанные на современных языках.

Расширение применения case технологий ограничивают 2 фактора.

1. Этап проектирования и кодирования, во многом являются творческими процессами.

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

Классификация case средств.

Классификация по функциям.

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

Классификация по типам поддерживаемых процессов разработки.

Классификация по широте охвата процессов разработки ПО. Различают три категории средств.

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

2. Инструментальные средства. Поддерживают определённые процессы разработки

3. Средства разработки. Они поддерживают определённые среды разработки по. Включат в себя различные средства ну и вспомогательные программы.

Классификация case средств по категориям. Рисунок.

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

Введение в ПИ 12 лекция (01.12.11)

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

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

2. Не существует стандартных процессов разработки ПО. Нет чёткой зависимости, между процессом создания ПО и его типам.

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

Процессы управления.

Процессы:

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

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

3. Оценивание стоимости проекта. Этот этап напрямую связан с планированием, поскольку здесь оцениваются ресурсы, требующиеся для выполнения плана, контроль за ходом выполнения проекта.

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

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

   1. Бюджет проекта, не позволяет привлечь высококвалифицированный персонал.

   2. Бывают ситуации когда невозможно найти специалистов необходимой квалификации или же они заняты в других проектах.

   3. Организация хочет повысить профессиональный уровень своих рабочих.

Планирование проектов.

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

Планирование это итерационный процесс, поскольку в процессе выполнения постоянно поступает новая информация, план должен постоянно пересматриваться, процесс планирования начинается с определения процентных ограничений. Возможности персонала, временные ограничения, бюджет и т.д. Эти ограничения определяются параллельно с оцениванием проектных параметров (структура и размер проекта, распределение функций по разработчикам) затем определяются этапы разработки, и то, какие результаты должны быть получены по окончанию этих этапов. Документация, прототипы, подсистемы, или версии ПО. Сначала разрабатывается график работ или используется ранее созданный график. После этого проводится контроль выполнения работ (недели через 3-4) и отмечаются расхождения между реальным и запланированным ходом работ. Далее по мере поступления новой информации возможен пересмотр первоначальных наценок, это в свою очередь может привести к изменению графика работ. Если в результате этих изменений нарушаются сроки завершения проекта, то должны быть пересмотрены проектные ограничения. Желательно описать возможные проблемы ещё до того, как они себя проявят.

План проекта.

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

1. Введение – Краткое описание целей проекта ( проектные ограничения, бюджетные, временные и т.д.)

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

3. Анализ рисков – Описание возможных проектных рисков, вероятности их появления и стратегии направленные на их уменьшение или разрешение

4. Аппаратные и программные ресурсы, необходимые для реализации проекта, перечень аппаратных средств. И программного обеспечения необходимого для разработки программного продукта. Если оборудование и ПО приходится закупать, приводится стоимость и график закупки и поставки.

5. Разбиение работ на этапы, процесс реализации проекта, разделяется на отдельные процессы, определяются этапы выполнения проектов, приводится описание результатов и контрольной отметке.

6. График работ – здесь отображаются зависимости между отдельными этапами разработки ПО. Оценки времени и распределение членов команды разработчиков по этапам.

7. Механизмы мониторинга и контроля за ходом выполнения проекта. Описываются предоставляемые менеджером отчёты о ходе выполнения работ, сроки их предоставления, а так же способы мониторинга всего проекта.

Контрольные отметки этапов работ.

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

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

Введение в ПИ 13 лекция (08.12.11)

План проекта.

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

1. Введение - краткое описание целей проекта, проектные ограничения (бюджетные, временные и т.д.)

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

3. Анализ рисков – описание возможных проектных рисков, вероятности их появления и стратегии направленные на их уменьшения или разрешение.

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

5. Разбиение работ на этапы – процесс реализации проекта разделяется на отдельные процессы, определяются этапы выполнения проектов, приводится описание результатов каждого этапа и контрольной отметки.

6. График работ – здесь отображаются зависимости между отдельными этапами разработки ПО, оценки времени их выполнения и распределение членов команды разработчиков по этапам.

7. Механизмы мониторинга и контроля за ходом выполнения проекта – описываются предоставляемые менеджером отчеты о ходе выполнения работ сроки их предоставления, а так же способы мониторинга всего проекта.

Контрольные отметки этапов работ.

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

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

Введение в ПИ 14 лекция (15.12.11)

Менеджер. Организации процесса .

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

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

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

1. Команда разработчиков.

2. Необходимая вычислительная техника.

3. Программное обеспечение.

4. Командировочные.

5. Проживание.

6. Пропитание, и т.д.

Главное правило, рассчитывайте время как будто бы ничего не случилось потом + 30% на непредвиденности и + 20% на то что не смогли допустим предусмотреть = 150%.

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

Сетевые и временные диаграммы.

Временные – начало и конец каждого этапа.

Сетевые – зависимости между этапами.

Этапы некоторого проекта.

Этап	Длительности (дни)	Зависимость
Т1	8
Т2	15
Т3	15	Т1(М1)
Т4	10
Т5	10	Т2, Т4 (М2)
Т6	5	Т1, Т2 (М3)
Т7	20	Т1 (М1)
Т8	25	Т4 (М5)
Т9	15	Т3, Т6 (М4)
Т10	15	Т5, Т7 (М7)
Т11	7	Т9 (М6)
Т12	10	Т11 (М8)

На основе приведённых значений длительности этапов и зависимостей между ними строится сетевая диаграмма .

(фото ..)

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

(Фото…)

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

(Фото…)

Введение в ПИ 15 лекция (22.12.11) Управление рисками.

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

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