3ª ETAPA ATPS - TADS 5º Sem. FAC 3 - Engenharia de Software e Gerência de Projetos
Felipe Soares - 0836162
William Ribeiro - 0919453818
Tiago Luis - 0924437995
Henrique Estevam - 0901416966
Cesar Fernandes - 1060132900
Relatório 3 - Cronograma De Atividades Do Projeto
Este documento possui o cronograma de atividades do projeto baseado nas informações acordadas no relatório de escopo do projeto:
1. Atividades Do Projeto
Análise de requisitos de software 12 03/03/2011 15/03/2011
Ajuste do escopo 1 15/03/2011 16/03/2011
Atualização da estimativa de custo 1 16/03/2011 17/03/2011
Validação da estimativa de custo 1 17/03/2011 18/03/2011
Elaboração das especificações 7 18/03/2011 25/03/2011
Elaboração dos casos de uso 2 25/03/2011 27/03/2011
Elaboração da arquitetura do software 6 27/03/2011 02/04/2011
Elaboração de protótipo 8 02/04/2011 10/04/2011
Validação do protótipo 2 10/04/2011 12/04/2011
Atualizações para codificação 1 12/04/2011 13/04/2011
Implementaçao do software 23 13/04/2011 06/05/2011
Realizaçao de testes 7 06/05/2011 13/05/2011
Homologação 2 13/05/2011 15/05/2011
Elaboração da documentação 7 15/05/2011 22/05/2011
Validação dos documentos 1 22/05/2011 23/05/2011
Realizaçao de treinamento 7 23/05/2011 30/05/2011
Migração de sistemas e processos de legado 9 30/05/2011 08/06/2011
Implantação do software 2 08/06/2011 10/06/2011
Suporte pós migração 7 10/06/2011 17/06/2011
Manutenção pós migração 7 17/06/2011 24/06/2011
Relatório 4 – Gerência De Riscos Do Projeto
Este documento possui o levantamento de possíveis riscos que podem prejudicar a execução do projeto e a definição do plano de ação para cada um deles caso ocorram:
1. Riscos
Mudança do escopo do projeto
Baixo nível de envolvimento do cliente no projeto
Introdução de uma nova tecnologia
Falta de acesso aos usuários finais do sistema
Substituição do gerente de projetos
2. Plano De Ação ( respectivamente )
Será necessário adequar os requisitos do projeto, bem como seu cronograma de execução e projeção de custos estimados para o mesmo pois será necessário alocar novos recursos a equipe e aumentar as horas de trabalho para execução das atividades
Propor reuniões de alinhamento com aumento na freqüência dos encontros e pontos de controle, realizando uma aproximação com o cliente para proporcionar um maior envolvimento do mesmo no decorrer dos principais pontos do projeto
Busca de uma parceria de mercado ou especialização da equipe do projeto para atender a novos requisitos necessários a nova tecnologia
Efetuar negociação da liberação do recurso ou do repasse necessário das informações que serão levantadas com um usuário final que tenha maios conhecimento dos processos envolvidos na atividade que será executada
Trabalhar com a parceria de um gerente back up que será envolvido durante todas as principais etapas do projeto criando um espelho das principais informações e decisões que serão tomadas durante o projeto
domingo, 17 de abril de 2011
quinta-feira, 14 de abril de 2011
Engenharia de Requisitos e Documentação
Engenharia de Requisitos e Documentação
Carlos Eduardo Domingos da Silva RA: 0950087
Engenharia de Requisitos
A Engenharia de Requisitos pode ser vista como uma subárea da Engenharia de Software e seu principal objetivo é a obtenção de uma especificação correta e completa dos requisitos, para isso é preciso criar e manter documentos de requisitos de sistemas, chamado de Documento de Especificações de Requisitos de Software (DERS).
No processo de Engenharia de Software conhecido como Ciclo de Vida Clássico, que também pode ser executado varias vezes como parte integrante de um ciclo de vida iterativo e incremental, a Engenharia de Requisitos se encontra na primeira fase, a fase de Análise.
A Engenharia de Requisitos se divide em três fases principais: Elicitação, especificação e validação, sendo que cada fase é subdividida em subfases, o processo de engenharia de requisitos é iterativo, ou seja, pode-se voltar a uma fase que já foi feita, como em uma espiral.
Quanto a Elicitação
Suas principais metas são: identificar os objetivos do sistema a ser construído (O que ele deve fazer, suas funções) e como ele se encaixa nas necessidades de negócio do cliente. Para isso as “primeiras perguntas” darão apenas um entendimento básico do problema, sendo assim é preciso utilizar abordagens mais sofisticadas, tais como:
· Elicitação Colaborativa;
· Implantação de Funções de Qualidade;
· Casos de Uso;
· Amostragem;
· Investigação;
· Entrevista;
· Questionário;
· Observação;
· Prototipação.
Quanto a Especificação
É o produto final da Engenharia de Requisitos e a base pra todas as fases seguintes do processo de Engenharia de Software.
Uma especificação pode ser:
· Um documento escrito;
· Modelos gráficos;
· Um modelo formal matemático;
· Um protótipo;
· Qualquer combinação dos itens acima.
As especificações podem incluir:
· Justificativa de necessidade e factibilidade;
· Definição do escopo;
· Stakeholders que participaram da elicitação;
· Requisitos e suas restrições de domínio;
· Condições de desempenho, segurança e etc.;
· Casos de uso;
· Protótipos.
Quanto a Validação
É a revisão do projeto para averiguar se:
· Todos os requisitos foram elencados sem ambiguidade;
· Inconsistências, omissões e erros foram detectados e corrigidos;
· Tudo está documentado de acordo com os padrões da empresa.
Para isso, é fundamental responder algumas perguntas como:
ü Os requisitos estão claramente descritos? Podem ser interpretados incorretamente?
ü As fontes dos requisitos foram identificadas? Elas validaram os requisitos?
ü Este requisito viola alguma restrição de domínio do sistema?
ü É possível testar esse requisito?
ü A especificação esta bem estruturada de forma a facilitar as próximas fases?
ü Etc.
Para produzir um Documento de Especificações de Requisitos do Software (DERS) bem estruturado foi criado um modelo padrão de documentação pelo IEEE.
DERS
DERS é a documentação que especifica os requisitos do sistema.
Segundo o IEEE (institute of Electrical and Eletronics Engineers), o DERS deve ser completo e não ambíguo. Ele deve auxiliar o cliente a descrever como precisão o que ele deseja, e ao desenvolvedor a entender o que o cliente deseja.
Além disso o DERS deve possuir algumas características especificas como:
· Acordar entre cliente e empresa fornecedora o que o software ira fazer.
· Reduzir o esforço do desenvolvimento.
· Prever e estimar os custos e o prazo.
· Facilitar a manutenção.
O DERS deve possuir padrões para sua elaboração. O IEEE elaborou um documento com padrões e praticas recomendadas.
INTRODUÇÃO
· Proposito = mostrar para que e para quem o software esta sendo feito.
· Escopo = especificar o software, nomeá-lo, explicar o que ira fazer, e ou, o que não ira, descrever as aplicações, benefícios, objetivos e metas.
· Definições siglas e abreviaturas = definir todos os termos, siglas e abreviaturas para entender o DERS.
· Referencias = listas os documentos referenciados no DERS, identificado por autor, titulo, data, editora, organização, entre outros.
· Visão global = apresentar de forma resumida o que os capítulos restantes do DERS ira tratar.
DESCRIÇÃO GERAL
· Perspectiva do produto = comparar o software com outros relacionados. Se for independente isso deve constar. Menções a sistemas maiores que o mesmo seja parte também deve-se constar.
· Funções do produto = criar um índice das principais funções do software.
· Restrições = descrever qualquer outro item que limite as opções do produto, como politicas de controle, limitações do hardware, interface com outros aplicativos, entre outros.
· Pressupostos e dependências = listar todos os fatores que afetam os requisitos definidos.
REQUISITOS ESPECIFICOS
· Conter a definição dos principais requisitos de software. Principal capítulo do DERS, pois, os requisitos funcionais e não funcionais aqui serão definidos.
Esse é o modelo do IEEE. Cockburn (2005) apresenta uma complementação a este modelo, incluindo um capitulo para casos de uso.
Casos de uso servem para interação entre o sistema e o usuário. Descritos geralmente em forma textual, mais também podem ser descritos através de fluxogramas, diagramas, entre outros.
INSPEÇÃO DO DERS
A inspeção do DERS é muito importante para o sucesso do mesmo. Deve-se avaliar o documento como um todo em busca de defeitos antes de ser validado junto ao cliente.
Os erros encontrados em um DERS podem ser:
· Omissão
· Ambiguidade
· Fato incorreto
· Informação estranha
ATPS_3º Etapa
ATPS_3º Etapa
Metodologias, técnicas e ferramentas da gerência de projetos.
Flávio Roberto Pereira_0991003869
Tatiane Regina Baldin_0940481012
Jhonata Camargo_0950246
Rafael Gonçalves_0901341313
Edilson Junior_0901397652
Allan Colletto_0959526403
Kleber Martins_0970475207
• Desenvolvimento de software
Na computação, o desenvolvimento de software é o ato de elaborar e implementar um sistema computacional, isto é, transformar a necessidade de um utilizador ou de um mercado em um produto de software.
Também é entendido como a aplicação dos processos da engenharia de software combinados com a pesquisa das necessidades do produto para desenvolver software.
É difícil avaliar se a engenharia (de software) ou o Marketing é o maior responsável pelo sucesso ou falha de um produto de software para satisfazer as expectativas do consumidor. Por isso é importante entender tanto os processos quanto as facilidades de colaboração entre a engenharia e o marketing em todo o processo de desenvolvimento.
• Definição do escopo do projeto
O escopo descreve todos os produtos de um projeto, os serviços necessários para realizá-los e resultados finais esperados. Descreve também o que é preciso fazer para que alcance seus objetivos com os recursos e funções especificados.
• Requisitos
Requisitos definem as capacidades que o sistema deve apresentar. Normalmente, a adequação ou não do sistema ao conjunto de requisitos determina o sucesso ou o fracasso dos projetos. Assim, é importante descobrir quais são os requisitos do sistema, descrevê-los, organizá-los, e rastrear os eventos que provocam as suas mudanças. Dessa forma, define-se Gerenciamento de Requisitos como:
Uma abordagem sistemática de elucidar, organizar e documentar os requisitos do sistema; e
Um processo que estabelece e mantém um contrato entre cliente e a equipe de projeto sobre as mudanças de requisitos do sistema.
• Desenvolvimento
Um processo de desenvolvimento de software é um conjunto de atividades, parcialmente ordenadas, com a finalidade de obter um produto de software. É estudado dentro da área de Engenharia de Software, sendo considerado um dos principais mecanismos para se obter software de qualidade e cumprir corretamente os contratos de desenvolvimento, sendo uma das respostas técnicas adequadas para resolver a Crise do software.
• Testes
Uma das fases mais importantes do projeto, nela buscamos fornecer informações sobre sua qualidade em relação ao contexto em que ele deve operar.
No teste são envolvidas ações que vão do levantamento de requisitos até a execução do teste propriamente dito.
• Implantação
Acompanhamento constante para total adaptação ao sistema, instalação do software junto ao cliente.
Será feito um acompanhamento com os usuários de modo que estes consigam sanar dúvidas que surjam após o uso do software.
Toda implantação de software altera a rotina da empresa, causa estress nos funcionários e caso não for bem executada gera dor de cabeça no futuro, gerando prejuízos para ambos os lados, contratante e contratado.
• Gerência de Riscos do Projeto
Em desenvolvimento de software, em geral, não se leva em conta que:
Pessoas adoecem
Ferramentas de desenvolvimento têm bugs e nem sempre são fáceis de usar
Desenvolvedores rendem menos que o esperado
Os requisitos são instáveis e incompletos no momento de se dar preço e prazo
• Integração externa
- Entre os usuários / clientes e equipe de projeto.
- Reuniões freqüentes.
- Prototipação.
- Ter um usuário sempre junto à equipe.
• Integração interna
- Entre membros da equipe de desenvolvimento.
- Maior importância se tecnologia é nova para a equipe.
- Reuniões para troca de experiência técnica.
• Planejamento formal
- Plano detalhado de projeto, atividade por atividade.
- Fácil de implementar em projeto de alta estruturação.
- Difícil em caso de baixa estruturação porque não se sabe direito o que deve ser feito.
• Tipos de risco:
1. Engenharia de produto (riscos técnicos) – questões técnicas que possam atrapalhar o projeto: hardware ou software básico inadequado
2. Ambiente de desenvolvimento (riscos metodológicos) – escolha de técnicas inadequadas, metodologia obsoleta ou recente demais
3. Restrições de projeto (riscos organizacionais) – excesso de política, troca de patrocinadores, prazos inviáveis
Metodologias, técnicas e ferramentas da gerência de projetos.
Flávio Roberto Pereira_0991003869
Tatiane Regina Baldin_0940481012
Jhonata Camargo_0950246
Rafael Gonçalves_0901341313
Edilson Junior_0901397652
Allan Colletto_0959526403
Kleber Martins_0970475207
• Desenvolvimento de software
Na computação, o desenvolvimento de software é o ato de elaborar e implementar um sistema computacional, isto é, transformar a necessidade de um utilizador ou de um mercado em um produto de software.
Também é entendido como a aplicação dos processos da engenharia de software combinados com a pesquisa das necessidades do produto para desenvolver software.
É difícil avaliar se a engenharia (de software) ou o Marketing é o maior responsável pelo sucesso ou falha de um produto de software para satisfazer as expectativas do consumidor. Por isso é importante entender tanto os processos quanto as facilidades de colaboração entre a engenharia e o marketing em todo o processo de desenvolvimento.
• Definição do escopo do projeto
O escopo descreve todos os produtos de um projeto, os serviços necessários para realizá-los e resultados finais esperados. Descreve também o que é preciso fazer para que alcance seus objetivos com os recursos e funções especificados.
• Requisitos
Requisitos definem as capacidades que o sistema deve apresentar. Normalmente, a adequação ou não do sistema ao conjunto de requisitos determina o sucesso ou o fracasso dos projetos. Assim, é importante descobrir quais são os requisitos do sistema, descrevê-los, organizá-los, e rastrear os eventos que provocam as suas mudanças. Dessa forma, define-se Gerenciamento de Requisitos como:
Uma abordagem sistemática de elucidar, organizar e documentar os requisitos do sistema; e
Um processo que estabelece e mantém um contrato entre cliente e a equipe de projeto sobre as mudanças de requisitos do sistema.
• Desenvolvimento
Um processo de desenvolvimento de software é um conjunto de atividades, parcialmente ordenadas, com a finalidade de obter um produto de software. É estudado dentro da área de Engenharia de Software, sendo considerado um dos principais mecanismos para se obter software de qualidade e cumprir corretamente os contratos de desenvolvimento, sendo uma das respostas técnicas adequadas para resolver a Crise do software.
• Testes
Uma das fases mais importantes do projeto, nela buscamos fornecer informações sobre sua qualidade em relação ao contexto em que ele deve operar.
No teste são envolvidas ações que vão do levantamento de requisitos até a execução do teste propriamente dito.
• Implantação
Acompanhamento constante para total adaptação ao sistema, instalação do software junto ao cliente.
Será feito um acompanhamento com os usuários de modo que estes consigam sanar dúvidas que surjam após o uso do software.
Toda implantação de software altera a rotina da empresa, causa estress nos funcionários e caso não for bem executada gera dor de cabeça no futuro, gerando prejuízos para ambos os lados, contratante e contratado.
• Gerência de Riscos do Projeto
Em desenvolvimento de software, em geral, não se leva em conta que:
Pessoas adoecem
Ferramentas de desenvolvimento têm bugs e nem sempre são fáceis de usar
Desenvolvedores rendem menos que o esperado
Os requisitos são instáveis e incompletos no momento de se dar preço e prazo
• Integração externa
- Entre os usuários / clientes e equipe de projeto.
- Reuniões freqüentes.
- Prototipação.
- Ter um usuário sempre junto à equipe.
• Integração interna
- Entre membros da equipe de desenvolvimento.
- Maior importância se tecnologia é nova para a equipe.
- Reuniões para troca de experiência técnica.
• Planejamento formal
- Plano detalhado de projeto, atividade por atividade.
- Fácil de implementar em projeto de alta estruturação.
- Difícil em caso de baixa estruturação porque não se sabe direito o que deve ser feito.
• Tipos de risco:
1. Engenharia de produto (riscos técnicos) – questões técnicas que possam atrapalhar o projeto: hardware ou software básico inadequado
2. Ambiente de desenvolvimento (riscos metodológicos) – escolha de técnicas inadequadas, metodologia obsoleta ou recente demais
3. Restrições de projeto (riscos organizacionais) – excesso de política, troca de patrocinadores, prazos inviáveis
3° etapa do atps
Engenharia de Software
ATPS 3° ETAPA
Daniele Sant’ Ana RA: 0901343786
Elianderson da Luz RA: 0996540533
Gislaine Almeida RA: 0901379702
Leis Melo RA: 0955509608
Rogério Freitas RA: 0906344240
Passo 2: • O levantamento de Requisitos de Software:
O analista terá o objetivo de fazer os requisitos do software com clareza e ao gosto do cliente. Fazer as necessidades do cliente com suas demandas; Determinar especificações para o software; Desenvolver orçamento para o cliente; Desenvolver tempo ao longo e curto prazo de entrega do software;
Compreensão do domínio: Os analistas do projeto densevolvera a sua compreensão do domínio da aplicação;
Coleta de requisitos: É o processo de interagir com o nosso projeto de software para descobrir seus requisitos. E fazer a sua compreensão para o domínio que se desenvolva mais durante a atividade;
Classificação: Essa atividade considera o conjunto não estruturado dos requisitos e os organiza em grupos coerentes;
Resolução de conflitos: Caso haja envolvimentos, o nosso requisito apresentará conflitos. Nossa equipe de projeto para essa atividade tem por objetivo solucionar esses conflitos;
Definição das prioridades: Em qualquer conjunto de requisitos, alguns serão mais importantes do que outros. Esse estágio envolve interação com os stakeholders para a definição dos requisitos mais importantes;
Verificação de requisitos: Os requisitos são verificados para descobrir se estão completos e consistentes e se estão em concordância com o que os stakeholders desejam do sistema.
O levantamento e análise de requisitos é um processo iterativo, com uma contínua validação de uma atividade para outra.
• Técnicas de Levantamento de Requisitos
As técnicas de levantamento de requisitos têm por objetivo superar as dificuldades relativas a esta fase. Todas as técnicas possuem um conceito próprio e suas respectivas vantagens e desvantagens, que podem ser utilizadas em conjunto pelo analista.
Serão apresentadas de forma resumida nesse artigo algumas técnicas de levantamento de requisitos.
O nosso levantamento de requisitos tem o objetivo planejar as atividades relativas. Para que esse objetivo seja alcançado, é necessário o analista de sistema possuir a capacidade de:
Compreender conceitos abstratos reorganizá-los em divisões lógicas e sintetizar soluções baseadas em cada divisão;
Absorver fatos pertinentes de fontes conflitantes ou confusas;
Entender os ambientes do usuário/cliente;
Aplicar elementos do sistema de hardware e/ou software aos elementos do usuário/cliente;
Comunicar bem nas formas escrita e verbal e entender o objetivo global do software.
Gerência de Riscos do Projeto
Os princípios de gerenciamento do risco podem ser aplicados a todos os aspectos do negócio e a todos os ramos de atividade, não ficando limitado ao mundo dos projetos ou mesmo da área de engenharia ou tecnologia. A gestão de risco já está inserida há muito tempo no mundo dos negócios em setores como Seguros, Energia Atômica, Petrolífera entre outros. Estas empresas criaram ao longo do tempo uma cultura de gestão do risco, e praticam esta cultura, pois entendem que este é fundamental para o seu negócio. A importância do gerenciamento de risco agora é evidente no mundo todo. Uma gestão mais eficiente dos riscos, por exemplo, poderia ter evitado grandes prejuízos a acionistas e investidores nestes tempos de crise financeira.
Muitos gerentes de projetos já chegaram a conclusão que a gestão de risco é a ferramenta que lhe permite se sobressair perante outros, pois proporciona capacidade de tomar ações sobre circunstâncias quais levariam o projeto a comprometer seus objetivos.Em uma visão mais abrangente poderíamos dizer que o papel principal do gerente de projetos é gerenciar riscos. O gerente de projetos trabalha para evitar o risco de o cronograma atrasar, risco do custo ficar além do esperado, risco do produto ser entregue com falhas.
Mesmo com a responsabilidade maior sob gerente de projeto, o gerenciamento do risco é uma atividade da equipe, pois permeia todos os outros planos e ações do projeto, entretanto é de sua responsabilidade liderar e manter a gestão de risco como cultura operacional do projeto e levar a alta administração a importância de se gerir riscos.
Na gestão moderna de projetos, os gerentes de projeto têm tratado o gerenciamento de risco de forma burocrática e procedimental, onde a gestão reduz a (1) identificar o risco, (2) desenvolver respostas ao risco e (3) controlar os riscos. O gerente de projeto deve entender que gerir risco é estar além de uma lista de possíveis problemas com suas probabilidades e impactos.
Riscos
Gerência Falta de experiência do gerente de projeto resultará em atraso no cronograma.
Tecnológico A tecnologia empregada é relativamente nova e pouco conhecida dos membros da equipe que pode resultar em atraso.
Equipamento Dispositivos necessários não serão entregues no prazo programado.
Cliente Recursos do cliente não estarão disponíveis como planejado.
Físico Um vírus de computador infectará o ambiente de desenvolvimento do projeto.
Para os riscos apresentados, é importante identificar a probabilidade de sua ocorrência, o impacto que eles podem trazer (ao projeto), o grau de severidade e como eles podem ser administrados. Por exemplo, se considerarmos o risco da perda de um membro importante da equipe, isto pode ser diagnosticado quando ocorrem reclamações por parte do membro da equipe, bem como quando ele solicita ser realocado para outra atividade. Em outras situações, outros gerentes na mesma empresa consultam sobre a disponibilidade de membros de sua equipe. Em tais circunstâncias, o gerente de projeto deve fomentar junto ao grupo o forte senso de trabalho em equipe e também destacar a importância do projeto e a participação dos membros naquela equipe.
Plano de Ação
O plano de ação talvez seja o instrumento mais utilizado na previsão e registro de ações para desenvolvimento de projetos de melhoria. Isso se deve basicamente a:
- simplicidade de preenchimento
- necessidade de poucos dados para gestão
- é feito a partir de textos, não requerendo nenhum software especial
- fácil entendimento dos dados
. O plano é composto por:
• Indicadores de resultado: meio para gerenciar o plano de ação e verificar se resultado está sendo atingido. São eles que quantificam e qualificam o resultado. São fontes importantes para a avaliação.
• Ação: tudo de que necessitamos fazer para atingir o resultado proposto.
• Prazo: data precisa em que o gerenciamento será feito.
• Responsável: pessoa que nem sempre terá de realizar uma ação, mas será
fundamental para que essa ação seja cumprida. O responsável pela ação tem nome e sobrenome, não pode ser o grupo todo.
• Recursos: tudo de que necessitamos para realizar a ação. Não apenas recursos financeiros, mas custo, recursos de conhecimento, tempo em horas, infra-estrutura (sala e material necessário), recursos políticos, de organização ou até uma ação realizadora anteriormente.
Todo Plano de Ação deve estar estruturado para permitir a rápida identificação dos elementos necessários à implementação do projeto.
Existem várias maneiras de se montar um plano de ação, uma delas é o PDCA
que é uma forma simples de realizá-lo, como mostrado abaixo.
Plan (planeamento): estabelecer missão, visão, objetivo(metas),procedimentos
e processos (metodologias) necessárias para o atingimentos dos resultados.
Do (execução): realizar, executar as atividades.
Check (verificação): monitorar e avaliar periodicamenteos resultados, avaliar
processos e resultados, confrontando-os com o planejado, objetivos,
especificações e estado desejado, consolidando as informações, eventualmente confeccionando relatórios.
Act (agir): Agir de acordo com o avaliado e de acordo com os relatórios,
eventualmente determinar e confeccionar novos planos de ação, de forma a
melhorar a qualidade, eficiência e eficácia, aprimorando a execução e corrigindo eventuais falhas.
No giro do PDCA devemos coletar dados, medir resultados compará-los com a
meta considerada e adotar ações apropriadas, portanto, no giro deste ciclo será necessário empregar ferramentas apropriadas para a coleta, o processamento e a disposição de dados, o que permitirá a tomada de decisões confiáveis.
ATPS 3° ETAPA
Daniele Sant’ Ana RA: 0901343786
Elianderson da Luz RA: 0996540533
Gislaine Almeida RA: 0901379702
Leis Melo RA: 0955509608
Rogério Freitas RA: 0906344240
Passo 2: • O levantamento de Requisitos de Software:
O analista terá o objetivo de fazer os requisitos do software com clareza e ao gosto do cliente. Fazer as necessidades do cliente com suas demandas; Determinar especificações para o software; Desenvolver orçamento para o cliente; Desenvolver tempo ao longo e curto prazo de entrega do software;
Compreensão do domínio: Os analistas do projeto densevolvera a sua compreensão do domínio da aplicação;
Coleta de requisitos: É o processo de interagir com o nosso projeto de software para descobrir seus requisitos. E fazer a sua compreensão para o domínio que se desenvolva mais durante a atividade;
Classificação: Essa atividade considera o conjunto não estruturado dos requisitos e os organiza em grupos coerentes;
Resolução de conflitos: Caso haja envolvimentos, o nosso requisito apresentará conflitos. Nossa equipe de projeto para essa atividade tem por objetivo solucionar esses conflitos;
Definição das prioridades: Em qualquer conjunto de requisitos, alguns serão mais importantes do que outros. Esse estágio envolve interação com os stakeholders para a definição dos requisitos mais importantes;
Verificação de requisitos: Os requisitos são verificados para descobrir se estão completos e consistentes e se estão em concordância com o que os stakeholders desejam do sistema.
O levantamento e análise de requisitos é um processo iterativo, com uma contínua validação de uma atividade para outra.
• Técnicas de Levantamento de Requisitos
As técnicas de levantamento de requisitos têm por objetivo superar as dificuldades relativas a esta fase. Todas as técnicas possuem um conceito próprio e suas respectivas vantagens e desvantagens, que podem ser utilizadas em conjunto pelo analista.
Serão apresentadas de forma resumida nesse artigo algumas técnicas de levantamento de requisitos.
O nosso levantamento de requisitos tem o objetivo planejar as atividades relativas. Para que esse objetivo seja alcançado, é necessário o analista de sistema possuir a capacidade de:
Compreender conceitos abstratos reorganizá-los em divisões lógicas e sintetizar soluções baseadas em cada divisão;
Absorver fatos pertinentes de fontes conflitantes ou confusas;
Entender os ambientes do usuário/cliente;
Aplicar elementos do sistema de hardware e/ou software aos elementos do usuário/cliente;
Comunicar bem nas formas escrita e verbal e entender o objetivo global do software.
Gerência de Riscos do Projeto
Os princípios de gerenciamento do risco podem ser aplicados a todos os aspectos do negócio e a todos os ramos de atividade, não ficando limitado ao mundo dos projetos ou mesmo da área de engenharia ou tecnologia. A gestão de risco já está inserida há muito tempo no mundo dos negócios em setores como Seguros, Energia Atômica, Petrolífera entre outros. Estas empresas criaram ao longo do tempo uma cultura de gestão do risco, e praticam esta cultura, pois entendem que este é fundamental para o seu negócio. A importância do gerenciamento de risco agora é evidente no mundo todo. Uma gestão mais eficiente dos riscos, por exemplo, poderia ter evitado grandes prejuízos a acionistas e investidores nestes tempos de crise financeira.
Muitos gerentes de projetos já chegaram a conclusão que a gestão de risco é a ferramenta que lhe permite se sobressair perante outros, pois proporciona capacidade de tomar ações sobre circunstâncias quais levariam o projeto a comprometer seus objetivos.Em uma visão mais abrangente poderíamos dizer que o papel principal do gerente de projetos é gerenciar riscos. O gerente de projetos trabalha para evitar o risco de o cronograma atrasar, risco do custo ficar além do esperado, risco do produto ser entregue com falhas.
Mesmo com a responsabilidade maior sob gerente de projeto, o gerenciamento do risco é uma atividade da equipe, pois permeia todos os outros planos e ações do projeto, entretanto é de sua responsabilidade liderar e manter a gestão de risco como cultura operacional do projeto e levar a alta administração a importância de se gerir riscos.
Na gestão moderna de projetos, os gerentes de projeto têm tratado o gerenciamento de risco de forma burocrática e procedimental, onde a gestão reduz a (1) identificar o risco, (2) desenvolver respostas ao risco e (3) controlar os riscos. O gerente de projeto deve entender que gerir risco é estar além de uma lista de possíveis problemas com suas probabilidades e impactos.
Riscos
Gerência Falta de experiência do gerente de projeto resultará em atraso no cronograma.
Tecnológico A tecnologia empregada é relativamente nova e pouco conhecida dos membros da equipe que pode resultar em atraso.
Equipamento Dispositivos necessários não serão entregues no prazo programado.
Cliente Recursos do cliente não estarão disponíveis como planejado.
Físico Um vírus de computador infectará o ambiente de desenvolvimento do projeto.
Para os riscos apresentados, é importante identificar a probabilidade de sua ocorrência, o impacto que eles podem trazer (ao projeto), o grau de severidade e como eles podem ser administrados. Por exemplo, se considerarmos o risco da perda de um membro importante da equipe, isto pode ser diagnosticado quando ocorrem reclamações por parte do membro da equipe, bem como quando ele solicita ser realocado para outra atividade. Em outras situações, outros gerentes na mesma empresa consultam sobre a disponibilidade de membros de sua equipe. Em tais circunstâncias, o gerente de projeto deve fomentar junto ao grupo o forte senso de trabalho em equipe e também destacar a importância do projeto e a participação dos membros naquela equipe.
Plano de Ação
O plano de ação talvez seja o instrumento mais utilizado na previsão e registro de ações para desenvolvimento de projetos de melhoria. Isso se deve basicamente a:
- simplicidade de preenchimento
- necessidade de poucos dados para gestão
- é feito a partir de textos, não requerendo nenhum software especial
- fácil entendimento dos dados
. O plano é composto por:
• Indicadores de resultado: meio para gerenciar o plano de ação e verificar se resultado está sendo atingido. São eles que quantificam e qualificam o resultado. São fontes importantes para a avaliação.
• Ação: tudo de que necessitamos fazer para atingir o resultado proposto.
• Prazo: data precisa em que o gerenciamento será feito.
• Responsável: pessoa que nem sempre terá de realizar uma ação, mas será
fundamental para que essa ação seja cumprida. O responsável pela ação tem nome e sobrenome, não pode ser o grupo todo.
• Recursos: tudo de que necessitamos para realizar a ação. Não apenas recursos financeiros, mas custo, recursos de conhecimento, tempo em horas, infra-estrutura (sala e material necessário), recursos políticos, de organização ou até uma ação realizadora anteriormente.
Todo Plano de Ação deve estar estruturado para permitir a rápida identificação dos elementos necessários à implementação do projeto.
Existem várias maneiras de se montar um plano de ação, uma delas é o PDCA
que é uma forma simples de realizá-lo, como mostrado abaixo.
Plan (planeamento): estabelecer missão, visão, objetivo(metas),procedimentos
e processos (metodologias) necessárias para o atingimentos dos resultados.
Do (execução): realizar, executar as atividades.
Check (verificação): monitorar e avaliar periodicamenteos resultados, avaliar
processos e resultados, confrontando-os com o planejado, objetivos,
especificações e estado desejado, consolidando as informações, eventualmente confeccionando relatórios.
Act (agir): Agir de acordo com o avaliado e de acordo com os relatórios,
eventualmente determinar e confeccionar novos planos de ação, de forma a
melhorar a qualidade, eficiência e eficácia, aprimorando a execução e corrigindo eventuais falhas.
No giro do PDCA devemos coletar dados, medir resultados compará-los com a
meta considerada e adotar ações apropriadas, portanto, no giro deste ciclo será necessário empregar ferramentas apropriadas para a coleta, o processamento e a disposição de dados, o que permitirá a tomada de decisões confiáveis.
3º ETAPA ATPS
ENGENHARIA DE SOFTWARE ATPS NOMES: AUGUSTO LEONARDO RA: 090533728 HERLAN GUSTAVO RA: 0991003997 RODRIGO CAMPAGNOLI RA: 0901396023 JÉSSICA BIANCA RA: 0916397737 ORIENTADORA: Tânia Alves ATPS – 3º Etapa 2º Passo – Gerência de Risco do Projeto Gerente: Criação do projeto participará das reuniões necessárias, fará o levantamento para iniciação do projeto. Determinar o Escopo do Projeto; Garantir Patrocínio; Definir Recurso; Garantir Recurso e gerenciar o Projeto. Analista: Analisará o objetivo e fazer com que se torne mais próximo do desejo do cliente. Analisará as necessidades; Determinar especificações de softwares; Desenvolver orçamento; Desenvolver tempo de entrega do software; Garantir recursos requeridos. Programadores: Tornará o esboço do projeto em realidade, usando seus conhecimentos. Analisar especificações de software; Desenvolver especificações funcionais; Desenvolver protótipo baseado nas especificações funcionais; Obter aprovação; Programar. 4º Passo – Gerência de Risco do Projeto Possíveis Riscos: Deve-se buscar identificar ameaças concretas que sejam parte da realidade da organização. Nova versão ou manutenção (paralisação ou mau funcionamento de funcionalidades essenciais ou não). Situações do Cliente Interno (dificuldades de entendimento, participação de responsável da área ou resistências previstas ou não). Situações de planejamento (custos, equipe, recursos diversos). Tecnologia (falta, excesso, erros, treinamento). Imprevisíveis (greve, falta de luz, emergências). Plano de ações para que o projeto cumpra o prazo e as metas: Deve-se buscar identificar quais os controles (atividades, procedimentos, recursos ou responsabilidades existentes ou que possam ser construídos) que ajudam a reduzir ou evitar a ocorrência da ameaça. Procedimento de backup. Controle de versões de software. Duplicidade em equipamentos. Controle financeiro e contábil. Responsabilidades definidas. Nova versão ou manutenção (paralisação ou mau funcionamento de funcionalidades essenciais ou não).
METRICAS DE SOFTWARE
Edilson J da Costa Jr. RA: 0901397652
Kleber Patrick Marques Martins RA : 0970475207
METRICAS DE SOFTWARE
Como utilizá-las no gerenciamento de projetos de software.
O que são Métricas De Software:
A medição é algo comum no mundo da engenharia. Infelizmente, a engenharia de software está longe de ter uma medição padrão amplamente aceita e com resultados sem nenhum fator subjetivo. Temos dificuldade em concordar sobre o que medir e como avaliar o resultado das medições obtidas.
Métricas de softwares nos possibilitam realizar uma das atividades mais fundamentais do processo de gerenciamento de projetos que é o planejamento. A partir deste, passamos a identificar a quantidade de esforço, o custo e as atividades que serão necessárias para a realização do projeto.
As métricas de software, do ponto de vista de medição, podem ser divididas em duas categorias: medidas diretas e indiretas. Podemos considerar como medidas diretas do processo de engenharia de software o custo e o esforço aplicados no desenvolvimento e manutenção do software e do produto, a quantidade de linhas de código produzidas e o total de defeitos registrados durante um determinado período de tempo. Porém, a qualidade e a funcionalidade do software ou a sua capacidade de manutenção são mais difíceis de serem avaliadas e só podem ser medidas de forma indireta.
Também podemos dividir as métricas de software, sob o ponto de vista de aplicação, em duas categorias: métricas de produtividade e de qualidade. As métricas de produtividade se concentram na saída do processo de engenharia de software e métricas de qualidade indicam o quanto o software atende aos requisitos definidos pelo usuário.
A garantia da qualidade é uma das principais preocupações da indústria do desenvolvimento de software.
A maior parte das empresas utiliza esse tipo de aplicação para gerir seus negócios, produtos e relacionamento com clientes, necessitando maior, confiabilidade e qualidade.
Existem diversas medidas de garantia de qualidades fundamentais para o sucesso de qualquer tipo de aplicação de software, de dados quantitativos, e capaz de informar que aspectos do produto atendem ou não ao padrão de qualidade espeficicado, além de permitir a avaliação dos benefícios de novos métodos e ferramentas de engenharia de software, o entendimento e aperfeiçoamento do processo de produção,avaliação do retorno do investimento e tornar o gerenciamento de projetos baseado em fatos não em ''achismos''.
Para medir software,são utilizadas diversas métricas que são como tipo de medições aplicadas a um sistema de software,documentação ou processo relacionado.através dessas métricas e possível determinar o esforço ou tempo para realização de uma tarefa ou o tamanho do produto.As métricas de software são facilmente calculadas.
Quais as vantagens de utilizar métricas no desenvolvimento de
sistemas?
Diminuir:
Defeitos;
Prazo de entrega;
Desperdício;
Custo;
Aumentar:
Satisfação do cliente;
Produtividade dos recursos;
Visibilidade das ações;
Qualidade do gerenciamento;
Utilização de métricas
Existem dois tipos de métricas no contexto de desenvolvimento de produtos de software:
. As métricas diretas que são realizadas em termos de atributos observáveis como esforço, tamanho e custo;
.As métricas indiretas ou derivadas,que podem ser obtidas através de outras métricas,como por exemplo,complexidade,confiabilidade ,e facilidade de manutenção.Quanto ao contexto podem ser aplicada em produtos ou em processos. Quando as métricas incidem diretamente, são chamadas de métricas de predição, quando em processo de software são chamadas de métricas de controle e sua aplicação normalmente e realizada em processos ja maduros e controlada.
Para Obter resultados, as métricas devem ser aplicadas em um ciclo constante. (medição, análise de resultados, tomada de decisão, interpretação das decisões) .Alguns cuidados também devem ser tomados no processo de medição,momento e a escolha do conjunto de métricas mais relevantes a serem aplicadas e a comparação entre produtos através da aplicação da métricas.
Segundo especialistas, para medir artefatos de softwares através de métricas significativas, as medições devem ser redefinidas de acordo com objetivos específicos. Brasili desenvolveu o GQM.
O GQM é uma metodologia que permite a definição sistemática, o estabelecimento e a exploração adequada de um programa de métricas de software orientado aos objetivos da empresa. O método GQM foi originalmente proposto por Basili; Caldiera; Rombach (1994) para avaliar os defeitos de um conjunto de projetos da NASA Goddard Space Flight Center. Posteriormente, o uso do GQM foi expandido e tem sido adotado para medir e melhorar a qualidade em organizações de desenvolvimento de software. De acordo com os mesmos autores, o método proposto contém três níveis: Conceitual (Objetivo); Operacional (Questões) e Quantitativo (Métricas). O objetivo é definido para um objeto (um produto, um processo, ou um recurso utilizado por um processo). As questões são utilizadas para definir um caminho para alcançar um determinado objetivo. As métricas são definidas através de um conjunto de dados associados a cada questão de forma quantitativa. Solingen e Berghout (1999).
.
Algumas Métricas Comumente Utilizadas
Softwares podem ser medidos baseados em diversos tipos de perspectivas: Tamanho e Complexidade.
Para medição do tamanho na etapa de levantamento de requisitos,podem utilizar como métrica o numero de requisitos utilizados.Já Na fase de projeto,o tamanho pode ser medido em função do numero de classes e,na fase de codificação, a partir do numero de linhas do código fonte.
Algumas das principais Métricas baseadas nos tipos de medição citados:
Analise de Pontos de Função (APF):
é uma técnica de medição das funcionalidades fornecidas por um software do ponto de vista de seus usuários. Ponto de função (PF) é a sua unidade de medida, que tem por objetivo tornar a medição independente da tecnologia utilizada para a construção do software. Ou seja, a APF busca medir o que o software faz, e não como ele foi construído.
Números de linhas de códigos (LOC, KLOC) O modelo LOC, é a técnica de estimativa mais antiga.
Esse Medição pode auxiliar o engenheiro de software a determinar o tamanho de uma aplicação já construída ou estimar o esforço a ser considerado para a obtenção de uma produto a ser desenvolvido.
Complexidade Ciclomática (CC)
Fornece uma medida quantitativa da complexidade lógica de um programa.Através dessa métrica é possível definir o numero de caminhos possíveis de um algoritmo através do seu numero de condições (IF,FOR WHILE,DO E SWITCH).
METRICAS DE CHIDAMBER & KEMERER (CK) este conjunto possui seis métricas para sistemas OO e é conhecido como CK Métricas. As CK métricas podem ser utilizadas para analisar acoplamento e complexidade muito bem, mas elas analisam parcialmente atributos específicos de OO como: polimorfismo, herança e encapsulamento.
1. WMC (Weighted Methods per class-Metodos ponderados por classe) :
cálculo do número de serviços por classe. Um alto WMC mostra que a classe tende a se tornar específica e seus serviços possuem características que atendem a necessidades individuais, restringindo sua reutilização. O número de serviços mostra ainda qual o nível de esforço deve ser despendido para o teste da complexidade da classe
2. DIT (Depht of the inheritance tree-Profundidade da arvore de herança): mede a distância, ao longo da árvore de herança entre uma classe qualquer e a raiz da árvore. Quando maior é o valor de profundidade da classe, mais métodos foram herdados e maior será a complexidade ligada ao funcionamento do código.
3. (NOC (Number of Children)-Numero de Filhos) mede o número de classe diretamente derivadas a partir de uma dada classe. Neste caso, se o valor de profundidade for elevado indica a re-utilização de código.
4. CBO (Coupling Between Object Classes-Acoplamento entre classes de objetos): O acoplamento de uma classe A para uma classe B é dado pelo número de métodos de B chamados a partir de A, adicionando ao número de atributos B referenciados por A.
5. LCOM (Lack Of Conhesion In Methods-Falta De Coesão Em Métodos):
Mede a coesão de uma classe e é calculada através do método de Henderson-Sellers. Se m(A)
é o número de métodos que acessam o atributo A, LCOM é calculada como a média de m(A) para todos os atributos, subtraindo o número de métodos m e dividindo o resultado por (1 - m). Um valor baixo indica uma classe coesa, enquanto um valor próximo de1 indica falta de coesão;
6. RFC (Response For A Class-Resposta De Uma Classe): é o número de métodos que pode ser invocado em resposta a uma mensagem enviada por um objeto. Quanto maior elevado for o valor da métrica, maior a complexidade de funcionamento. Como conseqüência, provavelmente mais teste devem ser realizados para assegurar a ausência de defeitos.
Métricas De Lorenz & Kidd
Conjunto de quatro métricas chamadas de LK,baseiam-se como as métricas CK,no calculo quantitativo de alguns aspectos fundamentais da Orientação a Objetos .como os atributos,métodos,herança,coesão e acoplamento.A diferença entre Métricas Lk e as métricas Ck, e em relação a metodologia empregada em seu calculo.
1. CS (Class Size-Tamanho Da Classe):
CS: número de serviços e atributos locais e herdados de superclasses. Os serviços e atributos Públicos das classes localizadas hierarquicamente acima e os da própria classe em questão compõe o CS. Um grande CS torna a classe muito específica, pois sua estrutura atende a particularidades, o que restringe a reutilização, requerendo ainda maior esforço de testes, já que a classe se torna mais complexa
2. NOO (Number Of Operations Overriden By A Subclass-Numeros De Operações Rdefinidas Por Uma Subclasse):
NOO: os métodos definidos nas superclasses são herdados pelas subclasses, mas, quando esses não atendem à necessidade individual da subclasse, podem ser redefinidos, ferindo assim a abstração implícita na superclasse. Um alto índice de NOO indica um problema estrutural. Se muitas subclasses hierarquicamente mal projetadas
3. NOA (Number Of Operations Added By A Subclass-Numeros de Operações Adicionadas Por Subclasse):
Noa: se a classe contém um alto número de operações e atributos privados, ela torna-se muito específica, diminuindo as possibilidades de reaproveitamento. Pode-se dizer que um alto NOA pode indicar uma falha de modelo. Muitas particularidades mostram que a classe não está bem posicionada na hierarquia, já que suas características principais deveriam estar implícitas nos seus ancestrais
4. SI (Specialization Index-Indice De Especialização):
SI: número de serviços adicionados, eliminados ou redefinidos. Indica o nível de especialização das classes ou as alterações efetuadas para atender à necessidade individual daquela classe.
Conclusão
As métricas de software são medidas quantitativas acerca de processos ou produtos de software. Nosso artigo mostra algumas das mais conhecidas métricas e exemplifica o uso de algumas deles através de exemplos simplificados, com o propósito de acentuar a importância de sua utilização em um projeto. As métricas são capazes de indicar de pontos em que são necessários maiores esforços de teste de acompanhamento.Através de ferramentas e possível coletar um grande numero de métricas com menor esforço,e que viabiliza a implantação de processos de medição em qualquer tipo de sistema, desde os mais simples até os mais críticos,o que contribui para a qualidade do produto final,
Bibliografia
Engenharia de Software Magazine
http://revista.universo.edu.br/index.php/1studospesquisa2/article/viewFile/69/69
Assinar:
Postagens (Atom)