Git Product home page Git Product logo

5thewin's Introduction

| Home | Courseware | Apoio | Programação em Par | Projeto | Syllabus | Equipes | Notas | Exercícios Escolares |

IF977 - Engenharia de Software

IF977

Esta é a página/repositório da disciplina de Engenharia de Software, voltada ao curso de Bacharelado em Sistemas de Informação, do Centro de Informática (CIn) da Universidade Federal de Pernambuco (UFPE). Esta "versão" da disciplina foi inspirada na experiência profissional do professor Vinicius Cardoso Garcia e nas lições aprendidas com as versões anteriores da disciplina, sugestões e relatos da disciplina "CS169 - Software Engineering" da UC Berkeley.

Para quem tiver curiosidade, a história dessa cadeira é, resumidamente, contada nestes três primeiros artigos. Os demais também influenciaram na história e evolução da cadeira.

Sistemas de Informação, Centro de Informática, (UFPE)

Instrutores

Local e Horários

Centro de Informática, horários: segunda (18:50-20:30) e quarta (17:00-18:40), sala E123.

Comunicação

  • Para facilitar a comunicação via e-mail no âmbito da disciplina, utilizem [if977] como parte do assunto do email.
  • [OBRIGATÓRIO] Temos um canal no Discord para uma comunicação mais dinâmica (para entrar, entre em contato com o professor).

Edições anteriores

Atenção

Este repositório contém apenas notas de aulas superficiais. Estas notas não devem ser utilizadas como livro-texto. Um bom desempenho na disciplina depende muito do estudo mais profundo dos livros e, principalmente, da prática no computador.

Ementa

Engenharia de Software não é só desenvolvimento de software. Ou seja, não é somente a atividade de programar e conhecer linguagens e ferramentas de apoio à programação. Existem uma série de processos envolvidos que colaboram na “construção” de um produto de software, desde a especificação do projeto, seu planejamento de execução, desenvolvimento, testes, manutenção e evolução. Portanto, Engenharia de Software claramente não se trata apenas de programação, uma atividade que pode ser desenvolvida de forma independente de outras pessoas, mas sim de um conjunto de atividades, tarefas e mais ainda, papéis que requerem trabalho em equipe (social) e capacidade de comunicação (socialização). Neste curso, vamos estudar princípios da Engenharia de Software, seus objetivos, atividades, papéis, recursos, como planejar um projeto, descobrir requisitos, abstrair uma proposta de construção de um produto de software e apresentar uma solução que será construída de forma iterativa, bem como a continuidade da vida útil deste produto.

Objetivos

O objetivo principal deste curso é estudar, analisar, discutir, e aplicar os fundamentos de Engenharia de Software. Do ponto de vista prático, os conceitos estudados serão aplicados no desenvolvimento de um projeto de um sistema de informação SaaS simples.

Os estudantes irão:

  • Entender os novos desafios, oportunidades e problemas em aberto do novo cenário da indústria de software como serviço e as principais diferença sem relação ao software empacotado (SWS, shrink-wrapped software);
  • Desenvolver um um projeto de um sistema de informação SaaS simples desde a concepção através de planejamento, desenvolvimento, avaliação/teste, implantação e operação, enfrentando os desafios inerentes de cada fase;
  • Compreender e utilizar ferramentas e metodologias ágeis de desenvolvimento, incluindo esboço UI de baixa fidelidade (lo-fi), estórias de usuários, desenvolvimento orientado a comportamento, controle de versão para desenvolvimento baseado em times e ferramentas de gerenciamento para ambientes de computação em nuvem;
  • Desenvolver habilidades técnicas e de colaboração para trabalhar em times de desenvolvimento software;
  • Compreender e aplicar estruturas, padrões e técnicas fundamentais de programação, incluindo padrões de projeto para arquitetura de software, funções de ordem superior, metaprogramação, reflexão, entre outras, para melhorar a capacidade de manutenção, modularidade e reutilização de software.

Metodologia

Utilizaremos uma abordagem aderente a essa jornada de educação digital. Para isso, temos uma composição metodológica inspirada em Sala de Aula Invertida, Pensamento de Design, Design de Experimentação e Ensino Baseado em Desafios. Trabalharemos com missões e para cada missão os alunos devem -- individualmente ou em grupo, isso vai se ajustando ao longo da jornada - inicialmente individual -- produzirem algo -- um texto, um sistema, uma imagem, um infográfico, um video, etc. -- que vai ser definido em função de cada missão (seus prazos são definidos a depender da missão em questão).

