27.02.2017 / by maximios / Журналистика / No Comments

Методичка курсовые



Министерство образования Московской области

ГОУ ВПО МО «Международный университет природы,

общества и человека «Дубна»

Филиал «Протвино»

Кафедра Информационных технологий

 

 

 

 

 

 

 

 

 

В.И. Ухов, А.В. Мандрик, И.О. Ковцова

 

 

ПОДГОТОВКА КУРСОВЫХ РАБОТ ПО ДИСЦИПЛИНЕ

«Технология разработки программного обеспечения»

МЕТОДИЧЕСКОЕ ПОСОБИЕ

 

Рекомендовано учебно-методическим советом филиала

«Протвино»университета «Дубна»

в качестве методического пособия

для студентов филиала, обучающихся по направлению подготовки

«Информатика и вычислительная техника»

профиль «Программное обеспечение вычислительной техники и автоматизированных систем»

 

 

 

 

 

 

 

 

Протвино, 2013

ББК 32.973.23 я73

У 89

Рецензенты:

 

С.Р. Слабоспицкий, д.ф-м.н., ведущий специалист, начальник группы ООО «СИСТЕЛ».

 

 

 

 

 

Ухов В.И., Мандрик А.В., Ковцова И.О.

   Подготовка курсовых работ по дисциплине «Технология разработки программного обеспечения». Методическое пособие. Протвино: филиал «Протвино» Международного университета природы, общества и человека «Дубна»; 2013. с.43.

 

 

Методическое пособие предназначено для студентов очного и заочного отделений направления «Информатика и вычислительная техника».    

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

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

 

 

 

 

 

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

 

 

 

 

@ В.И. Ухов, А.В. Мандрик, И.О. Ковцова

@ Международный университет

природы, общества и человека «Дубна»,

ISBN филиал «Протвино», 2013   

СОДЕРЖАНИЕ

Введение   4

1 Общие требования к курсовой работе   4

2 Организация учебного проекта   6

3 Программные технологии управления проектами   35

4 Рекомендации по выполнению курсовой работы   36

Библиографический список   41

Приложения   43

 

Введение

Целью преподавания дисциплины «Технология разработки программного обеспечения» является освоение студентами теоретических основ, принципов и современных методов разработки программного обеспечения в соответствии с российскими и международными стандартами и практикой. А также получение компетенций и практических навыков по проектированию, документированию, тестированию, внедрению, сопровождению и модернизации программных продуктов и систем. Работая над утвержденным курсовым заданием, студенты осваивают методы организации работ в коллективе, способы планирования, контроля и проведения аудита проекта.

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

   Итоговой работой при изучении курса «Технология разработки программного обеспечения» является курсовая работа проект, который предполагает разработку небольшой завершенной программной системы или продукта. Работа над проектом ведётся сформированной группой студентов. Данная дисциплина изучается студентами на последнем, выпускном курсе и предусматривает знакомство с основными технологиями создания программного обеспечения, изучавшимися ранее. В первую очередь студенты должны владеть навыками: программирования и отладки; проектирования и создания СУБД; создания распределенных программных систем; разработки дружественных человеко-машинных интерфейсов. Реализуемый проект обязательно должен опираться на современные информационные технологии.

Выполнение курсовой работы преследует следующие цели:

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

получение студентами навыков к анализу и синтезу полученной информации;

получение навыков формирования команды, работы в команде, а также социально-личностных, общекультурных и профессиональных компетенций;

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

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

определение общих форм, закономерностей, инструментальных средств для данной дисциплины;

развить творческие способности студентов, помочь найти своё место в проекте;

развитие целеустремлённости, ответственности, инициативности и умения решать возникающие проблемы и принимать решения;

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

Учебно-методические рекомендации предназначены для студентов очного и заочного отделений направления « Информатика и вычислительная техника«.

1 Общие требования к курсовой работе

1.1 Правила выбора темы для курсовой работы

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

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

Проект, выбранный группой, должен удовлетворять ряду требований. Во-первых, объем работ по проекту должен быть таким, чтобы выполняющая его группа могла выполнить его в течение семестра. Вторым требованием к проекту, являются технологические ограничения. Предлагаемый студентами проект должен опираться на современные программные технологии. Для успешной реализации проекта, выбранные технологии должны быть известны студентам и доступны для использования на практических занятиях. У студентов должна быть возможность получить расширенные консультации по их использованию от преподавателей кафедры. Так же допускается привлечение в качестве консультантов специалистов сторонних организаций, занимающихся данной предметной сферой, соответствующей теме курсовой работы. Третьим требованием к проекту, является его иннавационность и креативность. Для того чтобы студенты получили глубокие навыки работы в группе, выполняемая работа должна их увлекать и доставлять радость. Выполняемый проект должен быть интересен, выбравшей его команде. Еще одним желательным требованием к проекту, является его практическая польза. Как и для большинства учебных задач, данное требование не является обязательным.

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

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

1.2 Результаты и защита курсовой работы

В результате выполнения курсовой работы студенты должны предоставить преподавателю законченный программный проект, документацию к нему и набор артефактов, созданных в процессе его разработки. Также предоставляется презентация проекта в электронном виде. Отчет о курсовой работе в виде файла формата MS Word или аналогичном из Open Office предоставляется не позднее, чем за две недели до установленного срока защиты курсовой работы. Отчёт оформляется в соответствии с правилами, описанными в п. 2.2. На основании этих материалов аттестуется проект в целом. Также определяется личный вклад и индивидуальные оценки каждого участника проекта. Если данный программный продукт был внедрён или находился на опытной эксплуатации в сторонней организации, то желательно приложить отзыв о программном продукте (это может быть заключение или рекомендательное письмо заказчика, сторонних экспертов).

Не допускаются к защите и возвращаются для повторного написания курсовые работы, полностью или в значительной степени, выполненные не самостоятельно (путём механического копирования материала из источников информации, более 50%), а также работы, характеризующиеся низким уровнем грамотности и небрежным оформлением.

