Transcript
A crise do software Foi um termo utilizado em 1970, nessa época a própria engenharia de software nem existia, o termo expressava as dificuldades do software em ser desenvolvido frente ao rápido desenvolvimento e demanda do mesmo. Falava também da complexidade dos problemas e da inexistência de técnicas estabelecidas para o desenvolvimento de sistemas que funcionasse adequadamente. As causas da crise foram:
Projetos estourando o orçamento Projetos estourando o prazo Software de baixa qualidade Softwares que não atingiam os requisitos
As soluções formuladas foram:
Análise econômica de sistemas de informações O uso de melhores técnicas, métodos e ferramentas Interesse do governo em treinamento e educação
A crise do software não deixou de existir, e está vigente até hoje em determinados projetos que não seguem a engenharia.
Ciclo de vida O clico de vida de um software pode ser definido como, as etapas do desenvolvimento do mesmo. Desde de seu começo até seu desaparecimento, o objetivo é permitir a validação do desenvolvimento do software. Verificar o processo de desenvolvimento, ou seja, a adequação dos métodos. Quanto mais tarde erros são detectados em um projeto, maiores os custos, com o ciclo de vida é possível determinar os erros o mais depressa possível, com isso a qualidade do software só aumenta, como também são melhorados os custos e os prazos. O fluxo de um processo de software pode ser dado da seguinte forma: Comunicação >> Planejamento >> Modelagem >> Construção >> Entrega
Modelos de Ciclo de Vida: Os modelos de ciclo de vida definem o desenvolvimento do software, suas etapas, bem como os documentos que validam cada uma das etapas, para poder se passar para a próxima. Modelo em cascata: Este é o modelo mais antigo, mas ainda o mais usado, ele segue uma sequência linear. Ao fim de cada fase é produzido um documento para validar a passagem para a próxima fase.
Vantagens: Oferece uma maneira de tornar o processo mais visível. Facilita o planejamento. Desvantagens: Projetos reais raramente seguem um fluxo sequencial. Os requisitos se alteram durante o projeto. Comunicação Planejamento Modelagem Construção Entrega Modelo em V: Parte do princípio que os procedimentos de verificação da conformidade do software e as especificações devem ser elaboradas logo durante as fases de concepção, início.
Modelo de prototipação: O objetivo é entender os requisitos do usuário. Possibilita que o desenvolvedor crie um modelo do software que deve ser construído, podendo ser no papel ou executável. Vantagens: Os protótipos constituem uma boa pratica para melhorar as especificações dos requisitos. Partes do protótipo podem vir a ser usadas no sistema final. Desvantagens: Custo elevado. Atraso no desenvolvimento.
Modelo Espiral: Visa obter as melhores características do modelo clássico e da prototipagem. É dividido em fases, sendo que essas fases são repetidas várias vezes. Vantagens: Possibilidade de melhorar o sistema a cada interação. Diminui a manutenção. Desvantagens: É um modelo complexo, requer uma atenção maior. É relativamente novo.
Modelo Incremental: É uma combinação entre o modelo linear e a prototipação. O desenvolvimento deste modelo é dividido em etapas, chamadas de incremento. Em cada incremento é realizado todo o ciclo de desenvolvimento do software. Cada etapa produz um sistema totalmente funcional. Vantagens: Existe um risco menor de fracasso do software. Reduz a chance de mudança de requisito. Desvantagens: O número de interações não pode ser definido no início do processo. O fim do processo não pode ser previamente determinado. Modelo RAD: Enfatiza um ciclo de desenvolvimento curto. A construção é baseada em complementos. É usado principalmente para aplicações de sistema de informação. Vantagens: Baseado em componentes. Pode ser desenvolvido em várias equipes. Desvantagens: É necessário desenvolvedor e cliente comprometidos. Não é apropriado para qualquer aplicação.
Modelo Sincronizar e Estabilizar: O processo é dividido em incorporações, onde cada incorporação é realizada por uma série de pequenas equipes que trabalham em paralelo. No final de cada dia as equipes sincronizam os vários componentes abordados no processo e testam o produto. A estabilização acontece ao fim de cada incorporação, qualquer falha encontrada até então, será corrigida. E depois a incorporação será “congelada”, ou seja, não serão feitas mais especificações. A Microsoft adota emblematicamente este modelo.
Modelo de Codificar e Corrigir: Esse modelo requer pouca experiência. Não há tempo gasto em planejamento, documentação, gestão de qualidade, etc. Mas é um modelo perigoso, não há formas de assegurar a qualidade e identificar riscos. Se houverem falhas não percebidas imediatamente isso resultará em retrabalho. Modelo de Software Aberto: Pode ser dividido em duas fases. Na primeira um indivíduo tem uma ideia de um programa, como por exemplo o Linux, assim ele constrói a versão inicial do projeto, e a versão fica disponível para distribuição gratuita. Se for demonstrado um bom interesse pelo programa ele passará para a segunda fase, onde os usuário se tornam codesenvolvedores do programa, e começam a relatar falhas, mandar sugestões de melhoras e etc. Alguns outros até implementam ideias no projeto. Esses usuários passam a modificar o projeto inicial mas de forma voluntaria, em seu tempo livre, não são remunerados para isso.
PROCESSO DE SOFTWARE É um conjunto de atividades, parcialmente ordenadas, com a finalidade de obter um produto de software. É estudado dentro da área de Engenharia de Software, sendo considerado um dos principais mecanismos para se obter software de qualidade e cumprir corretamente os contratos de desenvolvimento, sendo uma das respostas técnicas adequadas para resolver a Crise do software.
PROCESSO UNIFICADO Visa a construção de sistemas orientados a objetos. É um modelo iterativo e adaptativo, consegue produzir um sistema de grande porte como se fosse vários pequenos sistemas, o que diminui o risco do projeto. É um conjunto de atividades necessárias para transformas requisitos de usuário em um sistema de software. Combina os ciclos iterativos e incremental para a construções de softwares. Fases: >> Concepção (Determinar se é economicamente viável) >> Elaboração (Elaborações da fase anterior) >> Construção (Primeira versão com qualidade operacional) >> Transição (Garantir que as necessidades do cliente sejam satisfeitas)
METODOLOGIAS ÁGEIS A aliança ágil foi um grupo de 17 notáveis desenvolvedores de software que se reuniram para tentar estabelecer métodos e procedimentos para facilitar, além de tornar mais fácil o processo desenvolvimento de software. Essa aliança foi resposta as metodologias tradicionais de desenvolvimento de software que abusam de burocracias desnecessárias em seus processos. Dessa forma, foi criada o manifesto ágil que estabelecia 4 princípios fundamentais, a saber:
Indivíduos e interações em vez de processos e ferramentas. Software funcionando em vez de burocracia. Colaboração do cliente em vez de contratos formais. Respostas a modificação em vez de seguir metas.
Com isso, essa nova abordagem de desenvolvimento de software chamada desenvolvimento ágil busca se embasar em novos alicerces para almejar a ideia de processo ágil, que trabalha com variável inerente ao próprio processo de desenvolvimento de software: a imprevisibilidade. Assim, a principal ideia do processo ágil é ser adaptável, saber trabalhar com mudanças. Essa nova abordagem trabalha principalmente com conceito de agilidade, que pode ser entendida como uma rápida e eficiente resposta a modificação. Os principais aspectos dessa nova abordagem podem ser listados abaixo:
Satisfação do cliente é prioridade. Cliente e desenvolvedores formam uma equipe. A ideia da colaboração. As equipes são auto organizadas, ou seja, elaboram e realizam suas próprias tarefas. Software sempre funcionando. Simplicidade nos projetos, livre de tantas burocracias.
Os principais métodos adotados nessa nova abordagem são:
XP Scrum
O XP divide o projeto em 4 etapas: planejamento; projeto; codificação; teste; O Scrum trabalha com: pendências; sprints; demos;
