Fundamentos de Tecnologia da Informaçao

Prévia do material em texto

�PAGE �
SUMÁRIO
3INTRODUÇÃO	�
71	DESENVOLVIMENTO	�
162	CONCLUSÃO	�
17GLOSSÁRIO	�
18REFERÊNCIAS:	�
��
INTRODUÇÃO
Um modelo de processo de desenvolvimento de software, ou simplesmente modelo de processo de software, pode ser visto como uma representação, ou abstração dos objetos e atividades envolvidas no processo de software. 
Além disso, oferece uma forma mais abrangente e fácil de representar o gerenciamento de processos de software e consequentemente o progresso do projeto.
Objetivo
Apresentar os principais paradigmas e modelos de processos de software, demonstrar o ciclo de vida do desenvolvimento de software e enfatizar os processos de especificação de requisitos, projeto, implementação, testes e mudanças.
�Processo de software
“É uma sequência coerente de práticas que objetiva o desenvolvimento ou evolução de sistemas de software. Estas práticas englobam as atividades de especificação, projeto, implementação, testes e caracterizam-se pela interação de ferramentas, pessoas e métodos”.
�Modelo de processo de software
“Um modelo de processo de software é uma representação abstrata de um processo. Ele apresenta uma descrição de um processo a partir de uma perspectiva específica”.
Exemplos de alguns modelos de processo de software;
�Modelos ciclo de vida:
O ciclo de vida é identificado como um conjunto de fases ou etapas que representam uma evolução desde o nascimento da necessidade de criação de um software até sua descontinuidade ou morte.
As fases são identificadas pelos seguintes elementos; a) produtos a serem utilizados ao iniciar, geralmente são produtos resultados das fases anteriores; b) recursos necessários para desempenhar as atividades previstas, sejam recursos materiais, temporais ou pessoais; c) métodos para a realização das tarefas, de acordo com o planejado e previsto pelos recursos; d) resultados esperados, finais ou para ser utilizados na próxima fase.
Estes "modelos de ciclo de vida" ou "modelos de processos" são tipicamente produzidos a partir de uma perspectiva de que poderão existir vários modelos para o mesmo processo. Nenhum modelo é capaz de dar uma visão completa de um determinado processo.
�Sequencial ou Cascata com fases distintas de especificação, projeto e desenvolvimento: 
O modelo em cascata é um modelo de desenvolvimento de software sequencial no qual o desenvolvimento é visto como um fluir constante para frente (como uma cascata) através das fases de análise de requisitos, projeto, implementação, testes (validação), integração, e manutenção de software. 
A origem do termo cascata é frequentemente citado como sendo um artigo publicado em 1970 por W. W. Royce; ironicamente, Royce defendia um abordagem iterativa para o desenvolvimento de software e nem mesmo usou o termo cascata. 
�Desenvolvimento iterativo e incremental:
O Desenvolvimento Iterativo e Incremental é um dos clássicos modelos de processo de desenvolvimento de software criado em resposta às fraquezas do modelo em cascata, o mais tradicional. 
Os dois padrões mais conhecidos de sistemas iterativos de desenvolvimento são o RUP (Processo Unificado da Rational) e o Desenvolvimento ágil de software. Por isso o desenvolvimento iterativo e incremental é também uma parte essencial da Programação Extrema e outros.
�Evolucional ou Prototipação - especificação, projeto e desenvolvimento de protótipos:
Prototipação é uma abordagem baseada em uma visão evolutiva do desenvolvimento de software, afetando o processo como um todo. 
Envolve a produção de versões iniciais -protótipos (análogo a maquetes para a arquitetura) - de um sistema futuro com o qual é possível realizar verificações e experimentos, com o intuito de avaliar algumas de suas características antes que o sistema venha realmente a ser construído, de forma definitiva.
�Espiral - evolução através de vários ciclos completos de especificação, projeto e desenvolvimento:
O Modelo em espiral é um processo de desenvolvimento de software que combina elementos de projeto prototipação-em-etapas, em um esforço para combinar as vantagens dos conceitos de top-down e bottom-up, acrescentando um novo elemento, a análise de riscos que falta a esses paradigmas.
O modelo em espiral foi definido por Barry Boehm em seu artigo de 1988 A Spiral Model of Software Development and Enhancement. Este modelo não foi o primeiro a discutir o Desenvolvimento iterativo e incremental, mas ele foi o primeiro modelo a explicar o porquê do modo iterativo. 
Cada fase inicia com um objetivo esperado e termina como uma revisão pelo cliente do progresso (que deve ser interna) e assim por diante. Esforços de análise e engenharia são aplicados em cada fase do projeto, com um olho focado no objetivo do projeto.
�Componentizado:
Reuso através de montagem de componentes já existentes.
�Formal:
Implementação a partir de modelo matemático formal.
�Ágil:
Desenvolvimento ágil de software (do inglês Agile software development) ou Método ágil é um conjunto de metodologias de desenvolvimento de software. O desenvolvimento ágil, tal como qualquer metodologia de software, providencia uma estrutura conceitual para reger projetos de engenharia de software.
�RAD:
Rapid Application Development (RAD) ou Desenvolvimento Rápido de Aplicação (em português), é um modelo de processo de desenvolvimento de software iterativo e incremental que enfatiza um ciclo de desenvolvimento extremamente curto (entre 60 e 90 dias).
O termo foi registrado por James Martin em 1991 e tem substituído gradativamente o termo de prototipação rápida que já foi muito utilizada no passado
�Quarta geração:
Este modelo é baseado no uso de um conjunto de ferramentas de software que possibilita que o desenvolvedor de software especifique algumas características do software em nível elevado. Em seguida a ferramenta gera, automaticamente, o código-fonte do software.
A grande dificuldade em se aplicar este modelo é que nem todas as aplicações possíveis de desenvolvimento são aplicáveis nas ferramentas existentes para este modelo de clico de vida.
�RUP- Rational Unified Process
O Rup se baseia em disciplinas, tarefas e responsabilidades e tem duas dimensões, uma que trata as fases do ciclo do processo de desenvolvimento (modelagem de negócios, requisitos, análise e projeto, implementações, teste, implantação, gerenciamento de configuração e mudança, gerenciamento do processo e ambiente) de forma dinâmica expressa em termos de fases iterações e marcos; já a outra dimensão trata das disciplinas, atividades, fluxos de trabalho, artefatos e papéis do processo de desenvolvimento.
DESENVOLVIMENTO
Desenvolvimento rápido de software
Segundo PERINE et, al (2013), os negócios atualmente operam em um ambiente global sujeito a rápidas mudanças. Eles tem que responder as novas oportunidades e mercados, mudanças de condições econômicas e ao surgimento de produtos e serviços concorrentes. O software é a parte de quase todas as operações de negócios e, assim, é essencial que um novo software seja desenvolvido rapidamente para aproveitar as novas oportunidades e responder as pressões competitivas.
Os processos de desenvolvimento de software baseados em especificações completas de requisitos, projeto, construção e teste de sistema não estão voltados para desenvolvimento rápido de software. Quando os requisitos mudam ou quando os problemas com requisitos são descobertos, o projeto ou a implementação precisa ser retrabalhada e retestada. Como consequência, um processo em cascata convencional ou baseado em especificações é geralmente prolongado e o software final é entregue para o cliente muito depois de ter sido originalmente especificado.
Processo de desenvolvimento rápido de software são projetados para criar software útil e rapidamente. Geralmente, eles são processos iterativos nos quais a especificação, o projeto, o desenvolvimento e oteste são intercalados.
O software não é desenvolvido e disponibilizado integralmente, mas em uma serie de incrementos, e cada incremento inclui uma nova funcionalidade do sistema. Embora existam muitas abordagens para o desenvolvimento rápido, elas compartilham algumas características fundamentais:
Os processos de especificação, projeto e implementação são concorrentes. Não há especificação detalhada de sistema e a documentação de projeto é minimizada ou gerada automaticamente por um ambiente de programação usado para implementar o sistema. O documento de requisito de usuário define somente as características mais importantes do sistema.
O sistema é desenvolvido em uma serie de incrementos. Os usuários finais participam da especificação e da avaliação de cada incremento. Eles podem propor alterações e novos requisitos que devem ser implementados em um incremento posterior do sistema.
As interfaces com o usuário do sistema são geralmente desenvolvidas usando-se um sistema de desenvolvimento interativo que permite que o projeto de interface seja criado rapidamente por desenho e inserção de ícones na interface. O sistema poderá, então gerar uma interface baseada na WEB para um navegador ou uma interface para uma plataforma especifica, como o Microsoft Windows.
O desenvolvimento incremental envolve a produção e a entrega do software em incrementos, em vez de em um único pacote. Cada iteração do processo produz um novo incremento de software. As duas principais vantagens de adotar uma abordagem incremental para o desenvolvimento são:
Entrega acelerada dos serviços ao cliente. Os incrementos iniciais do sistema podem fornecer uma funcionalidade de alta prioridade, de forma que os clientes logo poderão obter valor do sistema durante seu desenvolvimento. Os clientes podem ver seus requisitos em prática e especificar mudanças para serem incorporadas nos releases posteriores do sistema.
Engajamento do usuário com o sistema. Os usuários do sistema precisam estar envolvidos no processo de desenvolvimento incremental porque eles devem dar feedback à equipe de desenvolvimento sobre os incrementos entregues. Esse envolvimento não significa somente que o sistema terá mais chances de atender aos requisitos, mas também que os usuários finais que estão comprometidos com o sistema querem vê-lo funcionando.
O desenvolvimento de software incremental é uma abordagem muito melhor para a maioria de sistema de negócios de e-commerce, pois ela reflete a maneira fundamental como tendemos a resolver os problemas. Raramente trabalhamos uma solução completa de problemas antecipadamente, mas seguimos em direção à solução por meio de série de passos, retrocedendo quando percebemos que cometemos erros. 
Contudo, pode haver dificuldades reais como essas abordagens, particularmente em grandes empresas como procedimentos bastante rígidos, e em organizações nas quais o desenvolvimento de software em geral é terceirizado.
Naturalmente, há alguns tipos de sistemas nos quais o desenvolvimento e a entrega incrementais não são a melhor abordagem. Esses são sistemas muito grandes, nos quais o desenvolvimento pode envolver equipes que trabalham em locais diferentes; alguns sistemas embutidos, nos quais o software depende de desenvolvimento de hardware e alguns sistemas críticos, nos quais todos os requisitos devem ser analisados quanto a interações que possam comprometer a segurança do sistema.
Esses sistemas naturalmente, sofrem dos mesmos problemas de incerteza e mudança de requisitos. Portanto, para resolver esses problemas, um processo híbrido pode ser usado como plataforma de experimentos dos requisitos de sistema e projeto. Com a experiência obtida com o protótipo, você pode aumentar a confiança de que os requisitos atendem as reais necessidades do sistema.
�Métodos ágeis
Nas décadas de 1980 e início da década de 1990, havia uma visão geral de que a melhor maneira de obter o melhor software era por meio de um cuidadoso planejamento de projeto, garantia de qualidade formalizada, uso de métodos de análise e projeto apoiados por ferramentas CASE e controlados por um rigoroso processo de desenvolvimento de software. Essa visão vem, essencialmente, da comunidade de engenharia de software preocupada com sistemas grandes e de longa vida, geralmente constituídos de uma grande número de programas individuais. 
Esse software era desenvolvido por equipes grandes que algumas vezes trabalhavam para empresas diferentes. Elas muitas vezes estavam separadas geograficamente e trabalhavam no software durante longos períodos. Essas abordagens, envolvem um overhead significativo ou seja, processamento ou armazenamento em excesso, quando o trabalho de várias equipes de desenvolvimento tem de ser coordenado, quando o sistema é crítico e quando muitas pessoas diferentes serão envolvidas na manutenção do software durante seu tempo de vida. 
Contudo, quando essa abordagem de desenvolvimento pesada e baseada em planos foi aplicada em sistemas de pequenas e medias empresas, o overhead envolvido foi tão grande que algumas vezes dominou o processo de desenvolvimento de software. O tempo gasto para determinar como o sistema deveria ser desenvolvido era maior que o empregado no desenvolvimento do programa em testes. A medida que os requisitos do sistema mudavam, o retrabalho era essencial e, em princípio pelo menos, a especificação e o projeto tinham que mudar com o programa.
A insatisfação com essas abordagens pesadas levou um número de desenvolvedores na década de 1990 a propor novos métodos ágeis. Esses permitiam que a equipe de desenvolvimento se concentrasse no software somente em vez de em seu projeto e documentação. Geralmente os métodos ágeis contam com uma abordagem interativa para especificação, desenvolvimento e entrega de software, e foram criados principalmente para apoiar o desenvolvimento de aplicações de negócios nas quais os requisitos de sistema mudam rapidamente durante o processo de desenvolvimento.
Embora esses métodos ágeis sejam todos baseados na noção de desenvolvimento e entrega incrementais, eles propõem processos diferentes para conseguir isso. Contudo, compartilham um conjunto de princípios e, portanto, têm muito em comum. 
Extreme Programming (XP):�
A Extreme Programming (XP) é uma Metodologia Ágil para equipes pequenas e médias que desenvolvem software baseado em requisitos vagos e que se modificam rapidamente. Entre as principais diferenças da XP em relação às Metodologias Clássicas estão o feedback constante, a abordagem incremental e o encorajamento da comunicação entre as pessoas.
A maioria das regras da XP causa surpresa no primeiro contato e muitas não fazem sentido se aplicadas isoladamente. É a força de seu conjunto que sustenta o sucesso da XP, trazendo uma verdadeira revolução no desenvolvimento de software.
O principal objetivo da XP é dar agilidade ao desenvolvimento do projeto e busca garantir a satisfação do cliente. As práticas, regras, e os valores da XP garantem um agradável ambiente de desenvolvimento de software para os seus seguidores, que são conduzidos por quatro princípios básicos:
A – Princípio da Comunicação - busca manter o melhor relacionamento possível entre clientes e desenvolvedores, preferindo conversas pessoais a outros meios de comunicação.
 B – Princípio da Simplicidade - entende-se como simplicidade, a busca do objetivo de implementar o software com o menor número possível de classes e métodos. Outra ideia importante deste princípio é procurar implementar apenas requisitos atuais, evitando assim adicionar funcionalidades que podem ser importantes apenas no futuro. A aposta da XP é que é melhor fazer algo simples hoje do que implementar algo complicado hoje que talvez não venha a ser usado.
