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

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

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

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

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

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

Processo de Desenvolvimento Unificado

Processo de Desenvolvimento Unificado Processo de Desenvolvimento Unificado Processo de Desenvolvimento de Software? Conjunto de atividades bem definidas; com responsáveis; com artefatos de entrada e saída; com dependências entre as mesmas

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

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

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

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

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. 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

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

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

! ! #  # $ ! $ %& % !"#"$! %& 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

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

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

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

DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Processo Unificado e Desenvolvimento Ágil. Profª Esp.: Maysa de Moura Gonzaga

DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Processo Unificado e Desenvolvimento Ágil. Profª Esp.: Maysa de Moura Gonzaga DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Processo Unificado e Desenvolvimento Ágil Profª Esp.: Maysa de Moura Gonzaga 2º Semestre / 2011 O Processo Unificado dos autores Ivar Jacobson, Grady Booch e James

Leia mais

Requisitos para Gestão de Requisitos no Desenvolvimento de Software que Utilizam Prática Ágeis

Requisitos para Gestão de Requisitos no Desenvolvimento de Software que Utilizam Prática Ágeis Requisitos para Gestão de Requisitos no Desenvolvimento de Software que Utilizam Prática Ágeis Abstract. Resumo. 1. Introdução Vinicius A. C. de Abreu 1 Departamento de Ciência da Computação - DCC Universidade

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

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

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

! 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

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

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

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

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

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

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

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

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

Metodologias Ágeis. Aécio Costa

Metodologias Ágeis. Aécio Costa Metodologias Ágeis Aécio Costa Metodologias Ágeis Problema: Processo de desenvolvimento de Software Imprevisível e complicado. Empírico: Aceita imprevisibilidade, porém tem mecanismos de ação corretiva.

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

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

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

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

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

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

Pós Graduação Engenharia de Software

Pós Graduação Engenharia de Software Pós Graduação Engenharia de Software Ana Candida Natali COPPE/UFRJ Programa de Engenharia de Sistemas e Computação FAPEC / FAT Estrutura do Módulo Parte 1 QUALIDADE DE SOFTWARE PROCESSO Introdução: desenvolvimento

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

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

JAD. Joint Application Design. NOME: Edgar Masayuki Saito R.A. 0610125 UNIVERSIDADE SÃO FRANCISCO USF CENTRO DE CIÊNCIAS JURÍDICAS, HUMANAS E SOCIAIS

JAD. Joint Application Design. NOME: Edgar Masayuki Saito R.A. 0610125 UNIVERSIDADE SÃO FRANCISCO USF CENTRO DE CIÊNCIAS JURÍDICAS, HUMANAS E SOCIAIS UNIVERSIDADE SÃO FRANCISCO USF CENTRO DE CIÊNCIAS JURÍDICAS, HUMANAS E SOCIAIS JAD Joint Application Design Curso: Administração habilitação em Sistemas de Informações Disciplina: Análise de Sistemas II

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

Engenharia de Software

Engenharia de Software Engenharia de Software Conceitos e Metodologias para Desenvolvimento de Software Cascata, Prototipação, Espiral e RUP Prof. MSc. Edilberto Silva prof.edilberto.silva@gmail.com http://www.edilms.eti.br

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

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

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

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

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

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

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

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

Engenharia de Software II: Criando a Declaração de Escopo. Prof. Msc Ricardo Britto DIE-UFPI rbritto@ufpi.edu.br

Engenharia de Software II: Criando a Declaração de Escopo. Prof. Msc Ricardo Britto DIE-UFPI rbritto@ufpi.edu.br Engenharia de Software II: Criando a Declaração de Escopo Prof. Msc Ricardo Britto DIE-UFPI rbritto@ufpi.edu.br Sumário Desenvolvendo o Plano de Gerenciamento do Projeto. Coletando Requisitos. Declarando

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

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

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

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

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 06 PROFª BRUNO CALEGARO UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 06 PROFª BRUNO CALEGARO Santa Maria, 27 de Setembro de 2013. Revisão aula anterior Desenvolvimento Ágil de Software Desenvolvimento e entrega

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

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

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

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

UNIVERSIDADE FEDERAL DO RIO GRANDE TECNOLOGIA EM ANALISE E DESENVOLVIMENTO DE SISTEMAS

UNIVERSIDADE FEDERAL DO RIO GRANDE TECNOLOGIA EM ANALISE E DESENVOLVIMENTO DE SISTEMAS UNIVERSIDADE FEDERAL DO RIO GRANDE TECNOLOGIA EM ANALISE E DESENVOLVIMENTO DE SISTEMAS Professor: Adriel Ziesemer Disciplina: Engenharia de Software TRABALHO ACADÊMICO Cristian Santos - nº 45671 Guilherme

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

Processos de Software

Processos de Software Processos de Software Prof. Márcio Lopes Cornélio Slides originais elaborados por Ian Sommerville O autor permite o uso e a modificação dos slides para fins didáticos O processo de Um conjunto estruturado

Leia mais

Autoria:Aristófanes Corrêa Silva Adaptação: Alexandre César M de Oliveira

Autoria:Aristófanes Corrêa Silva Adaptação: Alexandre César M de Oliveira Unified Modeling Language (UML) Universidade Federal do Maranhão UFMA Pós Graduação de Engenharia de Eletricidade Grupo de Computação Assunto: Introdução Autoria:Aristófanes Corrêa Silva Adaptação: Alexandre

Leia mais

