Software – Técnicas e Aplicações  FACULDADE DE CIÊNCIAS DE ENGENHARIA E TECNOLOGIA 1º CICLO DE AULAS MAGNAS Software – Técnicas e Aplicações Processos de desenvolvimento de software

Frei Joaquim José Hangalo Ordem dos Frades Menores Capuchinhos Filosofia, Teologia e Engenharia Informática Docente na Universidade Católica de Angola Disciplinas Fundamentos de Programação (Java SE) Sistemas Distribuídos e Paralelos (Java EE) Interacção Homem Máquia e Programação em Web Standards (HTML, CSS, Javascript) Base de Dados Introdução às Tecnologias de Informação Director do Centro de Formação São Domingos Minha apresentação

Vamos conversar Sobre desenvolvimento de software

Software O software é um produto do trabalho humano cada vez mais presente na sociedade. Qualquer discussão sobre a prática de software deve se fundamentar na compreensão da real natureza do que é software e no relacionamento que ele provoca entre pessoas.

A Engenharia de Software A engenharia de software é a disciplina do conhecimento humano que tem por objectivo definir e exercitar processos (seres humanos a actuar como máquinas), métodos (planos de processos), ferramentas e ambientes (máquinas a apoiar processos e métodos) para construção de software que satisfaça as necessidades do cliente e utilizador dentro de prazos e custos previsíveis (nem sempre…).

Por outras palavras, engenharia de software é uma actividade industrial de produção de software, através da qual são produzidos vários artefactos não necessariamente compreensíveis por máquinas, mas que contribuem decisivamente para que um plano de construção do software.

Requisitos do software Design do software Construção do software O corpo de conhecimentos da engenharia de software é estruturado em áreas: Requisitos do software Design do software Construção do software Testes e qualidade de software Manutenção de software Etc … Engenharia de Software

O grande problema

Processos de Desenvolvimento de Software

O processo de software é visto por uma sequência de actividades que produzem uma variedade de documentos, resultando num programa satisfatório e executável. O desenvolvimento de software é caracterizado por uma sobreposição de actividades necessárias para especificar, projectar e testar retorno dos resultados do software que está a ser criado.

Modelos de Processo de Software

Modelos de Processo de Software Existem vários modelos de processo de software (ou paradigmas de engenharia de software) Cada um representa uma tentativa de colocar ordem em uma actividade inerentemente caótica

Modelos de Processo de Software O Modelo Sequencial Linear também chamado Modelo Cascata O Modelo de Prototipação O Modelo RAD (Rapid Application Development) Modelos Evolutivos de Processo de Software O Modelo Incremental O Modelo Espiral O Modelo de Montagem de Componentes Técnicas de Quarta Geração Metodologias Ágeis

Modelo em Cascata

Regra geral… Ouvir o cliente Construir, Rever o protótipo O cliente Em situações de incerteza sobre os requisitos, o paradigma de construção de protótipos pode ser a melhor alternativa. Este paradigma começa com a recolha de requisitos. O analista e o cliente falam sobre os objectivos globais do software e os requisitos conhecidos. Então aparece um desenho rápido focado na representação dos aspectos do software visíveis ao utilizador. O desenho rápido passa-se à construção do protótipo, que é avaliado pelo utilizador e é utilizado para a refinação de requisitos. Na maioria dos casos, o protótipo não serve como produto operacional. Pode ser muito lento, pesado de usar ou grande Vantagens: O tempo entre entregas é curto Serve como 1er sistema Facilita a aceitação do sistema Ideal quando os requisitos não estão claros, é de facto um método de identificação de requisitos Os requisitos são verificados atempadamente Disvantagens: Falsas expectativas geradas pelo protótipo quanto a sua funcionalidade e ao tempo requerido para as incorporar que propícios para o estabelecimento de compromissos para por funcionalidades no protótipo muitas vezes desenvolvido em sistemas operativos e linguagens inadequadas para o sistema final. Para solucionar isto, deve falar-se muito claro com o cliente. A gestão é mais demorada O cliente Testa o protótipo

modelo mais antigo e o mais amplamente O Modelo em Cascata modelo mais antigo e o mais amplamente Utilizado na engenharia de software modelado em função do ciclo da engenharia convencional requer uma abordagem sistemática, sequencial ao desenvolvimento do software o resultado de uma fase constitui-se na entrada da/para a outra

Modelo em cascata

Modelo em cascata Envolve a licitação de requisitos do sistema, com uma pequena quantidade de projecto e análise de alto nível; Preocupa-se com aquilo que se como engenharia progressiva do produto de software; Inicia com um modelo conceitual de alto nível para um sistema e prossegue com o projecto, implementação e teste do modelo físico do sistema.

