MODELAGEM DE SOFTWARE

Pessoal, como a UML tem uma importância impar para o desenvolvimento das disciplinas Analise e Modelagem e Engenharia de Software - disciplinas que ministro, resolvi em tempo, disponibilizar aos interessados, mais um material complementar de estudo: o conteúdo abaixo.

Não se esqueçam de dar ênfase nos estudos sobre histórico da UML, na especificação da UML 2, na classificação quanto a organização da UML 2 e na definição dos Diagramas da UML 2 pois o domínio desses assuntos podem ajuda-los nas avaliações. 

Bons estudos e boa sorte.

MODELAGEM DE SOFTWARE

O crescimento vertiginoso dos softwares nas ultimas décadas teve, crescimento foi acentuado na década de 1990 com o início da massificação da tecnologia onde o número de novos softwares aumentou e ocasionando o surgimento de uma variedade muito grande de formas de modelagem para os sistemas orientados a objeto. Todavia, para se construir um software de qualidade são necessários grandes esforços e muita experiência. A esse respeito Silva e Videira (2001) afirmam:

Fazer software não é uma tarefa fácil. Fazer software de qualidade é ainda mais difícil. A generalidade dos resultados obtidos ao longo do tempo têm sistematicamente apresentado padrões de baixa qualidade, de custos e prazos completamente ultrapassados. (SILVA; VIDEIRA 2001, p.27)

Nesse sentido, com a necessidade de criar processos padronizados para o desenvolvimento de software, que surgiu o UML por volta de 1996 unificando as notações e diagramas. A UML (Unified Modeling Language ou Linguagem Unificada de Modelagem, em português) é uma linguagem visual para a modelagem de sistemas orientados a objeto, permitindo uma melhor visualização padronizada de um sistema.

A esse respeito Silva e Videira (2001) definem:

A ênfase do UML é na definição de uma linguagem de modelação standard, e, por conseguinte, o UML é independente das linguagens de programação, das ferramentas CASE, bem como dos processos de desenvolvimento. (SILVA; VIDEIRA 2001, p. 143)

A evolução da UML desde a sua criação até o ano de 2002 pode ser melhor visualizado a partir da análise da Figura abaixo.

Evolução da UML. 

Fonte: Adaptado de http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/uml/historia_uml/historia_uml.htm

Como principais objetivos da UML destacam-se: simplicidade, especificação, documentação e estruturação. 

Segundo Silva e Videira (2001, p.145) os tipos de diagramas da UML podem ser classificados, destacando-se: os Diagramas de Casos de Uso; Diagramas de Classes e de Objetos; Diagramas de Comportamento. Os Diagramas de Comportamento se subdividem ainda em Diagramas de Estados; Diagramas de Atividades e Diagramas de Colaboração. E, por fim os Diagramas de Arquitetura são classificados como Diagramas de Componentes e Diagramas de Instalação.

A especificação de UML é composta por quatro documentos: infra-estrutura de UML(OMG, 2006), superestrutura de UML (OMG, 2005c), Object Constraint Language (OCL) (OMG, 2005a) e Intercâmbio de Diagramas (OMG, 2005b). 

• Infra-estrutura de UML: O conjunto de diagramas de UML constitui uma linguagem definida a partir de outra linguagem que define os elementos construtivos fundamentais. Esta linguagem que suporta a definição dos diagramas é apresentada no documento infra-estrutura de UML.
• Superestrutura de UML: Documento que complementa o documento de infra-estrutura e que define os elementos da linguagem no nível do usuário.
• Linguagem para Restrições de Objetos (OCL): Documento que apresenta a linguagem usada para descrever expressões em modelos UML, com pré-condições, pós-condições e invariantes.
• Intercâmbio de diagramas de UML: Apresenta uma extensão do metamodelo voltado a informações gráficas. A extensão permite a geração de uma descrição no estilo XMI orientada a aspectos gráficos que, em conjunto com o XMI original permite produzir representações portáveis de especificações UML.

Quanto a organização dos diagramas da UML 2.0 pode-se classifica-los em Diagramas Estruturais, Diagramas de comportamento e diagramas de interação.  Veja a imagem abaixo:

Figura: Organização dos diagramas de UML 2

