Правильно організуємо технічну підтримку проектів

У роботі з усіма своїми замовниками я дотримуюся правила: «Безкоштовна технічна підтримка в рамках технічного завдання і трохи більше». Спілкування з замовником після завершення проекту - це ефективний спосіб отримувати нову інформацію, рекомендації, а також нові замовлення на вигідних умовах. Я працюю з чотирма постійними замовниками і майже кожен день ми обговорюємо перспективи розвитку їх проектів, я пропоную різні ідеї, вони пропонують розширити функціональність в якості додаткових робіт. Якщо у їхніх знайомих виникає необхідність у виконанні робіт з Веб-проектам - вони рекомендують мене, як хорошого фахівця.

Будь-яка людина цінує увагу, але особливо її цінують замовники, так як вони впевнені, що з будь-якого технічного питання вони можуть отримати від мене докладну консультацію. У свою чергу я отримую від спілкування з ними додатковий дохід, постійний фронт робіт і масу позитивних емоцій. Також більшість замовників активно беруть участь у різних фокус-групах. Стабільні партнерські відносини, а саме такий вид відносин найбільш результативним: немає ризиків відсутності оплати, пільгові умови щодо виконання робіт, отримання додаткових замовлень. Крім того, якщо ви спілкуєтеся з людиною, яка веде бізнес онлайн - ви завжди отримуєте додатковий досвід, можете використовувати його аудиторію для отримання цінної інформації, а також безліч інших можливостей. Звичайно, відносини такого роду виникають не завжди, але замовнику також вигідно завжди мати «під рукою» фахівця для вирішення оперативних завдань, тому бізнес відносини «розробник - замовник» завжди прагнуть до постійного партнерству. При цьому ви не зв'язані ніякими зобов'язаннями (крім виправлення власних помилок) і завжди можете розірвати партнерство, якщо його умови не задовольняють вашим вимогам, у зв'язку з якими-небудь змінами. Пам'ятайте, що будь-який постійний контакт - це джерело інформації, а інформація є найціннішим товаром у роботі розробника.

Питання для контролю знань

1. Фінансові розрахунок

2. Як перевіряти проект при здачі замовнику?

3. Супровідний лист за проектом

4. Правила розрахунків між фрілансером і замовником

5. Правила коригувань помилок при здачі проекту

6. Правила організації технічної підтримки проектів

Лекція №17

Тема: Перспективи розвитку методології програмної інженерії Тематичний контроль.

Мета: Дати характеристику базовим наплавленням ррозвитку методології програмної інженерії

Перспективи і проблеми програмної інженерії в XXI столітті

Наступні кілька десятиліть зроблять XXI століття століттям програмного забезпечення. Програмне забезпечення стане основним елементом, що забезпечує людям необхідні можливості і якість життя, і фахівці, які знають, як найкраще розробляти програмні системи, отримають найбільший шанс змінити світ на краще. З одного боку, фахівці будуть дуже раді цій можливості, але, з іншого боку, на них ляже величезна відповідальність за забезпечення належної якості розроблюваних програмних систем і наданих ними сервісів. Як вважає Баррі Боєм, основними проблемами, з якими зіткнуться в XXI столітті фахівці в галузі інженерії програмного забезпечення, є постійне прискорення змін, наявність невизначених і непередбачених ситуацій, функціональна надійність, диверсифікація та взаємозалежність В XXI столітті життєздатність організацій визначатиметься їх можливістю пристосуватися до частих і непередбачених змін, які повинні виконуватися швидше, ніж у конкурентів. Однак за всі зміни доводиться платити. Людям подобаються результати змін, але зазвичай вони не люблять змінювати свою поведінку. Фахівці в галузі інженерії програмного забезпечення, що підвищують рівень зрілості процесів розробки, часто вважають, що досягнення п'ятого рівня зрілості забезпечує належну зрілість і оптимальність процесів на всі часи. Цей підхід загрожує ризиком надмірної оптимізації, він може зробити процеси розробки надмірно важкими і важко змінюються.

