Analīzes-paradīzes meklējumos

Ksenija Lāce

Ir viedokļi

Analīzes-paradīzes meklējumos

Ksenija Lāce

Aizej tur, nezin kur, atnes to - nezin koProgrammatūras prasību specifikācija.... varu saderēt, ka lasot šos vārdus katrs no Jums iedomājas kaut ko savu - lietotāju vai sistēmas prasības, augsta līmeņa vīziju vai detalizētu projektējumu, dažādus noformējuma formātus, dažādas ilustrējošas diagrammas, utt.. Uzdevums pierādīt Ferma teorēmu ir nieks salīdzinājumā ar uzdevumu atrast divas prasību specifikācijas ar vienādu pieeju diviem dažādiem risinājumiem. Jo katrā projektā ir savas nianses, kas diemžēl bieži nozīmē to, ka analīze tiek uzsākta no tukšas vietas, neizmantojot jau atstrādātās metodes un sagataves, atkārtojot vecas un pieļaujot jaunas kļūdas.

Aleksandrs Baikins Krievija

Analītiķu biedrības „Uml2.ru” dibinātājs, kompānijas

„Mototelekoms” Izstrādes, testēšanas un dokumentēšanas

nodaļas vadītājs

Jurijs Vedenins,Baltkrievija

Sistēmanalītiķu biedrības „Analyst.by” dibinātājs,

vadošais sistēmanalītiķis kompānijā „KRV7”

Bet varbūt tomēr ir iespējams vienoties par standarta pieeju programmatūras prasību specifikācijas izstrādei un izstrādāt specifikācijas sagatavi, kuru varētu izmantot jebkurā projektā? Varbūt kaut kur eksistē šāda analīzes paradīze, kur analītiķi dzīvo ilgi un laimīgi, iekļaujoties projekta termiņos un apmierinot visu iesaistīto pušu intereses?

Trīs spēkavīri aiz septiņām jūrāmKā jau vienmēr cilvēces vēsturē, šo paradīzi nolēmu meklēt aiz septiņām jūrām, vēršoties pēc padoma un pieredzes pie saviem kolēģiem no citām valstīm (pateicamies par laipnu attieksmi un atsaucību!!!).

Adrians Rids Lielbritānija

IIBA Lielbritānijas nodaļas marketinga direktors,

kompānijas „Blackmetric Business Solutions” direktors

Adrians: I have been working in Business Analysis in one form or another for around 10 years now.  In fact, I started doing business analysis before I even knew what the term meant!  I started my career as a BA in the

financial services sector, and after a few job moves and promotions decided to branch out and start my own company.  I now run Blackmetric Business Solutions, which is a company that provides business analysis consultancy to organisations large and small, and also provides BA training solutions.   I also passionately believe that the IIBA is an essential part of the BA community, and hold the position of Marketing Director for the UK Chapter of the IIBA. You can contact me, and read my blog at: www.adrianreed.co.uk.

Jurijs: Анализом в том или ином виде занимаюсь уже около 6-7 лет. Был программистом в крупной компании, тогда в ней ещё не было аналитиков, и в какой-то момент, представилась возможность

таковым стать, причем по собственной же инициативе: я сам стал описывать с помощью моделей то, что мы делали, чтобы лучше это понимать. Собственно, начальство оказалось не против, а очень даже «за», ну так и понеслось. Потом проект вырос до 80 человек, количество аналитиков до 10, а я стал главным аналитиком в этой славной команде.

