что такое проект в программировании

Программный проект

Проектирование программного обеспечения — процесс создания проекта программного обеспечения (ПО), а также дисциплина, изучающая методы проектирования.

Проектирование подразумевает выработку свойств системы на основе анализа постановки задачи, а именно: моделей предметной области, требований к ПО, а также опыта проектировщика.

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

Требования к ПО определяют внешние (видимые) свойства программы, рассматриваемой как чёрный ящик.

Определению внутренних свойств системы и детализации её внешних свойств собственно и посвящено проектирование.

Проектирование ПО является частным случаем Проектирования продуктов и Проектирования систем.

В зависимости от класса создаваемого ПО, процесс проектирования может обеспечиваться как «ручным» проектированием, так и различными средствами его автоматизации. В процессе проектирования ПО для выражения его характеристик используются различные нотации — блок-схемы, ER-диаграммы, DFD-диаграммы, а также макеты.

Проектированию обычно подлежат:

В российской практике результат проектирования представляется в виде комплекса документов под названием «Эскизный проект», «Технический проект», в зарубежной — Software Architecture Document, Software Design Document.

Источник

Тема. Понятие проекта при объектно-ориентированном программировании. Создание простых проектов. Экранная форма. Назначение основных объектов формы. Свойства форм. Пр. работа. №2 » Создание простых проектов. Формы.»

Тема. Понятие проекта при объектно-ориентированном программировании. Создание простых проектов. Экранная форма. Назначение основных объектов формы. Свойства форм. Пр. работа. №2 » Создание простых проектов. Формы.»

1. Обобщить и закрепить понятия проекта при объектно-ориентированном программировании, экранная форма. Назначение основных объектов формы. Свойства форм.

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

I. Орг. Момент. Сообщение целей урока.

II. Мотивация учебной деятельности учеников
Учитель предлагает ученикам попробовать на практике, как работать в среде программирования Visual Basic – выполнить домашнее задание:

«С помощью объектов линия и фигура нарисовать произвольный рисунок, например, снеговик.»,

запустить проект на выполнение.

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

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

III. Содержание самостоятельной работы.

— Создайте в тетрадях таблицу;

— Пользуясь файлом с теоретической частью, заполнить таблицу ответами

Главное окно состоит из…….

Инструментальная панель(окно шаблонов) состоит из…

Файл проекта имеет расширение…..

Файл с формой имеет расширение …

Характер управлений (включая форму) определяется их Свойствами. К Свойствам относятся….

Окно Свойств используется для…

Окно Проекта показывает….

Шаги к созданию Проекта Визуал Бейсик…..

После запуска среды Visual Basic на экране может появиться 5 стандартных окон.

Главное окно состоит из

А) заголовка окна (title bar), строки меню (menu bar), и инструментальной панели (tool bar), линейки, окно «свойства», «окно проекта

заголовок окна (title bar)

Панель элементов управления

Название окна указывает имя проекта и текущий режим работы: проектирование [design], прерывание [break], выполнение [run]. Строка меню состоит из названий, каждое из которых имеет свое раскрывающееся (drop-down) меню, из которого Вы можете управлять операциями в среде Визуал Бейсик. Инструментальная панель(окно шаблонов) имеет кнопки, которые обеспечивают быстрый доступ к некоторым командам меню. Найдите кнопки, которые мы использовали В главном окне отображаются координаты левого верхнего угла объекта (формы)-(0,0) и ее размеры. Эти размеры даются в Твипсах. Твипс-это экранная независимая единица измерения. 1 см=567 твипсов.

Мы видели, что в проекте Визуал Бейсик есть три крупных узла: сам проект (Project), форма (Form), и средства управления (Controls).

Проект-это набор файлов, с которыми пользователь работает при создании прикладной программы.

Важное понятие в проекте Визуал Бейсик – Свойство (Property). Характер управлений (включая форму) определяется их Свойствами. К Свойствам относятся имена, заголовки, размеры, цвета, позиция на форме и содержание. Для каждого управления, которые мы рассмотрим на уроках, мы будем уделять много времени, говоря о его Свойствах.

Окно Формы (Form Window)

Окно Формы является самым важным при разработке приложений в Визуал Бейсик. Это то место, где Вы создаете приложение

Окно Свойств (Properties Window)

Окно Свойств используется, чтобы установить первоначальные значения свойств для средств управления. Раскрывающееся поле наверху Окна Свойств перечисляет все средства управления, которые присутствуют на Вашей Форме. Под этим полем находятся свойства доступные для выбранного Вами объекта. Раскройте поле наверху, выделите какое-либо средство управления, например Timer и Вы увидите, как изменится содержание Окна Свойств, то есть Вы увидите свойства часов.

Доступны два вида: Алфавитный (Alphabetic) и по Категориям (Categorized).

Окно Проекта или Проводник Проекта (Project Window или Project Explorer)

