1. Процедурно-ориентированный и объектно-ориентированный подходы к разработке ПО

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

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

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

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

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

2. Этапы жизненного цикла разработки и развития ПС. Особенности

Наиболее часто говорят о следующих моделях жизненного цикла:

• Каскадная (водопадная) или последовательная

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

• Итеративная и инкрементальная – эволюционная (гибридная, смешанная)

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

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

• Спиральная (spiral) или модель Боэма

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

3. Системный анализ и системное проектирование ПС. Программа как система

4. Технология разработки ПС RUP. Особенности

Rational Unified Process – это методология создания программного обеспечения, оформленная в виде размещаемой на Web базы знаний, которая снабжена поисковой системой.

Продукт Rational Unified Process (RUP) разработан и поддерживается Rational Software. Он регулярно обновляется с целью учета передового опыта и улучшается за счет проверенных на практике результатов.

Rational Unified Processподдерживает объектно-ориентированную технологию. Моделирование по методологии RUP является объектно-ориентированным и базируется на понятиях объектов, классов и зависимостей между ними.

• моделирование бизнес-процессов;

• управление требованиями;

• анализ и проектирование;

• реализация;

• тестирование;

• развертывание;

• конфигурационное управление и управление изменениями;

• управление проектом;

• управление средой.

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

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

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

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

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

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

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

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

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

5. Язык UML. Назначение. Возможности

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

UMLпредставляет собой объектно-ориентированный язык моделирования, обладающий следующими основными характеристиками:

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

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

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

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

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

6. UML. Диаграмма классов. Выделение классов предметной области и выявление отношений между ними. Этапы построения объектной модели и формальные признаки ее усовершенствования

Класс (Class) - это описание совокупности объектов с общими атрибутами, операциями, отношениями и семантикой. Класс реализует один или несколько интерфейсов.

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

На диаграмме классов (Class Diagram) показывают классы, интерфейсы, объекты и кооперации, а также их отношения. Между классами возможны различные отношения:

• зависимости, которые описывают существующие между классами отношения использования;

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

• ассоциации, структурное отношение, описывающее совокупность связей; связь - это соединение между объектами.

• агрегация – это когда класс в своей структуре использует часть другого класса;

• композиция. При композиции класс является целиком частью другого класса.

Этапы построения объектной модели:

• определение объектов и классов;

• подготовка словаря данных;

• определение зависимостей между объектами;

• определение атрибутов объектов и связей;

• организация и упрощение классов при использовании наследования;

Для дальнейшего улучшения ищутся:

Признаки пропущенного объекта (класса):

• несимметричности связей и обобщений (наследований); для исправления ошибки необходимо добавить пропущенные классы;

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

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

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

Признаки ненужного (лишнего) класса:

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

Признаки пропущенных зависимостей:

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

Признаки ненужных (лишних) зависимостей:

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

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

Признаки неправильного размещения зависимостей:

• имена ролей слишком широки или слишком узки для их классов; для исправления ошибки необходимо переместить зависимость вверх или вниз по иерархии классов.

Признаки неправильного размещения атрибутов:

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

7. Классы и отношения между классами. Реализация отношений между классами средствами C#

Класс (Class) - это описание совокупности объектов с общими атрибутами, операциями, отношениями и семантикой. Класс реализует один или несколько интерфейсов.

На диаграмме классов (Class Diagram) показывают классы, интерфейсы, объекты и кооперации, а также их отношения. Между классами возможны различные отношения:

• зависимости, которые описывают существующие между классами отношения использования;

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

public class Employee : Man

• ассоциации, структурное отношение, описывающее совокупность связей; связь - это соединение между объектами.

public class Employee : Man{

private String position;

private IdCard iCard;

public void setIdCard(IdCard c){

iCard = c;

}

public IdCard getIdCard(){

return iCard;

}

}

public class IdCard{

private Date dateExpire;

private int number;

public IdCard(int n){

number = n;

}

}

• агрегация – это когда класс в своей структуре использует часть другого класса;

public class Department{

}

class other{

private Department department;

public void setDepartment(Department d){

department = d;

}

public Department getDepartment(){

return department;

}

}

• композиция. При композиции класс является целиком частью другого класса.

public class Department{

}

class other{

private Department department;

public void setDepartment(Department d){

department = d;

}

public Department getDepartment(){

return department;

}

}

class Main {

private List<> pastPosition = new HashSet();

...

public void setPastPosition(PastPosition p){

pastPosition.add(p);

}

public Set getPastPosition(){

return pastPosition;

}

public void deletePastPosition(PastPosition p){

pastPosition.remove(p);

}

}

8. UML. Диаграммы состояний объекта и последовательностей. Особенности синтеза

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

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

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

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

История (History) – свойство объекта запоминать предыдущие состояния, которое отображается на диаграмме специальным значком, размещаемым внутри элемента «Состояние». Этот элемент не может использоваться без связи с состоянием, к которому относится история.

Начальное состояние – это состояние объекта, в котором он создается.

Конечное состояние – состояние, из которого объект не может вернуться в активное состояние.

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

