Постоянная интеграция и  постепенное добавление программного кода весьма полезны в определенных обстоятельствах, особенно в поздних  частях проекта, и напоминают технологию «синхронизация и стабилизация» корпорации Microsoft.

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

Принятие решений с помощью  отбраковки

Во время выполнения проекта  часто возникает перегрузка. Например, список пожеланий «что нужно сделать» разбухает очень быстро и кажется, что может разрастаться безгранично. Обычный путь борьбы с этим явлением — устанавливать приоритеты. Однако на этом идеальном пути также очень быстро возникает перегрузка. Например, в списке «что нужно сделать» имеется 100 пунктов, а время есть только на выполнение 20 из них. Тогда упорядочивание по приоритету всех 100 пунктов — пустая трата времени. Для решения этой проблемы можно использовать отбраковку.

Суть метода отбраковки состоит  в том, чтобы любой вопрос анализировать  не более чем два раза. После  этого мы занимаемся только пунктами из категории Немедленно. Если (если!) они все будут выполнены, то переходим к рассмотрению категории Обычное, и т. д. Если угодно, пункты можно расставить по приоритетам внутри категорий. Таким образом, мы не теряем время на определение точного порядка действий, которые никогда не будем выполнять. По данным «Business Week» [19], такой прием обработки сообщений о найденных ошибках использовался в Microsoft во время отладки Windows 2000. Принцип метода отбраковки:

IF принадлежит к числу наиболее важных

     поместить в категорию НЕМЕДЛЕННО

ELSE

      IF можно проигнорировать, не меняя существенно проект,

           поместить в категорию В ПОСЛЕДНЮЮ ОЧЕРЕДЬ

      ELSE

           поместить в категорию ОБЫЧНОЕ

3. Типы ПО: автономное, встроенное, реального времени, сетевое.

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

1. Автономное:

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

2. Встроенное:

• часть уникального приложения с привлечением аппаратного обеспечения;
• пример — автомобильный контроллер.

3. Реального времени:

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

4. Сетевое:

• состоит из частей, взаимодействующих через сеть;
• пример основанная на веб-технологии видеоигра.

4. Распределённые команды, экстремальное  программирование. Метод отбраковки.

смотри вопрос 2

5. Исторический и современный взгляд  на разработку ПО. Влияние структурного и объектно-ориентированного программирования.

Разработка программного обеспечения является очень молодой  и быстро развивающейся отраслью инженерной науки. Она подвержена постоянным и быстрым изменениям. Так, всего  лишь в начале 90-х годов Британское сообщество вычислительной техники (British Computer Ѕосіеtу) начало присваивать разработчикам программ звание инженера (Chartered Engineer), а в Соединенных Штатах только в 1998 году стало возможным хоть где-то (а точнее, в штате Техас) зарегистрироваться в качестве профессионального инженера программного обеспечения. Но по-прежнему, даже в начале двадцать первого века, общепризнанным остается тот факт, что разработке программного обеспечения не достает достаточно развитой научной базы. По некоторым оценкам, 75 % организаций, занимающихся разработкой программ, делают это на примитивном уровне. С другой стороны, в этой области сформировалось немало интересных идей, и мы надеемся, что знакомство с ними в рамках настоящей книги вдохновит читателя на собственное исследование.

Влияние структурного и объектно-ориентированного программирования.

С момента зарождения технология разработки программ испытала несколько  подъемов в своем развитии. Один из них связан с публикацией письма Эдсгера Дийкстры (Edsger Dijkstra) в Ассоциацию вычислительной техники (ACM — Association for Computing Machinery), озаглавленного так: "О вреде использования операторов GOTO". В те времена программы писались с активным использованием операторов безусловного перехода. Обращая внимание на недостатки таких программ, Дийкстра предложил концепцию структурного программирования, позволяющую избежать использования этих операторов. Концепция Дийкстры основывалась на том наблюдении Бема и Якопини, что для записи любой программы в принципе достаточно только трех конструкций управления — последовательного выполнения, ветвления и цикла, то есть что теоретически необходимость в использовании операторов перехода отсутствует.

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

Нисходящее структурное  программирование стало само собой  разумеющимся стилем написания программ, и без него вряд ли был бы возможен прогресс в области разработки программного обеспечения. Однако структурным программам в таком виде недоставало одного важного свойства — в их структуре непосредственно не отображались сущности предметной области, и из-за этого программы было трудно модифицировать в условиях изменяющихся требований. Позднее в связи с этим возникла парадигма объектной ориентированности (OO), которая основана на использовании объектов, объединяющих в себе данные и функциональность. Объектно-ориентированную парадигму иллюстрирует рис. 1.3 на примере отображения в программе понятий "заказчик" и "счет". Помещая каждый функциональный элемент в соответствующий класс, мы значительно облегчаем процесс проектирования и сопровождения программ.

