Библиотека за управление

Теория и практика на автоматизирането на хаоса

Столберг Евгени Семенович, генерален директор на LLC " 1S-ESKV "

Поддръжка за вградени приложения. Теория и практика на автоматизирането на хаоса

въведение

Поддръжката на програмите е отнемащ време и постоянен процес, който тече от момента, в който системата бъде пусната в пробна експлоатация до края на жизнения цикъл на приложението.

За програмистите най-често става дума за изкопаване в лошо структуриран код на някой друг, залепване на "дупки" и постепенно изоставане в съвременните технологии.

За мениджърите това е постоянно главоболие от потребителски обаждания, напомняне за грешки, които изискваха корекции в предишната версия, затруднения при оценката на текущото състояние на нещата и прогнози за бъдещето. Често слушане на упреците на срещите.

Поддръжката изисква значителни ресурси, както човешки, така и финансови (наемане на аутсорсинг и консултантски компании), и искате да използвате тези ресурси много по-ефективно. За мнозина, типична ситуация, при която най-добрите специалисти, които познават системата като собствените си пет пръста, прекарват много време в работата с потребителите, докато по правило са същите потребители и същите проблеми.

Терминът "Софтуерна поддръжка" се определя от IEEE (IEEE Standard 1216) като "процес на модифициране на софтуерна система или нейните компоненти след доставката на системата на клиента за елиминиране на повреди, подобряване на производителността или подобряване на други характеристики на системата или приспособяване към променена софтуерна среда".

От това определение можем да определим основните области:

  • Коригиращата поддръжка е корекцията или заобикалянето на грешките и недостатъците, разкрити по време на работата на софтуера. На този етап потребителите очакват професионалистите да решат проблемите възможно най-бързо; И в идеалния случай откриването на грешки не трябва да засяга изобщо бизнес потребителите. Броят идентифицирани проблеми автоматично намалява удовлетвореността на потребителите и увеличава напрежението в компанията.
  • Подобрената поддръжка е добавянето на софтуерния продукт с нови функции. Изискванията за разширяване на функционалното покритие на системата обикновено идват от потребители и анализатори. В този случай задачите за подобряване на подкрепата по правило се разпределят за отделни проекти с независими бюджети, срокове и отговорни лица.
  • Адаптивна поддръжка - може да се определи като извършване на промени в текущото приложение, което е необходимо за поддръжка на нов софтуер и хардуер. Функционалността на системата не се нуждае от разширяване. Приложението трябва да изпълнява старите функции в новата среда.
  • Превантивната поддръжка е модификация на софтуерния продукт по време на операционната фаза, за да се идентифицират и предотвратят скрити дефекти, преди да доведат до реални неизправности.

Това определение е вярно за разработчиците на софтуер или за отделите за информационни технологии, които изпълняват изцяло цикъла на разработка на приложения от самото начало. Но за бизнеса, този подход често е неоправдано скъп, защото закупуването на продукт винаги е по-евтино от самоусъвършенстването. В тази връзка, с подкрепата на бизнес приложения, има и друга посока на подкрепа, а именно актуализации от продавача; В професионалния свят това се нарича миграция на софтуерни версии. Разработчикът на репликираното решение редовно предоставя на своите потребители нови версии, в които автоматизираната функционалност се разширява, грешките се коригират, приложението се адаптира към поддържане на промените във външната среда (това е много типично за счетоводните приложения, които съществуват в условията на нестабилност на законодателството).

В тази област има доста сериозни проблеми, свързани със съвместимостта на промените, получени от доставчика на решения, с промените, направени преди това от собствената услуга за поддръжка на клиенти на компанията. Анализът на тази ситуация за анализаторите е огромно главоболие и изисква екипът да поддържа високо ниво на документация. Много компании поради високата интензивност на труда на такава функция са изоставили напълно тази посока на подкрепа. В такава ситуация предприятието-потребител губи способността да използва ресурса за програмисти. Ето един жив пример: правилата за създаване на книга за покупки се променят, докато компанията, която поддържа услугата за актуализиране, получава от компанията-разработчик съответната актуализация почти безплатно и компанията, която не поддържа тази услуга, е принудена да произвежда съответното развитие независимо.

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

Процесът на управление на изискванията е поредица от действия за регистрация, проследяване, анализ, вземане на решения, изпълнение, проверка и затваряне. Този процес изисква приемането на редица решения от ръководителите на различни отдели и обмена на информация за възложените задачи и работата, извършена между заинтересованите страни.

Сценарии на поддръжката

Как трябва да бъде

Обмислете обичайния сценарий на работа с изискванията за софтуера. Например, потребителят има проблем. Той се обажда по телефона или пише писмо по електронна поща до службата за ескорт и го съобщава. Обадете се на това писмо "Изискване", трябва да бъде регистрирано, потребителят е информиран за регистрационния код. Освен това, това изискване трябва да бъде предадено на експертите за анализ. В случай, че е възможно проблема да бъде разрешен по "мирен начин", т.е. това изискване не поражда задачи за разработване на кодекс или допълнителни правила, проблемът може да бъде решен чрез кратки консултации за потребителя. Тази консултация в писмен вид, по факс или по електронна поща е предоставена на потребителя и заявката е затворена. В противен случай ръководителят на службата за ескорт определя трудолюбието и техническата способност да изпълнява тези работи. Координационният съвет определя бюджета за изпълнение и приоритетите за изпълнението на това изискване. В допълнение към това изискване се създават задачи, дефинират се изпълнители, се определят планове и т.н.