Сейчас у меня своя фирма, мы занимаемся консалтингом и обучением в области бизнес-анализа и юзабилити, так что планы на будущее – ого-го (:

Aleksandrs: Как многие ИТ специалисты я начинал с поддержки различных программ в маленькой не ИТ компании, параллельно работал начинающим программистом в другой небольшой компании DataX/FLORIN, и учился в МГТУ им. Баумана. Во Флорине я выполнил множество проектов, как в

одиночку, так в составе команды, и дорос до Ведущего Разработчика. Дальше понял, что расти в данной компании уже некуда, и перешел в фирму, которая занималась торговлей ценными бумагами на американском рынке, там я совмещал должность Ведущего Разработчика и Аналитика. Далее был незабываемый 2ух летний период в компании Egar, где я дорос до Старшего Аналитика и Менеджера Проектов и получил очень большой опыт на различных проектах. Потом немного меня поматало по двум компаниям - Сервис Плюс Арт и НТЦ ИРМ . В последней я руководил портфелем из 20 проектов и 5 Менеджерами Проектов. В итоге я оказался в компании Автомир, где стоят интересные задачи по стратегическому анализу и выстраиванию архитектуры предприятия с численностью персонала в 5 000 сотрудников. По мере того, как все интересные задачи в Автомире были сделаны, перешел в компанию Мототелеком, в которой руководил отделом разработки, где мы делали интересные решения для ip-телефонии и видеоконференцсвязи. Сейчас я работаю в средней компании, занимающейся оптовой торговлей, где я руковожу ИТ подразделением. В дальнейшем я уже планирую развиваться в этом направлении.

Daži vārdi par sevi – kāpēc saistījāt savu dzīvi ar analīzi, darba pieredze un nākotnes plāni?

I started doing business analysis

before I even knew what the term meant!

планы на будущее – ого-го (:

Ir viedokļi

Adrians: For me the word "specification" means "articulating a business or user need, goal, or requirement in enough detail so that the target audience can adequately understand it, and so that business stakeholders can verify and validate it".  I know that's a very vague explanation, so I'll expand further:

I believe BAs can add significant amount of value to projects by being involved early.  At this time, we'll be involved in specifying business goals, objectives and critical success factors.  The types of specification document we produce at this stage will be at a very high level of abstraction.  However, this is our opportunity to work with our business stakeholders to fully understand the problem or opportunity that is being addressed!

If this is done right, then the rest of the project is much easier.  Of course, as the project progresses, we'll need to produce very detailed requirement specifications.  The level of detail will depend on the project -- to give you an example, in my experience Waterfall projects require very detailed specifications, whereas Agile projects may rely more on interactions.  A photo of a hand-drawn diagram on a whiteboard can be a very valuable artefact.

I believe the other important thing to consider is the audience, i.e. the consumer of the specification.  It's important that we write the specification in a way that they'll find readable.  I find that creating different "views" on the same requirements set can be useful for this -- to give an example, often I'll separate out the data, process and UI requirements.  They can then be sent to different stakeholder groups for comment.  It's much easier for stakeholders to comment on smaller, more succinct documents, rather than 1,000 page documents!

I use a variety of specification techniques/standards. I particularly like BPMN for process modelling, context diagrams, use cases, and data modelling.  I also think BABOK provides a useful reference point.  However I also like trying out new and different techniques!

Jurijs: Спецификация – это более надежный (чем голос, лог чата и переписка) способ передачи информации в пространстве и во времени. Используем адаптированные стандарты ГОСТ и IEEE. Главное преимущество – синхронизация «карт реальности» для всех заинтересованных лиц.

Главный недостаток – в тот момент, когда спека написана, она сразу же становится неактуальной.

Aleksandrs: Скажу просто: спецификация требований - это согласованное описание на формальном языке того, что должна делать Система после того, как ее разработают.Мне нравятся западные шаблоны SRS - IEEE или по Вигерсу. Иногда приходится писать по ГОСТ34

в основном для гос заказов.Основной рецепт по шаблону такой: необходимо взять стандартный шаблон (из любого стандарта) и уже адаптировать его под проект (выкинув лишнее и добавив необходимое), согласовав формат с заказчиком и командой.

Ko Jūs saprotat ar programmatūras prasību specifikāciju (vienā teikumā)? Kāpēc tā ir svarīga programmatūras izstrādes projektos?

Word "specification" means "articulating a business or user need, goal, or requirement in enough detail so that the target audience can adequately understand it, and so that business stakeholders can verify and validate it"

/Adrians/

Спецификация требований - это согласованное описание на формальном языке того, что должна делать Система после того, как ее разработают.

/Aleksandrs/

Спецификация – это более надежный (чем голос, лог чата и переписка) способ передачи информации в пространстве и во времени.

/Jurijs/

Ir viedokļi

Adrians: Again, in my experience it varies by project and by organisation.  Generally, the BA will elicit requirements, normally through direct interaction with stakeholders.  In addition, a BA will carry out document analysis (e.g. looking at existing system generated reports) and for existing systems will refer

back to any previous specifications that are available.

Whilst there are many requirements management systems available, the vast majority of the organisations I have worked with use informal methods (Word, Excel, SharePoint) for managing requirements.  However, I have noticed that interest in more formal requirements management software is increasing.

Jurijs: Требования у нас собирают аналитики. Иногда на самом начальном этапе это могут делать продавцы (сэйлы) или менеджеры, т.к. они зачастую принимают участие в первом контакте с клиентом и аналитик может ещё просто быть не назначен на проект.

При сборе (во время интервью, опросов и собеседований) требования обычно документируются в блокнот, а затем переносятся уже в электронную форму (вики-система, ворд + шарепоинт и т.д.), но если есть возможность и позволяет время, то можем и сразу фиксировать результаты сбора в электрооном виде.

Спецификацию зачастую перед отправкой клиенту вычитывает либо другой аналитик, либо менеджер. Ну а затем она отправляется клиенту на согласование. Если спецификация обещает быть большой, то мы изначально договариваемся на поэтапное согласование.

Aleksandrs: В последнее время - это Ворд и ЮМЛ-тулз (Сракс ЕА), стараюсь сразу писать ТЗ и по частям согласовывать ТЗ. В свое время использовал Вики (Конфлюенс) для документирования требований.

Kā notiek programmatūras prasību specifikācijas izstrādes process? Vai tiek izmantoti kādi procesu standarti?

Kāds ir programmatūras prasību specifikācijas detalizācijas līmenis? Vai tiek apskatītas gan lietotāju prasības, gan prasības sistēmai?

Aleksandrs: В последнее время я пишу ТЗ на уровне пользовательских требований в виде Ви или простых требваний: Пользователь должен имать возможность ... Это обычно достаточно для Заказчика. Если что-то непонятно разработчикам, то детализирую на уровне системных требований.

Jurijs: Иногда применяются оба вида, в зависимости от проекта и используемой системы управления требованиями.

Adrians: This is a very good question.  And it's a difficult question to answer!  I generally try to write specifications from the perspective of the user and the business.  My view is that a good set of requirements should be able to be fulfilled by a number of solutions.... and in many cases a completely

manual solution might be viable. Therefore it can be dangerous to assume that there will be an automated system in place.  

However, in reality, in many cases we'll be working in an organisation where IT systems already exist.  In this case, it does sometimes make sense to include some selective system requirements.  However, I firmly believe that a BA should stay on the business side of the requirements, rather than the IT System side of the requirements.  This is the difference between a Business Analyst and an IT Systems Analyst.

The "grey areas" where (in my experience) it's necessary for a BA to consider the detailed IT system requirements are: ->

Ir viedokļi

Adrians: ->

1. Data migration:  When specifying how data should be extracted, transformed and loaded, it's often important to know the specifics of the current and target systems.  Without knowing the physical data model and physical data mappings, this would be impossible.  In my experience, this works best with a BA and IT Systems Analyst working together.  The IT Systems Analyst will know the physical data.. and the BA will be responsible for defining or finding out the significance and meaning of that data.  For example, an IT Systems Analyst may see that there is a field called "Client Status" with possible values of Gold, Silver and Bronze. But they might not know what that means.  The BA can work with the business to understand the processes that involve the data... and may find out that this refers to the value of the customer (e.g. "Gold customers are VIPs")

2. Interfaces: For the same reasons as above, whenever system-to-system interfaces are defined, knowledge of the data interchange is required.

I'm sure there are other areas too, but these are the ones that spring to mind.

Jurijs: Это всё (и список разделов, и формат, и уровень детализации) зависит от проекта: от всех заинтересованных лиц (заказчик, разработчики, тестировщики), от принятых в организации правил, стандартов, и, конечно же, от специфики проекта.

Т.е. у нас нет четкого списка, зато есть определенные правила составления. Например: в спецификации должно быть только то, что необходимо в данном проекте, все неактуальные для данного проекта разделы надо удалять.

Например, в проектах с несложной бизнес-логикой, мы обычно применяем визуальный кликабельный прототип + легковесное описание проекта (похожее на vision).

Aleksandrs: Как я сказал, что я предпочитаю шаблон Вигерса или IEEE.

Vai tiek izmantota kāda programmatūras prasību specifikācijas sagatave? Kādas ir tās galvenās sadaļas un kāds formāts?

Adrians: It really depends on the project, and also the organisation.  I always try to include diagrams, as I feel they help to convey information with more precision.  I find this particularly important for dispersed teams where multiple languages are spoken.  It's a great way of sharing understanding!

In terms of specification templates generally, I'm involved with a working group that have released a completely free set of Requirement Templates into the public domain.  You would be more than welcome to download them from www.pragnalysis.com.

Adrians: From users: "This is too much for me to read!" (which can be avoided by splitting the requirements into chunks, using diagrams, and keeping the documents as light-weight as possible).

From developers: "These two requirements conflict!"  (which can be avoided by developing models.  For example, a well constructed data model often helps to drive out inconsistencies).

Kādas ir galvenās sūdzības par specifikāciju no klientu puses un kādas no izstrādātāju puses?

Ir viedokļi

Jurijs: Со стороны команды разработки: слишком большая, слишком сложная для восприятия, неактуальная, с ошибками.

Со стороны клиента: слишком большая или слишком сложная (но они этого не говорят вслух, а просто как результат её не вычитывают), неправильная.

Aleksandrs: Клиент, как правило, не предъявляет претензий к моему ТЗ, только в плане дополнений или исправлений. А вот разработчики ... Им конечно же лучше прописать все как можно детальнее, но я старюсь проговаривать с ними ТЗ, если что-то действительно непонятно ли туманно, то пишу

подробнее.

Pasakas laimīgās beigas?Protams nav pareizi spriest pēc 3 ekspertu viedokļa, bet vismaz pagaidām atrast analīzes paradīzi man neizdevās. Mums visiem ir aptuveni vienādas problēmas un vienkārši noskatīties risinājumus no ārzemju kolēģiem nesanāks. Bet ir liels prieks, ka cilvēki aktīvisti eksistē visos pasaules stūrīšos, cīņa par analīzes kvalitāti turpinās, un es ļoti ceru, ka uzvara būs mūsu, analītiķu, pusē!

Vienmēr jāatceras par to, ka standarti un sagataves nav galvenais nosacījums kvalitatīvas analīzes veikšanai. Galvenais ir mūsu domāšanas veids un kvēloša vēlme rādīt vērtību. Kā arī mans personiskais viedoklis ir tas, ka analīzes lauciņā mēs neesam atpalikuši no citiem un mums ir labas izredzes analīzes paradīzi nodibināt pie sevis! :)

Analīzes lauciņā mēs neesam atpalikuši no citiem un mums ir labas izredzes analīzes paradīzi nodibināt

pie sevis! :)