Т.е. голод таки наступил, мало того усилился. Получается говорить об эффективном планировании и управлении ресурсами не приходится.

Анна, Вы правы!
что-то у меня с памятью... :)
слово "extended" упустил... :)
 
The SAP HANA software is available in these editions:
- SAP HANA platform edition
This is the basic edition containing the software stack needed to use SAP HANA as a database, including the SAP HANA database, SAP HANA Studio for data modeling and administration, the SAP HANA clients, and software
infrastructure components. The software stack comes with the hardware provided by the hardware partners; whereas, the license has to be obtained from SAP.
- SAP HANA enterprise edition
The SAP HANA enterprise edition extends the SAP HANA platform edition with the software licenses needed for SAP Landscape Transformation replication, ETL-based replication using SAP BusinessObjects Data Services,
and Extractor-based replication with Direct Extractor Connection.
- SAP HANA extended enterprise edition
SAP HANA extended enterprise edition extends the SAP HANA platform edition with the software licenses needed for log-based replication with the Sybase Replication server.
- SAP HANA database edition for SAP NetWeaver BW
This edition is restricted to be used as the primary database for an SAP NetWeaver BW system. Any access to the SAP HANA database must take place through the BW system.

Конечно же это самый дорогой метод разработки. Зачастую для большинства бизнес-приложений такой подход не требуется, как и не требуется разрабатываемый функционал - актуальность задачи теряется сразу же после ее реализации или меняется в ходе реализации. Нужен в случае контрактных обязательств сторон, экспертной оценке или согласования службами, комплексной оценке с точки зрения архитектуры системы и пр. глобальных бизнес и технических согласований. И обратная сторона медали - программист обнаруживший неточночность в ТЗ или ошибку, при таком правильном подходе, не должен продолжать работу, а отправить ТЗ на переделку и согласование. И третье, если в компании нет службы типа QA (Quality Assurance), которая бы следила за качеством кода в том числе и на соответствие ТЗ, и аналитик и программист, когда поджимают сроки, договоряться между собой и выдадут третий вариант реализации.

Евгений, в HANA EE не входит Sybase Replication Server. Входят Data Services и SAP Landscape Transformation.

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

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

Согласен, утопия.
Уж и помечтать нельзя? :)

Здравствуйте.
Добавлю свои пять копеек, главное помнить что метод жизненого цикла создания программа "водопад" не единственный и не всегда приемлем. Есть и другие подходы не требующие написания ТЗ в принципе. По большому счету во многих проектах применяются вариации данных жизненных циклов. Но так как народ этого не знает, то и не доводят до конца, не применяют проработанных методик.
Я считаю, что прежде чем приступить к регламентации процесса разработки стоит ознакомится с мировыми практиками, а не придумывать, что-то на коленке, а потом наступать на одни и те же грабли в 100 раз.
 
З.Ы.
Не надо думать, что с проблемами разработки программ мы столкнулись впервые и ни кто больше этого не делал.

в комплект SAP HANA Enterprise Edition входит Sybase Replication Server. основная нагрузка на создание теневых инстансов лежит на нем? или применяются инструменты от производителя аппаратной платформы?

Статья написана с точки зрения программиста. Прокомментирую с т.з. консультанта.
Несколько раз я пытался писать спеки подробно, как написано в статье. И что же? В большинстве случаев сталкивался с тем, что абапер некоторые алгоритмы менял (как ему проще), а что-то вообще пропускал. В итоге все сводилось к тому, что я открывал код программы и либо сам менял, либо пытался на пальцах объяснять что требуется.
Короче говоря, все сводится к профессионализму программиста. Если толковый, то все будет хорошо, если же "зеленый", то хоть как описывай в ТЗ - все равно придется сидеть и тыкать в экран.
 
Хочу упомянуть еще и о взаимодействии с абапером. Рекомендую такой стиль: лучше разбить разработку на части. Кусок программы написал, давай посмотрим, что сделано и как - по ходу исправляем ошибки.
Просто зачастую бывает так: абапер получает ТЗ, полностью его выполняет, как сам понимает, а потом выдает тебе "Я сделал", после чего понимаешь, что реализовано совсем не так, как надо. Отсюда огромные потери во времени.

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

Из SAP HANA Studio можно редактировать код нескольких систем?

Извините но вы путаете замещения и технологию BTE, это несколько разные техники.