UNIVERSIDADE FEDERAL DO MATO GROSSO ENGENHARIA DE SOFTWARE II Revisão dos principais conceitos da Engenharia de Software: Motivação; Histórico; Terminologia; Principais modelos de processos e métodos; AULA 1 Profª MSc. MICHELLE DE OLIVEIRA PARREIRA parreira.michelle@gmail.com
Software X Hardware Software é desenvolvido Alto custo de criação Baixo custo de reprodução Não enguiça, mas deteriora Defeitos no produto usualmente são consequências de problemas no processo de desenvolvimento Hardware é manufaturado Alto custo de reprodução Pode enguiçar Defeitos podem vir tanto na concepção quanto na produção Pode ser substituído na totalidade ou em partes 2
Software 1- INSTRUÇÕES que quando executadas produzem a função e o desempenho desejados 2 - ESTRUTURAS DE DADOS que possibilitam que os programas manipulem adequadamente a informação 3 - DOCUMENTOS que descrevem a operação e o uso dos programas 3
Características do Software 1- desenvolvido ou projetado por engenharia, não manufaturado no sentido clássico 2- não se desgasta, mas se deteriora 3- a maioria é feita sob medida em vez de ser montada a partir de componentes existentes 4
Curva de falhas para o hardware índice de falhas mortalidade infantil desgaste tempo 5
Curva de falhas do software índice de falhas mudança curva real curva idealizada tempo 6
Aplicações do software BÁSICO coleção de programas escritos para dar apoio a outros programas DE TEMPO REAL software que monitora, analisa e controla eventos do mundo real COMERCIAL sistemas de operações comerciais e tomadas de decisões administrativas CIENTÍFICO E DE ENGENHARIA caracterizado por algoritmos de processamento de números 7
Aplicações do software EMBUTIDO usado para controlar produtos e sistemas para os mercados industriais e de consumo DE COMPUTADOR PESSOAL envolve processamento de textos, planilhas eletrônicas, diversões, etc. DE INTELIGÊNCIA ARTIFICIAL faz uso de algoritmos não numéricos para resolver problemas que não sejam favoráveis à computação ou à análise direta 8
EVOLUÇÃO DO SOFTWARE 9
Evolução do software (1950-1965) O hardware sofreu contínuas mudanças O software era uma arte "secundária" para a qual havia poucos métodos sistemáticos O hardware era de propósito geral O software era específico para cada aplicação Não havia documentação 10
Evolução do software (1965-1975) Multiprogramação e sistemas multiusuários Técnicas interativas Sistemas de tempo real 1a. geração de SGBD s Produto de sofwtare - software houses Bibliotecas de Software Cresce nro. de sistemas baseado em computador Manutenção quase impossível... CRISE DE SOFTWARE 11
Evolução do software (1975 hoje) Sistemas distribuídos Redes locais e globais Uso generalizado de microprocessadores - produtos inteligentes Hardware de baixo custo Impacto de consumo 12
Evolução do software - Quarta era do software de computador Tecnologias orientadas o objetos Sistemas especialistas e software de inteligência artificial usados na prática Software de rede neural artificial Computação Paralela 13
Crise de software Refere-se a um conjunto de problemas encontrados no desenvolvimento de software: 1- As estimativas de prazo e de custo frequentemente são imprecisas Não dedicamos tempo para coletar dados sobre o processo de desenvolvimento de software Sem nenhuma indicação sólida de produtividade, não podemos avaliar com precisão a eficácia de novas ferramentas, métodos ou padrões 14
Crise de software 2- A produtividade das pessoas da área de software não tem acompanhado a demanda por seus serviços Os projetos de desenvolvimento de software normalmente são efetuados apenas com um vago indício das exigências do cliente 15
Crise de software 3- A qualidade de software às vezes é menos que adequada Só recentemente começam a surgir conceitos quantitativos sólidos de garantia de qualidade de software 4- O software existente é muito difícil de manter A tarefa de manutenção devora o orçamento destinado ao software A facilidade de manutenção não foi enfatizada como um critério importante 16
Crise de software estimativas de prazo e de custo produtividade das pessoas qualidade de software software difícil de manter 17
Causas dos problemas associados à crise de software 1- PRÓPRIO CARÁTER DO SOFTWARE O software é um elemento de sistema lógico e não físico. Consequentemente o sucesso é medido pela qualidade de uma única entidade e não pela qualidade de muitas entidades manufaturadas O software não se desgasta, mas se deteriora 18
Causas dos problemas associados à crise de software 2- FALHAS DAS PESSOAS RESPONSÁVEIS PELO DESENVOLVIMENTO DE SOFTWARE Gerentes sem nenhum background em software Os profissionais da área de software têm recebido pouco treinamento formal em novas técnicas para o desenvolvimento de software Resistência a mudanças 19
Causas dos problemas associados à crise de software 3- MITOS DO SOFTWARE Propagaram desinformação e confusão administrativos cliente profissional 20
Mitos do software: ADMINISTRATIVOS Mito: Já temos um manual repleto de padrões e procedimentos para a construção de software. Isso não oferecerá ao meu pessoal tudo o que eles precisam saber? Realidade: Será que o manual é usado? Os profissionais sabem que ele existe? Ele reflete a prática moderna de desenvolvimento de software? Ele é completo? 21
Mitos do software: ADMINISTRATIVOS Mito: Meu pessoal tem ferramentas de desenvolvimento de software de última geração; afinal lhes compramos os mais novos computadores. Realidade: É preciso muito mais do que os mais recentes computadores para se fazer um desenvolvimento de software de alta qualidade. 22
Mitos do software: ADMINISTRATIVOS Mito: Se nós estamos atrasados nos prazos, podemos adicionar mais programadores e tirar o atraso. Realidade: O desenvolvimento de software não é um processo mecânico igual à manufatura. Acrescentar pessoas em um projeto torna-o ainda mais atrasado. Pessoas podem ser acrescentadas, mas somente de uma forma planejada. 23
Mitos do software: CLIENTE Mito: Uma declaração geral dos objetivos é suficiente para se começar a escrever programas - podemos preencher os detalhes mais tarde. Realidade: Uma definição inicial ruim é a principal causa de fracassos dos esforços de desenvolvimento de software. É fundamental uma descrição formal e detalhada do domínio da informação, Professora função, MSc. Michelle Parreira desempenho, 24
Mitos do software: CLIENTE Mito: Os requisitos de projeto modificam-se continuamente, mas as mudanças podem ser facilmente acomodadas, porque o software é flexível. Realidade: Uma mudança, quando solicitada tardiamente num projeto, pode ser maior do que a ordem de magnitude mais dispendiosa da mesma 25 mudança solicitada nas fases iniciais.
Mitos do software: CLIENTE MAGNITUDE DAS MUDANÇAS FASES CUSTO DE MANUTENÇÃO DEFINIÇÃO 1 x DESENVOLVIMENTO MANUTENÇÃO 1.5-6x 60-100x 26
Mitos do software: PROFISSIONAL Mito: Assim que escrevermos o programa e o colocarmos em funcionamento nosso trabalho estará completo. Realidade: Os dados da indústria indicam que entre 50 e 70% de todo esforço gasto num programa serão despendidos depois que ele for entregue pela primeira vez ao cliente. 27
Mitos do software: PROFISSIONAL Mito: Enquanto não tiver o programa "funcionando", eu não terei realmente nenhuma maneira de avaliar sua qualidade. Realidade: Um programa funcionando é somente uma parte de uma Configuração de Software que inclui todos os itens de informação produzidos Professora durante MSc. Michelle Parreira a construção e 28
ENGENHARIA DE SOFTWARE 29
Engenharia de Software Abrange um conjunto de três elementos fundamentais: Processo, Métodos e Ferramentas PROCESSO Define os passos gerais para o desenvolvimento e manutenção do software Serve como uma estrutura de encadeamento de métodos e ferramentas MÉTODOS São os how to's de como fazer um passo específico do processo FERRAMENTAS Automatizam o processo e os métodos. Quando as ferramentas são integradas é estabelecido um sistema de suporte ao desenvolvimento de software chamado CASE - Computer Aided Software Engineering 30
Terminologias da área PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE Conjunto de atividades que podem ser seguidas para que seja atingido algum objetivo; MODELOS DE PROCESSO Uma representação de um processo que pode ser adaptada para uma empresa/projeto específico; Em uma representação muito simplificada, pode ser considerado um modelo de ciclo de vida. MÉTODO Descrição sistemática de como deve-se realizar uma determinada atividade ou tarefa; A descrição é normalmente feita através de padrões e guias; Pode fazer referência a linguagens textuais ou de modelagem. METODOLOGIA Estudo de métodos, processos, ferramentas, que são utilizadas no desenvolvimento de software; STAKEHOLDER Uma pessoa, grupo ou organização interessada ou que seja afetada pelo projeto: Ex: O gerente de projetos; A equipe de desenvolvimento; Os patrocinadores do projeto; A comunidade; O governo etc. É um conceito mais amplo que o de usuário. 31
Objetivos da Engenharia de Software Controle sobre o desenvolvimento de software dentro de custos, prazos e níveis de qualidade desejados Produtividade no desenvolvimento, operação e manutenção de software Qualidade versus Produtividade Permitir que profissionais tenham controle sobre o desenvolvimento de software dentro de custos, prazos e níveis de qualidade desejados
Características da Engenharia de Software A Engenharia de Software se refere a software (sistemas) desenvolvidos por grupos ao invés de indivíduos usa princípios de engenharia ao invés de arte, e inclui tanto aspectos técnicos quanto não técnicos
O que é um software de qualidade? O software que satisfaz os requisitos solicitados pelo usuário. Deve ser fácil de manter, ter boa performance, ser confiável e fácil de usar. Alguns atributos de qualidade: Manutenibilidade O software deve evoluir para atender os requisitos que mudam Eficiência O software não deve desperdiçar os recursos do sistema Usabilidade O software deve ser fácil de usar pelos usuários para os quais ele foi projetado
Qualidade de Software (um exemplo para o Varejo) Correto A loja não pode deixar de cobrar por produtos comprados pelo consumidor Robusto e altamente disponível A loja não pode parar de vender Eficiente O consumidor não pode esperar A empresa quer investir pouco em recursos computacionais (CPU, memória, rede)
Qualidade de Software (um exemplo para o Varejo) Amigável e fácil de usar A empresa quer investir pouco em treinamento Altamente extensível e adaptável A empresa tem sempre novos requisitos (para ontem!) A empresa quer o software customizado do seu jeito (interface, teclado, idioma, moeda, etc.) Reusável Várias empresas precisam usar partes de um mesmo sistema
Qualidade de Software (um exemplo para o Varejo) Aberto, compatível, de fácil integração com outros sistemas A empresa já tem controle de estoque, fidelização, etc. Portável e independente de plataforma (hw e sw) A empresa opta por uma determinada plataforma Baixo custo de instalação e atualização A empresa tem um grande número de PDVs
Produtividade Custo de desenvolvimento reduzido A empresa consumidora quer investir pouco em software A empresa produtora tem que oferecer software barato Tempo de desenvolvimento reduzido Suporte rápido às necessidades do mercado
Importância da Engenharia de Software Qualidade de software e produtividade garantem: Disponibilidade de serviços essenciais Segurança de pessoas Competitividade das empresas o Produtores o Consumidores
ENGENHARIA DE SOFTWARE UMA VISÃO GENÉRICA 40
Engenharia de Software Uma visão genérica O processo de desenvolvimento de software contém 3 fases genéricas, independentes do modelo de engenharia de software escolhido: DEFINIÇÃO, DESENVOLVIMENTO e MANUTENÇÃO. 41
Engenharia de Software Uma visão genérica FASE DE DEFINIÇÃO: o que será desenvolvido. Análise do Sistema: define o papel de cada elemento num sistema baseado em computador, atribuindo em última análise, o papel que o software desempenhará. Planejamento do Projeto de Software: assim que o escopo do software é estabelecido, os riscos são analisados, os recursos são alocados, os custos são estimados e, tarefas e programação de trabalho definidas. Análise de Requisitos: o escopo definido para o software proporciona uma direção, mas uma definição detalhada do domínio da informação e da função do software é necessária antes que o trabalho inicie. 42
Engenharia de Software Uma visão genérica DESENVOLVIMENTO: como o software vai ser desenvolvido. Projeto de Software: traduz os requisitos do software num conjunto de representações (algumas gráficas, outras tabulares ou baseadas em linguagem) que descrevem a estrutura de dados, a arquitetura do software, os procedimentos algorítmicos e as características de interface. Codificação: as representações do projeto devem ser convertidas numa linguagem artificial (a linguagem pode ser uma linguagem de programação convencional ou uma linguagem não procedimental) que resulte em instruções que possam ser executadas pelo computador. Realização de Testes do Software: logo que o software é implementado numa forma executável por máquina, ele deve ser testado para que se possa descobrir defeitos de função, lógica e implementação. 43
Engenharia de Software Uma visão genérica FASE DE MANUTENÇÃO: concentra-se nas mudanças que ocorrerão depois que o software for liberado para uso operacional Correção Adaptação Melhoramento Funcional 44
Engenharia de Software Uma visão genérica Correção: mesmo com as melhores atividades de garantia de qualidade de software, é provável que o cliente descubra defeitos no software. A manutenção corretiva muda o software para corrigir defeitos. Adaptação: com o passar do tempo, o ambiente original (por exemplo a CPU, o sistema operacional e periféricos) para o qual o software foi desenvolvido provavelmente mudará. A manutenção adaptativa muda o software para acomodar mudanças em seu ambiente. 45
Engenharia de Software Uma visão genérica Melhoramento Funcional: a medida que o software é usado, o cliente/usuário reconhecerá funções adicionais que oferecerão benefícios. A manutenção perfectiva estende o software para além de suas exigências funcionais originais. 46
Engenharia de Software Uma visão genérica ATIVIDADES DE PROTEÇÃO as fases e etapas correlatas descritas são complementadas por uma série de atividades de proteção. Revisões: efetuadas para garantir que a qualidade seja mantida à medida que cada etapa é concluída. Documentação: é desenvolvida e controlada para garantir que informações completas sobre o software estejam disponíveis para uso posterior. Controle das Mudanças: é instituído de forma que as mudanças possam ser aprovadas e acompanhadas. 47
Algumas considerações Engenharia de software é uma disciplina de engenharia que está envolvida com todos os aspectos da produção de software Produtos de software consistem de programas desenvolvidos e documentação associada. Alguns atributos de qualidade do produto são manutenibilidade, eficiência e usabilidade O processo de software consiste nas atividades que são envolvidas no desenvolvimento de produtos de software
Algumas considerações Métodos são formas organizadas de produzir software. Eles incluem sugestões para o processo a ser seguido, as notações a serem usadas, regras que governam as descrições do sistema que são produzidas e diretrizes de projeto Ferramentas CASE são sistemas de software que são projetados para suportar as atividades rotineiras no processo de software, como edição de diagramas de projeto e verificação de consistência dos diagramas
Alguns ciclos de vida mais conhecidos são: Ciclo de Vida Clássico Prototipação Modelo Espiral CICLO DE VIDA DE SOFTWARE 50
Para escolha de um Ciclo de Vida de software: natureza do projeto e da aplicação métodos e ferramentas a serem usados controles e produtos que precisam ser entregues 51
Ciclo de Vida Clássico Cascata modelo mais antigo e o mais amplamente usado da engenharia de software modelado em função do ciclo da engenharia convencional requer uma abordagem sistemática, seqüencial ao desenvolvimento de software 52
Ciclo de Vida Clássico Cascata Engenharia de Sistemas Análise de Requisitos Projeto Codificação Testes Manutenção 53
Ciclo de Vida Clássico Cascata Atividades do Ciclo de Vida Clássico 1- ANÁLISE E ENGENHARIA DE SISTEMAS envolve a coleta de requisitos em nível do sistema, com uma pequena quantidade de projeto e análise de alto nível esta visão é essencial quando o software deve fazer interface com outros elementos (hardware, pessoas e banco de dados) 54
Ciclo de Vida Clássico Cascata Atividades do Ciclo de Vida Clássico 2- ANÁLISE DE REQUISITOS DE SOFTWARE o processo de coleta dos requisitos é intensificado e concentrado especificamente no software deve-se compreender o domínio da informação, a função, desempenho e interfaces exigidos os requisitos (para o sistema e para o software) são documentados e revistos com o cliente 55
Ciclo de Vida Clássico Cascata Atividades do Ciclo de Vida Clássico 3- PROJETO tradução dos requisitos do software para um conjunto de representações que podem ser avaliadas quanto à qualidade, antes que a codificação se inicie se concentra em 4 atributos do programa: o Estrutura de Dados, o Arquitetura de Software, o Detalhes Procedimentais e o Caracterização de Interfaces 56
Ciclo de Vida Clássico Cascata Atividades do Ciclo de Vida Clássico 4- CODIFICAÇÃO tradução das representações do projeto para uma linguagem artificial resultando em instruções executáveis pelo computador 57
Ciclo de Vida Clássico Cascata Atividades do Ciclo de Vida Clássico 5- 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. 58
Ciclo de Vida Clássico Cascata Atividades do Ciclo de Vida Clássico 6- 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 em seu ambiente externo e exigência do cliente para acréscimos funcionais e de desempenho 59
Ciclo de Vida Clássico Cascata Problemas com o Ciclo de Vida Clássico projetos 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 projetos 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 60
Ciclo de Vida Prototipação processo que possibilita que o desenvolvedor crie um modelo do software que deve ser construído. idealmente, o modelo (protótipo) serve como um mecanismo para identificar os requisitos de software. apropriado para quando o cliente definiu um conjunto de objetivos gerais para o software, mas não identificou requisitos de entrada, processamento e saída com detalhes. 61
Ciclo de Vida Prototipação início fim construção produto obtenção dos requisitos projeto rápido refinamento protótipo avaliação protótipo construção protótipo 62
Ciclo de Vida Atividades de Prototipação 1- OBTENÇÃO DOS REQUISITOS: desenvolvedor e cliente definem os objetivos gerais do software, identificam quais requisitos são conhecidos e as áreas que necessitam de definições adicionais. 2- PROJETO RÁPIDO: representação dos aspectos do software que são visíveis ao usuário (abordagens de entrada e formatos de saída) 3- CONSTRUÇÃO PROTÓTIPO: implementação do projeto rápido 4- AVALIAÇÃO DO PROTÓTIPO: cliente e desenvolvedor avaliam o protótipo 63
Ciclo de Vida Atividades de Prototipação 5- REFINAMENTO DOS REQUISITOS: cliente e desenvolvedor refinam os requisitos do software a ser desenvolvido. Ocorre neste ponto um processo de iteração que pode conduzir a atividade 1 até que as necessidades do cliente sejam satisfeitas e o desenvolvedor compreenda o que precisa ser feito. 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. 64
Ciclo de Vida Problemas com a Prototipaçã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. Não aceita bem a ideia que a versão final do software vai ser construída e "força" a utilização do protótipo como produto final desenvolvedor frequentemente faz uma implementação comprometida (utilizando o que está disponível) com o objetivo de produzir rapidamente um protótipo. Depois de um tempo ele familiariza com essas escolhas, e esquece que elas não são apropriadas para o produto final. 65
Ciclo de Vida Considerações sobre Prototipação ainda que possam ocorrer problemas, a prototipação é um ciclo de vida eficiente. a chave é definir-se 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 a fim de definir os requisitos. 66
Ciclo de Vida: MODELOS ITERATIVOS Requisitos de sistema SEMPRE evoluem durante curso de um projeto. Assim a iteração do processo sempre faz parte do desenvolvimento de grandes sistemas Iterações podem ser aplicadas a quaisquer dos modelos de de ciclo de vida Duas abordagens (relacionadas) Desenvolvimento espiral Desenvolvimento incremental
Ciclo de Vida: MODELO ITERATIVO ESPIRAL engloba as melhores características do ciclo de vida Clássico e da Prototipação, adicionando um novo elemento: a Análise de Risco segue a abordagem de passos sistemáticos do Ciclo de Vida Clássico incorporando-os numa estrutura iterativa que reflete mais realisticamente o mundo real usa a Prototipação, em qualquer etapa da evolução do produto, como mecanismo de redução de riscos 68
Ciclo de Vida: MODELO ITERATIVO ESPIRAL planejamento análise dos riscos decisão de continuar ou não avaliação do cliente engenharia na direção de um sistema concluído 69
70 Ciclo de Vida: MODELO ITERATIVO ESPIRAL (Barry Boehm, 1988)
Ciclo de Vida: MODELO ITERATIVO ESPIRAL Atividades do ciclo de vida em Espiral 1- PLANEJAMENTO: determinação dos objetivos, alternativas e restrições 2- ANÁLISE DE RISCO: análise das alternativas e identificação / resolução dos riscos 3- CONSTRUÇÃO: desenvolvimento do produto no nível seguinte 4- AVALIAÇÃO DO CLIENTE: avaliação do produto e planejamento das novas fases 71
Ciclo de Vida: Desenvolvimento em Espiral Acrescenta aspectos gerenciais ao processo de desenvolvimento de software. análise de riscos em intervalos regulares do processo de desenvolvimento de software planejamento controle tomada de decisão O processo é representado como uma espiral em vez de uma sequência de atividades Cada volta na espiral representa uma fase no processo Não há fases fixas como especificação ou projeto - voltas na espiral são escolhidas dependendo do que é requerido Riscos são avaliados explicitamente e resolvidos ao longo do processo
Ciclo de Vida: Comentários sobre o ciclo de vida em Espiral é, atualmente, a abordagem mais realística para o desenvolvimento de software em grande escala. usa uma abordagem que capacita o desenvolvedor e o cliente a entender e reagir aos riscos em cada etapa evolutiva. pode ser difícil convencer os clientes que uma abordagem "evolutiva" é controlável exige considerável experiência na determinação de riscos e depende dessa experiência para ter sucesso 73
Ciclo de Vida: MODELO ITERATIVO Desenvolvimento Incremental Em vez de entregar o sistema como um todo, o desenvolvimento e a entrega são divididos em incrementos, com cada incremento entregando parte da funcionalidade requerida Requisitos dos usuários são priorizados e os requisitos de mais alta prioridade são incluídos nas iterações iniciais Uma vez que o desenvolvimento de um incremento é iniciado, os requisitos são "congelados". Embora os requisitos possam continuar a evoluir para incrementos posteriores
Ciclo de Vida: MODELO ITERATIVO Desenvolvimento Iterativo e Incremental (do RUP)
FASES DO RUP Concepção Visão aproximada, casos de negócio, escopo e estimativas iniciais Elaboração Visão refinada, implementação iterativa da arquitetura proposta, resolução dos altos riscos, análise da maioria dos requisitos, escopo e estimativas bem definidos Construção Implementação iterativa dos elementos restantes de menor risco e mais fáceis e preparação para a implantação. Transição Testes beta e implantação 76
Métodos Ágeis Valoriza-se: Indivíduos e interações mais que processos e ferramentas; Software em funcionamento mais que documentação abrangente; Colaboração com o cliente mais que negociação de contratos; Responder a mudanças mais que seguir um plano; 77
Exercícios para fazer no caderno 1) Qual a diferença da construção de um software e de um hardware? 2) O que foi a crise do software? Comente sobre as causas dos problemas associados à crise de software. 3) O que é engenharia de software? Quais os três elementos fundamentais da engenharia de software? Explique-os. 4) Diferencie processo, modelo, método e metodologia. 5) O que é stakeholder? 6) O que significa um software de qualidade? 7) Quais são as três fases genéricas de um processo de desenvolvimento de software? Explique-as. 8) O que é ciclo de vida de software? Explique os modelos cascata, prototipação, espiral e incremental. 9) Comente sobre RUP. 10) O que são os métodos ágeis? 78
BIBLIOGRAFIA BÁSICA Engenharia de Software - Ian Sommerville. 8ª edição. Pearson Education Engenharia de Software Roger Pressman 6ª edição. McGraw-Hill Engenharia de Software Wilson de Pádua Paula Filho 2ª edição. LTC 79
AGUARDEM PRÓXIMO CONTEÚDO!!! Contato: parreira.michelle@gmail.com
Aprender é a única coisa de que a mente nunca se cansa, nunca tem medo e nunca se arrepende Leonardo da Vinci 81