Análise de Requisitos do Software Modelo em cascata Análise de Requisitos do Software O processo de licitação dos requisitos é intensificado e concentrado especificamente no software deve-se compreender o domínio da informação, a função, desempenho e interfaces exigidas os requisitos (para o sistema e para o software) são documentados e revistos com o cliente

Projecto tradução dos requisitos do software para um conjunto de representações que podem ser avaliadas quanto à qualidade, antes que a codificação inicie

Implementação tradução das representações do projecto para uma linguagem “artificial” resultando em instruções executáveis pelo computador e implementado num ambiente de trabalho.

Testes Concentra-se: nos aspectos lógicos internos do software, garantindo que todas as instruções tenham sido testadas nos aspectos funcionais externos, para descobrir erros e garantir que a entrada definida produza resultados que concordem com os esperados.

Manutenção provavelmente o software deverá sofrer mudanças depois que for entregue ao cliente causas das mudanças: erros, adaptação do software para acomodar mudanças no ambiente externo e exigência do cliente para acréscimos funcionais e de desempenho

Alguns Problemas com o Modelo em Cascata Projectos reais raramente seguem o fluxo sequencial que o modelo propõe; Logo no início é difícil estabelecer explicitamente todos os requisitos. No começo dos projectos sempre existe uma incerteza natural; O cliente deve ter paciência. Uma versão executável do software só fica disponível numa etapa avançada do desenvolvimento (na instalação); Difícil identificação de sistemas legados (não acomoda a engenharia reversa).

Dica Embora o Modelo em Cascata tenha fragilidades, ele é significativamente melhor do que uma abordagem casual de desenvolvimento de software

O Paradigma de Prototipação

o objectivo é entender os requisitos do utilizador e, assim, obter uma melhor definição dos requisitos do sistema. possibilita que o desenvolvedor crie um modelo (protótipo)do software que deve ser construído apropriado para quando o cliente não definiu detalhadamente os requisitos.

1- OBTENÇÃO DOS REQUISITOS: desenvolvedor e cliente definem os objectivos gerais do software, identificam quais requisitos são conhecidos e as áreas que necessitam de definições adicionais.

2- PROJECTO RÁPIDO: representação dos aspectos do software que são visíveis ao utilizador (abordagens de entrada e formatos de saída) 3- CONSTRUÇÃO DO PROTÓTIPO: implementação rápida do projecto

4 -AVALIAÇÃO DO PROTÓTIPO Cliente e desenvolvedor avaliam o protótipo 5 .REFINAMENTO DO PROTÓTIPO: Cliente e desenvolvedor refinam os requisitos do software a ser desenvolvido.

6- CONSTRUÇÃO PRODUTO: identificados os requisitos, o protótipo deve ser descartado e a versão de produção deve ser construída considerando os critérios de qualidade.

Alguns Problemas com a Prototipação O cliente não sabe que o software que ele vê não considerou, durante o desenvolvimento, a qualidade global e a manutenibilidade a longo prazo O desenvolvedor frequentemente faz uma implementação comprometida (utilizando o que está disponível) com o objectivo de produzir rapidamente um protótipo

Comentários sobre o Paradigma de Prototipação ainda que possam ocorrer problemas, a prototipação é um ciclo de vida eficiente. a chave é definir as regras do jogo logo no começo. o cliente e o desenvolvedor devem ambos concordar que o protótipo seja construído para servir como um mecanismo para definir os requisitos

O Modelo RAD ( Rapid Application Development)

RAD ( Rapid Application Development) é um modelo sequencial linear que enfatiza um ciclo de desenvolvimento extremamente curto O desenvolvimento rápido é obtido usando uma abordagem de construção baseada em componentes.

Os requisitos devem ser bem entendidos e o alcance do projecto restrito O modelo RAD é utilizado principalmente para aplicações de sistema de informação Cada função principal pode ser direccionada para uma equipa RAD separada e então integrada para formar o todo.

Desvantagens: Exige recursos humanos suficientes para todas as equipas Exige que desenvolvedores e clientes estejam comprometidos com as actividades de “fogo-rápido” a fim de terminar o projecto num prazo bem curto

Modelos Evolutivos de Processo

Existem situações em que a engenharia de software necessita de um modelo de processo que possa acomodar um produto que evolui com o tempo.

quando os requisitos de produto e de negócio mudam conforme o desenvolvimento prossegue quando uma data de entrega apertada (mercado) - impossível a conclusão de um produto completo quando um conjunto de requisitos importantes é bem conhecido, porém os detalhes ainda devem ser definidos

Os modelos evolutivos são iterativos possibilitam o desenvolvimento de versões cada vez mais completas do software Modelos Evolutivos de Processo de Software O Modelo Incremental O Modelo Espiral O Modelo de Montagem de Componentes

