uzluga.ru
добавить свой файл



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



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

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

Т.о. разработка ПО постоянно происходит при этих ограничениях.

Возможны два пути выполнения проекта.

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

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

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

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


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


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

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

Пользователь должен ввести уровень сложности и получить список маршрутов с заданной сложностью.


Второе утверждение заказчика:

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

Ваши варианты:

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

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


Какие варианты ближе всего к ожиданиям заказчика?


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

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


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


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


Итак, мы приходим к понятию итерации разработки.


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

Без итераций процесс можно изобразить так:



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

Если же воспользоваться итерациями:



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




Длина итерации выбирается в процессе разработки, обычно (для средних проектов) она составляет 20 дней.

В итоге итерация дает:

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

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

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


Каждая итерация – это минипроект. У него есть все присущие большому проекту этапы:

  • сбор требований,

  • проектирование,

  • кодирование,

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








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







Одно из решений могло быть таким:



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


В жизни заказчики меняют и добавляют требования уже в процессе разработки. Например,



При этом возникают большие проблемы.




Чтобы решить новую задачу, придется:

1) оценить время необходимое на выполнение новых функций



2) заставить заказчика расставить реальные приоритеты для новых возможностей по сравнению с оставшимися



3) переделать план



4) проверить сроки сдачи проекта




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


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


Хорошие программисты пишут программы, отличные программисты сдают их заказчику! :-)


Основные принципы объектно-ориентированного программирования (начало)



Объектно-ориентированное программирование (ООП) — парадигма программирования, в которой основными концепциями являются понятия объектов и классов.


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

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

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


Обычно классы разрабатывают таким образом, чтобы их объекты соответствовали объектам предметной области.


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

Сообщение состоит из четырех частей:

• идентификатор получателя;

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

• аргументами для этого метода;

• возвращаемого отправителю значения.

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


По способу взаимодействия с другими объектами различают такие виды объектов:

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

• сервер – обслуживает запросы других объектов;

• агент – играет роль и клиента и сервера.


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

В объектно-ориентированных языках тип – синоним класса, но на этапе проектирования эти понятия различаются.

Объекты одного типа имеют общие свойства и поведение.

Класс является объединением двух вещей: интерфейса и реализации. Интерфейсная часть – это то, что объединяет понятия типа и класса. Класс, у которого есть только интерфейс, определяет тип. Желательно как можно дольше проектировать систему в терминах типов (интерфейсов), поскольку, таким образом, удается избежать введения деталей реализации.

Основной особенностью интерфейса является то, что он включает в себя только объявление методов класса без реализации.

История


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


Первым языком программирования, в котором были предложены принципы объектной ориентированности, была Симула. В момент своего появления (в 1967 году), этот язык программирования предложил поистине революционные идеи: объекты, классы, виртуальные методы и др., однако это всё не было воспринято современниками как нечто грандиозное. Тем не менее, большинство концепций были развиты Аланом Кэйем и Дэном Ингаллсом в языке Smalltalk. Именно он стал первым широко распространённым объектно-ориентированным языком программирования.


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