Защита курсовой работы проводится до начала зачётной сессии. Защита может проходить открыто с приглашением преподавателей и студентов. Студенты демонстрирует подготовленную презентацию проекта. В данной презентации должны быть отражены миссия и цель проекта, постановка задачи, изложены основные требования, предъявляемые к разработанному программному продукту, описаны существующие и выбранные методы и средства его реализации, их достоинства и недостатки, а также должен быть проиллюстрирован процесс разработки ПО и полученные результаты. Обязательно должен быть продемонстрирован сам проект, программный продукт. На выступление и представление проекта отводится время в пределах не более 7 минут. В конце сообщения необходимо сделать краткое заключение по достигнутым результатам работы.

При изложении материала студент должен продемонстрировать:

умение кратко, четко и технически грамотно излагать содержание проекта;

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

владение теоретическим материалом по предмету курсовой работы;

хорошее владение математическим аппаратом и четкое ориентирование в расчетах.

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

1.3 Критерии оценки курсовой работы

Оценка за курсовую работу учитывает:

1. Актуальность, новизну и практическую ценность работы.

2. Функциональность и степень завершённости программного продукта.

3. Полноту раскрытия темы, основательную проработку исследуемой предметной области.

4. Удобство и дружественность разработанного программного продукта.

5. Применение современных информационных технологий в процессе создания ПО.

6. Применение программных технологий управления проектом.

7. Наличие артефактов разработки ПО.

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

9. Качество презентации, умение коротко и ясно рассказать о своей работе.

10. Понимание и знания, проявленные при ответах на вопросы во время защиты.

Рекомендуемые критерии оценки:

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

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

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

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

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

2 Организация учебного проекта

2.1 Инструментальные средства

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

1. Электронная почта.

2. Централизованное хранение файлов (возможно, система управления версиями).

3. Представление данных о ходе проекта в виде web-ресурса.

4. Инструментальные средства разработки ПО.

Редакторы (текстовые, графические, моделей) и другие средства документирования, включая web-средства.

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

Стандартные библиотеки и оболочки разработки ПО.

Системы тестирования и статического анализа кода.

Возможно предоставление и других средств, в зависимости от специфики проекта. Поощряется самостоятельное нахождение, изучение и использование студентами специализированных инструментальных средств (в рамках существующего законодательства РФ).

2.2 Основы командной разработки ПО

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

Существует две основные модели организации коллектива при разработке ПО:

Иерархическая модель. определяет начальников и подчиненных, т.е это структура с вертикальной формой управления (контроля) элементами, входящими в неё. Фактически это пирамида, каждым уровнем которой управляет более высокий уровень. Можно выделить следующие недостатки иерархической модели:

нехватка информации на различных уровнях;

невозможность учесть все особенности проекта;

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

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

сложность расстановки приоритетов.

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

Можно выделить следующие недостатки модели группы:

разрозненная связь с внешними источниками информации;

несогласованное представление о разных сторонах проекта;

несогласованность личных планов членов группы;

отсутствие опыта, снижающее эффективность коллективной работы.

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

 

Рисунок 1 Роли в модели проектной группы

Каждая ролевая группа выполняет свои задачи:

«Архитектура»

формулирует спецификацию решения и разрабатывает его архитектуру;

определяет структуру развертывания (внедрения) решения.

«Разработка»

определяет детали физического дизайна;

оценивает необходимые время и ресурсы на реализацию каждого элемента дизайна;

разрабатывает или контролирует разработку элементов;

подготавливает продукт к внедрению;

консультирует команду по технологическим вопросам.

«Тестирование»

обеспечивает обнаружение всех дефектов;

разрабатывает стратегию и планы тестирования;

осуществляет тестирование.

«Управление выпуском»

представляет интересы отделов поставки и обслуживания продукта;

организует снабжение проектной группы;

организует внедрение продукта;

вырабатывает компромиссы в управляемости и удобстве сопровождения продукта;

организует сопровождение и инфраструктуру поставки.

«Удовлетворение потребителя»

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

организует работу с требованиями пользователя;

определяет компромиссы, относящиеся к удобству использования и потребительским качествам продукта;

определяет требования к системе помощи и её содержание;

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

«Управление продуктом»

выступает в роли представителя заказчика;

организует работу с требованиями заказчика;

формирует ожидания заказчика;

формирует общее видение и рамки проекта;

определяет компромиссы между параметрами «возможности продукта / время / ресурсы»;

организует маркетинг;

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

Влияние на успех группы такого важного фактора, как состав команды, выявили М. Белбин и его коллеги. Было проведено исследование нескольких сотен небольших групп в процессе их деятельности. Учёные определили, что поведение членов групп соответствует одной из девяти выделенных ими в ходе исследования ролей (Таблица 1).

Таблица 1 Типология командных ролей М. Белбина

Виды командных ролей

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

Допустимые недостатки

Мыслитель (генератор идей)

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

Недостаточность опыта межличностного общения. Психологическая неустойчивость. Может долго задерживаться на рассмотрении «интересных идей».

Исполнитель

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

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

Доводчик

Усердие и добросовестность. Следит за тем, чтобы задания выполнялись полностью. Отслеживает своевременность выполнения заданий.

Чрезмерная обеспокоенность состоянием дел. Склонность к внутренним переживаниям. Нежелание перепоручать свои обязанности. Неприятие несерьезного отношения к его обязанностям со стороны других.

Оценщик (эксперт)

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

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

Исследователь ресурсов

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

Теряет интерес по мере угасания энтузиазма. Перескакивает от одной задачи к другой. Нуждается в повышенном внешнем давлении.

Формирователь

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

Легко переходит к состоянию раздражительности. Импульсивность и нетерпеливость. Нетерпимость к нечетким формулировкам и нерешительности в поведении. Результат — любой ценой.

