Софтуерни технологии
Изтегляне 3.19 Mb.
|
- Навигация на страницата:
- 14.1. Как да се наемат най-добрите софтуерни специалисти
- 14.2. Определяне на структурата и състава на работните групи
- 74.3. Управление на взаимоотношенията в работната група
- 14.7. Професионализъм и етично поведение
170 Подходът се избира в началото на възложен проект и се следва систематич- но и планирано. Предполага се активно участие на потребителя. Осъществява се не само регистриране на реакциите му при работа с междинни версии на програмния продукт, а включването му в процеса на вземане на решения в кри- тични за проекта ситуации. Реализацията на подхода изисква специални техники на разработване. Една възможна и проверена в практиката техника е еволюционното прототипиране, при което разработването на ПП се разглежда като създаване на последовател- ност от междинни ПП, всеки от които е разширение на предишния. След завър- шване на един прототип се извършва едновременно тестване на готовия прото- тип в реални условия (от потребителя) и създаване на следващия прототип (от разработчика). Освен ранно откриване на грешки използването на прототип в реална потребителска среда позволява формулирането на допълнителни изиск- вания. Съществени за успеха на подхода са: а) правилното декомпозиране на програмния продукт на прототипи, всеки
б) регламентиране на комуникациите с потребителя — честота на обсъж- данията, вземане на решения с консенсус на основата на разумни компромиси и от двете страни, поощряване на активността на потребителя и поддържане на самочувствието му на пълноценен партньор, така че практическият му опит и познаване на приложната област да доведат до избор на решения, непостижими по умозрителен път или чрез проучване на литературата. Основното преимущество на подхода за разработване с участието на пот- ребителя е, че се създава ПП, който не се нуждае от поправяне на грешки или доработване поради пропуснати или погрешно разбрани потребителски изиск- вания. Недостатък на подхода е необходимостта от овладяване на специални техники за разработване. Литература 1. Sommerville I. Software Engineering, Addison-WesIey Publ.Company, Fourth Edition, 1992. 2.Sebesta R. Concepts of Programming Languages. Benjamin/Cummings Publishing Company, Inc., 1993. 3. Boar, B. Application Prototyping. Wiley-biterscience, 1984. 4.Rzepka, W., and Y.Ohno (eds.) Requirements Engineering Environments. IEEE Computer (special issue), vol.22, No 5, May 1989. 5.Proceeding of the Symposium on Software Reusability, Seatle, Washington, April 28—30,1995. 6.Communication of the ACM. Special Issue on the Participatory Design, vol. 36, No 4, June 1993.
Софтуерът се създава от индивиди с определени физически и умствени възможности и различна психологическа нагласа. Изследването и съобразява- нето с тези личностни характеристики може да подобри организацията на рабо- тата и да повиши производителността на труда на разработчиците на софтуер [1]. От друга страна, софтуерът се използва от хора и отчитането на психологи- ческите им особености в началните фази на анализ и проектиране може да дове- де до създаване на надеждни, ефективни и удобни за използване системи. Ще се спрем накратко на някои проблеми, изследвани от софтуерната пси- хология. Ефективното управление на софтуерните проекти се основава на управле- нието на хората, продукта, процеса и проекта (т. нар. четири P's — people, product, process and project). Наредбата не е случайна. Мениджърите в софту- ерното производство са осъзнали, че подценяването на човешкия фактор може да застраши успешната реализация на всеки проект. Това е обяснението за съ- живения интерес към софтуерната психология. Известният Software Engineering Institute разработи СММ-модела [2], осигуряващ мярка за глобалната ефектив- ност на дейностите в дадена софтуерна организация чрез определяне на раз- лични нива на зрелост (вж. глава 8.). Беше разработено и разширение на модела — РМ-СММ (People Management Capability Maturity Model), предназначение- то на което е "да подобри готовността на софтуерните организации да осъщес- твяват приложения с нарастваща сложност чрез привличане, обучаване, моти- виране и задържане на талантите, необходими за подобряване на техните въз- можности за разработване на софтуер" [3]. Ще разгледаме някои от ключовите дейности, определени от този РМ-СММ модел. 14.1. Как да се наемат най-добрите софтуерни специалисти Всяка софтуерна организация трябва да има кадрова политика, регламен- тираща принципите и процедурите по назначаване и освобождаване на служи- тели, системата от поощрения и наказания, правилата за издигане в служебната 172
йерархия и др. Някои страни на тази политика зависят от това, че създаването на софтуер не е изцяло производствена дейност, а има елементи и на творческа, интелектуална дейност. Набирането на кадри (recruitment) обхваща всички дейности, насочени към намиране и назначаване на най-подходящия кандидат за определена длъжност. Разглежданите кандидатури могат да бъдат от самата организация (internal recruitment) или външни (external recruitment) [4]. При вътрешното набиране след определяне на длъжностните характе- ристики за вакантните позиции се разглеждат възможностите за преназначава- не. Използваните техники могат да бъдат: поддържане на информация за всички служители (worker pool repository) професионални знания и умения, квалификация, опит от предишни софтуерни проекти и т. н. Тази информация може да се използва или за допълване на пос- тоянно действащи екипи за разработване (за да се удовлетворят специфичните изисквания на новия проект), или за динамично сформираните екипи за всеки нов проект в организацията. вътрешен конкурс. Свободните места се обявяват и всички служители, ко- ито се интересуват, могат да подават съответните документи, като в някои слу- чаи се изисква и съгласието на непосредствения ръководител на кандидата; назначаване на основа на препоръки (employee referalls). При външното набиране целта е да се потърсят и назначат нови за софту-
За избор на подходящи служители се предлага използването на т. нар. пси- хологически профили. Психологическият профил е съвкупност от индивидуал- ни личностни качества, за които се смята, че са важни за съответната професия. Създадени са модели на профил за програмисти. При назначаване чрез тестове се изследва психологическият профил на всеки кандидат и се сравнява с този на най-добрите професионалисти във фирмата. Реалното използване на този под- ход изисква разработване на адекватни тестове, съобразени с националните, културни и професионални различия. Не се препоръчва изборът на софтуерни специалисти да се основава изця- ло на психологическия профил поради следните причини:
173  "придирчивост" са полезни за функциите на отговорника по тестване;
— тестовете за психопрофил могат да бъдат разучени предварително и интелигентните кандидати да отговарят заблуждаващо така, че да се получи ис- каният профил. Друг подход е предложен от Уейнбърг. Той предлага изследването само на две характеристики, които смята за задължителни за работещите в областта на софтуерните технологии: адаптивност и устойчивост към стрес. Под адаптивност се разбира способността за бързо приспособяване към изменящата се среда. За програмистите от началото на 80-те години беше доста- тъчно да изучат една операционна система и един език за програмиране и да ги ползват до пенсионирането си. Сегашните разработчици на софтуер са принуде- ни да усвояват непрекъснато нови подходи и съответните им техники. За успеш- на професионална изява е необходимо личността да има психологическата нагла- са, че за реализацията на всеки проект ще е необходимо допълнително обучение. Статистическите изследвания показват, че разработването на софтуер е из- между десетте най-застрашени от стрес занимания в съвременното общество. Със съдействието на професионални организации в САЩ и Япония са проведе- ни изследвания и са идентифицирани следните стресови фактори [5]:
— неудовлетвореност от системата за материално поощряване и връзка свършена работа — заплащане; — бърза промяна в хардуерните и софтуерните технологии. Индивидуалната устойчивост към стрес, съчетана с целенасочените менид- жърски действия за контролиране на стресовите фактори, би осигурила висока производителност на създателите на софтуер. 14.2. Определяне на структурата и състава на работните групи Ще разгледаме някои основни принципи за сформирането на работните групи. 174 Идентифицирани са четири типа комуникативно поведение при изпълне- ние на групови дейности: обособяващ се, водим, лидер и сътруднчащ. Основното за хората с обособяващ се тип комуникативно поведение е устойчивата нагласа към индивидуализъм. При разпределението на функциите на такъв член на групата трябва да се възлагат задачи, които са относително самостоятелни и усамотяването няма да повлияе отрицателно върху изпълнява- ния проект. Хората с водим тип комуникативно поведение имат подчертана нагласа към доброволно подчинение и силно изразено предпочитание към изпълнение на възложена работа под непосредственото ръководство на лидера на групата. Предполага се, че установката към водимо сътрудничество се дължи на кон- формистката природа на личността или на видимо преобладаваща внушаемост. Анализът на лидерския тип комуникативно поведение е изключително важно за планиране на дейността на групата. Психологическит профил на лидерите е с нагласа към доминиране и предполага доброволно подчинение на останалите. Хората с предпочитания към сътрудничество показват стабилен стремеж към колективно решаване на общата задача, бързо ориентиране към рационал- ните решения благодарение на повишената ориентационна способност на лич- ността. В този случай е характерна готовността да се приемат и следват разум- ните решения и да се организира работата в групата за тяхното осъществяване. На основата на типовете поведение са формулирани и някои препоръки за груповата дейност на разработчиците на софтуер. Ефективна работа може да се постигне, като на всеки член се възлагат задачи, които са съобразени със стила на неговото поведение. Смята се, че поради склонността си към самоизолиране на обособяващия се тип трябва да се възлагат задачи, които не изискват взаимодействие и чести контакти с други хора. Например на разработчик от този тип не бива да се възлагат преговорите с потребителите. За хората от водим тип са подходящи изпълнителски дейности. Пълната удовлетвореност от работата при тях се свързва с успеха от изпълнението на възложената задача. На хората с ярко изразен лидерски тип ориентация трябва да се възлагат по-сложни задачи и ръководни функции поради нагласата им към поемане на отговорност, добра ориентация и организаторски способности. Например те са подходящи за осъществяване на изследователско прототипиране, за експер- тна оценка на междинен софтуерен продукт, за определяне каква CASE-среда да се закупи и др. Много от задачите при създаването на софтуер са на едно ниво на слож- ност и най-успешно се поемат от хора със сътрудничащ тип комуникативно поведение. Числеността и разпределението на задълженията в групата зависят от размера и сложността на конкретния софтуерен проект, който ще се осъществява. Препоръчва се да се определи съставът на групата чрез "длъжностни хактерис- тики" за дейностите, които ще се извършват, и след това да се изберат членове- те на групата с отчитане на: — възможността и желанието да се извършва дадена дейност. Някои пред- почитат изпълняването на познати, добре овладени процедури, а други — екс- периментирането с нови подходи и техники и проверка на нови идеи; 175
74.3. Управление на взаимоотношенията в работната група Разработването на софтуер се извършва в групи, чиито членове са обеди- нени от обща социална дейност и се намират в непосредствено лично общува- не, което е основа за възникване на емоционални отношения, групови норми и групови процеси. От психологическа гледна точка са определени две нива на взаимоотношения-
Някои задължения и права на членовете на групата са:
За цялостното функциониране на групата отговаря избиран или назначаван ръководител (мениджър). При определянето му се вземат предвид две групи условия — обективни (устойчиво централно положение в групата, лидерски тип комуникативна ориентация) и субективни — добре изразени и стабилни личностни качества, като висока степен на владеене на знания в областта и опит в прилагането им, авторитет сред членовете на групата, организаторски спо- собности, приемлива ценностна ориентация. Някои от задълженията на мениджъра са:
детайлизация;
176 ние). Някои от осъществяваните контакти могат да бъдат делегирани и на друг член на групата, който има персонални връзки или чията работа съществено зависи от външните контрагенти. Най-важни за проекта са връзките с потреби- телите и те трябва да бъдат определени. Могат да се разграничат четири вида управленски профила:
Добрият мениджър може да използва различни стилове в отношенията си с различни хора и в зависимост от конкретната ситуация. Психологическият климат е важен за производителността на труда и мени- джърът трябва да се опитва да го осигури чрез подходящи управленски техники Една от тях е разрешаване на конфликти. Различия в мненията, целите, приоритетите, подходите и др. могат да дове- дат до спорове, съперничество и конфликти. Конфликтите могат да се разреша- ват чрез арбитраж (изслушване на страните и вземане на решение), постигане на съгласие на основата на правила за работа, представяне на различията и опит за преодоляването им чрез взаимни компромиси или реорганизиране на работата така, че да се ограничат контактите между каращите се страни. Основна функция на мениджъра е да организира изпълнението на опреде- лени задачи, насочвайки подчинените си и отчитайки мотивацията им. Фактори, определящи мотивацията, могат да бъдат:
За да поддържа високо ниво на мотивираност, мениджърът трябва да се съобразява с тези фактори и да се опитва да ги контролира. Мениджърът носи отговорността за проекта като цяло, но той може да де- легира част от правата и задълженията си на други членове на работната група. Обикновено задълженията са за свършване на определена работа, а правата — за вземане на самостоятелни решения, свързани с изпълнението й. Преимущес- тво на делегирането е, че мениджърът може да се съсредоточи върху същински- те управленски функции, а членовете на групата са с повишена мотивация, за- щото се чувстват оценени, самостоятелни и отговорни. Мотивацията на участниците зависи и от стила на планиране и контроли- ране на работата. Продължителността на планирания период и честотата на про- 177
верките трябва да съответстват на квалификацията и опита на всеки участник и
на важността на изпълняваната от него задача. Разработването на софтуер в група изисква съобразяването с всички спо- менати по-горе управленски аспекти. Продължителната работа на група в един и същ състав може да има и ня- кои недостатъци. Нивото на „сработеност" може да бъде толкова високо, че да не може да се смени ръководителят на групата; да се допуска вземане на реше- ния без обсъждане на всички възможности или пък да не се проверява регуляр- но и систематично количеството и качеството на работата на членовете на гру- пата. За преодоляване на т. нар. групово мислене, което ограничава инициатив- ността и критичността към приеманите решения, се препоръчват специални уп- равленски техники — организиране на мозъчни атаки (brainstorm обсъждания) с поощряване на нестандартните идеи; използване на външни експерти за пара- лелни проверки и сравняване на резултатите и др. В [6] е предложено така нареченото egoless programming. Това е стил на разработване, при който всички софтуерни продукти (спецификации, проекти, програми, документация и др.) се разглеждат като собственост на групата, не- зависимо от кой конкретен неин член са създавани. Те могат да се изследват обективно и да се променят, без да се засяга нечие самочувствие. Този подход преодолява ,"когнитивния дисонанс", който се изразява в склонността на всеки човек да приписва заслугите за успехите на себе си, а причините за провалите да търси у другите. Колективната отговорност за разработването и резултатите от него ги подобряват значително. 14.4. Организиране на комуникациите в групата Според едно изследване на IBM разпределението на работното време на софтуерните специалисти е 50% за комуникации, 30% за самостоятелна работа и 20% — за други дейности. Затова и комуникациите между членовете на гру- пата трябва да се регламентират така, че да се осигури ефективността им. Формите и интензивността на контактите зависят от: — числеността на групата. За група от N членове възможните контакти са N(N-1)/2 ;
комуникативност. Регламентираните формални контакти могат да бъдат централизирани (чрез координатор) или свободни (на всеки със всеки). При първия вид организация се определя координатор, който приема всички съобщения и решава към кои членове на групата да ги пренасочи. Тази форма се предпочита за неголеми групи и съществени за успеха й са личностните ка- чества на координатора, като информираност, бързина на реакцията, акурат- ност и др. Координиращото лице може да поеме и допълнителни функции, като присвояване на приоритет на съобщенията, документиране и архивиране на разменяната информация. 178
При втория вид организация всеки член на групата може да общува дирек- тно с всички останали. Недостатък на тази форма е големият поток неструкту- рирана информация, който изисква допълнително време за класифициране на съобщенията и може да забави обработката и очакваните като реакция дейст- вия. 14.5. Организиране на сбирки и заседания на групата Сбирките са форма на комуникация, която поддържа колективния стил. Цел- та им може да бъде анализиране на текущото състояние на проекта, информира- не на участниците за настъпили изменения, вземане на решения в случаите, кога- то е необходимо обсъждане и съобразяване с различни гледни точки и т. н. Няма правила за броя, типа и лродължителността на провежданите сбирки, но са формулирани някои препоръки [7], следването на които би повишило ефективността на работа. а) планиране на сбирката Преди всичко трябва да се определи необходимо ли е провеждането на
б) провеждане на сбирката .3a ефективното протичане се определя водещ, който:
в) закриване на сбирката Сбирката се прекратява, когато свърши заплануваното време, когато се изчерпи дневният ред или когато групата няма ресурси да продължи. Задължи- телно е резюмиране на постигнатите резултати и взетите решения и насрочване на следваща сбирка, ако е необходимо. 14.6. Ергономика Основната цел на ергономиката е да изследва и да предложи подходяща работна среда, така че човешките ресурси да се използват по най-ефективен начин. Ще се спрем накратко на някои ергономични фактори, свързани с процеса на разработване на софтуера. Организацията на работното място влияе в най-голяма степен на произво- дителността. От значение са:
179
изисквания са 9 кв. м обща площ и 2,7 кв. м работна площ за всяко лице. Нару- шаването на тези изисквания би трябвало да се компенсира с подобряване на някои от останалите. Работните места могат да бъдат в общо помещение или в индивидуални стаи
Като ергономични фактори могат да се разглеждат и установените в софту- ерната фирма процедури и правила за осъществяване на спомагателните дей- ности — административни, финансово-счетоводни, снабдителски и др. 14.7. Професионализъм и етично поведение В специализираната литература са описани случаи, в които софтуерни спе- циалисти съзнателно са заблудили свои партньори, предоставяйки им неверна информация за извършена работа, за предполагаема продължителност или тру- доемкост на предстоящ софтуерен проект, за степента на завършеност или за качествата на ПП, за приложимостта на даден софтуерен продукт за решаване на конкретен проблем и др. В резултат са били взети решения, облагодетелства- щи неправомерно лицата или организацията, която те представят. Проблемът за професионалната етика е дискутиран със софтуерни специ- алисти от цял свят [8]. Много от тях не само са потвърдили, че такива случаи са често явление, но и смятат, че описаното поведение е оправдано в повечето случаи. Това не са просто примери за лоши управленски подходи, а посочване на по-сериозен проблем — липса на правила и стандарти за етично пове- дение. Във всяка организация се натрупват прецеденти и повтарящи се реак- ции и те се предават от по-опитните на пo~младите софтуерни специалисти чрез действия и недокументирани практики. Например по-младите програмисти се запознават със станалото популярно правило за оценяване на обема или на стойността на извършена работа: прави се оценката, след това се удвоява и накрая се добавят още 30%. Понякога се прилага и принципът на Мърфи за определяне на необходимото време за определена работа: прави се оценката, удвоява се и се сменя мерната единица със следващата (например от час — на ден, от ден — на седмица и т. н.). Такова поведение и стил на работа обикновено се улесняват от липсата на стандартизирано управление на софтуерните проекти, на процедури за оценка на качеството, оценка на разходите и др., които да са широко разпространени в Каталог: fmi -> fmi-ftp-upload-folder -> 4%20Semestur%202005 -> Predmeti -> AMP AMP -> Спецификация на софтуерен проект fmi-ftp-upload-folder -> Oracle e-business Suite Модул Financials, подмодул Fixed Assets fmi-ftp-upload-folder -> Бази от данни Упражнение 9 fmi-ftp-upload-folder -> Basic structures напишете pl/sql блок, който въвежда номера в таблицата messages AMP -> Спецификация на изискванията AMP -> 10. Управление на документацията Документация предназначена за разработчиците AMP -> 1. Анализ на риска Изтегляне 3.19 Mb. Сподели с приятели:
|
