Fábricas de Software. Processos de Software. Fábricas de Software. Fábricas de Software 17/08/2010. Jorge Dias

Transcrição

1 Fábricas de Software Processos de Software Jorge Dias Um processo estruturado, controladoe melhoradode forma contínua, considerando abordagens de engenharia industrial, orientado para o atendimento a múltiplas demandasde naturezae escopodistintas, visando à geração de produtos de software, conforme os requisitos documentados dos usuários e/ou clientes, da forma mais produtiva e econômica possível Introdução Aula 01 [2/23] Fábricas de Software O termo Fábrica de Softwarefoi empregado pela primeira vez em 1969, pela japonesa Hitachi, mas só começou a ficar popularno início dos anos 90 Características: Ter processos clarose depender mais delesdo que das pessoas, de forma a ter resultados mais previsíveis Aplicar conceitos da indústriaem geral em ambientes de desenvolvimento de software, de forma a aumentar a produtividade e diminuir prazos e custos. Divisãode trabalho com equipes especializadaspara cada parte do desenvolvimento de um software, que trabalham como numa linha de produção Fábricas de Software Existem fábricas especializadassomente na codificação... Os requisitosdevem ser entregues de forma padronizada... Assim como existem fábricas que englobam as várias fases de um processo de desenvolvimento Necessidade de utilização de melhores práticasde frameworks como CMMI, PMP, MPS.BR, UML/UP, dentre outros Introdução Aula 01 [3/23] Introdução Aula 01 [4/23] 1

2 Alguns Problemas no Desenvolvimento de Software... Custo da Mudança... Alguns projetos são cancelados mesmo antes de começar; O tempo de desenvolvimento e o custo são bem maiores do que o estimado; Os sistemas não funcionam como planejado; A qualidade é baixa; A manutenção e a reutilização são difíceis e custosas; Os problemas são proporcionais à complexidade dos sistemas; Pressman 5 Custo da correção de defeitos... Mas... Como obter qualidade? X100+ Custo x1 A qualidadede um sistema é fortemente influenciada pela qualidade do processo utilizado para adquiri-lo, desenvolvê-loe mantê-lo SEI requisitos projeto codificação teste implantação 2

3 Processo de Software Conjunto de práticasrealizadas para atingir um determinado propósito; pode incluir ferramentas, métodos, materiaise/ou pessoas SEI Um processo define quemestá fazendo o quê, quandoe comoalcançar um certo objetivo Jacobson, Booch e Rumbaugh Processo de Software Existem quatro atividades fundamentaisem qualquer processo de software: Especificação: Definição das funcionalidades e restrições. Desenvolvimento: Produção do software. Validação: Validação do software para verificar se é o que o cliente precisa. Evolução: Evolução do software para atender mudanças necessárias pelo cliente. Modelos de Processo de Software Aula 02 [10/29] Processo de Desenvolvimento de Software Características das atividades: bem definidas; com responsáveis; com artefatos de entrada e saída; com dependências entre as mesmas e ordem de execução; com modelo de ciclo de vida. Processo de Desenvolvimento de Software Processo de software padrão é composto por: Fases/atividades (entradas e saídas) procedimentos/métodos ferramentas, utilizados para construir um produto de software. Paradigmas de desenvolvimento Orientado a Objetos Orientado a componentes Orientado a Serviços

4 Processo de Desenvolvimento de Software Processo de Desenvolvimento de Software Processo de software padrão pode ser dividido nos seguintes sub-processos: Processos Fundamentais (Análise de Negócio, Requisitos, Análise e Projeto, Implementação, Testes e Implantação); Processos de Apoio (Gerência de Projetos, Garantia da Qualidade, Gerência de Configuração e Mudança, Medição e Análise); Processos Organizacionais (Infra-estrutura, Treinamento, Aquisição). Enfim, o processo de desenvolvimento de software define quem faz o quê, quando e como para atingir um certo objetivo Modelos de Processos de Software Modelos de Processos de Software Cadamodelorepresentaum processosob determinada perspectiva São bem genéricos Podemos ver como paradigmas de processo Podem ser ampliadas e adaptadas Não são mutuamente exclusivos, podem ser usados em conjunto

5 Modelo Cascata Modelo Cascata Foi o primeiro a ser adotado pelos desenvolvedores Possui um conjunto de fases bem definidas que correspondem às etapas do ciclo de vida do software Não há mistura de fases: uma fase só começa quando a anterior termina Ao final de cada fase, um ou mais documentos devem ser aprovados pela equipe de desenvolvimento 18 Modelo Cascata Principais características Atividades: Análise e Engenharia de Sistemas: Envolve a coleta dos requisitos em nível de sistema; Busca a compreensão do sistema como um todo, incluindo hardware, software, bancos de dados e pessoas envolvidas; Análise de Requisitos e Software: Intensifica e concentra a definição dos requisitos do software; O resultado será utilizado nas etapas posteriores de Projeto, Construção, Testes e Manutenção; Modelo Cascata Principais características Atividades: Projeto: Transforma os requisitos da análise, o modelo lógico, em modelo físico; Define a arquitetura do software, detalhes procedimentais e de interface, dentre outros; Codificação: Implementa os programas e relatórios do sistemas com base nas especificações das fases anteriores;

