AULAS 02 e 03: Noções sobre processo de desenvolvimento de software e Papéis e Responsabilidades em Projetos de Software

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

Download "AULAS 02 e 03: Noções sobre processo de desenvolvimento de software e Papéis e Responsabilidades em Projetos de Software"

Transcrição

1 AULAS 02 e 03: Noções sobre processo de desenvolvimento de software e Papéis e Responsabilidades em Projetos de Software SUMÁRIO PÁGINA Análise e Projeto de Software 1 Implementação, testes e implantação 13 Papéis e responsabilidades em projetos de software 19 Metodologias ágeis 24 Exercícios 32 Gabarito 40 Exercícios Comentados 41 Simulado 54 ANÁLISE E PROJETO DE SOFTWARE O levantamento de requisitos, a análise de requisitos e o projeto do software não são fases isoladas entre si. Ao elaborar diagramas e confeccionar documentos para buscar a melhor compreensão e entendimento dos requisitos de um sistema, já começa ali a fase de análise de requisitos. Tal imiscuidade entre fases também ocorrerá entre a análise e o projeto. O modelo de requisitos: entre a descrição do sistema e o projeto. Fonte: Pressman, de 55

2 ANÁLISE A fase de análise de requisitos, no contexto do desenvolvimento de um sistema, é aquela na qual são construídos modelos para representar o sistema a ser construído. Esta fase tem como característica não levar com conta o ambiente tecnológico a ser utilizado. Nesta atividade, o foco de interesse é tentar construir uma estratégia de solução sem se preocupar com a maneira como essa estratégia será realizada. Em resumo, a prioridade é saber o que o sistema proposto deve fazer, para, posteriormente (no projeto), definir como o sistema irá fazê-lo. A modelagem de requisitos possui duas visões clássicas: a análise estruturada e a análise orientada a objetos. A análise estruturada considera os dados e os processos que transformam os dados em entidades separadas. Esta técnica descreve o fluxo de informação e transformações que são aplicadas à medida que os dados se movimentam da entrada para a saída. O diagrama que melhor ilustra a análise estruturada é o Diagrama de Fluxo de Dados (DFD), que será visto adiante. A análise orientada a objetos, por sua vez, lança mão da abstração para representar coisas do mundo real, sob a forma de objetos. Os objetos podem ser uma entidade externa, uma coisa, uma ocorrência, um evento, uma unidade organizacional, um local, enfim, qualquer elemento que possa ser representado por um conjunto de atributos. Por exemplo, uma pessoa pode ser definida por um nome, endereço, telefone, número de CPF. Um pedido, por sua vez, pode ser definido pelo seu número, comprador, produtos, quantidade e preço total. Objetos serão exemplificados no diagrama de classes, visto adiante. PRINCIPAIS DIAGRAMAS DA FASE DE ANÁLISE Modelos baseados em cenários São os casos de usos e histórias de usuários, já detalhados na Engenharia de Requisitos. 2 de 55

3 Modelos de Fluxo A modelagem orientada a fluxos considera os dados e os processos que os transformam entidades distintas. É a representação da análise estruturada, e seu principal diagrama é o Diagrama de Fluxo de Dados, ou DFD. Em um DFD, representam-se entidades externas por caixas, processos (ou tarefas) por circunferências (também podem ser elipses ou elipses achatadas), o fluxo dos dados por setas e depósitos de dados por traços duplos. Veja abaixo: Diagrama de Fluxo de Dados: meramente ilustrativo. Diagrama de Fluxos de Dados: meramente ilustrativo. 3 de 55

4 Modelos de Comportamento Os modelos comportamentais indicam como o software irá responder a estímulos ou eventos externos. Os diagramas de estado e de sequência representam este tipo de modelo. Diagrama de estados: um exemplo. Diagrama de sequência: um exemplo. 4 de 55

5 Modelos de classe A modelagem baseada em classes representa os objetos que o sistema irá manipular, as operações (também denominada métodos ou serviços) que serão aplicados aos objetos para efetuar a manipulação, alguns relacionamentos entre os objetos e as colaborações que ocorrem entre as classes definidas. Os elementos de um modelo baseado em classes são: classes e objetos, atributos, operações, modelos CRC (classe-responsabilidade-colaborador), diagramas de colaboração e pacotes. Diagrama de classes: exemplo Como dito anteriormente, não existe uma fronteira clara entre o término da fase de análise e o início da fase de projeto. Teoricamente, ao término da análise, os requisitos estão suficientemente detalhados para que modelagens mais refinadas possam ser empregadas. 5 de 55

6 PROJETO O foco principal da análise são os aspectos lógicos e independentes de implementação de um sistema, ou seja, os requisitos. Na fase de projeto, determina-se o como o sistema funcionará, para atender aos requisitos. Os modelos de requisitos, apresentados por elementos baseados em cenários, baseados em classes, orientado a fluxos e comportamentais, alimentam a tarefa de projeto. A atividade de projeto engloba o conjunto de princípios, conceitos e práticas que conduzem ao desenvolvimento de um sistema ou produto com alta qualidade. Lembro que, lato sensu, este também é o objetivo de todo o processo de desenvolvimento de software. Para buscar a qualidade do software, o projeto deve possuir algumas características: O projeto deve implementar todos os requisitos explícitos contidos no modelo de requisitos e deve acomodar todos os requisitos implícitos desejados pelos interessados; O projeto deve ser um guia legível, compreensível para aqueles que geram código e para aqueles que testam, e, subsequentemente, dão suporte ao software; O projeto deve dar uma visão completa do software, trabalhando os domínios de dados, funcional e comportamental sob a perspectiva de implementação. Ainda, cabe destacar alguns conceitos que devem ser ponderados quando da elaboração de um projeto: Abstração: À medida que o nível de abstração migra de um nível mais alto para um nível mais baixo, a solução deixa de ser expressa na linguagem do domínio do problema para ser expressa em uma terminologia técnica. Arquitetura: Uma meta do projeto de software é derivar um quadro da arquitetura de um sistema, que representará a organização a partir da qual atividades mais detalhadas do projeto são conduzidas. 6 de 55

