FACULDADE FARIAS BRITO CIÊNCIA DA COMPUTAÇÃO

Tamanho: px
Começar a partir da página:

Download "FACULDADE FARIAS BRITO CIÊNCIA DA COMPUTAÇÃO"

Transcrição

1 FACULDADE FARIAS BRITO CIÊNCIA DA COMPUTAÇÃO JOÃO BATISTA DE SOUSA FILHO SISREQUI Sistema Especialista para Auxílio no Processo da Engenharia de Requisitos. Fortaleza, 2011

2 JOÃO BATISTA DE SOUSA FILHO SISREQUI Sistema Especialista para Auxílio no Processo da Engenharia de Requisitos. Monografia apresentada para obtenção dos créditos da disciplina Trabalho de Conclusão do Curso da Faculdade Farias Brito, como parte das exigências para graduação no Curso de Ciência da Computação. Orientador: José Helano Matos Nogueira, Msc. Fortaleza, 2011

3 SISREQUI SISTEMA ESPECILISTA PARA AUXÍLIO NO PROCESSO DA ENGENHARIA DE REQUISITOS. João Batista de Sousa Filho PARECER NOTA: FINAL (0 10): Data: / / BANCA EXAMINADORA: MSc. José Helano Matos Nogueira Orientador Dr. Paulo Benicio Melo de Sousa Examinador MSc. Ricardo Wagner Cavalcante Brito Examinador

4 Dedico este trabalho à minha família, pois representa a motivação central para a conclusão do mesmo.

5 AGRADECIMENTOS Ao Orientador Msc. Helano Matos, por ter aceitado a ideia inicial deste trabalho e pela paciência, coordenação, disponibilidade e ajuda. A todos os colegas de trabalho (Alexsandro Dórea, Cassiano Mourão, Fernando Pinto, Renan Sousa e Santana Magalhães) que me ajudaram na criação da base de conhecimento do SISREQUI. Aos professores e colegas da faculdade que ajudaram de maneira direta ou indireta para a minha formação. A minha mãe que sempre acreditou em mim e me apoio nos momentos que mais precisei. A Santana Magalhães que me indicou a fazer um curso com o Paulo Vieira, onde este me ajudou a me conhecer melhor e assim tive a força e garra para terminar este trabalho e assim realizar um de meus sonhos. A Deus, meu grande e amado pai que ao meu lado vem me ajudando e me orientado nos caminhos da vida. E a todos que puderam contribuir de alguma forma.

6 RESUMO As empresas desenvolvedoras de software estão cada vez mais tentando melhorar os seus processos de desenvolvimento de software. Ao Adotar processos definidos por instituições nacionais e/ou internacionais. Mas mesmo com a adoção de tais processos, os projetos de software tendem a falhar. Pesquisas realizadas por instituições de avaliação de risco e referenciadas por alguns autores apontam que os problemas que ocorrem nos projetos estão relacionados à não utilização correta dos princípios da disciplina de engenharia de requisitos. A disciplina tem uma série de conceitos desde a explicação do que são os requisitos do software, requisitos de usuário e requisitos de sistema, como descrevê-los corretamente nos documentos de requisitos, as formas de descobertas, validação, verificação e analise de mudanças dos requisitos. Uma série de conceitos, que somados à complexidade dos sistemas e à falta de experiência na área, acabam se tornando uma tarefa muito complexa. Mas por outro lado, tem crescido nos últimos anos a criação e/ou utilização de softwares que simulam o comportamento de especialistas humanos de uma determinada área, que resolvem problemas complexos na resolução de problemas complexos, denominados Sistemas Especialistas. Neste contexto inseriu-se esta monografia que apresenta uma proposta de criação de um sistema especialista, com o auxílio de uma ferramenta de criação de sistemas especialistas, para auxiliar a Analistas de Requisitos, Analistas de Sistemas e Analistas de Negócio, na aplicabilidade dos conceitos da Engenharia de Requisitos. Este trabalho tem sua contribuição no fornecimento de meio de aprendizado dos conceitos da disciplina, ressaltando quais são as melhores alternativas a se tomar em determinadas situações.

7 SUMÁRIO INTRODUÇÃO A DISCIPLINA DE ENGENHARIA DE REQUISITOS Requisitos de Software Requisitos de Usuário Requisitos Funcionais Requisitos Não Funcionais Requisitos de Sistema Documentos de requisitos de software RUP e seus artefatos Visão Especificação Suplementar Glossário Regras de negócios Caso de Uso Especificação de Requisitos de Software Extreme Programming (XP) e as estórias de usuários Scrum e o Backlog do produto Pontos Positivos e Negativos Sobre os Modelos PROCESSO DE ENGENHARIA DE REQUISITOS Elicitação de requisitos Entrevistas Tempestade de idéias (Brainstorm) Cenários Etnografia Verificação e validação de requisitos Gerenciamento de requisitos Rastreabilidade de requisitos SISTEMAS ESPECIALISTAS Introdução aos Sistemas Especialistas Expert SINTA Arquitetura de um sistema especialista no Expert SINTA Representação do Conhecimento Regras de Produção Cálculo Probabilístico dos Sistemas Especialistas... 31

8 4. SISTEMA ESPECIALISTA PARA AUXÍLIO NO PROCESSO DA ENGENHARIA DE REQUISITOS Projeto SISREQUI Estudo de viabilidades Formalização do Especialista em Engenharia de Requisitos Aquisição de conhecimento Implementação do SISREQUI Implementando o sistema Base de conhecimento Variáveis Objetivos Interface com o usuário Regras Informações adicionais Consultando o SISREQUI Consultas Acompanhamento Janela de Resultados Atingidos Garantindo a relevância do SISREQUI CONCLUSÕES REFERÊNCIAS BIBLIOGRÁFICAS ANEXOS I QUESTIONÁRIO UTILIZADO NA CRIAÇÃO BASE DE CONHECIMENTO DO SISREQUI ANEXOS II RESPOSTAS DO QUESTIONÁRIO UTILIZADO NA CRIAÇÃO BASE DE CONHECIMENTO DO SISREQUI ANEXOS III BASE DE CONHECIMENTO SISREQUI... 75

9 LISTA DE FIGURAS Figura 1 Fatores na conclusão de projetos. Fonte: The Standish Group Figura 2 Fatores críticos para o sucesso dos projetos. Fonte: The Standish Group Quadro 1 Especificação de requisito de sistema. Fonte: Sommerville, 2008, Modificado Figura 3 - Interessados presentes na ERS. Fonte: Sommerville, 2008, pag Figura 4 Rastreabilidade de requisitos. Fonte: Sayão e Leite, Figura 5 Arquitetura Simplificada do Expert SINTA. Fonte: Lia, Figura 6 Exemplo de tratamento probabilístico do caso Figura 7 - Exemplo de tratamento probabilístico do caso Figura 8 - Exemplo de tratamento probabilístico do caso Figura 9 - Exemplo de tratamento probabilístico do caso Figura 10 - Exemplo de regra com mais de um objetivo Figura 11 Ambiente do Expert SINTA. Fonte: Lia, Figura 12 Criando uma nova Base de Conhecimento no Expert SINTA Figura 13 Janela KIB. Fonte: Lia, 1999, Modificado Figura 14 Janela de criação de variáveis. Fonte: Lia, 1999, Modificado Figura 15 Janela de seleção de variáveis objetivos do SISREQUI. Fonte: Lia, 1999, Modificado Figura 16 Janela de seleção de variáveis perguntas do SISREQUI. Fonte: Lia, 1999, Modificado.. 46 Figura 17 Caixa de seleção de Ordem e modelo de regra. Fonte: Lia, Figura 18 Tela de criação de regra de produção. Fonte: Lia, Figura 19 Tela de inserção de premissas. Fonte: Lia, Figura 20 Tela de inserção de objetivos. Fonte: Lia, Figura 21 Janela de informações adicionais do SISREQUI. Fonte: Lia, 1999, Modificado Figura 22 Menu de controle de consultas. Fonte: Lia, Figura 23 Tela de abertura do SISREQUI Figura 24 Interface SISREQUI Figura 25 Resposta do SISREQUI com respectivo grau de confiança

10 Figura 26 Tela de ajuda do SISREQUI Figura 27 Execução do SISREQUI pelo modo depurador Figura 28 Tela de Resultados Figura 29 Arvore de pesquisa Figura 30 Todos os resultados Figura 31 Regras do SISREQUI Figura 32 Gráfico de teste do SISREQUI em projetos concluídos Figura 33 Gráfico de teste do SISREQUI em projetos não concluídos Figura 34 Média de resultados

11 LISTA DE QUADROS Quadro 1 Especificação de requisito de sistema. Fonte: Sommerville, 2008, Modificado Quadro 2 Estória de Usuário Quadro 3 Exemplo de um Backlog do produto... 15

12 LISTA DE SIGLAS AR Analista de Requisitos. ASE Arcabouços de Sistema Especialista. CMMI - Modelo Integrado de Maturidade e de Capacidade. IA Inteligência Artificial. IBM International Business Machine. MPS.Br - Melhoria de Processo do Software Brasileiro. SE Sistema Especialista. XP Extreme Programming.

13 GLOSSÁRIO Analista de Requisitos (AR): Responsável pela coleta, análise, validação e documentação dos requisitos junto ao cliente e passar esses requisitos coletados para os desenvolvedores (RUP, 2006). Artefato: Artefatos são produtos de trabalhos, finais ou intermediários, produzidos e usados para capturar e transmitir informações do projeto (RUP, 2006). Um artefato pode ser um dos seguintes elementos: Um documento, como Caso de Negócio ou Documento de Arquitetura de Software; Um modelo, como o Modelo de Casos de Uso ou o Modelo de Projeto; Um elemento do modelo, ou seja, um elemento existente em um modelo, como uma classe ou um subsistema. Ator: É uma entidade de fora do sistema que interage com o mesmo. Os atores podem ser os usuários do sistema, outros sistemas de computador ou eventos externos (RUP, 2006). Backlog do produto: É documento contendo todos os requisitos detalhadamente, com o tempo estimado para desenvolvimento dos requisitos assim como os responsáveis pelo desenvolvimento dos mesmos, agrupados de acordo com as suas prioridades. CMMI: Modelo Integrado de Maturidade e de Capacidade, voltado à melhoria de processo, composto pelas melhores práticas de desenvolvimento de projetos, abordando o ciclo de vida do produto desde a concepção até a entrega e manutenção. Documento de visão: Artefato RUP, que define as necessidades e características dos envolvidos e usuários-alvo do projeto (RUP, 2006). Documento Especificação de caso de uso: Consiste na descrição detalhada, mostrando passo a passo uma funcionalidade do sistema e a comunicação com os atores (RUP, 2006). Especificação de Requisitos de Software (ERS): Documento que descreve todos os requisitos de software que o sistema terá ou parte deles. Quando a modelagem de casos de uso é utilizada, os casos de uso aplicáveis estarão descritos no ERS (RUP, 2006). Especificação suplementar: Artefato RUP, que conterá todos os requisitos não funcionais necessários ao desenvolvimento do projeto (RUP, 2006).

14 Estórias de Usuário (User Stories): são descrições textuais sucintas a respeito das funcionalidades do sistema. Extreme Programming (XP): Processo ágil de desenvolvimento de software, que visa o trabalho em equipe com foco a agilidade para se atingir a total satisfação do cliente. Interessados (Stakeholders): Termo utilizado para designar todos aqueles que, de alguma maneira, estão envolvidas no projeto (pessoas ou organizações). Organização Internacional para a Padronização (ISO 9001 (2008)): Norma voltada em promover a adoção de uma abordagem de processo para aumentar a qualidade no desenvolvimento, implementação e melhoria no atendimento aos requisitos do cliente. Melhoria de Processo do Software Brasileiro (MPS.Br): Em desenvolvimento desde dezembro de 2003, pela Associação para Promoção da Excelência do Software Brasileiro (SOFTEX). O programa tem como base melhorar o processo de requisitos com base nos princípios da Engenharia de Software. Metodologias Ágeis: Abordagens de desenvolvimento que buscam descobrir as melhores, mais rápidas e eficientes maneiras de desenvolver softwares. As metodologias ágeis têm as seguintes características: Maior comunicação e participação do cliente, ao invés de negociações de contratos; Maior interação entre pessoas do projeto, que processos e ferramentas; Responder a mudanças mais que seguir um plano; Software em funcionando ao invés de extensas documentações. Processo Unificado (UP): Plataforma de processo de desenvolvimento de software desenvolvida inicialmente pela Rational Software, Inc.; Hoje controlada pela IBM. Rational Unified Process (RUP): O RUP é um processo de engenharia de software que tem uma abordagem baseada em disciplinas para atribuir tarefas e responsabilidades dentro de uma organização de desenvolvimento de software com foco em garantir a produção de software de alta qualidade que atenda às necessidades dos usuários dentro de um cronograma e com orçamento previsível (RUP, 2006). SCRUM: Metodologia ágil de projetos de software. No Scrum, os projetos são divididos em sprints, que são ciclos mensais ou semanais.

15 SHELL: Shell é o nome dado a uma família de ferramentas e não à linguagens de programação, que tem o objetivo de apoiar e simplificar o processo de construção de Sistemas Especialistas. Standish group: Grupo de profissionais altamente dedicados com anos de experiência prática na avaliação do risco, custo de retorno e valor de Tecnologia da Informação (TI) que tem como visão: coletar informações sobre o caso na vida real, falhas em ambientes de TI e ajudar a mostrar o caminho para melhorar as taxas de sucesso e aumentar o valor dos investimentos na TI das empresas. Story Points: Unidade de estimativa utilizada no Scrum, para calcular a quantidade de dias que um desenvolvedor trabalhou em uma determinada estória de usuário. Onde o cálculo da story points é feito em cima da quantidade de dias levados para a conclusão de uma estória, multiplicado pela quantidade de pessoas que trabalharam no desenvolvimento da estória. Sistemas Especialistas: Conceito utilizado na IA para definir programas que auxiliam na resolução de problemas de uma determinada área de conhecimento com a mesma qualidade e rapidez que um especialista humano.

16 1 INTRODUÇÃO Atualmente, as organizações estão buscando formas de melhorarem seus processos, seja através de modelos nacionais ou internacionais, tais como CMMI, ISO 9001 (2008) ou MPS.BR (ZANETTI, MONTONI e ROCHA, 2009). O objetivo é ter um melhor aperfeiçoamento dos seus serviços e produtos com maior qualidade (REINALDO, 2006). Contudo, mesmo com a utilização de tais modelos, podem existir problemas decorrentes de falhas na execução do processo ou manutenção de software, em grande parte devido à não utilização correta dos princípios da análise de requisitos (MEDEIROS, BELCHIOR e FARIAS, 2005). O processo de desenvolvimento de software se inicia a partir da fase de Análise de requisitos (MEDEIROS, BELCHIOR e FARIAS, 2005). Nessa fase de descobertas (PRESSMAN, 2005; CAMPELO, 2009), ocorre a elicitação de requisitos, onde são identificadas as necessidades que o software tem que atender e a complexidade de um problema do mundo real (SOMMERVILE, 2008; SWEBOK, 2004; CAMPELO, 2009). Apesar de hoje os softwares desenvolvidos estarem cada vez mais sofisticados, diminuindo a complexidade dos problemas do mundo real, os problemas que ocorrem no processo de desenvolvimento ainda trazem enormes dificuldades aos envolvidos (MEDEIROS, BELCHIOR e FARIAS, 2005). Oliveira (2008) comenta que, para minimizar os problemas que ocorrem no ciclo de desenvolvimento de software, basta a utilização da análise de requisitos, pois, segundo o mesmo, 37% dos problemas que ameaçam os projetos estão relacionados a requisitos. Uma pesquisa anterior do Standish Group reforça as palavras ditas por Oliveira (2008), pois segundo pesquisa realizada em 1995 por esta instituição, apenas 16% dos projetos são finalizados com sucesso, 31% dos projetos fracassam por algum motivo, enquanto mais de 53% dos projetos extrapolam o tempo, custos e/ou não satisfazem os clientes conforme figura 1.