Коллективист

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

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

Председатель (координатор)

Четко формулирует цели; хорошо выполняет функции ведущего во время дискуссий. Способствует эффективному принятию решений. Имеет хорошие коммуникативные навыки; социальный лидер.

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

Специалист

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

Полезен только в узкой профессиональной сфере. Зачастую слабые коммуникативные навыки. Иногда, образно выражаясь, «не видит леса за деревьями».

В равной степени важными для эффективной командной работы их можно считать лишь при условии, что они применяются в надлежащее время и наилучшим образом. Например, в тот период, когда команда только приступает к рассмотрению проблемы или к разработке проекта, обычно требуются инновационные идеи (т.е. нужен «мыслитель»). Затем возникает необходимость оценки того, как эти идеи могут быть претворены в практически выполнимые задачи (т.е. нужен «исполнитель»). Успех достигается при условии, что в команде есть хороший координатор («председатель»), задача которого — обеспечить наибольшую отдачу от членов команды в нужное время. Движущую силу и стимул команда обретает в лице энергичного «формирователя». Когда возникает необходимость в проведении сложных переговоров с другими группами, большое значение приобретают качества, которыми обладает «исследователь ресурсов». Чтобы сдерживать чрезмерные проявления энтузиазма, отвлекающие от главной цели, в составе команды должен быть «оценщик» (т.е. «эксперт»). Всевозможные трения и недоразумения между членами команды устраняются усилиями «коллективиста». Благодаря наличию «специалиста» команда имеет редко встречающиеся навыки и знания, в которых периодически возникает необходимость. Роль «доводчика» состоит в том, чтобы не упустить из виду даже мельчайшие детали реализации всех намеченных планов.

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

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

описание возможностей продукта (что продукт позволяет сделать);

конкретизацию продукта (описание функциональных возможностей данной версии);

описание путей реализации проекта.

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

Ориентация на продукт и понимание целей заказчика, нацеленность на результат.

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

обучение на опыте других проектов;

изучение методологии;

изучение технологий.

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

Можно выделить следующие этапы развития команды:

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

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

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

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

Любая коллективная разработка программного обеспечения сталкивается с одними и теми же проблемами:

групповая работа над кодом, документами;

учет проблем, ошибок, требований;

документирование, накопление и циркуляция (поиск, трансляция, агрегация) знаний компании;

организация правильного тестирования.

Работа средств коллективной разработки основана на выполнении двух базовых функций:

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

Автоматизация следующих операций:

доступа к общей базе данных;

обработки конфликтующих версий файла;

именования различных версий файла;

ввода и сохранения комментариев к изменениям.

Методические рекомендации

Формирование рабочих коллективов и выбор программного проекта вещи взаимосвязанные. В данном курсе даётся возможность студентам сначала «собрать команду», а потом выбрать проект. Группы, работающие над проектом должны состоять из 3-5 человек. Группы менее 3 человек, не позволят студентам получить навыки коллективной работы над проектом. Группы более 5 человек требуют более сложной координации и допустимы для уже сложившихся творческих коллективов.

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

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

Сформированные группы утверждаются преподавателем. Если преподаватель считает, что с точки зрения освоения практических навыков, предусмотренных программой ТРПО, данная группа малоэффективна, то он вправе расформировать или переформировать такую группу. Использовать данное право следует только в исключительных случаях, предварительно проконсультировавшись с лектором.

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

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

Рекомендуется следующая схема проведения собрания:

1. Руководитель проекта назначает секретаря и оглашает заранее подготовленную повестку собрания и краткий отчет о текущем состоянии проекта. (~5 минут).

2. Участники собрания вносят замечания. В результате формируется окончательная повестка собрания. (~5 минут).

3. Собрание идет согласно выработанной повестке. Заслушиваются отчеты разработчиков о проделанной работе, включая отчеты об исправлении замечаний, и выполняется анализ текущей документации и других артефактов. Обсуждаются и определяются дальнейшие направления и задачи. (~3570 минут).

4. Подведение итогов. Распределение задач, назначение ответственных и т.п. (~10 минут).

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

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

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

2.3 Проект. Обсуждение целей и миссии

Что же такое проект? Все мы постоянно осуществляем проекты в своей повседневной жизни. Вот простые примеры: ремонт в квартире, стройка на даче, проведение исследований, написание книги. Само слово проект имеет греческие корни и означает брошенный вперёд, выдающийся вперёд. В настоящее время проект определяется следующим образом:

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

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

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

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

Сущность миссии состоит в том, что она:

отражает общие ценности и взгляды членов коллектива;

связана с культурой организации;

определяет направленность процесса принятия решений и работы;

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

Миссия отвечает на вопросы: кто?, что?, для кого? и как (каким образом)?

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

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

Методические рекомендации

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

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

разработать формулировку миссии;

сформулировать главные цели проекта;

зафиксировать границы проекта (что должно быть сделано, а чего делать не надо);

произвести декомпозицию работ;

оценить сроки деятельности, необходимые ресурсы.

завести рабочую тетрадь проекта;

2.4 Выбор модели ЖЦ ПО

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

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

Исторически в ходе развития теории проектирования программного обеспечения и по мере его усложнения утвердились основные модели ЖЦ. Каждая такая модель представляет процесс создания ПО в каком-то своем «разрезе», используя только определенную часть всей информации о процессе. Перечисленные ниже модели разработки представляют обобщенные модели, основанные на архитектурном подходе. В этом случае можно увидеть всю структуру процесса создания ПО, абстрагируясь от частных деталей отдельных составляющих его этапов.

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

Первой во времени появления и самой распространённой явилась каскадная модель (водопад). Основные базовые виды деятельности, выполняемые в процессе создания ПО (такие, как разработка спецификации, проектирование и производство, атте­стация и модернизация ПО), представляются как отдельные этапы этого процесса.