Линия жизни объекта (Lifeline) – отображает все, что происходит с объектом от его создания до его разрушения.

Объект (Object) – в рамках диаграммы последовательности – это экземпляр класса, сущность, шаблон.

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

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

9. Диаграмма прецедентов. Роль прецедентов при разработке ПС. Виды прецедентов и отношения между ними. Правила описания

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

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

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

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

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

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

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

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

10. Формирование требований к ПС на основе прецедентов. Функции ПС

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

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

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

• заголовок (название прецедента, ответственный за исполнение, дата создания шаблона/внесения изменений);

• краткое описание прецедента;

• ограничения;

• предусловия (необходимое состояние системы или условия, при которых должен выполняться прецедент);

• постусловия (возможные состояния системы после выполнения прецедента);

• предположения;

• основная последовательность действий;

• альтернативные последовательности действий и условия, их инициирующие;

• точки расширения и включения прецедентов.

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

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

11. Развертывание и представление ПС. Диаграммы компонентов и развертывания

Диаграммы компонентов (component diagrams) – модель иерархии подсистем, отражает физическое размещение баз данных, приложений и интерфейсов ИС.

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

12. Анализ требований при проектировании ПС. Диаграммы кооперации и видов деятельности

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

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

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

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

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

13. Классический жизненный цикл разработки ПС. Частные реализации и особенности

Эта модель обязана своим появлением У. Ройсу ([1], 1970 г.). Модель имеет и другое название – водопад (waterfall). Особенность модели – переход на следующую ступень осуществляется только после того, как будет полностью завершена работа на предыдущей стадии; возвратов на пройденные стадии не предусматривается (рис.5.4).

Рис. 5.4. Каскадная модель жизненного цикла программного обеспечения

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

Преимущества каскадной модели:

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

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

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

Недостатки каскадной модели:

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

• реальные проекты часто требуют отклонения от стандартной последовательности шагов;

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

• результаты работ доступны заказчику только по завершении проекта.

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

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

Основными принципами являются:

• Итеративность.Разработка ведется короткими итерациями при наличии активной взаимосвязи с заказчиком.

• Простота решений.Принимается первое простейшее рабочее решение.

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

• Обратная связь с заказчиком, представитель которого фактически вовлечен в процесс разработки.

• Достаточная степень смелостии желание идти на риск.

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

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

2. Тесное взаимодействие с заказчиком.Представитель заказчика должен быть членом XP-команды. Необходимо наличие постоянное обратной связи с представителем заказчика.

3. Общесистемные правила именования.Команда разработчиков должна иметь единые правила именования.

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

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

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

7. 40-часовая рабочая неделя.Программист не должен работать более 8 часов в день.

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

9. Единые стандарты кодирования.Стандарты кодирования нужны для обеспечения других практик: коллективного владения кодом, парного программирования и рефакторинга. Без единого стандарта выполнять эти практики как минимум сложнее, а в реальности вообще невозможно.

10. Небольшие релизы.Минимальная итерация – один день, максимальная – месяц; чем чаще осуществляются релизы, тем больше недостатков системы будет выявлено.

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

12. Тестирование.В отличие от большинства остальных методологий тестирование в XP – одно из важнейших составляющих. Экстремальный подход предполагает, чтотесты пишутся до написания кода. Каждый модуль обязан иметь unit test – тест данного модуля.

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

15. Унифицированный процесс разработки ПС. Этапы и итерации. Особенности

Рациональный унифицированный процесс(Rational Unified Process, RUP) – одна из лучших методологий разработки программного обеспечения [32]. Основываясь на опыте многих успешных программных проектов, RUP позволяет создавать сложные программные системы, основываясь на индустриальных методах разработки.

RUP – одна из спиральных методологий разработки программного обеспечения. Методология поддерживается и развивается компанией Rational Software. В качестве языка моделирования в общей базе знаний используется язык Unified Modelling Language (UML). Итерационная и инкрементная разработка программного обеспечения в RUP предполагает разделение проекта на несколько проектов, которые выполняются последовательно, и каждая итерация разработки четко определена набором целей, которые должны быть достигнуты в конце итерации. Конечная итерация предполагает, что набор целей итерации должен в точности совпадать с набором целей, указанных заказчиком продукта, то есть все требования должны быть выполнены.

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

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

1. Начало (Inception) – формирование концепции проекта, понимание того, что мы создаем, представление о продукте (vision), разработка бизнес-плана (business case), подготовка прототипа программы или частичного решения. Это фаза сбора информации и анализа требований, определение образа проекта в целом. Цель – получить поддержку и финансирование. В конечной итерации результат этого этапа – техническое задание.

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

3. Реализация, создание системы (Construction) – этап расширения функциональности системы, заложенной в архитектуре. В конечной итерации это – рабочий проект.

4. Внедрение, развертывание (Transition). Создание конечной версии продукта. Фаза внедрения продукта, поставка продукта конкретному пользователю (тиражирование, доставка и обучение).

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

1. Бизнес-анализ и моделирование (Business modeling) обеспечивает реализацию принципов моделирования с целью изучения бизнеса организации и накопления знаний о нем.

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

