MANUAL TÉCNICO PARA METODOLOGIA DE DESENVOLVIMENTO DE SOFTWARE DO EXÉRCITO

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

Download "MANUAL TÉCNICO PARA METODOLOGIA DE DESENVOLVIMENTO DE SOFTWARE DO EXÉRCITO"

Transcrição

1 MINISTÉRIO DA DEFESA EXÉRCITO BRASILEIRO DEPARTAMENTO DE CIÊNCIA E TECNOLOGIA MANUAL TÉCNICO PARA METODOLOGIA DE DESENVOLVIMENTO DE SOFTWARE DO EXÉRCITO 1ª Edição 2012

2 MINISTÉRIO DA DEFESA EXÉRCITO BRASILEIRO CENTRO DE DESENVOLVIMENTO DE SISTEMAS MANUAL TÉCNICO PARA METODOLOGIA DE DESENVOLVIMENTO DE SOFTWARE DO EXÉRCITO 1ª Edição 2012

3 Separata do Boletim do Exército nº 17, 26 de abril de 2013.

4 FOLHA DE REGISTRO DE MODIFICAÇÕES NÚMERO DE ORDEM ATO DE APROVAÇÃO PÁGINAS AFETADAS DATA

5 ÍNDICE DE ASSUNTOS CAPÍTULO I DAS DISPOSIÇÕES PRELIMINARES 1. INTRODUÇÃO FINALIDADE OBJETIVOS PAPÉIS E RESPONSABILIDADES Cliente Gerente de Projeto Analista de Sistemas Arquiteto Projetista Desenvolvedor Administrador de Banco de Dados Testador Projetista de Infraestrutura MODELO DE DESENVOLVIMENTO DE SOFTWARE CAPÍTULO II DAS FASES DO PROJETO 1. FASES DO PROJETO FASE DE INICIAÇÃO FASE DE ELABORAÇÃO FASE DE CONSTRUÇÃO FASE DE TRANSIÇÃO CAPÍTULO III DAS DISPOSIÇÕES FINAIS 1. PRODUTOS DE TRABALHO PLANO DE PROJETO PLANO DE ITERAÇÃO RELATÓRIO DE AVALIAÇÃO DA ITERAÇÃO VISÃO GLOSSÁRIO MODELO DE CASO DE USO ESPECIFICAÇÕES SUPLEMENTARES LISTA DE REGRAS DE NEGÓCIO LISTA DE REQUISITOS FUNCIONAIS CASO DE USO DETALHADO DOCUMENTO DE ARQUITETURA TERMO DE HOMOLOGAÇÃO CÓDIGO FONTE BUILD (CONSTRUÇÃO) MODELO DE DESIGN...3-7

6 1.16 MODELO DE DADOS CASO DE TESTE REGISTRO DE TESTE PLANO DE IMPLANTAÇÃO MANUAL DO USUÁRIO MANUAL DO SISTEMA MANUAL DE TREINAMENTO RELATÓRIOS DA INFRAESTRUTURA TERMO DE ENCERRAMENTO DO PROJETO DIAGRAMAS DA UML UTILIZAÇÃO DE OUTRAS METODOLOGIAS ANEXOS: ANEXO A MODELO DE PLANO DE ITERAÇÃO ANEXO B MODELO DE RELATÓRIO DE AVALIAÇÃO DA ITERAÇÃO ANEXO C MODELO DE VISÃO DO PROJETO ANEXO D MODELO DE GLOSSÁRIO ANEXO E MODELO DE CASO DE USO ANEXO F MODELO DE ESPECIFICAÇÕES SUPLEMENTARES ANEXO G MODELO DE REGRAS DE NEGÓCIO ANEXO H MODELO DE LISTA DE REQUISITOS ANEXO I MODELO DE CASO DE USO DETALHADO ANEXO J MODELO DE DOCUMENTO DE ARQUITETURA ANEXO K MODELO DE TERMO DE HOMOLOGAÇÃO ANEXO L MODELO DE DESIGN ANEXO M MODELO DE CASO DE TESTE ANEXO N MODELO DE PLANO DE IMPLANTAÇÃO ANEXO O MODELO DE TERMO DE ENCERRAMENTO DE PROJETO GLOSSÁRIO... 1 REFERÊNCIAS... 4

7 CAPÍTULO I DAS DISPOSIÇÕES PRELIMINARES 1. INTRODUÇÃO O ciclo de vida de um software, de acordo com as Instruções Gerais (IG) do Ciclo de Vida de Software do Exército, compreende os seguintes processos: aquisição, fornecimento, desenvolvimento, produção e manutenção. O processo de desenvolvimento contém as atividades e tarefas do desenvolvedor, o qual, ainda de acordo com essas normas, contém as atividades para análise de requisitos, projeto, codificação, integração, testes, instalação e aceitação relacionadas aos produtos de software. Essas atividades foram detalhadas e, em alguns casos, fracionadas para comporem o processo de desenvolvimento de software apresentado neste documento. A existência de processos definidos é necessária para a maturidade das organizações que produzem software. Com a padronização dos seus processos, a organização poderá ter sua forma de trabalho reprodutível. Isso facilita as operações e torna a organização menos dependente da atuação individual das pessoas. Porém, não basta que os processos estejam definidos, mas que eles sejam aderentes à realidade da organização. Pretende-se que este documento seja um roteiro que padronize os processos de desenvolvimento de software, que deverá ser utilizado e avaliado por desenvolvedores, no âmbito do Exército. O mesmo possui caráter dinâmico, para que seja periodicamente revisado e aperfeiçoado, de forma a refletir as melhores práticas, adequadas à realidade e características do Exército, para a obtenção de sistemas de informação de qualidade. Separata do Boletim do Exército nº 17, 26 de abril de

8 A metodologia ora apresentada toma por base os processos e boas práticas do Rational Unified Process (RUP), que se trata de metodologia consolidada, descrita na literatura de engenharia de software, além de amplamente utilizada pelos desenvolvedores de software. Porém, não se exclui a inclusão e utilização de práticas advindas de outras metodologias, no processo de revisão e aperfeiçoamento deste trabalho. Vale ressaltar que, seja qual for o processo utilizado, o proposto por esta MDS ou outro adotado pela Organização Militar (OM), o desenvolvimento de um software deve ser documentado, para que seja possível sua futura manutenção. Ao final deste documento, consta uma relação de documentos mínimos que devem ser gerados em um projeto de desenvolvimento de software. 2. FINALIDADE Esta Metodologia de Desenvolvimento de Sistemas (MDS) visa descrever e padronizar os processos para o desenvolvimento de sistemas no âmbito do Centro de Desenvolvimento de Sistemas (CDS) e, posteriormente, servir como orientação às demais Organizações Militares do Exército. 3. OBJETIVOS a. Definir os papéis e responsabilidades dentro do processo de desenvolvimento de sistemas; b. Descrever o fluxo de atividades a serem desenvolvidas para o desenvolvimento de sistemas; c. Definir os produtos de trabalho gerados durante o processo de desenvolvimento de sistemas; e d. Padronizar os documentos gerados durante o processo de desenvolvimento de sistemas. Separata do Boletim do Exército nº 17, 26 de abril de

9 4. PAPÉIS E RESPONSABILIDADES Um papel define o comportamento e responsabilidades de um profissional ou grupo de profissionais que participam do desenvolvimento do projeto. O comportamento é representado através das atividades que cada papel deve desempenhar ao longo do projeto. As responsabilidades normalmente estão associadas aos produtos de trabalho que cada papel deve produzir, modificar ou controlar ao longo das atividades que realiza. Na prática, um mesmo papel pode ser desempenhado por mais de uma pessoa ao longo do projeto. Os principais papéis levantados nesta MDS são os que se seguem: 4.1 Cliente Representa as pessoas que conhecem ou utilizam o processo para o qual o sistema será desenvolvido. É responsável por fornecer as informações que permitam o levantamento dos requisitos do sistema, validar os produtos gerados no processo, bem como receber o sistema desenvolvido. Este papel: Informa os requisitos do sistema Homologa os produtos do projeto Testa o sistema desenvolvido Dá o aceite final ao produto desenvolvido 4.2 Gerente de Projeto Conduz o planejamento do projeto, coordena as interações com os Clientes e mantém a equipe de projeto focada em alcançar os objetivos do projeto. Este papel: Separata do Boletim do Exército nº 17, 26 de abril de

10 Planeja, coordena e controla o andamento das atividades do projeto Instrui a equipe para conduzir um resultado de êxito no projeto e aceitação do produto pelo cliente. É responsável pelo resultado do projeto e pela aceitação do produto pelo cliente. É responsável pela avaliação dos riscos do projeto e pelo controle destes riscos através de estratégias de atenuação. Aplica conhecimentos, habilidades, ferramentas e técnicas de gestão em uma grande quantidade de tarefas a fim entregar o resultado desejado para o projeto dentro dos prazos estabelecidos, recursos planejados e com os padrões de qualidade estabelecidos. 4.3 Analista de Sistemas Responsável por capturar as regras de negócio e os requisitos do sistema a ser desenvolvido, analisá-los e especificá-los por meio de linguagem de modelagem apropriada. Elabora e mantém um conjunto de documentos que descrevem os requisitos a serem atendidos pelo sistema. Este papel: Efetua o levantamento e documentação de informações, junto ao cliente e demais interessados, para a geração dos produtos que especificam os requisitos do sistema, considerando ainda aspectos do ambiente de produção, tais como: necessidade de processamento, armazenamento de dados, largura de banda e tipos de informação que trafegarão pela rede de comunicações. Elabora os documentos do projeto sob sua responsabilidade, conforme os prazos estabelecidos e em conformidade com a Metodologia de Desenvolvimento de Sistemas. Separata do Boletim do Exército nº 17, 26 de abril de