Последовательность фаз водопадной модели: анализ требований, проектирование, реализация, интеграция.

Каскадная модель характеризуется следующими основными особенностями:

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

началом последующего этапа только после завершения предыдущего;

отсутствием обратных связей между этапами;

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

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

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

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

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

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

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

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

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

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

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

1. анализ отличительных категорий проекта, помещенных в таблицах ниже;

2. ответьте на вопросы, приведённые для каждой категории, обведя кружочком слова «да» или «нет»;

3. Расположите по степени важности категории или вопросы, относящиеся к каждой категории, относительно выбранного проекта;

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

Таблица 2 Выбор модели жизненного цикла на основе характеристик требований

Требования

Каскадная

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

Спиральная

Инкрементная

Являются ли требования легко определимыми и хорошо известными

Да

Нет

Нет

нет

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

Да

Нет

Нет

да

Часто ли будут изменяться требования в цикле

Нет

Да

Да

нет

Нужно ли демонстрировать требования с целью определения

Нет

Да

Да

нет

Требуется ли для демонстрации возможностей проверка концепции

Нет

Да

Да

нет

Будут ли требования отражать сложность системы

Нет

Да

Да

Да

Обладает ли требование функциональными свойствами на раннем этапе

Нет

Да

Да

Да

 

Таблица 3 Выбор модели жизненного цикла на основе характеристик участников команды разработчиков

Команда разработчиков проекта

Каскадная

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

Спиральная

Инкрементная

Являются ли проблемы предметной области проекта новыми для большинства разработчиков

Нет

Да

Да

Нет

Является ли технология предметной области проекта новой для большинства разработчиков

Да

Нет

Да

Да

Являются ли инструменты, используемые проектом, новыми для большинства разработчиков

Да

Нет

Да

Нет

Изменяются ли роли участников проекта во время жизненного цикла

Нет

Да

Да

Да

Могут ли разработчики проекта пройти обучение

Нет

Нет

Нет

Да

Является ли структура более значимой для разработчиков чем гибкость

Да

Нет

Нет

Да

Будет ли менеджер проекта строго отслеживать прогресс команды

Да

Нет

Да

Да

Важна ли лёгкость распределения ресурсов

Да

Нет

Нет

Да

Приемлет ли команда равноправные обзоры и инспекции, менеджмент/обзоры заказчиков, а также стадии

Да

Да

Да

Да

 

Таблица 4 Выбор модели жизненного цикла на основе характеристик коллектива пользователей

Коллектив

Каскадная

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

Спиральная

Инкрементная

Будет ли присутствие пользователей ограничено в жизненном цикле

Да

Нет

Да

Да

Будут ли пользователи знакомы с определением системы

Нет

Да

Да

Да

Будут ли пользователи ознакомлены с проблемами предметной области

Нет

Да

Нет

Да

Будут ли пользователи вовлечены во все фазы жизненного цикла

Нет

Да

Нет

Нет

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

Нет

Да

Да

Нет

 

Таблица 5 Выбор модели жизненного цикла но основе характеристик типа проектов и рисков

Тип проекта и риски

Каскадная

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

Спиральная

Инкрементная

Будет ли проект идентифицировать новое направление продукта для организации

Нет

Да

Да

Да

Будет ли проект иметь тип системной интеграции

Нет

Да

Да

Да

Будет ли проект являться расширением существующей системы

Нет

Нет

Нет

Да

Будет ли финансирование проекта стабильным на всём протяжении жизненного цикла

Да

Да

Нет

Нет

Ожидается ли длительная эксплуатация продукта в организации

Да

Нет

Да

Да

Должна ли быть высокая степень надёжности

Нет

Нет

Да

Да

Будет ли система изменяться, возможно, с применением непредвиденных методов, на этапе сопровождения

Нет

Да

Да

Да

Является ли график ограниченным

Нет

Да

Да

Да

Являются ли «прозрачными» интерфейсные модули

Да

Нет

Нет

Да

Доступны ли повторно используемые компоненты

Нет

Да

Да

Нет

Являются ли достаточными ресурсы (время инструменты, персонал)

Нет

Да

Да

Нет

Методические рекомендации

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

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

2.5 Анализ требований и определение спецификаций ПО

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

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

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

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

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

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

Атрибуты качества при исполнении приложения:

Доступность — требования ко времени непрерывной работы приложения, например, 24×7, минимальное время простоя и т.п.

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

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

Масштабируемость — требования к горизонтальному или вертикальному масштабированию приложения.

Требования к удобству использования приложения с точки зрения использования, поддержки.

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

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

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

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

Атрибуты качества при проектировании приложения:

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

Требования к расширяемости приложения в связи с появлением новых функциональных требований.

Требования к портируемости (переносимости) приложения на различные платформы.

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

Требования к различным аспектам поддержки приложения, таким как дешевизна и скорость разработки, прозрачность поведения приложения, простота анализа ошибок и проблем в работе

Требования к разделению приложения на модули.

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

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

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

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

Процесс формирования и анализа требований проходит через ряд этапов:

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

2.    Сбор требований. Это процесс взаимодействия с лицами, формирующими требования. Во время этого процесса продолжается анализ предметной области.

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

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

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

6.    Проверка требований. На этом этапе определяется их полнота, последовательность и непротиворечивость.

Когда группа разработчиков начинает анализировать требования, заказчик обычно всё ещё формирует концепции того, что он хочет и что ему нужно. Это аналогично этапу уточнения требований при взаимодействии архитектора и клиента. Например, клиент может захотеть дом с четырьмя спальнями и большой гостиной. Но при уточнении требований клиент вынужден полагаться на архитектора, который должен помочь клиенту понять, чего последний хочет (например, просторную гостиную, в которой можно разместить 10 человек). Нужды заказчика несколько труднее определить, чем его желания. Например, заказчик может захотеть, чтобы музыкальное приложение позволяло компьютерным новичкам гарантированно записывать музыку, но ему также может быть нужна периодическая функция автосохранения для избегания потери работы. Являются ли последняя характеристика требованием, или это часть проектирования? Это зависит от соглашения между разработчиком и заказчиком. Если заказчик, осознав смысл автосохранения, принимает решения, что он действительно хочет иметь такую функцию, автосохранение становится требованием.

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

