portifolio Semestre 4 UNOPAR

Prévia do material em texto

Vitor dos Santos Gomes
Trabalho de Tecnologia em Análise e Desenvolvimento de Sistemas, como trabalho interdisciplinar das disciplinas estudas no Semestre 4º flex / 5º reg
• Engenharia e Projeto de Software 
• Projeto Orientado a Objetos
• Programação para Web I
Professores: 
• Gilberto Fernandes Junior
• Vanessa Matias Leite.
RESUMO
Estre trabalho procura abordar o conteúdo temático visto ao longo das disciplinas do Semestre 4º flex / 5º reg, do curso de Análise e Desenvolvimento de Sistemas.
Palavras-chave: Consultoria, Construarte, startup
Sumario
1 ....................................................................introducao Pág. 4
2 ............................................................................Scrum pág. 5
3 ...................................................Orientação a Objeto pág. 13
4 ............................................Arquitetura de Software pág. 16
5 .............................................................................MVC pág. 17
8 ...................................................................Conclusao pág. 22
9 ...................................................................referência pág. 22
INTRODUÇÃO
	A importância de planejar e desenvolver um sistema, onde todo o processo deve ser minunciosamente estudado. Apos uma analise sobre os processos apresentamos uma metodologia de desenvolvimento que vem agregar valor otimizando tempo em todo o processo.