7 Padrões: Os padrões de projeto são soluções comprovadamente eficazes que podem ser aproveitados em projetos de problemática recorrente. Por exemplo, um sistema de vendas online provavelmente possuirá um padrão de projeto consolidado. P.S.: não confundir o aproveitamento de um padrão de projeto com o aproveitamento de código (reuso de software). Separação por interesses (por afinidades): Esse conceito afirma que qualquer problema complexo pode ser tratado mais facilmente se decomposto em trechos a ser resolvidos e ou otimizados independentemente. Esse conceito aparece em outros conceitos, como modularidade, aspectos, independência funcional e refinamento. Modularidade: Dividir um software em poucos módulos o torna fácil de integrar, mas difícil de desenvolver e manutenir. Dividir demais o torna difícil de integrar, embora o custo do módulo seja baixo. O desafio do projeto é modularizar o problema da melhor forma possível, minimizando custos. Diagrama de classes ilustrando a modularidade. Modularizar na medida certa traz uma série de benefícios ao projeto e ao software. Encapsulamento de informações: O princípio do encapsulamento diz que os módulos devem ser capazes de ocultar suas características uns dos outros, disponibilizando apenas os itens que interessam aos outros módulos. Independência funcional: A independência funcional é atingida desenvolvendo-se módulos com função única e que pouco interagem com outros módulos. É medida qualitativamente pela coesão e pelo acoplamento. Um 7 de 55

8 módulo coeso realiza poucas tarefas, interagindo o mínimo necessário com outros módulos. Quanto ao acoplamento, é desejável que ele seja fraco, ou seja, que cada módulo se comunique o mínimo possível com os demais. Refinamento: O refinamento gradual é uma estratégia top-down. Um programa é desenvolvido refinando-se níveis procedurais sucessivamente. Refatoração: Técnica de reorganização que simplifica o projeto ou código, sem mudar sua função ou comportamento. Em projetos de refabricação de software, deve-se examinar o projeto antigo, eliminar redundâncias, corrigir algoritmos eficientes ou desnecessários. Refatoração: um exemplo. Um atributo que estava mal esclarecido, nome2, agora passa a se chamar mae, explicitando a sua funcionalidade. Usando a notação, princípios e métodos adequados, o projeto produz um projeto de dados/classes, um projeto de arquitetura, um projeto de interfaces e um projeto de componentes. 8 de 55

9 Projeto de dados/classes O projeto de dados/classes transforma os modelos de classes em realizações de classes de projeto e nas estruturas de dados dos requisitos necessários para implementar o software. Projeto de dados: um exemplo. 9 de 55

10 Projeto de arquitetura O projeto arquitetural define os relacionamentos entre os principais elementos estruturais do software, os estilos arquiteturais e os padrões de projeto que podem ser usados para satisfazer os requisitos definidos para o sistema e as restrições que o afetam. Diagramas de implantação podem mostrar os componentes físicos de um sistema, assim como diagramas de componentes pode mostrar os principais componentes de um software. Diagrama de Implantação, materializando a arquitetura de um sistema Diagrama de Componentes, materializando a arquitetura de um sistema 10 de 55

11 Projeto de componentes O projeto de componentes destrincha elementos estruturais da arquitetura, em uma descrição procedural dos componentes de software. Diagrama de classes, detalhando cada componente de um software Projeto de interface de usuário Conjunto de desenhos detalhados que representa fluxos de informação que entram em saem do sistema, como o sistema de comunica com sistemas externos e com as pessoas que o utilizam. Devem ser buscadas algumas características como: Familiaridade usar termos e conceitos obtidos da experiência de pessoas que farão uso do sistema. Consistência sempre que possível, operações similares devem ser ativadas da mesma maneira. 11 de 55

12 Surpresa mínima os usuários nunca devem ser surpreendidos pelo comportamento de um sistema. Deixar o usuário no comando o usuário deve ser capaz de interromper o que está fazendo para fazer outra coisa, sem perder o trabalho já feito. Reduzir a memória do usuário o sistema deve ser capaz de guiar o usuário, não precisando ele armazenar procedimentos na memória. Projeto de interface com o usuário: um exemplo. Em resumo, o projeto de interface com o usuário será a proposta de tela, ou telas, por meio das quais os usuários do sistema realização sua interação com o mesmo. Inevitavelmente o projeto de interface com o usuário será submetido à aprovação do cliente, podendo sofrer modificações antes da codificação. 12 de 55

13 IMPLEMENTAÇÃO, TESTES E IMPLANTAÇÃO IMPLEMENTAÇÃO Na implementação, o sistema é codificado, ou seja, ocorre a tradução da descrição computacional obtida na fase de projeto em código executável, mediante o uso de uma ou mais linguagens de programação. Código de programa: ilustração Ao codificar um software, um programador poderá escrever código novo, ou reaproveitar código já existente. Esse reaproveitamento de código é chamado de reuso de software. O reuso de software pode trazer vários benefícios, como ganho de tempo (o código já está escrito), confiança, redução de risco (o código já foi utilizado com sucesso anteriormente), dentre outros fatores. Por fim, é interessante destacar que a maioria das bibliografias prevê que o teste de unidade acontece na etapa da implementação. O teste de unidade é o teste pontual, realizado pelo programador, que verifica que aquele componente 13 de 55

