Managing Construction

583 views

Published on

Published in: Technology, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
583
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
11
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • Качествен програмен код изборен курс към ФМИ на СУ, летен семестър, 2004/2005 г. За коментари и препоръки: Николай Манчев [email_address] [email_address] Copyright (c) 2005 Nikolay Manchev. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License" .
  • Managing Construction

    1. 1. Методология на разработката Управление на процеса на конструиране на кода
    2. 2. План на темата <ul><li>Осигуряване качество на кода </li></ul><ul><li>Управление на промените </li></ul><ul><li>Изграждане на график </li></ul><ul><li>Статистика за проекта </li></ul><ul><li>Отношение към хората </li></ul><ul><li>Управление на по-висшестоящите </li></ul>
    3. 3. Осигуряване качество на кода <ul><li>Поне двама души работят по всяка отделна част в проекта </li></ul><ul><li>Разработчиците преглеждат взаимно кода си </li></ul><ul><li>Кодът се подписва </li></ul><ul><li>Добрия код се показва на всички </li></ul>
    4. 4. Осигуряване качество на кода <ul><li>Трябва да е ясно, че кодът принадлежи на всички разработчици </li></ul><ul><li>Добрият код носи награди </li></ul><ul><li>Съществува единен стандарт </li></ul>
    5. 5. План на темата <ul><li>Осигуряване качество на кода </li></ul><ul><li>Управление на промените </li></ul><ul><li>Изграждане на график </li></ul><ul><li>Статистика за проекта </li></ul><ul><li>Отношение към хората </li></ul><ul><li>Управление на по-висшестоящите </li></ul>
    6. 6. Какво е “Управление на промените” <ul><li>Оценка на предложените промени в системата </li></ul><ul><li>Следене на извършени в миналото промени </li></ul><ul><li>Възможност, системата да бъде върната във състоянието, в което била преди дадена промяна </li></ul>
    7. 7. Названия <ul><li>Концепцията за управление на промените е известна под няколко имена: </li></ul><ul><li>Change Control </li></ul><ul><li>Configuration Management </li></ul><ul><li>SCM – Software Configuration Management </li></ul>
    8. 8. Управление на промените <ul><li>Над 30% от програмистите не разбират концепцията за Управление на промените </li></ul><ul><li>Под 20% от компанните, разработващи софтуер имат адекватна система за Управление на промените </li></ul>
    9. 9. Изисквания и промени в дизайна <ul><li>Трябва да има единна процедура за контрол на промените </li></ul><ul><li>Добре е промените да се организират в групи </li></ul><ul><li>Всяка промяна има цена – тя трябва да се оцени правилно </li></ul><ul><li>Трябва да се внимава, когато възникне нужда от много промени </li></ul>
    10. 10. Изисквания и промени в дизайна <ul><li>Добре е да се организира Група за контрол на промените </li></ul><ul><li>Трябва да се внимава с бюрокрацията около промените </li></ul>
    11. 11. Система за контрол на версиите <ul><li>Няколко души могат да работят върху едни и същи части на системата </li></ul><ul><li>Всеки разработчик лесно актуализира копието, върху което работи </li></ul><ul><li>Всяка версия, на всеки файл е достъпна по всяко време </li></ul>
    12. 12. Система за контрол на версиите <ul><li>По всяко време може да се получи списък с промените направени за всеки файл </li></ul><ul><li>Не е нужно разработчиците да се грижат за backup -и </li></ul>
    13. 13. План на темата <ul><li>Осигуряване качество на кода </li></ul><ul><li>Управление на промените </li></ul><ul><li>Изграждане на график </li></ul><ul><li>Статистика за проекта </li></ul><ul><li>Отношение към хората </li></ul><ul><li>Управление на по-висшестоящите </li></ul>
    14. 14. Планиране и графици <ul><li>Статистиката показва, че всеки софтуерен проект закъснява средно с около година от планирания график и надхвърля бюджета си с над 100% </li></ul>
    15. 15. Как да планираме - подходи <ul><li>Софтуер за планиране </li></ul><ul><li>Алгоритъм за планиране </li></ul><ul><li>Външни консултанти </li></ul><ul><li>Оценка на компонентите и обединяване на резултата </li></ul><ul><li>Индивидуална оценка и обобщение </li></ul>
    16. 16. Как да планираме - подходи <ul><li>Опит от предишни проекти </li></ul><ul><li>Обновяване на вече използвани модели </li></ul>
    17. 17. Как да планираме - насоки <ul><li>Ясни очаквания </li></ul><ul><li>Планиране на време за планиране </li></ul><ul><li>Точни очаквания за софтуера </li></ul><ul><li>Оценка в детайлност </li></ul><ul><li>Използване на разнородни техники за оценка </li></ul>
    18. 18. Фактори, влияещи върху планирането и оценяването Документация на проекта Текучество на персонала Сработеност на екипа Опит на екипа в дадената област Качество на програмистите Фактор 23% -19% 20% -19% 11% -10% 22% -19% 34% -24% - +
    19. 19. Ако изостанем от плана <ul><li>Какво да правим, ако изостанем от графика? </li></ul><ul><li>Статистиката показва, че плановете подценяват нужното време средно с 20 ÷ 30% </li></ul>
    20. 20. Ако изостанем от плана <ul><li>Компенсация на закъснението </li></ul><ul><li>Разширяване на екипа </li></ul><ul><li>Съкращаване на изискванията </li></ul>
    21. 21. План на темата <ul><li>Осигуряване качество на кода </li></ul><ul><li>Управление на промените </li></ul><ul><li>Изграждане на график </li></ul><ul><li>Статистика за проекта </li></ul><ul><li>Отношение към хората </li></ul><ul><li>Управление на по-висшестоящите </li></ul>
    22. 22. Статистика за проекта <ul><li>Липсата на статистика за проекта е липса на идея какво се случва с проекта като цяло </li></ul>
    23. 23. Измерване големината на проекта <ul><li>Редове код </li></ul><ul><li>Редове коментари </li></ul><ul><li>Брой класове и методи </li></ul><ul><li>Брой декларации </li></ul><ul><li>Брой празни редове </li></ul>
    24. 24. Оценка на качеството <ul><li>Общ брой грешки </li></ul><ul><li>Брой грешки на клас или метод </li></ul><ul><li>Брой грешки на 1 000 реда код </li></ul><ul><li>MTBF </li></ul><ul><li>Грешки докладвани от компилатора </li></ul>
    25. 25. Продуктивност <ul><li>Часове работа върху проекта </li></ul><ul><li>Часове работа върху всеки клас/метод </li></ul><ul><li>Брой преправяния на метод </li></ul><ul><li>Разходи по проекта </li></ul><ul><li>Цена на ред код </li></ul><ul><li>Цена за поправяне на грешка </li></ul>
    26. 26. Леснота на поддръжка <ul><li>Брой public променливи за всеки клас </li></ul><ul><li>Брой параметри предавани на всеки метод </li></ul><ul><li>Брой декларации за клас/метод </li></ul><ul><li>Брой методи извиквани от други методи или класове и т.н. </li></ul>
    27. 27. Проследяване на грешките <ul><li>Тежест на всяка грешка </li></ul><ul><li>Място на възникване на грешка (клас, метод) </li></ul><ul><li>Произход на грешката (код, дизайн, изисквания и т.н.) </li></ul><ul><li>Програмист, отговорен за грешката </li></ul><ul><li>Брой грешки, възникващи от корекция на грешки и т.н. </li></ul>
    28. 28. Създаване на статистика - насоки <ul><li>Няма смисъл да се следят всички възможни показатели </li></ul><ul><li>Статистиката се прави с цел </li></ul><ul><li>Пикове в статистическите параметри за един метод или клас, обикновено показват проблем в реализацията му </li></ul>
    29. 29. План на темата <ul><li>Осигуряване качество на кода </li></ul><ul><li>Управление на промените </li></ul><ul><li>Изграждане на график </li></ul><ul><li>Статистика за проекта </li></ul><ul><li>Отношение към хората </li></ul><ul><li>Управление на по-висшестоящите </li></ul>
    30. 30. Отношение към хората <ul><li>Как програмистите прекарват времето си? </li></ul>
    31. 31. Разпределение на времето в проценти 1 13 Писане 2 2 14 Четене 1 2 Телефон 1 Разгвор с мениджър 3 7 17 4 Дискусия Техн. Документация Поща Обучение Сре-щи Лично По работа Код Дейност
    32. 32. Разпределение на времето в проценти 2 5 6 7 13 29 35 Общо 1 3 3 2 Други 1 1 2 2 Ходене 6 4 1 4 Навън Техн. Документация Поща Обучение Сре-щи Лично По работа Код Дейност
    33. 33. Любопитно <ul><li>Програмистите прекарват във ходене толкова време, колкото отделят за обучение </li></ul>
    34. 34. Производителност <ul><li>Мащабни изследвания в разработката на софтуер показват, че 80% от работата се извършва от 20% от работещитете по проекта програмисти </li></ul><ul><li>Тези 20% са най-квалифицираните служители участващи в проекта </li></ul>
    35. 35. Извод <ul><li>По-добре да се наемат малко, но високо квалифицирани хора, вместо много с по-ниска квалификация </li></ul>
    36. 36. Друг фактори <ul><li>Програмистите са силно религиозни </li></ul>
    37. 37. Друг фактори <ul><li>Програмистите са силно религиозни. Сред тях непрекъснато възникват спорове на религиозна основа. Например... </li></ul>
    38. 38. Спорни теми... <ul><li>Език за програмиране </li></ul><ul><li>Отмествания на кода </li></ul><ul><li>Място на скобите </li></ul><ul><li>Избор на IDE </li></ul><ul><li>Стил на коментарите </li></ul><ul><li>Ефикасност срещу лесна четимост </li></ul>
    39. 39. ...и още спорни теми <ul><li>Методология </li></ul><ul><li>Използвани инструменти </li></ul><ul><li>Конвенции за имената </li></ul><ul><li>Употреба на goto </li></ul><ul><li>Глобални променливи </li></ul><ul><li>Статистика за продуктивността </li></ul>
    40. 40. Опасна зона! <ul><li>Опитите за контрол над програмистите по тези теми трябва да са много внимателни </li></ul><ul><li>По добре е да се правят “предложения”, вместо да се налагат “правила” </li></ul>
    41. 41. Опасна зона! <ul><li>По-добре програмистите да се разберат сами. Дори собствено измисления стандарт е по-добър от липсата на какъвто и да е стандарт </li></ul><ul><li>Опитите за насилствено налагане на решния по темите водят единствено до проблеми в проекта </li></ul>
    42. 42. Условия за работа <ul><li>Проведени изследвания показват, че разработчиците, които присъстват в TOP 25 % по продуктивност имат по-големи, спокойни и комфортни работни места </li></ul>
    43. 43. Влияние на работното място върху качеството на работа 29% 57% Работното място кара ли служетля да се чувства “оценен”? 76% 38% Има ли много безмислени прекъсвания от колеги? 19% 76% Може ли да се пренасочва? 10% 52% Може ли да се изключва телфона? 19% 62% Спокойно ли е? 29% 57% Тихо ли е работното място? 46 кв. м. 78 кв. м. Пространство Най-лоши Най-добри Условия
    44. 44. Извод <ul><li>Подобряването на работното място на служителя увеличава неговата продуктивност с най-малко 100% </li></ul>
    45. 45. План на темата <ul><li>Осигуряване качество на кода </li></ul><ul><li>Управление на промените </li></ul><ul><li>Изграждане на график </li></ul><ul><li>Статистика за проекта </li></ul><ul><li>Отношение към хората </li></ul><ul><li>Управление на по-висшестоящите </li></ul>
    46. 46. Мениджъри <ul><li>Технически грамотен мениджър е рядко срещано явление. </li></ul><ul><li>В стандартната ситуация, трябва да се развие изкувство за “управление на мениджъра” </li></ul>
    47. 47. Методи за управление <ul><li>Решението се дава на малки порции, за да може мениджърът да го “открие” сам </li></ul><ul><li>Мениджърът се обучава, как да се правят нещата </li></ul>
    48. 48. Методи за управление <ul><li>Енкапсулацията е добър подход в комуникацията с мениджъра </li></ul><ul><li>Грубата съпротива рядко води до добри резултати </li></ul><ul><li>Ако нищо не помогне, смяната на работата винаги остава като възможност </li></ul>
    49. 49. Въпроси?

    ×