Professional Documents
Culture Documents
Resumo
As empresas de desenvolvimento de sistemas de pequeno porte tm seus recursos materiais e
humanos tanto quanto sobrecarregados, diante da demanda a ela submetida. Porm a no
implementao da engenharia de requisitos como fator crtico de sucesso no desenvolvimento
de software, ou por falta de cultura ou at por desconhecimento da sua existncia, levam
projetos de suma relevncia ao insucesso e aumentando ainda mais a quantidade de casos dos
sistemas inacabados, conseqentemente desperdiando tempo, recursos financeiros e no
atendendo as necessidades dos clientes e nem do desenvolvedor.
Palavras-chave: Engenharia de Requisitos, Engenharia de Software, pequenas empresas.
Abstract
The systems development companies of small size have their material and human resources as
much as overloaded, in front of the demand to her submitted. However the not implementation
of the requirements engineering as critical factor of success in the software development, or
for lack of culture or until for ignorance of your existence, carry projects of vanishes
relevance to the failure and even increasing the quantity of cases of the unfinished systems,
consequently wasting time, financial resources and not attending the needs to clients and
neither of the developer.
Key words: Requirements engineering, Software Engineering, small size companies.
1.
OBJETIVO
Este trabalho tem por objetivo principal apresentar os mtodos da engenharia de software, no mbito
da engenharia de requisitos, como processo fundamental e fator crtico de sucesso no
desenvolvimento de software atravs de aplicao de um modelo estruturado para resoluo de
problemas / questes apresentadas pelos clientes / usurios.
Este artigo pretende contribuir com outros estudos de implementao da Engenharia de Requisitos
para pequenas organizaes, porm de grande participao na comercializao de software.
2. INTRODUO
Num ambiente competitivo e de mudana cada vez mais complexo, a gesto adequada da
Informao assume uma importncia decisiva no processo de tomada de deciso nas organizaes.
Tratando-se de um tema simultaneamente abrangente e especializado, a adoo da Engenharia de
Requisitos como linha base da Gesto da Informao, possibilitar, no s desenvolver e consolidar
3. RELEVNCIA
Segundo o Ministrio da Cincia e Tecnologia [MCT02], a participao de mercado das micros,
pequenas e mdias empresas desenvolvedoras de software correspondem 65,1% do total (Tabela1).
Diante da dimenso deste mercado ainda em franca expanso, que motivou a prestar ateno
especial para este tema.
Tabela 1- Porte das Organizaes, segundo comercializao bruta anual (2000).
Porte das Organizaes
Portes
Micro
Pequena
Mdia
Grande
%
16,5
25,3
23,3
34,9
Atualmente com a viso global permitindo a participao nas exportaes de software para outros
pases, cada vez mais a qualidade no processo de desenvolvimento e do produto de software ganha
maior observao e adoo das melhores prticas e solues tecnolgicas que atendam os requisitos
estabelecidos.
Considerado por Brooks [BROOKS87] como problema essencial:
A parte mais difcil do desenvolvimento de software decidir precisamente o que ser
desenvolvido. Nenhuma outra parte do trabalho to difcil quanto estabelecer (definir) os detalhes
tcnicos necessrios incluindo todas as interfaces para pessoas, mquinas e para outros sistemas de
software. Nenhuma outra parte do trabalho to possvel de ocasionar erros no sistema como essa.
Nenhuma outra parte to difcil de ser posteriormente consertada.
Para compreender melhor a engenharia de requisitos, veremos alguns conceitos e objetivos a seguir
da engenharia de software.
4. ENGENHARIA DE SOFTWARE
Segundo Rezende [REZENDE99], Engenharia a arte das construes, embasada no conhecimento
cientfico e emprico, adequada ao atendimento das necessidades humanas.
Engenharia de Software a metodologia de desenvolvimento e manuteno de sistemas modulares,
com as seguintes caractersticas [REZENDE99]:
-
6. CRISE DO SOFTWARE
Para generalizar o termo, ocorre quando o software no satisfaz seus envolvidos, sejam clientes e/ou
usurios, desenvolvedores ou empresa [REZENDE99].
A expresso Crise do Software, que comeou a ser utilizada na dcada de 60, tem historicamente
aludido a um conjunto de problemas recorrentemente enfrentados no processo de desenvolvimento
(Construo, implantao e manuteno) de software [MAFFEO92].
Esses problemas no se referem apenas a programas que no funcionam.Na verdade, a chamada
Crise do Software abrange todos os problemas relacionados a [REZENDE99]:
-
sistema, e somente percebidos na implantao do sistema, gerando assim uma fase de manuteno e
correo do software interminvel, excedendo no custo desta fase (Tabela 2) e alongando o prazo de
trmino substancialmente (Tabela 3).
Tabela 2- Excedentes de Custo [LEE02].
Excedentes de Custo
% Excedente de Custo
<20%
21% - 50%
51% - 100%
101% - 200%
201% - 400%
>400%
Excedente de Prazo
% de
Respostas
15,5%
31,5%
29,6%
10,2%
8,8%
4,4%
% Excedente de Prazo
<20%
21% - 50%
51% - 100%
101% - 200%
201% - 400%
>400%
% de
Respostas
13,9%
18,3%
20,0%
35,5%
11,2%
1,1%
O custo do desenvolvimento do software varia de acordo com cada fase de seu processo (Tabela 4).
No entanto com a implementao da engenhara de requisitos, os erros de levantamento de requisitos
identificados na fase de anlise do projeto de software, reduz o custo para correo (Tabela 5).
Tabela 4- Custos em projeto de software por fase de desenvolvimento [LEE02].
Custos em projeto de software por Fase de Desenvolvimento
Etapa de Trabalho
Anlise de Requisitos
Desenho
Programao
Testes
Manuteno
%
3
8
7
15
67
Anlise de Requisitos
Desenho
Teste do Cdigo e da Unidade
Teste de Integrao
Validao e Documentao
Manuteno Operacional
% de
Erros
Erros
Custo
Desvios
Introduzidos
encontrados
Relativo para
($)
5
25
10
50
10
(%)
55
30
(%)
18
10
Correo
1,0
1,0 - 1,5
10
50
1,0 - 5,0
22
10 100
7. ANTICRISE DO SOFTWARE
Segundo Rezende [REZENDE99], pode-se resumir que a anticrise a unio e trabalho conjunto e
harmonioso de trs elementos: Empresa (Alta Administrao), Cliente e/ou usurio e a unidade de
informtica (Desenvolvedores de solues).
E na prtica, cabe principalmente unidade de informtica aceitar este conceito e fazer o possvel
para a efetivao desta tese (Anticrise), utilizando-se de todos os recursos disponveis para tal.
A Unidade de informtica um dos principais agentes de mudana nas organizaes, preocupandose com o negcio empresarial, auxiliando efetivamente os gestores nos processos de tomada de
deciso, tanto operacionais, como gerenciais e estratgicas.
8. QUALIDADE DE SOFTWARE
Atingir um alto nvel de qualidade de produto ou servio o objetivo da maioria das organizaes.
Atualmente no mais aceitvel entregar produtos com baixa qualidade e reparar os problemas e as
deficincias depois que os produtos foram entregues ao cliente. [SOMMERVILLE03]
Segundo Machado [MACHADO01], para muitos engenheiros de software, a qualidade do processo
de software to importante quanto qualidade do produto. Assim na dcada de 90 houve uma
grande preocupao com a modelagem e melhorias no processo de software. Abordagens
importantes como as normas ISO 9000 e a ISO / IEC 12207, o modelo CMM (Capability Maturity
Model) e o SPICE (Software Process Improvement and Capability dEtermination) sugerem que
melhorando o processo de software, podemos melhorar a qualidade dos produtos.
A qualidade conseqncia dos processos, das pessoas e da tecnologia. A relao entre e qualidade
do produto e cada um desses fatores complexa. Por isso, muito mais difcil controlar o grau de
qualidade do produto do que controlar os requisitos.[PDUA03]
Prev-se que na primeira dcada dos anos 2000, aps ajustarem seus processos para a produo de
software de qualidade dentro de prazos e oramentos confiveis, as organizaes sero pressionadas
por seus concorrentes a reduzir substancialmente os prazos para a entrega de produtos.Organizaes
que sejam capazes de integrar, harmonizar e acelerar seus processos de desenvolvimento e
manuteno de software tero a primazia do mercado [MACHADO01].
A globalizao da economia vem influenciando as empresas produtoras e prestadoras de servios de
software a alcanar o patamar de qualidade e produtividade internacional para enfrentarem a
competitividade cada vez maior. A norma internacional NBR ISO/IEC 12207 Tecnologia da
Informao Processos de Ciclo de Vida de Software [ISO12207: 97] usada como referncia em
muitos pases, inclusive no Brasil, para alcanar esse diferencial competitivo [MACHADO01].
A norma ISO/IEC 12207 trata os requisitos do software como fator fundamental no processo de
ciclo de vida do software, gerando documentao para a fase de desenvolvimento do software,
possibilitando que o produto seja verificado e validado posteriormente, atendendo assim as
necessidades do adquirente.
Diante deste fato, podemos afirmar que por falta de utilizao de mtodos e modelos de
gerenciamento da qualidade de software com base em requisitos, produzimos softwares de qualidade
contestvel e participando efetivamente da Crise do Software [PRESSMAN02].
9. PRODUTO DE SOFTWARE
Quando entregamos a um cliente um pacote bem delimitado e identificado, podemos dizer que
entregamos um produto [SPINOLA98].
A definio para produto de software segundo a norma IEEE-STD-610 [IEEE90] :
O conjunto completo, ou qualquer dos itens individuais do conjunto, de programas de computador,
procedimentos, e documentao associada e dados designados para liberao para um cliente ou
usurio final [PAULK95].
11. REQUISITOS
Os problemas que os engenheiros de software tm para solucionar so, muitas vezes, imensamente
complexos. Compreender a natureza dos problemas pode ser muito difcil, especialmente se o
sistema for novo. Conseqentemente, difcil estabelecer com exatido o que o sistema deve fazer.
As descries das funes e das restries so os requisitos para o sistema [SOMMERVILLE03].
Os Requisitos (Requirements) podem ser definidos como as necessidades bsicas do cliente,
geralmente explicitadas como condio de negcio no contrato com o fornecedor. So
caractersticas, tais como especificaes tcnicas, prazo de entrega, garantia, que o cliente requer
do produto [MCT02].
Uma condio ou capacidade necessitada por um usurio, para resolver um problema ou alcanar
um objetivo [IEEE90].
Segundo Tonsig, Os requisitos compem o conjunto de necessidades estabelecido pelo cliente /
usurio do sistema que definem a estrutura e comportamento do software que ser desenvolvido
[TONSIG03].
Segundo Pdua, o fluxo de requisitos rene as atividades que visam a obter o enunciado completo,
claro e preciso dos requisitos de um produto de software. Esses requisitos devem ser levantados pela
equipe do projeto, em conjunto com representantes do cliente, usurios chaves e outros especialistas
da rea de aplicao [PADUA03].
12.ENGENHARIA DE REQUISITOS
O processo de descobrir, analisar, documentar, e verificar as funes e restries do sistema,
chamado de engenharia de requisitos [SOMMERVILLE03].
Engenharia de requisitos, uma subrea da engenharia de software, tem por objetivo tratar o processo
de definio dos requisitos de software. Para isso estabelece um processo pelo qual o que deve ser
feito elicitado, modelado e analisado. Esse processo deve lidar com diferentes pontos de vista e
usar uma combinao de mtodos, ferramentas e pessoal. O produto desse processo um modelo,
do qual um documento chamado requisitos produzido. Esse processo perene e acontece em um
contexto previamente definido e que chamamos de Universo de informaes [LEITE01].
O conjunto de tcnicas empregadas para levantar, detalhar, documentar e validar os requisitos de
um produto forma a engenharia de requisitos [PADUA03].
A engenharia de requisitos fornece um mecanismo adequado para entender o que o cliente deseja,
analisar as necessidades, avaliar a exeqibilidade, negociar uma soluo razovel, especificar a
soluo de maneira no-ambgua, validar a especificao e administrar os requisitos medida que
eles so transformados num sistema em operao. O processo da engenharia de requisitos pode ser
descrito em cinco passos distintos [PRESSMAN02]:
Elicitao de requisitos
Anlise e negociao de requisitos
Especificao de requisitos
Modelagem do sistema
Validao de requisitos
Gesto de requisitos
12.1 ELICITAO DE REQUISITOS
Certamente parece muito simples pergunte ao cliente, aos usurios e a outros quais so os
objetivos do sistema ou do produto, o que precisa ser conseguido, como o sistema ou o produto se
encaixa nas necessidades do negcio e, finalmente, como o sistema ou o produto vai ser usado no
dia-dia. Mas no simples muito difcil.
medida que medida que a anlise de requisitos comea, as seguintes perguntas so formuladas e
respondidas:
Cada requisito est consistente com o objetivo global do sistema/produto?
Todos os requisitos foram especificados no nvel de abstrao adequado?
O requisito realmente necessrio, ou pode ser essencial para o objetivo do sistema?
Cada requisito limitado e no-ambguo?
Cada requisito tem atribuio? Isto , uma fonte est associada a cada requisito?
Algum requisito conflita com outros requisitos?
Cada requisito realizvel no ambiente tcnico que vai alojar o sistema ou o produto?
Cada requisito pode ser testado, quando estiver implementado?
No incomum que os clientes / usurios peam mais do que pode ser conseguido, considerando os
recursos limitados do negcio.
O engenheiro de sistemas precisa reconciliar esses conflitos por intermdio de um processo de
negociao. Os riscos associados a cada requisito so identificados e analisados. Estimativas
grosseiras do esforo de desenvolvimento so feitas e usadas para avaliar o impacto de cada
requisito no custo do projeto e no prazo de entrega. Usando uma abordagem iterativa, requisitos so
eliminados, combinados ou modificados de modo que cada parte alcance algum grau de satisfao.
12.3 ESPECIFICAO DE REQUISITOS
No contexto de sistemas baseados em computador, o termo especificao significa coisas diferentes
para pessoas diferentes. Uma especificao pode ser um documento escrito, um modelo grfico, um
modelo matemtico formal, uma coleo de cenrios de uso, um prottipo ou qualquer combinao
desses elementos. Para sistemas grandes, um documento escrito, combinando descries em
linguagem natural e modelos grficos podem ser a melhor abordagem. Cenrios de uso podem,
entretanto, ser tudo que necessrio para produtos ou sistemas pequenos que residem em ambientes
tcnicos bem-entendidos [PRESSMAN02].
12.4 MODELAGEM DO SISTEMA
Cada sistema baseado em computador pode ser modelado como uma transformao de informao
usando um gabarito entrada processamento sada. Essa viso pode ser estendida para incluir duas
caractersticas adicionais dos sistemas processamento e manuteno de interface com o usurio e
autoteste [PRESSMAN02].
12.5 VALIDAO DE REQUISITOS
Os produtos de trabalho produzidos como conseqncia da engenharia de requisitos so avaliados
quanto qualidade durante o passo de validao. A validao de requisitos examina a especificao
para garantir que todos os requisitos do sistema tenham sido declarados de modo no-ambguo; que
as inconsistncias, omisses e erros tenham sido detectados e corrigidos e que os produtos de
trabalho estejam de acordo com as normas estabelecidas para o processo, projeto e produto
[PRESSMAN02].
12.6 GESTO DE REQUISITOS
Gesto de requisitos um conjunto de atividades que ajuda a equipe de projeto identificar, controlar
e rastrear requisitos e modificaes de requisitos em qualquer poca, medida que o projeto
prossegue [PRESSMAN02].
10
14. CONCLUSO
importante que os desenvolvedores de software reconheam que no possvel desenvolver
sistemas com qualidade, cumprir prazos e custos e atender s expectativas dos usurios sem ter um
processo de desenvolvimento de requisitos definido, compreendido e utilizado por toda a equipe.
Quanto engenharia de requisitos podemos ainda acrescentar:
-
11
Permite para micros, pequenas e mdias empresas que possuem recursos humanos e
financeiros limitados possibilidade de competir com as empresas de maior porte.
Com os processos de desenvolvimento de software controlados, documentados e gerenciados
o pequeno desenvolvedor poder assumir projetos de alta complexidade, aliados a tcnica e
criatividade, pois ter mais chance de sucesso.
Melhor capacitado e provedor de metodologias que levam ao desenvolvimento de software
com qualidade, o desenvolvedor poder criar solues que atendam as necessidades e os
requisitos da empresa, contribuindo para criao de vantagens competitivas, sustentando as
bases estratgicas das organizaes.
12