C – Princípio do Feedback - A prática do feedback constante significa que o desenvolvedor terá informações constantes do código e do cliente. A informação do código é dada pelos testes constantes, que indicam os erros tanto individuais quanto do softwareintegrado.
D – Princípio da Coragem - Sabe-se que não são todas as pessoas que possuem facilidade de comunicação e têm bom relacionamento interpessoal, este princípio também dá suporte à simplicidade, pois assim que a oportunidade de simplificar o software é percebida, a equipe pode experimentar e buscar novas soluções, além disso, é preciso coragem para obter e cobrar constantemente um feedback do cliente.
Principais práticas da Extreme Programming (XP):
A – Planejamento - Define o que é ou não necessário ser feito no projeto. A XP baseia-se em requisitos atuais para desenvolvimento de software, não em requisitos futuros.
B - Entregas Frequentes - Baseiam-se no desenvolvimento de um software simples, e conforme os requisitos aparecem, há a atualização da versão do software. Cada versão entregue deve ter o menor tamanho possível, contendo os requisitos de maior valor para o negócio. É recomendado que as versões devem ser entregues a cada mês, ou no máximo a cada dois meses, aumentando a possibilidade de feedback rápido do cliente.
C - Metáfora - São as descrições de um software sem a utilização de termos técnicos com o objetivo de guiar o desenvolvimento do software com a maior transparência possível para o cliente.
D - Projeto simples - O software desenvolvido de acordo com a metodologia XP deve ser o mais simples possível e satisfazer os requisitos atuais, sem a preocupação de requisitos futuros. Eventuais requisitos futuros devem ser adicionados assim que eles realmente existirem.
E – Testes - A Extreme Programming (XP) prioriza a validação do projeto durante todo o processo de desenvolvimento. Os desenvolvedores implementam o software criando primeiramente os testes.�
F - Programação em pares - A implementação do código é feita em dupla, ou seja, dois desenvolvedores trabalham em um único computador. Procurando identificar erros sintáticos e semânticos, pensando estrategicamente em como melhorar o código que está sendo implementado. Esses papéis podem e devem ser alterados sempre que possível.
G – Refatoração - Focaliza a lapidação do projeto do software e está presente em todas as etapas do desenvolvimento. A refatoração deve ser feita sempre que possível, buscando principalmente simplificar o código atual sem perder nenhuma funcionalidade.
 H - Propriedade coletiva - O código do projeto pertence a todos os membros da equipe. Isto significa que qualquer pessoa que percebe que pode adicionar valor a um código, mesmo que ele próprio não o tenha desenvolvido, pode fazê-lo, desde que faça os testes necessários e não prejudique as funcionalidades atuais. Isto é possível porque na XP todos são responsáveis pelo software. Uma grande vantagem desta prática é que, caso um membro da equipe deixe o projeto antes do fim, a equipe consegue continuar o projeto sem grandes dificuldades, pois todos conhecem todas as partes do software, mesmo que não seja de forma detalhada.