Metodologias Ágeis

As Metodologias Ágeis de Desenvolvimento de Software são indicadas como sendo uma opção alternativa às abordagens tradicionais para desenvolver softwares; Comparadas a outras metodologias, produzem pouca documentação. É recomendado documentar o que realmente será útil;

São recomendadas para projetos que: existem muitas mudanças; os requisitos são passíveis de alterações; a recodificação do programa não acarreta alto custo; a equipe é pequena; as datas de entrega curtas acarretam alto custo; o desenvolvimento rápido é fundamental. Em essência, as Metodologias Ágeis foram desenvolvidas com o objectivo de vencer as fraquezas percebidas e reais da Engenharia de Software (Pressman, 2010).

O Manifesto Ágil Em 2001, Kent Beck e mais 16 desenvolvedores, produtores e consultores de software, que formavam a Aliança Ágil, assinaram o Manifesto de Desenvolvimento Ágil de Software, declarando:

Estamos descobrir melhores métodos de desenvolvimento de software fazendo-o e ajudando outros a fazê-lo. Por meio desse trabalho, passamos a valorizar: Indivíduos e interacções em vez de processos e ferramentas. Software a funcionar em vez de uma documentação abrangente. Colaboração do cliente em vez da negociação de contractos. Resposta a modificações em vez de seguir um plano. Isto é, ainda que haja valor nos itens à direita, valorizamos mais os itens à esquerda.

Os 12 princípios do Manifesto Ágil Garantia da satisfação do consumidor com entrega rápida e contínua de softwares funcionais. Mudanças de requisitos, mesmo no fim do desenvolvimento, ainda são bem-vindas. Frequentemente são entregues softwares funcionais (semanas, em vez de meses). Desenvolvedores e pessoas relacionadas aos negócios devem trabalhar, em conjunto, até o fim do projecto. Construir projectos com indivíduos motivados, dar-lhes ambiente e suporte necessários e confiar que cada um fará o seu trabalho. Uma conversa face a face é o método mais eficiente e efectivo de transmitir informações para e dentro de uma equipa de desenvolvimento.

Os 12 princípios do Manifesto Ágil Software em funcionamento é a principal medida de progresso. Desenvolvimento sustentável, de modo a manter um ritmo constante indefinidamente. Atenção contínua para com a excelência técnica e para com bons projectos aumenta a agilidade. Simplicidade – a arte de maximizar a quantidade de trabalho não efectuado – é essencial. As melhores arquitecturas, requisitos e projectos emergem de equipes auto-organizáveis. Em intervalos regulares, a equipa deve reflectir sobre como se tornar mais eficiente.

Algumas metodologias XP (Extreme Programming) DAS (Desenvolvimento Adaptativo de Software) DSDM (Dynamic Software Development Method) Scrum Kanban Crystal FDD (Feature Driven Development) Modelagem Ágil (AM) Processo Unificado Ágil (AUP)

Linguagens e plataformas para desenvolvimento de software

As plataformas oferecem suporte a aplicativos e soluções projectadas para os menores dispositivos, bem como para as maiores empresas.

Ferramentas de desenvolvimento e linguagens Ferramentas existem várias dependendo da linguagens. As linguagens também são muitas mas é possível destacar algumas A linguagem Java, apesar de ter uma curva de aprendizagem um pouco grande é o destaque dos últimos 20 anos A linguagem C nos últimos tempos tem vindo a concorrer com o java C#, C++, Python… têm a sua fatia no mercado

Por áreas de desenvolvimento temos… Desenvolvimento Web PHP, ASP.NET, Java (Servlets, JSP e JSF) Ferramentas auxiliares: Drupal, Joomla, Plone Desenvolvimento corporativo e de servidores Java EE e A plataforma .NET tem várias propostas Desenvolvimento embedded e móvel Android, IOS, Windows Mobile, BlackBerry Desenvolvimento para a nuvem Existem propostas para quase todas a lingugagens

Dicas Esta foi apenas uma conversa… há um grande caminho a se fazer… Entretanto

Selecção do modelo Deve haver flexibilidade na escolha Projectos pequenos: ciclo clássico Limites severos de tempo: DRA Data entrega muito próxima: modelo incremental Os modelos vistos até agora não são, por si só, suficientes para o sucesso de projectos baseados no Paradigma Orientado a Objectos

Selecção do modelo… Para escolha de um Modelo de Processo de Software: natureza do projecto e da aplicação métodos e ferramentas a serem utilizadas controlos e produtos que é preciso entregar

Perguntas...comentários... Joaquim José Hangalo facebook jaiKim Jaime joajoshang@gmail.com hangalo.centrofsd.org Perguntas...comentários...