14 ou módulo que ele desenvolveu realmente faz o que deveria fazer, atendendo às especificações do projeto. Uma vez que o sistema esteja codificado (e com seus módulos testados, a nível unidade), os códigos desenvolvidos pelos diversos programadores é integrado, e poderá ser submetido a uma bateria maior e mais complexa de testes. TESTES Teste de software é uma atividade realizada para descobrir erros que foram produzidos inadvertidamente no momento em que o software foi projetado e construído. Pode ser planejado antecipadamente e conduzido sistematicamente. Ainda, podem ser testes de baixo nível, no qual são verificados se pequenos segmentos de código-fonte foram corretamente implementados, bem como testes de alto nível, que validam as principais funções do sistema com base nos requisitos do cliente. Estratégias de teste de software As estratégias de teste de software fornecem um roteiro que descreve os passos a serem executados como parte do teste. Em um contexto macro, o teste de software é um elemento de um aspecto mais amplo, que é frequentemente referido como Verificação e Validação (V&V). Verificação se refere ao conjunto de atividades que garante que o software implementa corretamente uma função específica (estamos construindo o produto corretamente?), enquanto a Validação se certifica que o software construído corresponde aos requisitos do cliente (estamos construindo o produto certo?). O teste proporciona o último elemento a partir do qual a qualidade pode ser estimada, e, mais pragmaticamente, os erros podem ser descobertos. Conforme afirmado desde o início, a qualidade é incorporada ao software ao longo do processo de engenharia de software. Portanto, a motivação, por trás do teste, é a confirmação da qualidade. Se a qualidade não estiver lá antes do teste, não estará lá após a realização dele. 14 de 55

15 Quanto à responsabilidade pela execução dos testes, cabe aos próprios desenvolvedores a realização dos testes de unidade e, em muitos casos, também os testes de integração. Os mais complexos, por sua vez, serão realizados por um grupo independente de teste. Este grupo também faz parte da equipe de desenvolvimento do software. Quanto à estratégia em si, a espiral da figura abaixo ilustra o processo. Estratégia de teste de software. Fonte: Pressman, Teste de unidade se concentra em cada unidade: componente, classe ou módulo. Usa intensamente técnicas de teste com caminhos distintos, com o objetivo de descobrir erros dentro do módulo testado. Teste de integração técnica sistemática para construir a arquitetura do software ao mesmo tempo que conduz testes para descobrir erros associados com as interfaces (comunicação entre os módulos, não confundir com interface com o usuário). A integração pode ocorrer de forma descendente (top-down) ou ascendente (bottom-up). Integração de módulos. No exemplo, M4 e M7 serão incorporados à arquitetura, e o sistema deverá ser testado com a presença desses dois novos módulos. 15 de 55

16 Teste de validação a validação de software é conseguida por meio de uma série de testes que demonstram conformidade com os requisitos. Um plano de testes poderá definir casos de teste específicos que atestem que os requisitos funcionais sejam satisfeitos, que os requisitos de desempenho sejam atendidos, que a documentação esteja correta, dentre outros. Desvios ou erros descobertos nesse estágio raramente podem ser corrigidos antes do prazo de entrega programado. Se um software é desenvolvido como um produto para ser usado por muitos clientes, é impraticável que todos eles realizem testes formais de aceitação. Muitos construtores de software, então, usam um processo chamado de teste alfa e beta para descobrir erros que apenas o usuário final é capaz de encontrar. O teste alfa é conduzido na instalação do desenvolvedor por um grupo representativo de usuários finais. Nele, o desenvolvedor monitora os usuários, registrando os erros e os problemas de uso. O teste beta é conduzido nas instalações dos usuários finais. Via de regra, o desenvolvedor não está presente, e os erros e problemas encontrados são reportados pelos usuários. Teste de sistema o teste de sistema extrapola os limites da engenharia de software. Uma vez validado, o software deverá ser combinado com outros elementos do sistemas (como hardware, pessoas, base de dados). Ele verifica se todos os elementos se combinam corretamente e se a função/desempenho global do sistema é conseguida. Podem ser: Teste de recuperação: força o sistema a falhar de várias formas e verifica se a recuperação é executada corretamente; Teste de segurança: verifica se os mecanismos de proteção incorporados ao sistema protegem contra acesso indevido; Teste de esforço: coloca o programa em condições anormais. Até onde podemos forçar o sistema até que ele falhe? Teste de desempenho: testar o desempenho, em tempo de execução, do software em um contexto de sistema integrado. Pode ser feito em conjunto com testes de esforço; Teste de disponibilização: exercitar o software em cada ambiente no qual ele deve operar, como em vários sistemas operacionais, vários navegadores web, ou várias plataformas (PC, smartphone...). Depuração Quando um erro é encontrado, o código deverá ser futucado para encontrar o pedaço de código que está escrito de maneira incorreta, para então ser corrigido. A esta etapa é dada o nome de depuração. Depurar o código não é testar o código, mas são processos que se relacionam. 16 de 55

17 Técnicas de teste de software Realizar testes em software é um paradoxo de raciocínio. Os desenvolvedores devem deixar de construir o software e passar a trabalhar em casos de teste para quebrá-lo. O objetivo do teste é encontrar erros, e um bom este é aquele que tem alta probabilidade de encontrar um erro. Os testes devem ter uma série de características que permitam atingir o objetivo de encontrar o maior número de erros com um mínimo de esforço. São atributos desejáveis em um teste: Alta probabilidade de encontrar erros; Não ser redundante; O melhor de uma categoria (o mais completo de um grupo similar de testes);e Nem muito simples, nem muito complexo. Vejamos algumas técnicas de teste: Caixa-Branca - Também chamada de teste estrutural ou orientado à lógica, a técnica de caixa-branca avalia o comportamento interno do componente de software. Essa técnica trabalha diretamente sobre o código fonte do componente de software para avaliar aspectos tais como: teste de condição, teste de fluxo de dados, teste de caminho básico, teste de ciclos, teste de caminhos lógicos, códigos nunca executados, teste de estrutura de controle. Os aspectos avaliados nesta técnica de teste dependerão da complexidade e da tecnologia que determinarem a construção do componente de software, cabendo portanto avaliação de mais aspectos que os citados anteriormente. O testador tem acesso ao código fonte da aplicação e pode construir códigos para efetuar a ligação de bibliotecas e componentes. Este tipo de teste é desenvolvido analisando o código fonte e elaborando casos de teste que cubram todas as possibilidades do componente de software. Dessa maneira, todas as variações relevantes originadas por estruturas de condições são testadas. A técnica de teste de caixa-branca é recomendada para as fases de teste de unidade e teste de integração, cuja responsabilidade principal fica a cargo dos desenvolvedores do software, que por sua vez conhecem bem o código fonte produzido. Caixa-Preta - Também chamada de teste funcional, teste comportamental, orientado a dado ou orientado a entrada e saída, a técnica de caixa-preta avalia o comportamento externo do componente de software, sem se considerar o comportamento interno do mesmo. Dados de entrada são fornecidos, o teste é executado e o resultado obtido é comparado a um resultado 17 de 55