Є маса протиріч між людьми та організаціями, що швидко пристосовуються до змін, і тими, хто вважає за краще не робити цього. Хорошим сучасним прикладом є труднощі розробників програмного забезпечення, що намагаються пристосовуватися до змін при дотриманні фіксованої структури специфікацій контракту на розробку програмного забезпечення. Такого роду контракти визначаються адміністраторами, що дотримуються принципу THWADI (That's How We've Always Done It - «ми завжди так робимо»). У комерційному світі розробляються досконаліші структури контрактів, засновані, наприклад, на моделі «загальної долі» («shared destiny»). Застосування вдосконалених і загальноприйнятих видів контрактів сприятиме успішній розробці програмного забезпечення при наявності частих змін. Багато джерел змін є відносно непередбачуваними, наприклад, ті, які пов'язані з виникненням нових технологій. Часто, коли користувачів просять заздалегідь специфікувати бажаний для них спосіб взаємодії з новим додатком, вони відповідають «IKIWISI» (I'll Know It When I See It, «це буде зрозуміло, коли ми його побачимо»). В таких випадках використання послідовної каскадної моделі, в якій спочатку вказуються всі вимоги, швидше за все, призведе до створення неповороткою системи, що вимагає великого обсягу робіт для внесення змін. Для скорочення обсягу невизначеності найкраще використовувати стратегію BITAR (Buy Information To Avoid Risk, «щоб уникнути ризику, купуйте інформацію»). Ця стратегія передбачає витрачання додаткових коштів на прототипування, імітаційне моделювання, еталонне тестування, аналіз тенденцій ринку і т.п. для скорочення рівня невизначеності та ризиків. Крім того, важливо організовувати майбутні проекти таким чином, щоб залишалася можливість пристосуватися до появи нових джерел непередбачених змін. Це передбачає наявність здатності до швидких змін в колективі розробників, в їх організації, в архітектурі програмного продукту і процесі його розробки. Поряд з розвитком можливості швидких змін в майбутніх проектах буде потрібно домагатися більш високого рівня функціональної надійності (dependability), оскільки програмне забезпечення стає домінуючим фактором у конкурентних відмінностях продуктів і сервісів, вироблених компаніями. Одночасне досягнення здатності до швидких змін та функціональної надійності є однією з найбільш великих проблем XXI століття для фахівців в області інженерії програмного забезпечення.

Для створення функціонально надійної системи важливо визначити, які зацікавлені сторони можуть найбільш сильно вплинути на успішність майбутньої системи, і в чому вони найбільше потребують. Потреби різних зацікавлених сторін (кінцевих користувачів, адміністраторів, продавців), швидше за все, будуть конфліктувати. Наявність цих конфліктів означає, що потенційно проект може привести до ситуацій, в яких виграш однієї зацікавленої сторони є програшем іншого боку. Такі ситуації зазвичай перетворюються в ситуації, в яких не виграє жодна сторона: інвестори виявляють перевитрата бюджету, користувачі незадоволені продуктивністю, експлуатаційний персонал не влаштовує відсутність сумісності з іншими системами і т.д. Щоб уникнути подібної ситуації важливо вміти узгоджувати очікування зацікавлених сторін, витрачати великі зусилля на забезпечення застосовності пропонованого рішення для всіх зацікавлених сторін, домовлятися про яке влаштовувало всі сторони наборі вимог, планів і ресурсів до початку розробки. На ранній стадії узгодження вимог замість жорсткого терміна «вимога» краще використовувати терміни «завдання» або «мета».

«Безрозмірне» (one-size-uniformly-fits-all, OSUFA) визначення функціональної надійності в термінах часу безвідмовної роботи систем часто влаштовує не всі зацікавлені сторони. Висновок про непридатність підходу OSUFA стає ще більш явним при наявності тенденції до глобалізації, яка охоплює різні культури. Наприклад, через відмінності в культурі країни тільки 17 з 380 софтверних компаній Таїланду зважилося використовувати розроблену в США модель CMM.