На объектно-ориентированной парадигме основаны современные языки и системы программирования, такие как Java и CORBA. Отметим, что CORBA позволяет приложениям использовать функции, написанные на различных языках, и выполнять их на различных платформах. В качестве примера в этом же контексте можно упомянуть Visual Basic и рассматриваемую в следующем разделе модель COM фирмы Microsoft.

В этой книге предполагается, что читатель владеет методами объектно-ориентированного программирования.

Повторное использование компонентов

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

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

На уровне проектирования и реализации повторное использование программных кодов упрощается благодаря появлению таких стандартов, как COM (Component Object Model) и Java Beans. СОМ-объекты являются примером инструмента модульного программирования. Идею СОМ-объектов иллюстрирует рис. 1.4. СОМ-объект Счет — это фактически исполняемый модуль среды Windows, который может быть динамически использован любым другим приложением Windows. Этот объект поддерживает три интерфейса. В частности, он поддерживает интерфейс Identification, то есть в этом объекте имеется, например, функция setNameC...) и т. п. Основная идея состоит в том, что объект Счет может быть использован сколь угодно часто, так как мы знаем, для чего он предназначен. Заметим, что одни СОМ-объекты могут строиться из других СОМ-объектов и могут представлять довольно большие сущности, как, например, делая электронная таблица.

6. Анализ требований. С- и D-требования. Описание требований. Приоритет и контроль требований.

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

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

Вообще говоря, следующее  выражение (N) не является требованием для приложения.

Балансы счетов клиентов будут храниться  в таблице под названием «балансы» в базе данных Access.

Второе выражение касается того, как должно быть построено приложение, а не того, что это приложение должно делать.

Требование на одном уровне часто переходит в одно или  несколько конкретных требований на следующем, более подробном уровне. Чтобы понять это, представьте себе, что ваше требование для будущего дома — «видеть горы на 180 градусов вокруг». Это требование может перейти в утверждение, что «терраса справа должна иметь размеры 20 х 50 футов». Это более конкретное требование на более детальном уровне. Аналогично, утверждение (N) действительно может стать требованием на последующих уровнях процесса разработки.

Более того, встречаются исключения из правила, запрещающего специфицировать в требованиях, как должно работать приложение. Например, у заказчика могут быть особые причины потребовать, чтобы балансы счетов хранились в базе данных Access с конкретным именем, и тогда утверждение (N) действительно становится требованием.

Результатом анализа требований является документ, который обычно называют спецификацией требований, или спецификацией требований к программному обеспечению (SRS — Software Requirements Specification).

С-требования и D-требования

В течение некоторого времени  проходили дебаты относительно того, кому «принадлежат» требования: заказчику или разработчикам. Для решения этого вопроса мы разделяем анализ требований на два уровня. Первый уровень документирует желания и потребности заказчика и пишется на языке, понятном заказчику. Результаты иногда называют требованиями заказчика, или С-требованиями. Первичной аудиторией для С-требований будет сообщество заказчиков, а уже вторичной — сообщество разработчиков. Второй уровень документирует требования в специальной, структурированной форме. Эти документы называются требованиями разработчика, или D-требованиями. Первичной аудиторией для D-требований будет сообщество разработчиков, а уже вторичной — сообщество заказчиков.

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

Требования разработчика:

1 Ответ на требования  клиента, в котором детально  описывается, что должен предоставить  клиент.

2 Требования к аппаратно-программной  базе.

Требования разработчика включаются в ТЗ системы.

Требования заказчика:

1 К интерфейсу – внешний вид, цветовая гамма, стиль оформления.

2 Приблизительные ожидания  клиента от режима режима работы.

3 Функциональная нагрузка

 

7. Роли и артефакты. Требования  к процессу, проекту, продукту  и персоналу.

Требования к процессу, проекту, продукту и персоналу.

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

В современной практике разработки программного обеспечения существует пять ключевых требований, в основном сформулированных Хэмфри (рис. 1.5). Первое из них — заранее выбрать свою шкалу измерения качества для  проекта и продукта.

1 Например, «500 строк полностью протестированного программного кода, написанного одним человеком за месяц» или «не более трех ошибок на тысячу строк программного кода».