18 esperado previamente conhecido. Como detalhes de implementação não são considerados, os casos de teste são todos derivados da especificação. Quanto mais entradas são fornecidas, mais rico será o teste. Numa situação ideal todas as entradas possíveis seriam testadas, mas na ampla maioria dos casos isso é impossível. Outro problema é que a especificação pode estar ambígua em relação ao sistema produzido, e como resultado as entradas especificadas podem não ser as mesmas aceitas para o teste. Uma abordagem mais realista para o teste de caixa-preta é escolher um subconjunto de entradas que maximize a riqueza do teste. Pode-se agrupar subconjuntos de entradas possíveis que são processadas similarmente, de forma que testar somente um elemento desse subconjunto serve para averiguar a qualidade de todo o subconjunto. Por exemplo, em um sistema que aceita um inteiro como entrada, testar todos os casos possíveis pode gerar pelo menos dezenas de milhares de casos de testes distintos. Entretanto, a partir da especificação do sistema, podese encontrar um subconjunto de inteiros que maximizem a qualidade do teste. Depende do propósito do sistema, mas casos possíveis incluem inteiros pares, inteiros ímpares, zero, inteiros positivos, inteiros negativos, o maior inteiro, o menor inteiro. A aplicação de técnicas de teste leva o testador a produzir um conjunto de casos de teste (ou situações de teste). A aplicação combinada de outra técnica técnica de particionamento de equivalência (ou uso de classes de equivalência) permite avaliar se a quantidade de casos de teste produzida é coerente. A partir das classes de equivalência identificadas, o testador construirá casos de teste que atuem nos limites superiores e inferiores destas classes, de forma que um número mínimo de casos de teste permita a maior cobertura de teste possível. Uma outra variação é a Análise do Valor Limite na qual são testados valores nas fronteiras de um domínio. Por exemplo: se determinado campo só permite o preenchimento com números de 1 a 100, aplicam-se nos testes os valores 0,1,100 e 101. As técnicas caixa-preta podem ser aplicadas em todos as etapas de teste, embora mais apropriadas a partir dos testes de integração até a implantação. IMPLANTAÇÃO Na implantação, o sistema é empacotado, distribuído e instalado no ambiente do usuário. Os manuais do sistema são escritos, os arquivos são carregados, os dados são importados para o sistema, e os usuários são treinados para utilizar o sistema corretamente. Dependendo da situação, pode ocorrer também a migração de sistemas de do software e de dados preexistentes. 18 de 55

19 PAPÉIS E RESPONSABILIDADES EM PROJETOS DE SOFTWARE Como você deve ter observado, o estudo do processo de desenvolvimento de software é orientado a processos, ou seja, preocupa-se com o avançar do processo em si. Para avaliar os papéis e responsabilidades em projetos de software é necessário realizar um estudo transversal, extraindo as participações dos diversos personagens ao longo do projeto de software. Vejamos: Patrocinador O patrocinador do projeto, via de regra, é alguém do alto escalão de uma organização, que compra a idéia do software. Em virtude de sua posição, é capaz de atribuir recursos e dinheiro ao projeto. Entretanto, além de financiar o projeto, os patrocinadores têm outras funções muito importantes para o sucesso dos projetos. Durante o ciclo de vida do projeto, o patrocinador atua como um decisor acima do gerente de projeto, podendo tomar decisões fora da alçada do gerente do projeto. Além disso, o patrocinador funciona como um ponto focal para a alta administração e também para outros stakeholders, eventualmente. À primeira vista, pode parecer que o patrocinador do projeto duplica os esforços do gerente de projeto. No entanto, um patrocinador do projeto experiente pode melhorar a comunicação e coordenação em questões além das responsabilidades do gerente de projeto. O papel do patrocinador está diretamente ligado à gerência sênior e inclui, mas não se limita a: Participar na seleção de projetos, categorização e priorização; Participar no estabelecimento de prioridades e alocação de recursos; Estabelecer objetivos estratégicos para o projeto; Alinhar os objetivos do projeto aos objetivos de negócio; Realizar acompanhamento e relatórios sobre o andamento do projeto para a alta administração; Auxilia a fixação da autoridade do gerente de projeto; Participa do comitê de controle de mudanças. 19 de 55

20 Em geral, patrocinadores devem ter sólidos conhecimentos de negócio e boa capacidade de comunicação. Ele irá atuar mais como um líder visionário para o projeto, enquanto o gerente de projeto irá desempenhar funções de gestão e técnica a maioria dos o tempo. Especialmente em projetos complexos de grande porte, os gerentes de projetos precisam de muita ajuda de executivos de nível sênior. Sem patrocínio, a chance de fracasso é muito grande. Sendo o patrocinador um gerente sênior, ele possui autoridade e poder para tomar decisões que trazem grande agilidade e flexibilidade aos projetos, permitindo responder a riscos mais rapidamente e controlar mudanças. Desta forma, o patrocinador assegura, de uma maneira indireta, que a alta administração apoia o projeto. Um bom patrocinador é a ligação entre o gerente de projeto e gerentes seniores e executa diferentes funções durante o ciclo de vida do projeto, promover e proteger o projeto. Durante o início de um projeto, o patrocinador deve ser responsável pelo Termo de Abertura do Projeto e seu Business Case, alinhando os objetivos do projeto à estratégia corporativa. O patrocinador irá designar um gerente para o projeto, que pode ajudar neste planejamento inicial. O planejamento do projeto será responsabilidade do gerente de projeto designado e sua equipe, mas o patrocinador deve tomar conhecimento e aprovar planos de projeto. Ao longo da execução, o patrocinador irá monitorar o progresso e status do projeto, informando à gerência sênior. O patrocinador deve ter reuniões regulares com o gerente do projeto para reforçar a confiança e obter informações atualizadas. Finalmente, é o patrocinador o responsável pelo projeto perante a organização e à alta administração. Ele deve assegurar que os benefícios do projeto estão sendo entregues. Gerente de Projetos O gerente de projetos é o responsável pela gerência ou coordenação das atividades necessárias à construção do sistema. Deve fazer o orçamento do projeto de desenvolvimento, estimar o tempo necessário para o desenvolvimento do sistema, definir qual o processo de desenvolvimento, o cronograma de execução das atividades, a equipe de desenvolvimento, os recursos de hardware e software, etc. 20 de 55

