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

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

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


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

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

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

Ресурсы

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

Скоуп проекта

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

Сроки

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

Зависимости

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

Итеративность

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

Выводы

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

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

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

URI (Uniform Resource Identifier, Универсальный идентификатор ресурса) – компактная строка символов для идентификации абстрактного или физического ресурса. Под ресурсом понимается любой объект, принадлежащий некоторому пространству. Необходимость в URI была понятна разработчикам WWW c момента зарождения системы, т.к. предполагалось объединение в единую информационную среду средств, использующих различные способы идентификации информационных ресурсов. Была разработана спецификация, которая включала в себя обращения к FTP, Gopher, WAIS, Usenet, E–mail, Prospero, Telnet, X.500 и, конечно, HTTP (WWW). В итоге была разработана универсальная спецификация, которая позволяет расширять список адресуемых ресурсов за счет появления новых схем.

Место применения URI – гипертекстовые ссылки, которые записываются в тегах и . Встраиваемые графические объекты также адресуются по спецификации URI в тегах и . Реализация URI для WWW называется URL (Uniform Resource Locator). Точнее, URL – это реализация схемы URI, отображенная на алгоритм доступа к ресурсам по сетевым протоколам. Существует еще и URN (Uniform Resource Name), которое отображает URI в пространство имен на сети.

Появление URN связано с желанием адресовать части почтового сообщения MIME. Принципы построения адреса WWW. В основу URI были заложены следующие принципы:

· Расширяемость – новые адресные схемы должны легко вписываться в существующий синтаксис URI.

· Полнота – по возможности, любая из существовавших схем должна описываться посредством URI.

· Читаемость – адрес должен был быть легко читаем пользователем, что вообще характерно для технологии WWW – документы вместе с ссылками могут разрабатываться в обычном текстовом редакторе.

Прежде, чем рассмотреть различные схемы представления адресов приведем пример простого адреса URI:

http://polyn.net.kiae.su/polyn/index.html

Перед двоеточием стоит идентификатор схемы адреса – «http». Это имя отделено двоеточием от остатка URI, который называется «путь». В данном случае путь состоит из доменного адреса машины, на которой установлен сервер HTTP и пути от корня дерева сервера к файлу «index.html». Кроме представленной выше полной записи URI, существует упрощенная. Она предполагает, что к моменту ее использования многие параметры адреса ресурса уже определены (протокол, адрес машины в сети, некоторые элементы пути). При таких предположениях автор гипертекстовых страниц может указывать только относительный адрес ресурса, т.е. адрес относительно определенных базовых ресурсов.

URL (Uniform Resource Locator, Универсальный указатель ресурса), –подмножество схем URI, который идентифицирует ресурс по способу доступа к нему (например, его «местонахождению в сети») вместо того, чтобы идентифицировать его по названию или другим атрибутам этого ресурса. URL явно описывает, как добраться до объекта.

Синтаксис: :, где:

scheme = «http» | «ftp» | «gopher» | «mailto» | «news» | «telnet» | «file» | «man» | «info» | «whatis» | «ldap» | «wais» | ... – имя схемы

scheme–specific–part – зависит от схемы. В scheme–specific–part можно использовать шестнадцатеричные значения в виде: %5f. Обязательно должны кодироваться непечатные октеты: 00–1F, 7F, 80–FF.

Примеры URL:

· http://www.ipm.kstu.ru/index.php

· ftp://www.ipm.kstu.ru/

URN (Uniform Resource Name, Универсальное имя ресурса) – частная URI–схема «urn:» с подмножеством «пространства имен», который должен быть уникальным и неизменным даже в том случае, когда ресурс уже не существует или недоступен.

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

Синтаксис: urn: namespace: data1.data2,more–data , где namespace (пространство имен) определяет, каким образом используются данные, указанные после второго «:».

Пример URN:

urn: ISBN: 0–395–36341–6

ISBN – тематический классификатор для издательств,

0–395–36341–6 – конкретный номер тематики книги или журнала

При получении URN клиентская программа обращается к ISBN (каталогу «тематический классификатор для издательств» в Интернете). И получает расшифровку номера тематики «0–395–36341–6» (например: «квантовая химия»). URN принят сравнительно недавно, в текущие версии HTML не включен и службы каталогов пока не развиты, поэтому URN не так широко распространен как URL.

Схемы адресации ресурсов Internet

Существует 3 схемы адресации ресурсов Internet. В схеме указывается ее идентификатор, адрес машины, TCP–порт, путь в директории сервера, переменные и их значения, метка.

Схема HTTP . Это основная схема для WWW. В схеме указывается ее идентификатор, адрес машины, TCP–порт, путь в директории сервера, поисковый критерий и метка.

Синтаксис: http://[[:@][:][?]]

http – название схемы

user – имя пользователя

password – пароль пользователя

host – имя хоста

port – номер порта

url–path – путь к файлу и сам файл

