Главная » Просмотр файлов » Бьерн Страуструп

Бьерн Страуструп (947334), страница 62

Файл №947334 Бьерн Страуструп (Стpаустpуп - Книга о C++) 62 страницаБьерн Страуструп (947334) страница 622013-09-15СтудИзба
Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 62)

Здесь основная трудность для менеджера или разработчика или

программиста в том, чтобы создать такой порядок в этом процессе,

который не препятствует усовершенствованиям и не запрещает повторные

проходы, необходимые для успешного развития.

У процесса развития три стадии:

- Анализ: определение области задачи.

- Проектирование: создание общей структуры системы.

- Реализация: программирование и тестирование.

Не забудьте об итеративной природе этих процессов (неспроста стадии

не были пронумерованы), и заметьте, что никакие важные аспекты процесса

развития программы не выделяются в отдельные стадии, поскольку они

должны допускать:

- Экспериментирование.

- Тестирование.

- Анализ проектирования и реализации.

- Документирование.

- Сопровождение.

Сопровождение программного обеспечения рассматривается просто как

еще несколько проходов по стадиям процесса развития (см. также

$$11.3.6).

Очень важно, чтобы анализ, проектирование и реализация не были

слишком оторваны друг от друга, и чтобы люди, принимающие в них

участие, были одного уровня квалификации для налаживания эффективных

контактов.

В больших проектах слишком часто бывает иначе. В идеале, в процессе

развития проекта работники должны сами переходить с одной стадии на

другую: лучший способ передачи тонкой информации - это использовать

голову работника. К сожалению, в организациях часто устанавливают

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

более высокий статус и (или) более высокий оклад, чем у "простого"

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

набраться опыта и знаний, но пусть, по крайней мере, будут

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

Для средних и малых проектов обычно не делают различия между

анализом и проектированием - эти стадии сливаются в одну. Для малых

проектов также не разделяют проектирование и программирование.

Конечно, тем самым решается проблема взаимодействия. Для данного

проекта важно найти подходящую степень формализации и выдержать

нужную степень разделения между стадиями ($$11.4.2). Нет единственно

верного способа для этого.

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

радикально отличается от традиционной модели "каскад" (waterfall).

В последней процесс развития протекает линейно от стадии анализа до

стадии тестирования. Основной недостаток модели каскад тот, что в ней

информация движется только в одном направлении. Если выявлена

проблема "ниже по течению", то возникает сильное методологическое

и организационное давление, чтобы решить проблему на данном уровне,

не затрагивая предыдущих стадий процесса. Отсутствие повторных

проходов приводит к дефектному проекту, а в результате локального

устранения проблем получается искаженная реализация. В тех

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

источнику ее получения и вызвать изменения в проекте, мы получим

лишь слабое "колыхание" на всех уровнях системы, стремящейся подавить

внесенное изменение, а значит система плохо приспособлена к

изменениям. Аргумент в пользу "никаких изменений" или "только локальные

изменения" часто сводится к тому, что один отдел не хочет

перекладывать большую работу на другой отдел "ради их же блага".

Часто бывает так, что ко времени, когда ошибка уже найдена, исписано

столько бумаги относительно ошибочного решения, что усилия,

нужные на исправление документации, затмевают усилия для исправления

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

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

и возникают в процессе развития больших систем. В конце концов,

определенная работа с бумагами необходима. Но выбор линейной модели

развития (каскад) многократно увеличивает вероятность, что эта

проблема выйдет из-под контроля.

Недостаток модели каскад в отсутствии повторных проходов и

неспособности реагировать на изменения. Опасность предлагаемой здесь

итеративной модели состоит в искушении заменить размышление и

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

Тот и другой недостатки легче указать, чем устранить, и для того,

кто организует работу, легко принять простую активность за реальный

прогресс.

Вы можете уделять пристальное внимание деталям, использовать

разумные приемы управления, развитую технологию, но ничто не спасет

вас, если нет ясного понимания того, что вы пытаетесь создать. Больше

всего проектов проваливалось именно из-за отсутствия хорошо

сформулированных реалистичных целей, а не по какой-либо иной причине.

Что бы вы не делали и чем бы не занимались, надо ясно представлять

имеющиеся у вас средства, ставить достижимые цели и ориентиры и не

искать технических решений социологических проблем. С другой стороны,

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

затрат,- люди работают лучше, имея адекватные средства и приемлемую

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

11.3.1 Цикл развития

Процесс развития системы - это итеративная деятельность. Основной

цикл сводится к повторяемым в следующей последовательности шагам:

[1] Создать общее описание проекта.

[2] Выделить стандартные компоненты.

