IT в России и мире в реалиях мирового кризиса

ЦитатаМОСКВА, 31 января. /ТАСС/. Институт концерна ВКО "Алмаз-Антей" завершает создание полностью отечественного персонального компьютера (ПК). Об этом сообщили в среду в пресс-службе компании.

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


Подробнее на ТАСС:
http://tass.ru/ekonomika/4919059

Цитата: Danila96 от 01.02.2018 04:24:23Понятно что на клиентских ПК будет очередной клон линукса, потому что с нуля все делать - нереально. А вот серверные решения могут быть и чисто свои, например как разработка "касперский ОС" для роутеров.

Цитата: slavae от 28.01.2018 18:45:24Хочу поделиться статьёй, которая мне очень понравилась. Читал достаточно давно, разослал всем )
Хотя здесь разговор идёт про разработку программ, сами принципы можно прикладывать к чему угодно. Почему статья вспомнилась. На форуме развелось много планировщиков нашего счастливого будущего, но, думаю, на пятом вопросе они скажут ту самую фразу, которая меня так рассмешила: "Не надо, прошу." ))

https://habrahabr.ru…og/344652/

Как правильно чистить лук, или Почему разработка ПО выходит из-под контроля

Скрытый текст

Вы придумали стартап и с самыми лучшими намерениями нанимаете разработчика для реализации своей идеи. Но идет неделя за неделей, а приложение по-прежнему нуждается в доработке. Как-то незаметно появляются новые функции, и масштаб задачи понемногу расширяется.

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



Как так случилось? Может, наняли плохого разработчика? Кто-то ошибся в планировании проекта? А вдруг сама идея проекта была ужасной?

Возможно. Но часто проект бывает с самого начала обречен на провал из-за недопонимания одного важного момента.

Мы предполагаем, что продукт определяется набором функций, записанных на листочке бумаги: иногда что-то добавляется, иногда убирается — но масштаб проекта всегда будто бы можно понять с одного взгляда.

Это предположение — неверно.

Проект — это не лист бумаги, не двумерный объект — у него есть глубина.

Каждую функцию на поверхности можно раскрыть — и так слой за слоем. Будь у меня склонность к громким заголовкам, я бы сказал, что всякое приложение — это лук, и нужно уметь правильно его чистить. Не очень понятно? Тогда давайте я поясню, что имеется в виду, и расскажу, почему не получается раскрывать слои приложения без слёз.

Переведено в Alconost

Наша библиотека — убийца всех библиотек

Рассмотрим конкретный пример. Подкиньте-ка мне идею.

Часто читателям нужна книга, которой нет в ближайшей библиотеке — зато она может быть у кого-то другого неподалеку. Сделаем же приложение, в котором одни люди будут отправлять заявки на книги, а те, у кого такие книги есть, будут отвечать. И с каждой операции будем брать процент.

Гениально.

Я знаю, мне уже об этом говорили. Итак, функционал довольно простой:



Можно отправлять ТЗ разработчику и начинать думать о том, как назвать наш стартап-убийцу: kaBooki? lib.rari.ly? reddit?

Что ж, поехали. Давайте взглянем поближе. (И кстати, «reddit» уже занят.)

Зададим пару вопросов о приложении и посмотрим, куда это нас приведет.

Как пользователи друг другу платят? Они просто передают друг другу наличные при встрече или оплачивают книги через приложение?

Они должны платить карточкой через приложение — так мы сможем снимать комиссию.

Каким образом запрашивается книга? В смысле, что конкретно пользователь делает в приложении? Заполняет открытую форму с названием книги и именем автора?

Хм… Пожалуй, пользователь ищет книгу в приложении и выбирает нужную.

Хорошо, значит, нам нужна база книг.

Ну да.

А что, собственно, представляет собой заявка на книгу? Может, продавцы видят список всех запрашиваемых книг? Или мы отправляем уведомления продавцам — как, например, Uber или Thumbtack?

Как Uber: мы отправляем заявки тем, у кого есть нужная книга.

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

Ага.

Как происходит передача книги? Пользователи отправляют их сами? Или мы занимаемся доставкой?

Доставка — наша забота.

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

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

Значит, мы будем показывать отправителю адрес получателя? Что мы будем делать с расходами на пересылку?

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

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