DSI é o processo cujo objetivo é introduzir mudanças num sistema de informação, com objetivo de melhorar o seu desempenho.

DSI é o processo cujo objetivo é introduzir mudanças num sistema de informação, com objetivo de melhorar o seu desempenho. - DSI DSI é o processo cujo objetivo é introduzir mudanças num sistema de informação, com objetivo de melhorar o seu desempenho. Preocupação: Problema técnicos Mudança na natureza e conteúdo do trabalho

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

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

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

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

Introdução ao RUP Rational Unified Process. por Denize Terra Pimenta Outubro/2004

Introdução ao RUP Rational Unified Process. por Denize Terra Pimenta Outubro/2004 Introdução ao RUP Rational Unified Process por Denize Terra Pimenta Outubro/2004 1 Contexto Não é suficiente apenas a presença de desenvolvedores altamente treinados: Precisamos de uma linguagem para a

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

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

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

UNIVERSIDADE DO ESTADO DE SANTA CATARINA - UDESC DCC Departamento de Ciência da Computação Joinville-SC

UNIVERSIDADE DO ESTADO DE SANTA CATARINA - UDESC DCC Departamento de Ciência da Computação Joinville-SC CURSO: Bacharelado em Ciência da Computação DISCIPLINA: ANPS Análise e Projeto de Sistemas AULA NÚMERO: 3 DATA: PROFESSOR: Murakami Sumário 1 APRESENTAÇÃO...1 2 DESENVOLVIMENTO...1 2.1 Revisão...1 2.1.1

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

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

DOMAIN-DRIVEN DESIGN E TEST-DRIVEN DEVELOPMENT

DOMAIN-DRIVEN DESIGN E TEST-DRIVEN DEVELOPMENT DOMAIN-DRIVEN DESIGN E TEST-DRIVEN DEVELOPMENT Jaqueline Rissá Franco email: jaquerifr@gmail.com Karla Marturelli Mattos Luciano Mathias Doll João Almeida Resumo: Este artigo mostra novas abordagens na

Leia mais

CMMI Conceitos básicos. CMMI Representações contínua e por estágios. Professor Gledson Pompeu (gledson.pompeu@gmail.com)

CMMI Conceitos básicos. CMMI Representações contínua e por estágios. Professor Gledson Pompeu (gledson.pompeu@gmail.com) CMMI Conceitos básicos 113 CMMI integra as disciplinas de engenharia de sistemas e de engenharia de software em um único framework de melhoria de processos. 114 No tocante às disciplinas de engenharia

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

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

fagury.com.br. PMBoK 2004

fagury.com.br. PMBoK 2004 Este material é distribuído por Thiago Fagury através de uma licença Creative Commons 2.5. É permitido o uso e atribuição para fim nãocomercial. É vedada a criação de obras derivadas sem comunicação prévia

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

Aplicação da ISO/IEC TR 15504 na Melhoria do Processo de Desenvolvimento de Software de uma Pequena Empresa

Aplicação da ISO/IEC TR 15504 na Melhoria do Processo de Desenvolvimento de Software de uma Pequena Empresa Aplicação da ISO/IEC TR 15504 na Melhoria do Processo de Desenvolvimento de Software de uma Pequena Empresa Odair Jacinto da Silva 1, Carlos Alberto Borges 1, Clênio Sampaio Salviano 2, Adalberto N. Crespo

Leia mais

Projeto de Arquitetura

Projeto de Arquitetura Projeto de Arquitetura Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 11 Slide 1 Objetivos Apresentar projeto de arquitetura e discutir sua importância Explicar as decisões de projeto

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

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

Objetivos. Processos de Software. Tópicos abordados. O processo de software. Modelos genéricos de modelos de processo de software.

Objetivos. Processos de Software. Tópicos abordados. O processo de software. Modelos genéricos de modelos de processo de software. Processos de Software Objetivos Apresentar os modelos de processo de software Conjunto coerente de atividades para especificar, projetar, implementar e testar s de software Descrever os diferentes modelos

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

Borland: Informatizando TI. João Carlos Bolonha jbolonha@borland.com

Borland: Informatizando TI. João Carlos Bolonha jbolonha@borland.com Borland: Informatizando TI João Carlos Bolonha jbolonha@borland.com Software Diferentes Níveis Extrair o Máximo Valor para o Negócio Eficiência Vantagem Competitiva Copyright 2007 Borland Software Corporation.

Leia mais

Aula Nº 13 Fechamento do projeto

Aula Nº 13 Fechamento do projeto Aula Nº 13 Fechamento do projeto Objetivos da Aula: Os objetivos desta aula visam apresentar como se encerra o ciclo de vida de um projeto. Para tal, pretende-se verificar as derradeiras providências que

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

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

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

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

Proposta de um método para auditoria de projetos de desenvolvimento de software iterativo e incremental

Proposta de um método para auditoria de projetos de desenvolvimento de software iterativo e incremental Proposta de um método para auditoria de projetos de desenvolvimento de software iterativo e incremental Francisco Xavier Freire Neto 1 ; Aristides Novelli Filho 2 Centro Estadual de Educação Tecnológica

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 SOFTWARE/ SISTEMAS DE SOFTWARE

ENGENHARIA DE SOFTWARE/ SISTEMAS DE SOFTWARE ENGENHARIA DE SOFTWARE/ SISTEMAS DE SOFTWARE CMP1280/CMP1250 Prof. Me. Fábio Assunção Introdução à Engenharia de Software SOFTWARE Programa de computador acompanhado dos dados de documentação e configuração

Leia mais