[a] Подогнать компоненты под данный проект.

[3] Создать новые стандартные компоненты.

[a] Подогнать компоненты под данный проект.

[4] Составить уточненное описание проекта.

В качестве примера рассмотрим автомобильный завод. Проект должен

начинаться с самого общего описания новой машины. Этот первый шаг

базируется на некотором анализе и описании машины в самых общих

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

чем к характеристикам желаемых возможностей машины. Часто самой

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

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

возможностей. Удача здесь, как правило, является

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

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

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

проваливающимся проектам.

Итак, допустим необходимо создать машину среднего размера с

четырьмя дверцами и достаточно мощным мотором. Очевидно, что

на первом этапе проекта не следует начинать проектирование машины

(и всех ее компонентов) с нуля. Хотя программист или разработчик

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

так.

На первом этапе надо выяснить, какие компоненты доступны на

вашем собственном складе и какие можно получить от надежных

поставщиков. Найденные таким образом компоненты не обязательно

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

компонентов. Может быть даже потребуется изменить характеристики

"следующей версии" выбранных компонентов, чтобы сделать их

пригодными для проекта. Например, может существовать вполне пригодный

мотор, вырабатывающий немного меньшую мощность.Тогда

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

описания проекта, в качестве компенсации дополнительный

зарядный генератор. Заметим, что сделать это,"не изменяя общего описания

проекта", маловероятно, если только само описание не приспособлено

к определенной подгонке. Обычно подобная

подгонка требует кооперации между вами и поставщиком моторов.

Сходные вопросы возникают и у программиста или разработчика

программного обеспечения. Здесь подгонку обычно облегчает эффективное

использование производных классов. Но не рассчитывайте провести

произвольные расширения в проекте без определенного предвидения

или кооперации с создателем таких классов.

Когда исчерпается набор подходящих стандартных компонентов,

проектировщик машины не спешит заняться проектированием новых

оптимальных компонентов для своей машины. Это было бы слишком

расточительно. Допустим, что не нашлось подходящего блока

кондиционирования воздуха, зато есть свободное пространство, имеющее

форму буквы L, в моторном отсеке. Возможно решение разработать

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

блок подобной странной формы будет использоваться в машинах другого

типа (даже после значительной подгонки), крайне низка. Это означает,

что наш проектировщик машины не сможет разделить затраты на

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

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

который найдет более широкое применение, т.е. разработать

разумный проект блока, более приспособленный для подгонки, чем наше

L-образное чудище. Возможно, это потребует больших усилий, и даже

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

общее описание проекта машины. Поскольку новый блок разрабатывался

для более общего применения, чем наше L-образное чудище,

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

полностью удовлетворить наши пересмотренные запросы.

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

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

привязанную к конкретному проекту, разработчик может спроектировать

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

хорошие шансы стать стандартной в определенной области.

Наконец, когда мы прошлись по всем стандартным компонентам,

составляется "окончательное" общее описание проекта. Несколько

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

в следующем году придется для новой модели повторить наши шаги,

и как раз эти специальные средства придется переделать или выбросить.

Как ни печально, но опыт традиционно проектировавшихся программ

показывает, что лишь несколько частей системы можно выделить в

отдельные компоненты и лишь несколько из них пригодны вне

данного проекта.

Мы не пытаемся утверждать, что все разработчики машин

действуют столь разумно, как в приведенном примере, а разработчики

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

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

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

Тем не менее можно сказать, что сама природа программирования

способствует совершению указанных ошибок ($$12.2.1 и $$12.2.5).

В разделе 11.4.3 опровергается профессиональное предубеждение против

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

Заметим, что модель развития программного обеспечения хорошо

применима только в расчете на большие сроки. Если ваш горизонт

сужается до времени выдачи очередной версии, нет смысла создавать

и поддерживать функционирование стандартных компонентов. Это

просто приведет к излишним накладным расходам. Наша модель

рассчитана на организации со временем жизни, за которое проходит

несколько проектов, и с размерами, которые позволяют нести

дополнительные расходы и на средства проектирования, программирования,

и на сопровождение проектов, и на повышение квалификации разработчиков,

программистов и менеджеров. Фактически это эскиз некоторой фабрики по

производству программ. Как ни удивительно, она только масштабом

отличается от действий лучших программистов, которые для повышения своей

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

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

большинство организаций просто не умеет воспользоваться достижениями

лучших сотрудников, как из-за отсутствия предвидения, так и по

неспособности применить эти достижения в достаточно широком

объеме.

Все-таки неразумно требовать, чтобы "стандартные компоненты"

были стандартными универсально. Существует лишь малое число