Підхід OSUFA і стандартизація процесів розробки особливо погано відповідають ще одній тенденції XXI століття - появі великих, переважно програмних систем, споруджуваних з існуючих систем (software-intensive systems of systems, SISOS). Ця тенденція означає наявність вимоги масштабування при вирішенні проблеми одночасного забезпечення можливості швидких змін і функціональної надійності. Деякі альтернативи підходу OSUFA пропонуються в статті Баррі Боема, опублікованій в цьому ж збірнику і також доступною на сайті університету Південної Каліфорнії. Статтю «Визначення впливу на практику досліджень в галузі інженерії програмного забезпечення» («Determining the Impact of Software Engineering Research on Practice») представили Леон Остервейл, Карло Гецці, Джеф Креймер і Александер Волф (Leon J. Osterweil, University of Massachusetts, Amherst, Carlo Ghezzi, Politecnico di Milano, Jeff Kramer, Alexander L. Wolf, Imperial College London). Інженерія програмного забезпечення стала активною дослідницької областю в 1968 р, коли на знаменної конференції NATO, що проходила в Гармише (Garmisch), Німеччина, учасники обґрунтували наукову і практичну важливість цієї дисципліни. З 1975 р стали регулярно проводитися Міжнародні конференції з інженерії програмного забезпечення (International Conference on Software Engineering), на які в останні роки надходить більше 400 заявок на доповіді, і які збирають понад 1000 учасників, а з 1982 р ще й Міжнародні симпозіуми ACM SIGSOFT з основ інженерії програмного забезпечення (ACM SIGSOFT International Symposium on the Foundations of Software Engineering). Дослідники вважають ці конференції кращими в галузі інженерії програмного забезпечення. Технічні заходи, присвячені програмної інженерії, регулярно проходять в Європі, Азії, Індії, Південній Америці, країнах Тихоокеанського басейну і багатьох інших регіонах. Проводяться незліченні дрібніші заходи, часто присвячені спеціальними напрямками програмної інженерії.

Поряд з працями конференцій, поширенню результатів досліджень сприяють журнальні публікації. До числа провідних журналів, які спеціалізуються на тематиці програмної інженерії, відносяться ACM Transactions on Software Engineering and Methodology і IEEE Transactions on Software Engineering. Останній з цих журналів видається з 1975 р Програмної інженерії присвячуються і численні інші періодичні видання. В останні десятиліття відбулися величезні зміни в практиці програмної інженерії. Практика виконання в пакетному режимі програм, що включають кілька тисяч рядків коду на мовах типу Fortran і Cobol, перетворилася в практику швидкої компонування величезних (що включають мільйони рядків коду) паралельних і розподілених систем, які працюють в режимі реального часу і складаються з все більших і все краще налагоджених компонентів, написаних на різних сучасних мовах. Щорічний дохід світової індустрії програмного забезпечення тепер становить сотні мільярдів доларів, і він продовжує рости. У всьому світі все частіше визнається, що індустрія програмного забезпечення є ключовою рушійною силою суспільного та економічного розвитку.

Зважаючи на все це представляється розумним розглянути взаємодія цих двох важелів - досліджень і практики програмної інженерії. З цією метою в статті обґрунтовуються основні мотиви, що призвели до створення проекту Impact, описуються використовувана при виконанні цього проекту методологія і план виконання проекту. Обговорення більш спеціальних питань дозволяє виділити групи досліджень в області програмної інженерії, що вивчаються в рамках даного проекту. Автори статті вивчають велику кількість областей досліджень та практичного застосування програмної інженерії. У цій статті представлені деякі області, при вивченні яких вдалося досягти найбільшого прогресу.

Багатомільйонна індустрія конфігураційного управління забезпечує важливу підтримку практиці програмного забезпечення. Ця область отримує істотну вигоду від методів і інструментальних засобів, створених при виконанні досліджень. Проміжне програмне забезпечення (middleware) у все більшій мірі застосовується для зборки великих додатків, що використовуються тепер практично у всіх областях людської діяльності. Дослідження в області програмної інженерії сприяють підвищенню рівня зрілості інструментів і технологій middleware. Мови програмування є основним засобом розробки програмного забезпечення. На розвиток мовних засобів, в свою чергу, впливали і впливають дослідження в області програмної інженерії. Базові методи управління проектами, такі як збір і аналіз різних показників продуктивності, регулярно використовуються у виробничій практиці і є невід'ємною частиною сучасної програмної інженерії. Результати досліджень у цій області здавна публікуються в літературі з програмної інженерії. В інженерії програмного забезпечення, як і в інших інженерних дисциплінах, давно використовуються різні методи проектування, моделі і нотації. На їх розробку вплинули багато років досліджень методів та інструментальних засобів програмної інженерії.

Ці дослідження представляють типові приклади розміру і природи впливу на практику досліджень в області програмної інженерії. Хоча для багатьох це істотний вплив представляється очевидним, широко поширена і протилежна точка зору. На думку авторів статті, виразне розуміння результатів цього впливу є важливим для дослідників, практиків, представників індустрії та уряду. Тому вони вважають своєчасним витіснити необгрунтовані домисли про наявність або відсутність цього впливу вагомими доказами. Остання стаття тематичної добірки представлена Лоріном Хохштейном і Віктором Базилі (Lorin Hochstein, University of Nebraska-Lincoln, Victor R. Basili, University of Maryland) і називається «Проекти ASC-Alliance: приклад великомасштабної розробки паралельного наукового коду» («The ASC-Alliance Projects: A Case Study of Large-Scale Parallel Scientific Code Development »).