11 Valida junto ao cliente e gerente de projetos todos os documentos de requisitos gerados sob sua responsabilidade 4.4 Arquiteto Define a arquitetura dos elementos do software. Coordena o desenho técnico do projeto junto ao projetista. Este papel: Identifica e documenta os aspectos arquiteturalmente significativos do sistema como visões que descrevem requisitos, design, implementação e distribuição. Reduz os riscos técnicos e assegura que as decisões sejam eficazmente comunicadas, validadas e seguidas. Trabalha junto ao Gerente de Projeto na alocação da equipe e no planejamento do projeto. 4.5 Projetista Desenvolve o design de forma que ele atenda a arquitetura e a prototipagem da interface de usuário. Este papel: Define e cria soluções técnicas de acordo com a tecnologia utilizada no projeto. Compreende a arquitetura. Comunica o design, por meio de modelos, de forma que os outros membros da equipe o compreendam. Separata do Boletim do Exército nº 17, 26 de abril de

12 4.6 Desenvolvedor Implementa e integra os componentes que são parte da solução e, também, executa testes de unidade. Este papel: Transforma o design em código, implementa a estrutura do sistema na linguagem fonte escolhida. Implementa o comportamento do sistema definido nos requisitos funcionais. Escreve o código que permita às diferentes partes da aplicação (classes ou componentes) colaborarem para a realização do comportamento do sistema. Identifica e constrói os testes de desenvolvedor que verificam o comportamento desejado dos componentes técnicos. Integra e constrói o incremento da solução na qual esteja trabalhando. 4.7 Administrador de Banco de Dados Define tabelas, índices, visões, restrições, triggers, procedimentos armazenados, parâmetros de armazenamento ou tablespaces e outras construções específicas de um banco de dados necessárias para armazenar, recuperar e excluir objetos persistentes. Este papel: Identifica possibilidades de reuso de dados. Integra os modelos de dados do projeto com o modelo de dados corporativo. Implementa o modelo físico de dados 4.8 Testador Separata do Boletim do Exército nº 17, 26 de abril de

13 Identifica, define, implementa e conduz os testes necessários, bem como registra e analisa os resultados dos mesmos. Este papel: Identifica os testes que necessitam ser executados. Identifica a abordagem de implementação mais apropriada para um determinado teste. Implementa testes individuais. Prepara e executa os testes. Registra a execução e resultados para os testes. Analisa e recupera os erros de execução. Comunica os resultados do teste à equipe. 4.9 Projetista de Infraestrutura Analisa os impactos dos requisitos não funcionais com a infraestrutura disponível para produção e propõe medidas de adequação, quando for o caso. Atua como elemento de ligação entre a equipe responsável pelo desenvolvimento do sistema e o órgão responsável pela hospedagem e produção do sistema. Este papel: Estabelece as possibilidades e limitações do ambiente de produção para o projeto. Analisa, junto à equipe do projeto, as necessidades não funcionais, requeridas pelo produto, e as possibilidades do ambiente de produção. Propõe mudanças nos requisitos do projeto e/ou na infraestrutura existente, para atender as necessidades do projeto. Atua como elemento de ligação entre o órgão desenvolvedor e o de produção. Separata do Boletim do Exército nº 17, 26 de abril de

14 5. MODELO DE DESENVOLVIMENTO DE SOFTWARE Este modelo de processo de desenvolvimento de software descreve o fluxo de atividades e tarefas a serem executadas, para transformar requisitos de usuários e de sistemas em produto final de software. O modelo proposto neste documento foi dividido em fases. Em cada fase, o trabalho a ser realizado é composto por iterações. Cada iteração compreende um ciclo completo de atividades que, uma vez realizadas, levam à construção de um conjunto de produtos de trabalho significativos, os quais, somados, permitem que seja atingido o escopo da fase. Dentro de cada fase, o trabalho pode ser dividido em tantas iterações quantas forem necessárias. A cada ciclo da iteração, são agregados novos valores ou funcionalidades ao sistema, de maneira que o desenvolvimento torna-se incremental. Dessa forma, o processo proposto incorpora duas características fundamentais do processo unificado de engenharia de software, quais sejam: ser iterativo e incremental. Separata do Boletim do Exército nº 17, 26 de abril de

15 CAPÍTULO II DAS FASES DO PROJETO 1. FASES DO PROJETO Do ponto de vista do gerenciamento, o ciclo de vida do projeto de desenvolvimento de software desta MDS está dividido em quatro fases sequenciais: iniciação, elaboração, construção e transição. Cada uma dessas fases é concluída por um marco principal. Tais fases, portanto, representam, basicamente, um intervalo de tempo entre dois marcos principais. Os marcos são os seguintes (Tabela 1.): para a fase de iniciação, o escopo do projeto definido e aprovado; para a fase de elaboração, a arquitetura definida e validada; para a fase de construção, o sistema codificado e testado; e para a fase de transição, o projeto homologado pelo demandante. A cada final de fase, é feita uma avaliação para determinar se os objetivos da fase foram alcançados. Caso a avaliação seja satisfatória, o projeto poderá avançar para a próxima fase. Os trabalhos, dentro das fases, são estruturados na forma de ciclos de iterações, os quais realizados, permitem que seja alcançado o marco da fase. Iniciação Elaboração Construção Transição Escopo definido e Arquitetura definida Software codificado e Software homologado aprovado e validada testado Tabela 1: Marcos do ciclo de vida do desenvolvimento de software Separata do Boletim do Exército nº 17, 26 de abril de

16 1.1 FASE DE INICIAÇÃO Os projetos no Exército, de acordo com a NEGAPEB, devem ser precedidos por um estudo de viabilidade, a fim de investigar a sua exequibilidade. Concluindo-se pelo prosseguimento do projeto, deve ser expedida a Diretriz de Implantação do Projeto pela autoridade que determinou a ação. A complexidade do estudo de viabilidade depende de cada projeto, mas, normalmente, devem ser levantados aspectos legais, técnicos, econômicos, gerenciais item Estudo Técnico, no caso de projetos de desenvolvimento de software, deverá considerar também eventuais restrições ou limitações do ambiente de produção. A fase de iniciação marca o início do processo de desenvolvimento, após a aceitação do projeto. O foco principal nesta fase é obter o consenso em relação ao escopo do projeto, o qual será detalhado pela equipe do projeto. Os principais objetivos da fase são: a) Estabelecer o escopo do software do projeto e as condições limite, incluindo uma visão operacional, critérios de aceitação e o que deve ou não estar no produto; b) Discriminar os casos de uso críticos do sistema e os principais cenários de operação; c) Exibir, e talvez demonstrar, pelo menos uma opção de arquitetura para alguns cenários básicos; d) Estimar o custo geral e a programação para o projeto inteiro (e estimativas detalhadas para a fase de elaboração); e) Identificar as características do ambiente de produção e seus impactos quanto aos requisitos não funcionais, requeridos pelo produto, de forma a equilibrar às necessidades do sistema. Separata do Boletim do Exército nº 17, 26 de abril de FASE DE INICIAÇÃO e de riscos que permitam avaliar as reais possibilidades de sucesso do projeto. Em seu

17 f) Levantar e planejar o controle dos riscos em potencial (as fontes de imprevistos); e g) Preparar o ambiente (físico e lógico) de suporte para o projeto. FASE DE INICIAÇÃO Separata do Boletim do Exército nº 17, 26 de abril de

18 1.1.1 FLUXO DE ATIVIDADES DA FASE DE INICIAÇÃO FASE DE INICIAÇÃO Figura 1: Fluxo de trabalho de uma iteração na fase de iniciação Separata do Boletim do Exército nº 17, 26 de abril de

19 1.1.2 ATIVIDADES, TAREFAS E ENVOLVIDOS Atividade : Planejar o Projeto A equipe deve planejar o escopo, objetivos, riscos, duração inicial e os entregáveis do projeto. O Plano do Projeto será atualizado à medida que o projeto progredir, com base nas informações colhidas sobre o andamento dos trabalhos e mudanças no ambiente. O Gerente do Projeto deve garantir que todos estejam comprometidos com o plano elaborado. Tarefas Descrição Identificar os envolvidos Identificar os usuários, conhecedores do domínio, responsáveis pela validação dos artefatos e descrever suas responsabilidades no projeto. Alocar a equipe A equipe deve ser alocada e definidos os papéis e responsabilidades. Estimar tamanho e duração do projeto Aplicar técnica de mensuração de tamanho de projeto de software para estimar o tamanho do sistema a ser desenvolvido. A equipe deve esboçar uma duração inicial para cada item da lista de requisitos. Documentar a estimativa de tamanho e duração no Plano do Projeto. Organizar o projeto Identificar as premissas e restrições do projeto; Documentar os papéis, responsabilidades e nomear as pessoas responsáveis por cada papel; Separata do Boletim do Exército nº 17, 26 de abril de FASE DE INICIAÇÃO Figura 2: Subprocesso Identificar e Refinar Requisitos