6 Modelo Cascata Principais características Atividades: Testes: Realiza os testes do sistema (aspectos lógicos internos e aspectos funcionais externos); Manutenção: Constrói alterações no software que visem a solução de erros, melhorias ou inclusão de novas funcionalidades. (Prototipação) Capacita o desenvolvedor a criar um modelo do software que será implementado; Tem o objetivo de resolver problemas ou limitações existentes na análise de requisitos, antes do início da implementação do software; O protótipo pode ser apresentado ao cliente na forma de papel ou modelo executável no computador, retratando a interface do software; Com o protótipo, o cliente poderá verificar se os requisitos especificados são os desejados ou reformulálos se houver necessidade (Prototipação) Há duas abordagens Desenvolvimento exploratório O protótipo evolui junto com os requisitos do sistema e se transforma no próprio sistema final Desenvolvimento de protótipos descartáveis O protótipo é usado apenas para ajudar na definição de requisitos e não é aproveitado no sistema final 23 6

7 Desenvolvimento exploratório Um sistema inicial é feito a partir dos requisitos que foram bem entendidos e que são prioritários para a aplicação A implementação é exposta a comentários dos usuários para ser aperfeiçoada ao longo de vários estágios Desenvolvimento exploratório À medida que vão surgindo novos requisitos para o sistema, o protótipo vai sendo modificado (desenvolvimento sob demanda) Os padrões de qualidade (segurança, confiabilidade, usabilidade) devem ser levados em consideração desde o começo pois devem estar presentes na versão final Desenvolvimento exploratório Vantagens Sistemas que atendem à necessidade imediata dos clientes Resultados concretos rapidamente Envolvimento dos usuários ao longo de todo o projeto (contribuições) Especificação gradativa do sistema (flexibilidade) Desenvolvimento exploratório Desvantagens A rápida evolução dos protótipos dificulta a produção de documentação Excesso de mudanças no código pode comprometer a estrutura do sistema; a longo prazo, o sistema pode precisar ser substituído ou completamente reescrito 7

8 Desenvolvimento exploratório Desvantagens A mudança de membros da equipe pode tornar a compreensão do sistema difícil (falta de documentação) Dificuldade para estipular valores de contrato, uma vez que a especificação não é formalizada Cobrar por tempo de trabalho? Cobrar por funcionalidade? Desenvolvimento de protótipos descartáveis O objetivo é compreender melhor os requisitos do cliente através de protótipos experimentais Apenas os requisitos que não estão claros são prototipados Pronta a especificação do sistema, o protótipo deixa de ser útil Desenvolvimento Orientado a Reuso Desenvolvimento Orientado a Reuso Também conhecido como Desenvolvimento Baseado em Componentes ou CBSE (Component-Based Software Engineering) Uma base de componentes de software obtidos de terceiros ou produzidos internamente é utilizada pelos desenvolvedores na produção da aplicação Os componentes têm diferentes níveis de abstração (podem ser desde funções matemáticas a componentes de prateleira) Especificação de Requisitos Análise de Componentes Modificação de Requisitos Projeto de Sistema com Reuso Validação de Sistema Desenvolvimento e Integração 8

9 Desenvolvimento Orientado a Reuso Vantagens Reduzir riscos e custos (menos código) Redução de prazos de entrega Desvantagens Adequação dos requisitos aos componentes pode resultar em sistemas que não satisfaçam os clientes A organização não tem controle sobre os componentes de terceiros (o código muitas vezes não está disponível e não se conhece sua qualidade) Desenvolvimento Orientado a Reuso Computação Orientada a Serviços Evolução do CBSE Pode-se utilizarserviçosemqualquerlugarde maneira interoperável Iteração de Processo Mudanças são inevitáveis em qualquer software As atividadesdo processoprecisamser repetidas Entregaincremental Desenvolvimentoespiral Desenvolvimento Incremental Modelo Cascata + Modelo Evolucionário As funcionalidades gerais do sistema são definidas e são planejados vários estágios de entrega de versões de acordo com a prioridade das funcionalidades para o negócio 9

10 Desenvolvimento Incremental Desenvolvimento Incremental Definir esboço dos requisitos Desenvolver incremento do sistema Validar incremento Atribuir requisitos aos incrementos Integrar incremento Sistema Incompleto Projetar arquitetura do sistema Validar sistema Sistema Final Vantagens O cliente recebe resultados rapidamente (vantagem para o negócio) Risco menor de fracasso do sistema (problemas isolados, não gerais) Funcionalidades mais importantes são entregues primeiro (testadas com mais freqüência, menor quantidade de erros) Desenvolvimento Incremental Desvantagens Dificuldade para mapear requisitos em incrementos Incrementos devem ser pequenos e devem produzir funcionalidades completas Incrementos devem ter aproximadamente o mesmo tamanho e o mesmo prazo de entrega Modelo Espiral Desenvolvido para abranger as melhores características do ciclo de vida clássico e da prototipação; Acrescenta um novo elemento: a análise de riscos; O processo é representado como uma espiral em vez de uma seqüência de atividades; Cada volta na espiral representa uma fase no processo

11 Modelo Espiral Modelo Iterativo: Espiral Definição dos objetivos, alternativas e restrições:objetivos específicos para a fase são identificados, alternativas para realizar os objetivos e restrições são encontradas Avaliação e redução de risco:os riscos principais são identificados, analisados e buscam-se meios para reduzir estes riscos Desenvolvimento e validação:um modelo apropriado para o desenvolvimento é escolhido, que pode ser qualquer um dos modelos de ciclo de vida Planejamento:O projeto é revisto e a próxima fase da espiral é planejada 41 Exemplo de Processos RUP (Rational Unified Process) Metodologias ágeis Scrum, XP, etc Processos focados em paradigmas UML Components, Catalysis SOMA (IBM) Qual o melhor processo de software? A escolha do Processo de Software que será adotado em um projeto dependerá de vários fatores cultura e características do cliente e da empresa desenvolvedora de software tipo de aplicação experiência dos desenvolvedores 11