Temos como base os princípios:

  • Conhecimento como “obra aberta” (em vez de “mensagem fechada”);
  • Curadoria de conteúdos, sínteses e roteiros de trabalho (em vez da produção de conteúdos próprios para EAD, por exemplo);
  • Ambiências computacionais diversas (em vez de se restringir aos serviços do Ambiente de Aprendizagem);
  • Aprendizagem em rede, colaborativa (em vez de aprendizagem isolada);
  • Divergência, convergência e conversação entre todos, em interatividade (em vez de apresentação de conteúdos);
  • Atividades autorais inspiradas nas práticas da cibercultura (em vez de “estudo dirigido”);
  • Mediação online para colaboração (em vez de “tutoria reativa”); e,
  • Jornada formativa e colaborativa, baseada em competências (em vez de apenas exames presenciais).

Do ponto de vista de plataforma de apoio a jornada de educação digital, utilizamos um servidor do Discord para comunicação assíncrona e ambientes de reunião (sala de audio e video) para encontros fortuitos, os encontros síncronos (e gravados) acontecem em uma sala fixa no Google Meet, Mural para dinâmicas de trabalho síncrono e para as missões utilizados a plataforma Strateegia). Informamos que cada aula terá a duração de 60 (sessenta) minutos, configurada no Siga.

Avaliação

A avaliação neste curso se dará da seguinte forma: os aspectos teóricos serão avaliados por meio das missões com caráter de avaliação individual, mas vale ressaltar que as missões possuem uma natureza de execução prática; a consolidação dos aspectos teóricos discutidos ao longo da disciplina serão avaliados por meio de um exercício prático e em equipe que consistirá no desenvolvimento de um projeto de sistema de informação SaaS simples. Quanto aos exercícios escolares no formato de missões, as 25% piores avaliações de cada estudante serão descartadas. A não realização das missões ou no exercício em, equipe implica em reprovação. A media da disciplina sera calculada da seguinte forma:

  • Media = ( 4 * NotaEE1 + 6 * NotaProjeto) / 10, onde
    • NotaEE1 é a nota individual do estudante referente às missões;
    • NotaProjeto é a nota do projeto sera calculada com base nos seguintes aspectos:
      • avaliação do desempenho nas iterações; escopo do cenário; identificação das personas; concepção do Plano de MVP; especificação da Proposta de Solução; projeto da Arquitetura; especificação e implementação de Testes; Implantação da solução; Relato de Lições Aprendidas & Decisões de Projeto.

Monitoria

Os monitores são responsáveis por aulas práticas da disciplina. Também são responsáveis por acompanhar projetos das equipes formadas. Fora do horário das aulas, deve-se agendar uma reunião com os monitores com o fim de tirar dúvidas sobre o conteúdo da disciplina, bem como para discussão do projeto.

São eles:

  • Joismar Antonio Batista Braga (jabb)
  • Lerisson F. Freitas (lff3)
  • Lucas Serra da Cunha Assad (lsca)
  • Mateus Cardozo Gomes da Silva (mcgs)
  • Paulo Sergio da Silva Rodrigues (pssr)
  • Ricardo Ferreira dos Santos Junior (rfsj)
  • Sandrine Ventura Martins (svm2)
  • Vinícius Giles Costa Paulino (vgcp)

Além dos monitores, temos também uma equipe de consultores, que estão disponíveis também para ajudar, sempre que solicitados, são eles:

  • Alysson dos Santos Lima (asl)
  • Antonio Augusto Correa Gondim Neto (aacgn)
  • Antonio Rodrigues da Mata Neto (armn)
  • André Victor Costa de Melo (avcm)
  • Avyner Henrique B. da Fonseca Lucena (ahbfl)
  • Denio Batista Brasileiro Bezerra (dbbb)
  • Hugo Roberto de Melo Daher (hrmd)
  • Ian Fireman (imlbf)
  • Isabel Oliveira Jordao do Amaral (ioja)
  • Joao Vitor Bizerra de Araujo (jvba)
  • Johnny Mayron Santana Ferreira (jmsf2)
  • Jorge Henrique Cordeiro Linhares (jhcl)
  • José Durval Carneiro Campello Neto (jdccn)
  • Linaldo Leite Ferreira Junior (llfj)
  • Marcela Pereira de Oliveira (mpo)
  • Mariana Ferreira de Melo (mfm2)
  • Matheus Raz de Oliveira Leandro (mrol)
  • Pedro Jose de Souza Neto (pjsn)
  • Pedro Paulo Sousa Neto (ppsn)
  • Rafael Felipe Pedroza Jordao (rfpj)
  • Rafael Leonardo de Lima Brito (rllb)
  • Ricardo Ebbers Carneiro Leao (recl)
  • Victor Hugo Barbosa Arruda (vhba)
  • Wellington Oliveira (wmof)