20 O Gerente do Projeto deve avaliar a necessidade de definir os planos para o acompanhamento do projeto, comunicação, mudanças, aceitação do produto e outros conforme avaliação. Analisar o escopo do projeto e seus principais requisitos para descrever quais características serão implementadas em quais iterações, colocando os itens de trabalho de maior prioridade primeiro, incluindo respostas planejadas para os maiores riscos ou oportunidades. Definir a duração das iterações e utilizá-las para avaliar a duração do projeto. Documentar um breve resumo dos marcos do projeto e de um a três objetivos para cada iteração Identificar e avaliar riscos A equipe deve identificar os riscos, avaliar e atualizar a lista de riscos. O Gerente do Projeto deve tomar a decisão de quais riscos serão inicialmente tratados (mitigados ou evitados), quais serão apenas observados e aqueles que serão aceitos. Priorizar requisitos Os requisitos do Projeto devem ser priorizados em conjunto com a área cliente. O Plano do Projeto deve ser aprovado pelo cliente para garantir o seu comprometimento. Relacionamentos Papéis Responsável: Gerente de Projeto Participantes: Arquiteto Analista de Sistemas Cliente Entradas Estudo de viabilidade do projeto Termo de abertura do projeto Saídas Plano do Projeto Atividade: Planejar a Iteração Esta atividade tem o objetivo de planejar como serão realizadas as iterações dentro da fase. Cada iteração consiste em um ciclo de atividades que envolvem as principais tarefas da fase e que têm por objetivo gerar um produto de valor. Tal planejamento visa dividir os trabalho, de forma que o escopo da fase possa ser alcançado. Tarefas Descrição Selecionar os trabalhos e objetivos de cada iteração para a fase. Em conjunto com o cliente, selecione e priorizar os requisitos do tarefas para compor o escopo da iteração com base nos cenários e valores adicionados. Os itens selecionados definem a meta da iteração. Determinar quais requisitos dentre os selecionados para a iteração atual necessitam de maior detalhamento. Detalhar trabalho Uma vez detalhados os requisitos selecionados para a iteração, a equipe os da Iteração divide em tarefas conforme sua própria experiência e estima o esforço necessário para completar cada tarefa. A equipe discute com o Gerente do Projeto a melhor alocação das tarefas aos membros da equipe. Documentar planejamento Iteração o Documentar os requisitos selecionados para a iteração (meta). da Documentar o planejamento acordado na reunião. Separata do Boletim do Exército nº 17, 26 de abril de FASE DE INICIAÇÃO Descrever o ciclo de vida do projeto

21 Relacionamentos Papéis Responsável: Gerente do Projeto Participantes: Analista de Sistemas Arquiteto Testador Desenvolvedores Cliente Entradas Plano do Projeto Saídas Plano da Iteração Observações Atividade: Definir a Visão Esta atividade tem por objetivo principal elaborar o documento Visão, o qual define a visualização de envolvidos com o produto a ser desenvolvido e especifica suas necessidades e recursos mais importantes. Ele contém uma descrição dos requisitos centrais pretendidos e, portanto, proporciona a base contratual dos requisitos técnicos mais detalhados do sistema Tarefas Descrição Identificar os Clientes/Usuários Identificam-se os envolvidos, clientes e usuários que farão parte do desenvolvimento, orientando e descrevendo as regras dos processos para a entrega do sistema. Obter consenso Adquirir consenso entre todos os envolvidos no trabalho a ser realizado e na sobre o problema a maneira como será gerenciado o projeto. ser resolvido Capturar um Termos que contemplam o negócio devem ser definidos para terem significado vocabulário comum definido ao longo do desenvolvimento do projeto. Obter os requisitos solicitados pelos Clientes Serão base para elucidar os requisitos para desenvolver o produto. Deve-se realizar reuniões para discutir as solicitações do cliente. Definir os limites do Delimitar o escopo é importante para que funcionalidades não especificadas não sistema sejam construídas sem planejamento. Relacionamentos Papéis Responsável: Analista de Sistemas Participantes: Arquiteto Gerente de Projeto Cliente Separata do Boletim do Exército nº 17, 26 de abril de FASE DE INICIAÇÃO É importante notar que a reunião de planejamento é de suma importância para garantir a comunicação e comprometimento da equipe e do cliente com o planejamento. Quando o projeto estiver na 1ª iteração do projeto (Iniciação), esta atividade é dividida em dois momentos. No primeiro momento são selecionados os requisitos da iteração e realizada uma primeira avaliação dos riscos. Após, em um segundo momento, é feito o detalhamento dos requisitos prioritários.

22 Saídas Documento de Visão Glossário Observações A solução é proposta para um problema que todos identificam. Os Clientes colaboram com a equipe de desenvolvimento para expressar e documentar seus problemas, necessidades e potenciais características para o sistema de forma que a equipe de projeto possa compreender melhor o que tem de ser feito. Atividade: Gerenciar a Iteração Essa atividade contém as tarefas que permitem o início, o acompanhamento, a coordenação, o controle, a finalização e a revisão de cada iteração. Descrição Capturar e comunicar o andamento das Iterações O gerente de projeto necessita: monitorar continuamente o projeto para assegurar que esteja progredindo corretamente. permitir à equipe reagir o mais cedo possível a qualquer mudança. Muitas formas alternativas podem ser usadas para acompanhar o andamento, dentre elas, rápidas reuniões diárias, com a equipe do projeto, as quais são úteis para compreender o que os membros da equipe realizaram desde a última reunião, e o que planejam realizar antes da próxima reunião. Essas reuniões, também, permitem que a equipe identifique problemas e tome medidas corretivas. Tratar as exceções e os problemas Identifique a causa e o impacto dos problemas e exceções assim que eles aparecerem, as soluções possíveis que têm impacto imediato nos objetivos e metas de curto prazo, bem como quem necessita ser envolvido na execução da solução. A seguir, defina as ações corretivas e coordene sua execução. Identificar e gerenciar os riscos Identifique os riscos assim que o projeto inicie. A Lista de Riscos será incluída no documento Plano de Projeto, de acordo com a NEGAPEB. Deve ser revisada semanalmente, ou no mínimo uma vez por iteração. Gerenciar os objetivos Altere o escopo do trabalho, caso necessário, para assegurar que a equipe entregue um incremento útil do produto no fim da iteração, maximizando o valor aos Clientes, quando uma equipe estiver atrasando de forma significativa, ou problemas críticos ocorrerem, que impeçam a equipe de alcançar os objetivos da iteração. Trabalhe com a equipe e os Clientes para revisar o Plano de Iteração e, se necessário, reduzir a ênfase nas tarefas menos críticas adiando-as para uma iteração subsequente. Em casos raros, se os objetivos da iteração ainda parecerem impossíveis de serem cumpridos, a equipe pode considerar o encerramento ou a reformulação da iteração para um novo objetivo. Relacionamentos Papéis Responsável: Gerente de Projeto Participantes: Analista de Sistemas Arquiteto Desenvolvedor Cliente Separata do Boletim do Exército nº 17, 26 de abril de FASE DE INICIAÇÃO Tarefas

23 Testador Entradas Plano de Iteração Plano de Projeto Saídas Plano de Iteração revisado Plano de Projeto revisado Atividade: Planejar Próxima Iteração Esta atividade tem o objetivo de planejar como serão realizadas as iterações da próxima fase. Cada iteração consiste em um ciclo de atividades que envolvem as principais tarefas da fase e que têm por objetivo gerar um produto de valor. Tal planejamento visa dividir os trabalho, de forma que o escopo da fase possa ser alcançado. Descrição Selecionar os trabalhos e objetivos de cada iteração para a fase. Em conjunto com o cliente, selecione e priorizar os requisitos do tarefas para compor o escopo da iteração com base nos cenários e valores adicionados. Os itens selecionados definem a meta da iteração. Determinar quais requisitos dentre os selecionados para a iteração atual necessitam de maior detalhamento. Detalhar trabalho Uma vez detalhados os requisitos selecionados para a iteração, a equipe os da Iteração divide em tarefas conforme sua própria experiência e estima o esforço necessário para completar cada tarefa. A equipe discute com o Gerente do Projeto a melhor alocação das tarefas aos membros da equipe. Documentar planejamento Iteração o Documentar os requisitos selecionados para a iteração (meta). da Documentar o planejamento acordado na reunião. Relacionamentos Papéis Responsável: Gerente de Projeto Participantes: Analista de Sistemas Arquiteto Analista de Teste Desenvolvedor Cliente Entradas Plano de Projeto Plano de Iteração Saídas Plano de Iteração Plano de Projeto revisado Atividade: Encerrar a Iteração No encerramento da iteração o Gerente do Projeto coordena a revisão da estimativa do projeto, em função das alterações e conhecimento adquirido com a implementação das funcionalidades da iteração. Caso seja a última iteração do projeto prossegue com o encerramento do mesmo e dos contratos a ele associados. Tarefas Descrição Separata do Boletim do Exército nº 17, 26 de abril de FASE DE INICIAÇÃO Tarefas