интервью, опросы, анкетирование;

мозговой штурм, семинар;

наблюдение за производственной деятельностью;

анализ нормативной документации;

анализ моделей деятельности;

анализ конкурентных продуктов;

анализ статистики использования предыдущих версий системы;

Рассмотрим один из способов проведения опроса заказчика

Перед интервью:

1. Перечислите и расставьте приоритеты в списке интервьюируемых.

2. Спланируйте интервью с фиксированным временем начала и конца;

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

приготовьтесь записывать видео или аудио файлы.

Во время интервью:

1. Сконцентрируйтесь на слушании:

не будьте пассивны: исследуйте сами и побуждайте собеседника;

настаивайте на понимании желаний и изучении нужд;

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

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

2. Спланируйте следующую встречу

После интервью:

1. составить черновик требований;

2. связаться с заказчиком для получения его замечаний по документу;

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

Методические рекомендации

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

1. Введение

1.1 Цель (Цель документа в целом, а не цель ПО)

1.2 Область применения (Какие аспекты программы этот документ должен охватить)

1.3 Определения, термины и сокращения

1.4. Ссылки (исходные документы)

1.5 Обзор

2. Общее описание

2.1 Перспективы продукта

2.1.1 Концепции операций

2.1.2 Концепции пользовательского интерфейса

2.1.3 Аппаратные интерфейсы

2.1.4 Программные интерфейсы

2.1.5 Коммуникационные интерфейсы

2.1.6 Ограничения по памяти

2.1.7 Операции

2.1.8 Требования по адаптации

2.2 Функции продукта

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

2.4 Ограничения (все условия, которые могут ограничить возможности разработчика. Могут исходить из разных источников)

2.5 Предположения и зависимости (могут быть сделаны любые допущения)

2.6 Распределение требований

3 Детальные требования

3.1 Требования к внешнему интерфейсу

3.2 Детальные требования

3.3 Требования к производительности

3.4 Ограничения проектирования

3.5 Атрибуты программной среды

3.5.1 Надёжность

3.5.2 Доступность

3.5.3 Защита

3.5.4 Поддержка

3.6 Дополнительные требования

4 Дополнительная информация

4.1 Оглавление и индекс

4.2 Приложение

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

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

Планирование определяется как ответ на вопросы:

Что должно быть сделано?

Кто сделает?

Как они это сделают?

Как долго будут это делать? И т.д.

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

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

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

Обычный календарный план представляется в виде таблицы со следующей структурой:

Таблица 6 Календарный план

Наименование работ

(тема, работа, задача,

задание)

Сроки выполнения начало/конец

Ответственный исполнитель и исполнители, роли

Требуемые ресурсы и сроки их предоставления план/факт

Примечания

план

факт

1

2

3

4

5

6

Столбец 1 заполняется в соответствии с разбиением заказанного проекта на составляющие. Обычно глубина разбиения зависит от декомпозиции проекта. Распределение времени и контроль над ним назначение столбцов 2 и 3. В них указываются календарные даты планируемого (столбец 2) и фактического (столбец 3) сроков выполнения работы. Планируемое начало работы это самая ранняя дата, после которой можно приступать к выполнению; конец это предельный срок отчета исполнителей перед руководителем. Иногда графа планируемых сроков дополняется критическими и целесообразными сроками начала/конца работы. Столбец 4 «Ответственный исполнитель и исполнители, роли» задает информацию о том, кто работает над данным заданием, и какая квалификация от исполнителей требуется. Распределение технических ресурсов и задание сроков их предоставления содержание столбца 5. Здесь указывается необходимая для выполнения задания техническая, а в ряде случаев, и программная база. Полезным расширением состава сведений столбца 5 является включение в него информации о зависимости работ внутри проекта, т.е. перечисление заданий (в том числе, ссылки на другие строки данного календарного плана), без выполнения которых осуществимость планируемых работ нарушается.

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

выявить перечень работ вашего проекта;

наглядно представить порядок их следования;

определить длительности каждой работы и всего проекта;

определить критические работы проекта и его критический путь;

определить резервы времени по каждой работе;

и т.д.

В качестве примера рассмотрим проект «Разработка программного комплекса». Предположим, что проект состоит из работ, характеристики которых приведены в таблице 7.

Таблица 7 Характеристики проекта

Номер работы

Название работы

Длительность

Зависимость

1

Начало реализации проекта

0

 

2

Постановка задачи

10

 

3

Разработка интерфейса

5

 

4

Разработка модулей обработки данных

7

 

5

Разработка структуры базы данных

6

 

6

Заполнение базы данных

8

 

7

Отладка программного комплекса

5

 

8

Тестирование и исправление ошибок

10

 

9

Составление программной документации

5

 

10

Завершение проекта

0

 

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

Нахождение критического пути сводится к нахождению критических работ и выполняется в два этапа.

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

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

Критические работы имеют одинаковое значение раннего и позднего времени начала.

Диаграмма Ганта это инструмент иллюстрации календарного плана. Представляет собой столбчатые диаграммы, вписанные в календарную шкалу. Длина диаграммы соответствует отрезку времени, отведенному на выполнение той или иной задачи.

Рисунок 2 Диаграмма Ганта

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

Типы связей:

Финиш-Старт операция B не может начаться до завершения операции А;

Финиш-Финиш операция B должна окончиться не раньше операции А;

Старт-Старт операция В начинается не раньше операции А;

