Artefatos Sprint 1

O primeiro passo de qualquer projeto deve ser de prospecção. A razão de existir da engenharia é a solução metódica dos problemas das pessoas através do conhecimento da ciência aplicada. Sendo assim, a prospecção deve primeiro focar nas pessoas, para depois entender como entregar valor e, por fim, definir um escopo para o projeto.

Para finalidade de avaliação, divide-se essa etapa inicial em:

1. Proposta de design;
2. Proposta de negócios; e
3. Proposta de arquitetura.

A seguir, é possível ver com detalhes o que se espera em cada uma dessas entregas.

1.1. Enunciado

A proposta de design do projeto contempla a arquitetura da informação prevista para a interface do usuário. Para isso, deve-se realizar uma análise detalhada para compreender o perfil do usuário final. Sendo assim, para esse entregável, espera-se:

Definição das personas

Descrever o perfil completo de, no mínimo, duas personas que utilizarão o sistema em desenvolvimento. As descrições devem ser fundamentadas em uma pesquisa utilizando artigos científicos, relatórios de mercado, entre outros materiais. A descrição das personas deve incluir:

1. dados demográficos (nome, idade, gênero, escolaridade);
2. perfil profissional (cargo/função ocupado atualmente, habilidades/capacidades, nível de letramento digital);
3. dores/necessidades/desejos;
4. cenário(s) de uso.

Definição das user stories

Descrever pelo menos duas user stories para cada persona (totalizando pelo menos quatro user stories diferentes), seguindo a estrutura "Pessoas + necessidade + objetivo", por exemplo: "Como engenheiro, quero operar um robô móvel para inspecionar tubulações, tanques ou outras estruturas em locais de difícil acesso, como em alturas elevadas ou em espaços confinados, sem precisar entrar nesses locais e me colocar em risco."

Arquitetura da informação

Projetar a arquitetura da informação prevista para a interface em diagramas de relação e de sequência. O objetivo é responder a seguinte pergunta: que tipo de informação cada persona irá buscar no sistema e como ela irá encontrá-la?

1.2. Padrão de entrega

warning

O padrão de entrega do artefato contempla uma série de requisitos para que a atividade seja considerada concluída. Embora não haja atribuição direta de pontuação aos itens aqui descritos, entenda-se que o não cumprimento de qualquer dos requisitos pode, no melhor dos casos, acarretar em um desconto de nota e, no pior caso, invalidar a entrega por completo. Fique atento!

1. O texto desenvolvido pelo grupo deve estar disponível em uma página estática gerada pelo framework Docusaurus. Para tal, deve haver um diretório no repositório denominado docs, onde ficará a raíz do Docusaurus;
2. A documentação da sprint 1 deve estar inteiramente contida em uma seção denominada Sprint 1. Cada um dos artefatos deve ter sua descrição contida em uma página ou subseção dentro da seção Sprint 1; e
3. As figuras utilizadas no documento devem sempre ser referenciadas no texto, com descrições textuais que estimulem a coesão entre o que é apresentado visualmente e o restante do texto.

1.3. Padrão de qualidade

1.3.1. Definição das personas (até 3,0 pontos)

[0,0 - 0,5] As personas estão incompletas ou não alinhadas com o contexto do projeto.

[0,5 - 2,0] As personas são completas e coerentes com o contexto do projeto, mas as descrições carecem de detalhamento ou profundidade na pesquisa.

[2,0 - 3,0] As personas são detalhadas, baseadas em pesquisas profundas e bem documentadas, mostrando clara coerência com o projeto e os objetivos do parceiro.

1.3.2. Definição das user stories (até 2,0 pontos)

[0,0 - 1,0] As user stories estão incompletas ou não refletem as necessidades das personas ou do projeto.

[1,0 - 2,0] As user stories são completas, claramente formuladas e alinhadas com as personas e o contexto do projeto.

1.3.3. Arquitetura da informação (até 4,0 pontos)

[0,0 - 1,0] A arquitetura da informação é incompleta ou incoerente com o projeto.

[1,0 - 2,0] A arquitetura da informação está completa e contextualizada, mas alguns elementos ainda são vagos ou pouco informados pela pesquisa.

[2,0 - 3,0] A arquitetura da informação é coerente, com decisões bem informadas pela pesquisa, mas faltam detalhes nos diagramas.