24 Revisar os resultados da iteração Avalie em conjunto com a equipe do projeto, ao final da iteração, se os objetivos e os critérios de avaliação estabelecidos no Plano de Iteração foram alcançados, e se a equipe aderiu ao plano da iteração e concluiu todos os itens de trabalho atribuídos à iteração Avaliar a estimativa Avaliar se as estimativas de tempo iniciais foram atingidas. do tamanho do produto Demonstrar valor e Demonstre o produto ao cliente, aos usuários finais e aos outros clientes para obter retorno obter seu retorno de informações (feedback). Isto deve ser feito durante a iteração, ou pelo menos em uma sessão separada próxima ao fim da iteração. Proceda com o pagamento de acordo com o valor calculado do tamanho desenvolvido, em pontos de função, em caso de desenvolvimento feito por empresa contratada: Divulgue a todos os envolvidos via , atualização do andamento do projeto e a conclusão da iteração. Realizar procedimentos contratuais Se aplicável, encerrar os contratos vigentes para o término do projeto. Relacionamentos Papéis Responsável: Gerente do Projeto Participantes: Analista de Sistemas Entradas Especificação de Requisitos Plano de Iteração Plano de Projeto Saídas Relatório de Avaliação da Iteração Plano de Iteração revisado Plano de Projeto revisado Observações O termo de homologação deverá ser assinado pelo gerente de projetos e pelo cliente, firmando as decisões que foram tomadas. Atividade: Identificar e Refinar os Requisitos / Encontrar e descrever os requisitos O propósito desta atividade é a identificação e refinamento dos requisitos para posterior aprovação do cliente. O objetivo é adquirir consenso entre todos os envolvidos do trabalho a ser realizado e o detalhamento das funcionalidades do sistema. Tarefas Descrição Encontrar requisitos Através de reuniões com o cliente, levantam-se os requisitos (funcionais e não funcionais) do sistema. Refinar Requisitos Especificar os requisitos na forma de casos de uso e especificações suplementares. Relacionamentos Separata do Boletim do Exército nº 17, 26 de abril de FASE DE INICIAÇÃO Realizar procedimentos administrativos

25 Papéis Responsável: Analista de Sistemas Participantes: Gerente do Projeto Analistas de Sistemas Arquiteto Cliente/Usuário Plano de Iteração Plano de Projeto Visão Glossário Saídas Modelo de Caso de Uso Especificação de Requisitos Suplementares Lista de Regras de Negócio Lista de Requisitos Funcionais Atividade: Identificar e revisar os requisitos / Detalhar os requisitos Detalhar os requisitos para validar o entendimento dos requisitos, assegurar consenso na área cliente e permitir que o desenvolvimento do sistema comece. Tarefas Detalhar requisitos Descrição Identificar os atores e os cenários dos casos de uso e detalhar. Criar esboços de tela para garantir o entendimento do fluxo de navegação e disposição dos elementos de interface por parte do cliente e desenvolvedores. Atualizar o Modelo de Casos de Uso e obter o consenso dos envolvidos. Relacionamentos Papéis Responsável: Analista de Sistemas Participantes: Cliente Gerente do Projeto Desenvolvedor Entradas Lista de Requisitos Funcionais Modelo de Caso de Uso Saídas Caso de Uso detalhado Descrição de Interfaces Atividade: Homologar requisitos O propósito desta atividade é coletar a aprovação da área cliente dos requisitos detalhados e, dessa forma, adquirir consenso entre todos os envolvidos do trabalho a ser realizado e da maneira como será gerenciado o projeto. Tarefas Descrição Aprovar requisitos Avaliar se a Especificação de Requisitos contempla todas as especificidades Separata do Boletim do Exército nº 17, 26 de abril de FASE DE INICIAÇÃO Entradas

26 funcionais e não funcionais para os requisitos selecionados para a Iteração. Avaliar os esboços de tela para garantir o entendimento do fluxo de navegação e disposição dos elementos de interface. Emitir aprovação. Relacionamentos Responsável: Analista de Sistemas Participantes: Gerente de Projeto Cliente/Usuário Entradas Especificação de Requisitos Especificações Suplementares Plano do Projeto Modelo de Casos de Uso Especificação de Casos de Uso Descrição de interfaces Saídas Termo de Homologação Atividade: Preparar ambiente de desenvolvimento O objetivo desta atividade é garantir que tecnicamente todos da equipe tenham condições de iniciar a implementação dos requisitos selecionados para realização da iteração. As ferramentas de desenvolvimento devem ser instaladas e configuradas, conforme as necessidades do projeto. Tarefas Descrição Identificar ferramentas Verificar as ferramentas necessárias para o desenvolvimento, nas devidas versões. Mapear servidores Definir os servidores que serão utilizados como ambiente de teste, homologação e produção e instalar os sistemas necessários. Criar Bases de Dados Instalar sistema gerenciador de banco de dados e base de dados do projeto, se for o caso. Configurar ambiente Deixar os computadores dos desenvolvedores prontos para a implementação prevista na iteração. Instalar ferramentas, plug-ins e acessórios. Criar a estrutura de diretório do projeto e configurar o software de controle de versionamento. Relacionamentos Papéis Responsável: Arquiteto Participantes: Gerente de projeto Analista de Sistemas Desenvolvedor DBA Entradas Plano do Projeto e Plano de Iteração Saídas Repositório Configurado Ambiente de Desenvolvimento Configurado Separata do Boletim do Exército nº 17, 26 de abril de FASE DE INICIAÇÃO Papéis

27 Atividade: Descrever a Arquitetura Descrever a arquitetura através da análise dos requisitos arquiteturalmente significantes e pela identificação de restrições, decisões e objetivos arquiteturais. Tarefas Descrição Identificar as metas Trabalhe com a equipe, especialmente com os Cliente e o Analista, para arquiteturais descrever as metas da arquitetura restantes e identificar quais são adequadas para a iteração. Examine a Visão e os requisitos. Estas metas irão priorizar e guiar a abordagem para decisões técnicas importantes. Será importante revisar periodicamente o status dessas metas em todo o projeto para certificar que elas ainda são válidas e que o sistema está no caminho certo para entregá-las. Identifique quais dos requisitos atuais são arquiteturalmente significantes. Explore e refine aqueles que devem ser implementados para alcançar as metas arquiteturais da iteração atual. Identificar as restrições na arquitetura Liste quaisquer restrições na arquitetura e eventuais conflitos entre os requisitos e os recursos concorrentes. Decida como a arquitetura irá resolver essas questões. Justifique cada decisão tomada e capture essas informações. Revise periodicamente a lista de restrições para certificar que elas ainda são válidas e que não apareceram outras novas. Examinar, avaliar e selecionar os recursos disponíveis Identifique os recursos de outras áreas que podem ser reutilizados na arquitetura atual. Podem ser: frameworks arquiteturais, mecanismos arquiteturais, decisões arquiteturais, restrições, aplicações e componentes. Definir a Decida como estruturar o software em termos lógicos e físicos. No mínimo defina: abordagem para Como decompor o software ao gerenciar o desenvolvimento (o uso de estruturar o sistema divisão em camadas como uma estratégia de decomposição, por exemplo). Como o software será composto em tempo de execução. Para cada decomposição do software, descreva resumidamente: Seu nome e finalidade. Seus relacionamentos com outras decomposições. Estas definições irão construir a base para estruturar o Design e a Implementação. Definir a Descreva como o software será distribuído nos nós da rede. Trabalhe com os abordagem para clientes bem como com as equipes de implantação e de suporte de rede para implantar o sistema assegurar que a abordagem proposta seja uma boa opção para todo o ambiente técnico. Identificar os mecanismos arquiteturais Faça uma lista dos serviços técnicos que o sistema precisa fornecer e capture algumas informações básicas sobre cada item na lista. Normalmente, é uma boa ideia fazer uma lista inicial de todos os mecanismos necessários ao projeto e, em seguida, priorizar o desenvolvimento dos que devem ser entregues, para alcançar as metas da iteração atual Separata do Boletim do Exército nº 17, 26 de abril de FASE DE INICIAÇÃO Identificar os requisitos arquiteturalmente significantes

28 Verificar a coerência arquitetural Trabalhe com o Desenvolvedor e o Gerente de Projeto, para verificar se a arquitetura está consistente com os requisitos e se as descrições da arquitetura estão claras, significativas e completas. Capturar as decisões arquiteturais Capture decisões importantes sobre a arquitetura para referência futura. Considere o uso dos templates fornecidos para o Documento de Arquitetura. Os Desenvolvedores em particular, devem compreender claramente o estado atual da arquitetura em cada iteração antes do desenvolvimento da arquitetura. Relacionamentos Responsável: Arquiteto Participantes: Analista de Sistemas Desenvolvedor Gerente de Projeto Cliente Entradas Visão Modelo de Casos de Uso Glossário Saídas Documento de Arquitetura Separata do Boletim do Exército nº 17, 26 de abril de FASE DE INICIAÇÃO Papéis

29 Atividade: Analisar ambiente de Produção O objetivo desta atividade é analisar a infraestrutura do ambiente de produção, para se verificar a sua adequabilidade às exigências do sistema. Tarefas Descrição Identificar as características técnicas do ambiente de produção, suas possibilidades e limitações. Identificar as características do ambiente de produção relevantes para o sistema em desenvolvimento, tais como: servidores, capacidades de processamento, memória, armazenamento de dados, de banda de rede e backup, sistemas operacionais e softwares existentes e suas licenças de uso, bem como capacitação do pessoal. Verificar, também, a projeção de utilização dessas capacidades pelos sistemas atuais e futuros (previstos). Verificar se a infraestrutura atual atende o sistema Verificar se a infraestrutura atual e/ou futura atende os requisitos não-funcionais do sistema. Propor ajustes no ambiente de produção e/ou reservas de capacidades. Propor ajustes na infraestrutura de produção, para atender aos requisitos não-funcionais do sistema. Propor, também, reserva de recursos de infraestrutura, visando atender o sistema em desenvolvimento. Consolidar todo o estudo em um relatório. Relacionamentos Papéis Responsável: Projetista de Infraestrutura Participantes: Analista de Sistemas Arquiteto Gerente de Projeto Entradas Especificação de Requisitos Suplementares Documento de Arquitetura Saídas Relatório 1.2 FASE DE ELABORAÇÃO Na fase de elaboração, busca-se estabelecer a linha de base (baseline) para a arquitetura do sistema, a fim de fornecer uma base estável para o esforço da fase de construção. Separata do Boletim do Exército nº 17, 26 de abril de FASE DE ELABORAÇÃO Verificar as Verificar as necessidades do sistema, em virtude dos requisitos não-funcionais, necessidades do levantados nas especificações suplementares. sistema decorrentes dos requisitos não-funcionais