query (<имя–поля>=<значение>{&<имя–поля>=<значение>) – строка запроса

По умолчанию, port=80.

Приведем несколько примеров URI для схемы HTTP:

http://polyn.net.kiae.su/polyn/manifest.html

Это наиболее распространенный вид URI, применяемый в документах WWW. Вслед за именем схемы (http) следует путь, состоящий из доменного адреса машины и полного адреса HTML–документа в дереве сервера HTTP.

В качестве адреса машины допустимо использование и IP–адреса:

http://144.206.160.40/risk/risk.html

Если сервер протокола HTTP запущен на другой, отличный от 80 порт TCP, то это отражается в адресе:

http://144.206.130.137:8080/altai/index.html

http://polyn.net.kiae.su/altai/volume4 .html#first

Схема FTP . Данная схема позволяет адресовать файловые архивы FTP из программ–клиентов World Wide Web. При этом программа должна поддерживать протокол FTP. В данной схеме возможно указание не только имени схемы, адреса FTP–архива, но и идентификатора пользователя и даже его пароля.

Синтаксис: ftp://[[:@][:]

ftp – название схемы

user – имя пользователя

password – пароль пользователя

host – имя хоста

port – номер порта

url–path – путь к файлу и сам файл

По умолчанию, port=21, user=anonymous, password=email–адрес.

Наиболее часто данная схема используется для доступа к публичным архивам FTP:

ftp://polyn.net.kiae.su/pub/0index.txt

В данном случае записана ссылка на архив «polyn.net.kiae.su» c идентификатором «anonymous» или «ftp» (анонимный доступ). Если есть необходимость указать идентификатор пользователя и его пароль, то можно это сделать перед адресом машины:

ftp://nobody:[email protected]/users/local/pub

В данном случае эти параметры отделены от адреса машины символом «@», а друг от друга двоеточием.

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

Синтаксис: telnet://[[:@][:]/

telnet – название схемы

user – имя пользователя

password – пароль пользователя

host – имя хоста

port – номер порта

По умолчанию, port=23.

Пример: telnet://name:[email protected]

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

telnet://guest:[email protected]

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

Служба WWW

Служба WWW (World Wide Web) – предназначена для обмена гипертекстовой информацией, построена по схеме «клиент–сервер». Браузер (Internet Explorer, Opera ...) является мультипротокольным клиентом и интерпретатором HTML. И как типичный интерпретатор, клиент в зависимости от команд (тегов) выполняет различные функции. В круг этих функций входит не только размещение текста на экране, но обмен информацией с сервером по мере анализа полученного HTML–текста, что наиболее наглядно происходит при отображении встроенных в текст графических образов.

Сервер HTTP (Apаche, IIS ...) обрабатывает запросы клиента на получение файла. В начале служба WWW базировалась на трех стандартах:

· HTML (HyperText Markup Lan–guage) – язык гипертекстовой разметки документов;

· URL (Universal Resource Locator) – универсальный способ адресации ресурсов в сети;

· HTTP (HyperText Transfer Protocol) – протокол обмена гипертекстовой информацией.

Схема работы WWW сервера

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

Рассмотрим более схему работы WWW–сервера:

1. Пользователь сети запускает браузер, в функции которого входит:

· установление связи с сервером;

· получение требуемого документа;

· отображение полученного документа;

· реагирование на действия пользователя – доступ к новому документу. После запуска браузер по команде пользователя или автоматически устанавливает связь с заданным WWW – сервером и передает ему запрос-получение заданного документа.

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

3. Браузер, получив документ, отображает его пользователю и ожидает его реакции. Возможные варианты:

· ввод адреса нового документа;

· печать, поиск, другие операции над текущим документом;

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

1.4. Универсальный идентификатор ресурса URI

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

Многие виды ресурсов, размещенных в Интернете, независимо от того, являются ли они HTML?документами, рисунками или файлами архива, чаще всего представляют собой файлы на жестком диске компьютера (сервера), подключенного к сети. С каждым ресурсом сопоставляется значение, по которому можно однозначно определить его расположение, – универсальный идентификатор ресурса или URI (Universal Resource Identifier). URI широко используются как при самостоятельном доступе пользователя к ресурсу (когда, например, пользователь сам вводит URI в адресной строке браузера), так и при переходе между веб?страницами. URI также используются в HTML?документе для указания браузеру, где искать ресурсы (например, рисунки), используемые в самом документе.

Примечание

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

Идентификатор ресурса URI состоит из трех частей: из наименования механизма доступа к ресурсу, доменного имени компьютера и пути файла ресурса. Для пояснения сказанного можно рассмотреть пример:

Здесь можно увидеть, что для доступа к ресурсу, которым в данном случае является HTML?документ, используется протокол HTTP (Hyper Text Transfer Protocol). Ресурс хранится на компьютере, имеющем доменное имя somesite.com в файле ex_1.html, расположенном в папке /info/examples.

При помощи URI можно также ссылаться на части HTML?документов, например:

При использовании этого URI можно получить доступ к части HTML?документа, имеющей имя description (то, как создавать имена для фрагментов HTML?документов, будет рассмотрено в гл. 5).

URI также позволяют ссылаться на ресурсы в пределах одного компьютера. При этом указывается относительный путь ресурса. Например, чтобы из HTML?документа, расположенного в папке /info/examples, сослаться на файл /info/files/file1.jpg, достаточно задать URI /files/file1.jpg. В HTML?документах при помощи подобных ссылок указываются пути рисунков и других объектов, используемых в документах, но непосредственно не хранимых в них.

В общем случае URI считаются нечувствительными к регистру символов. Однако для полной уверенности в правильности интерпретации URI все же обращайте внимание на регистр символов в URI гиперссылок, рисунков и т. д. Это полезно для устранения таких ситуаций, когда, например, при работе сайта на компьютере под Windows все гиперссылки работают, а при помещении сайта на UNIX?сервер работать отказываются (в UNIX имена файлов чувствительны к регистру).