21 O monitoramento e controle das atividades realizadas também é de responsabilidade do gerente do projeto, bem como a realização dos ajustes necessários para a adequação dos recursos e gastos. O gerente deverá ser meticuloso em seus estudos, quando realizar o estudo de viabilidade, escolher a equipe de desenvolvimento e o processo de desenvolvimento de software. O gerente de projeto, por sua vez, presta contas ao patrocinador do projeto. Segundo Pressman, o gerente de projeto, ao gerenciar efetivamente o projeto de software, deve focar em 4Ps, e nessa sequência: Pessoas, Produto, Processo e Projeto. Pessoas O gerente de projeto deve ater-se a algumas práticas-chaves, como: formar a equipe, liderar sua equipe, estabelecer boa comunicação com a equipe e com os interessados no projeto. Produto O gerente de projeto também deve analisar detalhadamente os requisitos (junto com os analistas de requisitos), para estabelecer e delimitar o escopo, de modo a poder estimar recursos e prazo. Processo A equipe de software deve ser flexível ao escolher o processo de software mais adequado ao projeto e às tarefas de engenharia de software que fazem parte do modelo selecionado. Projeto É a abordagem de cuidar do projeto como um projeto em si, entendendo fatores críticos de sucesso, planejando, monitorando e controlando o projeto, por meio de métricas e ferramentas. 21 de 55

22 Área de Negócio A área de negócio é o conjunto de stakeholders que será o principal beneficiado pelo projeto de software. Cabe a ela colaborar com a elicitação de requisitos, participar dos testes finais do software, e fornecer o feedback após a sua implantação. Pode-se destacar um personagem nesse contexto, o Especialista de Domínio. O especialista do domínio interage com o analista de requisitos para levantar os requisitos do sistema. Analista de Requisitos O analista de requisitos é o profissional que precisa ter conhecimento do domínio do negócio. Ele precisa compreender tal domínio para definir os requisitos do sistema a ser desenvolvido. Analistas devem estar aptos a se comunicar com especialistas do domínio para obter conhecimento acerca dos problemas e das necessidades envolvidas na empresa que necessita do sistema. Se, por um lado, ele não precisa ser um especialista, por outro, deve ter suficiente domínio do vocabulário da área de conhecimento na qual o sistema será implantado. Preferencialmente, este nível de domínio deve ser suficiente para que o especialista de domínio não precise, a todo momento, explicar conceitos básicos da área. O analista de requisitos precisará captar as necessidades dos clientes e repassar esse entendimento aos demais desenvolvedores do sistema, fazendo uma ponte entre os profissionais da computação e os profissionais do negócio. Em suma, os analistas de requisitos realizam o levantamento e a análise de requisitos. Inclusive, enxerga-se como uma progressão natural na carreira dos analistas de requisitos a gerência de projetos, uma vez que os analistas de requisitos adquirem experiência com a participação em diversos projetos. Equipe de desenvolvimento A equipe de desenvolvimento é fortemente atuante nas fases de projeto e implementação da solução de software. Destaque para: Projetistas: avaliam as alternativas de solução do problema resultante da análise e geram a especificação de uma solução computacional detalhada. Podem ser especializados em interface, redes, bancos de dados, etc; 22 de 55

23 Arquitetos de software: especialista em elaborar a arquitetura do sistema como um todo; Programadores: codificação do sistema e testes; Equipe de sustentação A sustentação consiste no suporte e atendimento ao cliente, responsável por manter o produto. Logo, a equipe de sustentação é aquela responsável pela manutenção do sistema após a sua entrega. Via de regra, equipes de desenvolvimento de software são montadas sob medida, em virtude do talento de seus integrantes, e desfeitas após o término do projeto. Inclusive, pode ocorrer, por questões contratuais, que uma empresa diferente da que desenvolveu o sistema seja responsável por sua manutenção. A equipe de sustentação pode realizar suporte técnico e prestar consultoria aos cliente, se for o caso. A manutenção prestada por essa equipe pode ser corretiva, aquela que corrige defeitos no sistema, adaptativa, adaptando alguns aspectos do sistema, como hardware, plataforma de sistema operacional, etc, desde que não sejam muito complexas, ou evolutiva, que adiciona novas funcionalidades ao software. Destaco, ainda, que esse acréscimo de funcionalidade é pontual. Evolução significativa de software é tratada à parte, como um outro projeto de software. Dentre os integrantes da equipe de sustentação, destaca-se o analista de suporte, profissional capaz de interpretar a solicitação do cliente e analisar se o problema relatado é um defeito a ser corrigido no sistema ou não. 23 de 55

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

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

Leia mais

Processo de Desenvolvimento de Software. Unidade V Modelagem de PDS. Luiz Leão luizleao@gmail.com http://www.luizleao.com

Processo de Desenvolvimento de Software. Unidade V Modelagem de PDS. Luiz Leão luizleao@gmail.com http://www.luizleao.com Processo de Desenvolvimento de Software Luiz Leão luizleao@gmail.com http://www.luizleao.com Conteúdo Programático desta aula Modelo Cascata (Waterfall) ou TOP DOWN. Modelo Iterativo. Metodologia Ágil.

Leia mais

Desenvolvimento Ágil de Software

Desenvolvimento Ágil de Software Desenvolvimento Ágil de Software Métodos ágeis (Sommerville) As empresas operam em um ambiente global, com mudanças rápidas. Softwares fazem parte de quase todas as operações de negócios. O desenvolvimento

Leia mais

