Tópicos desta Aula: Custo de desenvolver um software. Para …profcelso.orgfree.com/Arquivos_Aulas/07-Proces_Desen... · 2013. 4. 24. · Tempo: Amigo ou Inimigo? ... Clientes e

ADS / REDES / ENGENHARIA Prof. Celso Candido

PROCESSO DE DESENVOLVIMENTO

DE SOFTWARE

Tópicos desta Aula:

Custo de desenvolver um software.

Para quem se desenvolve um software?

Tempo: Amigo ou Inimigo?

Definição: Atividades e Responsabilidades?



DE SOFTWARE

2

Por que tantos sistemas informatizados são entregues com atraso e

custam mais do que o previsto?

REALISMO DE PRAZOS E CUSTOS

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.



DE SOFTWARE

3

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.



DE SOFTWARE

4


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?



DE SOFTWARE

5

"Não me interessa como você vai fazer, desde que entregue no prazo!"

PLANEJAMENTO DE PROJETOS

A cultura do prazo político é ruim para todos.

Para os desenvolvedores, ela significa estresse e má qualidade de vida.

Para os gerentes, perda de credibilidade e prejuízos.

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.

E para os clientes, produtos de má qualidade e mais caros do que

deveriam. Ainda por cima, entregues fora do prazo.



DE SOFTWARE

6

Entendemos como qualidade de um produto: “O seu grau de

conformidade com os respectivos requisitos”.

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

em sua 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.



DE SOFTWARE

7

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 ou o gerente não irão dizer:

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 do projeto.

“Tudo bem, você acerta da próxima vez”.



DE SOFTWARE

8

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.



DE SOFTWARE

9

Um produto de software é composto por diversos artefatos:

GESTÃO DE CONFIGURAÇÕES

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 de um 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.



DE SOFTWARE

10

Entre os requisitos e o código final existe sempre um desenho.

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.



DE SOFTWARE

11

Alguns dos resultados típicos de defeitos de desenho são:

DESENHO

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.



DE SOFTWARE

12

1) O que costuma dar errado em projetos?

EXERCÍCIOS

2) Tendo em vista a definição dos sintomas,por que dá errado?



DE SOFTWARE

13

EXERCÍCIOSVamos analisar as imagens a seguir:



DE SOFTWARE

14

EXERCÍCIOS3) Vamos analisar as imagens a seguir e depois elaborar um resumo do que deve ser

evitado em um projeto.



DE SOFTWARE

15

3) Agora vamoselaborar umresumo doque deve serevitado emum projeto.

EXERCÍCIOS



DE SOFTWARE

16

AULAS DE APOIO

Este arquivo está disponibilizado para estudos e consultas noformato PDF.

Alguns estarão disponíveis para impressão, outros, somente paraleitura.

www.aulasprof.6te.net ou www.profcelso.orgfree.com/

Documents

Tópicos desta Aula: Custo de desenvolver um software. Para …profcelso.orgfree.com/Arquivos_Aulas/07-Proces_Desen... · 2013. 4. 24. · Tempo: Amigo ou Inimigo? ... Clientes e