Proposta de processo de especificação de software a partir de técnicas baseadas em suas funcionalidades sob a óptica de seus usuários finais

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

Download "Proposta de processo de especificação de software a partir de técnicas baseadas em suas funcionalidades sob a óptica de seus usuários finais"

Transcrição

1 Proposta de processo de especificação de software a partir de técnicas baseadas em suas funcionalidades sob a óptica de seus usuários finais Vagner Luiz Gava (IPT) Paulo Antonio de Almeida (EPUSP) Mauro de Mesquita Spínola (EPUSP) Resumo Este trabalho tem como objetivo desenvolver um processo de especificação de softwarwe através da combinação de um conjunto de técnicas que se complementam. Será visto como o uso combinado de técnicas de prototipação orientada por casos de uso e JAD e da lista de eventos podem ser utilizados desde a fase de elicitação de requisitos e reaproveitados durante todo o ciclo de vida do processo de desenvolvimento de software, economizando tempo e aumentando a produtividade de todo o processo, permitindo, desde seu início, derivar elementos para a medida do tamanho do sistema informatizado que está sendo construído. Palavras chave: Casos de uso, Processo de software, Gerência de requisitos. 1. Introdução Apesar da evolução que vem ocorrendo no campo da engenharia de software e de ferramentas para seu desenvolvimento como conseqüência do aumento expressivo da demanda por produtos e serviços de sistemas computadorizados, a área de software sofre, ainda hoje, de problemas crônicos, como por exemplo: Como desenvolver aplicações que atendam as reais necessidades dos usuários e da administração da empresa? Como separar as informações realmente importantes no meio do oceano de dados que envolve a empresa? Como identificar e separar os fatos e necessidades da empresa dos desejos e opiniões das pessoas? Por outro lado, existe uma série de ferramentas/técnicas que, no todo, contribuem positivamente para alcançar os anseios das questões acima. O problema é que estas contribuições são, de um modo geral, isoladas entre si, nem sempre permitindo que o resultado final faça proveito da soma destas contribuições. Este trabalho tem como principal objetivo propor um processo de especificação de software que permita utilizar as melhores contribuições, dentro de seus domínios, de algumas das técnicas mais importantes utilizadas na engenharia de software. Assim, este processo deverá ser dirigido por casos de uso, em conjunto com a lista de eventos da análise essencial para se modelar os eventos e a conseqüente descrição dos caso de uso correspondentes, delineando também as fronteiras do sistema. O uso de técnicas de prototipação/storyboarding aproveitando técnicas JAD (Joint Application Development) permitirão uma maior interatividade com os usuários e stakeholders, facilitando a coleta de requisitos através dos casos de uso, assim como provendo meios para a medida da funcionalidade do sistema através da análise de pontos de ENEGEP 2004 ABEPRO 4605

2 função Finalmente o uso destas técnicas permitirá um aumento de velocidade na primeira iteração do ciclo de desenvolvimento do processo RUP (Rational Unified Process), como conseqüência do uso de prototipação. 2. Clientes e funções do sistema Os problemas relacionados ao levantamento e ao gerenciamento de requisitos tem se mostrado os principais fatores responsáveis pelo sucesso ou insucesso dos projetos de software. Um trabalho de pesquisa e análise desenvolvido pelo instituto Standish Group International e publicado em seu CHAOS Report (1994) apontou as causas mais comuns de sucesso (ou fracasso) de projetos de software, resultando nos 10 mais importantes critérios a serem considerados. Esta pesquisa foi realizada com executivos e gerentes de projetos de software a partir de um questionário que procurou estabelecer os principais critérios que poderiam influenciar positiva ou negativamente um projeto de software. Uma vez identificados os 10 principais critérios, cada um deles foi classificado de acordo com a quantidade de pontos obtidos na pesquisa. O objetivo da utilização desta tabela foi obter um índice variando de 0 a 100 pontos, demonstrando o potencial de sucesso que o projeto de software pode ter de acordo com a pontuação conseguida com a aplicação desses critérios. A tabela abaixo, adaptada do CHAOS Report (1994), relaciona os 10 principais critérios e os pontos atribuídos a cada um deles na pesquisa realizada: Ordem de Importância Critério de Sucesso(*) Qtd. Pontos 01 User Involvement Executive Management Support Clear Statement of Requirements Proper Planning Realistic Expectations Smaller Project Milestones Competent Staff Ownership Clear Vision & Objectives Hard-Working, Focused Staff 03 Total 100 Fonte: (CHAOS Report, 1994) - * Foram mantidos no idioma original para reforçar o significado de cada um deles. Tabela 1 Critérios de Sucesso CHAOS Report É importante notar que o primeiro e o terceiro critérios juntos, podem representar até 34 pontos e são relativos à participação e a comunicação constantes que devem existir entre os usuários e a equipe de desenvolvimento de sistemas durante a execução de todo o projeto de software. Pensando-se nos fatores apontados acima como ligados ao processo e tendo-se como meta a maneira como o usuário vê o sistema e a sua correspondente funcionalidade, obtém-se o foco de orientação da solução adotada. Por isso, as técnicas como: casos de uso, lista de eventos, JAD, prototipação/storyboards e pontos de função, devem ser utilizadas de modo ponderado e em conjunto, já que as mesmas possuem, justamente, como ponto focal, o modo como o usuário percebe as funcionalidades ENEGEP 2004 ABEPRO 4606

3 do sistema e métodos e medidas quantitativas para atingí-las. 3. Lista de eventos e casos de uso De acordo com a Análise Essencial, um sistema não existe por si só, ou seja, ele só existe para permitir que eventos que aconteçam no mundo externo, que são iniciados ou solicitados por agentes (entidades externas) e que tenham importância para o contexto definido para estudo do problema possam ser identificados e tratados pelo sistema (MCNEMANIM & PALMER, 1986). Um evento pode ser definido informalmente como um acontecimento do mundo exterior que requer do sistema uma resposta pré-planejada. À identificação, tratamento e armazenamento das informações relativas a cada evento, dá-se o nome de funcionalidade do sistema. E é o conjunto de funcionalidades que determina o contexto, as capacidades e as limitações na análise para a construção de um sistema de informações, pois a rigor o valor do sistema está na capacidade de responder com eficiência a todos os estímulos (eventos) a que for submetido. Desta forma, pode-se concluir que a base fundamental para definição do problema é a identificação, definição e detalhamento dos eventos que o sistema deve reconhecer e tratar, dentro dos limites impostos pela área de negócio (problema) em que o mesmo se encontra. Uma lista de eventos corresponde então a uma lista narrativa que mostra o comportamento, ou as respostas que o sistema deve processar para cada evento definido dentro dos limites desta solução. Por outro lado, um caso de uso corresponde a uma sequência relacionada de transações em um diálogo entre ator (entidade externa ao sistema) e o sistema que retorne um valor observável para este ator (JACOBSON, 1992). De certo modo, a lista de eventos e casos de uso são muito similares: ambos tentam definir uma visão externa do sistema sob a ótica de entidades externas ao mesmo (atores). A principal diferença é que a lista de eventos dá um indicação detalhada de qual resposta será dada para certo evento (MARTIN, 1998) e ( WINANT, 1996). Assim, a utilização de casos de uso para dirigir todas as fases do desenvolvimento de um sistema informatizado possue as seguintes vantagens (LEFFINGWELL, 2003): Força os desenvolvedores a pensar através da perspectiva do usuário, Casos de uso dão o contexto dos requisitos do sistema. Pode-se compreender porque um requisito é o que é, bem como o sistema atinge seus objetivos, Casos de uso ligam os usuários nos requisitos do processo, permitindo-os compreender o sistema proposto e dando a eles um meio de documentar e comunicar suas necessidades, Em muitas cirscunstâncias, os desenvolvedores escrevem os casos de uso, significando que estes, além de realmente compreenderem os requisitos, também são responsáveis por determiná-los, Os casos de uso servem como uma ferramenta crítica no processo de análise, permitindo a compreensão de que o sistema necessita fazer e como pode ser feito, Os casos de uso servem como uma ferramenta crítica para o processo do projeto e implementação, reduzindo o risco nas transições destes processos, Casos de uso podem ser utilizados diretamente no processo de teste, assegurando que o sistema faça realmente aquilo que se planeja que faça e Casos de uso servem como entrada para a documentação do usuário, convenientemente ENEGEP 2004 ABEPRO 4607