Bibliografia principal (mas não limitada a)

P. Bourque and R.E. Fairley, eds., Guide to the Software Engineering Body of Knowledge, Version 3.0, IEEE Computer Society, 2014; www.swebok.org. Disponível online.

Bibliografia complementar

  • SOMMERVILLE, I. Engenharia de Software. 9ª. Ed. São Paulo: Pearson Education, 2011.
  • Mary e Tom Poppendieck. Implementando o Desenvolvimento Lean de Software: Do conceito ao dinheiro. Bookman. 2010.
  • Matt Wynne and Aslak Hellesoy. The Cucumber Book: Behaviour-Driven Development for Testers and Developers. Pragmatic Bookshelf, 2012

Ferramentas

Links, posts e artigos diversos

5thewin's People

Contributors

emm2 avatar iillx avatar marciodeaquino avatar

Watchers

 avatar  avatar  avatar  avatar  avatar

5thewin's Issues

Criar Labels

Criar labels de acordo com a especificação dada na monitoria sobre Git & Github.

Feedback Iteração 2

Postmortem
-> Sem erros de português
- O que estava planejado
-> Realização das HUs 01 e 02, porém as mesmas não possuem fácil identificação (sem nome específico para as HUs)
- O que foi feito
-> Nenhum teste foi realizado, testes continuam iguais a iteração anterior
- O que não foi feito
-> Faltaram as razões de não realização dos testes
- O que está planejado pra próxima iteração
-> Nenhuma informação sobre o que está planejado para a iteração seguinte foi informado
- Lições aprendidas
-> Nada a acrescentar

Identificar o subconjunto de histórias trabalhadas na iteração
- Cadastrar issue
-> Issues cadastradas
- Atribuir a um responsável
-> Responsáveis atribuídos
- Utilizar labels
-> Labels utilizadas, porém cmo não informações sobre os status do desenvolvimento não foi possível adicionar as labels referentes a review e/ou accepted as issues

Usar BDD + TDD
- Desenvolver as HUs
-> TDD e BDD inexistentes, não houve mudança entre as iterações
- Utilizar padrão do cucumber e rspec
-> Como nenhum teste foi desenvolvido, não há utilização de padrões

Modelo ER
- Modelo Inserido
-> O modelo foi apresentado em issues, porém não encontra-se commitado no código

Corrigir README

Corrigir README do projeto de acordo com as especificações solicitadas no site da disciplina:
https://sites.google.com/a/cin.ufpe.br/if977/projeto

Há também o modelo do README com as seções necessárias e obrigatórias.

O motivo da correção deve-se:

  1. semanticamente falando, objetivos e descrição são coisas diferentes;
  2. a descrição do produto está simples e vaga.

Uma dúvida: qual o nome da aplicação que vcs irão desenvolver? 5theWin ou outro?

Feedback Iteração 0

Preenchimento do Github
Nome do projeto:

  • o nome do projeto não estava explicito na entrega

Justificativa:

  • a justificativa não apresentava de forma clara as razões pelas quais o projeto estava sendo realizado

Descrição:

  • não havia descrição, o que foi confundido com o objetivo e mesmo assim as semânticas são diferentes.

Uso das labels:

  • equipe não criou as labels no prazo, além disso as cores não estavam de acordo com o especificado. também não foi possível para o monitor adicionar as labels durante a correção pq ainda não possuem permissão no projeto para adicionar labels

Erros de português:

  • pontuação não utilizada corretamente

Ata de reunião com o cliente
Participantes da reunião:

  • papeis de dois membros não estavam especificados

Tópicos discutidos:

  • o tópico definição de product owner não ficou claro, não é possível identificar se o PO foi definido na reunião ou se as HUs foram identificas e priorizadas pelo PO

O que foi definido:

  • não ficou claro o que foi definido na reunião, apenas as ações a serem tomadas

Erro de labels:

  • não houve criação de issue para a ata de reunião, consequentemente não houve utilização de labels

Criação de mockups e storyboards Lo-Fi para HUs
Demonstrar as principais funcionalidades:

  • não há identificação de qual HU cada mockup corresponde, bem como existem bem mais HU's do que Lo-Fi's presentes