Ладно, пусть так. Без разницы.

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

Они сами будут договариваться о цене.

Как они будут это делать? В приложении будет встроенный чат?

Они могут просто позвонить друг другу.

Понятно. Так нам нужно подтверждать номера по SMS? А как насчет… впрочем, думаю, вы уже поняли. Я могу продолжать бесконечно.

Не надо, прошу.

Давайте посмотрим, как выглядит список функций теперь:



И каждый пункт можно раскрыть еще по нескольку раз. А мы ведь просто сняли первый слой нашей луковицы — и вот что получилось.

Тише, тише, не надо плакать.

Так что же произошло?

В первую очередь давайте проясним, что не является причиной такого расширения функционала.

Нагромождение ненужного функционала? Нет.

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

Вопросы технической реализации? Тоже нет.

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

Речь не об этом. Хороший разработчик расскажет о самых разных вариантах технической реализации — но он не сможет решить, какие функции вам нужны.

Маркетинговые соображения? Мимо.

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

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

Ага, а еще глобальное потепление и Баба-яга тут тоже ни при чем. Может, назовете причину проблем с этим вашим «луком» или мы будем по одному перебирать все, что причиной не является?

Ай, с вами скучно. Ладно. Поясняю, что произошло.

Мы совершенно неверно представили себе, как обстоят дела со сложностью ПО.

Мы рассчитывали, что сложность отдельной функции представлена ее описанием. Ну правда же: чтобы написать код или что там еще делают программисты, может, и нужно время, но конкретную функцию все-таки можно описать парой слов. «Пользователь делает X с помощью Y». Так?

Нет.

Функционал ПО напоминает скорее фракталы

Чем ближе смотреть, тем больше деталей появляется.

А разве луковица — фрактал?

Не-а, у нас теперь другая метафора.

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

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



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

Создание ПО во многом похоже: чем пристальнее смотреть, тем больше открывается необходимых для решения задачи деталей.

Отлично. Распишите все полностью до самых мелких деталей. Именно это мне и нужно было. Но… так, наверное, мой продукт никогда не выйдет в свет?

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

Впрочем, сложность сама по себе — не проблема. Проблема появляется, когда мы решаем, каким образом эта сложность будет раскрываться. Мы передаем описание функционала разработчику. Через несколько недель у нас есть первая версия приложения, и мы ее проверяем: проходимся по приложению шаг за шагом и замечаем огромные дыры в функционале. Мы записываем замечания, отправляем их разработчику и ждем версии номер два.



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

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

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

А делать нужно так:



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

Решение — гонять по циклу доработки не приложение, а техническое задание.

Мы должны перейти от такой модели:



К вот такой:



Чтобы работа была эффективной, нам понадобится, во-первых, составить каким-то образом список функций, чтобы с ним можно было работать. А во вторых — придумать, каким образом этот список функций можно эффективно исследовать.

Вот об этом мы сейчас и поговорим.

Схема функционирования

Нам придется перестать думать о приложении с точки зрения бизнеса и начать думать как пользователь — именно на этом уровне мы сможем разобраться со сложностью ПО.

Для начала составьте список целей пользователя: для чего пользователи будут заходить в приложение?

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

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

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


Пример простого макета (источник)

Какой бы вариант вы ни выбрали, постарайтесь, чтобы он не замедлял работу: если вы не владеете графическим редактором на «отлично», лучше возьмите в руки карандаш и бумагу.

На схеме должен быть представлен каждый экран приложения. Например, если на каком-то шаге — несколько экранов, разбейте этот шаг: нам ведь нужно как можно больше подробностей.

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

Спрашивайте обо всем

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

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

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

Далее — список вопросов.

Вводимые пользователем данные

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

• Какие данные вводит пользователь?
  


• Ввод данных свободный или интерактивный?
  


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


• Примеры интерактивного ввода: ввод текста в поле поиска, отображающее результаты, из которых можно выбирать, выбор адреса на карте, выбор из заранее определенного набора вариантов.
  


• Могут ли вводимые данные быть неверными? Что приложение должно в этом случае делать?
  


• Используется ли пассивное получение данных? Самый распространенный пример — местоположение пользователя по GPS.
  
  