30 Esta fase envolve uma análise detalhada sobre as necessidades e problemas gerais do projeto e a definição de como o sistema será desenvolvido em termos tecnológicos, considerando os requisitos (funcionais e não funcionais), limitações e restrições identificadas durante a fase de iniciação. Os principais objetivos da fase são: a) Assegurar que a arquitetura, os requisitos e os planos sejam estáveis o suficiente e que os riscos sejam suficientemente diminuídos a fim de determinar com segurança o custo e a programação para a conclusão do b) Tratar todos os riscos significativos do ponto de vista da arquitetura do projeto; c) Estabelecer uma arquitetura de baseline derivada do tratamento dos cenários significativos do ponto de vista da arquitetura, que normalmente expõem os maiores riscos técnicos do projeto; d) Implementar e testar um ou mais casos de uso que representam os maiores riscos técnicos do projeto,para demonstrar que a arquitetura proposta suportará os requisitos do sistema a um custo e tempo viáveis; e e) Configurar o ambiente de suporte para o projeto. Isso inclui adaptar o processo para o projeto, preparar gabaritos, diretrizes e configurar ferramentas. Separata do Boletim do Exército nº 17, 26 de abril de FASE DE ELABORAÇÃO desenvolvimento;

31 1.2.1 FLUXO DE ATIVIDADES DA FASE DE ELABORAÇÃO FASE DE ELABORAÇÃO Figura 3: Fluxo de trabalho de uma iteração na fase de elaboração / construção Separata do Boletim do Exército nº 17, 26 de abril de

32 Figura 5: Subprocesso Testar a Solução Separata do Boletim do Exército nº 17, 26 de abril de FASE DE ELABORAÇÃO Figura 4: Subprocesso Desenvolver Incremento da Solução

33 1.2.2 ATIVIDADES, TAREFAS E ENVOLVIDO As atividades Gerenciar a Iteração, Planejar Próxima Iteração, Encerrar a Iteração, Identificar e Refinar Requisitos e Homologar Requisitos, por se repetirem nas fases de Iniciação e de Elaboração, já foram detalhadas na fase de Iniciação. Atividade: Revisar a Iteração Tarefas Verificar requisitos iteração Descrição os Verificar se os objetivos da iteração da fase anterior foram atingidos. da Avaliar o trabalho a ser realizado dentro da fase atual e confrontar com o planejado no Plano de iteração realizado anteriormente. Selecionar os requisitos a serem implementados na iteração. Os requisitos selecionados definem a meta da iteração. Confirmar ou redefinir a prioridade dos itens de trabalho da iteração, conforme definições do cliente e, com base nesta prioridade, selecionar requisitos a serem detalhados para as próximas iterações. Determinar quais requisitos dentre os selecionados para a iteração atual necessitam de maior detalhamento. Identificar e revisar Identificar e revisar os riscos e seus planos de resposta. riscos Revisar o Revisar ou confirmar as tarefas necessárias para realizar os requisitos detalhamento do selecionados para a iteração. Estimar o esforço necessário para completar cada trabalho da Iteração tarefa. O Gerente do Projeto realiza a distribuição das tarefas para os membros da equipe. Documentar a Documentar as alterações nos requisitos selecionados para a iteração (meta). revisão do Documentar as alterações no planejamento acordado. planejamento da iteração, caso necessário. Relacionamentos Papéis Responsável: Gerente de Projeto Participantes: Analista de Sistemas Arquiteto Desenvolvedor Testador Entradas Plano de Projeto Visão do Projeto Plano da Iteração Separata do Boletim do Exército nº 17, 26 de abril de FASE DE ELABORAÇÃO Essa atividade tem o objetivo de avaliar o Plano de Iteração elaborado anteriormente, confrontar com as iterações realizadas até o momento e, a partir disso, revisar o planejamento das iterações da fase que se inicia.

34 Relatório de Avaliação de Iteração anterior Saídas Plano da Iteração revisado Observações Atividade: Refinar a arquitetura A arquitetura, inicialmente esboçada, na fase de iniciação, será, durante a fase de elaboração, refinada em um nível apropriado de detalhe para suportar o desenvolvimento. Tarefas Descrição Identificar os elementos de design arquiteturalmente significantes Refine as principais abstrações em elementos concretos de design (tais como classes e subsistemas) e forneça pelo menos um nome e uma descrição resumida para cada um. Refinar os mecanismos arquiteturais Refine cada mecanismo arquitetural priorizado em um estado de design. Revise os requisitos da iteração atual para identificar quais mecanismos precisam realmente ser entregues no software. Trabalhe com os desenvolvedores para que eles refinem os mecanismos para um estado de implementação. Definir métricas de qualidade de código Defina as métricas e os parâmetros que serão utilizados para avaliar a qualidade e a segurança do código produzido Associar o software ao Associe os elementos de design arquiteturalmente significantes ao ambiente hardware definido para implantação. Trabalhe com os especialistas de rede e hardware para assegurar que o hardware seja adequado para atender as necessidades do sistema; e que qualquer hardware novo esteja disponível oportunamente. Definir a arquitetura de Assegure-se de que as arquiteturas de desenvolvimento e de teste estejam desenvolvimento e a definidas. Identifique qualquer diferença arquiteturalmente significante entre arquitetura de teste estes ambientes e trabalhe com a equipe para planejar estratégias para atenuar qualquer risco que eles possam gerar. Atualizar a arquitetura Atualize o Documento de Arquitetura para refletir qualquer mudança feita Separata do Boletim do Exército nº 17, 26 de abril de FASE DE ELABORAÇÃO 1. Durante o planejamento do projeto, as iterações são identificadas, mas as estimativas possuem uma incerteza aceitável devido à falta de detalhes na concepção do projeto. 2. Esta atividade é repetida em cada iteração durante uma entrega. Isto permite que a equipe aumente a precisão das estimativas para uma iteração, visto que mais detalhes sobre o projeto serão conhecidos. 3. O Gerente de Projeto tem a responsabilidade de garantir que a equipe comprometa-se com uma quantidade razoável de trabalho para a iteração, baseado no desempenho da equipe e nas iterações anteriores. 4. O foco de uma iteração na fase de elaboração é validar a arquitetura. 5. O foco de uma iteração na fase de construção é a implementação dos requisitos funcionais. 6. O foco de uma iteração na fase de transição é assegurar que o software esteja disponível para seus usuários finais. 7. Avaliar a clareza dos critérios de avaliação para a iteração. 8. Assegurar-se de que os produtos planejados podem ser construídos com o esforço e tempo disponível. 9. Assegurar-se de que os resultados da iteração serão passíveis de verificação.

35 durante o desenvolvimento. Assegure-se de que a arquitetura suporte os requisitos e as necessidades do projeto. Desenvolva alguns casos de uso importantes para o projeto para produzir uma versão que mostre que a arquitetura de software é viável. Isto deve fornecer a base definitiva para validar a viabilidade da arquitetura. Como o software deve ser desenvolvido de forma iterativa, mais de um incremento pode ser necessário para validar a arquitetura. Durante os estágios iniciais do projeto pode ser aceitável que o software tenha uma aparência incompleta ou prototípica, porque será considerado inicialmente como linha base da arquitetura para fornecer uma base estável para o trabalho de desenvolvimento restante. Comunicar as decisões Assegure-se de que aqueles que necessitam agir sobre o trabalho arquitetural compreendam-no e possam trabalhar com ele. Certifique-se de que a descrição da arquitetura explica claramente não somente a solução, mas também a motivação e os objetivos relacionados às decisões que foram tomadas na elaboração da arquitetura. Isto tornará mais fácil aos outros a compreensão da arquitetura e sua adaptação no tempo. Relacionamentos Papéis Responsável: Arquiteto Participantes: Gerente de Projeto Desenvolvedor Entradas Visão Modelo de Casos de Uso Glossário Documento de Arquitetura Saídas Documento de Arquitetura revisado Observações O arquiteto deve executar esta tarefa com a colaboração de toda a equipe para promover consenso e compreensão comum de toda a solução. O arquiteto deve trabalhar para coordenar e guiar as atividades técnicas da equipe. O arquiteto deve colocar ênfase no envolvimento dos desenvolvedores durante toda esta tarefa. Atividade: Projetar a solução A finalidade desta tarefa é descrever os elementos do sistema de modo que suportem o comportamento necessário, sejam de alta qualidade, e adaptem-se a arquitetura. Tarefas Descrição Compreender os detalhes dos requisitos Examine os Caso de Uso relevantes e a Especificação de Requisitos Suplementares para compreender o escopo da tarefa de design e as expectativas sobre o Design Compreender a arquitetura Revise o Documento de Arquitetura para identificar mudanças e adições à arquitetura Este passo pode ser ignorado, se não houve alterações na arquitetura proposta na iteração anterior. Separata do Boletim do Exército nº 17, 26 de abril de FASE DE ELABORAÇÃO Validar a arquitetura