Diagramas Estruturais Diagrama de classes Diagrama de objetos Diagrama de componentes Diagrama de instalação Diagrama de pacotes Diagrama de estrutura

Diagramas Comportamentais Diagrama de Caso de Uso Diagrama de transição de estados Diagrama de atividade

Diagramas de Interação Diagrama de sequência Diagrama de Interatividade Diagrama de colaboração ou comunicação Diagrama de tempo Fonte: http://pt.wikipedia.org/wiki/UML

Thânia Clair de Souza Vargas (http://www.lavailama.com.br/arquivo/2.pdf) descreve cada um dos 13 diagramas na UML 2 e diz "Um diagrama é uma representação gráfica de um conjunto de elementos (classes, interfaces, colaborações, componentes, nós, etc) e são usados para visualizar o sistema sob diferentes perspectivas. A UML define um número de diagramas que permite dirigir o foco para aspectos diferentes do sistema de maneira independente. Se bem usados, os diagramas facilitam a compreensão do sistema que está sendo desenvolvido". 

Embora a UML tenha oferecido inúmeros e inquestionáveis benefícios procurando padronizar, simplificar, especificar, documentar e estruturar os processos de desenvolvimento de software, independente da linguagem de programação ou plataforma de desenvolvimento, a UML ainda deixa algumas lacunas como o problema relacionado à semântica, onde desenvolvedores distintos podem diagramar um mesmo sistema de formas diferentes. Na essência do princípio do UML, um mesmo sistema deveria ser diagramado de apenas uma forma, seja pelo desenvolvedor A, seja pelo desenvolvedor B. Todavia esse objetivo ainda não é possível para o UML atual. Talvez, pensando nisso os idealizadores do UML deixaram espaço para que no futuro a questão da semântica do UML seja resolvida

ENGENHARIA DE SOFTWARE

Somente na década de 1968 na  NATO Conference on Software Engineering (Conferência sobre Engenharia de Software da OTAN) a Engenharia de Software ganhou destaque e passou a ser um termo oficialmente usado. Historicamente os primeiros passos do que é entendido como Engenharia de Software na atualidade foi na década de 1960.

Nesse sentido, Mazzola (2010, p. 06) afirma que “engenharia de software é um conjunto de métodos, técnicas e ferramentas necessárias à produção de software de qualidade para todas as etapas do ciclo de vida do produto”. Já para Pressman (2006) a engenharia de software ocorre como resultado da engenharia de sistemas. A esse respeito ele diz:

Antes que o software possa ser submetido à engenharia, o “sistema” no qual ele reside deve ser entendido. Para conseguir isso, o objetivo geral do sistema deve ser determinado: o papel do hardware, software, pessoal, base de dados, procedimentos e outros elementos do sistema devem ser identificados; e requisitos operacionais devem ser conseguidos, analisados, especificados, modelados, validados e gerenciados. Essas atividades são à base da engenharia de sistemas. (PRESSMAN, 2006, p. 99).

Todavia, para a elaboração e implementação de um software ou programa de computador é necessário uma seqüência de práticas. Essa seqüência é conhecida como Processo de Software, ou Processo de Engenharia de Software e englobam as atividades de especificação, projeto, implementação, testes e caracterizam-se pela interação de ferramentas, pessoas e métodos.

Dentre várias possibilidades para o desenvolvimento de software, o desenvolvimento tradicional e o desenvolvimento ágil merecem atenção especial. Teles (2006, p.30) define “desenvolvimento tradicional” ou “clássico” quando os projetos de software são “baseados no modelo cascata” ou quando estão muitos próximos desse modelo como o RUP (Rational Unified Process). Esse modelo clássico foi o primeiro processo de desenvolvimento de software publicado (PRESSMAN, 2006).

Segundo Teles (2006) o modelo tradicional, sugere que a construção do programa de computador ou software deve seguir uma linha seqüencial ou fases: Análise onde o desenvolvedor procura buscar e entender as necessidades; Design é a projeção da arquitetura tendo como base a análise; Implementação que é quando a equipe define a arquitetura e as diversas partes do programa de computador; Teste que ajuda a identificar e verificar se o sistema atende aos requisitos específicos definidos pelo usuário; Implantação que é quando o sistema é colocado em operação; Manutenção que ocorre até o final da vida ou seja, até quando o software estiver em operação poderá sofrer alterações.

Para Sommerville (2003), como ilustrado na Figura 08 o ciclo de vida clássico do software tem cinco fases: definição de requisitos, projeto do software, implementação e teste unitário, integração e teste do sistema, operação e manutenção.

Fases do modelo de Desenvolvimento Clássico

Fonte: Adaptado de Sommerville (2003)

O Modelo em Cascata, também chamado de Ciclo de Vida Clássico, é um processo recomendado quando os requisitos de um problema são razoavelmente bem compreendidos, ou seja, quando o trabalho flui da comunicação até a implantação de um modo linear.O Modelo em Cascata, conforme ilustrado na figura 1, sugere uma abordagem sistemática e seqüencial para o desenvolvimento de softwares.
Fonte: http://julianakolb.com/2012/02/01/o-modelo-em-cascata/

Modelo em Cascata.

Fonte: PRESSMAN (2010).

Para o modelo de Desenvolvimento Ágil, Teles (2006, p. 31) refere-se ao desenvolvimento interativo ou espiral, de forma que todas as fases descritas no modelo cascata “sejam executadas diversas vezes ao longo do projeto, produzindo círculos”.

Introdução das premissas dos controles de versão

Introdução sobre algumas premissas sobre controles de versão. Muito útil para designers e iniciantes na área




Parece ser óbvio, mas muitos desenvolvedores desdenham de ter controle total sobre o código gerado no desenvolvimento. Muitos, por trabalharem sozinhos, entendem que não precisam manter um certo nível de organização do seu código exatamente porque talvez, somente eles, o verão.

Quem nunca ficou horas tentando debugar um código que você mesmo fez, mas não lembrava o que uma determinada função fazia… Esse código pode ter sido por você de madrugada, quando você estava pingando de sono, ou pior, bêbado… Vai saber…

Controlar seu código fonte deve ser uma premissa. Um princípio. Se você acha que o undo do seu editor predileto salva sua vida, imagina ter um undo do seu projeto inteiro. Imagine você ter a história de edição de cada um dos arquivos do seu projeto.

Os princípios abaixo servem para qualquer tipo de controle de versão que conhecemos hoje: GIT, SVN, Mercurial etc.

Branchs e trunks

A última revisão, a mais atual, normalmente é chamada de HEAD. Existem momentos onde teremos vários HEADs porque o projeto tem vários BRANCHES.

Um branch é uma cópia do projeto. Cada branch pode ser editado e evoluído independentemente.

Imagine que exista a versão de produção que é aquela que está no ar. É a versão o usuário está utilizando. É importante que nós não modifiquemos esta versão porque alguém pode commitar algo errado, quebrar tudo e o usuario reclamar. Por isso nós precisamos de outro ambiente, é aí que criamos um branch de desenvolvimento, onde podemos fazer o que quisermos ali, sem afetar o branch principal.


É muito útil criarmos novos trunks (tronco) quando precisamos fazer modificações drásticas de novas features, resolver bugs ou modificar layout.


Exemplo: imagine que você esteja trabalhando em uma nova feature, em um branch específico. O cliente liga e diz que encontrou um bug, originado de uma modificação feita na semana passada. Você sai do branch da nova feature e cria um novo branch. Este novo branch tem a cópia do código do branch de produção, que é o que o cliente está vendo. Você resolve o bug neste novo branch. Quando resolver o bug, você move as modificações deste branch para o branch de produção. Isso tudo sem ter que subir as modificações incompletas da nova feature que você estava trabalhando anteriormente.

Versionamento

Versionamento é uma das características mais básicas do controle de código. Quando comecei a desenvolver, normalmente eu trabalhava guardando pastas com nomes do tipo nomeDoProjeto-v1, nomeDoProjeto-v2 etc… Estas pastas guardavam apenas as versões com grandes modificações de projeto… algo como mudança geral de layout, uma feature importante ou algo do tipo. O problema são as pequenas edições… Quando juntamos as pequenas modificações, temos uma grande modificação. É muito provável que se você perder essa versão, você não se lembre de todas as pequenas modificações feitas e isso é um problemão.


Toda vez que o desenvolvedor termina uma determinada tarefa, ele geral um commit que por sua vez gera um ponto de referência, uma versão, daqueles arquivos modificados. Cada commit gera uma versão do seu código. A graça é que se você tem versões do código, você tem praticamente um undo gigante do seu projeto… Se depois de uma determinada modificação seu projeto começou a dar pau, você consegue entender com a história do seu versionamento – o famoso log – a partir de onde exatamente o problema foi iniciado.

Logs

Quando cada revisão é comitada, o desenvolvedor pode ou não adicionar uma mensagem explicando o que ele fez naquela tarefa. É importante que essa mensagem seja clara e rica em detalhes, mas não um texto gigante, apenas o suficiente para que você mesmo ou outras pessoas envolvidas entenda o que aquela submissão significa.

Diffs

Diffs são sensacionais. Imagine que você queira comparar duas versões de um mesmo arquivo para descobrir as linhas modificadas. Fazer um diff entre as versões do arquivo te possibilita encontrar exatamente onde está o erro e o melhor, quando juntamos com o Log, podemos saber exatamente o porque a pessoa incluiu aquela linha ou aquele código, e o melhor, quem fez aquela alteração.

Rollback

Mantendo uma história de commits, você tem pontos de volta na história do arquivo, possibilitando a facilidade de voltarmos para antes de alguma modificação. Você pode voltar a partir de um commit, por exemplo. Se o sistema ou o arquivo passou a dar problema depois de uma determinada revisão, é simples de você voltar o arquivo para a versão daquele determinado commit.

Edição multiusuário e merge

Isso é uma maravilha. Me lembro de equipes inteiras perdendo arquivos e partes de código porque dois membros abriam o mesmo arquivo para editar. Obviamente nunca, mas nunca dava certo. O que faziam que equipes inteiras criassem mecanismos da idade das pedras para avisar o resto do pessoal que determinado arquivo estava sendo usado. O trabalho em equipe remotamente nunca era possível. Com um controle de versão isso muda. Qualquer um pode editar qualquer arquivo a qualquer hora.

O sistema de controle de versão compara as modificações feitas no arquivo pelos dois (ou mais) desenvolvedores e junta os códigos automaticamente. Muito bonito, hein?

E quando os desenvolvedores modificam a mesma linha de código? Aí o controle de versão gera um conflito, esse conflito se resolve deve ser resolvido pelo desenvolvedor que executou o segundo commit. Funciona assim:

1. Dois desenvolvedores abrem o mesmo arquivo para editar.

2. Quando os desenvolvedores terminam, eles geram um commit. Se os desenvolvedores fizeram edições em partes diferentes do arquivo, por exemplo, um no topo do arquivo e o outro no final, o sistema junta os códigos fazendo um merge, e criando um arquivo atualizado com as duas revisões.

3. Se sistema percebe que os desenvolvedores fizeram as modificações na mesma linha, o sistema gera um conflito.

4. O conflito é resolvido pelo segundo desenvolvedor que comitar o código. Ou seja, o cara comitou a modificação dele primeiro que você. Quando você comitar a sua modificação, o controle de versão avisará que há um conflito em uma parte do seu código. O conflito é resolvido mostrando algo mais ou menos assim:

1 2 3 4 5 6 7

p { <<<<<<< HEAD:estilo.css    color: red; =======    color: blue; >>>>>>> 77976da35a11db4580b80ae27e8d65caf5208086:estilo.css }

A primeira linha mostra a sua linha. A segunda linha mostra a modificação do outro dev. Aquele hash maluco no final é a identificação do commit do outro dev.

Bom, nesses casos você precisa ver qual código é o correto, e isso as vezes inclui ir perguntar para o outro brother que diachos é aquela coisa que ele fez. Tudo na camaradagem… as vezes.

Concluindo

Estas são algumas premissas sobre controles de versão utilizados hoje em dia. Os controles de versão mais usados hoje são o GIT, SVN e Mercurial. Cada um deles tem comandos diferentes para lidar com as premissas acima e cada um deles faz o controle de sua forma particular. Mesmo assim todos trazem as vantagens que citamos no artigo. Mesmo que você trabalhe sozinho, é recomendado que você trabalhe com controle de versão. Assim você guarda seu projeto de forma segura e tem um histórico das suas modificações durante o tempo. Boas práticas, my friend.

Por Diego Eis

Diego Eis criou o Tableless para disseminar os padrões web no Brasil. Como consultor já treinou equipes de empresas como Nokia, Globo.com, Yahoo! e iG. É palestrante e empreendedor.

http://twitter.com/diegoeis/

Veja os outros posts de Diego Eis

PodCast sobre XP

Para um maior aprendizado, recomendo que escutem e relatem os principais pontos do PodCast sobre XP a seguir:

Introdução ao agilcast e apresentação do Manifesto Ágil. 20:25, 18,7 MB.
Episódio 02 - Uma visão geral de Programação eXtrema (XP). 20:48, 19,1 MB.
Episódio 03 - Testes automatizados. 15:39, 14,7 MB.
Episódio 04 - Bancos de dados ágeis e refatoração de bancos de dados. 14:09, 19,2 MB.
Episódio 05 - Ensino de XP na universidade: a experiência do Sistema Cigarra com o Ministério da Cultura (participação especial: Gilberto Gil). 16:22, 15,7 MB.
Episódio 06 - Entrevista com Eduardo Teruiya, gerente de projetos PMP, sobre gerenciamento de projetos usando XP. 26:42, 24,3 MB.
Episódio 07 - Respondendo perguntas dos Ouvintes. 33:46, 30,9 MB
Episódio 08 - Debate sobre Banco de Dados e CMM. 25:01, 22,9 MB
Episódio 09 - Apresentação da ferramenta Selenium. 10:18, 9,44 MB
Episódio 10 - Uma visão geral de Scrum. 23:38, 22,7 MB
Episódio 11 - Padrões para introduzir novas idéias. 25:52 22,8 MB

Bons estudos, fiquem com Deus e boa sorte.

Provas 2012.1 - UNIDADE I

Avaliações  

Caros colegas, está chegando a hora de nossas avaliações da Unidade I.
Fiquem alertas com relação as datas das avaliações indicadas abaixo.

Disciplina_________________________________ Data
Trabalho Interdisciplinar Dirigido I ______ avaliação contínua
Analise e Modelagem II ____________________ 10/04/2012
Introdução a Sistemas de Informação _______ 12/04/2012
Analise e Modelagem I _____________________ 13/04/2012
Engenharia de Software I __________________ 16/04/2012
Engenharia de Software II _________________ 18/04/2012

Importante: Não se prendam aos slides, estudem os assuntos pelos livros, internet, artigos e apostilas. O conteúdo das provas foi informado em sala de aula.

Não se prendam aos slides! Estudem!

Dicas e Assuntos para as avaliações:

Analise e Modelagem II ____________________ 10/04/2012

·      UML, Diagramas de sequencia, colaboração, estados, componentes, implantação, Processo de desenvolvimento de software e engenharia de Requisitos.

Introdução a Sistemas de Informação _______ 12/04/2012

·      Noções de sistemas de informação, princípios de sistemas de informação, Conceito de dados, informação e conhecimento, porque as empresas precisam de sistemas de informação, Teoria geral de Sistemas e Origem dos Sistemas, classificação dos Sistemas.

Analise e Modelagem I _____________________ 13/04/2012

·     UML, diagrama de caso de uso, diagrama de atividade e identificação de casos de uso.

Engenharia de Software I __________________ 16/04/2012

·     UML, Processos de Software, Engenharia de Requisitos, verificação e validação de software.

Engenharia de Software II _________________ 18/04/2012

·     Gestão de Qualidade, Processo de software, CMMI e MPS.BR,
ATIVIDADE 4 - Verificação de  Conhecimento ao MPS.BR e ATIVIDADE 5 - sobre MPS.BR e CMMI, Reuso de software, Reengenharia.

Fiquem com Deus, bons estudos e boa sorte.

Engenharia de Software II

Pessoal, veja o interessante texto sobre Reuso de Software publicado em 2007 no website http://www.newtonbragarosa.com.br.

REÚSO DE SOFTWARE GERA OTIMIZAÇÃO DOS RECURSOS

Patrícia KnebelOtimizar tempo e reduzir custos são as premissas que estão fazendo com que a estratégia de reutilização de software cresça no mundo e, aos poucos, ganhe força no Brasil. A lógica está em criar uma espécie de biblioteca com práticas e rotinas que possam ser repetidas em alguns estágios do desenvolvimento dos programas pelas fábricas de software e empresas em geral.
Para a professora da Faculdade de Informática da Pontifícia Universidade Católica do Rio Grande do Sul (Pucrs) Ana Paula Terra Bacelo não é mais compatível com a realidade de hoje do mercado a prática de começar do zero todos os projetos. "As corporações precisam ter um processo de desenvolvimento que permita o reuso, a partir da criação de componentes genéricos e que possam ser usados em aplicações específicas", afirma.
A universidade irá sediar, em 2008, o Simpósio Brasileiro de Componentes, Arquiteturas e Reutilização de Software (SBCCARS), que este ano está sendo realizado na Universidade de Campinas (Unicamp). A edição deste ano termina na sexta-feira. "Com esse evento, queremos disseminar o conceito de reutilização de software e avançar o estado da arte sobre desenvolvimento de componentes", afirma a coordenadora-geral do simpósio, Cecília Mary Fischer Rubira. Além disso, a idéia é estimular o contato da indústria com as áreas de engenharia de software, na busca por aplicabilidades e soluções que funcionem na prática.
A especialista da Pucrs explica que, para que seja possível a concepção de modelos que sigam esse conceito, devem ser criadas estruturas fixas nas quais os colaboradores possam consultar as bibliotecas e adaptar os sistemas para cada projeto. Entre os softwares nos quais o reuso vem sendo aplicado estão os de gestão e também os mais específicos, como para a área médica.
Essa estratégia, entretanto, ainda não é uma realidade no mercado brasileiro. "A diminuição do trabalho e da qualidade dos produtos é grande, porém, ainda não existe uma política de uso no País", observa. O contrário acontece nos países mais desenvolvidos, nos quais as exigências na manutenção dos índices de qualidade e produtividade perseguem os gestores.
A Digital Assets atua na implantação, com o conceito de reutilização de software dentro das empresas. São usados produtos e serviços para ajudar as áreas internas de Tecnologia da Informação (TI), de clientes como Embraer e Bank Boston, a usar esses processos no dia-a-dia.
Kleber Bacili, diretor de tecnologia, diz que soluções contribuem para a criação de repositórios através dos quais as companhias podem catalogar os procedimentos, rotinas e ferramentas usadas. "Trabalhamos muito com empresas cujo foco não é o desenvolvimento de software e, por isso mesmo, precisam otimizar o tempo", relata.
O presidente da Associação Sul-rio-grandense de Apoio ao Desenvolvimento de Software (Softsul), José António Antonioni, acredita que o mercado deverá demandar mais esse tipo de solução nos próximos anos, principalmente as fábricas de software. "Ao ter componentes previamente construídos, testados e validados, as empresas têm um menor esforço de desenvolvimento e reduzem custos", constata.
Segundo ele, entretanto, ainda existem questões tecnológicas que impedem que o reuso de software seja adotado em larga escala. Se um sistema estiver sendo construído usando a linguagem de programação Java, é mais complexo fazer uma reutilização se a continuação for através da .net. "Não é algo tão trivial, mas que, quando pode ser feita, traz inúmeras vantagens para as empresas", relata Antonioni. Soluções que ajudem na interoperabilidade dos sistemas, como Service Oriented Architecture (SOA) conseguem atenuar essa dificuldade entre as interfaces.
Fonte: Jornal do Comércio

Exemplo de documentação de requisitos de sistema

Pessoal, para quem esta com um pouco de dificuldade com relação a documentação dos requisitos de sistema, segue um exemplo.

http://vensso.sourceforge.net/doc/VENSSO_REQ_20050526.pdf

Em breve, estarei disponibilizando outros materiais complementares.

Boa sorte, bons estudos. Fiquem com Deus.

Engenharia de Software II

Parabéns a todas as equipes!

Caros, meus elogios pelas apresentações sobre processos de software.
As considerações e maiores detalhes a respeito já foram feitos em classe.
Tenho certeza que a próxima atividade será muito melhor.

Bom, para a próxima aula estudem MPS.BR e CMMI.

Recomendo que tragam bastante material sobre o assunto pois provavelmente será feito uma atividade de pesquisa.

Bons estudos, fiquem com Deus.

Material de estudo

Caros, segue para download os arquivos e outros materiais usados na confecção das aulas.

Atenção: estudem pelos livros indicados na ementa acrescentando a esse estudo as abordagens em sala de aula e os materiais indicados pelo professor.

Qualquer dúvida entrem contato.

1. Analise e Modelagem I
2. Analise e Modelagem II
3. Engenharia de Software I
4. Engenharia de Software II
5. Introdução a Sistemas de Informação
6. Trabalho Interdisciplinar Dirigido I

Engenharia de Software II

Engenharia de Software II - Avaliação em Grupo I Unidade

Cada equipe deve abordar um modelo para apresentação expositiva com slide, abordando todos os aspectos de cada modelo, apontando vantagens e desvantagens. Deve ser feito comparações com outros modelos. Tempo médio para cada apresentação: 20 minutos.

Detalhe: todos os membros serão avaliados individualmente no dia da apresentação, levando em conta domínio do conteúdo apresentado.

1. Modelo cascata.
2. Modelo interativo e incrementais.
3. Modelos evolutivos de processo.
4. Modelos especializados de processo.
5. Modelos de Processo unificado.

Além da apresentação, deve ser produzido  material impresso referente a todos os modelos e suas respectivas abordagens. Será sorteado na hora o assunto a ser apresentado. Portanto, todas as equipes devem estar preparadas na próxima aula para à apresentação.

Entrega impressa e eletrônica
1. Impressa: ao professor no dia da apresentação
2. Eletrônica no e-mail do professor antes da data de apresentação: marcosmoraisdesousa@gmail.com

Abaixo, a relação de integrantes por equipe.

1-Modelo cascata
Marcos Almeida, Eric Miranda, Diego Santos,

2-Modelo interativo e incrementais 
Jose Roberto, Aloísio Alves, Fábio Nogueira, Charles  Barreto

3-Modelos evolutivos de processo
Edson, Richard

4-Modelos especializados de processo
Danila Araujo, David Jr, Felipe Cajado

5-Modelos de Processo unificado
Jéssica Cerqueira, Caio Lucas, Rodrigo Cardoso

Engenharia de Software I e II

Assista direto no Youtube as aulas abaixo para complementar o conteúdo sobre engenhraria de software.

São aulas ministradas por professores que abordam vários aspectos da Engenharia de Software com uma boa apresentação de slides.

Cada aula dura em média 10 a 11 minutos.

Aula 1 - Parte 1 - Entender as principais características de um Software e sua qualidade.
Link Youtube

Aula 1 - Parte 2 - História e Princípios da Engenharia de Software
Link Youtube

Aula 2 - Parte 1 - Processos e Modelos de Softwares.
Link Youtube

Aula 2 - Parte 2 - Desenvolvimento Evolucionário de um Software(Controle de Versões)
Link Youtube

Aula 3 - Parte 1 - Requisitos de ambas as partes, Tarefa da Engenharia de Requisitos.
Link Youtube

Aula 3 - Parte 2 - Especificação, Validação, Gestão(Partes do processo de construção)
Link Youtube

Aula 4 - Parte 1 - Metodologias de testes na engenharia, Técnicas de manutenção do software.
Link Youtube

Aula 4 - Parte 2 - Caixa preta, Casos de Teste, Confiabilidade
Link Youtube

Aula 5 - Parte 1 - Qualidade e Métricas de Software, Qualidade e Custos de Softwares.
Link Youtube

Aula 5 - Parte 2 - Métricas de Software(Tamanhos, Funções, Re-Trabalho), Problemas de métricas.
Link Youtube

Aula 6 - Parte 1 - Teoria da Análise orientada a Objetos
Link Youtube

Aula 6 - Parte 2 - Continuação da Análise orientada a Objetos
Link Youtube