Participantes do Processo de Desenvolvimento de Software

Slides:



Advertisements
Apresentações semelhantes
Desenvolvimento de Sistemas
Advertisements

Engenharia de Software
Introdução à Análise de Sistemas
Os projetos.
Empresa Classe Mundial e Analista de Negócio
Engenharia de Software
Objetivos do Capítulo Utilizar o processo de desenvolvimento de sistemas delineado neste capítulo e o modelo de componentes de SI, do Capítulo 1, como.
Especificação de Requisitos
Engenharia de Requisitos
Análise Estruturada Moderna
Validação de Requisitos
Especificação de Processos
Testando o sistema Teste funcional: o sistema integrado realiza as funções especificadas nos requisitos? Teste de desempenho: os requisitos não-funcionais.
Sistema Gerenciador de Ocorrências
Contabilidade Sistemas de Informação
Tópicos Motivação para teste Por que algumas empresas não testam
Engenharia de Software
Professor Sílder Lamas Vecchi
Faculdade de Ciências Sociais e Aplicadas de Petrolina – FACAPE
Adélia Barros Requisitos Adélia Barros
APRESENTAÇÃO DE ESTÁGIO
Professor: Rogério Lopes Disciplina: Engenharia de Software II Fortium Sistemas da Informação Engenharia de Software II.
O processo de coletar os requisitos (escopo do cliente)
Implementação de Sistemas
Prof. Everton Lopes Bonifácio
TIPOS DE TESTES APLICÁVEIS E NÃO APLICÁVEIS AO PROJETO
TSDD Teste de segurança durante o desenvolvimento.
Visão Geral do Desenvolvimento de Sistemas e Papéis no Desenvolvimento de Software Marcely Dias
Metodologia Versão 2 FSRS.
Análise e Gerenciamento de Requisitos com Casos de Uso Módulo 0 Sobre o Curso.
Modelos de Processos de Software
Engenharia de Software
Sistema de Informação Gerencial (SIG)
RUP - Cap. 2 – Os 4 P’s (Pessoas, Projeto, Produto e Processo)
Fundamentos da Auditoria de Sistemas de Informação
Engenharia de Software
Prof.Alfredo Parteli Gomes
Planejamento e Gerenciamento de Projetos
Processos de Desenvolvimento de Software – Parte 2
IEEE Std IEEE Melhores Práticas para Especificações de Requisitos de Software (ERS)
Análise e Projeto de Sistemas
Arquitetura do Software
ANÁLISE E DESENVOLVIMENTO
O Processo de desenvolvimento de software
Marcio de Carvalho Victorino Processo Unificado. Unidade VI: Teste.
The Avengers Testers Team. Diraci Junior Trindade da Silva Analista de Qualidade CWI Software Coordenador do GUTS-rs
Documentação de Software
Teste de Software Conceitos iniciais.
O Processo Unificado (UP)
Sistemas operacionais
Engenharia de Software
O que é? É o processo de investigação técnica com intuito de identificar a qualidade, a segurança e a exatidão do software desenvolvido. A validação do.
Análise e Projeto de Sistemas de Informação 2o. Semestre de 2014 Material criado por Prof. Edinelson Revisão e atualização: Prof. Gustavo Gonzalez Faculdade.
Objetivos do Capítulo Explicar a importância da implementação de processos e tecnologias de gerenciamento de dados numa organização. Explicar as vantagens.
Engenharia de Software
Processo de Desenvolvimento de Software – PDS C Construção - PAS
Programa de Pós-Graduação em Engenharia de Produção - UNIFEI
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE AULA 5
Gestão de projetos de Software GTI-16
ANÁLISE E MODELAGEM DE SISTEMAS I
ALOCAÇÃO DE RECURSOS Suporte material que o processo precisa para ser executado e poder cumprir as metas preestabelecidas. São equipamentos, instalações.
Introdução aos Sistemas Operacionais
SISTEMA DE MONITORAMENTO DA TECNOLOGIA DA INFORMAÇÃO.
Aula 02 de Eng. de Requisitos
Análise e Projeto de Sistemas Análise e Projeto de Sistemas Aula 2 Professor: Italo Rodrigues Castro.
ISO9001:2000 para Software Professor: Alexandre Vasconcelos Equipe: Amanda Pimentel Börje Karlsson Danielly Karine Erika Pessoa Jorge Cavalcanti Jose Edson.
SECRETARIA DA FAZENDA DO ESTADO DE SÃO PAULO Gerenciamento de Serviços de TI - Evolução, Lições Aprendidas e Resultados Práticos - Dezembro / 2015.
Eduardo C. Nicácio ITIL v3 Foundation Certified.  As melhores práticas do ITIL abrangem cinco processos de suporte a serviços, além do papel do Service.
1 Projeto Piloto Conclusão em Agenda Projeto Piloto –Descrição –Execução da aplicação –Implementação de requisitos funcionais e não- funcionais.
ROTEIRO PARA ELABORAÇÃO DE SISTEMA ESTRUTURADO
Transcrição da apresentação:

Participantes do Processo de Desenvolvimento de Software Eveline Alonso Veloso PUC-Minas

Bibliografia YOURDON, Edward. Análise Estruturada Moderna. Rio de Janeiro: Campus, 1992. Capítulo 3.

Participantes do Processo de Desenvolvimento de Software Usuários Gerentes Auditores Analistas de Requisitos Arquitetos de Software Programadores Testadores Analistas de Suporte Pessoal de Operação

Usuários Participantes mais importantes do processo de desenvolvimento de software. Grupo de pessoas para o qual o sistema é construído; utilizará o sistema desenvolvido. Sistema surge da solicitação formal de seus futuros usuários. O usuário nem sempre é o cliente.