Старт-Финиш операция В не может окончиться пока не начнется операция А.

Рисунок 3 Типы связей

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

Таблица 8 Исполнители этапов

Этап

Исполнитель

Т1

Т2

Т3

Т4

Т5

Т6

Т7

Т8

Т9

Т10

Т11

Т12

Джейн

Анна

Джейн

Фред

Мэри

Анна

Джим

Фред

Джейн

Анна

Фред

Фред

Временная диаграмма распределения работников по этапам

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

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

 

Рисунок 4 Временная диаграмма распределения работников по этапам

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

Методические рекомендации

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

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

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

2.7 Проектирование программного обеспечения

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

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

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

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

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

Ниже перечислены отдельные этапы процесса проектирования:

Архитектурное проектирование — определяются и документируются подсистемы и взаимосвязи между ними.

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

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

Компонентное проектирование — проводится распределение системных функций (сер­висов) по различным компонентам и их интерфейсам.

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

Проектирование алгоритмов — детально разрабатываются алгоритмы, предназна­ченные для реализации системных сервисов.

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

Нисходящее и восходящие проектирование и разработка

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

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

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

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

разбивка системы на множество независимых задач, легких для понимания и решения;

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

В основе этих принципов лежат операции:

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

формализации, т.е строгое методологическое решение проблемы;

непротиворечивости, состоящей в обосновании и согласовании элементов системы;

структуризации данных (т.е. данные должны быть структурированы и иерархически организованы).

При структурном анализе применяются в основном три вида наиболее распространённых моделей проектирования ПО:

SADT (Structured Analysis and Design Technique) модель и соответствующие функциональные диаграммы;

SSADM (Structured Systems Analysis and Design Method) метод структурного анализа и проектирования;

IDEF0 (Integrated Definition Functions) метод создания функциональной модели;

IDEF1 информационной модели, IDEF2 динамической модели и др.

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

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

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

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

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

2. Объектноориентированное проектирование. Разработка объектноориентированной модели системы ПО (системной архитектуры) с учётом требований. В этой модели определение всех объектов подчинено решению конкретной задачи.

3. Объектноориентированное программирование. Реализация архитектуры (модели) системы с помощью объектноориентированного языка программирования (С++, Java) для определения объектов и средств определения классов объектов.

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

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

Существует два типа моделей архитектуры ПО:

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

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

Документируемые взаимодействия содержат последовательность запросов к сервисам объектов и описывают реакцию системы на взаимодействия между объектами.

Язык моделирования UML(United Modeling Language унифицированный язык моделирования) поддерживает большое количество всевозможных статических и динамических моделей, в том числе модель подсистем и модель последовательностей. Модель последовательностей одна из наиболее полезных и наглядных моделей, которая в каждом узле взаимодействия документирует последовательность происходящих взаимодействий между объектами.

В UML используются следующие виды диаграмм:

Структурные диаграммы:

Диаграмма классов (Class diagram)

Диаграмма компонентов (Component diagram)

Композитной/составной структуры(Composite structure diagram)

Диаграмма кооперации (Collaboration) (UML2.0)

Диаграмма развёртывания (Deployment diagram)

Диаграмма объектов (Object diagram)

Диаграмма пакетов (Package diagram)

Диаграмма профилей (Profile diagram)(UML2.2)

Диаграммы поведения:

Диаграмма деятельности (Activity diagram)

Диаграмма состояний (State Machine diagram)

Диаграмма прецедентов (Use case diagram)

Диаграммы взаимодействия:

• Диаграмма коммуникации(Communication diagram) (UML2.0) / Диаграмма кооперации (Collaboration) (UML1.x)

Диаграмма обзора взаимодействия (Interaction overview diagram) (UML2.0)

• Диаграмма последовательности (Sequence diagram)

Диаграмма синхронизации (Timing diagram) (UML2.0)

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

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

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

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

Диаграмма компонентов (Component diagram) статическая структурная диаграмма, показывает разбиение программной системы на структурные компоненты и связи (зависимости) между компонентами. В качестве физических компонент могут выступать файлы, библиотеки, модули, исполняемые файлы, пакеты и т.п.

Диаграмма композитной/составной структуры (Composite structure diagram) статическая структурная диаграмма, демонстрирует внутреннюю структуру классов и, по возможности, взаимодействие элементов (частей) внутренней структуры класса. Подвидом диаграмм композитной структуры являются диаграммы кооперации (Collaboration diagram, введены в UML 2.0), которые показывают роли и взаимодействие классов в рамках кооперации. Кооперации удобны при моделировании шаблонов проектирования. Диаграммы композитной структуры могут использоваться совместно с диаграммами классов.

Диаграмма развёртывания (Deployment diagram) служит для моделирования работающих узлов (аппаратных средств,англ. node) и артефактов, развёрнутых на них. Между артефактом и логическим элементом (компонентом), который он реализует, устанавливается зависимость манифестации.

Диаграмма объектов (Object diagram) демонстрирует полный или частичный снимок моделируемой системы в заданный момент времени. На диаграмме объектов отображаются экземпляры классов (объекты) системы с указанием текущих значений их атрибутов и связей между объектами.

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

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

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

Диаграмма вариантов использования (Use case diagram) диаграмма, на которой отражены отношения, существующие между акторами и вариантами использования. Основная задача представлять собой единое средство, дающее возможность заказчику, конечному пользователю и разработчику совместно обсуждать функциональность и поведение системы.

Диаграмма коммуникации (Communication diagram, в UML 1.x диаграмма кооперации, collaboration diagram) диаграмма, на которой изображаются взаимодействия между частями композитной структуры или ролями кооперации. В отличие от диаграммы последовательности, на диаграмме коммуникации явно указываются отношения между элементами (объектами), а время как отдельное измерение не используется (применяются порядковые номера вызовов).