36 Identifique os elementos que colaboram entre si para fornecer o comportamento desejado. Isto pode começar com as principais abstrações identificadas no Caderno de Arquitetura, no design, na análise de domínio e na análise clássica dos requisitos (filtragem de substantivo) para derivar os elementos que serão necessários para cumpri-los O Padrão Entidade-Controle-Fronteira fornece um bom começo para identificar elementos Determinar como os elementos colaboram para realizar o cenário Percorra o cenário distribuindo as responsabilidades aos elementos participantes e assegurando que eles têm os relacionamentos necessários para colaborar. Estas responsabilidades podem ser simples declarações do comportamento atribuídas aos elementos; não necessitam ser especificações detalhadas de operações com parâmetros. Verifique o Documento de Arquitetura e o trabalho de design prévio para criar uma colaboração consistente. Trabalhe com o Arquiteto para entender os detalhes e as motivações da arquitetura. Procure reutilizar relações e comportamentos existentes ou aplique estruturas similares para simplificar o design de todo o sistema. Refinar as decisões Refine o design até um nível apropriado de detalhe para orientar a de design implementação e assegurar que se adapta à arquitetura. Nesta etapa o design pode levar em consideração a linguagem de implementação real e outras decisões técnicas Discuta questões sobre teste, tais como os elementos de design que são difíceis de testar ou áreas críticas de desempenho, com o Testador e o Arquiteto. Projetar o interior Projete elementos grandes ou complexos ou algum comportamento interno complexo mais detalhadamente. Pode ser útil descrever uma máquina de estado para os elementos com estados complexos. Comunicar o Design Comunique o design do sistema para aqueles que necessitam compreendê-lo. Embora isto esteja descrito daqui até o fim da tarefa, a comunicação deve acontecer em todas as etapas. Trabalhar colaborativamente é sempre melhor do que revisar o trabalho depois dele estar completo. Avaliar o Design Avalie o design de objeto para acoplamento, coesão e outras medidas de qualidade de design. Relacionamentos Papéis Responsável: Projetista Participantes: Arquiteto Desenvolvedor Analista de Sistemas Testador Entradas Documento de Arquitetura Caso de Uso Detalhado Especificação de Requisitos Suplementares Saídas Modelo de Design Separata do Boletim do Exército nº 17, 26 de abril de FASE DE ELABORAÇÃO Identificar elementos de design

37 Observações Atividade: Validar e implementar o modelo de dados O objetivo desta atividade é analisar as regras de negócio em relação aos dados e implementar fisicamente um modelo de dados lógico Tarefas Descrição Validar o modelo Verifique a aderência do modelo de dados às normas para definição de dados e metadados (IR 14-06). Identificar reuso Identifique oportunidades para reutilização de dados Implementar o modelo de dados Definir tipos reutilizáveis definidos pelo usuário. Criar as tabelas e relações iniciais do banco de dados. Definir tabelas de referência Definir uma ou mais colunas que identifiquem exclusivamente uma linha na tabela (chave primária). Definir limites sobre as colunas que garantam a exclusividade dos dados ou da coleta de dados. Definir regras de cumprimento de integridade referencial e dados (Chaves estrangeiras). Desnormalizar o modelo de dados para otimizar o desempenho. Otimizar acesso a dados por meio de indexação. Projetar a alocação de espaço e a organização de página de disco do banco de dados. Projetar procedimentos armazenados para distribuir comportamento de classe ao banco de dados. Separata do Boletim do Exército nº 17, 26 de abril de FASE DE ELABORAÇÃO 1. Esta atividade serve para projetar parte do sistema, não o sistema inteiro. Deve ser aplicada com base em um pequeno grupo dos requisitos. O design é mais bem executado em pequenas partes. 2. Aplique padrões durante toda esta tarefa. Os padrões representam designs aprovados e seu uso promove qualidade e consistência em todo o Design. 3. Os requisitos que orientam o Design podem ser requisitos funcionais baseados em cenários, requisitos não-funcionais ou uma combinação destes. 4. Se esta tarefa estiver sendo executada em um elemento arquiteturalmente significante, os resultados deste design devem ser referenciados pelo Documento de Arquitetura 5. Aqui estão alguns exemplos dos indivíduos que precisarão entender o design do sistema: Os desenvolvedores que implementarão uma solução baseados no design. Os arquitetos que podem revisar o design para assegurar que se conforma com a arquitetura ou que possa examinar o design para oportunidades de melhoria na arquitetura. Outros projetistas que podem examinar o design para aplicabilidade em outras partes do sistema. Desenvolvedores ou outros projetistas que estarão trabalhando em outras partes do sistema que dependerão dos elementos projetados nesta tarefa. Outros revisores que revisarão o design em relação à qualidade e aderência aos padrões.

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

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

Metodologia de Gestão e Desenvolvimento de Software. Coordenação Geral de Tecnologia da Informação

Metodologia de Gestão e Desenvolvimento de Software. Coordenação Geral de Tecnologia da Informação Metodologia de Gestão e Desenvolvimento de Software Coordenação Geral de Tecnologia da Informação 2 Índice 1. Processos Organizacionais... 7 1.1. A gestão da demanda... 7 1.2. e Responsabilidades... 7

Leia mais

Metodologia de Desenvolvimento de Sistemas (MDS - ANEEL)

Metodologia de Desenvolvimento de Sistemas (MDS - ANEEL) Metodologia de Desenvolvimento de Sistemas (MDS - ANEEL) Versão 2.0 Escritório de Gerenciamento de Projetos - EGP Superintendência da Gestão Técnica da Informação SGI Agência Nacional de Energia Elétrica

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

! 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

DESENVOLVIMENTO DE SISTEMAS

DESENVOLVIMENTO DE SISTEMAS Agência Nacional de Vigilância Sanitária METODOLOGIA DE DESENVOLVIMENTO DE SISTEMAS GGTIN GESIS Brasília, julho de 2006. Página: 1 Histórico de Revisões Data Versão Descrição Autor 12/06/2006 1.0.00 Criação

Leia mais

METODOLOGIA DE DESENVOLVIMENTO DE SISTEMAS

METODOLOGIA DE DESENVOLVIMENTO DE SISTEMAS PODER JUDICIÁRIO JUSTIÇA DO TRABALHO TRIBUNAL REGIONAL DO TRABALHO DA 11ª REGIÃO SECRETARIA DE TECNOLOGIA DA INFORMAÇÃO - SETI Versão 1.0 MANAUS-AM (2010) MDS Metodologia de Desenvolvimento de Sistemas

Leia mais

VANT-EC-SAME. Software de Suporte do VANT V-SUP Caso de Desenvolvimento Versão 1.0

VANT-EC-SAME. Software de Suporte do VANT V-SUP Caso de Desenvolvimento Versão 1.0 VANT-EC-SAME Software de Suporte do VANT V-SUP Caso de Desenvolvimento Versão 1.0 Histórico da Revisão Data Versão Descrição Autor 17/0/07 1.0 Versão Inicial Douglas Moura Confidencial VANT-EC-SAME, 2007

Leia mais

Metodologia de Desenvolvimento de Sistemas (Versão 2.0)

Metodologia de Desenvolvimento de Sistemas (Versão 2.0) SERVIÇO PÚBLICO FEDERAL MINISTÉRIO DA INTEGRAÇÃO NACIONAL DEPARTAMENTO NACIONAL DE OBRAS CONTRA AS SECAS Metodologia de Desenvolvimento de Sistemas (Versão 2.0) 1 Sumário 1Introdução... 5 1.1 Objetivo...

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

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

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

METODOLOGIA DE DESENVOLVIMENTO DE SISTEMAS

METODOLOGIA DE DESENVOLVIMENTO DE SISTEMAS METODOLOGIA DE DESENVOLVIMENTO DE SISTEMAS Versão 1 MDS Metodologia de Desenvolvimento de Sistemas 1 Presidente INCRA Rolf Hackbart Diretor de Gestão Estratégica DE - INCRA Roberto Kiel Coordenador Geral

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

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

MDMS-ANAC. Metodologia de Desenvolvimento e Manutenção de Sistemas da ANAC. Superintendência de Tecnologia da Informação - STI

MDMS-ANAC. Metodologia de Desenvolvimento e Manutenção de Sistemas da ANAC. Superintendência de Tecnologia da Informação - STI MDMS-ANAC Metodologia de Desenvolvimento e Manutenção de Sistemas da ANAC Superintendência de Tecnologia da Informação - STI Histórico de Alterações Versão Data Responsável Descrição 1.0 23/08/2010 Rodrigo

Leia mais

Princípios da Engenharia de Software aula 05 Gerenciamento de planejamento de projetos. Prof.: Franklin M. Correia

Princípios da Engenharia de Software aula 05 Gerenciamento de planejamento de projetos. Prof.: Franklin M. Correia 1 Princípios da Engenharia de Software aula 05 Gerenciamento de planejamento de projetos Prof.: Franklin M. Correia Na aula anterior... Metodologias ágeis Princípios do Manifesto ágil 12 itens do manifesto

Leia mais

Guia do Nexus. O Guia Definitivo para o Nexus: O exoesqueleto do desenvolvimento Scrum escalado. Desenvolvido e mantido por Ken Schwaber e Scrum.

Guia do Nexus. O Guia Definitivo para o Nexus: O exoesqueleto do desenvolvimento Scrum escalado. Desenvolvido e mantido por Ken Schwaber e Scrum. Guia do Nexus O Guia Definitivo para o Nexus: O exoesqueleto do desenvolvimento Scrum escalado Desenvolvido e mantido por Ken Schwaber e Scrum.org Tabela de Conteúdo Visão Geral do Nexus... 2 O Propósito

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

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

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

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

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