17 2 Projetos Bem sucedidos Problemáticos Fracassados 31% 16% 53% Figura 1 Fatores na conclusão de projetos. Fonte: The Standish Group. Essa pesquisa teve o intuito de identificar as falhas dos projetos de softwares, os fatores causadores das falhas e os meios de se evitar as falhas dos projetos. O envolvimento dos usuários no projeto, suporte da gerência executiva e estabelecimento claro dos requisitos, foram apontados pela pesquisa como os fatores responsáveis pelo sucesso dos projetos, conforme mostrados na figura 2. Fatores de Sucesso Envolvimento dos Usuários 16% 14% Suporte da gerência executiva 57% 13% Estabelecimento claro dos requisitos Outros (planejamento apropriado, equipe competente comprometimento, outros) Figura 2 Fatores críticos para o sucesso dos projetos. Fonte: The Standish Group.

18 3 Nos projetos problemáticos e/ou fracassados os maiores problemas estão na falta de um levantamento completo dos requisitos e/ou no não tratamento correto na mudança de requisitos. Portanto, com o intuito de se chegar ao desenvolvimento correto de um software, evitando ou reduzindo casos de falhas no processo de criação e gerando mais tarde gastos com manutenção e correção de erros, é fundamental o correto entendimento e aplicação da disciplina de Engenharia de Requisitos. Mas, entender e aplicar corretamente os princípios da análise de requisitos para analistas que não sejam especialistas na área acaba se tornando uma tarefa muito complexa. Por outro lado, recentemente, tem crescido bastante a quantidade de softwares que capturam e simulam o comportamento de especialistas humanos, estes denominados Sistemas Especialistas (NOGUEIRA e SILVA, 1997; DIEHL, 2000). A utilização de sistema especialista voltado para a área de engenharia de requisitos iria auxiliar os analistas a tratarem de problemas complexos, onde a solução só seria alcançada com a ajuda de um especialista na área de requisitos. Segundo os autores citados anteriormente, a utilização de um sistema especialista se torna necessária devido a diversos fatores tecnológicos e econômico-sociais tais como: Dificuldade de acesso a especialistas humanos em determinadas regiões; Armazenamento e formalização do conhecimento de vários especialistas humanos; Ferramenta de apoio à tomada de decisões por parte do especialista; Treinamento de profissionais e imparcialidade na tomada de decisões. Por essas razões este trabalho tem com objetivo principal a criação de um sistema especialista com o auxílio do Expert SINTA para a área de engenharia de requisitos denominado SISREQUI. O SISREQUI não tem o intuito de retirar do homem o trabalho abordado na fase de requisitos, o objetivo do SISREQUI e o de auxiliar e/ou treinar analistas de sistemas, analistas de requisitos e analistas de negócios no correto desenvolvimento e aplicabilidade da engenharia de requisitos no processo de desenvolvimento de sistemas computacionais, diminuindo assim a complexidade e facilitando a utilização eficiente e eficaz dos conceitos de engenharia de requisitos.