I - Integração contínua - É a prática de interagir e construir o sistema de software várias vezes por dia, mantendo os programadores em sintonia, além de possibilitar processos rápidos. Integrar apenas um conjunto de modificações de cada vez é uma prática que funciona bem porque fica óbvio quem deve fazer as correções quando os testes falham. Esta prática é facilitada com o uso de apenas uma máquina de integração, que deve ter livre acesso a todos os membros da equipe.
J - 40 horas de trabalho semanal - a XP assume que não se deve fazer horas extras constantemente. Caso seja necessário trabalhar mais de 40 horas pela segunda semana consecutiva, existe um problema sério no projeto que deve ser resolvido não com aumento de horas trabalhadas, mas com melhor planejamento.
K - Cliente presente - É fundamental a participação do cliente durante todo o desenvolvimento do projeto. O cliente deve estar sempre disponível para sanar todas as dúvidas de requisitos, evitando atrasos e até mesmo construções erradas. Uma ideia interessante é manter o cliente como parte integrante da equipe de desenvolvimento (Testes).
L - Código padrão - Baseia-se na padronização da arquitetura do código, para que este possa ser compartilhado entre todos os programadores e até mesmo entre outros softwares.
Prototipação de Software
�
Prototipação é uma abordagem baseada em uma visão evolutiva do desenvolvimento de software, afetando o processo como um todo. Envolve a produção de versões iniciais -protótipos (análogo a maquetes para a arquitetura) - de um sistema futuro com o qual é possível realizar verificações e experimentos, com o intuito de avaliar algumas de suas características antes que o sistema venha realmente a ser construído, de forma definitiva.
Quando usar?
Em muitos casos o cliente define somente um conjunto de objetivos gerais para o Sistema (Software), mas não foi capaz de gerar requisitos definidos, de entrada, processamento e saída, para o sistema (software).
Desenvolvedor não tem certeza da eficiência de um algoritmo, ou como ele pode se comportar em um determinado Sistema.
Operacional, ou durante a comunicação com alguma interface, periféricos/componentes; interação homem-máquina pode não ser aceita pelo cliente, ou seja a interface de comunicação com o aplicação (Software) pode ser confusa ou não usual.
Para gerar o protótipo existem várias formas e ferramentas, sendo as mais usuais:
Modelo de papel:
ilustra como o sistema (software) irá se comportar e interagir como o Usuário de forma a capacitar a todos entender como ocorrerão os processos de interação;
Modelo de trabalho:
implementa algumas características do software, em sua maioria a interface de comunicação com usuário como a navegação em telas, entre outros subconjuntos de funcionalidades existentes no sistema;
Toda a funcionalidade existente será melhorada em um novo esforço de desenvolvimento, gerando um novo protótipo mais completo.
Modelo de desenvolvimento espiral:�
O Modelo em espiral é um processo de desenvolvimento de software que combina elementos de projeto prototipação-em-etapas, em um esforço para combinar as vantagens dos conceitos de top-down e bottom-up, acrescentando um novo elemento, a análise de riscos que falta a esses paradigmas.
O modelo em espiral foi definido por Barry Boehm em seu artigo de 1988 A Spiral Model of Software Development and Enhancement. Este modelo não foi o primeiro a discutir o Desenvolvimento iterativo e incremental, mas ele foi o primeiro modelo a explicar o porquê do modo iterativo. 
Como originalmente antevisto, as iterações têm uma duração típica de 6 meses a dois anos. Cada fase inicia com um objetivo esperado e termina como uma revisão pelo cliente do progresso (que deve ser interna) e assim por diante. Esforços de análise e engenharia são aplicados em cada fase do projeto, com um olho focado no objetivo do projeto.
Para uma típica aplicação, o modelo em espiral deverá significar que se tem uma visão grosseira dos elementos como uma aplicação utilizável, adicionando características nas fases e, a determinado ponto, o gráfico final.
O modelo espiral é usado com mais frequência em grandes projetos. Para pequenos projetos, os conceitos de desenvolvimento de software ágil torna-se uma alternativa mais viável.
�IBM Rational Unified Process:
O RUP, abreviação de Rational Unified Process (ou Processo Unificado Rational), é um processo proprietário de Engenharia de software criado pela Rational Software Corporation, adquirida pela IBM, ganhando um novo nome IRUP que agora é uma abreviação de IBM Rational Unified Process e tornando-se uma brand na área de Software, fornecendo técnicas a serem seguidas pelos membros da equipe de desenvolvimento de software com o objetivo de aumentar a sua produtividade no processo de desenvolvimento.
O RUP define as seguintes linhas-mestras e esqueletos para os membros da equipe de um ciclo de produção: parte do cliente, e uma avaliação do progresso do projeto pela sua gerência. Além disso, ajuda os programadores a manterem-seconcentrados no projeto.
O RUP oferece uma forma sistemática para construir este tipo de sistema, focando-se em produzir uma arquitetura executável nas fases iniciais do projeto, ou seja, antes de comprometer recursos em larga escala.
O RUP visa auxiliar no controle do planejamento da qualidade, verificando-a na construção de todo o processo e envolvendo todos os membros da equipe de desenvolvimento.
Em todos os projetos de software a existência de mudanças é inevitável. O RUP define métodos para controlar e monitorar mudanças. Como uma pequena mudança pode afetar aplicações de formas inteiramente imprevisíveis, o controle de mudanças é essencial para o sucesso de um projeto.
O RUP também define áreas de trabalho seguras, garantindo a um programador que as mudanças efetuadas noutro sistema não afetarão o seu sistema.
 
