Цели программных инженеров

Целями программных инженеров являются:

- Создать качественный продукт.

- Уложиться в бюджет.

- Уложиться в сроки.

Разберем по очереди эти вопросы.

Качественный программный продукт

- Должен предоставлять требуемую функциональность.

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

- Должен быть удобным в сопровождении.

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

- Должен быть надежным.

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

- Должен быть эффективным.

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

- Должен быть удобным в использовании.

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

Создание ПО должно укладываться в бюджет

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

- 60% – разработка;

- 40% – тестирование.

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

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

Создание ПО должно укладываться в сроки

Залог успеха – строгое соблюдение следующих принципов:

- Грамотное планирование.

- Анализ возможных рисков и способы реагирования.

- Борьба за четкие границы проекта.

- Мотивирование сотрудников.

Программные инженеры и научная среда

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

- Новые технологии.

- Новые методы, алгоритмы.

- Анализ новых перспективных разработок.

- Исследовательская работа в смежных областях.

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

- Там, где в принципе не решить задачу своими силами.

- Там, где есть специалисты, но нет времени и ресурсов для исследований.

Этот подход широко применяется современными IT-компаниями: Intel, Microsoft, IBMи другими.

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

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

Понятие процесса

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

Выделяют 4 основных мероприятия (стадии) процесса:

Спецификация: формулирование спецификаций определяет основные требования к ПО (что должна делать система).

Разработка: создание ПО в соответствии со спецификациями.

Аттестация: проверка ПО на соответствие потребностям заказчика.

Модернизация: развитие ПО в соответствии с изменившимися потребностями заказчика.

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

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

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

Существуют известные, хорошо проработанные процессы:Microsoft Solutions Framework (MSF), Rational Unified Process (RUP) и другие.

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

Модели процесса

Итак, некий «каркас» процесса обычно выглядит так:

- Спецификация.

- Разработка.

- Аттестация.

- Модернизация.

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

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