19 4 Este trabalho está estruturado em quatro capítulos, onde o primeiro capítulo aborda os conceitos da disciplina de engenharia de requisitos, explicando o que são requisitos de softwares e quais os seus documentos. Já o segundo capítulo descreve o processo da engenharia de requisitos abordando desde o levantamento dos requisitos junto ao cliente até a validação dos requisitos e o gerenciamento dos mesmos. O terceiro capítulo comenta sobre o uso de ferramentas automatizadas geradoras de sistema especialistas, onde é exemplificado o uso do Expert SINTA 1. Também é apresentada a arquitetura básica de um sistema especialista com suas regras de produção. O quarto capítulo descreve o Sistema de Requisitos proposto, SISREQUI. Neste capítulo é detalhado como será a base de conhecimento do sistema, quais as variáveis, objetivos, regras e interfaces com o usuário o mesmo terá. Ao final do capítulo são apresentados os resultados que foram atingidos com o sistema. 1 Ferramenta criada pelo Laboratório de Inteligência Artificial da Universidade Federal do Ceará LIA/UFC (

20 5 1. A DISCIPLINA DE ENGENHARIA DE REQUISITOS O objetivo deste capítulo é apresentar a disciplina de Engenharia de Requisitos, mostrando o que são requisitos de software, abordados na seção 1.1 e mostrando os documentos de requisitos, seção 1.2, com seus modelos definidos em processos de desenvolvimento de software, tais como RUP, XP e SCRUM. 1.1 Requisitos de Software Com a globalização do mercado e a alta competividade existente entre as organizações desenvolvedoras de software tem crescido, nessas organizações, a necessidade de se criar softwares em menos tempo e com poucos recursos, com maior qualidade que atinja a satisfação dos clientes (ZANETTI; MONTONI e ROCHA, 2009). Meira (2008) comenta que as organizações consideram as áreas de especificação de requisitos e a gerência de requisitos do cliente como os principais focos de problemas no desenvolvimento do software. Melhorar os processos de descobertas, documentação e controle de requisitos do cliente são fatores críticos para o sucesso do negócio (PRESSMAN, 2005). O sucesso no processo de engenharia de requisitos se torna possível quando se consegue entender as diferenças entre os requisitos de usuário e dos requisitos de sistema (SOMMERVILLE, 2008). Os requisitos de usuário e de sistema podem ser definidos da seguinte maneira: Requisitos de usuário são declarações, em uma linguagem natural, contendo os serviços que são esperados pelo sistema e suas restrições. Requisitos de sistema são descrições detalhadas de como serão exatamente implementados as funções, serviços e as restrições do sistema.

21 6 A seguir tais modelos são mostrados e exemplificados com maiores detalhes Requisitos de Usuário Os requisitos de usuário devem descrever os requisitos funcionais e não funcionais do sistema. Estes requisitos devem ser descritos o mais próximo da linguagem natural, evitando-se o máximo a utilização de termos técnicos, de modo que sejam compreensíveis para a leitura de usuários que irão utilizar o sistema. Eles devem especificar apenas detalhes externos do sistema, evitando-se características de projeto (SOMMERVILLE, 2008) Requisitos Funcionais Os requisitos funcionais detalham ações que o sistema deve ter, sem levar em consideração as restrições físicas (SEWBOOK, 2004). Os requisitos funcionais dependem do tipo de software que está sendo desenvolvido e dos usuários aos quais o software se destina. Quando expressos como requisitos de usuários, eles são descritos de forma abstrata, mas, como requisitos funcionais, eles devem ser descritos com maior nível de detalhamento, descrevendo suas entradas, saídas e exceções. (SOMMERVILLE, 2008). Por exemplo, um requisito funcional de funcionamento de um sistema de locadora de filmes, na rotina de pesquisa de um filme pelo título poderia ser descrito como: 1. Quando o usuário solicitar a pesquisa de algum filme ele informa alguma palavra como chave; 2. O sistema deve buscar no banco de dados todos os filmes que tenham no título ou sinopse a palavra informada pelo usuário em seguida deve exibir os 20 primeiros resultados em ordem alfabética. Este requisito funcional foi um exemplo de como é feita a interação entre usuário e sistema. Os requisitos podem ser descritos em diferentes níveis, como no exemplo acima, contanto que seu entendimento fique claro a quem o ler. Geralmente, os requisitos funcionais são descritos em um documento de casos de uso.

22 Requisitos Não Funcionais Os requisitos não funcionais são relacionados às características restritivas dos sistemas, tais como: confiabilidade, tempo de resposta, desempenho, interface, espaço de armazenamento (RUP, 2006). Tais restrições podem afetar tanto na implementação dos requisitos funcionais quanto nos componentes do sistema (SWEBOOK, 2004; OLIVEIRA, 2008). Por exemplo, no mesmo sistema de locadora de filmes, um requisito não funcional seria: 1. A interface do sistema deve ser leve, para que o acesso seja possível por uma conexão de internet de no mínimo 60 kbps. 2. O tempo de resposta no sistema em uma pesquisa não poderá ser superior a 60 milissegundos Requisitos de Sistema O comportamento externo do sistema, bem como suas restrições operacionais, são formas de descrição de requisitos de sistema (SWEBOOK, 2004). Sommerville (2008) comenta que especificar completamente um sistema de software complexo no nível de detalhe necessário é uma prática inviável, pois, em alguns casos, os sistemas terão de interagir com outros sistemas existentes, restringindo o projeto e impondo requisitos ao novo sistema. Para a descrição de requisitos de sistemas, como também de usuários, deve-se utilizar a linguagem natural. Contudo, como os requisitos de sistemas são mais detalhados que os requisitos de usuários, as especificações em linguagem natural podem acabar ficando mais confusas e difíceis de serem compreendidas. Logo, pode-se escrever os requisitos de sistema usando notações mais especializadas como casos de uso, diagramas de classes, sequencia ou até formulários padrões (SOMMERVILLE, 2008).

23 8 Um exemplo de especificação de requisito de sistema utilizando um formulário padrão para o sistema de locadora de filmes seria: Função: Calcular o valor de filmes. Descrição: Calcular o valor dos filmes solicitados para empréstimo. Entradas: Código do Filme e Nome ou CPF do cliente. Saídas: Valor calculado. Destino: Controle financeiro. Ação: O valor será calculado [ se o cliente não possuir nenhum débito negativo com a empresa. Se o mesmo possuir algum débito, será impresso uma nota promissora informando o valor que está em atraso.] Caso contrário o valor dos filmes e calculado e impresso. Requer: Fornecimento do código do filme e o nome ou CPF do cliente. Pré-Condição: O cliente possuir cadastro e não ter nenhum débito negativo com a locadora. Pós-Condição: Valor calculado e nota promissória impressa. Quadro 1 Especificação de requisito de sistema. Fonte: Sommerville, 2008, Modificado. 1.2 Documentos de requisitos de software A Especificação de Requisitos tem por finalidade estabelecer e manter um entendimento comum sobre o sistema entre de todos os envolvidos (SOMMERVILLE, 2008). Ela deve abranger todos os requisitos do sistema, definir a interface de usuário para o sistema, determinar as fronteiras, custos e o tempo de desenvolvimento do sistema (RUP, 2006). Para se conseguir atingir essas metas, é importante compreender o problema para saber se é possível resolvê-lo com o sistema a ser construído. As solicitações dos usuários são recolhidas, reunidas e analisadas, que posteriormente se tornarão os requisitos de software que o sistema terá. Os requisitos de software são descritos em um documento chamado de especificação de requisitos de software. A Especificação de Requisitos de Software (ERS), também conhecida como documento de especificação de software, é o documento que contém todos os requisitos de software que envolvem o projeto, ou seja, é a declaração do que os desenvolvedores do sistema devem implementar (SEWBOOK, 2004), podendo incluir também os casos de uso,

24 9 requisitos funcionais e não funcionais (RUP, 2006; CAMPELO, 2009). O documento de ERS abrange vários tipos de usuários, desde os patrocinadores até os responsáveis pelo desenvolvimento de software (SEWBOOK, 2004). A ERS controla a evolução do sistema em toda a fase de desenvolvimento do projeto. Mesmo quando novos recursos são adicionados ou modificados, eles são elaborados dentro da ERS (RUP, 2006). A figura 3 ilustra alguns dos grupos de interessados que contribuem com a ERS e seus respectivos focos de atenção. Figura 3 - Interessados presentes na ERS. Fonte: Sommerville, 2008, pag. 91. A quantidade de possíveis interessados presentes na ERS significa que a escrita da mesma deve estar compreensível para todos. O nível de detalhamento do documento dependerá das características do sistema que será desenvolvido e do processo de desenvolvimento que está sendo utilizado. Sommerville (2008) explica que grandes organizações como o IEEE definiram padrões para as ERS. Um dos mais conhecidos é IEEE/ANSI o qual de acordo com Sommerville (2008), possui a seguinte estrutura: 1. Introdução 1.1. Propósito do documento de requisitos 1.2. Escopo do produto 1.3. Definições, acrônimos de abreviaturas

25 Referências 2. Descrição geral 2.1. Perspectiva do produto 2.2. Funções do produto 2.3. Características dos usuários 2.4. Restrições gerais 2.5. Suposições gerais 2.6. Suposições e dependências 3. Requisitos específicos abrangem requisitos funcionais, não funcionais e de interface. 4. Apêndices 5. Índice Embora o padrão não seja o ideal, ele contém boas recomendações de como descrever requisitos, evitando-se problemas futuros. O padrão é muito geral e acaba não sendo pouco adotado pelas instituições. Todavia, pode ser adaptado e modificado para a realidade de cada instituição (SOMMERVILLE, 2008). A ERS é indispensável quando o sistema está sendo desenvolvido por uma equipe externa. Os métodos ágeis de desenvolvimento apontam que os requisitos mudam tão frequentemente que a ERS ficaria desatualizada rapidamente e mantê-la atualizada resultaria em esforço inútil. Sommerville (2008) comenta que em situações como a descrita anteriormente, a descrição de requisitos de usuário e mais aconselhável utilizar a abordagem dos métodos ágeis, como a Extreme Programming (XP) e SCRUM onde se priorizam apenas os requisitos que serão implementados RUP e seus artefatos O RUP tem vários documentos a serem utilizados em processos de desenvolvimento de softwares. Smith (2003) explica que para utilizar o RUP, as empresas não necessitam utilizar todos os artefatos, pois a seleção e adaptação de artefatos é uma parte

26 11 necessária no processo. O próprio RUP oferece orientações sobre como adaptá-lo à realidade da empresa desenvolvedora de software (SMITH, 2003). Para o RUP, os objetivos da disciplina de requisitos são: Estabelecer a concordância com todos os envolvidos sobre o que o sistema a ser desenvolvido; Oferecer aos desenvolvedores do sistema um entendimento sobre requisitos do sistema; Definir as fronteiras do sistema; Fornecer uma base para planejar o conteúdo técnico das repetições; Fornecer uma base para estimar o custo e o tempo de desenvolvimento do sistema; Definir uma interface de usuário para o sistema, com base nas necessidades e metas dos usuários; Artefatos necessários para se chegar esses objetivos são: Documento de Visão; Especificação suplementar; Glossário; Regras de negócios; Casos de uso; Especificação de requisitos de software. Esses documentos são utilizados como formas de se descrever o sistema, em projetos nos quais os interessados são vistos como fontes de informações (RUP, 2006) Visão O documento de visão tanto fornece uma visão completa do negócio a ser atendido pelo desenvolvimento do sistema, como também serve de auxílio para o contrato entre cliente e a organização de desenvolvimento. O documento de visão é uma referência que

27 12 contem as expectativas capturadas entre os envolvidos (RUP, 2006). A visão é escrita com base nas perspectivas dos clientes, focalizando as características cruciais do sistema, os níveis desejáveis de qualidade e descrição das características dos sistemas, tanto as que serão incluídas, bem como aquelas que foram consideradas, mas não incluídas (RUP, 2006). Ela também deve especificar as capacidades operacionais, como tempo de resposta e os usuários que utilizarão o sistema. O documento de visão fornece uma base contratual com os envolvidos para os requisitos visíveis que terá o sistema, podendo ser modificada conforme os requisitos sejam entendidos com maiores detalhes. O documento de visão pode também ser expresso em casos de uso (RUP, 2006) Especificação Suplementar A especificação suplementar é um modelo que contém todos os requisitos funcionais e não funcionais essenciais para o sistema que não são descritos imediatamente nos documentos de casos de uso (RUP, 2006). Entre os requisitos estão incluídos requisitos de regulamentação e padrões de aplicativo, atributos de qualidade do sistema, requisitos de usabilidade, confiabilidade, desempenho, suportabilidade, segurança, portabilidade, restrições computacionais dentre outras, sistemas operacionais e ambientes (RUP, 2006) Glossário Nas fases de elicitação e/ou descrição dos requisitos, termos técnicos podem surgir e para que esses requisitos possam ser entendidos, modelados e desenvolvidos, se torna necessário que o significado dos mesmos sejam descritos em um glossário. Nele são descritos todos os termos necessários para entender a modelagem do negócio e termos específicos do projeto. Com o glossário se cria um vocabulário que contem os termos e as expressões mais comuns com todas as descrições textuais do negócio, evitando-se mal-entendidos entre os envolvidos no projeto sobre o uso e o significado dos termos (RUP, 2006).

28 Regras de negócios No documento de regras de negócios são descritas as regras de negócios impostas com base em leis e regulamentos ou padrões da empresa utilizados para o correto desenvolvimento dos requisitos que o software precisa atender. As regras de negócios são descritas em uma linguagem rigorosa e formal (RUP, 2006). A descrição das regras de negócios deve conter informações de como se obter alguma informação especifica para alguma ação do sistema, regras de como deve ser feito algum cálculo específico, comportamento e exibição de campos, dentre outras. No documento de regras de negócios é descrito o comportamento dos requisitos de negócios e das ferramentas de negócios, podendo estes requisitos e ferramentas serem leis e regulamentos impostos ao negócio, como também arquitetura e o estilo de negócio escolhidos para o sistema (RUP, 2006) Caso de Uso O documento de caso de uso é um modelo das funções pretendidas do sistema e seu ambiente, uma descrição de como será a funcionalidade do sistema (RUP, 2006). Casos de uso definem principalmente os requisitos funcionais do sistema refinados por fluxos de eventos mais detalhados durante a fase de construção (RUP, 2006). Por ser um instrumento de planejamento bastante importante, o documento de casos de uso é usado em todas as fases do ciclo de desenvolvimento (RUP, 2006) Especificação de Requisitos de Software A Especificação de Requisitos de Software no RUP contem todos os requisitos de software para o sistema ou para uma parte dele. O esquema de ERS é parecido com um projeto que utiliza modelagem de casos de uso. A ERS consiste em um pacote contendo casos de uso e Especificações Suplementares aplicáveis, além de outras informações de suporte (RUP, 2006).

29 Extreme Programming (XP) e as estórias de usuários Na Extreme Programming (XP), os requisitos são feitos a partir das estórias de usuário, criadas pelos clientes. As estórias de usuário têm o mesmo propósito dos casos de uso, mas possuem diferenças. Beck (2002) comenta que as estórias de usuário são utilizadas em vez de um documento de requisitos, já que as mesmas são escritas pelos clientes com as funcionalidades que o sistema precisa fazer por eles (BECK, 2002). Elas são semelhantes aos casos de usos, exceto que elas não se limitam a descrever termos técnicos. Estórias de usuário só fornecem detalhes suficientes para fazer uma estimativa de quanto tempo ela levará para ser desenvolvida. No momento da implementação, o desenvolvedor responsável pela estória de usuário, conversa com o cliente para receber uma descrição mais detalhada dos requisitos (WELLS, 1999), conforme quadro 1. Estória 01 Implementar a funcionalidade da pesquisa de filmes. Estimativa Inicial: 4 horas Quadro 2 Estória de Usuário Wells (1999), afirma que um dos maiores mal-entendidos com as estórias de usuário é como elas diferem das especificações tradicionais. A maior diferença está no nível de detalhe (WELLS, 1999). Outra diferença, segundo Wells (1999), entre as estórias de usuário e um documento de requisitos está no foco nas necessidades do usuário evitando-se detalhes de uma tecnologia específica, leiaute base de dados e algoritmos mantendo as estórias focadas nas necessidades do usuário (WELLS, 1999) Scrum e o Backlog do produto O Scrum também utiliza estórias de usuário como forma de armazenar os requisitos (MARTINS, SZALVAY, 2007), mas, diferente do XP, no Scrum as estórias de usuário são descritas com maiores detalhes no Backlog do produto. O Backlog do produto é uma lista de alto nível, definida pelo analista e/ou cliente, que contém todos os requisitos

30 15 funcionais, não funcionais e requisitos técnicos desejados pelo cliente para o sistema (KNIBERG, 2007). No início do projeto, o Backlog do produto deve descrever apenas os requisitos mais importantes. Com o tempo, o Backlog do produto cresce e muda à medida que o cliente descreve melhor os requisitos (MARTINS, SZALVAY, 2007). O documento é compartilhado com todos os membros da equipe, normalmente em algum local da rede da empresa ou em planilhas na rede. No Backlog do produto, os requisitos são numerados, batizados, priorizados e descritos. A lista do produto do backlog é estruturada da seguinte maneira, conforme quadro 3: ID Nome Estimativa Inicial Importância Descrição 01 Cadastro de Filmes 9 (Story Points) 120 O sistema deve pesquisar antes se o filme que está sendo cadastrado já possui cadastro. Caso possua, o sistema deve exibir uma mensagem avisando ao usuário. Caso contrário, o sistema deve efetuar o cadastro. 02 Cadastro de Cliente 9 (Story Points) 120 O sistema deve verificar se o cliente já está cadastrado, avisando ao usuário caso esteja. Caso contrário, o sistema deve efetuar o cadastro. Quadro 3 Exemplo de um Backlog do produto Os tópicos do backlog do produto, segundo KNIBERG (2007), são os seguintes: ID: Numeração da estória de usuário. Identificador utilizado para evitar que se perca o controle sobre as estórias, caso o nome delas seja modificado; Nome: Frase que descreve o que é a estória de usuário; Estimativa Inicial: Estimativa inicial em story points da quantidade de tempo necessário para a implementação da estória de usuário. Exemplo: Digamos que 3 dias é o tempo que 3 desenvolvedores trabalhando junto levariam para desenvolver uma determinada estória. Então temos 3 dias trabalhados X 3 pessoas = 9 story points. Os valores dependem muito do processo adotado pela empresa;

31 16 Importância: Importância da estória de usuário para o Analista, quanto maior o número, maior a importância; Descrição: É a descrição em alto nível, linguagem natural, de como o requisito deve se comportar. O Backlog do produto geralmente é feito em uma planilha e é de responsabilidade do AR, mas pode ser visualizado pelos demais membros e até editado, como por exemplo, um desenvolvedor que deseje alterar a estimativa (KNIBERG, 2007) Pontos Positivos e Negativos Sobre os Modelos A utilização de todos os artefatos da disciplina de requisitos pelo RUP implica em softwares de qualidade que atendem aos princípios da engenharia de software (RUP, 2006), tendo como principais vantagens: Rápida correção de problemas; Rápido desenvolvimento de melhorias; Melhor entendimento sobre o negócio; Melhor visão sobre as funcionalidades do sistema; Requisitos mais definidos e explicados. Contudo, a utilização dos artefatos também possui suas desvantagens: Necessidade de um conhecimento formal sobre como preencher e manter os documentos; Documentos muito extensos; Os artefatos necessitam estar sempre atualizados. Documentar requisitos através de estórias conforme utilizado no XP e SCRUM resolve as principais desvantagens na utilização dos artefatos do RUP. Contudo, as estórias não descrevem com maiores detalhes os requisitos e muitos detalhes acabam passando despercebidos (RUP, 2006), o que acaba requerendo que o desenvolvedor tenha um vasto conhecimento sobre o negócio a ser desenvolvido. Segundo Smith (2003), métodos ágeis não

32 17 proíbem a utilização de documentos ou outros artefatos com as estórias. Os métodos ágeis apenas produzem os artefatos que realmente irão ser utilizados.

33 18 2. PROCESSO DE ENGENHARIA DE REQUISITOS O objetivo deste capítulo e explicar as atividades presentes no processo de engenharia de requisitos. São abordados pontos sobre a elicitação de requisitos e quais as principais técnicas utilizadas para se coletar os requisitos. Será explicada a validação dos requisitos e como se gerenciar os requisitos. O capítulo está organizado da seguinte maneira: A seção 2.1 aborda a elicitação de requisitos e as principais técnicas utilizadas para o correto levantamento dos requisitos. Na seção 2.2 aborda o processo de verificação e validação de requisitos. Finalmente o gerenciamento de requisitos é abordado na seção Elicitação de requisitos A elicitação de requisitos é a atividade em que todos os (interessados) envolvidos no projeto trabalham juntos com o intuito de aprender mais sobre como deve ser o sistema (SOMMERVILLE, 2008). Na elicitação são identificados os requisitos do sistema, chegandose a um entendimento mais completo do software (OLIVEIRA, 2008). Oliveira (2008) ressalta que a fase de elicitação de requisitos não consiste apenas em perguntar aos clientes o que eles querem, e sim fazer um levantamento cuidadoso do domínio e do processo de negócio que o sistema deverá ter. Todavia, a elicitação, segundo Sommerville (2008), acaba se tornando difícil pelas seguintes razões: Os interessados não sabem o que querem; Os interessados utilizam seus próprios termos com conhecimento implícito sobre os requisitos cabendo ao Analista de Requisitos o conhecimento e o domínio para entender esses requisitos;

34 19 Diferentes interessados possuem diferentes formas de expressar os requisitos. O AR deve saber entender os pontos em comum nos requisitos expressados; Fatores políticos podem influenciar nos requisitos do sistema. Por exemplo, um secretário de saúde pode solicitar um requisito que aumentará sua influência no estado; Os requisitos mudam constantemente durante o processo, mudando também a importância de determinados requisitos. Novos requisitos de novos interessados podem surgir. A elicitação de requisitos não se resume à simples transferência de conhecimento das pessoas para documentos de requisitos. Na realidade, acaba se tornando um processo muito mais complexo devido aos fatores descritos anteriormente. Portanto, a elicitação de requisitos não é simplesmente pescar os requisitos, mas um complexo processo de negociação envolvendo todos os interessados envolvidos no projeto (OLIVEIRA, 2008). Para conseguir chegar ao entendimento completo do software são utilizadas algumas técnicas, dentre as quais se destacam: entrevistas, tempestade de ideias, cenários e etnografia Entrevistas Entrevistas formais ou informais com todos os interessados, segundo Sommerville (2008), ocorrem na maioria dos processos de engenharia de requisitos. Nessas entrevistas os ARs formulam questões para os interessados sobre o sistema que eles usam e/ou o sistema que será desenvolvido. Os requisitos vão sendo formulados conforme os interessados forem respondendo as questões. As entrevistas, segundo Oliveira (2008), podem ser de dois tipos: Entrevistas fechadas, onde os ARs perguntam aos interessados uma lista de perguntas já elaboradas. Entrevistas abertas, nas quais não existem perguntas predefinidas. Os ARs exploram vários assuntos com os interessados, de forma a adquirir uma compreensão maior sobre a necessidade dos mesmos.

35 20 Na prática, as entrevistas são uma mistura dos dois tipos. As entrevistas são úteis para conhecer melhor as atividades dos interessados, como eles podem interagir com o sistema e as dificuldades que eles têm com os sistemas atuais (OLIVEIRA, 2008). No entanto, as entrevistas não são úteis para entender o domínio da aplicação (SOMMERVILLE, 2008). Elicitar o domínio da aplicação com entrevistas e muito complicado, pois, os interessados especialistas do domínio não conseguem explicar os requisitos sem termos específicos, ou então acham que os domínios são tão fundamentais que não vale a pena mencioná-los o que acaba provocando um mau entendimento ou não é levado em consideração por parte dos ARs (SOMMERVILLE, 2008). As informações obtidas através das entrevistas, que muitas vezes são a única forma de conhecimento do sistema, complementam outras informações sobre o sistema, como documentos. Para uma correta elicitação, Sommerville (2008) comenta que as entrevistas devem ser aplicadas junto com outras técnicas para a elicitação de requisitos, pois apenas as entrevistas, pode levar a perda de informações essenciais para o sistema Tempestade de idéias (Brainstorm) A tempestade de idéias é uma das mais antigas técnicas para geração de idéias em reuniões em grupo. O princípio básico consiste em reunir um conjunto de interessados especialistas em sistemas e negócios (APARECIDO e CARVALHO, 2002). Na reunião, todos os interessados dão ideias para contribuir para a resolução do problema, cabendo ao AR filtrar as ideias sugeridas e exploradas nestes encontros. No início da fase de desenvolvimento, quando se tem pouco conhecimento do negócio, a aplicação da técnica se torna necessária para o surgimento de novas idéias (OLIVEIRA, 2008). Esta técnica é usada para gerar novas ideias, deixando a mente livre para aceitar todas as ideias criativas que forem sugeridas. O resultado de uma sessão bem-sucedida é a solução do problema com um conjunto de ideias, propostas por todos que participaram da sessão (APARECIDO e CARVALHO, 2002). Em termos de tempo, a tempestade de idéias pode ter um custo baixo, já que uma sessão não leva mais que uma hora, principalmente se os envolvidos já tiverem experiência

36 21 com a técnica e forem criativos. Já em termos de esforços, a tempestade de idéias pode ter um custo relativamente alto, pois requer um número significativo de pessoas, o que não é indicado. O aconselhável é incluir pessoas chaves com diferentes perfis (APARECIDA e CARVALHO, 2002; OLIVEIRA, 2008). Entretanto, segundo Aparecido e Carvalho (2002), levando-se em conta a quantidade de informação coletada com o custo para obtê-la, o uso da técnica tempestade de idéias acaba sendo uma ótima escolha Cenários Os usuários e demais interessados acham mais simples relatar os exemplos do trabalho assim descrever as funcionalidades que deverão existir no sistema. No cenário, eles podem interagir, compreendendo e/ou criticando como seriam as funcionalidades do sistema (OLIVEIRA, 2008). A utilização de cenários para descrever os requisitos do sistema e como o sistema poderá ser utilizada é bastante usado em metodologias ágeis com as estórias ou no RUP com os casos de uso. Um sistema muito grande terá também um número muito grande e complexo de cenários. Os cenários devem incluir pelo menos uma das seguintes informações, segundo Oliveira (2008) e Sommerville (2008): Uma descrição do estado do sistema antes de entrar no cenário; O fluxo normal de eventos no cenário; Uma descrição dos possíveis fluxos de exceções; Informações sobre outras atividades que podem ocorrer no mesmo momento; Uma descrição do estado do sistema após concluir o cenário. Os cenários podem ser descritos na forma de textos, diagramas e imagens.

37 Etnografia A etnografia é uma técnica de observação utilizada para obter os requisitos organizacionais e os requisitos de sistema que podem ficar omitidos. A técnica consiste basicamente em o Analista de Requisitos se inserir no ambiente de trabalho para o qual o sistema será desenvolvido (OLIVEIRA, 2008). O AR observa o dia a dia de trabalho das pessoas envolvidas, anotando e construindo imagens de como é o trabalho delas. A etnologia ajuda o AR a descobrir e entender os requisitos reais e implícitos que o sistema deverá ter (SOMMERVILE, 2008). Portanto, o etnógrafo deve ser uma pessoa com boa habilidade de observação e transformação dessa observação em cenários como casos de uso (OLIVEIRA, 2008). Oliveira (2008) comenta que dentre as diretrizes para a etnografia, deve-se preocupar sempre em procurar formas não padronizadas de trabalho, tomar nota de forma detalhada de todas as práticas de trabalho, analisando-as e chegando a uma conclusão e, sempre que possível, combinar a etnografia com entrevistas abertas e outras técnicas de elicitação. 2.2 Verificação e validação de requisitos A validação de requisitos tem o intuito de mostrar que os requisitos atendem realmente ao que o sistema precisa. A validação de requisitos está relacionada à descoberta de problemas que os requisitos possam ter, evitando-se custos excessivos com retrabalho (OLIVEIRA, 2008). O custo de correção de requisitos é o maior dentre as outras partes do processo como projeto ou desenvolvimento, pois um erro de requisito implica que o projeto e o desenvolvimento á que ser mudados e o sistema deverá ser novamente testado (SOMMERVILLE, 2008). Sommeville (2008) comenta que para se ter sucesso no processo de validação de requisitos, se torna necessária a realização de verificações nos requisitos. Essas verificações incluem alguns pontos como:

38 23 Verificar se o sistema está atendendo a todas as necessidades dos interessados, pois o sistema terá diferentes usuários e cada usuário terá necessidades diferentes; Verificar se os documentos (de requisitos) descrevem todos os requisitos e restrições dos usuários, não gerando conflito entre estes os requisitos; Verificar se os requisitos podem realmente ser desenvolvidos com a tecnologia escolhida no prazo e orçamento estipulados, e; Verificar se a descrição dos requisitos está entendível. Os problemas encontrados na validação de requisitos não podem ser subestimados. Conflitos, contradições, erros e omissões nos requisitos devem ser apontados e negociados entre os interessados para se chegar a uma solução para os problemas identificados (SOMMERVILLE, 2008). 2.3 Gerenciamento de requisitos Os requisitos de sistemas de software estão sempre mudando, conforme os interessados têm novos entendimentos sobre os problemas existentes. Cabe aos ARs adaptar os requisitos a esses novos entendimentos. Conforme os usuários utilizem os sistemas, novos requisitos irão surgir (LUIZA e OLIVEIRA, 2008). Luiza e Oliveira (2008) comentam que o gerenciamento de requisitos consiste em compreender e controlar as mudanças dos requisitos. O controle deve ser iniciado a partir do momento que se tiver um documento de requisitos pronto. Os requisitos devem ser acompanhados individualmente, mantendo as ligações dos requisitos que dependem dos requisitos. Sommerville (2008) comenta que a mudança de requisitos quando o sistema já está em operação com o cliente é inevitável. Mudanças no ambiente de trabalho ocorrem e os requisitos evoluem para atender a essas modificações. Para se gerenciar corretamente essas mudanças, o planejamento deve ser feito. O AR deve verificar a validade da solicitação de modificação, as dependências entre os requisitos que podem sofrer modificações, estimar os custos das mudanças, acordar com os usuários os custos de tal mudança e utilizar ferramentas para auxiliar na rastreabilidade destes requisitos (LUIZA e OLIVEIRA, 2008).

39 Rastreabilidade de requisitos A rastreabilidade de requisitos é dita como o centro da atividade de gerenciamento de requisitos. A técnica consiste em acompanhar o ciclo de vida do requisito. A dificuldade da técnica, segundo Luiza e Oliveira (2008), está no grande volume de informações que precisam ser levantadas, associadas e referenciadas, atividade muito complexa que sem o auxílio de ferramentas não conseguirá ser concluída. As informações da rastreabilidade são freqüentemente representadas por meio de matrizes de rastreabilidade (LUIZA e OLIVEIRA, 2008). Nessas matrizes, requisitos são registrados em uma linha e uma coluna da matriz. As dependências dos requisitos são registradas na interseção da linha com a coluna (SOMMERVILLE, 2008). A matriz de rastreabilidade auxilia na manutenção e acompanhamento de requisitos que são criados a partir de planos de negócios e reuniões com os clientes, pré-rastreabilidade, e dos requisitos que são criados a partir de artefatos já definidos e códigos, pós-rastreabilidade, (SAYAO e LEITE, 2005), conforme mostrado na figura 4. Figura 4 Rastreabilidade de requisitos. Fonte: Sayão e Leite, 2005.

40 25 3. SISTEMAS ESPECIALISTAS O objetivo deste capítulo é explicar o que são sistemas especialistas e sua utilização. É abordada uma introdução sobre os sistemas especialistas, mostrando a utilização dos mesmos e comentando o desafio de se criar um sistema especialista. O capítulo está organizado da seguinte maneira: A seção 3.1 aborda os sistemas especialistas e suas áreas de aplicação do conhecimento. A seção 3.2 aborda um software gerador de sistemas especialistas, chamado de Expert Sinta, mostrando como é a sua arquitetura e como é dividido a sua base de conhecimento. 3.1 Introdução aos Sistemas Especialistas Sistemas Especialistas (SE s) são programas capazes de resolver tarefas específicas de uma área de conhecimento supostamente com a mesma qualidade que um especialista humano. Os SE s começaram a ser estudados por volta da década de 60 quando as pesquisas na área da IA, segundo Reategui (1993), eram bastante audaciosas, pois visavam criar resolvedores de problemas com interfaces em uma linguagem natural. Contudo os resultados não eram muito satisfatórios. As pesquisas com a IA começaram a ter melhores resultados a partir do momento em que o foco passou a ser tratar problemas mais restritos de uma área de conhecimento (REATEGUI, 1993). Assim. começou a ser desenvolvido programas que reproduzissem o comportamento humano na resolução de problemas do mundo real (BITTENCOURT, 2006), armazenando, sequenciando informações e autoaprendendo com base nos experimentos práticos impostos pelas situações em estudo (FIGUEIREDO, 2011). Figueiredo (2011) comenta que para um SE entrar em funcionamento, o mesmo deve ser alimentado com informações especificas e orientado a executar determinadas tarefas para a qual se requer o seu uso como também devem ser construídas bases com o

41 26 conhecimento de um especialista da área ao qual o problema se relaciona, programando as variáveis usadas e posteriormente simuladas com base no conhecimento do especialista, de tal forma que ao final o SE seja capaz de oferecer sugestões e conselhos aos usuários e, também, adquirir novos conhecimentos e heurísticas com essa interação (PY, 2006). Portanto, o estudo dos problemas que o SE terá de tratar torna-se essencial. Um SE pode ser aplicado nas mais diversas áreas do conhecimento, como: agricultura, química, sistemas de computadores, eletrônica, engenharia, gerenciamento de informações, etc. (FIGUEIREDO, 2011). Contudo, para se criar um SE, é necessário um software que auxilie no processo, segundo Nogueira e Silva (1997), a construção de um software para a geração de sistemas especialistas não é fácil, pois o software deve ser capaz de tratar e resolver os problemas da mesma maneira que um especialista humano quando se depara com algum problema equivalente. O software também deverá permitir que a captura do conhecimento através de sua interface seja de fácil utilização, que para manusear o mesmo não seja necessário ter um conhecimento aprofundado em informática. O Expert SINTA possui todas estas características e muitas outras, conforme descrito na seção seguinte. 3.2 Expert SINTA O Expert SINTA é, segundo LIA (1999), uma ferramenta utilizada para geração automática de sistemas especialistas com o auxílio de técnicas de Inteligência Artificial. Esta ferramenta possibilita a criação de modelos de representação do conhecimento baseados em regras de produção e probabilidades, possibilitando uma economia de tempo e simplificação do trabalho aos desenvolvedores de sistemas especialistas, construção automática de telas e menus, tratamento das regras de produção e criação de menus de ajuda com explicações sobre a base de conhecimento modelada (LIA, 1999). Um sistema especialista com este tipo de modelo é bastante útil em problemas de classificação, pois o usuário responde a uma sequência de menus e o sistema se encarrega de fornecer respostas que se encaixem no quadro apontado pelo usuário. Mendes (1997), afirma que a grande diferença entre um sistema especialista e um simples programa de banco de dados está no uso de raciocínio lógico para resolução de problemas. Os sistemas especialistas utilizam regras de produção SE e ENTÃO, seguido por

42 27 conectivos relacionados dentro do âmbito do assunto em questão e o uso da probabilidade. A estrutura básica de um sistema especialista é a interface com o usuário, o motor de inferência, e a base de conhecimento Arquitetura de um sistema especialista no Expert SINTA O Expert SINTA tem como objetivo simplificar as etapas de criação de um SE completo, oferecendo uma máquina de inferência básica, fundamentada no encadeamento para trás. O encadeamento para trás é utilizado em problemas que possuem um número muito grande de soluções, mas os meios pelos quais as respostas são alcançadas são restritos (LIA, 1999). Os SE s gerados no Expert SINTA tem sua arquitetura composta basicamente pelos seguintes componentes: Bases de conhecimentos; Editor de bases; Máquina de inferência; Banco de dados global. Tais componentes estão interligados, conforme exemplificado na figura 5. Figura 5 Arquitetura Simplificada do Expert SINTA. Fonte: Lia, 1999.

43 28 Flores (2003) e LIA (1999) definem cada um dos componentes da seguinte maneira: Base de conhecimento: encontra-se o conhecimento do especialista, dividido entre fatos e regras, modelado de acordo com o domínio de representação computacional; Editor de bases: é o meio em que ocorre a implementação das bases desejadas. É responsável pela atualização da base de conhecimentos; Máquina de inferência: é a parte do SE responsável pelas deduções sobre a base de conhecimentos, examinando o conteúdo da base de conhecimentos e decidindo a ordem das inferências; Banco de dados global: Possui as evidências apontadas pelo usuário do sistema especialista durante uma consulta Representação do Conhecimento Parte mais sensível e crítica no desenvolvimento de um SE (NOGUEIRA e SILVA, 1997; BITTENCOURT, 2006), a representação do conhecimento não se limita apenas a adicionar novos elementos à base de conhecimentos, mesclando os novos conhecimentos, com os conhecimentos já armazenados na base (BITTENCOURT, 2008). A representação do conhecimento, segundo Diehl (2000), constitui de um conjunto de mecanismos utilizados no armazenamento e manipulação do conhecimento, modelando de forma eficiente ao ponto de serem utilizados em um sistema inteligente. Existem várias formas de se modelar o conhecimento de um especialista, tais como, lógica matemática, regras de produção, raciocínio baseado em casos, redes probabilísticas, entre outros (FLORES, 2003; DIEHL, 2000). As mais utilizadas, segundo Nogueira e Silva (1997), são as regras de produção (ou regras de realização), que utilizam a teoria das probabilidades, garantindo assim uma maior legibilidade da base de conhecimentos.

44 Regras de Produção Uma regra em si é um conjunto de premissas, normalmente escritas com sintaxe próxima à linguagem natural, que realizam as conclusões indicadas na mesma. Estas regras têm o formato SE - ENTÃO, permitindo-se o uso dos conectivos lógicos (E, OU, NÃO, e outros desejados). Como por exemplo: 1. SE cliente tem cadastro em outras locadoras = sim 2. OU reside no mesmo endereço a mais de 5 anos = sim 3. E situação = adimplente 4. ENTÃO crédito = liberado sem perdas [90%] O SE é o corpo da regra, também conhecido como parte antecedente ou lado esquerdo, avaliado em relação à base de conhecimento como um todo. Existindo o ajuste, é feito uma busca no mecanismo de avaliação pela ação correspondente especificada no lado direito, ou a parte consequente, é executada. As condições na parte antecedente da regra devem ser satisfeitas para que a ação, na parte consequente, seja considerada. Se qualquer premissa falhar, o lado direito também falha (DIEHL, 2000; NOGUEIRA e SILVA, 1997). As regras de produção possuem algumas vantagens, segundo LIA (1999), como: Modularidade: cada regra pode ser considerada como uma peça de conhecimento independente; Facilidade de edição: novas regras podem ser incluídas e regras antigas podem modificadas com relativa independência; Transparência do sistema: garante maior legibilidade das bases de conhecimentos. Resumindo, uma regra é um par ordenado de símbolos que representa algum conhecimento sobre um determinado assunto (DIEHL, 2000). Uma das grandes vantagens da

45 30 utilização de regras é a facilidade na demonstração de como se chega à solução através do rastreamento das regras pela máquina de inferência (NOGUEIRA e SILVA, 1997). Quando se estiver criando bases de conhecimento com o Expert SINTA devem ser levados em consideração alguns critérios na estrutura das premissas e conclusão das regras, conforme descrito por Diehl (2000): O modelo para cada premissa deve seguir a seguinte estrutura: <CONECTIVO> <ATRIBUTO> <OPERADOR> <VALOR> Conectivo: São os elementos (E, NÃO, OU) utilizados para unir a sentença ao conjunto de premissas que formam a seção de antecedentes de uma regra; Atributo: É uma variável capaz de assumir um ou uma lista de valores no decorrer da consulta à base de conhecimento; Operador: São as ligações entre o atributo e o valor da premissa, definindo o tipo de comparação a ser realizada. Os operadores podem ser: =, >, <=, >=, <>, entre outros; Valor: é um item de uma lista, a qual foi previamente criada e relacionada a um atributo. Já a estrutura da conclusão deve seguir o seguinte modelo, conforme Nogueira e Silva (1997): <ATRIBUTO> = <VALOR> <GRAU DE CONFIANÇA> Atributo: Mesmo atributo utilizado nas premissas; = : é um operador de atribuição. O atributo receberá o valor que lhe está sendo atribuído; Valor: Mesmo valor utilizado nas premissas; Grau de confiança: Percentual indicando a confiabilidade da conclusão da regra com base nas premissas. Varia de 0% à 100%.

46 Cálculo Probabilístico dos Sistemas Especialistas Para se efetuar o tratamento do raciocínio, evidência e aquisição automática de conhecimento, um sistema especialista necessita de um mecanismo para se tratar destes problemas. Nogueira e Silva (1997) exaltam o Expert SINTA como a ferramenta ideal para este tipo de situação, pois segundo os mesmos, o Expert Sinta utiliza a teoria das probabilidades em conjunto com a teoria das possibilidades na resolução dos problemas de forma automática e transparente ao usuário. Examinando uma das cabeças da regra mostrada como exemplo na seção anterior, verifica-se a presença de um grau de confiança na decisão de que a liberação do crédito pode ser efetuada. Contudo um ponto critico está no grau de confiabilidade da regra imposto pela da base de conhecimento estar apenas em 90%, sem levar em consideração a confiabilidade das demais premissas, levantando assim a dificuldade de se representar a confiabilidade das seguintes informações, segundo Lia (1999): Os especialistas humanos não utilizam estimativas definidas matematicamente; Os resultados gerados através de cálculos matemáticos de probabilidade nem sempre são a melhor resposta para aquela aplicação prática. O Expert SINTA modela os tratamentos probabilísticos utilizando quatro casos como base onde o cálculo varia de acordo com o objetivo que se deseja podendo ser para se descobrir o valor final atribuído a uma regra, calcular o grau de confiança quando se tem o operador E embutido na regra ou calcular o grau de confiança quando se tem o operador OU na regra. Para melhor exemplificar os casos disponíveis no Expert SINTA, será mostrado o cálculo utilizando as regras retiradas da base do Sistema Especialista de Requisitos, SISREQUI.

47 32 Caso 1: Quando queremos saber o valor final atribuído às variáveis na conclusão de um regra (LIA, 1999). O grau de confiança de uma regra R, será o número atribuído a C1 ao final da premissa de R, onde na conclusão de R, temos expressões como Var = value CNF C2. Onde: Var é uma variável; value é um termo qualquer que pode ser substituído pela variável; C2 é um número real no intervalo de 0 a 100, que representa o grau de confiança da atribuição; O resultado final e dependente da premissa, pois C2 é apenas uma referência. Assim a operação a ser realizada é Var = value CNF C1*C2. Como por exemplo: Figura 6 Exemplo de tratamento probabilístico do caso 1. Então, na execução da regra mostrada na figura 6, o usuário digitando o grau de confiança da premissa Problemas no desenvolvimento do sistema = sim com 80%, tem-se que o atributo Para esta situação o mais indicado é receberá o valore Verificar se o documento de Requisitos está claro, com o respectivo grau de confiança da regra de 60%. O valor final da regra atribuída pelos valores fornecidos e obtido pelo cálculo = 0.80 * 0.60 = 0.48 = 48%.

48 33 Caso 2: Cálculo do grau de confiança com o conectivo E (LIA, 1999). A regra possuindo duas igualdades var1 = value1 e var2 = value2, com os respectivos graus de confiança c1 e c2, temos a sentença var1 = value1 E var2 = value2, ficando como valor de confiança o resultado a multiplicação de C1 por C2. Como por exemplo: Figura 7 - Exemplo de tratamento probabilístico do caso 2. Ao executar a regra da figura 7, digamos que o grau de confiança para Projeto Complexo = Sim é 60% e o grau de confiança pra Problemas no desenvolvimento do sistema = sim é 90%. Chega-se ao valor de 56%, obtido pelo seguinte cálculo 0.60*0.90 = Com o valor do cálculo entre as premissas, agora se multiplica pelo grau de confiança da regra de 80%, ficando o valor final da regra em 43,2%. Caso 3: Cálculo do grau de confiança com o conectivo OU (LIA, 1999). Possuindo duas igualdades var1 = value1 e var2 = value2, com seus respectivos graus de confiança c1 e c2, obtêm-se a sentença var1 = value1 OU var2 = value2. O valor de confiança é obtido com o seguinte cálculo c1 + c2 (c1* c2). Como por exemplo:

49 34 Figura 8 - Exemplo de tratamento probabilístico do caso 3. Na execução da regra exemplificada na figura 8, digamos que o valor para o grau de confiança da igualdade Projeto Complexo = sim é 80% e o grau de confiança da igualdade Requisitos Claros = sim é 90%, então obtêm-se um valor de 98%, através do seguinte cálculo (( ) (0.80 * 0.90)) = ( ) = Como valor das premissas, o passo seguinte e multiplica-lo com o grau de confiança da regra de 70%, obtendo o valor final da regra de 68,6%. Caso 4: Cálculo do grau de confiança com o conectivo NÃO (MATOS, 2011). Negando uma ou mais igualdades var = value, com seus respectivos graus de confiança c, obtêm-se a sentença NÃO var = value. O valor de confiança é obtido com o seguinte cálculo: (1 c). Como por exemplo: Figura 9 - Exemplo de tratamento probabilístico do caso 4.

50 35 A regra mostrada na figura 9 possui o grau de confiança de 90% fornecido pelo usuário para o atributo Cliente tem certeza sobre os Requisitos = Sim, mas como a premissa foi negada inicialmente com o operador NÃO, o valor real da premissa será 10%, de acordo com o cálculo Com o resultado da premissa, aplicasse a regra do caso 2, pois na premissa seguinte possui o conectivo E. O valor do atributo Envolvidos no projeto com total entendimento e de 60%. Ao final do calculo entre as premissas, 0.10 * 0.60, chegasse ao valor de 6%. Já o valor final da regra será o valor o grau de confiança das premissas 6% multiplicado pelo grau de confiança da regra de 40%. Chegando ao valor final de 24%. A partir dos casos base de modelagem de tratamento probabilístico, mostrados, podem-se criar vários outros casos simplesmente acrescentando conectivos diferentes em uma mesma regra, lembrando que a ordem de prioridade dos conectivos é: NÃO primeiro, seguido do E, e após o OU. Vale lembrar também que toda regra possui um objetivo final, mas com o Expert SINTA é possível ter mais de um objetivo na mesma regra. A ferramenta efetua o cálculo do grau de confiança das premissas e, ao final, multiplica o valor encontrado por cada um dos objetivos da regra. Como por exemplo, na regra abaixo retirada da base de conhecimento do SISREQUI. Figura 10 - Exemplo de regra com mais de um objetivo. Conforme mostrado na figura 10, a regra 50 possui três objetivos onde cada um possui seu respectivo grau de confiança. Para exemplificar melhor daremos para cada atributo os

51 36 seguintes valores na mesma ordem dos atributos: 80 %, 90%, 50 % e 70%. Para o cálculo das premissas, como em todas possui apenas o conectivo E, se aplica apenas a regra do caso 2, obtendo em seguida o valor de 25,2 %. Em seguida, o Expert SINTA irá multiplicar o valor de 25,2 % por cada um dos objetivos da regra, chegando ao seguintes valores: Para esta situação o mais adequado Negociar mais tempo com o cliente. 17,64%, referente ao cálculo de 25,2% * 70%; Validar com o cliente o requisito coletado. 17, 64 %, referente ao cálculo de 25,2% * 70%; Técnica de Elicitação de Requisitos mais adequada Etnografia. 22,68%, referente ao cálculo de 25,2% * 90%.

52 37 4. SISTEMA ESPECIALISTA PARA AUXÍLIO NO PROCESSO DA ENGENHARIA DE REQUISITOS O objetivo deste capítulo e mostrar o processo de criação do sistema especialista para a disciplina de requisitos, discutindo as etapas básicas na elaboração do sistema especialista, a implementação do sistema e as consultas do mesmo. O capítulo está organizado da seguinte maneira: A seção 4.1 aborda sobre o projeto do SISREQUI, com o estudo de viabilidade e a formalização do conhecimento. A seção 4.2 aborda sobre a implementação do SISREQUI e a seção 4.3 aborda os resultados alcançados com o SISREQUI. 4.1 Projeto SISREQUI Os Sistemas que são da área científica não possuem uma usabilidade e interface amigável com o usuário. Nos dias atuais as ferramentas que possibilitam uma fácil interação entre homem e máquina, ajudam no aumento da produtividade e no rápido desenvolvimento no processo de criação de um software. Boa parte das ferramentas hoje disponíveis para a criação de sistemas especialistas, não possibilitam que ocorra uma maior comunicação entre o responsável pela criação do sistema especialista. A ferramenta que irá auxiliar na criação de um sistema especialista deve ter uma fácil utilização, possuindo uma interface autoexplicativa, permitindo que qualquer pessoa familiarizada com um computador possa criar o conhecimento especializado de acordo com a linguagem de representação do conhecimento disponível (BITTENCOURT, 2006). Com o Expert SINTA é possível criar rapidamente todas as variáveis e seus possíveis valores, como também os objetivos do sistema para, em seguida, iniciar a criação das regras de produção, conforme verificado na figura 11.

53 38 Figura 11 Ambiente do Expert SINTA. Fonte: Lia, Assim como o Expert SINTA, existem outras ferramentas que ajudaram segundo Bittencourt (2006), na disseminação dos sistemas especialistas, denominadas Arcabouços de Sistemas Especialistas, ASE. Os ASE s dividem os SE s entre a ferramenta de criação do conhecimento que define as regras e aspectos operacionais, do conhecimento de domínio Estudo de viabilidades Criar um sistema especialista para auxiliar em processos complexos como o da disciplina de Engenharia de Requisitos não pode ser resolvido facilmente. Por isso serão utilizados como base na criação do sistema as metodologias utilizadas por autores que tem um embasamento muito mais profundo sobre sistemas especialistas, tais como Nogueira e Silva (1997), LIA (1999) e Bittencourt (2006). As metodologias utilizadas pelos autores consistem em saber se o sistema especialista é a resposta na resolução de um problema. Nogueira e Silva (1997) afirmam que se torna necessário na definição da resposta, os seguintes parâmetros:

54 39 A tarefa não necessita de senso comum? Já que computadores têm uma enorme dificuldade em lidar com senso comum. Mas sistemas especialistas são quase que totalmente desprovidos de bom senso, então não sofrem grandes prejuízos ao tratarem do assunto (NOGUEIRA E SILVA, 1997); Existem modos de formalização para o conhecimento desejado? O sistema deve ser validado por diversos especialistas no assunto (NOGUEIRA E SILVA, 1997); Existem especialistas disponíveis que possam colaborar com o desenvolvimento do sistema? Presença ativa de profissionais com alto grau de conhecimento do problema em estudo é vital para obtenção de resultados funcionais (NOGUEIRA E SILVA, 1997); A aplicação é relevante? O sistema só valerá a pena se o mesmo não for para resolução de tarefas triviais ou de pouca importância (NOGUEIRA E SILVA, 1997). Também deve ser levado em consideração o público alvo, afinal de contas o sistema tem como missão validar uma informação da mesma forma que um especialista humano, treinar novos analistas com as melhores respostas dos principais problemas já vivenciados por outros especialistas. Para se chegar a estes objetivos se torna necessária uma boa formalização do conhecimento, conforme descrito a seguir Formalização do Especialista em Engenharia de Requisitos O grande problema na criação de um sistema especialista está na dificuldade de se conseguir elaborar corretamente o conhecimento dos especialistas. Nogueira e Silva (1997) indicam uma boa entrevista com os especialistas da área em que esteja querendo coletar as informações, pois segundo os mesmos é difícil se criar regras com base nas conclusões feitas pelos Especialistas, quando os mesmos lidam com novas situações, onde se torna necessário, uma boa experiência ou até mesmo na dificuldade de comunicação quando se utiliza muitos termos técnicos.

55 40 Por causa dos problemas descritos acima, foram utilizados na formalização do conhecimento para a base do SISREQUI, dois métodos para extração do conhecimento dos especialistas em requisitos. Os métodos são os seguintes: O Método da Observação, onde o desenvolvedor do sistema especialista deve assistir ao dia a dia de trabalho de um especialista na resolução dos problemas (NOGUEIRA E SILVA, 1997); Método Intuitivo, onde é feito um estudo e interação tanto com o especialista em requisitos quanto com a literatura básica sobre o assunto (NOGUEIRA E SILVA, 1997). Além dos métodos de observação e intuitivo descritos acima, também foi elaborado um questionário com alguns problemas típicos do dia a dia de um analista de sistema, e enviados a alguns Analistas para que os mesmos dessem suas contribuições. A formalização do conhecimento utilizado na criação da base de conhecimento do SISREQUI é descrita com maiores detalhes na seção Aquisição de conhecimento O SISREQUI é um sistema especialista voltado a suporte na resolução de problemas relacionados a conceitos da engenharia de requisitos. Seu principal objetivo e o de auxiliar a analista de requisitos, analistas de sistemas e analistas de negócio na correta aplicabilidade dos conceitos da engenharia de requisitos, podendo também ser utilizado como treinamento a novos membros de uma equipe responsável pela coleta de requisitos. A modelagem do conhecimento requer uma série de refinamento (NOGUEIRA E SILVA, 1997) aumentando a imparcialidade das respostas do sistema. O refinamento do conhecimento, obtido com as técnicas descritas na seção 4.1.2, sobre requisitos utilizados na versão inicial do SISREQUI feito da seguinte maneira: Método da Observação

56 41 Foi observado durante um período de 5 meses a rotina de trabalho de especialistas em requisitos nas empresas de desenvolvedoras de software, analisando e documentando o trabalho dos especialistas. Método Intuitivo A partir do levantamento bibliográfico sobre a disciplina de requisitos de software foi feito um documento com as melhores práticas sobre o assunto descrito pelos autores. O Documento possuía algumas frases, que se tornaram as variáveis da SISREQUI, que abordavam diversos temas relacionados a disicplina. Questionário As perguntas contidas no questionário eram voltadas as melhores práticas no processo de requisitos, abordando sobre as técnicas de elicitação, validação e gerenciamento. O questionário serviu como base para a criação do grau de confiança atribuído aos objetivos das regras. 4.2 Implementação do SISREQUI Em LIA (1999), é descrito a praticidade e facilidade que o Expert SINTA, proporciona ao desenvolvedor do sistema especialista na implementação da base de conhecimento desejada. Uma base de conhecimento no Expert SINTA envolve os seguintes conjuntos de atributos que devem ser criados na base: Variáveis são os atributos que serão utilizados nas regras; Regras são formadas por um conjunto de premissas com um grau de confiança; Perguntas são variáveis que irão aparecer ao usuário como forma de perguntas; Objetivos são variáveis que irão estar na conclusão das regras; Informações adicionais, local onde são colocados as informações de apresentação do sistema especialista, nome do sistema e nome dos autores.

57 42 especialista. Só quando esses elementos estiverem definidos, se torna possível utilizar o sistema Implementando o sistema Com a base de conhecimento já levantada, deve-se abrir o Expert SINTA e criar uma nova base de conhecimento, através do Menu Arquivo Nova base. Conforme figura 12. Figura 12 Criando uma nova Base de Conhecimento no Expert SINTA. O Expert SINTA, inicialmente irá abrir uma nova janela, denominada Knowledge-ina-box, KIB (LIA, 1999). Com a KIB aberta, é possível elaborar todos os elementos necessários para o Sistema Especialista. Conforme figura 13.

58 43 Figura 13 Janela KIB. Fonte: Lia, 1999, Modificado Base de conhecimento Na criação da base de conhecimento do SISREQUI, é necessária primeiramente a criação das variáveis que serão utilizadas no sistema. Dessas variáveis devem ser separadas as que irão se tornar objetivos e as que serão as perguntas, para finalmente dar início a criação das regras de produção que serão utilizadas no sistema. Todo o processo de criação das variáveis, separação das variáveis objetivos das variáveis perguntas e criação das regras será explicado na seção seguinte Variáveis A criação de variáveis do SISREQUI pelo Expert SINTA é bastante simples. Após ter definido quais serão os problemas ou situações mais vivenciadas por especialistas em requisitos de software, basta a partir da janela KIB, selecionar o botão Variáveis. Logo em seguida irá ser carregada a janela de criação e edição de variáveis conforme figura 14.

59 44 Figura 14 Janela de criação de variáveis. Fonte: Lia, 1999, Modificado. Onde: 1: Referisse a campo onde serão exibidas as variáveis que o sistema terá; 2: Será exibido o valor referente a uma determinada variável; 3: Campo de descrição com o nome da variável; 4: Campo com o valor que a variável terá; 5: O botão com formato de V, serve para confirmar a inclusão ou alteração da variável. Enquanto o no formato de X cancela a alteração ou inclusão; 6: Tipos das variáveis, onde: Numérica: Não podem ter valores pré-definidos. Será exibido o intervalo de números reais no formato a;b. Onde a deve ser menor ou igual a b ; Multivalorada: São variáveis que podem assumir vários valores, onde estes valores são exibidos em forma de listagem ao lado do nome da variável; Univalorada: Variáveis lógicas que só podem receber um valor por vez, 0-Sim, 1-Não. Por padrão o Expert SINTA cria as variáveis como univaloradas; 7: Botões de criação e exclusão de variáveis e seus valores.

60 45 LIA (1999), aconselha a nunca mudar o tipo de uma variável não numérica para numérica, pois pode implicar em perda de valores ou mesmo excluir alguma variável ou seu valor, pois esta exclusão irá invalidar qualquer regra que esteja com aquela variável. Após definir todas as variáveis, seus tipos e valores, o próximo passo na criação do SISREQUI é separar das variáveis criadas, quais serão os objetivos nas regras Objetivos O objetivo em uma regra, é a resposta que um especialista daria como solução a determinado problema (LIA, 1999). A diferença é que no Expert SINTA os problemas são representados por variáveis que por sua vez se tornam variáveis objetivos. O SISREQUI, assim como qualquer sistema especialista, antes de sua execução necessita que sejam definidas quais são as suas variáveis objetivos, pois sem esta definição, seria o mesmo que perguntar alguma coisa a um especialista e o mesmo não a responder (LIA, 1999). A determinação dos objetivos é feita a partir da janela KIB, selecionado a opção Objetivos. Em seguida aparecerá uma janela com uma lista contendo as variáveis comuns e outra com as variáveis objetivos, conforme mostrado na figura 15. Figura 15 Janela de seleção de variáveis objetivos do SISREQUI. Fonte: Lia, 1999, Modificado.

61 46 Ao definir as variáveis objetivos, o próximo passo é a criação da interface com o usuário. A interface é a forma como as variáveis irão ser exibidas aos usuários do sistema, e como serão feitas as perguntas aos usuários Interface com o usuário O SISREQUI se comunica com o usuário final através de menus de múltipla escolha. Os menus são construídos automaticamente pelo Expert SINTA, restando apenas ao criador do sistema especialista definir as variáveis perguntas e para cada variável pergunta criar uma questão e um motivo de ajuda, que irá auxiliar o usuário quando o mesmo não souber sobre do que se trata a pergunta (LIA, 1999). Na janela de seleção e criação de perguntas do Expert SINTA, figura 16 aparece as variáveis criadas em um lado e as variáveis perguntas do outro. O Expert SINTA não proíbe que uma variável definida como objetivo se torne uma variável pergunta, ele não permite e que esta mesma variável seja referenciada em uma regra como variável pergunta e objetivo. Figura 16 Janela de seleção de variáveis perguntas do SISREQUI. Fonte: Lia, 1999, Modificado. Com a seleção das variáveis, a criação das perguntas e definição dos motivos para o SISREQUI, o próximo passo e o mais complexo é a criação das regras de produção com seus respectivos graus de confiança.

62 Regras A modelagem do conhecimento no Expert SINTA é feita através das regras de produção. Na janela KIB, aparecem todas as regras que o sistema tem. A criação de regras é iniciada a partir da seleção da opção Nova Regra na janela KIB (LIA, 1999), surgindo em seguida uma tela informando a ordem da regra, que se refere ao número da regra, e o modelo, referente à criação de uma nova regra com as mesmas informações de uma já criada, conforme figura 17. Figura 17 Caixa de seleção de Ordem e modelo de regra. Fonte: Lia, A tela seguinte, caso não seja selecionado nenhum modelo de regra, virá apenas com a estrutura SE, ENTÃO, conforme figura 18. Figura 18 Tela de criação de regra de produção. Fonte: Lia, 1999.

63 48 A partir dela, se torna possível a criação da regra que irá compor o sistema. Lembrando que a criação da regra, deve possuir a mesma estrutura abordada na seção de regras de produção do capítulo anterior. No Expert SINTA, as variáveis criadas e definidas como perguntas, serão os atributos das regras. E são inseridas no bloco correspondente à silaba SE. As variáveis Objetivos devem ser inseridas no bloco correspondente à silaba ENTÃO. Para incluir uma variável, primeiramente deve-se selecionar a opção Incluir. Após a escolha, será exibida uma caixa de seleção com o item de regra, onde o mesmo é uma lista contendo todas as variáveis criadas, o operador e o valor que irá receber aquela variável. Após ser inserida a primeira premissa da regra, o Expert SINTA permite que sejam inseridos os conectivos E e OU ; o NÃO já é liberado para ser utilizado na primeira premissa. Figura 19 Tela de inserção de premissas. Fonte: Lia, Inseridas todas as premissas do bloco SE, o próximo passo é inserir o objetivo da regra, bloco ENTÃO. A caixa de seleção do bloco é um pouco parecida com a anterior, só que nesta tela é selecionado apenas o objetivo da regra, o seu respectivo valor e seu graus de confiança, conforme figura 20. Figura 20 Tela de inserção de objetivos. Fonte: Lia, Se por ventura se chegar a errar na criação de alguma regra, seleciona-se a premissa e clica na opção alterar. Após a criação das regras, o SISREQUI já esta com sua base de conhecimento completa, restando apenas consulta-la e verificar os resultados alcançados.

64 Informações adicionais Antes de executar o SISREQUI, se torna necessário criar uma tela de abertura para o sistema. A criação da tela foi através da opção Informações da janela KIB. A opção abriu uma tela onde foi possível inserir o nome do Sistema, assim como os autores e uma breve descrição sobre o SISREQUI, conforme figura 21. Figura 21 Janela de informações adicionais do SISREQUI. Fonte: Lia, 1999, Modificado. LIA (1999), comenta que também é possível a criação de arquivos de ajuda online, definir preferências na execução dos conectivos, formulas matemáticas e proteção por senha para o sistema especialista. Em uma versão futura do SISREQUI, poderá ser agregada algumas destas funcionalidades presentes no Expert SINTA. 4.3 Consultando o SISREQUI Antes de mostrar as consultas, primeiramente serão mostrados alguns comandos básicos do Expert SINTA, ou, conforme Lia (1999), um conjunto de operações básicas.

65 50 Existem dois menus de acompanhamento de consultas no Expert SINTA (LIA, 1999), mas este trabalho se focou em explicar o menu já presente na barra de ferramentas do Expert SINTA, conforme mostrado na figura 22. Figura 22 Menu de controle de consultas. Fonte: Lia, Consultas Iniciando a consulta, a primeira tela que irá aparecer será a tela de abertura do sistema. A tela mostra uma pequena descrição sobre o SISREQUI, figura 23. Figura 23 Tela de abertura do SISREQUI.

66 51 Após a tela de abertura irão aparecer as perguntas criadas. A base de conhecimento do SISREQUI possui 50 regras e foi elaborada com variáveis univaloradas, então as perguntas irão aceitar apenas uma opção a ser selecionada, que conforme seja selecionada permite ao sistema solicitar qual o grau de confiança naquela resposta, conforme mostrado nas figuras 24 e 25. Figura 24 Interface SISREQUI. Figura 25 Resposta do SISREQUI com respectivo grau de confiança. Contudo, caso o analista que esteja utilizando o SISREQUI, não saiba o que a pergunta significa, basta consultar a ajuda selecionando a opção Por que?. O SISREQUI irá mostrar ao analista o porque de estar fazendo aquela pergunta, conforme figura 26.

67 52 Figura 26 Tela de ajuda do SISREQUI. Mas se mesmo com a tela de ajuda o Analista não souber como responder a pergunta, simplesmente poder passar a pergunta só escolhendo a opção OK. Independente da escolha, o SISREQUI irá auxiliar o Analista na melhor maneira Acompanhamento O acompanhamento das consultas do SISREQUI pode ser feito através do depurador. O depurador exibe uma caixa de listagem com todas as regras que formam a base de conhecimento do sistema (LIA, 1999), destacando a premissa que está sendo analisada pela maquina de inferência naquele momento, conforme mostrado na figura 27.

68 53 Figura 27 Execução do SISREQUI pelo modo depurador. Para utilizar o modo depurador o analista deve executar o SISREQUI apertando a tecla F8, e para cada resposta efetuada, continuar apertando a tecla. Assim e possível ver como o SISREQUI funciona na escolha das regras Janela de Resultados Atingidos Ao final de uma busca de objetivos, o SISREQUI apresenta uma janela de resultados. LIA (1999), comenta que esta janela se divide em quatro partes: A de resultados, onde são apresentados todos os objetivos atingidos, com seus respectivos graus de confiança, conforme mostrado na figura 28; Histórico: onde é exibido todo o caminho realizado pelo sistema especialista até atingir a solução, conforme mostrado na figura 29; Todos os valores: que é uma generalização da primeira página, pois exibe todos os valores de todas as variáveis do SISREQUI, conforme figura 30;

69 54 O sistema: onde exibe todas as regras contidas no SISREQUI, mostrado na figura 31. Figura 28 Tela de Resultados. Figura 29 Arvore de pesquisa.

70 55 Figura 30 Todos os resultados. Figura 31 Regras do SISREQUI.

71 56 O SISREQUI possui em sua versão atual, quatro objetivos onde os tópicos abordados em cada um deles e o seguinte: Para esta situação o mais adequado é, trata as melhores práticas sobre requisitos de software definidas por autores consagrados como Sommeville (2008) e Pressman (2005); Técnica de Elicitação Requisitos mais adequada, aborda sobre as melhores técnicas de elicitação de requisitos de acordo com levantamento feito por especialistas na área e autores consagrados como Sommeville (2008) e Pressman (2005); Validação de Requisitos mais adequada, trata sobre as melhores técnicas de validação de requisitos de acordo com levantamento feito por especialistas na área e autores consagrados como Sommeville (2008) e Pressman (2005); Técnica de Gerenciamento de requisitos mais adequada, aborda sobre as melhores técnicas de gerenciamento de requisitos de acordo com levantamento feito por especialistas na área e autores consagrados como Sommeville (2008) e Pressman (2005). A disciplina de requisitos por ser muito complexa e lidar muito com o senso comum, se torna necessário garantir a relevância da base do SISREQUI Garantindo a relevância do SISREQUI A garantia da funcionalidade na versão atual do SISREQUI tem o intuito de verificar se os objetivos sugeridos pelo sistema realmente ajudaram os analistas em suas rotinas de trabalho. Para efetuar os testes, foram aplicados a partir de projetos complexos já concluídos ou em processos de conclusão. O primeiro teste, figura 32, efetuado com o sistema foi em relação a um projeto já concluído. O intuito foi verificar se os objetivos que SISREQUI chegou, atingiram qual o porcentagem em relação à solução adotada pelos analistas para se chegar à conclusão do sistema. No momento do teste foram levadas em consideração as situações que ocorreram na

72 57 época que o projeto estava sendo elicitado e desenvolvido. O segundo teste, figura 33, foi aplicado em um projeto ainda em desenvolvimento. O intuito do teste foi verificar se os objetivos atingidos pelo SISREQUI satisfazem as necessidades nos analistas no projeto. Figura 32 Gráfico de teste do SISREQUI em projetos concluídos. Figura 33 Gráfico de teste do SISREQUI em projetos não concluídos.

ENGENHARIA DE SOFTWARE I

ENGENHARIA DE SOFTWARE I ENGENHARIA DE SOFTWARE I Prof. Cássio Huggentobler de Costa [cassio.costa@ulbra.br] Twitter: www.twitter.com/cassiocosta_ Agenda da Aula (002) Metodologias de Desenvolvimento de Softwares Métodos Ágeis

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Requisitos Cap. 06 e 07 Sommerville 8 ed. REQUISITOS DE SOFTWARE» Requisitos são descrições de serviços fornecidos pelo sistema e suas restrições operacionais. REQUISITOS DE USUÁRIOS: São

Leia mais

Projeto de Sistemas I

Projeto de Sistemas I Instituto Federal de Educação, Ciência e Tecnologia de São Paulo Projeto de Sistemas I Professora: Kelly de Paula Cunha E-mail:kellypcsoares@ifsp.edu.br Requisitos: base para todo projeto, definindo o

Leia mais

Requisitos de Software. Teresa Maciel DEINFO/UFRPE

Requisitos de Software. Teresa Maciel DEINFO/UFRPE Requisitos de Software Teresa Maciel DEINFO/UFRPE 1 Requisito de Software Características que o produto de software deverá apresentar para atender às necessidades e expectativas do cliente. 2 Requisito

Leia mais

Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software

Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO RIO GRANDE DO NORTE Curso Técnico em Informática ENGENHARIA DE SOFTWARE Prof.: Clayton Maciel Costa clayton.maciel@ifrn.edu.br Clayton Maciel Costa

Leia mais

Requisitos de Software

Requisitos de Software Requisitos de Software Centro de Informática - Universidade Federal de Pernambuco Kiev Gama kiev@cin.ufpe.br Slides originais elaborados por Ian Sommerville e adaptado pelos professores Márcio Cornélio,

Leia mais

UNIDADE 4. Introdução à Metodologia de Desenvolvimento de Sistemas

UNIDADE 4. Introdução à Metodologia de Desenvolvimento de Sistemas UNIDADE 4. Introdução à Metodologia de Desenvolvimento de Sistemas 4.1 Motivação Sistemas de Informação são usados em diversos níveis dentro de uma organização, apoiando a tomada de decisão; Precisam estar

Leia mais

Tópicos em Engenharia de Software (Optativa III) AULA 2. Prof. Andrêza Leite andreza.lba@gmail.com (81 )9801-6619

Tópicos em Engenharia de Software (Optativa III) AULA 2. Prof. Andrêza Leite andreza.lba@gmail.com (81 )9801-6619 Tópicos em Engenharia de Software (Optativa III) AULA 2 Prof. Andrêza Leite andreza.lba@gmail.com (81 )9801-6619 Engenharia de Software Objetivo da aula Depois desta aula você terá uma revisão sobre o

Leia mais

AUTOR: DAVID DE MIRANDA RODRIGUES CONTATO: davidmr@ifce.edu.br CURSO FIC DE PROGRAMADOR WEB VERSÃO: 1.0

AUTOR: DAVID DE MIRANDA RODRIGUES CONTATO: davidmr@ifce.edu.br CURSO FIC DE PROGRAMADOR WEB VERSÃO: 1.0 AUTOR: DAVID DE MIRANDA RODRIGUES CONTATO: davidmr@ifce.edu.br CURSO FIC DE PROGRAMADOR WEB VERSÃO: 1.0 SUMÁRIO 1 Conceitos Básicos... 3 1.1 O que é Software?... 3 1.2 Situações Críticas no desenvolvimento

Leia mais

ARCO - Associação Recreativa dos Correios. Sistema para Gerenciamento de Associações Recreativas Plano de Desenvolvimento de Software Versão <1.

ARCO - Associação Recreativa dos Correios. Sistema para Gerenciamento de Associações Recreativas Plano de Desenvolvimento de Software Versão <1. ARCO - Associação Recreativa dos Correios Sistema para Gerenciamento de Associações Recreativas Versão Histórico da Revisão Data Versão Descrição Autor Página

Leia mais

Engenharia de Requisitos Estudo de Caso

Engenharia de Requisitos Estudo de Caso Engenharia de Requisitos Estudo de Caso Auxiliadora Freire Fonte: Engenharia de Software 8º Edição / Ian Sommerville 2007 Slide 1 Engenharia de Requisitos Exemplo 1 Reserva de Hotel 1. INTRODUÇÃO Este

Leia mais

Requisitos. Sistemas de Informações

Requisitos. Sistemas de Informações Requisitos Sistemas de Informações Definindo o Sucesso do Software Clientes satisfeitos Eles estão satisfeitos quando você: Atende às expectativas Entrega no prazo Entrega no orçamento O Sucesso começa

Leia mais

Tópicos da Aula. Que é são requisitos? Tipos de Requisitos. Requisitos Funcionais. Classificação de Requisitos. Requisitos de Software.

Tópicos da Aula. Que é são requisitos? Tipos de Requisitos. Requisitos Funcionais. Classificação de Requisitos. Requisitos de Software. Engenharia de Software Aula 06 Tópicos da Aula Software Eduardo Figueiredo http://www.dcc.ufmg.br/~figueiredo dcc603@gmail.com 26 Março 2012 Funcionais e não funcionais De usuário e do Engenharia de Estudo

Leia mais

Engenharia de Software

Engenharia de Software Universidade São Judas Tadeu Profª Dra. Ana Paula Gonçalves Serra Engenharia de O Processo Uma Visão Genérica Capítulo 2 (até item 2.2. inclusive) Engenharia de - Roger Pressman 6ª edição McGrawHill Capítulo

Leia mais

Na medida em que se cria um produto, o sistema de software, que será usado e mantido, nos aproximamos da engenharia.

Na medida em que se cria um produto, o sistema de software, que será usado e mantido, nos aproximamos da engenharia. 1 Introdução aos Sistemas de Informação 2002 Aula 4 - Desenvolvimento de software e seus paradigmas Paradigmas de Desenvolvimento de Software Pode-se considerar 3 tipos de paradigmas que norteiam a atividade

Leia mais

Roteiro para a escrita do documento de Especificação de Requisitos de Software (ERS)

Roteiro para a escrita do documento de Especificação de Requisitos de Software (ERS) Roteiro para a escrita do documento de Especificação de Requisitos de Software (ERS) Definição Geral: Disciplina de Compiladores Prof. Jorge Bidarra (UNIOESTE) A especificação de requisitos tem como objetivo

Leia mais

O Processo Unificado: Captura de requisitos

O Processo Unificado: Captura de requisitos O Processo Unificado: Captura de requisitos Itana Gimenes Graduação em Informática 2008 Captura de Requisitos Modelagem do negócio: Visão de negócios Modelo de objetos de negócio de negócio Especificação

Leia mais

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software PROCESSO DE DESENVOLVIMENTO DE SOFTWARE Introdução Modelos de Processo de Desenvolvimento de Software Os modelos de processos de desenvolvimento de software surgiram pela necessidade de dar resposta às

Leia mais

Resumo do BABok 2.0 O Guia de Referência de Análise de Negócio Curso de Analista de Negócio 3.0

Resumo do BABok 2.0 O Guia de Referência de Análise de Negócio Curso de Analista de Negócio 3.0 O que é BABok? O BABok 2.0, Corpo de Conhecimento de Análise de Negócios, é considerado como um Guia Referência de Práticas de Análise de Negócio. Este guia é publicado e mantido pelo IIBA. O guia BABok

Leia mais

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 10 PROFª BRUNO CALEGARO

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 10 PROFª BRUNO CALEGARO UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 10 PROFª BRUNO CALEGARO Santa Maria, 10 de Outubro de 2013. Revisão aula anterior Documento de Requisitos Estrutura Padrões Template Descoberta

Leia mais

Pós-Graduação em Gerenciamento de Projetos práticas do PMI

Pós-Graduação em Gerenciamento de Projetos práticas do PMI Pós-Graduação em Gerenciamento de Projetos práticas do PMI Planejamento do Gerenciamento das Comunicações (10) e das Partes Interessadas (13) PLANEJAMENTO 2 PLANEJAMENTO Sem 1 Sem 2 Sem 3 Sem 4 Sem 5 ABRIL

Leia mais

O Rational Unified Process (RUP) é um processo de desenvolvimento de software inspirado no

O Rational Unified Process (RUP) é um processo de desenvolvimento de software inspirado no 1.1 RATIONAL UNIFIED PROCESS (RUP) O Rational Unified Process (RUP) é um processo de desenvolvimento de software inspirado no processo que atende pelo nome de Processo Unificado (ou UP do inglês Unified

Leia mais

PEN - Processo de Entendimento das Necessidades de Negócio Versão 1.4.0

PEN - Processo de Entendimento das Necessidades de Negócio Versão 1.4.0 PEN - Processo de Entendimento das Necessidades de Negócio Versão 1.4.0 Banco Central do Brasil, 2015 Página 1 de 14 Índice 1. FLUXO DO PEN - PROCESSO DE ENTENDIMENTO DAS NECESSIDADES DE NEGÓCIO... 3 2.

Leia mais

MASTER IN PROJECT MANAGEMENT

MASTER IN PROJECT MANAGEMENT MASTER IN PROJECT MANAGEMENT PROJETOS E COMUNICAÇÃO PROF. RICARDO SCHWACH MBA, PMP, COBIT, ITIL Atividade 1 Que modelos em gestão de projetos estão sendo adotados como referência nas organizações? Como

Leia mais

PLANEJAMENTO E PROJETOS. Lílian Simão Oliveira

PLANEJAMENTO E PROJETOS. Lílian Simão Oliveira PLANEJAMENTO E GERENCIAMENTO DE PROJETOS Lílian Simão Oliveira Contexto Gerentes lutam com projetos assustadores e com prazos finais difíceis de serem cumpridos Sistemas não satisfazem aos usuários Gastos

Leia mais

Engenharia de Requisitos

Engenharia de Requisitos Engenharia de Requisitos Introdução a Engenharia de Requisitos Professor: Ricardo Argenton Ramos Aula 08 Slide 1 Objetivos Introduzir a noção de requisitos do sistema e o processo da engenharia de requisitos.

Leia mais

Engenharia de Requisitos

Engenharia de Requisitos Engenharia de Requisitos Conteúdo Definição Questionamentos Típicos Visão Geral Ciclo de Vida dos Requisitos Síntese dos Objetivos Gerência de Mudança Identificação de Requisitos Classificação de Requisitos

Leia mais

Engenharia de Software II

Engenharia de Software II Engenharia de Software II Aula 5 http://www.ic.uff.br/~bianca/engsoft2/ Aula 5-05/05/2006 1 Dúvidas da aula passada RUP (Rational Unified Process) é uma ferramenta ou um processo? Resposta: os dois. O

Leia mais

Engenharia de Software e Gerência de Projetos Prof. Esp. André Luís Belini Bacharel em Sistemas de Informações MBA em Gestão Estratégica de Negócios

Engenharia de Software e Gerência de Projetos Prof. Esp. André Luís Belini Bacharel em Sistemas de Informações MBA em Gestão Estratégica de Negócios Engenharia de Software e Gerência de Projetos Prof. Esp. André Luís Belini Bacharel em Sistemas de Informações MBA em Gestão Estratégica de Negócios Cronograma das Aulas. Hoje você está na aula Semana

Leia mais

UML - Unified Modeling Language

UML - Unified Modeling Language UML - Unified Modeling Language Casos de Uso Marcio E. F. Maia Disciplina: Engenharia de Software Professora: Rossana M. C. Andrade Curso: Ciências da Computação Universidade Federal do Ceará 24 de abril

Leia mais

Requisitos de Software

Requisitos de Software Requisitos de Software Prof. José Honorato F.N. Prof. José Honorato F.N. honoratonunes@gmail.com Requisitos de Software Software é o conjunto dos programas e dos meios não materiais que possibilitam o

Leia mais

LEVANTAMENTO DE REQUISITOS DE FORMA ENXUTA

LEVANTAMENTO DE REQUISITOS DE FORMA ENXUTA LEVANTAMENTO DE REQUISITOS DE FORMA ENXUTA Kleber Lopes Petry Éder Moretto Garcia Rodrigo Clemente Thom de Souza Proposta de processo para levantamento de requisitos para desenvolvimento de produtos de

Leia mais

2 Diagrama de Caso de Uso

2 Diagrama de Caso de Uso Unified Modeling Language (UML) Universidade Federal do Maranhão UFMA Pós Graduação de Engenharia de Eletricidade Grupo de Computação Assunto: Diagrama de Caso de Uso (Use Case) Autoria:Aristófanes Corrêa

Leia mais

Gerência de Projetos Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br www.ufpa.br/srbo

Gerência de Projetos Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br www.ufpa.br/srbo Gerência de Projetos Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br www.ufpa.br/srbo Laboratório de Tecnologia de Software LTS www.ufpa.br/lts Rede Paraense de Pesquisa em Tecnologias de Informação

Leia mais

Introdução à Engenharia de Software

Introdução à Engenharia de Software Introdução à Engenharia de Software Professor: Rômulo César romulodandrade@gmail.com www.romulocesar.com.br Imagem Clássica Objetivo da aula Depois desta aula você terá uma visão sobre o que é a engenharia

Leia mais

ALESSANDRO RODRIGO FRANCO FERNANDO MARTINS RAFAEL ALMEIDA DE OLIVEIRA

ALESSANDRO RODRIGO FRANCO FERNANDO MARTINS RAFAEL ALMEIDA DE OLIVEIRA ALESSANDRO RODRIGO FRANCO FERNANDO MARTINS RAFAEL ALMEIDA DE OLIVEIRA INTRODUÇÃO O projeto de um banco de dados é realizado sob um processo sistemático denominado metodologia de projeto. O processo do

Leia mais

Processos de Desenvolvimento de Software

Processos de Desenvolvimento de Software Processos de Desenvolvimento de Software Gerenciamento de Projetos Mauro Lopes Carvalho Silva Professor EBTT DAI Departamento de Informática Campus Monte Castelo Instituto Federal de Educação Ciência e

Leia mais

Concepção e Elaboração

Concepção e Elaboração UNIVERSIDADE ESTADUAL PAULISTA INSTITUTO DE BIOCIÊNCIAS, LETRAS E CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIAS DE COMPUTAÇÃO E ESTATÍSTICA Análise e Projeto Orientado a Objetos Concepção e Elaboração Estudo

Leia mais

Engenharia de Software Questionário sobre Engenharia de Requisitos Resolvido Prof. MSc Wagner Siqueira Cavalcante

Engenharia de Software Questionário sobre Engenharia de Requisitos Resolvido Prof. MSc Wagner Siqueira Cavalcante 1 - Q193183 ( Prova: FCC - 2011 - TRT - 19ª Região (AL) - Analista Judiciário - Tecnologia da Informação / Engenharia de Software / Análise de Requisitos; Engenharia de Requisitos; ) De acordo com Sommerville,

Leia mais

Requisitos de Software

Requisitos de Software Requisitos de Software Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 6 Slide 1 Objetivos Apresentar os conceitos de requisitos de usuário e de sistema Descrever requisitos funcionais

Leia mais

GUIA DE CURSO. Tecnologia em Sistemas de Informação. Tecnologia em Desenvolvimento Web. Tecnologia em Análise e Desenvolvimento de Sistemas

GUIA DE CURSO. Tecnologia em Sistemas de Informação. Tecnologia em Desenvolvimento Web. Tecnologia em Análise e Desenvolvimento de Sistemas PIM PROGRAMA DE INTEGRAÇÃO COM O MERCADO GUIA DE CURSO Tecnologia em Sistemas de Informação Tecnologia em Desenvolvimento Web Tecnologia em Análise e Desenvolvimento de Sistemas Tecnologia em Sistemas

Leia mais

Processo de Abertura de Projetosescritorio. Bizagi Process Modeler

Processo de Abertura de Projetosescritorio. Bizagi Process Modeler Processo de Abertura de Projetosescritorio Bizagi Process Modeler Índice PROCESSO DE ABERTURA DE PROJETOS-ESCRITORIO...1 BIZAGI PROCESS MODELER...1 1 PROCESSO DE ABERTURA DE PROJETOS...5 1.1 PROCESSO

Leia mais

APOO Análise e Projeto Orientado a Objetos. Requisitos

APOO Análise e Projeto Orientado a Objetos. Requisitos + APOO Análise e Projeto Orientado a Objetos Requisitos Requisitos 2 n Segundo Larman: n São capacidades e condições às quais o sistema e em termos mais amplos, o projeto deve atender n Não são apenas

Leia mais

Extração de Requisitos

Extração de Requisitos Extração de Requisitos Extração de requisitos é o processo de transformação das idéias que estão na mente dos usuários (a entrada) em um documento formal (saída). Pode se entender também como o processo

Leia mais

Processos de gerenciamento de projetos em um projeto

Processos de gerenciamento de projetos em um projeto Processos de gerenciamento de projetos em um projeto O gerenciamento de projetos é a aplicação de conhecimentos, habilidades, ferramentas e técnicas às atividades do projeto a fim de cumprir seus requisitos.

Leia mais

O processo de melhoria de processo

O processo de melhoria de processo O processo de melhoria de processo Prof.ª Dra. Aida Araújo Ferreira aidaferreira@recife.ifpe.edu.br Modelos de Melhoria de Processo de Software Tecnologia em Análise e Desenvolvimento de Sistemas IFPE

Leia mais

GARANTIA DA QUALIDADE DE SOFTWARE

GARANTIA DA QUALIDADE DE SOFTWARE GARANTIA DA QUALIDADE DE SOFTWARE Fonte: http://www.testexpert.com.br/?q=node/669 1 GARANTIA DA QUALIDADE DE SOFTWARE Segundo a NBR ISO 9000:2005, qualidade é o grau no qual um conjunto de características

Leia mais

REQUISITOS. Prof. Msc. Hélio Esperidião

REQUISITOS. Prof. Msc. Hélio Esperidião REQUISITOS Prof. Msc. Hélio Esperidião OS REQUISITOS O que são requisitos? Uma descrição de um serviço ou de uma limitação O que é a engenharia de requisitos? O processo envolvido no desenvolvimento de

Leia mais

Governança de TI. ITIL v.2&3. parte 1

Governança de TI. ITIL v.2&3. parte 1 Governança de TI ITIL v.2&3 parte 1 Prof. Luís Fernando Garcia LUIS@GARCIA.PRO.BR ITIL 1 1 ITIL Gerenciamento de Serviços 2 2 Gerenciamento de Serviços Gerenciamento de Serviços 3 3 Gerenciamento de Serviços

Leia mais

Gerenciamento de Requisitos Gerenciamento de Requisitos

Gerenciamento de Requisitos Gerenciamento de Requisitos Gerenciamento de Requisitos Objetivos da disciplina Descrever o processo de Gerenciamento e Engenharia de Requisitos para projetos Treinar alunos no Gerenciamento de Requisitos Apresentar estudos de caso

Leia mais

Gerenciamento de Projetos Modulo II Ciclo de Vida e Organização do Projeto

Gerenciamento de Projetos Modulo II Ciclo de Vida e Organização do Projeto Gerenciamento de Projetos Modulo II Ciclo de Vida e Organização do Projeto Prof. Walter Cunha falecomigo@waltercunha.com http://waltercunha.com PMBoK Organização do Projeto Os projetos e o gerenciamento

Leia mais

FATEC Cruzeiro José da Silva. Ferramenta CRM como estratégia de negócios

FATEC Cruzeiro José da Silva. Ferramenta CRM como estratégia de negócios FATEC Cruzeiro José da Silva Ferramenta CRM como estratégia de negócios Cruzeiro SP 2008 FATEC Cruzeiro José da Silva Ferramenta CRM como estratégia de negócios Projeto de trabalho de formatura como requisito

Leia mais

MÓDULO 9 METODOLOGIAS DE DESENVOLVIMENTO DE SISTEMAS

MÓDULO 9 METODOLOGIAS DE DESENVOLVIMENTO DE SISTEMAS MÓDULO 9 METODOLOGIAS DE DESENVOLVIMENTO DE SISTEMAS O termo metodologia não possui uma definição amplamente aceita, sendo entendido na maioria das vezes como um conjunto de passos e procedimentos que

Leia mais

Engenharia de Software: conceitos e aplicações. Prof. Tiago Eugenio de Melo, MSc tiagodemelo@gmail.com

Engenharia de Software: conceitos e aplicações. Prof. Tiago Eugenio de Melo, MSc tiagodemelo@gmail.com Engenharia de Software: conceitos e aplicações Prof. Tiago Eugenio de Melo, MSc tiagodemelo@gmail.com 1 Objetivos da aula Apresentar os conceitos de Engenharia de Software e explicar a sua importância.

Leia mais

Engenharia de Software III

Engenharia de Software III Engenharia de Software III Casos de uso http://dl.dropbox.com/u/3025380/es3/aula6.pdf (flavio.ceci@unisul.br) 09/09/2010 O que são casos de uso? Um caso de uso procura documentar as ações necessárias,

Leia mais

Capítulo 2. Processos de Software. 2011 Pearson Prentice Hall. Todos os direitos reservados. slide 1

Capítulo 2. Processos de Software. 2011 Pearson Prentice Hall. Todos os direitos reservados. slide 1 Capítulo 2 Processos de Software slide 1 Tópicos apresentados Modelos de processo de software. Atividades de processo. Lidando com mudanças. Rational Unified Process (RUP). Um exemplo de um processo de

Leia mais

Levantamento, Análise e Gestão Requisitos. Aula 12

Levantamento, Análise e Gestão Requisitos. Aula 12 Levantamento, Análise e Gestão Requisitos Aula 12 Agenda Miscelâneas (Parte 3): Gerenciamento dos Requisitos Mutáveis Rastreabilidade de Requisitos Processo de Gestão de Mudanças Requisitos Estáveis e

Leia mais

Prof. Raul Sidnei Wazlawick UFSC-CTC-INE. Fonte: Análise e Projeto de Sistemas de Informação Orientados a Objetos, 2ª Edição, Elsevier, 2010.

Prof. Raul Sidnei Wazlawick UFSC-CTC-INE. Fonte: Análise e Projeto de Sistemas de Informação Orientados a Objetos, 2ª Edição, Elsevier, 2010. Casos de Uso de Alto Nível Prof. Raul Sidnei Wazlawick UFSC-CTC-INE 2010 Fonte: Análise e Projeto de Sistemas de Informação Orientados a Objetos, 2ª Edição, Elsevier, 2010. Contexto Na fase de concepção

Leia mais

DESENVOLVIMENTO DE INTERFACE WEB MULTIUSUÁRIO PARA SISTEMA DE GERAÇÃO AUTOMÁTICA DE QUADROS DE HORÁRIOS ESCOLARES. Trabalho de Graduação

DESENVOLVIMENTO DE INTERFACE WEB MULTIUSUÁRIO PARA SISTEMA DE GERAÇÃO AUTOMÁTICA DE QUADROS DE HORÁRIOS ESCOLARES. Trabalho de Graduação DESENVOLVIMENTO DE INTERFACE WEB MULTIUSUÁRIO PARA SISTEMA DE GERAÇÃO AUTOMÁTICA DE QUADROS DE HORÁRIOS ESCOLARES Trabalho de Graduação Orientando: Vinicius Stein Dani vsdani@inf.ufsm.br Orientadora: Giliane

Leia mais

SETIS- III Seminário de Tecnologia Inovação e Sustentabilidade 4 e 5 de novembro de 2014.

SETIS- III Seminário de Tecnologia Inovação e Sustentabilidade 4 e 5 de novembro de 2014. A importância da comunicação no gerenciamento de projetos de softwares: reflexões teóricas Lucas Krüger lucas_kruger-@hotmail.com Resumo: Esse artigo objetiva estudar a comunicação entre cliente e desenvolvedor

Leia mais

Gerenciamento de Projetos

Gerenciamento de Projetos Gerenciamento de Projetos Grupo de Consultores em Governança de TI do SISP 20/02/2013 1 Agenda 1. PMI e MGP/SISP 2. Conceitos Básicos - Operações e Projetos - Gerenciamento de Projetos - Escritório de

Leia mais

O modelo unificado de processo. O Rational Unified Process, RUP.

O modelo unificado de processo. O Rational Unified Process, RUP. Cursos: Sistemas de Informação Disciplina: Administração ADM Prof. Jarbas Avaliação: Prova B1, 5º/6º semestres Data: 27/09/2010 Nome: Gabarito RA: Assinatura: Turma: 1) Segundo as afirmações a seguir,

Leia mais

Gerência de Projetos

Gerência de Projetos Gerência de Projetos Escopo Custo Qualidade Tempo CONCEITO PROJETOS: são empreendimentos com objetivo específico e ciclo de vida definido Precedem produtos, serviços e processos. São utilizados as funções

Leia mais

Service Level Management SLM. Gerenciamento de Níveis de Serviço

Service Level Management SLM. Gerenciamento de Níveis de Serviço Service Level Management SLM Gerenciamento de Níveis de Serviço 1 É o balanço o entre... Qualidade dos serviços entregues Expectativa do cliente 2 Processo: Definições Service Level Management (SLM) Têm

Leia mais

Sistemas de Informação I

Sistemas de Informação I + Sistemas de Informação I Dimensões de análise dos SI Ricardo de Sousa Britto rbritto@ufpi.edu.br + Introdução n Os sistemas de informação são combinações das formas de trabalho, informações, pessoas

Leia mais

TI Aplicada. Aula 02 Áreas e Profissionais de TI. Prof. MSc. Edilberto Silva prof.edilberto.silva@gmail.com http://www.edilms.eti.

TI Aplicada. Aula 02 Áreas e Profissionais de TI. Prof. MSc. Edilberto Silva prof.edilberto.silva@gmail.com http://www.edilms.eti. TI Aplicada Aula 02 Áreas e Profissionais de TI Prof. MSc. Edilberto Silva prof.edilberto.silva@gmail.com http:// Papéis... Um papel é uma definição abstrata de um conjunto de atividades executadas e dos

Leia mais

Ciclo de Vida Clássico ou Convencional CICLOS DE VIDA DE DESENVOLVIMENTO DE SISTEMAS. Ciclo de Vida Clássico ou Convencional. Enfoque Incremental

Ciclo de Vida Clássico ou Convencional CICLOS DE VIDA DE DESENVOLVIMENTO DE SISTEMAS. Ciclo de Vida Clássico ou Convencional. Enfoque Incremental CICLOS DE VIDA DE DESENVOLVIMENTO DE SISTEMAS Elicitação Ciclo de Vida Clássico ou Convencional O Modelo Cascata Análise Ana Paula Terra Bacelo Blois Implementação Material Adaptado do Prof. Marcelo Yamaguti

Leia mais

Referências internas são os artefatos usados para ajudar na elaboração do PT tais como:

Referências internas são os artefatos usados para ajudar na elaboração do PT tais como: Plano de Teste (resumo do documento) I Introdução Identificador do Plano de Teste Esse campo deve especificar um identificador único para reconhecimento do Plano de Teste. Pode ser inclusive um código

Leia mais

GESTÃO DAS INFORMAÇÕES DAS ORGANIZAÇÕES MÓDULO 11

GESTÃO DAS INFORMAÇÕES DAS ORGANIZAÇÕES MÓDULO 11 GESTÃO DAS INFORMAÇÕES DAS ORGANIZAÇÕES MÓDULO 11 Índice 1. Importância do ERP para as organizações...3 2. ERP como fonte de vantagem competitiva...4 3. Desenvolvimento e implantação de sistema de informação...5

Leia mais

Desenvolvimento de Interfaces Prototipação

Desenvolvimento de Interfaces Prototipação Autarquia Educacional do Vale do São Francisco AEVSF Faculdade de Ciências Aplicadas e Sociais de Petrolina - FACAPE Centro de Engenharia e Ciências Tecnológicas CECT Curso de Ciência da Computação Desenvolvimento

Leia mais

Engenharia de Software 2012/3 Aula 4 Engenharia de Requisitos

Engenharia de Software 2012/3 Aula 4 Engenharia de Requisitos Engenharia de Software Engenharia de Software 2012/3 Aula 4 Engenharia de Requisitos Thiago P. da Silva thiagosilva.inf@gmail.com Agenda Engenharia de Requisitos Níveis de Descrição dos Requisitos Tipos

Leia mais

Gestão do Conhecimento A Chave para o Sucesso Empresarial. José Renato Sátiro Santiago Jr.

Gestão do Conhecimento A Chave para o Sucesso Empresarial. José Renato Sátiro Santiago Jr. A Chave para o Sucesso Empresarial José Renato Sátiro Santiago Jr. Capítulo 1 O Novo Cenário Corporativo O cenário organizacional, sem dúvida alguma, sofreu muitas alterações nos últimos anos. Estas mudanças

Leia mais

CONCURSO PÚBLICO ANALISTA DE SISTEMA ÊNFASE GOVERNANÇA DE TI ANALISTA DE GESTÃO RESPOSTAS ESPERADAS PRELIMINARES

CONCURSO PÚBLICO ANALISTA DE SISTEMA ÊNFASE GOVERNANÇA DE TI ANALISTA DE GESTÃO RESPOSTAS ESPERADAS PRELIMINARES CELG DISTRIBUIÇÃO S.A EDITAL N. 1/2014 CONCURSO PÚBLICO ANALISTA DE GESTÃO ANALISTA DE SISTEMA ÊNFASE GOVERNANÇA DE TI RESPOSTAS ESPERADAS PRELIMINARES O Centro de Seleção da Universidade Federal de Goiás

Leia mais

Documento de Arquitetura

Documento de Arquitetura Documento de Arquitetura A2MEPonto - SISTEMA DE PONTO ELETRÔNICO A2MEPonto - SISTEMA DE PONTO ELETRÔNICO #1 Pág. 1 de 11 HISTÓRICO DE REVISÕES Data Versão Descrição Autor 28/10/2010 1 Elaboração do documento

Leia mais

UNIVERSIDADE FEDERAL DO PARANÁ UFPR Bacharelado em Ciência da Computação

UNIVERSIDADE FEDERAL DO PARANÁ UFPR Bacharelado em Ciência da Computação SOFT DISCIPLINA: Engenharia de software AULA NÚMERO: 08 DATA: / / PROFESSOR: Andrey APRESENTAÇÃO O objetivo desta aula é apresentar e discutir conceitos relacionados a modelos e especificações. Nesta aula

Leia mais

Pós-Graduação em Gerenciamento de Projetos práticas do PMI

Pós-Graduação em Gerenciamento de Projetos práticas do PMI Pós-Graduação em Gerenciamento de Projetos práticas do PMI Planejamento do Gerenciamento das Comunicações (10) e das Partes Interessadas (13) PLANEJAMENTO 2 PLANEJAMENTO Sem 1 Sem 2 Sem 3 Sem 4 Sem 5 ABRIL

Leia mais

Professor: Curso: Disciplina: Aula 4-5-6

Professor: Curso: Disciplina: Aula 4-5-6 Professor: Curso: Disciplina: Aula 4-5-6 Turma: Esp. Marcos Morais de Sousa Sistemas de informação Engenharia de Software I Engenharia de Requisitos 03º semestre 1 Engenharia de Requisitos Prof. Marcos

Leia mais

DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Desenvolvimento Ágil Modelos Ágeis. Profª Esp.: Maysa de Moura Gonzaga

DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Desenvolvimento Ágil Modelos Ágeis. Profª Esp.: Maysa de Moura Gonzaga DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Desenvolvimento Ágil Modelos Ágeis Profª Esp.: Maysa de Moura Gonzaga 2º Semestre / 2011 Extreme Programming (XP); DAS (Desenvolvimento Adaptativo de Software)

Leia mais

Faculdade Pitágoras. Engenharia de Software. Prof.: Julio Cesar da Silva. juliocesar@tecnocracia.eti.br. Http://e-academy.com.br

Faculdade Pitágoras. Engenharia de Software. Prof.: Julio Cesar da Silva. juliocesar@tecnocracia.eti.br. Http://e-academy.com.br Faculdade Pitágoras Engenharia de Software Prof.: Julio Cesar da Silva juliocesar@tecnocracia.eti.br Http://e-academy.com.br Evolução do Software (1950 1965) - O hardware sofreu contínuas mudanças - O

Leia mais

Introdução Ciclo de vida tradicional de desenvolvimento Prototipagem Pacotes de software Desenvolvimento de 4ª geração Terceirização

Introdução Ciclo de vida tradicional de desenvolvimento Prototipagem Pacotes de software Desenvolvimento de 4ª geração Terceirização Prof. Ricardo José Pfitscher Material elaborado com base em: José Luiz Mendes Gerson Volney Lagemann Introdução Ciclo de vida tradicional de desenvolvimento Prototipagem Pacotes de software Desenvolvimento

Leia mais

F.1 Gerenciamento da integração do projeto

F.1 Gerenciamento da integração do projeto Transcrição do Anexo F do PMBOK 4ª Edição Resumo das Áreas de Conhecimento em Gerenciamento de Projetos F.1 Gerenciamento da integração do projeto O gerenciamento da integração do projeto inclui os processos

Leia mais

Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Programa de Pós-Graduação em Informática

Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Programa de Pós-Graduação em Informática Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Programa de Pós-Graduação em Informática Disciplina: INF5008 Prof.: (monalessa@inf.ufes.br) Conteúdo 3. Gerência de

Leia mais

PLANEJAMENTO OPERACIONAL - MARKETING E PRODUÇÃO MÓDULO 3 O QUE É PLANEJAMENTO DE VENDAS E OPERAÇÕES?

PLANEJAMENTO OPERACIONAL - MARKETING E PRODUÇÃO MÓDULO 3 O QUE É PLANEJAMENTO DE VENDAS E OPERAÇÕES? PLANEJAMENTO OPERACIONAL - MARKETING E PRODUÇÃO MÓDULO 3 O QUE É PLANEJAMENTO DE VENDAS E OPERAÇÕES? Índice 1. O que é planejamento de...3 1.1. Resultados do planejamento de vendas e operações (PVO)...

Leia mais

Gerenciamento de projetos. cynaracarvalho@yahoo.com.br

Gerenciamento de projetos. cynaracarvalho@yahoo.com.br Gerenciamento de projetos cynaracarvalho@yahoo.com.br Projeto 3URMHWR é um empreendimento não repetitivo, caracterizado por uma seqüência clara e lógica de eventos, com início, meio e fim, que se destina

Leia mais

Ricardo Roberto de Lima UNIPÊ 2008.1 APS-I. Históricos e Modelagem Orientada a Objetos

Ricardo Roberto de Lima UNIPÊ 2008.1 APS-I. Históricos e Modelagem Orientada a Objetos Históricos e Modelagem Orientada a Objetos Histórico Diversas metodologias e métodos surgiram para apoiar OO. Evolução a partir de linguagens C++ e SmallTalk. Anos 80 Anos 80-90: diversidade de autores.

Leia mais

Prova de Conhecimento para Consultores de Implementação MPS.BR INSTRUÇÕES

Prova de Conhecimento para Consultores de Implementação MPS.BR INSTRUÇÕES Implementação MPS.BR 26 de maio de 2008 4 horas de duração e-mail: (DEIXAR EM BRANCO) RESULTADO: Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8 Q9 Q10 Nota INSTRUÇÕES Para a maioria das questões você tem mais de uma opção e

Leia mais

Introdução a Computação

Introdução a Computação Introdução a Computação Aula 03 Profissões de TI Prof. MSc. Edilberto Silva edilms@yahoo.com http:// Papéis... Um papel é uma definição abstrata de um conjunto de atividades executadas e dos respectivos

Leia mais

Aula 2 Revisão 1. Ciclo de Vida. Processo de Desenvolvimento de SW. Processo de Desenvolvimento de SW. Processo de Desenvolvimento de SW

Aula 2 Revisão 1. Ciclo de Vida. Processo de Desenvolvimento de SW. Processo de Desenvolvimento de SW. Processo de Desenvolvimento de SW Ciclo de Vida Aula 2 Revisão 1 Processo de Desenvolvimento de Software 1 O Processo de desenvolvimento de software é um conjunto de atividades, parcialmente ordenadas, com a finalidade de obter um produto

Leia mais

Objetivos. Requisitos de Software. Tipos de Requisitos. O que é um requisito? Requisitos Funcionais e Não- Funcionais. Requisitos Funcionais

Objetivos. Requisitos de Software. Tipos de Requisitos. O que é um requisito? Requisitos Funcionais e Não- Funcionais. Requisitos Funcionais Objetivos de Software Gidevaldo Novais (gidevaldo.vic@ftc.br) Introduzir os conceitos do usuário e do Descrever requisitos funcionais e nãofuncionais (domínio) Apresentar um esqueleto de documento e notas

Leia mais

Como conduzir com sucesso um projeto de melhoria da qualidade

Como conduzir com sucesso um projeto de melhoria da qualidade Como conduzir com sucesso um projeto de melhoria da qualidade Maria Luiza Guerra de Toledo Coordenar e conduzir um projeto de melhoria da qualidade, seja ele baseado no Seis Sigma, Lean, ou outra metodologia

Leia mais

Metodologia de Gerenciamento de Projetos da Justiça Federal

Metodologia de Gerenciamento de Projetos da Justiça Federal Metodologia de Gerenciamento de Projetos da Justiça Federal Histórico de Revisões Data Versão Descrição 30/04/2010 1.0 Versão Inicial 2 Sumário 1. Introdução... 5 2. Público-alvo... 5 3. Conceitos básicos...

Leia mais

APLICATIVO WEB PARA O SETOR DE EXTENSÃO IFC VIDEIRA

APLICATIVO WEB PARA O SETOR DE EXTENSÃO IFC VIDEIRA APLICATIVO WEB PARA O SETOR DE EXTENSÃO IFC VIDEIRA Autores: Claudiléia Gaio BANDT; Tiago HEINECK; Patrick KOCHAN; Leila Lisiane ROSSI; Angela Maria Crotti da ROSA Identificação autores: Aluna do Curso

Leia mais

TRABALHO DE DIPLOMAÇÃO Regime Modular ORIENTAÇÕES SOBRE O ROTEIRO DO PROJETO FINAL DE SISTEMAS DE INFORMAÇÕES

TRABALHO DE DIPLOMAÇÃO Regime Modular ORIENTAÇÕES SOBRE O ROTEIRO DO PROJETO FINAL DE SISTEMAS DE INFORMAÇÕES TRABALHO DE DIPLOMAÇÃO Regime Modular ORIENTAÇÕES SOBRE O ROTEIRO DO PROJETO FINAL DE SISTEMAS DE INFORMAÇÕES [Observação: O template a seguir é utilizado como roteiro para projeto de sistemas orientado

Leia mais

Qualidade de Software

Qualidade de Software Produto de Software Qualidade de Software Um produto de software compreende os programas e procedimentos de computador e a documentação e dados associados, que foram projetados para serem liberados para

Leia mais

extreme Digital Television (XDTv): um método Ágil para o Desenvolvimento de Aplicações para TV Digital.

extreme Digital Television (XDTv): um método Ágil para o Desenvolvimento de Aplicações para TV Digital. APÊNDICES A seguir são exibidos os documentos, formulários e questionários que contribuíram para a elaboração da tese, denominada: XDTv: um método Ágil para o Desenvolvimento de Aplicações para TV Digital.

Leia mais

Metodologias de Desenvolvimento de Sistemas. Analise de Sistemas I UNIPAC Rodrigo Videschi

Metodologias de Desenvolvimento de Sistemas. Analise de Sistemas I UNIPAC Rodrigo Videschi Metodologias de Desenvolvimento de Sistemas Analise de Sistemas I UNIPAC Rodrigo Videschi Histórico Uso de Metodologias Histórico Uso de Metodologias Era da Pré-Metodologia 1960-1970 Era da Metodologia

Leia mais