Dicas TCC Estágio

[[http://pt.wikipedia.org/wiki/Metodologia_%28engenharia_de_software%29]]

[[http://pt.wikipedia.org/wiki/Engenharia_de_Software]]

[[http://pt.wikipedia.org/wiki/Desenvolvimento_%C3%A1gil_de_software]]

Metodologias e métodos

O termo metodologia é bastante controverso nas ciências em geral e na Engenharia de Software em particular. Muitos autores parecem tratar metodologia e método como sinônimos, porém seria mais adequado dizer que uma metodologia envolve princípios filosóficos que guiam uma gama de métodos que utilizam ferramentas e práticas diferenciadas para realizar algo.5

Assim teríamos, por exemplo, a Metodologia Estruturada, na qual existem vários métodos, como Análise Estruturada e Projeto Estruturado (muitas vezes denominados SA/SD, e Análise Essencial). Dessa forma, tanto a Análise Estruturada quanto a Análise Essencial utilizam a ferramenta Diagrama de Fluxos de Dados para modelar o funcionamento do sistema.

Segue abaixo as principais Metodologias e Métodos correspondentes no desenvolvimento de software:

Metodologia Estruturada
Análise Estruturada
Projeto Estruturado
Programação Estruturada
Análise Essencial
SADT
DFD - Diagrama de Fluxo de Dados
MER - Modelo de Entidades e Relacionamentos
Metodologia Orientada a Objetos
Orientação a Objetos
Rational Unified Process ( RUP )
Desenvolvimento ágil de software
Feature Driven Development ( FDD )
Enterprise Unified Process (EUP)
Scrum (Scrum)
Crystal (Crystal Clear, Crystal Orange, Crystal Orange Web)
Programação extrema ( XP )
Outras Metodologias
Microsoft Solution Framework ( MSF )

Modelagem

A abstração do sistema de software através de modelos que o descrevem é um poderoso instrumento para o entendimento e comunicação do produto final que será desenvolvido.

A maior dificuldade nesta atividade está no equilíbrio (tradeoff) entre simplicidade (favorecendo a comunicação) e a complexidade (favorecendo a precisão) do modelo.

Para a modelagem podemos citar 3 métodos:

Análise estruturada, criada por Gane & Searson;
Análise Essencial, criada por Palmer & McMenamin e Ed. Yourdon;
UML, criada por Grady Booch, Ivar Jacobson & Jaimes Rumbaugh. É hoje o método mais comum para o paradigma orientado a objetos.

Ferramentas, tecnologias e práticas

A engenharia de software aborda uma série de práticas e tecnologias, principalmente estudadas pela ciência da computação, enfocando seu impacto na produtividade e qualidade de software.

Destacam-se o estudo de linguagem de programação, banco de dados e paradigmas de programação, como:

Programação estruturada
Programação funcional
Programação orientada a objetos
Componentes de Software
Programação orientada a aspecto

Ferramentas

Outro ponto importante é o uso de ferramentas CASE (do inglês Computer-Aided Software Engineering). Essa classificação abrange toda ferramenta baseada em computadores que auxiliam atividades de engenharia de software, desde a análise de requisitos e modelagem até programação e testes.

Os ambientes de desenvolvimento integrado (IDEs) têm maior destaque e suportam, entre outras coisas:

Editor[desambiguação necessária]
Compilador
Debug
Geração de código
Modelagem
Deploy
Testes não automatizados
Testes automatizados
Refatoração (Refactoring)
Gestão de Riscos nos projectos de Software
Uso da Prototipagem na Eng. de Requisitos

Gerência de projetos

A gerência de projetos se preocupa em entregar o sistema de software no prazo e de acordo com os requisitos estabelecidos, levando em conta sempre as limitações de orçamento e tempo.

A gerência de projetos de software se caracteriza por tratar sobre um produto intangível, muito flexível e com processo de desenvolvimento com baixa padronização.
Planejamento

O planejamento de um projeto de desenvolvimento de software inclui:

Análise Econômica de Sistemas de Informações
organização do projeto (incluindo equipes e responsabilidades)
estruturação das tarefas (do inglês WBS - work breakdown structure)
cronograma do projeto (do inglês project schedule)
análise e gestão de risco
estimativa de custos

Essas atividades sofrem com dificuldades típicas de desenvolvimento de software. A produtividade não é linear em relação ao tamanho da equipe e o aumento de produtividade não é imediato devido aos custos de aprendizado de novos membros. A diminuição de qualidade para acelerar o desenvolvimento constantemente prejudica futuramente a produtividade.

A estimativa de dificuldades e custos de desenvolvimentos são muito difíceis, além do surgimento de problemas técnicos. Esses fatores requerem uma análise de riscos cuidadosa.

Além da própria identificação dos riscos, há que ter em conta a sua gestão. Seja evitando, seja resolvendo, os riscos necessitam ser identificados (estimando o seu impacto) e devem ser criados planos para resolução de problemas.
Análise de requisitos

As atividades de análise concentram-se na identificação, especificação e descrição dos requisitos do sistema de software. Em resumo, requisito é uma necessidade que o software deve cumprir.

Há várias interpretações e classificações sobre requisitos, entre elas:

funcional
não funcional
de usuário
de sistema

É comum que o cliente não saiba o que ele realmente deseja, que haja problemas na comunicação e ainda que haja mudança constante de requisitos. Todos esses fatores são recrudescidos pela intangibilidade sobre características de sistemas de software, principalmente sobre o custo de cada requisito.

Estudo de Viabilidade (Levantamento de Requisitos)

A Engenharia de requisitos é um processo que envolve todas as atividades exigidas para criar e manter o documento de requisitos de sistema (SOMMERVILLE). Segundo RUMBAUGH, alguns analistas consideram a engenharia de Requisitos como um processo de aplicação de um método estrutura como a análise orientada a objetos. No entanto, a Engenharia de requisitos possui muito mais aspectos do que os que estão abordados por esses métodos.

Abaixo um pequeno Processo de Engenharia de Requisitos (SOMMERVILLE).

Estudo da viabilidade → "Relatório de Viabilidade" Obtenção e Análise de Requisitos → "Modelos de Sistema" Especificação de Requisitos → "Requisitos de Usuário e de Sistema" Validação de Requisitos → "Documento de Requisitos"

O primeiro processo a ser realizado num Sistema novo é o Estudo de Viabilidade. Os resultados deste processo devem ser um relatório com as recomendações da viabilidade técnica ou não da continuidade no desenvolvimento do Sistema proposto. Basicamente um estudo de viabilidade, embora seja normalmente rápido, deverá abordar fundamentalmente as seguintes questões:

O Sistema proposto contribui para os objetivos gerais da organização?
O Sistema poderá ser implementado com as tecnologias dominadas pela equipe dentro das restrições de custo e de prazo? Ou precisa de treinamentos adicionais?
O Sistema pode ser integrado, e é compatível com os outros sistemas já em operação?

Gestão

Existem cinco tipo de gestões: pessoal, produto, processo, projeto e material.
Histórico

A Engenharia de Software (ES) surgiu em meados dos anos 1970 numa tentativa de contornar a crise do software e dar um tratamento de engenharia (mais sistemático e controlado) ao desenvolvimento de sistemas de software complexos. Um sistema de software complexo se caracteriza por um conjunto de componentes abstratos de software (estruturas de dados e algoritmos) encapsulados na forma de procedimentos, funções, módulos, objetos ou agentes interconectados entre si, compondo a arquitetura do software, que deverão ser executados em sistemas computacionais.
ES no presente e tendências

Atualmente existe um destaque todo especial para a Engenharia de Software na Web. Também utilizado por Presmann a sigla WebE, é o processo usado para criar WebApps (aplicações baseadas na Web) de alta qualidade. Embora os princípios básicos da WebE sejam muito próximos da Engenharia de Software clássica, existem peculiaridades específicas e próprias.

Com o advento do B2B (e-business) e do B2C (e-commerce), e ainda mais com aplicações para a Web 2.0, maior importância ficou sendo esse tipo de engenharia. Normalmente adotam no desenvolvimento a arquitetura MVC (Model-View-Controller).

Outra área de tendência em Engenharia de Software trata da aplicação de técnicas otimização matemática para a resolução de diversos problemas da área. A área, denominada Search-based software engineering, ou Otimização em engenharia de software em Português, apresenta vários resultados interessantes.6 Para mais detalhes em Português, ver texto com aplicações da otimização em engenharia de software.7

O Brasil atualmente conta com seis cursos de nível superior em Engenharia de Software nas seguintes instituições reconhecidas pelo MEC: UnB, UFRN, Universidade Federal do Ceará, Universidade Federal de Goiás, Universidade de Rio Verde, Unipampa e UniCesumar.8

Eventos acadêmicos também mostram tópicos interessantes sobre futuras tendências de engenharia de software. O Brasil em 2013 sedia grandes eventos de engenharia como a Conferência Internacional de Engenharia de Requisitos9 e a Escola Latino Americana de Engenharia de Software.10
Ver também
Portal A Wikipédia possui o
Portal de engenharia
Portal A Wikipédia possui o portal:

Portal das tecnologias de informação

Engenharia informática
Desenvolvimento de software
Qualidade de software
Arquitetura de dados
Software Engineering Body of Knowledge
Análise econômica de sistemas de informações
Matriz CRUD
Otimização em engenharia de software
Praxis - Processo de desenvolvimento de software com enfoque educaciona
==========================================================
Desenvolvimento ágil de software
Origem: Wikipédia, a enciclopédia livre.


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.

Índice

1 Introdução
2 Princípios
3 História
4 Comparações com outros métodos
4.1 Comparação com o desenvolvimento iterativo
4.2 Comparação com o modelo em cascata
4.3 Comparação com a "codificação cowboy"
5 Aplicabilidade dos métodos ágeis
6 Adaptabilidade dos métodos ágeis
7 Métodos ágeis e o gerenciamento de projeto
8 Metodologias
9 Críticas
10 Referências
11 Futuras leituras
12 Ligações externas

Introdução

Existem inúmeros frameworks de processos para desenvolvimento de software. A maioria dos métodos ágeis tenta minimizar o risco pelo desenvolvimento do software em curtos períodos, chamados de iteração, os quais gastam tipicamente menos de uma semana a até quatro. Cada iteração é como um projeto de software em miniatura de seu próprio, e inclui todas as tarefas necessárias para implantar o mini-incremento da nova funcionalidade: planejamento, análise de requisitos, projeto, codificação, teste e documentação. Enquanto em um processo convencional, cada iteração não está necessariamente focada em adicionar um novo conjunto significativo de funcionalidades, um projecto de software ágil busca a capacidade de implantar uma nova versão do software ao fim de cada iteração, etapa a qual a equipe responsável reavalia as prioridades do projecto.

Métodos ágeis enfatizam comunicações em tempo real, preferencialmente face a face, a documentos escritos. A maioria dos componentes de um grupo ágil deve estar agrupada em uma sala. Isso inclui todas as pessoas necessárias para terminar o software: no mínimo, os programadores e seus clientes (clientes são as pessoas que definem o produto, eles podem ser os gerentes, analistas de negócio, ou realmente os clientes). Nesta sala devem também se encontrar os testadores, projectistas de iteração, redactores técnicos e gerentes.

Métodos ágeis também enfatizam trabalho no software como uma medida primária de progresso. Combinado com a comunicação face-a-face, métodos ágeis produzem pouca documentação em relação a outros métodos, sendo este um dos pontos que podem ser considerados negativos. É recomendada a produção de documentação que realmente será útil.
Princípios

Os princípios do desenvolvimento ágil valorizam

Garantir a satisfação do consumidor entregando rapidamente e continuamente softwares funcionais;
Softwares funcionais são entregues frequentemente (semanas, ao invés de meses);
Softwares funcionais são a principal medida de progresso do projecto;
Até mesmo mudanças tardias de escopo no projecto são bem-vindas.
Cooperação constante entre pessoas que entendem do 'negócio' e desenvolvedores;
Projetos surgem através de indivíduos motivados, entre os quais existe relação de confiança.
Design do software deve prezar pela excelência técnica;
Simplicidade;
Rápida adaptação às mudanças;
Indivíduos e interações mais do que processos e ferramentas;
Software funcional mais do que documentação extensa;
Colaboração com clientes mais do que negociação de contratos;
Responder a mudanças mais do que seguir um plano.

História

As definições modernas de desenvolvimento de software ágil evoluíram a partir da metade de 1990 como parte de uma reação contra métodos "pesados", caracterizados por uma pesada regulamentação, regimentação e micro gerenciamento usado o modelo em cascata para desenvolvimento. O processo originou-se da visão de que o modelo em cascata era burocrático, lento e contraditório a forma usual com que os engenheiros de software sempre realizaram trabalho com eficiência.

Uma visão que levou ao desenvolvimento de métodos ágeis e iterativos era retorno a prática de desenvolvimento vistas nos primórdios da história do desenvolvimento de software [1].

Inicialmente, métodos ágeis eram conhecidos como métodos leves. Em 2001, membros proeminentes da comunidade se reuniram em Snowbird e adotaram o nome métodos ágeis, tendo publicado o Manifesto ágil, documento que reúne os princípios e práticas desta metodologia de desenvolvimento. Mais tarde, algumas pessoas formaram a Agile Alliance, uma organização não lucrativa que promove o desenvolvimento ágil.

Os métodos ágeis iniciais—criado a priore em 2000— incluíam Scrum (1986), Crystal Clear, Programação extrema (1996), Adaptive Software Development, Feature Driven Development, and Dynamic Systems Development Method (1995).
Comparações com outros métodos

Métodos Ágeis são algumas vezes caracterizados como o oposto de metodologias guiadas pelo planejamento ou disciplinadas. Uma distinção mais acurada é dizer que os métodos existem em um contínuo do adaptativo até o preditivo.1 Métodos ágeis existem do lado adaptativo deste contínuo. Métodos adaptativos buscam a adaptação rápida a mudanças da realidade. Quando uma necessidade de um projeto muda, uma equipe adaptativa mudará também. Um time adaptativo terá dificuldade em descrever o que irá acontecer no futuro. O que acontecerá em uma data futura é um item de difícil predição para um método adaptativo. Uma equipe adaptativa pode relatar quais tarefas se iniciarão na próxima semana. Quando perguntado acerca de uma implantação que ocorrerá daqui a seis meses, uma equipe adaptativa deve ser capaz somente de relatar a instrução de missão para a implantação, ou uma expectativa de valor versus custo.

Métodos preditivos, em contraste, colocam o planejamento do futuro em detalhe. Uma equipe preditiva pode reportar exatamente quais aspectos e tarefas estão planejados para toda a linha do processo de desenvolvimento. Elas porém tem dificuldades de mudar de direção. O plano é tipicamente otimizado para o objetivo original e mudanças de direção podem causar a perda de todo o trabalho e determinar que seja feito tudo novamente. Equipes preditivas freqüentemente instituem um comitê de controle de mudança para assegurar que somente as mudanças mais importantes sejam consideradas.

Métodos ágeis têm muito em comum com técnicas de Desenvolvimento rápido de aplicação de 1980 como exposto por James Martin e outros.
Comparação com o desenvolvimento iterativo

A maioria dos métodos ágeis compartilha a ênfase no Desenvolvimento iterativo e incremental para a construção de versões implantadas do software em curtos períodos de tempo. Métodos ágeis diferem dos métodos iterativos porque seus períodos de tempo são medidos em semanas, ao invés de meses, e a realização é efetuada de uma maneira altamente colaborativa. estendendo-se a tudo.
Comparação com o modelo em cascata

O desenvolvimento ágil tem pouco em comum com o modelo em cascata. Na visão de alguns este modelo é desacreditado, apesar de ser um modelo de uso comum. O modelo em cascata é uma das metodologias com maior ênfase no planejamento, seguindo seus passos através da captura dos requisitos, análise, projeto, codificação e testes em uma seqüência pré-planejada e restrita. O progresso é geralmente medido em termos de entrega de artefatos—especificação de requisitos, documentos de projeto, planos de teste, revisão do código, e outros. O modelo em cascata resulta em uma substancial integração e esforço de teste para alcançar o fim do ciclo de vida, um período que tipicamente se estende por vários meses ou anos. O tamanho e dificuldade deste esforço de integração e teste é uma das causas das falhas do projeto em cascata. Métodos ágeis, pelo contrário, produzem um desenvolvimento completo e teste de aspectos (mas um pequeno subconjunto do todo) num período de poucas semanas ou meses. Enfatiza a obtenção de pequenos pedaços de funcionalidades executáveis para agregar valor ao negócio cedo, e continuamente agregar novas funcionalidades através do ciclo de vida do projeto.

Algumas equipes ágeis usam o modelo em cascata em pequena escala, repetindo o ciclo de cascata inteiro em cada iteração. Outras equipes, mais especificamente as equipes de Programação extrema, trabalham com atividades simultaneamente.
Comparação com a "codificação cowboy"

A codificação cowboy, também chamada de Modelo Balbúrdia, é a ausência de metodologias de desenvolvimento de Software: os membros da equipe fazem o que eles sentem que é correto. Como os desenvolvedores que utilizam métodos ágeis freqüentemente reavaliam os planos, enfatizam a comunicação face a face e fazem o uso relativamente esparso de documentos, ocasionalmente levam as pessoas a confundirem isto com codificação cowboy. Equipes ágeis, contudo, seguem o processo definido (e freqüentemente de forma disciplinada e rigorosa).

Como em todas as metodologias, o conhecimento e a experiência dos usuários definem o grau de sucesso e/ou fracasso de cada atividade. Os controles mais rígidos e sistematizados aplicados em um processo implicam altos níveis de responsabilidade para os usuários. A degradação de procedimentos bem-intencionados e organizados pode levar as atividades a serem caracterizadas como codificação cowboy.
Aplicabilidade dos métodos ágeis

Embora os métodos ágeis apresentem diferenças entre suas práticas, eles compartilham inúmeras características em comum, incluindo o desenvolvimento iterativo, e um foco na comunicação interativa e na redução do esforço empregado em artefatos intermediários. (Cohen et al., 2004)2 A aplicabilidade dos métodos ágeis em geral pode ser examinada de múltiplas perspectivas. Da perspectiva do produto, métodos ágeis são mais adequados quando os requisitos estão emergindo e mudando rapidamente, embora não exista um consenso completo neste ponto (Cohen et al., 2004).2 De uma perspectiva organizacional, a aplicabilidade pode ser expressa examinando três dimensões chaves da organização: cultura, pessoal e comunicação. Em relação a estas áreas inúmeros fatores chave do sucesso podem ser identificados (Cohen et al., 2004):2

A cultura da organização deve apoiar a negociação.
As pessoas devem ser confiantes.
Poucas pessoas, mas competentes.
A organização deve promover as decisões que os desenvolvedores tomam.
A Organização necessita ter um ambiente que facilite a rápida comunicação entre os membros.

O fator mais importante é provavelmente o tamanho do projeto (Cohen et al., 2004)..2 Com o aumento do tamanho, a comunicação face a face se torna mais difícil. Portanto, métodos ágeis são mais adequados para projetos com pequenos times, com no máximo de 20 a 40 pessoas.

De forma a determinar a aplicabilidade de métodos ágeis específicos, uma análise mais sofisticada é necessária. O método dinâmico para o desenvolvimento de sistemas, por exemplo, provê o denominado 'filtro de aplicabilidade' para este propósito. Também, a família de métodos Crystal provê uma caracterização de quando selecionar o método para um projeto. A seleção é baseada no tamanho do projeto, criticidade e prioridade. Contudo, outros métodos ágeis não fornecem um instrumento explícito para definir sua aplicabilidade a um projeto.

Alguns métodos ágeis, como DSDM e Feature Driven Development, afirmam se aplicar a qualquer projeto de desenvolvimento ágil, sem importar suas características (Abrahamsonn et al., 2003).3

A comparação dos métodos ágeis irá revelar que eles suportam diferentes fases de um ciclo de vida do software em diferentes níveis. Estas características individuais dos métodos ágeis podem ser usadas como um critério de seleção de sua aplicabilidade.

Desenvolvimentos ágeis vêm sendo amplamente documentados (ver Experiências relatadas, abaixo, como também em Beck,4 e Boehm & Turner5 ) como funcionando bem para equipes pequenas (< 10 desenvolvedores). O desenvolvimento ágil é particularmente adequado para equipes que têm que lidar com mudanças rápidas ou imprevisíveis nos requisitos.

A aplicabilidade do desenvolvimento ágil para os seguintes cenários é ainda uma questão aberta:

esforços de desenvolvimento em larga escala (> 20 desenvolvedores), embora estratégias para maiores escalas tenham sido descritas.6
esforços de desenvolvimento distribuído (equipes não co-alocadas). Estas estratégias tem sido descritas em Bridging the Distance7 e Using an Agile Software Process with Offshore Development8
esforços críticos de missão e vida.
Companhias com uma cultura de comando e controle.

Barry Boehm e Richard Turner sugeriram que análise de risco pode ser usada para escolher entre métodos adaptativos ("ágeis") e preditivos ("dirigidos pelo planejamento").5 Os autores sugerem que cada lado deste contínuo possui seu ambiente ideal"

Ambiente ideal para o desenvolvimento ágil:

Baixa criticidade
Desenvolvedores senior
Mudanças freqüente de requisitos
Pequeno número de desenvolvedores
Cultura que tem sucesso no caos.

Ambiente ideal para o desenvolvimento direcionado ao planejamento:

Alta criticidade
Desenvolvedores Junior
Baixa mudança nos requisitos
Grande número de desenvolvedores
Cultura que procura a ordem.

Adaptabilidade dos métodos ágeis

Um método deve ser bastante flexível para permitir ajustes durante a execução do projeto. Há três problemas chaves relacionados ao tópico de adaptação dos métodos ágeis: a aplicabilidade dos métodos ágeis (no geral e no particular), e finalmente, o suporte ao gerenciamento de projeto.
Métodos ágeis e o gerenciamento de projeto

Os métodos ágeis diferem largamente no que diz respeito a forma de serem gerenciados. Alguns métodos são suplementados com guias para direcionar o gerenciamento do projeto, mas nem todos são aplicáveis.3

PRINCE2™ tem sido considerado como um sistema de gerenciamento de projeto complementar e adequado.9

Uma característica comum dos processos ágeis é a capacidade de funcionar em ambientes muito exigentes que tem um grande número de incertezas e flutuações (mudanças) que podem vir de várias fontes como: equipe em processo de formação que ainda não trabalhou junto em outros projetos, requisitos voláteis, baixo conhecimento do domínio de negócio pela equipe, adoção de novas tecnologias, novas ferramentas, mudanças muito bruscas e rápidas no ambiente de negócios das empresas: novos concorrentes, novos produtos, novos modelos de negócio.

Sistemas de gerenciamento de projetos lineares e prescritivos, neste tipo de ambiente, falham em oferecer as características necessárias para responder de forma ágil as mudanças requeridas. Sua adoção pode incrementar desnecessariamente os riscos, o custo, o prazo e baixar a qualidade do produto gerado, desgastando a equipe e todos os envolvidos no processo.

A abordagem Scrum, para gestão de projetos ágeis, leva em consideração planejamento não linear, porém de maneira mais exaustiva e está focada em agregar valor para o cliente e em gerenciar os riscos, fornecendo um ambiente seguro. Pode ser utilizada na gestão do projeto aliada a uma metodologia de desenvolvimento como Programação Extrema, FDD, OpenUP, DSDM, Crystal ou outras.
Metodologias

Programação extrema
Scrum

Albert Joseph ; Ercilia Chilaule ; Francelino Itc(I2cv)

Feature Driven Development
DSDM
Adaptive Software Development
Crystal
Pragmatic Programming
Test Driven Development (em português)