[3,0 - 4,0] A arquitetura da informação é detalhada, clara e totalmente informada pela pesquisa, com diagramas que refletem de forma resumida e clara a disposição dos dados.

1.3.4. Inovação (até 1,0 ponto)

[0,0 - 0,5] O projeto não apresenta elementos claros de inovação ou os elementos não são adequadamente justificados.

[0,5 - 1,0] O projeto inclui elementos de inovação claramente justificados que demonstram impacto e valor significativos para o avanço do projeto.

2. Proposta de negócios

2.1. Enunciado

Para que um projeto seja bem sucedido, não basta que ele resolva o problema de pessoas; é necessário que ele seja viável também. Para isso, deve-se realizar uma análise do moelo de negócios com a finalidade de compreender qual o valor do projeto a ser desenvolvido e quais são os seus potenciais riscos. Sendo assim para este artefato pede-se:

1. Business model canvas; e
2. Matriz de risco.

Business model canvas

O Business Model Canvas é uma ferramenta estratégica de gestão e planejamento que permite visualizar as principais funções de um negócio em um único quadro. Criado por Alexander Osterwalder, este modelo é dividido em nove blocos principais que cobrem os elementos cruciais de um negócio: Segmentos de Clientes, Propostas de Valor, Canais, Relacionamento com Clientes, Fontes de Receita, Recursos Principais, Atividades-chave, Parcerias Principais e Estrutura de Custos. A utilização do Canvas facilita a compreensão, design e inovação de modelos de negócios, ajudando empreendedores e empresas a alinhar suas atividades por meio de uma visão clara e compartilhada, garantindo que todas as partes do negócio trabalhem em harmonia para alcançar seus objetivos estratégicos.

Template do business model canvas

Matriz de risco

A matriz de risco é uma ferramenta utilizada no gerenciamento de riscos para avaliar e priorizar riscos com base em sua probabilidade de ocorrência e impacto potencial. Essa ferramenta visual ajuda as organizações a identificar quais riscos requerem atenção imediata e quais podem ser monitorados com menos urgência. Tipicamente, a matriz é organizada em um formato de grade com a probabilidade de um lado e o impacto no outro, criando quadrantes que categorizam os riscos como baixos, moderados, altos ou extremos. Isso permite que gerentes e equipes de projeto tomem decisões informadas sobre onde concentrar recursos e esforços para mitigação de riscos, contribuindo para uma gestão mais eficaz e proativa dos desafios potenciais.

Template da matriz de risco

2.2. Padrão de entrega

warning

O padrão de entrega do artefato contempla uma série de requisitos para que a atividade seja considerada concluída. Embora não haja atribuição direta de pontuação aos itens aqui descritos, entenda-se que o não cumprimento de qualquer dos requisitos pode, no melhor dos casos, acarretar em um desconto de nota e, no pior caso, invalidar a entrega por completo. Fique atento!

1. O texto desenvolvido pelo grupo deve estar disponível em uma página estática gerada pelo framework Docusaurus. Para tal, deve haver um diretório no repositório denominado docs, onde ficará a raíz do Docusaurus;
2. A documentação da sprint 1 deve estar inteiramente contida em uma seção denominada Sprint 1. Cada um dos artefatos deve ter sua descrição contida em uma página ou subseção dentro da seção Sprint 1.
3. As figuras utilizadas no documento devem sempre ser referenciadas no texto, com descrições textuais que estimulem a coesão entre o que é apresentado visualmente e o restante do texto; e

2.3. Padrão de qualidade

2.3.1. Business model canvas (até 6,0 pontos)

2.3.1.1. Oferta (até 1,5 pontos)

Componentes: Proposta de Valor, Segmentos de Clientes

[0,0 - 0,5] A oferta não é clara ou relevante para os segmentos de clientes identificados; falta alinhamento entre a proposta de valor e as necessidades dos clientes.

[0,5 - 1,0] A oferta é relevante, mas a descrição é genérica; falta detalhamento sobre como a proposta de valor satisfaz especificamente as necessidades dos segmentos de clientes.

[1,0 - 1,5] A oferta é bem definida, claramente alinhada com os segmentos de clientes, e detalhadamente adaptada às suas necessidades e desejos.

2.3.1.2. Clientes (até 1,5 pontos)

Componentes: Canais, Relacionamento com Clientes