Какие сведения нужны продукту от нового пользователя? Сможет ли пользователь изменить их позже?

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

Если выше мы говорили о вводе данных, то теперь рассмотрим вывод.

• Какие данные показываются пользователю на конкретном экране?
  


• Как они отображаются? Примеры: текст, изображения, карты, списки, диаграммы.
  


• Нужно ли каким-либо образом упорядочивать данные? Примеры: по новизне, расстоянию от пользователя, релевантности.
  


• Использует ли приложение активную передачу исходящих данных? Примеры: электронные письма, push-уведомления, SMS-сообщения.
  
  

Взаимодействие между компонентами

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

• Взаимодействуют ли пользователи друг с другом? Примеры: обмениваются сообщениями, добавляются в друзья, «лайкают» или помечают тегами материалы других пользователей.
  


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


• Взаимодействует ли продукт с внешними сервисами? Примеры: сервисы поиска местоположения, API прогноза погоды, социальные сети («К нам присоединился ваш друг Х! Загляните к нему на страницу!»).
  
  

Функционал для владельца бизнеса

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

• Нужно ли вам получать оповещения или сводки по электронной почте либо посредством иного средства передачи?
  


• Нужна ли отдельная система для вас или ваших сотрудников? Примеры: водительское приложение для службы доставки, интерфейс управления заказами в реальном времени для кухонного персонала.
  


• Нужен ли интерфейс для ручного утверждения пользователей или их материалов?
  


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

Как-то… многовато вопросов.

Именно! Причем это — самые общие вопросы, о которых часто забывают в начале работы над проектом. Для каждого отдельного продукта по мере работы над ним обязательно появится множество других более конкретных вопросов.

Собираем всё вместе

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

Я-то надеялся, что у вас есть какой-нибудь хитрый прием, который поможет вытащить мой проект. А над этим вот всем, похоже, придется хорошенько поработать.

Конечно. Но на каком-то этапе «это вот всё» так или иначе придется делать.

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

По сути, есть два варианта:

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


2. Можно сразу поставить перед разработчиком задачу сделать приложение, а затем с каждой новой версией постепенно раскрывать все эти нюансы — по одной неделе на каждый «слой». Так вы за несколько месяцев узнаете всё то же, что можно было бы понять за неделю работы с карандашом и бумагой.
   
   

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

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

Избавьте себя от лишних волнений и мук, выпустите свой проект в мир — и пусть он расцветет.

Цитата: Danila96 от 01.02.2018 04:24:23Понятно что на клиентских ПК будет очередной клон линукса, потому что с нуля все делать - нереально. А вот серверные решения могут быть и чисто свои, например как разработка "касперский ОС" для роутеров.

Цитата: adolfus от 03.02.2018 22:16:20"касперский ОС" для роутеров маршрутизаторов – это שиндовс российского разлива со всеми его неизлечимыми проблемами. В маршрутизатораз отлично живет линукс и нет никакого смысла изобретать велосипеды.

Насчет "с нуля" – нельзя просто так взять и засунуть какой-нибудь линукс в комп и сказать, что он "свой". Нужна инфраструктура, подобная той, что у китайского линукса.

Цитата: Поверонов от 03.02.2018 22:48:18Для  начала еще надо бы определиться а ради чего стоит затевать разработку своей ОС. Чтобы сделать еще одно такое же дырявое чудо как современные ОС которые непрерывно нужно патчить по безопасности ( security patch ). Затевать разработку стоит только для придания ОС новых фундаментальных свойств,

Цитата: slavae от 03.02.2018 11:20:31Программа берёт с веб-камеры ваши гримасы и накладывает их на кого угодно

Цитата: Danila96 от 01.02.2018 04:24:231. ПМСМ, нужно развивать отечественное it железо. 
2. Не для того что бы доказать миру "и мы могём".
3. Для гораздо прозаичного - мы в начале развития it сферы.
4. И можно урвать свой кусок перспективного рынка... Банально - продавать свои it решения целиком (софт-железо) многим странам, с гарантией что АНБ/РУМО/ЦРУ гарантированно не имеют в ней закладок
5. Понятно что на клиентских ПК будет очередной клон линукса, потому что с нуля все делать - нереально

