UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL ESCOLA DE ENGENHARIA
MESTRADO PROFISSIONALIZANTE EM ENGENHARIA
AVALIAÇÃO DA FORMA TRADICIONAL E MACROERGONÔMICA DE IDENTIFICAÇÃO DE REQUISITOS PARA A CONCEPÇÃO DE PROJETOS DE
SOFTWARE
Rosimeire Sedrez Bitencourt
Porto Alegre, 2003
UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL ESCOLA DE ENGENHARIA
MESTRADO PROFISSIONALIZANDO EM ENGENHARIA
AVALIAÇÃO DA FORMA TRADICIONAL E MACROERGONÔMICA DE IDENTIFICAÇÃO DE REQUISITOS PARA A CONCEPÇÃO DE PROJETOS DE
SOFTWARE
Rosimeire Sedrez Bitencourt
Orientadora: Profa Lia Buarque de Macedo Guimarães, PhD, CPE
Banca Examinadora:
Profa. Anamaria de Moraes, Dra.
Profa. Marília Levacov, PhD.
Prof. Marcelo Soares Pimenta, Dr.
Trabalho de Conclusão do Curso de Mestrado Profissionalizante em Engenharia como requisito parcial à obtenção do título de Mestre em Engenharia – modalidade
Profissionalizante – Ênfase Ergonomia
Porto Alegre, 2003
Este Trabalho de Conclusão foi analisado e julgado adequado para a obtenção do título de mestre em ENGENHARIA e aprovada em sua forma final pelo orientador e
pelo coordenador do Mestrado Profissionalizante em Engenharia, Escola de Engenharia, Universidade Federal do Rio Grande do Sul.
_______________________________________
Profa. Lia Buarque Macedo de Guimarães Orientadora
Escola de Engenharia
Universidade Federal do Rio Grande do Sul
____________________________________
Profa. Helena Beatriz Bettella Cybis Coordenadora
Mestrado Profissionalizante em Engenharia Escola de Engenharia
Universidade Federal do Rio Grande do Sul
BANCA EXAMINADORA Profa. Anamaria de Moraes PUC/RJ
Profa. Marília Levacov PPG-COM/UFRGS
Prof. Marcelo Soares Pimenta PPGCC/UFRGS
Para minha família, minha constante fonte de motivação, orgulho e amor.
Para meus amigos que, mesmo estando longe, sempre fizeram-se muito presentes.
Para Deus, por todos eles.
AGRADECIMENTOS
A Deus, agradeço por tudo que passei para atingir mais esta meta.
A Lia Buarque Macedo Guimarães, mais do que minha orientadora, uma grande
pesquisadora que está à frente do nosso tempo. Agradeço, principalmente, porque, com ela, aprendi a ser muito mais do que uma profissional de TI; aprendi a ser mais humana e menos técnica, entendi os reais benefícios e prejuízos que a engenharia (quer seja ela de software ou de produção) pode trazer à sociedade.
A todos que tornaram possível a realização desta pesquisa, meus amigos, aos profissionais e colegas da UFRGS e, em especial, a Paulo Henrique dos Santos, Tânia Cristina de Souza e Sandro Marques.
ÍNDICE
LISTA DE FIGURAS...viii
LISTA DE TABELAS...ix
Resumo... x
Abstract...xi
1. INTRODUÇÃO ... 1
1.1. Objetivo Geral ... 6
1.2. Objetivos Específicos ... 7
1.3. Hipóteses ... 7
1.4. Estrutura da Dissertação ... 8
2. Revisão Literatura... 9
2.1. Processos de desenvolvimento de software... 9
2.1.1. Benefícios do processo iterativo e incremental ... 11
2.1.2. Estrutura do processo iterativo e incremental... 12
2.1.2.1. Fases...13
2.1.2.2. Disciplinas...15
2.1.2.3. Iterações ...16
2.1.3. A Fase de concepção do processo de desenvolvimento da MSA-Infor ... 18
2.1.3.1. Modelagem de negócio ...18
2.1.3.2. Requisitos...19
2.1.3.3. Gestão de Projeto ...22
2.1.4. A importância da fase de concepção para o projeto de software... 24
2.1.4.1. Riscos para o projeto...25
2.1.5. Visão geral da engenharia de requisitos ... 26
2.1.5.1. Elicitação de Requisitos ...27
2.1.5.2. Análise de Requisitos ...29
2.1.6. Desdobramento dos requisitos da qualidade para softwares ... 30
2.1.6.1. Norma ISO/IEC 9126...30
2.1.6.2. Usabilidade x Qualidade em uso (Desenvolvimento de Softwares) ...35
2.1.6.3. Desdobramento da Função Qualidade (QFD) ...41
2.2. O papel da ergonomia no desenvolvimento de softwares ... 44
2.2.1. Ergonomia de Software ... 44
2.2.1.1. Algumas metodologias em HCI ...45
2.2.2. Método desenvolvido pelo LabIUtil: abordagem ergonômica para Interfaces Humano-Computador ... 46
2.2.2.1. Técnicas de Projeto ...46
2.2.2.2. O envolvimento do usuário no projeto ...47
2.2.3. Método desenvolvido pelo grupo de Design e Ergonomia LOPP/PPGEP/UFRGS: Análise Macroergonômica do Trabalho (AMT)... 52
2.2.4. Comparativo entre a proposta LabIUtil e a proposta grupo de Design e
Ergonomia LOPP/PPGEP/UFRGS... 58
2.2.5. O método DM na interface ... 61
3. Estudo de Caso: Materiais e Métodos... 65
3.1. Estudo de caso: MSA-Infor Ltda (Projeto Portofer). ... 65
3.1.1. O Cliente: Portofer... 66
3.1.2. Objetivos definidos pela Ferronorte para o projeto Portofer... 67
3.2. Procedimentos adotados no projeto Portofer... 68
3.2.1. Identificação e priorização dos requisitos da forma tradicional ... 68
3.2.1.1. Identificar os Requisitos...69
3.2.1.2. Analisar os Requisitos...69
3.2.1.3. Proposta técnica comercial...72
3.2.2. Identificação e priorização dos requisitos com o método AMT/DM ... 74
3.2.2.1. Identificar os Requisitos...75
3.2.2.2. Analisar e priorizar os Requisitos...77
4. Resultados e Discussão ... 90
4.1. Resultados da aplicação da metodologia tradicional... 90
4.2. Resultados da aplicação do método AMT/DM ... 91
4.3. Resultados: método AMT/DM e tradicional (para a Fase de Concepção) ... 96
4.3.1. Envolvimento de diferentes grupos de usuários ... 97
4.3.2. Contexto de uso e possíveis problemas ... 97
4.3.3. Identificação e Priorização de Requisitos... 98
4.3.3.1. IDEs-Atividades...98
4.3.2.2. IDEs-Preocupações ...100
4.3.4. Reflexo para a organização: cliente x empresa de desenvolvimento ... 102
4.3.5. Engenharia de Software... 103
5. Conclusões e Recomendações para Trabalhos Futuros ... 105
5.1. Conclusões... 105
5.2. Recomendações para Trabalhos Futuros ... 107
REFERÊNCIAS BIBLIOGRÁFICAS ... 109
ANEXO A - fase de concepção MSA-INFOR (resumo)... 119
ANEXO B - niveis de casos de uso ... 121
ANEXO C - Objetivos do Projeto portofer ... 122
ANEXO D - diagramas gerados para o projeto portofer... 124
ANEXO E - questionário ... 127
ANEXO F - Algumas das métricas estabelecidas pela norma ISO/IEC 9126 (ABNT, 1999)... 129
LISTA DE FIGURAS
Figura 1 - Processo de engenharia de software... 9
Figura 2 - Processo de desenvolvimento de software iterativo e incremental... 12
Figura 3 - As fases e marcos principais do processo iterativo e incremental. ... 13
Figura 4 - Cada iteração dentro de uma fase resulta em uma parte (release) executável do software. ... 16
Figura 5 - Processo dirigido por casos de uso. ... 17
Figura 6 - Qualidade Interna e Externa... 32
Figura 7 - Qualidade em Uso... 34
Figura 8 - Qualidade Interna e Externa versus Qualidade em uso (ABNT 2001)... 40
Figura 9 - Qualidade no ciclo de vida do software (ABNT 2001). ... 41
Figura 10 - Importância das Preocupações por Enfoque... 84
Figura 11 - Atividades identificadas x retiradas do escopo... 91
Figura 12 - Relação entre tempo de ferrovia e grau de instrução... 93
Figura 13 - Priorização das atividades (IDEs) - antes e depois da força de relação. ... 93
Figura 14 - Atividades priorizadas (IDEs) com Força de Relação. ... 94
Figura 15 - Importância das Preocupações com Força de Relação. ... 96
LISTA DE TABELAS
Tabela 1 - Percentual médio de recursos e tempo necessários por fase... 15
Tabela 2 - Sumário das distinções através dos níveis de foco da interface (adaptado de Grudin 1990) em 1990... 36
Tabela 3 - Quadro comparativo entre a proposta do grupo de Design e Ergonomia LOOP/PPGEP/UFRGS e a proposta do LabIUtil. ... 59
Tabela 4 - Requisitos identificados pelo analista de sistemas. ... 71
Tabela 5 - Requisitos retirados do escopo pelo cliente... 73
Tabela 6 - Operadores do CCO. ... 75
Tabela 7 - Lista dos Itens de Demanda - Atividades... 79
Tabela 8 - Lista dos Itens de Demanda - Atividades, ajustados após questionário... 81
Tabela 9 - Lista dos Itens de Demanda - Atividades c/ incorporação opinião especialista.82 Tabela 10 - Lista dos Itens de Demanda -– Preocupações. ... 83
Tabela 11 - Lista dos Itens de Demanda-Preocupações, ajustados com força de relação.. 85
Tabela 12 - Lista dos IDEs-Preocupações com força de relação... 86
Tabela 13 - Intervalos de Classificação TI%. ... 86
Tabela 14 - IDEs-Preocupações classificados em categorias de prioridade conforme valores de importância. ... 87
Tabela 15 - Lista dos Itens de Demanda-Preocupações, com força de relação dos IDs... 88
Tabela 16 - Quadro comparatico entre os procedimentos utilizados na forma tradicional de identificação de requisitos e com o método AMT/DM. ... 89
Tabela 17 - Lista dos IDEs-Atividades relacionados aos IDEs-Preocupações não atendidos ou retirados do escopo. ... 99
RESUMO
Esta dissertação apresenta o estudo da identificação dos requisitos de projeto de informatização do centro de controle operacional de trens de uma empresa ferroviária brasileira. A identificação dos requisitos foi realizada de duas maneiras: da maneira tradicional (PRESSMAN, 1995) e com a ferramenta do Design Macroergonômico - DM (FOGLIATTO e GUIMARÃES, 1999). O método DM, que envolve os usuários,
identificou problemas estratégicos e organizacionais além de priorizar os requisitos
conforme a ótica dos operadores. O método tradicional, que não é participativo, se mostrou satisfatório na identificação de alguns dos requisitos, mas não quanto a sua priorização, o que comprometeu a implantação do projeto. Além disso, o método DM identificou outros requisitos importantes que servem de base para o operador antever possíveis problemas de controle operacional, que não foram identificados pelo método tradicional. O método DM pode ser utilizado no desenvolvimento de software, maximizando suas chances de sucesso.
ABSTRACT
This dissertation presents the study of the identification of requirements for the train control of a Brazilian railroad company. Requirements’ identification was done according two different methods: the traditional (PRESSMAN, 1995) and the macroergonomic (MD) proposed by FOGLIATTO e GUIMARAES (1999). The Macroergonomic Design (MD), which involves the user in the design process, identified requirements of strategic and organizational source, besides ranking the important items according to the users. The traditional method, which is not participatory, identified some requirements with no ranking, what had a negative impact during the project implementation. Contrary to the traditional method, MD also identified important requirements which serve as a basis for problems anticipation during control operation. MD showed to be useful in software development, maximizing its chances of success.
1. INTRODUÇÃO
A crescente preocupação com a qualidade dos projetos tem levado as empresas de
desenvolvimento de software a buscarem modelos e métodos orientados à qualidade, quer seja nos produtos quanto nos serviços ofertados. Isto é justificável, à medida que a
necessidade de vantagem competitiva é uma realidade no mercado de software. Hoje, e cada vez mais, a demanda por software insere-se num contexto onde as organizações buscam por aquele que melhor atende suas expectativas e metas organizacionais (OUYANG et al., 1997; HIGHSMITH III, 1999; PBQP, 2001).
A partir da década de 90, surgiram inúmeros modelos de desenvolvimento de software focados na melhoria da sua qualidade. Com a implantação destes modelos, aliada aos investimentos em atualização tecnológica, as empresas de desenvolvimento de software buscam maximizar o número de projetos bem sucedidos, objetivando o atendimento a prazo, orçamento e requisitos previstos (WEBER et al., 2001). O atendimento a estes objetivos consolidou-se como um dos principais desafios para a comunidade de engenharia de software, visto que 72% dos projetos de software desenvolvidos não conseguem ter sucesso, segundo pesquisa realizada em 2001 pelo Standish Group 1(apud MACHADO et al., 2002).
Apesar de haver um consenso entre os autores quanto à importância do atendimento aos prazos, custos e requisitos especificados para um projeto de software (PRESSMAN, 1995;
WEBER et al., 2001; MACHADO et al., 2002), é questionável a visão de qualidade sob o foco apenas destes critérios. Para um projeto de software ser, de fato, bem sucedido, é necessário a visão do problema sob a perspectiva da organização em que o software será inserido (HIGHSMITH III, 1999; ABNT, 2001). Para a organização, é necessário que o software se apresente como útil dentro de um contexto de uso real, vindo a contribuir, de forma efetiva, com as necessidades de negócio da comunidade de usuários, gerando maior
1Standish Group Survey - "Chaos". 2001.
satisfação, segurança e produtividade (HIRATSUKA, 1996; BEVAN, 1997;
HASSENZAHL et al., 2002).
Os critérios para avaliação da qualidade do software quando em uso foram inseridos na última versão da norma ISO/IEC 9126 (2000). Esta norma representa a padronização mundial para a qualidade de produtos de softwares, e considera que um produto que atenda aos requisitos não é necessariamente um produto de boa qualidade quando realmente utilizado. Para tanto, inseriu a Parte 4 da norma que define métricas para avaliação dos efeitos do uso do produto de software ou da “qualidade em uso”. A definição de qualidade em uso, segundo a ISO, é: “o quanto um produto, utilizado por usuários específicos, atende as necessidades desses usuários para que eles atinjam as metas especificadas com eficácia, produtividade, segurança e satisfação, num contexto de uso definido”. A norma aponta como necessário que os requisitos de qualidade sejam estabelecidos de maneira precisa e quantitativa, ao invés da subjetividade que vem sendo utilizada pela comunidade de desenvolvimento de software (BEVAN, 1997; ISO/IEC 9126, 2000; ABNT, 2001).
Contudo, ABNT (2001) comenta sobre a dificuldade dos analistas de sistemas na identificação e priorização dos requisitos relacionados à qualidade em uso desde a fase inicial do projeto de software. Segundo ABNT (2001), os usuários não conhecem as reais necessidades até que utilizem o software, desta forma, a qualidade do produto é conhecida apenas na fase final do desenvolvimento, com o produto já acabado. Assim, os requisitos que devem ser atendidos, pela próxima iteração do software, são identificados a partir do feedback dos usuários (com o software já implantado). A cada iteração, o software deve se apresentar mais adequado ao contexto de uso real, garantindo a evolução da qualidade em uso, entretanto, é necessário que o custo desta evolução seja avaliado (BEVAN, 1997).
O custo da alteração de um requisito já implementado no software varia conforme os investimentos efetuados no projeto arquitetural; todavia, não é um custo baixo: cerca de 60 a 100 vezes mais caro em relação ao custo da implementação correta desde o início do projeto (TRAVASSOS, 2001; RATIONAL, 2002). Entretanto, os problemas encontrados
no software, quando em uso, podem levar a conseqüências além daquelas relacionadas ao custo de sua correção, envolvendo, por exemplo:
• Vidas humanas: como no caso do centro de controle de tráfico aéreo da Northeast em Nashua, New Hampshire, que em agosto de 1998 perdeu, por 37 minutos, o contato com 350 aeronaves que estavam sendo monitoradas naquele momento, devido a uma falha no sistema; mais de 100 outras falhas foram reportadas no mesmo ano, naquele centro de controle (TRAVASSOS, 2001);
• Meio ambiente: como no caso da usina nuclear de Three Mile Island, na Pensilvânea, em 1979: o desastre foi causado por um erro na concepção do sistema de informações e de controle da central que não permitia fazer a tempo o diagnóstico das panes
(GUIMARÃES, 1999);
• Desperdício de tempo, trabalho e material: como no caso do sistema utilizado nas eleições de 2000 na Flórida que, de acordo com o estudo publicado por Neumann (2001), mais de quatro milhões de votos não foram contados devido a problemas na concepção do projeto de software, que dentre outros problemas, não reconheceu como válidas centenas das cédulas utilizadas;
• Queda na produtividade, não permitindo o atendimento aos objetivos organizacionais e deixando das organizações menos competitivas (JONES e SMITH, 2001);
• Insatisfações e estresse, gerando conseqüências para os envolvidos com o sistema devido ao tempo de parada dos usuários, horas extras para recuperar o serviço atrasado, além de multas contratuais, processos judiciais, etc. (HIRATSUKA, 1996; SELNER, 1999; HAEGELAND, 2000).
Os problemas que propiciam erros durante a operação dos sistemas, e que estão relacionados ao seu contexto de uso, são potencializados quando a equipe de
desenvolvimento envolvida desconhece os elementos do ambiente em que o software será inserido como: a tarefa, o modo operatório, estratégia de resolução de problemas, o componente humano do sistema homem-máquina e sua interação (BENYON e DAVIES, 1990 apud MORAES, 2002; BEVAN, 2000). Para Iida (1990) não é possível projetar algo para o ser humano utilizar no seu trabalho, sem levar em consideração os aspectos humanos durante essa atividade e seus diversos planos de interação. O fato é que, segundo Earthy et
al (2002), questões relacionadas à produtividade, segurança, satisfação e eficácia
extrapolam as fronteiras de conhecimento da engenharia de software o que torna difícil a percepção destas questões por profissionais sem a qualificação necessária. Para Hassenzahl et al. (2002), a qualidade em uso requer olhar a tecnologia a partir de uma perspectiva humana levando em consideração questões organizacionais e, segundo o autor,
historicamente, os responsáveis pelo desenvolvimento de software não têm sido capacitados para isso (HASSENZAHL et al., 2002).
Portanto, se o projeto de software não contar com a participação de um profissional capacitado para avaliar formalmente o contexto de uso em que o software será inserido, independentemente do investimento tecnológico ou de todo esforço da equipe de
desenvolvimento, o resultado final poderá ser um software com baixa qualidade quando colocado em uso e que acarrete em prejuízos irreparáveis tanto do ponto de vista
econômico quanto do social (SELNER, 1999). Naturalmente, problemas relacionados ao contexto de uso podem ser introduzidos no software ao longo de todo o processo de desenvolvimento, contudo, a necessidade de prevenir estes prejuízos é o que justifica investimentos na tentativa de identificar os possíveis problemas o mais cedo quanto possível e preferencialmente ainda na fase de concepção do projeto (SELNER, 1999).
A fase de concepção, para um processo de desenvolvimento do tipo iterativo e incremental, é a primeira etapa do projeto. Esta etapa é responsável por: definir o contexto de uso do negócio, identificando a situação atual (problemas existentes, sistemas existentes, falhas nos processos) e os aspectos relevantes do contexto do negócio no qual o software irá operar (critérios de sucesso, riscos e requisitos); delimitar o escopo do projeto, definindo os limites de atuação do software, determinando os objetivos do projeto, identificando as áreas, usuários e sistemas envolvidos, identificando as premissas e restrições impostas ao projeto e ao desenvolvimento e descrevendo uma visão geral do produto a ser desenvolvido sob a ótica dos interessados. Ao final da fase de concepção, o projeto é verificado e
analisado de forma crítica pelos envolvidos. O projeto somente continua se a concordância entre todas as partes interessadas for estabelecida (MSA, 2000; RATIONAL, 2002). Esta concordância representa a busca por um equilíbrio entre pessoas, tecnologia e organização
no contexto de uso real do software. Orientações sobre o contexto de uso do software são especificadas pela ISO na norma ISO 9241 (2001) - Requisitos Ergonômicos para Trabalho de Escritório com Computadores (ainda em processo de tradução para o Brasil) e,
representam um dos focos de estudo da ergonomia (CYBIS et al., 1998; GUIMARÃES, 2001; DITTRICH e LINDEBERG, 2002; HASSENZAHL et al., 2002).
A atuação conjunta entre a ergonomia e a engenharia de software vem sendo constatada, por diversos autores (CYBIS et al., 1998; ENDLER, 2000; JONES e SMITH, 2001), como responsável por resultados positivos no desenvolvimento de software. Sob o ponto de vista macro, a ergonomia enfatiza a interação entre o contexto organizacional e psicossocial de um sistema e o projeto (HENDRICK, 1993). Como forma de garantir a melhor
compreensão de um sistema, a macroergonomia considera imperativo a participação dos usuários (seguindo a linha do designer participativo), quer na identificação de demandas, quer na projetação/validação de propostas projetuais (GUIMARÃES, 1999; DITTRICH e LINDEBERG, 2002). A Interação Homem-Computador (HCI) é caso particular dentro da ergonomia que se preocupa com a adaptação de sistemas computacionais ao seu usuário, visando a maior satisfação, segurança e produtividade (BAECKER et al., 1995).
Na última década, métodos de ergonomia aplicáveis ao desenvolvimento de software e que buscam um equilíbrio sociotécnico têm sido testados e consolidados (CYBIS et al., 1998;
SHNEIDERMAN, 1998; ENDLER, 2000; PRADO, 2001) e, nesta linha, merecem destaque os métodos focados na concepção ergonômica para o desenvolvimento de interfaces com o usuário de sistemas interativos, os quais vêem contribuindo fortemente com a qualidade em uso, como por exemplo, os desenvolvidos pelo Laboratório de
Usabilidade - LabIUtil (LABIUTIL, 2003) e pelo Laboratório de Ergonomia e Usabilidade de Interfaces em Sistemas Humano-Tecnologia (MORAES, 2002).
Portanto, é uma necessidade real para a qualidade dos projetos de software, que a fase de concepção busque pela concordância entre todas as partes interessadas no projeto, com base em informações geradas através de métodos ergonômicos, que permitam a identificação de problemas relacionados ao contexto de uso do software a partir das demandas dos usuários.
A identificação de requisitos da forma tradicional sugere a participação dos usuários (clientes, gerentes, usuários operacionais, ...) nas entrevistas, sendo que o analista de sistemas elenca, subjetivamente, os elementos problemáticos para o projeto (PRESSMAN, 1995), entretanto, este método, não define como fundamental a participação dos usuários operacionais nem mesmo sugere visitas ao posto de trabalho onde o software será
implantado. O método Análise Macroergonômica do Trabalho (AMT), proposto por Guimarães (1999), que tem como bases a macroergonomia e a ergonomia participativa utiliza-se, nas fases de apreciação e projetação, o método Design Macroergonômico (DM) proposto por Fogliatto e Guimarães (1999). Até o momento, o método DM foi utilizado com sucesso em projetos de postos de trabalho (GUIMARÃES et al, 1998; FOGLIATTO e GUIMARÃES, 1999; KRUG, 1999), ambientes de trabalho (VAN DER LINDEN, 1999;
RAMIRES, 2000; TRAMONTIN, 2000). No contexto de desenvolvimento de software, o DM foi aplicado por Endler (2000) na coleta e análise das demandas e dos índices de satisfação dos usuários e especialistas quanto à qualidade ergonômica de interfaces gráficas, contribuindo para a administração do processo de melhoria contínua no desenvolvimento de sistemas.
Em paralelo ao método tradicional, o método AMT/DM foi aplicado na identificação e priorização dos requisitos a serem atendidos pelo Projeto Portofer a partir das demandas dos usuários, visando a identificação de problemas relacionados a este projeto ainda na fase de concepção. O projeto para a empresa Portofer (Operadora Ferroviária do Porto de
Santos) foi desenvolvido, de forma terceirizada, seguindo o método tradicional (PRESSMAN, 1995), pela empresa MSA-Infor, e visa a informatização do Centro de Controle Operacional (CCO) de trens do porto de Santos.
1.1. Objetivo Geral
Este estudo é focado na avaliação da aplicabilidade da Análise Macroergonômica do Trabalho – AMT (Guimarães,1999)/Design Macroergonômico – DM (Fogliatto e
Guimarães, 1999), na fase de concepção de projetos de software. Na avaliação, pretende-se confrontar as demandas identificadas e priorizadas junto aos usuários pelo método
AMT/DM com aquelas definidas pelo método de identificação tradicional de requisitos (PRESSMAN, 1995).
1.2. Objetivos Específicos
Identificar se existem diferenças significativas entre a concepção do software com e sem a utilização de um método participativo;
Identificar se existem diferenças entre a demanda das atividades dos operadores e os requisitos implementados pelo software;
Identificar se existem diferenças entre o método tradicional e AMT/DM que gerem conseqüências para a concepção do projeto;
Identificar a aplicabilidade do método AMT/DM na identificação de requisitos de projetos de software, de forma complementar às metodologias utilizadas na fábrica de software;
Avaliar se a utilização de preceitos macroergonômicos permite identificar demandas que gerem conseqüências para a Organização.
1.3. Hipóteses
Existem diferenças significativas entre a concepção do software com e sem a utilização de um método participativo;
Existem diferenças identificáveis entre a demanda das atividades dos operadores e os requisitos implementados pelo software;
Existem diferenças entre o método tradicional e AMT/DM que gerem conseqüências para a concepção do projeto;
A utilização do método AMT/DM na identificação de requisitos de projetos de software é aplicável de forma complementar às metodologias utilizadas na fábrica de software;
A utilização de preceitos macroergonômicos permite identificar demandas que gerem conseqüências para a Organização.
1.4. Estrutura da Dissertação
Esta dissertação está estruturada em cinco capítulos, incluindo a presente Introdução. Seus conteúdos vêm descritos na seqüência.
No Capítulo 2, é apresentado o embasamento teórico. Inicialmente são descritos os conceitos gerais do processo de desenvolvimento dirigido por fases permitindo a
apresentação: da importância da fase de concepção de projetos, onde a técnica tradicional de identificação de requisitos é contextualizada; do modelo que representa a qualidade de produtos de software e de técnicas adequadas à garantia da conformidade com o modelo de qualidade. Na seqüência, é apresentada uma coletânea que contextualiza a aplicação da ergonomia no desenvolvimento de software, onde o método AMT/DM é descrito e comparado com outras técnicas, também, aplicáveis ao desenvolvimento de software,
O Capítulo 3 apresenta os procedimentos que foram adotados para o estudo de caso (Projeto Portofer), descrevendo-se a utilização dos métodos, tradicional e AMT/DM, na fase de concepção do projeto.
O Capítulo 4 apresenta e discute os resultados obtidos com a aplicação dos métodos tradicional e AMT/DM.
O Capítulo 5 apresenta as considerações finais, além de propor algumas recomendações para pesquisas futuras.
2. REVISÃO LITERATURA
2.1. Processos de desenvolvimento de software
Um processo para engenharia de software é um conjunto de atividades técnicas e gerenciais para criar ou alterar um software a partir de requisitos. Isto se aplica ao longo do ciclo de vida do software (Figura 1). Desenvolvimento de software é o processo de desenvolver software a partir de requisitos (PRESSMAN, 1995).
Figura 1 - Processo de engenharia de software.
Existem vários processos de desenvolvimento utilizados pela engenharia de software. Os mais difundidos são (PRESSMAN, 1995; MSA, 2000):
• Codifica-e-remenda: o software é desenvolvido com base em uma especificação insuficiente e informal. O produto final é resultado de um “turbilhão” entre a
implementação de novas especificações, as alterações nas implementações incorretas e as tentativas de implantação do software no cliente;
• Cascata: possui cinco etapas: requisitos, análise, projeto, implementação, testes e implantação; as quais devem ser executadas em estrita seqüência. A rigidez deste processo permite pontos de controle bem definidos que facilitam a gestão. As etapas requisitos, análise e desenho têm de ser muito bem dominados. O cliente só recebe o resultado no final do projeto;
Processo de Engenharia de Software Requisitos
novos ou alterados
Software novo ou alterado Processo de
Engenharia de Software Requisitos
novos ou alterados
Software novo ou alterado
• Espiral: é composto de cinco etapas: ativação, análise de riscos, avaliação, desenvolvimento e planejamento da próxima etapa; as quais ocorrem de forma seqüêncial sendo que estas etapas são focadas apenas em um grupo de requisitos escolhido inicialmente. Com o término do desenvolvimento um novo grupo de requisitos é escolhido pela etapa de planejamento dando início à um novo ciclo. O escopo do software aumenta a cada ciclo realizado.
• Prototipagem Evolutiva: possui quatro etapas: conceito inicial, protótipo inicial, protótipos refinados e produto; as quais são seqüências. Após uma entrevista inicial com o cliente (conceito inicial) os protótipos de interface são construídos (protótipo inicial). Na etapa “protótipos refinados”, o cliente interage com as interfaces
implementadas e sugere melhorias. As melhorias solicitadas são implementadas diretamente nos protótipos de interface até que o cliente não solicite mais alterações.
Na seqüência as funcionalidades são implementadas e o produto é entregue. Apresenta flexibilidade e visibilidade para o cliente já que é focado nas interfaces;
• Entrega por Estágios: é similar ao processo “cascata”, diferindo-se nas etapas de implementação e testes que, neste processo, têm seu escopo subdividido em partes menores desde que representativas para o cliente, permitindo a entrega de liberações parciais do produto;
• Entrega Evolutiva: é similar ao processo “entrega por estágios”, diferindo-se na etapa de projeto que também possui seu escopo subdividido em partes menores, assim, os usuários podem avaliar partes do produto fornecendo realimentação quanto às decisões tomadas;
• Dirigido pelo prazo: o software é desenvolvido a partir da definição de um prazo final de entrega. Na prática, os prazos costumam ser definidos de forma política. O produto final é resultado de um conjunto de requisitos possíveis de implementação dentro do prazo especificado. Pode ser razoável quando se consegue definir o conjunto de requisitos indispensáveis e implementá-los no para o prazo definido, caso contrário, o
“produto” que se entrega no final do prazo é apenas um resultado parcial;
• Dirigido por ferramenta: o software é desenvolvido a partir da definição de uma ferramenta de desenvolvimento. A qualidade deste processo depende da qualidade da
ferramenta definida e é restrito ao tipo de produto que a ferramenta permite desenvolver;
• Iterativo e Incremental: desenvolver software de forma iterativa e incremental significa desenvolver o software em partes menores iterativamente, em função de revisões periódicas da evolução de suas funcionalidades, o que viabiliza a redução de riscos de desvios de escopo e o aprimoramento da qualidade dos produtos gerados (BOOCH et.
al., 2000).
Cada processo de desenvolvimento apresenta vantagens e desvantagens em relação ao contexto de sua utilização. Nos últimos anos, o processo de desenvolvimento do tipo
iterativo e incremental tem apresentado flexibilidade para diversos contextos de utilização e tem sido aplicado como base para novos processos de desenvolvimento (PRESSMAN, 1995; MSA, 2000).
2.1.1. Benefícios do processo iterativo e incremental
O processo de desenvolvimento de software iterativo e incremental torna o
desenvolvimento mais flexível para a acomodação de novos requisitos ou de mudanças táticas de objetivos de negócio. Uma solução iterativa requer uma compreensão crescente do problema por meio de aperfeiçoamentos sucessivos e do desenvolvimento incremental de uma solução efetiva em vários ciclos (Figura 2). Também permite que o projeto identifique e solucione riscos de início, em vez de posteriormente. Durante o ciclo de desenvolvimento do software, fases devem ser atingidas para avaliação da situação do projeto, conforme é explicado em 2.1.2.1 (BOOCH et. al., 2000; RATIONAL, 2002).
Figura 2 - Processo de desenvolvimento de software iterativo e incremental.
O processo de desenvolvimento de software Rational Unified Process - RUP é o processo da Rational Corporation que segue a abordagem do ciclo de vida proposto pelo processo iterativo e incremental, especialmente adequada à Linguagem de Modelagem Unificada - UML (RATIONAL, 2002).
A UML é uma linguagem padrão para a elaboração da estrutura de softwares que pode ser empregada para a visualização, a especificação, a construção e a documentação de artefatos de sistemas complexos (BOOCH et. al., 2000).
2.1.2. Estrutura do processo iterativo e incremental
Seguindo o RUP, a estrutura definida para o processo permite seu entendimento sob duas dimensões: a primeira representa o aspecto estático do processo, ou seja, como ele é descrito em termos de disciplinas e atividades (organização por conteúdo); a segunda dimensão representa o aspecto dinâmico do processo, ou seja, como ele é executado em termos de ciclos, fases, iterações e marcos (organização ao longo do tempo). Esta estrutura pode ser observada na Figura 3 (RATIONAL, 2002).
Figura 3 - As fases e marcos principais do processo iterativo e incremental.
O processo é descrito sob dois diferentes pontos de vista: um ponto de vista é o técnico, onde o enfoque está nos artefatos e produtos agregados ao software que é desenvolvido; o outro ponto de vista é o gerencial, onde o enfoque é tempo, orçamento, pessoas, processos, e outras considerações econômicas.
2.1.2.1. Fases
O processo de desenvolvimento iterativo e incremental é dividido nas fases de concepção, elaboração, construção e transição.
Uma fase é o período de tempo entre dois importantes marcos de progresso do processo em que um conjunto bem definido de objetivos é alcançado, artefatos são concluídos e decisões críticas são tomadas em relação à passagem para a fase seguinte. As fases são:
• Concepção: durante a fase de Concepção é estabelecido o caso de negócio para o software e é delimitado o escopo do projeto. O caso de negócio inclui critérios de sucesso, avaliação de riscos e requisitos do projeto. Durante a Concepção pode ser criado um protótipo executável, que serve de teste para a fase.
• Elaboração: as metas da fase de Elaboração são a análise do domínio do problema, o estabelecimento de uma arquitetura sólida, a elaboração do plano de projeto e a eliminação dos elementos de mais alto risco do projeto. As decisões de arquitetura são feitas com uma compreensão de todo o software.
• Construção: durante a fase de Construção o software é desenvolvido de uma maneira iterativa e incremental, até atingir o produto completo, pronto para a transição aos usuários. Isso implica na implementação e no teste completo do software.
• Transição: durante a Transição, o software é instalado no ambiente de produção do cliente, os usuários são treinados e sua utilização é iniciada. A partir daí, caso seja necessário alguma manutenção corretiva, adaptativa ou evolutiva, ela deve ser tratada conforme pelo processo de manutenção de software.
Em cada fase ocorrem iterações, sendo que, tanto as fases quanto as iterações tem um foco de redução de riscos e conclui um marco de progresso bem definido. Um marco de
progresso proporciona um ponto no tempo para avaliar como as metas foram alcançadas e se o projeto necessitará ser reestruturado de alguma maneira para prosseguir.
As fases se diferem em termos da utilização dos recursos e do tempo. O percentual de utilização dos recursos e do tempo depende do projeto, entretanto, a Rational (2002) apresenta, conforme a Tabela 1, a média histórica de utilização destes recursos e do tempo, em um primeiro ciclo de desenvolvimento de projetos de sistemas de informação de
tamanho médio.
Tabela 1 - Percentual médio de recursos e tempo necessários por fase.
Concepção Elaboração Construção Transição
Recursos 5% 20% 65% 10%
Tempo 10% 30% 50% 10%
Cada uma destas fases utiliza-se de um conjunto de disciplinas necessárias para o atendimento dos objetivos da fase.
2.1.2.2. Disciplinas
O processo de desenvolvimento iterativo e incremental é composto de disciplinas técnicas e de disciplinas gerenciais, como segue:
Disciplinas Técnicas: agrupam atividades técnicas necessárias ao desenvolvimento do software, são elas:
• Modelagem de Negócio: descreve o contexto no qual o software irá operar;
• Requisitos: descreve o método baseado em casos de uso para identificar, especificar e gerenciar os requisitos;
• Análise e Projeto: descreve as várias visões da arquitetura;
• Implementação: considera a codificação do software, o teste de unidade e a integração;
• Teste: descreve os casos de teste, os procedimentos e as medidas para acompanhamento de erros e;
• Distribuição: abrange as diretrizes para instalação do software a ser entregue.
Disciplinas Gerenciais: agrupam atividades gerenciais necessárias para o planejamento, acompanhamento e encerramento do projeto de software, são elas:
• Gestão de Configuração e Mudança: controla as modificações e mantém a integridade dos artefatos do projeto;
• Gestão de Projeto: descreve as estratégias para a condução gerencial do projeto, incluindo as atividades de gestão de riscos, planejamento, supervisão e
acompanhamento e;
• Gestão de Ambiente: abrange o controle do ambiente de trabalho necessário para o desenvolvimento do software.
As disciplinas colaboram entre si em função de cada iteração planejada para o projeto.
2.1.2.3. Iterações
Cada fase do processo de desenvolvimento de software é dividida em iterações. Uma iteração é uma passagem por todas as disciplinas, resultando em uma parte (release) de um produto de resultado significativo, release este que constitui um subconjunto do produto final em desenvolvimento e cresce de modo incremental de uma iteração para outra até se tornar o produto final (Figura 4). Um release é um subconjunto do produto final que pode ser utilizado como item de validação em um marco do projeto. Um release pode ser constituído de uma versão executável do produto em conjunto com artefatos associados a esta versão.
Figura 4 - Cada iteração dentro de uma fase resulta em uma parte (release) executável do software.
Cada iteração passa por todas as disciplinas do desenvolvimento de software, embora com uma ênfase diferente em cada disciplina que depende da fase em questão. As iterações têm datas, prazos, e objetivos bem definidos, além de produtos resultantes de suas execuções;
possuem atividades de levantamento de requisitos, análise, projeto, implementação, testes e implantação, além das gerenciais. Para cada uma destas atividades são definidos
responsabilidades e produtos (artefatos de software) a serem entregues, e prazos são
estimados para sua execução. Estas ações de planejamento permitem melhor
acompanhamento de seu desempenho e efetiva avaliação comparativa de seus resultados com parâmetros de qualidade predefinidos.
Durante a Concepção, o foco está na captura de requisitos. Durante a Elaboração, o foco passa a ser a análise e o projeto. A implementação é a atividade central na Construção e a Transição é focada na implantação do software. Todas as fases do processo RUP são orientadas pelos requisitos. O artefato utilizado pelo processo para documentar requisitos é o caso de uso. Afirma-se então, que o processo RUP é dirigido por casos de uso, como mostra a Figura 5.
Figura 5 - Processo dirigido por casos de uso.
As empresas de desenvolvimento de software que buscam pelos benefícios do processo RUP, acabam adaptando o processo ao contexto de sua organização. A adaptação,
normalmente, é diferente entre as empresas que vivem do desenvolvimento de software de forma terceirizada para clientes e para empresas que desenvolvem software para uso interno, devido à complexidade inerente a cada um dos focos. A MSA-Infor trabalha com uma adaptação do processo RUP a técnicas anteriormente consolidadas pela empresa (MSA, 2000).
2.1.3. A Fase de concepção do processo de desenvolvimento da MSA-Infor
Assim como no processo RUP, no processo de desenvolvimento de software utilizado pela MSA-Infor, a fase de concepção tem como objetivo identificar o caso de negócio para o software, delimitar o escopo do projeto e elaborar um planejamento preliminar para o projeto. O Anexo A apresenta todas as atividades e responsáveis por cada uma das disciplinas da fase de concepção conforme o processo da MSA-Infor (MSA, 2000).
Sob o foco da concepção de projetos, cada uma das disciplinas técnicas e gerencias são responsáveis pela execução de um conjunto de atividades que, de forma macro, devem estar adequadas a este foco. Assim, a disciplina de modelagem de negócio descreve o contexto de negócio no qual o software deverá operar, sob o qual a disciplina de requisitos identifica e especifica os requisitos a serem atendidos pelo projeto. A disciplina de gestão de projeto descreve as estratégias para a condução do projeto, incluindo as atividades de planejamento e gestão de riscos. Através da supervisão e acompanhamento das demais disciplina, a disciplina de gestão de projeto busca pelo estabelecimento da concordância entre todas as partes interessadas no projeto. As demais disciplinas atuam de forma complementar à estas três disciplinas.
Segue uma descrição mais específica destas três disciplinas, já que elas são responsáveis pela execução de atividades sob o foco dos objetivos da fase de concepção, que é a área de interesse desta dissertação.
2.1.3.1. Modelagem de negócio
Para a fase de concepção, a disciplina de modelagem de negócio é de responsabilidade do analista de negócios e é composta por duas atividades: definir o contexto do negócio e delimitar o escopo do projeto.
Esta disciplina é de responsabilidade do analista de negócios, uma vez que ela pode envolver a aplicação de técnicas de Modelagem de Negócio (Business Modeling). Cabe a ele, então, a responsabilidade de definir a situação atual e os aspectos relevantes do contexto do negócio no qual o software irá operar após sua construção.
Nesta atividade, também deve ser descrita a visão geral do produto, que deve ser focada nas necessidades dos interessados. Esta visão deve apresentar as características fundamentais desejadas no produto a ser desenvolvido. O principal artefato utilizado para documentar as informações de definição do escopo do projeto é o “Documento de Visão”, onde deve constar:
• escopo do projeto (o que será e o que não será tratado);
• os objetivos do projeto (em termos de benefícios para o cliente);
• as áreas, os usuários e os sistemas envolvidos;
• identificar as premissas e restrições impostas ao projeto e/ou ao desenvolvimento;
• uma visão geral do produto, baseada nas necessidades e expectativas dos interessados.
2.1.3.2. Requisitos
O propósito da disciplina de requisitos é: estabelecer e manter a concordância do cliente em relação ao que o software deve fazer; fornecer aos desenvolvedores um melhor
entendimento dos requisitos; definir os limites de atuação do software; fornecer uma base para planejamento do projeto; fornecer uma referência para as estimativas de custo e tempo para o desenvolvimento e definir as interfaces do software.
Esta disciplina possui as atividades de identificar os requisitos e analisar os requisitos como fundamentais sob o foco da fase de concepção. A definição de requisitos, assim como as técnicas existentes, são descritas no item 2.1.5 deste capítulo.
Identificar os Requisitos
A identificação de requisitos tem como objetivo produzir uma lista de requisitos do
projeto com o objetivo de entender quais são as suas necessidades em relação ao software a ser desenvolvido. As informações levantadas servem para gerar uma lista de requisitos do software. Esta atividade é de responsabilidade do analista de sistemas e é realizada em conjunto com o analista de negócios, usuários chave e outros especialistas da área de aplicação quando necessário.
O método de identificação de requisitos sugerido pelo processo de desenvolvimento de software da MSA-Infor é o tradicional sugerido em Pressman (1995). O analista de
sistemas, subjetivamente, avalia os problemas atuais e as informações desejadas (entrada e saída), e sintetiza uma ou mais soluções. Para tanto, segundo Pressman (1995), o analista de sistemas deve exibir, entre outros traços característicos, a capacidade de “ver a floresta por entre as árvores”. Quanto mais o analista de sistemas conhecer do negócio, mais adequada será a solução proposta.
O primeiro passo para se delimitar o escopo do projeto é conhecer quem são os envolvidos e obter o consenso dos mesmos quanto ao problema a ser resolvido. Alguns dos envolvidos podem ser os próprios usuários do software, os representantes do cliente, os patrocinadores do projeto, entre outros.
Analisar os Requisitos
A análise de requisitos envolve atividades que visam obter a especificação dos requisitos levantados para o software. Esta análise também é feita pelo analista de sistemas em conjunto com o analista de negócios, usuários chave e outros especialistas da área de aplicação quando requeridos.
A análise dos requisitos visa gerar os casos de uso a partir dos requisitos identificados anteriormente. Os casos de uso são as representações das funcionalidades que o software deve disponibilizar para gerar algum benefício mensurável para os usuários
Identificar os Atores
Neste momento, os atores que interagem com os casos de uso devem ser identificados. Um ator representa um conjunto coerente de papéis que os usuários de casos de uso
desempenham quando interagem com esses casos de uso. Tipicamente, um ator representa um papel que um ser humano, um dispositivo de hardware ou até outro sistema
desempenha com o sistema a ser desenvolvido.
Analisar os Requisitos Funcionais
A análise de requisitos funcionais visa obter os casos de uso a partir dos requisitos
funcionais identificados anteriormente. Os requisitos funcionais são modelados através de casos de uso. Requisitos funcionais descrevem as funcionalidades que o software deve disponibilizar para gerar algum benefício mensurável para os usuários. Os casos de uso são as representações destas funcionalidades. Neste ponto do projeto, os casos de uso não precisam ser descritos em detalhes. É suficiente que eles sejam identificados e que tenham pelo menos uma descrição geral do seu propósito (casos de uso nível 2). Os níveis de casos de uso são descritos no Anexo B.
Analisar os Requisitos Não Funcionais
Os requisitos não funcionais incluem os requisitos de desempenho, requisitos lógicos de dados e requisitos de qualidade do software. Os requisitos de desempenho são requisitos tais como: número de terminais suportados, número de usuários simultâneos, volume de informação que deve ser tratado, número de transações por unidade de tempo, condições de normalidade e de pico. Os requisitos de desempenho são especificados de forma
quantitativa e mensurável, e são medidos nos testes de aceitação. Os requisitos lógicos de dados são caracterizados pelas estruturas de dados a serem usadas pelo software, tais como:
tabelas em bancos de dados, arquivos convencionais, arquivos partilhados entre o software e outros sistemas, as fontes e destinos dos dados assim como os formatos destes, os
relatórios gerados, etc.
Especificar os Requisitos
O objetivo da especificação de requisitos é especificar os requisitos identificados com informações suficientes para controle e acompanhamento.
Priorizar requisitos
Os benefícios que se espera obter com o projeto também devem ser identificados. O valor do benefício do projeto para o cliente é descrito pela importância atribuída pelo cliente ao benefício conforme a prioridade demandada. O valor atribuído a cada benefício do projeto é útil na atividade de classificação dos requisitos. Os benefícios são classificados quanto a sua importância de forma subjetiva como:
• Essencial: requisito sem cujo atendimento o software é inaceitável;
• Desejável: requisito cujo atendimento aumenta o valor do software, mas cuja ausência pode ser relevada em caso de necessidade (por exemplo de prazo) e;
• Opcional: requisito a ser cumprido se houver disponibilidade de prazo e orçamento, depois de atendido os demais requisitos.
Nesta atividade também deve ser descrita a visão geral do produto, que é uma visão de alto nível focada nas necessidades dos interessados. Esta visão deve apresentar as características fundamentais desejadas no produto a ser desenvolvido.
2.1.3.3. Gestão de Projeto
Esta disciplina é responsável pela condução gerencial do projeto, incluindo as atividades de gestão de riscos, planejamento, supervisão e acompanhamento das outras disciplinas. O responsável por esta disciplina é o gerente do projeto. Sob o foco da concepção ela é responsável por verificar e analisar criticamente o projeto buscando o aceite desta fase junto aos principais interessados pelo projeto, através da execução das seguintes atividades:
identificar riscos do projeto, calcular o FPA estimado, planejar o projeto (planejamento preliminar).
Identificar os Riscos do Projeto
A identificação dos riscos do projeto é o ponto de partida para todo o controle e
monitoramento dos riscos detectados para o projeto. Na identificação dos riscos, devem ser considerados: riscos legais; riscos tecnológicos; riscos devidos ao tamanho e à
complexidade do produto; riscos relativos a pessoal; riscos relativos à aceitação pelos usuários; dentre outros.
Sob o foco da fase de concepção são identificados os eventos de risco, os prováveis
impactos de sua ocorrência e os indicadores que precisam ser observados para se antever a sua ocorrência.
Calcular o FPA Estimado
Esta atividade tem o objetivo de fazer uma estimativa do tamanho do software a partir de suas funcionalidades, considerando a solução proposta, utilizando Análise de Pontos de Função (FPA) como unidade de medida. Esta estimativa foi criada em 1979 por Allan J.
Albrecht (IBM) e é uma técnica de métrica de uma aplicação na visão externa do usuário (independente da linguagem utilizada). Em 1986 foi formado o Grupo Internacional de Usuários da FPA, International Function Point Users Group (IFPUG), destinado a divulgar informações e novas implementações da técnica (GARMUS & HERRON, 2000).
O esforço de desenvolvimento para o projeto deve ser estimado em horas, tendo como referência o tamanho estimado do software (FPA) e a taxa de produção. O Gerente de Projeto deve solicitar à área de Gestão da Qualidade (GDQ) a taxa de produção média da MSA-Infor em projetos com a mesma característica técnica, para utilizar como referência.
Um cronograma para o projeto deve ser estimado quando o tamanho calculado para o software exceder a 500 pontos de função (FPA). O planejamento do projeto deve ser acompanhado através de um cronograma elaborado no Microsoft Project, detalhando o projeto por fases e, dentro de cada fase, as atividades por disciplina.
Planejar o Projeto (planejamento preliminar)
O gerente do projeto é responsável por elaborar um planejamento que englobe as atividades de desenvolvimento do projeto e os responsáveis por estas atividades, para posteriormente serem alocados os recursos humanos devidos para cada uma delas. Este planejamento é que dá origem á proposta técnica comercial.
Ao final da fase de concepção são conduzidas reuniões de acompanhamento técnico e gerencial do projeto, onde são efetuadas e documentadas análises críticas formais e verificações do projeto. As verificações são efetuadas pelos participantes do projeto a fim de assegurar que as saídas planejadas para a fase atendam aos requisitos de entrada da mesma e a fim de assegurar que os produtos estejam em conformidade com as necessidades e/ou requisitos definidos pelo usuário.
Assim que o gerente do projeto conseguir um consenso entre os interessados pelo projeto, a fase de concepção é concluída, iniciando-se a fase de elaboração do projeto.
2.1.4. A importância da fase de concepção para o projeto de software
Para as empresas que desenvolvem software de forma terceirizada, normalmente, a fase de concepção gera uma proposta técnica comercial do projeto de software a ser desenvolvido.
A proposta técnica comercial é originada a partir do planejamento gerado pelo gerente do projeto, o qual engloba as atividades de desenvolvimento e os responsáveis por estas atividades para o projeto.
Se a proposta for aceita pelo cliente é, então, gerado um contrato de prestação de serviços.
Esta proposta e o contrato servem como um guia ao desenvolvimento do projeto. Não atender à algum dos itens contratados, geralmente, acarreta em multas contratuais.
Dependendo da forma em que esta proposta é elaborada, alguma das partes pode ser
prejudicada. Portanto, é interesse tanto da empresa de desenvolvimento quanto do cliente se invista na fase de concepção do projeto.
Na MSA-Infor, a proposta técnica comercial é formulada em conjunto com o cliente. Nela são especificados os objetivos definidos para o software pelo cliente em conjunto com especificações identificadas pelas unidades funcionais que atuam na fase de concepção de projetos.
No processo de desenvolvimento de software da MSA-Infor, a equipe de projeto é dividida em unidades funcionais, ficando cada uma delas responsável por uma parcela de trabalho ao longo do ciclo de desenvolvimento do software. Com isso, cada integrante da equipe de projeto passa a ter uma visão geral do negócio e se especializa em uma área com objetivos específicos. A união do trabalho de todos os integrantes busca o atendimento aos objetivos globais definidos.
Assim, a unidade de “negócio e requisitos” é acionada no início do projeto e é responsável por estabelecer os processos de negócio para o desenvolvimento e por especificar os requisitos deste software. Os requisitos identificados são especificados em documentos chamados de casos de uso. As outras unidades são: “análise e projeto”, “implementação”,
“teste”, “gerência de projeto”, “ambiente operacional” e “processo e qualidade” e visam a garantia de que o software produzido atenda aos casos de uso especificados dentro dos prazos acordados. Para que o resultado final obtenha sucesso é importante que a documentação seja o mais detalhada quanto possível, buscando evitar especificações subjetivas ou com dupla interpretação (MSA, 2000).
2.1.4.1. Riscos para o projeto
A subjetividade é fator gerador de riscos durante todo o ciclo de desenvolvimento do software e, devido à natureza dos softwares, qualquer processo de desenvolvimento está suscetível a problemas relacionados à subjetividade. Quanto maior a subjetividade na especificação de um requisito, maior é o risco de que ele não seja implementado como o usuário necessita (LAMIA, 2001). Vale ressaltar que, segundo Standish Group (apud MACHADO et al., 2002), em média, apenas 65% das expectativas dos usuários são
atendidas pelos projetos de software implantados e, consequentemente, os usuários acabam insatisfeitos tendo de se adaptar a um produto inadequado, enquanto os outros requisitos continuam sendo implementados (o software entra em manutenção). O correto seria que os softwares, assim como outros produtos, tivessem o máximo possível de adequação às necessidades de seus usuários, antes de serem implantados para utilização no ambiente real de trabalho, conforme defende a ergonomia (GUIMARÃES, 1999; MORAES, 2003).
Por vezes, os analistas de sistemas mais experientes, percebem os riscos gerados pelo atendimento a certas definições previamente estabelecidas pelo cliente. Entretanto, devido ao caráter inédito que fundamenta cada projeto e o torna único, nem sempre o feeling do analista de sistemas é uma forma efetiva de fundamentar possíveis problemas. Fica ainda mais difícil para o analista de sistemas quando questões políticas internas à organização do cliente é que dão alicerce às definições estabelecidas. É fundamental para a gestão dos riscos que se utilize ferramentas que contribuam com estes profissionais no embasamento da percepção em relação ao projeto atual. A MSA-Infor adota o procedimento de
documentar os riscos identificados e notificá-los aos clientes. Apesar deste procedimento ser necessário, ele tem se comprovado como insuficiente, em função do exposto.
A condução dos requisitos é avaliada por métricas geradas em relação aos quesitos de qualidade externa e interna definidos para software. No processo de desenvolvimento utilizado pela MSA-Infor, a garantia da qualidade externa e interna é dada por artefatos, documentos que viabilizam a verificação dos requisitos ao longo do processo de
desenvolvimento. Um processo de engenharia de requisitos deve ser seguido.
2.1.5. Visão geral da engenharia de requisitos
A principal preocupação da engenharia de requisitos é eliminar problemas relacionados a identificação, análise, documentação e gerenciamento dos requisitos, buscando a
diminuição da subjetividade dos requisitos. Segundo a engenharia de requisitos, uma das primeiras medidas do sucesso de um projeto de software é verificar se ele atende às necessidades dos stakeholders (principais interessados pelo projeto) (ALVES, 2001).
2.1.5.1. Elicitação de Requisitos
Esta é a primeira atividade no ciclo de vida da engenharia de requisitos sendo o seu
propósito geral obter conhecimento relevante para o problema a ser resolvido. Elicitação de requisitos é um processo de descoberta dos requisitos para um sistema por maio da
comunicação com clientes, usuários finais e, quem tiver interesse no desenvolvimento do sistema. Além de descobrir quais são as necessidades dos usuários, essa atividade também requer uma cuidadosa análise da organização, do domínio de aplicação e dos processos organizacionais (KOTONYA e SOMMERVILLE, 1997). Assim, cabe a elicitação a tarefa de identificar os fatos que compõem os requisitos do sistema, de forma a prover o mais correto entendimento do que é esperado do sistema software (SHARP2 et al., 1999 apud ALVES, 2001).
Segundo Pressman (1995), os requisitos são agrupados em três tipos: requisitos normais, esperados e atrativos:
• Requisitos normais: compreendem os objetivos e as metas declarados para um produto ou sistema durante encontros com o cliente. A presença destes requisitos no produto garante a satisfação do cliente;
• Requisitos esperados: são aqueles implícitos ao produto ou sistema e não precisam ser explicitamente declarados pelo cliente. Entretanto, sua ausência causa significante descontentamento do cliente em relação ao produto;
• Requisitos atrativos: são aqueles que estão além das expectativas do cliente e provocam total satisfação quando presentes.
Um dos principais problemas encontrados é a dificuldade de entender as reais necessidades dos usuários (NUSEIBEH e EASTERBROOK, 2000). Em boa parte dos casos, isso é devido à formação distinta entre analistas e usuários e, portanto, eles têm pontos de vista diferentes sobre o mesmo problema. Outro fator que dificulta o processo de elicitação é que muitas vezes os usuários não têm uma idéia precisa e explícita do sistema a ser
desenvolvido, ou mesmo possuem dificuldades em descrever seu conhecimento sobre o domínio do problema.
A escolha da técnica apropriada para elicitar requisitos depende do tempo e dos recursos disponíveis, assim como do tipo de informação necessária. Algumas das classes de técnicas de elicitação são (ALVES, 2001):
• Técnicas Tradicionais: incluem o uso de questionários, entrevistas, análise de
documentação existente. Para Pressman (1995), a identificação de requisitos da forma tradicional é delegada ao analista de sistemas, que, subjetivamente, elenca os elementos problemáticos para o projeto a partir de entrevistas realizadas com os usuários;
• Técnicas de Elicitação de Grupo: são técnicas de dinâmica de grupo com o objetivo de entender de forma mais detalhada as necessidades dos usuários (DAMIAN et al., 1997);
• Prototipação: é utilizada para elicitar requisitos quando há um alto grau de incerteza ou quando é necessário um rápido feedback dos usuários;
• Técnicas de Modelagem: fornece um modelo específico das informações que serão adquiridas, e usa esse modelo para orientar o processo de elicitação;
• Técnicas Cognitivas: inclui uma série de técnicas originalmente desenvolvidas para aquisição de conhecimento para sistemas baseados em conhecimento;
• Técnicas Contextuais: surgiu como uma alternativa para as técnicas tradicionais e cognitivas, inclui técnicas de etnografia e análise social (VILLER e SOMMERVILLE, 1999 apud ALVES, 2001).
O processo de elicitação é uma atividade complexa e quase sempre requer uma quantidade considerável de tempo e recursos. Entretanto, ela é fundamental para garantir que o sistema final atenderá às expectativas e necessidades dos usuários. O resultado final da fase de elicitação é um esboço de documento que contém uma descrição abstrata dos requisitos.
2 SHARP, H. FINKELSTEIN, A. e GALAL, G. Stakeholder Identification in the Requirements Engineering Process. Workshop on Requirements Engineering Process. Florença, Itália. 1999.
2.1.5.2. Análise de Requisitos
O principal objetivo dessa fase é fornecer descrições abstratas dos requisitos que possam ser facilmente interpretadas. Existem inúmeras abordagens para modelagem de requisitos, modelos podem ser usados para representar todo o processo de engenharia de requisitos.
Além disso, muitas abordagens podem ser usadas como ferramentas de elicitação, onde as notações e modelos parciais são usados para direcionar novas aquisições de informações (NUSEIBEH e EASTERBROOK, 2000). Alguns exemplos de modelagem são: organizacional, comportamental, de domínio, de requisitos não-funcionais. Cada classe de modelagem se destina a analisar e resolver um determinado tipo de problema (ALVES, 2001).
Durante os processos de análise e negociação são encontrados problemas com os requisitos, tais como: requisitos esquecidos, conflitantes, ambíguos e duplicados. A partir da
identificação desses requisitos com problemas, os usuários devem discutir, priorizar e negociar esses requisitos até que se obtenha um acordo com possíveis modificações e simplificações. O processo de negociação de requisitos tenta resolver conflitos entre usuários sem necessariamente comprometer a satisfação dos objetivos de cada usuário. Em geral, os modelos de negociação identificam as principais necessidades de cada usuário, ou seja, atribuem prioridades aos requisitos, em seguida analisam esses resultados para tentar garantir que os requisitos mais críticos sejam atendidos (ALVES, 2001).
Em princípio, a negociação de requisitos deveria ser um processo objetivo. As decisões a serem tomadas em relação aos requisitos do sistema deveriam ser baseadas nas
necessidades técnicas e organizacionais (KOTONYA e SOMMERVILLE, 1997) e preferencialmente, atendendo as características e subcaracterísticas definidas pela norma ISO-9126 (2000), tais como: confiabilidade, usabilidade, eficiência, etc. Entretanto, segundo Alves (2001), a realidade é normalmente diferente, negociações raramente são conduzidas usando somente argumentos lógicos e técnicos, elas também são fortemente influenciadas pelas necessidades pessoais dos indivíduos.
2.1.6. Desdobramento dos requisitos da qualidade para softwares
A ISO define a qualidade dos produtos de software através do modelo de qualidade de produtos de software segundo a série de normas ISO/IEC 9126. Estas normas listam o conjunto de características que devem ser verificadas em um software para que ele seja considerado um "software de qualidade" (ABNT, 2001; WEBER et al., 2001).
2.1.6.1. Norma ISO/IEC 9126
A norma ISO/IEC 9126 subdivide-se em: ISO/IEC 9126-1: Modelo de Qualidade; ISO/IEC 9126-2: Métricas externas; ISO/IEC 9126-3: Métricas Internas e ISO/IEC 9126-4: Métricas de Qualidade em Uso (BARBOSA, 2000; ABNT, 2001; WEBER et al., 2001).
A ISO/IEC 9126-1 fornece um modelo de propósito geral o qual define seis amplas categorias de características de qualidade de software: funcionalidade, confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade. Estas podem ser subdivididas em subcaracterísticas que possuem atributos mensuráveis. O efeito combinado das
características de qualidade em uma situação particular de uso é definido como qualidade em uso (ISO/IEC 9126, 2000). As subcaracteristicas podem ser medidas por meio de métricas definidas pelas partes 2, 3 e 4 da norma ISO/IEC 9126. O Anexo F apresenta algumas das métricas estabelecidas pela norma (ABNT, 2001).
Segundo a ISO/IEC 9126 (2000), convém que: 1) a qualidade de produtos de software seja avaliada usando um modelo de qualidade definido; 2) este modelo de qualidade seja usado durante o estabelecimento de metas de qualidade para produtos de software finais e
intermediários; 3) a qualidade do produto seja hierarquicamente decomposta por meio de um modelo de qualidade composto de características e subcaracteristicas as quais possam ser usadas como uma lista de verificação de tópicos relacionados com qualidade (ABNT, 1999; WEBER et al., 2001).
Características de Qualidade Internas e Externas
O modelo de qualidade nesta parte da série ISO/IEC 9126 categoriza os atributos de qualidade de software em seis características: funcionalidade, confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade (Figura 6), as quais são, por sua vez,
subdivididas em subcaracteristicas (ABNT, 2001):
• Funcionalidade: conjunto de atributos que evidenciam a existência de um conjunto de funções e suas propriedades especificadas. As funções são as que satisfazem as
necessidades explícitas ou implícitas;
• Confiabilidade: conjunto de atributos que evidenciam a capacidade do software de manter seu nível de desempenho sob condições estabelecidas durante um período de tempo estabelecido;
• Usabilidade: conjunto de atributos que evidenciam o esforço necessário para se poder utilizar o software, bem como o julgamento individual desse uso, por um conjunto explícito ou implícito de usuários;
• Eficiência: conjunto de atributos que evidenciam o relacionamento entre o nível de desempenho do software e a quantidade de recursos usados, sob condições
estabelecidas;
• Manutenibilidade: conjunto de atributos que evidenciam o esforço necessário para fazer modificações especificadas no software;
• Portabilidade: conjunto de atributos que evidenciam a capacidade do software de ser transferido de um ambiente para outro.