Диаграмма последовательности (Sequence diagram) диаграмма, на которой изображено упорядоченное во времени взаимодействие объектов. В частности, на ней изображаются участвующие во взаимодействии объекты и последовательность сообщений, которыми они обмениваются.

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

Диаграмма обзора взаимодействия (Interaction overview diagram) разновидность диаграммы деятельности, включающая фрагменты диаграммы последовательности и конструкции потока управления. Этот тип диаграмм включает в себя диаграммы Sequence diagram (диаграммы последовательностей действий) и Collaboration diagram (диаграммы сотрудничества). Эти диаграммы позволяют с разных точек зрения рассмотреть взаимодействие объектов в создаваемой системе.

Диаграмма синхронизации (Timing diagram) альтернативное представление диаграммы последовательности, явным образом показывающее изменения состояния на линии жизни с заданной шкалой времени. Может быть полезна в приложениях реального времени.

Агентно-ориентированный подход (АОП) к программированию  разновидность представления программ, или парадигма программирования, в которой основополагающими концепциями являются понятия агента и его ментальное поведение, которое зависит от среды, в которой он находится.

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

Агент может обладать такими свойствами:

автономность это способность действовать без внешнего управляющего воздействия;

реактивность это способность реагировать на изменения данных и среды, и воспринимать их;

активность это способность ставить цели и выполнять заданные действия для достижения этой цели;

социальность это способность к взаимодействию с другими агентами (или людьми).

В задачи программного агента входят:

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

взаимодействие с другими агентами;

изменение поведения в зависимости от состояния внешней среды;

выдача достоверной информации о выполнении заданной функции и т.п.

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

Компонентный подход к проектированию

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

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

Информационная часть представляет собой информацию о компоненте: назначение, дата изготовления, условия применения (ОС, среда, платформа и т.п.); уровень повторного использования; контекст или окружение; способ взаимодействия между собою компонентов.

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

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

способ интеграции (композиции) компонентов;

нефункциональные сведения (безопасность, аутентификация, надежность и др.);

технология проектирования (например, объектноориентированная среда и т.п.) и повторное использования компонентов.

Внутренняя часть это некоторый артефакт (системная или абстрактная структура, фрагмент кода и др.) и вид его представления: проектный компонент, проектная спецификация, вычисляемая часть, код и др.

Как правило, компоненты наследуются в виде классов. Управление компонентами проводится на трех уровнях: архитектурном, компонентном и на уровне инфраструктуры интерфейса.

Внутренняя часть компонента состоит из: интерфейса (interfaces), реализации (implementation), схемы развертки (deployment).

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

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

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

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

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

отражения фундаментальных понятий приложения;

скрытия способа представления и предоставления операций обновления и получения доступа;

обработки исключительных операций в приложении.

Главным преимуществом создания программных систем из компонентов является уменьшение затрат на разработку за счет:

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

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

Методические рекомендации

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

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

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

2.8 Разработка программного обеспечения

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

Процесс реализации модулей можно разделить на несколько этапов:

1. Определить стандарты кодирования в рамках проекта.

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

3. Осуществить инспектирование класса.

4. Произвести набор модульных тестов.

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

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

Рассмотрим один из способов реализации кода:

1. Спланируйте структуру вашего кода

2. Проинспектируйте проект и структуру

3. Наберите код

пока не компилируйте

попробуйте использовать методы, перечисленные ниже

примените необходимые стандарты

кодируйте таким способом, который будет легче всего проверить

4. Проинспектируйте код, но пока не компилируйте

5. Откомпилируйте код:

исправьте синтаксические ошибки

6. Протестируйте код

Следование приведённому способу гарантирует написание качественного программного кода. Не менее важным аспектом является его читабельность при коллективной разработке программного обеспечения. Использование стандартов способствует дисциплине программирования и повышает как читаемость, так и переносимость программ. Рассмотрим наиболее значимые моменты соглашения о кодировании. Указанные соглашения не являются строгим стандартом, но отражают генезис правил «чистого кодирования».

Соглашение об именах

1. Именуйте объекты с помощью конкатенации слов, например fileSize. Такие имена легко понять, и они экономят место. Исключения со знаком подчёркивания оставляются на выбор программиста (вместо aAAAAAAuto лучше написать a_AAA_AA_Auto).

2. Начинайте имена классов с большой буквы. Так вы будете легко отличать их от имён переменных. Иногда для именования классов проекта полезно выбрать префикс, чтобы отличать ваши классы от классов сторонних разработчиков (PwUnit, ZnChannel, CString, MwString).

3. Имена переменных начинайте с маленькой буквы.

4. Используйте в именах констант прописные буквы, например Я_ЕСТЬ_КОНСТАНТА (CYCLE_REQUEST_TIME_OUT, CHANNEL_BOX_SIZE ).

5. Для методов доступа используйте имена, начинающиеся с get, set и is, например, getName(), setName(), isBox() — возвращает тип boolean.

6. Добавьте стандартные дополнительные методы get и set для коллекций, например insertIntoName(), removeFromeName(), newName().

7. Договоритесь о соглашении для параметров. Можно использовать префиекс а, например sum(int aNum1P, int aNum2P), или суффикс P, например sum( int Num1P, int Num2P)

Договоритесь о следующих стандартах внутри методов:

1. выполняйте только одну операцию на одной строке

2. старайтесь чтобы ваши методы помещались на один экран

3. блоки в командах if, else, while должны состоять из одной строки в которой обычно содержится вызов функции.

4. для обеспечения принципов «защещённого» кодирования следует проверять все входные параметры на корректность.

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

Методические указания

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

В процессе написания кода осуществлять мониторинг чистоты и защищённости кода посредством инспектирования и модульного тестирования.

2.9 Тестирование программного обеспечения

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

Основной целью тестирования является точное определение мест неудовлетворительного функционирования программного продукта.

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

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

Определение целей тестирования, постановка задачи теста.

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

Проектирование, разработка и написание тестов.