международных стандартных библиотек, а в своем большинстве компоненты

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

производственной цепочки, отдела или области приложения и т.д.

Просто мир слишком велик, чтобы универсальный стандарт

всех компонентов и средств был реальной или желанной целью проекта.

11.3.2 Цели проектирования

Каковы самые общие цели проектирования? Конечно, простота, но в чем

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

во времени, т.е. система будет расширяться, переноситься,

настраиваться и, вообще, изменяться массой способов, которые невозможно

Характеристики

Тип файла
Документ
Размер
4,26 Mb
Тип материала
Учебное заведение
Неизвестно

Список файлов книги

Свежие статьи
Популярно сейчас
Почему делать на заказ в разы дороже, чем купить готовую учебную работу на СтудИзбе? Наши учебные работы продаются каждый год, тогда как большинство заказов выполняются с нуля. Найдите подходящий учебный материал на СтудИзбе!
Ответы на популярные вопросы
Да! Наши авторы собирают и выкладывают те работы, которые сдаются в Вашем учебном заведении ежегодно и уже проверены преподавателями.
Да! У нас любой человек может выложить любую учебную работу и зарабатывать на её продажах! Но каждый учебный материал публикуется только после тщательной проверки администрацией.
Вернём деньги! А если быть более точными, то автору даётся немного времени на исправление, а если не исправит или выйдет время, то вернём деньги в полном объёме!
Да! На равне с готовыми студенческими работами у нас продаются услуги. Цены на услуги видны сразу, то есть Вам нужно только указать параметры и сразу можно оплачивать.
Отзывы студентов
Ставлю 10/10
Все нравится, очень удобный сайт, помогает в учебе. Кроме этого, можно заработать самому, выставляя готовые учебные материалы на продажу здесь. Рейтинги и отзывы на преподавателей очень помогают сориентироваться в начале нового семестра. Спасибо за такую функцию. Ставлю максимальную оценку.
Лучшая платформа для успешной сдачи сессии
Познакомился со СтудИзбой благодаря своему другу, очень нравится интерфейс, количество доступных файлов, цена, в общем, все прекрасно. Даже сам продаю какие-то свои работы.
Студизба ван лав ❤
Очень офигенный сайт для студентов. Много полезных учебных материалов. Пользуюсь студизбой с октября 2021 года. Серьёзных нареканий нет. Хотелось бы, что бы ввели подписочную модель и сделали материалы дешевле 300 рублей в рамках подписки бесплатными.
Отличный сайт
Лично меня всё устраивает - и покупка, и продажа; и цены, и возможность предпросмотра куска файла, и обилие бесплатных файлов (в подборках по авторам, читай, ВУЗам и факультетам). Есть определённые баги, но всё решаемо, да и администраторы реагируют в течение суток.
Маленький отзыв о большом помощнике!
Студизба спасает в те моменты, когда сроки горят, а работ накопилось достаточно. Довольно удобный сайт с простой навигацией и огромным количеством материалов.
Студ. Изба как крупнейший сборник работ для студентов
Тут дофига бывает всего полезного. Печально, что бывают предметы по которым даже одного бесплатного решения нет, но это скорее вопрос к студентам. В остальном всё здорово.
Спасательный островок
Если уже не успеваешь разобраться или застрял на каком-то задание поможет тебе быстро и недорого решить твою проблему.
Всё и так отлично
Всё очень удобно. Особенно круто, что есть система бонусов и можно выводить остатки денег. Очень много качественных бесплатных файлов.
Отзыв о системе "Студизба"
Отличная платформа для распространения работ, востребованных студентами. Хорошо налаженная и качественная работа сайта, огромная база заданий и аудитория.
Отличный помощник
Отличный сайт с кучей полезных файлов, позволяющий найти много методичек / учебников / отзывов о вузах и преподователях.
Отлично помогает студентам в любой момент для решения трудных и незамедлительных задач
Хотелось бы больше конкретной информации о преподавателях. А так в принципе хороший сайт, всегда им пользуюсь и ни разу не было желания прекратить. Хороший сайт для помощи студентам, удобный и приятный интерфейс. Из недостатков можно выделить только отсутствия небольшого количества файлов.
Спасибо за шикарный сайт
Великолепный сайт на котором студент за не большие деньги может найти помощь с дз, проектами курсовыми, лабораторными, а также узнать отзывы на преподавателей и бесплатно скачать пособия.
Популярные преподаватели
Добавляйте материалы
и зарабатывайте!
Продажи идут автоматически
6518
Авторов
на СтудИзбе
302
Средний доход
с одного платного файла
Обучение Подробнее