3. Анализ и проектирование (Analysis and design) охватывает процедуры преобразования требований в промежуточные описания (модели), представляющие, как эти требования должны быть реализованы.

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

5. Тестирование (Test) посвящено оценке качества создаваемого продукта.

6. Развертывание (Deployment) охватывает операции, имеющие место при передаче продуктов заказчикам и обеспечении доступности продукта конечным пользователям.

7. Конфигурационное управление и управление изменениями (Configuration management) посвящено синхронизации промежуточных и конечных продуктов и управлению их развитием в ходе проекта и поиском скрытых проблем.

8. Управление проектом (Management) посвящено планированию проекта, управлению рисками, контролю хода его выполнения и непрерывной оценке ключевых показателей.

9. Управление средой (Environment) включает элементы формирования среды разработки информационной системы и поддержки проектной деятельности.

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

16. Планирование и управление проектом. Командная разработка ПС

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

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

• составление плана-проспекта по разработке ПС;

• планирование и составление расписаний по разработке ПС;

• управление издержками по разработке ПС;

• текущий контроль и документирование деятельности коллектива по разработке ПС.

• подбор и оценка персонала коллектива разработчиков ПС.

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

• для внешнего заказчика,

• для других подразделений той же организации,

• или является инициативной внутренней разработкой.

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

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

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

Харлан Миллз [Брукс 1999] предложил организовывать команды (бригады) главного программиста (chief programmer teams), подобные хирургическим бригадам. Лишь один участник команды занимается основной работой, остальные оказывают ему всевозможную поддержку

 Можно выделить четыре типа совместной деятельности [Robillard, Robillard 2000].

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

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

• Естественная совместная деятельность имеет место, когда как минимум двое программистов работают над одной и той же задачей одновременно и обмениваются информацией о выполняемой работе. Эта деятельность занимает около 41% рабочего времени.

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

17. Критерии и метрики определения качества и сложности разработки пс. Фунционально и размерно-ориентированные метрики. Метрики оопс (метрики Чидамбера-Кемерерва).

Функционально-ориентированные метрики косвенно измеряют программный

продукт и процесс его разработки. Вместо подсчета LOC – оценки при этом

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

Используется 5 информационных характеристик.

1.Количество внешний вводов. Подсчитываются все вводы пользователя, по

которым поступают разные прикладные данные.

2.Количество внешних выводов. Подсчитываются все выводы, по которым к

пользователю поступают результаты, вычисленные программным приложением.

3.Количество внешних запросов. Под запросами понимают диалоговый ввод,

который приводит к немедленному программному ответу в форме диалогового вывода.

4.Количество внутренних логических файлов. Подсчитываются все логические

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

отдельным файлом).

5.Количество внешних интерфейсных файлов. Подсчитываются все логические

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

После сбора всей необходимой информации приступают к расчетам метрики – количества

функциональных указателей FP (Function Points).

FP= Общее количество*(0,65+0,01*F

i

),

Где F

i

– коэффициент регулировки сложности (I=1..14).

После вычисления FP на его основе формируются метрики производительности,

качества и другие оценки.

Производительность = ФункцУказатель / Затраты (FP/чел.-мес.);

Качество = Ошибки / ФункцУказатель (Единиц/FP);

Удельная Стоимость = Стоимость / ФункцУказатель (Тыс.$/FP);

Документированность=СтраницДокумента/ФункцУказатель (Страниц/FP)

Размерно-ориентированные метрики прямо измеряют программный продукт и процесс его разработки. Основываются такие метрики на LOC-оценках (Lines Of Code). LOC-оценка — это количество строк в программном продукте. Исходные данные для расчета этих метрик сводятся в таблицу (табл. 2.1)

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

- общие затраты (в человеко-месяцах  - чел.-мес);

- объем программного изделия (в тысячах строк исходного кода -KLOC);

- стоимость разработки (в тыс.рублей или в долларах $);

- объем документации (в страницах документов -СД);

- ошибки, обнаруженные в течение первого года эксплуатации (число ошибок -  ЧО);

- число людей, работавших над изделием (человек);

- срок разработки (в календарных месяцах).

Достоинства размерно-ориентированных метрик:

1)    широко распространены;

2)    просты и легко вычисляются.

Недостатки размерно-ориентированных метрик:

1)    зависимы от языка программирования;

2)    требуют исходных данных, которые трудно получить на начальной стадии проекта;

3)    не приспособлены к непроцедурным языкам программирования.

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

 

Метрика 1: Взвешенные методы на класс wmc (Weighted Methods Per Class)

 

Допустим, что в классе С определены п методов со сложностью с₁..._,c₂,..., с_n. Для оценки сложности может быть выбрана любая метрика сложности (например, цикломатическая сложность). Главное — нормализовать эту метрику так, чтобы номинальная сложность для метода принимала значение 1. В этом случае

Очень часто применяют упрощенную версию метрики. При этом полагают С_i= 1, и тогда WMC — количество методов в классе.

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

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

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