IDSI
Infraestrutura para
o Desenvolvimento de
Sistemas de Informação
Prof. Rodrigo Nin
[email protected]
1
Nosso Escopo
O negócio
Conhecimento
contido em
software
A solução
do negócio
Pessoas
Organização
e Processos
Hardware
componentes
da solução do
negócio
Software
Materiais
Infraestrutura
Aspectos Finanças
legais e
normativos
2
ORGANIZAÇÃO
Processos:
Finanças
Processos:
Operações
Clientes
Fornecedores
Processos:
RH
Software
Processos:
Comercial
Processos:
Contabilidade
Processos:
Marketing
Bancos
Etc...
3
O que é Software?
1o - Instruções (programas de computador) que,
quando executadas, produzem a função e o
desempenho desejados - código;
2o - Dados armazenados.
É uma descrição de processo para ser executado por
um perfeito idiota – um computador.
O que não está escrito, não existe.
O software comanda o hardware.
4
Exemplo de um código HTML
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
<H1> Isto é um cabeçalho do tipo H1 </H1>
<H2> Isto é um cabeçalho do tipo H2 </H2>
<P> Isto é um parágrafo. Marcador final para parágrafo não é
necessário, mas ele existe </P>
<P> Agora será mostrada uma lista não ordenada </P>
<UL>
<LI> Primeiro item da lista não ordenada
<LI> Segundo item da lista não ordenada
</UL>
<P> Agora será mostrada uma lista ordenada </P>
<OL>
<LI> Primeiro item da lista ordenada
<LI> Segundo item da lista ordenada
</OL>
<P> É permitida a formatação dos caracteres que serão mostrados </P>
<P> <I> Este parágrafo será mostrado em itálico </I> </P>
<P> <B> Este parágrafo será mostrado em negrito </B> </P>
<P> Isto é uma ligação Hipertexto que para acesso ao servidor da UFRGS
<P>
<A href="http://www.ufrgs.br/"> UFRGS – Universidade Federal do Rio
Grande do Sul </A>
5
Fonte: Marco Aurélio Bonato
Resultado da interpretação do código HTML
1
2
3
4
6
7
9
11
12
14
15
16
17
18
Fonte: Marco Aurélio Bonato
6
Formulário em HTML
7
Fonte: Marco Aurélio Bonato
Código
HTML
que produz
um
formulário
<HTML>
<HEAD> <TITLE>Exemplo de formulário</TITLE></HEAD>
<BODY>
<CENTER><P><B>EXEMPLOS DE FORMULÁRIOS</B></P></CENTER>
<FORM ACTION="mailto:[email protected]" METHOD=POST>
<PRE>Exemplo de campo <B>TEXTO</B> -> Nome:<INPUT TYPE="text"
NAME="Nome" SIZE=50></PRE>
<P>Exemplo de campo <B>SELEÇÃO</B> ------------------------>
<SELECT NAME="SELEÇÃO">
<OPTION SELECTED> Empresa Privada
<OPTION> Empresa Pública
<OPTION> Universidade
<OPTION> Entidades de Pesquisa
</SELECT>
<P>Exemplo
<INPUT
<INPUT
<INPUT
<INPUT
de campo <B><I>Checkbox</I></B> (várias opções são aceitas)<BR>
TYPE="checkbox" NAME="Desvantagens" VALUE="Padrões" CHECKED>Padrões <br>
TYPE="checkbox" NAME="Desvantagens" VALUE="Software">Software <br>
TYPE="checkbox" NAME="Desvantagens" VALUE="Jukeboxes">Jukeboxes <br>
TYPE="checkbox" NAME="Desvantagens" VALUE="Indexação">Indexação <br>
<P>Exemplo de campo <B><I>Radio Buttons</I></B> (somente uma opção é aceita)
<MENU>
<INPUT TYPE="radio" NAME="Vantagem" VALUE="Tecnologia Nova" CHECKED>Tecnologia Nova<br>
<INPUT TYPE="radio" NAME="Vantagem" VALUE="Baixo Custo" >Baixo Custo<BR>
<INPUT TYPE="radio" NAME="Vantagem" VALUE="Velocidade de Gravação " >Velocidade de
Gravação<br>
</MENU>
<P> Exemplo de botões para submissão do formulário
<P><INPUT TYPE="submit" VALUE="ENVIAR">
<INPUT TYPE="reset" VALUE="CANCELAR">
</FORM>
</BODY>
</HTML>
Fonte: Marco Aurélio Bonato
8
Por outro lado, a mente humana...
De aorcdo com uma pqsieusa de uma uinrvesriddae
ignlsea, não ipomtra em qaul odrem as lrteas de uma
plravaa etãso, a úncia csioa iprotmatne é que a
piremria e útmlia lrteas etejasm no lgaur crteo. O rseto
pdoe ser uma bçguana ttaol que vcoê pdoe anida ler
sem pobrlmea. Itso é poqrue nós não lmeos cdaa lrtea
isladoa, mas a plravaa cmoo um tdoo e dtnero do
ctoxteno.
Sohw de bloa!
9
Outra...
M473M471C0 (53N54C1ON4L)
4S V3235 3U 4C0RD0 M310 M473M471C0.
D31X0 70D4 4 4857R4Ç40 N47UR4L D3 L4D0
3 M3 P0NH0 4 P3N54R 3M NUM3R05,
C0M0 53 F0553 UM4 P35504 R4C10N4L.
540 5373 D1550, N0V3 D4QU1L0...
QU1N23 PR45 0NZ3...
7R323N705 6R4M45 D3 PR35UNT0...
M45 L060 C410 N4 R34L
3 C0M3Ç0 4 F423R V3R505
H1NDU-4R481C05
10
Tamanho de software
Categoria
Tamanho em
linhas de código
Tamanho da
equipe
Duração do
desenvolvimento
Trivial
500
1
1-4 semanas
Pequeno
1000 a 2000
1
1-6 meses
Médio
5000 a 50.000
2-5
1-2 anos
Grande
50.000 a 100.000
5-20
2-3 anos
Muito grande
1 milhão
100-1000
4-5 anos
Extremamente
grande
1 a 10 milhões
2000-5000
5-10 anos
O Windows 95 da Microsoft foi desenvolvido por uma equipe de 200
pessoas e possui 11 milhões de linhas de código fonte.
11
Fonte: Jair C Leite
Alguns dados interessantes

U$ 250 bilhões/ano - desenvolvimento de software nos EUA

U$38 bilhões em 2002 - perdidos em projetos não entregues (15%)

U$17 bilhões - em custos acima do previsto (7%)

15% dos projetos - terminam sem entregar resultados

66% dos projetos - foram considerados não atendendo as necessidades
dos usuários

43% - é o erro médio em relação ao orçamento do projeto daqueles que
foram completados
12
Fonte: The Standish Group International CHAOS Report2003
Algumas características do software
Nenhum software está pronto !
Porque a realidade a que o software se refere está sempre mudando
Porque a tecnologia está sempre evoluindo
Porque as pessoas estão sempre tendo novas idéias para evolução da
solução - melhorias
Porque há sempre um novo bug para corrigir
Porque a “mão invisível” do mercado não deixa ninguém quieto
13
Mais algumas características do software
Todo software tem BUG !
 Os softwares são cada vez mais complexos
 O ser humano tem muita dificuldade de lidar com a complexidade
 A dificuldade em lidar com a complexidade está na origem da grande
maioria dos erros em software
O Software é desenvolvido ou projetado por engenharia, não
manufaturado no sentido clássico:
 Custos são concentrados no trabalho de engenharia
 Projetos não podem ser geridos como projetos de manufatura
14
O Processo de Produção de Software
Formulação
de conceitos
Necessidade
Projeto
Idéia
Construção
Necessidade
satisfeita
FORMALIZAÇÃO
Partindo de uma idéia até chegar a um código que a máquina
entenda e execute, o software deve passar por diversas
representações cada vez mais formais.
15
Passos para a construção de um software
(ou de qualquer outra coisa)
1. Saber o que fazer
2. Inventar uma solução
3. Detalhar a solução
4. Construir
5. Testar
6. Corrigir os defeitos
7. Colocar em funcionamento
ESPECIFICAÇÃO
ANÁLISE
PROJETO
PROGRAMAÇÃO
TESTES
mais PROGRAMAÇÃO mais TESTES
IMPLANTAÇÃO
16
Projetos
Áreas de conhecimento necessárias para o sucesso
de projetos
Engenharia
do Produto
Engenharia
de Processos
dominar as técnicas
de desenho
e construção
saber organizar
o trabalho
Gerência
de Projetos
saber planejar
e controlar
Adaptado de PMBOK 2000 - Project Management Institute
17
Constrói e conserta (modelo caótico ou clássico)
Bate papo
com o cliente
Programação
Implantaçao
Operação
Manutenção +
manutenção + …
18
Evolução das Metodologias
Fases encadeadas
Fases gerando produtos
Fases com produtos
explicitamente aprovados
19
Estratégia Cascata
20
Estratégia Cascata
Todas as fases do ciclo de desenvolvimento são executadas em seqüência.
Esta abordagem pode ser adequada quando :
- existe um conjunto de Requisitos do Usuário estáveis e de alta
qualidade;
- a duração do projeto é pequena;
- o sistema completo deve estar disponível de um única vez.
Principais críticas à estratégia Cascata
 Inadequação à maioria dos problemas reais
 Há muito intercâmbio de informações entre as fases
 Raramente ocorrem projetos onde não há concorrência das
fases
 Não leva em consideração alterações constantes nos requisitos
21
Estratégia Incremental
Inicialmente um
conjunto de
funcionalidades são
especificadas,
implementadas,
construídas e
aprovadas.
Em seguida o mesmo
ciclo se repete até que
todas as
funcionalidades
previstas na solicitação
do sistema tenham
sido atendidas. 22
Engenharia de Software
(1) Aplicação ao desenvolvimento, operação e
manutenção de software de uma abordagem
sistemática, disciplinada e quantificável;
(2) O estudo das abordagens conceituadas em (1).
23
Problemas que Engenharia de Software pretende resolver
 Não cumprimento dos prazos de desenvolvimento
 Não cumprimento dos orçamento de desenvolvimento
 Não cumprimento dos requisitos de qualidade
 Desconhecimento de quanto de software já foi
produzido e quanto falta produzir e de quanto é possível
produzir
24
Qualidade de Software
 Foco no produto
X
 Foco no processo
25
Foco no produto
ISO 9126
Características da qualidade de produtos de software.
NBR 13596
Versão brasileira da ISO 9126
ISO 14598
Guias para a avaliação de produtos de software, baseados na
utilização prática da norma ISO 9126
ISO 12119
Características de qualidade de pacotes de software
(software de prateleira, vendido com um produto embalado)
26
Foco no processo
xAnálise
Necessidades
do negócio
Projeto
x
Testes
x
x
x
Codificação
SOFTWARE
SOFTWARE
Implantação
x
Processo de software
27
Foco no Produto X Foco no Processo
“Toda falha de software indica um
erro no projeto ou no processo pelo
qual o projeto foi traduzido para
código de máquina” (Pressman)
O foco no produto define onde
se pretende chegar e o foco no
processo proporciona que se
alcance o objetivo
28
Principais modelos para avaliação e melhoria
da qualidade do processo de desenvolvimento de software
ISO/IEC 15504 (SPICE)
+ ISO/IEC 12207
Software Process Improvement & Capability dEtermination
http://www.abnt.org.br/
CMMI (Capability Maturity Model® Integration)
http://www.sei.cmu.edu/cmmi/
Projeto mps Br: melhoria de processo do software
Brasileiro http://www.softex.br
29
Níveis de Maturidade (CMMI)
Fonte: http://www.sei.cmu.edu/cmmi/
30
Níveis de Maturidade (ISO/IEC 15504)
31
Fonte: http://www.softex.br
32
Fonte: http://www.softex.br
33
Fonte: http://www.softex.br
34
Fonte: http://www.softex.br
Processos imaturos
• Improvisado pelos profissionais e gerência
• Pouca ou nenhuma definição
• O que está definido é freqüentemente abandonado em função de atrasos e
outras pressões
• Altamente dependente dos profissionais do momento (donos de sistema)
• Pouca visibilidade de progresso e qualidade
• Funcionalidades e qualidade tendem a ser sacrificadas em função de
pressões de recursos e prazos
• Uso arriscado de novas tecnologias
• Produz software com altos custos de manutenção
• Baixa capacidade de prever custos, prazos e qualidade
35
Processos maduros
• Definido, documentado e continuamente aprimorado
• Trabalho realizado de modo consistente e consciente
• Total transparência quanto ao andamento dos projetos
• Processo conhecido, entendido e utilizado em toda a organização
• Novas tecnologias são introduzidas de modo controlado
• Resultados previsíveis em termos de custos, prazos e qualidade
36
Modelos de Maturidade – melhoria progressiva dos processos
O cronograma e o
orçamento
normalmente
“estouram” e a
qualidade é
“casual”
In
Out
In
Out
Com processos bem
definidos, o
In
desempenho e a
qualidade melhoram
significativamente
Out
O planejamento
e a qualidade
baseados na
experiência são
mais confiáveis
Com base em
In
métricas, aumenta o
grau de acerto e o
desempenho
O desempenho e a In
qualidade evoluem
contínuamente
Adaptado de http://www.sei.cmu.edu
Out
Out
37
38
Fonte: http://www.softex.br
39
Fonte: http://www.softex.br
40
Fonte: http://www.softex.br
41
Fonte: http://www.softex.br
mpsBR – Atributos de Processo (para avaliação da capacidade)
1. Atributos de Execução
1.1. O processo é executado
2. Atributos de Gerenciamento
(o processo atinge os resultados definidos)
2.1. O processo é gerenciado
(política; objetivos; planejamento/controle;
responsabilidades/autoridades; recursos/informações/treinamento;
comunicação; revisão)
2.2. Os produtos de trabalho do processo são gerenciados
(identificação;
requisitos; controle; revisão/ajuste dos produtos do trabalho)
3. Atributos de Institucionalização
3.1. O processo é definido
(existe um processo-padrão adaptável que
define: a interação com outros processos; papéis e competências;
infraestrutura e ambiente; métodos para monitoramento)
3.2. O processo está implementado
(os projetos utilizam processos de
acordo com o processo-padrão; papéis/responsabilidades/autoridades são
atribuídos e comunicados; as pessoas são competentes; os recursos e a
infraestrutura são alocados, gerenciados e utilizados; medições e análises
são realizadas e consideradas para decisões)
42
Fonte: http://www.mct.gov.br/upd_blob/8752.pdf
43
Fonte: http://www.mct.gov.br/upd_blob/8752.pdf
44
Avaliações mpsBR
1 - BL INFORMÁTICA - Nível F do MPS.BR (validade de 23/09/05 até 22/09/07)
2 - COMPERA - Nível F do MPS.BR (validade de 21/10/05 até 20/10/07)
3 - IN FORMA - Nível G do MPS.BR (validade de 13/09/05 até 12/09/07)
4 - PROGRAMMER'S - Nível F do MPS.BR
(validade de 25/11/05 até 24/11/07)
5 - RELACIONAL - Nível E do MPS.BR (validade de 29/09/05 até 28/09/07)
6 - MARLIN - Nível D do MPS.BR (validade de 14/07/06 até 13/07/09)
7 - POLITEC - Nível A do MPS.BR (validade de 26/05/06 até 25/05/09)
8 - PROGRAMMER'S - Nível F do MPS.BR (validade de 25/11/05 até 24/11/08)
http://www.softex.br/cgi/cgilua.exe/sys/start.htm?sid=222
45
Download

no processo