Scrum. Introdução UFRPE-DEINFO BSI-FÁBRICA DE SOFTWARE

Scrum. Introdução UFRPE-DEINFO BSI-FÁBRICA DE SOFTWARE Scrum Introdução UFRPE-DEINFO BSI-FÁBRICA DE SOFTWARE scrum Ken Schwaber - Jeff Sutherland http://www.scrumalliance.org/ Scrum Uma forma ágil de gerenciar projetos. Uma abordagem baseada em equipes autoorganizadas.

Leia mais

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

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

Leia mais

ENGENHARIA DE SOFTWARE I

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

Leia mais

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

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

Leia mais

Ideal para que tipo de empresa (equipe): pequena, média, grande? Em software onde os requisitos não são conhecidos é recomendado o uso do XP? Por quê?

Ideal para que tipo de empresa (equipe): pequena, média, grande? Em software onde os requisitos não são conhecidos é recomendado o uso do XP? Por quê? Significado de XP? Extreme Programming (Programação Extrema). Ideal para que tipo de empresa (equipe): pequena, média, grande? Pequenas e Médias. Em software onde os requisitos não são conhecidos é recomendado

Leia mais

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

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

Leia mais

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

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

Leia mais

Processos de gerenciamento de projetos em um projeto

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

Leia mais

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

Engenharia de Software II

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

Leia mais

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

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

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

Leia mais

SCRUM: UM MÉTODO ÁGIL. Cleviton Monteiro (cleviton@gmail.com)

SCRUM: UM MÉTODO ÁGIL. Cleviton Monteiro (cleviton@gmail.com) SCRUM: UM MÉTODO ÁGIL Cleviton Monteiro (cleviton@gmail.com) Roteiro Motivação Manifesto Ágil Princípios Ciclo Papeis, cerimônias, eventos, artefatos Comunicação Product Backlog Desperdício 64% das features

Leia mais

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

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

Leia mais

Engenharia de Software II

Engenharia de Software II Engenharia de Software II Aula 8 http://www.ic.uff.br/~bianca/engsoft2/ Aula 8-17/05/2006 1 Ementa Processos de desenvolvimento de software Estratégias e técnicas de teste de software (Caps. 13 e 14 do

Leia mais

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

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

Leia mais

XP extreme Programming, uma metodologia ágil para desenvolvimento de software. Equipe WEB Cercomp web@cercomp.ufg.br

XP extreme Programming, uma metodologia ágil para desenvolvimento de software. Equipe WEB Cercomp web@cercomp.ufg.br XP extreme Programming, uma metodologia ágil para desenvolvimento de software. Equipe WEB Cercomp web@cercomp.ufg.br Introdução Criada por Kent Baeck em 1996 durante o projeto Daimler Chrysler. O sucesso

Leia mais

Tópicos. Métodos Ágeis. Histórico; Valores; Métodos Ágeis x Modelos Tradicionais; Exemplo: Referências Bibliográficas.

Tópicos. Métodos Ágeis. Histórico; Valores; Métodos Ágeis x Modelos Tradicionais; Exemplo: Referências Bibliográficas. Métodos Ágeis Edes Garcia da Costa Filho edes_filho@dc.ufscar.br 1 Tópicos Histórico; Valores; Métodos Ágeis x Modelos Tradicionais; Exemplo: Extreme Programming (XP). Referências Bibliográficas. 2 Histórico

Leia mais

Capítulo 1. Extreme Programming: visão geral

Capítulo 1. Extreme Programming: visão geral Capítulo 1 Extreme Programming: visão geral Extreme Programming, ou XP, é um processo de desenvolvimento de software voltado para: Projetos cujos requisitos são vagos e mudam com freqüência; Desenvolvimento

Leia mais

Introdução a Computação

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

Leia mais

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

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

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

Leia mais

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

MASTER IN PROJECT MANAGEMENT

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

Leia mais

ISO/IEC 12207: Gerência de Configuração

ISO/IEC 12207: Gerência de Configuração ISO/IEC 12207: Gerência de Configuração Durante o processo de desenvolvimento de um software, é produzida uma grande quantidade de itens de informação que podem ser alterados durante o processo Para que

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

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

Gerenciamento da Integração (PMBoK 5ª ed.)

Gerenciamento da Integração (PMBoK 5ª ed.) Gerenciamento da Integração (PMBoK 5ª ed.) O PMBoK diz que: O gerenciamento da integração do projeto inclui os processos e as atividades necessárias para identificar, definir, combinar, unificar e coordenar

Leia mais

Gerenciamento de projetos. cynaracarvalho@yahoo.com.br

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

Leia mais

MÓDULO 9 METODOLOGIAS DE DESENVOLVIMENTO DE SISTEMAS

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

Leia mais

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

EXIN Agile Scrum Fundamentos

EXIN Agile Scrum Fundamentos Exame Simulado EXIN Agile Scrum Fundamentos Edição Fevereiro 2015 Copyright 2015 EXIN Todos os direitos reservados. Nenhuma parte desta publicação pode ser publicado, reproduzido, copiado ou armazenada

Leia mais

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

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

Leia mais

Tecnologia da Informação para EPPGG 2013. Victor Dalton

Tecnologia da Informação para EPPGG 2013. Victor Dalton Tecnologia da Informação para EPPGG 2013 Victor Dalton Edital TECNOLOGIA DA INFORMAÇÃO: 1. Noções sobre processo de desenvolvimento de software: modelos organizacionais, stakeholders, modelagem de negócio,

Leia mais

Glossário Apresenta a definição dos termos, siglas e abreviações utilizadas no contexto do projeto Citsmart.

Glossário Apresenta a definição dos termos, siglas e abreviações utilizadas no contexto do projeto Citsmart. Apresenta a definição dos termos, siglas e abreviações utilizadas no contexto do projeto Citsmart. Versão 1.6 15/08/2013 Visão Resumida Data Criação 15/08/2013 Versão Documento 1.6 Projeto Responsáveis

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

GARANTIA DA QUALIDADE DE SOFTWARE

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

Leia mais

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

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

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

Leia mais