[0,0 - 0,5] Estratégias de comunicação e relacionamento são inapropriadas ou mal definidas, com canais mal escolhidos que não atingem os clientes efetivamente.

[0,5 - 1,0] Canais e estratégias de relacionamento estão identificados, mas não há uma estratégia clara que fortaleça a relação de forma significativa.

[1,0 - 1,5] Canais e estratégias de relacionamento com clientes são detalhados, focados e efetivos na construção e manutenção de um relacionamento forte e benéfico.

2.3.1.3. Infraestrutura (até 1,5 pontos)

Componentes: Recursos Principais, Atividades-chave, Parcerias Principais

[0,0 - 0,5] Falta clareza ou relevância nos recursos, atividades-chave e parcerias, ou eles não são adequados para apoiar a oferta ou operação do negócio.

[0,5 - 1,0] Recursos, atividades e parcerias são identificados, mas a descrição de como eles suportam a proposta de valor e a operação do negócio é superficial.

[1,0 - 1,5] Recursos, atividades e parcerias são bem alinhados com a proposta de valor, detalhadamente descritos e fundamentais para o sucesso operacional do negócio.

2.3.1.4. Viabilidade Financeira (até 1,5 pontos)

Componentes: Fontes de Receita, Estrutura de Custos

[0,0 - 0,5] As fontes de receita e a estrutura de custos não são viáveis ou adequadas, ou não estão claramente conectadas com a proposta de valor.

[0,5 - 1,0] Fontes de receita e estrutura de custos estão identificadas, mas a descrição de como eles suportam a sustentabilidade financeira do negócio é insuficiente.

[1,0 - 1,5] Fontes de receita e estrutura de custos são detalhadas, claramente conectadas à proposta de valor e fundamentais para a viabilidade financeira do negócio.

2.3.2. Matriz de risco (até 4,0 pontos)

[0,0 - 1,0] Os riscos mapeados estão fora do contexto do projeto.

[1,0 - 2,0] Os riscos mapeados apresentam ao menos uma correlação com as necessidades do parceiro, mas ainda não são suficientemente específicos, tendo um ou mais riscos definidos de forma genérica (e.g., "Risco de não dar tempo de terminar o projeto").

[2,0 - 3,0] Os riscos mapeados são todos relevantes para o projeto e as necessidades do parceiro. Cada risco é analisado em termos de sua probabilidade de ocorrência e impacto potencial, porém não há estratégias definidas para evitar/mitigar os riscos.

[3,0 - 4,0] Os riscos mapeados são todos ressonantes com o projeto e representam adequadamente os aspectos mais críticos de sua realização. Além disso, foram apresentadas estratégias adequadas e eficazes para evitar/mitigar cada um dos riscos mapeados, incluindo detalhes sobre implementação e acompanhamento dessas medidas.

3. Proposta de arquitetura

3.1. Enunciado

A definição do escopo técnico é a última etapa do planejamento por uma razão essencial: a arquitetura e os requisitos do sistema devem ser derivados diretamente do valor que o projeto se propõe a entregar. Antes de escolher as tecnologias ou ferramentas, é crucial saber qual objetivo se deseja alcançar. Optar por uma tecnologia sem compreender plenamente os requisitos e o contexto do projeto pode levar a escolhas inadequadas e ineficientes.

Neste estágio do projeto, você irá:

1. Definir os requisitos do sistema.
2. Elaborar uma proposta inicial da arquitetura do sistema.

Definição de Requisitos

Com base nos insights obtidos nas fases de design e negócios do projeto, identifique e documente os requisitos essenciais para o sistema:

1. Requisitos Funcionais: Descreva as funcionalidades específicas que o sistema deve oferecer, detalhando as ações que os usuários poderão executar.
2. Requisitos Não Funcionais: Especifique padrões de desempenho e outras métricas de qualidade que o sistema deve atender, explicando como essas características influenciam a usabilidade, a eficiência e a segurança do sistema.

Proposta Inicial da Arquitetura

Esta proposta de arquitetura serve como um esboço inicial e não como um plano definitivo. O objetivo é esclarecer o design básico do sistema, facilitando a estimativa de recursos e prazos para o desenvolvimento:

