Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
|
[1] Объектно-ориентированное программирование [1.1] Понятие объекта [1.2] Класс [1.3] Наследование [1.4] Полиморфизм [1.5] Визуальное программирование [1.5.1] Вопросы для самоконтроля
[2] [2.1] Экономические аспекты программирования [2.2] Этапы разработки программ [2.3] Период разработки ПО [2.4] Контроль качества [2.5] Стандарты качества ПО [2.6] Повышение индивидуального мастерства [2.7] Гибкие методики [2.8] Методы маркетинга программного обеспечения [2.8.1] Вопросы для самоконтроля |
Развитие идей структурного и событийного программирования существенно под няло производительность труда программистов и позволило в разумные сроки (несколько месяцев) создавать приложения объемом в сотни тысяч строк. Однако такой объем уже приблизился к пределу возможностей человека, и потребовались новые технологии разработки программ.
В начале 80-х годов в программировании возникло новое направление, основанное на понятии объекта. До того времени основные ограничения на возможность созда ния больших систем накладывала разобщенность в программе данных и методов их обработки.
Реальные объекты окружающего мира обладают тремя базовыми характеристиками:
Именно в таком виде в языках программирования и реализовано понятие объекта как совокупности свойств (структур данных, характерных для этого объекта), методов их обработки (подпрограмм изменения свойств) и событий, на которые данный объект может реагировать и которые приводят, как правило, к изменению свойств объекта.
Появление возможности создания объектов в программах качественно повлияло на производительность труда программистов. Максимальный объем приложений, которые стали доступны для создания группой программистов из 10 человек, за несколько лет увеличился до миллионов строк кода, при этом одновременно удалось добиться высокой надежности программ и, что немаловажно, повторно использо вать ранее созданные объекты в других задачах.
Объекты могут иметь идентичную структуру и отличаться только значениями свойств. В таких случаях в программе создается новый тип, основанный на единой структуре объекта (по аналогии с тем, как создаются новые типы для структур данных). Он называется классом, а каждый конкретный объект, имеющий струк туру этого класса, называется экземпляром класса.
Описание нового класса
Описание нового класса похоже на описание новой структуры данных, только к полям (свойствам) добавляются методы — подпрограммы.
В Си++ и Паскале для описания класса используется ключевое слово class.
Паскаль:
class TMyClass
Item1: integer;
Item2: string;
function GetSum(n: integer): integer;
procedure Initialize;
end;
Си++:
class TMyClass
{
int Item1;
int Item2;
int GetSum(int n);
void Initialize();
);
При определении подпрограмм, принадлежащих конкретному классу, его методов, в заголовке подпрограммы перед ее названием явно указывается, к какому классу она принадлежит. Название класса от названия метода отделяют специальные сим волы (точка в Паскале или два двоеточия в Си++).
Паскаль:
procedure TMyClass.Initialize;
begin
Iteml := 1;
Item2 := «»;
end;
Си++:
void TMyClass::Initialize ()
{
Item1 = 1;
Item2 = 0;
}
Класс — это тип данных, такой же, как любой другой базовый или сложный тип. На его основе можно описывать конкретные объекты (экземпляры классов).
Паскаль:
var Cl, C2: TMyClass;
Си++:
TMyClass Cl, C2;
Доступ к свойствам объектов и к их методам осуществляется так же, как к полям записей, через точку:
Cl.Item1 := 5;
C2.Initialize;
х := Cl.GetSum(21) ;
Объектно-ориентированное программирование базируется на трех ключевых кон цепциях — инкапсуляции, наследовании и полиморфизме. Объединение данных с методами в одном типе (классе) называется инкапсуляцией. Помимо объединения, инкапсуляция позволяет ограничивать доступ к данным объектов и реализации методов классов. В результате у программистов появляется возможность исполь зования готовых классов в своих приложениях на основе только описаний этих классов.
Важнейшая характеристика класса — возможность создания на его основе новых классов с наследованием всех его свойств и методов и добавлением собственных. Класс, не имеющий предшественника, называется базовым.
Например, класс «животное» имеет свойства «название», «размер», методы «идти» и «размножаться». Созданный на его основе класс «кошка» -наследует все эти свойства и методы, к которым дополнительно добавляется свойство «окраска» и метод «пить».
Наследование позволяет создавать новые классы, повторно используя уже гото вый исходный код и не тратя времени на его переписывание.
В большинстве случаев методы базового класса у классов-наследников приходится переопределять — объект класса «кошка» выполняет метод «идти» совсем не так, как объект класса «амеба». Все переопределяемые методы по написанию (назва нию) будут совпадать с методами базового объекта, однако компилятор по типу объекта (его классу) распознает, какой конкретно метод надо использовать, и не вызовет для объекта класса «кошка» метод «идти» класса «животное». Такое свой ство объектов переопределять методы наследуемого класса и корректно их исполь зовать называется полиморфизмом.
Технологии объектного, событийного и структурного программирования сегодня объединены в .RAD-системах, которые содержат множество готовых классов, пред ставленных в виде визуальных компонентов, которые добавляются в программу одним щелчком мыши. Программисту надо только спроектировать внешний вид окон своего приложения и определить обработку основных событий — какие опера торы будут выполняться при нажатии на кнопки, при выборе пунктов меню или щелч ках мышкой. Весь вспомогательный исходный код среда сгенерирует сама, позво ляя программисту полностью сосредоточиться только на реализации алгоритма.
1. Для чего в языки программирования было введено понятие класса?
2. В чем различие между классом и объектом?
3. Поясните понятие инкапсуляции на бытовых примерах.
4. Для чего применяется механизм наследования?
5. Как полиморфизм модифицирует принцип наследования?
6. Опишите использование принципов объектно-ориентированного програм мирования в средах быстрого проектирования.
Появление первых компьютеров породило программирование как науку. Разраба тывались первые математические теории обработки информации, средства дока зательства правильности программ, оптимизации кода, создания эффективных компиляторов, формального тестирования и т. д. Затем, с появлением универсаль ных языков программирования третьего поколения, эти аспекты стали менее акту альными — исследования шли и идут в основном в области автоматической генера ции исходных текстов и повышения эффективности компиляторов. Программирование превратилось в искусство — миллионы людей, не имевших специального образо вания, получили возможности применять компьютеры для решения собственных прикладных задач, что потребовало от них мастерства создавать правильно рабо тающие программы. Искусством программирование остается и сегодня для про фессиональных разработчиков и любителей, создающих программы в одиночку или в небольших компаниях, где все решает индивидуальное мастерство.
Вместе с тем, при росте спроса со стороны государственных и частных организа ций на все более и более сложные системы автоматизации предприятий, надеж ные операционные среды, комплексы глобального телекоммуникационного управ ления, возникла необходимость в постановке процесса разработки программного обеспечения (ПО) на поток, превращения программирования в ремесло. Было раз работано несколько методологий и стандартов, позволивших эффективно органи зовывать труд сотен программистов средней квалификации, точно укладываться в отпущенные сроки и средства и не зависеть от настроения нескольких талантли вых ведущих специалистов. Отрицательная сторона подобных методологий — отсутствие творческого элемента в работе и своеобразная конвейерная «потогон ная» система промышленного производства программ, которая, будучи внедрен ной в организации, в условиях жесточайшего дефицита программистов во всем мире может только отпугнуть сотрудников.
Потенциальные возможности человека
|
Объем проекта, строк исходного кода |
Тип программы |
Время создания |
Вероятность успешного завершения |
Число программистов |
|
100 |
Утилиты для временных нужд |
1 день |
100% |
1 |
|
1000 |
Небольшие приложения и дополнения, вносимые в готовые системы |
до 1 Месяца |
100% |
1 |
|
10000 |
Типичная средняя программа, разрабатываемая на заказ |
до 6 месяцев |
85% |
1 (предел возможностей среднего программиста) |
|
100000 |
Большинство современных коммерческих автономных и небольших клиент-серверных приложений |
1 год |
85% для групп, 35% для одиночки |
10 |
|
1 млн |
Крупные системы автоматизации |
1,5-5 лет |
50% для группы, 0% для одиночки |
100 |
|
10 млн |
Операционные системы (Microsoft Windows, IBM VMS), большие военные комплексы. Предел сегодняшних возможностей. Стоимость подобной разработки может равняться стоимости большого стадиона или крупного корабля |
5-8 лет |
35% |
до тысячи |
Когда на свет появились первые компьютеры, одна минута их работы стоила очень дорого, а задачи решались достаточно простые, поэтому в расходах на подготовку программ труд разработчиков составлял небольшую часть. С появлением ПК и ростом спроса на большие программные системы практически всю расходную часть проекта стала составлять зарплата программистов. Как видно из таблицы, большой процент таких проектов заканчивается неудачно, а расходы на них очень велики, поэтому проблемы создания качественного программного обеспечения точно в срок и в рамках бюджета сегодня самые важные и над созданием эффективных методо логий производства ПО трудятся специалисты во всех развитых странах.
Программы небольшого и среднего размера (несколько тысяч строк) создаются, как правило, в два этапа. Сначала необходимо точно установить, что надо сделать, продумать соответствующий алгоритм, определить структуры данных, объекты и взаимодействие между ними (это этап системного анализа), а затем выразить этот алгоритм в виде, понятном машине (этап кодирования). Если же разрабатывается крупный проект объемом от десятков тысяч до миллионов строк кода, тогда прихо дится применять специальные методологии проектирования, охватывающие период разработки ПО.
Рассмотрим классический период разработки ПО.
1. Формируются и анализируются требования к проекту. Этот этап самый важ ный, так как неправильное формулирование требований приводит к выполне нию ненужной работы, а недооценка сложности вызывает перерасход средств и времени. Сегодня около 60% крупных проектов завершаются неудачей именно из-за ошибок на стадии подготовки требований.
На основе требований по различным методикам определяется примерный объем проекта и его трудоемкость, рассчитываются будущие трудозатраты и определяется его стоимость. Так как требования к проекту во время работы над ним могут уточняться и меняться, а выполнение требований надо отслежи вать, применяются специальные программы для управления требованиями.
Часто заказчик не в состоянии точно выразить, чего он хочет, и задача специа листов по системному анализу — помочь ему выразить свои требования в виде, пригодном для формализации. После согласования требований подписывается контракт на разработку ПО. В дальнейшем любые отклонения от сформули рованных требований к продукту (как со стороны заказчика, так и со стороны исполнителя) рассматриваются как нарушение контракта.
Каждый этап требует от заказчика вложения собственных трудозатрат и при влечения высокопрофессиональных специалистов, поэтому он обязательно должен оплачиваться — бесплатно выполнять сложную работу никто не будет. Однако, хотя первый этап самый важный, заказчик редко понимает эту важность и не готов платить достаточно большие суммы. Примерный объем работ на этом этапе — 5% от объема всего проекта.
2. Начинается предпроектное обследование объекта автоматизации. С помощью CASE-средств составляется формальная модель его работы, модель базы дан ных, объектов и потоков информации. На этом этапе привлекаются специали сты заказчика и эксперты, хорошо знакомые с предметной областью, для кото рой составляется задача.
Примерный объем работ второго этапа — 10% от общего.
3. На основе формальной модели составляется подробное техническое задание для программистов, спецификации отдельных модулей, таблицы баз данных, другая сопроводительная документация. Готовится подробный календарный план работ, где указываются все сроки, конкретные исполнители и выполняе мые объемы работ (понедельно, помесячно). Для составления планов работ имеется немало хороших программ, ориентированных как на небольшие группы программистов, так и на коллективы из сотен сотрудников, выполняющих тысячи различных работ в рамках общего плана.
Примерный объем работ третьего этапа — 10% от общего.
4. Выбирается методология разработки ПО и начинается разработка (кодирова ние). Крупные компании имеют собственные методологии, ориентированные на конкретные задачи (как правило, это задачи автоматизации предприятий), однако все методологии имеют общие черты и более-менее серьезно различа ющихся известно около двух десятков.
Мы коснулись, в частности, методологий структурного (нисходящего) и объект ного проектирования. Хотя объектный подход, безусловно, один из самых пере довых, он подразумевает высокую квалификацию всех исполнителей без исключения и поэтому распространен не очень широко.
Достаточно популярна методология итерационного проектирования, ориенти рованная на использование RAD-средств и систем автоматической генерации исходных текстов на основе созданной формальной модели. Такой подход хорош тем, что позволяет быстро создать первый работающий прототип программы, когда еще требования к ней окончательно не определены, а в дальнейшем, на следующих итерациях (их обычно требуется от двух до пяти), постепенно детали зировать и реализовывать конкретные возможности, пропущенные по каким-то причинам на предыдущей итерации. Эта методология немного отличается от нисходящего проектирования тем, что применяется, когда окончательные тре бования неизвестны и могут меняться, а основные работающие функции нужны заказчику как можно быстрее (заказчик чаще хочет получить приложение, закон ченное на 80%, сегодня, чем законченное на 100% завтра). При нисходящем проектировании основная структура задачи должна быть определена заранее.
Принятие решения о выборе подходящей методологии — очень ответственный процесс. Человек, принимающий такое решение, должен обладать богатым опытом и знаниями в области создания ПО. Многое зависит от инфраструктуры заказчика — какие у него компьютеры, операционные системы, каковы их ресурсы. В соответствии с этим выбираются и средства разработки. Иногда бывает, что лучше всего подходит, например, итерационная методология, но для операци онной системы заказчика нет хорошей RAD-среды и приходится остановиться на менее эффективной методологии.
В процессе разработки необходимо:
Примерный объем этих работ — 10% от общего объема проекта.
5. Когда программа закончена (готова работоспособная альфа-версия), она посту пает к тестерам компании-исполнителя, которые начинают проверять ее на наличие ошибок и сообщать о найденных ошибках программистам. Анализиру ется, в частности, устойчивость работы программы при вводе недопустимых или критических значений, при отсутствии информации, при неверных дейст виях, при сбоях аппаратуры, в стрессовых режимах и т. п. Когда число ошибок, выявляемых за определенный срок (неделя, месяц), снижается ниже экспери ментально подобранного уровня (на основе аналогичных проектов), начина ется бета-тестирование программы у заказчика. К такому тестированию при влекается максимально возможное число сотрудников, и программа уже начинает частично функционировать в рабочем режиме.
Примерный объем этих работ — 10% от общего объема проекта.
6. После того как заказчик удовлетворен качеством продукта, начинается его вне дрение — подготовка к окончательному запуску в эксплуатацию. Если прило жение многопользовательское, нередко требуется сформировать и настроить локальную сеть, установить серверы, инсталлировать вспомогательные про граммы. Очень много проблем возникает при переходе со старых программ (например, бухгалтерского учета, расчета зарплаты, работы с персоналом), кото рые создавались разными сотрудниками и покупались в разных фирмах (так называемая лоскутная автоматизация}, к новой интегрированной системе. Необходимо выверить, ввести или перенести множество жизненно важной информации: всю бухгалтерскую и финансовую отчетность, данные о хранимом оборудовании и множество других сведений. Этот этап самый трудоемкий и «нудный» и занимает порой до 90% времени всего проекта. Для систем автома тизации больших предприятий он растягивается на годы.
7. После того как новая система готова к работе, сотрудников организации заказ чика нужно обучить работе с этой системой, потому что книг о ней не написано, да и содержится в такой системе, внедренной на конкретном предприятии, множество нюансов, связанных со спецификой работы.
Примерный объем трудозатрат на обучение — 5% от общего объема проекта.
8. После того как заказчик подписывает акт приемки, проект считается завершен ным, но связь с исполнителем не теряется. Особенно в первое время у пользова телей системы постоянно будет возникать множество вопросов по работе с ней. Неизбежно и возникновение ошибок, которые требуется устранять. Кроме того, исполнитель может выпускать новые версии системы, и старая система потре бует обновления. Сотрудничество с заказчиком по обслуживанию системы назы вается сопровождением. Оно бесплатно на определенный гарантийный срок (например, год).
Реально объем непосредственного программирования и отладки (тестирова ния) в цикле разработки невелик. Он составляет 10-20% от общего объема работ.
Чем крупнее проект, тем больше в нем ошибок. При этом слишком затягивать этап тестирования нельзя — нарушаются сроки, растет недовольство потребителей, и на рынок выпускается «сырая» система с множеством ошибок, которые устраня ются уже в процессе эксплуатации выпуском многочисленных «заплаток».
Современные технологии создания надежного ПО предусматривают непрерывный сквозной контроль качества разрабатываемого продукта на всех этапах жизненного цикла — от анализа требований до внедрения и сопровождения, а не только на этапе тестирования. Качество каждой работы в плане формализуется числовой величиной с помощью специальных методик, но его можно контролировать, только оптимальным образом организовав работу большой группы аналитиков и програм мистов. Для этого надо иметь возможность отслеживать вносимые в проект изме нения — изменения требований, формальных моделей, сопроводительной докумен тации, версий исходных текстов, хода выполнения календарного плана по разработке, тестированию, внедрению, сопровождению, а также контролировать и управлять всеми этапами периода создания программы — процессом разработки ПО. Для этого предназначены системы конфигурационного управления — сложные и дорогие (десятки и сотни тысяч долларов) продукты, однако без них крупный проект, скорее всего, обречен на неудачу.
Системы не очень сложного конфигурационного управления, охватывающие кон троль версий исходных текстов и ряд других аспектов работы группы программи стов, встроены, в частности, в такие системы, как Delphi 7 и Visual Studio .NET.
Компания может организовать у себя очень эффективный процесс разработки ПО, однако заказчик вполне обоснованно может ей не поверить. Существует междуна родная система сертификации компаний по стандарту качества ISO 9000, которая гарантирует, что данная компания выполняет программные проекты в срок и с высоким качеством. Процесс сертификации сложен и требует подготовительной работы в течение нескольких лет.
В университете Карнеги-Меллона в США несколько лет назад была разработана специальная методология СММ (Capability Maturity Model for Software), позволяющая сертифицировать компании по одному из 5 уровней «зрелости» процесса разработки ПО. Согласно результатам 20-летних исследований Министерства обо роны США оказалось, что главная причина слишком частых неудач при разработке крупных информационных проектов заключается прежде всего в неумении менед жеров управлять процессом создания качественного ПО.
В отличие от стандарта ISO 9000, который просто подтверждает качественную работу компании на основании достаточно общих критериев, методология СММ ориентирована именно на качество управления процессом разработки и имеет мно жество конкретных рекомендаций и указаний по способам организации всех этапов создания ПО. Сегодня в США невозможно получить крупный государственный или военный заказ на создание программного продукта стоимостью более 2 млн. долларов, если компания не сертифицирована как минимум по третьему уровню СММ. Сегодня на смену этой модели приходит новая интеграционная концепция CMMI, дополняющая процессы разработки не менее важными вопросами органи зации деятельности персонала, общения с подрядчиками, выбора программного обеспечения и т. д.
На основе методологии СММ была создана методология PSP (Personal Software Process), ориентированная на индивидуальных разработчиков. Она позволяет в несколько раз повысить качество создания программ, значительно поднять собст венную производительность и научиться предсказывать сроки выполнения работ.
Методология PSP состоит из 7 этапов самосовершенствования, и, чтобы хорошо ее освоить, надо закончить специальные курсы. Однако даже простое знакомство с ее идеологией позволит любому программисту значительно улучшить свою работу.
Перед началом проекта составляется подробный календарный план работ и произ водится попытка оценить его объем в строках кода и рабочих днях. Весь процесс работы детально хронометрируется, а найденные ошибки подробно описываются — накапливается статистика. По окончании проекта весь процесс тщательно анализи руется и делаются выводы о том, что можно улучшить в своей работе, каких ошибок надо стараться избегать, какова реальная производительность труда и т. п. Сегодня лучшая характеристика программиста — это не просто знание Си++ или Delphi, а способность планировать свой труд, разрабатывать программу точно в срок и без ошибок.
В последние годы наряду с ростом интереса к «тяжелым» сертификационным мето дологиям значительно увеличилась роль и популярность так называемых гибких, проворных (agile) методик. Они не требуют значительных усилий по реорганиза ции компании-разработчика и могут быть внедрены не за годы, а за недели. Наибо лее известные среди них — экстремальное программирование, MDA (архитектура системы, управляемая моделью), Scrum и другие.
Гибкие методики не навязывают исполнителю множество формализованных дейст вий по разработке ПО. Они предоставляют участникам проекта большую свободу (но и требуют от них большей ответственности) и акцентируют их внимание на важнейших задачах соблюдения требований заказчика, сроков и качества работы.
Коммерческое ПО. При создании программного продукта издатель, выполнив анализ рынка, заказывает у исполнителя разработку такого ПО, которое должно пользоваться на рынке спросом, и выделяет на его создание деньги. По окончании работ издатель получает все имущественные права на созданный продукт (право на тиражирование, продажу под собственной торговой маркой, право на получение дохода от программы любым способом). При этом может быть оговорено получе ние исполнителем некоторого процента (роялти) с каждой проданной копии (как правило, для программ, издающихся сотнями тысяч или миллионами копий, роялти составляет 1-3%) — тогда он получает меньшую сумму на разработку или вообще создает программу за свой счет. Если же отчисления не предусмотрены, то все рас ходы по подготовке программы издатель берет на себя. Он также вкладывает сред ства в упаковку, рекламную кампанию, организацию сетей сбыта и т. д. Издатель обеспечивает расходы, связанные с сопровождением продукта и технической под держкой пользователей.
За исполнителем навечно остаются авторские права на программу — право указы вать свое имя или логотип своей фирмы на начальной заставке, в документации, на упаковочной коробке.
Крупные компании имеют и подразделения разработки ПО, и отделы, занимаю щиеся его распространением, что помогает эффективно организовать весь процесс от производства программ до доставки их потребителю.
Условно-бесплатное ПО (shareware). В связи с активным развитием Интернета огромное число индивидуальных разработчиков получили возможность распро странения своих программ по всему миру. Не имея средств на рекламные кампании, они предоставляют возможность получения ознакомительных версий их программ (демонстрационных или имеющих искусственные ограничения) через Интернет. Если человеку эта программа нравится, он оплачивает небольшую сумму и полу чает полную работоспособную версию.
В Интернете есть немало узлов, которые предлагают бесплатные услуги по размеще нию таких программ. Отечественным shareware-разработчикам можно порекомен довать сайт www.swrus.com, на котором можно найти множество материалов и фору мов по всем вопросам организации shareware.
Бесплатное ПО (freeware, public domain). Такие программы не имеют никаких ограничений, однако автор может попросить заплатить ему некоторую сумму, не настаивая, впрочем, на этом (это метод freeware). Некоторые программы авторы называют «общественным достоянием» (public domain), ничего взамен не требуют и нередко распространяют такое ПО в исходных текстах.
Как правило, стимулом к созданию бесплатных программ служит стремление повы сить собственную квалификацию, установить контакты с коллегами, а в случае удачно созданной программы получить известность.
1. В чем трудности разработки крупных программных проектов?
2. Опишите организацию работы над сложной программной системой.
3. Какой этап разработки проекта является наиболее ответственным?
4. Какова роль собственно программирования в ходе работы над проектом?
5. Опишите известные вам методы контроля качества программного обеспечения.
6. Каковы основные методы распространения программного обеспечения?