Окно Проекта показывает, какая Форма создает Ваш проект. Когда Вы станете более опытным программистом, Вы научитесь, разрабатывать проекты с несколькими Формами. В этом случае, все Формы в Вашем проекте будут перечислены в этом окне. Вы можете также увидеть окно объектов (управлений) формы (Object) и окно Кодирования (Code) (окно, содержащее кодировку БЕЙСИКА), нажимая на одно из слов (Object или Code) в меню View. Мы рассмотрим окно Кодирования (Code) в следующем разделе.

Шаги к созданию Проекта Визуал Бейсик

Есть три главных шага в формировании Проекта Визуал Бейсик:

Размещение (или ввод) средств управления на форме. Назначение свойств к средствам управления. Запись процедуры события для средств управления.

IV. Обсуждение проделанной работы.

V. Практическая работа.

Мы видели, что Форма – центральное средство управления в создании проекта Визуал Бейсик. Без формы, не может быть никакого проекта! Давайте рассмотрим некоторые важные свойства и события для формы. Форма появляется, когда Вы запускаете новый проект.

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

Свойство (Property). Описание (Description)

Caption (Заголовок). текст, который появляется в области Заголовка формы.

Icon (Иконка). ссылка к иконке, которая появляется в области заголовка формы (мы рассмотрим создание иконок в Классе 7).

Left (Левый). расстояние от левого края экрана компьютера до левого края формы.

Top (Верх). расстояние от верхнего края экрана компьютера до верхнего края формы.

Height (Высота). высота формы.

BorderStyle (Стиль Границ)..изменение размеров формы с использованием мышки или установка неизменяемого размера.

Чтобы лучше узнать эти свойства, запустите Визуал Бейсик и откройте проект»Снеговик». Установите свойства Top, Left, Height и Width, и понаблюдайте их влияние на позицию формы на экране и размеры. Измените размеры, переместите форму и посмотрите, какие произошли изменения в окне свойств. Установите свойство Заголовка. Выберите новый цвет фона. Чтобы увидеть эффект свойства BorderStyle, установите значение (или 1-фиксированный одиночный размер или 2-возможность изменения размера; это те значения, которые мы будем использовать в нашем курсе) и запустите проект (режим [run]). Вы можете запустить проект только с формой! Попробуйте изменять размеры формы. Обратите внимание на различия. Остановите проект.

Прежде всего, Форма действует как «контейнер» для других средств управления, но она также и поддерживает события. То есть она может отвечать на некоторые Ваши (пользователя) действия. Мы, в этом курсе, коснемся только двух событий для формы:

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

— Что нового узнали на уроке?

— Что такое проект? Из чего он состоит?

VII. Дом. задание. Выучить теор. Материал, записанный в таблицу. Подготовиться к проверочной работе.

Источник

Понятие программного проекта

Классическое операционное разделение труда является сутью массового индустриального производства. То есть существует четко налаженный процесс работы и имеются области специализации – один цех точит, другой строгает, третий собирает, четвертый красит и т.д. Пропускная способность такого производства намного превосходит выполнение всей работы одним человеком или одной группой. Это стало причиной промышленной революции в XIX веке. В начале XX века эту структуру работ перенесли и на управление – то есть многочисленные менеджеры контролировали отдельные участки работ.

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

Слово «проект» имеет достаточно много значений. Происходит от латинского projectus, что означает «брошенный вперед». В последнее время слово «проект» употребляется достаточно часто (и часто всуе): проект озеленения улиц города, проект повышения квалификации сотрудников, проект реорганизации деятельности фирмы и т.д.

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

Проект – это уникальная (в отличии от пооперационного промышленного производства) деятельность, имеющая начало и конец во времени, направленная на достижение определённого результата/цели, создание определённого, уникального продукта или услуги, при заданных ограничениях по ресурсам и срокам, а также требованиям к качеству и допустимому уровню риска.

Во всех определениях в той или иной степени отражаются следующие существенные характеристики проекта:

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

· Ограниченность во времени. Проект имеет начало и конец. Для его реализация необходима временная концентрация ресурсов. По минованию надобности, ресурсы используются на другие цели.

· Ограниченность ресурсов, выделяемых на выполнение проекта (финансовых, людских, материальных).

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

· Неопределенность. Возможность достижения цели в указанные сроки с выделенными ресурсами заранее не гарантирована.

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

Иными словами, проект – это достаточно сложный вид деятельности, которым сложно управлять в силу его уникальности и ограниченности ресурсов и времени. Это обстоятельство вносит в проект элемент неопределенности, а правильно организованное управление делает результаты предсказуемыми. Кстати, предсказуемый – не значит успешный. Это значит – во время завершенный (успешно) или во время прекращенный (неуспешно).

Хотя разработка методов и приемов управления была начата еще в начале прошлого века, как дисциплина управление проектами начало складываться в 50-х годах XX столетия, что было вызвано необходимостью координации работ в крупных проектах по разработке вооружений и освоению космоса (США). Разрабатывались методы управления крупными проектами, среди которых наиболее известными являются:

· Метод критического пути – МКП (CPM – Critical Path Method)