Modelos de processos de desenvolvimento de software

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

Leia mais

Para cada fase consideramos. Tempo para um projeto típico Tempo para um projeto Complexo. Arquitetura do Processo Unificado. A meta a ser atingida

Para cada fase consideramos. Tempo para um projeto típico Tempo para um projeto Complexo. Arquitetura do Processo Unificado. A meta a ser atingida Arquitetura do Processo Unificado Tempo para um projeto típico Tempo para um projeto Complexo O tempo gasto nas fases iniciais aumentam Para cada fase consideramos A meta a ser atingida Workflows a executar

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

SIGECO07 Sistema Integrado de Gestão de Contas Universidade Federal de Lavras PLANO DE PROJETO 23/09/2007 SIGECO07/GERENCIA/PROJETOS/

SIGECO07 Sistema Integrado de Gestão de Contas Universidade Federal de Lavras PLANO DE PROJETO 23/09/2007 SIGECO07/GERENCIA/PROJETOS/ SIGECO07 Sistema Integrado de Gestão de Contas Universidade Federal de Lavras PLANO DE PROJETO 23/09/2007 SIGECO07/GERENCIA/PROJETOS/ ModeloPlanoProjeto_2007_04_24 SIGECO07_PlanoProjeto_2007_09_23 Página

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

Qualidade de Processo de Software Normas ISO 12207 e 15504

Qualidade de Processo de Software Normas ISO 12207 e 15504 Especialização em Gerência de Projetos de Software Qualidade de Processo de Software Normas ISO 12207 e 15504 Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br Qualidade de Software 2009 Instituto

Leia mais

CONCORRÊNCIA AA Nº 05/2009 BNDES ANEXO X PROJETO BÁSICO: DESCRIÇÃO DOS PROCESSOS DE TI

CONCORRÊNCIA AA Nº 05/2009 BNDES ANEXO X PROJETO BÁSICO: DESCRIÇÃO DOS PROCESSOS DE TI CONCORRÊNCIA AA Nº 05/2009 BNDES ANEXO X PROJETO BÁSICO: DESCRIÇÃO DOS PROCESSOS DE TI 1. PI06 TI 1.1. Processos a serem Atendidos pelos APLICATIVOS DESENVOLVIDOS Os seguintes processos do MACROPROCESSO

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

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

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

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

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

Leia mais

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

Desenvolvimento de Sistemas Orientados a Objetos com UML UP/RUP: Projeto

Desenvolvimento de Sistemas Orientados a Objetos com UML UP/RUP: Projeto Desenvolvimento de Sistemas Orientados a Objetos com UML UP/RUP: Projeto Engenharia de Software I Informática 2009 Profa. Dra. Itana Gimenes RUP: Artefatos de projeto Modelo de Projeto: Use-Case Realization-projeto

Leia mais

Gerenciamento de Projeto

Gerenciamento de Projeto UNIVERSIDADE ESTADUAL PAULISTA INSTITUTO DE BIOCIÊNCIAS, LETRAS E CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIAS DE COMPUTAÇÃO E ESTATÍSTICA Gerenciamento de Projeto Engenharia de Software 2o. Semestre/ 2005

Leia mais

Políticas de Qualidade em TI

Políticas de Qualidade em TI Políticas de Qualidade em TI Aula 05 MPS.BR (ago/12) Melhoria de Processo do Software Brasileiro Prof. www.edilms.eti.br edilms@yahoo.com Agenda Descrição sumária do MPS.BR - Melhoria de Processo do Software

Leia mais

Engenharia de Software I

Engenharia de Software I Engenharia de Software I Curso de Desenvolvimento de Software Prof. Alessandro J de Souza ajdsouza@cefetrn.br 1 Rational Unified Process RUP Fase Construção 2 VISÃO GERAL Fase Construção. Visão Geral 3

Leia mais

Gestão da Tecnologia da Informação

Gestão da Tecnologia da Informação TLCne-051027-P0 Gestão da Tecnologia da Informação Disciplina: Governança de TI São Paulo, Outubro de 2012 0 Sumário TLCne-051027-P1 Conteúdo desta Aula Abordar o domínio Adquirir e Implementar e todos

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

Curso: Engenharia de Software com Ênfase em Padrões de Software (UECE Universidade Estadual do Ceará) RUP