4 organizados em um formato passo a passo. Uma abordagem que considere o sistema como um mecanismo deste tipo é bastante eficaz para a comunicação entre usuários e desenvolvedores de sistemas, pois, por um lado, contorna a linguagem excessivamente técnica dos analistas de sistemas e a linguagem altamente redundante e ambígua dos usuários, e por outro lado, permanece suficientemente precisa para permitir que se produza uma especificação que seja base para as demais fases do projeto. 4. Storyboarding/Técnicas de Prototipação e JAD Storyboarding basicamente corresponde a qualquer técnica que expressa o comportamento do sistema, projeto ou intenção de implementação pela perspectiva do usuário. Foi utilizada inicialmente no cinema e cartoons e representa um esboço dos personagens e da história. Geralmente, storyboards podem ser categorizadas em três tipos (LEFFINGWELL, 2003): Passivo: Podem ser constituídos de quadros, fotos, esboços, etc. Neste caso é apresentado ao usuário as regras do sistema em sua seqüência, com a explanação do tipo Quando você faz isto, acontece isto, Ativo: Corresponde a uma seqüência de figuras que mostram uma descrição automatizada do modo como o sistema se comporta em um uso típico ou em um cenário operacional, por exemplo em uma apresentação automática de slides e Interativo: Permite ao usuário interagir sobre o sistema de um modo mais realístico, exigindo sua participação. Pode ser uma simulação dos possíveis cenários (protótipo não funcional), ou mesmo um protótipo funcional do sistema simplificado. A prototipação funcional de acordo com Boar (1984), implementa de modo simplificado parte dos requisitos do sistema através de ferramentas específicas e após obter-se os requisitos, o protótipo é descartado, passando-se para o modelo tradicional de desenvolvimento. Hoje, pode-se dizer que uma variante desta técnica é aplicada no processo incremental e iterativo do RUP, onde na verdade, após a primeira iteração de um ciclo de desenvolvimento, tem-se de fato um protótipo funcional do sistema (JACOBSON, 1999) e (KRUCHTEN, 2000). A prototipação não funcional obtém o comportamento dos usuários, stakeholders e do sistema através de interações e iterações com estes, por meio de um conjunto de interfaces gráficas simulando o comportamento real do sistema. Na medida que os casos de uso descrevem uma seqüência de eventos entre um ator e o sistema de modo a dar um resultado de valor para o usuário, sua utilização com prototipação não funcional se torna natural. Outro aspecto que pode ser considerado para a escolha de utilização de prototipação não funcional para a obtenção de requisitos corresponde ao fato de que para o ator basta que a resposta seja aquilo que o mesmo espera do sistema, não importando se esta resposta foi obtida através da implementação de um conjunto de funcionalidades ou somente pela simulação deste comportamento (ação/resposta). Assim, os casos de uso podem ser desenvolvidos em conjunto com uma série de interfaces de usuário, como por exemplo web browsers ou GUI (Graphical User Interface), uma vez que as interações entre os atores e o sistema implicam em uma série destas interfaces, que podem ser construídas visando os passos descritos pelos casos de uso (LEFFINGWELL, 2003). O uso de storyboards interativos, que na realidade são protótipos do sistema (funcionais ou não) permitem uma série de vantagens (BOAR,1984) e (LEFFINGWELL, 2003): ENEGEP 2004 ABEPRO 4608

5 Reduz a distância entre os participantes do projeto: A comunicação é um problema fundamental no desenvolvimento. Mesmo quando uma pessoa sabe o que quer, sempre ocorrem mudanças quando estas necessidades se transformam em requisitos, Permite um aumento da participação e interesse dos atores: Sistemas complexos que envolvem várias áreas de uma empresa requerem um compromisso, concordância e consenso entre vários atores para poderem operar corretamente, Sistemas através de exemplos: Com o passar do tempo, através do uso contínuo desta técnica, serão produzidos uma série de protótipos que poderão ser utilizados para demonstrar diferentes soluções aos usuários, permitindo estimular idéias, identificar estilos, mostrar o que é possível e permitir a explicação de suas necessidades em termos de modificações nos protótipos existentes, Aumenta a eficiência e diminui o tempo para a implementação das iterações planejadas: O uso desta técnica desde a elicitação de requisitos, permite que haja um ganho de produtividade no primeiro ciclo de desenvolvimento dos casos de usos no RUP, pois os requisitos estarão mais maduros antes do início do primeiro ciclo, mudando-se de requisitos não planejados para iterações planejadas, não sendo necessário fechar este ciclo para se ter o primeiro protótipo funcional do sistema, Permite medidas do tamanho das funcionalidades através da análise de pontos de função: a partir da identificação das funções do tipo dados e das funções do tipo transação e um esboço do modelo de dados do sistema é possível o cálculo dos pontos de função desde o início do sistema (elicitação) e seu refinamento durante os diversos ciclos de desenvolvimento (VAZQUEZ, 2003), É um veículo para a validação de requisitos e Permite desde cedo o teste das interfaces. A prototipação, tal como definida acima, tanto funcional, como não funcional pode ser aplicada a um conjunto de sistemas bons candidatos, que devem possuir as seguintes características (BOAR,1984): O sistema não exige grande quantidade de especificação algorítmica. A aplicação deve ser um problema estruturado com uma grande quantia de elementos de dados e relacionamento entre registros mas uma pequena quantia de processos algorítmicos, Os usuários devem estar dispostos e capazes de participar ativamente, assim como o gerente do projeto e O sistema possui muita interação com os usuários através de transações com relatórios associados aos banco de dados, não operando com muito processamento em lote ( batch ). A técnica de storyboarding interativa através do uso de protótipos desde a fase de elicitação de um projeto de software e acompanhando todo o ciclo de desenvolvimento deve ser orientada, sempre que possível, utilizando-se parte das práticas JAD (Joint Application Design) e que podem ser resumidas como se segue (COSTA, 1994): Dar preferência ao uso de reuniões ou sessões de trabalho, ao invés de entrevistas individuais: a principal vantagem é que os usuários se sentem prestigiados e parte integrante do processo de desenvolvimento, visto que suas opiniões são consideradas e as divergências são resolvidas de forma transparente, As decisões são baseadas em consenso: a forma mais produtiva de decisão é aquela alcançada por consenso, isto é, não ocorre necessariamente uma unanimidade, mas sim cada membro concorda que a solução encontrada é a melhor para o grupo e que é possível ENEGEP 2004 ABEPRO 4609