· Метод анализа и оценки программ PERT (Program Evaluation and Review Technique)

60-80 гг. прошлого века характеризуются широким распространением методов управления проектами, созданием компьютерных программ на базе МКП, PERT и разработкой новых методов и программ правления проектами. Подробнее.

С 90 гг. XX в. главным образом благодаря усилиям PMI (Project Management Institute) управление проектами становится профессией и областью знаний.

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

Управление проектом основано на двух китах (принципах):

1. Умение – знание принципов и методов управления проектом (планирования, организация, составление графиков, контроль, управление и отслеживание).

2. Навыки – опыт в области управления – применение умения для достижения целей в конкретных условиях

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

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

Ключевой категорией, участвующей в процессе управления проектами, являются ограничения. Известный закон Лермана гласит: «Любую техническую проблему можно преодолеть, имея достаточно времени и денег», а следствие Лермана уточняет: «Вам никогда не будет хватать либо времени, либо денег». Если попросить менеджера описать, как он понимает свою основную задачу в выполнении проекта, то он ответит: «Обеспечить выполнение работ в срок, в рамках выделенных средств, в соответствии с техническим заданием». Именно эти три момента: время, бюджет и качество работ находятся под постоянным вниманием руководителя проекта. Их также можно назвать основными ограничениями, накладываемыми на проект.

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

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

Источник

Работа в реальном проекте: советы начинающим программистам

Авторизуйтесь

Работа в реальном проекте: советы начинающим программистам

Рассказывает Олег Меринов, Senior Development TeamLeader в DataArt

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

Оценка требований

Вспоминаю себя студентом: едва получив задачу, я садился кодить. Думаю, это нормально, а уж для студента просто естественно — кидаться в бой, как только вручили условие.

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

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

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

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

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

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

Что проще: изобразить схему с тремя блоками и связями между ними или исписать половину листа А4? К тому же, картинку проще воспринимать, а читать длинные тексты никому не хочется. Обратите внимание на UML — язык, на котором можно писать и физические модели базы данных, и концептуальные модели, и диаграммы последовательности вызовов, и многое другое.

Оценка сложности

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

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

Разработка

Главный вопрос: как писать? Один проджект-менеджер выразился довольно точно: «надо писать без багов всегда». И здесь самое главное: naming convention и code style.

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

Той же цели служит и Code style (стандарт оформления кода) — стиль оформления кода, необходимый для унификации. Программный код, разработанный разными людьми, должен читаться так, как будто его написал один программист. Поэтому, придя в проект, в первую очередь, нужно понять, какие naming convention и code style здесь используют. Помните, что строгое следование им — ещё и знак уважения к коллегам, который они обязательно оценят.

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

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

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

Пишите простой код! Элементарный совет, следовать которому очень сложно. Если инженер не до конца продумал решение задачи, не смог сделать декомпозицию (не разбил задачу на составные части) — в методе мы видим 500 строк кода. Это не так страшно, но важно вернуться назад и подумать над декомпозицией ещё раз.

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

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

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

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

Что такое IoC?

Этот паттерн называется Inversion of control. В микросервисах слабая связанность приводит к масштабированию системы. Когда у нас есть интерфейс, мы можем изолировать наш основной класс с логикой и протестировать его.

Ещё здесь не хватает комментариев. Комментарий — это важный и полезный элемент работы. Когда вы пишете сложный алгоритм, то комментарии помогут понять, что там вообще происходит, особенно они важны для регулярных выражений. Я пишу регулярное выражение, а через 15 минут забываю, что оно делает.

Проверяйте аргументы — это частая проблема молодых инженеров: они уверены, что всё написали чётко и в проверках написанное ими не нуждается. Но это не так!

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

Вообще исключение — это особая тема. Чтобы понять, что с ним делать, можно почитать «Программист — прагматик» Дэйва Томаса и Энди Ханта. Книга старая, но очень интересная, там хорошие и здравые идеи, когда выбрасывать, когда нет, когда считать, что это ошибка бизнес-, а не программного уровня. Но у нас tax evaluator = null — это ключевая функциональность и без неё мы работать не можем, поэтому выбрасываем исключение.

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

Исключения надо обрабатывать

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

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

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

Unit test

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

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

Сборка, деплой, конфигурация

Что мы делаем, после того как написали что-то? Мы делаем сборку, потом собранные элементы где-то храним, затем деплоим.

Это цикл жизни от момента создания до деплоя, и этот код будет использовать конечный пользователь. Я написал, какие инструменты могут быть использованы: создать автоматическую сборку можно с помощью PowerShell и msbuilt; хранить — в ProGet, и дальше мы можем деплоить полученные пакеты. Это немного сложно.

Работа над ошибками, изменение требований

Мы всё поняли, всё запрограммировали, протестировали, отдали, а заказчик говорит: всё не то.

Что делать? Возвращаться к самому началу и спрашивать: что не то? Если изменились требования — уточнить их и прорабатывать дальше.

Источник