Curso: Engenharia de Software com Ênfase em Padrões de Software (UECE Universidade Estadual do Ceará) RUP Conceitos RUP RUP, abreviação de Rational Unified Process (ou Processo Unificado da Rational), é um processo de Engenharia de software criado pela Rational Software Corporation(a qual foi incorporada pela

Leia mais

Concepção e Elaboração

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

Leia mais

Engenharia de Software

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

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

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 Introdução à Melhoria de Processos de Software baseado no MPS.BR Prof. Maxwell Anderson www.maxwellanderson.com.br Agenda Introdução MPS.BR MR-MPS Detalhando o MPS.BR nível G Introdução

Leia mais

1 UML (UNIFIED MODELING LANGUAGE)

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

Leia mais

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

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

PROJETO DE FÁBRICA DE SOFTWARE

PROJETO DE FÁBRICA DE SOFTWARE FACULDADE SETE DE SETEMBRO FASETE Departamento de Sistemas de Informação PROJETO DE FÁBRICA DE SOFTWARE Denise Xavier Fortes Paulo Afonso BA Agosto/2015 Sumário 1. INTRODUÇÃO... 3 2. PERFIS FUNCIONAIS...

Leia mais

Poder Judiciário. Justiça do Trabalho. Tribunal Regional do Trabalho da 24ª Região SECRETARIA DE TECNOLOGIA DA INFORMAÇÃO

Poder Judiciário. Justiça do Trabalho. Tribunal Regional do Trabalho da 24ª Região SECRETARIA DE TECNOLOGIA DA INFORMAÇÃO Poder Judiciário Justiça do Trabalho Tribunal Regional do Trabalho da 24ª Região SECRETARIA DE TECNOLOGIA DA INFORMAÇÃO DIVISÃO DE SISTEMAS E INTERNET METODOLOGIA DE PRODUÇÃO DE SOFTWARE Versão 1.0 APROVAÇÃO

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

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

FINANÇAS EM PROJETOS DE TI

FINANÇAS EM PROJETOS DE TI FINANÇAS EM PROJETOS DE TI 2012 Material 1 Prof. Luiz Carlos Valeretto Jr. 1 E-mail valeretto@yahoo.com.br Objetivo Objetivos desta disciplina são: reconhecer as bases da administração financeira das empresas,

Leia mais

Documentação de um Produto de Software

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

Leia mais

Metodologia de Desenvolvimento de Software (MDS) do DNIT

Metodologia de Desenvolvimento de Software (MDS) do DNIT Versão 1.02 Metodologia de Desenvolvimento de Software (MDS) do DNIT Projeto: FUB/DNIT Emissão: 08/06/2015 Arquivo: MDS DNIT v1.02 20150701a - revisado e formatado (2).doc 1/86 FICHA TÉCNICA Grupo de Trabalho

Leia mais

Unified Process. Sueleni Mendez Batista. Orientadora: Dra. Elisa Hatsue Moriya Huzita

Unified Process. Sueleni Mendez Batista. Orientadora: Dra. Elisa Hatsue Moriya Huzita Unified Process Sueleni Mendez Batista Orientadora: Dra. Elisa Hatsue Moriya Huzita Processo de Desenvolvimento de Software 8O processo de desenvolvimento de software é um conjunto de atividades e resultados

Leia mais

Histórico da Revisão. Versão Descrição Autor. 1.0 Versão Inicial

Histórico da Revisão. Versão Descrição Autor. 1.0 Versão Inicial 1 of 14 27/01/2014 17:33 Sistema de Paginação de Esportes Universitários Documento de Arquitetura de Software Versão 1.0 Histórico da Revisão Data 30 de novembro de 1999 Versão Descrição Autor 1.0 Versão

Leia mais

Engenharia de Software na Prática Hélio Engholm Jr.

Engenharia de Software na Prática Hélio Engholm Jr. Engenharia de Software na Prática Hélio Engholm Jr. Novatec Sumário Agradecimentos... 17 Sobre o autor... 18 Prefácio... 19 Capítulo 1 Desenvolvimento de software para o valor de negócios... 20 1.1 Qualidade

Leia mais

UNIVERSIDADE ESTADUAL DE MARINGÁ CENTRO DE TECNOLOGIA DEPARTAMENTO DE INFORMÁTICA ENGENHARIA DE SOFTWARE III

UNIVERSIDADE ESTADUAL DE MARINGÁ CENTRO DE TECNOLOGIA DEPARTAMENTO DE INFORMÁTICA ENGENHARIA DE SOFTWARE III UNIVERSIDADE ESTADUAL DE MARINGÁ CENTRO DE TECNOLOGIA DEPARTAMENTO DE INFORMÁTICA ENGENHARIA DE SOFTWARE III FERRAMENTAS DE GERENCIAMENTO DE PROJETOS TRAC E DOTPROJECT ORIETADOS AO RUP ACADÊMICOS: GUSTAVO

Leia mais

METODOLOGIA DE DESENVOLVIMENTO DE SISTEMAS

METODOLOGIA DE DESENVOLVIMENTO DE SISTEMAS METODOLOGIA DE DESENVOLVIMENTO DE SISTEMAS VERSÃO 2.0 MDS 12/3/2013 2.0 1/79 SUMÁRIO 1. INTRODUÇÃO... 4 2. OBJETIVO... 4 3. TIPOS DE DEMANDA DE SISTEMA DA DET... 5 3.1 Novo Sistema... 5 3.2 Sustentação

Leia mais

Msc. Daniele Carvalho Oliveira Doutoranda em Ciência da Computação UFU Mestre em Ciência da Computação UFU Bacharel em Ciência da Computação UFJF

Msc. Daniele Carvalho Oliveira Doutoranda em Ciência da Computação UFU Mestre em Ciência da Computação UFU Bacharel em Ciência da Computação UFJF Msc. Daniele Carvalho Oliveira Doutoranda em Ciência da Computação UFU Mestre em Ciência da Computação UFU Bacharel em Ciência da Computação UFJF 1. Identificação de um problema a ser implementado 2. Análise

Leia mais

Gerenciamento de Projetos Modulo I Conceitos Iniciais

Gerenciamento de Projetos Modulo I Conceitos Iniciais Gerenciamento de Projetos Modulo I Conceitos Iniciais Prof. Walter Cunha falecomigo@waltercunha.com http://waltercunha.com Bibliografia* Project Management Institute. Conjunto de Conhecimentos em Gerenciamento

Leia mais

Engenharia de Software. Parte I. Introdução. Metodologias para o Desenvolvimento de Sistemas DAS 5312 1

Engenharia de Software. Parte I. Introdução. Metodologias para o Desenvolvimento de Sistemas DAS 5312 1 Engenharia de Software Parte I Introdução Metodologias para o Desenvolvimento de Sistemas DAS 5312 1 Mitos do Desenvolvimento de Software A declaração de objetivos é suficiente para se construir um software.

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

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

ENGENHARIA DE SOFTWARE Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br

ENGENHARIA DE SOFTWARE Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br - MÓDULO 2 - ANÁLISE DE REQUISITOS DE SOFTWARE APLICATIVO 1. INTRODUÇÃO Entender os requisitos de um problema está entre as tarefas mais difíceis na construção de um software. Na maioria das vezes o cliente

Leia mais

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

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

Leia mais

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

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

Leia mais

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

TERMO DE REFERÊNCIA. 1. Objeto. 2. Antecedentes. 3. Objeto da Licitação

TERMO DE REFERÊNCIA. 1. Objeto. 2. Antecedentes. 3. Objeto da Licitação TERMO DE REFERÊNCIA 1. Objeto 1.1. Contratação de empresa especializada em auditoria de tecnologia da informação e comunicações, com foco em segurança da informação na análise de quatro domínios: Processos

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

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

ALESSANDRO RODRIGO FRANCO FERNANDO MARTINS RAFAEL ALMEIDA DE OLIVEIRA

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

Leia mais

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

Algumas propriedades dos objetos:

Algumas propriedades dos objetos: Orientação a Objetos Vivemos num mundo de objetos. Esses objetos existem na natureza, nas entidades feitas pelo homem, nos negócios e nos produtos que usamos. Eles podem ser categorizados, descritos, organizados,

Leia mais

SABiO: Systematic Approach for Building Ontologies

SABiO: Systematic Approach for Building Ontologies SABiO: Systematic Approach for Building Ontologies Ricardo de Almeida Falbo Engenharia de Ontologias Departamento de Informática Universidade Federal do Espírito Santo Agenda Preocupações Principais do

Leia mais

Professor: Disciplina:

Professor: Disciplina: Professor: Curso: Disciplina: Marcos Morais de Sousa marcosmoraisdesousa@gmail.com marcosmoraisdesousa.blogspot.com Sistemas de informação Engenharia de Software II Gerenciamento de Qualidade CMMI e MPS.BR

Leia mais

Plano de Projeto. 1. Introdução. 2. Escopo do Projeto. Projeto: Biblioteca Central da UFES. Versão: 2.0. Responsável: Ricardo de Almeida Falbo

Plano de Projeto. 1. Introdução. 2. Escopo do Projeto. Projeto: Biblioteca Central da UFES. Versão: 2.0. Responsável: Ricardo de Almeida Falbo Plano de Projeto Projeto: Biblioteca Central da UFES Versão: 2.0 Responsável: Ricardo de Almeida Falbo 1. Introdução Este documento apresenta a versão 2.0 do Plano de Projeto para o projeto de desenvolvimento

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

Engenharia de Software I

Engenharia de Software I Engenharia de Software I Rogério Eduardo Garcia (rogerio@fct.unesp.br) Bacharelado em Ciência da Computação Aula 03 In a calm sea every man is a pilot. Engenharia de Software I Aula 3 Gerenciamento de

Leia mais

Plano de Gerência de Configuração

Plano de Gerência de Configuração Plano de Gerência de Configuração Objetivo do Documento Introdução A aplicação deste plano garante a integridade de códigos-fonte e demais produtos dos sistemas do, permitindo o acompanhamento destes itens

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

Estudo de Caso da Implantação do Nível G do MPS.BR em Uma Empresa

Estudo de Caso da Implantação do Nível G do MPS.BR em Uma Empresa Estudo de Caso da Implantação do Nível G do MPS.BR em Uma Empresa Dayana Henriques Fonseca 1, Frederico Miranda Coelho 1 1 Departamento de Ciência da Computação Universidade Presidente Antônio Carlos (UNIPAC)

Leia mais

08/09/2011 GERÊNCIA DA INTEGRAÇÃO PMBOK GESTÃO DE PROJETOS

08/09/2011 GERÊNCIA DA INTEGRAÇÃO PMBOK GESTÃO DE PROJETOS GESTÃO DE PROJETOS Prof. Me. Luís Felipe Schilling "Escolha batalhas suficientemente grandes para importar, suficientemente pequenas para VENCER." Jonathan Kozol GERÊNCIA DA INTEGRAÇÃO PMBOK 1 GERÊNCIA

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

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

FIC Faculdade Integrada do Ceará Curso em tecnologia em analise e desenvolvimento de sistemas. OpenUp. Arquitetura de software

FIC Faculdade Integrada do Ceará Curso em tecnologia em analise e desenvolvimento de sistemas. OpenUp. Arquitetura de software FIC Faculdade Integrada do Ceará Curso em tecnologia em analise e desenvolvimento de sistemas OpenUp Arquitetura de software Fortaleza/2010 OpenUP Alguns anos atrás, vários funcionários da IBM começaram

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

CONCORRÊNCIA AA Nº 05/2009 BNDES ANEXO IV PROJETO BÁSICO: PROCESSO DE DESENVOLVIMENTO DE PROJETOS. Sumário

CONCORRÊNCIA AA Nº 05/2009 BNDES ANEXO IV PROJETO BÁSICO: PROCESSO DE DESENVOLVIMENTO DE PROJETOS. Sumário CONCORRÊNCIA AA Nº 05/2009 BNDES ANEXO IV PROJETO BÁSICO: PROCESSO DE DESENVOLVIMENTO DE PROJETOS Sumário 1. DIRETRIZES PARA O PROCESSO DE DESENVOLVIMENTO DE PROJETOS DE APLICATIVOS...172 1.1. INTRODUÇÃO...172

Leia mais

Fundamentos de Teste de Software

Fundamentos de Teste de Software Núcleo de Excelência em Testes de Sistemas Fundamentos de Teste de Software Módulo 2- Teste Estático e Teste Dinâmico Aula 3 Teste Estático SUMÁRIO INTRODUÇÃO... 3 1. Definição... 3 2. Custo Versus Benefício...

Leia mais

Engenharia de Requisitos

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

Leia mais

Engenharia de Sistemas de Computador

Engenharia de Sistemas de Computador Engenharia de Sistemas de Computador Sistema é um conjunto ou disposição de elementos que é organizado para executar certo método, procedimento ou controle ao processar informações. Assim, o que é um Sistema????????

Leia mais

Módulo 3: Gerenciamento da Qualidade, dos Recursos Humanos e das Comunicações

Módulo 3: Gerenciamento da Qualidade, dos Recursos Humanos e das Comunicações ENAP Diretoria de Desenvolvimento Gerencial Coordenação Geral de Educação a Distância Gerência de Projetos - Teoria e Prática Conteúdo para impressão Módulo 3: Gerenciamento da Qualidade, dos Recursos

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

Gerenciamento de Configuração de Software

Gerenciamento de Configuração de Software Gerenciamento de Configuração de Software Prof. Ricardo Argenton Ramos [Baseado na apresentação do prof. Masiero ICMC-USP] Contexto para Gerência de Configuração 2 Problema dos Dados Compartilhados Desenvolvedor

Leia mais

Metodologia e Gerenciamento do Projeto na Fábrica de Software

Metodologia e Gerenciamento do Projeto na Fábrica de Software .:: Universidade Estadual de Maringá Bacharelado em Informática Eng. de Software III :. Sistema de Gerenciamento de Eventos - Equipe 09 EPSI Event Programming System Interface Metodologia e Gerenciamento

Leia mais

Profa. Celia Corigliano. Unidade IV GERENCIAMENTO DE PROJETOS DE TI

Profa. Celia Corigliano. Unidade IV GERENCIAMENTO DE PROJETOS DE TI Profa. Celia Corigliano Unidade IV GERENCIAMENTO DE PROJETOS DE TI Agenda da disciplina Unidade I Gestão de Projetos Unidade II Ferramentas para Gestão de Projetos Unidade III Gestão de Riscos em TI Unidade

Leia mais