Цитата: Поверонов от 03.02.2018 22:48:18Для  начала еще надо бы определиться а ради чего стоит затевать разработку своей ОС

Цитата: TAU от 04.02.2018 20:34:463. Не могу согласиться. У СССР были свои традиции в информационных технологиях. Могу напомнить и троичные компьютеры, и БЭСМ-6, и прообраз персонального компьютера с уникальными характеристиками, коий захотела приобрести корпорация IBM, как только увидела на международной выставке - МИР. А уж в области программно-математического обеспечения у нас признанная в мире своя школа. Так что мы - на определенном витке спирали. Понемногу вылезать начали из глубочайшей ямы, в кою угодили в 1990-х.

Цитата: пОМиДор от 04.02.2018 21:22:55Есть у меня мини опрос.
Кто может сказать что принципиально нового появилось в  IT за последние
1. 5 лет
2. 10 лет
3. 25 лет

Цитата: пОМиДор от 04.02.2018 21:22:55Есть у меня мини опрос.
Кто может сказать что принципиально нового появилось в  IT за последние
1. 5 лет
2. 10 лет
3. 25 лет

Цитата: TAU от 04.02.2018 20:37:35А на этот вопрос давно ответили. И ОС свои создали. Надеюсь, Вы не думаете, что в стратегических ракетах, комплексах ПВО и на атомных подлодках - Linux?

Цитата: Поверонов от 05.02.2018 08:40:561. "облачные" сервисы
2.  смартфоны и таблеты ( в сотни раз увеличили сферу приложений IT )
3.  хотя собственно интернет возник и раньше, но именно  за последние 25 лет
    он от академических текстовых форм транформировался в многоформатный медиа-ресурс:
    фото, видео, фильмы, радио и TV-вещание, телефония

Цитата: TAU от 04.02.2018 20:34:46
******
5. Почему "понятно" и "нереально"? Ничего сверхъестественного и невозможного для наших программистов в создании собственной ОС, своих трансляторов, редакторов и баз данных "с нуля" нет.  Говорю со знанием дела. 

Цитата: Danila96 от 05.02.2018 11:14:54Я предполагал что полноценная ОС, это очень большой, и дорогой, продукт.
Полноценная ОС предполагает наличие продвинутого офисного пакета, а не только "блокнот", работа с внешней периферией, начиная с ЮСБ накопителя, и заканчивая драйверами на разные МФУ, например позволяя сканировать по сети, это и доменные службы и т.д. и т.п.

Цитата: Senya от 05.02.2018 11:37:00Хм. С моей кочки зрения ОС вообще ничего этого не предполагает. Она предполагает обеспечение устойчивого выполнения программных пакетов, наличие функций и интерфейсов для пользовательских программ, ну и её архитектура должна поддерживать написание качественных драйверов для любых устройств, включая файловые системы и сетевые среды.
Всё остальное это продвижение и позиционирование ОС на рынке.
Мысль об ОС, написанной с нуля под современное железо и потребности наверное назрела. Когда я узнал, что вся система безопасности и распределения полномочий *NIX-ов была предназначена исключительно для распределения квот машинного времени между отделами и сотрудниками, а на все прочие задачи её натянули как сову на глобус, я только хмыкнул - мне с ней всё равно не работать. Но рано или поздно лопнет либо сова, либо глобус.

Цитата: Danila96 от 05.02.2018 11:47:34С другой - вот появился на рынке

Цитата: Danila96 от 05.02.2018 11:47:34Тогда появляется другой вопрос - зачем этот гемморой

Цитата: Danila96 от 05.02.2018 11:47:34С одной стороны - таки да.
С другой - вот появился на рынке новый игрок среди ОС, назовем его условно "Руссиан Едишн", и у него ничего нет кроме простейшего ГУИ. Встает вопрос - а как на ней работать? Именно работать, в электронных таблицах, работа с сетевыми файлами и прочее, если ОС этого не предлагает.
То есть нужно как минимум портировать тот же ООфис.
Потом отлавливать баги, тестировать, содержать сотрудников "хелп деска".
Тогда появляется другой вопрос - зачем этот гемморой, если можно попросту переписать линукс под свои реалии с меньшими заморочками?