Рубрика «проектирование» - 30

Данная статья является третьей частью и продолжает рассмотрение ГОСТов 34й серии (часть 1, часть 2)

Теперь пришло время поговорить о шестой стадии разработки АС, а именно о стадии «Рабочая документация». Что же это за стадия такая? Как я заметил ранее во второй части, эта стадия настолько близка к стадии «Технический проект», что даже ГОСТ 34.601-90 при всей своей строгости допускает объединение этих стадий в одну «Техно-рабочий проект». В чем же между ними разница? Разница достаточно очевидная (как и родство): если на стадии «Технический проект» мы готовили комплект документов именно на проект АС как таковой, то на стадии «Рабочая документация» мы готовим комплект документов необходимых непосредственно для внедрения АС на конкретной площадке.
Читать полностью »

После появления статей типа "Я не знаю ООП" — возникает желание внести ясность, «сорвать покровы» и «докопаться до истины».

Принципы объектно-ориентированности

Обычно выделяют (читай: на собеседовании требуют назвать) четыре «принципа объектно-ориентированного программирования»: абстракцию, инкапсуляцию, наследование и полиморфизм.

На мой взгляд (не говоря о том, что абстракция и полиморфизм могут быть запросто отнесены к подразделам наследования), принцип тут один, в общем, тот же самый, что при проектировании баз данных: представление всего в виде объекта — некоторой штуковины со свойствами. Набор обычно бывает фиксированным, и тогда говорят о классе объектов, а даже если понятия класса и нет, то наличие свойств с определёнными названиями подразумевается логикой программы, т.е. нечто типа класса в виде некоего минимального набора свойств всё равно присутствует. В общем, воззрения восходят к давнему С-шному/паскалевскому типу данных struct/record. Потом к этому добавили немного «функциональности» (в смысле функционального программирования): значением свойства может быть функция, причём такая, которая имеет доступ к самой структуре/записи, значением одного из свойств которой она является. Сей феномен, в лучших традициях немецкого латиноязычного нейминга (когда опция называется «вариантом», а степень числа — «потенцией»), назвали «методом». Желание повторно использовать код, в сочетании с представлением каждого предмета как некоего подобия паскалевской «записи», привело к появлению концепции «наследования».Читать полностью »

Эта статья является продолжением моей статьи «ГОСТ 34-й серии для сисадминов, начинающих фрилансеров и всех заинтересованных». Продолжим наш разговор о советских ГОСТах 34й серии и чем они могут помочь в нелегкой работе над проектами.
Читать полностью »

image

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

Но для начала небольшое лирическое отступление. А вы чего хотели?

Работаю я в Обнинской/Калужской региональной редакции газеты «Из рук в руки», и должность моя — «сервис-менеджер». Но, по сути, я исполняю обязанности не только сервис-менеджера, но и быдлокодера Delphi и 1С (назвать себя программистом, пока что, язык не поворачивается). На эту работу я устроился примерно полгода назад, когда еще учился в техникуме. И так получилось, что я пришел туда в такой период, когда у руководства уже были идеи по улучшению рабочего процесса, но еще не было рук, которые бы этим занялись. Для начала мне дали задание написать конвертер для газетных объявлений, который бы менял их формат так, чтобы их можно было загружать на сайт, а то операторам не улыбается вручную парсить мегатонны строк в блокноте. Задание было успешно выполнено, после чего меня оформили, и выделили деньги для покупки Delphi XE2 Professional мне на новое рабочее место (да, у нас директор и сисадмин в одном лице, поэтому они быстро друг с другом договариваются, когда появляется необходимость закупить софт или хард). И когда я уже был в штате, мне доверили заняться инновацией — программой для составления объявлений. А тут начинается самое интересное…

Кому интересно, прошу под кат.

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

Читать полностью »

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

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

Читать полностью »

На самом деле правильнее было бы назвать «машинное зрение», но так я думаю понятнее будет, если кто не знает то это не охранное видеонаблюдение, а распознавание или измерение чего либо c помощью камер. Существует много задач и областей, где компьютерное зрение было бы очень востребовано и могло бы использоваться повсеместно, но на практике оно используется очень редко.

Я реализовал несколько проектов в этой области для решения разных задач, конкретно это вычисление и подсчет площадей, контроль качества продукции, причем разной и в разных отраслях таких как: фигурная порезка и раскрой листов ДСП, ДВП, МДФ, измерение площадей шкурок животных на производства изделий из кожи и др.

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

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

Эпиграф: Верблюд — это лошадь, сделанная по всем требованиям заказчика.

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

Опытные и слаженные команды в России есть, а вот методологии управления требованиями — единой, прозрачной и удобной в использовании — до сих пор нет. Даже в одной организации от проекта к проекту меняются инструменты и методы управления требованиями, роли участников процесса, и, как следствие, нашим организациям не хватает «зрелости» — гарантии повторяемости проектных процедур со стабильно высоким качеством выдаваемых результатов.
Читать полностью »

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

Читать полностью »

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

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

Есть и другая крайность, когда команда можем потратить недели в поисках идеального решения (Святого Грааля архитектора), когда дизайн будет способен «расширяться» во всех возможных направлениях, и быть настолько «гибким», что реализовать его не будет никакой возможности.
Читать полностью »

Автор рассказывает о перипетиях пивоваров, производителей СУБД, себя и кратко о том как правильно проектировать приложения. Мне показалась полезной поучительная часть статьи.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js