P R O C E SSO D E D E S E N VOLVIMENTO D E S O F T WAR E - PDF
Download "P R O C E SSO D E D E S E N VOLVIMENTO D E S O F T WAR E"
Andreia Freire Antunes
1 Tópicos desta Aula: Custo de desenvolver um software. Para quem se desenvolve um software? Tempo: Amigo ou Inimigo? Definição: Atividades e Responsabilidades?
2 REALISMO DE PRAZOS E CUSTOS Por que tantos sistemas informatizados são entregues com atraso e custam mais do que o previsto? Estourar cronogramas e orçamentos é parte da rotina da maioria dos profissionais de software. Clientes e gerentes se desesperam com os atrasos dos projetos de software, e às vezes sofrem enormes prejuízos com eles. Entretanto, no próximo contrato, eles provavelmente escolherão o oferente que prometer menor prazo e/ou menor custo. Se for um projeto interno da organização, farão todo tipo de pressões para conseguir que os desenvolvedores prometam prazos politicamente agradáveis, embora irreais. 2
3 REALISMO DE PRAZOS E CUSTOS Estimar prazos e custos é uma rotina de qualquer ramo da engenharia. Para viabilizar um produto, não basta atender aos requisitos desejados; ele precisa ser produzido dentro dos parâmetros de prazo e custo. A empresa de desenvolvimento que não segue essas práticas no seu total, está condenada a descontentamentos por parte dos clientes e um replanejamento de tudo que foi desenvolvido. Essas organizações, seguem a política de "matar os mensageiros de más notícias". Política que foi muito usada por reis da antigüidade, com resultados geralmente desastrosos. 3
4 REALISMO DE PRAZOS E CUSTOS Requisitos, prazos e custos formam os vértices de um triângulo crítico. Aumentos de requisitos levam a aumentos de prazos ou custos, ou ambos. Reduções de requisitos podem levar a reduções de prazos ou custos (mas nem sempre). Por que? 4
5 PLANEJAMENTO DE PROJETOS "Não me interessa como você vai fazer, desde que entregue no prazo!" A cultura doprazo político é ruim para todos. Para osdesenvolvedores, ela significa estresse e má qualidade de vida. Para os gerentes, perda de credibilidade e prejuízos. E para os clientes, produtos de má qualidade e mais caros do que deveriam. Ainda por cima, entregues fora do prazo. Para cumprir compromissos de prazos e custos, estes precisam ser assumidos com base em requisitos bem levantados, analisados e documentados. Os planos dos projetos precisam ser elaborados com boas técnicas de estimativa e análise de tamanho, esforços, prazos e riscos. 5
6 QUALIDADE DOS REQUISITOS Entendemos como qualidade de um produto: O seu grau de conformidade com os respectivos requisitos. De acordo com esta definição de qualidade, por exemplo, um carro popular poderia ser de uma boa qualidade, e um carro de luxo poderia ser de uma má qualidade. No geral o que irá decidir a qualidade será a comparação com os respectivos requisitos: o confronto entre a promessa e a realização de cada produto, decorrendo diretamente da qualidade do processo utilizado emsua produção. Cada requisito não atendido irá gerar um defeito. No mundo da informática é comum ouvirmos a palavra Bug, problemas que surgem com o uso do programa, geralmente ocasionados por incompatibilidades não prevista no código-fonte. 6
7 QUALIDADE DOS REQUISITOS Com palavra Bug os erros técnicos adquirem conotação menos negativa, mas não deixa de ser um erro, que se tivesse sido feita uma pré análise dos requisitos as probabilidades de não acontecer teria sido menor ou próximo de nula. O ser humano, não é perfeito, comete erros, mas dependendo da gravidade dos erros o cliente ouo gerente não irão dizer: Tudo bem, você acerta da próxima vez. Para se evitar erros, temos as atividades relacionadas a garantia da qualidade, como: revisões, testes e auditorias. Estas atividades removem parte dos defeitos introduzidos. Quando atividades de controle da qualidade são cortadas, temos uma queda direta de suas funcionalidades, pois parte dos defeitos deixarão de ser removidos em algum ponto doprojeto. 7
8 QUALIDADE DOS REQUISITOS Uma das formas mais caras e dispendiosas, para o cliente ou a empresa desenvolvedora, acontece quando o bug chega ao produto final, só sendo removido através de uma operação de manutenção. Vários métodos de garantia da qualidade levam em conta uma limitação humana: somos mais eficazes para achar os defeitos dos outros do que nosso próprios defeitos. Geralmente para obtermos revisões eficazes, os testes de aceitações, precisam ser feitas por revisores sem vínculos com os autores, isto é, organizações independentes, com acesso direto à alta gerência da organização. 8
9 GESTÃO DE CONFIGURAÇÕES Um produto de software é composto por diversos artefatos: Códigos executáveis; Códigos fontes; Modelos; Relatórios, e outros documentos; Em sua maioria os artefatos evoluem ao longo do projeto ou ao longo de toda a vida deum produto. Após o termino de um projeto, é de suma importância que os resultados sejam arquivados e controlados, em uma manutenção, talvez seja necessário uma atualização. Se a gestão de configurações não for seguida, fica impossível atingir até os níveis razoáveis de qualidade, com versões corrigidas de artefatos perdidas e versões defeituosas reaparecendo. 9
10 DESENHO Entre os requisitos e o código final existe sempre um desenho. Ele pode ser explícito, documentado e feito de acordo com determinadas técnicas. Poderá existir apenas na cabeça do programador, de maneira informal e semiconsciente. Com relação a este último caso, seriam mais as limitações humanas: de raciocínio, de memória e de capacidade de visualização. Um desenho de boa qualidade é explícito e documentado. 10
11 DESENHO Alguns dos resultados típicos de defeitos de desenho são: Dificuldade de uso; Lentidão; Problemas imprevisíveis e irreprodutíveis; Perda de dados; Dificuldade de manutenção; Dificuldade de adaptação e expansão. 11
12 EXERCÍCIOS P R O C E SSO D E D E S E N VOLVIMENTO 1) O que costuma dar errado em projetos? 2) Tendo em vista a definição dos sintomas, por que dá errado? 12
13 EXERCÍCIOS Vamos analisar as imagens a seguir: P R O C E SSO D E D E S E N VOLVIMENTO 13
14 EXERCÍCIOS 3) Vamos analisar as imagens a seguir e depois elaborar um resumo do que deve ser evitado em um projeto. 14
15 EXERCÍCIOS P R O C E SSO D E D E S E N VOLVIMENTO 3) Agora vamos elaborar um resumo do que deve ser evitado em um projeto. 15
16 AULAS DE APOIO Este arquivo está disponibilizado para estudos e consultas no formato PDF. Alguns estarão disponíveis para impressão, outros, somente para leitura. ou 16
Construção. Transição
Análise de Sistemas Processo de Engenharia de Software 1. ESQUEMA GERAL (Ciclo de Vida de Software) Ciclo de Vida 2. PRODUTOS 2.1. PROBLEMAS Percepção da Necessidade Concepção Elaboração Desenvolvimento
Engenharia de Software: Introdução e uma Visão do Processo de Software
Engenharia de Software: Introdução e uma Visão do Processo de Software (Algumas partes deste material correspondem a excertos do livro de Wilson Pádua Filho, Editora LTC - Direitos autorais respeitados)
Engenharia de Software: fundamentos, métodos e padrões. (Excertos de livro a ser publicado pela Editora LTC proibida a reprodução)
Engenharia de Software: fundamentos, métodos e padrões (Excertos de livro a ser publicado pela Editora LTC proibida a reprodução) Wilson de Pádua Paula Filho Março de 2000 Página em branco 2 Manual do
Multiplicando Resultados com a Evolução dos Processos de Software Ernani Ferrari Chief-consultant ernani.ferrari@mondostrategies.
Multiplicando Resultados com a Evolução dos Processos de Software Ernani Ferrari Chief-consultant ernani.ferrari@mondostrategies.com AGENDA Importância dos Processos Atenção à Qualidade e Produtividade
Estimativa de custo de software: roteiro e dicas para estimativas de projeto
94 Estimativa de custo de software: roteiro e dicas para estimativas de projeto ANTONIO MENDES DA SILVA FILHO * Learn from yesterday, live for today, hope for tomorrow. The important thing is not to stop
Campus Capivari Análise e Desenvolvimento de Sistemas (ADS) Prof. André Luís Belini E-mail: prof.andre.luis.belini@gmail.com / andre.belini@ifsp.edu.br MATÉRIA: QUALIDADE DE SOFTWARE Aula N : 03 Tema:
PROJETO E DESENVOLVIMENTO DE SISTEMAS DA INFORMAÇÃO EAD MÓDULO 1 O DESENVOLVIMENTO DE SISTEMAS
PROJETO E DESENVOLVIMENTO DE SISTEMAS DA INFORMAÇÃO EAD MÓDULO 1 O DESENVOLVIMENTO DE SISTEMAS O desenvolvimento de sistemas tem como característica a complexidade que envolve todos os seus processos,
Maiores riscos do uso de planilhas no controle financeiro
Maiores riscos do uso de planilhas no controle financeiro Planejamento Performance Dashboard Plano de ação Relatórios Indicadores O efeito acumulado do erro humano nas tabelas do Excel Certa vez a equipe