Прикладная информатика Статья Информатика

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

  • Оформление работы
  • Список литературы по ГОСТу
  • Соответствие методическим рекомендациям
  • И еще 16 требований ГОСТа,
    которые мы проверили
Нажимая на кнопку, я даю согласие
на обработку персональных данных
Фрагмент работы для ознакомления
Не хочешь рисковать и сдавать то, что уже сдавалось?!
Закажи оригинальную работу - это недорого!
 

Фрагмент текста работы:

 

Аннотация.
Несколько лет назад потребовались значительные инвестиции в коммерческие продукты или в создание собственных решений для полного управления процессом разработки программного обеспечения, что означало низкое качество продукта или высокую стоимость доступа для небольших компаний – разработчиков. Развитие систем с открытым исходным кодом сделало эту цель почти свободной, но проблема системной интеграции остается.
Ключевые слова: система, контроль версий, разработки программного обеспечения, информационные объекты , управляемость.
Введение
На сегодняшний день написано много книг о том, как управлять людьми и деятельностью, программным кодом и оборудованием для построения связи с клиентами или субподрядчиками. Существует много работ экспертов – гуру, а также ряд методологий и стандартов сертификации, таких как ITIL, PMBOK, SWEBOK, RUP, CMMI и т. д [1].
К сожалению, универсального решения пока не найдено. Прежде всего, большинство концепций предполагают слишком формализованные процессы. Эта формализация, вероятно, оправдана в обществах, где разработка программного обеспечения не является бизнесом, а ИТ – отдел является сервисным подразделением, эффективность которого практически не влияет на прибыльность организации. Но для софтверных компаний чрезмерная формализация выражается в ненужных отчетах и процессах («часы», сбор данных для метрик, которые необходимы только для «контроля» и т. д.) [3].
На наш взгляд, это подавляет инициативу и снижает производительность труда. Кроме того, существует деструктивная демотивация сотрудников: самые влиятельные программисты и аналитики просто отказываются работать в таких условиях (или требуют вознаграждения в супермаркете), в то время как другие склонны молча саботировать «бюрократию». Во – вторых, описания самих методологий не отвечают на вопрос, какую систему автоматизации использовать для управления разработкой [2, С.15].
Конечно, на рынке есть сильные коммерческие продукты, которые, согласно любой методологии, требуют полного цикла автоматизации, но они дороги и даже если они автоматизированы, слишком формализованные процессы не подходят.

Важно! Это только фрагмент работы для ознакомления
Скачайте архив со всеми файлами работы с помощью формы в начале страницы