Всього декілька вчених використовують комп'ютери для моделювання фізичних явищ в ситуаціях, в яких експерименти були б надмірно дороги або неможливі. Передові наукові дослідження залежать від продуктивності розробки цими вченими необхідного програмного забезпечення. Однак процес розробки програмного забезпечення в цій області відрізняється від інших областей. Наприклад, для наукового програмного забезпечення потрібні обчислювальні можливості найбільш потужних комп'ютерів. Ці машини, звані суперкомпьютерами або високопродуктивними обчислювальними системами (high-end computing system, HEC-системи), породжують унікальні проблеми при розробці програмного забезпечення. Щоб більше дізнатися про розробку програмного забезпечення для HEC-систем, автори досліджували п'ять софтверних проектів, в яких розроблялися такі комп'ютерні програми, звані в співтоваристві HEC кодами. Ці проекти виконувались у п'яти дослідницьких центрах Альянсу з розвиненому моделюванню і обчисленням (Advanced Simulation and Computing-Alliance, ASC-Alliance). У кожному з цих проектів вирішувалася окрема проблема обчислювальних наук, і у кожного центру мався доступ до великомасштабних системам в різних суперкомп'ютерних центрах.

Автори інтерв'ювали основних учасників проектів ASC-Alliance, пов'язаних з управлінням проектом, архітектурою програмного забезпечення та інтеграцією програмного забезпечення. Цілі складалися в з'ясуванні проблем, з якими довелося зіткнутися вченим, а також визначенні основних характеристик кінцевого продукту, організації проекту і процесу розробки програмного забезпечення. Поза тематичної добірки в журналі також опубліковані три великі статті. Авторами статті «Модель процесу розробки, орієнтована на змістовний матеріал» («A Content-Centric Development Process Model») є Пабло Морено-Гер, Іван Мартінез-Ортіз, Хосе Луїс Сієрра і Балтазар Фернандез-Маньон (Pablo Moreno-Ger, Iván Martínez -Ortiz, José Luis Sierra, Baltasar Fernández-Manjón, Complutense University of Madrid). У комп'ютерів і відеоігор є величезний потенціал для сприяння навчанню, оскільки на них легко фіксується увагу студентів. Поширена точка зору про те, що діти не здатні зосереджувати увагу на чомусь одному протягом досить довгого проміжку часу, розходиться з тим, що вони можуть проводити години за іграми, що не втрачаючи своєї концентрації. При застосуванні належного підходу час, що витрачається на ігри, може служити на користь освіти, і тут стає доречним навчання на основі ігор. Однак навчати під час розваг нелегко. Не можна просто вмонтувати в гру якусь математику і назвати її освітньої, як і не можна назвати розвагою дію, під час якого урок веде тварина, що розмовляє, а студент вирішує дурні головоломки. Словами професора літератури Генрі Дженкінса (Henry Jenkins), потрібно «просуватися за межі поточного стану освітньо-розважальних (edutainment) продуктів, в яких об'єднується розважальна цінність поганий лекції з освітньою цінністю поганої гри».

На думку авторів, керовані мишею пригодницькі ігри, такі як саги Monkey Island і King's Quest, містять всі компоненти, необхідні для досягнення цього балансу між викладенням змістовного матеріалу і розвагою. Ігри цього типу оцінюються в термінах якості їх розкадровки та ритму на відміну від типових рис відеоігор інших типів, таких як занурення гравців в проблемні ситуації, що підвищують рівень адреналіну в їх крові і вимагають блискавичної реакції. Розповідні ігри, в яких в розкадрування весь час вплітається змістовний матеріал, володіє потенціалом для досягнення цього невловимого балансу. Проте присутність в індустрії відеоігор нетехнічних професійних сценаристів завжди породжує проблеми при їх інтеграції в технічні групи розробки.

Читайте також:

<== попередня сторінка	\|	наступна сторінка ==>
Правила коригувань помилок при здачі проекту	\|	Розділ «Системи менеджменту якості»

Не знайшли потрібну інформацію? Скористайтесь пошуком google:

Генерація сторінки за: 0.015 сек.