Sequência de acontecimentos:

  • Não foi feito o mapeamento de navegação dos mockup's, qual ação que é tomada pelos botões presentes.

Descrição das cenas:

  • alguns desenhos ficaram muito claros impedindo uma boa visualização dos cenários

Uso de Labels:

  • não foram criadas issues para a criação dos mockups, como consequência, também não foram utilizadas as labels

Criação de histórias de usuários inicias
História bem escrita:

  • algumas HUs estão confusa sobre quais papeis irão utilizar como no caso do gestor público (político) pois um gestor público não necessariamente precisa ser um político, também há repetição de HUs e as mesmas não estão identificadas. Outra HU não muito clara foi a última, como cidadão - 25, o que significa esse 25?

Uso de labels:

  • não foram criadas issues para Hus, como consequência as labels não foram utilizadas

Feedback Iteração 3

Postmortem
-> Sem erros de português
- O que estava planejado
-> Realização das HUs 01 e 02
- O que foi feito
-> Nenhum teste foi realizado, testes continuam iguais a iteração anterior, HU2 não foi commitada
- O que não foi feito
-> Faltaram as razões de não realização dos testes e motivos da HU2 não ter sido commitada
- O que está planejado pra próxima iteração
-> Informações incompletas quanto ao que será realizado
- Lições aprendidas

Identificar o subconjunto de histórias trabalhadas na iteração
- Cadastrar issue
-> As issues estavam cadastradas, porém não houve mudança do milestone para a iteração 3
- Atribuir a um responsável
-> Tarefas atribuídas a um responsável
- Utilizar labels
-> Labels utilizadas, porém cmo não informações sobre os status do desenvolvimento não foi possível adicionar as labels referentes a review e/ou accepted as issues

Usar BDD + TDD
- Desenvolver as HUs
-> TDD e BDD inexistentes, não houve mudança entre as iterações
- Utilizar padrão do cucumber e rspec
-> Como nenhum teste foi desenvolvido, não há utilização de padrões

Feedback Iteração 1

Postmortem

  • Sem erros de português

O que estava planejado

  • Escolheram apenas uma HU para desenvolvimento, onde o mínimo seriam duas
  • Faltou a delegação de tarefas durante o planejamento

O que foi feito

  • Testes de aceitação incompletos, poucos cenários (apenas um cenário feliz)

O que não foi feito

  • Faltou as razões de não terem sido feitas

O que está planejado pra próxima iteração

  • Lições aprendidas preenchido

Identificar o subconjunto de histórias trabalhadas na iteração
Cadastrar issue

  • Até a data de encerramento da iteração, nenhuma issue foi cadastrada

Atribuir a um responsável

  • Nenhum responsável foi atribuido

Utilizar labels

  • Labels não utilizadas

Usar BDD + TDD
Desenvolver as HUs

  • TDD inexistente, BDD adicionado apenas após 2 dias do termino da iteração

Utilizar padrão do cucumber e rspec

  • No BDD, há apenas um caso feliz, possuindo assim casos de teste insuficientes.
  • Código não possui backend, o caso de teste está com os passos pendentes.

Feedback Iteração 4

Postmortem
-> Sem erros de português
- O que estava planejado
-> Realização das HUs 06, 04, 12 e 11
- O que foi feito
-> Testes foram escritos, com poucos cenários e sem backend.
- O que não foi feito
-> Faltaram as razões da realização parcial dos testes
- Lições aprendidas
-> Lições aprendidas detalhadas

Identificar o subconjunto de histórias trabalhadas na iteração
- Cadastrar issue
-> As issues estavam cadastradas, com milestones corretas, porém, ainda existe dificuldade de identificação do que se trata cada HU
- Atribuir a um responsável
- Utilizar labels
-> Labels utilizadas, porém como não existem informações sobre os status do desenvolvimento não foi possível adicionar as labels referentes a review e/ou accepted as issues

Usar BDD + TDD
- Desenvolver as HUs
-> TDD inexistente e BDD incompleto, cenários insuficientes. Por se tratar da última iteração, todos os testes deveriam possuir backend e estarem passando (com a cor verde)
- Utilizar padrão do cucumber e rspec
-> nenhum feature do rspec foi desenvolvido. Testes de cucumber incompletos.

Screencast
- Completude
-> Funcionalidades abordadas, usuário consegue saber como utilizar a aplicação
-> screencast não contém áudio

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.