Введение в разработку крупномасштабных программных систем (Large-Scale Software).

• Процесс разработки программного обеспечения
• Определение и пересмотр задачи
• Планирование решения задачи
• Кодирование решения
• Общая оценка и тестирование

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

Когда измеряются затраты на разработку (всего часов), то оказывается, что написание кода программы — это относительно незначительная часть процесса создания программного обеспечения. Для нетривиальных программ, особенно крупномасштабного коммерческого программного обеспечения, программист не может только сидеть и писать коды программ. Вместо этого, каждый, вовлеченный в создание программного обеспечения, должен разделять понимание того, что должно делать программное обеспечение и из чего оно состоит. Процесс создания программного обеспечения начинается с определения потребности и проходит через серию фаз разработки, ведущих к поставке и использованию. Однако, детали того, как происходит этот процесс еще далеки от полного понимания и часто они являются объектом споров, а также темами многочисленных международных конференций. На практике процесс разработки редко устойчив и редко легко управляем. Половина всех проектов программного обеспечения отменяются до завершения, и большинство из тех, которые завершены, не удовлетворяют требованиям, указанным пользователями. Фактически, "разработка программного обеспечения" — одна из самых быстро растущих областей профессиональных интересов в содружестве программного обеспечения. Мы представляли процесс разработки в первом курсе программы SSD (Software Systems Development), SSD1 Введение в Информационные Системы. Был представлен следующий процесс программирования:

1. Определение и пересмотр задачи (Define or redefine the problem)
2. . Планирование решения задачи (Plan a solution to the problem)
3. . Кодирование (Code the solution)
4. Общая оценка и тестирование (Evaluate and test everything)

Ниже рисунок модели.

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

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

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

Определение и переопределение задачи

1. Осознание потребности (в программном продукте): возможно всеобщее понимание потребности, возможно пришедшее вследствие маркетинга или менеджмента, возможно источником является техническая группа, или потребность в разработке определяется контрактом.
2. Спецификация (функциональные требования): это процесс опроса заинтересо­ванных сторон о требованиях к системе программного обеспечения. Хорошо сделать несколько циклов и протестировать предложения, сфокусировавшись на группе непосредственных пользователей.

Планирование решения задачи

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

Кодирование решения

1. 
   Реализация решения: программисты кодируют систему на выбранном языке или языках. Решения определяются на фазе дизайна (например, интерфейсы и исполнение), но детали того, как части системы будут то, что они должны делать, зависят от программиста.
2. .
   Тестирование решения программистом: Сначала программист исследует программу на корректность. На следующем уровне, команды разработчиков встречается на сессиях обзора кода (code review sessions) для чтения и обсуждения работы. Полное тестирование проводиться руководителями проекта.
3. 
   Прием системы: Дополнительная группа некоторое время работает с программным обеспечением со смоделированными или реальными установками. Прием системы может быть достаточно формальным или неожиданно не формальным.

Общая оценка и тестирование

1. 
   Тестирование в среде: на рабочих системах еще долго могут выявляться дефекты, упущенные на предыдущих тестах. Дефекты разработки и принятых решений также еще будут выявляться на этой стадии. Хорошие системы чаще требуют изменений чем плохие: как только люди чувствуют, что используют хорошее программное обеспечение, у них появляются идеи о дополнительных возможностях, которые они хотели бы иметь.
2. Модернизация: Теперь начинается модернизация с возврата к первому шагу процесса.

Модель открытого кода

Пока вы работаете с Microsoft, вы не можете читать исходный код операционной системы Windows. Но, вы можете читать исходный код для операционной системы Linux, делать ее копии, даже бесплатно передавать ее. Linux – пример проекта программного обеспечения с открытым кодом (open source).

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

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

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

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

Бесплатное программное обеспечение

Термин бесплатное программное обеспечение (free software) было введено Ричардом Стэллманом (Richard M. Stallman), основателем Free Software Foundation. Стэллман писал:

«Бесплатное программное обеспечение» означает свободу, без оплаты. В этой концепции, «бесплатный» означает — «бесплатное слово», но не «бесплатное пиво».

Термин «открытый код» представили в связи с неправильным пониманием употребления слова «бесплатный» (free). Концепции открытого кода и бесплатного программного обеспечения имеют много общего, но есть несколько философских различий.

Бесплатное программное обеспечение может использоваться для любой цели, копироваться, изменяться и передаваться по желанию. Для того, чтобы гарантировать сохранение всех этих свобод во всех копиях и версиях, программное обеспечение защищено лицензией. Были предложены различные виды бесплатных лицензий на программное обеспечение. Одна из них называется законная левая копия (copy left), в отличие от "авторского права" (copyright). Другая известна как GPL, для Общедоступная лицензия (General Public License). Лицензии отличаются техническими пунктами, но в основном, они предполагают, что люди, делающие копии программного обеспечения, должны сохранить лицензию. Они должны распространять источник наряду с объектным кодом, и они должны позволить другим делать копии. Если они изменяют программное обеспечение, они должны сделать свои изменения общедоступными с теми же ограничениями лицензии. Поэтому, никто не может взять часть бесплатного программного обеспечения и превратить его в программу закрытым кодом, потому что лицензия препятствует этому.

Не нашли, что искали? Воспользуйтесь поиском по сайту: