7
CAP2
CAP2
CAP2
CAP2---- O contexto de desenvolvimento de projectos
O contexto de desenvolvimento de projectos
O contexto de desenvolvimento de projectos
O contexto de desenvolvimento de projectos de SI
de SI
de SI
de SI
Introdução Introdução Introdução Introdução
Tendo em conta que os SI surgem para dar suporte ao negócio, como podemos definir negócio? NegócioNegócioNegócioNegócio é um sistema económico no qual, bens e serviços são trocados um pelo outro ou por dinheiro com base no seu valor percebido. No caso das organizações sem fins lucrativos (ex: cruz vermelha), estas são desenhadas para servir um propósito público, podem ter lucro mas não podem ser criadas com esse objectivo.
Objectivos dos SI Objectivos dos SI Objectivos dos SI Objectivos dos SI
Como visto na classificação dos SI segundo Anthony, podemos enumerar os seguintes objectivos primordiais dos SI.
• Suporte à produção (operacionais)
o Reduzir custos operacionais, através da automatização e reformulação dos processos de negócio
o Melhorar o desempenho de pessoas e máquinas • Suporte táctico
o Satisfazer requisitos de informação dos utilizadores
o Melhorar o nível de serviço prestado aos clientes actuais e facilitar a aquisição de novos clientes.
• Suporte estratégico
o Contribuir para a criação de novos produtos e serviços
o Melhorar e automatizar (integrar) a relação com os parceiros de
negócio.
O planeamento estratégico dos SI têm como objectivo garantir o alinhamento dos SI com os objectivos de negócio.
8 Processos e Metodologias
Processos e Metodologias Processos e Metodologias Processos e Metodologias
Quando se fala do desenvolvimento de software, são frequentemente aplicadas expressões diferentes mas que muitas vezes representam a mesma ideia. É por isso fundamental a clarificação de alguns conceitos básicos adoptados nesta disciplina. O processo de desenvolvimento de software processo de desenvolvimento de software processo de desenvolvimento de software processo de desenvolvimento de software é uma sequência de actividades, normalmente agrupadas em fases e tarefas, que são executadas de forma sistemática e uniformizada, que são realizadas por intervenientes com responsabilidades bem definidas, e que a partir de um conjunto de inputs produzem um conjunto de outputs. Metodologia
Metodologia Metodologia
Metodologia: É a aplicação de um processo através da utilização de um conjunto concreto de ferramentas, técnicas e notações [Booch94].
A metodologia inclui ainda referências a diversos princípios e regras cujo objectivo é concretizar na prática as orientações mais teóricas que são expressas no processo, e nas quais podemos incluir:
• Regras de elaboração de estimativas (custos, prazos).
• Técnicas para efectuar medições e regras de elaboração de estimativas. • Procedimentos a seguir de forma a garantir a qualidade.
• Programas de formação.
• Referência sobre a utilização de ferramentas de apoio ao longo de todo o processo.
• Modelos da documentação a produzir, vulgarmente designados por templates. • Exemplos práticos detalhados.
• Técnicas para configuração da metodologia, que poderão ser aplicadas para se adaptar a realidades específicas.
Modelo Modelo Modelo
Modelo: É uma interpretação de um sistema segundo um determinado ponto de vista, e envolve a sua especificação a um certo nível de abstracção e de detalhe.
• Exemplos de modelos:
Modelo de objectos da linguagem UML especificado em UML Modelo de classes, ao nível da análise
Modelo de classes, ao nível do desenho/implementação Esquema
Esquema Esquema
Esquema: É a especificação de um modelo usando uma determinada linguagem, a qual pode ser formal, informal (e.g., linguagem natural); de texto, gráfica, etc.
Quando a representação do esquema é gráfica designa-se usualmente por diagramadiagramadiagramadiagrama. • Exemplos de esquemas:
o Esquema relacional de um sistema de crédito
9 Importância da modelação
Importância da modelação Importância da modelação Importância da modelação
Podemos especificar a modelação com os seguintes itens:
• Modelação é a arte e ciência de criar modelos de uma determinada realidade. • Modelação é uma técnica de engenharia bem aceite e provada (e.g., Eng.ª
civil, mecânica).
• Permite partilhar conhecimento entre utilizadores e técnicos, e entre diferentes tipos de técnicos.
• Permite gerir melhor os projectos, as equipas, etc.
• Permite prever custos e prazos; permite minimizar os riscos e os custos.
Benefícios da modelação Benefícios da modelação Benefícios da modelação Benefícios da modelação
Segundo [Booch99], temos os seguintes benefícios:
• Os modelos ajudam a visualizar um sistema, quer seja a sua situação no passado, no presente ou no futuro.
• Os modelos permitem especificar a estrutura ou o comportamento de um sistema.
• Os modelos permitem controlar e guiar o processo de construção do sistema. • Os modelos documentam as tomadas de decisão realizadas.
Princípios da modelação Princípios da modelação Princípios da modelação Princípios da modelação
Segundo Booch, independentemente do modelo se verificam sempre quatro (4) princípios.
P1 P1 P1
P1- A escolha dos modelos a criar tem uma profunda influência no modo como o problema é atacado e consequentemente como a solução é tratada
P2 P2 P2
P2- Cada modelo pode ser expresso em diferentes níveis de precisão/abstracção P3
P3 P3
P3- Os melhores modelos reflectem a realidade P4
P4 P4
P4---- Nenhum modelo único é suficiente. Qualquer sistema não-trivial é melhor representado através de pequeno número de modelos razoavelmente independentes.
É possível distinguir genericamente os processos de desenvolvimento de SI segundo as seguintes aproximações:
10 Aproximação em Cascata
Aproximação em Cascata Aproximação em Cascata Aproximação em Cascata
As actividades a executar são agrupadas em tarefas, executadas sequencialmente, de forma que uma tarefa só tem início quando a tarefa anterior tiver terminado (ver exemplo da figura abaixo).
Positivo Positivo Positivo Positivo
• Só se avança para a tarefa seguinte quando o cliente valida e aceita os produtos finais (documentos, modelos, programas) da tarefa actual – uma garantia “formal” para o fornecedor que fica mais “descansado”...
• Pressupõe que o cliente participa activamente no projecto e que sabe bem o que quer.
Negativo Negativo Negativo Negativo
• Promove compartimentação dos esforços ao longo das diferentes tarefas, desencorajando a comunicação e partilha de visões entre todos os intervenientes do projecto (analistas, arquitectos, programadores, utilizadores, etc).
• Minimiza o impacto da compreensão adquirida no decurso de um projecto, pois se um processo não pode voltar atrás de modo a alterar os modelos e as conclusões das tarefas anteriores, é normal que as novas ideias sobre o sistema não sejam aproveitadas.
11 Aproximação em cascata revista
Aproximação em cascata revista Aproximação em cascata revista Aproximação em cascata revista
• Vantagens
Prevê a possibilidade de a partir de qualquer tarefa do ciclo se poder regressar a uma tarefa anterior de forma a contemplar alterações funcionais e/ou técnicas que entretanto tenham surgido, em virtude de um maior conhecimento que se tenha obtido.
• Desvantagens
Risco desta aproximação é que, na ausência de um processo de gestão do projecto e de controlo das alterações bem definido, podemos passar o tempo num ciclo sem fim, sem nunca se atingir o objectivo final que é disponibilizar um sistema a funcionar.
Aproximação Iterativa e Incremental Aproximação Iterativa e Incremental Aproximação Iterativa e Incremental Aproximação Iterativa e Incremental
• Baseia-se no princípio que a equipa envolvida possa refinar e alargar pouco a pouco a qualidade, detalhe e âmbito do sistema envolvido
• A principal consequência da aproximação iterativa é que os produtos finais de todo o processo vão sendo amadurecidos e completados ao longo do tempo, mas cada iteração produz sempre um conjunto de produtos finais.
12 Aproximação em Espiral
Aproximação em Espiral Aproximação em Espiral Aproximação em Espiral
Variante do modelo iterativo e incremental. Foi proposto por Barry Boehm [Boehm88] como resposta às críticas que os processos existentes não favoreciam a utilização de prototipagem e reutilização de software.
Problemas típicos no desenvolvimento de SI Problemas típicos no desenvolvimento de SI Problemas típicos no desenvolvimento de SI Problemas típicos no desenvolvimento de SI
• (falta de) Qualidade, traduzida na satisfação incompleta dos requisitos, nos problemas que se verificam após a instalação do produto.
• (desvios dos) Prazos previamente estabelecidos para o desenvolvimento de software.
• (controlo dos) Custos previamente definidos para o desenvolvimento de software largamente ultrapassados.
Causas típicas dos problemas Causas típicas dos problemas Causas típicas dos problemas Causas típicas dos problemas
• Falta de empenho dos órgãos de topo das organizações. • Falta de comprometimento e empenho dos utilizadores. • Incompreensão do valor dos sistemas de informação.
• Falta de entendimento e de sintonia entre informáticos e clientes utilizadores do sistema, no âmbito e requisitos do mesmo.
• Deficiências várias no processo de desenvolvimento.
• Falhas na coordenação do projecto, nomeadamente ao nível dos objectivos, prioridades, estimativas.
• Falta de qualidade e inadequação dos recursos envolvidos.
• Mudanças frequentes dos requisitos do negócio e incapacidade de lidar com esta situação.
13 Causa comum a todos os problemas
Causa comum a todos os problemas Causa comum a todos os problemas Causa comum a todos os problemas
• Falta de comunicação, ou comunicação desadequada entre os intervenientes:
o No levantamento dos requisitos (resultando em expectativas erradas ou irrealistas)
o Na análise (causado resultando em certezas erradas)
o No desenho (resultando em soluções impraticáveis ou erradas)
o No desenvolvimento (resultando em funções desajustadas)
o Nos testes (resultando em conflitos entre diferentes classes de actores)
o Na gestão de projecto (resultando no descontrolo dos custos)
• As razões para a falta de comunicação resulta geralmente de:
o Intimidação hierárquica (medo de fazer perguntas básicas ao chefe ou ao cliente...)
o Ignorância, arrogância ou falta de respeito pelo “outro” (“eles disseram que querem isso assim, mas nós sabemos que não é assim que deve ser...”)
o Falta de rigor (“Mas porque é que não nos disseram isso antes? Porque vocês não perguntaram antes...”)
Decomposição hierárquica Decomposição hierárquica Decomposição hierárquica
Decomposição hierárquica: também conhecido por divide and conquer ("dividir para conquistar"). Um problema é dividido em sub-problemas mais elementares e assim sucessivamente até serem simples de resolver.
Abstracção Abstracção Abstracção
Abstracção: Favorece a eliminação da complexidade: já que não é possível lidar com toda a realidade dos sistemas complexos, o ser humano opta por "esquecer" os detalhes menos importantes e focar a sua atenção nos mais relevantes, lidando com um modelo simplificado da realidade, mas considerado suficiente para entender e solucionar correctamente o problema em questão.
B B B
Booooaaaassss pppprrrrááááttttiiiiccccaaaassss
• O desenvolvimento deve ser efectuado de forma iterativa, repetindo as mesmas actividades em momentos temporais desfasados, mas detalhando o âmbito das funcionalidades do sistema.
• Efectuar uma gestão integrada dos requisitos, permitindo a verificação da rastreabilidade dos mesmos desde a sua identificação até à implementação, e facilitando todo o processo de gestão de alterações.
14 • Modelar o software através de diagramas gráficos, mais facilmente compreensíveis
e menos sujeitos a interpretações subjectivas.
• Efectuar a verificação sistemática da qualidade, e não apenas no final do desenvolvimento.
• Conseguir e promover o envolvimento dos utilizadores.
• Utilizar uma abordagem orientada para a resolução de problemas. • Definir e utilizar standards para o desenvolvimento e documentação.
• Justificar o desenvolvimento de software como uma actividade estratégica e como investimento financeiro.
• Não ter receio de alterar ou mesmo cancelar o projecto ou parte dele. • Conceber sistemas que sejam fáceis de expandir e alterar.
Q Q Q
Quuuueeeessssttttõõõõeeeessss ppppaaaarrrraaaa ddddiiiissssccccuuuussssssssããããoooo
Quais os elementos estruturais comuns nos processos de desenvolvimento de sistemas?