Колко често се случва

Обща картина на процеса на неформална поддръжка е, че системен специалист прекарва голяма част от работното си време, комуникирайки с потребителите по телефона, като обяснява проблеми, свързани с работата на софтуера. В същото време входящата информация в най-добрия случай е фиксирана във файла на Excel и, когато се правят корекции, тя се изтрива и в най-лошия случай - обикновено се записва върху хартия, периодично изчезва някъде.

Има непродуктивна загуба на време от квалифициран специалист; Освен това има трудности при планирането на работата, за да се премахнат коментарите. Главата няма пълна информация за откритите дефекти, няма обобщена статистика за коментарите, които вече са коригирани или все още се нуждаят от внимание.

Кой в такива случаи дава приоритет? Експертът на подкрепа - той приема изискванията и решава какво да прави на първо място и какво да отложи за по-късно. Трябва да бъде изключително отговорна личност, която се вкоренява в работата си и внимателно подрежда отпечатъци от дефекти в татко, а такива между програмистите, в масата на привържениците на разумен хаос, все още трябва да изглеждат. През годината такъв разработчик запушва чекмеджетата на работния си плот с документи и не гарантира, че забележката на поне един потребител няма да бъде загубена.

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

Има и друг проблем, който възниква в резултат на неконтролиран ескорт - често тази подкрепа се изпомпва от колапса на системата, макар и не в буквалния смисъл на думата. Системата е пълна с петна, които буквално друг не може да я прехвърли и няма време, никакви ресурси, няма документация за пълно преобразуване. Авторът е виждал такива системи многократно и в подобно състояние те са били дадени само за две години поддръжка от двама напълно способни специалисти. И експертите не бяха лоши и работеха понякога за 12 часа на ден - от потребителите се иска да го направят възможно най-бързо и колкото е възможно по-просто.

Все още няма дърво за коментари и един специалист се справя с всички проблеми, а системата е съвсем проста, но все пак може да я кажете по някакъв начин, но когато се увеличат томовете, трябва да се намери решение на проблема. Необходим е инструмент, който да направи прозрачността на поддръжката, да поддържа необходимата организация на работата, да забрани отклонения от правилата и да не изисква големи усилия за поддържане на процеса и разбира се да съдържа хранилище на всички получени данни за изискванията и историята на тяхната обработка на едно място за бърза и Безпрепятствен достъп до екипа на ескорта - от главата до програмиста.

Управление на изискванията в софтуера
Управление на изпълнението и поддръжката

Модел за управление на търсенето, който автоматизира следния бизнес процес:

Този подход към управлението на изискванията ви позволява да гарантирате, че потребителските изисквания се запазват, следват процедурите за затваряне на потребителските изисквания и регулират потока от изисквания чрез процедурите за съгласуване и управление на бюджета.

Документацията за извършената работа се извършва на ниво пакет "Цели" с метаданни обекти.

Този подход ви позволява да създадете следната верига от данни:

Такава информация, поставена в базата данни, не натоварва потребителите - в повечето случаи потребителят все още трябва да напише писмо до електронната поща - това не натоварва разработчиците - те все още правят отчет за работата си. Но в същото време този инструмент ви позволява да получите информация за всички произведения на обекта на метаданните, по-специално за кого е направено, защо и кой го е направил - което е безценна информация за анализа на направените промени в системата.

Също важен фактор е икономическата оценка на потребителските изисквания чрез сравнение на разходите за труд на ИТ отдела и ефективността на резултата. По принцип всяка функция за управление на автоматизацията винаги може да бъде анализирана чрез следните показатели:

  • Брой транзакции на месец
  • Сложността на изпълнението без автоматизация
  • Разходите за изпълнение на функцията без автоматизация (изчислени като вложен труд × брой × размер на художника)
  • Работа с интензивно изпълнение с автоматизация
  • Разходи за изпълнение с автоматизация (изчислени като вложен труд × брой × степен на изпълнение)
  • Спестявате на автоматизацията
  • Разходи за автоматизация (трудност на изпълнението × процент на изпълнителя)
  • Значението на човешкия фактор (определя коефициента, който увеличава значението на автоматизацията във връзка с възможните грешки на оператора при неавтоматизираната подготовка на информацията)
  • Изисквания за тази информация в други процеси (коефициент, който увеличава значението на автоматизацията по отношение на използването на тази информация в други процеси).

По този начин е възможно да се изведе икономическата ефективност на всяко функционално изискване, но, уви, в допълнение към икономиката, предприятията също имат политика. В тази връзка процедурата за приемане на иск е ограничена само от процедурата за бюджетна координация, но нашата практика показва, че дори такова ограничение намалява потока от вземания средно два пъти само чрез въвеждане на процедура, в която притежателят на бюджета сравнява съдържанието на изискването с разходите за неговото изпълнение и съкращения Неразумни изисквания.

Автоматизирането на процеса на поддръжка по този начин може да удвои качеството на поддръжката на системата, да намали рисковете, свързани с оборота на персонала в организацията и да оптимизира разпределението на работата в рамките на поддръжката.