O Scrum
O Scrum trabalha com ciclos curtos de desenvolvimento e entrega de software. Dessa maneira, o feedback sobre o resultado é obtido rapidamente, o que garante a qualidade do produto e a satisfação do cliente, que passa a fazer parte do processo e a perceber os resultados rapidamente.
O Scrum se apoia em 3 pilares fundamentais: Transparência, Inspeção e Adaptação.
Transparência
Todos os responsáveis pelo resultado devem ter a visão de tudo o que está acontecendo, além de um mesmo entendimento do que está sendo visto.
Inspeção
Os artefatos e o progresso em direção ao objetivo devem ser inspecionados frequentemente por todos os usuários do Scrum, de maneira a detectar desvios indesejáveis.
Adaptação
As coisas mudam. O Scrum aceita essa verdade e prega a adaptação a mudanças no lugar de tentar evitá-las. Trabalhando com ciclos curtos, as mudanças são melhor aceitas e menos dolorosas, uma vez que não existem planos extensos que deverão ser mudados para adequar-se a elas.
Papéis
Um time Scrum apresenta 3 papéis distintos, que serão melhor explicados a seguir: Scrum Master, Product Owner e Time de Desenvolvimento.
Scrum Master
O Scrum Master ou SM é o Mestre do time Scrum. No entanto, ele não é um gerente ou coisa que o valha, uma vez que o time Scrum é autogerenciável.
As principais tarefas do Scrum Master são:
Garantir que os membros do time entendam e apliquem as regras do Scrum;
Remover todos os impedimentos que possam atrapalhar o bom andamento do time;
Realizar o treinamento de pessoas / equipes que não sejam familiarizadas com o Scrum;
Ser o facilitador de todos os eventos do Scrum.
O Scrum Master deve ser uma pessoa capaz de inspirar os demais membros do time a serem autogerenciáveis e interdisciplinares, além de mostrar a importância dos valores ágeis. Deve ser uma pessoa com influência na organização e apoio da alta gerência, uma vez que caberá a ele resolver os impedimentos.
Product Owner
O Product Owner ou PO representa o cliente dentro do time Scrum. É sabido que um alto grau de envolvimento do cliente representa mais assertividade nos resultados. No entanto, normalmente o cliente não pode estar disponível para o Time de Desenvolvimento toda vez que seja necessário tirar uma dúvida ou validar um requisito, por exemplo. Por isso esse papel no Scrum cabe ao Product Owner.
O Product Owner é o responsável por priorizar os requisitos a serem desenvolvidos, aceitar os requisitos entregues e fazer a interface entre o Time de Desenvolvimento e o cliente.
O foco do Product Owner é maximizar o valor do produto entregue, visando sempre o desenvolvimento dos requisitos mais importantes para o negócio.
As principais tarefas do Product Owner são:
Manter o Product Backlog;
Aceitar ou rejeitar o trabalho realizado pelo Time de Desenvolvimento;
Priorizar os requisitos a serem implementados;
Estar presente para auxiliar o Time de Desenvolvimento durante a execução do trabalho;
Auxiliar o cliente na descoberta de novos requisitos;
Ser o centralizador de demandas que chegarão ao Time de Desenvolvimento;
Caso o Product Owner não possua alguma informação necessária, é papel dele realizar esse levantamento junto ao cliente.
Time de Desenvolvimento
O Time de Desenvolvimento é composto por todos os responsáveis pelo desenvolvimento dos requisitos (programadores, testers, DBA's, etc.). Dentro do time, independente de seu cargo na organização, todos são conhecidos como Desenvolvedor.
O Time de Desenvolvimento é auto gerenciável, ou seja, ninguém pode dizer ao time o que fazer, exceto o próprio time.
De acordo com o Guia do Scrum, o Time de Desenvolvimento idealmente deve ter entre 3 e 9 membros.
Artefatos
O Scrum possui alguns artefatos definidos que têm como principal objetivo possibilitar a sustentação dos três pilares do Scrum durante o trabalho, fornecendo transparência e oportunidades para inspeção e adaptação durante todo o processo.
A seguir, uma definição dos artefatos definidos no Guia do Scrum
Product Backlog
É uma lista priorizada de todos os requisitos necessários no produto.
O Product Backlog é a origem única de todos os requisitos para qualquer mudança a ser feita no produto, e é mantido pelo Product Owner.
Os primeiros itens do Product Backlog, que são os prioritários, serão os primeiros a serem desenvolvidos. Por isso, precisam estar em um nível tal de detalhe que possibilite o seu entendimento por todos os envolvidos.
Já os itens menos imediatos têm um nível de detalhe menor, uma vez que não serão desenvolvidos imediatamente.
A medida que um item vai subindo no backlog, seu nível de detalhe aumenta.
O Product Backlog nunca está pronto. Uma vez que o Scrum aceita as mudanças, a cada ciclo de desenvolvimento, novos requisitos são descobertos, e esses devem ser incluídos no backlog de acordo com sua prioridade.
Da mesma maneira, durante o ciclo de vida de um produto pode-se perceber que determinados itens do backlog deixaram de fazer sentido, não sendo mais necessários. Esses itens devem ser removidos do Product Backlog tão logo se perceba essa necessidade.
Sprint Backlog
É uma lista priorizada de tudo que será desenvolvido na Sprint atual.
Durante toda a Sprint, o Time de Desenvolvimento modifica o backlog, adequando-o as mudanças ocorridas durante o desenvolvimento.
Somente o Time de Desenvolvimento pode alterar o Sprint Backlog.
Incremento
Ao final de uma sprint, todos os itens que foram finalizados formam um incremento do produto. Esse incremento deve ser entregável e utilizável, de maneira que o cliente perceba valor no produto a cada final de sprint.
A decisão de liberar ou não o incremento pertence ao Product Owner.
Definição de Pronto
Todos os itens que serão implementados devem possuir uma definição de pronto clara e que faça sentido para todos os envolvidos.
É através da definição de pronto que se assegura a transparência de quando determinada parte do trabalho estará realmente finalizada.
Somente itens com definição de pronto clara são considerados aptos para terem sua estimativa realizada e seu desenvolvimento iniciado, uma vez que sem essa informação é impossível para o Time de Desenvolvimento estimar e realizar o trabalho.
Eventos
O Guia do Scrum descreve alguns eventos, usados para criar uma rotina e diminuir a ocorrência de reuniões não planejadas.
Os eventos no Scrum são time-boxed, ou seja, possuem um tempo pré-determinado. Isso força que o evento seja realizado no tempo estabelecido, evitando desperdícios.
Todos os eventos do Scrum são oportunidades para inspecionar e adaptar algo. A ocorrência doseventos aumenta a transparência do processo para todos os envolvidos.
Sprint
Com um time-box que varia entre duas e quatro semanas, a sprint é o coração do Scrum. É durante a sprint que o trabalho é efetivamente realizado pelo Time de Desenvolvimento e, ao seu final, espera-se obter um incremento potencialmente utilizável do produto.
Toda sprint possui uma meta. A meta é definida pelo Product Owner e deve refletir um objetivo do negócio. Durante a sprint, o Time de Desenvolvimento se guia pela meta, para saber qual tarefa é mais importante de ser concluída. A meta é a grande responsável por manter todos os membros do time em sintonia, uma vez que guia o trabalho de todos durante a sprint.
Sprints não podem durar mais do que quatro semanas. Isso porque em quatro semanas as coisas podem mudar e a meta da sprint deixar de fazer sentido.
Scrum aceita muito bem mudanças, no entanto, durante uma sprint certas coisas não podem ser alteradas:
A composição do Time de Desenvolvimento;
Critérios de qualidade;
A meta da Sprint.
Caso o aprendizado durante a sprint force alguma alteração no escopo combinado previamente, isso deve ser negociado entre o Product Owner e o Time de Desenvolvimento.
Durante a sprint, é papel do Scrum Master manter o Time de Desenvolvimento isolado de problemas externos, eliminando todos os impedimentos à realização do trabalho que possam surgir.
O Product Owner deve estar disponível durante a sprint o maior tempo possível. Um Product Owner ausente costuma ser um grande problema, uma vez que algumas dúvidas relacionadas a regras de negócio só podem ser esclarecidas por ele.
Reunião de Planejamento da Sprint
Com um time-box que varia entre quatro e oito horas, a reunião de planejamento é o evento onde são definidos e discutidos os itens que farão parte da sprint.
Basicamente a reunião de planejamento deve responder duas questões:
O que será entregue como incremento ao fim da próxima sprint?
Como o trabalho será realizado para que esse incremento seja entregue?
A reunião de planejamento é dividida em duas partes, cada uma com metade do time-box da reunião, dedicada a responder uma das questões.
Como o trabalho será realizado?
Após selecionar os itens que serão completados na sprint, o Time de Desenvolvimento passa a discutir como construir as funcionalidades durante a sprint, de maneira que sejam consideradas completadas (de acordo com a definição de pronto).
Os itens que serão realizados na sprint, junto com seu plano de entrega, compõem o Sprint Backlog.
Feito isso, o Time de Desenvolvimento estima todos os itens do backlog da sprint. Nesse momento, o Product Owner pode estar presente, para esclarecer alguma dúvida que possa surgir ou mesmo realizar algum ajuste no escopo da sprint, caso o Time de Desenvolvimento julgue esse ajuste necessário.
Se sentir necessidade, o Time de Desenvolvimento também pode convidar outras pessoas a participarem da reunião, como especialistas técnicos, por exemplo.
As estimativas são feitas sempre por todos os membros do Time de Desenvolvimento. Existem diversas técnicas de estimativa, mas o mais importante nesse momento é que os itens sejam discutidos por todos até que o Time se sinta confortável a se comprometer com uma estimativa.
Ao final da reunião, o Time de Desenvolvimento possui o Sprint Backlog e metas definidos, além de um plano de trabalho determinado para a entrega dos requisitos.
Reunião diária
Com um time-box de quinze minutos, a reunião diária deve ser realizada sempre no mesmo local e horário, contando com a presença de todos os membros do Time de Desenvolvimento.
Somente os membros do Time de Desenvolvimento participam dessa reunião. Alguns sustentam que essa reunião seja feita com os participantes em pé, de maneira a evitar que o time-box seja desrespeitado.
Nessa reunião, cada membro do Time de Desenvolvimento deve responder três questões:
O que foi feito desde a última reunião?
O que será feito até a próxima reunião?
Existe algum impedimento para a conclusão das tarefas?
A reunião diária é uma reunião chave para inspeção e adaptação, uma vez que, a cada 24 horas, todos os membros do Time de Desenvolvimento tem oportunidade de se reunir, inspecionar o andamento do trabalho e adaptá-lo a alguma necessidade que tenha surgido.
Com a reunião diária, todos os membros do Time de Desenvolvimento são capazes de reportar o andamento da sprint para o Scrum Master ou Product Owner, por exemplo.
O Scrum Master deve ficar atento aos impedimentos levantados durante a reunião diária, uma vez que será sua responsabilidade removê-los para que o trabalho do time possa ser executado.
Revisão da Sprint
Com um time-box entre duas e quatro horas, a reunião de revisão da sprint é realizada ao final da sprint e tem o propósito de inspecionar o incremento e atualizar o Product Backlog, se necessário.
Nessa reunião, o Time de Desenvolvimento e as partes interessadas discutem sobre o que foi feito na sprint e também sobre os próximos itens a serem entregues.
Essa reunião tem o intuito de promover ao Time de Desenvolvimento um feedback sobre o trabalho realizado durante a sprint, motivando-o e promovendo a colaboração.
Durante essa reunião, o Product Owner identifica o que foi pronto e o que não foi pronto, de acordo com a definição estabelecida. Além disso, discute e revisa o Product Backlog, projetando as prováveis datas de conclusão de acordo com o andamento até o momento.
O Time de Desenvolvimento levanta o que foi bem durante a sprint, além dos problemas ocorridos e como foram resolvidos. Além disso, o Time de Desenvolvimento apresenta o que está pronto e também responde questões sobre o incremento.
Retrospectiva da Sprint
Com um time-box entre uma e três horas, a reunião de retrospectiva da sprint serve para o Time de Desenvolvimento promover sua melhoria contínua.
Nessa reunião o Scrum Master, como facilitador, deve incentivar o Time de Desenvolvimento a levantar os seguintes pontos:
Como a sprint transcorreu em relação às pessoas, aos processos, às ferramentas, etc;
Levantar os pontos positivos da sprint e os pontos a melhorar;
Montar um plano para implementar melhorias no trabalho do Time de Desenvolvimento.
Ao final dessa reunião, o time possui uma lista de melhorias a serem realizadas para a próxima sprint, além de uma lista do que deu certo e deve ser repetido.
Modelo de Maturidade (CMMI)
nível 2 (Práticas Nascentes) acontece quando alguém começa a realizar um experiento em base pessoal ou no seu time. Por exemplo, um desenvolvedor de software começa a fazer “Código Limpo”, que é uma abordagem estruturada para codificar com manutenibilidade, estensibilidade, segurança e reduzidos defeitos.
Orientacao a Objetos (Csharp)
O C# é uma linguagem de programação orientada a objetos e orientada a componentes. O c# fornece construções de linguagem para dar suporte direto a esses conceitos, tornando o C# uma linguagem natural para criar e usar componentes de software. Desde sua origem, o C# adicionou recursos para dar suporte a novas cargas de trabalho e práticas de design de software emergentes.
Os programas em C# são executados no .NET, um sistema de execução virtual chamado Common Language Runtime (CLR) e um conjunto de bibliotecas de classes. O CLR é a implementação da Microsoft da CLI (Common Language Infrastructure), um padrão internacional. A CLI é a base para a criação de ambientes de execução e desenvolvimento nos quais as linguagens e bibliotecas funcionam em conjunto diretamente.
O código-fonte escrito em C# é compilado em uma Il (linguagem intermediária) que está de acordo com a especificação da CLI. O código de IL e os recursos, como bitmaps e cadeias de caracteres, são armazenados em um assembly, normalmente com uma extensão de . dll. Um assembly contém um manifesto que fornece informações sobre os tipos, a versão e a cultura do assembly.
Quando o programa C# é executado, o assembly é carregado no CLR. O CLR executa a compilação JIT (just-in-time) para converter o código IL em instruções de máquina nativa. OCLR fornece outros serviços relacionados à coleta de lixo, manipulação de exceções e gerenciamento de recursos automáticos. O código executado pelo CLR, às vezes, é chamado de "código gerenciado", em oposição ao "código não gerenciado", que é compilado em linguagem de máquina nativa direcionada a uma plataforma específica.
A interoperabilidade de linguagem é um recurso fundamental do .NET. O código de IL produzido pelo compilador C# está de acordo com a CTS (especificação de tipo comum). O código IL gerado do C# pode interagir com o código gerado nas versões do .NET do F #, Visual Basic, C++ ou em qualquer um dos mais de 20 outros idiomas compatíveis com CTS. Um único assembly pode conter vários módulos escritos em diferentes linguagens .NET, e os tipos podem referenciar um ao outro como se fossem escritos no mesmo idioma.
frameworks
O Entity Framework Core é um mapeador moderno de banco de dados de objeto para .NET. Ele dá suporte a consultas LINQ, controle de alterações, atualizações e migrações de esquema. O EF Core funciona com muitos bancos de dados
Arquitetura de software
conceito principal do modelo MVC é utilizar uma solução já definida para separar partes distintas do projeto reduzindo suas dependências ao máximo.
Desenvolver uma aplicação utilizando algum padrão de projeto pode trazer alguns dos seguintes benefícios:
· Aumento de produtividade;
· Uniformidade na estrutura do software;
· Redução de complexidade no código;
· As aplicações ficam mais fácies de manter;
· Facilita a documentação;
· Estabelece um vocabulário comum de projeto entre desenvolvedores;
· Permite a reutilização de módulos do sistema em outros sistemas;
· É considerada uma boa prática utilizar um conjunto de padrões para resolver problemas maiores que, sozinhos, não conseguiriam;
· Ajuda a construir softwares confiáveis com arquiteturas testadas;
· Reduz o tempo de desenvolvimento de um projeto.
O Padrão MVC (Model-View-Controller)
O MVC é utilizado em muitos projetos devido a arquitetura que possui, o que possibilita a divisão do projeto em camadas muito bem definidas. Cada uma delas, o Model, o Controller e a View, executa o que lhe é definido e nada mais do que isso.
A utilização do padrão MVC traz como benefício o isolamento das regras de negócios da lógica de apresentação, que é a interface com o usuário. Isto possibilita a existência de várias interfaces com o usuário que podem ser modificadas sem a necessidade de alterar as regras de negócios, proporcionando muito mais flexibilidade e oportunidades de reuso das classes.
Uma das características de um padrão de projeto é poder aplicá-lo em sistemas distintos. O padrão MVC pode ser utilizado em vários tipos de projetos como, por exemplo, desktop, web e mobile.
A comunicação entre interfaces e regras de negócios é definida através de um controlador, que separa as camadas. Quando um evento é executado na interface gráfica, como um clique em um botão, a interface se comunicará com o controlador, que por sua vez se comunica com as regras de negócios.
Imagine uma aplicação financeira que realiza cálculos de diversos tipos, como os de juros. Você pode inserir valores para os cálculos e também escolher que tipo de cálculo será realizado. Isto tudo é feito pela interface gráfica, que para o modelo MVC é conhecida como View. No entanto, o sistema precisa saber que você está requisitando um cálculo, e para isso, terá um botão no sistema que quando clicado gera um evento.
Este evento pode ser uma requisição para um tipo de cálculo específico como o de juros simples ou juros compostos. Fazem parte da requisição os valores digitados no formulário e a seleção do tipo de cálculo que o usuário quer executar sobre o valor informado. O evento do botão é como um pedido a um intermediador (Controller) que prepara as informações para então enviá-las para o cálculo. O controlador é o único no sistema que conhece o responsável pela execução do cálculo, neste caso, a camada que contém as regras de negócios. Esta operação matemática será realizada pelo Model assim que ele receber um pedido do Controller.
O Model realiza a operação matemática e retorna o valor calculado para o Controller, que também é o único que possui conhecimento da existência da camada de visualização. Tendo o valor em mãos, o intermediador o repassa para a interface gráfica que exibirá para o usuário. Caso esta operação deva ser registrada em uma base de dados, o Model se encarrega também desta tarefa.
O MVC inicialmente foi desenvolvido no intuito de mapear o método tradicional de entrada, processamento, e saída que os diversos programas baseados em GUI utilizavam. No padrão MVC, teríamos então o mapeamento de cada uma dessas três partes para o padrão MVC.
			
a modelagem do mundo externo e o feedback visual para o usuário são separados e gerenciados pelos objetos Modelo (Model), Visão (View) e Controlador (Controller).
	
Explicando cada um dos objetos do padrão MVC tem-se:
Primeiramente o controlador (Controller), que interpreta as entradas do mouse ou do teclado enviadas pelo usuário e mapeia essas ações do usuário em comandos que são enviados para o modelo (Model) e/ou para a janela de visualização (View) para efetuar a alteração apropriada;
Por sua vez, o modelo (Model) gerencia um ou mais elementos de dados, responde a perguntas sobre o seu estado e responde a instruções para mudar de estado. O modelo sabe o que o aplicativo quer fazer e é a principal estrutura computacional da arquitetura, pois é ele quem modela o problema a ser resolvido;
Por fim, a visão (View) gerencia a área retangular do display e é responsável por apresentar as informações para o usuário através de uma combinação de gráficos e textos. A visão não sabe nada sobre o que a aplicação está atualmente fazendo, pois tudo que ela realmente faz é receber instruções do controle e informações do modelo e então exibi-las. A visão também se comunica de volta com o modelo e com o controlador para reportar o seu estado.
Portanto, a principal ideia do padrão arquitetural MVC é a separação dos conceitos - e do código. O MVC é como a clássica programação orientada a objetos, ou seja, criar objetos que escondem as suas informações e como elas são manipuladas e então apresentadas em uma interface simples para o mundo. Entre as diversas vantagens do padrão MVC estão a possibilidade de reescrita da GUI ou do Controller sem alterar o modelo, reutilização da GUI para diferentes aplicações com pouco esforço, facilidade na manutenção e adição de recursos, reaproveitamento de código, facilidade na manutenção do código sempre limpo etc.
Exemplo prático de MVC
			
Note que eu coloquei o controller dentro de parenteses, isso faz com que não seja necessário eu instanciar em uma variável, já que só vou usar isso agora, então eu executei um método chamado action(), o action é uma "parte" do controller, normalmente usamos para definir uma página expecifica, por exemplo, um controller chamado Usuarios poderia ter actions login, logout, editar, ver, apagar.
Agora vamos criar nosso arquivo controller.php.
		
Modelo
		
View
		
Vantagens do padrão MVC
Como todo padrão de desenvolvimento de software, existem vantagens e desvantagens em utilizá-los. O padrão MVC oferece principalmente vantagens, mas pode também considerar-se que possui algumas desvantagens. Vamos relembrar algumas vantagens em desenvolver utilizando o padrão MVC:
Separação muito clara entre as camadas de visualização e regras de negócios;
Manutenção do sistema se torna mais fácil;
Reaproveitamento de código, principalmente da camada de modelo, que pode ser reutilizada em outros projetos;
As alterações na camada de visualização não afetam as regras de negócios já implementadas na camada de modelo;
Permite o desenvolvimento, testes e manutenção de forma isolada entre as camadas;
O projeto passa a ter uma melhor organização em sua arquitetura;
Torna o entendimento do projeto mais fácil para novos programadores que não participaram de sua criação.
As desvantagens sãopoucas, mas alguns desenvolvedores acabam não usando o padrão MVC por conta delas, veja algumas:
Em sistemas de baixa complexidade, o MVC pode criar uma complexidade desnecessária;
Exige muita disciplina dos desenvolvedores em relação à separação das camadas;
Requer um tempo maior para modelar o sistema.
Sempre que um sistema for desenvolvido, terá com certeza a necessidade de manutenção como melhorias ou correção de erros e também pode necessitar de varias atualizações. Embora alguns programadores achem que o padrão MVC é muito custoso para ser aplicado, ele se torna muito mais fácil quando há necessidades de executar manutenções e atualizações, já que possui sua estrutura bem definida e suas camadas separadas de forma a diminuir a dependência entre elas.
CONCLUSÃO:
Esta atividade teve como principal objetivo aperfeiçoar nossos conhecimentos.
Podemos concluir que Metodologias ageis nao so beneficia o desenvolvimento de aplicaçoes como uma serie de beneficioes tanto para o time de desenvolvimento quanto a espectativa do cliente.
REFERÊNCIAS:
https://www.devmedia.com.br/apresentacao-do-scrum/27887
https://docs.microsoft.com/pt-br/dotnet/csharp/tour-of-csharp/
https://www.devmedia.com.br/introducao-ao-padrao-mvc/29308
https://webdevbr.com.br/mvc-na-pratica-entendendo-o-padrao-mvc-na-pratica