Sistemas de Informação I

Sistemas de Informação I + Sistemas de Informação I Processo de software I Ricardo de Sousa Britto rbritto@ufpi.edu.br + O que é Engenharia de Software n Definição dada pela IEEE [IEE93]: n Aplicação de uma abordagem sistemática,

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

Após completar este módulo você deverá ter absorvido o seguinte conhecimento: Uma ampla visão do framework Scrum e suas peculiaridades

Após completar este módulo você deverá ter absorvido o seguinte conhecimento: Uma ampla visão do framework Scrum e suas peculiaridades Objetivos da Aula 1 Após completar este módulo você deverá ter absorvido o seguinte conhecimento: Uma ampla visão do framework Scrum e suas peculiaridades Entendimento sobre os processos essenciais do

Leia mais

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

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

Leia mais

Metodologia de Gerenciamento de Projetos da Justiça Federal

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

Leia mais

CHECK - LIST - ISO 9001:2000

CHECK - LIST - ISO 9001:2000 REQUISITOS ISO 9001: 2000 SIM NÃO 1.2 APLICAÇÃO A organização identificou as exclusões de itens da norma no seu manual da qualidade? As exclusões são relacionadas somente aos requisitos da sessão 7 da

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

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

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

Leia mais

Engenharia de Software II

Engenharia de Software II Engenharia de Software II Aula 14 Revisão http://www.ic.uff.br/~bianca/engsoft2/ Aula 14-07/05/2006 1 Processo de Software Qual é a diferença entre uma atividade de arcabouço e uma atividade guarda chuva?

Leia mais

Fundamentos em Teste de Software. Vinicius V. Pessoni viniciuspessoni@gmail.com

Fundamentos em Teste de Software. Vinicius V. Pessoni viniciuspessoni@gmail.com Fundamentos em Teste de Software Vinicius V. Pessoni viniciuspessoni@gmail.com Objetivos do treinamento 1. Expor os fundamentos de Teste de Software; 2. Conceituar os Níveis de Teste; 3. Detalhar sobre

Leia mais

Professor: Curso: Disciplina:

Professor: Curso: Disciplina: Professor: Curso: Disciplina: Aula 1 Turma: Esp. Marcos Morais de Sousa Sistemas de informação Engenharia de Software I Dinâmica da disciplina, plano de curso e avaliação 03º semestre Prof. Esp. Marcos

Leia mais

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

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

Leia mais

Práticas de. Engenharia de Software. Givanaldo Rocha de Souza givanaldo.rocha@ifrn.edu.br http://docente.ifrn.edu.

Práticas de. Engenharia de Software. Givanaldo Rocha de Souza givanaldo.rocha@ifrn.edu.br http://docente.ifrn.edu. "Antes de imprimir pense em sua responsabilidade e compromisso com o MEIO AMBIENTE." Engenharia de Software Práticas de Engenharia de Software Givanaldo Rocha de Souza givanaldo.rocha@ifrn.edu.br http://docente.ifrn.edu.br/givanaldorocha

Leia mais

Manifesto Ágil - Princípios

Manifesto Ágil - Princípios Manifesto Ágil - Princípios Indivíduos e interações são mais importantes que processos e ferramentas. Software funcionando é mais importante do que documentação completa e detalhada. Colaboração com o

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

A Disciplina Gerência de Projetos

A Disciplina Gerência de Projetos A Disciplina Gerência de Projetos Atividades, Artefatos e Responsabilidades hermano@cin.ufpe.br Objetivos Apresentar atividades da disciplina Gerência de Projetos Discutir os artefatos e responsáveis envolvidos

Leia mais

3 Qualidade de Software

3 Qualidade de Software 3 Qualidade de Software Este capítulo tem como objetivo esclarecer conceitos relacionados à qualidade de software; conceitos estes muito importantes para o entendimento do presente trabalho, cujo objetivo

Leia mais

Engenharia de Software. Apostila I >>> Introdução à ES - HEngholmJr

Engenharia de Software. Apostila I >>> Introdução à ES - HEngholmJr Engenharia de Software Apostila I >>> Introdução à ES - HEngholmJr Histórico de Revisões Data Versão Descrição Autor 12/08/2014 1.0 Criação da primeira versão HEngholmJr Agenda Introdução à Engenharia

Leia mais

Conteúdo. Disciplina: INF 02810 Engenharia de Software. Monalessa Perini Barcellos

Conteúdo. Disciplina: INF 02810 Engenharia de Software. Monalessa Perini Barcellos Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Disciplina: INF 02810 Prof.: (monalessa@inf.ufes.br) Conteúdo 1. Introdução 2. Processo de Software 3. Gerência de

Leia mais

Testes de Software. Testes de Software. Teste de Validação. Teste de Defeito. Modelo de Entrada e Saída. Modelo de Entrada e Saída

Testes de Software. Testes de Software. Teste de Validação. Teste de Defeito. Modelo de Entrada e Saída. Modelo de Entrada e Saída DCC / ICEx / UFMG Testes de Software Testes de Software Eduardo Figueiredo http://www.dcc.ufmg.br/~figueiredo Teste de software buscam por erros ou anomalias em requisitos funcionais e não funcionais Classificação

Leia mais

Tecnologia em Gestão Pública Desenvolvimento de Projetos - Aula 9 Prof. Rafael Roesler

Tecnologia em Gestão Pública Desenvolvimento de Projetos - Aula 9 Prof. Rafael Roesler Tecnologia em Gestão Pública Desenvolvimento de Projetos - Aula 9 Prof. Rafael Roesler Introdução Objetivos da Gestão dos Custos Processos da Gerência de Custos Planejamento dos recursos Estimativa dos

Leia mais

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

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

Leia mais

natureza do projeto e da aplicação métodos e ferramentas a serem usados controles e produtos que precisam ser entregues

natureza do projeto e da aplicação métodos e ferramentas a serem usados controles e produtos que precisam ser entregues Modelo De Desenvolvimento De Software É uma representação abstrata do processo de desenvolvimento que define como as etapas relativas ao desenvolvimento de software serão conduzidas e interrelacionadas

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