CONCLUSÃO
Como vimos, este trabalho é resultado de um estudo feitos com dedicação e que exigiu análise, e reflexão. Uma das vantagens oferecidas, é que considero o mais importante foi o conhecimento que tivemos a respeito dos modelos de processo na criação de um software, e como ele é atuante hoje em dia. Foi um estudo instrutivo elaborado através de uma visão geral sobre a Engenharia de Software.
Os conceitos de Engenharia de Software foram aplicados observando-se todas as fases necessárias para a realização de um experimento. Inicialmente, tinha-se o objetivo de melhoria de processo e de produto, mais conforme o andamento, optou-se por focar apenas para a melhoria de processo. 
A maior dificuldade deste trabalho foi direcionar o tema, pois a Engenharia de Software é um tema muito amplo e de muitas bibliografias. Outra dificuldade foi a falta de tempo disponível para buscar atividades de estudo.
Em fim espero ter atingido o objetivo esperado.
GLOSSÁRIO
PERINE L.C., HISATOMI M.I., BERTO W.L. Engenharia de Software: Sistemas II. 1ª Edição. São Paulo: Pearson, 2009.
Referencias:
�Referência: http://pt.wikipedia.org/wiki/Modelos_ciclo_de_vida
�Referência: http://pt.wikipedia.org/wiki/Modelo_em_cascata
�Referência: http://pt.wikipedia.org/wiki/Desenvolvimento_iterativo_e_incremental
�Referência: http://pt.wikipedia.org/wiki/Prototipação
�Referência: http://pt.wikipedia.org/wiki/Modelo_em_espiral
�Referência: http://pt.wikipedia.org/wiki/Engenharia_de_software
�Referência: http://pt.wikipedia.org/wiki/Métodos_Formais
�Referência: http://pt.wikipedia.org/wiki/Desenvolvimento_Ágil
�Referência: http://pt.wikipedia.org/wiki/Rapid_Application_Development
�Referência: Engenharia de Software (PERINI et al, 2013).
�Referência: http://pt.wikipedia.org/wiki/IBM_Rational_Unified_Process 
Sistema de Ensino Presencial Conectado
aNÁLISE E DESENVOLVIMENTO DE SISTEMAS
Bruno vieira dos anjos sena
Fundamentos de tecnologia da informação
Belo Horizonte
2013
bruno vieira dos anjos sena
Modelo de processo de software:
Trabalho de Modelo de Processo de Software Apresentado à Universidade Norte do Paraná - UNOPAR, como requisito parcial para a obtenção de média bimestral na disciplina de Análise e Desenvolvimento de Sistemas
Orientadores: 
Prof. Reinaldo Nishikawa
Prof. Anderson Macedo
Prof. Polyanna P. Gomes
Prof..Merris Mozer
Prof. André Luis Ribeiro
Prof. Vicente Lucarelli
Belo Horizonte, 2013
� Referência: Engenharia de Software (PERINI et al, 2013).
� Referência: Engenharia de Software (PERINI et al, 2013).
� Referência: �HYPERLINK "http://pt.wikipedia.org/wiki/Modelos_ciclo_de_vida"��http://pt.wikipedia.org/wiki/Modelos_ciclo_de_vida�
� Referência: � HYPERLINK "http://pt.wikipedia.org/wiki/Modelo_em_cascata" �http://pt.wikipedia.org/wiki/Modelo_em_cascata�
� Referência: � HYPERLINK "http://pt.wikipedia.org/wiki/Desenvolvimento_iterativo_e_incremental" �http://pt.wikipedia.org/wiki/Desenvolvimento_iterativo_e_incremental�
� Referência: �HYPERLINK "http://pt.wikipedia.org/wiki/Prototipação"��http://pt.wikipedia.org/wiki/Prototipação�
� Referência: � HYPERLINK "http://pt.wikipedia.org/wiki/Modelo_em_espiral" �http://pt.wikipedia.org/wiki/Modelo_em_espiral�
� Referência: � HYPERLINK "http://pt.wikipedia.org/wiki/Engenharia_de_software" �http://pt.wikipedia.org/wiki/Engenharia_de_software�
� Referência: �HYPERLINK "http://pt.wikipedia.org/wiki/Métodos_Formais"��http://pt.wikipedia.org/wiki/Métodos_Formais�
� Referência: �HYPERLINK "http://pt.wikipedia.org/wiki/Desenvolvimento_Ágil"��http://pt.wikipedia.org/wiki/Desenvolvimento_Ágil�
� Referência: � HYPERLINK "http://pt.wikipedia.org/wiki/Rapid_Application_Development" �http://pt.wikipedia.org/wiki/Rapid_Application_Development�
�Referência: Engenharia de Software (PERINI et all, 2013)
�Referência: � HYPERLINK "http://pt.wikipedia.org/wiki/IBM_Rational_Unified_Process" �http://pt.wikipedia.org/wiki/IBM_Rational_Unified_Process�
�Referencia: �HYPERLINK "http://pt.wikipedia.org/wiki/Desenvolvimento_agil_de_software"��http://pt.wikipedia.org/wiki/Desenvolvimento_agil_de_software�
� Referência: �HYPERLINK "http://pt.wikipedia.org/wiki/Extreme_Programming"��http://pt.wikipedia.org/wiki/Extreme_Programming�
2 Referência: �HYPERLINK "http://pt.wikipedia.org/wiki/Extreme_Programming"��http://pt.wikipedia.org/wiki/Extreme_Programming�
� Referência: �HYPERLINK "http://pt.wikipedia.org/wiki/Prototipacao"��http://pt.wikipedia.org/wiki/Prototipacao�cao
� Referência: �HYPERLINK "http://pt.wikipedia.org/wiki/Modelo_Espiral"��http://pt.wikipedia.org/wiki/Modelo_Espiral�
� Referência:� HYPERLINK "http://pt.wikipedia.org/wiki/IBM_Rational_Unified_Process" �http://pt.wikipedia.org/wiki/IBM_Rational_Unified_Process