Usuários O analista de requisitos deve realizar entrevistas/reuniões; diretamente com os futuros usuários do sistema; sob pena de não conseguir especificar adequadamente os requisitos desse sistema. Intermediários podem não conhecer os verdadeiros requisitos do sistema. Após as entrevistas/reuniões, é aconselhável que o analista de requisitos produza documentações/atas formais.

Tipos de Usuários Por tipo de função: Usuário Operacional Usuário Supervisor Usuário Executivo Por nível de experiência em tecnologia da informação: Amador Novato “Arrogante” Familiarizado com TI

Usuários Operacionais Normalmente, terão contato diário com o sistema; irão operar o sistema. Preocupados com aspectos relacionados às: interfaces de usuário (telas e relatórios); visão física do sistema; têm, em geral, dificuldades para realizar abstrações; funcionalidades do sistema.

Usuários Operacionais Possuem visão local detalhada das tarefas que realizam; mas não do funcionamento de todo o sistema. O sistema fará parte das tarefas que eles realizam atualmente manualmente. Freqüentemente, demonstram medo de serem substituídos pelo sistema; dificultando, às vezes, seu processo de especificação e modelagem.

Usuários Supervisores Gerenciam um grupo de usuários operacionais; sendo responsáveis por seu desempenho. Usuários de nível gerencial. Muitas vezes, são os intermediários entre o analista de requisitos e os usuários operacionais.

Usuários Supervisores Nem sempre conhecem bem o trabalho dos usuários operacionais; e as tarefas que o sistema deve contemplar. Podem ou não ter visão local do sistema. Supervisores e usuários operacionais podem ter objetivos diferentes. Supervisores podem ter como objetivo: redução do número de usuários operacionais; aumento, com o sistema, da produtividade de seu setor.

Usuários Executivos Visão global e abstrata. Preocupações estratégicas; e de longo prazo. Na maioria das vezes, nunca foram usuários operacionais; não conhecem detalhadamente a operação do sistema; não definem requisitos; não estão diretamente envolvidos.

Usuários Executivos Dão suporte ao projeto. Representam a autoridade financeira do projeto. Estabelecem prazos.

Usuários – Níveis de Experiência em Tecnologia da Informação Amador: Nunca utilizou um computador; ou o utiliza rara e restritamente. Não compreende as técnicas de modelagem. Novato “Arrogante”: Possui alguns conhecimentos em tecnologia. Pode se preocupar demais com a solução tecnológica.

Usuários – Níveis de Experiência em Tecnologia da Informação Novato “Arrogante”: Pode dar diversos palpites sobre a forma de modelar o sistema; sem, no entanto, conhecer adequadamente as técnicas de modelagem. Familiarizado com TI: Possui conhecimentos avançados em tecnologia. Pode se preocupar demais com a solução tecnológica.

Gerentes de Projetos Responsáveis pelo projeto de desenvolvimento do sistema; e pela alocação de recursos de toda a equipe técnica no desenvolvimento desse sistema. Interface do projeto. Em geral, para cada projeto há um gerente de projeto: na organização desenvolvedora de software; e outro na organização cliente. Controlam os recursos do projeto.

Outros Gerentes Definem: objetivos; prioridades; prazo; orçamento. Pode haver conflitos entre os diversos níveis gerenciais. Decidem sobre a continuidade; ou interrupção do projeto de desenvolvimento do sistema.

Auditores Compreendem: Identificam problemas. auditores internos; auditores externos; grupo de garantia da qualidade. Identificam problemas. Devem ter postura isenta e imparcial. Garantem o desenvolvimento dos sistemas de acordo com padrões: externos; da própria empresa.

Analistas de Requisitos Especificam o problema dos usuários. Atuam como mediadores; entre os diversos participantes de um projeto. Devem possuir: aptidões interpessoais; conhecimento de tecnologia; raciocínio lógico e abstrato; criatividade; capacidade de mediação.

Analistas de Requisitos Em um projeto de desenvolvimento de sistema, os analistas de requisitos lidam com diferentes pessoas. Devem ficar atentos se: a linguagem utilizada é familiar a essas pessoas; os modelos e documentos apresentados são familiares a essas pessoas; e estão sendo compreendidos por elas.

Arquitetos de Software Recebem o resultado do trabalho do analista de requisitos. Utilizam os requisitos do usuário; para criar um projeto arquitetural do sistema; que servirá como base para o trabalho dos programadores.

Arquitetos de Software Constante interação entre o arquiteto de software e o analista de requisitos. Verificam se os requisitos especificados são viáveis. Se os requisitos não forem tecnicamente viáveis; o analista de requisitos pode ter que negociar com o usuário uma mudança nos requisitos.

Programadores Codificam o sistema; Conhecem mais da tecnologia; a partir do trabalho do arquiteto de software. Conhecem mais da tecnologia; e menos do negócio do cliente. Muitas vezes descobrem erros e ambigüidades no trabalho do analista de requisitos. Interagem com o analista de requisitos quando existe a necessidade de realizar alguma correção nos modelos de análise.

Testadores Testam os componentes de código desenvolvidos a procura de erros; inclusive erros de não-conformidade do produto com seus requisitos.

Analistas de Suporte Pouco contato com o usuário. Às vezes, o sistema apresenta alguma restrição; por causa do ambiente de operação. Exemplos: DBA; Analista de Desempenho; Analista de Redes; etc.

Pessoal de Operação Técnicos responsáveis por: backup; atualizações de versões; instalação de ferramentas; manutenção dos equipamentos; controle de impressão; etc.