Выполнение тестов.

Анализ результатов тестирования.

Выделяют три уровня тестирования:

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

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

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

На этапе модульного тестирования широко распространены следующие подходы к проведению процесса тестирования: тестирование «белого ящика», тестирование «чёрного ящика», тестирование «серого ящика».

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

Тестирование «серого ящика» рассматривает внутреннюю работу программы или модуля, но только до некоторой степени. Сюда могут быть также отнесены и некоторые аспекты тестирования «чёрного ящика».

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

К основным этапам тестирования в процессе интеграции можно отнести следующие:

Возможность повторного тестирования модулей в контексте системы (в пакетах);

Тестирование интерфейсов подразумевает валидацию интерфейсов между модулями;

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

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

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

1) Объём тестируемый продукт исследуется при подаче больших объёмов входных данных.

2) Удобство и простота использования требуется измерить реакцию пользователя в любой заданной шкале.

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

4) Конфигурация настройка системы под разные аппаратные и программные архитектуры с фиксацией временных затрат на этот процесс.

5) Совместимость с другими обозначенными программными приложениями измерение времени адаптации.

6) Надёжность и доступность измерение периода работоспособного состояния в течение длительного времени.

7) Безопасность среднее время взлома системы.

8) Использование ресурсов измеряется степень использования оперативной памяти, жёсткого диска и т.д.

9) Установка программа устанавливается в разных условиях и измеряется время установки.

10) Восстанавливаемость выполнение принудительных действий для зависания программы. Измеряется время восстановления.

11) Удобство в эксплуатации выполняется обслуживание программы в разных ситуациях. Измеряется время обслуживания.

12) Загрузка и стресс программа подвергается экстремальному трафику данных и событий.

Выполнение тестов

Существует два основных подхода к выполнению тестов:

Ручное тестирование выполняется человеком, который последовательно выполняет определённые действия, определяющие методику выполнения тестов и задающие порядок их выполнения.

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

Инструментальные средства тестирования

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

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

Выделяют следующие основные инструментальные средства тестирования:

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

2.    Генератор тестовых данных. Генерирует тестовые данные для тестируемой программы в заданных областях входных данных.

3.    Оракул. Генерирует ожидаемые результаты тестов. В качестве оракулов могут выступать предыдущие версии программы или исследуемого объекта.

4.    Компаратор файлов. Сравнивает результаты тестирования с результатами предыдущего тестирования и составляет отчет об обнаруженных различиях.

5.    Генератор отчетов. Формирует отчеты по результатам проведения тестов.

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

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

Методические рекомендации

Силами проектных групп требуется разработать наборы модульных и интеграционных тестов. Результатом прохождения этапа тестирования программного продукта должны быть журналы обнаружения/исправления дефектов. Желательным является использование современных инструментальных средств тестирования.

2.10 Подготовка документации к проекту

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

Выделяют четыре основных типа документации на ПО:

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

техническая документация на код, алгоритмы, интерфейсы, API;

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

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

Документирование программного обеспечения осуществляется в соответствии с Единой системой про­граммной документации (ГОСТ 19.ХХХ). Так, ГОСТ 19.10177 устанавливает виды программных документов для программного обеспечения различных типов. Ниже перечислены основные про­граммные документы по этому стандарту и указано, какую инфор­мацию они должны содержать.

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

Текст программы (код вида документа 12) должен содер­жать текст программы с необходимыми комментариями. Необ­ходимость этого документа определяется на этапе разработки и утверждения технического задания.

Описание программы (код вида документа 13) должно со­держать сведения о логической структуре и функционировании программы.

Ведомость эксплуатационных документов (код вида докумен­та 20) должна содержать перечень эксплуатационных доку­ментов на программу, к которым относятся документы с кодами 30, 31, 32, 33, 34, 35, 46. Необходимость этого документа также определяется на этапе разработки и утверждения технического задания.

Формуляр (код вида документа 30) должен содержать ос­новные характеристики программного обеспечения, комплект­ность и сведения об эксплуатации программы.

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

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

Руководство программиста (код вида документа 33) долж­но содержать сведения для эксплуатации программного обеспе­чения.

Руководство оператора (код вида документа 34) должно содержать сведения для обеспечения процедуры общения опера­тора с вычислительной системой в процессе выполнения про­граммного обеспечения.

Руководство по техническому обслуживанию (код вида доку­мента 46) должно содержать сведения для применения тестовых и диагностических программ при обслуживании техниче­ских средств.

Программа и методика испытаний (код вида документа 51) должны содержать требования, подлежащие проверке при испы­тании программного обеспечения, а также порядок и методы их контроля.

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

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

Методические рекомендации

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

Руководство пользователя, как правило, содержит следующие разделы:

общие сведения о программном продукте;

описание установки;

описание запуска;

инструкции по работе (или описание пользовательского интерфейса);

сообщения пользователю.

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

Раздел Установка обычно содержит подробное описание действий по установке программного продукта и сообщений, ко­торые при этом могут быть получены.

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

Раздел Инструкции по работе обычно содержит описание ре­жимов работы, форматов ввода-вывода информации и возмож­ных настроек.

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

Руководство системного программиста должно содержать следующие разделы:

общие сведения о программном продукте;

структура;

настройка;

проверка;

дополнительные возможности;

сообщения системному программисту.

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

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

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

В разделе Проверка программы должно быть приведено опи­сание способов проверки работоспособности программы, напри­мер контрольные примеры.

В разделе Дополнительные возможности должно быть приве­дено описание дополнительных возможностей программы и спо­собов доступа к ним.

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

3 Программные технологии управления проектами

3.1 GanttProject

GanttProject является кросс-платформенным приложением с открытым исходным кодом.

Основным направлением его использования является планирование проектов и сопутствующие этому процессу задачи, в частности:

построение диаграмм Ганта;

распределение ресурсов по задачам;