Producto x Processo x Projecto

Apresentação em tema: "Producto x Processo x Projecto"— Transcrição da apresentação:

1 Producto x Processo x Projecto
Aula 6

2 Sumário O processo O Projecto O produto O processo do software CMM
O software como produto Evolução Características Tipos Aplicações Atributos de um bom software Produto x Processo O processo O processo do software CMM O Projecto 10 Sinais de perigo no Projecto Como evitar o perigo Perguntas-chave para o seu planeamento Âmbito desta Aula Gestão de Projectos de SW: pessoal, producto, processo e projecto

3 Producto de SW

4 Estrutura de conceitos
Produto Processo cria Notação (UML) exprime implementa Metodologia Técnica (Modelação) utiliza Suporta, automatiza Ferramenta (Object Domain, Rational Rose)

5 O produto O software é simultaneamente um produto
software de gestão pacotes de uso geral (folhas de cálculo, processadores de palavras) e um veículo para o entregar sistemas operativos, software de comunicação Ambientes de desenvolvimento Ferramentas CASE

6 Evolução do software Antes Depois Preocupação: Preocupação: Hardware
Caro Poder Computacional Limitado Programas simples Preocupação: aproveitamento dos recursos de hardware i.e. Eficiência do produto Depois Hardware mais barato e poderoso Software mais complexo Preocupação: Satisfação dos requisitos do utilizador (produto eficaz) Baixar custos e tempo de desenvolvimento (processo eficiente)

7 Características do software
O software é um produto lógico, não físico e portanto, não é fabricado num sentido clássico, senão desenvolvido O software não se estraga Embora cada vez o software é uma assemblagem de componentes, ainda se faz muito software à medida

8 Tipos de software Genérico Feito à medida
Problemas do desenvolvimento são os mesmos A diferencia reside na especificação dos requisitos

9 Aplicações do software
Software de sistemas Software de tempo real Software de gestão Software de engenharia e científico Software embebido Software de PC’s Software baseado na WEB Software de IA Software de sistemas: servem outros programas. Exemplos: compiladores, editores y utilidades de gestão de ficheiros. Forte interacção com o hardware, múltiplos utilizadores, operação concorrente que requer planeamento e partilha de recursos. Software de tempo real: coordena, analisa e controla factos do mundo real assim que ocorrem. Incluem componentes de aquisição de dados que recolhem e formatam a informação recebida, componentes de análise que transformam a informação segundo requerido, componente de controlo/saída que responde ao entorno externo e uma componente de monitorização que coordena as componentes restantes. Software de gestão: suportam as operações de contabilidade, salários, recursos humanos, inventários. Transformam os dados recebidos para ajudar na tomada de decisões Software de engenharia e científico: alta manipulação numérica. Aplicações vão desde a vulcanologia até a astronomia, os sistemas CAD são outro exemplo Software embebido: em ROM, controlam produtos médicos, comerciais e industriais. Funções muito limitadas mas muito especializadas Software de PC’s: processadores de palavras, folhas de cálculo, pacotes gráficos, etc, etc. Software baseado na WEB: paginas HTML com cgi, perl, ou java applets Sistemas de inteligência artificial: algoritmos baseados na lógica

10 Atributos de um bom software
Descrição Mantainability O software deve ser capaz de evoluir perante as mudanças nos requisitos Dependability Características como Confiabilidade e seguridade Eficiência Aproveitamento dos recursos de hardware Usabilidae Apropriadas interface do utilizador e documentação

11 Produto x Processo Se o processo é fraco, o produto vai sofrer
A dependência excessiva no processo também é má A comunidade alterna a sua preocupação pelo produto e processo cada 5 ou 10 anos aprox. Acredita-se que esta dualidade manter-se-á por uns tempos

12 Processo de SW

13 O Processo de SW Definição: Selecção do modelo de processo
Estratégia de desenvolvimento do software Define a ordem de execução das fases de engenharia de software Selecção do modelo de processo Clientes e pessoal envolvido Produto requerido Ambiente da equipa de desenvolvimento Maduração do produto e o processo Definição de actividades básicas Estimação de recursos para cada função do produto e discriminado pelas actividades básicas Decomposição do processo

14 Níveis de Maturidade do Processo
CMM – Capability Maturity Model Nível 1 Caos | nível inicial Nível 2 Reutilização | identifica processos repetitivos Nível 3 Documentação | já existe um processo definido ISO 9001 Nível 4 Qualidade de SW | processos são bem geridos Definem Métricas e estimações Nível 5 + difícil | Optimização dos Processos poucas empresas de desenvolvimento de SW atingem este nível

15 Projectos de SW

16 10 Sinais de perigo no Projecto
O pessoal de software não percebe as necessidades do cliente A definição do âmbito do produto é fraca Os câmbios são mal feitos Mudança na tecnologia seleccionada Necessidades do negócio cambiam ou estão mal definidas As datas de entrega não são realistas Os utilizadores oferecem resistência Perdem-se os sponsors A equipa de projecto não tem as competências requeridas Os gestores evitas boas práticas e sábias lições

17 como evitar o perigo Começar com o pé direito
Manter-se com o pé direito Monitorizar o projecto Tomar decisões inteligentes Realizar análise post-mortem Começar com o pé direito: Trabalhar muito duro no início por forma a compreender o melhor possível o problema a solucionar e estabelecendo então objectivos e metas realista. Também, construindo a equipa adequada e dando-lhe a autonomia, autoridade e tecnologia necessária para realizar o trabalho Manter-se: proporcionar os incentivos requeridos para minimizar a rotação, destacando a qualidade em todas as tarefas desenvolvidas. Monitorização do progresso: os produtos do trabalho devem ser revisados e aprovados mediantes inspecções Tomar Decisões Inteligentes: evitar complicações, utilize software do mesmo fornecedor ou componentes de software existentes, evita personalizar interfaces quando estejam disponíveis aproximações standard, identifique e elimine riscos óbvios, seja pessimista na estimação de tarefas arriscadas Análise post-mortem: ao acabar o projecto, estabeleça mecanismos de avaliação para extrair lições do projecto. Comparar os planos com a execução real, reunir e analisar métricas do projecto e retro alimentar com dados dos membros da equipa e dos clientes e armazenar esses dados.

18 perguntas-chave para o seu planeamento
Por que se vai desenvolver o sistema? O que será feito e quando? Onde estão os responsáveis? Como será realizado o trabalho técnico e de gestão? Quais e quantos recursos são requeridos? Porquê se vai desenvolver o sistema? A resposta permite avaliar a validez ds razões de negócio para o trabalho, i.e. Justifica o propósito do sistema o gasto em pessoal, tempo e dinheiro? O quê será feito e quando? A resposta ajuda na elaboração do plano do projecto Onde estão localizados organizacionalmente? Nem todos os papéis e responsabilidades ficam dentro da equipa de software. O cliente, utilizadores e outros directivos também têm responsabilidades Como será realizado o trabalho técnico e de gestão? A resposta a isto resulta na estratégia técnica e de gestão Quais e quantos recursos são requeridos? A resposta a isto resulta nas estimativas do projecto

19 próxima aula teórica

20 Modelos de processo Tipos: Modelos em cascata Construção de Prototipos
Sequêncial (Clássico) Revisto Construção de Prototipos Desenvolvimento Rápido de Aplicações Modelos evolutivos Incrementais Iterativos Iterativos e incrementais Espiral Modelo de Processos OO Modelo recursivo/paralelo Outros