1. Descrição dos Módulos: Identifique e descreva os principais sistemas ou módulos do projeto, explicando a função de cada um dentro do contexto geral do sistema.
2. Integração entre Módulos: Defina as interfaces de comunicação entre os módulos, incluindo uma descrição em alto nível dos protocolos e métodos de integração.
3. Diagrama de Arquitetura: Elabore um diagrama que visualize a estrutura e as conexões entre os módulos, facilitando a compreensão da configuração e interações do sistema.

Importância da Flexibilidade

Reconheça que esta arquitetura inicial pode evoluir à medida que novos requisitos e desafios emergem durante o desenvolvimento do projeto. A flexibilidade e a adaptação são essenciais para responder efetivamente às necessidades que podem surgir ao longo do processo.

3.2. Padrão de entrega

warning

O padrão de entrega do artefato contempla uma série de requisitos para que a atividade seja considerada concluída. Embora não haja atribuição direta de pontuação aos itens aqui descritos, entenda-se que o não cumprimento de qualquer dos requisitos pode, no melhor dos casos, acarretar em um desconto de nota e, no pior caso, invalidar a entrega por completo. Fique atento!

1. O texto desenvolvido pelo grupo deve estar disponível em uma página estática gerada pelo framework Docusaurus. Para tal, deve haver um diretório no repositório denominado docs, onde ficará a raíz do Docusaurus;
2. A documentação da sprint 1 deve estar inteiramente contida em uma seção denominada Sprint 1. Cada um dos artefatos deve ter sua descrição contida em uma página ou subseção dentro da seção Sprint 1.
3. As figuras utilizadas no documento devem sempre ser referenciadas no texto, com descrições textuais que estimulem a coesão entre o que é apresentado visualmente e o restante do texto; e

3.3. Padrão de qualidade

3.3.1 Qualidade textual (até 2,0 pontos)

[0,0 - 0,5] A documentação é substancialmente incompleta ou irrelevante para o contexto do projeto, falhando em cobrir os temas essenciais requeridos.

[0,5 - 1,0] A documentação aborda todos os temas obrigatórios mas falta coesão, dificultando a compreensão do projeto como um todo. A linguagem é inconsistente ou inapropriada para um documento técnico, resultando em uma leitura desconexa.

[1,0 - 1,5] A documentação é completa e apresenta os temas com coesão suficiente para entender o projeto em geral. O texto tem poucas ocorrências de linguagem inadequada e mantém consistência de estilo na maior parte do documento.

[1,5 - 2,0] A documentação é completamente coesa e clara, com uso de linguagem técnica adequada e consistente ao longo do texto, facilitando a compreensão integral do projeto.

3.3.2 Requisitos (até 4,0 pontos)

[0,0 - 0,5] Os requisitos documentados são inapropriados para o contexto do projeto, não refletindo as necessidades do parceiro ou os objetivos estabelecidos.

[0,5 - 1,5] Os requisitos estão alinhados com os objetivos do projeto, mas faltam métricas de aferição de desempenho e/ou planos detalhados para testes, limitando a verificação de sua implementação.

[1,5 - 3,0] Os requisitos estão bem contextualizados e incluem métricas aferíveis para todos os requisitos não funcionais. No entanto, os planos de teste precisam de mais detalhes para garantir a eficácia da verificação.

[3,0 - 4,0] Requisitos completamente alinhados com o projeto, detalhadamente métricos e com um plano de testes robusto e bem documentado, assegurando a viabilidade de sua implementação.

3.3.3. Detalhamento da arquitetura (até 4,0 pontos)

[0,0 - 0,5] A arquitetura proposta é inadequada, não refletindo as necessidades ou os objetivos do projeto, ou é excessivamente vaga.

[0,5 - 1,5] A arquitetura reflete os requisitos e análises realizadas, com módulos bem definidos e justificativas técnicas claras para a estrutura escolhida. Contudo, a integração entre módulos é descrita de forma superficial.

[1,5 - 3,0] A arquitetura é detalhada e alinhada com os requisitos. Os módulos estão claramente descritos e a comunicação entre eles é explicada através de protocolos especificados. O diagrama, porém, ainda não captura totalmente a arquitetura descrita.

[3,0 - 4,0] A arquitetura é detalhada, coesa e reflete perfeitamente os requisitos. Todos os módulos e suas integrações são claramente descritos, e o diagrama sintetiza eficazmente a arquitetura completa de forma visualmente acessível.