6 conviver com ela sem ferir convicções ou valores essenciais, Utilizar a figura do facilitador: sua responsabilidade consiste em sugerir métodos e procedimentos que ajudem o grupo a se concentrar em tarefas específicas. Também deve ser capaz de consultar a documentação existente sobre o projeto, entrevistar individualmente cada participante buscando entender o que eles fazem, esclarecer os participantes do que é a técnica e o que é esperado de sua participação, Papéis bem definidos: executivo patrocinador, gerente de projetos, equipe, facilitador e documentador e Planejar e preparar as reuniões: Cada reunião deve ter um única finalidade, com escopo e restrições bem definidos. 5. Aplicação Prática O exemplo em questão corresponde a uma parte do projeto ManWapp (Maintenence Wireless Application) que está sendo desenvolvido no LTI da Engenharia de Produção da POLI (http://www.vanzolini-ead.org.br/crsoft/). Este projeto tem o seguinte objetivo, retirado de seu documento de visão: O sistema terá com principal objetivo o gerenciamento de serviços de campo, ou seja, o serviço terceirizado, envolvendo as áreas de telecomunicações e energia elétrica, entre outras. Este gerenciamento se dará pelo acompanhamento da solicitação de chamadas (serviços) até o seu término, envolvendo a área administrativa do cliente, infra-estrutura, logística e manutenção e o prestador de serviços. Durante as discussões entre os especialistas do domínio e analistas, foi construída a lista de eventos (LE) do sistema (tabela 2) e a partir dela, vários casos de uso foram identificados, sendo que somente um será utilizado (figura 2 ). No. Evento Resposta Padrão 12 CallCenter informa Solicitação Chamada identifica CallCenter identifica Cliente registra SolicitacaoChamada 13 Atendente informa Solicitacão Chamada identifica Cliente registra SolicitacaoChamada 22 Prestador solicita Ordem Chamada identifica Prestador registra Envio Ordem Chamada Tabela 2 Lista de eventos (LE) parcial do sistema Manwapp Em sessões específicas de JAD para definição e refinamento de cada um dos casos de uso, foram feitas as simulações dos mesmos, através de um trabalho interativo com os participantes das reuniões (usuários, stakeholders, analistas, etc). Pode-se notar, na figura 2, o inter-relacionamento entre a lista de eventos, caso de uso, prototipação e pontos de funções. Assim, dado um caso de uso, pode-se detalhar cada ação e sua respectiva resposta a partir do detalhamento das interfaces gráficas do protótipo. Por exemplo, quando o cliente informa o CPF (passo 1), o atendente entra com esta informação no sistema (interface 1A ) e o sistema responde com uma lista de clientes (interface 1B). No passo 2 deste caso de uso, o atendente seleciona o cliente da lista (interface 1A ) e como resposta são mostrados detalhes da chamada selecionada pelo atendente ENEGEP 2004 ABEPRO 4610

7 (interface 2AB). Finalmente no passo 3 o cliente informa o problema ao atendente, que registra na inteface 2B e é aberta uma ordem de serviço para esta chamada. Call Atendente Center ReceberChamadas Call Atendente Center Caso de uso: Receber Chamada LE 13 Atores Call center e Atendente Entrada CPF, Nome, Descrição, Telefone e para contato Saída Lista de clientes e detalhes do cliente Pré-condiçoes Cliente cadastrado Pós-condições Chamada registrada Passo Descrição da ação Resposta Interface Tabelas função Exceções 1 Cliente informa CPF ou nome ao atendente (1A). Atendente seleciona cliente da lista (1B) Cliente informa para atendente descrição do problema e dados para retorno (2B) O cliente não sabe número de CPF, ou CPF incorreto. Atendente escolhe nome ou número correto da lista (1B) São mostradas informações genéricas sobre o cliente (1B) São mostradas detalhes de informações sobre o cliente (2A) Chamada é registrada São mostradas informações genéricas sobre o cliente (1B) 1.Pesquisa de clientes 1.Pesquisa de clientes e 2.Solicitação de chamada 2.Solicitação de chamada Pesquisa de clientes Clientes Clientes e Contratos Chamada Clientes 1 CE 1 CE 1EE 1 CE Figura 2. Caso de uso Receber Chamadas Mesmo quando o ator não corresponde a uma pessoa, o conceito de prototipação pode ser aplicado, uma vez que as informações trocadas sempre podem ser mostradas como uma ENEGEP 2004 ABEPRO 4611

8 interface gráfica (evento 12 da tabela 2). Na figura 2, no diagrama de caso de uso ReceberChamada, o ator Call Center é um arquivo que é importado pela sistema. A coluna tabelas corresponde às tabelas que o sistema acessa para poder dar suas respectivas respostas, sendo importante para se determinar os pontos de função do tipo dado. A coluna ponto de função permite estimar os pontos de função do tipo transação, identificando-se se é uma entrada externa (EE), uma saída externa (SE), ou uma consulta externa (CE), assim como os tipos de dados (pelas interfaces) e arquivos referenciados. Por exemplo, na figura 2, no passo 1 do caso de uso é necessário uma consulta externa (CE), sendo, neste caso envolvido dois tipos de dados (CPF e Nome) e um único arquivo referenciado (Cliente). Na medida que se conhece melhor o modelo de dados, pode-se refinar estas estimativas, inclusive identificando-se melhor os arquivos referenciados (VAZQUEZ, 2003). 6 Conclusões As diretivas propostas neste trabalho fazem parte do processo de desenvolvimento de software utilizado pelo elabsoft do LTI (Laboratório de Tecnologia de Informação) do Departamento de Engenharia de Produção da Escola Politénica da USP e pelo Labsoft da Divisão de Mecânica e Eletricidade do IPT e tem-se mostrado muito úteis em sua aplicação prática. Estas diretivas caminham no sentido de proporcionar um mecanismo eficaz para a comunicação entre usuários e desenvolvedores de sistemas, obtendo-se requisitos claros e consensuais, além de elementos para a estimativa do tamanho do sistema desde suas fases inicias de desenvolvimento. Os protótipos obtidos pela aplicação destas diretivas permitem o reaproveitamento das interfaces e casos de uso de negócio e facilitam o desenvolvimento de novos sistemas, através da técnica sistema por exemplos. Referências BOAR, B.H. (1985) Application Prototyping. John Wiley & Sons. 1 a Edição. New York. COSTA, O.W.D. (1994) JAD Joint Application Development. Livraria e Editora Infobook S.A. 1 a Edição. Rio de Janeiro. JACOBSON,G.(1992) Object-Oriented Software Engineering: A Use Case Driven Approach. Addison-Wesley JACOBSON, G. & BOOCH, G. & RUMBAUGH, J. (1999) - The Unified Software Development Process. Addison Wesley Longaman Inc. 2 a Edição. Massachusetts. KRUCHTEN, P. (2000) The Rational Unified Process: An Introduction. Pearson Education. LEFFINGWELL, D & WIDRIG, D. (2003) Managing Software Requirements. A Use Case Approach. Addison-Wesley. 2 a Edição. Boston MARTIN, D. (1998) Prelimirary Design Use Case: Combining Use cases and Event Response Lists for Reuse and Legacy Enhancement. Sofware Engineering Notes Vol. 23, n. 1, p McMENAMIM, S.M & PALMER, J.P. (1984) - Essential Systems Analysis. Englewood Cliffs. 1 a Edição. N.J. THE STANDISH GRUP SAMPLE RESEARCH, The CHAOS Report, VAZQUEZ, E.V & SIMÕES, G.S. & ALBERT, R.M. (2003) - Análise de Pontos de Função: medição, estimativas e gerenciamento de projetos de software. Érica. 1 a Edição. São Paulo. WINANT, B. & FRANKEL, M. (1996) - Key Dictionary and Use Cases. Object Magazine, SIGS Publications, Vol. 6, p , November. ENEGEP 2004 ABEPRO 4612

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

UNIVERSIDADE FEDERAL DO PARANÁ. CURSO: Ciência da Computação DATA: / / 2013 PERÍODO: 4 o.

UNIVERSIDADE FEDERAL DO PARANÁ. CURSO: Ciência da Computação DATA: / / 2013 PERÍODO: 4 o. CURSO: Ciência da Computação DATA: / / 2013 PERÍODO: 4 o. PROFESSOR: Andrey DISCIPLINA: Técnicas Alternativas de Programação AULA: 08 APRESENTAÇÃO Na aula de hoje vamos apresentar e discutir como definir

Leia mais

Engenharia de Requisitos de Software. Visão Geral

Engenharia de Requisitos de Software. Visão Geral de Software Visão Geral João Sousa Apoio: Desenvolvimento de Sw - Como estamos? Segundo o Standish Group (CHAOS Report 2004): 34% dos projetos com sucesso. 15% dos projetos cancelados antes de completados.

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

Casos de Uso O que é. Casos de Uso. Objetivos de um Caso de Uso. Atores. Atores e Casos de Uso. Diagramas de Caso de Uso

Casos de Uso O que é. Casos de Uso. Objetivos de um Caso de Uso. Atores. Atores e Casos de Uso. Diagramas de Caso de Uso Casos de Uso O que é Casos de Uso Descrições narrativas de processos do domínio da aplicação Documentam a seqüência de eventos de um ator (um agente externo) usando o sistema para completar, do início

Leia mais

Programa do Módulo 2. Processo Unificado: Visão Geral

Programa do Módulo 2. Processo Unificado: Visão Geral 9.1 Programa do Módulo 2 Orientação a Objetos Conceitos Básicos Análise Orientada a Objetos (UML) O Processo Unificado (RUP) Processo Unificado: Visão Geral 9.2 Encaixa-se na definição geral de processo:

Leia mais

No artigo anterior explicamos. Desenvolvimento de Software Dirigido por Caso de Uso. Parte II: Especificando Caso de Uso

No artigo anterior explicamos. Desenvolvimento de Software Dirigido por Caso de Uso. Parte II: Especificando Caso de Uso Desenvolvimento de Software Dirigido por Caso de Uso Parte II: Especificando Caso de Uso Vinicius Lourenço de Sousa viniciuslsousa@gmail.com Atua no ramo de desenvolvimento de software há mais de 10 anos,

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

Extração de Requisitos

Extração de Requisitos Extração de Requisitos Criação: Março 2001 Atualização: Setembro 2005 Referências I.Sommerville. Sw Engineering, 6ª ed, 2001, cap6 P.Jalote. An Integrated Approach to Sw Engineering, 2ª ed., 1997, cap3

Leia mais

do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade;

do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade; 1 ARQUITETURA E DESIGN DE SOFTWARE O que é Arquitetura? do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade; do dicionário: Arte de projetar e construir prédios,

Leia mais

Residência em Arquitetura de Software. O Modelo PMBOK. srbo@ufpa.br www.ufpa.br/srbo. Gerência de Desenvolvimento 2008.2

Residência em Arquitetura de Software. O Modelo PMBOK. srbo@ufpa.br www.ufpa.br/srbo. Gerência de Desenvolvimento 2008.2 Residência em Arquitetura de Software O Modelo PMBOK Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br www.ufpa.br/srbo Gerência de Desenvolvimento 2008.2 Faculdade de Computação Instituto de Ciências

Leia mais

ATENAS: Um Sistema Gerenciador de Regras de Negócio

ATENAS: Um Sistema Gerenciador de Regras de Negócio 1. Introdução ATENAS: Um Sistema Gerenciador de Regras de Negócio Geraldo Zimbrão da Silva (IM/UFRJ) Victor Teixeira de Almeida (COPPE/UFRJ) Jano Moreira de Souza (COPPE/UFRJ) Francisco Gonçalves Pereira

Leia mais

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS PDS - DATASUS Processo de Desenvolvimento de Software do DATASUS Coordenação Geral de Arquitetura e Engenharia Tecnológica Coordenação de Padronização e Qualidade de Software Gerência de Padrões e Software

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

Utilizando métricas para dimensionar um software.

Utilizando métricas para dimensionar um software. Utilizando métricas para dimensionar um software. Entenda como funcionam as Métricas de Software, como e quando devem ser utilizadas, e qual a real necessidade do uso desta técnica da Engenharia de Software.

Leia mais

RUP. Evolução. Principais Características do RUP. Principais Características do RUP RUP

RUP. Evolução. Principais Características do RUP. Principais Características do RUP RUP RUP Rational Unified Process ( Unificado de Desenvolvimento da Rational) Conjunto de passos que tem como objetivo atingir uma meta de software na ES, processo que visa a produzir o software - de modo eficiente

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: 13B DATA: / / PROFESSOR: Andrey APRESENTAÇÃO O objetivo desta aula é apresentar, discutir o conceito de métricas de software orientadas a função. DESENVOLVIMENTO

Leia mais

Princípios da Engenharia de Software Aula 02. Prof.: Franklin M. Correia

Princípios da Engenharia de Software Aula 02. Prof.: Franklin M. Correia Princípios da Engenharia de Software Aula 02 Prof.: Franklin M. Correia Na aula anterior... Introdução a Engenharia de Software O que é software? O que é Engenharia de Software? Conceitos importantes Tipos

Leia mais

LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE

LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE RESUMO Fazer um bom levantamento e especificação de requisitos é algo primordial para quem trabalha com desenvolvimento de sistemas. Esse levantamento

Leia mais

Notas de Aula 04: Casos de uso de um sistema

Notas de Aula 04: Casos de uso de um sistema Notas de Aula 04: Casos de uso de um sistema Objetivos da aula: Aprender os elementos básicos da modelagem por casos de uso Utilizar as associações entre casos de uso, atores e demais artefatos Compreender

Leia mais

Especificação de Sistemas e Especificação de Requisitos

Especificação de Sistemas e Especificação de Requisitos Especificação de Sistemas e Especificação de Requisitos Universidade Federal do Estado do Rio de Janeiro Centro de Ciências Exatas e Tecnologia Escola de Informática Aplicada Curso: Bacharelado em Sistemas

Leia mais

Se observarmos nos diferentes livros. Planejamento de Testes a partir de Casos de Uso

Se observarmos nos diferentes livros. Planejamento de Testes a partir de Casos de Uso Planejamento de Testes a partir de Casos de Uso Arilo Cláudio Dias Neto ariloclaudio@gmail.com É Bacharel em Ciência da Computação formado na Universidade Federal do Amazonas, Mestre em Engenharia de Sistemas

Leia mais

Engenharia de Software Software Requirements

Engenharia de Software Software Requirements Requisitos Engenharia de Software Software Requirements SWEBOK, Capítulo 2 Primeira Classificação de Requisito 1. Requisito do usuário: declarações sobre as funções que o sistema deve oferecer 2. Requisito

Leia mais

Processos de Software. 2007 by Pearson Education Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 4 Slide 1

Processos de Software. 2007 by Pearson Education Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 4 Slide 1 Processos de Software Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 4 Slide 1 Objetivos Apresentar modelos de processos de software Descrever três modelos genéricos de processo e quando

Leia mais

Processo Unificado (RUP)

Processo Unificado (RUP) Fases do Desenvolvimento Processo Unificado (RUP) Ulf Bergmann ulf@ime.eb.br Domínio do Problema Objetos Objetos do do Mundo Mundo real real Modelo Semântico Domínio da Solução Aplicação Interface Serviços

Leia mais

FERRAMENTA DE WORKFLOW DE DOCUMENTOS PARA O AMBIENTE COLABORATIVO ARCASE

FERRAMENTA DE WORKFLOW DE DOCUMENTOS PARA O AMBIENTE COLABORATIVO ARCASE FERRAMENTA DE WORKFLOW DE DOCUMENTOS PARA O AMBIENTE COLABORATIVO ARCASE Marcello Thiry thiry@univali.br Ana Frida da Cunha Silva anafrida@univali.br Universidade do Vale do Itajaí UNIVALI Campus São José

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

! "! # " # $ "! $ %& %

! ! #  # $ ! $ %& % !"#"$! %& O CHAOS Empresas americanas gastam mais de US$275 bilhões a cada ano em projetos de desenvolvimento de software aplicativo. Muitos desses projetos falharão, mas não por falta de dinheiro ou tecnologia;

Leia mais

Engenharia de Software

Engenharia de Software Tema da Aula A Modelagem e os Métodos em Prof. Cristiano R R Portella portella@widesoft.com.br Modelos em Abstração Um modelo é uma abstração de um objeto ou fenômeno sob um determinado ponto de vista

Leia mais

Palavras-Chaves: engenharia de requisitos, modelagem, UML.

Palavras-Chaves: engenharia de requisitos, modelagem, UML. APLICAÇÃO DA ENGENHARIA DE REQUISITOS PARA COMPREENSÃO DE DOMÍNIO DO PROBLEMA PARA SISTEMA DE CONTROLE COMERCIAL LEONARDO DE PAULA SANCHES Discente da AEMS Faculdades Integradas de Três Lagoas RENAN HENRIQUE

Leia mais

ANÁLISE E PROJETO ORIENTADO A OBJETOS. Isac Aguiar isacaguiar.com.br isacaguiar@gmail.com

ANÁLISE E PROJETO ORIENTADO A OBJETOS. Isac Aguiar isacaguiar.com.br isacaguiar@gmail.com ANÁLISE E PROJETO ORIENTADO A OBJETOS Isac Aguiar isacaguiar.com.br isacaguiar@gmail.com Análise Descrição do problema a ser implementado Descrição dos objetos e classes que fazem parte do problema, Descrição

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

Ciência da Computação ENGENHARIA DE SOFTWARE. Análise dos Requisitos de Software

Ciência da Computação ENGENHARIA DE SOFTWARE. Análise dos Requisitos de Software Ciência da Computação ENGENHARIA DE SOFTWARE Análise dos Requisitos de Software Prof. Claudinei Dias email: prof.claudinei.dias@gmail.com Roteiro Introdução Tipos de requisitos Atividades Princípios da

Leia mais

Implantando um Programa de Melhoria de Processo: Uma Experiência Prática

Implantando um Programa de Melhoria de Processo: Uma Experiência Prática Implantando um Programa de Melhoria de Processo: Uma Experiência Prática Evandro Polese Alves Ricardo de Almeida Falbo Departamento de Informática - UFES Av. Fernando Ferrari, s/n, Vitória - ES - Brasil

Leia mais

FORMULÁRIO PARA CRIAÇÃO DE DISCIPLINA

FORMULÁRIO PARA CRIAÇÃO DE DISCIPLINA Universidade Federal do Ceará Pró-Reitoria de Graduação Coordenadoria de Projetos e Acompanhamento Curricular Divisão de Pesquisa e Desenvolvimento Curricular FORMULÁRIO PARA CRIAÇÃO DE DISCIPLINA 1. Unidade

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Software Requisitos de Software Prof. MSc. Edilberto Silva prof.edilberto.silva@gmail.com http://www.edilms.eti.br Requisito O que é um REQUISITO? Em software: É a CARACTERIZAÇÃO do que o

Leia mais

UML: Casos de Uso. Projeto de Sistemas de Software

UML: Casos de Uso. Projeto de Sistemas de Software UML: Casos de Uso Projeto de Sistemas de Software UML Casos de Uso Introdução Casos de uso Elementos do diagrama de casos de uso Descrição de casos de uso Exemplo: Blog Ferramentas de modelagem Bibliografia

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

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

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

Uma Abordagem usando PU

Uma Abordagem usando PU Uma Abordagem usando PU Curso de Especialização DEINF - UFMA Desenvolvimento Orientado a Objetos Prof. Geraldo Braz Junior Referências: Baseada em: Rational Software Corpotation G. Booch, Ivar Jacobson,

Leia mais

Planejamento da disciplina: Modelagem de processos de negócio

Planejamento da disciplina: Modelagem de processos de negócio UNIVERSIDADE FEDERAL DE MINAS GERAIS / INSTITUTO DE CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIA DA COMPUTAÇÃO Planejamento da disciplina: Modelagem de processos de negócio Professor: Clarindo Isaías Pereira

Leia mais

Gestão de Projectos de Software - 1

Gestão de Projectos de Software - 1 Gestão de Projectos de Software Licenciaturas de EI / IG 2012/2013-4º semestre msantos@ispgaya.pt http://paginas.ispgaya.pt/~msantos Gestão de Projectos de Software - 1 Objectivos da Disciplina de Gestão

Leia mais

1 UML (UNIFIED MODELING LANGUAGE)

1 UML (UNIFIED MODELING LANGUAGE) 1 UML (UNIFIED MODELING LANGUAGE) Segundo Tonsig (2003), para conseguir desenvolver um software capaz de satisfazer as necessidades de seus usuários, com qualidade, por intermédio de uma arquitetura sólida

Leia mais

1. Desenvolver o software iterativamente. Um pouco de reflexão: Acabou aí? 31/08/2010

1. Desenvolver o software iterativamente. Um pouco de reflexão: Acabou aí? 31/08/2010 Engenharia de Software Aula 5 (Versão 2010-02) Melhores práticas para desenvolvimento de software Desenvolver de forma iterativa e gerenciar requisitos Professor Gabriel Baptista ( gabriel.baptista@uninove.br

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

Casos de Uso - definições

Casos de Uso - definições Casos de Uso - definições Um caso de uso é uma descrição narrativa de uma seqüência de eventos que ocorre quando um ator (agente externo) usa um sistema para realizar uma tarefa [Jacobson 92] Um caso de

Leia mais

A PROBLEMÁTICA DO DESENVOLVIMENTO DE SOFTWARE: CRISE OU CALAMIDADE CRÔNICA?

A PROBLEMÁTICA DO DESENVOLVIMENTO DE SOFTWARE: CRISE OU CALAMIDADE CRÔNICA? A PROBLEMÁTICA DO DESENVOLVIMENTO DE SOFTWARE: CRISE OU CALAMIDADE CRÔNICA? ADEMILSON ANGELO CABRAL Discente da AEMS Faculdades Integradas de Três Lagoas DIEGO BEZERRA DA SILVA Discente da AEMS Faculdades

Leia mais

Uma Metodologia de Desenvolvimento de Sistemas de Informações em Empresas de Pequeno e Médio Porte

Uma Metodologia de Desenvolvimento de Sistemas de Informações em Empresas de Pequeno e Médio Porte Uma Metodologia de Desenvolvimento de Sistemas de Informações em Empresas de Pequeno e Médio Porte Autoria: Denis Silveira, Eber Schmitz Resumo: Este artigo apresenta uma Metodologia Rápida de Desenvolvimento

Leia mais

Uma Arquitetura de Linha de Produto Baseada em Componentes para Sistemas de Gerenciamento de Workflow

Uma Arquitetura de Linha de Produto Baseada em Componentes para Sistemas de Gerenciamento de Workflow Uma Arquitetura de Linha de Produto Baseada em Componentes para Sistemas de Gerenciamento de Workflow Itana M. S. Gimenes 1 itana@din.uem.br Fabrício R. Lazilha 2 fabricio@cesumar.br Edson A. O. Junior

Leia mais

Engenharia de Software I

Engenharia de Software I Engenharia de Software I Curso de Sistemas de Informação Karla Donato Fook karladf@ifma.edu.br DESU / DAI 2015 Desenvolvimento Rápido de Software 2 1 Para quê o Desenvolvimento Rápido de Software? Os negócios

Leia mais

Engenharia de Software: Introdução. Mestrado em Ciência da Computação 2008 Profa. Itana Gimenes

Engenharia de Software: Introdução. Mestrado em Ciência da Computação 2008 Profa. Itana Gimenes Engenharia de Software: Introdução Mestrado em Ciência da Computação 2008 Profa. Itana Gimenes Programa 1. O processo de engenharia de software 2. UML 3. O Processo Unificado 1. Captura de requisitos 2.

Leia mais

Plano de Projeto G Stock. G Stock. Plano de Projeto. Versão 1.0

Plano de Projeto G Stock. G Stock. Plano de Projeto. Versão 1.0 Plano de Projeto G Stock Plano de Projeto G Stock Versão 1.0 Histórico das Revisões Data Versão Descrição Autores 10/09/2010 1.0 Descrição inicial do plano de projeto Denyson José Ellís Carvalho Isadora

Leia mais

Derivando a arquitetura inicial do software de uma central de monitoração de diabéticos a partir do modelo de Negócio da UML

Derivando a arquitetura inicial do software de uma central de monitoração de diabéticos a partir do modelo de Negócio da UML Derivando a arquitetura inicial do software de uma central de monitoração de diabéticos a partir do modelo de Negócio da UML Claudio Yua Shen Ling Centro Estadual de Educação Tecnológica Paula Souza (CEETEPS)

Leia mais

! Introdução. " Motivação para Processos de Software. ! Processo Unificado (USDP) " Definições " RUP x USDP " Características do Processo Unificado

! Introdução.  Motivação para Processos de Software. ! Processo Unificado (USDP)  Definições  RUP x USDP  Características do Processo Unificado Agenda! Introdução " Motivação para Processos de Software! (USDP) " Definições " RUP x USDP " Características do! Descrição detalhada do! Processos Derivados! Templates simplificados! Conclusões 2 Processo

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

SISTEMATIZAÇÂO DOS TIPOS DE INFORMAÇÂO DO PLANEJAMENTO ESTRATÉGICO EMPRESARIAL E DE TECNOLOGIA DA INFORMAÇÂO E COMUNICAÇÂO

SISTEMATIZAÇÂO DOS TIPOS DE INFORMAÇÂO DO PLANEJAMENTO ESTRATÉGICO EMPRESARIAL E DE TECNOLOGIA DA INFORMAÇÂO E COMUNICAÇÂO SISTEMATIZAÇÂO DOS TIPOS DE INFORMAÇÂO DO PLANEJAMENTO ESTRATÉGICO EMPRESARIAL E DE TECNOLOGIA DA INFORMAÇÂO E COMUNICAÇÂO Danilo Freitas Silvas Sistemas de informação CEATEC danilofs.ti@gmail.com Resumo:

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

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

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

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

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

Levantamento de Requisitos.

Levantamento de Requisitos. FACULDADES INTEGRADAS MATO-GROSSENSES DE CIÊNCIAS SOCIAIS E HUMANAS RESUMO Levantamento de Requisitos. Leandro Cícero da Silva Mello. Prof. Jeanine Ferrazza Meyer Metodologia e Técnica de Pesquisa- Levantamento

Leia mais

Sistemas de Informação e Programação II Odorico Machado Mendizabal

Sistemas de Informação e Programação II Odorico Machado Mendizabal Sistemas de Informação e Programação II Odorico Machado Mendizabal Universidade Federal do Rio Grande FURG C3 Engenharia de Computação 16 e 23 de março de 2011 Processo de Desenvolvimento de Software Objetivos

Leia mais

UNIVERSIDADE DE MOGI DAS CRUZES Centro de Ciências Exatas e Tecnológicas

UNIVERSIDADE DE MOGI DAS CRUZES Centro de Ciências Exatas e Tecnológicas UNIVERSIDADE DE MOGI DAS CRUZES Centro de Ciências Exatas e Tecnológicas Sistemas de Informação e Tecnologia em 3º Semestre Análise Orientada aos Objetos Modelagem de Casos de Uso Objetivo: Apresentar

Leia mais

Projeto Disciplinar de Infra-Estrutura de Software ECOFROTA TRIBUNAL THEMIS

Projeto Disciplinar de Infra-Estrutura de Software ECOFROTA TRIBUNAL THEMIS 1 Projeto Disciplinar de Infra-Estrutura de Software ECOFROTA TRIBUNAL THEMIS EDILBERTO SILVA 1, AQUILA ISRAEL (1316079) 2, CYNTHIA FERREIRA (1316079) 2, MARKO DE CASTRO (1316119) 2, RAFAELA ALMEIDA (1316189)

Leia mais

Requisitos. Professor Gabriel Baptista ( gabriel.baptista@uninove.br ) ( http://sites.google.com/site/professorgabrielbaptista )

Requisitos. Professor Gabriel Baptista ( gabriel.baptista@uninove.br ) ( http://sites.google.com/site/professorgabrielbaptista ) Qualidade de Software Aula 8 (Versão 2012-01) 01) Requisitos Professor Gabriel Baptista ( gabriel.baptista@uninove.br ) ( http://sites.google.com/site/professorgabrielbaptista ) Revisando... 1. Qual o

Leia mais

Análise e Projeto OO com UML. Lição 3 Especificação e Modelagem de Requisitos com UML

Análise e Projeto OO com UML. Lição 3 Especificação e Modelagem de Requisitos com UML Análise e Projeto OO com UML Lição 3 Especificação e Modelagem de Requisitos com UML Prof. Fábio Bianchi Campos 1 Objetivos Gerais Apresentar as características básicas de uma especificação de requisitos;

Leia mais

Padrões de Requisitos para Especificação de Casos de Uso em Sistemas de Informação

Padrões de Requisitos para Especificação de Casos de Uso em Sistemas de Informação Padrões de Requisitos para Especificação de Casos de Uso em Sistemas de Informação Gabriela T. de Souza 1, 2, Carlo Giovano S. Pires 2 e Arnaldo Dias Belchior 1 1 Universidade de Fortaleza Av. Washington

Leia mais

Palavras-Chaves: estoque, modelagem, requisitos, UML, vendas.

Palavras-Chaves: estoque, modelagem, requisitos, UML, vendas. UTILIZAÇÃO DA UML NO DESENVOLVIMENTO DE SISTEMA DE CONTROLE DE VENDAS E ESTOQUE GILBERTO FRANCISCO PACHECO DOS SANTOS Discente da AEMS Faculdades Integradas de Três Lagoas JACKSON LUIZ ARROSTI Discente

Leia mais

Introdução a Abordagens de Identificação de Requisitos

Introdução a Abordagens de Identificação de Requisitos Introdução a Abordagens de Identificação de Requisitos Janaína Bedani Dixon Moraes jana_dixon2001@yahoo.com.br É especialista em Concepção e Gerência de Sistemas Orientado a Objeto pela UNIRON- DON. Tem

Leia mais

Diagrama de Casos de Uso. Diagrama de Casos de Uso. Diagrama de Casos de Uso. Diagrama de Casos de Uso. Componentes do Diagrama

Diagrama de Casos de Uso. Diagrama de Casos de Uso. Diagrama de Casos de Uso. Diagrama de Casos de Uso. Componentes do Diagrama DCC / ICEx / UFMG Diagrama de Diagrama de Eduardo Figueiredo http://www.dcc.ufmg.br/~figueiredo Adota uma linguagem simples Acessível ao cliente Objetivo é a compreensão do comportamento externo do sistema

Leia mais

Documentação de um Produto de Software

Documentação de um Produto de Software Documentação de um Produto de Software Versão 3.0 Autora: Profª Ana Paula Gonçalves Serra Revisor: Prof. Fernando Giorno 2005 ÍNDICE DETALHADO PREFÁCIO... 4 1. INTRODUÇÃO AO DOCUMENTO... 6 1.1. TEMA...

Leia mais

UTILIZANDO ICONIX NO DESENVOLVIMENTO DE APLICAÇÕES DELPHI

UTILIZANDO ICONIX NO DESENVOLVIMENTO DE APLICAÇÕES DELPHI UTILIZANDO ICONIX NO DESENVOLVIMENTO DE APLICAÇÕES DELPHI Dr. George SILVA; Dr. Gilbert SILVA; Gabriel GUIMARÃES; Rodrigo MEDEIROS; Tiago ROSSINI; Centro Federal de Educação Tecnológica do Rio Grande do

Leia mais

Nos artigos anteriores apresentamos. Desenvolvimento de Software Dirigido por Caso de Uso Parte III: Caso de Uso de Negócio

Nos artigos anteriores apresentamos. Desenvolvimento de Software Dirigido por Caso de Uso Parte III: Caso de Uso de Negócio Desenvolvimento de Software Dirigido por Caso de Uso Parte III: Caso de Uso de Negócio Vinicius Lourenço de Sousa vinicius.lourenco.sousa@gmail.com Atua no ramo de desenvolvimento de software há mais de

Leia mais

Unified Modeling Language

Unified Modeling Language Unified Modeling Language Modelagem de Negócios e de Sistemas com Casos de Uso Denize Terra Pimenta dpimenta@gmail.com www.analisetotal.com.br Índice 2 1 Objetivos Esta palestra é uma introdução à modelagem

Leia mais

Executive Proposal: Um Padrão para a Apresentação de Propostas de Projetos

Executive Proposal: Um Padrão para a Apresentação de Propostas de Projetos Executive Proposal: Um Padrão para a Apresentação de Propostas de Projetos Corneli Gomes Furtado Júnior 1, Thiago Ferraz 1, Rossana Maria de Castro Andrade 1 1 Departamento de Computação Universidade Federal

Leia mais

Casos de Uso. Viviane Torres da Silva viviane.silva@ic.uff.br. http://www.ic.uff.br/~viviane.silva/2012.1/es1

Casos de Uso. Viviane Torres da Silva viviane.silva@ic.uff.br. http://www.ic.uff.br/~viviane.silva/2012.1/es1 Casos de Uso Viviane Torres da Silva viviane.silva@ic.uff.br http://www.ic.uff.br/~viviane.silva/2012.1/es1 O que é? Uma técnica para capturar requisitos funcionais Descreve o sistema sob a perspectiva

Leia mais

Os casos de uso dão conta da maioria dos requisitos de um sistema computacional.

Os casos de uso dão conta da maioria dos requisitos de um sistema computacional. Unidade 3: Modelagem de requisitos e de soluções (Parte a) 1 Casos de uso 1.1 Conceitos básicos e parâmetros de descrição Os casos de uso dão conta da maioria dos requisitos de um sistema computacional.

Leia mais

Análise Orientada a Objetos Modelagem Requisitos usando Casos de Uso

Análise Orientada a Objetos Modelagem Requisitos usando Casos de Uso Análise Orientada a Objetos Modelagem Requisitos usando Casos de Uso Não diga pouco em muitas palavras, mas sim, muito em poucas. Pitágoras Especificação e Modelagem de Requisitos Regras de Negócio Glossário

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, Análise e Gestão Requisitos. Aula 06

Levantamento, Análise e Gestão Requisitos. Aula 06 Levantamento, Análise e Gestão Requisitos Aula 06 Agenda Técnicas de Levantamento de Requisitos: Entrevista Workshop, Brainstorming, Storyboarding e Roleplaying Prototipação JAD Joint Application Design

Leia mais

AGNALDO IZIDORO DE SOUZA UNIPAR agnaldo@unipar.br JAIR OTT UNIPAR jairott@gmail.com PABLO A. MICHEL UNIPAR pamichel@unipar.br

AGNALDO IZIDORO DE SOUZA UNIPAR agnaldo@unipar.br JAIR OTT UNIPAR jairott@gmail.com PABLO A. MICHEL UNIPAR pamichel@unipar.br A importância da aplicação de técnicas de gerenciamento de riscos em projetos de desenvolvimento de software: estudo de caso do sistema de controle de veículos AGNALDO IZIDORO DE SOUZA UNIPAR agnaldo@unipar.br

Leia mais

Engenharia de Software para Sistemas de Informação em Saúde

Engenharia de Software para Sistemas de Informação em Saúde Engenharia de Software para Sistemas de Informação em Saúde Renata Granato da Costa Bergamin 1, Ricardo A. Quintano Neira 2, Adriana C. Martins Mendoza Cuellas 3, Fabiane Bizinella Nardon 4 1,2,3,4, Brasil

Leia mais

Feature-Driven Development

Feature-Driven Development FDD Feature-Driven Development Descrição dos Processos Requisitos Concepção e Planejamento Mais forma que conteúdo Desenvolver um Modelo Abrangente Construir a Lista de Features Planejar por

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

Sommerville, Ian. Software Engineering. Editora: Addison Wesley. (capítulos sobre Requisitos)

Sommerville, Ian. Software Engineering. Editora: Addison Wesley. (capítulos sobre Requisitos) Sommerville, Ian. Software Engineering. Editora: Addison Wesley. (capítulos sobre Requisitos) Engenharia, Levantamento, Elicitação, Gerenciamento Fernando Pedrosa fpedrosa@gmail.com 1 2 Área da Engenharia

Leia mais

comentários post favorito (20)

comentários post favorito (20) 1 de 16 01/10/2014 21:54 comentários post favorito (20) DevMedia Curtir Anuncie Loja Publique Assine Fale conosco 33.682 pessoas curtiram DevMedia. Plug-in social do Facebook Hospedagem web por Porta 80

Leia mais

Fase 1: Engenharia de Produto

Fase 1: Engenharia de Produto Fase 1: Engenharia de Produto Disciplina: Análise de Requisitos DURAÇÃO: 44 h O objetivo principal da disciplina é realizar uma análise das necessidades e produzir um escopo do produto. Representará os

Leia mais

Casos de Uso. Viviane Torres da Silva viviane.silva@ic.uff.br. http://www.ic.uff.br/~viviane.silva/2010.1/es1

Casos de Uso. Viviane Torres da Silva viviane.silva@ic.uff.br. http://www.ic.uff.br/~viviane.silva/2010.1/es1 Casos de Uso Viviane Torres da Silva viviane.silva@ic.uff.br http://www.ic.uff.br/~viviane.silva/2010.1/es1 O que é? Uma técnica para capturar requisitos funcionais Descreve o sistema sob a perspectiva

Leia mais

ENGENHARIA DE REQUISITOS

ENGENHARIA DE REQUISITOS Universidade Federal de Santa Maria Mestrado em Computação ELC 923 Processos de Negócio e Engenharia de Requisitos Especialização em Modelagem e Desenvolvimento de Aplicações Web com JAVA ENGENHARIA DE

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

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

Engenharia de requisitos

Engenharia de requisitos Engenharia de requisitos Um Requisito é uma característica que um sistema precisa ter ou uma restrição que ele precisa satisfazer para ser aceito pelo cliente. A Engenharia de requisitos tem por objetivo

Leia mais

Modelos de processos de desenvolvimento de software

Modelos de processos de desenvolvimento de software Definição Um modelo de processo de software é uma representação abstrata de um processo. Os modelos de processo podem ser desenvolvidos a partir de várias perspectivas e podem mostrar as atividades envolvidas

Leia mais

Modelagem de Casos de Uso (Parte 2)

Modelagem de Casos de Uso (Parte 2) Modelagem de Casos de Uso (Parte 2) Roteiro (1) Método para Modelagem de Casos De Uso Estudo de Caso: Sistema de Controle para Videolocadora Levantamento Inicial dos Casos de Uso Identificação dos Casos

Leia mais

UML 2.0 - Modelo Casos de Uso

UML 2.0 - Modelo Casos de Uso UML 2.0 - Modelo Casos de Uso Márcia Ito ito@mind-tech.com.br Julho/2004 Pensamento Inicial Nada lhe posso dar que já não exista em você mesmo. Não posso abrir-lhe outro mundo de imagens, além daquele

Leia mais

Uma Ferramenta para Geração Automática de Testes Funcionais e Protótipos de Interface a partir de Casos de Uso

Uma Ferramenta para Geração Automática de Testes Funcionais e Protótipos de Interface a partir de Casos de Uso Uma Ferramenta para Geração Automática de Testes Funcionais e Protótipos de Interface a partir de Casos de Uso Ernesto C. Brasil 1, Thiago C. de Sousa 2 1 Centro de Ensino Unificado de Teresina (CEUT)

Leia mais

Modelagem de Processos. Prof.: Fernando Ascani

Modelagem de Processos. Prof.: Fernando Ascani Modelagem de Processos Prof.: Fernando Ascani Bibliografia UML Guia de consulta rápida Douglas Marcos da Silva Editora: Novatec UML Guia do usuário Grady Booch James Rumbaugh Ivair Jacobson Editora: Campus

Leia mais