Manifesto Ágil e as Metodologias Ágeis (XP e SCRUM)

Manifesto Ágil e as Metodologias Ágeis (XP e SCRUM) Programação Extrema Manifesto Ágil e as Metodologias Ágeis (XP e SCRUM) Prof. Mauro Lopes Programação Extrema Prof. Mauro Lopes 1-31 45 Manifesto Ágil Formação da Aliança Ágil Manifesto Ágil: Propósito

Leia mais

F.1 Gerenciamento da integração do projeto

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

Leia mais

UNIP Ciência da Computação / Sistemas de Informação TED I - Orientações Gerais para Elaboração dos Documentos

UNIP Ciência da Computação / Sistemas de Informação TED I - Orientações Gerais para Elaboração dos Documentos I - Orientações Gerais para Elaboração dos Documentos A seguir, orientações fundamentais para a elaboração dos documentos do projeto, tendo em vista a complexidade inerente neste processo. Este roteiro

Leia mais

Gerenciamento de Riscos do Projeto Eventos Adversos

Gerenciamento de Riscos do Projeto Eventos Adversos Gerenciamento de Riscos do Projeto Eventos Adversos 11. Gerenciamento de riscos do projeto PMBOK 2000 PMBOK 2004 11.1 Planejamento de gerenciamento de riscos 11.1 Planejamento de gerenciamento de riscos

Leia mais

Com metodologias de desenvolvimento

Com metodologias de desenvolvimento Sociedade demanda grande quantidade de sistemas/aplicações software complexo, sistemas distribuídos, heterogêneos requisitos mutantes (todo ano, todo mês, todo dia) Mas, infelizmente, não há gente suficiente

Leia mais

SIMULADO: Simulado 3 - ITIL Foundation v3-40 Perguntas em Português

SIMULADO: Simulado 3 - ITIL Foundation v3-40 Perguntas em Português 1 de 7 28/10/2012 16:47 SIMULADO: Simulado 3 - ITIL Foundation v3-40 Perguntas em Português RESULTADO DO SIMULADO Total de questões: 40 Pontos: 0 Score: 0 % Tempo restante: 55:07 min Resultado: Você precisa

Leia mais

Universidade Paulista

Universidade Paulista Universidade Paulista Ciência da Computação Sistemas de Informação Gestão da Qualidade Principais pontos da NBR ISO/IEC 12207 - Tecnologia da Informação Processos de ciclo de vida de software Sergio Petersen

Leia mais

Conteúdo. Disciplina: INF 02810 Engenharia de Software. Monalessa Perini Barcellos

Conteúdo. Disciplina: INF 02810 Engenharia de Software. Monalessa Perini Barcellos Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Disciplina: INF 02810 Prof.: (monalessa@inf.ufes.br) Conteúdo 1. Introdução 2. Processo de Software 3. Gerência de

Leia mais

Exame de Fundamentos da ITIL

Exame de Fundamentos da ITIL Exame de Fundamentos da ITIL Simulado B, versão 5.1 Múltipla escolha Instruções 1. Todas as 40 perguntas devem ser respondidas. 2. Todas as respostas devem ser assinaladas na grade de respostas fornecida.

Leia mais

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

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

Leia mais

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

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

Leia mais

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: 10 DATA: / / PROFESSOR: Andrey APRESENTAÇÃO O objetivo desta aula é apresentar e discutir os conceitos de coesão e acoplamento. DESENVOLVIMENTO Projetar

Leia mais

Planejamento - 7. Planejamento do Gerenciamento do Risco Identificação dos riscos. Mauricio Lyra, PMP

Planejamento - 7. Planejamento do Gerenciamento do Risco Identificação dos riscos. Mauricio Lyra, PMP Planejamento - 7 Planejamento do Gerenciamento do Risco Identificação dos riscos 1 O que é risco? Evento que representa uma ameaça ou uma oportunidade em potencial Plano de gerenciamento do risco Especifica

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

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

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

Leia mais

Atividades da Engenharia de Software ATIVIDADES DE APOIO. Atividades da Engenharia de Software. Atividades da Engenharia de Software

Atividades da Engenharia de Software ATIVIDADES DE APOIO. Atividades da Engenharia de Software. Atividades da Engenharia de Software Módulo 1 SCE186-ENGENHARIA DE SOFTWARE Profª Rosely Sanches rsanches@icmc.usp.br CONSTRUÇÃO Planejamento do Codificação Teste MANUTENÇÃO Modificação 2003 2 Planejamento do Gerenciamento CONSTRUÇÃO de Codificação

Leia mais

Introdução ao OpenUP (Open Unified Process)

Introdução ao OpenUP (Open Unified Process) Introdução ao OpenUP (Open Unified Process) Diferentes projetos têm diferentes necessidades de processos. Fatores típicos ditam as necessidades de um processo mais formal ou ágil, como o tamanho da equipe

Leia mais

Por que sua organização deve implementar a ABR - Auditoria Baseada em Riscos

Por que sua organização deve implementar a ABR - Auditoria Baseada em Riscos Março de 2010 UM NOVO PARADIGMA PARA AS AUDITORIAS INTERNAS Por que sua organização deve implementar a ABR - Auditoria Baseada em Riscos por Francesco De Cicco 1 O foco do trabalho dos auditores internos

Leia mais

Nome: Login: CA: Cidade: UF CARTÃO RESPOSTA QUESTÃO RESPOSTA QUESTÃO RESPOSTA

Nome: Login: CA: Cidade: UF CARTÃO RESPOSTA QUESTÃO RESPOSTA QUESTÃO RESPOSTA ANÁLISE E DESENVOLVIMENTO DE SISTEMAS TURMA 2008 3º PERÍODO - 5º MÓDULO AVALIAÇÃO A4 DATA 23/04/2009 ENGENHARIA DE SOFTWARE Dados de identificação do Acadêmico: Nome: Login: CA: Cidade: UF CARTÃO RESPOSTA

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

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

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

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

Leia mais

Engenharia de Software III

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

Leia mais

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

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

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

Leia mais