58
« : 29 Апреля 2013, 23:48:55 »
Коллеги, доброго вам времени суток.
Классификация, как мне кажется, очень увлекательное занятие. Главное, что пытаясь что-то классифицировать - ощущаешь себя причастным к чему-то великому и значимому ;-) (каюсь, сам делал несколько подходов к этому делу). Но с другой стороны, всякое знание (ну или почти всякое) начинается с упорядочивания и классификации. Именно по этому я предпочел изучить доступные мне на тот момент материалы тем или иным образом относящиеся к классификации требований, попытаться их сопоставить м/у собой и понять, что Вигерс дал вполне себе нормальную схему именно требований, относящихся к программной инженерии. Конечно можно спорить с ней, обоснованно утверждать, что не всегда имеет смысл использовать все три уровня требовании в отдельно взятом проекте и заниматься строгим контролем и трассировкой м/у уровнями (хотя это делает модель требований конкретного проекта более структурированной) ... Можно так же его критиковать за то, что у него два раза встречается название "функциональные" требования, что может вносить путаницу для неподготовленного читателя. Но в любом случае она вполне себе выполняет свою задачу, особенно если мы говорим про заказную разработку... А если чем-то можно пользоваться, и оно позволяет решать имеющиеся задачи, то зачем тратить время на изобретение? Можно конечно наплодить кучу типов требований, добавить еще шкалу времени "в туда" (с) (привязав требования, например, к ЖЦ разработки). Но ничего принципиально нового это не даст. Разве только позволит детализировать и уточнить предложенную Вигерсом схему (я упорно не называю его схему классификацией, т.к. сам Вигерс, если мне не изменяет память, сам называет ее не классификацией, а "моделью", которую он использует в своей практике), ну и конечно же позволит "размять мозги" и получить творческий азарт, куда без этого :-). Но в то же время, никто не мешает, по аналогии с Вигерсом - сделать ту схему требований, которая используется в практике конкретного специалиста. Если это помогает - вперед!
Кстати, в этой презе моей, есть очень тонкое место, которое возможно не заметно на первый взгляд, хотя я думаю многие из вас об этом подумали ... А именно сравнение ТЗ по ГОСТ 34.602 которое суть ТЗ на АС (а мы помним, что есть АС) с требованиями на собственно программное обеспечение :-). Когда рисовал эту презу, меня просто терзали сомнения, стоит ли сравнивать ... но в конечном итоге подумал, кто этим заморачивается? У нас все что делают, считают АС ... и не парятся с тонкостями.
Просмотр сообщений